#opendaylight-sfc: sfc_weekly

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

Meeting summary

  1. agenda (tbachman, 17:00:13)
    1. https://meetings.opendaylight.org/opendaylight-sfc/2015/sfc_weekly/opendaylight-sfc-sfc_weekly.2015-02-05-17.00.html Last week’s meeting minutes (tbachman, 17:00:23)
    2. https://lists.opendaylight.org/pipermail/sfc-dev/2015-February/000907.html Agenda for today’s meeting (tbachman, 17:01:20)

  2. SFC/GBP integration (tbachman, 17:06:09)
    1. https://wiki.opendaylight.org/view/Service_Function_Chaining:Group_Based_Policy_Integration wiki page describing the integration (tbachman, 17:08:48)
    2. ebrjohn says the EPGs determine which traffic gets sent into the chain (tbachman, 17:09:07)
    3. SFC is responsible for getting the packets through the chain and to the termination point (tbachman, 17:09:27)
    4. alagalah says it would help to frame the conversation around scope (tbachman, 17:10:43)
    5. alagalah asks ebrjohn if it’s okay to delineate scope (tbachman, 17:11:14)
    6. ebrjohn says its good to make clear that it’s a POC (tbachman, 17:11:31)
    7. paulq agrees with addressing scope (tbachman, 17:12:01)
    8. alagalah says someone else provisions the service chain (tbachman, 17:12:37)
    9. alagalah says there are two EPGs, with instances on two different servers, can talk over VxLAN tunnel (tbachman, 17:12:59)
    10. alagalah says one of the things between the two EPGs is the contract with an action called CHAIN, with an action referenced by name (tbachman, 17:13:19)
    11. alagalah says there’s an outer list and an inner list — the inner list says how to get in and how to come out (tbachman, 17:13:40)
    12. in the reverse direction is also needed — the entry and exit point (tbachman, 17:13:55)
    13. GBP has to then encap in NSH and get it there — black boxing SFC (tbachman, 17:14:10)
    14. paulq says that sounds fine (tbachman, 17:14:23)
    15. abhijitkumbhare asks for the prototype — will it be possible to extend it to other transport types such as MPLS (tbachman, 17:14:59)
    16. alagalah says it’s a bit out of scope of a POC goal, as it’s specific on GBP — maybe address this in the GBP meeting (tbachman, 17:16:18)
    17. ebrjohn says the communication between GBP and SFC is NSH — does it always have to be NSH (tbachman, 17:16:44)
    18. alagalah says this is just to get this to the head of the SFC chain — how we get it from the beginning or end of the service chain to the beginning or ending endpoint is a GBP specific thing, and maybe best to address it in that team meeting (tbachman, 17:17:43)
    19. paulq says we’re assuming that GBP is receiving the requisite information to start the chain — be it NSH, et. al. (tbachman, 17:18:12)
    20. ebrjohn says it needs to be flexible enough to use SFC with other technologies than NSH (tbachman, 17:19:06)
    21. paulq emphasizes that SFC will return the requisite information for the appropriate encap (tbachman, 17:19:32)
    22. mikey_spiegel says that the requirement of transport of SFC vs. transport of what GBP normally does, and as long as they’re different, it’s okay (tbachman, 17:20:07)
    23. paulq doesn’t agreee with that statement (tbachman, 17:20:14)
    24. alagalah says he kind of agrees with it, but has a question on that (tbachman, 17:20:26)
    25. alagalah says with NSH there’s no chance of openflow “glare” with GBP (tbachman, 17:20:50)
    26. paulq says he may have misunderstood mickey_spiegel’s comment (tbachman, 17:21:17)
    27. mickey_spiegel says it’s only the multiple writers that he’s addressing (tbachman, 17:22:17)
    28. paulq agrees (tbachman, 17:22:21)
    29. alagalah recommends a phased approach for long term (tbachman, 17:23:31)
    30. ebrjohn agrees — what would be the next step (tbachman, 17:24:20)
    31. https://trello.com/b/yc0xHFlv/opendaylight-groupbasedpolicy-lithium Group Based Policy Trello board with cards for SFC (tbachman, 17:25:12)
    32. vina_ermagan asks when you say terminating EPG, is that the final SFF, or the where the final endpoint is located (tbachman, 17:26:06)
    33. ebrjohn says it’s after the SFF (tbachman, 17:26:13)
    34. vina_ermagan says that information has to be conveyed to SFC so that it knows where to send it (tbachman, 17:26:24)
    35. GBP would ask for the chain and at the last hop, send it to this location (tbachman, 17:26:37)
    36. ebrjohn says the difference between SFC as it is now vs. sending it to the terminating EPG — is there any difference for SFC? (tbachman, 17:27:38)
    37. paulq says there shouldn’t be — as long as we can impose the classification (tbachman, 17:27:48)
    38. https://docs.google.com/document/d/1ZnLHuSiyOmVFR0pW65K4enB7QcYbLL18yzxYgmK_iDo/edit (alagalah, 17:27:59)
    39. mickey_spiegel says there’s the issue of creating the tunnel from the SFF (tbachman, 17:28:02)
    40. https://docs.google.com/document/d/1ZnLHuSiyOmVFR0pW65K4enB7QcYbLL18yzxYgmK_iDo/edit SFC+GBP phased design brainstorming (alagalah, 17:28:13)
    41. mickey_spiegel says there’s an action at the end of the chain that’s GBP-ish for the tunnel (tbachman, 17:28:41)
    42. vina_ermagan says that the way the POC is being designed, it’s kind of boxing out SFC — control of everything, including the last SFF (tbachman, 17:29:22)
    43. vina_ermagan says if we assume that they don’t have control over the SFFs, then the last SFF has to do the encap — maybe without NSH header — to the final EPG (tbachman, 17:29:55)
    44. vina_ermagan says both SFC and GBP both have the ability to do the encap (tbachman, 17:30:35)
    45. paulq says post service chain — the packet comes out w/o NSH (tbachman, 17:30:36)
    46. normal routing/forwarding has to handle that (tbachman, 17:30:43)
    47. in the case of GBP, the overlay has to handle that (tbachman, 17:30:52)
    48. in the case of non-GBP, it would just be handled by normal routing (tbachman, 17:31:01)
    49. mickey_spiegel asks who puts the overlay there at the last SFF — GBP or SFC (tbachman, 17:31:16)
    50. paulq says that after the service chain, SFC is done (tbachman, 17:31:23)
    51. alagalah says that’s his understanding as well - and vice versa — inside the service chain GBP doesn’t care (tbachman, 17:31:39)
    52. vina_ermagan says that there’s an overlap there tho (tbachman, 17:31:47)
    53. paulq says not really — the SFC rules are written on NSH; post-decap, it’s just an IP packet (tbachman, 17:32:12)
    54. alagalah would request SFC #1, gets back ‘you will send packets to start chain on OVS-1, port 1, NSH header A’ (tbachman, 17:34:11)
    55. alagalah says at the end, coming out of the tunnel openflow switch 2 port 2 — also getting this from SFC (tbachman, 17:34:31)
    56. alagalah says we also get the reverse path (tbachman, 17:34:40)
    57. alagalah says we’d then need to key our flow, setting up the tunnel such that a packet is going to SFC#1, we need to get a VxLAN encaped packet with an NSH header (tbachman, 17:35:29)
    58. alagalah says coming out, we just have to take the packets from the tunnel and strip the headers (tbachman, 17:36:07)
    59. alagalah says SFC has now knowledge that GBP is using a VxLAN overlay (tbachman, 17:36:27)
    60. vina_ermagan says then GBP must have control over wherever the last SFF is to be able to get back the packet (tbachman, 17:37:17)
    61. alagalah says yes, the OVS would be shared (tbachman, 17:37:51)
    62. alagalah says that’s everything that’s SFC is matching on an NSH field (tbachman, 17:38:40)
    63. paulq says for the POC, let’s assume it’s NSH end to end, which allows us to avoid the multiple writers issue (tbachman, 17:40:03)
    64. vina_ermagan says that sounds good — the handoff is local from SFC to GBP on the vSwitch (tbachman, 17:40:22)
    65. mickey_spiegel says if we’re doing the local handoff on the vSwitch, then some details need to be worked out (tbachman, 17:40:43)
    66. alagalah agrees (tbachman, 17:40:46)
    67. alagalah says we’d have to address conflict resolution in order to do this, which would be tough to do in the given time frame (tbachman, 17:41:05)
    68. ebrjohn asks what the difference between alagalah’s google doc and the wiki page that repenno started (tbachman, 17:41:36)
    69. alagalah says this is just a brainstorming document — prefers gdoc with history, etc. (tbachman, 17:41:52)
    70. alagalah says the gdoc is also meant to address phases/goals beyond the POC (tbachman, 17:42:19)
    71. ebrjohn says he’d like to clarify a point in the email on the conflict resolution — we do need to make sure that GBP and SFC are each dealing with their parts of the network (tbachman, 17:43:20)
    72. paulq says yes — for POC, there’s a clear separation of who controls which switch (tbachman, 17:43:33)
    73. paulq says the only constraint is that the last SFF has to deliver an IP packet to GBP (tbachman, 17:43:49)
    74. ebrjohn asks if we should consider a “no encap” option (tbachman, 17:44:08)
    75. paulq says it does mean that the forwarding is “clean” on the intermediate switches (tbachman, 17:44:29)
    76. paulq says when you have a clear identifier in the packet then it’s easy to avoid any conflicts in the middle (tbachman, 17:44:55)
    77. ebrjohn asks if we want to address the different phases in alagalah’s document (tbachman, 17:45:22)
    78. alagalah says we should push the transparent case to a later phase (tbachman, 17:47:33)
    79. ebrjohn asks if there’s anything else we should mention for phase 0 (tbachman, 17:48:19)
    80. ebrjohn asks folks to review repenno’s document (tbachman, 17:49:18)
    81. tbachman is looking into providing an example patch on how SFC and GBP might integrate for the POC (tbachman, 17:52:13)
    82. ebrjohn asks if we should continue this in the GBP meeting (tbachman, 17:52:31)
    83. folks agree to continue in GBP (tbachman, 17:52:38)


Meeting ended at 17:54:37 UTC (full logs).

Action items

  1. (none)


People present (lines said)

  1. tbachman (97)
  2. odl_meetbot (5)
  3. alagalah (2)
  4. abhijitkumbhare (2)
  5. ebrjohn (1)


Generated by MeetBot 0.1.4.