#opendaylight-group-policy: gbp_arch

Meeting started by tbachman at 17:07:27 UTC (full logs).

Meeting summary

  1. agenda (tbachman, 17:08:58)
    1. https://git.opendaylight.org/gerrit/gitweb?p=sfc.git;a=tree;f=sfc-model/src/main/yang;h=ad40d0c9861ddb7ce058c0a2379204c7f3293881;hb=218ea63128db2a9d2d1d8e10693a0ebcbe090860 <= link to SFC yang models (tbachman, 17:11:23)
    2. agenda item: SFC Discussion (tbachman, 17:12:10)

  2. SFC Discussion (tbachman, 17:12:21)
    1. mickey_spiegel says that the chain is a list of types, rather than a service function (tbachman, 17:13:08)
    2. sanjay says that a service node may have multiple service functions (tbachman, 17:13:26)
    3. mickey_spiegel asks if service function chain is a list of service functions or service function types (Youcef, 17:16:24)
    4. sanjay says from the intent point of view he thinks its complete, but for the rendering point of view, it is not (tbachman, 17:16:58)
    5. mickey_spiegel sees Paul Quinn’s work is an another alternative within ODL to service chaining (i.e. alternative to what dvorkinista created in previous meetings) (tbachman, 17:19:54)
    6. mickey_spiegel asks why is a service function path not referring to the service function chain from which it was constructed. (Youcef, 17:22:18)
    7. SanjayK says that the renderer takes a chain and builds a path from the available instances for each service function type. (Youcef, 17:23:47)
    8. tbachman notes that the model that sanjay and mickey_spiegel were looking at is an older one (see newer one in meeting minutes above) (tbachman, 17:24:50)
    9. mickey_spiegel says we probably need to talk w/Paul Quinn some more about this (tbachman, 17:25:03)
    10. mickey_spiegel asks whether for group-policy service chain intent, we should go with the model that Mike Dvorkin outlined before or follow the model that the SFC project is building (tbachman, 17:26:01)
    11. readams says that GBP has to do all the connectivity for the elements of the chain. The SFC project can tell us about pieces of the chain (tbachman, 17:27:06)
    12. mickey_spiegel says the big issue is getting in and out of the chain (tbachman, 17:27:24)
    13. readams says if the SFC project is trying to program OF rules outside of GBP then this won’t work (tbachman, 17:27:49)
    14. sanjay says that the SFC and GBP can agree on intent, but how to render it into NSH chaining or OpenFlow (tbachman, 17:28:23)
    15. Rob Adams says that for example, GBP is injecting rules into a switch and SFC is also injecting rules in the same switch, and they may be conflicting and creates problems (Youcef, 17:28:44)
    16. readams says that there’s a lot of work related to orchestration and confiuration of the services themselves, and how you configure a generic firewall, etc. But the SFC crew isn’t working on this (tbachman, 17:29:01)
    17. readams notes that you can go in and manually configure the devices, but that doesn’t solve the problem. (tbachman, 17:29:40)
    18. mickey_spiegel says that the header has everything that’s needed to forward it (tbachman, 17:31:47)
    19. sanjay says that the header provides a service path id (context) and tells you where you are in the chain (tbachman, 17:32:19)
    20. SFC is not tied to NSH headers. It also supports LISP and is open to other mechanisms (Youcef, 17:32:42)
    21. readams asks if a geneve tunnel could be used (tbachman, 17:32:55)
    22. mickey_spiegel says we need to be more generic than this (tbachman, 17:34:31)
    23. mickey_spiegel says that this model is much more of a chain and path model, and that dvorkinista’s model is more of a graph model (tbachman, 17:36:38)
    24. sanjay says that a path to him is an instance of intent, regardless of how they’re organized. (tbachman, 17:37:20)
    25. mickey_spiegel says that the "service graph" model of GBP is different from the path model in SFC. (Youcef, 17:38:20)
    26. readams a path is a graph, but a graph may not necesarrily be a path (tbachman, 17:39:35)
    27. and therefore the graph is more flexible (tbachman, 17:39:43)
    28. mickey_spiegel says it’s worth asking if we need that flexibility (tbachman, 17:39:55)
    29. readams asks what the SFC group is trying to do with their project in ODL (prototype)? (tbachman, 17:41:13)
    30. Youcef says they are building a prototype using a vSwitch with NSH and OpenFlow rules to create the service chain (tbachman, 17:41:34)
    31. they are using OVSDB for managing the vSwitch (tbachman, 17:41:46)
    32. Youcef says there are extensions in Open vSwitch to support NSH (tbachman, 17:41:57)
    33. readams says that the yang model seems specific to NSH (tbachman, 17:44:29)
    34. mickey_spiegel says that’s something we should bring up with paul (tbachman, 17:44:40)
    35. readams says this isn’t some sort of intent model (tbachman, 17:44:48)
    36. mickey_spiegel says he’s not sure about that — that may be what paul was thinking (tbachman, 17:45:03)
    37. Youcef says this is also a mechanism for supporting metadata and service chaining — this isn’t the only model, but they’re open to other things (tbachman, 17:45:30)
    38. mickey_spiegel says that they need to do another model than just NSH to prove that this is actually intent (tbachman, 17:45:47)

  3. Flow Use Case (tbachman, 17:48:07)
    1. We were looking into introducing a concept of session to the model for the UC use case (tbachman, 17:48:41)
    2. readams says he’d prefer holding off working on the model until someone comes to GBP ready to do an implementation for their use case (tbachman, 17:52:02)
    3. sanjay says what about a non-open-source implementation (tbachman, 17:52:48)
    4. readams agrees that’s a valid trigger for evolving the model (tbachman, 17:53:06)
    5. sanjay asks if the application needs to understand the policy model, or will there be a front-end that would provide an API for applications (tbachman, 17:55:23)
    6. readams says you wouldn’t be modifying contracts dynamically for that. You’d create a concept outside of that in an operational store (tbachman, 17:55:55)
    7. sanjay says that in the operational store, you’ll still need to create things like flows, filters for the flows, action for the flows, etc. (tbachman, 17:56:49)
    8. readams says it’s more like you’ll have all the actions and things defined in the contract, and you’re just instantiating that particular subject with respect to specific sessions (tbachman, 17:57:13)
    9. you wouldn’t be creating dynamic subjects or clauses (tbachman, 17:57:31)
    10. sanjay says it’s not clear how you would handle the dynamic flows (tbachman, 17:57:43)
    11. readams says that the simplest case, you have a classifier that says reference the following set of sessions (tbachman, 17:58:00)
    12. that normally wouldn’t do anything, but once one of those sessions is created, that classifier would now match against it (tbachman, 17:58:18)
    13. mickey_spiegel says that we have all these labels — there’s a question whether those as they exist are enough to get a sesion through the clauses to get a subject or whether we need something in addition (tbachman, 17:58:51)
    14. readams says that they’re not (tbachman, 17:58:55)
    15. readams says that the membership of EPs in the EPGs is very dynamic (tbachman, 17:59:45)
    16. This same concept can be extended to classifiers (tbachman, 18:00:05)
    17. sanjay asks where this is residing (tbachman, 18:00:10)
    18. readams says there could be a separate session registry, or the EP registry could be extended to support this (tbachman, 18:00:29)
    19. sanjay says that actions may need dynamic programming (tbachman, 18:00:58)
    20. readams why you would need dynamic programming (tbachman, 18:01:10)
    21. sanjay says an example is a redirect action, a counting action…. (tbachman, 18:01:24)
    22. mickey_spiegel asks if the intent is specific to a single session? (tbachman, 18:01:35)
    23. readams says that some of this can be done with conditions (tbachman, 18:03:39)
    24. readams says the rule would be something like sesson group UCS, and the action would be allow (tbachman, 18:11:43)
    25. The subject has the rule in it, (tbachman, 18:12:22)
    26. the classifier is session group UCS (tbachman, 18:12:28)
    27. The clause pulls in a subject, and a subject has a list of rules in it. (tbachman, 18:13:18)
    28. uchau says that one way we could apply this is to set it up so that they’re types assigned, like all VOIP sessions, and the action is voice QoS (tbachman, 18:13:47)
    29. readams says the action could also be as simple as “allow" (tbachman, 18:13:58)
    30. mickey_spiegel says that navigating a clause and getting to particular subject is a function of EPG membership, requirements, capabilities, etc. (tbachman, 18:14:28)
    31. mickey_spiegel says that if you’re only going navigate your clauses one way, you only need one subject (tbachman, 18:16:39)
    32. a session group could be created, which is analagous to an endpoint group (tbachman, 18:19:00)
    33. the session group would be two endpoints that are referenced by their EP identifiers, with additinoal classifiers (tbachman, 18:19:22)
    34. (e.g. like a service classifier) (tbachman, 18:19:33)
    35. sanjay asks whether there is one session group or multiple? (tbachman, 18:21:00)
    36. readams says session groups can be named (Session group “X”) (tbachman, 18:21:14)
    37. readams says that the user would set up all the rules in advance (tbachman, 18:22:25)
    38. and the set of session groups that exist (tbachman, 18:22:34)
    39. the application would be configured to dynaically put sessions into session groups (tbachman, 18:22:46)
    40. sanjay asks if there is a concept of "action group" similar to session groups (Youcef, 18:23:26)
    41. readams says that it starts making things look like huge ACL lists, which is getting away from the goals of GBP (tbachman, 18:23:57)
    42. : mickey_spiegel says let's try not to solve the issue of grouping actions until we have some use cases\ (tbachman, 18:24:26)
    43. sanjay asks if I need to know if the EPGs that the endpoints belong to, when I'm programming session groups (Youcef, 18:25:31)
    44. readams says that session groups should be developed independent of specific endpoints (Youcef, 18:26:00)
    45. readams says that session groups could be stored in the Endpoint Registry (EPR) or we could have a separate session registry. (Youcef, 18:29:10)
    46. readams says that realizing contracts for communication within an EPG are spotty in GBP, but there is an option to allow communication between endpoints within the same EPG. (Youcef, 18:34:26)


Meeting ended at 18:38:50 UTC (full logs).

Action items

  1. (none)


People present (lines said)

  1. tbachman (86)
  2. Youcef (18)
  3. odl_meetbot (4)


Generated by MeetBot 0.1.4.