



Internet Engineering Task Force (IETF)                           H. Wang
Request for Comments: 9723                                       J. Dong
Category: Informational                              Huawei Technologies
ISSN: 2070-1721                                            K. Talaulikar
                                                           Cisco Systems
                                                                  T. Han
                                                     Huawei Technologies
                                                                 R. Chen
                                                         ZTE Corporation
                                                                May 2025


 BGP Colored Prefix Routing (CPR) for Services Based on Segment Routing
                            over IPv6 (SRv6)

Abstract

   This document describes a mechanism to advertise IPv6 prefixes in BGP
   that 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 intents.  SRv6 services (e.g., SRv6 VPN services) with a
   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 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
   to advertise IPv6 Colored Prefixes without new BGP extensions; thus,
   this mechanism is easy to interoperate and can be deployed
   incrementally in multi-Autonomous System (AS) networks that belong to
   the same trusted domain.

Status of This Memo

   This document is not an Internet Standards Track specification; it is
   published for informational purposes.

   This document is a product of the Internet Engineering Task Force
   (IETF).  It represents the consensus of the IETF community.  It has
   received public review and has been approved for publication by the
   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.

   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 (c) 2025 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (https://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Revised BSD License text as described in Section 4.e of the
   Trust Legal Provisions and are provided without warranty as described
   in the Revised BSD License.

Table of Contents

   1.  Introduction
   2.  BGP CPR
     2.1.  Colored Prefix Allocation
     2.2.  Colored Prefix Advertisement
     2.3.  CPR to Intra-Domain Path Resolution
     2.4.  SRv6 Service Route Advertisement
     2.5.  SRv6 Service Steering
   3.  Encapsulation and Forwarding Process
     3.1.  CPR over SRv6 Intra-Domain Paths
     3.2.  CPR over MPLS Intra-Domain Paths
   4.  Operational Considerations
   5.  IANA Considerations
   6.  Security Considerations
   7.  References
     7.1.  Normative References
     7.2.  Informative References
   Acknowledgements
   Contributors
   Authors' Addresses

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 the "intent" of
   the service or customer, which is represented as an abstract notion
   called "color".

   In network scenarios where the services are delivered across multiple
   Autonomous Systems (ASes), there is a need to provide the services
   with different end-to-end paths to meet the intent.  [INTENTAWARE]
   describes the problem statements and requirements for inter-domain
   intent-aware routing.

   The inter-domain path can be established using either Multi-Protocol
   Label Switching (MPLS) or the IP data plane.  In MPLS-based networks,
   the usual inter-domain approach is to establish an end-to-end Label
   Switched Path (LSP) based on the mechanism defined in [RFC8277]
   (which is usually referred to as BGP-LU (BGP Labeled Unicast)).  Each
   domain's ingress border node needs to perform label swapping for the
   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
   advertised to network nodes in different domains using BGP, so that
   all the domain border nodes can obtain the routes to the IP prefixes
   of the destination nodes 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.  Inter-domain LSPs based on the BGP-LU mechanism are not
   necessary for IPv6- and SRv6-based networks.

   This document describes a mechanism to advertise IPv6 prefixes that
   are associated with the 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 intents.  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 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, resulting in smaller encapsulation overhead than with other
   options.

   The existing IPv6 Address Family and Color Extended Community could
   be reused to advertise IPv6 Colored Prefixes without new BGP
   extensions; thus, this mechanism is easy to interoperate and can be
   deployed incrementally in multi-AS networks that belong to the same
   trusted domain (in the sense used by Section 8 of [RFC8402]).

2.  BGP CPR

2.1.  Colored Prefix Allocation

   In SRv6 networks, an SRv6 locator needs to be allocated for each
   node.  In order to distinguish N different intents, a Provider Edge
   (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, whereby 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-AS IPv6 network, the mechanism for IPv6 unicast routing as
   defined in [RFC2545] is used for the advertisement of the Colored
   Prefix routes, in which the Address Family / Subsequent Address
   Family (AFI/SAFI = 2/1) is used.  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.

   *  PE3 originates BGP IPv6 unicast (AFI/SAFI=2/1) route for the
      Colored Prefixes PE3:CL1:: and PE3:CL2::. Each route should carry
      the corresponding Color Extended Community C1 or C2.  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.  Since 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.
      ASBR23 and ASBR24 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 the behavior of
      ASBR23 and ASBR24.

   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.  In some special cases, one intent may be represented as a
   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 the color "red", while the same intent is represented by color
   "blue" in AS2.  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 autonomous
   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
   intermediate domains; at the MPLS domain border nodes, some route
   resolution policy could be used to make the CPR routes resolve 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 [SRv6-INTERWORK].

2.3.  CPR to Intra-Domain Path Resolution

   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),
   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 Policy

   *  SR-MPLS Policy

   *  SRv6 Flex-Algo

   *  SR-MPLS Flex-Algo

   *  RSVP-TE

   For example, if PE1 receives a CPR route to PE3:CL1:: with the 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 that 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
   is 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 that receives the
   SRv6 service routes follows the behavior of SRv6 shortest path
   forwarding (refer to Sections 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 that encapsulates the service
   packet.  If the corresponding CPR route has been received and
   installed, longest prefix matching of SRv6 service SIDs to the
   Colored Prefixes is performed.  As a result of this prefix matching,
   the next hop found is an intra-domain color-aware path, which will be
   used for forwarding the SRv6 service traffic.  This process repeats
   at the border node of each domain the packet traverses, until it
   reaches its destination.

3.  Encapsulation and Forwarding Process

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

   The topology of Figure 1 is used in each example.

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 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".

   In AS1, the SRv6 Policy on PE1 for (ASBR11, C1) is represented with
   SID list <P1, ASBR11>.

   In AS2, the SRv6 Policy on ASBR21 for (ASBR23, C1) is represented
   with the SID list <P2, ASBR23>.

   In AS3, the SRv6 Policy on ASBR31 for (PE3, C1) is represented with
   the SID list <P3, PE3>.

   C-pkt is the customer packet PE1 received from its attaching CE.

   For packets that belong to an SRv6 VPN service associated with the
   SRv6 Service SID PE3:CL1.DT6, the packet encapsulation and forwarding
   process using H.Encaps.Red behavior [RFC8986] is shown as below:

   PE1 ->P1:           (PE1, P1)(PE3:CL1.DT6, ASBR11; SL=2)(C-pkt)
   P1 ->ASBR11:    (PE1, ASBR11)(PE3:CL1.DT6, ASBR11; SL=1)(C-pkt)
   ASBR11->ASBR21:                       (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)
   ASBR23->ASBR31:                       (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)

                                  Figure 2

   In some autonomous systems, 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 autonomous systems use the
   MPLS-based data plane, the CPR route can be resolved over a color-
   aware intra-domain MPLS LSP.  Such an 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 IPv6 Provider Edge Routers (6PEs)
   [RFC4798].

   In AS1, the SR-MPLS Policy on PE1 for (ASBR11, C1) is represented
   with the SID list <P1, ASBR11>.

   In AS2, the SR-MPLS Flex-Algo on ASBR21 for (ASBR23, C1) is
   represented with SID list <ASBR23>.

   In AS3, the SR-MPLS Policy on ASBR31 for (PE3, C1) is represented
   with SID list <P3, PE3>.

   C-pkt is the customer packet PE-1 received from its attaching CE.

   For packets that belong to an SRv6 VPN service associated with the
   SRv6 Service SID PE3:CL1.DT6, the packet encapsulation and forwarding
   process is shown as below:

   PE1-> P1: Label-stack(P1, 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)
   ASBR21->P2:   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)
   ASBR31->P3:  Label-stack(P3, PE3)(PE1, PE3:CL1.DT6)(C-pkt)
   P3->PE3:         Label-stack(PE3)(PE1, PE3:CL1.DT6)(C-pkt)

                                  Figure 3

4.  Operational Considerations

   The CPR mechanism can be used in network scenarios where multiple
   inter-connected ASes belong to the same operator, or where there is
   an operational trust model between the ASes of different operators
   which means they belong to the same trusted domain (in the sense used
   by Section 8 of [RFC8402]).

   As described in Section 5 of [INTENTAWARE], inter-domain intent-aware
   routing may be achieved with a logical tunnel created by an SR Policy
   that applies to multiple ASes.  In addition, 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
   [INTENTAWARE].  The operator may also consider the availability of an
   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 Colored Prefixes are assigned as sub-locators of the node's base
   SRv6 locator, the IPv6 unicast route of the base locator prefix is
   the prefix that covers all of 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 route
   aggregation be disabled for IPv6 unicast routes that carry the Color
   Extended Community.

   With the CPR mechanism, at the prefix originator, each Colored Prefix
   is associated with one specific intent (i.e., color).  In each
   domain, according to the color mapping policy, the same CPR route is
   always updated with the same color.  The case where there are
   multiple copies of CPR routes with the same Colored Prefix but
   different Color Extended Community is considered a misconfiguration.

   All the border nodes and the ingress PE nodes need to install the
   Colored locator prefixes in the RIB and FIB.  For transit domains
   that support the CPR mechanism, the border nodes can use the tuple
   (N, C), where N is the next hop and C is the color, to resolve the
   CPR routes to intent-aware intra-domain paths.  For transit domains
   that 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 resolve to
   intent-aware intra-domain paths in any autonomous systems that
   support the CPR mechanism, while the CPR routes can fall back to
   resolve over best-effort intra-domain paths in the legacy autonomous
   systems.

   There may be multiple inter-domain links between the adjacent
   autonomous systems, and a border node BGP speaker may receive CPR
   routes from multiple peering BGP speakers in another domain via
   External BGP (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-AS environment, the policy of BGP speakers in different domains
   needs to be consistent.

   In this document, the 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 need to separate Colored
   Prefixes from public IPv6 unicast routes.  Because 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 concern is not
   considered to be a significant issue.  [RFC9602] allocates the prefix
   5f00::/16 for SRv6 SIDs.  By common agreement among participants in
   the trusted domain, the filters can be configured to by default drop
   all traffic from 5f00::/16 but permit the Colored Prefixes in use in
   these domains.  The proposal in [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.

   [BGP-CT] describes another mechanism for intent-aware routing, in
   which the SRv6 service SIDs are not directly associated with the
   intent (additional SRv6 transport SIDs are required to steer traffic
   to the inter-domain intent-aware paths), and an SRv6 operation
   similar to MPLS label swapping is needed on the border nodes of
   autonomous systems.

5.  IANA Considerations

   This document has no IANA actions.

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 proportionate to the number of intents it
   supports.  This may introduce additional routes to the BGP IPv6
   routing table.  Because these are infrastructure routes, the number
   of Colored Prefixes is only a small portion of the total amount of
   IPv6 prefixes.  Thus, the impact to the required routing table size
   is considered acceptable.

   As the CPR routes are distributed across multiple ASes that belong to
   a trusted domain, the mapping relationship between the intent and the
   IPv6 Colored Prefixes are observable to BGP nodes in those ASes.  It
   is possible for an on-path attacker in the trusted domain to identify
   packets associated with a particular intent.

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

7.  References

7.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, March 1999,
              <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, January 2006,
              <https://www.rfc-editor.org/info/rfc4271>.

   [RFC4272]  Murphy, S., "BGP Security Vulnerabilities Analysis",
              RFC 4272, DOI 10.17487/RFC4272, January 2006,
              <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,
              July 2018, <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, March 2020,
              <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, February 2021,
              <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, April 2021,
              <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, July 2022,
              <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, July 2022,
              <https://www.rfc-editor.org/info/rfc9256>.

7.2.  Informative References

   [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.
              Jalil, "Problem statement for Inter-domain Intent-aware
              Routing using Color", Work in Progress, Internet-Draft,
              draft-hr-spring-intentaware-routing-using-color-04, 31
              January 2025, <https://datatracker.ietf.org/doc/html/
              draft-hr-spring-intentaware-routing-using-color-04>.

   [RFC3031]  Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol
              Label Switching Architecture", RFC 3031,
              DOI 10.17487/RFC3031, January 2001,
              <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, January 2001,
              <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, February 2007,
              <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, October 2017,
              <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, December 2019,
              <https://www.rfc-editor.org/info/rfc8660>.

   [RFC9602]  Krishnan, S., "Segment Routing over IPv6 (SRv6) Segment
              Identifiers in the IPv6 Addressing Architecture",
              RFC 9602, DOI 10.17487/RFC9602, October 2024,
              <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

   Haibo Wang
   Huawei Technologies
   China
   Email: rainsword.wang@huawei.com


   Jie Dong
   Huawei Technologies
   China
   Email: jie.dong@huawei.com


   Ketan Talaulikar
   Cisco Systems
   India
   Email: ketant.ietf@gmail.com


   Tao Han
   Huawei Technologies
   China
   Email: hantao@huawei.com


   Ran Chen
   ZTE Corporation
   China
   Email: chen.ran@zte.com.cn
