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
