Internet-Draft BGP CPR for SRv6 Services July 2024
Wang, et al. Expires 2 January 2025 [Page]
Workgroup:
Interdomain Routing Working Group
Internet-Draft:
draft-ietf-idr-cpr-04
Published:
Intended Status:
Informational
Expires:
Authors:
H. Wang
Huawei Technologies
J. Dong
Huawei Technologies
K. Talaulikar
Cisco Systems
T. Han
Huawei Technologies
R. Chen
ZTE Corporation

BGP Colored Prefix Routing (CPR) for SRv6 based Services

Abstract

This document describes a mechanism to advertise IPv6 prefixes in BGP which are associated with Color Extended Communities to establish end-to-end intent-aware paths for Segment Routing over IPv6 (SRv6) services. Such IPv6 prefixes are called "Colored Prefixes", and this mechanism is called Colored Prefix Routing (CPR). In SRv6 networks, the Colored prefixes are the SRv6 locators associated with different intent. SRv6 services (e.g. SRv6 VPN services) with specific intent could be assigned with SRv6 Segment Identifiers (SIDs) under the corresponding SRv6 locators, which are advertised as Colored prefixes.

This operational methodology allows the SRv6 service traffic to be steered into end-to-end intent-aware paths simply based on the longest prefix matching of SRv6 Service SIDs to the Colored prefixes. The existing IPv6 Address Family and Color Extended Community are reused for the advertisement of IPv6 Colored prefixes without new BGP extensions, thus this mechanism is easy to interoperate and can be deployed incrementally in multi-domain networks.

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."

This Internet-Draft will expire on 2 January 2025.

Table of Contents

1. Introduction

With the trend of using one common network to carry multiple types of services, each service type can have different requirements for 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 a need to provide the services with different end-to-end paths to meet the intent. [I-D.hr-spring-intentaware-routing-using-color] 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 Labeled Unicast (BGP-LU) mechanism as defined in [RFC8277]. 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 is 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 can obtain the routes to the IP prefixes of the destination node in other domains. With the introduction of SRv6 [RFC8402] [RFC8754] [RFC8986], BGP services are assigned with SRv6 Service SIDs [RFC9252], 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 routes to the prefix, and inter-domain LSPs based on BGP-LU mechanism is not necessary for IPv6 and SRv6-based networks.

This document describes a mechanism to advertise IPv6 prefixes which are associated with Color Extended Community to establish end-to-end intent-aware paths for SRv6 services. The color value in the Color Extended Community indicates the intent [RFC9256]. Such IPv6 prefixes are called "Colored Prefixes", and this mechanism is called Colored Prefix Routing (CPR). In SRv6 networks, the Colored Prefixes are the SRv6 locators associated with different intent. BGP services over SRv6 (e.g. SRv6 VPN services) [RFC9252] with specific intent could be assigned with SRv6 SIDs under the corresponding SRv6 locators, which are advertised as Colored Prefixes. This allows the SRv6 service traffic to be steered (as specified in [RFC9252]) into end-to-end intent-aware paths simply based on the longest prefix matching of SRv6 Service SIDs to the Colored Prefixes. In the data plane, the dedicated transport label or SID for the inter-domain path is not needed, so that the encapsulation efficiency could be optimized.

The existing IPv6 Address Family and Color Extended Community could be reused for the advertisement of IPv6 Colored Prefixes without new BGP extensions, thus this mechanism is easy to interoperate and can be deployed incrementally in multi-domain networks.

2. BGP CPR

This section describes the BGP CPR mechanisms. More specifically, section 2.1 describes the allocation of the IPv6 Colored Prefixes, section 2.2 describes the advertisement of Colored 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 BGP SRv6 services to CPR routes.

2.1. Colored Prefix Allocation

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 that is identified by a color value. One way to achieve this is by splitting the base SRv6 locator of the node into N sub-locators, and these sub-locators are Colored Prefixes associated with different intents.

For example, a PE node is allocated with the base SRv6 Locator 2001:db8:aaaa:1::/64. In order to provide 16 different intents, 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.

2.2. Colored Prefix Advertisement

After the allocation of Colored Prefixes on a PE node, routes to these Colored Prefixes need to be advertised both in the local domain and also to other domains using BGP, so that the BGP 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) [RFC2545] is used for the advertisement of the Colored Prefix routes. The color extended community [RFC9012] is carried with the Colored Prefix route with the color value indicating the intent [RFC9256]. The procedure of Colored Prefix advertisement is described using an example with the following topology:

                       Consistent Color Domain:
                               C1, C2, ...
     +--------------+        +--------------+        +-------------+
     |              |        |              |        |             |
     |        [ASBR11]---[ASBR21]      [ASBR23]---[ASBR31]         |
 --[PE1] [P1]       |  X     |    [P2]      |   X    |     [P3]  [PE3]--
     |        [ASBR12]---[ASBR22]      [ASBR24]---[ASBR32]         |
     |              |        |              |        |             |
     +--------------+        +--------------+        +-------------+
           AS1                     AS2                     AS3

                                        Colored Prefixes of PE3:
                                             Low delay: PE3:CL1::
                                        High bandwidth: PE3:CL2::
                                                    ...
        Figure 1. Example Topology for CPR Route Illustration

