#opendaylight-group-policy: gbp_requirements

Meeting started by tbachman at 20:09:10 UTC (full logs).

Meeting summary

  1. agenda (tbachman, 20:15:22)
    1. https://lists.opendaylight.org/pipermail/groupbasedpolicy-dev/2014-August/000441.html email describing agenda for today’s meeting (tbachman, 20:15:44)
    2. mickey_spiegel asks what SFC goals are in terms of GBP (tbachman, 20:17:50)
    3. paulq says that the intent of SFC is to provide an infrastructure to chain basic services together (tbachman, 20:18:09)
    4. There’s no tie-ing to a broader policy (tbachman, 20:18:26)
    5. It’s an exercise in plumbing and stitching together the chain (tbachman, 20:18:49)
    6. mickey_spiegel says that the notion of EPGs, contracts, etc. are pure policy stuff. When that drives an action that involves a bunch of services that you want to direct traffic to, there’s a question whether the GBP group has a notion of chaining of it’s own. (tbachman, 20:19:53)
    7. dvorkinista says that this should be in GBP, that in turn uses the API of the service chaining to configure whatever needs to be configured (tbachman, 20:20:17)
    8. paulq says his assumption is that if a user/operator is using this infrastructure, that the SFC would provide an API to satisfy the intent expressed in GBP (tbachman, 20:20:45)
    9. paulq says it’s a question of who instantiates the classifier. THe current implementation is NSH-centric, but there could be other implementations (tbachman, 20:22:40)
    10. mickey_spiegel asks how we can keep an OF renderer and SFC from colliding at the flow tables (tbachman, 20:23:08)
    11. paulq says that the risk of conflict occurs at the classifiers. At the classifier edge, GBP should control the policy entirely (tbachman, 20:23:55)
    12. SFC programs rules around NSH values. (tbachman, 20:25:01)
    13. mickey_spiegel says that people sometimes stitch functions using VXLANs. (tbachman, 20:25:52)
    14. There’s a question of who allocates the VNI value (tbachman, 20:26:21)
    15. dvorkinista says it would be good to have a VNI authority (tbachman, 20:26:37)
    16. It’s either that or segment the namespace (tbachman, 20:26:50)
    17. paulq says the tenant namespace for topology doesn’t require non-conflict mapping (tbachman, 20:28:28)
    18. paulq says he’d like to see GBP reflect things to SFC (tbachman, 20:34:16)
    19. For example, indicate what groups are talking (tbachman, 20:34:22)
    20. So that this can be carried in the NSH (tbachman, 20:34:29)
    21. This would map to the source class and destination class (tbachman, 20:34:47)
    22. If you carry the tenant information in the VXLAN, how do you get this to the service? (tbachman, 20:35:18)
    23. This can be handled in NSH, independent of the VXLAN (tbachman, 20:35:37)
    24. paulq says that when you blur the forwarding and the contextual, it gets very difficult (tbachman, 20:37:05)
    25. you end up overloading, which leads either to incredible complexity, or loss of granularity (tbachman, 20:37:28)
    26. For example, when you have tenant coke with 400 service chains, you don’t want to map these to VLANs (tbachman, 20:37:50)
    27. paulq asks what a GBP intent request to SFC looks like (tbachman, 20:38:08)
    28. dvorkinista says we’d send a list (ordered collection) (tbachman, 20:38:32)
    29. like “we need a firewall”, with qualifiers (e.g. “big” vs. “little”) (tbachman, 20:38:52)
    30. in some cases, we’d need to support graphs, but in the first cut, this may not be required (tbachman, 20:39:09)
    31. paulq says that we can take that, then return either an error condition or return the chain (tbachman, 20:39:24)
    32. mickey_spiegel says there are a few things we need to tackle (tbachman, 20:39:35)
    33. one is graph vs. chain (tbachman, 20:39:40)
    34. beyond that, there’s the question of the services themselves, and the things that tie them together (e.g. “connector”) (tbachman, 20:40:04)
    35. dvorkinista says that the ordered list is probably sufficient (tbachman, 20:40:47)
    36. mickey_spiegel says services do many different things today, and not all are modeled as bumps-in-the-wire (tbachman, 20:41:43)
    37. There’s some indirection needed to decouple the problem, but what that is may restrict what you can do with the service chains (tbachman, 20:42:02)
    38. dvorkinista says that’s where NSH is really good, as it provides all the context needed (tbachman, 20:42:19)
    39. paulq says there are 2 ways to derive context: 1) interface, 2) Network Locator (tbachman, 20:42:59)
    40. where interfaces are port interfaces, VLANs, etc (tbachman, 20:43:19)
    41. where the mapping to interfaes occurs inside NSH (tbachman, 20:44:50)
    42. mickey_spiegel asks if there are proprietary ways to stitch things together, does it fit under the NSH model (tbachman, 20:46:29)
    43. paulq says that there only NSH and implementation version provided by Ericsson (tbachman, 20:46:55)
    44. if others have a mechanism they want to bear, he encourages them to join the SFC project (tbachman, 20:47:20)
    45. dvorkinista asks when using OF, are they doing VNID stitching? (tbachman, 20:47:56)
    46. (OF implementation is being done by Ericsson) (tbachman, 20:48:09)
    47. mickey_spiegel asks if we go in this direction, and it’s more of a chain model, how do we capture the intent and feed it to SFC, given that the existing model is a graph (tbachman, 20:49:24)
    48. dvorkinista says we can still think of them in GBP in terms of graphs, but provide a chain (tbachman, 20:50:02)
    49. paulq says that SFCs original thinking was with graphs, but the current implementation is a chain. (tbachman, 20:50:27)
    50. paulq asks how the intent would look different if we were doing graphs (tbachman, 20:51:09)
    51. sanjay says there’s a classification, a chain with a series of elements, where a chain is intent, and path is an expression of that intent (tbachman, 20:52:43)
    52. if a graph is bunch of chains, then there has to be classification at each service element (tbachman, 20:52:59)
    53. paulq says that SFC supports the concept of N classification events to support the policy (tbachman, 20:53:58)
    54. mickey_spiegel asks if it’s clear where those classifiers would fit (tbachman, 20:54:42)
    55. paulq says they’re not in the yang model now (tbachman, 20:54:54)
    56. conceptually it’s a logical element. In reality, it sits with a service function (tbachman, 20:55:11)
    57. mickey_spiegel says that if the service has multiple terminals, then the service itself drives things (tbachman, 20:56:08)
    58. ATM is making a comeback :) (tbachman, 20:57:10)
    59. sanjay asks what is a service function forwarder (tbachman, 21:02:14)
    60. paulq says architecturally SFC differentiates between the forwarding functionality and the service itself (tbachman, 21:02:30)
    61. this is a logical separation (tbachman, 21:02:34)
    62. this allows the concept of forwarding to not impose on the service function (tbachman, 21:02:50)
    63. The role is to take in an overlay packet, remove the encap, examine NHS, deliver to service function, et. (tbachman, 21:03:15)
    64. paulq says asking a service to do forwarding is typically a problem (tbachman, 21:03:42)
    65. OVS can be an SFF (tbachman, 21:03:51)
    66. This gives you a level of functionality that you don’t have to push to the edge. (tbachman, 21:04:13)
    67. mickey_spiegel asks if the service chain is just a chain of types (tbachman, 21:04:25)
    68. paulq says the chain is types, the path is instances (tbachman, 21:04:34)
    69. mickey_spiegel says that before you provision a service you have to instantiate a chain (tbachman, 21:04:52)
    70. when you instantiate a chain, you create a path for the chain. There’s also a concept of a service function in multiple paths (tbachman, 21:05:25)
    71. mickey_spiegel asks if there’s a way to achieve this today (tbachman, 21:05:32)
    72. paulq says they currently don’t spin up the services since they don’t have a link to the VMM (tbachman, 21:06:08)
    73. This has to wait until this gets hooked into the orchestration system (tbachman, 21:06:23)
    74. (there’s nothing to discover service functions) (tbachman, 21:06:51)
    75. there’s no mechanism today to know whether a network supports a DPI, FW, LB, etc. (tbachman, 21:07:51)
    76. currently there’s a config file that says where the services exist in the network (tbachman, 21:08:10)
    77. mickey_spiegel asks if you want to specify a service function, how is that done (tbachman, 21:08:36)
    78. paulq says that you just pick from a list (tbachman, 21:08:49)
    79. (as provided by the config file) (tbachman, 21:08:55)
    80. paulq says he’d welcome folks to look into the model and provide feedback (tbachman, 21:10:46)
    81. paulq says there aren’t constraints yet, but those will be added eventually (tbachman, 21:15:22)
    82. sanjay asks what the fail mode is (tbachman, 21:17:22)
    83. paulq says it’s used to indicate whether you can re-route around it or whether the chain is invalid (tbachman, 21:17:46)
    84. paulq says they’re adding redundant pairs as well (tbachman, 21:18:56)
    85. mickey_spiegel asks if redundant pairs are under a single service function (tbachman, 21:19:10)
    86. dvorkinista asks if this is used in an anycast way (tbachman, 21:19:28)
    87. paul says you can go around it or use anycast (tbachman, 21:19:38)
    88. paulq will check with Reinaldo Penno to see if he can join Friday’s meeting (tbachman, 21:22:21)
    89. paulq says he has UML figures that he can email (tbachman, 21:22:45)


Meeting ended at 21:24:10 UTC (full logs).

Action items

  1. (none)


People present (lines said)

  1. tbachman (92)
  2. odl_meetbot (3)


Generated by MeetBot 0.1.4.