Multi-homing in EVPN with Inter-AS Option B

Inter-AS Option B: This is described in Section 10.b of EAD-per-ES: Ethernet A-D per Ethernet Segment Route. EAD-per-EVI: Ethernet A-D per EVPN Instance Route. EAD: EVPN Type 1 route: Ethernet Auto-discovery Route. Either an EAD-per-ES or an EAD-per-EVI route. Type 2/5: either the EVPN Type 2 route: MAC/IP Advertisement Route or the EVPN Type 5 route: IP Prefix Route described in . Mass Withdraw: To withdraw the route from the forwarding table. For example, a MAC route that is mass withdrawn remains in the BGP table. The MAC route is required for directing packets with the specified MAC destination address to a matching backup or alias route. When a MAC route is completely withdrawn, then the matching backup or alias routes can no longer be used for the given MAC address. The withdrawal of an EAD-per-ES route will cause the mass withdrawal of associated Type 2/5 routes as well as associated EAD-per-EVI routes.

Inter-AS Option B is illustrated in Figure 1.

Traffic flow is from CE2 to CE1 where PE3 is an imposition PE, and PE1 and PE2 are disposition PEs. In a multi-homing scenario, the router that performs the redundancy switchover or the load balancing (e.g. PE3) must know which router originated the Ethernet A-D routes. These redundancy functions are normally implemented on a PE, but not on an ASBR. Quote from : "A remote PE that receives a MAC/IP Advertisement route with a non-reserved ESI SHOULD consider the advertised MAC address to be reachable via all PEs that have advertised reachability to that MAC address's EVI/ES via the combination of an Ethernet A-D per EVI route for that EVI/ES (and Ethernet tag, if applicable) AND Ethernet A-D per ES routes for that ES." In the Intra-AS case, the remote PE identifies the "PEs that have advertised reachability" by the next-hops of the Ethernet A-D routes. In the Inter-AS option B case, ASBR1 and ASBR2 rewrite the next-hops to themselves on all EVPN route advertisements, thus losing the identity of the PE that originated an advertisement. As a result, PE3 is unable to distinguish an EAD-per-ES route that originated at PE1 from one that originated at PE2.

The Tunnel Encapsulation Attribute is specified in . A new TLV to identify the PE of Origin is specified here. It is called PEO. The tunnel type for the PEO (suggested value 15) is to be assigned by IANA. The PEO MUST contain the Remote Endpoint Sub-TLV. The PEO must be able to uniquely identify the PE of origin within all ASes that participate in an EVPN instance. If a BGP speaker, such as a route reflector or an ASBR, is about to re-advertise a Type 2/5 or EAD route that does not have a PEO, and will change the next-hop of that route, then it MUST add one by putting the received next-hop into the Remote Endpoint Sub-TLV of the PEO. This will ensure that all originating EVPN routes carry the necessary information for imposition PEs to function properly for aliasing and mass withdraw. Any router that re-advertises a route that contains a PEO may modify some TLVs in the Tunnel Encapsulation Attribute attribute. However, it MUST keep the PEO unchanged. Examples are ASBR1 and ASBR2 in Figure 1.

For an inter-AS option B scenario, when a PE receives EVPN route(s) with PEO from an ASBR, then everything works per specification including both aliasing function and mass withdraw. i.e., the imposition PE (e.g., PE3) can process mass withdraw messages (Ethernet A-D per ES route). However, if a PE receives EVPN route(s) without a PEO from an ASBR, then the mass withdraw function operates in a degenerate mode where only Ethernet A-D per EVI route can be processed (for its corresponding MAC-VRF) but not Ethernet A-D per ES route (corresponding to all the impacted MAC-VRFs). The following sections detail the procedures associated with PEO processing.

When routes are being compared, they must exist in the same MAC-VRF and have the same non-reserved ESI. In addition, when Type 2/5 routes and EAD-per-EVI routes are being compared, they must have the same Ethernet Tag. Type 2/5 routes with ESI==0 do not use mass withdrawal or aliasing.

If all Type 2/5 and EAD routes have a PEO, then "PEs that have advertised reachability" can be identified by the PEO and the procedures of can be applied without modification.

