15:10:43 #startmeeting bgpvpn 15:10:43 Meeting started Tue Aug 16 15:10:43 2016 UTC and is due to finish in 60 minutes. The chair is tmorin. Information about MeetBot at http://wiki.debian.org/MeetBot. 15:10:44 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 15:10:46 The meeting name has been set to 'bgpvpn' 15:10:50 hi everyone 15:11:53 hi doude, matrohon, mickeys, pcarver, timirnich, wdeclercq, michchap 15:12:04 hello 15:12:10 Hi 15:12:11 hi 15:13:23 let's start 15:13:41 #topic update on work during past weeks 15:13:57 I'm myself just back from PTO 15:14:06 some things have happened in the meantime 15:14:10 some bugfixes 15:14:15 some tempest improvements 15:15:07 we are currently fixing the tempest job so that it actually runs our tempest suite 15:15:28 kinda required before merging tempest additional test 15:16:08 when do you think it will be available ? 15:16:48 eon : https://review.openstack.org/355999 https://review.openstack.org/#/c/352401/ 15:17:09 eon : under review, merge hopefully tomorroxw 15:17:27 matrohon: thx, I did not see the first one 15:17:38 as soon as we see the test run in the gate and confirm that it does what we want 15:17:48 and assuming all tests do pass :) 15:18:47 #topic bug review 15:19:01 we have a few new bugs/enhancements to address 15:19:14 https://bugs.launchpad.net/bgpvpn/+bug/1608481 15:19:14 Launchpad bug 1608481 in networking-bgpvpn "neutron bgpvpn-update command fails to update a list of import-targets" [Undecided,New] 15:19:24 this one I did not try to reproduce yet 15:20:09 but I'm surprised that there would be an issue there, since we're just reusing an existing, and I assume largely tested, framework 15:22:03 any idea ? 15:22:05 Well judging by the error message and the command it kind of makes sense that the framework doesn't know the end of the list. It probably appends the name to the import-targets 15:22:14 and then complains there is no name 15:22:34 yep maybe the name should be placed as the first argument 15:23:02 not name but bgpvpn* 15:24:06 I agree 15:24:25 I'm not sure we can fix the output of --help 15:24:33 to avoid misleading the user 15:24:55 ok, I think we can reply/close this report 15:25:03 https://bugs.launchpad.net/bgpvpn/+bug/1607596 15:25:05 Launchpad bug 1607596 in networking-bgpvpn "[RFE] Add 'technique' column in bgpvpns table in Neutron database." [Undecided,New] 15:25:15 mickeys: any comment on this one ? 15:25:59 mickeys: wrt to steve comment, I think the rationale for adding a 'technique' field distinct from the type, wasn't taken into consideration 15:26:31 I will reply to steve 15:26:57 tmorin: If you go to some of the more advanced methods in the IETF drafts, you can support a combination of L2 evpn and L3 evpn-prefix at the same time. 15:27:06 we want an admin-only distinct field, so that only the admin has to care about this 15:27:20 tmorin: In the near term, what we will implement will be mostly L3 evpn-prefix 15:29:20 tmorin: My memory of the L2/L3 evpn/evpn-prefix combination is not that clear. I think it was using two VNIs, with L2/L3 forwarding decisions driving which one to use. 15:29:44 If you can tell in more detail it will be useful 15:29:45 tmorin: So one question is whether L3 evpn-prefix can include type 5 / type 2 combination 15:30:08 tmorin: I think the answer is yes, in which case we can get by with evpn-prefix for now 15:30:14 right now I don't see what steve mean by a "conflict", in his comment 15:30:55 mickeys: yes, I'd say yes as well, the question is not about the protocol details, but the kind of connectivity provided 15:31:36 if a type 2 route is necessary, with a given technique, to provide an l3 connectivity, then it's ok, it not a conflict 15:33:41 next topic ? 15:35:02 tmorin: The L2/L3 case (which we are not implementing) is described in https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-inter-subnet-forwarding/, which is expired 15:35:39 yes 15:36:09 the doc is expired, but alive/relevant, still suffering from a delayed update 15:36:36 tmorin: The question is whether that breaks the type/technique design, since both L2 and L3 forwarding are used at the same time. 15:39:16 mickeys: what makes it clearly a service of type l3 is that you look at the dest IP header and resolve for deliver to the corresponding IP destination, the fact that you also look at the L2 header does not change that 15:39:46 if needed, we can develop the explanation of what the 'type' attribute means 15:40:03 tmorin: I would have to look at it more carefully to see if the L2/L3 divide falls clearly into different bgpvpns, or whether there is a case where one bgpvpn needs both L2 and L3. 15:40:24 tmorin: More explanation would be good. 15:40:38 tmorin: I think we can take this offline, or back to the bug itself. 15:40:43 agreed 15:40:53 #topic open discuss 15:41:06 do we have anything else to discuss ? 15:41:17 #undo 15:41:18 Removing item from minutes: 15:41:36 the VNI contribution may be worth discussing 15:41:51 https://review.openstack.org/#/c/332711/ 15:41:53 mickeys: ^ 15:42:48 we think we have identified how the semantic of the VNI field needs to be adjusted to clarify how to handle overlaps between the VXLAN ranged defined for L2 networks, and the value used in a BGPVPN vni attribute 15:43:07 tmorin: I still think the doc/source/api.rst description could use more discussion. I don't think anything else is affected. 15:44:35 it would be good to cover what is needed (the overlap thing, maybe other things?) in this change 15:44:37 tmorin: While we are focused primarily on a L3 implementation, looking at how the internals of the Quagga EVPN implementation work (still under discussion, not yet accepted), it would be difficult to implement the coupling of RT and VNI that you have arrived at for L2. 15:45:43 mickeys: can you be explicit on what you mean by "the coupling of RT and VNI that you have arrived at for L2" ? 15:46:14 mickeys: do you have a pointer to the E-VPN contribution ? 15:47:23 tmorin: When you have multiple RTs and multiple VNIs, the VNI must be considered with the set of RTs rather than just the RT that it is associated with (ignoring the other RTs if present). Not sure I stated it in a way that clarifies things. 15:48:08 tmorin: Let me look it up. Actually it is a L3VPN implementation which we are extending to EVPN. I don't think the EVPN aspects have been submitted upstream yet, but it is based on the L3VPN implementation that has been submitted upstream to Quagga. 15:48:22 mickeys: remember that I'm back from PTO :) 15:48:35 mickeys: I need more to understand, can you provide an example ? 15:49:51 tmorin: You have L2 BGPVPN 1 with VNI 1 and RT 1, and L2 BGPVPN 2 with VNI 2 and RT 2. Under the current proposal, if you receive RT 1 with VNI 1, it can be used. If you receive RT 1 and RT 2 with VNI 1, it is not allowed. 15:51:05 tmorin: In the current Quagga implementation (which has some L2VPN capability but it needs to be brought up to current EVPN standards), upon receive the RT filtering happens first to get it in the right grouping. The VNI filtering would happen afterwards, but by then the RT is gone. 15:51:25 tmorin: I still think in the latter case of RT 1 and RT 2 with VNI 1, it should be allowed. 15:52:20 tmorin: The initial Quagga patch is https://lists.quagga.net/pipermail/quagga-dev/2016-May/015364.html 15:52:40 mickeys: didn't we had this discussion already in May/June ? the discussion we had at the time hasn't indeed been incorporated in steve's change 15:53:06 tmorin: I think we made a lot of progress, but it could use a little more discussion. And yes it is the same discussion. 15:53:23 tmorin: And yes it needs to be incorporated into Steve's change. 15:53:33 mickeys: ok, then it's just a matter of incorporating what we concluded on, in steve's change 15:53:36 yes 15:54:12 assuming we came to a conclusion we agreed on at the time ; I think I recall that we did 15:54:54 mickeys: I don't agree with the conclusion 100%. Maybe next week I can spend some time clarifying my concerns. 15:55:07 mickeys: ok 15:55:39 can you propose clarification in the form of comments on the VNI related bug, or on steve's vni change ? 15:55:57 tmorin: yes 15:56:04 thanks 15:56:05 #topic open discussion 15:56:10 done for today ? 16:00:28 hongbin: Error: Can't start another meeting, one is in progress. Use #endmeeting first. 16:00:44 ..... 16:01:03 thanks everyone! 16:01:07 #endmeeting