15:10:43 <tmorin> #startmeeting bgpvpn
15:10:43 <openstack> 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 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:10:46 <openstack> The meeting name has been set to 'bgpvpn'
15:10:50 <tmorin> hi everyone
15:11:53 <tmorin> hi doude, matrohon, mickeys, pcarver, timirnich, wdeclercq, michchap
15:12:04 <wdeclercq> hello
15:12:10 <mickeys> Hi
15:12:11 <matrohon> hi
15:13:23 <tmorin> let's start
15:13:41 <tmorin> #topic update on work during past weeks
15:13:57 <tmorin> I'm myself just back from PTO
15:14:06 <tmorin> some things have happened in the meantime
15:14:10 <tmorin> some bugfixes
15:14:15 <tmorin> some tempest improvements
15:15:07 <tmorin> we are currently fixing the tempest job so that it actually runs our tempest suite
15:15:28 <tmorin> kinda required before merging tempest additional test
15:16:08 <eon`> when do you think it will be available ?
15:16:48 <matrohon> eon : https://review.openstack.org/355999 https://review.openstack.org/#/c/352401/
15:17:09 <matrohon> eon : under review, merge hopefully tomorroxw
15:17:27 <eon`> matrohon: thx, I did not see the first one
15:17:38 <tmorin> as soon as we see the test run in the gate and confirm that it does what we want
15:17:48 <tmorin> and assuming all tests do pass :)
15:18:47 <tmorin> #topic bug review
15:19:01 <tmorin> we have a few new bugs/enhancements to address
15:19:14 <tmorin> https://bugs.launchpad.net/bgpvpn/+bug/1608481
15:19:14 <openstack> Launchpad bug 1608481 in networking-bgpvpn "neutron bgpvpn-update command fails to update a list of import-targets" [Undecided,New]
15:19:24 <tmorin> this one I did not try to reproduce yet
15:20:09 <tmorin> 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 <tmorin> any idea ?
15:22:05 <wdeclercq> 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 <wdeclercq> and then complains there is no name
15:22:34 <eon`> yep maybe the name should be placed as the first argument
15:23:02 <wdeclercq> not name but bgpvpn*
15:24:06 <tmorin> I agree
15:24:25 <tmorin> I'm not sure we can fix the output of --help
15:24:33 <tmorin> to avoid misleading the user
15:24:55 <tmorin> ok, I think we can reply/close this report
15:25:03 <tmorin> https://bugs.launchpad.net/bgpvpn/+bug/1607596
15:25:05 <openstack> Launchpad bug 1607596 in networking-bgpvpn "[RFE] Add 'technique' column in bgpvpns table in Neutron database." [Undecided,New]
15:25:15 <tmorin> mickeys: any comment on this one  ?
15:25:59 <tmorin> 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 <tmorin> I will reply to steve
15:26:57 <mickeys> 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 <tmorin> we want an admin-only distinct field, so that only the admin has to care about this
15:27:20 <mickeys> tmorin: In the near term, what we will implement will be mostly L3 evpn-prefix
15:29:20 <mickeys> 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 <tmorin> If you can tell in more detail it will be useful
15:29:45 <mickeys> tmorin: So one question is whether L3 evpn-prefix can include type 5 / type 2 combination
15:30:08 <mickeys> tmorin: I think the answer is yes, in which case we can get by with evpn-prefix for now
15:30:14 <tmorin> right now I don't see what steve mean by a "conflict", in his comment
15:30:55 <tmorin> 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 <tmorin> 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 <tmorin> next topic ?
15:35:02 <mickeys> 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 <tmorin> yes
15:36:09 <tmorin> the doc is expired, but alive/relevant, still suffering from a delayed update
15:36:36 <mickeys> 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 <tmorin> 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 <tmorin> if needed, we can develop the explanation of what the 'type' attribute means
15:40:03 <mickeys> 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 <mickeys> tmorin: More explanation would be good.
15:40:38 <mickeys> tmorin: I think we can take this offline, or back to the bug itself.
15:40:43 <tmorin> agreed
15:40:53 <tmorin> #topic open discuss
15:41:06 <tmorin> do we have anything else to discuss ?
15:41:17 <tmorin> #undo
15:41:18 <openstack> Removing item from minutes: <ircmeeting.items.Topic object at 0x7f5bc01d6290>
15:41:36 <tmorin> the VNI contribution may be worth discussing
15:41:51 <tmorin> https://review.openstack.org/#/c/332711/
15:41:53 <tmorin> mickeys: ^
15:42:48 <tmorin> 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 <mickeys> 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 <tmorin> it would be good to cover what is needed (the overlap thing, maybe other things?) in this change
15:44:37 <mickeys> 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 <tmorin> 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 <tmorin> mickeys: do you have a pointer to the E-VPN contribution ?
15:47:23 <mickeys> 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 <mickeys> 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 <tmorin> mickeys: remember that I'm back from PTO :)
15:48:35 <tmorin> mickeys: I need more to understand, can you provide an example ?
15:49:51 <mickeys> 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 <mickeys> 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 <mickeys> tmorin: I still think in the latter case of RT 1 and RT 2 with VNI 1, it should be allowed.
15:52:20 <mickeys> tmorin: The initial Quagga patch is https://lists.quagga.net/pipermail/quagga-dev/2016-May/015364.html
15:52:40 <tmorin> 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 <mickeys> 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 <mickeys> tmorin: And yes it needs to be incorporated into Steve's change.
15:53:33 <tmorin> mickeys: ok, then it's just a matter of incorporating what we concluded on, in steve's change
15:53:36 <tmorin> yes
15:54:12 <tmorin> assuming we came to a conclusion we agreed on at the time ; I think I recall that we did
15:54:54 <mickeys> mickeys: I don't agree with the conclusion 100%. Maybe next week I can spend some time clarifying my concerns.
15:55:07 <tmorin> mickeys: ok
15:55:39 <tmorin> can you propose clarification in the form of comments on the VNI related bug, or on steve's vni change ?
15:55:57 <mickeys> tmorin: yes
15:56:04 <tmorin> thanks
15:56:05 <tmorin> #topic open discussion
15:56:10 <tmorin> done for today ?
16:00:28 <openstack> hongbin: Error: Can't start another meeting, one is in progress.  Use #endmeeting first.
16:00:44 <hongbin> .....
16:01:03 <tmorin> thanks everyone!
16:01:07 <tmorin> #endmeeting