14:09:15 <colindixon> #startmeeting of app coexistences
14:09:15 <odl_meetbot> Meeting started Thu Oct 15 14:09:15 2015 UTC.  The chair is colindixon. Information about MeetBot at http://ci.openstack.org/meetbot.html.
14:09:15 <odl_meetbot> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:09:15 <odl_meetbot> The meeting name has been set to 'of_app_coexistences'
14:10:39 <colindixon> #topic andre presents his take
14:11:02 <colindixon> #chair afredette alagalah abhijitkumbhare
14:11:02 <odl_meetbot> Current chairs: abhijitkumbhare afredette alagalah colindixon
14:12:42 <colindixon> #info to be clear, his take is the problem we're trying to solve is the specific coexistence between either (a) GBP + SFC and (b) NetVirt + SFC
14:12:52 <colindixon> #link https://docs.google.com/presentation/d/1tEa1Z_AW-NusViY7fvDtDlvP064ExWJlH-8KP2yuS8g/edit?usp=sharing slides
14:13:47 <colindixon> #info low-level issues to solve: (i) independent pipelines, (ii) table 0 problem, (ii) application-cooperation or handoff
14:15:55 <colindixon> #info higher level issues: (1) abstractions for for packet hand-off, independent pipelines, and table-0 pipeline classifiers, (2) composable applications, e.g., more than just these three and you could do more mix-and-match (not today)
14:19:11 <colindixon> #info emphasizes that we will have have application co-existence in all OVS instances because SFs are VMs and we will need some way to access them, e.g., even if hypervisors are isolated to being SF-hosting or host-hosting, we'll still likely need some overlay management of of the SF-hosting hypervisor switch to manage the SFs as the VMs they are
14:19:40 <colindixon> #info alagalah says yes, he'd been thinking the same thing, but both he and afredette agree that it might be a rathole for today and agree to talk offline
14:20:54 <colindixon> #info in the general case, it's very clear that if SFs and hosts are on the same hypervisor(s) then you need to share the hypervisor switch
14:21:15 <colindixon> #Info alagalah notes that handling the case where everything is attached to the same switch is key
14:21:58 <colindixon> #info if you don't the amount of state/responsibility required at the app level is huge and makes having an abstraction almost useless
14:23:43 <colindixon> #info afredette's table 0 proposal: is (i) keep it simple, (ii) use table 0 only for first arrival: if on a service path hand to sfc, otherwise to overlay manager, e.g., GBP or OVSDB, (iii) resubmit goes to table != 0, (iv) we need to handle both local and network port traffic
14:31:08 <alagalah> https://docs.google.com/presentation/d/1ETDWzdjOOGpMO2jOxj198FQg430EA3nMuBQW2fKWlrQ/edit#slide=id.g66a855e37_0_731
14:31:10 <colindixon> #info alagalah says that this is interesting and it's related to ttkacik's suggestion of having virtual table namespaces
14:32:53 <colindixon> #info colindixon asks if we could just have a table 0 with openflow rule requests so that we don't have to bake specific match criteria into the table 0 solution
14:33:13 <colindixon> #link https://docs.google.com/presentation/d/1ETDWzdjOOGpMO2jOxj198FQg430EA3nMuBQW2fKWlrQ/edit#slide=id.g66a855e37_0_731 alagalah shows this slide as a discussion item
14:34:01 <colindixon> #info alagalah suggests maybe doing two passes a test/dev pass to identify conflicts and then a second pass (possibly with development, but maybe only with config changes) to create heuristics to resolve the conflicts
14:37:28 <colindixon> #info colindixon says he's increasingly convinced that's probably the right approach as avoiding conflicts is likely going to require baking in knowledge of other applications being baked into a given applications match criteria
14:39:01 <colindixon> #info alagalah's link above is a use-case-specific example of his take on a set of heuristics that deal with this
14:46:16 <colindixon> #info alagalah asks what the heuristics would look like concretely
14:46:59 <colindixon> #info colindixon says in his mind it would be a list of table 0 matches, priorities, and next table IDs, which we would provide canned versions of, but we would allow anyone who wanted to load their own version
14:48:07 <colindixon> #info alagalah and afredette seem to agree with this approach, especially if we give pre-canned versions
14:49:16 <colindixon> #info there's some debate in alagalah's head as whether this should be an xml config file or as data in the MD-SAL
14:50:33 <colindixon> #info alagalah says that for those who are interested they have two classes in GBP: FlowUtils which helps in building flows and a separate OFFlowWriter which manages some plugin issues, it could act as a intermediary before dropping into the normal flow programming
14:50:53 <colindixon> #info alagalah notes that, for example, it creates unique flowIDs in a user-friendly way
14:52:17 <colindixon> #info colindixon notes that Yi's work is another example of such a layer
14:52:39 <colindixon> #info colindixon notes that we probably need a java interface and an actual service for the abstractions afredette called out on his slide 6
14:54:08 <colindixon> #info packet-handoff cases OM to SFC and SFC to OM (also same bridge vs. different bridge)
14:54:44 <colindixon> #info if on same bridge: set metadata? table jump? resubmit?
14:55:09 <colindixon> #info if on different bridges, add packet header, who sets up the tunnel? alagalah says he things OM has to do the tunnel
14:55:31 <colindixon> #topic what's next (afredette's last slide)
14:56:19 <colindixon> #info agree on the details to get it working at least for GBP, SFC, and OVSDB to get implementations to work soon
14:56:43 <colindixon> #info create abstraction: application interface and code to generate correct flows
14:57:23 <colindixon> #info application interface is: (i) like a function signature of message passing interface, (ii) inter-bridge, (iii) inter-bridge
14:59:46 <abhijitkumbhare> Just curious Andre works for OVSDB?
15:00:51 <colindixon> abhijitkumbhare: afredette works on OVSDB and is employed by RedHat
15:10:57 <colindixon> #endmeeting