<?xml version="1.0" encoding="US-ASCII"?> version='1.0' encoding='UTF-8'?>

<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?> [
  <!ENTITY nbsp    "&#160;">
  <!ENTITY zwsp   "&#8203;">
  <!ENTITY nbhy   "&#8209;">
  <!ENTITY wj     "&#8288;">
]>

<rfc xmlns:xi="http://www.w3.org/2001/XInclude" category="info" docName="draft-ietf-idr-cpr-08" ipr="trust200902"> number="9723" ipr="trust200902" consensus="true" obsoletes="" updates="" submissionType="IETF" xml:lang="en" tocInclude="true" tocDepth="3" symRefs="true" sortRefs="true" version="3">

  <front>
    <title abbrev="BGP CPR for SRv6 Services">BGP Colored Prefix Routing (CPR)
    for SRv6 based SRv6-Based Services</title>
    <seriesInfo name="RFC" value="9723"/>
    <author fullname="Haibo Wang" initials="H." surname="Wang">
      <organization>Huawei Technologies</organization>
      <address>
        <postal>
          <street/>

          <city/>

          <region/>

          <code/>
          <country>China</country>
        </postal>
        <email>rainsword.wang@huawei.com</email>
      </address>
    </author>
    <author fullname="Jie Dong" initials="J." surname="Dong">
      <organization>Huawei Technologies</organization>
      <address>
        <postal>
          <street/>

          <city/>

          <region/>

          <code/>
          <country>China</country>
        </postal>
        <email>jie.dong@huawei.com</email>
      </address>
    </author>
    <author fullname="Ketan Talaulikar" initials="K." surname="Talaulikar ">
      <organization>Cisco Systems</organization>
      <address>
        <postal>
          <street/>

          <city/>

          <region/>

          <code/>
          <country>India</country>
        </postal>
        <email>ketant.ietf@gmail.com</email>
      </address>
    </author>
    <author fullname="Tao Han" initials="T." surname="Han">
      <organization>Huawei Technologies</organization>
      <address>
        <postal>
          <street/>

          <city/>

          <code/>
          <country>China</country>
        </postal>
        <email>hantao@huawei.com</email>
      </address>
    </author>
    <author fullname="Ran Chen" initials="R." surname="Chen">
      <organization>ZTE Corporation</organization>
      <address>
        <postal>
          <street/>

          <city/>

          <region/>

          <code/>
          <country>China</country>
        </postal>
        <email>chen.ran@zte.com.cn</email>
      </address>
    </author>
    <date day="24" month="February" month="May" year="2025"/>

    <area>Routing Area</area>

    <workgroup>Interdomain Routing Working Group</workgroup>

    <area>RTG</area>
    <workgroup>idr</workgroup>

<!-- [rfced] Please insert any keywords (beyond those that appear in
the title) for use on https://www.rfc-editor.org/search. -->

