<?xml version='1.0' encoding='utf-8'?>
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" version="3" category="info" docName="draft-ietf-idr-cpr-08" number="9723" ipr="trust200902" consensus="true" obsoletes="" updates="" submissionType="IETF" xml:lang="en" tocInclude="true" tocDepth="3" symRefs="true" sortRefs="true" prepTime="2025-05-29T11:18:56" indexInclude="true" scripts="Common,Latin">
  <link href="https://datatracker.ietf.org/doc/draft-ietf-idr-cpr-08" rel="prev"/>
  <link href="https://dx.doi.org/10.17487/rfc9723" rel="alternate"/>
  <link href="urn:issn:2070-1721" rel="alternate"/>
  <front>
    <title abbrev="BGP CPR for SRv6 Services">BGP Colored Prefix Routing (CPR) for Services Based on Segment Routing over IPv6 (SRv6)</title>
    <seriesInfo name="RFC" value="9723" stream="IETF"/>
    <author fullname="Haibo Wang" initials="H." surname="Wang">
      <organization showOnFrontPage="true">Huawei Technologies</organization>
      <address>
        <postal>
          <country>China</country>
        </postal>
        <email>rainsword.wang@huawei.com</email>
      </address>
    </author>
    <author fullname="Jie Dong" initials="J." surname="Dong">
      <organization showOnFrontPage="true">Huawei Technologies</organization>
      <address>
        <postal>
          <country>China</country>
        </postal>
        <email>jie.dong@huawei.com</email>
      </address>
    </author>
    <author fullname="Ketan Talaulikar" initials="K." surname="Talaulikar">
      <organization showOnFrontPage="true">Cisco Systems</organization>
      <address>
        <postal>
          <country>India</country>
        </postal>
        <email>ketant.ietf@gmail.com</email>
      </address>
    </author>
    <author fullname="Tao Han" initials="T." surname="Han">
      <organization showOnFrontPage="true">Huawei Technologies</organization>
      <address>
        <postal>
          <country>China</country>
        </postal>
        <email>hantao@huawei.com</email>
      </address>
    </author>
    <author fullname="Ran Chen" initials="R." surname="Chen">
      <organization showOnFrontPage="true">ZTE Corporation</organization>
      <address>
        <postal>
          <country>China</country>
        </postal>
        <email>chen.ran@zte.com.cn</email>
      </address>
    </author>
    <date month="05" year="2025"/>
    <area>RTG</area>
    <workgroup>idr</workgroup>
    <keyword>intent-aware routing</keyword>
    <abstract pn="section-abstract">
      <t indent="0" pn="section-abstract-1">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.</t>
      <t indent="0" pn="section-abstract-2">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.</t>
    </abstract>
    <boilerplate>
      <section anchor="status-of-memo" numbered="false" removeInRFC="false" toc="exclude" pn="section-boilerplate.1">
        <name slugifiedName="name-status-of-this-memo">Status of This Memo</name>
        <t indent="0" pn="section-boilerplate.1-1">
            This document is not an Internet Standards Track specification; it is
            published for informational purposes.  
        </t>
        <t indent="0" pn="section-boilerplate.1-2">
            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. 
        </t>
        <t indent="0" pn="section-boilerplate.1-3">
            Information about the current status of this document, any
            errata, and how to provide feedback on it may be obtained at
            <eref target="https://www.rfc-editor.org/info/rfc9723" brackets="none"/>.
        </t>
      </section>
      <section anchor="copyright" numbered="false" removeInRFC="false" toc="exclude" pn="section-boilerplate.2">
        <name slugifiedName="name-copyright-notice">Copyright Notice</name>
        <t indent="0" pn="section-boilerplate.2-1">
            Copyright (c) 2025 IETF Trust and the persons identified as the
            document authors. All rights reserved.
        </t>
        <t indent="0" pn="section-boilerplate.2-2">
            This document is subject to BCP 78 and the IETF Trust's Legal
            Provisions Relating to IETF Documents
            (<eref target="https://trustee.ietf.org/license-info" brackets="none"/>) 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.
        </t>
      </section>
    </boilerplate>
    <toc>
      <section anchor="toc" numbered="false" removeInRFC="false" toc="exclude" pn="section-toc.1">
        <name slugifiedName="name-table-of-contents">Table of Contents</name>
        <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1">
          <li pn="section-toc.1-1.1">
            <t indent="0" keepWithNext="true" pn="section-toc.1-1.1.1"><xref derivedContent="1" format="counter" sectionFormat="of" target="section-1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-introduction">Introduction</xref></t>
          </li>
          <li pn="section-toc.1-1.2">
            <t indent="0" pn="section-toc.1-1.2.1"><xref derivedContent="2" format="counter" sectionFormat="of" target="section-2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-bgp-cpr">BGP CPR</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.2.2">
              <li pn="section-toc.1-1.2.2.1">
                <t indent="0" keepWithNext="true" pn="section-toc.1-1.2.2.1.1"><xref derivedContent="2.1" format="counter" sectionFormat="of" target="section-2.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-colored-prefix-allocation">Colored Prefix Allocation</xref></t>
              </li>
              <li pn="section-toc.1-1.2.2.2">
                <t indent="0" keepWithNext="true" pn="section-toc.1-1.2.2.2.1"><xref derivedContent="2.2" format="counter" sectionFormat="of" target="section-2.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-colored-prefix-advertisemen">Colored Prefix Advertisement</xref></t>
              </li>
              <li pn="section-toc.1-1.2.2.3">
                <t indent="0" pn="section-toc.1-1.2.2.3.1"><xref derivedContent="2.3" format="counter" sectionFormat="of" target="section-2.3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-cpr-to-intra-domain-path-re">CPR to Intra-Domain Path Resolution</xref></t>
              </li>
              <li pn="section-toc.1-1.2.2.4">
                <t indent="0" pn="section-toc.1-1.2.2.4.1"><xref derivedContent="2.4" format="counter" sectionFormat="of" target="section-2.4"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-srv6-service-route-advertis">SRv6 Service Route Advertisement</xref></t>
              </li>
              <li pn="section-toc.1-1.2.2.5">
                <t indent="0" pn="section-toc.1-1.2.2.5.1"><xref derivedContent="2.5" format="counter" sectionFormat="of" target="section-2.5"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-srv6-service-steering">SRv6 Service Steering</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.3">
            <t indent="0" pn="section-toc.1-1.3.1"><xref derivedContent="3" format="counter" sectionFormat="of" target="section-3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-encapsulation-and-forwardin">Encapsulation and Forwarding Process</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.3.2">
              <li pn="section-toc.1-1.3.2.1">
                <t indent="0" pn="section-toc.1-1.3.2.1.1"><xref derivedContent="3.1" format="counter" sectionFormat="of" target="section-3.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-cpr-over-srv6-intra-domain-">CPR over SRv6 Intra-Domain Paths</xref></t>
              </li>
              <li pn="section-toc.1-1.3.2.2">
                <t indent="0" pn="section-toc.1-1.3.2.2.1"><xref derivedContent="3.2" format="counter" sectionFormat="of" target="section-3.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-cpr-over-mpls-intra-domain-">CPR over MPLS Intra-Domain Paths</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.4">
            <t indent="0" pn="section-toc.1-1.4.1"><xref derivedContent="4" format="counter" sectionFormat="of" target="section-4"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-operational-considerations">Operational Considerations</xref></t>
          </li>
          <li pn="section-toc.1-1.5">
            <t indent="0" pn="section-toc.1-1.5.1"><xref derivedContent="5" format="counter" sectionFormat="of" target="section-5"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-iana-considerations">IANA Considerations</xref></t>
          </li>
          <li pn="section-toc.1-1.6">
            <t indent="0" pn="section-toc.1-1.6.1"><xref derivedContent="6" format="counter" sectionFormat="of" target="section-6"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-security-considerations">Security Considerations</xref></t>
          </li>
          <li pn="section-toc.1-1.7">
            <t indent="0" pn="section-toc.1-1.7.1"><xref derivedContent="7" format="counter" sectionFormat="of" target="section-7"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-references">References</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.7.2">
              <li pn="section-toc.1-1.7.2.1">
                <t indent="0" pn="section-toc.1-1.7.2.1.1"><xref derivedContent="7.1" format="counter" sectionFormat="of" target="section-7.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-normative-references">Normative References</xref></t>
              </li>
              <li pn="section-toc.1-1.7.2.2">
                <t indent="0" pn="section-toc.1-1.7.2.2.1"><xref derivedContent="7.2" format="counter" sectionFormat="of" target="section-7.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-informative-references">Informative References</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.8">
            <t indent="0" pn="section-toc.1-1.8.1"><xref derivedContent="" format="none" sectionFormat="of" target="section-appendix.a"/><xref derivedContent="" format="title" sectionFormat="of" target="name-acknowledgements">Acknowledgements</xref></t>
          </li>
          <li pn="section-toc.1-1.9">
            <t indent="0" pn="section-toc.1-1.9.1"><xref derivedContent="" format="none" sectionFormat="of" target="section-appendix.b"/><xref derivedContent="" format="title" sectionFormat="of" target="name-contributors">Contributors</xref></t>
          </li>
          <li pn="section-toc.1-1.10">
            <t indent="0" pn="section-toc.1-1.10.1"><xref derivedContent="" format="none" sectionFormat="of" target="section-appendix.c"/><xref derivedContent="" format="title" sectionFormat="of" target="name-authors-addresses">Authors' Addresses</xref></t>
          </li>
        </ul>
      </section>
    </toc>
  </front>
  <middle>
    <section numbered="true" toc="include" removeInRFC="false" pn="section-1">
      <name slugifiedName="name-introduction">Introduction</name>
      <t indent="0" pn="section-1-1">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".</t>
      <t indent="0" pn="section-1-2">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. <xref target="I-D.hr-spring-intentaware-routing-using-color" format="default" sectionFormat="of" derivedContent="INTENTAWARE"/> describes the
      problem statements and requirements for inter-domain intent-aware
      routing.</t>
      <t indent="0" pn="section-1-3">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 <xref target="RFC8277" format="default" sectionFormat="of" derivedContent="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.</t>
      <t indent="0" pn="section-1-4">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" format="default" sectionFormat="of" derivedContent="RFC8402"/> <xref target="RFC8754" format="default" sectionFormat="of" derivedContent="RFC8754"/> <xref target="RFC8986" format="default" sectionFormat="of" derivedContent="RFC8986"/>,
      BGP services are assigned with SRv6 Service SIDs <xref target="RFC9252" format="default" sectionFormat="of" derivedContent="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.</t>
      <t indent="0" pn="section-1-5">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 <xref target="RFC9256" format="default" sectionFormat="of" derivedContent="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) <xref target="RFC9252" format="default" sectionFormat="of" derivedContent="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
      <xref target="RFC9252" format="default" sectionFormat="of" derivedContent="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.</t>
      <t indent="0" pn="section-1-6">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 <xref target="RFC8402" sectionFormat="of" section="8" format="default" derivedLink="https://rfc-editor.org/rfc/rfc8402#section-8" derivedContent="RFC8402"/>).</t>
    </section>
    <section numbered="true" toc="include" removeInRFC="false" pn="section-2">
      <name slugifiedName="name-bgp-cpr">BGP CPR</name>
      <section numbered="true" toc="include" removeInRFC="false" pn="section-2.1">
        <name slugifiedName="name-colored-prefix-allocation">Colored Prefix Allocation</name>
        <t indent="0" pn="section-2.1-1">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.</t>
        <t indent="0" pn="section-2.1-2">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.</t>
      </section>
      <section numbered="true" toc="include" removeInRFC="false" pn="section-2.2">
        <name slugifiedName="name-colored-prefix-advertisemen">Colored Prefix Advertisement</name>
        <t indent="0" pn="section-2.2-1">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 indent="0" pn="section-2.2-2">In a multi-AS IPv6 network, the mechanism for IPv6 unicast routing as defined in <xref target="RFC2545" format="default" sectionFormat="of" derivedContent="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 <xref target="RFC9012" format="default" sectionFormat="of" derivedContent="RFC9012"/> is
        carried with the Colored Prefix route with the color value indicating
        the intent <xref target="RFC9256" format="default" sectionFormat="of" derivedContent="RFC9256"/>. The procedure of Colored Prefix
        advertisement is described using an example with the following
        topology:</t>
        <figure anchor="fig-1" align="left" suppress-title="false" pn="figure-1">
          <name slugifiedName="name-example-topology-for-cpr-ro">Example Topology for CPR Route Illustration</name>
          <artwork name="" type="" align="left" alt="" pn="section-2.2-3.1">
                       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::
                                                    ...
