==================================== #opendaylight-group-policy: Renderer ==================================== Meeting started by alagalah at 16:09:09 UTC. The full logs are available at http://meetings.opendaylight.org/opendaylight-group-policy/2014/renderer/opendaylight-group-policy-renderer.2014-06-20-16.09.log.html . Meeting summary --------------- * renderer_common (regXboi, 16:14:28) * LINK: https://wiki.opendaylight.org/view/Group_Policy:Architecture/Renderer_Common (regXboi, 16:14:45) * lenrow asks what is tenant (regXboi, 16:15:00) * readams answers that it is the top level container for policies (regXboi, 16:15:22) * plan is to build two renderers: OpenFlow and OpFlex (tbachman, 16:15:30) * WIll use OVS-based overlay (tbachman, 16:15:40) * lenrow points out that this is an overloaded term across ODL and so it might change (regXboi, 16:15:45) * LINK: https://wiki.opendaylight.org/view/Group_Policy:Architecture/OVS_Overlay Description of overlay network (tbachman, 16:16:55) * Overlay needs MTU that can support 1500 byte packets (e.g. 1600 MTU, to account for tunnel encap overhead) (tbachman, 16:17:48) * regXboi notes that this is a real issue (tbachman, 16:17:55) * The overlay model is simple, in order to be able to demonstrate use of GBP (tbachman, 16:19: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) * This currently isn’t planned — will be either or, but not both (tbachman, 16:20:34) * The Overlay example has two subnets (tbachman, 16:21:06) * it’s important to have a logically “out of band" control channel (tbachman, 16:21:50) * The example uses VxLAN encap (tbachman, 16:22:04) * VxLAN encap has network identifier (tbachman, 16:22:49) * would allocate a universal gateway map, which would be owned by distributed router (tbachman, 16:23:25) * simple lookup to see if L2 is targeting GW (tbachman, 16:23:37) * For bridging, deliver to destination (tbachman, 16:23:52) * 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) * Determination of Next Hop destination for any given EP is renderer-specific (tbachman, 16:25:22) * for OpFlex, will likely be reactive, since agent is on the switch (tbachman, 16:25:35) * for OpenFlow, will likely be a hybrid (tbachman, 16:25:46) * Question on reactive in OpFlex: driven by the controller or agent? (tbachman, 16:26:09) * For learning, this will be a packet-in (tbachman, 16:26:19) * controller then pushes this information where needed (tbachman, 16:26:48) * dvorkinista notes that this is a proof-of-concept (tbachman, 16:28:06) * regXboi notes that this is rebuilding OpenDove (tbachman, 16:29:20) * dvorkinista asks if we can leverage OpenDove (tbachman, 16:29:37) * Since this is a proof-of-concept for GBP, this might make sense (tbachman, 16:30:14) * regXboi says there are some slight differences, but with so it might be good to leverage pieces (tbachman, 16:30:42) * lenrow notes that OpenDove is currently competing with GBP, so bringing rending code into GBP would be great (tbachman, 16:31:11) * dave_tucker notes that OVSDB also has netvirt (tbachman, 16:31:49) * lenrow adds VTN to that (tbachman, 16:31:55) * regXboi says that we probably should look at OVSDB, since it’s the most mature (tbachman, 16:32:14) * AGREED: opendaylight-ovsdb guys are “mature” ;) (tbachman, 16:32:36) * lenrow points out that it’s important to get all things writing to flow tables under the GBP umbrella (tbachman, 16:33:28) * regXboi has an issue with that, but that should be taken up separately (tbachman, 16:33:45) * dvorkinista notes that GBP does not dictate who gets to write renderers. (tbachman, 16:34:06) * where projects can decide if they want to have plugins that participate as part of GBP (tbachman, 16:34:26) * Question for OpFlex renderer case: there is an agent needed for the OVS switch (tbachman, 16:35:25) * dvorkinista says yes, and the interface between the agent and OVS is OpenFlow and OVSDB (tbachman, 16:35:45) * 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) * Question of whether it’s worthwhile to support L2, and not just do L3 (tbachman, 16:37:12) * readams notes that you can do that, but that some folks like L2 as well (tbachman, 16:37:36) * One tricky part is allowing hosts to communicate with the outside world (tbachman, 16:37:58) * There are two broad approaches, and not clear which one this proof of concept will use (tbachman, 16:38:25) * 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) * That has the advantage in that it’s conceptually simple (i.e. easy to conceive) (tbachman, 16:39:13) * The other approach is a dNAT scheme (tbachman, 16:39:25) * 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) * current plan is to use dNAT scheme (tbachman, 16:40:47) * lenrow asks who’s going to be impacted by configuration complexity? (tbachman, 16:41:11) * readams says it’s an operational impact (tbachman, 16:41:20) * regXboi says that dNAT doesn’t scale, b/c scaling pools with each vSwitch (tbachman, 16:43:09) * dvorkinista emphasizes this is proof of concept, so this is probably fine (tbachman, 16:43:49) * 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) * the OVSDB project may have pieces that can be leveraged for the renderer (tbachman, 16:53:59) * The actual OF renderer itself isn’t yet flushed out. (tbachman, 16:54:16) * LINK: https://wiki.opendaylight.org/view/Group_Policy:Architecture/OpenFlow_Renderer Description of what OF renderer needs (tbachman, 16:54:57) * lenrow asks if enhancing some components like topology manager for lookup can be leveraged for this example (tbachman, 16:58:15) * readams says that we of course could/should leverage existing controller components (tbachman, 16:58:33) * mickey asks whether we are merging mapping concepts with the endpoint registry (tbachman, 17:00:18) * readams notes that dvorkin says this should be handled in the EP registry, using context (tbachman, 17:01:04) * Where a field exists that isn’t defined by the model, but renderers know how to interpret and use (tbachman, 17:01:35) * regXboi is over on model hangout keeping dconde company.... (regXboi, 17:03:18) * alagalah: you need to herd folks to the new hangout (regXboi, 17:03:44) * I am here in the hangout with regXboi (dconde, 17:03:56) * Renderer meeting bleeding into model meeting (tbachman, 17:05:39) Meeting ended at 17:10:43 UTC. People present (lines said) --------------------------- * tbachman (72) * regXboi (18) * odl_meetbot (7) * alagalah (7) * dconde (2) * mestery (1) * dave_tucker (1) Generated by `MeetBot`_ 0.1.4