Hi Jeffrey, On 6/14/16, 2:44 AM, "Jeffrey (Zhaohui) Zhang" <[email protected]> wrote:
>Hi Ali, > >> -----Original Message----- >> From: Ali Sajassi (sajassi) [mailto:[email protected]] >> Sent: Monday, June 13, 2016 11:01 PM >> To: Jeffrey (Zhaohui) Zhang <[email protected]>; [email protected] >> Cc: Ali Sajassi (sajassi) <[email protected]> >> 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).” > >> >> 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 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" >> <[email protected] on behalf of [email protected]> 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 >> >[email protected] >> >https://www.ietf.org/mailman/listinfo/bess > _______________________________________________ BESS mailing list [email protected] https://www.ietf.org/mailman/listinfo/bess