</artwork>
        </figure>
        <t indent="0" pn="section-2.2-4">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>
        <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-2.2-5">
          <li pn="section-2.2-5.1">
            <t indent="0" pn="section-2.2-5.1.1">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 pn="section-2.2-5.2">
            <t indent="0" pn="section-2.2-5.2.1">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 pn="section-2.2-5.3">
            <t indent="0" pn="section-2.2-5.3.1">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.</t>
          </li>
          <li pn="section-2.2-5.4">
            <t indent="0" pn="section-2.2-5.4.1">The behavior of ASBR21 and ASBR22 are similar to the behavior
            of ASBR31 and ASBR32.</t>
          </li>
          <li pn="section-2.2-5.5">
            <t indent="0" pn="section-2.2-5.5.1">The behavior of ASBR11 and ASBR12 are similar to the behavior
            of ASBR23 and ASBR24.</t>
          </li>
        </ul>
        <t indent="0" pn="section-2.2-6">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.</t>
        <t indent="0" pn="section-2.2-7">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
        <xref target="I-D.ietf-spring-srv6-mpls-interworking" sectionFormat="of" section="7.1.2.1" format="default" derivedLink="https://datatracker.ietf.org/doc/html/draft-ietf-spring-srv6-mpls-interworking-00#section-7.1.2.1" derivedContent="SRv6-INTERWORK"/>.</t>
      </section>
      <section numbered="true" toc="include" removeInRFC="false" pn="section-2.3">
        <name slugifiedName="name-cpr-to-intra-domain-path-re">CPR to Intra-Domain Path Resolution</name>
        <t indent="0" pn="section-2.3-1">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:</t>
        <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-2.3-2">
          <li pn="section-2.3-2.1">SRv6 Policy</li>
          <li pn="section-2.3-2.2">SR-MPLS Policy</li>
          <li pn="section-2.3-2.3">SRv6 Flex-Algo</li>
          <li pn="section-2.3-2.4">SR-MPLS Flex-Algo</li>
          <li pn="section-2.3-2.5">RSVP-TE</li>
        </ul>
        <t indent="0" pn="section-2.3-3">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).</t>
        <t indent="0" pn="section-2.3-4">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 numbered="true" toc="include" removeInRFC="false" pn="section-2.4">
        <name slugifiedName="name-srv6-service-route-advertis">SRv6 Service Route Advertisement</name>
        <t indent="0" pn="section-2.4-1">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.</t>
        <t indent="0" pn="section-2.4-2">The SRv6 service routes are advertised using the mechanism defined
        in <xref target="RFC9252" format="default" sectionFormat="of" derivedContent="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.</t>
      </section>
      <section numbered="true" toc="include" removeInRFC="false" pn="section-2.5">
        <name slugifiedName="name-srv6-service-steering">SRv6 Service Steering</name>
        <t indent="0" pn="section-2.5-1">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 <xref target="RFC9252" sectionFormat="bare" section="5" format="default" derivedLink="https://rfc-editor.org/rfc/rfc9252#section-5" derivedContent="RFC9252"/> and <xref target="RFC9252" sectionFormat="bare" section="6" format="default" derivedLink="https://rfc-editor.org/rfc/rfc9252#section-6" derivedContent="RFC9252"/> of <xref target="RFC9252" format="default" sectionFormat="of" derivedContent="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.</t>
      </section>
    </section>
    <section numbered="true" toc="include" removeInRFC="false" pn="section-3">
      <name slugifiedName="name-encapsulation-and-forwardin">Encapsulation and Forwarding Process</name>
      <t indent="0" pn="section-3-1">This section describes the encapsulation and forwarding process of
      data packets which are matched with the corresponding CPR route.</t>
      <t indent="0" pn="section-3-2">The topology of <xref target="fig-1" format="default" sectionFormat="of" derivedContent="Figure 1"/> is used in each example.</t>
      <section numbered="true" toc="include" removeInRFC="false" pn="section-3.1">
        <name slugifiedName="name-cpr-over-srv6-intra-domain-">CPR over SRv6 Intra-Domain Paths</name>
        <t indent="0" pn="section-3.1-1">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 <xref target="RFC8754" sectionFormat="of" section="6" format="default" derivedLink="https://rfc-editor.org/rfc/rfc8754#section-6" derivedContent="RFC8754"/> is used.</t>
        <t indent="0" pn="section-3.1-2">PE3 is provisioned with a Colored Prefix PE3:CL1:: for
        "low-delay".</t>
        <t indent="0" pn="section-3.1-3">In AS1, the SRv6 Policy on PE1 for (ASBR11, C1) is represented with
        SID list &lt;P1, ASBR11&gt;.</t>
        <t indent="0" pn="section-3.1-4">In AS2, the SRv6 Policy on ASBR21 for (ASBR23, C1) is represented
        with the SID list &lt;P2, ASBR23&gt;.</t>
        <t indent="0" pn="section-3.1-5">In AS3, the SRv6 Policy on ASBR31 for (PE3, C1) is represented with
        the SID list &lt;P3, PE3&gt;.</t>
        <t indent="0" pn="section-3.1-6">C-pkt is the customer packet PE1 received from its attaching
        CE.</t>
        <t indent="0" pn="section-3.1-7">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 <xref target="RFC8986" format="default" sectionFormat="of" derivedContent="RFC8986"/> is shown
        as below:</t>
        <figure align="left" suppress-title="false" pn="figure-2">
          <artwork name="" type="" align="left" alt="" pn="section-3.1-8.1">
