14:09:15 #startmeeting of app coexistences 14:09:15 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 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 14:09:15 The meeting name has been set to 'of_app_coexistences' 14:10:39 #topic andre presents his take 14:11:02 #chair afredette alagalah abhijitkumbhare 14:11:02 Current chairs: abhijitkumbhare afredette alagalah colindixon 14:12:42 #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 #link https://docs.google.com/presentation/d/1tEa1Z_AW-NusViY7fvDtDlvP064ExWJlH-8KP2yuS8g/edit?usp=sharing slides 14:13:47 #info low-level issues to solve: (i) independent pipelines, (ii) table 0 problem, (ii) application-cooperation or handoff 14:15:55 #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 #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 #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 #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 #Info alagalah notes that handling the case where everything is attached to the same switch is key 14:21:58 #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 #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 https://docs.google.com/presentation/d/1ETDWzdjOOGpMO2jOxj198FQg430EA3nMuBQW2fKWlrQ/edit#slide=id.g66a855e37_0_731 14:31:10 #info alagalah says that this is interesting and it's related to ttkacik's suggestion of having virtual table namespaces 14:32:53 #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 #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 #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 #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 #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 #info alagalah asks what the heuristics would look like concretely 14:46:59 #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 #info alagalah and afredette seem to agree with this approach, especially if we give pre-canned versions 14:49:16 #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 #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 #info alagalah notes that, for example, it creates unique flowIDs in a user-friendly way 14:52:17 #info colindixon notes that Yi's work is another example of such a layer 14:52:39 #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 #info packet-handoff cases OM to SFC and SFC to OM (also same bridge vs. different bridge) 14:54:44 #info if on same bridge: set metadata? table jump? resubmit? 14:55:09 #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 #topic what's next (afredette's last slide) 14:56:19 #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 #info create abstraction: application interface and code to generate correct flows 14:57:23 #info application interface is: (i) like a function signature of message passing interface, (ii) inter-bridge, (iii) inter-bridge 14:59:46 Just curious Andre works for OVSDB? 15:00:51 abhijitkumbhare: afredette works on OVSDB and is employed by RedHat 15:10:57 #endmeeting