16:09:09 <alagalah> #startmeeting Renderer 16:09:09 <odl_meetbot> Meeting started Fri Jun 20 16:09:09 2014 UTC. The chair is alagalah. Information about MeetBot at http://ci.openstack.org/meetbot.html. 16:09:09 <odl_meetbot> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 16:09:09 <odl_meetbot> The meeting name has been set to 'renderer' 16:09:20 <alagalah> #chair regXboi 16:09:20 <odl_meetbot> Current chairs: alagalah regXboi 16:10:55 * regXboi wonders if he should get biz cards that say "unprofessional scribe - have pen, will travel" 16:14:28 <regXboi> #topic renderer_common 16:14:45 <regXboi> #link https://wiki.opendaylight.org/view/Group_Policy:Architecture/Renderer_Common 16:15:00 <regXboi> #info lenrow asks what is tenant 16:15:22 <regXboi> #info readams answers that it is the top level container for policies 16:15:30 <tbachman> #info plan is to build two renderers: OpenFlow and OpFlex 16:15:40 <tbachman> #info WIll use OVS-based overlay 16:15:45 <regXboi> #info lenrow points out that this is an overloaded term across ODL and so it might change 16:15:55 <regXboi> #chair tbachman 16:15:55 <odl_meetbot> Current chairs: alagalah regXboi tbachman 16:16:55 <tbachman> #link https://wiki.opendaylight.org/view/Group_Policy:Architecture/OVS_Overlay Description of overlay network 16:17:07 <alagalah> Go tbachman 16:17:10 <tbachman> lol 16:17:48 <tbachman> #info Overlay needs MTU that can support 1500 byte packets (e.g. 1600 MTU, to account for tunnel encap overhead) 16:17:55 <tbachman> #info regXboi notes that this is a real issue 16:19:11 <tbachman> #info The overlay model is simple, in order to be able to demonstrate use of GBP 16:20:18 <tbachman> #info lenrow asks if this design has an OpFlex connection to one OVS instance and OpenFlow connection to the other OVS instanct 16:20:34 <tbachman> #info This currently isn’t planned — will be either or, but not both 16:21:06 <tbachman> #info The Overlay example has two subnets 16:21:50 <tbachman> #info it’s important to have a logically “out of band" control channel 16:22:04 <tbachman> #info The example uses VxLAN encap 16:22:49 <tbachman> #info VxLAN encap has network identifier 16:23:25 <tbachman> #info would allocate a universal gateway map, which would be owned by distributed router 16:23:37 <tbachman> #info simple lookup to see if L2 is targeting GW 16:23:52 <tbachman> #info For bridging, deliver to destination 16:24:39 <tbachman> #info 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 16:25:22 <tbachman> #info Determination of Next Hop destination for any given EP is renderer-specific 16:25:35 <tbachman> #info for OpFlex, will likely be reactive, since agent is on the switch 16:25:46 <tbachman> #info for OpenFlow, will likely be a hybrid 16:26:09 <tbachman> #info Question on reactive in OpFlex: driven by the controller or agent? 16:26:19 <tbachman> #info For learning, this will be a packet-in 16:26:48 <tbachman> #info controller then pushes this information where needed 16:28:06 <tbachman> #info dvorkinista notes that this is a proof-of-concept 16:29:20 <tbachman> #info regXboi notes that this is rebuilding OpenDove 16:29:37 <tbachman> #info dvorkinista asks if we can leverage OpenDove 16:30:14 <tbachman> #info Since this is a proof-of-concept for GBP, this might make sense 16:30:42 <tbachman> #info regXboi says there are some slight differences, but with so it might be good to leverage pieces 16:31:11 <tbachman> #info lenrow notes that OpenDove is currently competing with GBP, so bringing rending code into GBP would be great 16:31:49 <tbachman> #info dave_tucker notes that OVSDB also has netvirt 16:31:55 <tbachman> #info lenrow adds VTN to that 16:32:14 <tbachman> #info regXboi says that we probably should look at OVSDB, since it’s the most mature 16:32:36 <tbachman> #agreed opendaylight-ovsdb guys are “mature” ;) 16:33:28 <tbachman> #info lenrow points out that it’s important to get all things writing to flow tables under the GBP umbrella 16:33:45 <tbachman> #info regXboi has an issue with that, but that should be taken up separately 16:34:06 <tbachman> #info dvorkinista notes that GBP does not dictate who gets to write renderers. 16:34:26 <tbachman> #info where projects can decide if they want to have plugins that participate as part of GBP 16:35:25 <tbachman> #info Question for OpFlex renderer case: there is an agent needed for the OVS switch 16:35:45 <tbachman> #info dvorkinista says yes, and the interface between the agent and OVS is OpenFlow and OVSDB 16:36:50 <tbachman> #info Since routing and bridging is happening, that means we’re injecting L2 and L3 adjacencies when a new host comes up 16:37:12 <tbachman> #info Question of whether it’s worthwhile to support L2, and not just do L3 16:37:36 <tbachman> #info readams notes that you can do that, but that some folks like L2 as well 16:37:58 <tbachman> #info One tricky part is allowing hosts to communicate with the outside world 16:38:25 <tbachman> #info There are two broad approaches, and not clear which one this proof of concept will use 16:38:54 <tbachman> #info 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 16:39:13 <tbachman> #info That has the advantage in that it’s conceptually simple (i.e. easy to conceive) 16:39:25 <tbachman> #info The other approach is a dNAT scheme 16:40:17 <tbachman> #info 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. 16:40:47 <tbachman> #info current plan is to use dNAT scheme 16:41:11 <tbachman> #info lenrow asks who’s going to be impacted by configuration complexity? 16:41:20 <tbachman> #info readams says it’s an operational impact 16:43:09 <tbachman> #info regXboi says that dNAT doesn’t scale, b/c scaling pools with each vSwitch 16:43:49 <tbachman> #info dvorkinista emphasizes this is proof of concept, so this is probably fine 16:47:25 <tbachman> #info 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. 16:51:50 <regXboi> time check? 16:52:03 <tbachman> 9:52PST ;) 16:52:08 <tbachman> lol 16:52:13 <regXboi> model meeting in 8 minutes? 16:53:04 <regXboi> and PST? 16:53:06 <regXboi> really? 16:53:59 <tbachman> #info the OVSDB project may have pieces that can be leveraged for the renderer 16:54:05 <regXboi> mestery: yo! 16:54:16 <tbachman> #info The actual OF renderer itself isn’t yet flushed out. 16:54:55 * mestery waves hello to regXboi from Detroit 16:54:57 <tbachman> #link https://wiki.opendaylight.org/view/Group_Policy:Architecture/OpenFlow_Renderer Description of what OF renderer needs 16:55:09 <regXboi> mestery: why Detroit? 16:55:45 <tbachman> regXboi: mestery’s flight from TX was delayed. Re-route thru Detroit Rock City :) 16:58:00 <alagalah> Thanks for scribing tbachman 16:58:06 <alagalah> Send me the minutes 16:58:15 <tbachman> #info lenrow asks if enhancing some components like topology manager for lookup can be leveraged for this example 16:58:33 <tbachman> #info readams says that we of course could/should leverage existing controller components 16:58:40 <tbachman> alagalah: NP :) 17:00:18 <tbachman> #info mickey asks whether we are merging mapping concepts with the endpoint registry 17:00:47 <dave_tucker> guys I've got to drop. bye all! 17:01:04 <tbachman> #info readams notes that dvorkin says this should be handled in the EP registry, using context 17:01:35 <tbachman> #info Where a field exists that isn’t defined by the model, but renderers know how to interpret and use 17:03:18 <regXboi> #info regXboi is over on model hangout keeping dconde company.... 17:03:44 <regXboi> #info alagalah: you need to herd folks to the new hangout 17:03:56 <dconde> #info I am here in the hangout with regXboi 17:05:09 <tbachman> #chair dconde 17:05:09 <odl_meetbot> Current chairs: alagalah dconde regXboi tbachman 17:05:39 <tbachman> #info Renderer meeting bleeding into model meeting 17:05:50 * regXboi wonders if #chair doubles as the IRC's version of an std 17:06:11 <tbachman> lol 17:06:20 <tbachman> regXboi: I think you’re cured today ;) 17:06:26 <regXboi> I wondered if somebody would get that 17:06:39 <tbachman> lenrow: we got your voicemail 17:06:41 <dconde> I am calling dlenrow on hangout 17:09:17 <regXboi> alagalah: ping on moving to the new google hangout? 17:09:39 <alagalah> I'm not joining to make space 17:09:46 <alagalah> I'm in the room tho 17:10:36 <odl_meetbot> dconde: Error: Can't start another meeting, one is in progress. Use #endmeeting first. 17:10:43 <tbachman> #endmeeting