#opendaylight-meeting: tws

Meeting summary

1. agenda bashing (colindixon, 17:02:00)
   1. https://wiki.opendaylight.org/view/Tech_Work_Stream:Main the TWS main page (colindixon, 17:05:17)
   2. https://lists.opendaylight.org/pipermail/discuss/2015-August/005478.html (alagalah, 17:05:19)
   3. https://lists.opendaylight.org/pipermail/discuss/2015-August/005478.html this is the topic alagalah proposed for today and nobody else had anything, so here we are (colindixon, 17:05:58)
   4. the 3 proposed topics were: (1) app coexitence via layered/stacked pipelines, (2) growing a proper overlay layer that can meet the needs of other layers, e.g., Policy and SFC, (3) Honeycomb: building a disgtributed ODL agend out of ODL parts that could run on the local server (colindixon, 17:07:20)
   5. these topics came out of the summit and edwarnicke shares out the slides (colindixon, 17:08:03)
   6. https://docs.google.com/presentation/d/1hPqNVgrvTDbgw0FmMdQ6nEWve6D7fYYCrtPz2qYztEM/edit#slide=id.g63c24fb28_0_0 (edwarnicke, 17:08:35)
   7. edwarnicke also notes that these are somewhat different than prior efforts as they don’t generally fit inside a single project and fall more cross-project (colindixon, 17:09:16)
   
   
2. app coexistence through a stack/layer approach (colindixon, 17:09:32)
   1. edwarnicke says when it comes to OpenFlow coexistence we have a series of approaches (colindixon, 17:09:50)
   2. a common one is the global arbiter that says yes/no and/or modifies flows, edwarnicke doesn’t sense an appetite for this from OF app devs (colindixon, 17:10:15)
   3. another approach was used by GBP/SFC in Lithium, was a light-handoff between different functions (essentially passing between tables) (colindixon, 17:10:43)
   4. in networking, we generally succeed with layers, edwarnicke has one idea of three layers with policy over SFC over Overlay (colindixon, 17:11:21)
   5. edwarnicke says there are a few things that need to be worked out: (1) how do handoffs actually happen and (2) how we allocate tables to logical functions (colindixon, 17:12:42)
   6. alagalah asks if we want to try to solve this in the general case for OpenFlow or for OVS specifically (colindixon, 17:13:32)
   7. jan medved says that this *has* to be OVS-specific because the appraoch of put nearly anything in any table and create tables as you see fit just doesn’t exist in h/w switches (colindixon, 17:14:10)
   8. Uri suggests that we do go along the lines of investigating how to work with hardware even if over the period of years (colindixon, 17:15:12)
   9. colindixon asks are we asking h/w OF vs. s/w OF or OVS OF vs. non-OVS OF? (colindixon, 17:18:01)
   10. edwarnicke says that from his memory of cpqd was that it stayed very close the OF spec, apps tended to require OVS-specific things like registers, and cpqd was a pain in the ass to get running at all (colindixon, 17:19:26)
   11. Uri says that we should focus on one thing for the short term to get things working, but again keeping in mind working more broad would help (colindixon, 17:19:51)
   12. edwarnicke’s notes on cpqd were in response to Jan’s question if other vSwitches would just work with OVS, the answer is seemingly not easily (colindixon, 17:20:24)
   13. alagalah says that tony had talked about an idea that would translate a general pipeline into more h/w or vSwitch-specific rules (colindixon, 17:23:07)
   14. there’s a lot of discussion TTPs as way to handle diverse switch table formats, but maybe in the longer run (colindixon, 17:24:23)
   15. ACTION: alagalah to reschedule followup for OpenFlow App co-existance... key thing to resolve: general vs OVS solution. (alagalah, 17:31:35)
   
   
