<?xml version="1.0" encoding="US-ASCII"?>
<?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"?> version='1.0' encoding='UTF-8'?>

<!DOCTYPE rfc [
  <!ENTITY nbsp    "&#160;">
  <!ENTITY zwsp   "&#8203;">
  <!ENTITY nbhy   "&#8209;">
  <!ENTITY wj     "&#8288;">
]>

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

  <front>
    <title abbrev="BGP Color-Aware Routing (CAR)">
    BGP (CAR)">BGP Color-Aware Routing (CAR)
    </title> (CAR)</title>
    <seriesInfo name="RFC" value="9871"/>
    <author fullname="Dhananjaya Rao" initials="D" role="editor" surname="Rao">
      <organization>Cisco Systems</organization>
      <address>
        <postal>
          <street/>

          <country>USA</country>
          <country>United States of America</country>
        </postal>
        <email>dhrao@cisco.com</email>
      </address>
    </author>
    <author fullname="Swadesh Agrawal" initials="S" role="editor" surname="Agrawal">
      <organization>Cisco Systems</organization>
      <address>
        <postal>
          <street/>

          <country>USA</country>
          <country>United States of America</country>
        </postal>
        <email>swaagraw@cisco.com</email>
      </address>
    </author>

    <date/>

    <area>Routing</area>

    <workgroup>IDR WorkGroup</workgroup>
    <date month="September" year="2025"/>
    <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 BGP based BGP-based routing solution to establish
    end-to-end intent-aware paths across a multi-domain transport network. The transport
    network can span multiple service provider and customer network domains.
    The BGP intent-aware paths can be used to steer traffic flows for service routes
    that need a specific intent. This solution is called BGP Color-Aware Routing (BGP CAR).
      </t>
      <t>
   This document describes the routing framework and BGP extensions to enable
   intent-aware routing using the BGP CAR solution. The solution defines two
   new BGP SAFIs (BGP CAR SAFI and BGP VPN CAR SAFI) for IPv4 and IPv6. It
   also defines an extensible NLRI Network Layer Reachability Information (NLRI)
   model for both SAFIs that allow allows multiple NLRI types to be defined for
   different use cases.  Each type of NLRI contains key and TLV based TLV-based non-key
   fields for efficient encoding of different per-prefix information. This
   specification defines two NLRI types, types: Color-Aware Route NLRI and IP Prefix
   NLRI. It defines non-key TLV types for the MPLS label stack, stack -- Label Index and SRv6 SIDs.
   and Segment Routing over IPv6 (SRv6) Segment Identifiers (SIDs). This
   solution also defines a new Local Color Mapping (LCM) Extended Community.
      </t>
    </abstract>
  </front>
  <middle>
    <section anchor="INTRO" title="Introduction"> anchor="INTRO">
      <name>Introduction</name>

      <t>
      BGP Color-Aware Routing (CAR) is a BGP based BGP-based routing solution to establish
      end-to-end intent-aware paths across a multi-domain service provider
      transport network. BGP CAR distributes distinct routes to a destination network
      endpoint, such as a PE Provider Edge (PE) router, for different intents or colors. Color is a
      non-zero 32-bit integer value associated with a network intent (low-cost, low-delay, (such as low cost, low delay,
      avoid some resources, 5G network slice, etc.) as defined in Section 2.1 of
      <xref target="RFC9256"/>. target="RFC9256" sectionFormat="of" section="2.1"/>.
      </t>

      <t>
      BGP CAR fulfills the transport and VPN problem statement and the requirements described
      in <xref target="I-D.hr-spring-intentaware-routing-using-color"/>.
      </t>
      <t>
      For this purpose, this document specifies two new BGP SAFIs, called
      BGP CAR SAFI (83) and VPN CAR SAFI (84) (84), that carry infrastructure routes to
      set up the transport paths. Both CAR SAFI and VPN CAR SAFI apply to IPv4 Unicast and
      IPv6 Unicast AFIs (AFI 1 and AFI 2). The use of these SAFIs with other AFIs are
      outside the scope of this document.
      </t>
      <t>
      BGP CAR SAFI can be enabled on transport devices in a provider network
      (underlay) to set up color-aware transport/infrastructure paths across
      provider networks.  The multi-domain transport network may comprise of
      multiple BGP ASes Autonomous Systems (ASes) as well as multiple IGP domains within a single BGP
      AS. BGP CAR SAFI can also be enabled within a VRF VPN Routing and Forwarding (VRF) on a PE router towards
      a peering CE Customer Edge (CE) router, and on devices within a customer
      network. VPN CAR SAFI is used for the distribution of intent-aware
      routes from different customers received on a PE router across the
      provider networks, maintaining the separation of the customer address
      spaces that may overlap. The BGP CAR solution thus enables intent-aware
      transport paths to be set up across a multi-domain network that can span
      customer and provider network domains.
      </t>
      <t>
      The
      This document also defines two BGP CAR route types for this purpose.
      </t>
      <t>
      The BGP CAR Type-1 NLRI (E, C) enables the generation and distribution of multiple
      color-aware routes to the same destination IP prefix for different colors.
      This case arises from situations where a transport node such as a PE has a common
      IP address (such as a loopback) to advertise for multiple intents. The operator intends
      to use the common IP address as both the BGP next hop for service routes and as the
      transport endpoint for the data plane path. Multiple routes are needed for this same
      address or prefix to set up a unique path for each intent. One example is setting up
      multiple MPLS/SR-MPLS LSPs Label Switched Paths (LSPs) for MPLS or Segment Routing over MPLS (SR-MPLS) to an egress PE, one per intent.
      </t>
      <t>
      The BGP CAR Type-2 NLRI (IP Prefix or E) enables the distribution of multiple color-aware routes to a
      transport node for the case where the operator specifies a unique network
      IP address block for a given intent, and the transport node gets assigned a
      unique IP prefix or address for each intent. An example use-case use case is
      SRv6 Segment Routing over IPv6 (SRv6)
      per-intent locators.
      </t>
      <t>
      These BGP CAR intent-aware paths are then used by an ingress node (such as a PE) to
      steer traffic flows for service routes that need the specific intents. Steering may be
      towards a destination for all or specific traffic flows.
      </t>
      <t>
      BGP CAR adheres to the flat routing model of BGP-IP/LU(Labeled Unicast) but extends
      it to support intent-awareness, intent awareness, thereby providing a consistent operational experience
      with those widely deployed transport routing technologies.
      </t>

      <section title="Terminology">
        <texttable>
          <ttcol width="20%"></ttcol>
          <ttcol width="48%"></ttcol>

          <c>Intent
      <section>
        <name>Terminology</name>

<!-- [rfced] Section 1.1. Terminology: We have made the following changes in
this section; please review and let us know if any adjustments are needed.

a) We have updated the text below to clarify the order of preference:

Original:
  If several such paths exist, a preference scheme is used to select the best
  path (for example, IGP Flex-Algo preferred over SR Policy preferred over BGP CAR.

Current:
  If several such paths exist, a preference scheme is used to select the best
  path (for example, IGP Flex-Algo is preferred over SR Policy, and SR Policy
  is preferred over BGP CAR).

b) We have updated "trust domain" to "trusted domain" in the text below
for consistency with RFC 8402.

Original:
  In an SR deployment, the transport network is within a trust domain as per
  [RFC8402].

Current:
  In an SR deployment, the transport network is within a trusted domain as per
  [RFC8402].
-->

<!-- [rfced] Section 1.1. (Abbreviations): We have the following
questions regarding the abbreviations list in this section.

a) We were unable to find the term "BGP-LU" or "BGP Labeled Unicast SAFI"
mentioned in RFC 8277. Is it the correct reference for this term?

In addition, we also note the following different uses of this term throughout
this document. Please review and let us know how to update for consistency.

BGP IP/LU
BGP LU
BGP-IP/LU(Labeled Unicast)
BGP LU/IP

Original:
   *  BGP-LU: BGP Labeled Unicast SAFI [RFC8277].

b) We were unable to find the term "BGP-IP" or "BGP IPv4/IPv6 Unicast AFI/SAFIs"
in RFCs 4271 and 4760. How may we update?

Original:
   *  BGP-IP: BGP IPv4/IPv6 Unicast AFI/SAFIs [RFC4271], [RFC4760].

c) FYI - We have already made the following updates to this section. Please
review.

i) We have separated this list item into two separate entries for clarity and
have updated their definitions for consistency with RFC 4760:

Original:

   *  AFI/SAFI: BGP Address-Family/Sub-Address-Family Identifiers.

Current:

   AFI:  Address Family Identifier

   SAFI:  Subsequent Address Family Identifier

ii) We have added list entries for the following terms so that they do
not need to be expanded when they appear in figures or other list items.

   ABR:  Area Border Router
   ASBR:  Autonomous System Border Router
   RD:  Route Distinguisher
-->

<dl spacing="normal" newline="true">
          <dt>Intent (in routing)</c>
          <c>Any routing):</dt>
          <dd>
	    <t>Any behaviors to influence routing or path selection, including
	    any combination of the following
          behaviors: a) Topology behaviors:</t>
	    <ol type="a" spacing="compact">
	      <li>Topology path selection
          (e.g. (e.g., minimize metric or avoid resource), b) NFV
	      resource)</li>
	      <li>Network Function Virtualization (NFV) service insertion (e.g. (e.g., service chain steering), c) per-hop steering)</li>
	      <li>Per-hop behavior (e.g. (e.g., a 5G slice). This slice)</li>
	    </ol>
	      <t>This is a more specific concept
          w.r.t. with respect to routing
	      beyond best-effort, compared to intent as a declarative
	      abstraction in <xref target="RFC9315"/>.
          </c>

          <c></c>
          <c></c>
          <c>Color</c>
          <c>A target="RFC9315"/>.</t>
	  </dd>

          <dt>Color:</dt>
          <dd>A non-zero 32-bit integer value associated with an intent (e.g. low-cost
          , low-delay,
          (e.g., low cost, low delay, or avoid some resources) as defined in
          <xref target="RFC9256"/> Section 2.1. target="RFC9256" sectionFormat="of" section="2.1"/>. Color assignment is managed by
          the operator.</c>

          <c></c>
          <c></c>

          <c>Colored Service Route</c>
          <c>An operator.</dd>

          <dt>Colored service route:</dt>
          <dd>An egress PE (e.g. (e.g., E2) colors its BGP service (e.g. (e.g., VPN) route (e.g.
          (e.g., V/v) to indicate the intent that it requests for the traffic
          bound to V/v.  The color is encoded as a BGP Color
          Extended-Community <xref target="RFC9012"/>, used as per [RFC9256], <xref target="RFC9256"/>,
          or represented by the locator part of SRv6 Service SID <xref target="RFC9252"/>.</c>

          <c></c>
          <c></c>

          <c>Color-Aware Path
          target="RFC9252"/>.</dd>

          <dt>Color-aware path to (E2, C)</c>
          <c>A C):</dt>
          <dd>A path to forward packets towards E2 which that satisfies the intent
          associated with color C.  Several technologies may provide a Color-Aware Path
          color-aware path to (E2, C): C), such as SR Policy <xref target="RFC9256"/>, IGP
          Flex-Algo <xref target="RFC9350"/>, and BGP CAR [specified (as specified in this document].</c>

          <c></c>
          <c></c>

          <c>Color-Aware Route document).</dd>

          <dt>Color-aware route (E2, C)</c>
          <c>A C):</dt>
          <dd>A distributed or signaled route that builds a color-aware path to E2 for
          color C.
          </c>

          <c></c>
          <c></c>

          <c>Service Route Automated Steering C.</dd>

          <dt>Service route automated steering on Color-Aware Path</c>
          <c>An color-aware path:</dt>
          <dd>An ingress PE (or ASBR) E1 automatically steers traffic for a
          C-colored service route V/v from E2 onto an (E2, C) color-aware
          path. If several such paths exist, a preference scheme is used to
          select the best path (for example, IGP Flex-Algo is preferred over SR
          Policy, and SR Policy is preferred over BGP CAR.</c>

          <c></c>
          <c></c>

          <c>Color Domain</c>
          <c>A CAR).</dd>

          <dt>Color domain:</dt>
          <dd>A set of nodes which that share the same Color-to-Intent color-to-intent mapping, typically under
          single administration. This set can be organized into one or multiple network domains
          (IGP areas/instances within a single BGP AS, or multiple BGP ASes). Color-to-intent
          mapping on nodes is set by configuration. Color re-mapping and filtering may happen
          at color domain boundaries. Refer to
          <xref target="I-D.hr-spring-intentaware-routing-using-color"/>.</c>

          <c></c>
          <c></c>

          <c>Resolution target="I-D.hr-spring-intentaware-routing-using-color"/>.</dd>

          <dt>Resolution of a BGP CAR route (E, C)</c>
          <c>An C):</dt>
          <dd>An inter-domain BGP CAR route (E, C) via N is resolved on an
          intra-domain color-aware path (N, C) where N is the next hop of the
          BGP CAR
          route.</c>

          <c></c>
          <c></c>

          <c>Resolution vs Steering</c>
          <c>In this document, and consistent route.</dd>

          <dt>Resolution versus steering:</dt>
          <dd>
	    <t>Consistent with the terminology used in the SR Policy document <xref target="RFC9256"/> Section 8, (Service
	    (<xref target="RFC9256" sectionFormat="of" section="8"/>), in
	    this document (service route) steering is used to describe the
	    mapping of the traffic for a service route onto a BGP CAR path.
	    In contrast, the term resolution is preserved for the mapping of
	    an inter-domain BGP CAR route on an intra-domain color-aware path.</c>

          <c></c>
          <c></c>

          <c></c>
          <c>Service Steering: Service
	    path.</t>
	    <dl spacing="normal" newline="true">
              <dt>Service steering:</dt>
	      <dd>Service route maps traffic to a BGP CAR path (or other Color-Aware
          Path: e.g.
	      color-aware path, e.g., SR Policy). If a Color-Aware Path color-aware path is not
	      available, local policy may map to a traditional routing/TE path (e.g.
	      (e.g., BGP LU, RSVP-TE, IGP/LDP).  The service steering concept is
	      agnostic to the transport technology used.  <xref
	      target="STEERING"/> describes the specific service steering
	      mechanisms leveraged for MPLS, SR-MPLS SR-MPLS, and SRv6.
          </c>

          <c></c>
          <c></c>

          <c></c>
          <c>Intra-Domain Resolution: BGP SRv6.</dd>

              <dt>Intra-domain resolution:</dt>
	      <dd>BGP CAR route maps to an intra-domain color aware color-aware path
          (e.g. (e.g., SR
	      Policy, IGP Flex-Algo, BGP CAR) or a traditional routing/TE path (e.g.
	      (e.g., RSVP-TE, IGP/LDP, BGP-LU).</c>

          <c></c>
          <c></c>
	  <c>Transport Network</c>
	  <c>A BGP-LU).</dd>
	    </dl>
	  </dd>

          <dt>Transport network:</dt>
          <dd>A network that comprises of multiple cooperating domains managed
          by one or more operators, and uses routing technologies such as IP, MPLS
          MPLS, and Segment Routing SR to forward packets for connectivity and
          other services.  In an SR deployment, the transport network is
          within a trust trusted domain as per [RFC8402].</c>
          <c></c>
          <c></c>
	  <c>Transport Layer</c>
	  <c>Refers <xref target="RFC8402"/>.</dd>

          <dt>Transport layer:</dt>
          <dd>Refers to an underlay network layer (e.g., MPLS LSPs between
          PEs) that gets used by an overlay or service layer (e.g., MPLS VPNs).</c>
          <c></c>
          <c></c>
          <c>Transport RR</c>
          <c>A
          VPNs).</dd>

          <dt>Transport RR:</dt>
          <dd>A BGP Route Reflector (RR) used to distribute transport/underlay routes within a domain or
          across domains. </c>
          <c></c>
          <c></c>
          <c>Service RR</c>
          <c>A domains.</dd>

          <dt>Service RR:</dt>
          <dd>A BGP Route Reflector (RR) used to distribute service/overlay routes
          within a domain or across domains. </c>

        </texttable> domains.</dd>
	</dl>

        <t>Abbreviations:</t>
        <t><list style="symbols">
          <t>AFI/SAFI: BGP Address-Family/Sub-Address-Family Identifiers.
          </t>
          <t>
	  AIGP: Accumulated
        <dl spacing="normal" newline="false">
	  <dt>ABR:</dt>
	  <dd>Area Border Router</dd>

	  <dt>AFI:</dt>
	  <dd>Address Family Identifier</dd>

	  <dt>AIGP:</dt>
	  <dd>Accumulated IGP Metric Attribute <xref target="RFC7311"/>.
          </t>
          <t>
          BGP-LU: BGP target="RFC7311"/></dd>

	  <dt>ASBR:</dt>
	  <dd>Autonomous System Border Router</dd>

	  <dt>BGP-LU:</dt>
	  <dd>BGP Labeled Unicast SAFI <xref target="RFC8277"/>.
          </t>
          <t>
          BGP-IP: BGP target="RFC8277"/></dd>

	  <dt>BGP-IP:</dt>
	  <dd>BGP IPv4/IPv6 Unicast AFI/SAFIs <xref target="RFC4271"/>,
          target="RFC4271"/> <xref target="RFC4760"/>.
          </t>
          <t>BR: Border Router, either target="RFC4760"/></dd>

	  <dt>BR:</dt><dd>Border Router (either for an IGP Area (ABR) area (an ABR) or a BGP Autonomous System (ASBR).
          </t>
          <t>
	  Color-EC: BGP
          autonomous system (an ASBR))</dd>

	  <dt>Color-EC:</dt>
	  <dd>BGP Color Extended-Community <xref target="RFC9012"/>.
          </t>
          <t>
          E: Generic target="RFC9012"/></dd>

          <dt>E:</dt>
	  <dd>Generic representation of a transport endpoint such
          as a PE, ABR ABR, or ASBR.
          </t>
          <t>
	  LCM-EC: BGP ASBR</dd>

	  <dt>LCM-EC:</dt>
	  <dd>BGP Local Color Mapping Extended-Community.
          </t>
          <t>
          NLRI: Network Extended-Community</dd>

          <dt>NLRI:</dt>
	  <dd>Network Layer Reachability Information <xref target="RFC4271"/>.
          </t>
          <t>P node: An target="RFC4271"/></dd>

          <dt>P node:</dt>
	  <dd>An intra-domain transport router.
          </t>
          <t>RR: BGP Route Reflector.
          </t>
          <t>
	  TEA: Tunnel router</dd>

	  <dt>RD:</dt>
	  <dd>Route Distinguisher</dd>

          <dt>RR:</dt>
	  <dd>Route Reflector</dd>

	  <dt>SAFI:</dt>
	  <dd>Subsequent Address Family Identifier</dd>

	  <dt>TEA:</dt>
	  <dd>Tunnel Encapsulation Attribute <xref target="RFC9012"/>.
          </t>
          <t>
          V/v, W/w: Generic target="RFC9012"/></dd>

          <dt>V/v, W/w:</dt>
	  <dd>Generic representations of a service route (indicating prefix/masklength),
	  prefix/mask length), regardless of AFI/SAFI or actual NLRI encoding.
          </t>

          </list>
        </t>
	  encoding</dd>

        </dl>
      </section>
      <section anchor="SECCARIllus" title="Illustration"> anchor="SECCARIllus">
        <name>Illustration</name>
        <t>Here is a brief illustration of the salient properties of the BGP CAR
        solution.</t>
        <figure anchor="Illustration" title="BGP anchor="Illustration">
          <name>BGP CAR Solution Illustration"> Illustration</name>
          <artwork><![CDATA[
+-------------+      +-------------+      +-------------+
|             |      |             |      |             | V/v with C1
|----+        |------|             |------|        +----|/
| E1 |        |      |             |      |        | E2 |\
|----+        |      |             |      |        +----| W/w with C2
|             |------|             |------|             |
|  Domain 1   |      |   Domain 2  |      |   Domain 3  |
+-------------+      +-------------+      +-------------+
]]></artwork>
        </figure>
        <t>All the nodes are part of an inter-domain network under a single authority
        and with a consistent color-to-intent mapping:
          <list style="symbols">
        </t>
        <ul spacing="normal">
          <li>
            <t>C1 is mapped to "low-delay"
            <list>
            </t>
            <ul spacing="normal">
              <li>
                <t>Flex-Algo FA1 is mapped to "low delay" delay", and hence to C1</t>
            </list>
          </t>
              </li>
            </ul>
          </li>
          <li>
            <t>C2 is mapped to "low-delay and avoid resource R"
            <list> R"</t>
            <ul spacing="normal">
              <li>
                <t>Flex-Algo FA2 is mapped to "low delay and avoid resource R" R", and hence to C2</t>
            </list>
          </t>
          </list>
        </t>
              </li>
            </ul>
          </li>
        </ul>
        <t>E1 receives two service routes from E2:
          <list style="symbols">
        </t>
        <ul spacing="normal">
          <li>
            <t>V/v with BGP Color-EC C1</t>
          </li>
          <li>
            <t>W/w with BGP Color-EC C2</t>
          </list>
        </t>
          </li>
        </ul>
        <t>E1 has the following color-aware paths:
          <list style="symbols"> paths:</t>

        <ul spacing="normal">
          <li>
            <t>(E2, C1) provided by BGP CAR with the following per-domain support:
            <list>
            <t>Domain1: support:</t>
            <ul spacing="normal">
              <li>
                <t>Domain 1: over IGP FA1</t>
            <t>Domain2:
              </li>
              <li>
                <t>Domain 2: over SR Policy bound to color C1</t>
            <t>Domain3:
              </li>
              <li>
                <t>Domain 3: over IGP FA1</t>
            </list>
          </t>
              </li>
            </ul>
          </li>
          <li>
            <t>(E2, C2) provided by SR Policy</t>
          </list>
        </t>
          </li>
        </ul>

        <t>E1 automatically steers traffic for the received service routes as follows:
          <list style="symbols"> follows:</t>

        <ul spacing="normal">
          <li>
            <t>V/v via (E2, C1) provided by BGP CAR</t>
          </li>
          <li>
            <t>W/w via (E2, C2) provided by SR Policy</t>
          </list>
        </t>
          </li>
        </ul>

        <t>Illustrated Properties:
          <list style="symbols"> properties:</t>

        <ul spacing="normal">
          <li>
            <t>Leverage of the BGP Color-EC
            <list>
            </t>
            <ul spacing="normal">
              <li>
                <t>The service routes are colored with widely used BGP Color
                Extended-Community <xref target="RFC9012"/> to request
                intent</t>
            </list>
          </t>
              </li>
            </ul>
          </li>
          <li>
            <t>(E, C) Automated Steering
            <list> automated steering</t>
            <ul spacing="normal">
              <li>
                <t>V/v and W/w are automatically steered on the appropriate color-aware
            path</t>
            </list>
          </t>
              </li>
            </ul>
          </li>
          <li>
            <t>Seamless co-existence coexistence of BGP CAR and SR Policy
            <list>
            </t>
            <ul spacing="normal">
              <li>
                <t>V/v is steered on BGP CAR color-aware path</t>
              </li>
              <li>
                <t>W/w is steered on SR Policy color-aware path</t>
            </list>
          </t>
              </li>
            </ul>
          </li>
          <li>
            <t>Seamless interworking of BGP CAR and SR Policy
            <list>
            </t>
            <ul spacing="normal">
              <li>
                <t>V/v is steered on a BGP CAR color-aware path that is itself resolved
            within domain 2 onto an SR Policy bound to the color of V/v</t>
            </list>
          </t>
      	    </list>
        </t>
              </li>
            </ul>
          </li>
        </ul>
        <t>Other properties:
          <list style="symbols">
        </t>
        <ul spacing="normal">
          <li>
            <t>MPLS data-plane: with 300k PE's PEs and 5 colors, the BGP CAR solution ensures
          that no single node needs to support a data-plane scaling in the order of
          Remote PE * C (<xref target="SCLNG"/>). This would otherwise exceed the MPLS
          data-plane.</t>
          <t>Control-Plane:
          </li>
          <li>
            <t>Control-plane: a node should not install a (E, C) path if it's not participating
          in that color-aware path.</t>
          </li>
          <li>
            <t>Incongruent Color-Intent color-intent mapping: the solution supports the signaling of
          a BGP CAR route across different color domains. domains
          (<xref target="SDIFFCOLORS"/>)</t>
          </list>
        </t> target="SDIFFCOLORS"/>).</t>
          </li>
        </ul>

        <t>The key benefits of this model are:
          <list style="symbols">
          <t>leverage are:</t>
        <ul spacing="normal">
          <li>
            <t>Leverage of the BGP Color-EC <xref target="RFC9012"/> to color
          service routes</t>
          <t>the
          </li>
          <li>
            <t>The definition of the automated service steering: a C-colored service route V/v
          from E2 is steered onto a color-aware path (E2, C)</t>
          <t>the
          </li>
          <li>
            <t>The definition of the data model of a BGP CAR path: (E, C)
            <list>
            <t>natural
            </t>
            <ul spacing="normal">
              <li>
                <t>Natural extension of BGP IP/LU data model (E)</t>
            <t>consistent
              </li>
              <li>
                <t>Consistent with SR Policy data model</t>
            </list>
          </t>
          <t>the
              </li>
            </ul>
          </li>
          <li>
            <t>The definition of the recursive resolution of a BGP CAR route: a BGP CAR
          (E2, C) route via N is resolved onto the color-aware path (N, C) C), which may itself
          be provided by BGP CAR or via another color-aware routing solution (e.g.,
          SR Policy, IGP Flex-Algo).</t> Flex-Algo)</t>
          </li>
          <li>
            <t>Native support for multiple transport encapsulations (e.g., MPLS, SR,
          SRv6, IP)</t>
          </list>
        </t>
          </li>
        </ul>
      </section>
      <section title="Requirements Language">
        <t>The
      <section>
	<name>Requirements Language</name>
        <t>
    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
        "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
    "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>",
    "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>",
    "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
    "<bcp14>MAY</bcp14>", and
        "OPTIONAL" "<bcp14>OPTIONAL</bcp14>" in this document are to be
    interpreted as described in BCP
        14 BCP&nbsp;14 <xref target="RFC2119"/> <xref
    target="RFC8174"/> when, and only when, they appear in all capitals, as
    shown here.</t> here.
        </t>
      </section>
    </section>
    <section anchor="CARSAFI" title="BGP anchor="CARSAFI">
      <name>BGP CAR SAFI"> SAFI</name>
      <section anchor="SECDATAMODEL" title="Data Model"> anchor="SECDATAMODEL">
        <name>Data Model</name>
        <t>The BGP CAR data model is:
          <list style="symbols">
          <t>NLRI Key: Falls is:</t>
        <dl spacing="normal" newline="false">
          <dt>NLRI key:</dt><dd><t>Falls into two categories, categories to accommodate the use-cases use cases described
          in the introduction:
            <list style="symbols">
            <t>Type-1: Key introduction:</t>
            <dl spacing="normal" newline="false">
              <dt>Type-1:</dt><dd>Key is IP Prefix and Color (E, C). Color in
              NLRI key distinguishes a color-aware route for a common IP
              prefix, one per intent. Color also indicates the intent
              associated with the route.
            </t>
            <t>Type-2: Key route.</dd>
              <dt>Type-2:</dt><dd>Key is IP Prefix (E). The unique IP prefix
              assigned for an intent (i.e, IP Prefix == Intent intent or Color)
              distinguishes the color-aware route.  Color is not needed in
              NLRI key as a distinguisher.
            </t>
            </list>
          </t>
          <t>NLRI distinguisher.</dd>
	    </dl>
          </dd>
<!-- [rfced] Section 2.1: For consistency with the rest of the list items in
this section, what definition/content should appear for "BGP Next Hop"?

Original:
   *  BGP Next Hop.
