Jeffrey, I don't think anyone would argue that the proper solution to per-ES mass withdraw is to include the originating router's address in Ethernet AD and MAC Advertisement routes and the only discussion is the best way to encode this information.
Your suggestion of having an ingress PE use the RD field to get the originating router's address has two issues: 1) RDs are known to be re-written by inter-provider ASBRs 2) An IPv6 router address will not fit in an RD Furthermore this is a fundamentally new behavior for an ingress PE and an implementation would need to be changed to support it; no implementation of which I am aware does this today. Given all of the above, the consensus is to include the originating router's address in the remote next-hop sub-TLV of the Encapsulation Attribute and modify egress PEs to include it and ingress PEs to use it. This is a simple and incrementally deployable solution and in the meantime per-EVI mass withdraw can be used. Yours Irrespectively, John > -----Original Message----- > From: BESS [mailto:bess-boun...@ietf.org] On Behalf Of Jeffrey (Zhaohui) Zhang > Sent: Wednesday, June 15, 2016 6:54 AM > To: Ali Sajassi (sajassi); bess@ietf.org > Subject: Re: [bess] Comments on draft-ietf-bess-evpn-overlay-04, wrt Inter-AS > Option B > > Hi Ali, > > > -----Original Message----- > > From: Ali Sajassi (sajassi) [mailto:saja...@cisco.com] > > Sent: Wednesday, June 15, 2016 1:59 AM > > To: Jeffrey (Zhaohui) Zhang <zzh...@juniper.net>; bess@ietf.org > > Subject: Re: [bess] Comments on draft-ietf-bess-evpn-overlay-04, wrt > > Inter-AS Option B > > > > > > Hi Jeffrey, > > > > On 6/14/16, 2:44 AM, "Jeffrey (Zhaohui) Zhang" <zzh...@juniper.net> wrote: > > > > >Hi Ali, > > > > > >> -----Original Message----- > > >> From: Ali Sajassi (sajassi) [mailto:saja...@cisco.com] > > >> Sent: Monday, June 13, 2016 11:01 PM > > >> To: Jeffrey (Zhaohui) Zhang <zzh...@juniper.net>; bess@ietf.org > > >> Cc: Ali Sajassi (sajassi) <saja...@cisco.com> > > >> Subject: Re: [bess] Comments on draft-ietf-bess-evpn-overlay-04, > > >> wrt Inter-AS Option B > > >> > > >> > > >> Hi Jeffrey, > > >> > > >> A few points: > > >> > > >> 1) There have been lots of discussions on this topic but you were > > >> not > > in > > >> attendance for some of them including the ones held at the last > > >> IETF in Bones Aires. So, before jumping into a haste conclusion > > >> that there were not consensus on section 10, please check with your > > >> own colleagues who participated in those meetings. > > >> > > >> 2) Regarding the current text in section 10: this text is > > >>consistent with the one that was checked for IETF at Yokohama and > > >>it is also consistent with RFC 7432 operation. We still require Eth > > >>A-D per ES in order to validate Eth A-d per EVI, the only > > >>difference is that the mass-withdraw doesn¹t work (i.e., route > > >>validation still works). > > > > > >Could the document clarify how the validation is done - how do you > > >conclude that a per-ES route and a per-EVI route are related? If I > > >understand it correctly, if the correlation can be done, then > > >mass-withdraw works. > > > > > >That is the key of the issue that is missing from the document. > > > > It has been described in 4th paragraph of section 10.2.2: > > > > "Now, when the AC between the PE2 and the CE fails and PE2 sends NLRI > > withdrawal for Ether A-D per ES route and this withdrawal gets > > propagated and received by the PE3, the BGP process in PE3 removes > > the corresponding BGP route; however, it doesn't remove the > > associated info (namely ESI and BGP next hop) from the L2 routing > > table (L2 RIB) because it still has the other Ether A-D per ES route > > (originated from PE1) with the same info. That is why the mass- > > withdraw mechanism does not work when doing DCI with inter-AS option > > B. However, as described previoulsy, the aliasing function works and > > so does "mass-withdraw per EVI" (which is associated with withdrawing > > the EVPN route associated with Aliasing - i.e., Ether A-D per EVI > > route)." > > The above describes why only "mass-withdraw per EVI" works. The main problem > is NOT > with that. It's with the following in RFC 7432 as I mentioned initially in > this thread: > > > >> > Note that the Ethernet A-D per EVI route may be received by a remote > > >> > PE before it receives the set of Ethernet A-D per ES routes. > > >> > Therefore, in order to handle corner cases and race conditions, the > > >> > Ethernet A-D per EVI route MUST NOT be used for traffic forwarding by > > >> > a remote PE until it also receives the associated set of Ethernet A-D > > >> > per ES routes. > > For the aliasing part, how do you tell if a per-ES route and a per-EVI route > are from the same > PE? If you cannot tell, then the above validation cannot be done. > > If we assume that they always have the same global admin field in the RDs, > then the > correlation can be done similar to how you associate the per-EVI route and > mac routes as > you clarified; but when I first proposed this solution when the option-B > issue was brought > up, people were saying that RFC 7432 does NOT require the per-ES route and > per-EVI route > have the same global admin field in the RDs, because: > > - per-EVI route uses per-mac-vrf RD, which is RECOMMENDED to use type-1 (not > MUST), > with "typically the lookback address". > - per-ES route MUST uses a type-1 RD with "typically the loopback address". > > Note that there is no explicit requirement/guarantee that the two will have > the same global > admin field in the RDs. If we put that explicit requirement in, then the > problem is solved; > and with that, mass-withdraw per ES also works. > > Please note that it is not me who is splitting hair here. It is other people > who were saying > that RFC does not require they have the same global admin field. > > So if we take this opportunity to tighten up the language, then we have an > "easy solution" > that always works (more below on that), and it removes hair splitting > arguments from some > people. > > > > > > > > >> > > >> 3) Your so-called ³easy solution² doesn¹t work in all scenarios so > > there > > >> is no point in documenting something that works sometimes :-) If > > >> you recall several years ago, we went to great length to > > >> accommodate multi-homing across multiple AS¹s and that¹s why we > > >> added originating router¹s IP address to the ES route. The 4 byte > > >> field in RD type-1, is > > a > > >> router ID (for both IPv4 and IPv6) and per RFC 6286, router-id is > > unique > > >> within an AS only. Thus the suggested solution won¹t work when a CE > > >> is dual-homed to two PEs in two different AS¹s. > > > > > >If those two PEs happen to have the same router-id, and they happen > > >to choose the same local admin field for the RD, e.g. vlan id as > > >section 7.9 of RFC 7432 says: > > > > > > The value field > > > comprises an IP address of the PE (typically, the loopback address) > > > followed by a number unique to the PE. This number may be generated > > > by the PE. Or, in the Unique VLAN EVPN case, the low-order 12 bits > > > may be the 12-bit VLAN ID, with the remaining high-order 4 bits set > > > to 0. > > > > > >How do you distinguish the two routes from the PEs? There is no way > > >to guarantee it "always works" even if you don't use vlan-id. > > > > In such scenarios, the ASBRs perform RD (and RT) translation; however, > > the translated RD no longer needs to be of type-1. > > We discussed this before as well - as long as the RD translation ensures that > routes with the > same global admin field in the RDs continue to have the same global admin > field that is > different from those in routes from different PEs, then the "easy solution" > still works. If it is > not practical to have different admin field for routes from different PEs > after translation, > then the following requirement cannot be satisfied: > > Note that the Ethernet A-D per EVI route may be received by a remote > PE before it receives the set of Ethernet A-D per ES routes. > Therefore, in order to handle corner cases and race conditions, the > Ethernet A-D per EVI route MUST NOT be used for traffic forwarding by > a remote PE until it also receives the associated set of Ethernet A-D > per ES routes. > > BTW - now that you say after translation the RD no longer needs to be of > type-1, is there > any reason to require type-1 at all, even when there is no inter-AS option B? > > Jeffrey > > > > > > > > >> > > >> We are currently separately documenting a proper solution based on > > >> a > > new > > >> sub-TLV added to the attribute in idr-tunnel-encap draft to > > >> identify > > the > > >> originating PE. A solution based on this attribute will work for > > >>all scenarios. Now the question is what to do in short term. We can > > >>either go with the text that it is in section 10.2 of the > > >>evpn-overlay draft, > > plus > > >> go with the new draft, or just go with the new draft and remove the > > >> suggested solution in section 10.2. I am open to both. > > > > > >Multi-homing across ASes (or any segmentation points) is complicated. > > >I've spent quite some cycles on it - in particular split horizon > > >becomes more complicated (I documented it in initial unpublished > > >version of draft-zzhang-bess-evpn-bum-procedure-updates but then > > >removed it). I would like to be included in the relevant discussions on > > >the new > document. > > > > Sure, we can definitely consider it. > > > > Cheers, > > Ali > > > > > > > >If we can say "multi-homing across ASes" is out of scope for now, > > >then the overlay draft can certainly clarify inter-as optin B > > >procedure (especially on how the correlation is done). Otherwise, I'd > > >suggest to remove section 10.2. It is NOT specific to overlay anyway. > > > > > >Jeffrey > > > > > >> > > >> Cheers, > > >> Ali > > >> > > >> > > >> > > >> > > >> > > >> > > >> > > >> On 6/10/16, 1:03 PM, "BESS on behalf of Jeffrey (Zhaohui) Zhang" > > >> <bess-boun...@ietf.org on behalf of zzh...@juniper.net> wrote: > > >> > > >> >I want to bring up an old discussion about the following: > > >> > > > >> > In summary, it can be seen that aliasing (and backup path) > > >> > functionality should work as is for inter-AS option B without > > >> > requiring any addition functionality in ASBRs or PEs. However, the > > >> > mass-withdraw functionality falls back from per-ES mode to per-EVI > > >> > mode for inter-AS option B - i.e., PEs receiving mass-withdraw > > route > > >> > from the same AS use Ether A-D per ES route; whereas, PEs receiving > > >> > mass-withdraw route from different AS use Ether A-D per EVI route. > > >> > > > >> >There have been lot of discussions on this - offline and in > > >> >Yokohama > > >> >(https://www.ietf.org/proceedings/94/slides/slides-94-bess-1.pdf). > > >> >The above text does not reflect the consensus among some of us and in > > >> >particular > does not reflect what was presented in Yokohama. > > >> > > > >> >There are two issues with inter-as option B as currently specified > > >> >in > > >>RFC > > >> >7432. > > >> > > > >> >A minor issue is that mass-withdraw degrades from per ES to from > > >> >per > > >>(ES, > > >> >EVI) (with the clarification in this overlay draft), which would > > >> >not exist if the main issue is resolved as presented in Yokohama. > > >> > > > >> >The main one is the following requirement in RFC 7432: > > >> > > > >> > Note that the Ethernet A-D per EVI route may be received by a > > remote > > >> > PE before it receives the set of Ethernet A-D per ES routes. > > >> > Therefore, in order to handle corner cases and race conditions, the > > >> > Ethernet A-D per EVI route MUST NOT be used for traffic > > >> > forwarding > > >>by > > >> > a remote PE until it also receives the associated set of > > >> > Ethernet > > >>A-D > > >> > per ES routes. > > >> > > > >> >Basically, the per-EVI A-D routes cannot be used before the > > >>corresponding > > >> >per-ES A-D routes are received and associated. Either that > > >> >requirement must be removed, or there must be a way to associate > > >> >the per-ES routes and per-EVI routes from the same PE. > > >> > > > >> >There is an easy solution to the latter, which was presented in > > >>Yokohama > > >> >(https://www.ietf.org/proceedings/94/slides/slides-94-bess-1.pdf). > > That > > >> >does require a beefed up requirement: the routes from the same PE > > >> >MUST have the same global admin field in the RDs. That should be > > >> >reasonable, and RFC already uses RECOMMEND keyword: > > >> > > > >> >7.9. Route Distinguisher Assignment per MAC-VRF > > >> > > > >> > The Route Distinguisher (RD) MUST be set to the RD of the MAC-VRF > > >> > that is advertising the NLRI. An RD MUST be assigned for a given > > >> > MAC-VRF on a PE. This RD MUST be unique across all MAC-VRFs on > > >> > a > > >>PE. > > >> > It is RECOMMENDED to use the Type 1 RD [RFC4364]. The value field > > >> > comprises an IP address of the PE (typically, the loopback address) > > >> > followed by a number unique to the PE. > > >> > > > >> >Notice the "RECOMMEND" in the above paragraph. > > >> > > > >> >8.4.1. Constructing Ethernet A-D per EVPN Instance Route > > >> > ... > > >> > The Route Distinguisher (RD) MUST be set per Section 7.9. > > >> > > > >> >8.2.1. Constructing Ethernet A-D per Ethernet Segment Route > > >> > ... > > >> > The Route Distinguisher (RD) MUST be a Type 1 RD [RFC4364]. The > > >> > value field comprises an IP address of the PE (typically, the > > >> > loopback address) followed by a number unique to the PE. > > >> > > > >> >As long as 8.4.1 or 7.9 says Type 1 RD MUST be used, then all the > > >> >problems are solved. While RFC 7432 did not use MUST, I doubt > > >> >there is any implementation not using a Type 1 RD for the per-EVI route. > > >> > > > >> >Jeffrey > > >> > > > >> >_______________________________________________ > > >> >BESS mailing list > > >> >BESS@ietf.org > > >> >https://www.ietf.org/mailman/listinfo/bess > > > > > _______________________________________________ > BESS mailing list > BESS@ietf.org > https://www.ietf.org/mailman/listinfo/bess _______________________________________________ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
