Skip to main content

BGP Colored Prefix Routing (CPR) for SRv6 based Services
draft-ietf-idr-cpr-02

Document Type Active Internet-Draft (idr WG)
Authors Haibo Wang , Jie Dong , Ketan Talaulikar , hantao , Ran Chen
Last updated 2024-05-18 (Latest revision 2024-05-15)
Replaces draft-wang-idr-cpr
RFC stream Internet Engineering Task Force (IETF)
Intended RFC status Informational
Formats
Reviews
Additional resources Mailing list discussion
Stream WG state In WG Last Call
Document shepherd Susan Hares
Shepherd write-up Show Last changed 2024-05-18
IESG IESG state I-D Exists
Consensus boilerplate Unknown
Telechat date (None)
Responsible AD (None)
Send notices to shares@ndzh.com
draft-ietf-idr-cpr-02
Interdomain Routing Working Group                                H. Wang
Internet-Draft                                                   J. Dong
Intended status: Informational                       Huawei Technologies
Expires: 17 November 2024                                  K. Talaulikar
                                                           Cisco Systems
                                                                  T. Han
                                                     Huawei Technologies
                                                                 R. Chen
                                                         ZTE Corporation
                                                             16 May 2024

        BGP Colored Prefix Routing (CPR) for SRv6 based Services
                         draft-ietf-idr-cpr-02

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 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.  In the data
   plane, dedicated transport labels or SIDs for the inter-domain path
   are not needed, thus 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.

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

Wang, et al.            Expires 17 November 2024                [Page 1]
Internet-Draft          BGP CPR for SRv6 Services               May 2024

   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 17 November 2024.

Copyright Notice

   Copyright (c) 2024 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  . . . . . . . . . . . . . . . . . . . . . . . .   3
   2.  BGP CPR . . . . . . . . . . . . . . . . . . . . . . . . . . .   4
     2.1.  Colored Prefix Allocation . . . . . . . . . . . . . . . .   4
     2.2.  Colored Prefix Advertisement  . . . . . . . . . . . . . .   5
     2.3.  CPR to Intra-domain Path Resolution . . . . . . . . . . .   6
     2.4.  SRv6 Service Route Advertisement  . . . . . . . . . . . .   7
     2.5.  SRv6 Service Steering . . . . . . . . . . . . . . . . . .   7
   3.  Encapsulation and Forwarding Processes  . . . . . . . . . . .   7
     3.1.  CPR over SRv6 Intra-Domain Paths  . . . . . . . . . . . .   7
     3.2.  CPR over MPLS Intra-Domain Paths  . . . . . . . . . . . .   8
   4.  Operational Considerations  . . . . . . . . . . . . . . . . .   9
   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  10
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .  11
   7.  Contributing Authors  . . . . . . . . . . . . . . . . . . . .  11
   8.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  11
   9.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  11
     9.1.  Normative References  . . . . . . . . . . . . . . . . . .  11
     9.2.  Informative References  . . . . . . . . . . . . . . . . .  12
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  14

Wang, et al.            Expires 17 November 2024                [Page 2]
Internet-Draft          BGP CPR for SRv6 Services               May 2024

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.

Wang, et al.            Expires 17 November 2024                [Page 3]
Internet-Draft          BGP CPR for SRv6 Services               May 2024

   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.

Wang, et al.            Expires 17 November 2024                [Page 4]
Internet-Draft          BGP CPR for SRv6 Services               May 2024

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.

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

Wang, et al.            Expires 17 November 2024                [Page 5]
Internet-Draft          BGP CPR for SRv6 Services               May 2024

   *  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 ASBR 24 advertise the CPR routes further in AS2 with
      the next-hop set to itself.

   *  The behavior of ASBR21 and ASBR22 are similar to the behavior of
      ASBR31 and ASBR32.

   *  The behavior of ASBR11 and ASBR12 are similar to 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.
   While in some special cases, one intent may be represented as
   different color value in different domains, then the Color Extended
   Community in the CPR routes may be updated at the border nodes of the
   domains 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:

   *  SRv6 or SR-MPLS Policy

   *  SRv6 or SR-MPLS Flex-Algo

   *  RSVP-TE

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

Wang, et al.            Expires 17 November 2024                [Page 6]
Internet-Draft          BGP CPR for SRv6 Services               May 2024

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

Wang, et al.            Expires 17 November 2024                [Page 7]
Internet-Draft          BGP CPR for SRv6 Services               May 2024

   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.Insert.Red behavior 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  : (PE1, P2)(PE3:CL1.DT::, BR23; SL=2)(C-pkt)
   P2  ->BR23: (PE1, BR23)(PE3:CL1.DT::, BR23; SL=1)(C-pkt)
   BR23->BR31: (PE1, PE3:CL1.DT::)(C-pkt)
   BR31->P3  : (PE1, P3)(PE3:CL1.DT::, PE3; SL=2)(C-pkt)
   P3  ->PE3 : (PE1, PE3)(PE3:CL1.DT::, PE3; SL=1)(C-pkt)

   The packet encapsulation and forwarding process using H.Encaps.Red
   behavior 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].

Wang, et al.            Expires 17 November 2024                [Page 8]
Internet-Draft          BGP CPR for SRv6 Services               May 2024

   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 SR Policy across multiple
   domains, and services with specific intent can be steered to SR
   Policy at the ingress domain based on Color.  While an operator may
   prefer a BGP-based solution for the reasons described there.  Another
   possible consideration of the operator is the availability of inter-
   domain controller for end-to-end path computation.

   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

Wang, et al.            Expires 17 November 2024                [Page 9]
Internet-Draft          BGP CPR for SRv6 Services               May 2024

   (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 network domains,. A
   border node may receive CPR routes from multiple peering border
   nodes.  Then the border node may take the attributes of the inter-
   domain links and/or the attributes of the received CPR routes into
   consideration to select the best path for specific Colored Prefixes
   to better meet the intent.  The detailed mechanism is up to the
   operator's policy.

   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.

Wang, et al.            Expires 17 November 2024               [Page 10]
Internet-Draft          BGP CPR for SRv6 Services               May 2024

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.  The
   proposed mechanism does not introduce any additional security
   considerations than those described in [RFC4271] and [RFC4272].

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

Wang, et al.            Expires 17 November 2024               [Page 11]
Internet-Draft          BGP CPR for SRv6 Services               May 2024

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

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, 4 March 2024,
              <https://datatracker.ietf.org/doc/html/draft-agrawal-
              spring-srv6-mpls-interworking-14>.

Wang, et al.            Expires 17 November 2024               [Page 12]
Internet-Draft          BGP CPR for SRv6 Services               May 2024

   [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, 23
              October 2023, <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, 26 April 2024,
              <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, 26 April 2024,
              <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, 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>.

Wang, et al.            Expires 17 November 2024               [Page 13]
Internet-Draft          BGP CPR for SRv6 Services               May 2024

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

Wang, et al.            Expires 17 November 2024               [Page 14]