#opendaylight-meeting: of app coexistences

Meeting summary

1. andre presents his take (colindixon, 14:10:39)
   1. 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)
   2. https://docs.google.com/presentation/d/1tEa1Z_AW-NusViY7fvDtDlvP064ExWJlH-8KP2yuS8g/edit?usp=sharing slides (colindixon, 14:12:52)
   3. low-level issues to solve: (i) independent pipelines, (ii) table 0 problem, (ii) application-cooperation or handoff (colindixon, 14:13:47)
   4. 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)
   5. 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)
   6. 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)
   7. 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)
   8. alagalah notes that handling the case where everything is attached to the same switch is key (colindixon, 14:21:15)
   9. 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)
   10. 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)
   11. https://docs.google.com/presentation/d/1ETDWzdjOOGpMO2jOxj198FQg430EA3nMuBQW2fKWlrQ/edit#slide=id.g66a855e37_0_731 (alagalah, 14:31:08)
   12. alagalah says that this is interesting and it's related to ttkacik's suggestion of having virtual table namespaces (colindixon, 14:31:10)
   13. 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)
   14. 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)
   15. 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)
   16. 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)
   17. 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)
   18. alagalah asks what the heuristics would look like concretely (colindixon, 14:46:16)
   19. 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)
   20. alagalah and afredette seem to agree with this approach, especially if we give pre-canned versions (colindixon, 14:48:07)
   21. 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)
   22. 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)
   23. alagalah notes that, for example, it creates unique flowIDs in a user-friendly way (colindixon, 14:50:53)
   24. colindixon notes that Yi's work is another example of such a layer (colindixon, 14:52:17)
   25. 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)
   26. packet-handoff cases OM to SFC and SFC to OM (also same bridge vs. different bridge) (colindixon, 14:54:08)
   27. if on same bridge: set metadata? table jump? resubmit? (colindixon, 14:54:44)
   28. 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)
   
   
2. what's next (afredette's last slide) (colindixon, 14:55:31)
   1. 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)
   2. create abstraction: application interface and code to generate correct flows (colindixon, 14:56:43)
   3. application interface is: (i) like a function signature of message passing interface, (ii) inter-bridge, (iii) inter-bridge (colindixon, 14:57:23)

Action items

1. (none)

People present (lines said)

1. colindixon (36)
2. odl_meetbot (4)
3. abhijitkumbhare (1)
4. alagalah (1)
5. afredette (0)