-->
          <dt>NLRI non-key encapsulation data: Data data:</dt><dd>Data such as MPLS label
          stack, Label Index Index, and SRv6 SID list associated with NLRI. Contained
          in TLVs as described in <xref target="NLRITLVs"/></t>
          <t>BGP Next Hop.</t>
          <t>AIGP Metric target="NLRITLVs"/>.</dd>
          <dt>BGP next hop.</dt>
	  <dd></dd>
          <dt>AIGP metric <xref target="RFC7311"/>: accumulates color/intent specific target="RFC7311"/>:</dt><dd>Accumulates a metric value specific to color/intent
          for a CAR route across multiple BGP hops.</t>
          <t>Local-Color-Mapping hops.</dd>
          <dt>Local-Color-Mapping Extended-Community (LCM-EC): Optional (LCM-EC):</dt><dd><t>Optional non-zero 32-bit Color
          value used to represent the intent associated with a CAR route:

            <list style="symbols"> route:</t>
            <ul spacing="normal">
              <li>
                <t>when the CAR route propagates between different color domains.</t>
              </li>
              <li>
                <t>when the CAR route has a unique IP prefix for an intent.</t>
            </list>
          </t>
          <t>BGP
              </li>
            </ul>
          </dd>
          <dt>BGP Color Extended-Community (Color-EC) <xref target="RFC9012"/>: Optional
          target="RFC9012"/>:</dt><dd>Optional non-zero 32-bit Color value
          used to represent the intent associated with the BGP CAR next
          hop. It is used as per <xref target="RFC9256"/> for automated route
          resolution, when intent/color used for the next hop is different
          than the CAR route's intent/color. </t>
          </list>
        </t> </dd>
        </dl>
        <t>
          The sections below describe the data model in detail. The sections that
          describe the protocol processing for CAR SAFI generally apply consistently
          to both route types (for instance, any operation based on color). The
          examples use (E, C) for simplicity.
        </t>
      </section>

      <section title="Extensible Encoding">
      <section>
        <name>Extensible Encoding</name>
        <t>Extensible encoding is provided by:
          <list style="symbols">
          <t>NLRI by:</t>

        <dl spacing="normal" newline="false">
          <dt>NLRI Type field: field:</dt><dd><t>This provides extensibility to add new NLRI formats for new route-types.
          <list style="empty"> route types.</t>
          <t>NLRI (Route) Types (route) types other than Type-1 (E, C) and Type-2 (E) are
          outside the scope of this document. </t>
          </list>
          </t>

          <t>Key length field: document.</t></dd>
          <dt>Key Length field:</dt><dd>This specifies the key length. It allows new NLRI types to be handled
          opaquely, which permits transitivity of new route types through BGP speakers such as
          Route Reflectors.
          </t>

          <t>TLV-based Reflectors (RRs).</dd>
          <dt>TLV-based encoding of non-key part of NLRI: This NLRI:</dt><dd>This allows
          the inclusion of additional non-key fields for a prefix to support
          different types of transport simultaneously with efficient BGP
          update packing (<xref target="ColorFamily"/>).
          </t>

          <t>AIGP Attribute target="ColorFamily"/>).</dd>
          <dt>AIGP attribute:</dt><dd>This provides extensibility via TLVs, enabling definition of
          additional metric semantics for a color as needed for an intent.</t>
          </list>
        </t> intent.</dd>
        </dl>
      </section>

      <section title="BGP

      <section>
        <name>BGP CAR Route Origination"> Origination</name>
        <t>A BGP CAR route may be originated locally (e.g., loopback) or through
        redistribution of an (E, C) color-aware path provided by another routing
        solution: e.g.,
        solution (e.g., SR Policy, IGP Flex-Algo, RSVP-TE, BGP-LU <xref target="RFC8277"/>. target="RFC8277"/>).
        </t>
      </section>
      <section anchor="ROUTEVALIDN" title="BGP anchor="ROUTEVALIDN">
        <name>BGP CAR Route Validation"> Validation</name>
        <t>A BGP CAR path (E, C) via next hop N with encapsulation T is valid if color-aware
        path (N, C) exists with encapsulation T available in data-plane.</t>
        <t>A local policy may customize the validation process:
          <list style="symbols">
        </t>
        <ul spacing="normal">
          <li>
            <t>The color constraint in the first check may be relaxed. If N is
          reachable via alternate color(s) or in the default routing table, the route
          may be considered valid.</t>
          </li>
          <li>
            <t>The data-plane availability constraint of T may be relaxed to use an
 	      alternate encapsulation.</t>
          </li>
          <li>
            <t>A performance-measurement verification may be added to ensure that the
          intent associated with C is met (e.g. (e.g., delay &lt; bound).</t>
          </list>
        </t>
          </li>
        </ul>
        <t>A path that is not valid MUST NOT <bcp14>MUST NOT</bcp14> be considered for BGP best path selection.
        </t>
      </section>
      <section anchor="ROUTERES" title="BGP anchor="ROUTERES">
        <name>BGP CAR Route Resolution"> Resolution</name>
        <t>A BGP color-aware route (E2, C1) with next hop N is automatically
        resolved over a color-aware route (N, C1) by default. The color-aware
        route (N, C1) is provided by color aware color-aware mechanisms such as IGP
        Flex-Algo <xref target="RFC9350"/>, SR policy <xref target="RFC9256"/> Section 2.2, (<xref target="RFC9256"
        sectionFormat="of" section="2.2"/>), or recursively by BGP CAR.
        When multiple producers of (N, C1) are available, the default
        preference is: IGP Flex-Algo, SR Policy, BGP CAR.
        </t>
        <t>Local policy SHOULD <bcp14>SHOULD</bcp14> provide additional control:
          <list style="symbols"> control:</t>
        <ul spacing="normal">
          <li>
            <t>A BGP color-aware route (E2, C1) with next hop N may be
            resolved over a color-aware route (N, C2) (i.e., the local policy
            maps the resolution of C1 over a different color C2).</t>
            <ul spacing="normal">
              <li>

<!-- [rfced] Please clarify the last two points; we suggest making them
complete sentences and consistent with one another. More specifically,
what is the outcome of the "if" clause in the final list item below (the
item that begins with "Another example is:")?

Original:
   *  A BGP color-aware route (E2, C1) with next hop N may be resolved
      over a color-aware route (N, C2): i.e., the local policy maps the
      resolution of C1 over a different color C2.
            <list style="symbols">

      -  For example, in a domain where resource R is known to not be
         present, the inter-domain intent C1="low delay and avoid R" may
         be resolved over an intra-domain path of intent C2="low delay".

      -  Another example is: if no (N, C1) path is available and the user has
         allowed resolution to fallback to a C2 path.

Perhaps:
      -  For example, in a domain where resource R is known to not be
         present, the inter-domain intent C1="low delay and avoid R" may
         be resolved over an intra-domain path of intent C2="low delay".

      -  For another example, if no (N, C1) path is available, and the user has
         allowed resolution to fallback to a C2 path, then ... [what outcome occurs]?
-->

                <t>For example, in a domain where resource R is known to not
                be present, the inter-domain intent C1="low delay and avoid R"
                may be resolved over an intra-domain path of intent C2="low
                delay".</t>
              </li>

              <li>
                <t>Another example is: if no (N, C1) path is available and the
 	        user has allowed resolution to fallback to a C2 path.</t>
            </list>
          </t>
              </li>
            </ul>
          </li>
          <li>
            <t>
          Route resolution may be driven by an egress node. In an SRv6 domain, an egress node
          selects and advertises an SRv6 SID from its locator for intent C1, with a BGP CAR
          route. In such a case, the ingress node resolves the received SRv6 SID over an
          IPv6 route for the intent-aware locator of the egress node for C1 or a
          summary route that covers the locator. This summary route may be provided by SRv6
          Flex Algo or BGP CAR IP Prefix route itself (e.g., <xref target="SECSRv6LOCencap"/>).
            </t>
          </li>
          <li>
            <t>Local policy may map the CAR route to traditional mechanisms that are unaware of
          color or that provide best-effort, such as RSVP-TE, IGP/LDP, BGP LU/IP (e.g.,
          <xref target="COREDOMAINTE"/>) for brownfield scenarios.</t>
          </list>
        </t>
          </li>
        </ul>
        <t>Route resolution via a different color C2 can be automated by
        attaching BGP Color-EC C2 to CAR route (E2, C1), leveraging Automated automated
        steering as described in Section 8.4 <xref target="RFC9256"
        sectionFormat="bare" section="8.4"/> of Segment "Segment Routing Policy Architecture
        Architecture" <xref target="RFC9256"/> for BGP CAR routes. This
        mechanism is illustrated in <xref target="APPENDIXNM"/>. This
        mechanism SHOULD <bcp14>SHOULD</bcp14> be supported.</t>

<!-- [rfced] How may we clarify how the content in parentheses relates to
the rest of the sentence?

Original:
   For CAR route resolution, Color-EC color if present takes precedence
   over the route's intent color (LCM-EC if present (Section 2.9.5), or
   else NLRI color).

Perhaps:
   If present, Color-EC color takes precedence over the route's intent color
   (which, if present, is LCM-EC (see Section 2.9.5) or else NLRI color) for
   CAR route resolution.
-->

        <t>For CAR route resolution, Color-EC color if present takes precedence over
        the route's intent color (LCM-EC if present (<xref target="SECLCMEC"/>),
        or else NLRI color).</t>
        <t>Local policy takes precedence over the color based color-based automated resolution specified above.</t>
        <t>The color-aware route (N, C1) may be provided by BGP CAR itself in a
        hierarchical transport routing design. In such cases, based on the
        procedures described above, recursive resolution may occur over the same
        or different CAR route type.
        <xref target="SECNRSSID"/> describes a scenario where CAR (E, C) route
        resolves over CAR IP Prefix route.
        </t>
        <t>CAR IP Prefix route is allowed to be without color for best-effort. In this
        case, resolution is based on BGP next hop N, or when present, a best-effort
        SRv6 SID advertised by node N.</t>
        <t>A BGP CAR route may recursively resolve over a BGP route that
        carries a TEA and follows Section 6 of [RFC9012] <xref target="RFC9012" sectionFormat="of"
        section="6"/> for validation. In this case, the procedures of section 8 of [RFC9012] <xref
        target="RFC9012" sectionFormat="of" section="8"/> apply to BGP CAR
        routes, using color precedence as specified above for resolution.</t>
        <t>The procedures of [RFC9012] Section 6 <xref target="RFC9012" sectionFormat="comma"
        section="6"/>, also apply to BGP CAR routes (AFI/SAFI = 1/83 or
        2/83). For instance, a BGP CAR BR may advertise a BGP CAR route to an
        ingress BR or PE with a specific BGP next hop per color, with a TEA or
        Tunnel Encapsulation EC, as per Section 6 of [RFC9012].</t> <xref target="RFC9012" sectionFormat="of" section="6"/>.</t>
        <t> BGP CAR resolution in one network domain is independent of resolution in
        another domain.</t>
      </section>
      <section anchor="AIGPMETRIC" title="AIGP anchor="AIGPMETRIC">
        <name>AIGP Metric Computation"> Computation</name>
        <t>The Accumulated IGP (AIGP) Metric Attribute <xref target="RFC7311"/> is updated as
        the BGP CAR route propagates across the network.</t>

<!-- [rfced] What is the subject of "or appropriately incremented" in the text below?

Original:
   The value set (or appropriately incremented) in the AIGP TLV
   corresponds to the metric associated with the underlying intent of
   the color.

Perhaps:
   The value that is set (or appropriately incremented) in the AIGP TLV
   corresponds to the metric associated with the underlying intent of
   the color.
-->

        <t>The value set (or appropriately incremented) in the AIGP TLV corresponds
        to the metric associated with the underlying intent of the color. For example,
        when the color is associated with a low-latency path, the metric value is set
        based on the delay metric.</t>
        <t>Information regarding the metric type used by the underlying intra-domain
        mechanism can also be used to set the metric value.</t>
        <t>If BGP CAR routes traverse across a discontinuity in the transport path for
        a given intent, a penalty is added in accumulated IGP the AIGP metric (value set by user
        policy).  For This could occur, for instance, when color C1 path is not available, and route resolves via
        color C2 path (See (see <xref target="SHDFAUSECASE"/> for an example).</t>
        <t>AIGP metric computation is recursive.</t>
        <t>To avoid continuous IGP metric changes causing end to end end-to-end BGP CAR route churn, an
        implementation should provide thresholds to trigger AIGP update.</t> updates.</t>
        <t>Additional AIGP extensions may be defined to signal state for specific
        use-cases:
        use cases such as Maximum SID-Depth SID Depth (MSD) along the BGP CAR route advertisement, Minimum advertisement and minimum MTU along the BGP
        CAR route advertisement. This is out of scope for this document.</t>
      </section>
      <section anchor="SECPA" title="Native MultiPath Capability"> anchor="SECPA">
        <name>Native Multipath Capability</name>
        <t>The (E, C) route definition inherently provides availability of redundant paths at
        every BGP hop identical to BGP-LU or BGP IP. For instance, BGP CAR routes originated
        by two or more egress ABRs in a domain are advertised as multiple paths to ingress
        ABRs in the domain, where they become equal-cost or primary-backup paths.
        A failure of an egress ABR is detected and handled by ingress ABRs locally within
        the domain for faster convergence, without any necessity to propagate the event
        to upstream nodes for traffic restoration.</t>
        <t>BGP ADD-PATH <xref target="RFC7911"/> SHOULD <bcp14>SHOULD</bcp14> be enabled for BGP CAR to signal multiple
        next hops through a transport RR.</t>
      </section>

      <section anchor="SDIFFCOLORS" title="BGP anchor="SDIFFCOLORS">
        <name>BGP CAR Signaling through different Through Different Color Domains">
        <figure align="center"> Domains</name>
        <artwork align="left"><![CDATA[
          [Color Domain 1   A]-----[B     Color Domain 2     E2]
          [C1=low-delay      ]     [C2=low-delay               ]
       ]]></artwork>
        </figure>

        <t>Let us assume a BGP CAR route (E2, C2) is signaled from B to A, two border
        routers of respectively domain Domain 2 and domain 1. Domain 1, respectively. Let us assume that these two
        domains do not share the same color-to-intent mapping (i.e., they belong to different
        color domains). Low-delay in domain Domain 2 is color C2, while it is C1 in
        domain
        Domain 1 (C1 &lt;> &lt;&gt; C2).</t>
        <t>It is not expected to be a typical scenario to have an underlay
        transport path (e.g., an MPLS LSP) extend across different color
        domains. However, the BGP CAR solution seamlessly supports this rare
        scenario while maintaining the separation and independence of the
        administrative authority in different color domains.</t>
        <t>The solution works as described below:
          <list style="symbols"> below:</t>
        <ul spacing="normal">
          <li>
            <t>Within domain Domain 2, the BGP CAR route is (E2, C2) via E2.</t>
          </li>
          <li>
            <t>B signals to A the BGP CAR route as (E2, C2) via B with
            Local-Color-Mapping-Extended-Community (LCM-EC) of color C2.</t>
          </li>
          <li>
            <t>A is aware of the intent-to-color mapping
            within domain Domain 2 ("low-delay" in domain Domain 2 is C2), as per typical coordination that exists between operators of peering domains.</t>
          </li>
          <li>
            <t>A maps C2 in LCM-EC to C1 and signals within domain Domain 1 the received
            BGP CAR route as (E2, C2) via A with LCM-EC(C1).</t> LCM-EC (C1).</t>
          </li>
          <li>
            <t>The nodes within the receiving domain Domain 1 use the local color encoded
            in the LCM-EC for next-hop resolution and service steering.</t>
          </list>
        </t>
          </li>
        </ul>
        <t>
        The following procedures apply at a color domain boundary for BGP CAR routes,
        performed by route policy at the sending and receiving peer:
          <list style="symbols">
        </t>
        <ul spacing="normal">
          <li>
            <t>Use local policy to control which routes are advertised to or accepted from a
        peer in a different color domain.</t>
          </li>
          <li>
            <t>Attach LCM-EC if not present with the route. If LCM-EC is present, then update
        the value to re-map the color as needed.
          <list>
            </t>
            <ul spacing="normal">
              <li>
                <t>This function may be done by the advertising BGP speaker or the receiving BGP
        speaker as determined by the operator peering agreement, and indicated by local policy
        on the BGP peers.</t>
          </list>
          </t>
          </list>
        </t>
              </li>
            </ul>
          </li>
        </ul>
        <t>These procedures apply to both CAR route types, in addition to all procedures specified in earlier sections. LCM-EC is described in <xref target="SECLCMEC"/>.</t>
        <t>Salient properties:
          <list style="symbols">
        </t>
        <ul spacing="normal">
          <li>
            <t>The NLRI never changes, even though the color-to-intent mapping changes</t> changes.</t>
          </li>
          <li>
            <t>E is globally unique, which makes E-C in that order unique</t> unique.</t>
          </li>
          <li>
            <t>In typical expected cases, the color of the NLRI is used for
          resolution and steering</t> steering.</t>
          </li>
          <li>
            <t>In the rare case of color incongruence, the local color encoded in
          LCM-EC takes precedence</t>
          </list>
        </t> precedence.</t>
          </li>
        </ul>
        <t>Operational consideratons considerations are in <xref target="MANAGEOPER"/>. Further illustrations are provided in <xref target="ColorMapping"/>.</t>
      </section>
      <section anchor="ColorFamily" title="Format anchor="ColorFamily">
        <name>Format and Encoding"> Encoding</name>
        <t>BGP CAR leverages BGP multi-protocol extensions <xref target="RFC4760"/> and uses the MP_REACH_NLRI and MP_UNREACH_NLRI
        attributes for route updates within SAFI value 83 along with
        AFI 1 for IPv4 prefixes and AFI 2 for IPv6 prefixes.</t>
        <t>BGP speakers MUST <bcp14>MUST</bcp14> use the BGP Capabilities Advertisement to ensure
        support for processing of BGP CAR updates. This is done as
        specified in <xref target="RFC4760"/>, by using capability code 1
        (multi-protocol BGP), with AFI 1 and 2 (as required) and SAFI 83.</t>
        <t>
        The Next Hop network address field in the MP_REACH_NLRI may either be
        an IPv4 address or an IPv6 address, independent of AFI. If the
        next hop length is 4, then the next hop is an IPv4 address. The next hop
        length may be 16 or 32 for an IPv6 next hop address, set as per section 3
        of [RFC2545].
        <xref target="RFC2545" sectionFormat="of" section="3"/>. Processing of the Next Hop field is governed by
        standard BGP procedures as described in section 3 of [RFC4760]. <xref target="RFC4760" sectionFormat="of" section="3"/>.
        </t>
        <t>The sub-sections below specify the generic encoding of the BGP CAR NLRI and non-key TLV fields fields,
        followed by the encoding for specific NLRI types introduced in this
        document.</t>
        <section anchor="NLRI" title="BGP anchor="NLRI">
          <name>BGP CAR SAFI NLRI Format"> Format</name>
          <t>The generic format for the BGP CAR SAFI NLRI is shown
          below:</t>

          <t><figure align="center">
          <artwork align="left"><![CDATA[
 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  NLRI Length  |  Key Length   |   NLRI Type   |              //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+              //
|                  Type-specific                  Type-Specific Key Fields                    //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|           Type-specific           Type-Specific Non-Key TLV Fields (if applicable)   //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

where:
]]></artwork>
          </figure>
            <list style="symbols">
            <t>NLRI Length: 1 octet

<t>where:</t>
          <dl spacing="normal" newline="false">
            <dt>NLRI Length:</dt><dd>1-octet field that indicates the length in octets
            of the NLRI excluding the NLRI Length field itself.</t>

            <t>Key Length: 1 octet itself.</dd>
            <dt>Key Length:</dt><dd>1-octet field that indicates the length in octets
            of the NLRI type-specific key fields. Key length MUST <bcp14>MUST</bcp14> be at least
            2 less than the NLRI length.</t>

            <t>NLRI Type: 1 octet length.</dd>
            <dt>NLRI Type:</dt><dd>1-octet field that indicates the type of the BGP
            CAR NLRI.</t>

            <t>Type-Specific NLRI.</dd>
            <dt>Type-Specific Key Fields: The Fields:</dt><dd>The exact definition of these fields
            depends on the NLRI type. They have length indicated by the Key Length.</t>

            <t>Type-Specific Length.</dd>
            <dt>Type-Specific Non-Key TLV Fields: The Fields:</dt><dd>The fields are
            optional and can carry one or more non-key TLVs (of different
            types) depending on the NLRI type.  The NLRI definition allows for
            encoding of specific non-key information associated with the route
            as part of the NLRI for efficient packing of BGP updates.
            </t>
            </list>
          </t> updates.</dd>
          </dl>
          <t>The non-key TLVs portion of the NLRI MUST <bcp14>MUST</bcp14> be omitted while carrying it
          within the MP_UNREACH_NLRI when withdrawing the route advertisement.</t>
          <t>Error handling for CAR SAFI NLRI and non-key TLVs is described in
          <xref target="Fault"/>.</t>

          <t>Benefits
          <t>The benefits of CAR NLRI design:</t>

          <t>The design are:</t>
	  <ul spacing="normal">
            <li>The indication of the key length enables BGP Speakers speakers to
            determine the key portion of the NLRI and use it along with the
            NLRI Type field in an opaque manner for the handling of unknown or
            unsupported NLRI types.  This can help deployed Route Reflectors
            (RR) to propagate NLRI types introduced in the future in a
            transparent manner.</t>

          <t>The manner.</li>
            <li>The key length also helps error handling be more resilient and
            minimally disruptive. The use of key length in error handling is
            described in <xref target="Fault"/>.</t>

          <t>The target="Fault"/>.</li>
            <li><t>The ability of a route (NLRI) to carry more than one non-key
            TLV (of different types) provides significant benefits such as
            signaling multiple encapsulations simultaneously for the same
            route, each with a different value
          (label/SID etc). (label/SID, etc.).  This enables simpler,
            simpler and efficient migrations with low overhead :
              <list style="symbols"> overhead:</t>
            <ul spacing="normal">
              <li>
		<t>avoids the need for duplicate routes to signal different encapsulations</t>
              </li>
              <li>
		<t>avoids the need for separate control planes for distribution</t>
              </li>
              <li>
		<t>preserves update packing (e.g. (e.g., <xref target="UPDATEPACKING"/>)</t>
              </list>
          </t>
              </li>
            </ul>
	    </li>
	  </ul>
        </section>
        <section anchor="NLRITLVs" title="Type-Specific anchor="NLRITLVs">
          <name>Type-Specific Non-Key TLV Format"> Format</name>
          <t>The generic format for Non-Key TLVs is shown below:</t>
         <t><figure align="center">
          <artwork align="left"><![CDATA[
 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     Type      |    Length     |    Value (variable)          //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

where:]]></artwork>
            </figure>
            <list style="symbols">
              <t>Type: 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>

<t>where:</t>
          <dl spacing="normal" newline="false">
            <dt>Type:</dt><dd><t>1 octet that contains the type code and
            flags. It is encoded as shown below:

             <figure align="center"> below:</t>
              <artwork align="left"><![CDATA[
 0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|R|T| Type code |
+-+-+-+-+-+-+-+-+
 where:]]></artwork>
             </figure>
               <list style="symbols">
               <t>R: Bit
]]></artwork>
<t>where:</t>
              <dl spacing="normal" newline="false">
                <dt>R:</dt><dd>Bit is reserved and MUST <bcp14>MUST</bcp14> be set
                to 0 and ignored on receive.</t>
               <t>T: Transitive receive.</dd>
                <dt>T:</dt><dd><t>Transitive bit, applicable to speakers that
                change the BGP CAR next hop.
                 <list>
                 <t>T hop.</t>
                  <ul spacing="normal">
                    <li><t>The T bit is set to indicate TLV is transitive. An
                    unrecognized transitive TLV MUST <bcp14>MUST</bcp14> be
                    propagated by a speaker that changes the next hop.</t>
                 <t>T
                    </li>
                    <li><t>The T bit is unset to indicate TLV is non-transitive.  An
                    unrecognized non-transitive TLV MUST NOT <bcp14>MUST NOT</bcp14> be
                    propagated by a speaker that changes the next hop.</t>
                 </list>
                 A
                    </li>
                  </ul>
                  <t>A speaker that does not change the next hop SHOULD
                  <bcp14>SHOULD</bcp14> propagate all received TLVs.</t>
               <t>Type code: Remaining
                </dd>
                <dt>Type code:</dt><dd>Remaining 6 bits contain the type of the TLV.</t>
               </list>
              </t>

              <t>Length: 1 octet TLV.</dd>
              </dl>
	    </dd>
            <dt>Length:</dt><dd>1-octet field that contains the length of the
            value portion of the non-key TLV in terms of octets.</t>

              <t>Value: variable length octets.</dd>
            <dt>Value:</dt><dd>Variable-length field as indicated by the length
            Length field and to be interpreted as per the type field.</t>
            </list>
          </t> Type field.</dd>
          </dl>
          <t> The following sub-sections specify non-key TLVs. Each NLRI type MUST <bcp14>MUST</bcp14>
          list the TLVs that can be associated with it.</t>
          <section anchor="CARMPLS" title="Label TLV"> anchor="CARMPLS">
            <name>Label TLV</name>
            <t>The Label TLV is used for the advertisement of CAR routes
            along with their MPLS labels and labels. It has the following format as per
            <xref target="NLRITLVs"/>:</t>

            <t><figure align="center">
            <artwork align="left"><![CDATA[
 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|R|T|  Type     |    Length     |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Followed

It is followed by one (or more) Labels encoded as below:

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                 Label                 |Rsrv |S|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

where:        ]]></artwork>
              </figure>
              <list style="symbols">
              <t>Type : Type
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>

<t>where:</t>
            <dl spacing="normal" newline="false">
              <dt>Type:</dt><dd>Type code is 1. The T bit MUST <bcp14>MUST</bcp14> be unset.</t>

              <t>Length: In octets. Length unset.</dd>
              <dt>Length:</dt><dd>Length is in octets, variable, MUST and
              <bcp14>MUST</bcp14> be a multiple of 3.</t>

              <t>Label Information: multiples 3.</dd>
              <dt>Label Information:</dt><dd>Multiples of 3 octet 3-octet fields to
              convey the MPLS label(s) associated with the advertised CAR
              route.  It is used for encoding a single label or a stack of
              labels for usage as described in <xref
              target="RFC8277"/>. Number The number of labels is derived from length the Length
              field. The 3-bit Rsrv field and the 1-bit S field SHOULD <bcp14>SHOULD</bcp14> be set
              to zero on transmission and MUST <bcp14>MUST</bcp14> be ignored on reception.
              </t>
              </list>
            </t>
              reception.</dd>
            </dl>
            <t>If a BGP transport CAR speaker sets itself as the next hop while
            propagating a CAR route, it allocates a local label for
            the type specific type-specific key, and updates the value in this
            TLV. It also MUST <bcp14>MUST</bcp14> program a label cross-connect that would result in
            the label swap operation for the incoming label that it advertises
            with the label received from its best-path router(s).</t>
          </section>
          <section anchor="CARMPLSSID" title="Label anchor="CARMPLSSID">
            <name>Label Index TLV"> TLV</name>
            <t>The Label Index TLV is used for the advertisement of Segment
            Routing over MPLS (SR-MPLS) Segment Identifier (SID) <xref
            target="RFC8402"/> information associated with the labeled CAR routes and
            routes. It has the following format as per <xref
            target="NLRITLVs"/>:</t>

            <t><figure align="center">
            <artwork align="left"><![CDATA[
 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|R|T|   Type    |    Length     |    Reserved   |     Flags     ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~               |                 Label Index                   ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~               |
+-+-+-+-+-+-+-+-+

where:       ]]></artwork>
              </figure>
              <list style="symbols">
              <t>Type : Type
+-+-+-+-+-+-+-+-+]]></artwork>

<t>where:</t>
            <dl spacing="normal" newline="false">
              <dt>Type:</dt><dd>Type code is 2. The T bit MUST <bcp14>MUST</bcp14> be set.</t>

              <t>Length: In octets. Length set.</dd>
              <dt>Length:</dt><dd>Length is 7.</t>

              <t>Reserved: 1 octet in octets and is 7.</dd>
              <dt>Reserved:</dt><dd>1-octet field that MUST <bcp14>MUST</bcp14> be
              set to 0 and ignored on
              receipt.</t>

              <t>Flags: 2 octet receipt.</dd>

              <dt>Flags:</dt><dd>2-octet field that's defined as per the Flags
              field of the Label Index TLV of the BGP Prefix-SID Attribute attribute
              (<xref
              target="RFC8669"/> section 3.1).</t>

              <t>Label Index: 4 octet target="RFC8669" sectionFormat="of" section="3.1"/>).</dd>
              <dt>Label Index:</dt><dd>4-octet field that's defined as per the
              Label Index field of the Label Index TLV of the BGP Prefix-SID Attribute
              attribute (<xref
              target="RFC8669"/> section 3.1).</t>
              </list>
            </t> target="RFC8669" sectionFormat="of" section="3.1"/>).</dd>
            </dl>
            <t>This TLV provides the equivalent functionality as the Label Index TLV
            of <xref target="RFC8669"/> for Transport CAR route in SR-MPLS
            deployments.
            When a speaker allocates a local label for a received CAR route as per
            <xref target="CARMPLS"/>, it SHOULD <bcp14>SHOULD</bcp14> use the received Label Index as a hint
            using procedures as specified in [RFC8669] Section 4. <xref target="RFC8669" sectionFormat="comma" section="4"/>.
            </t>
            <t>The Label Index TLV provides much better packing efficiency by carrying the
            Label Index in NLRI instead of in the BGP Prefix-SID Attribute attribute
            (<xref target="UPDATEPACKING"/>). </t>

            <t>Label
            <t>The Label Index TLV MUST NOT <bcp14>MUST NOT</bcp14> be carried in the Prefix-SID attribute for
            BGP CAR routes. If a speaker receives a CAR route with the Label Index TLV in
            the Prefix-SID attribute, it SHOULD <bcp14>SHOULD</bcp14> ignore it. The BGP Prefix-SID Attribute
            SHOULD NOT attribute
            <bcp14>SHOULD NOT</bcp14> be sent with the labeled CAR routes if the attribute is
            being used only to convey the Label Index TLV.</t>
          </section>
          <section anchor="CRSRv6" title="SRv6 anchor="CRSRv6">
            <name>SRv6 SID TLV"> TLV</name>
            <t>BGP Transport CAR can be also used to setup set up end-to-end
            color-aware connectivity using Segment Routing over IPv6 (SRv6)
            <xref target="RFC8402"/>. <xref target="RFC8986"/> specifies the
            SRv6 Endpoint behaviors (e.g. (e.g., End PSP) Penultimate Segment Pop (PSP)), which can be leveraged for
            BGP CAR with SRv6. The SRv6 SID TLV is used for the advertisement of
            CAR routes along with their SRv6 SIDs and SIDs. It has the following format
            as per <xref target="NLRITLVs"/>:</t>

            <t><figure align="center">
            <artwork align="left"><![CDATA[
 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|R|T|  Type     |    Length     |   SRv6 SID Info (variable)   //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

where:
]]></artwork>
              </figure>
              <list style="symbols">
              <t>Type : Type

<t>where:</t>
            <dl spacing="normal" newline="false">
              <dt>Type:</dt><dd>Type code is 3. The T bit MUST <bcp14>MUST</bcp14> be unset.</t>

              <t>Length: In octets. Length unset.</dd>
              <dt>Length:</dt><dd>Length is in octets, variable, MUST and
              <bcp14>MUST</bcp14> be either less than or equal to 16, or be a
              multiple of 16.</t>

              <t>SRv6 16.</dd>
              <dt>SRv6 SID Information: field Information:</dt><dd><t>Field of size as indicated by the
              length that either carries the SRv6 SID(s) for the advertised
              CAR route as one of the following:
                <list style="symbols">
                <t>A following:</t>
                <ul spacing="normal">
                  <li><t>A single 128-bit SRv6 SID or an ordered list of
                  128-bit SRv6
                SIDs.</t>

                <t>A SIDs.</t></li>
                  <li><t>A transposed portion (refer to <xref
                  target="RFC9252"/>) of the SRv6 SID that
                MUST <bcp14>MUST</bcp14>
                  be of size in multiples of one octet and less than 16.</t>
                </list>
              </t>
              </list>
            </t>

            <t>
                  </li>
                </ul>
              </dd>
            </dl>

<!-- [rfced] FYI - We adjusted these list items to make them parallel
and consistent. Please review and let us know any further updates.

Original:
   BGP CAR SRv6 SID TLV definitions provide the following benefits:
              <list style="symbols">
              <t>Native

   *  Native encoding of SIDs avoids robustness issue caused by
      overloading of MPLS label fields.</t>
              <t>Simple fields.

   *  Simple encoding to signal Unique SIDs (non-transposition),
      maintaining BGP update prefix packing.</t>
              <t>Highly packing.

   *  Highly efficient transposition scheme (12-14 bytes saved per
      NLRI), also maintaining BGP update prefix packing.</t>
              </list> packing.

Current:
   BGP CAR SRv6 SID TLV definitions provide the following benefits:

   *  The native encoding of SIDs avoids robustness issues caused by the
      overloading of MPLS label fields.

   *  The simple encoding to signal Unique SIDs (non-transposition)
      maintains BGP update prefix packing.

   *  The highly efficient transposition scheme (12-14 bytes saved per
      NLRI) also maintains BGP update prefix packing.
-->

            <t>
            BGP CAR SRv6 SID TLV definitions provide the following benefits:
            </t>
            <ul spacing="normal">
              <li>The native encoding of SIDs avoids robustness issues caused by the
      overloading of MPLS label fields.</li>
              <li>The simple encoding to signal Unique SIDs (non-transposition)
      maintains BGP update prefix packing.</li>
              <li>The highly efficient transposition scheme (12-14 bytes saved per
      NLRI) also maintains BGP update prefix packing.</li>
            </ul>
            <t>The BGP CAR route update for SRv6 encapsulation MUST <bcp14>MUST</bcp14>
            include the BGP Prefix-SID attribute along with the SRv6 L3 Service TLV
            carrying the SRv6 SID information as specified in <xref target="RFC9252"/>.
            When using the transposition scheme of encoding for packing efficiency
            of BGP updates <xref target="RFC9252"/>, the transposed part of the SID is carried
            in the SRv6 SID TLV and is not limited by MPLS label field size.
            </t>
            <t>If a BGP transport CAR speaker sets itself as the next hop while
            propagating a CAR route and allocates an SRv6 SID that maps to the received
            SRv6 SID, it updates the value in this TLV.</t>
            <t>Received MPLS information can map to SRv6 and vice versa.
             <xref target="I-D.ietf-spring-srv6-mpls-interworking"/> describes MPLS
            and SRv6 interworking procedures and an extension to BGP CAR routes.</t>
          </section>
        </section>
        <section anchor="NLRITYPE1" title="Color-Aware anchor="NLRITYPE1">
          <name>Color-Aware Route (E, C) NLRI Type"> Type</name>
          <t>The Color-Aware Route NLRI Type is used for the advertisement of
          BGP CAR color-aware routes (E, C) and C). It has the following format:</t>

          <t><figure align="center">
          <artwork align="left"><![CDATA[
 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  NLRI Length  |  Key Length   |   NLRI Type   |Prefix Length  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|               IP Prefix (variable)                           //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|               Color (4 octets)                                |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

]]></artwork>
</figure>

