BGP Colorful Prefix Routing (CPR) for SRv6 based Services

With the trend of using one common network to carry multiple types of services, each service type can have different requirements on the network. Such requirements are usually considered as the "intent" of the service or customer, and is represented as an abstract notion called "color". In network scenarios where the services are delivered across multiple network domains, there is need to provide the services with different end-to-end paths to meet the intent. describes the problem statements and requirements for inter-domain intent aware routing. The inter-domain path can be established using either MPLS or IP data plane. In MPLS based networks, the traditional inter-domain approach is to establish an end-to-end LSP based on the BGP-LU mechanisms as defined in . Each domain or area border node needs to perform label swapping for the end-to-end BGP-LU LSP, and encapsulate the label stack which are used for the intra-domain LSP within the subsequent network domain or area. While in IP based networks, IP reachability information can be advertised to network nodes in different domains using BGP, so that all the domain or area border nodes have the routes to the prefixes of the destination node in other domains. With the introduction of SRv6 , services are assigned with SRv6 Service SIDs , which are routable in the network according to its Locator prefix. Thus the inter-domain path can be established simply based on the inter-domain prefix routes, and the BGP-LU based LSP is not necessary in IPv6 and SRv6 based networks. This document describes a mechanism to advertise different IPv6 prefixes of a node with different color attributes to establish end-to-end intent aware paths. Such IPv6 prefixes are called "colorful prefixes", and this mechanism is called Colorful Prefix Routing (CPR). The colorful prefixes are used as the SRv6 locators associated with different intent. SRv6 services (e.g. SRv6 VPN services) could be assigned with SRv6 SIDs under the SRv6 locator prefix according to the required intent, so that the SRv6 service traffic can be steered using the end-to-end intent aware paths of the corresponding SRv6 locator prefix to meet the service requirement. The existing IPv6 unicast Address Family could be used for the advertisement of colorful prefixes, which makes this mechanism easy to interoperate and helps the incremental deployment in multi domain networks.

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.

This section describes the BGP CPR mechanisms. More specifically, section 2.1 describes the allocation of the colorful IP prefixes, section 2.2 describes the advertisement of colorful prefixes in BGP, section 2.3 describes the resolution of CPR routes to the intra-domain paths, and section 2.4 describes the steering of SRv6 services to CPR routes.

In SRv6 networks, an SRv6 Locator needs to be allocated for each node. In order to distinguish N different intent, a PE node needs to be allocated with N SRv6 Locators, each of which is associated a different intent. This can be achieved by splitting the base SRv6 locator of the node into N sub-locators, and these sub-locators are called colorful locators. For example, node PE2 is allocated with the base SRv6 Locator 2001:db8:aaaa:1::/64. In order to provide 16 different intent, this base SRv6 Locator is split into 16 sub-locators from 2001:db8:aaaa:1:0000::/68 to 2001:db8:aaaa:1:F000::/68, each of these sub-locators is associated with a different intent, such as low-delay, high-bandwidth, etc.

After the allocation of colorful locator prefixes on a PE node, routes to these colorful locators need to be advertised both in the local domain and also to other domains using BGP, so that the SRv6 services route could be resolved using the corresponding CPR route. BGP IPv6 unicast Address Family/Subsequent Address Family (AFI/SAFI = 2/1) is used for the advertisement of the colorful prefix routes. The procedure of colorful prefix advertisement is described using an example with the following topology:

Assume PE3 is provisioned with two different colorful locator prefixes CLP-1 and CLP-2 for two different intent such as "low-delay" and "high-bandwidth" respectively. The color for "low-delay" in AS1, AS2 and AS3 are C11, C21 and C31 respectively, and the color for "high-bandwidth" in AS1, AS2 and AS3 are C12, C22 and C32 respectively. which are represented as color C11 and C12 respectively in domain AS1. PE3 originates BGP IPv6 unicast (AFI/SAFI=2/1) route for the colorful locator prefixes PE3:CL1:: and PE3:CL2::. Each route SHOULD carry the corresponding color extended community C31 or C32. PE3 also advertise a route for the base SRv6 Locator prefix PE3:BL, there is no color extended community carried with this route. ASBR31 and ASBR32 receive the CPR routes of PE3, and advertise the CPR routes further to ASBR23 and ASBR24 with next-hop set to itself. ASBR23 and ASBR24 receive the CPR routes of PE3. As the color-to-intent mapping in AS2 is different from AS3, the color in the received CPR routes are changed to the corresponding color in AS2, e.g. C21 and C22. ASBR23 and ASBR 24 advertise the CPR routes further in AS2 with the next-hop set to itself. The behavior of ASBR21 and ASBR22 are similar to the behavior of ASBR31 and ASBR32. The behavior of ASBR11 and ASBR12 are similar to behavior of ASBR31 and ASBR32. The color in the received CPR routes are changed to the corresponding color in AS1, e.g. C11 and C12.

For a node which receives a CPR route, it SHOULD resolves the CPR routes to an intra-domain color-aware path based on the tupple (N, C), where N is the next-hop of the CPR route, and C is the color extended community of the CPR route. The intra-domain color aware path could be built with any of the following mechanisms: SRv6 or SR-MPLS Policy SRv6 or SR-MPLS Flex-Algo RSVP-TE For example, PE1 receives a CPR route to PE3:CL1 with color C31 and next-hop ASBR11, it will resolve the CPR routes to an intra-domain SRv6 Policy based on the tupple (ASBR11, C31). The intra-domain path resolution scheme could be based on any existing tunnel resolution policy, and new tunnel resolution mechanisms could also be introduced if needed.