<keyword>example</keyword>

    <abstract>
      <t>This document describes a mechanism to advertise IPv6 prefixes in BGP
      which
      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 "Colored Prefix Routing Routing" (CPR). In SRv6 networks, the
      Colored prefixes Prefixes are the SRv6 locators associated with different intent. intents.
      SRv6 services (e.g. (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.</t> Prefixes.</t>
      <t>This operational methodology allows the SRv6 service traffic to be
      steered into end-to-end intent-aware paths simply based on the longest
      prefix matching of SRv6 Service SIDs to the Colored prefixes. Prefixes. The
      existing IPv6 Address Family and Color Extended Community are reused for
      the advertisement of to
      advertise IPv6 Colored prefixes Prefixes without new BGP extensions,
      thus extensions;
      thus, this mechanism is easy to interoperate and can be deployed
      incrementally in multi-Autonomous System (AS) networks which that belong to
      the same trusted domain.</t>
    </abstract>
  </front>
  <middle>
    <section title="Introduction"> numbered="true" toc="default">
      <name>Introduction</name>
      <t>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 which is represented as an abstract notion called
      "color".</t>
      <t>In network scenarios where the services are delivered across multiple
      Autonomous Systems (ASes) , (ASes), there is a need to provide the services with
      different end-to-end paths to meet the intent. <xref
      target="I-D.hr-spring-intentaware-routing-using-color"/> target="I-D.hr-spring-intentaware-routing-using-color" format="default"/> describes the
      problem statements and requirements for inter-domain intent-aware
      routing.</t>
<!-- [rfced] RFC 8277 doesn't appear to use the term "BGP Labeled Unicast" or "BGP-LU."  For clarity, may we add text to draw a more clear connection, for example, "the mechanism described in RFC 8277 is referred to BGP-LU although that term does not actually appear in the document."

Original:
   The inter-domain path can be established using either Multi-Protocol
   Label Switching (MPLS) or 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 BGP Labeled Unicast (BGP-LU)
   mechanism as defined in [RFC8277].
-->
      <t>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 Label Switched
      Path (LSP) based on the BGP Labeled Unicast (BGP-LU) mechanism as
      defined in <xref target="RFC8277"/>. target="RFC8277" format="default"/>. Each domain's ingress border node
      needs to perform label swapping for the end-to-end LSP, and impose the
      label stack which that is used for the LSP within its own domain.</t>
      <t>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 <xref
      target="RFC8402"/> target="RFC8402" format="default"/> <xref target="RFC8754"/> target="RFC8754" format="default"/> <xref target="RFC8986"/>, target="RFC8986" format="default"/>,
      BGP services are assigned with SRv6 Service SIDs <xref
      target="RFC9252"/>, target="RFC9252" format="default"/>, 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 prefix. Inter-domain
      LSPs based on the BGP-LU mechanism is are not necessary for IPv6 IPv6- and SRv6-based
      networks.</t>
      <t>This document describes a mechanism to advertise IPv6 prefixes which 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 <xref target="RFC9256"/>. target="RFC9256" format="default"/>. 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. intents. BGP
      services over SRv6 (e.g. (e.g., SRv6 VPN services) <xref target="RFC9252"/> target="RFC9252" format="default"/>
      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
      <xref target="RFC9252"/>) target="RFC9252" format="default"/>) 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, resulting in smaller encapsulation
      overhead than with other options.</t>
      <t>The existing IPv6 Address Family and Color Extended Community could
      be reused for the advertisement of to advertise IPv6 Colored Prefixes without new BGP
      extensions, thus
      extensions; thus, this mechanism is easy to interoperate and can be
      deployed incrementally in multi-AS networks which that belong to the same
      trusted domain (in the sense used by Section 8 of <xref
      target="RFC8402"/>).</t> target="RFC8402" sectionFormat="of" section="8"/>).</t>
    </section>
    <section title="BGP CPR">
      <t/> numbered="true" toc="default">
      <name>BGP CPR</name>
      <section title="Colored numbered="true" toc="default">
        <name>Colored Prefix Allocation"> Allocation</name>
<!-- [rfced] Would it be correct to change "and" to "whereby"?

Original:
   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.
-->

        <t>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, and these sub-locators are Colored Prefixes
        associated with different intents.</t>
        <t>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, 2001:db8:aaaa:1:F000::/68; each of these
        sub-locators is associated with a different intent, such as low-delay,
        high-bandwidth, etc.</t>
      </section>
      <section title="Colored numbered="true" toc="default">
        <name>Colored Prefix Advertisement"> Advertisement</name>
        <t>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.</t>

        <t>In
<!-- [rfced] RFC 2545 does not contain the term "IPv6 unicast Address
Family/Subsequent Address Family (AFI/SAFI = 2/1)", "AFI", or "SAFI".  We see one instance of "Address Family" and a couple instances of "unicast address".  Please consider how the text and citation can be clarified.

   In a multi-AS IPv6 network, the IPv6 unicast Address
        Family/Subsequent Family/
   Subsequent Address Family (AFI/SAFI = 2/1) [RFC2545] is used for the
   advertisement of the Colored Prefix routes.
