#opendaylight-meeting: OF app coexistences

Meeting summary

1. 1. https://lists.opendaylight.org/pipermail/discuss/attachments/20150910/11fe33b7/attachment-0001.pdf the diagram I’m goint to talk to (colindixon, 14:07:08)
   2. https://lists.opendaylight.org/pipermail/discuss/2015-September/005667.html it’s from this mail (colindixon, 14:07:23)
   3. this diagram describes the 3 proposals that have been introduced thus far. (phrobb, 14:09:16)
   4. https://lists.opendaylight.org/pipermail/discuss/2015-September/005689.html colin’s attempt to summarize the high-level API we might need (colindixon, 14:11:46)
   5. https://lists.opendaylight.org/pipermail/discuss/2015-September/005665.html colindixon asks if people agree on #1 and #2 from this mail (which refers to the above diagram) (colindixon, 14:14:26)
   6. uri says this looks like a first step to you, not a full solution, at least in part because it seems to require cooperation between applications every time you change things (colindixon, 14:15:14)
   7. colindixon says he doesn’t see it that way, he sees as punting the issue of picking the chain of snippets and which snippet gets the packet first up to some “smart guy in the sky” or “oracle” (colindixon, 14:18:47)
   8. colindixon got there by basically realizing somebody needs to decide on the ordering of these pipeline snippets, and so you’re not hurting yourself by inventing an entity to do that (colindixon, 14:20:15)
   9. edwarnicke notes that at the summit there was a description that pipeline snippets would provide “roles” and then you would pick a pipelin of roles and provider for each each “role” (colindixon, 14:21:09)
   10. there is a discssion betwen edwarnicke and colindixon about how to build chains (peer-to-peer vs. with a central service), but agree that we need some way to discover (a) the pipeline-snippets, (b) how they should be ordered including who gets packets first, (c) the appropriate mapping between rules in pipeline snippets and rules in the switch, e.g., table number/metatdata mapping (colindixon, 14:28:43)
   11. colindixon notes that you can build the peer-to-peer thing using a centralized registry (with peers registering their desires and the centralized registry just honoring them unless the conflict), while it’s hard to build the centralized registry (allowing for more user control) from the peer-to-peer approach (colindixon, 14:39:22)
   12. a lot of dicussion seesm to agree that what’s presented here is good and solves the problems you can at this leve, and that it somewhat cleanly punts the harder problems up to another layer (colindixon, 14:43:50)
   
   
2. fixed function table numbers (colindixon, 14:45:48)
   1. https://lists.opendaylight.org/pipermail/discuss/2015-September/005646.html abhijitkumbhare’s propoasl (colindixon, 14:46:11)
   2. https://docs.google.com/presentation/d/1MHg0gNELvpzCwOWdnCNLVURd5y5DBat_eOPOAKV7mzo/edit#slide=id.g66a5341cf_2_349 abhijitkumbhare says it’s basically a vairant of option III for a “fixed pipeline” in this presentation (colindixon, 14:46:55)
   3. the basic idea is that you actually assign logical functions to table numbers (or maybe table ranges) (colindixon, 14:47:59)
   4. abhijitkumbhare says that at first you might literally give each app that wants to provide a given function one of the tables there (colindixon, 14:49:41)
   5. Uri says this is more where he wanted to go, because it might make handling conflicts more tenable as you’re going to group all the security providers into one place where you detect conflicts (colindixon, 14:52:51)
   6. colindixon says he shied away from this because (a) conflict detection is hard even in a single table, (b) many functions will actually be rendered in multiple tables, and (c) detecting conflicts when functions are rendered into multiple tables seems nearly impossible (colindixon, 14:54:40)
   7. abhijitkumbhare notes that the other approaches won’t work on hardware switches (colindixon, 15:00:30)
   8. colindixon notes that has been the assumption here, but his hope is that the layer of indirection between what apps *think* they’re writing to (rules in logical pipeline snippets) and what they’re actually writing (rules in a switch) will help to be able to move to hardware (colindixon, 15:03:09)

Action items

1. (none)

People present (lines said)

1. colindixon (26)
2. odl_meetbot (5)
3. abhijitkumbhare (2)
4. phrobb (1)
5. phrobb- (0)
6. edwarnicke (0)