Inter Domain considerations for Constrained Route distribution

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here.

Section 3.1 and 3.2 describes respectively inter-AS and intra-AS VPN route distribution and distinguish two types of Route Target Membership NLRIs (RT NLRIs): Locally originated NLRI where origin-as field of the NLRI is equal to the local AS number. External NLRI where origin-as field of the NLRI is different from the local AS number. When the mechanism detailed in is in place, inter AS VPN route propagation happens only on the shortest path towards the peer ASes by pruning of some branches of the distribution tree. Existing implementations of exhibit two flavors of pruning for interAS that are both compatible with . Pruning based on peering type: pruning is applied when RT membership path are learned from eBGP peers only. No pruning is applied when path is iBGP. The pruning applies regardless of the RT NLRI (locally originated or external). Pruning based on NLRI type: pruning is applied to external RT NLRIs (source AS different from local AS). This pruning rule applies both to eBGP and iBGP. These different approaches in pruning can lead to different VPN route distribution behaviors as highlighted in the following example.

AS 1 AS 2 | ASBR11 --- (mpebgp vpnv4+rtc) ----+ | \ | \ ASBR12 --- (mpebgp vpnv4+rtc) ---- ASBR21 | \ PE11 | (mpibgp vpnv4+rtc) | \ | RR -------- PE12 | / | (mpibgp vpnv4+rtc) | / ASBR13 --- (mpebgp vpnv4+rtc) --- ASBR22 | | An example is provided in . ASBR11, ASBR12 and ASBR13 are part of the AS1. We consider that all PE11 and PE12 are interested in an any-to-any VPN using RT 65535:10. All ASBRs will generate and advertise the same RT NLRI 1:65335:10/96 towards ASBR21/22. When implementation uses peering type based pruning: as ASBR21 has two ebgp paths for 1:65535:10/96, only the best path (ASBR11) will be picked up as a branch of the VPN route distribution tree because the RT NLRI is received over eBGP. However, RR in AS2 has two paths for 1:65535:10/96, one from ASBR21, one from ASBR22. Because the paths are iBGP, RR considers all paths as branches of the VPN distribution tree. As a consequence, VPN routes from PE12 will be distributed to ASBR21 and ASBR22. In AS1, ASBR11 and ASBR13 will receive the routes. When implementation uses NLRI type based pruning: as ASBR21 has two ebgp paths for 1:65535:10/96, only the best path (ASBR11) will be picked up as a branch of the VPN route distribution tree because the RT NLRI is an external RT NLRI. Similarly, RR in AS2 has two paths for 1:65535:10/96, one from ASBR21, one from ASBR22. Because the NLRI is an external RT NLRI, RR selects also only the best path (e.g.: ASBR21) as a branch of the VPN distribution tree. As a consequence, VPN routes from PE12 will be distributed to ASBR21 only. In AS1, only ASBR11 will receive the routes.

The current model of distribution of VPN routes across ASes when RT membership is advertising is optimizing the number of VPN route states to be maintained on nodes. While this is a good goal, this may lead to some limitations/issues in some scenarios.

AS65000 | AS 1 | +-------+ | DC1 | -- CE1 -- (mpebgp vpnv4+rtc) -- PE1 +-------+ \ (mpibgp vpnv4+rtc) \ RR / (mpibgp vpnv4+rtc) +-------+ / | DC2 | -- CE2 -- (mpebgp vpnv4+rtc) -- PE2 +-------+ | | +-------+ | | DC3 | -- CE3 -- (mpebgp vpnv4+rtc) ----+ +-------+ | | presents a scenario where datacenters are connected through MPLS VPN inter-AS option B to a service provider network. RT membership is distributed to optimize distribution of VPN routes. In this scenario, all datacenters are using the same AS number, generally a private ASN (65000). As we expect DCs to communicate between each other, some features like "as-override" are deployed on PEs to overcome ASPATH loop issue. CE1, CE2 and CE3 are advertising RT 1:1 respectively to PE1 and PE2, the generated NLRI would be 65000:1:1/96. According to procedures defined in Section 3.2, both PEs are using the standard BGP route selection and advertisement rules. PE2 has two paths for RT NLRI 65000:1:1/96, picks one as best (e.g.: CE2) and advertises it to the route-reflector. PE1 advertises its path learned from CE1 to the RR. RR in AS1 has two paths for 65000:1:1/96 and will pick one as best (e.g.: path from PE1). The VPN route distribution tree will be established to PE1 only, PE2 will never get VPN routes for RT 1:1. However, even if RR1 picked up PE2 has best path, because PE2 picked up CE2 as best path, CE3 will have never received VPN routes for RT 1:1.

In , a VPN route Pv with RT 65335:10 from PE12 is distributed only to ASBR11 by RR in AS2. In AS1, PE11 has a single path to reach Pv. If ASBR11 fails, BGP convergence should occur to provide a new path to PE12: ASBR21 detects the failure of ASBR11 and picks up a new best path for RT 1:65335:10/96 through ASBR12. ASBR21 sends Pv to ASBR12. ASBR12 sends Pv to PE11. This convergence process could be very slow in high scale scenarios, thus not fitting the service level agreements that the service provider maintains.

In , a VPN route Pv with RT 65335:10 from PE12 is distributed only to ASBR11 by RR in AS2. In AS1, PE11 has a single path to reach Pv from ASBR11. However, from a geographical point of view, ASBR11 may not be the best option for PE11 to reach PE12 (ASBR13 may provide a better end-to-end path). PE11 doesn't have the ability to pick the best path to Pv from its point of view.

This document proposes an alternative to the default behavior proposed by for inter-AS VPN route distribution. Any alternate behavior SHOULD consider multiple paths for an external RT NLRI among the ones available to solve the limitations highlighted in this document. Implementations MAY propose one or more alternate behaviors to balance between adding more VPN routes states within the network and solving the limitations highlighted in this document. As examples: An implementation MAY support the ability to consider all paths for external RT NLRIs as eligible to be part of the VPN route distribution tree regardless of the origin-as. Thus, all VPN routes will be propagated other all possible distribution paths. An implementation MAY support the ability to consider all paths for external RT NLRIs as eligible to be part of the VPN route distribution tree for only a subset of origin-as (e.g.: configured list of ASes, or all private ASes...). Thus, VPN routes will be propagated other all possible distribution paths only for a subset of destination ASes. An implementation MAY support the ability to consider the best and second best paths for external RT NLRIs as eligible to be part of the VPN route distribution tree regardless of the origin-as. This would allow to provide at least one alternate path for VPN routes in the destination ASes.

Enabling alternate behaviors in consideration of external RT NLRIs that deviate from the default behavior specified in may have operational implications as VPN routes may be distributed across additional paths leading to increase of BGP prefixes and paths on some devices. Users must carefully evaluate the impact of these changes on their network/router scale. Choosing the intended behavior for considering paths of external RT NLRIs is a local decision. Different nodes can use different behaviors without breaking the overall functionality of the VPN: alternate behaviors are adding paths for the VPN routes. However, in order to overcome the limitations of presented in , it is important to ensure that all nodes that are participating to the VPN route distribution (e.g.: RRs, ASBRs...) are configured with a behavior that fulfills the propagation requirements.

This document does not introduce any new security issue compared to .

Authors would like to thank Aravind Kumar Paramasivam for the useful comments and review.

There is no IANA consideration.