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. > > 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. > > 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. 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