Assume PE3 is provisioned with two different Colored Prefixes CLP-1 and CLP-2 for two different intents such as "low-delay" and "high-bandwidth" respectively. In this example, It is assumed that the color representing a specific intent is consistent throughout all the domains.

In normal cases, the color value in the color extended community associated with the CPR route is consistent through all the domains, so that the Color Extended Community in the CPR routes is kept unchanged. While in some special cases, one intent may be represented as different color value in different domains. If this is the case, then the Color Extended Community in the CPR routes needs to be updated at the border nodes of the domains based on the color-mapping policy. For example, in AS1, the intent "low latency" is represented by color "red", while in AS2 the same intent is represented by color "blue". When a CPR route is sent from AS1 to AS2, the Color Extended Community in the CPR routes needs to be updated from "red" to "blue" at the border nodes based on the color-mapping policy.

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 LU 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 [I-D.agrawal-spring-srv6-mpls-interworking].

2.3. CPR to Intra-domain Path Resolution

A domain border node which receives a CPR route can resolve the CPR route to an intra-domain color-aware path based on the tuple (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:

For example, PE1 receives a CPR route to PE3:CL1:: with color C1 and next-hop ASBR11, it can resolve the CPR routes to an intra-domain SRv6 Policy based on the tuple (ASBR11, C1).

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.

2.4. SRv6 Service Route Advertisement

For an SRv6 service which is associated with a specific intent, the SRv6 Service SID could be allocated under the corresponding Colored 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 PE3:CL1:DT::, where PE3:CL1:: is the SRv6 Colored Prefix for low-delay service.

The SRv6 service routes are advertised using the mechanism defined in [RFC9252]. 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.

2.5. SRv6 Service Steering

With the CPR routing mechanism, the ingress PE node which receives the SRv6 service routes follows the behavior of SRv6 shortest path forwarding (refer to Section 5 and 6 of [RFC9252]). 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 longest prefix matching of SRv6 service SIDs to the Colored Prefixes is performed, then the intra-domain color-aware paths in each network domain which the CPR route is resolved to are used for forwarding the SRv6 service traffic.

3. Encapsulation and Forwarding Processes

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

3.1. CPR over SRv6 Intra-Domain Paths

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 [RFC8754] is used.

PE3 is provisioned with a Colored Prefix PE3:CL1:: for "low-delay".

In AS1, the SRv6 Policy for (ASBR11, C1) is represented with SID list (P1, BR11).

In AS2, the SRv6 Policy for (ASBR23, C1) is represented with the SID list (P2, BR23).

In AS3, the SRv6 Policy for (PE3, C1) 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 using H.Encaps.Red behavior [RFC8986] is shown as below:

PE1 ->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  : {(BR21, P2)(BR23; SL=1)}(PE1, PE3:CL1.DT::)(C-pkt)
P2  ->BR23: {(BR21, BR23)}(PE1, PE3:CL1.DT::)(C-pkt)
BR23->BR31: (PE1, PE3:CL1.DT::)(C-pkt)
BR31->P3  : {(BR31, P3)(PE3; SL=1)}(PE1, PE3:CL1.DT::)(C-pkt)
P3  ->PE3 : {(BR31, PE3)}(PE1, PE3:CL1.DT::)(C-pkt)

In some network domains, SRv6 Flex-Algo may be used to provide intent-aware intra-domain paths. The encapsulation is similar to the case with SRv6 Policy.

3.2. CPR over MPLS Intra-Domain Paths

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 (which are actually IPv6 packets) over an intra-domain MPLS LSP is based on the MPLS mechanisms as defined in [RFC3031] [RFC3032] and [RFC8660]. The behavior is similar to that of 6PE [RFC4798].

In AS1, the SR-MPLS Policy for (ASBR11, C1) is represented with Label-stack (P1, BR11).

In AS2, the SR-MPLS Flex-Algo for (ASBR23, C1) is represented with Label-stack (BR23).

In AS3, the SR-MPLS Policy for (PE3, C1) 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:

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

4. Operational Considerations

The CPR mechanism can be used in network scenarios where multiple inter-connected network domains belong to the same operator, or there is an operational trust model between the network domains of different operators.

As described in section 5 of [I-D.hr-spring-intentaware-routing-using-color], the inter-domain intent-aware routing may be achieved with a logical tunnel created by an SR Policy across multiple domains, and service traffic with specific intent can be steered to the inter-domain SR Policy based on the intent signaled by Color Extended Community. An operator may prefer a BGP routing based solution for the reasons described in [I-D.hr-spring-intentaware-routing-using-color]. Another possible consideration of the operator is the availability of inter-domain controller for end-to-end intent-aware path computation. This document proposes an alternate solution to signal the intent with IPv6 Colored Prefixes using BGP.

When the Colored 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 Colored locator prefixes. To make sure the Colored locator prefixes can be distributed to the ingress PE nodes along the border nodes, it is required that the route aggregation be disabled for IPv6 unicast routes which carry the color extended community.

All the border nodes and the ingress PE nodes need to install the Colored locator prefixes into the RIB and FIB. For transit domains which support the CPR mechanism, the border nodes can use the tuple (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 would ignore the color extended community and 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 that support the CPR mechanism, while can fall back to resolve over best-effort intra-domain path in the legacy network domains.

There may be multiple inter-domain links between the adjacent network domains, and a border node BGP speaker may receive CPR routes from multiple peering BGP speakers in another domain via EBGP. The local policy of a BGP speaker may take the attributes of the inter-domain links and the attributes of the received CPR routes into consideration when selecting the best path for specific Colored Prefixes to better meet the intent. The detailed local policy is outside the scope of this document. In a multi-domain environment, the policy of BGP speakers in different domains needs to be consistent.

In this document, IPv6 Unicast Address Family is used for the advertisement of IPv6 Colored Prefixes. The primary advantage of this approach is the improved interoperability with legacy networks that lack support for intent-aware paths, and the facilitation of incremental deployment of intent-aware routing mechanisms. One potential concern arises regarding the necessity of separating Colored Prefixes from public IPv6 unicast routes. Since the IP prefixes and SRv6 locators of network infrastructure are usually advertised as part of the IP unicast routes, and appropriate filters are configured at the boundaries of network administration, this is not considered to be a significant issue. The proposal in [I-D.ietf-idr-bgp-car] provides a complementary solution that is also based on the notion of color indicating the intent and where the SRv6 Locator prefix itself signifies the intent, the difference is that a separate SAFI is used.

[I-D.ietf-idr-bgp-ct] describes another mechanism for intent-aware routing, in which the SRv6 service SIDs are not directly associated with the intent, while additional SRv6 transport SIDs are required for steering traffic to the inter-domain intent-aware paths, and an SRv6 operation similar to MPLS label swapping is needed on the border nodes of network domains.

5. IANA Considerations

This document makes no request of IANA.

6. Security Considerations

The mechanism described in this document provides an approach for inter-domain intent-aware routing based on existing BGP protocol mechanisms. The existing BGP IPv6 Unicast Address Family and existing Color extended community are reused without further BGP extensions. With this approach, the number of IPv6 Colored Prefixes advertised by PE nodes is in proportion to the number of intents it supports. This may introduce additional routes to BGP IPv6 routing table. While since these are infrastructure routes, the amount of Colored Prefixes is only a small portion of the total amount of IPv6 prefixes. Thus it is considered that the impact is acceptable.

As the CPR routes are distributed across multiple network domains, the mapping relationship between the intent and the IPv6 Colored Prefixes are observable to BGP nodes in those network domains. it is possible for a man-in-the-middle attacker to identify packets associated with a particular intent. While this is similar to other intent-based mechanisms, as the packets will also be encapsulated with necessary information to represent and fulfil the intent.

The security considerations as described in [RFC4271] [RFC4272] and [RFC8754] apply to this document.

7. Contributing Authors

The following people contributed significantly to the content of this document and should be considered co-authors:

Xinjun Chen
ifocus.chen@huawei.com

Jingrong Xie
xiejingrong@huawei.com

Zhenqiang Li
li_zhenqiang@hotmail.com

8. Acknowledgements

The authors would like to thank Shunwan Zhuang, Zhibo Hu, Zhenbin Li, Dhananjaya Rao and Dhruv Dhody for the review and valuable discussion.

9. References

9.1. Normative References

[RFC2545]
Marques, P. and F. Dupont, "Use of BGP-4 Multiprotocol Extensions for IPv6 Inter-Domain Routing", RFC 2545, DOI 10.17487/RFC2545, , <https://www.rfc-editor.org/info/rfc2545>.
[RFC4271]
Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A Border Gateway Protocol 4 (BGP-4)", RFC 4271, DOI 10.17487/RFC4271, , <https://www.rfc-editor.org/info/rfc4271>.
[RFC4272]
Murphy, S., "BGP Security Vulnerabilities Analysis", RFC 4272, DOI 10.17487/RFC4272, , <https://www.rfc-editor.org/info/rfc4272>.
[RFC8402]
Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., Decraene, B., Litkowski, S., and R. Shakir, "Segment Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, , <https://www.rfc-editor.org/info/rfc8402>.
[RFC8754]
Filsfils, C., Ed., Dukes, D., Ed., Previdi, S., Leddy, J., Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header (SRH)", RFC 8754, DOI 10.17487/RFC8754, , <https://www.rfc-editor.org/info/rfc8754>.
[RFC8986]
Filsfils, C., Ed., Camarillo, P., Ed., Leddy, J., Voyer, D., Matsushima, S., and Z. Li, "Segment Routing over IPv6 (SRv6) Network Programming", RFC 8986, DOI 10.17487/RFC8986, , <https://www.rfc-editor.org/info/rfc8986>.
[RFC9012]
Patel, K., Van de Velde, G., Sangli, S., and J. Scudder, "The BGP Tunnel Encapsulation Attribute", RFC 9012, DOI 10.17487/RFC9012, , <https://www.rfc-editor.org/info/rfc9012>.
[RFC9252]
Dawra, G., Ed., Talaulikar, K., Ed., Raszuk, R., Decraene, B., Zhuang, S., and J. Rabadan, "BGP Overlay Services Based on Segment Routing over IPv6 (SRv6)", RFC 9252, DOI 10.17487/RFC9252, , <https://www.rfc-editor.org/info/rfc9252>.
[RFC9256]
Filsfils, C., Talaulikar, K., Ed., Voyer, D., Bogdanov, A., and P. Mattes, "Segment Routing Policy Architecture", RFC 9256, DOI 10.17487/RFC9256, , <https://www.rfc-editor.org/info/rfc9256>.

9.2. Informative References

[I-D.agrawal-spring-srv6-mpls-interworking]
Agrawal, S., Filsfils, C., Voyer, D., Dawra, G., Li, Z., and S. Hegde, "SRv6 and MPLS interworking", Work in Progress, Internet-Draft, draft-agrawal-spring-srv6-mpls-interworking-14, , <https://datatracker.ietf.org/doc/html/draft-agrawal-spring-srv6-mpls-interworking-14>.
[I-D.hr-spring-intentaware-routing-using-color]
Hegde, S., Rao, D., Uttaro, J., Bogdanov, A., and L. Jalil, "Problem statement for Inter-domain Intent-aware Routing using Color", Work in Progress, Internet-Draft, draft-hr-spring-intentaware-routing-using-color-03, , <https://datatracker.ietf.org/doc/html/draft-hr-spring-intentaware-routing-using-color-03>.
[I-D.ietf-idr-bgp-car]
Rao, D., Agrawal, S., and Co-authors, "BGP Color-Aware Routing (CAR)", Work in Progress, Internet-Draft, draft-ietf-idr-bgp-car-10, , <https://datatracker.ietf.org/doc/html/draft-ietf-idr-bgp-car-10>.
[I-D.ietf-idr-bgp-ct]
Vairavakkalai, K. and N. Venkataraman, "BGP Classful Transport Planes", Work in Progress, Internet-Draft, draft-ietf-idr-bgp-ct-33, , <https://datatracker.ietf.org/doc/html/draft-ietf-idr-bgp-ct-33>.
[RFC3031]
Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol Label Switching Architecture", RFC 3031, DOI 10.17487/RFC3031, , <https://www.rfc-editor.org/info/rfc3031>.
[RFC3032]
Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack Encoding", RFC 3032, DOI 10.17487/RFC3032, , <https://www.rfc-editor.org/info/rfc3032>.
[RFC4798]
De Clercq, J., Ooms, D., Prevost, S., and F. Le Faucheur, "Connecting IPv6 Islands over IPv4 MPLS Using IPv6 Provider Edge Routers (6PE)", RFC 4798, DOI 10.17487/RFC4798, , <https://www.rfc-editor.org/info/rfc4798>.
[RFC8277]
Rosen, E., "Using BGP to Bind MPLS Labels to Address Prefixes", RFC 8277, DOI 10.17487/RFC8277, , <https://www.rfc-editor.org/info/rfc8277>.
[RFC8660]
Bashandy, A., Ed., Filsfils, C., Ed., Previdi, S., Decraene, B., Litkowski, S., and R. Shakir, "Segment Routing with the MPLS Data Plane", RFC 8660, DOI 10.17487/RFC8660, , <https://www.rfc-editor.org/info/rfc8660>.

Authors' Addresses

Haibo Wang
Huawei Technologies
China
Jie Dong
Huawei Technologies
China
Ketan Talaulikar
Cisco Systems
India
Tao Han
Huawei Technologies
China
Ran Chen
ZTE Corporation
China