<t>Followed
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>
          <t>It is followed by optional Non-Key TLVs encoded as per <xref target="NLRITLVs"/></t>
<t>where:</t>
            <list style="symbols">
            <t>NLRI Length: variable</t>

            <t>Key Length: variable. target="NLRITLVs"/>.</t>
          <t>Where:</t>
          <dl spacing="normal" newline="false">
            <dt>NLRI Length:</dt><dd>Variable.</dd>
            <dt>Key Length:</dt><dd>Variable. It indicates the total length comprised of
            the Prefix Length field, IP Prefix field, and the Color field, as
            described below.  For IPv4 (AFI=1), the minimum length is 5 and the
            maximum length is 9.  For IPv6 (AFI=2), the minimum length is 5
            and the maximum length is 21.</t>

            <t>NLRI Type: 1</t>
            <t>Type-Specific 21.</dd>
            <dt>NLRI Type:</dt><dd>1.</dd>
            <dt>Type-Specific Key Fields: Fields:</dt><dd><t>These are as below
              <list style="symbols">

              <t>Prefix Length: 1 octet seen below:</t>
              <dl spacing="normal" newline="false">
                <dt>Prefix Length:</dt><dd>1-octet field that carries the
                length of prefix in bits. Length MUST <bcp14>MUST</bcp14> be less
                than or equal to 32 for IPv4 (AFI=1) and less than or equal to
                128 for IPv6
              (AFI=2).</t>

              <t>IP Prefix: IPv4 (AFI=2).</dd>
                <dt>IP Prefix:</dt><dd><t>IPv4 or IPv6 prefix (based on the
                AFI). A
              variable size variable-size field that contains the most significant
                octets of the prefix. The format of this field for an IPv4
                prefix is:
              <list style="empty">
              <t>0 is:</t>
                  <ul spacing="normal">
                    <li>0 octet for prefix length 0,</t>
              <t>1 0</li>
                    <li>1 octet for prefix length 1 to 8,</t>
              <t>2 8</li>
                    <li>2 octets for prefix length 9 to 16,</t>
              <t>3 16</li>
                    <li>3 octets for prefix length 17 up to 24,</t>
              <t>4 24</li>
                    <li>4 octets for prefix length 25 up to 32.</t>
              </list>
	      </t> 32</li>
                  </ul>
                <t>The format for this field for an IPv6 address follows the
                same pattern for prefix lengths of 1-128 (octets 1-16).</t>
                <t>The last octet has enough trailing bits to make the end of
                the field fall on an octet boundary. Note that the value of
                the trailing bits MUST <bcp14>MUST</bcp14> be set to zero. The size
                of the field MUST <bcp14>MUST</bcp14> be less than or equal to 4
                for IPv4 (AFI=1) and less than or equal to 16 for IPv6
                (AFI=2).</t>

              <t>Color: 4
	      </dd>
              <dt>Color:</dt><dd>4 octets that contains contain non-zero color value
              associated with the prefix. </t>
              </list>
            </t>

            <t>Type-Specific prefix.</dd>
              </dl>
            </dd>
            <dt>Type-Specific Non-Key TLVs: TLVs:</dt><dd>The Label TLV, Label Index TLV TLV,
            and SRv6 SID TLV (<xref target="NLRITLVs"/>) may be associated
            with the Color-aware route NLRI type.</t>
            </list>
            </t> type.</dd>
          </dl>
          <t>The prefix is unique across the administrative domains where BGP
          transport CAR is deployed. It is possible that the same prefix is
          originated by multiple BGP CAR speakers in the case of
          anycast addressing or multi-homing.</t> multihoming.</t>
          <t>The Color is introduced to enable multiple route advertisements
          for the same prefix. The color is associated with an intent
          (e.g.
          (e.g., low-latency) in originator color-domain.</t> color domain.</t>
        </section>
        <section anchor="NLRITYPE2" title="IP anchor="NLRITYPE2">
          <name>IP Prefix (E) NLRI Type"> Type</name>
          <t>The IP Prefix Route NLRI Type is used for the advertisement of
          BGP CAR IP Prefix routes (E) and (E). It has the following format:</t>
        <t><figure align="center">
          <artwork align="left"><![CDATA[
 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  NLRI Length  |  Key Length   |   NLRI Type   |Prefix Length  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|               IP Prefix (variable)                           //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>

<t>Followed
          <t>It is followed by optional Non-Key TLVs encoded as per <xref target="NLRITLVs"/></t>
<t>where:</t>
            <list style="symbols">
            <t>NLRI Length: variable</t>

            <t>Key Length: variable. target="NLRITLVs"/>.</t>
          <t>Where:</t>
          <dl spacing="normal" newline="false">
            <dt>NLRI Length:</dt><dd>Variable.</dd>
            <dt>Key Length:</dt><dd>Variable. It indicates the total length comprised of
            the Prefix Length field and IP Prefix field as described below.
            For IPv4 (AFI=1), the minimum length is 1 and the
            maximum length is 5.  For IPv6 (AFI=2), the minimum length is 1
            and the maximum length is 17.</t>

            <t>NLRI Type: 2.</t>
            <t>Type-Specific 17.</dd>
            <dt>NLRI Type:</dt><dd>2.</dd>
            <dt>Type-Specific Key Fields: Fields:</dt><dd><t>These are as below
              <list style="symbols">

              <t>Prefix Length: 1 octet seen below:</t>
              <dl spacing="normal" newline="false">
                <dt>Prefix Length:</dt><dd>1-octet field that carries the
                length of prefix in bits. Length MUST <bcp14>MUST</bcp14> be less
                than or equal to 32 for IPv4 (AFI=1) and less than or equal to
                128 for IPv6
              (AFI=2).</t>

              <t>IP Prefix: IPv4 (AFI=2).</dd>
                <dt>IP Prefix:</dt><dd><t>IPv4 or IPv6 prefix (based on the
                AFI). A
              variable size variable-size field that contains the most significant
                octets of the prefix. The format of this field for an IPv4
                prefix is:
              <list style="empty">
              <t>0 is:</t>
                  <ul spacing="normal">
                    <li>0 octet for prefix length 0,</t>
              <t>1 0</li>
                    <li>1 octet for prefix length 1 to 8,</t>
              <t>2 8</li>
                    <li>2 octets for prefix length 9 to 16,</t>
              <t>3 16</li>
                    <li>3 octets for prefix length 17 up to 24,</t>
              <t>4 24</li>
                    <li>4 octets for prefix length 25 up to 32.</t>
              </list>
              </t> 32</li>
                  </ul>
               <t>The format for this field for an IPv6 address follows the
               same pattern for prefix lengths of 1-128 (octets 1-16).</t>
               <t>The last octet has enough trailing bits to make the end of
               the field fall on an octet boundary. Note that the value of the
               trailing bits MUST <bcp14>MUST</bcp14> be set to zero. The size of
               the field MUST <bcp14>MUST</bcp14> be less than or equal to 4 for
               IPv4 (AFI=1) and less than or equal to 16 for IPv6 (AFI=2).</t>
              </list>
            </t>
            <t>Type-Specific
             </dd>
	      </dl>
	    </dd>
             <dt>Type-Specific Non-Key TLVs: TLVs:</dt><dd>The Label TLV, Label Index TLV
             TLV, and SRv6 SID TLV (<xref target="NLRITLVs"/>) may be
             associated with the IP Prefix NLRI type.</t>
            </list>
          </t> type.</dd>
          </dl>
        </section>
        <section anchor="SECLCMEC" title="Local-Color-Mapping anchor="SECLCMEC">
          <name>Local-Color-Mapping (LCM) Extended-Community"> Extended-Community</name>
          <t>This document defines a new BGP Extended-Community called "LCM".
          The LCM is a Transitive Opaque Extended-Community with the following encoding:</t>

          <t><figure align="center">
          <artwork align="left"><![CDATA[
 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     Type=0x3  | Sub-Type=0x1b |          Reserved             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                             Color                             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

where:
]]></artwork>
            </figure>
            <list style="symbols">

            <t>Type: 0x3.</t>

            <t>Sub-Type: 0x1b.</t>

            <t>Reserved: 2 octet of

<t>where:</t>
          <dl spacing="normal" newline="false">
            <dt>Type:</dt><dd>0x3.</dd>
            <dt>Sub-Type:</dt><dd>0x1b.</dd>
            <dt>Reserved:</dt><dd>2-octet reserved field that MUST
            <bcp14>MUST</bcp14> be set to zero on transmission and ignored on reception.</t>

            <t>Color: 4-octet
            reception.</dd>
            <dt>Color:</dt><dd>4-octet field that carries the non-zero 32-bit color value.</t>
            </list> value.</dd>
          </dl>
          <t>
          When a CAR route crosses the originator's color domain boundary, LCM-EC
          is added or updated, as specified in <xref target="SDIFFCOLORS"/>. LCM-EC
          conveys the local color mapping for the intent
          (e.g.
          (e.g., low latency) in other (transit or destination) color domains.
          </t>
          <t>For CAR IP Prefix routes, LCM-EC may also be added in the originator color domain to
          indicate the color associated with the IP prefix.</t>
          <t>An implementation SHOULD NOT <bcp14>SHOULD NOT</bcp14> send more than one instance of the LCM-EC.
 	      However, if more than one instance is received, an implementation MUST <bcp14>MUST</bcp14>
 	      disregard all instances other than the one with the numerically highest
 	      value.</t>
          <t>If a node receives multiple BGP CAR routes (paths) for a given destination endpoint and color that have
               different LCM values, it is a misconfiguration in color re-mapping for one of the routes.</t>
          <t>In this case, the LCM from the selected BGP best path SHOULD <bcp14>SHOULD</bcp14> be chosen to be installed into the routing
              table.</t>
          <t>A warning message SHOULD <bcp14>SHOULD</bcp14> also be logged for further operator intervention.</t>
          <t>If present, LCM-EC contains the intent of a BGP CAR route.
 	      LCM-EC Color is used instead of the Color in CAR route NLRI for procedures
 	      described in earlier sections such as route validation (<xref target="ROUTEVALIDN"/>),
              route resolution (<xref target="ROUTERES"/>),
 	      AIGP calculation (<xref target="AIGPMETRIC"/>) and steering (<xref target="STEERING"/>).</t>
          <t>The LCM-EC MAY <bcp14>MAY</bcp14> be used for filtering of BGP CAR routes and/or for
          applying routing policies on the intent, when present.</t>
        </section>
      </section>
      <section anchor="LCMBGPECUSAGE"
      title="LCM-EC anchor="LCMBGPECUSAGE">
        <name>LCM-EC and BGP Color-EC usage"> Usage</name>
        <t>There are 2 distinct requirements to be supported as stated in
        <xref target="I-D.hr-spring-intentaware-routing-using-color"/>:
          <list style="numbers">
        </t>
        <ol spacing="normal" type="1"><li>
            <t>Domains with different intent granularity (section 6.3.1.9)</t> (<xref
            target="I-D.hr-spring-intentaware-routing-using-color"
            sectionFormat="of" section="6.3.1.9"/>)</t>
          </li>
          <li>
            <t>Network domains under different administration, i.e., administration (i.e., color domains
          (section 6.3.1.10)</t>
          </list>
        </t>
            domains; see <xref
            target="I-D.hr-spring-intentaware-routing-using-color"
            sectionFormat="of" section="6.3.1.10"/>)</t>
          </li>
        </ol>
        <t>Requirement 1 is the case where within the same administrative or
        color domain, BGP CAR routes for N end-to-end intents may need to traverse
        across an intermediate transit domain where only M intents are available, N >= &gt;= M.
        For example, consider a multi-domain network is designed as Access-Core-Access.
        The core may have the most granular N intents, whereas the access only has fewer M
        intents. So, Therefore, the BGP next-hop resolution for a CAR route in the access domain must be
        via a color-aware path for one of these M intents. As the procedures in <xref target="ROUTERES"/> describe,
        and the example in <xref target="APPENDIXNM"/> illustrates,
        BGP Color-EC is used to automate the CAR route resolution in this case.</t>
        <t>For requirement 2, where CAR routes traverse across different color domains,
        LCM-EC is used to carry the local color mapping for the NLRI color in other color
        domains. The related procedures are described in <xref target="SDIFFCOLORS"/>, and
        an example is given in <xref target="APPENDIXMCD"/>.</t>
        <t>Both LCM-EC and BGP Color-EC may be present at the same time with a BGP CAR route.
        For example, a BGP CAR route (E, C1) from color domain D1, with LCM-EC C2 in color
        domain D2, may also carry Color-EC C3 and next hop N in a transit network domain
        within D2 where C2 is being resolved via an available intra-domain intent C3 (See (see
        the detailed example in the combination of Appendices <xref target="APPENDIXNM"/> target="APPENDIXNM" format="counter"/> and
        <xref target="APPENDIXMCD"/>). target="APPENDIXMCD" format="counter"/>).
        </t>
        <t>In this case, as described in <xref target="ROUTERES"/>, the default order of
        processing for resolution in the presence of LCM-EC is local policy, then BGP Color-EC
        color, and finally LCM-EC color.</t>
      </section>
      <section anchor="Fault" title="Error Handling"> anchor="Fault">
        <name>Error Handling</name>

        <t>The error handling actions as described in <xref target="RFC7606"/> are applicable for the handling of BGP update messages
        for BGP CAR SAFI. In general, as indicated in <xref target="RFC7606"/>,
        the goal is to minimize the disruption of a session reset or
        'AFI/SAFI disable' to the extent possible.</t>
        <t>When the error determined allows for the router to skip the malformed
        NLRI(s) and continue processing of the rest of the update message, then
        it MUST <bcp14>MUST</bcp14> handle such malformed NLRIs as 'Treat-as-withdraw'. 'treat-as-withdraw'.
        In other cases, where the error in the NLRI encoding results in the inability to
        process the BGP update message, then the router SHOULD <bcp14>SHOULD</bcp14> handle such malformed
        NLRIs as 'AFI/SAFI disable' when other AFI/SAFI besides BGP CAR are being
        advertised over the same session. Alternately, the router MUST <bcp14>MUST</bcp14> perform
        'session reset' when the session is only being used for BGP CAR SAFI.</t>
        <t>The CAR NLRI definition encodes NLRI length and key length explicitly.
        The NLRI length MUST <bcp14>MUST</bcp14> be relied upon to enable the beginning of the next
        NLRI field to be located. Key length MUST <bcp14>MUST</bcp14> be relied upon to extract the
        key and perform 'treat-as-withdraw' for malformed information.</t>
        <t>A sender MUST <bcp14>MUST</bcp14> ensure that the NLRI and key lengths are the number of actual
	bytes encoded in the NLRI and key fields fields, respectively, regardless of
	content being encoded.</t>

	<t>Given

<!-- [rfced] May we update the list below as follows for consistency?
Is it intentional that the first "must" is lowercase, or should it be the
all-caps requirement keyword "MUST" (which is used in the other bullet point)?

Original:
   Given NLRI length and Key length MUST be valid, failures in following
   checks result in 'AFI/SAFI disable' or 'session reset':
	<list style="symbols">
	<t>Minimum

   *  Minimum NLRI length (must be atleast 2, as key length and NLRI
      type are required fields).

   *  Key Length MUST be at least two less than NLRI Length.

Perhaps:
   Given the NLRI length and Key length MUST be valid, failures in the following
   checks result in 'AFI/SAFI disable' or 'session reset':

   *  The minimum NLRI length MUST be at least 2, as key length and NLRI
      type are required fields.

   *  The Key Length MUST be at least 2 less than NLRI Length.
-->

        <t>Given NLRI length and Key length <bcp14>MUST</bcp14> be valid, failures in the following
	checks result in 'AFI/SAFI disable' or 'session reset':
        </t>
        <ul spacing="normal">
          <li>
            <t>Minimum NLRI length (must be at least 2, as key length and NLRI
            type are required fields).</t>
          </li>
          <li>
            <t>Key Length MUST <bcp14>MUST</bcp14> be at least two less than NLRI Length.</t>
	</list>
	</t>
          </li>
        </ul>

        <t>NLRI Type specific type-specific error handling:
	<list style="symbols">
        </t>
        <ul spacing="normal">
          <li>
            <t>By default, a speaker SHOULD <bcp14>SHOULD</bcp14> discard an
            unrecognized or unsupported NLRI type and move to the next
            NLRI.</t>
          </li>
          <li>
            <t>Key length and key errors of a known NLRI type SHOULD
            <bcp14>SHOULD</bcp14> result in the discard of NLRI similar to an
            unrecognized NLRI type. (This MUST <bcp14>MUST</bcp14> be logged for
            trouble shooting).</t>
	</list>
	</t> shooting.)</t>
          </li>
        </ul>
        <t>Transparent propagation of unrecognized NLRI type:
	<list style="symbols"> type:</t>
        <ul spacing="normal">
          <li>
            <t>Key length allows unrecognized route types to transit through the RR
	transparently without a software upgrade. The RR receiving unrecognized route
        types does not need to interpret the key portion of an NLRI and handles the NLRI
        as an opaque value of a specific length. An implementation SHOULD <bcp14>SHOULD</bcp14> provide configuration
        that controls the RR unrecognized route type propagation behavior and behavior, possibly at
        the granularity of route type values allowed. This configuration option gives the
        operator the ability to allow specific route types to be transparently passed through
        RRs based on client speaker support.</t>
          </li>
          <li>
            <t>In such a case RR case, the RRs may reflect NLRIs with NLRI type specific type-specific key length and
	field errors. Clients of such an RR that consume the route for installation
	will perform the key error handling of known NLRI type or discard the
	unrecognized type. This prevents propagation of routes with NLRI errors any
	further in network.</t>
	</list>
	</t>

	<t>Type-Specific
          </li>
        </ul>
        <t>Type-specific Non-Key TLV handling:
	<list style="symbols"> handling:</t>
        <ul spacing="normal">
          <li>
            <t>Either the length of a TLV would cause the NLRI length to be exceeded when
	parsing the TLV, or fewer than 2 bytes remain when beginning to parse the TLV.
	In either of these cases, an error condition exists exists, and the 'treat-as-withdraw'
	approach MUST <bcp14>MUST</bcp14> be used.</t>

        <t>Type specific
          </li>
          <li>
            <t>Type-specific length constraints should be verified. The TLV MUST <bcp14>MUST</bcp14> be
	discarded if there is an error. When discarded, an error may be logged for further
        analysis.</t>
          </li>
          <li>
            <t>If multiple instances of same type are encountered, all but the first
	instance MUST <bcp14>MUST</bcp14> be discarded. When discarded, an error may be logged for further analysis.</t>
          </li>
          <li>
            <t>If a speaker that performs encapsulation to the BGP next hop
            does not receive at least one recognized forwarding information
            TLV with the T bit unset (such as label or SRv6 SID), such NLRI is
            considered invalid and not eligible for best path
            selection. Treat-as-withdraw 'Treat-as-withdraw' may be used, though it is recommended
            to keep the NLRI for debugging purposes.</t>

	</list>
	</t>
          </li>
        </ul>
      </section>
    </section>
    <section anchor="STEERING" title="Service anchor="STEERING">
      <name>Service Route Automated Steering on Color-Aware Path"> Paths</name>
      <t>An ingress PE (or ASBR) E1 automatically steers a C-colored service route
      V/v from E2 onto an (E2, C) color-aware path, as illustrated in
      (<xref target="SECCARIllus"/>).
      <xref target="SECCARIllus"/>. If several such paths exist, a preference scheme is used
      to select the best path. The default preference scheme is IGP Flex-Algo first, then
      SR Policy, followed by BGP CAR. A configuration option may be used to adjust the
      default preference scheme.</t>
      <t>An egress PE may express its intent that traffic should be steered a certain way through the transport layer
      by including the BGP Color-EC [RFC9012] <xref target="RFC9012"/> with the relevant service routes. An ingress PE
      steers service traffic over a CAR (E, C) route using the service route's next
      hop and BGP Color-EC.
      </t>

<!-- [rfced] FYI, for clarity, we added the word 'steering' twice
and changed 'path' to 'paths'. Please review whether this conveys
this intended meaning.

Original:
   All the steering variations described in [RFC9256] are applicable to BGP
   CAR color-aware path: on-demand steering, per- destination, per-flow,
   color-only steering.

Current:
   All the steering variations described in [RFC9256] are applicable to BGP
   CAR color-aware paths: on-demand steering, per-destination steering,
   per-flow steering, and color-only steering.
-->

      <t>This is consistent with the automated service route steering on SR
      Policy (a routing solution providing color-aware path) paths) defined in <xref
      target="RFC9256"/>. All the steering variations described in <xref
      target="RFC9256"/> are applicable to BGP CAR color-aware path: paths:
      on-demand steering, per-destination,
      per-flow, per-destination steering, per-flow steering, and
      color-only steering. For brevity, please refer to <xref target="RFC9256"/> Section 8.</t> target="RFC9256"
      sectionFormat="of" section="8"/>.</t>
      <t><xref target="SSTEERINGAPNDX"/> provides illustrations of service route
      automated steering over BGP CAR (E, C) routes.</t>
      <t>An egress PE may express its intent that traffic should be steered a certain way through the transport layer
      by allocating the SRv6 Service SID from a routed intent-aware
      locator prefix (Section 3.3 of <xref target="RFC8986"/>). (<xref target="RFC8986" sectionFormat="of" section="3.3"/>). Steering at an ingress
      PE is via resolution of the Service SID over a CAR Type-2 IP Prefix route.
      Service Steering steering over BGP CAR SRv6 transport is described in
      <xref target="SECCARSRV6"/>.</t>
      <t>Service steering via BGP CAR routes is applicable to any BGP SAFI, including SAFIs for
      IPv4/IPv6 (SAFI 1), L3VPN (SAFI 128), PW, pseudowire (PW), EVPN (SAFI 70), FlowSpec,
      and BGP-LU (SAFI 4).</t>
    </section>
    <section anchor="FILTERING" title="Filtering">
      <t>PE anchor="FILTERING">
      <name>Filtering</name>
      <t>PEs and BRs may support filtering of CAR routes. For instance, the filtering
      may only accept routes of locally configured colors.</t>
      <t>Techniques such as RT-Constrain RT Constrain <xref target="RFC4684"/> may also be applied to the CAR SAFI, where
      Route Target (RT) Extended-Communities <xref target="RFC4360"/> can be used to constrain distribution and
      automate filtering of CAR routes. RT assignment may be via user policy, policy; for example example, an RT
      value can be assigned to all routes of a specific color.</t>
      <t>A PE may support on-demand installation of a CAR route based on the presence of a service route whose next-hop next hop
      resolves via the CAR route.</t>
      <t>Similarly, a PE may dynamically subscribe to receive individual CAR
      routes from upstream routers or
      route-reflectors Route Reflectors (RRs) to limit the routes
      that it needs to learn. On-demand subscription and automated filtering
      procedures for individual CAR routes are outside the scope of this
      document.
      </t>
    </section>
    <section anchor="SCLNG" title="Scaling"> anchor="SCLNG">
      <name>Scaling</name>
      <t>This section analyses analyzes the key scale requirement of
      <xref target="I-D.hr-spring-intentaware-routing-using-color"/>, specifically:
        <list style="symbols">
      </t>
      <ul spacing="normal">
        <li>
          <t>No intermediate node data-plane should need to scale to (Colors * PEs).</t>
        </li>
        <li>
          <t>No node should learn and install a BGP CAR route to (E, C) if it does
        not install a Colored colored service route to E.</t>
        </list>
      </t>
        </li>
      </ul>
      <t>While the requirements and design principles generally apply to any transport,
      the logical analysis based on the network design in this section focuses on
      MPLS / SR-MPLS
      MPLS/SR-MPLS transport since the scaling constraints are specifically relevant to
      these technologies. BGP CAR SAFI is used here, but the considerations can apply to
      [RFC8277]
      <xref target="RFC8277"/> or [RFC8669] <xref target="RFC8669"/> used with MPLS/SR-MPLS.
      </t>
      <t>Two key principles used to address the scaling requirements are a
 	  hierarchical network and routing design, and on-demand route
 	  subscription and filtering.</t>
      <t><xref target="SUSRT"/> in <xref target="USTOP"/> provides an ultra-scale
      reference topology. <xref target="USTOP"/> describes this topology.
      <xref target="SSDM"/> presents three design models to deploy BGP CAR in the
      reference topology, including hierarchical options. <xref target="SSA"/> analyses analyzes
      the logical scaling properties of each model.</t>
      <t>Filtering techniques described in the previous section allow a PE to
      limit the CAR routes that it needs to learn or install. Scaling benefits
      of on-demand BGP subscription and filtering will be described in a
      separate document.</t>
      <section anchor="USTOP" title="Ultra-Scale anchor="USTOP">
        <name>Ultra-Scale Reference Topology"> Topology</name>
        <figure anchor="SUSRT" title="Ultra-Scale anchor="SUSRT">
          <name>Ultra-Scale Reference Topology"> Topology</name>
          <artwork><![CDATA[
                                         RD:V/v via E2
          +-----+              +-----+ vpn label:30030 +-----+
  ....... |S-RR1| <........... |S-RR2| <...............|S-RR3| <......
  :       +-----+              +-----+  Color C1       +-----+       :
  :                                                                  :
  :                                                                  :
  :                                                                  :
 +:------------+--------------+--------------+--------------+--------:-+
 |:            |              |              |              |        : |
 |:            |              |              |              |        : |
 |:          +---+          +---+          +---+          +---+      : |
 |:          |121|          |231|          |341|          |451|      : |
 |:          +---+          +---+          +---+          +---+      : |
 |---+         |              |              |              |      +---|
 | E1|         |              |              |              |      | E2|
 |---+         |              |              |              |      +---|
 |           +---+          +---+          +---+          +---+        |
 |           |122|          |232|          |342|          |452|        |
 |           +---+          +---+          +---+          +---+        |
 |   Access    |   Metro      |   Core       |   Metro      | Access   |
 |   domain 1  |   domain 2   |   domain 3   |   domain 4   | domain 5 |
 +-------------+--------------+--------------+--------------+----------+
  iPE         iBRM          iBRC           eBRC           eBRM       ePE
]]></artwork>

        </figure>
        <t>The following description applies to the reference topology above:
          <list style="symbols">
        </t>
        <ul spacing="normal">
          <li>
            <t>Independent IS-IS/OSPF SR instance in each domain.</t>
          </li>
          <li>
            <t>Each domain has Flex Algo 128. Prefix SID Prefix-SID for a node is SRGB Segment Routing Global Block (SRGB) 168000 plus
          node number.</t>
          </li>
          <li>
            <t>A BGP CAR route (E2, C1) is advertised by egress BRM node 451. The route is
          sourced locally from redistribution from IGP-FA 128.</t>
          </li>
          <li>
            <t>Not shown for simplicity, node 452 will also advertise (E2, C1).</t>
          </li>
          <li>
            <t>When a transport RR is used within the domain or across domains,
          ADD-PATH is enabled to advertise paths from both egress BRs to it's its
          clients.</t>
          </li>
          <li>
            <t>Egress PE E2 advertises a VPN route RD:V/v with BGP Color extended
          community Color-EC C1 that propagates via service RRs to ingress PE E1.</t>
          </li>
          <li>
            <t>E1 steers V/v prefix via color-aware path (E2, C1) and VPN label 30030.</t>
          </list>
        </t>
          </li>
        </ul>
      </section>
      <section anchor="SSDM" title="Deployment Model">
        <section title="Flat"> anchor="SSDM">
        <name>Deployment Model</name>
        <section>
          <name>Flat</name>
          <figure anchor="SFLAT"
          title="Flat anchor="SFLAT">
            <name>Flat Transport Network Design"> Design</name>
            <artwork><![CDATA[
                                        RD:V/v via E2
         +-----+              +-----+ vpn label:30030 +-----+
 ....... |S-RR1| <........... |S-RR2| <...............|S-RR3| <......
 :       +-----+              +-----+  Color C1       +-----+       :
 :                                                                  :
 :                                                                  :
 :                                                                  :
+:------------+--------------+--------------+--------------+--------:-+
|:            |              |              |              |        : |
|:            |   (E2,C1)    |   (E2,C1)    |   (E2,C1)    |        : |
|:          +---+ via 231  +---+ via 341  +---+ via 451  +---+      : |
|:(E2,C1)   |121|<---------|231|<---------|341|<---------|451|      : |
|: via 121 /+---+ L=168002 +---+ L=168002 +---+ L=168002 +---+      : |
|---+     /   |              |              |              |      +---|
| E1| <--/    |              |              |              |      | E2|
|---+ L=168002|              |              |              |      +---|
|           +---+          +---+          +---+          +---+        |
|           |122|          |232|          |342|          |452|        |
|           +---+          +---+          +---+          +---+        |
|   Access    |   Metro      |   Core       |   Metro      | Access   |
|   domain 1  |   domain 2   |   domain 3   |   domain 4   | domain 5 |
+-------------+--------------+--------------+--------------+----------+
 iPE         iBRM          iBRC           eBRC           eBRM      ePE

168121      168231        168341        168451
168002      168002        168002        168002         168002
 30030       30030         30030         30030          30030     30030
]]></artwork>
          </figure>
          <t>
            <list style="symbols">
          <ul spacing="normal">
            <li>
              <t>Node 451 advertises BGP CAR route (E2, C1) to 341, from which
              it goes to 231 231, then to 121 121, and finally to E1.</t>
            </li>
            <li>
              <t>Each BGP hop allocates local label and programs swap entry in forwarding
            for (E2, C1).</t>
            </li>
            <li>
              <t>E1 receives BGP CAR route (E2, C1) via 121 with label 168002.
              <list>
              </t>
              <ul spacing="normal">
                <li>
                  <t>Let's assume E1 selects that path.</t>
              </list>
            </t>
                </li>
              </ul>
            </li>
            <li>
              <t>E1 resolves BGP CAR route (E2, C1) via 121 on color-aware path (121, C1).
              <list>
              </t>
              <ul spacing="normal">
                <li>
                  <t>Color-aware path (121, C1) is FA128 path to 121 (label 168121).</t>
              </list>
            </t>
                </li>
              </ul>
            </li>
            <li>
              <t>E1's imposition color-aware label-stack label stack for V/v is thus
              <list> thus:</t>
              <ul spacing="normal">
                <li>
                  <t>30030  &lt;=> &lt;=&gt; V/v</t>
                </li>
                <li>
                  <t>168002  &lt;=> &lt;=&gt; (E2, C1)</t>
                </li>
                <li>
                  <t>168121  &lt;=> &lt;=&gt; (121, C1)</t>
              </list>
            </t>
                </li>
              </ul>
            </li>
            <li>
              <t>Each BGP hop performs swap operation on 168002 bound to color-aware path
            (E2, C1).</t>
            </list>
          </t>
            </li>
          </ul>
        </section>

        <section title="Hierarchical
        <section>
          <name>Hierarchical Design with Next-Hop-Self at Ingress Domain BR"> BR</name>
          <figure anchor="BGPCARSCALEHEIRNH"
          title="Hierarchical anchor="BGPCARSCALEHEIRNH">
            <name>Hierarchical BGP transport Transport CAR, Next-Hop-Self (NHS) at iBR"> iBR</name>
            <artwork><![CDATA[
                               (E2,C1)
                      +-----+  via 451        +-----+
                      |T-RR1| <-------------- |T-RR2|
                    / +-----+  L=168002       +-----+\
                   /                                   \
+-------------+---/----------+--------------+-----------\--+----------+
|             |  /           |              |            \ |          |
|  (E2,C1)    | / (451,C1)   |   (451,C1)   |             \|          |
|  via 121  +---+ via 231  +---+ via 341  +---+          +---+        |
|  L=168002 |121| <======= |231| <========|341| <======= |451|        |
|         / +---+ L=168451 +---+ L=168451 +---+          +---+        |
|---+    /    |              |              |              |      +---|
| E1|<--/     |              |              |              |      | E2|
|---+         |              |              |              |      +---|
|           +---+          +---+          +---+          +---+        |
|           |122|          |232|          |342|          |452|        |
|           +---+          +---+          +---+          +---+        |
|   Access    |   Metro      |   Core       |   Metro      | Access   |
|   domain 1  |   domain 2   |   domain 3   |   domain 4   | domain 5 |
+-------------+--------------+--------------+--------------+----------+
 iPE         iBRM          iBRC           eBRC           eBRM      ePE

            168231        168341
168121      168451        168451        168451
168002      168002        168002        168002         168002
 30030       30030         30030         30030          30030     30030
]]></artwork>
          </figure>
          <t>
            <list style="symbols">
          <ul spacing="normal">
            <li>
              <t>Node 451 advertises BGP CAR route (451, C1) to 341, from which it goes to
            231
            231, and finally to 121.</t>
            </li>
            <li>
              <t>Each BGP hop allocates local label and programs swap entry in forwarding
            for (451, C1).</t>
            </li>
            <li>
              <t>121 resolves received BGP CAR route (451, C1) via 231 (label 168451) on
            color-aware path (231, C1).
              <list>
              </t>
              <ul spacing="normal">
                <li>
                  <t>Color-aware path (231, C1) is FA128 path to 231 (label 168231).</t>
              </list>
            </t>
                </li>
              </ul>
            </li>
            <li>
              <t>451 advertises BGP CAR route (E2, C1) via 451 to transport RR T-RR2, which
            reflects it to transport RR T-RR1, which reflects it to 121.</t>
            </li>
            <li>
              <t>121 receives BGP CAR route (E2, C1) via 451 with label 168002.
              <list>
              </t>
              <ul spacing="normal">
                <li>
                  <t>Let's assume 121 selects that path.</t>
              </list>
            </t>
                </li>
              </ul>
            </li>
            <li>
              <t>121 resolves BGP CAR route (E2, C1) via 451 on color-aware path (451, C1).
              <list>
              </t>
              <ul spacing="normal">
                <li>
                  <t>Color-aware path (451, C1) is BGP CAR path to 451 (label 168451).</t>
              </list>
            </t>
                </li>
              </ul>
            </li>
            <li>
              <t>121 imposition of color-aware label stack for (E2, C1) is thus
              <list> thus:</t>
              <ul spacing="normal">
                <li>
                  <t>168002  &lt;=> &lt;=&gt; (E2, C1)</t>
                </li>
                <li>
                  <t>168451  &lt;=> &lt;=&gt; (451, C1)</t>
                </li>
                <li>
                  <t>168231	 &lt;=> &lt;=&gt; (231, C1)</t>
              </list>
            </t>
                </li>
              </ul>
            </li>
            <li>
              <t>121 advertises (E2, C1) to E1 with next hop self next-hop-self (121) and label 168002</t> 168002.</t>
            </li>
            <li>
              <t>E1 constructs same imposition color-aware label-stack label stack for V/v via (E2, C1)
            as in the flat model:
              <list>
              </t>
              <ul spacing="normal">
                <li>
                  <t>30030  &lt;=> &lt;=&gt; V/v</t>
                </li>
                <li>
                  <t>168002	 &lt;=> &lt;=&gt; (E2, C1)</t>
                </li>
                <li>
                  <t>168121	 &lt;=> &lt;=&gt; (121, C1)</t>
              </list>
            </t>
                </li>
              </ul>
            </li>
            <li>
              <t>121 performs swap operation on 168002 with hierarchical color-aware label
            stack for (E2, C1) via 451 from step 7.</t>
            </li>
            <li>
              <t>Nodes 231 and 341 perform swap operation on 168451 bound to color-aware
            path (451, C1).</t>
            </li>
            <li>
              <t>451 performs swap operation on 168002 bound to color-aware path (E2, C1).</t>
            </list>
          </t>
            </li>
          </ul>
          <t>Note: E1 does not need the BGP CAR route (451, C1) in this design.</t>
        </section>
        <section anchor="SBGPCARSCALEHEIRNHU"
        title="Hierarchical anchor="SBGPCARSCALEHEIRNHU">
          <name>Hierarchical Design with Next-Hop-Unchanged at Ingress Domain BR"> BR</name>
          <figure anchor="BGPCARSCALEHEIRNHU"
          title="Hierarchical anchor="BGPCARSCALEHEIRNHU">
            <name>Hierarchical BGP transport Transport CAR, Next-Hop-Unchanged (NHU) at iBR"> iBR</name>
            <artwork><![CDATA[
                               (E2,C1)
                      +-----+  via 451        +-----+
                      |T-RR1| <-------------- |T-RR2|
                    / +-----+  L=168002       +-----+\
                   /                                   \
+-------------+---/----------+--------------+-----------\--+----------+
|             |  /           |              |            \ |          |
|  (E2,C1)    | / (451,C1)   |   (451,C1)   |             \|          |
|  via 451  +---+ via 231  +---+ via 341  +---+          +---+        |
|  L=168002/|121| <======= |231| <========|341| <======= |451|        |
|         / +---+ L=168451 +---+ L=168451 +---+          +---+        |
|---+ <--/  //|              |              |              |      +---|
| E1|      // |              |              |              |      | E2|
|---+ <===//  |              |              |              |      +---|
|  (451,C1) +---+          +---+          +---+          +---+        |
|  via 121  |122|          |232|          |342|          |452|        |
|  L=168451 +---+          +---+          +---+          +---+        |
|             |              |              |              |          |
|   Access    |   Metro      |   Core       |   Metro      | Access   |
|   domain 1  |   domain 2   |   domain 3   |   domain 4   | domain 5 |
+-------------+--------------+--------------+--------------+----------+
 iPE         iBRM           iBRC          eBRC           eBRM      ePE

168121      168231        168341
168451      168451        168451        168451
168002      168002        168002        168002         168002
 30030       30030         30030         30030          30030     30030
]]></artwork>
          </figure>
          <t>
            <list style="symbols">

          <ul spacing="normal">
            <li>
              <t>Nodes 341, 231 231, and 121 receive and resolve BGP CAR route (451, C1) the
            same as in the previous model.</t>
            </li>
            <li>
              <t>Node 121 allocates local label and programs swap entry in forwarding for
            (451, C1).</t>
            </li>
            <li>
              <t>451 advertises BGP CAR route (E2, C1) to transport RR T-RR2, which
            reflects it to transport RR T-RR1, which reflects it to 121.</t>
            </li>
            <li>
              <t>Node 121 advertises (E2, C1) to E1 with next hop as 451; i.e.,
            next-hop-unchanged.</t> 451
              (i.e., next-hop-unchanged).</t>
            </li>
            <li>
              <t>121 also advertises (451, C1) to E1 with next hop self next-hop-self (121) and label
            168451.</t>
            </li>
            <li>
              <t>E1 resolves BGP CAR route (451, C1) via 121 on color-aware path (121, C1).
              <list>
              </t>
              <ul spacing="normal">
                <li>
                  <t>Color-aware path (121, C1) is FA128 path to 121 (label 168121).</t>
              </list>
            </t>
                </li>
              </ul>
            </li>
            <li>
              <t>E1 receives BGP CAR route (E2, C1) via 451 with label 168002.
              <list>
              </t>
              <ul spacing="normal">
                <li>
                  <t>Let's assume E1 selects that path.</t>
              </list>
            </t>
                </li>
              </ul>
            </li>
            <li>
              <t>E1 resolves BGP CAR route (E2, C1) via 451 on color-aware path (451, C1).
              <list>
              </t>
              <ul spacing="normal">
                <li>
                  <t>Color-aware path (451, C1) is BGP CAR path to 451 (label 168451).</t>
              </list>
            </t>
                </li>
              </ul>
            </li>
            <li>
              <t>E1's imposition color-aware label-stack label stack for V/v is thus
              <list> thus:</t>
              <ul spacing="normal">
                <li>
                  <t>30030  &lt;=> &lt;=&gt; V/v</t>
                </li>
                <li>
                  <t>168002	&lt;=> &lt;=&gt; (E2, C1)</t>
                </li>
                <li>
                  <t>168451	&lt;=> &lt;=&gt; (451, C1)</t>
                </li>
                <li>
                  <t>168121	&lt;=> &lt;=&gt; (121, C1)</t>
              </list>
            </t>
                </li>
              </ul>
            </li>
            <li>
              <t>Nodes 121, 231 231, and 341 perform swap operation on 168451 bound to (451, C1).</t>
            </li>
            <li>
              <t>451 performs swap operation on 168002 bound to color-aware path (E2, C1).</t>
            </list>
          </t>
            </li>
          </ul>
        </section>
      </section>
      <section anchor="SSA" title="Scale Analysis"> anchor="SSA">
        <name>Scale Analysis</name>
        <t>The following two tables summarize the logically analyzed scaling of the
        control-plane and data-plane for these the previous three models:</t>

        <figure>
        <artwork><![CDATA[
     |        E1           |       121           |       231
-----+---------------------+---------------------+--------------------
FLAT | (E2,C) via (121,C)  | (E2,C) via (231,C)  | (E2,C) via (341,C)
-----+---------------------+---------------------+--------------------
H.NHS| (E2,C) via (121,C)  | (E2,C) via (451,C)  |
     |                     | (451,C) via (231,C) | (451,C) via (341,C)
-----+---------------------+---------------------+--------------------
H.NHU| (E2,C) via (451,C)  |                     |
     | (451,C) via (121,C) | (451,C) via (231,C) | (451,C) via (341,C)
-----+---------------------+---------------------+--------------------
        ]]></artwork>
      </figure>

              <figure>
        <artwork><![CDATA[
     |        E1           |       121           |       231
-----+---------------------+---------------------+--------------------
FLAT | V ->   30030        | 168002
<table>
  <thead>
    <tr>
      <th></th>
      <th>E1</th>
      <th>121</th>
      <th>231</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <th>FLAT</th>
      <td>(E2,C) via (121,C)</td>
      <td>(E2,C) via (231,C)</td>
      <td>(E2,C) via (341,C)</td>
    </tr>
    <tr>
      <th>H.NHS</th>
      <td>(E2,C) via (121,C)</td>
      <td>(E2,C) via (451,C)<br/>(451,C) via (231,C)</td>
      <td>(451,C) via (341,C)</td>
    </tr>
    <tr>
      <th>H.NHU</th>
      <td>(E2,C) via (451,C)<br/>(451,C) via (121,C)</td>
      <td>(451,C) via (231,C)</td>
      <td>(451,C) via (341,C)</td>
    </tr>
  </tbody>
</table>

<table>
  <thead>
    <tr>
      <th></th>
      <th>E1</th>
      <th>121</th>
      <th>231</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <th>FLAT</th>
      <td align="right">V -> 168002    | 168002 -> 168002
     |        168002       |           168231    |           168341
     |        168121       |                     |
-----+---------------------+---------------------+--------------------
H.NHS| V 30030<br/>168002<br/>168121</td>
      <td align="right">168002 ->   30030        | 168002 168002<br/>168231</td>
      <td align="right">168002 -> 168002    | 168451 168002<br/>168341</td>
    </tr>
    <tr>
      <th>H.NHS</th>
      <td align="right">V -> 168451
     |        168002       |           168451    |           168341
     |        168121       |           168231    |
-----+---------------------+---------------------+--------------------
H.NHU| V   30030<br/>168002<br/>168121</td>
      <td align="right">168002 ->   30030        | 168451 168002<br/>168451<br/>168231</td>
      <td align="right">168451 -> 168451    | 168451 168451<br/>168341</td>
    </tr>
    <tr>
      <th>H.NHU</th>
      <td align="right">V -> 168451
     |        168002       |           168231    |           168341
     |        168451       |                     |
     |        168121       |                     |
-----+---------------------+---------------------+--------------------
        ]]></artwork>
      </figure>

        <t>
          <list style="symbols">   30030<br/>168002<br/>168451<br/>168121</td>
      <td align="right">168451&nbsp;->&nbsp;168451<br/>168231</td>
      <td align="right">168451&nbsp;->&nbsp;168451<br/>168341</td>
    </tr>
  </tbody>
</table>
        <ul spacing="normal">
          <li>
            <t>The flat model is the simplest design, with a single BGP
            transport level.  It results in the minimum label/SID stack at
            each BGP hop. However, it significantly increases the scale impact
            on the core BRs (e.g. (e.g., 341), whose FIB capacity and even MPLS
            label space may be exceeded.
            <list>
            </t>
            <ul spacing="normal">
              <li>
                <t>341's data-plane scales with (E2, C) where there may be
                300k E's Es and 5 C's Cs, hence 1.5M entries > &gt; 1M MPLS
                data-plane.</t>
            </list>
          </t>
              </li>
            </ul>
          </li>
          <li>
            <t>The hierarchical models avoid the need for core BRs to learn routes and
          install label forwarding entries for (E, C) routes.
            <list>
            </t>
            <ul spacing="normal">
              <li>
                <t>Whether next hop is set to self or left unchanged at 121, 341's data-plane
            scales with (451, C) where there may be thousands of 451's 451s and 5 C's. Cs. Therefore,
            this scaling is well under the 1 million MPLS labels data-plane limit.</t>
              </li>
              <li>
                <t>They also aid faster convergence by allowing the PE routes
                to be distributed via out-of-band RRs that can be scaled
                independent of the transport BRs.</t>
            </list>
          </t>
              </li>
            </ul>
          </li>
          <li>
            <t>The next-hop-self option at ingress BRM (e.g. (e.g., 121) hides the hierarchical
          design from the ingress PE, keeping its outgoing label programming as simple as
          the flat model. However, the ingress BRM requires an additional BGP transport
          level recursion, which coupled with load-balancing adds data-plane complexity.
          It needs to support a swap and push operation. It also needs to install label
          forwarding entries for the egress PEs that are of interest to its local ingress
          PEs.</t>
          </li>
          <li>
            <t>With the next-hop-unchanged option at ingress BRM (e.g. (e.g., 121), only an ingress
          PE needs to learn and install output label entries for egress (E, C) routes.
          The ingress BRM only installs label forwarding entries for the egress ABR
          (e.g.
          (e.g., 451). However, the ingress PE needs an additional BGP transport level
          recursion and pushes a BGP VPN label and two BGP transport labels. It may also
          need to handle load-balancing for the egress ABRs. This is the most complex
          data-plane option for the ingress PE.</t>
          </list>
        </t>
          </li>
        </ul>
      </section>
      <section anchor="SECANYCASTSID" title="Anycast SID"> anchor="SECANYCASTSID">
        <name>Anycast SID</name>
        <t>This section describes how Anycast SID complements and improves the
        scaling designs above.</t>
        <section anchor="ASIDTRANS" title="Anycast anchor="ASIDTRANS">
          <name>Anycast SID for Transit Inter-domain Nodes">
          <t>
            <list style="symbols"> Inter-Domain Nodes</name>
          <ul spacing="normal">
            <li>
              <t>Redundant BRs (e.g. (e.g., two egress BRMs, 451 and 452) advertise BGP CAR
            routes for a local PE (e.g., E2) with the same SID (based on label index).
            Such egress BRMs may be assigned a common Anycast SID, so that the BGP
            next hops for these routes will also resolve via a color-aware path to
            the Anycast SID.</t>
            </li>
            <li>
              <t>The use of Anycast SID naturally provides fast local convergence upon
            failure of an egress BRM node. In addition, it decreases the recursive
            resolution and load-balancing complexity at an ingress BRM or PE in the
            hierarchical designs above.</t>
            </list>
          </t>
            </li>
          </ul>
        </section>
        <section title="Anycast
        <section>
          <name>Anycast SID for Transport Color Endpoints (e.g., PEs)"> Endpoints</name>
          <t>The common Anycast SID technique may also be used for a redundant pair
          of PEs that share an identical set of service (VPN) attachments.
          </t>
          <t>
            <list style="symbols">
          <ul spacing="normal">
            <li>
              <t>
            For example, assume a node E2' is paired with E2 above
            (e.g., <xref target="BGPCARSCALEHEIRNHU"/>). Both
            PEs should be configured with the same static label/SID for the services
            (e.g., per-VRF VPN label/SID), and will advertise associated service
            routes with the Anycast IP as BGP next hop. </t>
            </li>
            <li>
              <t>This design provides a convergence and recursive resolution benefit on
            an ingress PE or ABR similar to the egress ABR case in the previous section
            (<xref target="ASIDTRANS"/>).
            <xref target="ASIDTRANS"/>.  However, its applicability is limited
            to cases where the above constraints can be met.</t>
            </list>
          </t>
            </li>
          </ul>
        </section>
      </section>
    </section>

    <section title="Routing Convergence">
    <section>
      <name>Routing Convergence</name>
      <t>BGP CAR leverages existing well-known design techniques to provide fast
      convergence.</t>
      <t><xref target="SECPA"/> describes how BGP CAR provides localized
      convergence within a domain for BR failures, including originating BRs, without
      propagating failure churn into other domains.</t>
      <t>Anycast SID techniques described in <xref target="SECANYCASTSID"/>
      can provide further convergence optimizations for BR and PE failures deployed in
      redundant designs.
      </t>
    </section>
    <section anchor="SECCARSRV6" title="CAR SRv6">
      <section title="Overview"> anchor="SECCARSRV6">
      <name>CAR SRv6</name>
      <section>
        <name>Overview</name>
        <t>Steering services over SRv6 based SRv6-based intent-aware multi-domain
        transport paths may be categorized into two distinct cases that are
        described in Section 5 of <xref target="RFC9252"/>. target="RFC9252" sectionFormat="of"
        section="5"/>. Both cases are supported by BGP CAR, as described
        below.</t>
        <section anchor="SECRTDSSID" title="Routed anchor="SECRTDSSID">
          <name>Routed Service SID"> SID</name>
          <t>The SRv6 Service SID that is advertised with a service route is
          allocated by an egress PE from a routed intent-aware locator prefix
          (Section 3.3 of <xref target="RFC8986"/>).
          (<xref target="RFC8986" sectionFormat="of" section="3.3"/>). Service steering at an ingress PE is
          via resolution of the Service SID signaled with the service route as described in
          (<xref target="RFC9252"/>).</t>
          <xref target="RFC9252"/>.</t>
          <t>The intent-aware transport path to the SRv6 locator of the egress PE is provided
          by underlay IP routing. Underlay IP routing can include IGP Flex-Algo <xref target="RFC9350"/>
          within a domain, and BGP CAR [this document] (as defined in this document) across multiple IGP domains or BGP ASes.</t>
          <t> An SRv6 locator prefix is assigned for a given intent or color. The SRv6 locator
          may be shared with an IGP Flex-Algo, or it may be assigned specific to BGP CAR for
          a given intent.</t>
          <t>Distribution of SRv6 locators in BGP CAR SAFI:
          <list style="symbols">
          </t>
          <ul spacing="normal">
            <li>
              <t>In a multi-domain network, the SRv6 locator prefix is distributed using BGP CAR SAFI
          to ingress PEs and ASBRs in a remote domain. The SRv6 locator prefix may be advertised
          in the BGP CAR SAFI from an egress PE, or redistributed into BGP CAR from an IGP-FlexAlgo
          at a BR. The locator prefix may also be summarized on a border node along the path and
          a summary route distributed to ingress PEs.</t>
            </li>
            <li>
              <t> An IP Prefix CAR route (Type-2) is defined to distribute SRv6 locator prefixes
          and described in Sections <xref target="NLRITYPE2"/> target="NLRITYPE2" format="counter"/> and <xref target="CARIPPREFIX"/>.</t> target="CARIPPREFIX" format="counter"/>.</t>
            </li>
            <li>
              <t>A BGP CAR advertised SRv6 locator prefix may also be used for resolution
          of the SRv6 service Service SID advertised for best-effort connectivity.</t>
          </list>
	  </t>

          <t><xref target="SECLOCHBYH"/>
            </li>
          </ul>
          <t>Appendices <xref target="SECLOCHBYH" format="counter"/> and <xref target="SECSRv6LOCencap"/>
          illustrates target="SECSRv6LOCencap" format="counter"/>
          illustrate the control control, and forwarding behaviors for routed SRv6
          Service SID.</t> SIDs.</t>
          <t><xref target="SRv6DEPLT"/> describes the deployment options.</t>
          <t><xref target="SRv6CAROPER"/> describes operational considerations
          of using BGP CAR SAFI vs versus BGP IPv6 SAFI for inter-domain route distribution
          of SRv6 locators.</t>
        </section>
        <section anchor="SECNRSSID" title="Non-routed anchor="SECNRSSID">
          <name>Non-Routed Service SID"> SID</name>
          <t>The SRv6 Service SID allocated by an egress PE is not routed. The service
          route carrying the non-routed SRv6 Service SID is advertised by the egress PE
          with a Color-EC C (<xref target="RFC9252"/> section 5). target="RFC9252" sectionFormat="comma" section="5"/>).
          An ingress PE in a remote domain steers traffic for the received service route with
          Color-EC C and this SRv6 Service SID as described below.</t>
          <t>BGP CAR distribution of (E, C) underlay route:
          <list style="symbols">
          </t>
          <ul spacing="normal">
            <li>
              <t>The intent-aware path to the egress PE within the egress domain is
          provided by an SR-TE or similar policy (E, C) <xref target="RFC9256"/>.
          This (E, C) policy is distributed into the multi-domain network from egress BRs
          using a BGP CAR (E, C) route towards ingress PEs in other domains.
          This signaling is the same as for SR-MPLS as described in earlier sections.</t>
            </li>
            <li>
              <t>The (E, C) BGP CAR Type-1 route is advertised from a BR with an
          SRv6 transport SID allocated from an SRv6 locator assigned for the intent C.
          An SR-PCE or local configuration may ensure multiple BRs in the egress
          domain that originate the (E, C) route advertise the same SRv6 transport SID.
              </t>
          </list>
          </t>
            </li>
          </ul>
          <t>BGP CAR distribution of SRv6 locator underlay route:
          <list style="symbols">
          </t>
          <ul spacing="normal">
            <li>
              <t>
          BGP CAR MAY <bcp14>MAY</bcp14> also provide the underlay intent-aware inter-domain route to resolve
          the intent-aware SRv6 transport SID advertised with the (E, C) BGP CAR route as
          follows:

	  <list>

              </t>
              <ul spacing="normal">
                <li>
                  <t>An egress domain BR has a an SRv6 locator prefix that covers the SRv6 transport SID
	  allocated by the egress BR for the (E, C) BGP CAR route.</t>
                </li>
                <li>
                  <t>The egress domain BR advertises an IP Prefix Type-2 CAR route for the SRv6
          locator prefix, and the route is distributed across BGP hops in the underlay
          towards ingress PEs. This distribution is the same as the previous case in
          <xref target="SECRTDSSID"/> case. target="SECRTDSSID"/>. The route may also be summarized in another
          CAR type-2 Type-2 route prefix.</t>
          </list>
          </t>
          </list>
          </t>
                </li>
              </ul>
            </li>
          </ul>
          <t>Service traffic steering and SRv6 transport SID resolution at ingress PE:
          <list style="symbols">
          </t>
          <ul spacing="normal">
            <li>
              <t>An ingress PE in a remote domain resolves the received
              service route with Color color C via the (E, C) BGP CAR route above,
              as described in <xref target="STEERING"/>.</t>
            </li>
            <li>
              <t>Additionally, the ingress PE resolves the SRv6 transport SID
              received in the BGP CAR (E, C) route via the BGP CAR IP Prefix
              route, similar to the SRv6 Routed Service SID resolution in
              <xref target="SECRTDSSID"/>.
          <list>
              </t>
              <ul spacing="normal">
                <li>
                  <t>Multiple (E, C) routes may resolve via a single IP Prefix CAR route.
          <list>
                  </t>
                  <ul spacing="normal">
                    <li>
                      <t>Resolution of (E, C) routes over IP Prefix CAR routes is the typical
          resolution order as the IP Prefix route provides
          intent-aware reachability to the BRs that advertise the (E, C) specific
          routes for each egress PE. However, there can be use-cases use cases where a an IP Prefix
          CAR route may resolve via a (E, C) route.</t>
          </list>
          </t>
          </list>
          </t>
                    </li>
                  </ul>
                </li>
              </ul>
            </li>
            <li>
              <t>The ingress PE via the recursive resolution above builds the packet
          encapsulation that contains the SRv6 Service SID and the received (E, C)
          route's SRv6 transport SID in the SID-list.
          </t>

          </list> SID list.
              </t>
            </li>
          </ul>
          <t><xref target="SECSRv6EC"/> contains an example that illustrates the control
          plane distribution, recursive resolution and forwarding behaviors described
          above.
          </t>
          <t>Note: An SR-policy may also be defined for multi-domain end to end
          <xref target="RFC9256"/>, independent of BGP CAR. In that case, both
          BGP CAR and SR-TE inter-domain paths may be available at an ingress PE for an (E, C) route
          (<xref target="SECCARIllus"/>).</t>
        </section>
      </section>
      <section anchor="SRv6DEPLT"
      title="Deployment anchor="SRv6DEPLT">
        <name>Deployment Options For for CAR SRv6 Locator Reachability Distribution and Forwarding"> Forwarding</name>
        <t>Since an SRv6 locator (or summary) is an IPv6 prefix, it will be installed
        into the IPv6 forwarding table on a BGP router (e.g., ABR or ASBR), ASBR) for packet
        forwarding. With the use of IPv6 locator prefixes, there is no need to allocate and
        install per-PE SIDs on each BGP hop to forward packets.</t>
        <t> A few options to forward packets for BGP SRv6 prefixes described in
        (<xref
        <xref target="I-D.ietf-spring-srv6-mpls-interworking"/>
        also apply to BGP CAR. These options are described in
        Sections <xref target="SRv6HBH"/> target="SRv6HBH" format="counter"/> and <xref target="SRv6ENC"/>. target="SRv6ENC" format="counter"/>. </t>
        <section anchor="SRv6HBH" title="Hop by Hop anchor="SRv6HBH">
          <name>Hop-by-Hop IPv6 Forwarding for BGP SRv6 Prefixes"> Prefixes</name>
          <t>This option employs hop by hop hop-by-hop IPv6 lookup and forwarding on both BRs and P nodes
            in a domain along the path of propagation of BGP CAR routes. This option's
            procedures include the following:

            <list style="symbols">

          </t>
          <ul spacing="normal">
            <li>
              <t>In addition to BRs, P nodes within a domain also learn BGP CAR IP Prefix routes (for SRv6)
            and install them into the forwarding table. </t>
            </li>
            <li>
              <t>BGP routing is enabled on all internal nodes (iBGP) using full-mesh or an RR.</t>
            </li>
            <li>
              <t>BRs distribute external BGP SRv6 routes to internal peers including P routers,
            with the following conditions:

            <list style="symbols">
            <t>The

              </t>
              <ul spacing="normal">
                <li>
                  <t>the external BGP Next-hop next hop is advertised unchanged to the internal peers;</t>
            <t>Internal
                </li>
                <li>
                  <t>internal nodes use recursive resolution via IGP at each
                  hop to forward IPv6 packets towards the external BGP next-hop;
                  next hop; and </t>
            <t>Resolution
                </li>
                <li>
                  <t>resolution is per intent/color (e.g., via IGP IPv6 FlexAlgo).</t>
            </list>
	    </t>
            </list>
          </t>
                </li>
              </ul>
            </li>
          </ul>
          <t>This design is illustrated with an example in <xref target="SECLOCHBYH"/>.</t>
          <t>The benefits of this scheme are:
            <list style="symbols">
              <t>Simpler
          </t>
          <ul spacing="normal">
            <li>
              <t>A simpler design, as no tunnel encapsulation is required between BRs in a domain.</t>
            </li>
            <li>
              <t>No per-PE SID allocation and installation on any BGP hop.</t>
            </li>
            <li>
              <t>This design is similar to the well-known Internet / BGP
              hop-by-hop IP routing model and can support large scale large-scale route
              distribution.</t>
            </li>
            <li>
              <t>In addition, since SRv6 locator prefixes can be summarized,
              this minimizes the number of routes routes, and hence the scale
              requirements on P routers.</t>
              </list>
            </t>
            </li>
          </ul>
        </section>
        <section anchor="SRv6ENC" title="Encapsulation between anchor="SRv6ENC">
          <name>Encapsulation Between BRs for BGP SRv6 Prefixes"> Prefixes</name>
          <t>In this design, IPv6 lookup and forwarding for BGP SRv6 prefixes are only done on
            BGP BRs. This option includes the following procedures:

            <list style="symbols">
            <t> These procedures:</t>
          <ul spacing="normal">
            <li>
              <t>These nodes use SRv6 (or other) encapsulation encapsulations to reach the BGP SRv6 next hop.
              <list>
              <t>	SRv6
              </t>
              <ul spacing="normal">
                <li>
                  <t>SRv6 outer encapsulation may be H.Encaps.Red.</t>
              <t>	Encapsulation
                </li>
                <li>
                  <t>Encapsulation is not needed for directly connected next hops, such as with eBGP single-hop sessions.</t>
              </list>
            </t>
                </li>
              </ul>
            </li>
            <li>
              <t>BGP route distribution is enabled between BRs via RRs, or directly if single-hop BGP.</t>
            </li>
            <li>
              <t>An egress BR sets itself as BGP next hop, and selects and advertises an appropriate
            encapsulation towards itself.
              <list>
              </t>
              <ul spacing="normal">
                <li>
                  <t>If SRv6 encapsulation, then the SRv6 SID advertised from egress BR is from an SRv6
            locator for the specific intent within the domain.
            Multiple BGP SRv6 prefixes may share a common SID, avoiding
            per-PE SID allocation and installation on any BGP hop.</t>
                </li>
                <li>
<!-- [rfced] What is the subject of "may be shared" in the text below?

Original:
      -  If MPLS/SR-MPLS transport, the route will carry label/prefix-
         SID allocated by the next hop, may be shared.
-->

                  <t>If MPLS/SR-MPLS transport, the route will carry label/prefix-SID the label/Prefix-SID allocated
            by the next hop, may be shared.</t>
              </list>
            </t>
                </li>
              </ul>
            </li>
            <li>
              <t>An ingress BR encapsulates SRv6 egress PE destined packets with
            encapsulation to BGP next hop, ie. hop (i.e., the egress BR. </t>
            </list>
          </t>

            <t>Benefits BR).</t>
            </li>
          </ul>
          <t>The benefits of this scheme are:
            <list style="symbols">
          </t>
          <ul spacing="normal">
            <li>
              <t>P nodes do not need to learn or install BGP SRv6 prefixes in this (BGP-free core) design.</t>
            </li>
            <li>
              <t>No per-PE SID allocation and installation on any BGP hop.</t>
            </list>
          </t>
            </li>
          </ul>
          <t>This design is illustrated in <xref target="SECSRv6LOCencap"/>.</t>
        </section>
      </section>
      <section anchor="SRv6CAROPER"
      title="Operational anchor="SRv6CAROPER">
        <name>Operational Benefits of using Using CAR SAFI for SRv6 Locator Prefix Distribution"> Distribution</name>
        <t>When reachability to an SRv6 SID is provided by distribution of a locator prefix
      via underlay routing, BGP IPv6 SAFI (AFI/SAFI=2/1) may also be used for
      inter-domain distribution of these IPv6 prefixes as described in
      <xref target="I-D.ietf-spring-srv6-mpls-interworking"/> (Section 7.1.2) target="I-D.ietf-spring-srv6-mpls-interworking" sectionFormat="of" section="7.1.2"/> or
      <xref target="I-D.ietf-idr-cpr"/>.</t> target="RFC9723"/>.</t>
        <t>Using the BGP CAR SAFI provides the following operational benefits:
        <list style="symbols">
        </t>
        <ul spacing="normal">
          <li>
            <t>CAR SAFI is a separate BGP SAFI used for underlay transport intent-aware routing.
        It avoids overloading of BGP IPv6 SAFI, which also carries Internet (service)
        prefixes. Using CAR SAFI provides:
          <list style="symbols">
            </t>
            <ul spacing="normal">
              <li>
                <t>Automatic separation of SRv6 locator (transport) routes from Internet
          (service) routes,
            <list>
	    <t>Preventing
                </t>
                <ul spacing="normal">
                  <li>
                    <t>preventing inadvertent leaking of routes.</t>
   	    <t>Avoiding routes, and</t>
                  </li>
                  <li>
                    <t>avoiding the need to configure specific route filters for locator routes.</t>
            </list>
        </t>
                  </li>
                </ul>
              </li>
              <li>
                <t>Priority handling of infrastructure routes over service (Internet) routes.</t>
          </list>
        </t>
              </li>
            </ul>
          </li>
          <li>
            <t>CAR SAFI also supports inter-domain distribution of (E, C) routes
        sourced from SR-Policy, in addition to SRv6 locator IPv6 prefixes.</t>
          </li>
          <li>
            <t>CAR SAFI may also be used for best-effort routes in addition to
            intent-aware routes as described in the next section.</t>
        </list>
      </t>
          </li>
        </ul>
        <t>Note: If infrastructure routes such as SRv6 locator routes are
        carried in both BGP-IP [RFC4271] <xref target="RFC4271"/> / BGP-LU [RFC8277, RFC4798], <xref
        target="RFC8277"/> <xref target="RFC4798"/>, and BGP CAR, <xref
        target="CARIPPREFIX"/> describes the path selection preference between
        them.</t>
      </section>
    </section>
    <section anchor="CARIPPREFIX" title="CAR anchor="CARIPPREFIX">
      <name>CAR IP Prefix Route">
      <t>
An Route</name>
      <t>An IP Prefix CAR route is a route type (Type-2) that carries a
      routable IP prefix whose processing follows [RFC4271] the semantics of <xref target="RFC4271"/> and [RFC2545] semantics.
      <xref target="RFC2545"/>. IP Prefix CAR routes are installed
      in the default routing and forwarding table and provide
      longest-prefix-match forwarding. This is unlike Type-1 (E, C) routes,
      where it is the signaled forwarding data such as labels/SIDs that are
      installed in the forwarding table to create end to end end-to-end paths.</t>

      <t>
IP
      <t>IP Prefix CAR routes may be originated into BGP CAR SAFI either from
      an egress PE or from a BR in a domain. Type-2 routes carry
      infrastructure routes for both IPv4 and IPv6.
      </t> IPv6.</t>
      <t>As described in <xref target="SECDATAMODEL"/>, it is used for cases
      where a unique routable IP prefix is assigned for a given intent or
      color. It may also be used for routes providing best-effort
      connectivity.</t>
      <t>A few applicable example use-cases:
        <list style="symbols"> use cases:</t>
      <ul spacing="normal">
        <li>
          <t>SRv6 locator prefix with color for specific intents.</t>
        </li>
        <li>
          <t>SRv6 locator prefix without color for best-effort.</t>
        <t>Best effort
        </li>
        <li>
          <t>Best-effort transport reachability to a PE/BR without color.</t>
        </list>
      </t>
        </li>
      </ul>
      <t>
	For specific intents, color may be signaled with the IP Prefix CAR
	route for purposes such as intent-aware SRv6 SID or BGP next-hop next hop
	selection at each transit BR, color based color-based routing policies and
	filtering, and intent-aware next-hop resolution (<xref
	target="ROUTERES"/>). These purposes are the same as with (E, C)
	routes. For such purposes, color associated with the CAR IP Prefix
	route is signaled using LCM-EC.
      </t>
      <t>
	Reminder: LCM-EC conveys end-to-end intent/color associated with
	route/NLRI. When traversing network domain(s) where a different
	intent/color is used for next-hop resolution, BGP Color-EC may
	additionally be used as in <xref target="LCMBGPECUSAGE"/>.</t>
      <t>
	A special case of intent is best-effort best-effort, which may be represented by a
	color and follow the above procedures. But However, to be compatible with
	traditional operational usage, the CAR IP Prefix route is allowed to be
	without color for best-effort. In this case, the routes will not carry
	an LCM-EC. Resolution is described in <xref target="ROUTERES"/>.</t>
      <t>
	As described in <xref target="SRv6CAROPER"/>, infrastructure prefixes
	are intended to be carried in CAR SAFI instead of SAFIs that also
	carry service routes such as BGP-IP (SAFI 1, [RFC4271]) <xref target="RFC4271"/>)
	and BGP-LU (SAFI 4, <xref target="RFC4798"/>). However, if such
	infrastructure routes are also distributed in these SAFIs, a router
	may receive both BGP CAR SAFI paths and IP/LU SAFI paths. By default, the
	CAR SAFI transport path is preferred over the BGP IP or BGP-LU SAFI path.
      </t>
      <t>A BGP transport CAR speaker that supports packet forwarding lookup based on the
      IPv6 prefix route (such as a BR) will set itself as next hop while advertising the
      route to peers. It will also install the IPv6 route into forwarding with the
      received next hop and/or encapsulation. If such a transit router does not support
      this route type, it will not install this route and will not set itself as next hop,
      hence hop;
      hence, it will not propagate the route any further.
      </t>
    </section>

    <section title="VPN CAR">
    <section>
      <name>VPN CAR</name>
      <t>This section illustrates the extension of BGP CAR to address the VPN
      intent-aware routing requirement stated in Section 6.1.2 of <xref target="I-D.hr-spring-intentaware-routing-using-color"/>.
      target="I-D.hr-spring-intentaware-routing-using-color"
      sectionFormat="of" section="6.1.2"/>. The examples use MPLS, but other
      transport types can also be used (e.g., SRv6). </t>

      <figure> SRv6).</t>

      <artwork><![CDATA[
CE1 -------------- PE1 -------------------- PE2 -------------- CE2 - V
]]></artwork>
      </figure>
      <t>
        <list style="symbols">

      <ul spacing="normal">
        <li>
          <t>BGP CAR SAFI is enabled on CE1-PE1 and PE2-CE2 sessions</t> sessions.</t>
        </li>
        <li>
          <t>BGP VPN CAR SAFI is enabled between PE1 and PE2</t> PE2.</t>
        </li>
<!--[rfced] Will it be clear to the reader what "color CP" and "color CPT"
mean here? If not, please provide text to explain. We note that some other
examples use "color C1" and "color C2".

Current:
   *  Provider publishes to customer that intent 'low-delay' is mapped
      to color CP on its inbound peering links.

   *  Within its infrastructure, provider maps intent 'low-delay' to
      color CPT.
-->
        <li>
          <t>Provider publishes to customer that intent 'low-delay' is mapped to color CP on its
        inbound peering links</t> links.</t>
        </li>
        <li>
          <t>Within its infrastructure, Provider provider maps intent 'low-delay' to color CPT</t> CPT.</t>
        </li>
        <li>
          <t>On CE1 and CE2, intent 'low-delay' is mapped to CC</t>
        </list>
      </t> CC.</t>
        </li>
      </ul>
      <t>(V, CC) is a Color-Aware color-aware route originated by CE2</t>
      <figure>
        <artwork><![CDATA[ CE2.</t>

<!-- [rfced] FYI - Section 9: We have updated this artwork (containing
numbered items) to to an ordered list. Please review. If you prefer to
have the "[(V, CC)" portions aligned vertically, we can insert line
breaks (as shown in 'Perhaps' below). For example (showing only two items):

Original:
   1.   CE2 sends to PE2     : [(V, CC), Label L1] via CE2 with LCM-EC (CP)
                                            as per peering agreement
   2.   PE2 installs in VRF A: [(V, CC), L1]       via CE2
                                            which resolves on (CE2, CP)
                                            or connected OIF
   3

Current:
   1.  CE2 sends to PE2: [(V, CC), Label L1] via CE2 with LCM-EC (CP) as
       per peering agreement.

   2.  PE2 installs in VRF A: [(V, CC), L1] via CE2, which resolves on
       (CE2, CP) or connected Outgoing Interface (OIF).

Perhaps:
   1.  CE2 sends to PE2:
       [(V, CC), Label L1] via CE2 with LCM-EC (CP) as per peering
       agreement.

   2.  PE2 installs in VRF A:
       [(V, CC), L1] via CE2, which resolves on (CE2, CP) or connected
       Outgoing Interface (OIF).
-->

<ol>
  <li>CE2 sends to PE2: [(V, CC), Label L1] via CE2 with LCM-EC (CP) as per peering agreement.</li>
  <li>PE2 installs in VRF A: [(V, CC), L1] via CE2, which resolves on (CE2, CP) or connected Outgoing Interface (OIF).</li>
  <li>PE2 allocates VPN Label L2 and programs swap entry for (V, CC)
   4.   PE2 CC).</li>
  <li>PE2 sends to PE1     : PE1: [(RD, V, CC), L2] via PE2, LCM-EC(CP) LCM-EC (CP) with regular Color-EC (CPT)
   5.   PE1 (CPT).</li>
  <li>PE1 installs in VRF A: [(V, CC), L2] via (PE2, CPT) steered on (PE2, CPT)
   6.   PE1 CPT).</li>
  <li>PE1 allocates Label L3 and programs swap entry for (V, CC)
   7.   PE1 CC).</li>
  <li>PE1 sends to CE1     : CE1: [(V, CC), L3] via PE1 after removing LCM-EC through route-policy
   8.   CE1 installs         : route policy.</li>
  <li>CE1 installs: [(V, CC), L3] via PE1 PE1, which resolves on (PE1, CC) or connected OIF
   9.   Label OIF.</li>
  <li>Label L3 is installed as the imposition label for (V, CC)
        ]]></artwork>
      </figure> CC).</li>
