Signaling AFI-SAFI scope for Constrained Route Distribution

A VPN route (such as VPNv4/VPNv6 unicast , Multicast VPN , Layer 2 VPN , Flow-spec , etc.) is retained by a BGP speaker only if the route is of interest to itself - e.g., if the route belongs to a local VPN, or if it needs to be sent to one of its neighbors. The VPN membership of a route is determined by the set of route target (RT) extended communities attached to the route. Therefore the speaker's neighbors need to send only those routes to the speaker that carry one or more RTs that are of interest to the speaker. defines a new address family called Route Target Constrain (RTC) using which a BGP speaker can signal its neighbors the set of RTs it is interested in. For instance, if one of speaker A's locally configured VPNs is a member of RT:1:1 (i.e., if a local VRF imports RT:1:1), then speaker A advertises an RTC NLRI with RT:1:1 to speaker B. In turn speaker B sends to speaker A only the VPN routes with RT:1:1. extends the NLRI definition to accommodate longer IPv6 Specific Route Target extended communities . The scope of an RTC NLRI RT:X:Y spans all address family routes with RT:X:Y. This design choice makes RTC a standard route filtering mechanism for all BGP based VPN solutions. On the flip side, RTC can deliver optimal filtering only when the set of RTs used by an address family afi=x/safi=y is disjoint from the set of RTs used by any other address family afi=z/safi=w. The following section illustrates some of the problems when shared RTs are used.

| | ------------> | | |export RT:1:1| | VPNv4 unicast +---+ VPNv4 unicast | | +-------------+---+ VPNv6 unicast VPNv6 unicast +---+ ]]> Suppose speaker A has local VPNv4 unicast and VPNv6 unicast routes, both with membership in RT:1:1. Speaker B is a route-reflector with client speaker C. Speaker C only needs VPNv4 unicast routes with RT:1:1 for its VPN with membership in RT:1:1. Speaker C sends an RTC NLRI RT:1:1 to speaker B and speaker B in turn sends an RTC NLRI RT:1:1 to speaker A. Spearker A sends its VPNv4 unicast and VPNv6 unicast routes with RT:1:1 to speaker B. Speaker B retains routes from both address families and sends all of them to speaker C. Speaker C retains only the VPNv4 unicast routes and drops VPNv6 unicast routes. In this deployment, advertisement of VPNv6 unicast routes are not needed, but they are still advertised. Second, speaker B (the route-reflector) does not need to retain any VPNv6 unicast route since its only client, speaker C, does not need them. But speaker B still retains the VPNv6 unicast routes. Therefore, route constrain does not lead to optimal route filtering.

In the deployment shown in , in steady state speaker C retains the VPNv4 unicast routes for RT:1:1 and speaker B has an RTC NLRI path for RT:1:1 from speaker C. Now suppose the operator adds a new IPv6 VRF on speaker C that imports RT:1:1 depicted in . Now speaker C needs to get the VPNv6 unicast routes from speaker B with RT:1:1. At this point, if speaker C advertises the RTC NLRI RT:1:1 to speaker B again, speaker B would receive an identical path from speaker C. Standard BGP implementation practice is to ignore identical updates (i.e., not mark the local prefix for further processing), in which case speaker B will not send the VPN routes to speaker C again. Thus, speaker C would need to send a route refresh message to speaker B and receive all VPNv6 routes (this set of routes is larger than necessary if RT:1:1 is not the first RT imported by an IPv6 VRF on speaker C). There are possible implementation tricks to get around this issue (e.g., readvertise the RTC NLRI RT:1:1 from speaker C after changing an attribute such as local-preference). However, a standardized solution without possible side-effects is much more preferable.

Not using shared RTs by ensuring that the set of RTs used by one address family is disjoint from the set of RTs used by any other address family avoids the problems. However, this constraint poses a burden on the network operation, especially in large networks that are run by multiple loosely coupled departments, where configurations change frequently. Therefore, a protocol level solution is more preferable.