For an SRv6 service which is associated with a specific intent, the SRv6 Service SID MUST be allocated under the corresponding colorful locator prefix. For example, on PE3 in the example topology, an SRv6 VPN service with the low delay intent can be allocated with an SRv6 End.DT4 SID 2001:db8:aaaa:1:1000::0100, where 2001:db8:aaaa:1:1000::/68 is the SRv6 Colorful Locator for low delay service. The SRv6 Service SIDs SHOULD be advertised using the mechanism defined in . Inter-domain VPN Option C is used, which means the next-hop of the SRv6 service route is set to the originating PE and not changed. Since the intent of the service is embedded in the SRv6 service SID, the SRv6 service route does not need to carry color extended community.

On an ingress PE node which receives a SRv6 service route, it SHOULD follow the behavior of SRv6 BE forwarding and use the SRv6 Service SID in the service route for route iteration. If the corresponding CPR route has been received and installed, the service route can be iterated and match with the to the CPR route, and the intra-domain color-aware path which the CPR route is resolved to will be used for the forwarding of the service traffic.

This section describes the encapsulation and forwarding process of data packets which are matched with the corresponding CPR route.

Following is an illustration of the packet encapsulation and forwarding process of CPR over SRv6 Policy. The abstract representation of IPv6 and SRH in section 6 of is used. PE3 is provisioned with a colorful locator prefix PE3:C1 for "low-delay". In AS1, the SRv6 Policy for (ASBR11, C11) is represented with SID list (PE1, P1, BR11). In AS2, the SRv6 Policy for (ASBR23, C21) is represented with the SID list (BR21, P2, BR23). In AS3, the SRv6 Policy for (PE3, C31) is represented with the SID list (BR31, P3, PE3). For packets which belong to an SRv6 VPN service associated with the SRv6 Service SID PE3:CL1.DT, the packet encapsulation and forwarding process is shown as below:

P1 : (PE1, P1)(PE3:CL1.DT, BR11; SL=2)(C-pkt) P1 ->BR11: (PE1, BR11)(PE3:CL1.DT, BR11; SL=1)(C-pkt) BR11->BR21: (PE1, PE3:CL1.DT)(C-pkt) BR21->P2 : (PE1, P2)(PE3:CL1.DT, BR23; SL=2)(C-pkt) P2 ->BR23: (PE1, BR23)(PE3:CL1.DT, BR23; SL=1)(C-pkt) BR23->BR31: (PE1, PE3:CL1.DT)(C-pkt) BR31->P3 : (PE1, P3)(PE3:CL1.DT, PE3; SL=2)(C-pkt) P3 ->PE3 : (PE1, PE3)(PE3:CL1.DT, PE3; SL=1)(C-pkt) ]]> In some network domains, SRv6 Flex-Algo may be used to provide intent aware intra-domain path. The encapsulation is similar to the case with SRv6 Policy.

It is possible that some of the domains are still using MPLS based data plane. In these domains, A CPR route can be resolved over a color-aware intra-domain MPLS LSP. Such intra-domain MPLS LSP MAY be established using SR-MPLS Policy, SR-MPLS Flex-Algo or RSVP-TE. The encapsulation and forwarding of SRv6 service packets over an intra-domain MPLS LSP is based on the MPLS mechanisms as defined in and . For packets which belong to an SRv6 VPN service associated with the SRv6 Service SID PE3:CL1.DT, the packet encapsulation and forwarding process is shown as below:

P1 : (Label-stack for PE1 to BR11) (PE1, PE3:CL1.DT)(C-pkt) P1 ->BR11: (Label-stack for PE1 to BR11) (PE1, PE3:CL1.DT)(C-pkt) BR11->BR21: (PE1, PE3:CL1.DT)(C-pkt) BR21->P2 : (Label-stack for BR21 to BR23)(PE1, PE3:CL1.DT)(C-pkt) P2 ->BR23: (Label-stack for BR21 to BR23)(PE1, PE3:CL1.DT)(C-pkt) BR23->BR31: (PE1, PE3:CL1.DT)(C-pkt) BR31->P3 : (Label-stack for BR31 to PE3) (PE1, PE3:CL1.DT)(C-pkt) P3 ->PE3 : (Label-stack for BR31 to PE3) (PE1, PE3:CL1.DT)(C-pkt) ]]>

Since the colorful locator prefixes are the sub-locators of the node's base SRv6 locator, the IPv6 unicast route of the base locator prefix is the covering prefix of all the colorful locator prefixes. To make sure the colorful locator prefixes can be distributed to the ingress PE nodes along the border nodes, it is required that route aggregation SHOULD be disabled for IPv6 unicast routes which carries the color extended community. All the border nodes and the ingress PE nodes SHOULD install the colorful locator prefixes into the RIB and FIB. For transit domains which support the CPR mechanism, the border nodes SHOULD use the tupple (N, C) for the resolution of the CPR routes to intent aware intra-domain paths. For transit domains which do not support this mechanism, the border nodes MAY resolve the CPR routes over a best effort intra-domain path to the next-hop N, while the CPR route will be advertised further to the downstream domains with only the next-hop changed to itself. This allows the CPR routes to be resolved to intent aware intra-domain paths in the downstream domains which support the CPR mechanism.

This document makes no request of IANA.

TBD

The authors would like to thank Shunwan Zhuang and Zhibo Hu for the review and discussion.