</ol>

      <t>VPN CAR distribution for (RD, V, CC) requires a new SAFI that follows the
      same VPN semantics as defined in <xref target="RFC4364"/> and also supports the
      distribution of routes with the CAR NLRI and associated non-key TLVs defined in
      <xref target="ColorFamily"/> of this document. </t>
      <t>Procedures defined in <xref target="RFC4364"/> and <xref target="RFC4659"/> apply to
      VPN CAR SAFI.
      Further, all CAR SAFI procedures described in <xref target="CARSAFI"/> above apply to
      CAR SAFI enabled within a VRF. Since CE and PE are typically in different administrative
      domains, LCM-EC is attached to CAR routes.</t>
      <t>VPN CAR SAFI routes follow color based color-based steering techniques as described in
      <xref target="STEERING"/> and illustrated in the example above.</t>

<!-- [rfced] Is citing Section 9 of RFC 4364 correct here? We note "L3VPN"
does not appear in RFC 4364. ("L3" appears only once in Section 14;
zero instances of "layer 3".)

Original:
   Example use-cases are intent-aware L3VPN CsC ([RFC4364] Section 9) and SRv6
   over a provider network.

Current:
   Example use cases are intent-aware L3VPN Carriers' Carriers (Section 9 of
   [RFC4364]) and SRv6 over a provider network.