The routes that have a PEO are handled as per the previous section. The routes that do not have a PEO need the following procedures. Type 2/5 routes without a PEO and EAD-per-EVI routes without a PEO are valid if at least one EAD-per-ES route without a PEO exists with the same next-hop. In other words: if multiple EAD-per-ES routes with the same next-hop as a Type 2/5 route exist, then the Type 2/5 route will only be mass withdrawn once all of the EAD-per-ES routes are withdrawn. This rule is necessary, because a BGP speaker may serve dual roles as ASBR and PE [Editorial note: If it is determined that no BGP speakers exist that do not normally follow the procedures in this document (Legacy speakers) then the following sub sections may be omitted] If an EAD-per-EVI route without a PEO is withdrawn, it will mass withdraw all Type 2/5 routes without a PEO that have the same next-hop and the same RD as the EAD-per-EVI route. This is called mass-withdraw per EVI. Note, it is not the absence of the EAD-per-EVI route that causes mass-withdrawal, but the actual withdrawal itself. If the route was never there to begin with, then no withdrawal took place. If any entity in the network rewrites an RD, then all entities must rewrite the RD in a consistent manner, such that routes with the same RD continue to have the same RD and routes with different RDs continue to have different RDs. Note that if this condition is violated, then other network functions would also break.

If a Type 2/5 route exists without a PEO and an EAD-per-EVI route exists with a PEO and it has the same next-hop and the same RD as the Type 2/5 route, then the Type 2/5 route shall inherit the PEO from the EAD-per-EVI route. Thereafter, section 5.2 applies.

TBD

A Tunnel Encapsulation Attribute Tunnel Type for the PEO is required.

Thanks to Kiran Pillai, Patrice Brissette, Satya Mohanty and Keyur Patel for careful review and suggestions.

[Note to RFC editor: This appendix to be removed before publication]

The Extended Community to use must be transitive and either IPv4 Specific or IPv6 Specific as described in . Thus, if it is IPv4 Specific, it will be of type 0x41 and if IPv6 Specific, it will be of type 0x40. The extended community will hold the IP address of the PE that originates the EVPN routes.

A PE can be uniquely identified by its BGP identifier (also called Router ID) and its AS number. A Large Community is a 4-octet AS specific extended community with a 6 octet local administrator field. The local administrator field should carry the BGP identifier.

It may be possible to associate the EAD-per-ES route with the Type 2/5 route by matching the Administrator Subfield of the RD. However, there are too many constraints that need to be met to make this method reliable. Basically, the RD was emphatically designed to distinguish routes, not to identify them. The constraints that need to be met are: The RD MUST by of Type 1. recommends Type 1, but does not mandate it. The Administrator subfield of the RD MUST be the same for each of these routes originated by one PE. does not require this. It just says "The value field comprises an IP address of the PE", but does not say that it must be the same IP address for all. In an IPv6 only scenario, other ways will be used to assign RD. The Administrator subfield of the RD MUST be unique among all PEs participating in the Inter-AS EVPN. This is likely, but not guaranteed. If RDs are rewritten at AS boundaries, then the Administrator subfield MUST be rewritten in a consistent way such as to preserve the above properties. By allowing a single EAD-per-ES route to validate all EAD-per-EVI routes and all Type 2/5 routes, some of those routes may be falsely validated. However that is the best possible outcome without a PEO. It is transient until the Type 2/5 route can be withdrawn. The possibility of the address space of PE next-hops in one AS overlapping that of another AS was raised. In such a case, the IP address of a PE in one AS may be the same as the IP address of a different PE in another AS. Because an ASBR overwrites next-hops, this can work. The PEO contains both the ASN as well as the IP address of the originating PE, so this works too. However, EVPN route types 3 and 4 contain only the originating router's IP address, but not the originating router's ASN. Therefore, EVPN route types 3 and 4 may also need a PEO. The possibility of making the EAD-per-EVI route mandatory was raised. This would make some of the procedures easier, because the RD of the EAD-per-EVI route can be matched with the RD of the Type 2/5 route