PE1 -&gt;P1:           (PE1, P1)(PE3:CL1.DT6, ASBR11; SL=2)(C-pkt)
P1 -&gt;ASBR11:    (PE1, ASBR11)(PE3:CL1.DT6, ASBR11; SL=1)(C-pkt)
ASBR11-&gt;ASBR21:                       (PE1, PE3:CL1.DT6)(C-pkt)
ASBR21-&gt;P2: (ASBR21, P2)(ASBR23; SL=1)(PE1, PE3:CL1.DT6)(C-pkt)
P2-&gt;ASBR23:           (ASBR21, ASBR23)(PE1, PE3:CL1.DT6)(C-pkt)
ASBR23-&gt;ASBR31:                       (PE1, PE3:CL1.DT6)(C-pkt) 
ASBR31-&gt;P3:    (ASBR31, P3)(PE3; SL=1)(PE1, PE3:CL1.DT6)(C-pkt)
P3-&gt;PE3:                 (ASBR31, PE3)(PE1, PE3:CL1.DT6)(C-pkt)
</artwork>
        </figure>
        <t indent="0" pn="section-3.1-9">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 numbered="true" toc="include" removeInRFC="false" pn="section-3.2">
        <name slugifiedName="name-cpr-over-mpls-intra-domain-">CPR over MPLS Intra-Domain Paths</name>
        <t indent="0" pn="section-3.2-1">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.</t>
        <t indent="0" pn="section-3.2-2">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" format="default" sectionFormat="of" derivedContent="RFC3031"/>, <xref target="RFC3032" format="default" sectionFormat="of" derivedContent="RFC3032"/> and <xref target="RFC8660" format="default" sectionFormat="of" derivedContent="RFC8660"/>. The behavior is
        similar to that of IPv6 Provider Edge Routers (6PEs) <xref target="RFC4798" format="default" sectionFormat="of" derivedContent="RFC4798"/>.</t>
        <t indent="0" pn="section-3.2-3">In AS1, the SR-MPLS Policy on PE1 for (ASBR11, C1) is represented
        with the SID list &lt;P1, ASBR11&gt;.</t>
        <t indent="0" pn="section-3.2-4">In AS2, the SR-MPLS Flex-Algo on ASBR21 for (ASBR23, C1) is
        represented with SID list &lt;ASBR23&gt;.</t>
        <t indent="0" pn="section-3.2-5">In AS3, the SR-MPLS Policy on ASBR31 for (PE3, C1) is represented
        with SID list &lt;P3, PE3&gt;.</t>
        <t indent="0" pn="section-3.2-6">C-pkt is the customer packet PE-1 received from its attaching
        CE.</t>
        <t indent="0" pn="section-3.2-7">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:</t>
        <figure align="left" suppress-title="false" pn="figure-3">
          <artwork name="" type="" align="left" alt="" pn="section-3.2-8.1">