-->

      <t>VPN CAR SAFI routes may also be advertised with a specific BGP next hop per color,
      with a TEA or Tunnel Encapsulation EC EC, and follow the procedures of [RFC9012]
      Section 6.</t> <xref target="RFC9012" sectionFormat="of" section="6"/>.</t>
      <t>CAR routes distributed in VPN CAR SAFI are infrastructure routes advertised by
      CEs in different customer VRFs on a PE. Example use-cases use cases are intent-aware
      L3VPN CsC Carriers' Carriers (<xref target="RFC4364"/> Section 9) target="RFC4364" sectionFormat="of" section="9"/>) and SRv6 over a provider
      network .
      network.  The VPN RD distinguishes CAR routes of different customers being
      advertised by the PE.</t>
      <section anchor="VPNColorFamily" title="Format anchor="VPNColorFamily">
        <name>Format and Encoding"> Encoding</name>
        <t>BGP VPN CAR SAFI leverages BGP multi-protocol extensions [RFC4760] <xref
        target="RFC4760"/> and uses the MP_REACH_NLRI and MP_UNREACH_NLRI
        attributes for route updates within SAFI value 84 along with AFI 1 for
        IPv4 VPN CAR prefixes and AFI 2 for IPv6 VPN CAR prefixes.</t>
        <t>BGP speakers MUST <bcp14>MUST</bcp14> use the BGP Capabilities Advertisement
        to ensure support for processing of BGP VPN CAR updates.  This is done
        as specified in [RFC4760], <xref target="RFC4760"/>, by using capability code 1
        (multi-protocol BGP), with AFI 1 and 2 (as required) and SAFI 84.</t>
        <t>The Next Hop network address field in the MP_REACH_NLRI may contain
        either a VPN-IPv4 or a VPN-IPv6 address with 8-octet RD set to zero,
        independent of AFI. If the next hop length is 12, then the next hop is
        a VPN-IPv4 address with an RD of 0 constructed as per [RFC4364]. <xref
        target="RFC4364"/>. If the next hop length is 24 or 48, then the next
        hop is a VPN-IPv6 address constructed as per section 3.2.1.1 of [RFC4659].</t> <xref target="RFC4659"
        sectionFormat="of" section="3.2.1.1"/>.</t>
        <section anchor="VPNCARNLRITYPE1" title="VPN anchor="VPNCARNLRITYPE1">
          <name>VPN CAR (E, C) NLRI Type"> Type</name>
          <t>VPN CAR Type-1 (E, C) NLRI with RD has the format shown below</t>

        <figure align="center"> below:</t>
          <artwork align="left"><![CDATA[
 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  NLRI Length  |  Key Length   |   NLRI Type   |Prefix Length  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|               Route Distinguisher                             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|               Route Distinguisher                             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|               IP Prefix (variable)                           //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|               Color (4 octets)                                |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>

<t>Followed
          <t>It is followed by optional Non-Key TLVs encoded as per <xref target="NLRITLVs"/></t> target="NLRITLVs"/>.</t>
          <t>where:</t>
            <t>All
          <t>all fields are encoded as per <xref target="NLRITYPE1"/> with the following changes:</t>
            <list style="symbols">
            <t>Key Length: This
          <dl spacing="normal" newline="false">
            <dt>Key Length:</dt><dd>This length indicates the total length comprised of the
            RD, Prefix Length field, IP Prefix field, and the Color field.</t>

            <t>Route Distinguisher: An field.</dd>
            <dt>Route Distinguisher:</dt><dd>An 8-octet field encoded
            according to <xref target="RFC4364"/>.
            </t>
            <t>Type-Specific target="RFC4364"/>.</dd>
            <dt>Type-Specific Non-Key TLVs: TLVs:</dt><dd>The Label TLV, Label Index TLV TLV,
            and SRv6 SID TLV (<xref target="NLRITLVs"/>) may be associated
            with the VPN CAR (E, C) NLRI type.</t>
            </list> type.</dd>
          </dl>
        </section>
        <section anchor="VPNCARNLRITYPE2"
       title="VPN anchor="VPNCARNLRITYPE2">
          <name>VPN CAR IP Prefix NLRI Type">
        <figure align="center"> Type</name>
          <artwork align="left"><![CDATA[
 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  NLRI Length  |  Key Length   |   NLRI Type   |Prefix Length  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|               Route Distinguisher                             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|               Route Distinguisher                             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|               IP Prefix (variable)                           //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>

<t>Followed
          <t>It is followed by optional Non-Key TLVs encoded as per <xref target="NLRITLVs"/></t> target="NLRITLVs"/>.</t>
          <t>where:</t>
            <t>All
          <t>all fields are encoded as per <xref target="NLRITYPE2"/> with the following changes:</t>
            <list style="symbols">
            <t>Key Length: This
          <dl spacing="normal" newline="false">
            <dt>Key Length:</dt><dd>This length indicates the total length comprised of the
            RD, Prefix Length field field, and IP Prefix field.</t>
            <t>Route Distinguisher: 8 octet field.</dd>
            <dt>Route Distinguisher:</dt><dd>An 8-octet field encoded according
            to <xref target="RFC4364"/>.
            </t>
            <t>Type-Specific target="RFC4364"/>.</dd>
            <dt>Type-Specific Non-Key TLVs: TLVs:</dt><dd>The Label TLV, Label Index TLV TLV,
            and SRv6 SID TLV (<xref target="NLRITLVs"/>) may be associated
            with the VPN CAR IP Prefix NLRI type.</t>
            </list>
      <t>Error type.</dd>
          </dl>
          <t>The error handling specified in <xref target="Fault"/> also applies to VPN CAR SAFI.</t>
        </section>
      </section>
    </section>
    <section anchor="IANA" title="IANA Considerations">
      <section title="BGP anchor="IANA">
      <name>IANA Considerations</name>
      <section>
        <name>BGP CAR SAFIs"> SAFIs</name>
        <t>IANA has assigned SAFI value 83 (BGP CAR) and SAFI value
      84 (BGP VPN CAR) from the "SAFI Values" sub-registry under registry in the "Subsequent
      Address Family Identifiers (SAFI) Parameters" registry group with this document as a
      reference.</t>
      </section>
      <section anchor="NLRITYPESREG"
               title="BGP anchor="NLRITYPESREG">
        <name>"BGP CAR NLRI Types Registry"> Types" Registry</name>
        <t>IANA is requested to create has created a "BGP CAR NLRI Types"
        registry in the "Border Gateway Protocol (BGP) Parameters"
        registry group with this document as a reference. The registry is for
        assignment of the one octet sized code-points 1-octet code points for BGP CAR NLRI types
        and is populated with the values shown below:</t>

        <figure align="center">
          <artwork align="center"><![CDATA[    Type      NLRI Type                  Reference
-----------------------------------------------------------------
     0        Reserved               [This document]
     1        Color-Aware

<table>
<thead>
<tr><th>Type</th><th>NLRI Type</th><th>Reference</th></tr>
</thead>
<tbody>
<tr><td>0</td><td>Reserved</td><td>RFC 9871</td></tr>
<tr><td>1</td><td>Color-Aware Route NLRI [This document]
     2        IP NLRI</td><td>RFC 9871</td></tr>
<tr><td>2</td><td>IP Prefix NLRI         [This document]
    3-255     Unassigned

]]></artwork>
        </figure> NLRI</td><td>RFC 9871</td></tr>
<tr><td>3-255</td><td colspan="2">Unassigned</td></tr>
</tbody>
</table>
        <t>Allocations within the registry are to be made under with the
        "Specification Required" policy as specified in <xref
        target="RFC8126"/>) target="RFC8126"/> and in <xref target="DE-Guidance"/>.</t>
      </section>
      <section anchor="TLVTYPESREG"
               title="BGP anchor="TLVTYPESREG">
        <name>"BGP CAR NLRI TLV Registry"> TLV" Registry</name>
        <t>IANA is requested to create has created a "BGP CAR NLRI TLV Types"
        registry in the "Border Gateway Protocol (BGP) Parameters"
        registry group with this document as a reference. The registry is for
        assignment of the 6-bits sized code-points 6-bit code points for BGP CAR NLRI non-key
        TLV types and is populated with the values shown below:</t>

        <figure align="center">
          <artwork align="center"><![CDATA[    Type      NLRI TLV Type                  Reference
-----------------------------------------------------------------
     0        Reserved                   [This document]
     1        Label

<table>
<thead>
<tr><th>Type</th><th>NLRI TLV                  [This document]
     2        Label Type</th><th>Reference</th></tr>
</thead>
<tbody>
<tr><td>0</td><td>Reserved</td><td>RFC 9871</td></tr>
<tr><td>1</td><td>Label TLV</td><td>RFC 9871</td></tr>
<tr><td>2</td><td>Label Index TLV            [This document]
     3        SRv6 TLV</td><td>RFC 9871</td></tr>
<tr><td>3</td><td>SRv6 SID TLV               [This document]
    4-64      Unassigned

]]></artwork>
        </figure> TLV</td><td>RFC 9871</td></tr>
<tr><td>4-64</td><td colspan="2">Unassigned</td></tr>
</tbody>
</table>
        <t>Allocations within the registry are to be made under with the
        "Specification Required" policy as specified in <xref
        target="RFC8126"/>) target="RFC8126"/> and in <xref target="DE-Guidance"/>.</t>
        <t>For a new TLV to be used with existing NLRI Types, documentation of the NLRI Types
        must be updated.</t>
      </section>
      <section anchor="DE-Guidance" title="Guidance anchor="DE-Guidance">
        <name>Guidance for Designated Experts"> Experts</name>
        <t>In all cases of review by the Designated Expert (DE) described
        here, the DE is expected to ascertain the existence of suitable
        documentation (a specification) as described in <xref
        target="RFC8126"/> for BGP the "BGP CAR NLRI Types Registry Types" registry and BGP the "BGP CAR NLRI TLV Registry.
        TLV" registry.
        </t>
        <t>
        The
        <t>The DE is also expected to check the clarity of purpose and use of
        the requested code points. Additionally, the DE must verify that any
        request for one of these code points has been made available for
        review and comment within the IETF: the DE will post the request to
        the IDR Working Group mailing list (or a successor mailing list
        designated by the IESG). The DE must ensure that any request for a
        code point does not conflict with work that is active or already
        published within the IETF.</t>
        <t>The DE is expected to confirm that the specification satisfies the
        requirements for Specification Required (RFC 8126 Section 4.6). the "Specification Required" policy (<xref
        target="RFC8126" sectionFormat="of" section="4.6"/>). In particular,
        as a reminder, the specification is required to be "permanent and
        readily available". The DE may assume that any document in the Internet Draft
        Internet-Draft or RFC repository satisfies the requirement for
        permanence and availability. In other cases, and in particular for any
        document not hosted by another standards development organization, the
        burden of proof of permanence falls on the applicant.
        </t>

        <section title="Additional evaluation criteria
        <section>
          <name>Additional Evaluation Criteria for the BGP "BGP CAR NLRI Types Registry">
          <list style="symbols"> Types" Registry</name>
          <ul spacing="normal">
            <li>
              <t>Check the interoperability between the new NLRI type and
              current NLRI types specified in this document for BGP CAR SAFIs
              (BGP CAR SAFI and VPN CAR SAFI), and any updates to this
              document.</t>
            </li>
            <li>
              <t>Check if the specification indicates which non-key TLVs are
              applicable for the new NLRI Type.</t>
          </list>
            </li>
          </ul>
        </section>

        <section title="Additional evaluation criteria
        <section>
          <name>Additional Evaluation Criteria for the BGP "BGP CAR NLRI TLV Registry">
          <list style="symbols"> TLV" Registry</name>
          <ul spacing="normal">
            <li>
              <t>Check the applicability of the new TLV for the BGP CAR NLRI Types defined.</t>
            </li>
            <li>
              <t>Check the T bit setting for the new TLV</t>
          </list> TLV.</t>
            </li>
          </ul>
        </section>
      </section>
      <section anchor="PROTOIDREG" title="BGP Extended-Community Registry"> anchor="PROTOIDREG">
        <name>"Border Gateway Protocol (BGP) Extended Communities" Registry</name>
        <t>IANA has assigned the sub-type 0x1b for "Local Color Mapping (LCM)"
        in the "Transitive Opaque Extended Community Sub-Types" registry located in the
        "Border Gateway Protocol (BGP) Extended Communities" registry group.</t>
      </section>
    </section>
    <section anchor="MANAGEOPER" title="Manageability anchor="MANAGEOPER">
      <name>Manageability and Operational Considerations"> Considerations</name>
      <t>Color assignments in a multi-domain network operating under a common
      or cooperating administrative control (i.e., a color domain) should be
      managed similar to transport layer IP addresses, and ensure a unique and
      non-conflicting color allocation across the different network domains in
      that color domain. This is a logical best practice in a single color or
      administrative domain, which is the most typical deployment
      scenario.</t>
      <t>When color-aware routes propagate across a color domain boundary,
      there is typically no need for color assignments to be identical in both
      color domains, since the IP prefix is unique in the inter-domain
      transport network. This unique IP prefix provides a unique and
      non-conflicting scope for the color in an (E, C) route. Co-ordination Coordination
      between the operators of the color domains is needed only to enable the
      color to be re-mapped into a local color (carried in the LCM-EC)
      assigned for the same intent in the receiving color domain.</t>
      <t>However, if networks under different administrative control establish
      a shared transport service between them, where the same transport
      service IP address is co-ordinated coordinated and shared among two (or more) color
           domains
      domain networks, then the color assignments associated with that shared
      IP address should also be co-ordinated coordinated to avoid any conflicts in either
      network (<xref target="SHAREDIP"/>).</t>
      <t>It should be noted that the color assignments coordination are is only
      necessary for routes specific to the shared service IP. Colors used for
      intra-domain or for inter-domain intents associated with unique IP
      addresses do not need any coordination.
      </t>
      <t>Extended communities (LCM-EC/Color-EC) carried in BGP CAR and Service service
      routes
 	    MUST NOT <bcp14>MUST NOT</bcp14> be filtered, otherwise the desired intent
      will not be achieved.
      </t>
    </section>
    <section anchor="SecurityConsiderations" title="Security Considerations"> anchor="SecurityConsiderations">
      <name>Security Considerations</name>
      <t>This document does not change the underlying security considerations
      and issues inherent in the existing BGP protocol, such as those
      described in <xref target="RFC4271"/> and <xref target="RFC4272"/>.</t>
      <t>This document defines a new BGP SAFI and related extensions to carry color
    aware
      color-aware routes and their associated attributes. The separate SAFI is
      expected to be explicitly configured by an operator. It is also expected
      that the necessary BGP route policy filtering is configured on this new
      SAFI to filter routing information distributed by the routers
      participating in this network, at appropriate points within and at the
      boundaries of this network.</t>
      <t>Also, given that this SAFI and these mechanisms can only be enabled
      through configuration of routers within an operator's network, standard
      security measures should be taken to restrict access to the management
      interface(s) of routers that implement these mechanisms.
      </t>
      <t>Additionally, BGP sessions SHOULD <bcp14>SHOULD</bcp14> be protected using the
      TCP Authentication Option <xref target="RFC5925"/> and the Generalized
      TTL Security Mechanism <xref target="RFC5082"/>. BGP Origin Validation origin validation
      <xref target="RFC6811"/> and BGPsec <xref target="RFC8205"/> could also
      be used with this SAFI.</t>
      <t>Since CAR SAFI is a separate BGP SAFI that carries transport or
      infrastructure routes for routers in the operator network, it provides
      automatic separation of infrastructure routes and the service routes
      that are carried in existing BGP SAFIs such as BGP IPv4/IPv6 (SAFI=1),
      and BGP-LU (SAFI=4) (e.g., 6PE [RFC4798]). <xref target="RFC4798"/>).  Using CAR
      SAFI thus provides better security (such as protection against route
      leaking) than would be obtained by distributing the infrastructure
      routes in existing SAFIs that also carry service routes.</t>
      <t>BGP CAR distributes label binding similar to <xref target="RFC8277"/> and
    hence target="RFC8277"/>;
      hence, its security considerations apply. </t>

    <t>
    In apply.</t>
      <t>In SR deployments, BGP CAR distributes infrastructure prefixes along
      with their SID information for both SR-MPLS and SRv6. These deployments
      are within an SR Domain [RFC8402] domain <xref target="RFC8402"/> and the security
      considerations of [RFC8402] <xref target="RFC8402"/> apply. Additionally, security
      considerations related to SRv6 deployments that are discussed in section 9.3 of [RFC9252] <xref
      section="9.3" sectionFormat="of" target="RFC9252"/> also apply.</t>
      <t>As <xref target="RFC4272"/> discusses, BGP is vulnerable to
      traffic-diversion attacks. This SAFI routes route adds a new means by which an
      attacker could cause the traffic to be diverted from its normal
      path. Potential consequences include "hijacking" of traffic (insertion
      of an undesired node in the path, which allows for inspection or
      modification of traffic, or avoidance of security controls) or denial of
      service (directing traffic to a node that doesn't desire to receive it).
      </t>
      <t>The restriction of the applicability of this SAFI to its intended well-defined scope
    and the use of techniques described above limit the likelihood of traffic diversions.</t>
    </section>

    <section anchor="Contributors" title="Contributors">
    <section anchor="COAUTH" title="Co-authors">
<t>
The following people gave substantial contributions to the content of this document and should be considered as coauthors:</t>
      <figure>
        <artwork><![CDATA[Clarence Filsfils
Cisco Systems
Belgium
Email: cfilsfil@cisco.com
        ]]></artwork>
      </figure>

      <figure>
        <artwork><![CDATA[Bruno Decraene
Orange
France
Email: bruno.decraene@orange.com
        ]]></artwork>
      </figure>

      <figure>
        <artwork><![CDATA[Luay Jalil
Verizon
USA
Email: luay.jalil@verizon.com
        ]]></artwork>
      </figure>

      <figure>
        <artwork><![CDATA[Yuanchao Su
Alibaba, Inc
Email: yitai.syc@alibaba-inc.com
        ]]></artwork>
      </figure>

      <figure>
        <artwork><![CDATA[Jim Uttaro
Individual
USA
Email: juttaro@ieee.org
        ]]></artwork>
      </figure>

      <figure>
        <artwork><![CDATA[Jim Guichard
Futurewei
USA
Email: james.n.guichard@futurewei.com
        ]]></artwork>
      </figure>

      <figure>
        <artwork><![CDATA[Ketan Talaulikar
Cisco Systems
India
Email: ketant.ietf@gmail.com
        ]]></artwork>
      </figure>

      <figure>
        <artwork><![CDATA[Keyur Patel
Arrcus, Inc
USA
Email: keyur@arrcus.com
        ]]></artwork>
      </figure>

      <figure>
        <artwork><![CDATA[Haibo Wang
Huawei Technologies
China
Email: rainsword.wang@huawei.com]]></artwork>
      </figure>

      <figure>
        <artwork><![CDATA[Jie Dong
Huawei Technologies
China
Email: jie.dong@huawei.com
        ]]></artwork>
      </figure>
    </section>
    <section anchor="CONTR" title="Additional Contributors">
      <figure>
        <artwork><![CDATA[Dirk Steinberg
Lapishills Consulting Limited
Germany
Email: dirk@lapishills.com
        ]]></artwork>
      </figure>

      <figure>
        <artwork><![CDATA[Israel Means
AT&T
USA
Email: im8327@att.com
        ]]></artwork>
      </figure>

      <figure>
        <artwork><![CDATA[Reza Rokui
Ciena
USA
Email: rrokui@ciena.com
        ]]></artwork>
      </figure>

    </section>
  </section>

    <section anchor="Acknowledgements" title="Acknowledgements">
      <t>
      The authors would like to acknowledge the invaluable contributions of many collaborators towards the BGP CAR
      solution and this document in providing input about use-cases, participating in brainstorming and mailing list
      discussions and in reviews of the solution and draft revisions. In addition to the contributors listed in
      <xref target="Contributors"/>, the authors would like to thank Robert Raszuk, Bin Wen, Chaitanya Yadlapalli,
      Satoru Matsushima, Moses Nagarajah, Gyan Mishra, Jorge Rabadan, Daniel Voyer, Stephane Litkowski, Hannes Gredler,
      Jose Liste, Jakub Horn, Brent Foster, Dave Smith, Jiri Chaloupka, Miya Kohno, Kamran Raza, Zafar Ali, Xing Jiang,
      Oleksander Nestorov, Peter Psenak, Kaliraj Vairavakkalai, Natrajan Venkataraman, Srihari Sangli, Ran Chen and
      Jingrong Xie. </t>

      <t>The authors also appreciate the detailed reviews and astute suggestions provided by Sue Hares (as document
      shepherd), Jeff Haas, Yingzhen Qu and John Scudder that have greatly improved the document.</t>
    </section>

  </middle>
  <back>
    <references title="Normative References">

<displayreference target="I-D.hr-spring-intentaware-routing-using-color" to="INTENT-AWARE"/>
<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.2119.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8174.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.4360.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4760.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8669.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7311.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.4684.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7606.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.8986.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8126.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9350.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.9256.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2545.xml"/>
      </references>

    <references title="Informative References">
      <references>
        <name>Informative References</name>

<!-- [I-D.hr-spring-intentaware-routing-using-color]
draft-hr-spring-intentaware-routing-using-color-04
IESG State: I-D Exists as of 04/18/25
-->
      <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]
draft-ietf-spring-srv6-mpls-interworking-00
IESG State: I-D Exists as of 04/18/25
-->
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-spring-srv6-mpls-interworking.xml"/>

<!-- [I-D.ietf-idr-cpr] is now RFC 9723. -->

        <xi:include href="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-idr-cpr.xml"/> href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9723.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4364.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4659.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.4271.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7911.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5462.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9315.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8205.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5925.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6811.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5082.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4798.xml"/>
      </references>
    </references>

    <section anchor="SSTEERINGAPNDX" title="Illustrations anchor="SSTEERINGAPNDX">
      <name>Illustrations of Service Steering"> Steering</name>
      <t>The following sub-sections illustrate example scenarios of Colored
      Service Route Steering colored
      service route steering over E2E end-to-end (E2E) BGP CAR paths, resolving over different
      intra-domain mechanisms.</t>
      <t>The examples in this section use MPLS/SR for the transport data plane. Scenarios
      related to SRv6 encapsulation are in a section below.
      </t>
      <section anchor="SFAUSECASE"
      title="E2E anchor="SFAUSECASE">
        <name>E2E BGP transport Transport CAR intent realized using Intent Realized Using IGP Flex-Algo"> Flex-Algo</name>
        <figure anchor="FAUSECASE" title="BGP anchor="FAUSECASE">
          <name>BGP FA Aware transport Transport CAR path"> Path</name>
          <artwork><![CDATA[
                              RD:V/v via E2
          +-----+             vpn label: 30030       +-----+
   ...... |S-RR1| <..................................|S-RR2| <.......
   :      +-----+             Color C1               +-----+        :
   :                                                                :
   :                                                                :
   :                                                                :
+-:-----------------------+----------------------+------------------:--+
| :                       |                      |                  :  |
| :                       |                      |                  :  |
| :   (E2,C1) via 121     |   (E2,C1) via 231    | (E2,C1)via E2    :  |
| :   L=168002,AIGP=110 +---+ L=168002,AIGP=10 +---+ L=0x3,LI=8002  :  |
| : |-------------------|121|<-----------------|231|<-------------| :  |
| : V LI=8002           +---+ LI=8002          +---+              | :  |
|----+                    |                      |               +-----|
| E1 |                    |                      |               | E2  |
|----+(E2,C1) via 122     |   (E2,C1) via 232    |  (E2,C1)via E2+-----|
|   ^ L=168002,AIGP=210 +---+ L=168002,AIGP=20 +---+ L=0x3        |    |
|   |----------------   |122|<-----------------|232|<-------------|    |
|     LI=8002           +---+ LI=8002          +---+ LI=8002           |
|                         |                      |                     |
|         IS-IS SR        |      IS-IS SR        |     IS-IS SR        |
|         FA 128          |      FA 128          |     FA 128          |
+-------------------------+----------------------+---------------------+
 iPE                     iABR                   eABR               ePE

         ---------direction of traffic-------->
+------+                  +------+
|168121|                  |168231|
+------+                  +------+
+------+                  +------+                 +------+
|168002|                  |168002|                 |168002|
+------+                  +------+                 +------+
+------+                  +------+                 +------+
|30030 |                  |30030 |                 |30030 |
+------+                  +------+                 +------+
]]></artwork>
        </figure>
        <t>Use case: Provide end to end end-to-end intent for service flows.
          <list style="symbols"> flows.</t>
        <ul spacing="normal">
          <li>
            <t>The following description applies to the reference topology above:
            <list style="symbols"> above:</t>
            <ul spacing="normal">
              <li>
                <t>IGP FA 128 is running in each domain, and mapped to Color color C1.</t>
              </li>
              <li>
                <t>Egress PE E2 advertises a VPN route RD:V/v colored with Color-EC C1
            to steer traffic to BGP transport CAR (E2, C1).
            VPN route propagates via service RRs to ingress PE E1.</t>
              </li>
              <li>
                <t>BGP CAR route (E2, C1) with next hop, label index index, and
                label as shown above are advertised through border routers in
                each domain.  When a an RR is used in the domain, ADD-PATH is
                enabled to advertise multiple available paths.</t>
              </li>
              <li>
                <t>On each BGP hop, the (E2, C1) route's next hop is resolved over IGP FA 128
            of the domain. The AIGP attribute influences the BGP CAR route best path decision as
            per <xref target="RFC7311"/>. The BGP CAR label swap entry is installed that goes
            over FA 128 LSP to next hop providing intent in each IGP domain. The AIGP
            metric should be updated to reflect FA 128 metric to next hop.</t>
              </li>
              <li>
                <t>Ingress PE E1 learns CAR route (E2, C1). It steers colored
            VPN route RD:V/v into (E2, C1).</t>
            </list>
          </t>
              </li>
            </ul>
          </li>
          <li>
            <t>Important:
            <list style="symbols">
            </t>
            <ul spacing="normal">
              <li>
                <t>IGP FA 128 top label provides intent within each domain.</t>
              </li>
              <li>
                <t>BGP CAR label (e.g. (e.g., 168002) carries end to end end-to-end
                intent. Thus Thus, it stitches intent over intra-domain FA 128.</t>
            </list>
          </t>
          </list>
        </t>
              </li>
            </ul>
          </li>
        </ul>
      </section>

      <section title="E2E
      <section>
        <name>E2E BGP transport Transport CAR intent realized using Intent Realized Using SR Policy"> Policy</name>
        <figure anchor="SRPUSECASE" title="BGP anchor="SRPUSECASE">
          <name>BGP SR policy Policy Aware transport Transport CAR path"> Path</name>
          <artwork><![CDATA[
                              RD:1/8 via E2
          +-----+             vpn label: 30030       +-----+
   ...... |S-RR1| <..................................|S-RR2| <......
   :      +-----+             Color C1               +-----+        :
   :                                                                :
   :                                                                :
   :                                                                :
+-:-----------------------+----------------------+------------------:-+
| :                       |                      |                  : |
| :                       |                      |                  : |
| :  <-(E2,C1) via 121    |   <-(E2,C1) via 231  | <-(E2,C1)via E2  : |
| :                     +---+                  +---+                : |
| :  ------------------>|121|----------------->|231|--------------| : |
| : | SR policy(C1,121) +---+ SR policy(C1,231)+---+ SR policy    v : |
|----+                    |                      |   (C1,E2)      +---|
| E1 |                    |                      |                |E2 |
|----+ <-(E2,C1) via 122  |  (E2,C1) via 232     | <-(E2,C1)via E2+---|
|   |                   +---+                  +---+               ^  |
|    ------------------>|122|----------------->|232|---------------|  |
|    SR policy(C1,122)  +---+ SR policy(C1,232)+---+ SR policy(C1,E2) |
|                         |                      |                    |
|                         |                      |                    |
|         IS-IS SR        |      IS-IS SR        |     IS-IS SR       |
+-------------------------+----------------------+--------------------+
 iPE                     iABR                   eABR              ePE

        ---------direction of traffic-------->
+------+                  +------+
|  S1  |                  |  S2  |
+------+                  +------+
+------+                  +------+                 +------+
|160121|                  |160231|                 |  S3  |
+------+                  +------+                 +------+
+------+                  +------+                 +------+
|168002|                  |168002|                 |168002|
+------+                  +------+                 +------+
+------+                  +------+                 +------+
|30030 |                  |30030 |                 |30030 |
+------+                  +------+                 +------+
]]></artwork>
        </figure>
        <t>Use case: Provide end to end end-to-end intent for service flows.
          <list style="symbols"> flows.</t>
        <ul spacing="normal">
          <li>
            <t>The following description applies to the reference topology above:
            <list style="symbols">
            </t>
            <ul spacing="normal">
              <li>
                <t>An SR Policy provides intra-domain intent. The following are the example SID lists
            that are realized from SR policies in each domain and correspond to the label stack
            shown in <xref target="SRPUSECASE"/>
              <list> target="SRPUSECASE"/>:
                </t>
                <ul spacing="normal">
                  <li>
                    <t>SR policy (C1,121) (C1, 121) segments &lt;S1, 121&gt;,</t>
                  </li>
                  <li>
                    <t>SR policy (C1,231) (C1, 231) segments &lt;S2, 231&gt;, and</t>
                  </li>
                  <li>
                    <t>SR policy (C1,E2) (C1, E2) segments &lt;S3, E2&gt;.</t>
              </list>
            </t>
                  </li>
                </ul>
              </li>
              <li>
                <t>Egress PE E2 advertises a VPN route RD:V/v colored with Color-EC C1
            to steer traffic to BGP transport CAR (E2, C1).
            VPN route propagates via service RRs to ingress PE E1.</t>
              </li>
              <li>
                <t>BGP CAR route (E2, C1) with next hop, label index index, and label
                as shown above are advertised through border routers in each
                domain.  When a an RR is used in the domain, ADD-PATH is enabled
                to advertise multiple available paths.</t>
              </li>
              <li>
                <t>On each BGP hop, the CAR route (E2, C1) next hop is resolved over an
            SR policy (C1, next hop). The BGP CAR label swap entry is installed that goes
            over SR policy segment list.</t>
              </li>
              <li>
                <t>Ingress PE E1 learns CAR route (E2, C1). It steers colored
            VPN route RD:V/v into (E2, C1).
                </t>
            </list>
          </t>
              </li>
            </ul>
          </li>
          <li>
            <t>Important:
            <list style="symbols">
            </t>
            <ul spacing="normal">
              <li>
                <t>SR policy provides intent within each domain.</t>
              </li>
              <li>
                <t>BGP CAR label (e.g. (e.g., 168002) carries end to end end-to-end
                intent. Thus Thus, it stitches intent over intra-domain SR
                policies.</t>
            </list>
          </t>
          </list>
        </t>
              </li>
            </ul>
          </li>
        </ul>
      </section>
      <section anchor="SHDFAUSECASE"
      title="BGP transport anchor="SHDFAUSECASE">
        <name>BGP Transport CAR intent realized Intent Realized in a section Section of the network">
        <section title="Provide intent Network</name>
        <section>
          <name>Provide Intent for service flows only Service Flows Only in core domain
        running Core Domain Running IS-IS Flex-Algo"> Flex-Algo</name>
          <figure anchor="HDFAUSECASE" title="BGP anchor="HDFAUSECASE">
            <name>BGP Hybrid Flex-Algo Aware transport Transport CAR path"> Path</name>
            <artwork><![CDATA[
                              RD:1/8 via E2
          +-----+             vpn label: 30030       +-----+
   ...... |S-RR1| <..................................|S-RR2| <.......
   :      +-----+             Color C1               +-----+        :
   :                                                                :
   :                                                                :
   :                                                                :
+-:-----------------------+----------------------+------------------:--+
| :                       |                      |                  :  |
| :                       |                      |                  :  |
| :   (E2,C1) via 121     |  (E2,C1) via 231     | (E2,C1) via E2   :  |
| :   L=168002,AIGP=1110+---+L=168002,AIGP=1010+---+ L=0x3          :  |
| : |-------------------|121|<-----------------|231|<-------------| :  |
| : V LI=8002           +---+ LI=8002          +---+              | :  |
|----+                    |                      |               +-----|
| E1 |                    |                      |               | E2  |
|----+(E2,C1) via 122     |  (E2,C1) via 232     | (E2,C1) via E2+-----|
|   ^ L=168002,AIGP=1210+---+L=168002,AIGP=1020+---+ L=0x3        |    |
|   |----------------   |122|<-----------------|232|<-------------|    |
|     LI=8002           +---+ LI=8002          +---+                   |
|                         |                      |                     |
|         IS-IS SR        |      IS-IS SR        |     IS-IS SR        |
|         Algo 0          |      Flex-Algo 128   |     Algo 0          |
|         Access          |      Core            |     Access          |
+-------------------------+----------------------+---------------------+
iPE                     iABR                    eABR                ePE

         ---------direction of traffic-------->
+------+                  +------+
|160121|                  |168231|
+------+                  +------+
+------+                  +------+                 +------+
|168002|                  |168002|                 |160002|
+------+                  +------+                 +------+
+------+                  +------+                 +------+
|30030 |                  |30030 |                 |30030 |
+------+                  +------+                 +------+
]]></artwork>
          </figure>
          <t>
            <list style="symbols">
          <ul spacing="normal">
            <li>
              <t>The following description applies to the reference topology above:
              <list style="symbols">
              </t>
              <ul spacing="normal">
                <li>
                  <t>IGP FA 128 is only enabled in Core (e.g. core (e.g., WAN network),
                  mapped to C1.  Access network domain only has Base Algo
                  0.</t>
                </li>
                <li>
                  <t>Egress PE E2 advertises a VPN route RD:V/v colored with Color-EC C1
              to steer traffic via BGP transport CAR (E2, C1).
              VPN route propagates via service RRs to ingress PE E1.</t>
                </li>
                <li>
                  <t>BGP CAR route (E2, C1) with next hop, label index index, and label as
              shown above are advertised through border routers in each domain.
              When a an RR is used in the domain, ADD-PATH is enabled to advertise multiple
              available paths.</t>
                </li>
                <li>
                  <t>Local policy on 231 and 232 maps intent C1 to resolve CAR
                  route next hop over IGP Base Algo 0 in right access
                  domain. The BGP CAR label swap entry is installed that goes
                  over Base Algo 0 LSP to next hop. Updates AIGP metric is updated to
                  reflect Base Algo 0 metric to next hop with an additional
                  penalty (+1000).</t>
                </li>
                <li>
                  <t>On 121 and 122, CAR route (E2, C1) next hop learnt from
                  Core domain is resolved over IGP FA 128. The BGP CAR label
                  swap entry is installed that goes over FA 128 LSP to next
                  hop providing intent in Core IGP domain.</t>
                </li>
                <li>
                  <t>Ingress PE E1 learns CAR route (E2, C1). It maps intent
                  C1 to resolve CAR route next hop over IGP Base Algo 0. It
                  steers colored VPN route RD:V/v via (E2, C1)</t>
              </list>
            </t> C1).</t>
                </li>
              </ul>
            </li>
            <li>
              <t>Important:
              <list style="symbols">
              </t>
              <ul spacing="normal">
                <li>
                  <t>IGP Flex-Algo 128 top label provides intent in Core domain.</t>
                </li>
                <li>
                  <t>BGP CAR label (e.g. (e.g., 168002) carries intent from PEs PEs, which is
              realized in core Core domain.</t>
              </list>
            </t>
            </list>
          </t>
                </li>
              </ul>
            </li>
          </ul>
        </section>
        <section anchor="COREDOMAINTE"
        title="Provide intent anchor="COREDOMAINTE">
          <name>Provide Intent for service flows only Service Flows Only in core domain Core Domain over TE
        tunnel mesh"> Tunnel Mesh</name>
          <figure anchor="HRSVPDFAUSECASE" title="BGP anchor="HRSVPDFAUSECASE">
            <name>BGP CAR over TE tunnel mesh Tunnel Mesh in core network"> Core Network</name>
            <artwork><![CDATA[
                     RD:1/8 via E2
          +-----+         vpn label: 30030           +-----+
   ...... |S-RR1| <..................................|S-RR2| <.......
   :      +-----+             Color C1               +-----+        :
   :                                                                :
   :                                                                :
   :                                                                :
 +-:-----------------------+----------------------+-----------------:-+
 | :                       |                      |                 : |
 | :                       |                      |                 : |
 | :   (E2,C1) via 121     |  (E2,C1) via 231     | (E2,C1) via E2  : |
 | :   L=242003,AIGP=1110+---+L=242002,AIGP=1010+---+ L=0x3         : |
 | : |-------------------|121|<-----------------|231|<-------------|: |
 | : V                   +---+ TE tunnel(231)   +---+              |: |
 |----+                    |                      |               +---|
 | E1 |                    |                      |               |E2 |
 |----+(E2,C1) via 122     |  (E2,C1) via 232     | (E2,C1) via E2+---|
 |   ^ L=242004,AIGP=1210+---+L=242001,AIGP=1020+---+ L=0x3        |  |
 |   |----------------   |122|<-----------------|232|<-------------|  |
 |                       +---+ TE tunnel(232)   +---+                 |
 |                         |                      |                   |
 |                         |                      |                   |
 |         IS-IS/LDP       |      IS-IS/RSVP-TE   |     IS-IS/LDP     |
 |         Access 0        |      Core            |     Access 1      |
 +-------------------------+----------------------+-------------------+
  iPE                    iABR                   eABR               ePE

             ---------direction of traffic-------->
     +------+                  +------+
     |240121|                  |241231|
     +------+                  +------+
     +------+                  +------+                 +------+
     |242003|                  |242002|                 |240002|
     +------+                  +------+                 +------+
     +------+                  +------+                 +------+
     |30030 |                  |30030 |                 |30030 |
     +------+                  +------+                 +------+
]]></artwork>
          </figure>
          <t>
            <list style="symbols">
          <ul spacing="normal">
            <li>
              <t>The following description applies to the reference topology above:
              <list style="symbols">
              </t>
              <ul spacing="normal">
                <li>
                  <t>RSVP-TE MPLS tunnel mesh is configured only in core (e.g.
                  (e.g., WAN network).  Access only has IS-IS/LDP. (Figure (The figure
                  does not show all TE tunnels).</t> tunnels.)</t>
                </li>
                <li>
                  <t>Egress PE E2 advertises a VPN route RD:V/v colored with
                  Color-EC C1 to steer traffic via BGP transport CAR (E2,
                  C1). VPN route propagates via service RRs to ingress PE
                  E1.</t>
                </li>
                <li>
                  <t>BGP CAR route (E2, C1) with next hops and labels as
 	          shown above is advertised through border routers in each
 	          domain.  When a an RR is used in the domain, ADD-PATH is enabled
 	          to advertise multiple available paths.</t>
                </li>
                <li>
                  <t>Local policy on 231 and 232 maps intent C1 to resolve CAR route
 	          next hop over best-effort LDP LSP in access domain 1.  The BGP CAR
 	          label swap entry is installed that goes over LDP LSP to
 	          next hop. AIGP metric is updated to reflect best-effort metric to next hop
 	          with an additional penalty (+1000).</t>
                </li>
                <li>
                  <t>Local policy on 121 and 122 maps intent C1 to resolve CAR route
 	          next hop in Core domain over RSVP-TE tunnels. The BGP CAR label swap entry is
 	          installed that goes over a TE tunnel to next hop providing intent in Core
 	          domain. AIGP metric is updated to reflect TE tunnel metric.</t>
                </li>
                <li>
                  <t>Ingress PE E1 learns CAR route (E2, C1). It maps intent C1 to
 	          resolve CAR route's next hop over best-effort LDP LSP in Access access domain 0. It
 	          steers colored VPN route RD:V/v via (E2, C1).</t>
              </list>
            </t>

            <t>Important:
              <list style="symbols">
                </li>
              </ul>
            </li>
            <li>
              <t>Important:</t>
              <ul spacing="normal">
                <li>
                  <t>RSVP-TE tunnel LSP provides intent in Core domain.</t>
                </li>
                <li>
                  <t>Dynamic BGP CAR label carries intent from PEs PEs, which is
 	          realized in core Core domain by resolution via RSVP-TE tunnel.</t>
              </list>
            </t>
            </list>
          </t>
                </li>
              </ul>
            </li>
          </ul>
        </section>
      </section>

      <section title="Transit network domains that do not support CAR">
        <t>
          <list style="symbols">
      <section>
        <name>Transit Network Domains That Do Not Support CAR</name>
        <ul spacing="normal">
          <li>
            <t>In a brownfield deployment, color-aware paths between two PEs
            may need to go through a transit domain that does not support CAR.
            Examples of such a brownfield network include an MPLS LDP network
            with IGP best-effort, or a BGP-LU based multi-domain network. network based on BGP-LU. An MPLS
            LDP network with best-effort IGP can adopt the above scheme in Section A.3.
            <xref target="SHDFAUSECASE"/>. Below is the example scenario for
            BGP LU.</t>
          </li>
          <li>
            <t>Reference topology: topology:</t>

            <figure anchor="TRANSITNOCAR" title="BGP anchor="TRANSITNOCAR">
              <name>BGP CAR not supported Not Supported in transit domain"> Transit Domain</name>
              <artwork><![CDATA[
E1 --- BR1 --- BR2 ......... BR3 ---- BR4 --- E2
    Ci           <----LU---->              Ci
]]></artwork>
            </figure>

            <list style="symbols">

            <ul spacing="normal">
              <li>
                <t>Network between BR2 and BR3 comprises of multiple BGP-LU hops
            (over IGP-LDP domains).</t>
              </li>
              <li>
                <t>E1, BR1, BR4 BR4, and E2 are enabled for BGP CAR, with Ci colors.</t>
              </li>
              <li>
                <t>BR1 and BR2 are directly connected; BR3 and BR4 are directly connected.</t>
            </list>
	      </t>
              </li>
            </ul>
          </li>
          <li>
            <t>BR1 and BR4 form an over-the-top peering (via RRs as needed) to exchange
	      BGP CAR routes.</t>
          </li>
          <li>
            <t>BR1 and BR4 also form direct BGP-LU sessions to BR2 and BR3 BR3, respectively,
          to establish labeled paths between each other through the BGP-LU network.
          The sessions may be eBGP or iBGP.</t>
          </li>
          <li>
            <t>BR1 recursively resolves the BGP CAR next hop for CAR routes learnt from
          BR4 via the BGP-LU path to BR4.</t>
          </li>
          <li>
            <t>BR1 signals the transport discontinuity to E1 via the AIGP TLV, so that
          E1 can prefer other paths if available.</t>
          </li>
          <li>
            <t>BR4 does the same in the reverse direction.</t>
          </li>
          <li>
            <t>Thus, the color-awareness color awareness of the routes routes, and hence the paths
            in the data plane plane, are maintained between E1 and E2, even if the
            intent is not available within the BGP-LU island.</t>
          </li>
          <li>
            <t>A similar design can be used for going over network islands of other
          types.</t>
          </list>
        </t>
          </li>
        </ul>
      </section>
      <section title="Resource
      <section>
        <name>Resource Avoidance using Using BGP CAR and IGP Flex-Algo"> Flex-Algo</name>
        <t>This example illustrates a case of resource avoidance within a domain for a
 	    multi-domain color-aware path.
        </t> path.</t>

        <figure anchor="HRAVOIDUSECASE" title="BGP anchor="HRAVOIDUSECASE">
          <name>BGP CAR resolution Resolution over IGP FLex-Algo Flex-Algo for
        resource avoidance Resource Avoidance in a domain"> Domain</name>
          <artwork><![CDATA[
 	   +-------------+      +-------------+
 	   |             |      |             | V/v with C1
 	   |----+        |------|        +----|/
 	   | E1 |        |      |        | E2 |\
 	   |----+        |      |        +----| W/w with C2
 	   |             |------|   IGP FA128 |
 	   |  IGP FA128  |      |   IGP FA129 |
 	   |  Domain 1   |      |   Domain 2  |
 	   +-------------+      +-------------+
]]></artwork>
        </figure>
        <t>
            <list style="symbols">

        <ul spacing="normal">
          <li>
            <t>C1 and C2 represent the following two unique intents in the multi-domain network:
              <list style="symbols">
            </t>
            <ul spacing="normal">
              <li>
                <t>C1 is mapped to "minimize IGP metric", and</t>
              </li>
              <li>
                <t>C2 is mapped to "minimize IGP metric and avoid resource R".</t>
              </list>
            </t>
              </li>
            </ul>
          </li>
          <li>
            <t>Resource R represents link(s) or node(s) to be avoided.</t>
          </li>
          <li>
            <t>Flex-Algo FA128 in Domain 2 is mapped to "minimize IGP metric" metric", and hence
            to C1.</t>
          </li>
          <li>
            <t>Flex-Algo FA129 in Domain 2 is mapped to "minimize IGP metric
            and avoid resource R" R", and hence to C2.</t>
          </li>
          <li>
            <t>Flex-Algo FA128 in Domain 1 is mapped to "minimize IGP metric" i.e.,
              <list style="symbols">
              <t>There
            (i.e., there is no resource R to be avoided in Domain 1, hence
            both C1 and C2 are mapped to FA128.</t>
              </list>
            </t> FA128).</t>
          </li>
          <li>
            <t>E1 receives the following two service routes from E2:
              <list style="symbols"> E2:</t>
            <ul spacing="normal">
              <li>
                <t>V/v with BGP Color-EC C1, and</t>
              </li>
              <li>
                <t>W/w with BGP Color-EC C2.</t>
              </list>
            </t>
              </li>
            </ul>
          </li>
          <li>
            <t>E1 has the following color-aware paths:
              <list style="symbols">
            </t>
            <ul spacing="normal">
              <li>
                <t>(E2, C1) provided by BGP CAR with the following per-domain
 	          resolution:
 	            <list style="symbols">
 	            <t>Domain1:
                </t>
                <ul spacing="normal">
                  <li>
                    <t>Domain 1: over IGP FA128, and</t>
 	            <t>Domain2:
                  </li>
                  <li>
                    <t>Domain 2: over IGP FA128.</t>
 	            </list>
 	          </t>
                  </li>
                </ul>
              </li>
              <li>
                <t>(E2, C2) provided by BGP CAR with the following per-domain
 	          resolution:
 	            <list style="symbols">
 	            <t>Domain1:
                </t>
                <ul spacing="normal">
                  <li>
                    <t>Domain 1: over IGP FA128, and</t>
 	            <t>Domain2:
                  </li>
                  <li>
                    <t>Domain 2: over IGP FA129 (avoiding resource R).</t>
 	            </list>
 	          </t>
              </list>
            </t>
                  </li>
                </ul>
              </li>
            </ul>
          </li>
          <li>
            <t>E1 automatically steers the received service routes as follows:
              <list style="symbols">
            </t>
            <ul spacing="normal">
              <li>
                <t>V/v via (E2, C1) provided by BGP CAR.</t>
              </li>
              <li>
                <t>W/w via (E2, C2) provided by BGP CAR.</t>
              </list>
            </t>
            </list>
          </t>
          <t>Observations:
            <list style="symbols">
              </li>
            </ul>
          </li>
        </ul>
        <t>Observations:</t>
        <ul spacing="normal">
          <li>
            <t>C1 and C2 are realized over a common intra-domain intent (FA128) in one
            domain and distinct intents in another domain as required.</t>
          </li>
          <li>
            <t>32-bit Color space provides flexibility in defining a large
            number of intents in a multi-domain network. They may be
            efficiently realized by mapping to a smaller number of
            intra-domain intents in different domains.</t>
            </list>
          </t>
          </li>
        </ul>
      </section>
      <section title="Per-Flow

      <section>
        <name>Per-Flow Steering over CAR routes"> Routes</name>
        <t>This section provides an example of ingress PE per-flow steering as defined
        in section 8.6 of <xref target="RFC9256"/> target="RFC9256" sectionFormat="of" section="8.6"/>
        onto BGP CAR routes.
        </t>
        <t>The following description applies to the reference topology in <xref target="FAUSECASE"/>:
          <list style="symbols">
        </t>
        <ul spacing="normal">
          <li>
            <t>Ingress PE E1 learns best-effort BGP LU route E2.</t>
          </li>
          <li>
            <t>Ingress PE E1 learns CAR route (E2, C1), C1 is mapped to "low delay".</t>
          </li>
          <li>
            <t>Ingress PE E1 learns CAR route (E2, C2), C2 is mapped to
          "low delay and avoid resource R".</t>
          </li>
          <li>
            <t>Ingress PE E1 is configured to instantiate an array of paths to E2 where
          entry 0 is the BGP LU path to next hop, color C1 is the first entry entry, and
          color C2 is the second entry. The index into the array is called a
          Forwarding Class (FC).  The index can have values 0 to 7, especially when
          derived from the MPLS TC bits <xref target="RFC5462"/>.</t>
          </li>
          <li>
            <t>E1 is configured to match flows in its ingress interfaces (upon any field
          such as Ethernet destination/source/VLAN/TOS or IP destination/source/DSCP
          or transport ports ports, etc.) and color them with an internal per-packet FC variable
          (0, 1 1, or 2 in this example).</t>
          </li>
          <li>
            <t>This array is presented as a composite candidate path of SR policy (E2, C100)
          and acts as a container for grouping constituent paths of different
          colors/best-effort. This representation provides automated steering for
          services colored with Color-EC C100 via paths of different
          colors. Note that Color-EC C100 is used as indirection to the
          composite policy configured on ingress PE.</t>
          </li>
          <li>
            <t>Egress PE E2 advertises a VPN route RD:V/v with Color-EC C100
          to steer traffic via composite SR policy (E2, C100); i.e., C100) (i.e., FC array of paths.</t>
          </list>
        </t> paths).</t>
          </li>

        </ul>
        <t>E1 receives three packets K, K1, and K2 on its incoming interface. These three
        packets matches match on the VPN route which that recurses on E2. E1 colors these 3 packets
        respectively with forwarding-class forwarding class 0, 1, and 2.</t> 2, respectively.</t>
        <t>As a result
          <list style="symbols"> result:
        </t>
        <ul spacing="normal">
          <li>
            <t>E1 forwards K along the best-effort path to E2 (i.e., for the MPLS data plane,
          it pushes the best-effort label of E2).</t>
          </li>
          <li>
            <t>E1 forwards K1 along the (E2, C1) BGP CAR route.</t>
          </li>
          <li>
            <t>E1 forwards K2 along the (E2, C2) BGP CAR route.</t>
          </list>
        </t>
          </li>
        </ul>
      </section>
      <section anchor="SHAREDIP" title="Advertising anchor="SHAREDIP">
        <name>Advertising BGP CAR routes Routes for shared Shared IP addresses"> Addresses</name>
        <figure anchor="HSHIPUSECASE" title="BGP anchor="HSHIPUSECASE">
          <name>BGP CAR advertisements Advertisements for shared Shared IP
        addresses"> Addresses</name>
          <artwork><![CDATA[
 	  +-------------+      +--------------+
 	  |             |      |         +----|
 	  |             |------|         | E2 |(IP1)
 	  |----+        |      |         +----|
 	  | E1 |        |      |  Domain 2    |
 	  |----+        |      +--------------+
 	  |             |      +--------------+
 	  |             |      |         +----|
 	  |  Domain 1   |------|         | E3 |(IP1)
 	  +-------------+      |         +----|
 	                       |  Domain 3    |
 	                       +--------------+
]]></artwork>
        </figure>

        <t>This example describes a case where a route for the same transport
        IP address is originated from multiple nodes in different network domains.
        </t>
        domains.</t>
        <t>One use of this scenario is an Anycast anycast transport service, where packet
        encapsulation (e.g., LSP) may terminate on any one among a set of nodes. All the
        nodes are capable of forwarding the inner payload, typically via an IP lookup in
        the global table for Internet routes.
        </t> routes.</t>
        <t>A couple of variations of the use-case use case are described in the example below.
        </t> below.</t>
        <t>One node is shown in each domain, but there will be multiple nodes in practice
        for redundancy.
        </t>
        <t>Example-1: redundancy.</t>
<!-- [rfced] Appendix A.7: Is there text missing in the example below? For
instance, what does "nearest" refer to?

Original:
   Example-1: Anycast with forwarding to nearest
          <list style="symbols">
-->

        <t>Example 1: Anycast with forwarding to nearest:</t>
        <ul spacing="normal">
          <li>
            <t>Both E2 (in egress domain 2) and E3 (in egress domain 3) advertise
          Anycast (shared) IP (IP1, C1) with same label Label L1.</t>
          </li>
          <li>
            <t>An ingress PE E1 receives by default the best path(s) for (IP1, C1)
          propagated through BGP hops across the network.</t>
          </li>
          <li>
            <t>The paths to (IP1, C1) from E2 and E3 may merge at a common node
          along the path to E1, forming equal cost multipaths or active-backup paths
          at that node.</t>
          </li>
          <li>
            <t>Service route V/v is advertised from egress domains D2 and D3 with color
          C1 and next hop IP1.</t>
          </li>
          <li>
            <t>Traffic for V/v steered at E1 via (IP1, C1) is forwarded to
            either E2 or E3 (or both) as determined by routing along the
            network (nodes in the path).
            </t>
          </list>
        </t>
        <t>Example-2:
          </li>
        </ul>

        <t>Example 2: Anycast with egress domain visibility at ingress PE
          <list style="symbols"> PE:</t>
        <ul spacing="normal">
          <li>
            <t>E2 advertises (IP1, C1) and E3 advertises (IP1, C2) CAR routes for the
          Anycast IP IP1. C1 and C2 are colors assigned to distinguish the egress
          domains originating the routes to IP1.</t>
          </li>
          <li>
            <t>An ingress PE E1 receives the best path(s) propagated through BGP hops
          across the network for both (IP1, C1) and (IP1, C2).</t>
          </li>
          <li>
            <t>The CAR routes (IP1, C1) and (IP1, C2) do not get merged at any
          intermediate node, providing E1 control over path selection and load-balancing
          of traffic across these two routes. Each route may itself provide multipathing
          or Anycast anycast to a set of egress nodes.</t>
          </li>
          <li>
            <t>Service route V/v advertised from egress domains D2 and D3 with colors
          C1 and C2 C2, respectively, but with same next hop IP1.</t>
          </li>
          <li>
            <t>E1 will resolve and steer V/v path from D2 via (IP1, C1) and path from
          D3 via (IP2, C2). E1 will load-balance traffic to V/v across the two paths
          as determined by a local load-balancing policy.</t>
          </li>
          <li>
            <t>Traffic for colored service routes steered at E1 is forwarded to either E2
          or E3	(or load-balanced across both) as determined by E1.</t>
          </list>
        </t>
          </li>
        </ul>
        <t>In above example, D2 and D3 belonged to the same color or
        administrative domain. If D2 and D3 belong to different color domains,
        the domains will coordinate the assignment of colors with shared IP
        IP1 so that they do not cause conflicts.  For instance, in Example-1:
 		  <list style="symbols"> Example
        1:</t>
        <ul spacing="normal">
          <li>
            <t>D2 and D3 may both use C1 for the same intent when they originate CAR route for IP1.
 		    <list style="symbols">
            </t>
            <ul spacing="normal">
              <li>
                <t>In this case, neither D2 nor D3 will reuse C1 for some
                other intent.</t>
 		 	</list>
 		  </t>
              </li>
            </ul>
          </li>
          <li>
            <t>Alternatively, D2 may use C2 and D3 may use C3 for originating
            a CAR route for IP1 for the same intent.
 		    <list style="symbols"> intent.</t>
            <ul spacing="normal">
              <li>
                <t>In this case, D2 will not use C3 for originating CAR route
                for IP1 for some other intent. Similarly, D3 will not use C2
                for originating CAR route for IP1 for some other intent.</t>
 		 	</list>
 		  </t>
 		  </list>
 		</t>
              </li>
            </ul>
          </li>
        </ul>
      </section>
    </section>

    <section anchor="ColorMapping" title="Color anchor="ColorMapping">
      <name>Color Mapping Illustrations"> Illustrations</name>
      <t>
      There are a variety of deployment scenarios that arise when different
      color mappings are used in an inter-domain environment. This section
      attempts to enumerate them and provide clarity into the usage of the color related
      color-related protocol constructs.
      </t>

      <section title="Single color domain containing network domains
      <section>
        <name>Single Color Domain Containing Network Domains with N:N
      color distribution">
        <t>
          <list style="symbols">
          <t>
          All Color
        Distribution</name>
        <ul spacing="normal">
          <li>
            <t>All network domains (ingress, egress egress, and all transit domains)
            are enabled for the same N colors.
          <list>
          <t>
          A colors.</t>
            <ul spacing="normal">
              <li>
                <t>A color may of course be realized by different
                technologies in different domains as described above.
          </t>
          </list>
          </t>
          <t>
          The above.</t>
              </li>
            </ul>
          </li>
          <li>
            <t>The N intents are both signaled end-to-end via BGP CAR routes; routes,
            as well as realized in the data plane.
          </t> plane.</t>
          </li>
          <li>
            <t>
          <xref target="SFAUSECASE"/> is an example of this case.
            </t>
          </list>
        </t>
          </li>
        </ul>
      </section>
      <section anchor="APPENDIXNM"
      title="Single color domain containing network domains anchor="APPENDIXNM">
        <name>Single Color Domain Containing Network Domains with N:M color distribution">
        <t>
          <list style="symbols"> Color Distribution</name>
        <ul spacing="normal">
          <li>
            <t>
          Certain network domains may not be enabled for some of the
          colors used for end-to-end intents, but may still be required to provide
          transit for routes of those colors.
            </t>
          </li>
          <li>
            <t>
          When a (E, C1) route traverses a domain where color C1 is not
          available, the operator may decide to use a different intent of color
          C2 that is available in that domain to resolve the next hop and establish
          a path through the domain.
            <list style="symbols">
            </t>
            <ul spacing="normal">
              <li>
                <t>
            The next hop next-hop resolution may occur via paths of any intra-domain
            protocol or even via paths provided by BGP CAR.
                </t>
              </li>
              <li>
                <t>
            The next hop next-hop resolution color C2 may be defined as a local policy at
            ingress or transit nodes of the domain.
                </t>
              </li>
              <li>
                <t>
            It may also be automatically signaled from egress border nodes by
            attaching a Color-EC with value C2 to the BGP CAR routes.
                </t>
            </list>
          </t>
              </li>
            </ul>
          </li>
          <li>
            <t>
          Hence, routes of N end-to-end colors may be resolved over paths from a smaller
          set of M colors in a transit domain, while preserving the original
          color-awareness
          color awareness end-to-end.
            </t>
          </li>
          <li>
            <t>
          Any ingress PE that installs a service (VPN) route with a color C1, C1
          must have C1 enabled locally to install IP routes to (E, C1) and
          resolve the service route's next hop.
            </t>
          </li>
          <li>
            <t>
          A degenerate variation of this scenario is where a transit domain does
          not support any color. <xref target="SHDFAUSECASE"/> describes an example
          of this case.
            </t>
          </list>
        </t>
          </li>
        </ul>
        <t>Illustration for N end to end end-to-end intents over fewer M intra-domain intents: intents:</t>
        <figure anchor="NMUSECASE" title="N:M illustration"> anchor="NMUSECASE">
          <name>N:M Illustration</name>
          <artwork><![CDATA[
                     RD:V/v via E2 Color-EC: 100
                     RD:W/w via E2 Color-EC: 200
          +-----+    RD:X/x via E2 Color-EC: 300     +-----+
   ...... |S-RR1| <..................................|S-RR2| <........
  :       +-----+    RD:Y/y via E2 Color-EC: 400     +-----+          :
  :                                                                   :
  :                                                                   :
  :                                                                   :
+-:---------------------+---------------------+----------------------:-+
| :                     |                     |                      : |
|                       |                     |                        |
|     (E2,100) via 121  |   (E2,100) via 231  |     (E2,100) via E2    |
|      Color-EC: 1,10   |    Color-EC: 1,10   |      Color-EC: 1,10    |
|                       |                     |                        |
|     (E2,200) via 121  |   (E2,200) via 231  |     (E2,200) via E2    |
|      Color-EC: 1,20   |    Color-EC: 1,20   |      Color-EC: 1,20    |
|                     <---                  <----                      |
|     (E2,300) via 121  |   (E2,300) via 231  |     (E2,300) via E2    |
|      Color-EC: 2,30   |    Color-EC: 2,30   |      Color-EC: 2,30    |
|                       |                     |                        |
|     (E2,400) via 121  |   (E2,400) via 231  |     (E2,400) via E2    |
|      Color-EC: 2,40   |    Color-EC: 2,40   |      Color-EC: 2,40    |
|                       |                     |                        |
|                     +===+                 +===+                      |
|====+                |   |-------C10-------|   |                +=====|
|    |-------C1-------|   |-------C20-------|   |-------C1-------|     |
| E1 |                |121|                 |231|                | E2  |
|    |-------C2-------|   |-------C30-------|   |-------C2-------|     |
|====+                |   |-------C40-------|   |                +=====|
|                     +===+                 +===+                      |
|       C1=FA132        |      C10=FA128      |       C1=FA132         |
|       C2=FA133        |      C20=FA129      |       C2=FA133         |
|                       |      C30=FA130      |                        |
|                       |      C40=FA131      |                        |
|                       |                     |                        |
|        IS-IS SR       |      IS-IS SR       |     IS-IS SR           |
|        ACCESS         |       CORE          |     ACCESS             |
+-----------------------+---------------------+------------------------+
 iPE                  iABR                  eABR                    ePE
]]></artwork>
        </figure>

          <list style="symbols">
        <ul spacing="normal">
          <li>
            <t>The following description applies to the reference topology above:
            <list style="symbols">
            </t>
            <ul spacing="normal">
              <li>
                <t>Core domain provides 4 intra-domain intents as described below:
              <list style="symbols">
                </t>
                <ul spacing="normal">
                  <li>
                    <t>FA128 mapped to C10,</t>
                  </li>
                  <li>
                    <t>FA129 mapped to C20,</t>
                  </li>
                  <li>
                    <t>FA130 mapped to C30, and</t>
                  </li>
                  <li>
                    <t>FA131 mapped to C40.</t>
              </list>
            </t>
                  </li>
                </ul>
              </li>
              <li>
                <t>Access domain provides the following 2 intra-domain intents:
              <list style="symbols">
                </t>
                <ul spacing="normal">
                  <li>
                    <t>FA132 mapped to C1, and</t>
                  </li>
                  <li>
                    <t>FA133 mapped to C2</t>
              </list>
            </t> C2.</t>
                  </li>
                </ul>
              </li>
              <li>
                <t>Operator defines the following 4 BGP CAR end to end end-to-end intents as below:
              <list style="symbols">
                </t>
                <ul spacing="normal">
                  <li>
                    <t>CAR color C100 that resolves on C1 in access and C10 in core Core domain,</t>
                  </li>
                  <li>
                    <t>CAR color C200 that resolves on C1 in access and C20 in core Core domain,</t>
                  </li>
                  <li>
                    <t>CAR color C300 that resolves on C2 in access and C30 in core Core domain, and
                    </t>
                  </li>
                  <li>
                    <t>CAR color C400 that resolves on C2 in access and C40 in core Core domain.</t>
              </list>
            </t>
                  </li>
                </ul>
              </li>
              <li>
                <t>E2 may originate BGP CAR routes with multiple BGP Color-ECs
                as shown above.  At each hop, CAR route's next hop is resolved
                over the available intra-domain color. For example (E2, C100)
                with BGP color ECs Color-ECs C1, C10 resolves over C1 at ABR 231, C10 at
                ABR 121, and C1 at E1. </t>
              </li>
              <li>
                <t>Egress PE E2 advertises a VPN route RD:V/v colored with BGP Color-EC C100 to
            steer traffic through FA 132 in access and FA 128 in core. It also advertises
            another VPN route RD:W/w colored with BGP Color-EC C200 to steer traffic through
            FA 132 in access and FA 129 in core.</t>
            </list>
          </t>
              </li>
            </ul>
          </li>
          <li>
            <t>Important:
            <list style="symbols">
            </t>
            <ul spacing="normal">
              <li>
                <t> End-to-end (BGP CAR) colors can be decoupled from intra-domain transport colors. </t>
              </li>
              <li>
                <t>Each end-to-end BGP CAR color is a combination of various intra-domain colors or intents.</t>
              </li>
              <li>
                <t>Combination can be expressed by local policy at ABRs or by attaching
            multiple BGP Color-ECs at origination point of BGP CAR route.</t>
              </li>
              <li>
                <t>Service traffic is steered into suitable CAR color to use the most granular intent
            in a domain multiple hops away from ingress PE.</t>
              </li>
              <li>
                <t>Consistent reuse of standard color based color-based resolution mechanism at both service and
	    transport layers.</t>
            </list>
          </t>
          </list>
        </t>
              </li>
            </ul>
          </li>
        </ul>
      </section>
      <section anchor="APPENDIXMCD" title="Multiple color domains">
        <t>
        When anchor="APPENDIXMCD">
        <name>Multiple Color Domains</name>
        <t>When the routes are distributed between domains with different
        color-to-intent mapping schemes, both N:N and N:M cases are possible.
        Although an N:M mapping is more likely to occur. </t>
        <t>Reference topology: topology:</t>

        <figure anchor="MCD" title="Multiple color domains"> anchor="MCD">
          <name>Multiple Color Domains</name>
          <artwork><![CDATA[
   D1 ----- D2 ----- D3
   C1       C2       C3
]]></artwork>
        </figure>

            <list style="symbols">

        <ul spacing="normal">
          <li>
            <t>C1 in D1 maps to C2 in D2 and to C3 in D3.</t>
          </li>
          <li>
            <t>BGP CAR is enabled in all three color domains.</t>
            </list>
	      </t>
          </li>
        </ul>
        <t>
          The reference topology above is used to elaborate on the design
          described in <xref target="SDIFFCOLORS"/>
        </t>
        <t>
          When the route originates in color domain D1 and gets advertised
          to a different color domain D2, the following procedures apply:
          <list style="symbols">
          <t>
          The
        </t>
        <ul spacing="normal">
          <li>
            <t>The NLRI of the BGP CAR route is preserved end to end, i.e., end (i.e.,
            route is (E, C1).
	      </t>
          <t>
       A C1)).</t>
          </li>
          <li>
            <t>A BR of D1 attaches LCM-EC with value C1 when advertising to a
            BR in D2.
	      </t>
          <t>
       A D2.</t>
          </li>
          <li>
            <t>A BR in D2 receiving (E, C1) maps C1 in received LCM-EC to
            local color, say C2.
            <list style="symbols"> C2.</t>
            <ul spacing="normal">
              <li>
                <t>A BR in D2 may receive (E, C1) from multiple D1 BRs BRs, which provide
 	        equal cost or primary/backup paths.</t>
            </list>
	      </t>
              </li>
            </ul>
          </li>
          <li>
            <t>
       Within D2, this LCM-EC value of C2 is used instead of the Color in
    CAR route NLRI (E, C1). This applies to all procedures described in the
    earlier section for a single color domain, such as next-hop resolution and
    service steering.
            </t>
          </li>
          <li>
            <t>
       A colored service route V/v originated in color domain D1 with next hop E
    and Color-EC C1 will also have its color extended-community Color-EC value re-mapped
    to C2, typically at a service RR.
            </t>
          </li>
          <li>
            <t>
       On an ingress PE in D2, V/v will resolve via C2.
            </t>
          </li>
          <li>
            <t>
          When a BR in D2 advertises the route to a BR in D3, the same process
          repeats.
            </t>
    </list>
	      </t>
          </li>
        </ul>
      </section>
    </section>
    <section anchor="SRv6ILLUS" title="CAR anchor="SRv6ILLUS">
      <name>CAR SRv6 Illustrations"> Illustrations</name>
      <section anchor="SECLOCHBYH"
        title="BGP anchor="SECLOCHBYH">
        <name>BGP CAR SRv6 locator reachability hop by hop distribution"> Locator Reachability Hop-by-Hop Distribution</name>
        <figure anchor="SRv6LOCHopByHOP">
          <artwork><![CDATA[
                            RD:V/v via E2
           +-----+          SRv6SID=B:C11:2:DT4::     +-----+
    ...... |S-RR1| <..................................|S-RR2| <.....
   :       +-----+                                    +-----+       :
   :                                                                :
   :                                                                :
   :             AS2                                         AS1    :
 +-:------------------------------------+            +--------------:--+
 | :                                    |            |              :  |
 | :                 B:C11::/32 via IP1 |            |              :  |
 | :          +-----+ LCM=C1, AIGP=10   |            |              :  |
 | :          | TRR |<..............    |            |              :  |
 | :          +-----+<..........     :  |            |              :  |
 | :             :    B:C11::/32 :   :  |            |              :  |
 | :             :       via IP2 :   :  |            |              :  |
 | :             : LCM=C1,AIGP=10:   :  |            |              :  |
 | :   ......... :               :   :  | B:C11::/32 |              :  |
 | : :           :               :   :  | via 231    |           +-----|
 | : :           :               :   :  |  LCM=C1    |           | E2  |
   : :    +---+  :   +---+       :   :  |  AIGP=10   |           +-----|
 | : :    |P11|<.:..>|P13|       :  +----+        +---+             :  |
 | : :    +---+  :   +---+       :  | 121|-----IP1|231|             :  |
 | V V           :               :  +----+  eBGP  +---+             :  |
 |----+          :               :      |            |           +-----|
 | E1 |   +---+  :   +---+       :      |            |           | En  |
 |----+   |P12|<.:..>|P14|       :      |            |           +-----|
 |        +---+      +---+       :  +----+  eBGP  +---+                |
 |        IPv6 FIB:              ...| 122|-----IP2|232|                |
 |        B:C11::/32 via IP1        +----+        +---+                |
 |                   via IP2            | B:C11::/32 |                 |
 |                                      | via 232    |                 |
 |                                      | LCM=C1     |                 |
 |                                      | AIGP=10    |                 |
 |         IS-ISv6                      |            |     IS-ISv6     |
 |  FA 128 (B:C12::/32)                 |            |FA128(B:C11::/32)|
 |  FA 0   (B:02::/32)                  |            |FA0  (B:01::/32) |
 +--------------------------------------+            +-----------------+
 iPE                                  ASBR          ASBR             ePE
]]></artwork>
        </figure>
        <t>The topology above is an example to illustrate the BGP CAR SRv6
        locator prefix route based route-based design (Routed Service SID: <xref target="SECRTDSSID"/>), (<xref target="SECRTDSSID"/>) with hop by hop
        hop-by-hop IPv6 routing within and between domains.
              <list style="symbols">
        </t>
        <ul spacing="normal">
          <li>
            <t>Multi-AS network with eBGP CAR session between ASBRs.</t>
          </li>
          <li>
            <t>Transport RR (TRR) peers with P, BR BR, and PE clients within an AS to propagate
              CAR prefixes. AddPath ADD-PATH is enabled to propagate multiple paths.</t>
          </li>
          <li>
            <t>IS-IS (IGP) Flex-Algo 128 for SRv6 is running in each AS (AS may consist
              of multiple IGP domains), where the following steps apply:
                <list style="symbols">
            </t>
            <ul spacing="normal">
              <li>
                <t>Prefix B:C11::/32 summarizes Flex-Algo 128 block in AS1 for the given
                intent. Node locators in the egress domain are sub-allocated from the
                block for the given intent.</t>
              </li>
              <li>
                <t>Similarly, Prefix B:C12::/32 summarizes Flex-Algo 128 block in AS2.</t>
              </li>
              <li>
                <t>Per Flex-Algo external subnets for eBGP next hops IP1 and IP2 are
                distributed in IS-IS within AS2.</t>
                </list>
              </t>
              </li>
            </ul>
          </li>
          <li>
            <t>BGP CAR prefix route B:C11::/32 with LCM C1 is originated by AS1
              BRs 231 and 232 on eBGP sessions to AS2 BRs 121 and 122.</t>
          </li>
          <li>
            <t>ASBR 121 and 122 propagate the route in AS2 to all the P, ABRs ABRs, and PEs
              through transport RR.</t>
          </li>
          <li>
            <t>Every router in AS2 resolves BGP CAR prefix B:C11::/32 next hops
              IP1 and IP2 in IS-ISv6 Flex-Algo 128 and programs B:C11::/32 prefix in global
              IPv6 forwarding table.</t>
          </li>
          <li>
            <t>AIGP attribute influences BGP CAR route best path decision.</t>
          </li>
          <li>
            <t>Egress PE E2 advertises a VPN route RD:V/v with SRv6 service Service
              SID B:C11:2:DT4::. Service SID is allocated by E2 from its locator of
              color C1 intent.</t>
          </li>
          <li>
            <t>Ingress PE E1 learns (via service RRs S-RR1 and S-RR2) VPN route RD:V/v
              with SRv6 SID B:C11:2:DT4::.</t>
          </li>
          <li>
            <t>Service traffic encapsulated with SRv6 Service SID B:C11:2:DT4:: is
              natively steered hop by hop along IPv6 routed path to B:C11::/32 provided
              by BGP CAR in AS2.</t>
          </li>
          <li>
            <t>Encapsulated service traffic is natively steered along IPv6 routed path
              to B:C11::/32 provided by IS-ISv6 Flex-Algo 128 in AS1.</t>
              <t> Design
          </li>
          <li>
            <t>Design applies to multiple ASNs. BGP next hop is rewritten across a an eBGP hop.</t>
              </list>
            </t>
          </li>
        </ul>
        <t>Important:
              <list style="symbols">
        </t>
        <ul spacing="normal">
          <li>
            <t>No tunneling/encapsulation on Ingress ingress PE and BRs for BGP CAR provided
              transport.</t>
          </li>
          <li>
            <t>Uses longest prefix match of SRv6 service Service SID to BGP CAR IP prefix.
              No mapping to labels/SIDs, instead use of simple IP based IP-based forwarding.</t>
              </list>
            </t>
          </li>
        </ul>

        <t>Packet forwarding</t>
             <figure> forwarding:</t>
        <artwork><![CDATA[
@E1:  IPv4 VRF V/v => H.Encaps.red <B:C11:2:DT4::> => forward Forward based
                                                      on B:C11::/32
@P*:  IPv6 table: B:C11::/32 => forward Forward to interface, NH
@121: IPv6 Table: B:C11::/32 => forward Forward to interface, NH
@231: IPv6 table: B:C11:2::/48 :: => forward Forward via IS-ISv6 FA path to E2
@231: IPv6 Table B:C11:2::/48 => forward Forward via IS-ISv6 FA path to E2
@E2:  My SID table B:C11:2:DT4:: =>pop => Pop the outer header and lookup look up
                                    the inner DA in the VRF
]]></artwork>
            </figure>

      </section>
      <section anchor="SECSRv6LOCencap"
        title="BGP anchor="SECSRv6LOCencap">
        <name>BGP CAR SRv6 locator reachability distribution Locator Reachability Distribution with encapsulation"> Encapsulation</name>
        <figure anchor="SRv6LOCencap">
          <artwork><![CDATA[
                           RD:V/v via E2
          +-----+          SRv6SID=B:C11:2:DT4::     +-----+
   ...... |S-RR1| <..................................|S-RR2| <.......
   :      +-----+                                    +-----+        :
   :                                                                :
   :                                                                :
   :                                                                :
+-:-----------------------+----------------------+------------------:--+
| :                       |                      |                  :  |
| :                       |                      |                  :  |
| :  B:C11::/32 via 121   |  B:C11::/32 via 231  |                  :  |
| :  SID=B:C13:121:END::  |  SID=B:C12:231:END:: |                  :  |
| :  LCM=C1,AIGP=110    +---+LCM=C1 AIGP=10    +---+                :  |
| : |-------------------|121|<-----------------|231|<-------------| :  |
| : V                   +---+                  +---+              | :  |
|----+                    |                      |               +-----|
| E1 |                    |                      |               | E2  |
|----+                    |                      |               +-----|
|   ^                     |                      |                  :  |
|   |                     |                      |                  :  |
|   |                     |                      |               +-----|
|   |                     |                      |               | En  |
|   |                     |                      |               +-----|
|   |                   +---+                  +---+              |    |
|   |----------------   |122|<-----------------|232|<-------------|    |
|                       +---+                  +---+                   |
|    B:C11::/32 via 122   |  B:C11::/32 via 232  |                     |
|    SID=B:C13:122:END::  |  SID=B:C12:232:END:: |                     |
|    LCM=C1 AIGP=120      |  LCM=C1 AIGP=20      |                     |
|                         |                      |                     |
|         IS-ISv6         |      IS-ISv6         |     IS-ISv6         |
|  FA 128 (B:C13::/32)    | FA 128 (B:C12::/32)  |  FA128 (B:C11::/32) |
|  FA 0   (B:03::/32)     | FA 0   (B:02::/32)   |  FA1 0 (B:01::/32)  |
+-------------------------+----------------------+---------------------+
 iPE                    iABR                    eABR                ePE
]]></artwork>
        </figure>
        <t>The topology above is an example to illustrate the BGP CAR SRv6 locator
          prefix route based route-based design (Routed Service SID: <xref target="SECRTDSSID"/>), (<xref target="SECRTDSSID"/>) with intra-domain encapsulation.
          The example shown is iBGP, but also applies to eBGP (multi-AS).
            <list style="symbols">
        </t>
        <ul spacing="normal">
          <li>
            <t>IGP Flex-Algo 128 is running in each domain, where
              <list style="symbols"> where:
            </t>
            <ul spacing="normal">
              <li>
                <t>Prefix B:C11::/32 summarizes Flex-Algo 128 block in egress domain for the
              given intent. Node locators in the egress domain are sub-allocated from
              the block.</t>
              </li>
              <li>
                <t>Prefix B:C12::/32 summarizes FA128 block in transit domain.</t>
              </li>
              <li>
                <t>Prefix B:C13::/32 summarizes FA128 block in ingress domain.</t>
              </list>
            </t>
              </li>
            </ul>
          </li>
          <li>
            <t>BGP CAR route B:C11::/32 is originated by ABRs 231 and 232 with LCM C1.
            Along the propagation path, border routers set next-hop-self and appropriately
            update the intra-domain encapsulation information for the C1 intent.
            For example, 231 and 121 signal SRv6 SID of END End behavior
            <xref target="RFC8986"/> allocated from their respective
            locators for the C1 intent. (Note: IGP Flex-Algo is shown for intra-domain path,
            but SR-Policy may also provide the path as shown in
            <xref target="SECSRv6EC"/>).</t> target="SECSRv6EC"/>.)</t>
          </li>
          <li>
            <t>AIGP attribute influences BGP CAR route best path decision.</t>
          </li>
          <li>
            <t>Egress PE E2 advertises a VPN route RD:V/v with SRv6
            service
            Service SID B:C11:2:DT4::. Service SID is allocated by E2 from its
            locator of color C1 intent.</t>
          </li>
          <li>
            <t>Ingress PE E1 learns CAR route B:C11::/32 and VPN route RD:V/v with
            SRv6 SID B:C11:2:DT4::.</t>
          </li>
          <li>
            <t>Traffic encapsulated with SRv6 Service SID B:C11:2:DT4:: is steered
            along IPv6 routed path provided by BGP CAR IP prefix route to locator
            B:C11::/32.</t>
            </list>
          </li>
        </ul>
        <t>Important:
        </t>
          <t>Important
            <list style="symbols">
        <ul spacing="normal">
          <li>
            <t>Uses longest prefix match of SRv6 service Service SID to BGP CAR prefix.
            No
            There is no mapping labels/SIDs, instead labels/SIDs; there is simple IP based forwarding.</t> IP-based forwarding instead.</t>
          </li>
          <li>
            <t>Originating domain PE locators of the given intent can be summarized on
            transit BGP hops eliminating per PE state on border routers.</t>
            </list>
          </t>
          <t> Packet forwarding</t>
          <figure>
          </li>
        </ul>
        <t>Packet forwarding:</t>
        <artwork><![CDATA[
@E1:   IPv4 VRF V/v => H.Encaps.red <B:C13:121:END::, B:C11:2:DT4::>
@121: My SID table: B:C13:121:END:: => Update DA with B:C11:2:DT4::
@121: IPv6 Table: B:C11::/32 => H.Encaps.red <B:C12:231:END::>
@231: My SID table: B:C12:231:END:: => Remove IPv6 header;
                                       Inner DA B:C11:2:DT4::
@231: IPv6 Table B:C11:2::/48 => forward Forward via IS-ISv6 FA path to E2
@E2: My SID table B:C11:2:DT4:: =>pop => Pop the outer header and lookup look up
				   the inner DA in the VRF
]]></artwork>
          </figure>
      </section>
      <section anchor="SECSRv6EC"
        title="BGP anchor="SECSRv6EC">
        <name>BGP CAR (E, C) route distribution Route Distribution for steering non-routed service SID"> Steering Non-Routed Service SID</name>
        <figure anchor="SRv6EC">
          <artwork><![CDATA[
                          RD:V/v via E2
         +-----+          SRv6SID: B:01:2:DT4::     +-----+
  ...... |S-RR1| <..................................|S-RR2| <.......
  :      +-----+             Color C2               +-----+        :
  :                                                                :
  :                  +-----+ (E2,C2) via 231                       :
  : -----------------| TRR |-------------------|                   :
  :|                 +-----+  SID=B:C21:2:B6:: |                   :
+-:|---------------------+---------------------|+------------------:--+
| :|                     |                     ||                  :  |
| :|                     |                     ||                  :  |
| :|  B:C21::/32 via 121 |  B:C21::/32 via 231 ||SR policy(E2,C2)  :  |
| :|  LCM=C2,AIGP=110    |  LCM=C2 AIGP=10     ||BSID=B:C21:2:B6:: :  |
| :|                   +---+                  +---+                :  |
| :|-------------------|121|<-----------------|231|<-------------| :  |
| :V SR policy(121,C2) +---+SR policy(231,C2) +---+              | :  |
|----+                   |                      |               +-----|
| E1 |                   |                      |               | E2  |
|----+                   |                      |               +-----|
|  ^ SR policy(122,C2) +---+SR policy(232,C2) +---+              |    |
|  |----------------   |122|<-----------------|232|<-------------|    |
|    B:C21::/32 via 121+---+B:C21::/32 via 232+---+ SR policy(E2,C2)  |
|    LCM=C2,AIGP=120     |   LCM=C2 AIGP=20     |   BSID=B:C21:2:B6:: |
|                        |                      |                     |
|        IS-ISv6         |      IS-ISv6         |     IS-ISv6         |
|     FA 0 (B:03::/32)   |   FA 0 (B:02::/32)   |   FA 0(B:01::/32)   |
+------------------------+----------------------+---------------------+
 iPE                    iABR                   eABR                ePE
]]></artwork>
        </figure>
        <t>The topology above is an example to illustrate the BGP CAR (E, C) route
          based
        route-based design (<xref target="SECNRSSID"/>). The example is iBGP,
        but the design also applies to eBGP (multi-AS).
            <list style="symbols">
        </t>
        <ul spacing="normal">
          <li>
            <t>SR policy (E2, C2) provides given intent in egress domain.
              <list style="symbols">
            </t>
            <ul spacing="normal">
              <li>
                <t>SR policy (E2, C2) with segments  &lt;B:01:z:END::, B:01:2:END::&gt; B:01:2:END::&gt;,
              where z is the node id in egress domain.</t>
              </list>
            </t>
              </li>
            </ul>
          </li>
          <li>
            <t>Egress ABRs 231 and 232 redistribute SR policy into BGP CAR Type-1 NLRI
            (E2, C2) to other domains, with SRv6 SID of End.B6 behavior. This route is
            propagated to ingress PEs through transport Transport RR (TRR) or inline with next hop
            unchanged.</t> next-hop-unchanged.</t>
          </li>
          <li>
            <t>The ABRs also advertise BGP CAR prefix route (B:C21::/32) summarizing locator
            part of SRv6 SIDs for SR policies of given intent to different PEs in
            egress domain. BGP CAR prefix route propagates through border routers.
            At each BGP hop, BGP CAR prefix next-hop resolution triggers intra-domain
            transit SR policy (C2, CAR next hop). For example:
              <list style="symbols">
            </t>
            <ul spacing="normal">
              <li>
                <t>SR policy (231, C2) with segments &lt;B:02:y:END::, B:02:231:END::&gt;, and
                </t>
              </li>
              <li>
                <t>SR policy (121, C2) with segments &lt;B:03:x:END::, B:03:121:END::&gt;,</t>
              </li>
              <li>
                <t>where x and y are node ids within the respective domains.</t>
              </list>
            </t>
              </li>
            </ul>
          </li>
          <li>
            <t>Egress PE E2 advertises a VPN route RD:V/v with Color-EC C2.</t>
          </li>
          <li>
            <t>Ingress PE E1 steers VPN route from E2 onto BGP CAR route (E2, C2) that
            results in H.Encaps.red of SRv6 transport SID B:C21:2:B6:: and SRv6 service Service SID
            as last segment in IPv6 header.</t>
          </li>
          <li>
            <t>IPv6 destination B:C21:2:B6:: match on CAR prefix B:C21::/32 that
            steers the packet into intra-domain (intent-aware) SR Policy on ingress PE E1
            and ABR 121.</t>
          </li>
          <li>
            <t>IPv6 packet destination B:C21:2:B6:: lookup in mySID table on ABR
            231 or 232 results in END.B6 behavior (i.e., push of policy segments to E2).</t>
            </list>
          </li>
        </ul>
        <t>Important:
        </t>
          <t>Important
            <list style="symbols">
        <ul spacing="normal">
          <li>
            <t>Ingress PE steers services via (E, C) CAR route as per
            <xref target="RFC9256"/>.</t>
          </li>
          <li>
            <t>In data plane (E, C) C), resolution results in IPv6 header destination being
            SRv6 SID of END.B6 behavior whose locator is of given intent on
            originating ABRs.</t>
          </li>
          <li>
            <t>CAR IP prefix route along the transit path provides simple LPM Longest Prefix Match (LPM) IPv6 forwarding
            along the transit BGP hops.</t>
          </li>
          <li>
            <t>CAR NLRI Type-2 prefix summarizes binding SIDs of all SR policies on
            originating ABR of a given intent to different PEs in egress domain.
            This eliminates per PE state on transit routers.</t>
            </list>
          </t>
          </li>
        </ul>
        <t>Packet forwarding</t>
            <figure> forwarding:</t>
        <artwork><![CDATA[
@E1:   IPv4 VRF V/v => H.Encaps.red <B:C21:2:B6::, B:0:E2:DT4::>
                       H.Encaps.red <SR policy (C2,121) sid list>
@121: My SID table: B:03:121:END:: => Remove outer IPv6 header;
                                      Inner DA B:C21:2:B6::
@121: IPv6 Table: B:C21::/32 => H.Encaps.red <SR Policy (C2,231) sid
                                                                list>
@231: My SID table: B:02:231:END:: => Remove outer IPv6 header;
                                      Inner DA B:C21:2:B6::

@231: MySIDtable B:C21:2:B6:: => H.Encaps.red <SR Policy (C2,E2) sid
                                                                list>
@E2: IPv6 Table B:0:2:DT4:: =>pop => Pop the outer header and lookup look up the
                               inner DA in the VRF
]]></artwork>
            </figure>
      </section>
    </section>

<!-- [rfced] Appendix D: We have made several updates for clarity and
readability. Please carefully review and let us know if any additional
updates are needed.

a) FYI, we made this sentence into a list. May we change "4k bytes"
to "4000 bytes" for clarity?  (It seems fine for other instances of
'4k' to remain in this document, as they are not followed by the word
'bytes'.)