-->

        <t>In a multi-AS IPv6 network, the IPv6 Unicast Address
        Family / Subsequent Address Family (AFI/SAFI = 2/1) <xref
        target="RFC2545"/> target="RFC2545" format="default"/> is used for the advertisement of the Colored Prefix
        routes. The color extended community <xref target="RFC9012"/> target="RFC9012" format="default"/> is
        carried with the Colored Prefix route with the color value indicating
        the intent <xref target="RFC9256"/>. target="RFC9256" format="default"/>. The procedure of Colored Prefix
        advertisement is described using an example with the following
        topology:</t>

        <t><figure>
            <artwork><![CDATA[

<figure anchor="fig-1">
  <name>Example Topology for CPR Route Illustration</name>
        <artwork name="" type="" align="left" alt=""><![CDATA[
                       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
]]></artwork>
          </figure></t>
</figure>
        <t>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.</t>

        <t><list style="symbols">
        <ul spacing="normal">
          <li>
            <t>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.</t>
          </li>
          <li>
            <t>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.</t>
          </li>
          <li>
            <t>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 ASBR24 advertise the CPR routes further in
            AS2 with the next-hop next hop set to itself.</t>
          </li>
          <li>
            <t>The behavior of ASBR21 and ASBR22 are similar to the behavior
            of ASBR31 and ASBR32.</t>
          </li>
          <li>
            <t>The behavior of ASBR11 and ASBR12 are similar to the behavior
            of ASBR23 and ASBR24.</t>
          </list></t>
          </li>
        </ul>
        <t>In normal cases, the color value in the color extended community
        associated with the CPR route is consistent through all the domains,
        so that the Color Extended Community in the CPR routes is kept
        unchanged. While in 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 in AS2 the same intent is represented by color
        "blue".
        "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.</t>
        <t>In network scenarios where some of the intermediate autonomous
        systems are MPLS-based, 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 domains; at the MPLS domain border nodes, some route
        resolution policy could be used to make the CPR routes resolved 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
        <xref
        target="I-D.ietf-spring-srv6-mpls-interworking"/>.</t> target="I-D.ietf-spring-srv6-mpls-interworking" sectionFormat="of" section="7.1.2.1"/>.</t>
      </section>
      <section title="CPR numbered="true" toc="default">
        <name>CPR to Intra-domain Intra-Domain Path Resolution"> Resolution</name>
        <t>A domain border node which 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 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:</t>

        <t><list style="symbols">
<!-- [rfced] In the bulleted list, is it correct for SRv6 to be listed twice? Also, adding conjunctions may improve clarity regarding how the mechanisms are related.  Is the path built with a combination of the bulleted items or only one of the individual items?

Original:
   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

Perhaps (a combination):
   The intra-domain color-aware path could
   be built with any of the following mechanisms:

   *  SRv6 or SR-MPLS Policy, and
   *  SRv6 or SR-MPLS Flex-Algo, and
   *  RSVP-TE.

Perhaps (a single item):
   The intra-domain color-aware path could
   be built with any of the following mechanisms:

   *  SRv6,
   *  SR-MPLS Policy,
   *  SR-MPLS Flex-Algo, or
   *  RSVP-TE.
-->

        <ul spacing="normal">
          <li>
            <t>SRv6 or SR-MPLS Policy</t>
          </li>
          <li>
            <t>SRv6 or SR-MPLS Flex-Algo</t>
          </li>
          <li>
            <t>RSVP-TE</t>
          </list></t>
          </li>
        </ul>
        <t>For example, if PE1 receives a CPR route to PE3:CL1:: with the color C1
        and next-hop next hop ASBR11, it can resolve the CPR routes to an intra-domain
        SRv6 Policy based on the tuple (ASBR11, C1).</t>
        <t>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.</t>
      </section>
      <section title="SRv6 numbered="true" toc="default">
        <name>SRv6 Service Route Advertisement"> Advertisement</name>
        <t>For an SRv6 service which 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.</t>
        <t>The SRv6 service routes are advertised using the mechanism defined
        in <xref target="RFC9252"/>. target="RFC9252" format="default"/>. The inter-domain VPN Option C is used,
        which means the next-hop 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.</t>
      </section>
      <section title="SRv6 numbered="true" toc="default">
        <name>SRv6 Service Steering"> Steering</name>
        <t>With the CPR routing mechanism, the ingress PE node which that receives
        the SRv6 service routes follows the behavior of SRv6 shortest path
        forwarding (refer to Section 5 Sections <xref target="RFC9252"
        sectionFormat="bare" section="5"/> and 6 <xref target="RFC9252"
        sectionFormat="bare" section="6"/> of <xref target="RFC9252"/>). target="RFC9252"
        format="default"/>). 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.</t>
      </section>
    </section>
    <section title="Encapsulation numbered="true" toc="default">
      <name>Encapsulation and Forwarding Processes"> Process</name>

      <t>This section describes the encapsulation and forwarding process of
      data packets which are matched with the corresponding CPR route.</t>
      <t>The topology of Figure 1 <xref target="fig-1"/> is used in each example.</t>
      <section title="CPR numbered="true" toc="default">
        <name>CPR over SRv6 Intra-Domain Paths"> Paths</name>
        <t>Following is an illustration of the packet encapsulation and
        forwarding process of CPR over SRv6 Policy. The abstract
        representation of IPv6 and SRH the Segment Routing Header (SRH) described in section 6 of <xref
        target="RFC8754"/> target="RFC8754" sectionFormat="of" section="6"/> is used.</t>
        <t>PE3 is provisioned with a Colored Prefix PE3:CL1:: for
        "low-delay".</t>
        <t>In AS1, the SRv6 Policy on PE1 for (ASBR11, C1) is represented with
        SID list &lt;P1, ASBR11&gt;.</t>
        <t>In AS2, the SRv6 Policy on ASBR21 for (ASBR23, C1) is represented
        with the SID list &lt;P2, ASBR23&gt;.</t>
        <t>In AS3, the SRv6 Policy on ASBR31 for (PE3, C1) is represented with
        the SID list &lt;P3, PE3&gt;.</t>
        <t>C-pkt is the customer packet PE1 received from its attaching
        CE.</t>
        <t>For packets which 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 <xref target="RFC8986"/> target="RFC8986" format="default"/> is shown
        as below:</t>

        <t><figure>
            <artwork><![CDATA[PE1
<figure>
        <artwork name="" type="" align="left" alt=""><![CDATA[
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)
]]></artwork>
          </figure></t>
</figure>
        <t>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.</t>
      </section>
      <section title="CPR numbered="true" toc="default">
        <name>CPR over MPLS Intra-Domain Paths"> Paths</name>
        <t>In network scenarios where some of the autonomous systems use MPLS
        based 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 Flex-Algo, or RSVP-TE.</t>
        <t>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 <xref target="RFC3031"/> target="RFC3031" format="default"/>, <xref
        target="RFC3032"/> target="RFC3032" format="default"/> and <xref target="RFC8660"/>. target="RFC8660" format="default"/>. The behavior is
        similar to that of 6PE IPv6 Provider Edge Routers (6PEs) <xref target="RFC4798"/>.</t> target="RFC4798" format="default"/>.</t>
        <t>In AS1, the SR-MPLS Policy on PE1 for (ASBR11, C1) is represented
        with the SID list &lt;P1, ASBR11&gt;.</t>
        <t>In AS2, the SR-MPLS Flex-Algo on ASBR21 for (ASBR23, C1) is
        represented with SID list &lt;ASBR23&gt;.</t>
        <t>In AS3, the SR-MPLS Policy on ASBR31 for (PE3, C1) is represented
        with SID list &lt;P3, PE3&gt;.</t>
        <t>C-pkt is the customer packet PE-1 received from its attaching
        CE.</t>
        <t>For packets which 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:</t>

        <t><figure>
            <artwork><![CDATA[PE1->
<figure>
        <artwork name="" type="" align="left" alt=""><![CDATA[
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)
]]></artwork>
          </figure></t>

        <t/>
</figure>

      </section>
    </section>
    <section title="Operational Considerations">
      <t>The numbered="true" toc="default">
      <name>Operational Considerations</name>
<!-- [rfced] "which makes them belonging" is unclear.  We have updated the text as shown below.

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

Current:
   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]).
-->

      <t>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
      <xref target="RFC8402"/>).</t>

      <t>As target="RFC8402" sectionFormat="of" section="8"/>).</t>