PE1-&gt; P1: Label-stack(P1, ASBR11)(PE1, PE3:CL1.DT6)(C-pkt)
P1-&gt;ASBR11:   Label-stack(ASBR11)(PE1, PE3:CL1.DT6)(C-pkt)
ASBR11-&gt;ASBR21:                  (PE1, PE3:CL1.DT6)(C-pkt)
ASBR21-&gt;P2:   Label-stack(ASBR23)(PE1, PE3:CL1.DT6)(C-pkt)
P2-&gt;ASBR23:   Label-stack(ASBR23)(PE1, PE3:CL1.DT6)(C-pkt)
ASBR23-&gt;ASBR31:                  (PE1, PE3:CL1.DT6)(C-pkt)
ASBR31-&gt;P3:  Label-stack(P3, PE3)(PE1, PE3:CL1.DT6)(C-pkt)
P3-&gt;PE3:         Label-stack(PE3)(PE1, PE3:CL1.DT6)(C-pkt)
</artwork>
        </figure>
      </section>
    </section>
    <section numbered="true" toc="include" removeInRFC="false" pn="section-4">
      <name slugifiedName="name-operational-considerations">Operational Considerations</name>
      <t indent="0" pn="section-4-1">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" sectionFormat="of" section="8" format="default" derivedLink="https://rfc-editor.org/rfc/rfc8402#section-8" derivedContent="RFC8402"/>).</t>
      <t indent="0" pn="section-4-2">As described in <xref target="I-D.hr-spring-intentaware-routing-using-color" sectionFormat="of" section="5" format="default" derivedLink="https://datatracker.ietf.org/doc/html/draft-hr-spring-intentaware-routing-using-color-04#section-5" derivedContent="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 <xref target="I-D.hr-spring-intentaware-routing-using-color" format="default" sectionFormat="of" derivedContent="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.</t>
      <t indent="0" pn="section-4-3">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.</t>
      <t indent="0" pn="section-4-4">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.</t>
      <t indent="0" pn="section-4-5">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.