3. overlay manager layer (colindixon, 17:31:38)
   1. this stems from the issue that every app/layer (or at least many of them) are managing their own overlays complete with tunnels and everything else (colindixon, 17:32:18)
   2. edwarnicke’s idea is to first have a way to register a key that points to an overlay topology, a key could be an IP subnet, VLAN, etc. (colindixon, 17:33:31)
   3. in effect this is what the LISP mapping service in OpenDaylight already does (colindixon, 17:34:42)
   4. LuisGomez says that this is too hard for him to follow without an example (colindixon, 17:36:04)
   5. vishnoianil asks what the problem statement is (colindixon, 17:36:13)
   6. edwarnicke says this stems from gettting SFC and GBP to work together and it comes down to two problems: (1) how do we pass things back and forth between apps, e.g., SFC and GBP, (2) handling exit from chains to the next handler (colindixon, 17:37:41)
   7. vishnoianil says shouldn’t the exit be handled by that layer, but edwarnicke says that it’s no the way ti works, right now SFC doesn’t handle egress forwarding and maybe shoudln’t since it woudl require it to be nearly omniscient (colindixon, 17:39:54)
   8. alagalah adds that the SFC spec deosn’t specify egress filters, and so you need some logical equivalent to handle dealing with egress (colindixon, 17:41:10)
   9. alagalah says that it has to deal with *all* corner cases otherwise the amount of state that the consumers need to maintain may make this harder to use rather than not use (colindixon, 17:42:08)
   10. LuisGomez asks if this will work in a generic OpenFlow network, colindixon says that there was some discussion, but the zeitgeist seemed to be that we’d focus on OVS to actually get things done (colindixon, 17:44:05)
   
   
4. Honeycomb (colindixon, 17:44:13)
   1. edwarnicke says the problem statement here is that we do a lot of handling packet_ins, but forwarding packet_ins to a controller is expensive and making global decisions on packet_ins is even more so (colindixon, 17:45:08)
   2. instead, we could run a stripped down version of ODL on the servers by the vSwitches to handle most packet_in events locally (colindixon, 17:45:29)
   3. this “looks like” it would scale much better and might open up other alternative design points to OpenDaylight (colindixon, 17:45:54)
   4. Uri says we need to look at what should go in the stripped down ODL instance, what footprint it should have, how it performs, etc. (colindixon, 17:47:08)
   5. colindixon says the two big things he worries about are: (1) the engineering challenges to effectively build an ODL unikernel for ODL apps and (2) what does this buy us in terms of our creating a custom ODL to stripped-down ODL (colindixon, 17:50:23)
   6. on the first one, we desperately need to see how well we can scale it down while still doing useful things (colindixon, 17:50:46)
   7. on the second one, desiging the protocol between ODL and stripped-down ODL so that it’s not so “fat” that interactions bottleneck performance, but not so “thin” that it’s negligibly better than what your replacing, e.g., packet_ins (colindixon, 17:51:40)
   8. jan points out that resource utilization and performance are different things and that we have pretty impressive performacne numbers (colindixon, 17:53:35)
   9. vina_ermagan asks for jan’s numbers, jan says he’ll get her scripts and test setups to replicate them (colindixon, 17:53:53)
   
   
5. future meetings (colindixon, 17:55:06)
   1. it’s looking like there will be a meeting on Thursday morning (and future Thursday mornings) (colindixon, 17:55:47)
   2. the meeting will be at 7a pacific time on thursday (colindixon, 17:57:01)
   3. ACTION: edwarnicke will send an invite for the Thursday 7a pacific follow-up meeting over e-mail soon (colindixon, 17:58:10)
   4. ACTION: colindixon to try to find some topic for next week, hopefully user stories, maybe intern projects, maybe Jan’s performance numbers, etc. (colindixon, 17:59:49)
   5. vishnoianil asks for some kind of blueprint and/ro comprehensible writeup that we can start to work out details on (colindixon, 18:00:53)

Action items

1. alagalah to reschedule followup for OpenFlow App co-existance... key thing to resolve: general vs OVS solution.
2. edwarnicke will send an invite for the Thursday 7a pacific follow-up meeting over e-mail soon
3. colindixon to try to find some topic for next week, hopefully user stories, maybe intern projects, maybe Jan’s performance numbers, etc.

Action items, by person

1. alagalah
   1. alagalah to reschedule followup for OpenFlow App co-existance... key thing to resolve: general vs OVS solution.
2. colindixon
   1. colindixon to try to find some topic for next week, hopefully user stories, maybe intern projects, maybe Jan’s performance numbers, etc.
3. edwarnicke
   1. edwarnicke will send an invite for the Thursday 7a pacific follow-up meeting over e-mail soon

People present (lines said)

1. colindixon (65)
2. alagalah (12)
3. odl_meetbot (7)
4. edwarnicke (3)
5. abhijitkumbhare (3)
6. adetalhouet (2)
7. tbachman (0)
8. dfarrell07 (0)