<!-- [rfced] What spans across multiple ASes?  Is it the SR Policy or the tunnel?

Original:
   As described in section 5 of <xref
      target="I-D.hr-spring-intentaware-routing-using-color"/>,
   [I-D.hr-spring-intentaware-routing-using-color], the inter-domain
   intent-aware routing may be achieved with a logical tunnel created by
   an SR Policy across multiple ASes, and service traffic with specific
   intent can be steered to the inter-domain SR Policy based on the
   intent signaled by Color Extended Community.

Perhaps:
   As described in Section 5 of
   [INTENTAWARE], the 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 a specific
   intent can be steered to the inter-domain SR Policy based on the
   intent signaled by Color Extended Community.
-->

      <t>As described in <xref
      target="I-D.hr-spring-intentaware-routing-using-color"
      sectionFormat="of" section="5"/>, inter-domain intent-aware routing
      may be achieved with a logical tunnel created by an SR Policy across
      multiple ASes, and service traffic with specific intent can be steered
      to the inter-domain SR Policy based on the intent signaled by Color
      Extended Community. An operator may prefer a BGP routing based routing-based solution
      for the reasons described in <xref
      target="I-D.hr-spring-intentaware-routing-using-color"/>. Another
      possible consideration of the
      target="I-D.hr-spring-intentaware-routing-using-color"
      format="default"/>. The operator is 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.</t>
      <t>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 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 the route
      aggregation be disabled for IPv6 unicast routes which that carry the color
      extended community.</t>
      <t>With the CPR mechanism, at the prefix originator, each colored prefix Colored Prefix is
      associated with one specific intent (i.e. (i.e., color). And in 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 Colored Prefix but different color extened
      commuity extended
      community is considered a misconfiguration.</t>
<!-- [rfced] Is seems as though there may be words missing in the following.  What can "fall back"?

Original:
   This allows the CPR routes to be resolved to
   intent-aware intra-domain paths in any autonomous systems that
   support the CPR mechanism, while can fall back to resolve over best-
   effort intra-domain path in the legacy autonomous systems.
-->

      <t>All the border nodes and the ingress PE nodes need to install the
      Colored locator prefixes into in the RIB and FIB. For transit domains which that
      support the CPR mechanism, the border nodes can use the tuple (N, C) 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 which 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 next hop
      changed to itself. This allows the CPR routes to be resolved resolve to
      intent-aware intra-domain paths in any autonomous systems that support
      the CPR mechanism, while can fall back to resolve over best-effort
      intra-domain path in the legacy autonomous systems.</t>
      <t>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 EBGP. 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.</t>
      <t>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 necessity of separating need to separate Colored Prefixes from
      public IPv6 unicast routes. Since 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. <xref target="RFC9602"/> target="RFC9602" format="default"/> allocates the prefix 5f00::/16 for SRv6
      SIDs, by
      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 Colored Prefixes in use in these domains. The proposal in
      <xref target="I-D.ietf-idr-bgp-car"/> target="BGP-CAR" format="default"/> 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, intent; the
      difference is that a separate SAFI is used.</t>
      <t><xref target="I-D.ietf-idr-bgp-ct"/> target="I-D.ietf-idr-bgp-ct" format="default"/> describes another mechanism for
      intent-aware routing, in which the SRv6 service SIDs are not directly
      associated with the intent, while additional intent (additional SRv6 transport SIDs are
      required for steering to steer traffic to the inter-domain intent-aware paths, paths),
      and an SRv6 operation similar to MPLS label swapping is needed on the
      border nodes of autonomous systems.</t>
    </section>
    <section anchor="IANA" title="IANA Considerations"> numbered="true" toc="default">
      <name>IANA Considerations</name>
<t>This document makes has no request of IANA.</t> IANA actions.</t>
    </section>
    <section anchor="Security" title="Security Considerations"> numbered="true" toc="default">
      <name>Security Considerations</name>
      <t>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 proportionate to the number of intents it supports. This may
      introduce additional routes to the BGP IPv6 routing table. While since Because these
      are infrastructure routes, the amount number of Colored Prefixes is only a
      small portion of the total amount of IPv6 prefixes. Thus it is
      considered that Thus,
      the impact to the required routing table size is considered
      acceptable.</t>
      <t>As the CPR routes are distributed across multiple ASes which 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.</t>
      <t>The security considerations as described in <xref target="RFC4271"/> target="RFC4271" format="default"/>,
        <xref target="RFC4272"/> target="RFC4272" format="default"/> and <xref target="RFC8754"/> target="RFC8754" format="default"/> apply to this
      document.</t>
    </section>

  </middle>
  <back>
<displayreference target="I-D.ietf-idr-bgp-ct" to="BGP-CT"/>

<displayreference target="I-D.hr-spring-intentaware-routing-using-color" to="INTENTAWARE"/>
<displayreference target="I-D.ietf-spring-srv6-mpls-interworking" to="SRv6-INTERWORK"/>

    <references>
      <name>References</name>
      <references>
        <name>Normative References</name>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4271.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2545.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4272.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8402.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8754.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8986.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9012.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9252.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9256.xml"/>
      </references>
      <references>
        <name>Informative References</name>

<!-- [I-D.hr-spring-intentaware-routing-using-color]
IESG State: I-D Exists
-->
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.hr-spring-intentaware-routing-using-color.xml"/>

<!-- [I-D.ietf-spring-srv6-mpls-interworking]
IESG State: Expired
-->

<reference anchor="I-D.ietf-spring-srv6-mpls-interworking" target="https://datatracker.ietf.org/doc/html/draft-ietf-spring-srv6-mpls-interworking-00">
   <front>
      <title>SRv6 and MPLS interworking</title>
      <author initials="S." surname="Agrawal" fullname="Swadesh Agrawal" role="editor">
         <organization>Cisco Systems</organization>
      </author>
      <author initials="C." surname="Filsfils" fullname="Clarence Filsfils">
         <organization>Cisco Systems</organization>
      </author>
      <author initials="D." surname="Voyer" fullname="Daniel Voyer">
         <organization>Bell Canada</organization>
      </author>
      <author initials="G." surname="Dawra" fullname="Gaurav Dawra">
         <organization>LinkedIn</organization>
      </author>
      <author initials="Z." surname="Li" fullname="Zhenbin Li">
         <organization>Huawei Technologies</organization>
      </author>
      <author initials="S." surname="Hegde" fullname="Shraddha Hegde">
         <organization>Juniper Networks</organization>
      </author>
      <date month="October" day="17" year="2024" />
   </front>
   <seriesInfo name="Internet-Draft" value="draft-ietf-spring-srv6-mpls-interworking-00" />
</reference>

<!-- [I-D.ietf-idr-bgp-car]
IESG State: RFC ED Queue
-->

<reference anchor="BGP-CAR" target="https://datatracker.ietf.org/doc/html/draft-ietf-idr-bgp-car-16">
   <front>
      <title>BGP Color-Aware Routing (CAR)</title>
      <author initials="D." surname="Rao" fullname="Dhananjaya Rao" role="editor">
         <organization>Cisco Systems</organization>
      </author>
      <author initials="S." surname="Agrawal" fullname="Swadesh Agrawal" role="editor">
         <organization>Cisco Systems</organization>
      </author>
      <date month="February" day="20" year="2025" />
   </front>
   <seriesInfo name="Internet-Draft" value="draft-ietf-idr-bgp-car-16" />

</reference>

<!-- [I-D.ietf-idr-bgp-ct]
IESG State: RFC Ed Queue
-->

<reference anchor="I-D.ietf-idr-bgp-ct" target="https://datatracker.ietf.org/doc/html/draft-ietf-idr-bgp-ct-39">
   <front>
      <title>BGP Classful Transport Planes</title>
      <author initials="K." surname="Vairavakkalai" fullname="Kaliraj Vairavakkalai" role="editor">
         <organization>Juniper Networks, Inc.</organization>
      </author>
      <author initials="N." surname="Venkataraman" fullname="Natrajan Venkataraman" role="editor">
         <organization>Juniper Networks, Inc.</organization>
      </author>
      <date month="February" day="28" year="2025" />
   </front>
   <seriesInfo name="Internet-Draft" value="draft-ietf-idr-bgp-ct-39" />

</reference>

        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3031.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3032.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4798.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8277.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8660.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9602.xml"/>

      </references>
    </references>

    <section anchor="Acknowledgements" numbered="false" toc="default">
      <name>Acknowledgements</name>
      <t>The authors would like to thank <contact fullname="Shunwan Zhuang"/>,
      <contact fullname="Zhibo Hu"/>, <contact fullname="Zhenbin Li"/>,
      <contact fullname="Dhananjaya Rao"/>, and <contact fullname="Dhruv
      Dhody"/> for their reviews and valuable discussion.</t>
    </section>

    <section title="Contributing Authors"> anchor="contribs" numbered="false" toc="default">
      <name>Contributors</name>
      <t>The following people contributed significantly to the content of this
      document and should be considered co-authors:</t>

      <t><figure>
          <artwork><![CDATA[Xinjun Chen
ifocus.chen@huawei.com

Jingrong Xie
xiejingrong@huawei.com

Zhenqiang Li
li_zhenqiang@hotmail.com
]]></artwork>
        </figure></t>

    <contact fullname="Xinjun Chen">
      <address>
        <email>ifocus.chen@huawei.com</email>
      </address>
    </contact>

    <contact fullname="Jingrong Xie">
      <address>
        <email>xiejingrong@huawei.com</email>
      </address>
    </contact>

    <contact fullname="Zhenqiang Li">
      <address>
        <email>li_zhenqiang@hotmail.com</email>
      </address>
    </contact>

    </section>

    <section anchor="Acknowledgements" title="Acknowledgements">
      <t>The authors would like

<!-- [rfced] Throughout the text, the following terminology appears to thank Shunwan Zhuang, Zhibo Hu, Zhenbin Li,
      Dhananjaya Rao and Dhruv Dhody for be used
inconsistently.  Please review.

a) Colored Prefix vs Colored prefixes vs colored prefix

