#opendaylight-group-policy: GBP-150206

Meeting started by alagalah at 17:58:26 UTC (full logs).

Meeting summary

  1. agenda (tbachman, 17:59:13)
    1. https://wiki.opendaylight.org/view/Group_Policy:Sub-Groups:STATUS#Team_Meeting Agenda for today’s meeting (tbachman, 17:59:33)
    2. https://meetings.opendaylight.org/opendaylight-group-policy/2015/gbp_arch_status/opendaylight-group-policy-gbp_arch_status.2015-01-30-18.00.html last week’s meeting minutes (tbachman, 18:00:24)

  2. SFC GBP Integration (tbachman, 18:01:53)
    1. https://lists.opendaylight.org/pipermail/groupbasedpolicy-dev/2015-January/000682.html email describing multiple renderer solution (tbachman, 18:02:22)
    2. alagalah says both GBP and SFC would like a POC for the Lithium release (tbachman, 18:07:27)
    3. https://wiki.opendaylight.org/view/Service_Function_Chaining:Group_Based_Policy_Integration Wiki page describing a possible POC (tbachman, 18:07:50)
    4. alagalah says that today is the second half of the meeting that started in yesterday’s SFC weekly meeting (tbachman, 18:08:18)
    5. https://docs.google.com/drawings/d/1NOMUB0pcL5Ordlulb85B5krKa8w_Ce5rGYi2jywd-WQ/edit (edwarnicke, 18:09:42)
    6. paulq says the core thing is the question as to what granularity you ask for (i.e. by chain name? type?) (tbachman, 18:10:08)
    7. paulq says the classifier is pretty straightforward (tbachman, 18:10:19)
    8. edwarnicke says he thinks of it as to who’s responsible for what, and how do we prevent conflicts (tbachman, 18:10:40)
    9. paulq says if the classifier and SFF are separate, then the classifier rules are GBP rules (tbachman, 18:10:53)
    10. paulq says in the chain, flow rules are looked up by NSH (tbachman, 18:11:06)
    11. mickey_spiegel asks what happens at the end of the chain, and GBP is putting openflow rules at the end (tbachman, 18:11:39)
    12. paulq says we know in principle the last SFF; one thought (to GBP project) is if SFC tells GBP the last SFF, can GBP install a rule for this? (tbachman, 18:12:04)
    13. alagalah says more than likely this would be the reverse of the entry (tbachman, 18:12:36)
    14. paulq thinks this mickey_spiegel asked a different question (tbachman, 18:12:45)
    15. when NSH is thrown in the garbage, how do you forward it to the ultimate destination? (tbachman, 18:12:59)
    16. alagalah says his thinking is that it would be the same as the ofoverlay renderer acts on the same destination today (tbachman, 18:13:26)
    17. edwarnicke says the end of the chain can happen for all kinds of reasons — in which case things like normal L3 routing gets the packets there (tbachman, 18:13:52)
    18. alagalah says this could be problematic (tbachman, 18:14:13)
    19. paulq says that you don’t know which SFF the packet pops out on, should SFC tell GBP which SFF it is? (tbachman, 18:14:59)
    20. alagalah says yes, GBP will need that inforamtion (tbachman, 18:15:06)
    21. alagalah asks if the reverse path would also be the egress (tbachman, 18:15:19)
    22. paulq says that’s not guaranteed (tbachman, 18:15:27)
    23. paulq says there’s been a back and forth on what this integration looks like in the mailing lists (tbachman, 18:16:45)
    24. paulq says the use case for the POC is two EPGs and a contract; the contract expreses a chain, and the GBP will ask for that chain from SFC (tbachman, 18:17:09)
    25. SFC provides a set of IDs for the chain; as part of the EPG flow programming, GBP places the packet in a tunnel, tagged with appropriate identifiers and encap (tbachman, 18:17:59)
    26. alagalah asks if this will be a flow header rewrite? (tbachman, 18:18:08)
    27. paulq says the way this works is you attach it to a tunnel; the output would be a vxlan with NSH header (tbachman, 18:18:26)
    28. paulq says ideally the tunnel CRUD would come from OVSDB; in short term, we can stand it up other ways (tbachman, 18:19:01)
    29. edwarnicke says we have an overlay API coming into the MD-SAL, so you can ask for a tunnel between two places (tbachman, 18:19:22)
    30. edwarnicke says the overlay API is constructed using the per-side issue (tbachman, 18:19:37)
    31. edwarnicke says that the classification would be handled by GBP; GBP requests the tunnel to the first SFF; GBP adds classifier to direct traffic onto this tunnel (tbachman, 18:20:32)
    32. edwarnicke says that SFC knows where SFFs are doesn’t have to understand GBP knowledge of where EPs live (tbachman, 18:20:58)
    33. Uri asks if the policy that establishes the contract between two EPGs enforces policy on the chain (tbachman, 18:21:32)
    34. alagalah says we’re just discussing the POC, not to cover the end-all use cases (tbachman, 18:23:30)
    35. Uri asks if the scope is just connecting GBP and SFC (tbachman, 18:24:00)
    36. alagalah says yes (tbachman, 18:24:02)
    37. There is a question as to whether GBP and SFC would both be attempting to write the flow tables (tbachman, 18:25:20)
    38. alagalah says that SFC matches on an NSH header, so they’d be completely separate flows (tbachman, 18:25:35)
    39. abhijitkumbhare asks for clarification on this; the classifier is likely to be the first switch at the edge, and adds the vxlan and NSH headers (tbachman, 18:26:13)
    40. abhijitkumbhare asks if that will be programmed by GBP (tbachman, 18:26:21)
    41. paulq says the openflow rules instantiated by GBP will direct the appropriate EPG members to the tunnel that does this encap (tbachman, 18:26:48)
    42. paulq says this means that GBP uses the existing rules to direct it to the tunnel (tbachman, 18:27:08)
    43. paulq says SFC will provide the dataplane locator for the SFF (first hop in the chain) (tbachman, 18:28:06)
    44. sanjay asks if you’re using LISP in this example (tbachman, 18:28:20)
    45. paulq says there’s nothing that precludes this (tbachman, 18:28:31)
    46. paulq says this fits a model that makes sense — GBP asks essentially for a service chain, which is a form of graph; separates concerns (tbachman, 18:29:22)
    47. This allows SFC flexibility of the complexity of its graphs (tbachman, 18:29:36)
    48. Sanjay asks in the last SFF, all the SFC headers, etc. will be terminated. Will the last SFF forward the traffic back to the original switch that started the chain, or will the traffic be forwarded from the last SFF to go to the destination (tbachman, 18:30:16)
    49. alagalah says there is a contract that matches for traffic from A-B, we request stuff from SFC: head of the chain (node locator, encap, etc.); GBP adds flow to direct it there, and also gives us the last SFF; the return path may be a separte SFC, which gets handled the same way (tbachman, 18:31:37)
    50. Sanjay asks if the end of the chain returns the packet back to the switch that started the chain (tbachman, 18:32:09)
    51. paulq says he considers that a special case, so not necesarrily (tbachman, 18:32:22)
    52. mickey_spiegel points out that at the termination side of the chain, within the datapath, you have to get it from some lookups that SFC is handling to some lookup that GBP is handling, within that switch (tbachman, 18:33:09)
    53. mickey_spiegel is noting that the forwarding pieces need to be put together at the termination, so some coordination is needed there (tbachman, 18:33:59)
    54. alagalah says we’ll need a list of topologies we’ve tested (tbachman, 18:34:11)
    55. abhijitkumbhare asks if GBP is responsible for flow programming while tunnel programming is handled by SFC (tbachman, 18:34:27)
    56. alagalah says we’re treating this like a black box (tbachman, 18:34:33)
    57. paulq says that this conversation is the way we work through the issues in this POC (tbachman, 18:35:25)
    58. alagalah says we still need to keep in mind the goal of providing a POC in Lithium (tbachman, 18:36:03)
    59. alagalah asks if this POC is goood enough for Uri’s needs (tbachman, 18:36:26)
    60. paulq says we can show a demo with the OVS switch provisioned with the SFC script/demo (tbachman, 18:38:37)
    61. Sanjay asks if the new tunnel provisioning service is used to create the tunnels between the SFFs (tbachman, 18:38:57)
    62. alagalah says we’re not using ODL yet; would have to be done manually (tbachman, 18:39:08)
    63. alagalah says there are plans to make the OVSDB CRUD for creating tunnels available (tbachman, 18:39:22)
    64. Sanjay asks if that means we’re using tunnels between SFFs (tbachman, 18:39:53)
    65. alagalah says they key is being used to target the tunnels in GBP (tbachman, 18:40:11)
    66. paulq says they use wildcard tunnels and key into them (tbachman, 18:40:22)
    67. paulq says they use REST to provision tunnels until the OVSDB mechanism is available (tbachman, 18:40:34)
    68. rpenno says the service function agent is used to create these tunnels (tbachman, 18:40:47)
    69. edwarnicke asks if Sanjay has been following the tunnel API discussion (tbachman, 18:41:05)
    70. Sanjay he has, but needs to read up on it a bit more (tbachman, 18:41:13)
    71. paulq says the real key here is for everyone to look at the wiki, get agreement, and start development (tbachman, 18:41:51)
    72. alagalah says he’s got a card for SFC integration — should we use that to manage this task? (tbachman, 18:42:18)
    73. rpenno says they just use a list of action items (tbachman, 18:42:52)
    74. alagalah recomends a gdoc checklist (tbachman, 18:42:59)
    75. ACTION: alagalah to create a google doc to track this; link to wiki pages in both projects (tbachman, 18:43:13)
    76. alagalah asks who he should work with on this effort (tbachman, 18:43:45)
    77. rpenno says it will be him (tbachman, 18:43:50)
    78. mickey_spiegel says we’ve talked about fitting the pieces together; we haven’t talked about the model itself (tbachman, 18:44:20)
    79. mickey_spiegel asks if the proposal is to direct to a service function name, or something else? (tbachman, 18:44:35)
    80. alagalah says the idea is to put service function names into a list, which GBP will ask for (tbachman, 18:44:53)
    81. The list will be referenced by name (tbachman, 18:45:06)
    82. mickey_spiegel says he doesn’t understand the notion of a path and the granularity of the path (tbachman, 18:45:21)
    83. alagalah says that’s a good question, which needs to be resolved (tbachman, 18:46:04)
    84. alagalah we could have an ID for each instance of EPG (tbachman, 18:46:13)
    85. paulq says that for the POC, he would tend to think that SFC handles the graph abstraction and returns a path per request (tbachman, 18:46:37)
    86. LouisF asks for symmetric chains, do you need 2 paths for that; and how would your organize the classifiers for the forward and reverse directions (tbachman, 18:48:35)
    87. rpenno sasy you need 2 paths (tbachman, 18:48:44)
    88. mickey_spiegel asks if you want chain ABC, and in reverse CBA, are there 2 chains or 1? (tbachman, 18:51:56)
    89. Sanjay sasy these are different chains (tbachman, 18:52:10)
    90. rpenno sasy these are two different paths (tbachman, 18:52:17)
    91. forward direction and reverse direction# (tbachman, 18:52:26)
    92. mickey_spiegel asks if GBP is referencing two different chains (tbachman, 18:53:10)
    93. mickey_spiegel says that from a model perspective, GBP allows you to set a direction or say that it’s bidirectional (tbachman, 18:54:22)
    94. alagalah says the notion of the contract will still be applied in the direction (tbachman, 18:54:41)
    95. mickey_spiegel asks if the contract says bidirectional, and SFC supports this mapping, then we could use that (tbachman, 18:54:56)
    96. alagalah says GBP would look at this as two unidirectional things (tbachman, 18:55:38)
    97. Sanjay asks what’s implemented today in SFC? Unidirectional chains? (tbachman, 18:56:53)
    98. rpenno says today the API supports both: symmetric (bidirectional) paths (tbachman, 18:57:07)
    99. at the time of creation, they create two paths (tbachman, 18:57:13)
    100. they create the two paths in one shot, b/c if you want symmetry, you want the same SFFs to be traversed, just in reverse order (tbachman, 18:57:34)
    101. rpenno says you can also ask for two separate paths (tbachman, 18:57:44)
    102. rpenno says it’s up to the caller to decide what they want (tbachman, 18:57:55)
    103. Sanjay says with chain SFF1-SFF2-SFF3, in the in direction (A-B), you’ll go SFF1-SFF2-SFF3; in reverse, do you go SFF1-SFF2-SFF3, of SFF3-SFF2-SFF1? (tbachman, 18:58:34)
    104. rpenno says it’s SFF3-SFF2-SFF1 (tbachman, 18:58:41)
    105. paulq points out that the word symmetric is best here (tbachman, 18:58:54)


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

Action items

  1. alagalah to create a google doc to track this; link to wiki pages in both projects


Action items, by person

  1. alagalah
    1. alagalah to create a google doc to track this; link to wiki pages in both projects


People present (lines said)

  1. tbachman (122)
  2. abhijitkumbhare (7)
  3. odl_meetbot (5)
  4. yapeng (3)
  5. s3wong (3)
  6. alagalah (2)
  7. LouisF (1)
  8. edwarnicke (1)


Generated by MeetBot 0.1.4.