proposes a new NLRI format that includes the safi value (among other fields) and use different afi values during capability negotiations. This is not a backward compatible solution. Given many existing (large) deployments of based multi-vendor networks, backward compatibility is necessary. In addition, solves the IPv6 specific RT issue in a backward compatible manner that addresses.

The list of afi-safi that a speaker needs in the scope for a given RT can be carried in the path attribute of the RTC NLRI. This approach does not require any change in the NLRI format as the new information is not carried in the NLRI making the approach backward compatible. In addition, RTC being a hop-by-hop technique by nature, best path selection done on, say, a route-reflector, does not lead to missing information. In this document, we adopt this approach which leads to a light-weight, backward compatible solution. In addition, if the policy language supported on the BGP speakers allow attaching arbitrary extended communities to a route, then the proposed solution can be deployed on edge routers (i.e., on leafs of the VPN distribution graph) even without any software upgrade. While one could define a new BGP path attribute to carry the list of afi-safi as the scope, use of communities suffices for the present purpose. Specifically, we propose using a new type of opaque extended community called AFI-SAFI extended community to encode each afi-safi pair that is of interest to the speaker and use multiple extended communities to form the list. Extended communities instead of standard communities are used since the latter are used widely by the providers for communicating internal information.

The AFI-SAFI Community is an Non-Transitive Opaque Extended Community (, ) defined as follows: The value of the high-order octet of the extended Type Field is 0x43, which indicates that it is non-transitive. The value of low-order octet of the extended type field for this community is TBD. The first 3 octets of the Value field contains two sub-fields, described below. The last 3 octets of the Value field are reserved. The originator of an AFi-SAFI community must set the reserved octets to 0, and a receiver of an AFi-SAFI community must ignore the reserved octets.

We denote an AFI-SAFI extended community with Address Family Identifier field x and Subsequent Address Family Identifier field y as AFI-SAFI-EC:(x/y). A route carrying AFI-SAFI-EC:(x/y) implies that the route is correlated to the address family with index x/y. The route itself may belong to a different address family. The semantics of the correlation is context dependent. This document defines the correlation sematics for route constrain routes carrying AFI-SAFI-EC.

Suppose BGP speakers A and B have negotiated route constrain capability. Speaker A receives an RTC NLRI RT:X:Y from speaker B with set S of AFI-SAFI-EC attached. We define the following semantics: If S is empty, then speaker A SHOULD send all otherwise eligible routes from all address families to speaker B. If S is nonempty, then speaker A SHOULD send an otherwise eligible AFI=x/SAFI=y route with RT:X:Y to speaker B ONLY if S contains AFI-SAFI-EC:(x/y). Suppose speaker A has RTC route RT:X:Y with path i with AFI-SAFI-EC set S_i, for i=1..n. If all S_i are nonempty, then speaker A attaches AFI-SAFI-EC set S to RTC NLRI RT:X:Y that it advertises to its neighbors, where S is the union of S_i, i=1..n. If there is an empty S_i, then speaker A does not attach any AFI-SAFI-EC to RTC NLRI RT:X:Y that it advertises to its neighbors. The essential idea is to treat an RTC NLRI path with no AFI-SAFI-EC attached as a path with AFI-SAFI-EC for all address families attached. We illustrate the rules with a couple of examples shown in and .

