15:04:30 #startmeeting bgpvpn 15:04:31 Meeting started Tue Jun 21 15:04:30 2016 UTC and is due to finish in 60 minutes. The chair is tmorin. Information about MeetBot at http://wiki.debian.org/MeetBot. 15:04:32 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 15:04:34 The meeting name has been set to 'bgpvpn' 15:04:59 hi matrohon doude mickeys pcarver michchap wdeclercq 15:05:03 hi 15:05:06 o/ 15:05:18 hi. Double booked in another meeting again 15:05:28 hi 15:05:51 pcarver: ok, np 15:06:03 tmorin: hi 15:07:27 what do we have on our agenda ? 15:08:35 I see: horizon work, i18n things, RT/RD regex fix, some doc and test updates 15:08:43 anything else ? 15:09:53 let's start 15:09:59 #topic horizon 15:10:36 the change adding the horizon plugin (admin workflow only for now) is mostly ready after a few respins 15:10:58 matrohon has to do his review, I'm optimistic that the work is mostly done 15:11:18 I know, shame on me :( 15:12:18 yes, since cedric will follow up with the tenant workflow, so it would be nice if you can feedback on this first step 15:12:35 #topic i18n 15:12:54 I had a first look, should we wait for the doc in this patch? 15:13:17 no, the doc can come later I think 15:13:22 #undo 15:13:23 Removing item from minutes: 15:13:47 #topic i18n 15:13:51 I merged yesterday a simple change to not import neutron.i18n anymore 15:14:01 #link https://review.openstack.org/#/c/331710/ 15:14:10 not much to say about that... 15:14:24 #topic RT/RD regex 15:14:51 Thomas Monguillon contributed code to fix a limitation we had 15:15:05 we were not supporting all the different formats for RT/RDs 15:15:14 we merged the fix a few minutes ago 15:15:24 #link https://review.openstack.org/#/c/331159/ 15:16:00 #topic doc/test updates 15:16:22 we also merged a few doc and unit test additions 15:16:27 not much to say about these 15:16:49 #topic bugs 15:17:12 there were a few discussions last week around a few bug reports 15:17:25 #topic VNI in the API 15:17:43 #link https://bugs.launchpad.net/bgpvpn/+bug/1590908 15:17:44 Launchpad bug 1590908 in bgpvpn "[RFE] Add 'VNI' column in bgpvpns table in Neutron database." [Wishlist,Confirmed] - Assigned to Siddanagouda Khot (siddanmk) 15:17:59 mickeys: do you want to comment more ? 15:18:28 Yes, I was just looking at your response. I am composing a reply. 15:18:29 Hi tmorin, 15:18:30 this discussion related to the addition of the VNI field, which is needed by the BGP DR project E-VPN extension 15:18:41 The question is the nature of the constraint. 15:18:46 coding is almost finished, will send for review soon 15:19:10 One part is the forward and reverse directions using the same VNI. 15:19:16 steve_ruan: good - let me assign you to the bug 15:19:35 I think one aspect is that EVPN can be used for both L2 and L3 connectivity. In the case of association with a router, it is L3 connectivity. 15:19:53 thanks 15:19:55 That router can be connected to multiple VNIs, each representing a separate connection to an L2 network. 15:20:47 I am referring to EVPN prefix advertisement specifically. 15:23:16 mickeys: I'm not sure I have a clear understanding of what you mean by "a router can be connected to multiple VNIs" 15:24:43 A tenant has a router. Behind the router are multiple tenant networks. On the other side of the router there are two networks. One is the external gateway network that connects to the internet. Another network connects to the tenant VRF instance on the upstream physical router. Both of the latter two can be VXLAN-based, with different VNIs. 15:26:51 mickeys: yes, at this point of the description, BGPVPN would be involved only for "Another network connects to the tenant VRF instance" 15:28:01 Initially that is how we plan to deploy it. However, we have had some internal discussion of supporting the external gateway network eventually becoming just another BGPVPN, with one shared VNI for internet connectivity. 15:33:23 I guess this brings up questions about the L2 versus L3 semantics of router associations, and of EVPN prefix advertisement. 15:33:35 mickeys: I'm trying to understand how we could reconciliate what it seems you would like to do (associate a router to two BGPVPNs that specify a distinct VNI) with what we had initially described (reflect hardware VXLAN limitations and prevent processing a route for a Router/Network associated to two BGPVPNs specifying a different VNI) 15:35:22 there are a few questions that I have 15:36:09 first, where does your need for controlling the VNI come from ? 15:36:59 second, could you instead, of associating a Router to the two BGPVPNs, associate each of the specific Network to one of the BGPVPNs ? 15:38:23 tmorin: Partly due to the way Neutron defines networks statically. Partly for interoperability with upstream physical routers. 15:38:33 tmorin: I agree with one VNI per L2 network. 15:39:58 tmorin: We don't seem to view a router association in the same way. If you associate multiple networks with a BGPVPN, are you routing or bridging between the multiple networks and the VNI? If you associate a router with a BGPVPN, are you routing or bridging between the multiple networks and the VNI? 15:40:45 tmorin: In case of a router association, we expect to route between the networks attached to the router, and the VNI. 15:41:35 "If you associate multiple networks with a BGPVPN, are you routing or bridging between the multiple networks and the VNI?" => route if l3 BGPVPN, bridge if l2 BGPVPN 15:42:04 tmorin: If you use that definition, then EVPN can be both l2 and l3 15:42:08 "If you associate a router with a BGPVPN, are you routing or bridging between the multiple networks and the VNI?" => route (only applies to type l3 BGPVPN) 15:42:56 tmorin: And in that case, I don't understand what a router association to a l2 BGPVPN is 15:43:08 but whether E-VPN is routing or bridging is a nearly-theological question, right ? ;) 15:43:40 If you want to call it l3 EVPN, with the constraint to a single VNI specific to l2 EVPN, I am fine with that 15:43:46 mickeys: as currently described in the API, a Router association to an l2 BGPVPN is not supported 15:44:45 yes, since it setups connectivity outside a given subnet, I believe the EVPN prefixes spec provide l3 connectivity 15:46:25 tmorin: With this approach, we need EVPN to be separate from type, i.e. we need 'technique' 15:46:59 mickeys: this is perfectly acceptable, evpn-prefixes is actually the one example we have for technique 15:47:12 tmorin: Yes I see that 15:47:22 getting back to my earlier question: where would it break if you associated your Router to (one or two) BGPVPNs without specifying the VNI ? 15:47:56 it seems that the VNI would only be derived from what is advertised in the route 15:48:19 The only thing that did not make sense to me is that in the examples, you have GET /bgpvpn/techniques. I think we need this on each bgpvpn, not just as a capability. 15:48:21 you would still be able to honor/use the VNI advertised in E-VPN routes by upstream physical routers 15:48:58 mickeys: we described both (listing the proposed techniques *and* specifying a technique per BGPVPN) 15:49:25 #link http://docs.openstack.org/developer/networking-bgpvpn/future/attributes.html 15:50:07 tmorin: Regarding 'technique', both is good. I only see GET /bgpvpn/techniques in the link right now. 15:50:33 pursing my reasoning above: without an ability to specify the VNI, you may however advertise routes that the upstream router, *if* it has a limitation of a fixed VNI per VPN, would not be able to honor -- is this an issue you need to address ? 15:50:51 http://docs.openstack.org/developer/networking-bgpvpn/future/attributes.html --> first table lists 'technique' as an attribute of BGPVPN 15:51:39 I now see that its not explicitly said that we talk about attributes *of the BGPVPN resource* 15:51:56 but well, this is the only resource that has attributes in the API today 15:51:58 tmorin: In the Neutron Dynamic Routing EVPN implementation, we are treating the entire transit network between the Neutron router and the upstream physical router as a static thing. A user has to create the network statically with a single VNI, create a bgpvpn listing that VNI, add a router interface to that VNI, and associate the router with the bgpvpn 15:53:13 tmorin: And yes, I blurred the lines a bit between admin and tenant with regard to all those things that have to be created. 15:53:31 tmorin: This is all clarified in the Neutron Dynamic Routing EVPN spec 15:53:38 mickeys: yes, this is the proposal that you currently have -- I'm trying to understand why each thing is needed 15:54:25 mickeys: perhaps using "has same VNI" as the things that binds the different things together, is not the right approach 15:54:57 tmorin: Typically interfaces on Neutron routers are defined statically, to L2 networks that are defined statically 15:55:23 tmorin: This is also a way to achieve same VNI for forward and reverse directions. 15:56:41 tmorin: I guess in terms of l2 bgpvpns, I am having trouble wrapping my head around the notion of associating a single network with multiple bgpvpns 15:57:29 tmorin: For l3, each bgpvpn represents different l2 connectivity and so can have a different VNI 15:58:33 mickeys: in practice it boils down to merging import RT lists and export RT lists, the result in terms of what connectivity you achieve, depend on what you'll find in the merged lists 15:59:03 mickeys: it's not easily summarized in a conceptually simpler way 15:59:32 I'm not sure what you mean by "For l3, each bgpvpn represents different l2 connectivity" 15:59:56 l3 BGPVPN relate to IP connectivity, nothing l2 in there 16:00:41 tmorin: You can have multiple bgpvpns, each with different VNIs. In case of EVPN prefix, there is L2 wrapped around the L3. The encap is L2, and this brings some baggage with it. 16:01:40 Hi folks, sorry. We need to start the Magnum meeting now 16:01:45 yes, sorry 16:02:01 mickeys: do you want to follow up in #openstack-net-bgpvpn ? 16:02:06 ok 16:02:11 thanks everyone 16:02:13 #endmeeting