========================================== #opendaylight-meeting: of app coexistences ========================================== Meeting started by colindixon at 14:09:15 UTC. The full logs are available at http://meetings.opendaylight.org/opendaylight-meeting/2015/of_app_coexistences/opendaylight-meeting-of_app_coexistences.2015-10-15-14.09.log.html . Meeting summary --------------- * andre presents his take (colindixon, 14:10:39) * 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 (colindixon, 14:12:42) * LINK: https://docs.google.com/presentation/d/1tEa1Z_AW-NusViY7fvDtDlvP064ExWJlH-8KP2yuS8g/edit?usp=sharing slides (colindixon, 14:12:52) * low-level issues to solve: (i) independent pipelines, (ii) table 0 problem, (ii) application-cooperation or handoff (colindixon, 14:13:47) * 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) (colindixon, 14:15:55) * 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 (colindixon, 14:19:11) * 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 (colindixon, 14:19:40) * 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 (colindixon, 14:20:54) * alagalah notes that handling the case where everything is attached to the same switch is key (colindixon, 14:21:15) * if you don't the amount of state/responsibility required at the app level is huge and makes having an abstraction almost useless (colindixon, 14:21:58) * 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 (colindixon, 14:23:43) * LINK: https://docs.google.com/presentation/d/1ETDWzdjOOGpMO2jOxj198FQg430EA3nMuBQW2fKWlrQ/edit#slide=id.g66a855e37_0_731 (alagalah, 14:31:08) * alagalah says that this is interesting and it's related to ttkacik's suggestion of having virtual table namespaces (colindixon, 14:31:10) * 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 (colindixon, 14:32:53) * LINK: https://docs.google.com/presentation/d/1ETDWzdjOOGpMO2jOxj198FQg430EA3nMuBQW2fKWlrQ/edit#slide=id.g66a855e37_0_731 alagalah shows this slide as a discussion item (colindixon, 14:33:13) * 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 (colindixon, 14:34:01) * 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 (colindixon, 14:37:28) * alagalah's link above is a use-case-specific example of his take on a set of heuristics that deal with this (colindixon, 14:39:01) * alagalah asks what the heuristics would look like concretely (colindixon, 14:46:16) * 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 (colindixon, 14:46:59) * alagalah and afredette seem to agree with this approach, especially if we give pre-canned versions (colindixon, 14:48:07) * there's some debate in alagalah's head as whether this should be an xml config file or as data in the MD-SAL (colindixon, 14:49:16) * 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 (colindixon, 14:50:33) * alagalah notes that, for example, it creates unique flowIDs in a user-friendly way (colindixon, 14:50:53) * colindixon notes that Yi's work is another example of such a layer (colindixon, 14:52:17) * colindixon notes that we probably need a java interface and an actual service for the abstractions afredette called out on his slide 6 (colindixon, 14:52:39) * packet-handoff cases OM to SFC and SFC to OM (also same bridge vs. different bridge) (colindixon, 14:54:08) * if on same bridge: set metadata? table jump? resubmit? (colindixon, 14:54:44) * if on different bridges, add packet header, who sets up the tunnel? alagalah says he things OM has to do the tunnel (colindixon, 14:55:09) * what's next (afredette's last slide) (colindixon, 14:55:31) * agree on the details to get it working at least for GBP, SFC, and OVSDB to get implementations to work soon (colindixon, 14:56:19) * create abstraction: application interface and code to generate correct flows (colindixon, 14:56:43) * application interface is: (i) like a function signature of message passing interface, (ii) inter-bridge, (iii) inter-bridge (colindixon, 14:57:23) Meeting ended at 15:10:57 UTC. People present (lines said) --------------------------- * colindixon (36) * odl_meetbot (4) * abhijitkumbhare (1) * alagalah (1) * afredette (0) Generated by `MeetBot`_ 0.1.4