#opendaylight-group-policy: Renderer

Meeting started by alagalah at 16:09:09 UTC (full logs).

Meeting summary

  1. renderer_common (regXboi, 16:14:28)
    1. https://wiki.opendaylight.org/view/Group_Policy:Architecture/Renderer_Common (regXboi, 16:14:45)
    2. lenrow asks what is tenant (regXboi, 16:15:00)
    3. readams answers that it is the top level container for policies (regXboi, 16:15:22)
    4. plan is to build two renderers: OpenFlow and OpFlex (tbachman, 16:15:30)
    5. WIll use OVS-based overlay (tbachman, 16:15:40)
    6. lenrow points out that this is an overloaded term across ODL and so it might change (regXboi, 16:15:45)
    7. https://wiki.opendaylight.org/view/Group_Policy:Architecture/OVS_Overlay Description of overlay network (tbachman, 16:16:55)
    8. Overlay needs MTU that can support 1500 byte packets (e.g. 1600 MTU, to account for tunnel encap overhead) (tbachman, 16:17:48)
    9. regXboi notes that this is a real issue (tbachman, 16:17:55)
    10. The overlay model is simple, in order to be able to demonstrate use of GBP (tbachman, 16:19:11)
    11. lenrow asks if this design has an OpFlex connection to one OVS instance and OpenFlow connection to the other OVS instanct (tbachman, 16:20:18)
    12. This currently isn’t planned — will be either or, but not both (tbachman, 16:20:34)
    13. The Overlay example has two subnets (tbachman, 16:21:06)
    14. it’s important to have a logically “out of band" control channel (tbachman, 16:21:50)
    15. The example uses VxLAN encap (tbachman, 16:22:04)
    16. VxLAN encap has network identifier (tbachman, 16:22:49)
    17. would allocate a universal gateway map, which would be owned by distributed router (tbachman, 16:23:25)
    18. simple lookup to see if L2 is targeting GW (tbachman, 16:23:37)
    19. For bridging, deliver to destination (tbachman, 16:23:52)
    20. For routing, if destination is on a remote vSwitch, it’s 2 hops: one on-local vSwitch, another on the destination vSwitch, which performs correct IP address to MAC mapping (tbachman, 16:24:39)
    21. Determination of Next Hop destination for any given EP is renderer-specific (tbachman, 16:25:22)
    22. for OpFlex, will likely be reactive, since agent is on the switch (tbachman, 16:25:35)
    23. for OpenFlow, will likely be a hybrid (tbachman, 16:25:46)
    24. Question on reactive in OpFlex: driven by the controller or agent? (tbachman, 16:26:09)
    25. For learning, this will be a packet-in (tbachman, 16:26:19)
    26. controller then pushes this information where needed (tbachman, 16:26:48)
    27. dvorkinista notes that this is a proof-of-concept (tbachman, 16:28:06)
    28. regXboi notes that this is rebuilding OpenDove (tbachman, 16:29:20)
    29. dvorkinista asks if we can leverage OpenDove (tbachman, 16:29:37)
    30. Since this is a proof-of-concept for GBP, this might make sense (tbachman, 16:30:14)
    31. regXboi says there are some slight differences, but with so it might be good to leverage pieces (tbachman, 16:30:42)
    32. lenrow notes that OpenDove is currently competing with GBP, so bringing rending code into GBP would be great (tbachman, 16:31:11)
    33. dave_tucker notes that OVSDB also has netvirt (tbachman, 16:31:49)
    34. lenrow adds VTN to that (tbachman, 16:31:55)
    35. regXboi says that we probably should look at OVSDB, since it’s the most mature (tbachman, 16:32:14)
    36. AGREED: opendaylight-ovsdb guys are “mature” ;) (tbachman, 16:32:36)
    37. lenrow points out that it’s important to get all things writing to flow tables under the GBP umbrella (tbachman, 16:33:28)
    38. regXboi has an issue with that, but that should be taken up separately (tbachman, 16:33:45)
    39. dvorkinista notes that GBP does not dictate who gets to write renderers. (tbachman, 16:34:06)
    40. where projects can decide if they want to have plugins that participate as part of GBP (tbachman, 16:34:26)
    41. Question for OpFlex renderer case: there is an agent needed for the OVS switch (tbachman, 16:35:25)
    42. dvorkinista says yes, and the interface between the agent and OVS is OpenFlow and OVSDB (tbachman, 16:35:45)
    43. Since routing and bridging is happening, that means we’re injecting L2 and L3 adjacencies when a new host comes up (tbachman, 16:36:50)
    44. Question of whether it’s worthwhile to support L2, and not just do L3 (tbachman, 16:37:12)
    45. readams notes that you can do that, but that some folks like L2 as well (tbachman, 16:37:36)
    46. One tricky part is allowing hosts to communicate with the outside world (tbachman, 16:37:58)
    47. There are two broad approaches, and not clear which one this proof of concept will use (tbachman, 16:38:25)
    48. First approach is OVS gateway boxes and map an external endpoint onto one of the external interfaces on that box, and then use that box as a routing bridge between the overlay network and the outside world (tbachman, 16:38:54)
    49. That has the advantage in that it’s conceptually simple (i.e. easy to conceive) (tbachman, 16:39:13)
    50. The other approach is a dNAT scheme (tbachman, 16:39:25)
    51. For any given switch, there’s a pool of IPs that it can allocate, and any endpoint that wants to communicate wtih the outside world gets an IP from that pool. (tbachman, 16:40:17)
    52. current plan is to use dNAT scheme (tbachman, 16:40:47)
    53. lenrow asks who’s going to be impacted by configuration complexity? (tbachman, 16:41:11)
    54. readams says it’s an operational impact (tbachman, 16:41:20)
    55. regXboi says that dNAT doesn’t scale, b/c scaling pools with each vSwitch (tbachman, 16:43:09)
    56. dvorkinista emphasizes this is proof of concept, so this is probably fine (tbachman, 16:43:49)
    57. regXboi notes that OpenDove does have a GW, but that OpenDove is not participating in Helium, b/c it wants pieces in place (e.g. GBP) before adding that feature. (tbachman, 16:47:25)
    58. the OVSDB project may have pieces that can be leveraged for the renderer (tbachman, 16:53:59)
    59. The actual OF renderer itself isn’t yet flushed out. (tbachman, 16:54:16)
    60. https://wiki.opendaylight.org/view/Group_Policy:Architecture/OpenFlow_Renderer Description of what OF renderer needs (tbachman, 16:54:57)
    61. lenrow asks if enhancing some components like topology manager for lookup can be leveraged for this example (tbachman, 16:58:15)
    62. readams says that we of course could/should leverage existing controller components (tbachman, 16:58:33)
    63. mickey asks whether we are merging mapping concepts with the endpoint registry (tbachman, 17:00:18)
    64. readams notes that dvorkin says this should be handled in the EP registry, using context (tbachman, 17:01:04)
    65. Where a field exists that isn’t defined by the model, but renderers know how to interpret and use (tbachman, 17:01:35)
    66. regXboi is over on model hangout keeping dconde company.... (regXboi, 17:03:18)
    67. alagalah: you need to herd folks to the new hangout (regXboi, 17:03:44)
    68. I am here in the hangout with regXboi (dconde, 17:03:56)
    69. Renderer meeting bleeding into model meeting (tbachman, 17:05:39)


Meeting ended at 17:10:43 UTC (full logs).

Action items

  1. (none)


People present (lines said)

  1. tbachman (72)
  2. regXboi (18)
  3. odl_meetbot (7)
  4. alagalah (7)
  5. dconde (2)
  6. mestery (1)
  7. dave_tucker (1)


Generated by MeetBot 0.1.4.