14:05:55 <colindixon> #startmeeting OF app coexistences
14:05:55 <odl_meetbot> Meeting started Fri Sep 18 14:05:55 2015 UTC.  The chair is colindixon. Information about MeetBot at http://ci.openstack.org/meetbot.html.
14:05:55 <odl_meetbot> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:05:55 <odl_meetbot> The meeting name has been set to 'of_app_coexistences'
14:06:06 <colindixon> #chair phrobb phrobb-
14:06:06 <odl_meetbot> Current chairs: colindixon phrobb phrobb-
14:06:10 <colindixon> #chair edwarnicke
14:06:10 <odl_meetbot> Current chairs: colindixon edwarnicke phrobb phrobb-
14:07:08 <colindixon> #link https://lists.opendaylight.org/pipermail/discuss/attachments/20150910/11fe33b7/attachment-0001.pdf the diagram I’m goint to talk to
14:07:23 <colindixon> #link https://lists.opendaylight.org/pipermail/discuss/2015-September/005667.html it’s from this mail
14:09:16 <phrobb> #info this diagram describes the 3 proposals that have been introduced thus far.
14:11:46 <colindixon> #link https://lists.opendaylight.org/pipermail/discuss/2015-September/005689.html colin’s attempt to summarize the high-level API we might need
14:14:26 <colindixon> #link 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)
14:15:14 <colindixon> #info 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
14:18:47 <colindixon> #info 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”
14:20:15 <colindixon> #info 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
14:21:09 <colindixon> #info 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”
14:28:43 <colindixon> #info 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
14:39:22 <colindixon> #info 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
14:43:50 <colindixon> #info 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
14:44:10 <colindixon> abhijitkumbhare: you’re next
14:44:17 <colindixon> can you send the link here when we get there
14:44:18 <abhijitkumbhare> What I wanted to talk about this somewhat simplistic approach that I believe most matches the TTP model (so will likely work for switches with more fixed pipelines like hardware switches): https://lists.opendaylight.org/pipermail/discuss/2015-September/005646.html
14:45:13 <abhijitkumbhare> Basically a variation of option 3: of fixed pipeline from: https://docs.google.com/presentation/d/1MHg0gNELvpzCwOWdnCNLVURd5y5DBat_eOPOAKV7mzo/edit#slide=id.g66a5341cf_2_349
14:45:48 <colindixon> #topic fixed function table numbers
14:46:11 <colindixon> #link https://lists.opendaylight.org/pipermail/discuss/2015-September/005646.html abhijitkumbhare’s propoasl
14:46:55 <colindixon> #link 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
14:47:59 <colindixon> #info the basic idea is that you actually assign logical functions to table numbers (or maybe table ranges)
14:49:41 <colindixon> #Info abhijitkumbhare says that at first you might literally give each app that wants to provide a given function one of the tables there
14:52:51 <colindixon> #info 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
14:54:40 <colindixon> #info 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
15:00:30 <colindixon> #info abhijitkumbhare notes that the other approaches won’t work on hardware switches
15:03:09 <colindixon> #info 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
15:03:21 <colindixon> #endmeeting