BGP Colorful Prefix Routing (CPR)
for SRv6 based ServicesHuawei TechnologiesChinarainsword.wang@huawei.comHuawei TechnologiesChinajie.dong@huawei.comHuawei TechnologiesChinaxiejingrong@huawei.comHuawei TechnologiesChinaifocus.chen@huawei.com
Routing Area
Interdomain Routing Working GroupThis document describes a mechanism to advertise different IPv6
prefixes which are associated with different color attributes to
establish end-to-end intent-aware paths for SRv6 services. Such IPv6
prefixes are called "Colorful Prefixes", and this mechanism is called
Colorful Prefix Routing (CPR). In SRv6 networks, the colorful prefixes
are the SRv6 locators associated with different intent. SRv6 services
(e.g. SRv6 VPN services) with specific intent could be assigned with
SRv6 SIDs under the corresponding SRv6 locators, which are advertised as
colorful prefixes. This allows the SRv6 service traffic to be steered
into end-to-end intent-aware paths simply based on the SRv6 Service
SIDs. The existing IPv6 Address Family could be used for the
advertisement of IPv6 colorful prefixes, thus this mechanism is easy to
interoperate and allows incremental deployment in multi-domain
networks.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, the 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 IP 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 SRv6 locator prefix. Thus the inter-domain path can be established
simply based on the inter-domain prefix routes, and the BGP-LU
inter-domain LSP mechanism is not necessary for IPv6 and SRv6 based
networks.This document describes a mechanism to advertise different IPv6
prefixes which are associated with different color attributes to
establish end-to-end intent-aware paths for SRv6 services. Such IPv6
prefixes are called "Colorful Prefixes", and this mechanism is called
Colorful Prefix Routing (CPR). In SRv6 networks, the colorful prefixes
are the SRv6 locators associated with different intent. SRv6 services
(e.g. SRv6 VPN services) with specific intent could be assigned with
SRv6 SIDs under the corresponding SRv6 locators, which are advertised as
colorful prefixes. This allows the SRv6 service traffic to be steered
into end-to-end intent-aware paths simply based on the SRv6 Service
SIDs. The existing IPv6 Address Family could be used for the
advertisement of IPv6 colorful prefixes, thus this mechanism is easy to
interoperate and allows incremental deployment in multi-domain
networks.This section describes the BGP CPR mechanisms. More specifically,
section 2.1 describes the allocation of the IPv6 colorful 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 prefixes on a PE node, routes to
these colorful prefixes need to be advertised both in the local domain
and also to other domains using BGP, so that the SRv6 services routes
could be resolved using the corresponding CPR route.In a multi-domain IPv6 network, the IPv6 unicast Address
Family/Subsequent Address Family (AFI/SAFI = 2/1) is used for the advertisement of the colorful
prefix routes. The color extended community
is carried with the colorful prefix route. The procedure of colorful
prefix advertisement is described using an example with the following
topology:Assume PE3 is provisioned with two different colorful prefixes
CLP-1 and CLP-2 for two different intent such as "low-delay" and
"high-bandwidth" respectively. Note that in different network domains,
the color representing the same intent may be different. In this
example, the color used for "low-delay" in AS1, AS2 and AS3 are C11,
C21 and C31 respectively, and the color used for "high-bandwidth" in
AS1, AS2 and AS3 are C12, C22 and C32 respectively.PE3 originates BGP IPv6 unicast (AFI/SAFI=2/1) route for the
colorful prefixes PE3:CL1:: and PE3:CL2::. Each route should carry
the corresponding color extended community C31 or C32. PE3 also
advertises a route for the base SRv6 Locator prefix PE3:BL, and
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.In network scenarios where some of the intermediate network
domains are MPLS based, the CPR routes may still be advertised using
the IPv6 unicast address family (AFI/SAFI=2/1) in the MPLS-based
intermediate domains, and at the MPLS domain border nodes, some route
resolution policy could be used to make the CPR routes resolved to
intra-domain intent-aware MPLS LSPs. Another possible mechanism is to
use the IPv6 Labeled Unicast address family (AFI/SAFI=2/4) to
advertise the CPR routes in the MPLS domains, the detailed procedure
is described in Section 7.1.2.1 of .A domain border node which receives a CPR route can resolve the CPR
route 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 PolicySRv6 or SR-MPLS Flex-AlgoRSVP-TEFor example, PE1 receives a CPR route to PE3:CL1 with color C31 and
next-hop ASBR11, it can 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 be introduced if needed.For an SRv6 service which is associated with a specific intent, the
SRv6 Service SID could 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 the SRv6
End.DT4 SID 2001:db8:aaaa:1:1000::0100, where
2001:db8:aaaa:1:1000::/68 is the SRv6 colorful prefix for low delay
service.The SRv6 service routes are advertised using the mechanism defined
in , the SRv6 Service SID is carried using the
BGP Prefix-SID attribute . The 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 the color extended community.With the CPR routing mechanism, the ingress PE node which receives
the SRv6 service routes follows the behavior of SRv6 best-effort
forwarding. The SRv6 service SID carried in the service route is used
as the destination address in the outer IPv6 header encapsulated to
the service packet. If the corresponding CPR route has been received
and installed, the SRv6 service SID can match with the colorful prefix
of the CPR route, then the intra-domain color-aware path which the CPR
route is resolved to is used for forwarding the SRv6 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 prefix PE3:C1 for
"low-delay".In AS1, the SRv6 Policy for (ASBR11, C11) is represented with SID
list (P1, BR11).In AS2, the SRv6 Policy for (ASBR23, C21) is represented with the
SID list (P2, BR23).In AS3, the SRv6 Policy for (PE3, C31) is represented with the SID
list (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: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.In network scenarios where some of the network domains use MPLS
based data plane, the 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 .In AS1, the SR-MPLS Policy for (ASBR11, C11) is represented with
Label-stack (P1, BR11).In AS2, the SR-MPLS Flex-Algo for (ASBR23, C21) is represented with
Label-stack (BR23).In AS3, the SR-MPLS Policy for (PE3, C31) is represented with
Label-stack (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:When the colorful prefixes are assigned as 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 be disabled for IPv6 unicast routes which carries the color
extended community.All the border nodes and the ingress PE nodes needs to install the
colorful locator prefixes into the RIB and FIB. For transit domains
which support the CPR mechanism, the border nodes can use the tupple (N,
C) to resolve the CPR routes to intent-aware intra-domain paths. For
transit domains which do not support the CPR mechanism, the border nodes
could 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 any
network domains which support the CPR mechanism, while can fall back to
resolve over best-effort intra-domain paths in the legacy network
domains.This document makes no request of IANA.The mechanism described in this document provide an approach for
inter-domain intent-aware routing based on existing BGP protocol
mechanisms. It does not introduces any additional security
considerations than those described in and
.The authors would like to thank Shunwan Zhuang and Zhibo Hu for the
review and discussion.