Original:
   Scenarios considered are ideal packing (maximum number of routes
   packed to update message limit of 4k bytes), practical deployment
   case with average packing (5 routes share set of BGP path attributes
   and hence packed in single update message) and worst-case of no
   packing (each route in separate update message).

Current:

The packing scenarios considered are as follows:

   *  the ideal case (where the maximum number of routes are packed to
      the update message limit of 4k bytes),

   *  the practical case of average packing (where 5 routes share a set
      of BGP path attributes, and hence are packed in a single update
      message), and

   *  the worst case of no packing (where each route is in a separate
      update message).

b) Table 5: FYI, we updated the title and made other slight adjustments to
the table.

Original:
  Figure 18: Summary of ideal, practical and no-packing BGP data in
                              each case

Current:
        Table 5: Summary of the Ideal, Practical, and Worst Cases of
                              Packing BGP Data

c) To avoid using an RFC number as an adjective, may we update the
various instances of "[RFC8277] style" as follows?

Original:

   It compares total BGP
   data on the wire for CAR SAFI and [RFC8277] style encoding in MPLS
   label (CASE A), SR extension with MPLS (per-prefix label index in
   Prefix-SID attribute) [RFC8669] (CASE B) and SRv6 SID (CASE C) cases.

   |RFC-8277 style  |
   |    NLRI        |

   No degradation from RFC8277 like encoding

   CAR SAFI encoding more efficient by 88% in best case and 71% in average
   case over RFC8277 style encoding

   SAFI 128 8277 style encoding with label in NLRI