We updated to use the form on the left.  Please let us know if any updates are needed.

In addition, please consider whether the capitalization of "Colored locator prefixes" is correct.

b) Please review the use of the following and valuable
      discussion.</t>
    </section>
  </middle>

  <back>
    <references title="Normative References">
      <?rfc include='reference.RFC.4271'?>

      <?rfc include='reference.RFC.2545'?>

      <?rfc include='reference.RFC.4272'?>

      <?rfc include='reference.RFC.8402'?>

      <?rfc include='reference.RFC.8754'?>

      <?rfc include='reference.RFC.8986'?>

      <?rfc include='reference.RFC.9012'?>

      <?rfc include='reference.RFC.9252'?>

      <?rfc include='reference.RFC.9256'?>
    </references>

    <references title="Informative References">
      <?rfc include='reference.I-D.hr-spring-intentaware-routing-using-color'?>

      <?rfc include='reference.I-D.ietf-spring-srv6-mpls-interworking'?>

      <?rfc include='reference.I-D.ietf-idr-bgp-car'?>

      <?rfc include='reference.I-D.ietf-idr-bgp-ct'?>

      <?rfc include='reference.RFC.3031'?>

      <?rfc include='reference.RFC.3032'?>

      <?rfc include='reference.RFC.4798'?>

      <?rfc include='reference.RFC.8277'?>

      <?rfc include='reference.RFC.8660'?>

      <?rfc include='reference.RFC.9602'?>
    </references> let us know how/if they may be updated for consistency.

color extended community vs Color Extended Community

-->

<!-- [rfced] Please review the "Inclusive Language" portion of the online
Style Guide <https://www.rfc-editor.org/styleguide/part2/#inclusive_language>
and let us know if any changes are needed.  Updates of this nature typically
result in more precise language, which is helpful for readers.

Note that our script did not flag any words in particular, but this should
still be reviewed as a best practice.
-->

  </back>
</rfc>