#opendaylight-group-policy: gbp_arch

Meeting started by tbachman at 16:59:26 UTC (full logs).

Meeting summary

  1. audiophiles rule (tbachman, 17:01:55)
  2. agenda (tbachman, 17:04:37)
    1. https://cisco.webex.com/ciscosales/j.php?MTID=mdfede3d482ceede44a93acdcca9f0e2e (tbachman, 17:05:00)
    2. agenda items: 1) documentation; 2) service chaining (tbachman, 17:10:10)

  3. service chaining (tbachman, 17:11:33)
    1. paulq gives a high-level view of SFC project (tbachman, 17:11:57)
    2. a service chain is the intent, such as “give me firewall”, or “give me IPS" (tbachman, 17:12:50)
    3. that gets rendered into a service function path (tbachman, 17:13:01)
    4. where path is a specific device, and can be one or more paths to one intent (tbachman, 17:13:30)
    5. It can be mulitiple instances, or multiple instances of the same intent (tbachman, 17:13:45)
    6. there is a service function forwarder, which is “the switch" (tbachman, 17:14:06)
    7. and a service function, which connects to the service function forwarder (tbachman, 17:14:21)
    8. this is done to decouple the function from the forwarding (tbachman, 17:14:28)
    9. assigned by a basic mapping at the moment (tbachman, 17:14:37)
    10. The current model does not contain constraints (tbachman, 17:14:54)
    11. They create an overlay topology that links forwarders to each other (tbachman, 17:15:10)
    12. paths are identified by a path ID which is unique in a domain (tbachman, 17:15:41)
    13. Think of a path ID as a graph ID (tbachman, 17:16:02)
    14. where a path is a graph that is traversed for a given class of traffic (tbachman, 17:16:38)
    15. you can alter the path to alter the graph (tbachman, 17:16:45)
    16. the path is the service plane (tbachman, 17:17:16)
    17. dvorkinista asks if it includes the endpoints (tbachman, 17:17:21)
    18. paulq says it does not (tbachman, 17:17:27)
    19. it starts at a classification event, and ends at the end of the chain (tbachman, 17:17:38)
    20. where chain end is the last service function forwarder (tbachman, 17:17:48)
    21. The EP in GBP is the classification in SFC (tbachman, 17:18:41)
    22. classification defines which traffic enters which graph (tbachman, 17:18:56)
    23. this is indicated both in the model and on the wire (tbachman, 17:19:08)
    24. so at any point you can see where you are (tbachman, 17:19:23)
    25. dvorkinista says lets look at the expression of intent (tbachman, 17:19:33)
    26. there is a function, a type, a data plane locator (essentially a network address), an encap type — basic data plane stuff (tbachman, 17:20:12)
    27. a path is a colleciton of forwarder and functions (tbachman, 17:20:27)
    28. that is the rendering (tbachman, 17:20:36)
    29. the intent model is a series of types, agnostic of forwarders (tbachman, 17:20:47)
    30. paulq says that intent is list of service types (tbachman, 17:21:05)
    31. paulq says that they do not expect the user to say “I want FW 28”, but rather just “I want a FW" (tbachman, 17:21:38)
    32. and there is an implied order in the lists (tbachman, 17:21:52)
    33. dvorkinista asks if there is a terminal (tbachman, 17:22:01)
    34. paulq says that there isn’t currently (tbachman, 17:22:08)
    35. but that they’re working on that — specifying a classifier (tbachman, 17:22:20)
    36. dvorkinista asks if there’s anything else in the intent (tbachman, 17:22:38)
    37. paulq says no (tbachman, 17:22:41)
    38. dvorkinista asks if the types are mapped into functions 1-to-1 (tbachman, 17:23:10)
    39. paulq says there can be more than one function of a given type (tbachman, 17:23:20)
    40. (i.e. one-to-one mapping of service tuypes to functions) (tbachman, 17:24:09)
    41. There is also a mapping of forwarders to functions (tbachman, 17:24:20)
    42. lenrow is concerned about multiple entities controlling resources (tbachman, 17:25:27)
    43. lenrow says that the current propsal is that GBP is the sole resource to manage the ships-in-the-night problems with accessing resources such as flow tables (tbachman, 17:26:24)
    44. dvorkinista says that the idea for GBP is to specify the high-level intent, such as SFC (tbachman, 17:26:45)
    45. paulq says there are a lot of constraints that can be resolved locally (tbachman, 17:26:57)
    46. as an example, a constraint such as “least loaded FW” (tbachman, 17:27:12)
    47. SFC is not going to track djikstra’s algorithm, etc. (tbachman, 17:27:30)
    48. hemanth asks if paths are bi-directional (tbachman, 17:27:48)
    49. paulq says that paths are uni-directional (tbachman, 17:27:54)
    50. dvorkinista asks if intent is uni-directional (tbachman, 17:28:02)
    51. paulq says intent is uni-directional (tbachman, 17:28:08)
    52. paulq says they could optimize — it’s come up, but they haven’t optimized currently (tbachman, 17:28:22)
    53. dvorkinista says you could create a graph, and the way to interact with the graph is strictly bi-directional (tbachman, 17:28:41)
    54. the way the boundaries of the chain are defined are bi-directional (tbachman, 17:29:03)
    55. (tbachman, 17:29:19)
    56. So that they way you connect to the chain is bi-directional (tbachman, 17:29:22)
    57. but within the chain, it can use uni-directional constructs (tbachman, 17:29:35)
    58. paulq says that their current use of uni-directional intent is a question of whether they keep state to know that path forward is the same as path back (tbachman, 17:31:32)
    59. hemanthravi asks if the user has the ability to ask whether the forward and reverse path are related (tbachman, 17:32:58)
    60. dlenrow points out it would be great if this could be encapsulated in the virtual function container, so that the details don’t become part of the intent, and are part of the rendering (tbachman, 17:34:03)
    61. dvorkinista says one way to think of it is that those things come from an operational policy (tbachman, 17:34:36)
    62. and this way you don’t over-burden the intent (tbachman, 17:35:00)
    63. paulq notes that the whole point of SFC is to abstract out the plumbing (tbachman, 17:35:41)
    64. paulq says that they add a data plane header/shim to build these topologies without having to change the plumbing (tbachman, 17:36:09)
    65. and that metadata is carried on the wire, e.g. an ID for group 1 and group 2 (tbachman, 17:36:27)
    66. dvorkinista asks if their using Network Service Headers (NSH) (tbachman, 17:36:45)
    67. paulq says yes, they’re doing this in NSH (tbachman, 17:36:54)
    68. dvorkinista asks if they’re looking at geneve? (tbachman, 17:37:02)
    69. paulq says that their current plan is NSH (tbachman, 17:37:09)
    70. paulq says that they’ve already done the first updates of NSH in OVS (tbachman, 17:37:41)
    71. they try to keep the metadata and transport separate (tbachman, 17:37:50)
    72. paulq says that they also allow services (not yet today in ODL), which allows services to inform other services of what they know. (tbachman, 17:38:11)
    73. where this context is put on the wire (tbachman, 17:38:24)
    74. which allows for things like dynamic alteration of the graph (tbachman, 17:38:46)
    75. dvorkinista asks if this looks more like a tree when looked at uni-directionally (tbachman, 17:41:09)
    76. paulq says no, b/c they can be cyclical (tbachman, 17:41:17)
    77. e.g. FW => LB => FW (tbachman, 17:41:25)
    78. mickey_spiegel asks how they capture intent when it’s not just a chain (tbachman, 17:41:43)
    79. paulq says it’s a series of sub-graphs (chains that overlap) (tbachman, 17:41:52)
    80. dvorkinista asks if you have a cycle, and you go back to the perimiter FW, will it be the same graph or different graph (tbachman, 17:42:17)
    81. paulq says the same graph (tbachman, 17:42:21)
    82. the metadata in the dataplane allows you to break the cycles (tbachman, 17:42:39)
    83. paulq says to hop between graphs, there’s a classification event (tbachman, 17:43:07)
    84. paulq says as long as you don’t alter the path ID, you’re in the same graph (tbachman, 17:43:32)
    85. sanjay says services may be connected in a graph, but as far as a single flow is concerned, they will only utilize this in a chain fashion (i.e. everything is a chain) (tbachman, 17:44:12)
    86. paulq re-emphasizes that everything is a path (tbachman, 17:44:23)
    87. where forking would be two different paths (tbachman, 17:44:51)
    88. mickey_spiegel asks why path is being used instead of chain (tbachman, 17:45:29)
    89. paulq says chain is the abstraction (e.g. FW => LB => DPI), and path is the concrete realization of that (e.g. FW #21 => LB #13 => DPI #4) (tbachman, 17:46:08)
    90. paulq says the reason they talk about the service plane is to provide a level of abstraction (tbachman, 17:51:03)
    91. which is why they are transport-independent (tbachman, 17:51:12)
    92. mickey_spiegel asks if there’s any notion of terminal or interface (tbachman, 17:51:51)
    93. paulq says they purposelly don’t have that — just classification, as they don’t want to become the classification project/platform (tbachman, 17:52:17)
    94. mickey_spiegel says the problem is that having the abstraction draws the line as to who has the ability to decide paths (tbachman, 17:53:21)
    95. mickey_spiegel asks whether classification can indirectly reference decisions functions make without directly referencing them (tbachman, 17:58:20)
    96. mickey_spiegel asks what we want to do about intent for a graph vs. a chain (tbachman, 17:59:47)
    97. mickey_spiegel asks if paulq can provide a reference for their intent model (tbachman, 18:00:55)
    98. dlenrow said we can tack this on to the Monday use case/requirements meeting agenda (tbachman, 18:01:09)
    99. dvorkinista notes that he’ll be out starting next Thursday for a week (8/7-8/15) (tbachman, 18:01:37)
    100. mickey_spiegel asks if folks will be able to look at the model in time for monday’s meeting (tbachman, 18:02:04)
    101. paulq says that it’s covered in the yang files in the git repo (tbachman, 18:02:30)
    102. sanjay asks if you’d consider multiple VIPs for each service funciton, or can we limit a single VIP per service function (tbachman, 18:03:30)
    103. sanjay asks if you’d consider multiple VIPs for each service funciton, or can we limit a single VIP per service function (tbachman, 18:03:42)
    104. https://datatracker.ietf.org/doc/draft-penno-sfc-yang/ (paulq, 18:03:48)
    105. https://git.opendaylight.org/gerrit/gitweb?p=sfc.git;a=tree;f=model/src/main/yang;h=abe368fdf09fc912b00625a76bddba9a03229f62;hb=218ea63128db2a9d2d1d8e10693a0ebcbe090860 link to yang models in git for SFC project (tbachman, 18:06:16)
    106. mickey_spiegel says he won’t be here on Friday next week (tbachman, 18:07:22)

  4. documentation (tbachman, 18:08:03)
  5. readams demo of OpenFlow Overlay renderer (tbachman, 18:09:34)
    1. readams says the current state is that a lot is working, but a few key pieces not there yet, which require additional changes to the OpenFlow plugin in ODL (tbachman, 18:10:12)
    2. readams is using a mininet environment, with some scripts to set up some policy (tbachman, 18:11:00)
    3. there’s a simple contract that allows web traffic and ICMP traffic, and two EPGs (tbachman, 18:11:20)
    4. readams demonstrates the flows written into the flow table (tbachman, 18:11:54)
    5. the policy model is rendered into an equivalent policy model, handling inheritance, etc. (tbachman, 18:12:17)
    6. The equivalent policy model is then used to create the flow entries in the switches (tbachman, 18:12:47)
    7. There are conventions used for the flow table: table 0 is used for port security (tbachman, 18:13:11)
    8. table 1 is used for the source EPG and source condition assignment (tbachman, 18:13:25)
    9. table 2 is used for destination EPG and destination condition assignment (tbachman, 18:14:39)
    10. last table is policy table (tbachman, 18:14:46)
    11. readams needs some extensions in the OF plugin in order to complete the implementation (tbachman, 18:16:36)
    12. everything up until the final packet delivery should work, until we get the extension (tbachman, 18:17:27)
    13. sanjay asks if we can check this out and run it ourselves (tbachman, 18:18:41)
    14. readams says that not currenlty, as it requires checking out several projects and building uncommitted patches (tbachman, 18:19:03)
    15. sanjay asks if readams can post the rest commands (tbachman, 18:19:36)

  6. documentation (tbachman, 18:22:04)
    1. mickey_spiegel talks about the different doc requirements (tbachman, 18:23:38)
    2. installation is pretty straightforward (tbachman, 18:23:45)
    3. they want pre-installation, post-installation, etc. (tbachman, 18:23:55)
    4. mickey_spiegel didn’t see specific dates for documentation in the release plan (tbachman, 18:24:16)
    5. mickey_spiegel says that with that in mind, installation requires a little more content, but not a lot (tbachman, 18:24:48)
    6. confusion on the developer guide, etc. (tbachman, 18:25:19)
    7. mickey_spiegel asked mlemay differences between developer and user guids (tbachman, 18:25:55)
    8. https://wiki.opendaylight.org/view/Group_Policy:Sub-Groups:ARCH#Team_Meeting <= link dscribing various documentation requirements (tbachman, 18:27:04)
    9. readams recommends just using what he’s provided on the wiki for the devloper guide (tbachman, 18:28:08)
    10. mickey_spiegel says the operations guide is optional (tbachman, 18:28:44)
    11. mickey_spiegel says that the user guide is required, but there’s confusion as to what exactly a user guide is (tbachman, 18:29:41)
    12. https://wiki.opendaylight.org/view/Sample_User_Guide <= link in ODL wiki for sample user guide (tbachman, 18:33:24)
    13. readams says that the UML probably isn’t going to be as helpful to users, as it requires a lot of explanation (tbachman, 18:34:35)
    14. readams says that a pseudo-cli type thing might be more helpful than the yang or JSON (tbachman, 18:35:14)
    15. mickey_spiegel says this needs to be converted to ASCII doc format (tbachman, 18:40:35)
    16. at which point the wiki becomes deprecated (tbachman, 18:40:45)
    17. mickey_spiegel asked mlemay whether the wiki and ASCII doc could be kept in sync, but mlemay said that the wiki was meant to be internal only (tbachman, 18:41:56)
    18. https://wiki.opendaylight.org/view/Sample_Developer_Guide <= link in ODL wiki for sample developer guide (tbachman, 18:52:27)
    19. https://wiki.opendaylight.org/view/CrossProject:Documentation_Group:Helium_Developer_Guide <= helium developers guide (tbachman, 18:55:10)
    20. https://wiki.opendaylight.org/view/CrossProject:Documentation_Group:Helium_User_Guide =< helium users guide (tbachman, 18:55:30)
    21. https://wiki.opendaylight.org/view/CrossProject:Documentation_Group:Helium_Installation <= helium installation guide (tbachman, 18:55:57)
    22. mickey_spiegel suggests that we focus on generating content on the wiki, and then convert it (tbachman, 18:57:51)
    23. given that dvorkinista and mickey_spiegel will both be out next Friday, the arch group will not meet next Friday (8/8) (tbachman, 18:59:32)


Meeting ended at 19:00:43 UTC (full logs).

Action items

  1. (none)


People present (lines said)

  1. tbachman (176)
  2. paulq (7)
  3. odl_meetbot (6)
  4. dlenrow (1)
  5. hemanthravi (1)


Generated by MeetBot 0.1.4.