</t>
      <t indent="0" pn="section-4-6">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.</t>
      <t indent="0" pn="section-4-7">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. <xref target="RFC9602" format="default" sectionFormat="of" derivedContent="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
      <xref target="BGP-CAR" format="default" sectionFormat="of" derivedContent="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.</t>
      <t indent="0" pn="section-4-8"><xref target="I-D.ietf-idr-bgp-ct" format="default" sectionFormat="of" derivedContent="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.</t>
    </section>
    <section anchor="IANA" numbered="true" toc="include" removeInRFC="false" pn="section-5">
      <name slugifiedName="name-iana-considerations">IANA Considerations</name>
      <t indent="0" pn="section-5-1">This document has no IANA actions.</t>
    </section>
    <section anchor="Security" numbered="true" toc="include" removeInRFC="false" pn="section-6">
      <name slugifiedName="name-security-considerations">Security Considerations</name>
      <t indent="0" pn="section-6-1">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.</t>
      <t indent="0" pn="section-6-2">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.</t>
      <t indent="0" pn="section-6-3">The security considerations as described in <xref target="RFC4271" format="default" sectionFormat="of" derivedContent="RFC4271"/>,
        <xref target="RFC4272" format="default" sectionFormat="of" derivedContent="RFC4272"/>, and <xref target="RFC8754" format="default" sectionFormat="of" derivedContent="RFC8754"/> 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 pn="section-7">
      <name slugifiedName="name-references">References</name>
      <references pn="section-7.1">
        <name slugifiedName="name-normative-references">Normative References</name>
        <reference anchor="RFC2545" target="https://www.rfc-editor.org/info/rfc2545" quoteTitle="true" derivedAnchor="RFC2545">
          <front>
            <title>Use of BGP-4 Multiprotocol Extensions for IPv6 Inter-Domain Routing</title>
            <author fullname="P. Marques" initials="P." surname="Marques"/>
            <author fullname="F. Dupont" initials="F." surname="Dupont"/>
            <date month="March" year="1999"/>
            <abstract>
              <t indent="0">BGP-4 Multiprotocol Extensions (BGP-MP) defines the format of two BGP attributes (MP_REACH_NLRI and MP_UNREACH_NLRI) that can be used to announce and withdraw the announcement of reachability information. This document defines how compliant systems should make use of those attributes for the purpose of conveying IPv6 routing information. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="2545"/>
          <seriesInfo name="DOI" value="10.17487/RFC2545"/>
        </reference>
        <reference anchor="RFC4271" target="https://www.rfc-editor.org/info/rfc4271" quoteTitle="true" derivedAnchor="RFC4271">
          <front>
            <title>A Border Gateway Protocol 4 (BGP-4)</title>
            <author fullname="Y. Rekhter" initials="Y." role="editor" surname="Rekhter"/>
            <author fullname="T. Li" initials="T." role="editor" surname="Li"/>
            <author fullname="S. Hares" initials="S." role="editor" surname="Hares"/>
            <date month="January" year="2006"/>
            <abstract>
              <t indent="0">This document discusses the Border Gateway Protocol (BGP), which is an inter-Autonomous System routing protocol.</t>
              <t indent="0">The primary function of a BGP speaking system is to exchange network reachability information with other BGP systems. This network reachability information includes information on the list of Autonomous Systems (ASes) that reachability information traverses. This information is sufficient for constructing a graph of AS connectivity for this reachability from which routing loops may be pruned, and, at the AS level, some policy decisions may be enforced.</t>
              <t indent="0">BGP-4 provides a set of mechanisms for supporting Classless Inter-Domain Routing (CIDR). These mechanisms include support for advertising a set of destinations as an IP prefix, and eliminating the concept of network "class" within BGP. BGP-4 also introduces mechanisms that allow aggregation of routes, including aggregation of AS paths.</t>
              <t indent="0">This document obsoletes RFC 1771. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="4271"/>
          <seriesInfo name="DOI" value="10.17487/RFC4271"/>
        </reference>
        <reference anchor="RFC4272" target="https://www.rfc-editor.org/info/rfc4272" quoteTitle="true" derivedAnchor="RFC4272">
          <front>
            <title>BGP Security Vulnerabilities Analysis</title>
            <author fullname="S. Murphy" initials="S." surname="Murphy"/>
            <date month="January" year="2006"/>
            <abstract>
              <t indent="0">Border Gateway Protocol 4 (BGP-4), along with a host of other infrastructure protocols designed before the Internet environment became perilous, was originally designed with little consideration for protection of the information it carries. There are no mechanisms internal to BGP that protect against attacks that modify, delete, forge, or replay data, any of which has the potential to disrupt overall network routing behavior.</t>
              <t indent="0">This document discusses some of the security issues with BGP routing data dissemination. This document does not discuss security issues with forwarding of packets. This memo provides information for the Internet community.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="4272"/>
          <seriesInfo name="DOI" value="10.17487/RFC4272"/>
        </reference>
        <reference anchor="RFC8402" target="https://www.rfc-editor.org/info/rfc8402" quoteTitle="true" derivedAnchor="RFC8402">
          <front>
            <title>Segment Routing Architecture</title>
            <author fullname="C. Filsfils" initials="C." role="editor" surname="Filsfils"/>
            <author fullname="S. Previdi" initials="S." role="editor" surname="Previdi"/>
            <author fullname="L. Ginsberg" initials="L." surname="Ginsberg"/>
            <author fullname="B. Decraene" initials="B." surname="Decraene"/>
            <author fullname="S. Litkowski" initials="S." surname="Litkowski"/>
            <author fullname="R. Shakir" initials="R." surname="Shakir"/>
            <date month="July" year="2018"/>
            <abstract>
              <t indent="0">Segment Routing (SR) leverages the source routing paradigm. A node steers a packet through an ordered list of instructions, called "segments". A segment can represent any instruction, topological or service based. A segment can have a semantic local to an SR node or global within an SR domain. SR provides a mechanism that allows a flow to be restricted to a specific topological path, while maintaining per-flow state only at the ingress node(s) to the SR domain.</t>
              <t indent="0">SR can be directly applied to the MPLS architecture with no change to the forwarding plane. A segment is encoded as an MPLS label. An ordered list of segments is encoded as a stack of labels. The segment to process is on the top of the stack. Upon completion of a segment, the related label is popped from the stack.</t>
              <t indent="0">SR can be applied to the IPv6 architecture, with a new type of routing header. A segment is encoded as an IPv6 address. An ordered list of segments is encoded as an ordered list of IPv6 addresses in the routing header. The active segment is indicated by the Destination Address (DA) of the packet. The next active segment is indicated by a pointer in the new routing header.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8402"/>
          <seriesInfo name="DOI" value="10.17487/RFC8402"/>
        </reference>
        <reference anchor="RFC8754" target="https://www.rfc-editor.org/info/rfc8754" quoteTitle="true" derivedAnchor="RFC8754">
          <front>
            <title>IPv6 Segment Routing Header (SRH)</title>
            <author fullname="C. Filsfils" initials="C." role="editor" surname="Filsfils"/>
            <author fullname="D. Dukes" initials="D." role="editor" surname="Dukes"/>
            <author fullname="S. Previdi" initials="S." surname="Previdi"/>
            <author fullname="J. Leddy" initials="J." surname="Leddy"/>
            <author fullname="S. Matsushima" initials="S." surname="Matsushima"/>
            <author fullname="D. Voyer" initials="D." surname="Voyer"/>
            <date month="March" year="2020"/>
            <abstract>
              <t indent="0">Segment Routing can be applied to the IPv6 data plane using a new type of Routing Extension Header called the Segment Routing Header (SRH). This document describes the SRH and how it is used by nodes that are Segment Routing (SR) capable.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8754"/>
          <seriesInfo name="DOI" value="10.17487/RFC8754"/>
        </reference>
        <reference anchor="RFC8986" target="https://www.rfc-editor.org/info/rfc8986" quoteTitle="true" derivedAnchor="RFC8986">
          <front>
            <title>Segment Routing over IPv6 (SRv6) Network Programming</title>
            <author fullname="C. Filsfils" initials="C." role="editor" surname="Filsfils"/>
            <author fullname="P. Camarillo" initials="P." role="editor" surname="Camarillo"/>
            <author fullname="J. Leddy" initials="J." surname="Leddy"/>
            <author fullname="D. Voyer" initials="D." surname="Voyer"/>
            <author fullname="S. Matsushima" initials="S." surname="Matsushima"/>
            <author fullname="Z. Li" initials="Z." surname="Li"/>
            <date month="February" year="2021"/>
            <abstract>
              <t indent="0">The Segment Routing over IPv6 (SRv6) Network Programming framework enables a network operator or an application to specify a packet processing program by encoding a sequence of instructions in the IPv6 packet header.</t>
              <t indent="0">Each instruction is implemented on one or several nodes in the network and identified by an SRv6 Segment Identifier in the packet.</t>
              <t indent="0">This document defines the SRv6 Network Programming concept and specifies the base set of SRv6 behaviors that enables the creation of interoperable overlays with underlay optimization.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8986"/>
          <seriesInfo name="DOI" value="10.17487/RFC8986"/>
        </reference>
        <reference anchor="RFC9012" target="https://www.rfc-editor.org/info/rfc9012" quoteTitle="true" derivedAnchor="RFC9012">
          <front>
            <title>The BGP Tunnel Encapsulation Attribute</title>
            <author fullname="K. Patel" initials="K." surname="Patel"/>
            <author fullname="G. Van de Velde" initials="G." surname="Van de Velde"/>
            <author fullname="S. Sangli" initials="S." surname="Sangli"/>
            <author fullname="J. Scudder" initials="J." surname="Scudder"/>
            <date month="April" year="2021"/>
            <abstract>
              <t indent="0">This document defines a BGP path attribute known as the "Tunnel Encapsulation attribute", which can be used with BGP UPDATEs of various Subsequent Address Family Identifiers (SAFIs) to provide information needed to create tunnels and their corresponding encapsulation headers. It provides encodings for a number of tunnel types, along with procedures for choosing between alternate tunnels and routing packets into tunnels.</t>
              <t indent="0">This document obsoletes RFC 5512, which provided an earlier definition of the Tunnel Encapsulation attribute. RFC 5512 was never deployed in production. Since RFC 5566 relies on RFC 5512, it is likewise obsoleted. This document updates RFC 5640 by indicating that the Load-Balancing Block sub-TLV may be included in any Tunnel Encapsulation attribute where load balancing is desired.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="9012"/>
          <seriesInfo name="DOI" value="10.17487/RFC9012"/>
        </reference>
        <reference anchor="RFC9252" target="https://www.rfc-editor.org/info/rfc9252" quoteTitle="true" derivedAnchor="RFC9252">
          <front>
            <title>BGP Overlay Services Based on Segment Routing over IPv6 (SRv6)</title>
            <author fullname="G. Dawra" initials="G." role="editor" surname="Dawra"/>
            <author fullname="K. Talaulikar" initials="K." role="editor" surname="Talaulikar"/>
            <author fullname="R. Raszuk" initials="R." surname="Raszuk"/>
            <author fullname="B. Decraene" initials="B." surname="Decraene"/>
            <author fullname="S. Zhuang" initials="S." surname="Zhuang"/>
            <author fullname="J. Rabadan" initials="J." surname="Rabadan"/>
            <date month="July" year="2022"/>
            <abstract>
              <t indent="0">This document defines procedures and messages for SRv6-based BGP services, including Layer 3 Virtual Private Network (L3VPN), Ethernet VPN (EVPN), and Internet services. It builds on "BGP/MPLS IP Virtual Private Networks (VPNs)" (RFC 4364) and "BGP MPLS-Based Ethernet VPN" (RFC 7432).</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="9252"/>
          <seriesInfo name="DOI" value="10.17487/RFC9252"/>
        </reference>
        <reference anchor="RFC9256" target="https://www.rfc-editor.org/info/rfc9256" quoteTitle="true" derivedAnchor="RFC9256">
          <front>
            <title>Segment Routing Policy Architecture</title>
            <author fullname="C. Filsfils" initials="C." surname="Filsfils"/>
            <author fullname="K. Talaulikar" initials="K." role="editor" surname="Talaulikar"/>
            <author fullname="D. Voyer" initials="D." surname="Voyer"/>
            <author fullname="A. Bogdanov" initials="A." surname="Bogdanov"/>
            <author fullname="P. Mattes" initials="P." surname="Mattes"/>
            <date month="July" year="2022"/>
            <abstract>
              <t indent="0">Segment Routing (SR) allows a node to steer a packet flow along any path. Intermediate per-path states are eliminated thanks to source routing. SR Policy is an ordered list of segments (i.e., instructions) that represent a source-routed policy. Packet flows are steered into an SR Policy on a node where it is instantiated called a headend node. The packets steered into an SR Policy carry an ordered list of segments associated with that SR Policy.</t>
              <t indent="0">This document updates RFC 8402 as it details the concepts of SR Policy and steering into an SR Policy.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="9256"/>
          <seriesInfo name="DOI" value="10.17487/RFC9256"/>
        </reference>
      </references>
      <references pn="section-7.2">
        <name slugifiedName="name-informative-references">Informative References</name>
        <reference anchor="BGP-CAR" target="https://datatracker.ietf.org/doc/html/draft-ietf-idr-bgp-car-16" quoteTitle="true" derivedAnchor="BGP-CAR">
          <front>
            <title>BGP Color-Aware Routing (CAR)</title>
            <author initials="D." surname="Rao" fullname="Dhananjaya Rao" role="editor">
              <organization showOnFrontPage="true">Cisco Systems</organization>
            </author>
            <author initials="S." surname="Agrawal" fullname="Swadesh Agrawal" role="editor">
              <organization showOnFrontPage="true">Cisco Systems</organization>
            </author>
            <date month="February" day="20" year="2025"/>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-ietf-idr-bgp-car-16"/>
          <refcontent>Work in Progress</refcontent>
        </reference>
        <reference anchor="I-D.ietf-idr-bgp-ct" target="https://datatracker.ietf.org/doc/html/draft-ietf-idr-bgp-ct-39" quoteTitle="true" derivedAnchor="BGP-CT">
          <front>
            <title>BGP Classful Transport Planes</title>
            <author initials="K." surname="Vairavakkalai" fullname="Kaliraj Vairavakkalai" role="editor">
              <organization showOnFrontPage="true">Juniper Networks, Inc.</organization>
            </author>
            <author initials="N." surname="Venkataraman" fullname="Natrajan Venkataraman" role="editor">
              <organization showOnFrontPage="true">Juniper Networks, Inc.</organization>
            </author>
            <date month="February" day="28" year="2025"/>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-ietf-idr-bgp-ct-39"/>
          <refcontent>Work in Progress</refcontent>
        </reference>
        <reference anchor="I-D.hr-spring-intentaware-routing-using-color" target="https://datatracker.ietf.org/doc/html/draft-hr-spring-intentaware-routing-using-color-04" quoteTitle="true" derivedAnchor="INTENTAWARE">
          <front>
            <title>Problem statement for Inter-domain Intent-aware Routing using Color</title>
            <author fullname="Shraddha Hegde" initials="S." surname="Hegde">
              <organization showOnFrontPage="true">Juniper Networks Inc.</organization>
            </author>
            <author fullname="Dhananjaya Rao" initials="D." surname="Rao">
              <organization showOnFrontPage="true">Cisco Systems</organization>
            </author>
            <author fullname="Jim Uttaro" initials="J." surname="Uttaro">
              <organization showOnFrontPage="true">Independent Contributor</organization>
            </author>
            <author fullname="Alex Bogdanov" initials="A." surname="Bogdanov">
              <organization showOnFrontPage="true">BT</organization>
            </author>
            <author fullname="Luay Jalil" initials="L." surname="Jalil">
              <organization showOnFrontPage="true">Verizon</organization>
            </author>
            <date day="31" month="January" year="2025"/>
            <abstract>
              <t indent="0">This draft describes the scope, set of use-cases and requirements for a distributed routing based solution to establish end-to-end intent- aware paths spanning multi-domain packet networks. The document focuses on BGP given its predominant use in inter-domain routing deployments, however the requirements may also apply to other solutions.</t>
            </abstract>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-hr-spring-intentaware-routing-using-color-04"/>
          <refcontent>Work in Progress</refcontent>
        </reference>
        <reference anchor="RFC3031" target="https://www.rfc-editor.org/info/rfc3031" quoteTitle="true" derivedAnchor="RFC3031">
          <front>
            <title>Multiprotocol Label Switching Architecture</title>
            <author fullname="E. Rosen" initials="E." surname="Rosen"/>
            <author fullname="A. Viswanathan" initials="A." surname="Viswanathan"/>
            <author fullname="R. Callon" initials="R." surname="Callon"/>
            <date month="January" year="2001"/>
            <abstract>
              <t indent="0">This document specifies the architecture for Multiprotocol Label Switching (MPLS). [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="3031"/>
          <seriesInfo name="DOI" value="10.17487/RFC3031"/>
        </reference>
        <reference anchor="RFC3032" target="https://www.rfc-editor.org/info/rfc3032" quoteTitle="true" derivedAnchor="RFC3032">
          <front>
            <title>MPLS Label Stack Encoding</title>
            <author fullname="E. Rosen" initials="E." surname="Rosen"/>
            <author fullname="D. Tappan" initials="D." surname="Tappan"/>
            <author fullname="G. Fedorkow" initials="G." surname="Fedorkow"/>
            <author fullname="Y. Rekhter" initials="Y." surname="Rekhter"/>
            <author fullname="D. Farinacci" initials="D." surname="Farinacci"/>
            <author fullname="T. Li" initials="T." surname="Li"/>
            <author fullname="A. Conta" initials="A." surname="Conta"/>
            <date month="January" year="2001"/>
            <abstract>
              <t indent="0">This document specifies the encoding to be used by an LSR in order to transmit labeled packets on Point-to-Point Protocol (PPP) data links, on LAN data links, and possibly on other data links as well. This document also specifies rules and procedures for processing the various fields of the label stack encoding. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="3032"/>
          <seriesInfo name="DOI" value="10.17487/RFC3032"/>
        </reference>
        <reference anchor="RFC4798" target="https://www.rfc-editor.org/info/rfc4798" quoteTitle="true" derivedAnchor="RFC4798">
          <front>
            <title>Connecting IPv6 Islands over IPv4 MPLS Using IPv6 Provider Edge Routers (6PE)</title>
            <author fullname="J. De Clercq" initials="J." surname="De Clercq"/>
            <author fullname="D. Ooms" initials="D." surname="Ooms"/>
            <author fullname="S. Prevost" initials="S." surname="Prevost"/>
            <author fullname="F. Le Faucheur" initials="F." surname="Le Faucheur"/>
            <date month="February" year="2007"/>
            <abstract>
              <t indent="0">This document explains how to interconnect IPv6 islands over a Multiprotocol Label Switching (MPLS)-enabled IPv4 cloud. This approach relies on IPv6 Provider Edge routers (6PE), which are Dual Stack in order to connect to IPv6 islands and to the MPLS core, which is only required to run IPv4 MPLS. The 6PE routers exchange the IPv6 reachability information transparently over the core using the Multiprotocol Border Gateway Protocol (MP-BGP) over IPv4. In doing so, the BGP Next Hop field is used to convey the IPv4 address of the 6PE router so that dynamically established IPv4-signaled MPLS Label Switched Paths (LSPs) can be used without explicit tunnel configuration. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="4798"/>
          <seriesInfo name="DOI" value="10.17487/RFC4798"/>
        </reference>
        <reference anchor="RFC8277" target="https://www.rfc-editor.org/info/rfc8277" quoteTitle="true" derivedAnchor="RFC8277">
          <front>
            <title>Using BGP to Bind MPLS Labels to Address Prefixes</title>
            <author fullname="E. Rosen" initials="E." surname="Rosen"/>
            <date month="October" year="2017"/>
            <abstract>
              <t indent="0">This document specifies a set of procedures for using BGP to advertise that a specified router has bound a specified MPLS label (or a specified sequence of MPLS labels organized as a contiguous part of a label stack) to a specified address prefix. This can be done by sending a BGP UPDATE message whose Network Layer Reachability Information field contains both the prefix and the MPLS label(s) and whose Next Hop field identifies the node at which said prefix is bound to said label(s). This document obsoletes RFC 3107.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8277"/>
          <seriesInfo name="DOI" value="10.17487/RFC8277"/>
        </reference>
        <reference anchor="RFC8660" target="https://www.rfc-editor.org/info/rfc8660" quoteTitle="true" derivedAnchor="RFC8660">
          <front>
            <title>Segment Routing with the MPLS Data Plane</title>
            <author fullname="A. Bashandy" initials="A." role="editor" surname="Bashandy"/>
            <author fullname="C. Filsfils" initials="C." role="editor" surname="Filsfils"/>
            <author fullname="S. Previdi" initials="S." surname="Previdi"/>
            <author fullname="B. Decraene" initials="B." surname="Decraene"/>
            <author fullname="S. Litkowski" initials="S." surname="Litkowski"/>
            <author fullname="R. Shakir" initials="R." surname="Shakir"/>
            <date month="December" year="2019"/>
            <abstract>
              <t indent="0">Segment Routing (SR) leverages the source-routing paradigm. A node steers a packet through a controlled set of instructions, called segments, by prepending the packet with an SR header. In the MPLS data plane, the SR header is instantiated through a label stack. This document specifies the forwarding behavior to allow instantiating SR over the MPLS data plane (SR-MPLS).</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8660"/>
          <seriesInfo name="DOI" value="10.17487/RFC8660"/>
        </reference>
        <reference anchor="RFC9602" target="https://www.rfc-editor.org/info/rfc9602" quoteTitle="true" derivedAnchor="RFC9602">
          <front>
            <title>Segment Routing over IPv6 (SRv6) Segment Identifiers in the IPv6 Addressing Architecture</title>
            <author fullname="S. Krishnan" initials="S." surname="Krishnan"/>
            <date month="October" year="2024"/>
            <abstract>
              <t indent="0">Segment Routing over IPv6 (SRv6) uses IPv6 as the underlying data plane. Thus, Segment Identifiers (SIDs) used by SRv6 can resemble IPv6 addresses and behave like them while exhibiting slightly different behaviors in some situations. This document explores the characteristics of SRv6 SIDs and focuses on the relationship of SRv6 SIDs to the IPv6 Addressing Architecture. This document allocates and makes a dedicated prefix available for SRv6 SIDs.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="9602"/>
          <seriesInfo name="DOI" value="10.17487/RFC9602"/>
        </reference>
        <reference anchor="I-D.ietf-spring-srv6-mpls-interworking" target="https://datatracker.ietf.org/doc/html/draft-ietf-spring-srv6-mpls-interworking-00" quoteTitle="true" derivedAnchor="SRv6-INTERWORK">
          <front>
            <title>SRv6 and MPLS interworking</title>
            <author initials="S." surname="Agrawal" fullname="Swadesh Agrawal" role="editor">
              <organization showOnFrontPage="true">Cisco Systems</organization>
            </author>
            <author initials="C." surname="Filsfils" fullname="Clarence Filsfils">
              <organization showOnFrontPage="true">Cisco Systems</organization>
            </author>
            <author initials="D." surname="Voyer" fullname="Daniel Voyer">
              <organization showOnFrontPage="true">Bell Canada</organization>
            </author>
            <author initials="G." surname="Dawra" fullname="Gaurav Dawra">
              <organization showOnFrontPage="true">LinkedIn</organization>
            </author>
            <author initials="Z." surname="Li" fullname="Zhenbin Li">
              <organization showOnFrontPage="true">Huawei Technologies</organization>
            </author>
            <author initials="S." surname="Hegde" fullname="Shraddha Hegde">
              <organization showOnFrontPage="true">Juniper Networks</organization>
            </author>
            <date month="October" day="17" year="2024"/>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-ietf-spring-srv6-mpls-interworking-00"/>
          <refcontent>Work in Progress</refcontent>
        </reference>
      </references>
    </references>
    <section anchor="Acknowledgements" numbered="false" toc="include" removeInRFC="false" pn="section-appendix.a">
      <name slugifiedName="name-acknowledgements">Acknowledgements</name>
      <t indent="0" pn="section-appendix.a-1">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 anchor="contribs" numbered="false" toc="include" removeInRFC="false" pn="section-appendix.b">
      <name slugifiedName="name-contributors">Contributors</name>
      <t indent="0" pn="section-appendix.b-1">The following people contributed significantly to the content of this
      document and should be considered co-authors:</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="authors-addresses" numbered="false" removeInRFC="false" toc="include" pn="section-appendix.c">
      <name slugifiedName="name-authors-addresses">Authors' Addresses</name>
      <author fullname="Haibo Wang" initials="H." surname="Wang">
        <organization showOnFrontPage="true">Huawei Technologies</organization>
        <address>
          <postal>
            <country>China</country>
          </postal>
          <email>rainsword.wang@huawei.com</email>
        </address>
      </author>
      <author fullname="Jie Dong" initials="J." surname="Dong">
        <organization showOnFrontPage="true">Huawei Technologies</organization>
        <address>
          <postal>
            <country>China</country>
          </postal>
          <email>jie.dong@huawei.com</email>
        </address>
      </author>
      <author fullname="Ketan Talaulikar" initials="K." surname="Talaulikar">
        <organization showOnFrontPage="true">Cisco Systems</organization>
        <address>
          <postal>
            <country>India</country>
          </postal>
          <email>ketant.ietf@gmail.com</email>
        </address>
      </author>
      <author fullname="Tao Han" initials="T." surname="Han">
        <organization showOnFrontPage="true">Huawei Technologies</organization>
        <address>
          <postal>
            <country>China</country>
          </postal>
          <email>hantao@huawei.com</email>
        </address>
      </author>
      <author fullname="Ran Chen" initials="R." surname="Chen">
        <organization showOnFrontPage="true">ZTE Corporation</organization>
        <address>
          <postal>
            <country>China</country>
          </postal>
          <email>chen.ran@zte.com.cn</email>
        </address>
      </author>
    </section>
  </back>
</rfc>
