rfc9723.original   rfc9723.txt 
Interdomain Routing Working Group H. Wang Internet Engineering Task Force (IETF) H. Wang
Internet-Draft J. Dong Request for Comments: 9723 J. Dong
Intended status: Informational Huawei Technologies Category: Informational Huawei Technologies
Expires: 28 August 2025 K. Talaulikar ISSN: 2070-1721 K. Talaulikar
Cisco Systems Cisco Systems
T. Han T. Han
Huawei Technologies Huawei Technologies
R. Chen R. Chen
ZTE Corporation ZTE Corporation
24 February 2025 May 2025
BGP Colored Prefix Routing (CPR) for SRv6 based Services BGP Colored Prefix Routing (CPR) for SRv6-Based Services
draft-ietf-idr-cpr-08
Abstract Abstract
This document describes a mechanism to advertise IPv6 prefixes in BGP This document describes a mechanism to advertise IPv6 prefixes in BGP
which are associated with Color Extended Communities to establish that are associated with Color Extended Communities to establish end-
end-to-end intent-aware paths for Segment Routing over IPv6 (SRv6) to-end intent-aware paths for Segment Routing over IPv6 (SRv6)
services. Such IPv6 prefixes are called "Colored Prefixes", and this services. Such IPv6 prefixes are called "Colored Prefixes", and this
mechanism is called Colored Prefix Routing (CPR). In SRv6 networks, mechanism is called "Colored Prefix Routing" (CPR). In SRv6
the Colored prefixes are the SRv6 locators associated with different networks, the Colored Prefixes are the SRv6 locators associated with
intent. SRv6 services (e.g. SRv6 VPN services) with specific intent different intents. SRv6 services (e.g., SRv6 VPN services) with a
could be assigned with SRv6 Segment Identifiers (SIDs) under the specific intent could be assigned with SRv6 Segment Identifiers
corresponding SRv6 locators, which are advertised as Colored (SIDs) under the corresponding SRv6 locators, which are advertised as
prefixes. Colored Prefixes.
This operational methodology allows the SRv6 service traffic to be This operational methodology allows the SRv6 service traffic to be
steered into end-to-end intent-aware paths simply based on the steered into end-to-end intent-aware paths based on the longest
longest prefix matching of SRv6 Service SIDs to the Colored prefixes. prefix matching of SRv6 Service SIDs to the Colored Prefixes. The
The existing IPv6 Address Family and Color Extended Community are existing IPv6 Address Family and Color Extended Community are reused
reused for the advertisement of IPv6 Colored prefixes without new BGP to advertise IPv6 Colored Prefixes without new BGP extensions; thus,
extensions, thus this mechanism is easy to interoperate and can be this mechanism is easy to interoperate and can be deployed
deployed incrementally in multi-Autonomous System (AS) networks which incrementally in multi-Autonomous System (AS) networks that belong to
belong to the same trusted domain. the same trusted domain.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This document is not an Internet Standards Track specification; it is
provisions of BCP 78 and BCP 79. published for informational purposes.
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 This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Not all documents
approved by the IESG are candidates for any level of Internet
Standard; see Section 2 of RFC 7841.
This Internet-Draft will expire on 28 August 2025. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
https://www.rfc-editor.org/info/rfc9723.
Copyright Notice Copyright Notice
Copyright (c) 2025 IETF Trust and the persons identified as the Copyright (c) 2025 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/ Provisions Relating to IETF Documents
license-info) in effect on the date of publication of this document. (https://trustee.ietf.org/license-info) in effect on the date of
Please review these documents carefully, as they describe your rights publication of this document. Please review these documents
and restrictions with respect to this document. Code Components carefully, as they describe your rights and restrictions with respect
extracted from this document must include Revised BSD License text as to this document. Code Components extracted from this document must
described in Section 4.e of the Trust Legal Provisions and are include Revised BSD License text as described in Section 4.e of the
provided without warranty as described in the Revised BSD License. Trust Legal Provisions and are provided without warranty as described
in the Revised BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction
2. BGP CPR . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. BGP CPR
2.1. Colored Prefix Allocation . . . . . . . . . . . . . . . . 4 2.1. Colored Prefix Allocation
2.2. Colored Prefix Advertisement . . . . . . . . . . . . . . 5 2.2. Colored Prefix Advertisement
2.3. CPR to Intra-domain Path Resolution . . . . . . . . . . . 6 2.3. CPR to Intra-Domain Path Resolution
2.4. SRv6 Service Route Advertisement . . . . . . . . . . . . 7 2.4. SRv6 Service Route Advertisement
2.5. SRv6 Service Steering . . . . . . . . . . . . . . . . . . 7 2.5. SRv6 Service Steering
3. Encapsulation and Forwarding Processes . . . . . . . . . . . 7 3. Encapsulation and Forwarding Process
3.1. CPR over SRv6 Intra-Domain Paths . . . . . . . . . . . . 8 3.1. CPR over SRv6 Intra-Domain Paths
3.2. CPR over MPLS Intra-Domain Paths . . . . . . . . . . . . 8 3.2. CPR over MPLS Intra-Domain Paths
4. Operational Considerations . . . . . . . . . . . . . . . . . 9 4. Operational Considerations
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 5. IANA Considerations
6. Security Considerations . . . . . . . . . . . . . . . . . . . 11 6. Security Considerations
7. Contributing Authors . . . . . . . . . . . . . . . . . . . . 12 7. References
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12 7.1. Normative References
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 7.2. Informative References
9.1. Normative References . . . . . . . . . . . . . . . . . . 12 Acknowledgements
9.2. Informative References . . . . . . . . . . . . . . . . . 13 Contributors
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 Authors' Addresses
1. Introduction 1. Introduction
With the trend of using one common network to carry multiple types of With the trend of using one common network to carry multiple types of
services, each service type can have different requirements for the services, each service type can have different requirements for the
network. Such requirements are usually considered as the "intent" of network. Such requirements are usually considered the "intent" of
the service or customer, and is represented as an abstract notion the service or customer, which is represented as an abstract notion
called "color". called "color".
In network scenarios where the services are delivered across multiple In network scenarios where the services are delivered across multiple
Autonomous Systems (ASes) , there is a need to provide the services Autonomous Systems (ASes), there is a need to provide the services
with different end-to-end paths to meet the intent. with different end-to-end paths to meet the intent. [INTENTAWARE]
[I-D.hr-spring-intentaware-routing-using-color] describes the problem describes the problem statements and requirements for inter-domain
statements and requirements for inter-domain intent-aware routing. intent-aware routing.
The inter-domain path can be established using either Multi-Protocol The inter-domain path can be established using either Multi-Protocol
Label Switching (MPLS) or IP data plane. In MPLS-based networks, the Label Switching (MPLS) or the IP data plane. In MPLS-based networks,
usual inter-domain approach is to establish an end-to-end Label- the usual inter-domain approach is to establish an end-to-end Label
Switched Path (LSP) based on the BGP Labeled Unicast (BGP-LU) Switched Path (LSP) based on the mechanism defined in [RFC8277]
mechanism as defined in [RFC8277]. Each domain's ingress border node (which is usually referred to as BGP-LU (BGP Labeled Unicast)). Each
needs to perform label swapping for the end-to-end LSP, and impose domain's ingress border node needs to perform label swapping for the
the label stack which is used for the LSP within its own domain. end-to-end LSP, and impose the label stack that is used for the LSP
within its own domain.
In IP-based networks, the IP reachability information can be In IP-based networks, the IP reachability information can be
advertised to network nodes in different domains using BGP, so that advertised to network nodes in different domains using BGP, so that
all the domain border nodes can obtain the routes to the IP prefixes all the domain border nodes can obtain the routes to the IP prefixes
of the destination nodes in other domains. With the introduction of of the destination nodes in other domains. With the introduction of
SRv6 [RFC8402] [RFC8754] [RFC8986], BGP services are assigned with SRv6 [RFC8402] [RFC8754] [RFC8986], BGP services are assigned with
SRv6 Service SIDs [RFC9252], which are routable in the network SRv6 Service SIDs [RFC9252], which are routable in the network
according to its SRv6 locator prefix. Thus, the inter-domain path according to its SRv6 locator prefix. Thus, the inter-domain path
can be established simply based on the inter-domain routes to the can be established simply based on the inter-domain routes to the
prefix, and inter-domain LSPs based on BGP-LU mechanism is not prefix. Inter-domain LSPs based on the BGP-LU mechanism are not
necessary for IPv6 and SRv6-based networks. necessary for IPv6- and SRv6-based networks.
This document describes a mechanism to advertise IPv6 prefixes which This document describes a mechanism to advertise IPv6 prefixes that
are associated with Color Extended Community to establish end-to-end are associated with the Color Extended Community to establish end-to-
intent-aware paths for SRv6 services. The color value in the Color end intent-aware paths for SRv6 services. The color value in the
Extended Community indicates the intent [RFC9256]. Such IPv6 Color Extended Community indicates the intent [RFC9256]. Such IPv6
prefixes are called "Colored Prefixes", and this mechanism is called prefixes are called "Colored Prefixes", and this mechanism is called
Colored Prefix Routing (CPR). In SRv6 networks, the Colored Prefixes Colored Prefix Routing (CPR). In SRv6 networks, the Colored Prefixes
are the SRv6 locators associated with different intent. BGP services are the SRv6 locators associated with different intents. BGP
over SRv6 (e.g. SRv6 VPN services) [RFC9252] with specific intent services over SRv6 (e.g., SRv6 VPN services) [RFC9252] with specific
could be assigned with SRv6 SIDs under the corresponding SRv6 intent could be assigned with SRv6 SIDs under the corresponding SRv6
locators, which are advertised as Colored Prefixes. This allows the locators, which are advertised as Colored Prefixes. This allows the
SRv6 service traffic to be steered (as specified in [RFC9252]) into SRv6 service traffic to be steered (as specified in [RFC9252]) into
end-to-end intent-aware paths simply based on the longest prefix end-to-end intent-aware paths based on the longest prefix matching of
matching of SRv6 Service SIDs to the Colored Prefixes. In the data SRv6 Service SIDs to the Colored Prefixes. In the data plane, the
plane, the dedicated transport label or SID for the inter-domain path dedicated transport label or SID for the inter-domain path is not
is not needed, resulting in smaller encapsulation overhead than with needed, resulting in smaller encapsulation overhead than with other
other options. options.
The existing IPv6 Address Family and Color Extended Community could The existing IPv6 Address Family and Color Extended Community could
be reused for the advertisement of IPv6 Colored Prefixes without new be reused to advertise IPv6 Colored Prefixes without new BGP
BGP extensions, thus this mechanism is easy to interoperate and can extensions; thus, this mechanism is easy to interoperate and can be
be deployed incrementally in multi-AS networks which belong to the deployed incrementally in multi-AS networks that belong to the same
same trusted domain (in the sense used by Section 8 of [RFC8402]). trusted domain (in the sense used by Section 8 of [RFC8402]).
2. BGP CPR 2. BGP CPR
2.1. Colored Prefix Allocation 2.1. Colored Prefix Allocation
In SRv6 networks, an SRv6 locator needs to be allocated for each In SRv6 networks, an SRv6 locator needs to be allocated for each
node. In order to distinguish N different intents, a Provider Edge node. In order to distinguish N different intents, a Provider Edge
(PE) node needs to be allocated with N SRv6 locators, each of which (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. 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 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 node into N sub-locators, whereby these sub-locators are Colored
associated with different intents. Prefixes associated with different intents.
For example, a PE node is allocated with the base SRv6 Locator 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 2001:db8:aaaa:1::/64. In order to provide 16 different intents, this
base SRv6 Locator is split into 16 sub-locators from 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 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- sub-locators is associated with a different intent, such as low-
delay, high-bandwidth, etc. delay, high-bandwidth, etc.
2.2. Colored Prefix Advertisement 2.2. Colored Prefix Advertisement
After the allocation of Colored Prefixes on a PE node, routes to After the allocation of Colored Prefixes on a PE node, routes to
these Colored Prefixes need to be advertised both in the local domain 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 and also to other domains using BGP, so that the BGP SRv6 services
routes could be resolved using the corresponding CPR route. routes could be resolved using the corresponding CPR route.
In a multi-AS IPv6 network, the IPv6 unicast Address Family/ In a multi-AS IPv6 network, the mechanism for IPv6 unicast routing as
Subsequent Address Family (AFI/SAFI = 2/1) [RFC2545] is used for the defined in [RFC2545] is used for the advertisement of the Colored
advertisement of the Colored Prefix routes. The color extended Prefix routes, in which the Address Family / Subsequent Address
community [RFC9012] is carried with the Colored Prefix route with the Family (AFI/SAFI = 2/1) is used. The Color Extended Community
color value indicating the intent [RFC9256]. The procedure of [RFC9012] is carried with the Colored Prefix route with the color
Colored Prefix advertisement is described using an example with the value indicating the intent [RFC9256]. The procedure of Colored
following topology: Prefix advertisement is described using an example with the following
topology:
Consistent Color Domain: Consistent Color Domain:
C1, C2, ... C1, C2, ...
+--------------+ +--------------+ +-------------+ +--------------+ +--------------+ +-------------+
| | | | | | | | | | | |
| [ASBR11]---[ASBR21] [ASBR23]---[ASBR31] | | [ASBR11]---[ASBR21] [ASBR23]---[ASBR31] |
--[PE1] [P1] | X | [P2] | X | [P3] [PE3]-- --[PE1] [P1] | X | [P2] | X | [P3] [PE3]--
| [ASBR12]---[ASBR22] [ASBR24]---[ASBR32] | | [ASBR12]---[ASBR22] [ASBR24]---[ASBR32] |
| | | | | | | | | | | |
+--------------+ +--------------+ +-------------+ +--------------+ +--------------+ +-------------+
AS1 AS2 AS3 AS1 AS2 AS3
Colored Prefixes of PE3: Colored Prefixes of PE3:
Low delay: PE3:CL1:: Low delay: PE3:CL1::
High bandwidth: PE3:CL2:: High bandwidth: PE3:CL2::
... ...
Figure 1. Example Topology for CPR Route Illustration
Figure 1: Example Topology for CPR Route Illustration
Assume PE3 is provisioned with two different Colored Prefixes CLP-1 Assume PE3 is provisioned with two different Colored Prefixes CLP-1
and CLP-2 for two different intents such as "low-delay" and "high- and CLP-2 for two different intents such as "low-delay" and "high-
bandwidth" respectively. In this example, It is assumed that the bandwidth" respectively. In this example, It is assumed that the
color representing a specific intent is consistent throughout all the color representing a specific intent is consistent throughout all the
domains. domains.
* PE3 originates BGP IPv6 unicast (AFI/SAFI=2/1) route for the * PE3 originates BGP IPv6 unicast (AFI/SAFI=2/1) route for the
Colored Prefixes PE3:CL1:: and PE3:CL2::. Each route should carry Colored Prefixes PE3:CL1:: and PE3:CL2::. Each route should carry
the corresponding color extended community C1 or C2. PE3 also the corresponding Color Extended Community C1 or C2. PE3 also
advertises a route for the base SRv6 Locator prefix PE3:BL, and advertises a route for the base SRv6 Locator prefix PE3:BL, and
there is no color extended community carried with this route. there is no Color Extended Community carried with this route.
* ASBR31 and ASBR32 receive the CPR routes of PE3, and advertise the * ASBR31 and ASBR32 receive the CPR routes of PE3, and advertise the
CPR routes further to ASBR23 and ASBR24 with next-hop set to CPR routes further to ASBR23 and ASBR24 with next-hop set to
itself. itself.
* ASBR23 and ASBR24 receive the CPR routes of PE3. Since the color- * ASBR23 and ASBR24 receive the CPR routes of PE3. Since the color-
to-intent mapping in AS2 is consistent with that in AS3, the Color to-intent mapping in AS2 is consistent with that in AS3, the Color
Extended Community in the received CPR routes are kept unchanged. Extended Community in the received CPR routes are kept unchanged.
ASBR23 and ASBR 24 advertise the CPR routes further in AS2 with ASBR23 and ASBR24 advertise the CPR routes further in AS2 with the
the next-hop set to itself. next hop set to itself.
* The behavior of ASBR21 and ASBR22 are similar to the behavior of * The behavior of ASBR21 and ASBR22 are similar to the behavior of
ASBR31 and ASBR32. ASBR31 and ASBR32.
* The behavior of ASBR11 and ASBR12 are similar to the behavior of * The behavior of ASBR11 and ASBR12 are similar to the behavior of
ASBR23 and ASBR24. ASBR23 and ASBR24.
In normal cases, the color value in the color extended community In normal cases, the color value in the Color Extended Community
associated with the CPR route is consistent through all the domains, associated with the CPR route is consistent through all the domains,
so that the Color Extended Community in the CPR routes is kept so that the Color Extended Community in the CPR routes is kept
unchanged. While in some special cases, one intent may be unchanged. In some special cases, one intent may be represented as a
represented as different color value in different domains. If this different color value in different domains. If this is the case,
is the case, then the Color Extended Community in the CPR routes then the Color Extended Community in the CPR routes needs to be
needs to be updated at the border nodes of the domains based on the updated at the border nodes of the domains based on the color-mapping
color-mapping policy. For example, in AS1, the intent "low latency" policy. For example, in AS1, the intent "low latency" is represented
is represented by color "red", while in AS2 the same intent is by the color "red", while the same intent is represented by color
represented by color "blue". When a CPR route is sent from AS1 to "blue" in AS2. When a CPR route is sent from AS1 to AS2, the Color
AS2, the Color Extended Community in the CPR routes needs to be Extended Community in the CPR routes needs to be updated from "red"
updated from "red" to "blue" at the border nodes based on the color- to "blue" at the border nodes based on the color-mapping policy.
mapping policy.
In network scenarios where some of the intermediate autonomous In network scenarios where some of the intermediate autonomous
systems are MPLS-based, the CPR routes may still be advertised using systems are MPLS based, the CPR routes may still be advertised using
the IPv6 unicast address family (AFI/SAFI=2/1) in the MPLS-based the IPv6 unicast address family (AFI/SAFI=2/1) in the MPLS-based
intermediate domains, and at the MPLS domain border nodes, some route intermediate domains; at the MPLS domain border nodes, some route
resolution policy could be used to make the CPR routes resolved to resolution policy could be used to make the CPR routes resolve to
intra-domain intent-aware MPLS LSPs. Another possible mechanism is 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 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 routes in the MPLS domains, the detailed procedure is described in
Section 7.1.2.1 of [I-D.ietf-spring-srv6-mpls-interworking]. Section 7.1.2.1 of [SRv6-INTERWORK].
2.3. CPR to Intra-domain Path Resolution 2.3. CPR to Intra-Domain Path Resolution
A domain border node which receives a CPR route can resolve the CPR A domain border node that receives a CPR route can resolve the CPR
route to an intra-domain color-aware path based on the tuple (N, C), 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 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 Community of the CPR route. The intra-domain color-aware path could
be built with any of the following mechanisms: be built with any of the following mechanisms:
* SRv6 or SR-MPLS Policy * SRv6 Policy
* SR-MPLS Policy
* SRv6 Flex-Algo
* SR-MPLS Flex-Algo
* SRv6 or SR-MPLS Flex-Algo
* RSVP-TE * RSVP-TE
For example, PE1 receives a CPR route to PE3:CL1:: with color C1 and For example, if PE1 receives a CPR route to PE3:CL1:: with the color
next-hop ASBR11, it can resolve the CPR routes to an intra-domain C1 and next hop ASBR11, it can resolve the CPR routes to an intra-
SRv6 Policy based on the tuple (ASBR11, C1). domain SRv6 Policy based on the tuple (ASBR11, C1).
The intra-domain path resolution scheme could be based on any The intra-domain path resolution scheme could be based on any
existing tunnel resolution policy, and new tunnel resolution existing tunnel resolution policy, and new tunnel resolution
mechanisms could be introduced if needed. mechanisms could be introduced if needed.
2.4. SRv6 Service Route Advertisement 2.4. SRv6 Service Route Advertisement
For an SRv6 service which is associated with a specific intent, the For an SRv6 service that is associated with a specific intent, the
SRv6 Service SID could be allocated under the corresponding Colored SRv6 Service SID could be allocated under the corresponding Colored
locator prefix. For example, on PE3 in the example topology, an SRv6 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 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 End.DT4 SID PE3:CL1:DT::, where PE3:CL1:: is the SRv6 Colored Prefix
for low-delay service. for low-delay service.
The SRv6 service routes are advertised using the mechanism defined in The SRv6 service routes are advertised using the mechanism defined in
[RFC9252]. The inter-domain VPN Option C is used, which means the [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 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 is not changed. Since the intent of the service is embedded in the
service SID, the SRv6 service route does not need to carry the color SRv6 service SID, the SRv6 service route does not need to carry the
extended community. Color Extended Community.
2.5. SRv6 Service Steering 2.5. SRv6 Service Steering
With the CPR routing mechanism, the ingress PE node which receives With the CPR routing mechanism, the ingress PE node that receives the
the SRv6 service routes follows the behavior of SRv6 shortest path SRv6 service routes follows the behavior of SRv6 shortest path
forwarding (refer to Section 5 and 6 of [RFC9252]). The SRv6 service forwarding (refer to Sections 5 and 6 of [RFC9252]). The SRv6
SID carried in the service route is used as the destination address service SID carried in the service route is used as the destination
in the outer IPv6 header that encapsulates the service packet. If address in the outer IPv6 header that encapsulates the service
the corresponding CPR route has been received and installed, longest packet. If the corresponding CPR route has been received and
prefix matching of SRv6 service SIDs to the Colored Prefixes is installed, longest prefix matching of SRv6 service SIDs to the
performed. As a result of this prefix matching, the next hop found Colored Prefixes is performed. As a result of this prefix matching,
is an intra-domain color-aware path, which will be used for the next hop found is an intra-domain color-aware path, which will be
forwarding the SRv6 service traffic. This process repeats at the used for forwarding the SRv6 service traffic. This process repeats
border node of each domain the packet traverses, until it reaches its at the border node of each domain the packet traverses, until it
destination. reaches its destination.
3. Encapsulation and Forwarding Processes 3. Encapsulation and Forwarding Process
This section describes the encapsulation and forwarding process of This section describes the encapsulation and forwarding process of
data packets which are matched with the corresponding CPR route. data packets which are matched with the corresponding CPR route.
The topology of Figure 1 is used in each example. The topology of Figure 1 is used in each example.
3.1. CPR over SRv6 Intra-Domain Paths 3.1. CPR over SRv6 Intra-Domain Paths
Following is an illustration of the packet encapsulation and Following is an illustration of the packet encapsulation and
forwarding process of CPR over SRv6 Policy. The abstract forwarding process of CPR over SRv6 Policy. The abstract
representation of IPv6 and SRH in section 6 of [RFC8754] is used. representation of IPv6 and the Segment Routing Header (SRH) described
in Section 6 of [RFC8754] is used.
PE3 is provisioned with a Colored Prefix PE3:CL1:: for "low-delay". PE3 is provisioned with a Colored Prefix PE3:CL1:: for "low-delay".
In AS1, the SRv6 Policy on PE1 for (ASBR11, C1) is represented with In AS1, the SRv6 Policy on PE1 for (ASBR11, C1) is represented with
SID list <P1, ASBR11>. SID list <P1, ASBR11>.
In AS2, the SRv6 Policy on ASBR21 for (ASBR23, C1) is represented In AS2, the SRv6 Policy on ASBR21 for (ASBR23, C1) is represented
with the SID list <P2, ASBR23>. with the SID list <P2, ASBR23>.
In AS3, the SRv6 Policy on ASBR31 for (PE3, C1) is represented with In AS3, the SRv6 Policy on ASBR31 for (PE3, C1) is represented with
the SID list <P3, PE3>. the SID list <P3, PE3>.
C-pkt is the customer packet PE1 received from its attaching CE. C-pkt is the customer packet PE1 received from its attaching CE.
For packets which belong to an SRv6 VPN service associated with the For packets that belong to an SRv6 VPN service associated with the
SRv6 Service SID PE3:CL1.DT6, the packet encapsulation and forwarding SRv6 Service SID PE3:CL1.DT6, the packet encapsulation and forwarding
process using H.Encaps.Red behavior [RFC8986] is shown as below: process using H.Encaps.Red behavior [RFC8986] is shown as below:
PE1 ->P1: (PE1, P1)(PE3:CL1.DT6, ASBR11; SL=2)(C-pkt) PE1 ->P1: (PE1, P1)(PE3:CL1.DT6, ASBR11; SL=2)(C-pkt)
P1 ->ASBR11: (PE1, ASBR11)(PE3:CL1.DT6, ASBR11; SL=1)(C-pkt) P1 ->ASBR11: (PE1, ASBR11)(PE3:CL1.DT6, ASBR11; SL=1)(C-pkt)
ASBR11->ASBR21: (PE1, PE3:CL1.DT6)(C-pkt) ASBR11->ASBR21: (PE1, PE3:CL1.DT6)(C-pkt)
ASBR21->P2: (ASBR21, P2)(ASBR23; SL=1)(PE1, PE3:CL1.DT6)(C-pkt) ASBR21->P2: (ASBR21, P2)(ASBR23; SL=1)(PE1, PE3:CL1.DT6)(C-pkt)
P2->ASBR23: (ASBR21, ASBR23)(PE1, PE3:CL1.DT6)(C-pkt) P2->ASBR23: (ASBR21, ASBR23)(PE1, PE3:CL1.DT6)(C-pkt)
ASBR23->ASBR31: (PE1, PE3:CL1.DT6)(C-pkt) ASBR23->ASBR31: (PE1, PE3:CL1.DT6)(C-pkt)
ASBR31->P3: (ASBR31, P3)(PE3; SL=1)(PE1, PE3:CL1.DT6)(C-pkt) ASBR31->P3: (ASBR31, P3)(PE3; SL=1)(PE1, PE3:CL1.DT6)(C-pkt)
P3->PE3: (ASBR31, PE3)(PE1, PE3:CL1.DT6)(C-pkt) P3->PE3: (ASBR31, PE3)(PE1, PE3:CL1.DT6)(C-pkt)
Figure 2
In some autonomous systems, SRv6 Flex-Algo may be used to provide In some autonomous systems, SRv6 Flex-Algo may be used to provide
intent-aware intra-domain paths. The encapsulation is similar to the intent-aware intra-domain paths. The encapsulation is similar to the
case with SRv6 Policy. case with SRv6 Policy.
3.2. CPR over MPLS Intra-Domain Paths 3.2. CPR over MPLS Intra-Domain Paths
In network scenarios where some of the autonomous systems use MPLS In network scenarios where some of the autonomous systems use the
based data plane, the CPR route can be resolved over a color-aware MPLS-based data plane, the CPR route can be resolved over a color-
intra-domain MPLS LSP. Such intra-domain MPLS LSP may be established aware intra-domain MPLS LSP. Such an intra-domain MPLS LSP may be
using SR-MPLS Policy, SR-MPLS Flex-Algo or RSVP-TE. established using SR-MPLS Policy, SR-MPLS Flex-Algo, or RSVP-TE.
The encapsulation and forwarding of SRv6 service packets (which are The encapsulation and forwarding of SRv6 service packets (which are
actually IPv6 packets) over an intra-domain MPLS LSP is based on the actually IPv6 packets) over an intra-domain MPLS LSP is based on the
MPLS mechanisms as defined in [RFC3031] [RFC3032] and [RFC8660]. The MPLS mechanisms as defined in [RFC3031], [RFC3032] and [RFC8660].
behavior is similar to that of 6PE [RFC4798]. The behavior is similar to that of IPv6 Provider Edge Routers (6PEs)
[RFC4798].
In AS1, the SR-MPLS Policy on PE1 for (ASBR11, C1) is represented In AS1, the SR-MPLS Policy on PE1 for (ASBR11, C1) is represented
with SID list <P1, ASBR11>. with the SID list <P1, ASBR11>.
In AS2, the SR-MPLS Flex-Algo on ASBR21 for (ASBR23, C1) is In AS2, the SR-MPLS Flex-Algo on ASBR21 for (ASBR23, C1) is
represented with SID list <ASBR23>. represented with SID list <ASBR23>.
In AS3, the SR-MPLS Policy on ASBR31 for (PE3, C1) is represented In AS3, the SR-MPLS Policy on ASBR31 for (PE3, C1) is represented
with SID list <P3, PE3>. with SID list <P3, PE3>.
C-pkt is the customer packet PE-1 received from its attaching CE. C-pkt is the customer packet PE-1 received from its attaching CE.
For packets which belong to an SRv6 VPN service associated with the For packets that belong to an SRv6 VPN service associated with the
SRv6 Service SID PE3:CL1.DT6, the packet encapsulation and forwarding SRv6 Service SID PE3:CL1.DT6, the packet encapsulation and forwarding
process is shown as below: process is shown as below:
PE1-> P1: Label-stack(P1, ASBR11)(PE1, PE3:CL1.DT6)(C-pkt) PE1-> P1: Label-stack(P1, ASBR11)(PE1, PE3:CL1.DT6)(C-pkt)
P1->ASBR11: Label-stack(ASBR11)(PE1, PE3:CL1.DT6)(C-pkt) P1->ASBR11: Label-stack(ASBR11)(PE1, PE3:CL1.DT6)(C-pkt)
ASBR11->ASBR21: (PE1, PE3:CL1.DT6)(C-pkt) ASBR11->ASBR21: (PE1, PE3:CL1.DT6)(C-pkt)
ASBR21->P2: Label-stack(ASBR23)(PE1, PE3:CL1.DT6)(C-pkt) ASBR21->P2: Label-stack(ASBR23)(PE1, PE3:CL1.DT6)(C-pkt)
P2->ASBR23: Label-stack(ASBR23)(PE1, PE3:CL1.DT6)(C-pkt) P2->ASBR23: Label-stack(ASBR23)(PE1, PE3:CL1.DT6)(C-pkt)
ASBR23->ASBR31: (PE1, PE3:CL1.DT6)(C-pkt) ASBR23->ASBR31: (PE1, PE3:CL1.DT6)(C-pkt)
ASBR31->P3: Label-stack(P3, PE3)(PE1, PE3:CL1.DT6)(C-pkt) ASBR31->P3: Label-stack(P3, PE3)(PE1, PE3:CL1.DT6)(C-pkt)
P3->PE3: Label-stack(PE3)(PE1, PE3:CL1.DT6)(C-pkt) P3->PE3: Label-stack(PE3)(PE1, PE3:CL1.DT6)(C-pkt)
Figure 3
4. Operational Considerations 4. Operational Considerations
The CPR mechanism can be used in network scenarios where multiple The CPR mechanism can be used in network scenarios where multiple
inter-connected ASes belong to the same operator, or there is an inter-connected ASes belong to the same operator, or where there is
operational trust model between the ASes of different operators which an operational trust model between the ASes of different operators
makes them belonging to the same trusted domain (in the sense used by which means they belong to the same trusted domain (in the sense used
Section 8 of [RFC8402]). by Section 8 of [RFC8402]).
As described in section 5 of As described in Section 5 of [INTENTAWARE], inter-domain intent-aware
[I-D.hr-spring-intentaware-routing-using-color], the inter-domain routing may be achieved with a logical tunnel created by an SR Policy
intent-aware routing may be achieved with a logical tunnel created by that applies to multiple ASes. In addition, service traffic with
an SR Policy across multiple ASes, and service traffic with specific specific intent can be steered to the inter-domain SR Policy based on
intent can be steered to the inter-domain SR Policy based on the the intent signaled by Color Extended Community. An operator may
intent signaled by Color Extended Community. An operator may prefer prefer a BGP routing-based solution for the reasons described in
a BGP routing based solution for the reasons described in [INTENTAWARE]. The operator may also consider the availability of an
[I-D.hr-spring-intentaware-routing-using-color]. Another possible inter-domain controller for end-to-end intent-aware path computation.
consideration of the operator is the availability of inter-domain This document proposes an alternate solution to signal the intent
controller for end-to-end intent-aware path computation. This with IPv6 Colored Prefixes using BGP.
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 When Colored Prefixes are assigned as sub-locators of the node's base
node's base SRv6 locator, the IPv6 unicast route of the base locator SRv6 locator, the IPv6 unicast route of the base locator prefix is
prefix is the covering prefix of all the Colored locator prefixes. the prefix that covers all of the Colored locator prefixes. To make
To make sure the Colored locator prefixes can be distributed to the sure the Colored locator prefixes can be distributed to the ingress
ingress PE nodes along the border nodes, it is required that the PE nodes along the border nodes, it is required that route
route aggregation be disabled for IPv6 unicast routes which carry the aggregation be disabled for IPv6 unicast routes that carry the Color
color extended community. Extended Community.
With CPR mechanism, at the prefix originator, each colored prefix is With the CPR mechanism, at the prefix originator, each Colored Prefix
associated with one specific intent (i.e. color). And in each is associated with one specific intent (i.e., color). In each
domain, according to the color mapping policy, the same CPR route is domain, according to the color mapping policy, the same CPR route is
always updated with the same color. The case where there are always updated with the same color. The case where there are
multiple copies of CPR routes with the same colored prefix but multiple copies of CPR routes with the same Colored Prefix but
different color extened commuity is considered a misconfiguration. different Color Extended Community is considered a misconfiguration.
All the border nodes and the ingress PE nodes need to install the All the border nodes and the ingress PE nodes need to install the
Colored locator prefixes into the RIB and FIB. For transit domains Colored locator prefixes in the RIB and FIB. For transit domains
which support the CPR mechanism, the border nodes can use the tuple that support the CPR mechanism, the border nodes can use the tuple
(N, C) where N is next hop and C is color, to resolve the CPR routes (N, C), where N is the next hop and C is the color, to resolve the
to intent-aware intra-domain paths. For transit domains which do not CPR routes to intent-aware intra-domain paths. For transit domains
support the CPR mechanism, the border nodes would ignore the color that do not support the CPR mechanism, the border nodes would ignore
extended community and resolve the CPR routes over a best-effort the Color Extended Community and resolve the CPR routes over a best-
intra-domain path to the next-hop N, while the CPR route will be effort intra-domain path to the next-hop N, while the CPR route will
advertised further to the downstream domains with only the next-hop be advertised further to the downstream domains with only the next
changed to itself. This allows the CPR routes to be resolved to hop changed to itself. This allows the CPR routes to resolve to
intent-aware intra-domain paths in any autonomous systems that intent-aware intra-domain paths in any autonomous systems that
support the CPR mechanism, while can fall back to resolve over best- support the CPR mechanism, while the CPR routes can fall back to
effort intra-domain path in the legacy autonomous systems. resolve over best-effort intra-domain paths in the legacy autonomous
systems.
There may be multiple inter-domain links between the adjacent There may be multiple inter-domain links between the adjacent
autonomous systems, and a border node BGP speaker may receive CPR autonomous systems, and a border node BGP speaker may receive CPR
routes from multiple peering BGP speakers in another domain via EBGP. routes from multiple peering BGP speakers in another domain via
The local policy of a BGP speaker may take the attributes of the External BGP (EBGP). The local policy of a BGP speaker may take the
inter-domain links and the attributes of the received CPR routes into attributes of the inter-domain links and the attributes of the
consideration when selecting the best path for specific Colored received CPR routes into consideration when selecting the best path
Prefixes to better meet the intent. The detailed local policy is for specific Colored Prefixes to better meet the intent. The
outside the scope of this document. In a multi-AS environment, the detailed local policy is outside the scope of this document. In a
policy of BGP speakers in different domains needs to be consistent. multi-AS environment, the policy of BGP speakers in different domains
needs to be consistent.
In this document, IPv6 Unicast Address Family is used for the In this document, the IPv6 Unicast Address Family is used for the
advertisement of IPv6 Colored Prefixes. The primary advantage of advertisement of IPv6 Colored Prefixes. The primary advantage of
this approach is the improved interoperability with legacy networks this approach is the improved interoperability with legacy networks
that lack support for intent-aware paths, and the facilitation of that lack support for intent-aware paths, and the facilitation of
incremental deployment of intent-aware routing mechanisms. One incremental deployment of intent-aware routing mechanisms. One
potential concern arises regarding the necessity of separating potential concern arises regarding the need to separate Colored
Colored Prefixes from public IPv6 unicast routes. Since the IP Prefixes from public IPv6 unicast routes. Because the IP prefixes
prefixes and SRv6 locators of network infrastructure are usually and SRv6 locators of network infrastructure are usually advertised as
advertised as part of the IP unicast routes, and appropriate filters part of the IP unicast routes, and appropriate filters are configured
are configured at the boundaries of network administration, this is at the boundaries of network administration, this concern is not
not considered to be a significant issue. [RFC9602] allocates the considered to be a significant issue. [RFC9602] allocates the prefix
prefix 5f00::/16 for SRv6 SIDs, by common agreement among 5f00::/16 for SRv6 SIDs. By common agreement among participants in
participants in the trusted domain, the filters can be configured to the trusted domain, the filters can be configured to by default drop
by default drop all traffic from 5f00::/16 but permit the colored all traffic from 5f00::/16 but permit the Colored Prefixes in use in
prefixes in use in these domains. The proposal in these domains. The proposal in [BGP-CAR] provides a complementary
[I-D.ietf-idr-bgp-car] provides a complementary solution that is also solution that is also based on the notion of color indicating the
based on the notion of color indicating the intent and where the SRv6 intent and where the SRv6 Locator prefix itself signifies the intent;
Locator prefix itself signifies the intent, the difference is that a the difference is that a separate SAFI is used.
separate SAFI is used.
[I-D.ietf-idr-bgp-ct] describes another mechanism for intent-aware [BGP-CT] describes another mechanism for intent-aware routing, in
routing, in which the SRv6 service SIDs are not directly associated which the SRv6 service SIDs are not directly associated with the
with the intent, while additional SRv6 transport SIDs are required intent (additional SRv6 transport SIDs are required to steer traffic
for steering traffic to the inter-domain intent-aware paths, and an to the inter-domain intent-aware paths), and an SRv6 operation
SRv6 operation similar to MPLS label swapping is needed on the border similar to MPLS label swapping is needed on the border nodes of
nodes of autonomous systems. autonomous systems.
5. IANA Considerations 5. IANA Considerations
This document makes no request of IANA. This document has no IANA actions.
6. Security Considerations 6. Security Considerations
The mechanism described in this document provides an approach for The mechanism described in this document provides an approach for
inter-domain intent-aware routing based on existing BGP protocol inter-domain intent-aware routing based on existing BGP protocol
mechanisms. The existing BGP IPv6 Unicast Address Family and mechanisms. The existing BGP IPv6 Unicast Address Family and
existing Color extended community are reused without further BGP existing Color Extended Community are reused without further BGP
extensions. With this approach, the number of IPv6 Colored Prefixes extensions. With this approach, the number of IPv6 Colored Prefixes
advertised by PE nodes is in proportion to the number of intents it advertised by PE nodes is proportionate to the number of intents it
supports. This may introduce additional routes to BGP IPv6 routing supports. This may introduce additional routes to the BGP IPv6
table. While since these are infrastructure routes, the amount of routing table. Because these are infrastructure routes, the number
Colored Prefixes is only a small portion of the total amount of IPv6 of Colored Prefixes is only a small portion of the total amount of
prefixes. Thus it is considered that the impact to the required IPv6 prefixes. Thus, the impact to the required routing table size
routing table size is acceptable. is considered acceptable.
As the CPR routes are distributed across multiple ASes which belong As the CPR routes are distributed across multiple ASes that belong to
to a trusted domain, the mapping relationship between the intent and a trusted domain, the mapping relationship between the intent and the
the IPv6 Colored Prefixes are observable to BGP nodes in those ASes. IPv6 Colored Prefixes are observable to BGP nodes in those ASes. It
It is possible for an on-path attacker in the trusted domain to is possible for an on-path attacker in the trusted domain to identify
identify packets associated with a particular intent. packets associated with a particular intent.
The security considerations as described in [RFC4271] [RFC4272] and The security considerations as described in [RFC4271], [RFC4272], and
[RFC8754] apply to this document. [RFC8754] apply to this document.
7. Contributing Authors 7. References
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 7.1. Normative References
[RFC2545] Marques, P. and F. Dupont, "Use of BGP-4 Multiprotocol [RFC2545] Marques, P. and F. Dupont, "Use of BGP-4 Multiprotocol
Extensions for IPv6 Inter-Domain Routing", RFC 2545, Extensions for IPv6 Inter-Domain Routing", RFC 2545,
DOI 10.17487/RFC2545, March 1999, DOI 10.17487/RFC2545, March 1999,
<https://www.rfc-editor.org/info/rfc2545>. <https://www.rfc-editor.org/info/rfc2545>.
[RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A
Border Gateway Protocol 4 (BGP-4)", RFC 4271, Border Gateway Protocol 4 (BGP-4)", RFC 4271,
DOI 10.17487/RFC4271, January 2006, DOI 10.17487/RFC4271, January 2006,
<https://www.rfc-editor.org/info/rfc4271>. <https://www.rfc-editor.org/info/rfc4271>.
skipping to change at page 13, line 27 skipping to change at line 556
B., Zhuang, S., and J. Rabadan, "BGP Overlay Services B., Zhuang, S., and J. Rabadan, "BGP Overlay Services
Based on Segment Routing over IPv6 (SRv6)", RFC 9252, Based on Segment Routing over IPv6 (SRv6)", RFC 9252,
DOI 10.17487/RFC9252, July 2022, DOI 10.17487/RFC9252, July 2022,
<https://www.rfc-editor.org/info/rfc9252>. <https://www.rfc-editor.org/info/rfc9252>.
[RFC9256] Filsfils, C., Talaulikar, K., Ed., Voyer, D., Bogdanov, [RFC9256] Filsfils, C., Talaulikar, K., Ed., Voyer, D., Bogdanov,
A., and P. Mattes, "Segment Routing Policy Architecture", A., and P. Mattes, "Segment Routing Policy Architecture",
RFC 9256, DOI 10.17487/RFC9256, July 2022, RFC 9256, DOI 10.17487/RFC9256, July 2022,
<https://www.rfc-editor.org/info/rfc9256>. <https://www.rfc-editor.org/info/rfc9256>.
9.2. Informative References 7.2. Informative References
[I-D.hr-spring-intentaware-routing-using-color] [BGP-CAR] Rao, D., Ed. and S. Agrawal, Ed., "BGP Color-Aware Routing
(CAR)", Work in Progress, Internet-Draft, draft-ietf-idr-
bgp-car-16, 20 February 2025,
<https://datatracker.ietf.org/doc/html/draft-ietf-idr-bgp-
car-16>.
[BGP-CT] Vairavakkalai, K., Ed. and N. Venkataraman, Ed., "BGP
Classful Transport Planes", Work in Progress, Internet-
Draft, draft-ietf-idr-bgp-ct-39, 28 February 2025,
<https://datatracker.ietf.org/doc/html/draft-ietf-idr-bgp-
ct-39>.
[INTENTAWARE]
Hegde, S., Rao, D., Uttaro, J., Bogdanov, A., and L. Hegde, S., Rao, D., Uttaro, J., Bogdanov, A., and L.
Jalil, "Problem statement for Inter-domain Intent-aware Jalil, "Problem statement for Inter-domain Intent-aware
Routing using Color", Work in Progress, Internet-Draft, Routing using Color", Work in Progress, Internet-Draft,
draft-hr-spring-intentaware-routing-using-color-04, 31 draft-hr-spring-intentaware-routing-using-color-04, 31
January 2025, <https://datatracker.ietf.org/doc/html/ January 2025, <https://datatracker.ietf.org/doc/html/
draft-hr-spring-intentaware-routing-using-color-04>. draft-hr-spring-intentaware-routing-using-color-04>.
[I-D.ietf-idr-bgp-car]
Rao, D. and S. Agrawal, "BGP Color-Aware Routing (CAR)",
Work in Progress, Internet-Draft, draft-ietf-idr-bgp-car-
16, 20 February 2025,
<https://datatracker.ietf.org/doc/html/draft-ietf-idr-bgp-
car-16>.
[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-38, 19 February 2025,
<https://datatracker.ietf.org/doc/html/draft-ietf-idr-bgp-
ct-38>.
[I-D.ietf-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-ietf-spring-srv6-mpls-
interworking-00, 17 October 2024,
<https://datatracker.ietf.org/doc/html/draft-ietf-spring-
srv6-mpls-interworking-00>.
[RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol
Label Switching Architecture", RFC 3031, Label Switching Architecture", RFC 3031,
DOI 10.17487/RFC3031, January 2001, DOI 10.17487/RFC3031, January 2001,
<https://www.rfc-editor.org/info/rfc3031>. <https://www.rfc-editor.org/info/rfc3031>.
[RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., [RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y.,
Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack
Encoding", RFC 3032, DOI 10.17487/RFC3032, January 2001, Encoding", RFC 3032, DOI 10.17487/RFC3032, January 2001,
<https://www.rfc-editor.org/info/rfc3032>. <https://www.rfc-editor.org/info/rfc3032>.
skipping to change at page 14, line 44 skipping to change at line 609
Decraene, B., Litkowski, S., and R. Shakir, "Segment Decraene, B., Litkowski, S., and R. Shakir, "Segment
Routing with the MPLS Data Plane", RFC 8660, Routing with the MPLS Data Plane", RFC 8660,
DOI 10.17487/RFC8660, December 2019, DOI 10.17487/RFC8660, December 2019,
<https://www.rfc-editor.org/info/rfc8660>. <https://www.rfc-editor.org/info/rfc8660>.
[RFC9602] Krishnan, S., "Segment Routing over IPv6 (SRv6) Segment [RFC9602] Krishnan, S., "Segment Routing over IPv6 (SRv6) Segment
Identifiers in the IPv6 Addressing Architecture", Identifiers in the IPv6 Addressing Architecture",
RFC 9602, DOI 10.17487/RFC9602, October 2024, RFC 9602, DOI 10.17487/RFC9602, October 2024,
<https://www.rfc-editor.org/info/rfc9602>. <https://www.rfc-editor.org/info/rfc9602>.
[SRv6-INTERWORK]
Agrawal, S., Ed., Filsfils, C., Voyer, D., Dawra, G., Li,
Z., and S. Hegde, "SRv6 and MPLS interworking", Work in
Progress, Internet-Draft, draft-ietf-spring-srv6-mpls-
interworking-00, 17 October 2024,
<https://datatracker.ietf.org/doc/html/draft-ietf-spring-
srv6-mpls-interworking-00>.
Acknowledgements
The authors would like to thank Shunwan Zhuang, Zhibo Hu, Zhenbin Li,
Dhananjaya Rao, and Dhruv Dhody for their reviews and valuable
discussion.
Contributors
The following people contributed significantly to the content of this
document and should be considered co-authors:
Xinjun Chen
Email: ifocus.chen@huawei.com
Jingrong Xie
Email: xiejingrong@huawei.com
Zhenqiang Li
Email: li_zhenqiang@hotmail.com
Authors' Addresses Authors' Addresses
Haibo Wang Haibo Wang
Huawei Technologies Huawei Technologies
China China
Email: rainsword.wang@huawei.com Email: rainsword.wang@huawei.com
Jie Dong Jie Dong
Huawei Technologies Huawei Technologies
China China
Email: jie.dong@huawei.com Email: jie.dong@huawei.com
Ketan Talaulikar Ketan Talaulikar
Cisco Systems Cisco Systems
India India
Email: ketant.ietf@gmail.com Email: ketant.ietf@gmail.com
 End of changes. 72 change blocks. 
283 lines changed or deleted 293 lines changed or added

This html diff was produced by rfcdiff 1.48.