| | | VPNv6 +---+ | | RTC:1:1 RTC:1:1 v EC: 1/128 +-------+ (No AFI-SAFI extcomm) +---+ EC: 2/128 +---+ | VPNv4 | <---------------------- | |<------------ | | | VPNv6 +-------------------------+ B +--------------+ D | | MVPN | ----------------------> | |------------->| | +-------+ VPNv4, VPNv6, MVPN +---+ VPNv4, VPNv6 +---+ Router A ^ | | RTC:1:1 |(No AFI-SAFI EC)+---+ | <------------- | | +----------------+ E | -------------> | | VPNv4, VPNv6, MVPN +---+ ]]> In , speaker B receives RTC NLRI RT:1:1 from neighbors C, D and E. Neighbor C attaches AFI-SAFI-EC:(2/128) and neighbor D attaches AFI-SAFI-EC:(1/128) and AFI-SAFI-EC:(2/128). Neighbor E does not attach any AFI-SAFI-EC to its route. From the received set of AFI-SAFI-EC, speaker B knows that among all the routes with RT:1:1, speaker C needs only VPNv6 unicast routes and speaker D needs only VPNv4 unicast and VPNv6 unicast routes. However, speaker B does not know which address family routes node E needs. Therefore, speaker B must request routes with RT:1:1 for all address families (whose capabilities have been negotiated) from its neighbors. So speaker B advertises RTC NLRI RT:1:1 to speaker A with no AFI-SAFI-EC. Speaker A has VPNv4 unicast, VPNv6 uncast and MVPN routes with RT:1:1 that are eligible for sending to speaker B. Speaker A sends all those routes to speaker B. Speaker B now has VPNv4 unicast, VPNv6 uncast and MVPN routes with RT:1:1 that are eligible for sending to neighbors C, D and E. Among those routes, speaker B sends only the VPNv6 unicast routes to neighbor C, VPNv4 unicast and VPNv6 unicast routes to neighbor D and VPNv4 unicast, VPNv6 unicast and MVPN (i.e., all) routes to neighbor E. If speaker E actually only needs VPNv4 unicast routes, it would drop the VPNv6 unicast and MVPN routes it receives from speaker B for RT 1:1. This sub-optimal behavior improves when speaker E also uses AFI-SAFI-EC to signal the scope for RT:1:1 and the "island" of contiguous AFI-SAFI-EC users expands.

| | | VPNv6 +---+ | | RTC:1:1 RTC:1:1 v EC: 1/128 +-------+ EC: 1/128, EC: 2/128 +---+ EC: 2/128 +---+ | VPNv4 | <---------------------- | |<------------ | | | VPNv6 +-------------------------+ B +--------------+ D | | MVPN | ----------------------> | |------------->| | +-------+ VPNv4, VPNv6 +---+ VPNv4, VPNv6 +---+ Router A ^ | | RTC:1:1 | EC: 1/128 +---+ | <------------- | | +----------------+ E | -------------> | | VPNv4 +---+ ]]> In , speaker B receives RTC NLRI RT:1:1 from neighbors C, D and E. Neighbor C attaches AFI-SAFI-EC:(2/128), neighbor D attaches AFI-SAFI-EC:(1/128) and AFI-SAFI-EC:(2/128), and neighbor E attaches AFI-SAFI-EC:(1/128). From the received set of AFI-SAFI-EC, speaker B knows that among all routes with RT:1:1, speaker C needs only VPNv6 unicast routes, speaker D needs only VPNv4 unicast and VPNv6 unicast routes, and speaker E needs only VPNv4 unicast routes. Speaker B advertises RTC NLRI RT:1:1 to speaker A with AFI-SAFI-EC:(1/128) and AFI-SAFI-EC:(2/128), which is the union of all AFI-SAFI-EC from all paths of the RTC NLRI. Speaker A therefore sends only VPNv4 unicast and VPNv6 unicast routes speaker B. Among those routes with RT:1:1 that speaker B has, speaker B sends only the VPNv6 unicast routes to neighbor C, VPNv4 unicast and VPNv6 unicast routes to neighbor D and only VPNv4 unicast routes to neighbor E. Therefore, when all speakers use AFI-SAFI-EC, optimal route filtering is restored even in shared RT deployments.

This document requests assignment of a codepoint from the Non-Transitive Opaque Extended Community Sub-Types registry for AFI-SAFI extended community.

This section is structured as recommended in .

TBD.

Procedures and protocol extensions defined in this document do not affect the BGP security model. See the 'Security Considerations' section of for a discussion of BGP security. Also refer to and for analysis of security issues for BGP.

TBD.