Perhaps:

   It compares total BGP data on the wire for CAR SAFI and encoding as specified
   in [RFC8277] in the following: an MPLS label (CASE A), an SR extension with MPLS
   (per-prefix label index in Prefix-SID attribute; see [RFC8669]) (CASE B), and
   an SRv6 SID (CASE C).

   | NLRI as      |
   | per RFC 8277 |

   No degradation from encoding as specified in [RFC8277].

   CAR SAFI encoding is more efficient by 88% in the best case and 71% in the
   average case over the encoding as specified in [RFC8277] (which precludes
   packing).

   SAFI 128 encoded per RFC 8277 with label in NLRI
-->

<section anchor="UPDATEPACKING" title="CAR anchor="UPDATEPACKING">
      <name>CAR SAFI NLRI update packing efficiency
    calculation"> Update Packing Efficiency Calculation</name>
      <t>
      CAR SAFI NLRI encoding is optimized for update packing. It allows
      per route
      per-route information (for example example, label, label index index, and SRv6 SID encapsulation data) to be
      carried in the non-key TLV part of NLRI. This allows multiple NLRIs to be packed in a
      single update message when other attributes (including LCM-EC LCM-EC, when present) are shared.
      The table below shows a theoretical analysis calculated from observed BGP update message
      size in operational networks. It compares total BGP data on the wire for CAR SAFI and
      <xref target="RFC8277"/> style encoding in MPLS label (CASE A),
      SR extension with MPLS (per-prefix label index in Prefix-SID attribute)
      <xref target="RFC8669"/> (CASE B) and SRv6 SID (CASE C) cases.
      Scenarios
      The packing scenarios considered are as follows:</t>
      <ul>
	<li>the ideal packing (maximum case (where the maximum number of routes are packed to the update message
	limit of 4k bytes), bytes),</li>
	<li>the practical deployment case with of average packing (5 (where 5 routes share a set
	of BGP path attributes attributes, and hence are packed in a single update message) and worst-case
	message), and</li>
	<li>the worst case of no packing
      (each (where each route is in a separate update message).
      </t>

      <t>
      <figure anchor="UPFIGURE" title="Summary message).</li>
      </ul>

<table anchor="UPFIGURE">
  <name>Summary of ideal, practical the Ideal, Practical, and no-packing BGP data in each case">
        <artwork><![CDATA[
----------------+--------------+----------------+-----------------------
Encoding        | Worst Cases of Packing BGP Data</name>
  <thead>
    <tr>
      <th>Encoding</th>
      <th>BGP CAR   |RFC-8277 NLRI</th>
      <th><xref target="RFC8277"/> style  |  Result
                |    NLRI      |NLRI            |
----------------+--------------+----------------+-----------------------
CASE NLRI</th>
      <th>Result</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <th colspan="4">CASE A: Label   |              |                |
     (Ideal)    |    27.5 MB   |     26 MB      |
                +--------------+----------------+  No Label</th>
    </tr>
    <tr>
      <td>(Ideal)</td>
      <td>27.5&nbsp;MB</td>
      <td>26 MB</td>
      <td rowspan="3">No degradation from
  (Practical)   |    86 MB     |     84 MB      |  RFC8277 <xref target="RFC8277"/> like encoding
                +--------------+----------------+
(No packing)    |   325 MB     |    324 MB      |
----------------+--------------+----------------+-----------------------
CASE encoding.</td>
    </tr>
    <tr>
      <td>(Practical)</td>
      <td>86&nbsp;MB</td>
      <td>84 MB</td>
    </tr>
    <tr>
      <td>(Worst; no packing)</td>
      <td>325&nbsp;MB</td>
      <td>324 MB</td>
    </tr>

    <tr>
      <th colspan="4">CASE B: Label   |              |    339 &amp; Label-index</th>
    </tr>
    <tr>
      <td>(Ideal)</td>
      <td>42&nbsp;MB</td>
      <td>339 MB      | CAR Packing not possible</td>
      <td rowspan="3">CAR SAFI encoding is more
& Label-index   |              |   Packing not  | efficient by 88% in
     (Ideal)    |    42 MB     |   possible     | the best case and
      71% in
                +--------------+----------------+ the average case over
  (Practical)   |    99 MB     |    339 MB      | RFC8277 <xref target="RFC8277"/> style encoding
                |              |   Packing not  | (which precludes
                |              |   possible     |  packing)
                +--------------+----------------+
(No packing)    |   339 MB     |    339
      packing).</td>
    </tr>
    <tr>
      <td>(Practical)</td>
      <td>99&nbsp;MB</td>
      <td>339 MB      |
                |              |                |
----------------+--------------+----------------+-----------------------
CASE Packing not possible</td>
    </tr>
    <tr>
      <td>(Worst; no packing)</td>
      <td>339&nbsp;MB</td>
      <td>339 MB</td>
    </tr>

    <tr>
      <th colspan="4">CASE C: SRv6 SID|              |                | Results SID</th>
    </tr>
    <tr>
      <td>(Ideal)</td>
      <td>49&nbsp;MB</td>
      <td>378 MB</td>
      <td rowspan="3">Results are similar to
    (Ideal)     |    49 MB     |    378 MB      | SR MPLS the SR-MPLS case.
                |              |                | Transposition provides
                +--------------+----------------+ a further 20% reduction
 (Practical)    |   115 MB     |    378 MB      | in BGP data.
                +--------------+----------------+
(No packing)    |   378 MB     |    378 MB      |
----------------+--------------+----------------+-----------------------

        ]]></artwork>
      </figure>
      </t>

      <t>Analysis data.</td>
    </tr>
    <tr>
      <td>(Practical)</td>
      <td>115&nbsp;MB</td>
      <td>378 MB</td>
    </tr>
    <tr>
      <td>(Worst; no packing)</td>
      <td>378&nbsp;MB</td>
      <td>378 MB</td>
    </tr>
  </tbody>
