#opendaylight-group-policy: gbp_arch

Meeting started by tbachman at 17:04:41 UTC (full logs).

Meeting summary

  1. agenda (tbachman, 17:04:47)
  2. SFC Discussion (tbachman, 17:05:08)
    1. intent of meeting is to walk through SFC model (tbachman, 17:06:10)
    2. That will help us deciding what to do in GBP (tbachman, 17:06:31)
    3. The main model is he service-function.yang (tbachman, 17:08:07)
    4. There’s a container for all service functions in the network (tbachman, 17:08:18)
    5. and a list that holds all the service functions, keyed by service function anme (tbachman, 17:08:30)
    6. there’s also operational data that the service function code populates based on input from other services (topology, openflow, etc.) (tbachman, 17:08:55)
    7. There are also RPCs, which are there mostly for completeness (tbachman, 17:09:10)
    8. as most people use internal APIs or REST interfaces (tbachman, 17:09:20)
    9. A service function has a name, type (FW, NAT, etc.), management IP address as per IETF, a leaf for NSH-aware capability (tbachman, 17:09:57)
    10. The service function also has a list of data plane locators (tbachman, 17:10:15)
    11. This is for how packets can reach the service function (e.g. VLAN ID) (tbachman, 17:10:32)
    12. mickey_spiegel asks when you have many locators, is it possible that they’re bound in different ways (e.g. in and out), or are they all treated the same (tbachman, 17:11:14)
    13. rpenno says they don’t make such distinctions. (tbachman, 17:11:31)
    14. this is how a service function forwarder sends to a function — you send to one of these locators (tbachman, 17:11:46)
    15. paulq says that once you break from topology, the concept of in/out (service model perspective) goes away (tbachman, 17:12:37)
    16. The semantic of in/out can be assigned by the policy layer, if desired (tbachman, 17:13:06)
    17. and it doesn’t matter from a service chaining perspective (tbachman, 17:13:20)
    18. in/out is used for policy constructs in the firewall, so as long as it can distinguish that packets are coming in and going out it’s fine (tbachman, 17:13:46)
    19. In other words, you don’t care about the context of the incoming interface (or other distinguisher) isn’t relavent (tbachman, 17:14:21)
    20. The sf-data-plane-locator is specific to the service function (tbachman, 17:15:10)
    21. The philosophy behind the model is that they’re very service function chaining specific (tbachman, 17:15:52)
    22. It presumes there can be more than one administrative domain (tbachman, 17:16:09)
    23. The service function chain is an ordered list of service function types (tbachman, 17:16:35)
    24. A type can be a firewall, NAT, proxy, etc. (tbachman, 17:16:45)
    25. There’s no standardized list for types (tbachman, 17:16:55)
    26. And users can create their own identities for their own deployment (tbachman, 17:17:07)
    27. The types can be linked under a service function chain (tbachman, 17:17:19)
    28. There is also a symmetric property, and ordered-by property (tbachman, 17:17:59)
    29. The service function chain doesn’t decide which element is going to provide a function (e.g. FW) (tbachman, 17:18:45)
    30. refer to the recording to see a demonstration of the UI showing the chains (tbachman, 17:19:33)
    31. The service function forwarder is a switch, router, bridge, etc. (tbachman, 17:19:47)
    32. The service function forwarder is responsible for sending packets to the service function and getting them back from it (tbachman, 17:20:06)
    33. It handles the data plane activities (tbachman, 17:20:15)
    34. There is a list of service function forwarders, keyed by its name (tbachman, 17:21:20)
    35. There is a classifier attached to the service function forwarder (tbachman, 17:21:41)
    36. sanjay asks whether a service function forwarder is in every service node (tbachman, 17:21:57)
    37. rpenno says the service node might not be there in the future (tbachman, 17:22:16)
    38. paulq says that the service function forwarder is something a user would never see (tbachman, 17:22:30)
    39. it allows the service chain to occur (tbachman, 17:22:37)
    40. to build it’s own service function chain topology (tbachman, 17:22:47)
    41. without the service functions to have to be routers (tbachman, 17:22:59)
    42. it provides a logical forwarding on behalf of the service function (tbachman, 17:23:14)
    43. sanjay asks if there’s one forwarder for every service function? (tbachman, 17:23:32)
    44. paulq says the service function forwarder is logical — it *could* be the service function (tbachman, 17:24:16)
    45. can a service function be attached to more than one forwarder? (tbachman, 17:24:31)
    46. yes it can (tbachman, 17:24:34)
    47. paulq says that in the context of GBP, GBP would control the classifier (tbachman, 17:26:17)
    48. mickey_spiegel asks if the classifier is at both the head end and the back if you fork (tbachman, 17:26:40)
    49. paulq says ues (tbachman, 17:26:44)
    50. The classifier is a service function construct — it’s not like a networking classifier (tbachman, 17:28:00)
    51. Each service function forwarder has a set of data plane locators (tbachman, 17:28:32)
    52. This is how service function forwarders can reach each other, and how overlays are constructed (tbachman, 17:28:45)
    53. They can be GRE data plane locators, VxLAN data plane locators, etc. (tbachman, 17:29:00)
    54. Sanjay asks if in a path there will be a single data plane locator for the next hop? (tbachman, 17:29:27)
    55. rpenno says yes (tbachman, 17:29:35)
    56. but if there are forks, then you can have multiple data plane locators (tbachman, 17:29:46)
    57. each service function forwarder has a dictionary, which is the list of all service functions it can reach (tbachman, 17:30:08)
    58. The data plane locators provide this dictionary (tbachman, 17:30:36)
    59. There is a fail mode — what a forwarder should do if it can’t reach a service function (bypass, drop) (tbachman, 17:31:51)
    60. There is also work for support for features like HA (tbachman, 17:32:11)
    61. The service function forwarder is very generic (tbachman, 17:32:20)
    62. and can apply to anything (vSwitch, router, etc.) (tbachman, 17:32:40)
    63. The service function forwarder should be augmented for specific use cases (e.g. OVS with OpenStack) (tbachman, 17:33:04)
    64. This is demonstrated in service-funciton-forwarder-ovs.yang (tbachman, 17:33:23)
    65. The service function path is the actual places that a packet will visit (tbachman, 17:34:33)
    66. as it traverses the overlay (tbachman, 17:34:42)
    67. There is a list of service function paths (tbachman, 17:34:49)
    68. A service function path is composed of service path hops (tbachman, 17:35:00)
    69. where each hop is collection of a service function forwarder and service function name (tbachman, 17:35:16)
    70. The hop counter is incremented on every service function forwarder (tbachman, 17:35:43)
    71. This is distinct from the service function index, which is incremented on each service function (tbachman, 17:36:09)
    72. The hop counter is there to deal with scenarios where you have forwarders with out functions (tbachman, 17:36:24)
    73. most users won’t have to deal with it (tbachman, 17:36:36)
    74. The starting index is important for systems that don’t want to compute the starting index (tbachman, 17:37:33)
    75. there’s also a path ID (tbachman, 17:37:38)
    76. In order to create a path, in the simplest case, you need to give it a name and the name of the chain that it should be instantiated (tbachman, 17:39:09)
    77. mickey_spiegel asks if you’re creating service function instances for each hop on the chain (tbachman, 17:39:48)
    78. rpenno says you need to create the catalog of service functions ahead of time (tbachman, 17:40:04)
    79. mickey_spiegel asks if you allocate individual service functions for each hop along the path (tbachman, 17:40:22)
    80. rpenno says yes — it will select the most suitable one for that path (tbachman, 17:40:40)
    81. where suitable could be as simple as picking the first one that it finds (tbachman, 17:41:01)
    82. rpenno says there is a language for describing this (tbachman, 17:41:14)
    83. but it hasn’t been committed upstream yet (tbachman, 17:41:27)
    84. It’s a metadata model for service function characteristics (tbachman, 17:41:41)
    85. You want the path to be constructed with certain constraints. Today the constraints are based on use cases (tbachman, 17:42:02)
    86. For example, geographic location, or more sophisticated things like number of connections on a Firewall (tbachman, 17:42:20)
    87. The model will be a container-based yang model with a list (tbachman, 17:42:36)
    88. so that the list can be updated when needed (tbachman, 17:42:45)
    89. mickey_spiegel asks whether you can reuse a service function that’s already been allocated (tbachman, 17:45:52)
    90. rpenno says you can (tbachman, 17:45:56)
    91. rpenno says there’s no tenancy here, and that would have to be an augmentation for the service model (tbachman, 17:47:03)
    92. and tenancy could be used as a constraint, if desired (tbachman, 17:47:21)
    93. when a service function path is created, it goes to the service function and checks the operational state (tbachman, 17:48:39)
    94. and checks to see if the service function is in use by this path (tbachman, 17:49:03)
    95. so, you could put the name of the tenant in the operational state (tbachman, 17:49:14)
    96. new service types can be added by creating new identities in the yang model (tbachman, 17:51:14)
    97. The data plane locators for service function and service function forwarder have a structure that’s imported from another SFC model (tbachman, 17:51:36)
    98. This is done so that you can enhance it as much as you want without touching the service function and service function forwarder (tbachman, 17:51:53)
    99. rpenno prefers to use groups and uses over leafrefs (tbachman, 17:54:47)
    100. b/c the java code that’s generated from leafrefs has additional considerations that he prefers to avoid (tbachman, 17:55:10)
    101. sanjay asks if there are authorization domains — like who can see what? (tbachman, 17:56:41)
    102. rpenno says that there are, but that will be post-helium (tbachman, 17:56:51)
    103. There’s still a question as to whether SFC or GBP renders that front-end classifier (tbachman, 18:00:02)


Meeting ended at 18:05:19 UTC (full logs).

Action items

  1. (none)


People present (lines said)

  1. tbachman (111)
  2. odl_meetbot (3)
  3. alagalah_ (1)
  4. uchau1 (1)


Generated by MeetBot 0.1.4.