</table>

      <t>This analysis considers 1.5 million routes (5 colors across 300k endpoints) </t> endpoints).</t>

<!--[rfced] Appendix D: We suggest adding a space between the
number and the units throughout the descriptions of Cases A, B, and C.
Please let us know if this update is acceptable. A few examples:

Original:  ~86MB
         ~27.5MB
          ~339MB

Suggested: ~86 MB
         ~27.5 MB
          ~339 MB
-->

      <t>CASE A: BGP data exchanged for non SR MPLS case
        <figure> the non-SR-MPLS case:</t>
      <artwork><![CDATA[
    Consider 200 bytes of shared attributes
    CAR SAFI signal Label in non-key TLV part of NLRI
       Each NLRI size for AFI 1 = 12(key) + 5(label) = 17 bytes
         Ideal packing:
          number of NLRIs in 4k update size = 223 (4k-200/17)
          number of update messages of 4k size = 1.5 million/223 = 6726
          Total BGP data on wire = 6726 * 4k = ~27.5MB
         Practical packing (5 routes in update message) message):
          size of update message = (17 * 5) + 200 = 285
          Total BGP data on wire = 285 * 300k = ~86MB
         No-packing case (1 route per update message) message):
          size of update message = 17 + 200 = 217
          Total BGP data on wire = 217 * 1.5 million = ~325MB
    SAFI 128 8277 style encoding with label in NLRI
       Each NLRI size for AFI 1 = 13(key) + 3(label) = 16 bytes
         Ideal packing:
          number of NLRIs in 4k update size = 237 (4k-200/16)
          number of update messages of 4k size = 1.5 million/237 = ~6330
          Total BGP data on wire = 6330 * 4k = ~25.9MB
         Practical packing (5 routes in update message) message):
          size of update message = (16 * 5) + 200 = 280
          Total BGP data on wire = 280 * 300k = ~84MB
         No-packing case (1 route per update message) message):
          size of update message = 16 + 200 = 216
          Total BGP data on wire = 216 * 1.5 million = ~324MB
]]></artwork>
            </figure>
      </t>

      <t>CASE B: BGP data exchanged for SR label index
        <figure> index:</t>
      <artwork><![CDATA[
    Consider 200 bytes of shared attributes
    CAR SAFI signal Label in non-key TLV part of NLRI
       Each NLRI size for AFI 1
			= 12(key) + 5(label) + 9(Index) = 26 bytes
         Ideal packing:
          number of NLRIs in 4k update size = 146 (4k-200/26)
          number of update messages of 4k size = 1.5 million/146 = 6726
          Total BGP data on wire = 10274 * 4k = ~42MB
         Practical packing (5 routes in update message)
          size of update message = (26 * 5) + 200 = 330
          Total BGP data on wire = 330 * 300k = ~99MB
         No-packing case (1 route per update message)
          size of update message = 26 + 200 = 226
          Total BGP data on wire = 226 * 1.5 million = ~339MB
    SAFI 128 8277 style encoding with label in NLRI
       Each NLRI size for AFI 1 = 13(key) + 3(label) = 16 bytes
         Ideal packing packing:
          Not supported as label index is encoded in Prefix-SID
							Attribute
							attribute
         Practical packing (5 routes in update message) message):
          Not supported as label index is encoded in Prefix-SID
							Attribute
							attribute
         No-packing case (1 route per update message) message):
          size of update message = 16 + 210 = 226
          Total BGP data on wire = 216 * 1.5 million = ~339MB
]]></artwork>
            </figure>
      </t>

      <t>CASE C: BGP data exchanged with 128 bit single SRv6 SID
        <figure> SID:</t>
      <artwork><![CDATA[
    Consider 200 bytes of shared attributes
    CAR SAFI signal Label in non-key TLV part of NLRI
       Each NLRI size for AFI 1 = 12(key) + 18(Srv6 SID) = 30 bytes
         Ideal packing:
          number of NLRIs in 4k update size = 126 (4k-200/30)
          number of update messages of 4k size = 1.5 million/126 = ~12k
          Total BGP data on wire = 12k * 4k = ~49MB
         Practical packing (5 routes in update message) message):
          size of update message
			= (30 * 5) + 236 (including Prefix SID) Prefix-SID) = 386
          Total BGP data on wire = 386 * 300k = ~115MB
         No-packing case (1 route per update message) message):
          size of update message = 12 + 236 (SID in Prefix SID) Prefix-SID) = 252
          Total BGP data on wire = 252 * 1.5 million = ~378MB
    SAFI 128 8277 style encoding with label in NLRI (No transposition)
       Each NLRI size for AFI 1 = 13(key) + 3(label) = 16 bytes
         Ideal packing packing:
          Not supported as label index is encoded in Prefix-SID
							Attribute
							attribute
         Practical packing (5 routes in update message) message):
          Not supported as label index is encoded in Prefix-SID
							Attribute
							attribute
         No-packing case (1 route per update message) message):
          size of update message = 16 + 236 = 252
          Total BGP data on wire = 252 * 1.5 million = ~378MB
]]></artwork>
            </figure>
      </t>

      <t>BGP data exchanged with SRv6 SID 4 bytes transposition into SRv6 SID TLV
        <figure> TLV:</t>
      <artwork><![CDATA[
    Consider 200 bytes of shared attributes
    CAR SAFI signal Label in non-key TLV part of NLRI
       Each NLRI size for AFI 1 = 12(key) + 6(Srv6 SID) = 18 bytes
         Ideal packing:
          number of NLRIs in 4k update size = 211 (4k-200/18)
          number of update messages of 4k size = 1.5 million/211 = ~7110
          Total BGP data on wire = 7110 * 4k = ~29MB
         Practical packing (5 routes in update message) message):
          size of update message
			= (18 * 5) + 236 (including Prefix SID) Prefix-SID) = 326
          Total BGP data on wire = 326 * 300k = ~98MB
         No-packing case (1 route per update message) message):
          size of update message
			= 12 + 236 (SID in Prefix-SID Attribute) attribute) = 252
          Total BGP data on wire = 252 * 1.5 million = ~378MB
]]></artwork>
            </figure>
    </section>

    <section anchor="Acknowledgements" numbered="false">
      <name>Acknowledgements</name>
      <t>
      The authors would like to acknowledge the invaluable contributions of
      many collaborators towards the BGP CAR solution and this document in
      providing input about use cases, participating in brainstorming and
      mailing list discussions and in reviews of the solution and draft
      revisions. In addition to the contributors listed in the Contributors
      section, the authors would like to thank <contact fullname="Robert
      Raszuk"/>, <contact fullname="Bin Wen"/>, <contact fullname="Chaitanya
      Yadlapalli"/>, <contact fullname="Satoru Matsushima"/>, <contact
      fullname="Moses Nagarajah"/>, <contact fullname="Gyan Mishra"/>,
      <contact fullname="Jorge Rabadan"/>, <contact fullname="Daniel Voyer"/>,
      <contact fullname="Stephane Litkowski"/>, <contact fullname="Hannes
      Gredler"/>, <contact fullname="Jose Liste"/>, <contact fullname="Jakub
      Horn"/>, <contact fullname="Brent Foster"/>, <contact fullname="Dave
      Smith"/>, <contact fullname="Jiri Chaloupka"/>, <contact fullname="Miya
      Kohno"/>, <contact fullname="Kamran Raza"/>, <contact fullname="Zafar
      Ali"/>, <contact fullname="Xing Jiang"/>, <contact fullname="Oleksander
      Nestorov"/>, <contact fullname="Peter Psenak"/>, <contact
      fullname="Kaliraj Vairavakkalai"/>, <contact fullname="Natrajan
      Venkataraman"/>, <contact fullname="Srihari Sangli"/>, <contact
      fullname="Ran Chen"/>, and <contact fullname="Jingrong Xie"/>. </t>
      <t>The authors also appreciate the detailed reviews and astute
      suggestions provided by <contact fullname="Sue Hares"/> (as document
      shepherd), <contact fullname="Jeff Haas"/>, <contact fullname="Yingzhen
      Qu"/>, and <contact fullname="John Scudder"/> that have greatly improved
      the document.</t>
    </section>

    <section anchor="Contributors" numbered="false">
      <name>Contributors</name>
        <t>The following people gave substantial contributions to the content
        of this document and should be considered as coauthors:</t>

    <contact fullname="Clarence Filsfils">
      <organization>Cisco Systems</organization>
      <address>
        <postal>
          <country>Belgium</country>
        </postal>
        <email>cfilsfil@cisco.com</email>
      </address>
    </contact>

    <contact fullname="Bruno Decraene">
      <organization>Orange</organization>
      <address>
        <postal>
          <country>France</country>
        </postal>
        <email>bruno.decraene@orange.com</email>
      </address>
    </contact>

    <contact fullname="Luay Jalil">
      <organization>Verizon</organization>
      <address>
        <postal>
          <country>United States of America</country>
        </postal>
        <email>luay.jalil@verizon.com</email>
      </address>
    </contact>

    <contact fullname="Yuanchao Su">
      <organization>Alibaba, Inc</organization>
      <address>
        <email>yitai.syc@alibaba-inc.com</email>
      </address>
    </contact>

    <contact fullname="Jim Uttaro">
      <organization>Individual</organization>
      <address>
        <postal>
          <country>United States of America</country>
        </postal>
        <email>juttaro@ieee.org</email>
      </address>
    </contact>

    <contact fullname="Jim Guichard">
      <organization>Futurewei</organization>
      <address>
        <postal>
          <country>United States of America</country>
        </postal>
        <email>james.n.guichard@futurewei.com</email>
      </address>
    </contact>

    <contact fullname="Ketan Talaulikar">
      <organization>Cisco Systems</organization>
      <address>
        <postal>
          <country>India</country>
        </postal>
        <email>ketant.ietf@gmail.com</email>
      </address>
    </contact>

    <contact fullname="Keyur Patel">
      <organization>Arrcus, Inc</organization>
      <address>
        <postal>
          <country>United States of America</country>
        </postal>
        <email>keyur@arrcus.com</email>
      </address>
    </contact>

    <contact fullname="Haibo Wang">
      <organization>Huawei Technologies</organization>
      <address>
        <postal>
          <country>China</country>
        </postal>
        <email>rainsword.wang@huawei.com</email>
      </address>
    </contact>

    <contact fullname="Jie Dong">
      <organization>Huawei Technologies</organization>
      <address>
        <postal>
          <country>China</country>
        </postal>
        <email>jie.dong@huawei.com</email>
      </address>
    </contact>

    <t>Additional contributors:</t>

    <contact fullname="Dirk Steinberg">
      <organization>Lapishills Consulting Limited</organization>
      <address>
        <postal>
          <country>Germany</country>
        </postal>
        <email>dirk@lapishills.com</email>
      </address>
    </contact>

    <contact fullname="Israel Means">
      <organization>AT&amp;T</organization>
      <address>
        <postal>
          <country>United States of America</country>
        </postal>
        <email>im8327@att.com</email>
      </address>
    </contact>

    <contact fullname="Reza Rokui">
      <organization>Ciena</organization>
      <address>
        <postal>
          <country>United States of America</country>
        </postal>
        <email>rrokui@ciena.com</email>
      </address>
    </contact>
    </section>

  </back>
</rfc>

<!-- [rfced] Formatting:

a) FYI, we add line breaks in the artwork so it fits within 72-character line
limit. Specifically, please review the artworks in Appendices C.1, C.2, and
C.3 titled "Packet Forwarding" and let us know if the line breaks should be
changed.

In addition, please consider whether any artwork elements should be tagged as
sourcecode or a different element.

b) Please review whether any of the notes in this document
should be in the <aside> element. It is defined as "a container for
content that is semantically less important or tangential to the
content that surrounds it" (https://authors.ietf.org/en/rfcxml-vocabulary#aside).
-->

<!-- [rfced] FYI, we added expansions for abbreviations upon first use
per Section 3.6 of RFC 7322 ("RFC Style Guide"). Please review each
expansion in the document carefully to ensure correctness.

Autonomous Systems (ASes)
VPN Routing and Forwarding (VRF)
Provider Edge (PE)
Customer Edge (CE)
Segment Routing over MPLS (SR-MPLS)
Label Switched Paths (LSPs)
Network Layer Reachability Information (NLRI)
Network Function Virtualization (NFV)
Segment Routing Global Block (SRGB)
Outgoing Interface (OIF)
end-to-end (E2E)
Longest Prefix Match (LPM)
pseudowire (PW)
Penultimate Segment Pop (PSP)
-->

<!-- [rfced] Terminology: Please review the following questions we have regarding
the terminology used in this document.

a) We note different capitalization of the terms below. Please review and let
us know each term should appear for consistency.

Label Index vs. label index

Label vs. label

Color value vs. color value

NLRI Type vs. NLRI type

NLRI Length vs. NLRI length

Key Length vs. Key length vs. key length

b) "Flex Algo" appears in various forms. Please review and let us know
how to update for consistency:

Flex-Algo vs. Flex Algo vs. FlexAlgo

Flex Algo 128 vs. Flex-Algo 128 vs. Flex-Algo FA128 vs. FA 128 vs. FA128

c) How should "prefix" be capitalized in the different instances below?

BGP CAR IP Prefix routes vs. BGP CAR IP prefix route

CAR IP prefix route vs. CAR IP Prefix route

IP Prefix vs. IP prefix

d) We note different use of hyphens and quotation marks in the instances
below. How would you like these items to be stylized for consistency?

low-delay vs. 'low-delay' vs. "low-delay" vs. "low delay"

low-cost vs. low cost
-->

<!-- [rfced] Terminology: We have already updated (or plan to update) the
terms below for consistency. Please review and let us know any objections.

a) We note different uses of the terms below. For consistency, we plan to
update the item on the left of the arrow to the term on the right.

Non-Key TLVs -> non-key TLVs

multi-protocol -> multiprotocol (for consistency with RFC 4760)

Label Index TLV -> Label-Index TLV (for consistency with RFC 8669)

data-plane -> data plane

control-plane -> control plane

SR policy, SR-policy, SR-Policy -> SR Policy (for consistency with RFC 9256)

b) The terms "border router" and "transport RR" appear throughout the document
after their abbreviations "BR" and "TRR" are introduced. For consistency, may
we update to use the abbreviations (after they are first introduced)?

c) We note "Extended Community" and "Local Color Mapping" are hyphenated
differently throughout this document (some examples below). For consistency
with RFCs 9012 and 9256, may we update these instances to "Extended Community"
and "Local Color Mapping" (no hyphens)?

Local-Color-Mapping Extended-Community (LCM-EC)
Local Color Mapping (LCM) Extended Community
Local Color Mapping Extended-Community

Route Target (RT) Extended-Communities
Transitive Opaque Extended-Community
BGP Extended-Community

d) FYI - We have already updated the terms below as follows for consistency
with their relevant RFCs.

RT-Constrain -> RT Constrain (per RFC 4684)
Prefix-SID Attribute -> Prefix-SID attribute (per RFC 8669)
BGP Prefix-SID Attribute -> BGP Prefix-SID attribute (per RFC 8669)
SRv6 service SID -> SRv6 Service SID (per RFC 9252)
SR Domain -> SR domain (per RFC 8402)
END behavior -> End behavior (per RFC 8986)
Route Target (RT) Extended-Communities -> Route Target (RT) Extended Communities (per RFC 4360)
AIGP Attribute -> AIGP attribute (per RFC 7311)

e) Is the term  "CAR color-aware path" (3 instances) necessary, or should
it simply be "CAR path" (10 instances)?

Section 1.2
      -  V/v is steered on BGP CAR color-aware path
      -  V/v is steered on a BGP CAR color-aware path that is itself ...

Section 3:
    All the steering variations described in [RFC9256] are
    applicable to BGP CAR color-aware paths: on-demand steering, ...
-->

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

a) For example, please consider whether "native" should be updated in the
instances below:

   Section 2.7.  Native MultiPath Capability

   Native support for multiple transport encapsulations (e.g., MPLS, SR, SRv6, IP)

   Native encoding of SIDs avoids robustness issue...

   Service traffic encapsulated with SRv6 Service SID B:C11:2:DT4:: is natively
   steered hop by hop along IPv6 routed path...

   Encapsulated service traffic is natively steered along IPv6 routed path...

b) In addition, please consider whether "traditional" should be updated for clarity.
While the NIST website
<https://web.archive.org/web/20250214092458/https://www.nist.gov/nist-research-library/nist-technical-series-publications-author-instructions#table1>
indicates that this term is potentially biased, it is also ambiguous.
"Tradition" is a subjective term, as it is not the same for everyone.
There are 4 instances currently:

         If a color-aware path is not
         available, local policy may map to a traditional routing/TE
         path (e.g., BGP LU, RSVP-TE, IGP/LDP).

      Intra-domain resolution:
         BGP CAR route maps to an intra-domain color-aware path (e.g.,
         SR Policy, IGP Flex-Algo, BGP CAR) or a traditional routing/TE
         path (e.g., RSVP-TE, IGP/LDP, BGP-LU).

   *  Local policy may map the CAR route to traditional mechanisms that
      are unaware of color or that provide best-effort, such as RSVP-TE,
      IGP/LDP, BGP LU/IP (e.g., Appendix A.3.2) for brownfield
      scenarios.

   However, to be compatible
   with traditional operational usage, the CAR IP Prefix route is
   allowed to be without color for best-effort.
-->