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

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

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

  <front>
    <title abbrev="BGP Classful Transport Planes">BGP Classful Transport
    Planes</title>
    <seriesInfo name="RFC" value="9832"/>
    <author fullname="Kaliraj Vairavakkalai" initials="K." role="editor" surname="Vairavakkalai">
      <organization>Juniper Networks, Inc.</organization>
      <address>
        <postal>
          <street>1133 Innovation Way,</street> Way</street>
          <city>Sunnyvale</city>
          <region>CA</region>
          <code>94089</code>

          <country>US</country>
          <country>United States of America</country>
        </postal>
        <email>kaliraj@juniper.net</email>
      </address>
    </author>
    <author fullname="Natrajan Venkataraman" initials="N." role="editor" surname="Venkataraman">
      <organization>Juniper Networks, Inc.</organization>
      <address>
        <postal>
          <street>1133 Innovation Way,</street> Way</street>
          <city>Sunnyvale</city>
          <region>CA</region>
          <code>94089</code>

          <country>US</country>
          <country>United States of America</country>
        </postal>
        <email>natv@juniper.net</email>
      </address>
    </author>
    <date day="28" month="2" month="August" year="2025"/>

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

<keyword>BGP-CT, CT, Intent Based Routing, BGP Service Mapping</keyword>

    <abstract>
      <t>This document specifies a mechanism referred to as "Intent Driven
      Service Mapping". The mechanism uses BGP to express intent Intent based
      association of overlay routes with underlay routes having specific
      Traffic Engineering (TE) characteristics satisfying a certain Service
      Level Agreement (SLA). This is achieved by defining new constructs to
      group underlay routes with sufficiently similar TE characteristics into
      identifiable classes (called "Transport Classes"), Classes" or "TCs"), that overlay routes
      use as an ordered set to resolve reachability (Resolution Schemes)
      towards service endpoints. These constructs can be used, for example, to
      realize the "IETF Network Slice" defined in the TEAS Network Slices
      framework.</t>
      framework (RFC 9543).</t>
      <t>Additionally, this document specifies protocol procedures for BGP
      that enable dissemination of service mapping information in a network
      that may span multiple cooperating administrative domains. These domains
      may be administered either by the same provider or by closely
      coordinating providers. A new BGP address family that leverages RFC 4364
      ("BGP/MPLS the procedures described in
      "BGP/MPLS IP Virtual Private Networks (VPNs)") procedures (VPNs)" (RFC 4364) and follows the NLRI encoding described in
      RFC 8277 ("Using BGP to Bind MPLS Labels to Address Prefixes") NLRI
      encoding is defined to enable each advertised underlay route to be
      identified by its class. This new address family is called "BGP Classful
      Transport", a.k.a., BGP CT.</t>
      Transport" (or "BGP CT").</t>
    </abstract>

    <note title="Requirements Language">

      <t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
      NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED",
      "MAY", and "OPTIONAL" in this document are to be interpreted as
      described in BCP 14 <xref target="RFC2119"></xref> <xref target="RFC8174"></xref>
      when, and only when, they appear in all capitals, as shown here.</t>

    </note>
  </front>
  <middle>
    <section title="Introduction"> numbered="true" toc="default">
      <name>Introduction</name>
      <t>Provider networks typically span across multiple domains where each
      domain can either represent an Autonomous System (AS) or an Interior
      Gateway Protocol (IGP) region within an AS. In these networks, several
      services are provisioned between different pairs of service endpoints
      (e.g., Provider Edge (PE) nodes), nodes) that can either be either in the same domain
      or across different domains.</t>
      <t><xref target="RFC9315"></xref> target="RFC9315" format="default"/> defines "Intent" as, "A as:</t>
      <blockquote><t>A set of operational
      goals (that a network should meet) and outcomes (that a network is supposed
      to deliver) defined in a declarative manner without specifying how to achieve
      or implement them.".</t> them.</t></blockquote>
      <t> This document prescribes constructs and procedures
      to realize "Intent", "Intent" and enable provider networks to be able to forward
      service traffic based on service specific intent, Intent from end-to-end across service
      endpoints.</t>
      <t>The mechanisms described in this document achieve "Intent Driven
      Service Mapping" between any pair of service endpoints by:<list> by:</t>
      <ul spacing="normal">
        <li>
          <t>Provisioning end-to-end "intent-aware" "Intent aware" paths using BGP. For
          example, low latency path, best effort a low-latency path or a best-effort path.</t>
        </li>
        <li>
          <t>Expressing a desired intent. Intent. For example, use low latency a low-latency path
          with a fallback to the best effort best-effort path.</t>
        </li>
        <li>
          <t>Forwarding service traffic "only" using end-to-end "intent-aware" "Intent aware"
          paths honoring that desired intent.</t>
        </list></t> Intent.</t>
        </li>
      </ul>
      <t>The constructs and procedures defined in this document apply equally
      to intra-AS as well as and inter-AS (a.k.a. multi-AS) Option deployments in the style of option A, Option B option B, and
      Option
      option C (Section 10, <xref target="RFC4364"/>) style deployments (<xref target="RFC4364" sectionFormat="of" section="10"/>) in
      provider networks.</t>
      <t>Such networks provision intra-domain transport tunnels between a pair
      of endpoints, typically a service node or a border node that service traffic
      traverses through. These tunnels are signaled using various tunneling
      protocols depending on the forwarding architecture used in the domain,
      which can be Multiprotocol Label Switching (MPLS), Internet Protocol
      version 4 (IPv4), or Internet Protocol version 6 (IPv6).</t>
      <t>The mechanisms defined in this document allow different tunneling
      technologies to become Transport Class TC aware. These can be applied
      homogeneously to intra-domain tunneling technologies used in existing
      brownfield networks as well as new greenfield networks. For clarity,
      only some tunneling technologies are detailed in this document. In some
      examples
      examples, only MPLS Traffic Engineering (TE) examples are is described.
      Other tunneling technologies have been described in detail in other
      documents and (and only an overview has been included in this document. document). For
      example, the details for Segment Routing over IPv6 (SRv6) are provided in <xref
      target="BGP-CT-SRv6"/>, target="I-D.ietf-idr-bgp-ct-srv6" format="default"/> and an overview is provided in <xref
      target="SRv6-Support"/>.</t> target="SRv6-Support" format="default"/>.</t>
      <t>Customers need to be able to express desired Intent to the network,
      and the network needs to have constructs able to enact the customer's
      intent.
      Intent. The network constructs defined in this document are used to
      classify and group these intra-domain tunnels based on various
      characteristics, like TE characteristics (e.g., low latency), low-latency), into
      identifiable classes that can pass "intent-aware" "Intent aware" traffic. These
      constructs enable services to signal their intent Intent to use one or more
      identifiable classes, classes and mechanisms to selectively map traffic onto
      "intent-aware"
      "Intent aware" tunnels for these classes.</t>
      <t>This document introduces a new BGP address family called "BGP
      Classful Transport", that Transport (BGP CT)", which extends/stitches intent-aware Intent aware intra-domain
      tunnels belonging to the same class across domain boundaries, boundaries to
      establish end-to-end intent-aware Intent aware paths between service endpoints.</t>
      <t><xref target="Intent-Routing-Color"/> target="I-D.hr-spring-intentaware-routing-using-color" format="default"/> describes various use cases and
      applications of the procedures described in this document.</t>
      <t><xref target="Appendix C"/> target="Appendix_C" format="default"/> provides an outline of the design
      philosophy behind this specification. In particular, readers who are
      already familiar with one or more BGP VPN technologies may want to
      review this appendix before reading the main body of the
      specification.</t>
    </section>
    <section title="Terminology">
      <t>ABR: Area numbered="true" toc="default">
      <name>Terminology</name>
      <section numbered="true" toc="default">
	<name>Abbreviations</name>
      <dl spacing="normal" newline="false">
	<dt>ABR:</dt><dd>Area Border Router (Readvertises (readvertises BGP CT or BGP LU
	routes with
      next hop self)</t>

      <t>AFI: Address NH self)</dd>
	<dt>AFI:</dt><dd>Address Family Identifier</t>

      <t>AS: Autonomous System</t>

      <t>ASBR: Autonomous Identifier</dd>
	<dt>AS:</dt><dd>Autonomous System</dd>
	<dt>ASBR:</dt><dd>Autonomous System Border Router</t>

      <t>ASN: Autonomous Router</dd>
	<dt>ASN:</dt><dd>Autonomous System Number</t>

      <t>BGP VPN: VPNs Number</dd>
	<dt>BGP VPN:</dt><dd>VPNs built using RD, RD or RT; architecture described
	in
      RFC4364</t>

      <t>BGP LU: BGP <xref target="RFC4364"/></dd>
	<dt>BGP LU:</dt><dd>BGP Labeled Unicast family (AFI/SAFIs 1/4, 2/4)</t>

      <t>BGP CT: BGP 2/4)</dd>
	<dt>BGP CT:</dt><dd>BGP Classful Transport family (AFI/SAFIs 1/76, 2/76)</t>

      <t>BN: Border Node</t>

      <t>CBF: Class Based Forwarding</t>

      <t>CsC: Carrier serving 2/76)</dd>
	<dt>BN:</dt><dd>Border Node</dd>
	<dt>CBF:</dt><dd>Class-Based Forwarding</dd>
	<dt>CCA:</dt><dd>Community Carrying Attribute</dd>
	<dt>CsC:</dt><dd>Carriers' Carriers (serving the Carrier VPN</t>

      <t>DSCP: Differentiated VPN)</dd>
	<dt>DSCP:</dt><dd>Differentiated Services Code Point</t>

      <t>EP: Endpoint of Point</dd>
	<dt>EP:</dt><dd>Endpoint (of a tunnel, e.g. e.g., a loopback address in the network</t>

      <t>EPE: Egress network)</dd>
	<dt>EPE:</dt><dd>Egress Peer Engineering</t>

      <t>eSN: Egress Engineering</dd>
	<dt>eSN:</dt><dd>Egress Service Node</t>

      <t>FEC: Forwarding Node</dd>
	<dt>FEC:</dt><dd>Forwarding Equivalence Class</t>

      <t>FRR: Fast ReRoute (Pre-programmed next hop Class</dd>
	<dt>FRR:</dt><dd>Fast Reroute (Preprogrammed NH leg in forwarding)</t>

      <t>iSN: Ingress forwarding)</dd>
	<dt>iSN:</dt><dd>Ingress Service Node</t>

      <t>L-ISIS: Labeled Node</dd>
	<dt>L-ISIS:</dt><dd>Labeled ISIS (RFC 8667)</t>

      <t>LSP: Label (see RFC 8667)</dd>
	<dt>LSP:</dt><dd>Label Switched Path</t>

      <t>MPLS: Multi Protocol Path</dd>
	<dt>MPLS:</dt><dd>Multiprotocol Label Switching</t>

      <t>NLRI: Network Switching</dd>
	<dt>NH:</dt><dd>Next Hop</dd>
	<dt>NLRI:</dt><dd>Network Layer Reachability Information</t>

      <t>PE: Provider Edge</t>

      <t>PIC: Prefix scale Information</dd>
	<dt>PE:</dt><dd>Provider Edge</dd>
	<dt>PIC:</dt><dd>Prefix Independent Convergence</t>

      <t>PNH: Protocol Convergence</dd>
	<dt>PNH:</dt><dd>Protocol Next Hop address (address carried in a BGP Update message</t>

      <t>RD: Route Distinguisher</t>

      <t>RD:EP : BGP CT Prefix consisting of Route UPDATE message)</dd>
	<dt>RD:</dt><dd>Route Distinguisher</dd>
	<dt>RD:EP:</dt><dd>Route Distinguisher and
      Endpoint</t>

      <t>RSVP-TE: Resource
	Endpoint (in a BGP Prefix)</dd>
	<dt>RSVP-TE:</dt><dd>Resource Reservation Protocol - Traffic Engineering</t>

      <t>RT: Engineering</dd>
	<dt>RT:</dt><dd>Route Target (as used in Route Target extended community</t>

      <t>RTC: Route community)</dd>
	<dt>RTC:</dt><dd>Route Target Constrain (RFC 4684)</t>

      <t>SAFI: Subsequent Constraint <xref target="RFC4684"/></dd>
	<dt>SAFI:</dt><dd>Subsequent Address Family Identifier</t>

      <t>SID: Segment Identifier</t>

      <t>SLA: Service Identifier</dd>
	<dt>SID:</dt><dd>Segment Identifier</dd>
	<dt>SLA:</dt><dd>Service Level Agreement</t>

      <t>SN: Service Node</t>

      <t>SR: Segment Routing</t>

      <t>SRTE: Segment Agreement</dd>
	<dt>SN:</dt><dd>Service Node</dd>
	<dt>SR:</dt><dd>Segment Routing</dd>
	<dt>SRTE:</dt><dd>Segment Routing Traffic Engineering</t>

      <t>TC: Transport Class</t>

      <t>TC ID: Transport Engineering</dd>
	<dt>TC:</dt><dd>Transport Class</dd>
	<dt>TC ID:</dt><dd>Transport Class Identifier</t>

      <t>TC-BE: Identifier</dd>
	<dt>TC-BE:</dt><dd>Transport Class - Best Effort Transport Class</t>

      <t>TE: Traffic Engineering</t>

      <t>TEA: Tunnel Effort</dd>
	<dt>TE:</dt><dd>Traffic Engineering</dd>
	<dt>TEA:</dt><dd>Tunnel Encapsulation Attribute, attribute type Attribute (attribute code 23</t>

      <t>TRDB: Transport 23)</dd>
	<dt>TRDB:</dt><dd>Transport Route Database</t>

      <t>UHP: Ultimate Database</dd>
	<dt>UHP:</dt><dd>Ultimate Hop Pop</t>

      <t>VRF: Virtual Popping</dd>
	<dt>VRF:</dt><dd>Virtual Routing and Forwarding table</t> (used with a table)</dd>
      </dl>
      </section>
      <section title="Definitions numbered="true" toc="default">
        <name>Definitions and Notations">
        <t>BGP Community Carrying Attribute (CCA) : A Notations</name>

	<dl spacing="normal" newline="true">

          <dt>BGP CCA:</dt><dd>A BGP attribute
          that carries community. Examples of BGP CCA are: CCAs are COMMUNITIES
          (attribute code 8), EXTENDED COMMUNITIES (attribute code 16), IPv6
          Address Specific Extended Community (attribute code 25), and
          LARGE_COMMUNITY (attribute code 32).</t>

        <t>color:0:100 : This 32).</dd>

          <dt>color:0:100 or col-100:</dt><dd>This notation denotes a Color extended
          community as defined in RFC 9012 <xref target="RFC9012"/> with the Flags "Flags" field set to 0 and
          the color "Color Value" field set to 100.</t>

        <t>End to End Tunnel: A 100.</dd>
          <dt>End-to-End Tunnel:</dt><dd>A tunnel spanning several adjacent
          tunnel domains created by "stitching" them together using MPLS
          labels or an equivalent identifier based on the forwarding architecture.</t>

        <t>Import processing: Receive side
          architecture.</dd>
          <dt>Import processing:</dt><dd>Receive-side processing of an overlay
          route, including things like import policy import-policy application, resolution scheme
        selection Resolution Scheme selection, and next hop resolution.</t>

        <t>Mapping Community: Any NH resolution.</dd>

          <dt>Mapping Community:</dt><dd>Any BGP CCA (e.g., Community,
          Extended Community) on an overlay route that maps to a Resolution
          Scheme. For example, color:0:100, transport-target:0:100.</t>

        <t>Provider Namespace: Internal transport-target:0:100.</dd>
          <dt>Provider Namespace:</dt><dd>Internal Infrastructure address
          space in
        Provider a provider network managed by the Operator.</t>

        <t>Resolution Scheme: A operator.</dd>
          <dt>Resolution Scheme:</dt><dd>A construct comprising of an ordered
          set of TRDBs to resolve next hop reachability, NH reachability for realizing a
          desired
        intent.</t>

        <t>Service Family: A Intent.</dd>
          <dt>Service Family:</dt><dd>A BGP address family used for
          advertising routes for destinations in "data traffic". For example,
          AFI/SAFIs 1/1 or
        1/128.</t>

        <t>Service Prefix: A destinations 1/128.</dd>
          <dt>Service Prefix:</dt><dd>A destination in "data traffic". Routes
          to these prefixes are carried in a Service family.</t>

        <t>Transport Family: A Family.</dd>
          <dt>Transport Family:</dt><dd>A BGP address family used for
          advertising tunnels, which are are, in turn turn, used by service routes for
          resolution. For example, AFI/SAFIs 1/4 or 1/76.</t>

        <t>Transport Tunnel : A 1/76.</dd>
          <dt>Transport Tunnel:</dt><dd>A tunnel over which a service may
          place traffic.  Such a tunnel can be provisioned or signaled using a
          variety of means.  For example, Generic Routing Encapsulation (GRE),
          UDP, LDP, RSVP-TE, IGP FLEX-ALGO or SRTE.</t>

        <t>Transport, Transport Layer: A Flexible Algorithm (Flex-Algo), or SRTE.</dd>
          <dt>Transport Layer:</dt><dd>A layer in the network that
          contains Transport Tunnels and Transport Families.</t>

        <t>Tunnel Route: A Families.</dd>
          <dt>Tunnel Route:</dt><dd>A Route to Tunnel Destination/Endpoint
          that is installed at the headend (ingress) of the tunnel.</t>

        <t>Tunnel Domain: A tunnel.</dd>
          <dt>Tunnel Domain:</dt><dd>A domain of the network containing Service Nodes
        (SNs)
          SNs and Border Nodes (BNs) BNs under a single
          administrative control that has tunnels between them.</t>

        <t>Brownfield network: An them.</dd>
          <dt>Brownfield network:</dt><dd>An existing network that is already
          in service, deploying a chosen set of technologies and
          hardware. Enhancements and upgrades to such network deployments
          protect return on investment, investment and should consider continuity of service.</t>

        <t>Greenfield network: A
          service.</dd>
          <dt>Greenfield network:</dt><dd>A new network deployment which that can
          make choice choices of new technology or hardware as needed, needed with fewer
          constraints than brownfield network.</t>

        <t>Transport Class: A network.</dd>
          <dt>Transport Class:</dt><dd>A construct to group transport tunnels
          offering similar SLA (Ref: Sec 4.1).</t>

        <t>Transport SLAs (see <xref target="tc-te"/>).</dd>
          <dt>Transport Class RT: A RT:</dt><dd>A Route Target Extended Community extended community
          used to identify a specific Transport Class.</t>

        <t>transport-target:0:100 : This Class.</dd>
          <dt>transport-target:0:100:</dt><dd>This notation denotes a
          Transport Class RT
        extended community as defined in this document
          with the "Transport Class ID" field set to 100.</t>

        <t>Transport 100.</dd>
          <dt>Transport Route Database: At Database:</dt><dd>At the SN and BN, a Transport
          Class has an associated Transport Route Database TRDB that collects its Tunnel
        Routes.</t>

        <t>Transport Plane: An
          tunnel routes.</dd>
          <dt>Transport Plane:</dt><dd>An end-to-end plane consisting of
          transport tunnels belonging to the same Transport Class.</t> Class.</dd>
	</dl>
      </section>
      <section numbered="true" toc="default">
	<name>Requirements Language</name>
	        <t>
    The key words "<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 "<bcp14>OPTIONAL</bcp14>" in this document are to be
    interpreted as described in BCP&nbsp;14 <xref target="RFC2119"/> <xref
    target="RFC8174"/> when, and only when, they appear in all capitals, as
    shown here.
        </t></section>

    </section>
    <section title="Architecture Overview"> numbered="true" toc="default">
      <name>Architecture Overview</name>
      <t>This section describes the BGP CT architecture with a brief
      illustration.</t>
      illustration:</t>

<figure title="BGP CT Overview with Example Topology" anchor="ArchOv"><artset><artwork  type="svg"><svg xmlns="http://www.w3.org/2000/svg" version="1.1" height="496" width="560" width="536" viewBox="0 0 560 536 496" class="diagram" text-anchor="middle" font-family="monospace" font-size="13px" stroke-linecap="round">
<path d="M 24,240 L 24,320" fill="none" stroke="black"/>
<path d="M 424,64 L 424,96" fill="none" stroke="black"/>
<path d="M 472,240 L 472,320" fill="none" stroke="black"/>
<path d="M 240,32 L 344,32" fill="none" stroke="black"/>
<path d="M 360,32 L 384,32" fill="none" stroke="black"/>
<path d="M 104,64 L 176,64" fill="none" stroke="black"/>
<path d="M 328,64 L 376,64" fill="none" stroke="black"/>
<path d="M 72,112 L 88,112" fill="none" stroke="black"/>
<path d="M 240,110 L 256,110" fill="none" stroke="black"/><path d="M 240,114 L 256,114" fill="none" stroke="black"/>
<path d="M 312,112 L 328,112" fill="none" stroke="black"/>
<path d="M 104,192 L 168,192" fill="none" stroke="black"/>
<path d="M 312,192 L 400,192" fill="none" stroke="black"/>
<path d="M 40,224 L 48,224" fill="none" stroke="black"/>
<path d="M 136,224 L 152,224" fill="none" stroke="black"/>
<path d="M 360,224 L 376,224" fill="none" stroke="black"/>
<path d="M 448,224 L 456,224" fill="none" stroke="black"/>
<path d="M 48,240 L 64,240" fill="none" stroke="black"/>
<path d="M 272,240 L 288,240" fill="none" stroke="black"/>
<path d="M 48,288 L 64,288" fill="none" stroke="black"/>
<path d="M 272,288 L 288,288" fill="none" stroke="black"/>
<path d="M 40,336 L 48,336" fill="none" stroke="black"/>
<path d="M 448,336 L 456,336" fill="none" stroke="black"/>
<path d="M 56,80 L 72,112" fill="none" stroke="black"/>
<path d="M 320,80 L 328,96" fill="none" stroke="black"/>
<path d="M 376,64 L 384,48" fill="none" stroke="black"/>
<path d="M 40,224 C 31.16936,224 24,231.16936 24,240" fill="none" stroke="black"/>
<path d="M 456,224 C 464.83064,224 472,231.16936 472,240" fill="none" stroke="black"/>
<path d="M 40,336 C 31.16936,336 24,328.83064 24,320" fill="none" stroke="black"/>
<path d="M 456,336 C 464.83064,336 472,328.83064 472,320" fill="none" stroke="black"/>
<path d="M 124,88 L 148,88" fill="none" stroke="black"/>
<path d="M 364,88 L 388,88" fill="none" stroke="black"/>
<path d="M 120,136 L 140,136" fill="none" stroke="black"/>
<path d="M 360,136 L 380,136" fill="none" stroke="black"/>
<polygon class="arrowhead" points="432,64 420,58.4 420,69.6" fill="black" transform="rotate(270,424,64)"/>
<polygon class="arrowhead" points="408,192 396,186.4 396,197.6" fill="black" transform="rotate(0,400,192)"/>
<polygon class="arrowhead" points="368,224 356,218.4 356,229.6" fill="black" transform="rotate(180,360,224)"/>
<polygon class="arrowhead" points="368,32 356,26.4 356,37.6" fill="black" transform="rotate(180,360,32)"/>
<polygon class="arrowhead" points="336,64 324,58.4 324,69.6" fill="black" transform="rotate(180,328,64)"/>
<polygon class="arrowhead" points="280,288 268,282.4 268,293.6" fill="black" transform="rotate(180,272,288)"/>
<polygon class="arrowhead" points="280,240 268,234.4 268,245.6" fill="black" transform="rotate(180,272,240)"/>
<polygon class="arrowhead" points="144,224 132,218.4 132,229.6" fill="black" transform="rotate(180,136,224)"/>
<polygon class="arrowhead" points="112,64 100,58.4 100,69.6" fill="black" transform="rotate(180,104,64)"/>
<polygon class="arrowhead" points="56,288 44,282.4 44,293.6" fill="black" transform="rotate(180,48,288)"/>
<polygon class="arrowhead" points="56,240 44,234.4 44,245.6" fill="black" transform="rotate(180,48,240)"/>
<g class="text">
<text x="132" y="36">INET</text>
<text x="212" y="36">[RR21]</text>
<text x="352" y="36">&lt;</text>
<text x="412" y="36">[RR11]</text>
<text x="144" y="52">Service</text>
<text x="192" y="52">/</text>
<text x="424" y="52">|</text>
<text x="496" y="52">IP1,color:0:100</text> x="480" y="52">IP1,col-100</text>
<text x="60" y="68">[PE21]</text>
<text x="96" y="68">&lt;</text>
<text x="248" y="68">:</text>
<text x="284" y="68">[SN11]</text>
<text x="320" y="68">&lt;</text>
<text x="496" y="68">IP2,color:0:200</text> x="480" y="68">IP2,col-200</text>
<text x="248" y="84">:</text>
<text x="480" y="84">IP3,100:200</text>
<text x="116" y="100">_(</text>
<text x="148" y="100">.)</text>
<text x="248" y="100">:</text>
<text x="356" y="100">_(</text>
<text x="388" y="100">.)</text>
<text x="512" y="100">^^^^^^^^^^^</text> x="496" y="100">^^^^^^^</text>
<text x="104" y="116">(</text>
<text x="156" y="116">_)</text>
<text x="204" y="116">--[BN21]</text>
<text x="284" y="116">[BN11]</text>
<text x="344" y="116">(</text>
<text x="424" y="116">_)-[PE11]</text>
<text x="504" x="496" y="116">Mapping</text>
<text x="116" y="132">(.</text>
<text x="144" y="132">)</text>
<text x="248" y="132">:</text>
<text x="356" y="132">(.</text>
<text x="384" y="132">)</text>
<text x="504" x="496" y="132">Community</text>
<text x="248" y="148">Inter-AS-Link</text>
<text x="248" y="164">:</text>
<text x="248" y="180">[.......AS2:SR-TE........]:[.......AS1:RSVP-TE......]</text>
<text x="200" y="196">Traffic</text>
<text x="272" y="196">Direction</text>
<text x="96" y="228">[PE21]--&lt;</text>
<text x="180" y="228">[BN21]</text>
<text x="320" y="228">[BN21]--&lt;</text>
<text x="404" y="228">[BN11]</text>
<text x="40" y="244">&lt;</text>
<text x="152" y="244">RD1:PE11(L3),PNH=BN21</text>
<text x="248" y="244">:</text>
<text x="264" y="244">&lt;</text>
<text x="376" y="244">RD1:PE11(L1),PNH=BN11</text>
<text x="140" y="260">transport-target:0:100</text>
<text x="248" y="260">:</text>
<text x="364" y="260">transport-target:0:100</text>
<text x="496" y="260">BGP</text>
<text x="248" y="276">:</text>
<text x="516" y="276">Classful</text> x="496" y="276">BGP</text>
<text x="524" y="276">CT</text>
<text x="40" y="292">&lt;</text>
<text x="152" y="292">RD2:PE11(L4),PNH=BN21</text>
<text x="248" y="292">:</text>
<text x="264" y="292">&lt;</text>
<text x="376" y="292">RD2:PE11(L2),PNH=BN11</text>
<text x="520" y="292">Transport</text>
<text x="140" y="308">transport-target:0:200</text>
<text x="248" y="308">:</text>
<text x="364" y="308">transport-target:0:200</text>
<text x="140" y="324">^^^^^^^^^^^^^^^^^^^^^^</text>
<text x="440" y="324">^^^</text>
<text x="112" y="340">Route</text>
<text x="164" y="340">Target</text>
<text x="200" y="340">&amp;</text>
<text x="336" y="340">Transport</text>
<text x="400" y="340">Class</text>
<text x="436" y="340">ID</text>
<text x="112" y="356">Mapping</text>
<text x="184" y="356">Community</text>
<text x="32" y="388">Intents</text>
<text x="76" y="388">at</text>
<text x="108" y="388">SN11</text>
<text x="144" y="388">and</text>
<text x="184" y="388">PE21:</text>
<text x="68" y="420">Scheme1:</text>
<text x="156" y="420">color:0:100,</text>
<text x="268" y="420">(TRDB[TC-100],</text>
<text x="380" y="420">TRDB[TC-BE])</text>
<text x="68" y="436">Scheme2:</text>
<text x="156" y="436">color:0:200,</text>
<text x="268" y="436">(TRDB[TC-200],</text>
<text x="380" y="436">TRDB[TC-BE])</text>
<text x="68" y="452">Scheme3:</text>
<text x="172" y="452">100:200,</text>
<text x="268" y="452">(TRDB[TC-100],</text>
<text x="384" y="452">TRDB[TC-200])</text>
<text x="64" y="468">^^^^^^^</text>
<text x="236" y="468">^^^^</text>
<text x="396" y="468">^^^^^^</text>
<text x="44" y="484">Resolution</text>
<text x="120" y="484">Schemes</text>
<text x="208" y="484">Transport</text>
<text x="272" y="484">Route</text>
<text x="308" y="484">DB</text>
<text x="384" y="484">Transport</text>
<text x="448" y="484">Class</text>
</g>
</svg>
</artwork><artwork  type="ascii-art"><![CDATA[
              INET     [RR21]--------------<<---[RR11]
              Service  /                       /    | IP1,color:0:100 IP1,col-100
    [PE21] <<--------+        : [SN11] <<-----+     ^ IP2,color:0:200 IP2,col-200
      \        ___            :        \     ___    | IP3,100:200
       \     _(  .)           :         \  _(  .)   |     ^^^^^^^^^^^     ^^^^^^^
        +-- (     _) --[BN21]===[BN11]--- (     _)-[PE11] Mapping
             (.__)            :            (.__)         Community
                        Inter-AS-Link
                              :
    [.......AS2:SR-TE........]:[.......AS1:RSVP-TE......]
            ---------Traffic Direction----------->

   .-- [PE21]--<<--[BN21]          [BN21]--<<--[BN11]  --.
  | <<--RD1:PE11(L3),PNH=BN21 : <<--RD1:PE11(L1),PNH=BN11 |
  |   transport-target:0:100  :   transport-target:0:100  | BGP
  |                           :                           | Classful BGP CT
  | <<--RD2:PE11(L4),PNH=BN21 : <<--RD2:PE11(L2),PNH=BN11 | Transport
  |   transport-target:0:200  :   transport-target:0:200  |
  |   ^^^^^^^^^^^^^^^^^^^^^^                         ^^^  |
   '--     Route Target &            Transport Class ID--'
          Mapping Community

Intents at SN11 and PE21:

    Scheme1: color:0:100, (TRDB[TC-100], TRDB[TC-BE])
    Scheme2: color:0:200, (TRDB[TC-200], TRDB[TC-BE])
    Scheme3:     100:200, (TRDB[TC-100], TRDB[TC-200])
    ^^^^^^^                ^^^^               ^^^^^^
Resolution Schemes   Transport Route DB    Transport Class
]]></artwork></artset></figure>

      <t>To achieve end-to-end "Intent Driven Service Mapping", this document
      defines the following constructs and BGP extensions:<list> extensions:</t>
      <ul spacing="normal">
        <li>
          <t>The <xref target="tc">"Transport Class"</xref> "Transport Class" construct (see <xref target="tc" format="default"></xref>) to group
          underlay tunnels.</t>
        </li>
        <li>
          <t>The <xref target="Nexthop_Resoln_Schm">"Resolution Scheme"</xref> "Resolution Scheme" construct (see <xref target="Nexthop_Resoln_Schm" format="default"></xref>)
          for overlay routes with Mapping Community Communities to resolve next
          hop NH reachability from either one or an ordered set of Transport
          Classes.</t>
        </li>
        <li>
          <t>The <xref target="ct-family">"BGP "BGP Classful Transport"</xref> Transport" (see <xref target="ct-family" format="default"></xref>)
          address family to extend these constructs to adjacent domains.</t>
        </list><xref target="ArchOv"/>
        </li>
      </ul>
      <t><xref target="ArchOv" format="default"/> depicts the intra-AS and inter-AS
      application of these constructs. Interactions between SN1 and PE11 describe
      the Intra-AS intra-AS usage. Interactions between PE21 and PE11 describe the Inter-AS inter-AS usage.</t>
      <t> The example topology is an Inter-AS inter-AS
      option C (Section 10, <xref target="RFC4364"/>) network (<xref target="RFC4364" sectionFormat="of" section="10"/>) with two AS domains, domains;
      each domain contains tunnels serving two Intents, e.g. e.g., 'low-latency' denoted
      by color 100 and 'high-bandwidth' denoted by color 200. AS1 is a an RSVP-TE
      network,
      network; AS2 is a an SRTE network. BGP CT and BGP LU are transport families
      used between the two AS domains. IP1, IP2, and IP3 are service prefixes
      (AFI/SAFI: 1/1) behind egress PE11.</t>
      <t>PE21, SN11 SN11, and PE11 are the SNs in this network. SN11 is an ingress
      PE with intra domain intra-domain reachability to PE11. PE21 is an ingress PE with
      inter domain
      inter-domain reachability to PE11.</t>
      <t>The tunneling mechanisms are made "Transport Class" aware. They
      publish their underlay tunnels for a Transport Class into an associated TRDB
      (see <xref target="trdb">"Transport Route Database" (TRDB)</xref>. target="trdb" format="default"></xref>). In <xref
      target="ArchOv"/>, target="ArchOv" format="default"/>, RSVP-TE publishes its underlay tunnels into TRDBs
      created for Transport Class Classes 100 and 200 at BN11 and SN11 within AS1;
      Similarly, SR-TE publishes its underlay tunnels into TRDBs created for
      Transport Class Classes 100 and 200 at PE21 within AS2.</t>
      <t>Resolution Schemes are used to realize Intent. A Resolution Scheme is
      identified by its "Mapping Community", Community" and contains an ordered list of
      transport classes.
      Transport Classes. Overlay routes carry an indication of the desired
      Intent using a BGP community community, which assumes the role of "Mapping Community".</t>
      <t>Egress SN "PE11" advertises service routes with desired  Mapping Community
      e.g. Community, e.g., color:0:100.</t>
      <t>For the Intra-AS intra-AS case, SN1 maps this intra-AS route on RSVP-TE
      tunnels with TC ID 100 by using the Resolution Scheme for color:0:100.</t>
      <t>For the Inter-AS inter-AS case, the underlay route in a TRDB is advertised
      in BGP to extend an underlay tunnel to adjacent domains. A new BGP
      transport family called "BGP Classful Transport", also known as BGP CT
      (AFI/SAFIs 1/76, 2/76) 2/76), is defined for this purpose. BGP CT makes it
      possible to advertise multiple tunnels to the same destination address,
      thus avoiding the need for multiple loopbacks on the Egress Service Node
      (eSN).</t> eSN.</t>
      <t>The BGP CT address family carries transport prefixes across tunnel
      domain boundaries. Its design and operation are analogous to BGP LU
      (AFI/SAFIs 1/4 or 2/4). It disseminates "Transport Class" information
      for the transport prefixes across the participating domains while
      avoiding the need of per-transport class per-TC loopback. This is not possible
      with BGP LU without using per-color loopback. This dissemination makes
      the end-to-end network a "Transport Class" aware tunneled network.</t>
      <t>In <xref target="ArchOv"/>, target="ArchOv" format="default"/>, BGP CT routes are originated at BN11 in
      AS1 with next hop NH "self" towards BN21 in AS2 to extend available RSVP-TE
      tunnels for Transport Class Classes 100 and 200 in AS1. BN21 propagates these
      routes with next hop NH "self" to PE21, which resolves the BGP CT routes
      over SRTE tunnels belonging to same transport class. Thus Transport Class, thus forming a
      BGP CT tunnel for each TC ID at PE21.</t>
      <t>PE21 maps the Inter-AS inter-AS service routes received with color:0:100 from
      AS1 on BGP CT tunnel with TC ID 100 by using the Resolution Scheme for
      color:0:100. Note that this procedure is same as that followed by SN1
      in the Intra-AS intra-AS case.</t>
      <t>The following text illustrates how CT architecture provides tiered
      fallback options at a per-route granularity. <xref target="ArchOv"/>, target="ArchOv" format="default"/>
      shows the Resolution Schemes in use, which make the following next hop NH
      resolution happen at SN11 (Intra-AS) (intra-AS) and PE21 (Inter-AS) (inter-AS) for the service
      routes of prefixes IP1, IP2, IP3:<list> and IP3:</t>
      <ul spacing="normal">
        <li>
          <t>Resolve IP1 next hop NH over available tunnels in TRDB for Transport
          Class 100 with fallback to TRDB for best effort.</t>
        </li>
        <li>
          <t>Resolve IP2 next hop NH over available tunnels in TRDB for Transport
          Class 200 with fallback to TRDB for best effort.</t>
        </li>
        <li>
          <t>Resolve IP3 next hop NH over available tunnels in TRDB for Transport
          Class 100 with fallback to TRDB for Transport Class 200.</t>
        </list>In
        </li>
      </ul>
      <t>In <xref target="ArchOv"/>, target="ArchOv" format="default"/>, SN11 resolves IP1, IP2 IP2, and IP3
      directly over RSVP-TE tunnels in AS1. PE21 resolves IP1, IP2 IP2, and IP3
      over extended BGP CT tunnels that resolve over SR-TE tunnels in AS2.</t>
      <t>This document describes procedures using MPLS forwarding
      architecture. However, these procedures would work in a similar manner
      for non-MPLS forwarding architectures as well. <xref target="SRv6-Support"/> target="SRv6-Support" format="default"/>
      describes the application of BGP CT over the SRv6 data plane.</t>
    </section>
    <section anchor="tc" title="Transport Class"> numbered="true" toc="default">
      <name>Transport Class</name>
      <t>Transport Class is a construct that groups transport tunnels offering
      similar SLA SLAs within the administrative domain of a provider network or
      closely coordinated provider networks.</t>
      <t>A Transport Class is uniquely identified by a 32-bit "Transport Class
      ID",
      ID" that is assigned by the operator. The operator consistently
      provisions a Transport Class on participating nodes (SNs and BNs) in a
      domain with its unique Transport Class ID.</t>
      <t>A Transport Class is also configured with RD and import/export RT
      attributes. Creation of a Transport Class instantiates its corresponding
      TRDB and Resolution Schemes on that node.</t>
      <t>All nodes within a domain agree on a common Transport Class ID
      namespace. However, two co-operating cooperating domains may not always agree on the
      same namespace. Procedures to manage differences in Transport Class ID
      namespaces between co-operating cooperating domains are specified in <xref
      target="non-agreeing"/>.</t> target="non-agreeing" format="default"/>.</t>
      <t>Transport Class ID conveys the Color of tunnels in a Transport Class.
      The terms 'Transport Class ID' and 'Color' are used interchangeably in
      this document.</t>
      <section anchor="tc-te" title="Classifying numbered="true" toc="default">
        <name>Classifying TE tunnels"> Tunnels</name>
        <t>TE tunnels can be classified into a Transport Class based on the TE
        attributes they possess and the TE characteristics that the operator
        defines for that Transport Class. Due to the fact that multiple TE
        tunneling protocols exist, their TE attributes and characteristics may
        not be equal but sufficiently similar. Some examples of such
        classifications are as follows:<list> follows:</t>
        <ul spacing="normal">
          <li>
            <t>Tunnels (RSVP-TE, IGP FLEX-ALGO, Flex-Algo, SR-TE) that support latency
            sensitive routing.</t>
          </li>
          <li>
            <t>RSVP-TE Tunnels tunnels that only go over admin-group with Green
            links.</t>
          </li>
          <li>
            <t>Tunnels (RSVP-TE, SR-TE) that offer Fast Reroute.</t> FRR.</t>
          </li>
          <li>
            <t>Tunnels (RSVP-TE, SR-TE) that share resources in the network
            based on Shared Risk Link Groups defined by TE policy.</t>
          </li>
          <li>
            <t>Tunnels (RSVP-TE, SR-TE, BGP CT) that avoid certain nodes in
            the network based on RSVP-TE ERO, Explicit Route Object (ERO), SR-TE policy policy, or BGP policy.</t>
          </list></t>
          </li>
        </ul>
        <t>An operator may configure a an SN/BN to classify a tunnel into an
        appropriate Transport Class. How exactly these tunnels are made
        Transport Class aware is implementation specific and outside the scope
        of this document.</t>
        <t>When a tunnel is made Transport Class aware, it causes the Tunnel
        Route to be installed in the corresponding TRDB of that Transport
        Class. These routes are used to resolve overlay routes, including BGP
        CT. The BGP CT routes may be further readvertised to adjacent domains
        to extend these tunnels. While readvertising BGP CT routes, the
        "Transport Class" identifier Class ID" is encoded as part of the Transport Class
        RT, which is a new Route Target extended community defined in <xref
        target="tc-rt"/>.</t>

        <t>A target="tc-rt" format="default"/>.</t>
        <t>An SN/BN receiving the transport routes via BGP with sufficient
        signaling information to identify a Transport Class can associate
        those tunnel routes to with the corresponding Transport Class. For example,
        in BGP CT family routes, the Transport Class RT indicates the
        Transport Class. For BGP LU family routes, import processing based on
        Communities
        communities or Inter-AS inter-AS source-peer may be used to place the route in
        the desired Transport Class.</t>
        <t>When the tunnel route is received via <xref target="SRTE"/> target="RFC9830" format="default"/> with
        "Color:Endpoint" as the NLRI that encodes the Transport Class as an
        integer 'Color' in its Policy Color field, the 'Color' is mapped to a
        Transport Class during the import processing. The SRTE tunnel route
        for this 'Endpoint' is installed in the corresponding TRDB. The SRTE
        tunnel will be extended by a BGP CT advertisement with NLRI
        'RD:Endpoint',
        RD:EP, Transport Class RT RT, and a new label. The MPLS swap route
        thus installed for the new label will pop the label and forward the
        decapsulated traffic into the path determined by the SRTE route for
        further encapsulation.</t>
        <t><xref target="PCEP-SRPOLICY"/> target="I-D.ietf-pce-segment-routing-policy-cp" format="default"/> extends the Path Computation Element
        Communication Protocol (PCEP) to signal attributes of an SR Policy
        which
        that include Color. This Color is mapped to a Transport Class thus
        associating the SR Policy with the desired Transport Class.</t>
        <t>Similarly, <xref target="PCEP-RSVP-COLOR"/> target="I-D.ietf-pce-pcep-color" format="default"/> extends PCEP to carry
        the Color attribute for its use with RSVP-TE LSPs . LSPs. This Color is
        mapped to a Transport Class thus associating the RSVP-TE LSP with the
        desired Transport Class.</t>
      </section>
      <section anchor="trdb" title="Transport Route Database">
        <t>A Transport numbered="true" toc="default">
        <name>Transport Route Database (TRDB) (TRDB)</name>
        <t>A TRDB is a logical collection of
        transport routes pertaining to the same Transport Class. In any node,
        every Transport Class has an associated TRDB. Resolution Schemes
        resolve next hop NH reachability for EP using the transport routes within
        the scope of the TRDBs.</t>
        <t>Tunnel endpoint EP addresses (EP) in a TRDB belong to the "Provider
        Namespace" provider
        namespace representing the core transport region.</t>
        <t>An implementation may realize the TRDB as a "Routing Table"
        referred to in <eref
        target="https://www.rfc-editor.org/rfc/rfc4271#section-9.1.2.1">Section
        9.1.2.1 of RFC4271</eref> <xref target="RFC4271" sectionFormat="of" section="9.1.2.1"/>, which is used only for resolving next hop NH
        reachability in the control plane. An implementation may choose a
        different datastructure to realize this logical construct while still
        adhering to the procedures defined in this document. The tunnel routes
        in a TRDB require no footprint in the forwarding plane unless they are
        used to resolve a next hop.</t> an NH.</t>
        <t>SNs or BNs originate routes for the "Classful Transport" BGP CT address
        family from the TRDB. These routes have "RD:Endpoint" RD:EP in the NLRI,
        carry a Transport Class RT, and an MPLS label or equivalent identifier
        in different forwarding architecture. "Classful Transport" BGP CT family
        routes received with Transport Class RT are installed into their
        respective TRDB.</t>
      </section>
      <section anchor="tc-rt"
               title="&quot;Transport Class&quot; numbered="true" toc="default">
        <name>Transport Class Route Target Extended Community"> Target</name>
        <t>This section defines a new type of Route Target, Target called a
        "Transport Class" Class Route Target Extended Community; also extended community" (also known as a
        Transport Target.
        "Transport Class RT"). The procedures for use of this extended community
        with BGP CT routes (AFI/SAFI: 1/76 or 2/76) are described below.</t>

        <t>The "Transport Class" Route Target Extended Community Transport Class RT is a
        transitive extended community <xref target="RFC4360">EXT-COMM</xref> target="RFC4360" format="default"></xref>
        of extended type, which has the format as shown in <xref
        target="TCExtCom"/>.</t> target="TCExtCom" format="default"/>.</t>
        <figure anchor="TCExtCom" suppress-title="false"
                title="&quot;Transport Class&quot; Route Target Extended Community"> anchor="TCExtCom">
          <name>Transport Class RT</name>
          <artwork align="left" xml:space="preserve"> name="" type="" alt=""><![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= 0xa   | SubType= 0x02 |            Reserved           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                     Transport Class ID                        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

 Type:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>
	</figure>

	<dl spacing="normal" newline="false">
	  <dt>Type:</dt>
	  <dd>A 1-octet field MUST that <bcp14>MUST</bcp14> be set to 0xa to indicate 'Transport Class'.

 SubType: Class'.</dd>

	  <dt>SubType:</dt>
	  <dd>A 1-octet field MUST that <bcp14>MUST</bcp14> be set to 0x2 to indicate 'Route Target'.

 Reserved: Target'.</dd>

	  <dt>Reserved:</dt>
	  <dd><t>A 2-octet reserved bits field.
         This field.</t>
          <t>This field MUST <bcp14>MUST</bcp14> be set to zero on transmission.
         This transmission.</t>
          <t>This field SHOULD <bcp14>SHOULD</bcp14> be ignored on reception, reception and
         MUST <bcp14>MUST</bcp14> be left unaltered.

 Transport unaltered.</t>
	  </dd>

	  <dt>Transport Class ID: This ID:</dt>
	  <dd><t>This field is encoded in 4 octets.

    This octets.</t>
	  <t>This field contains the "Transport Class" identifier, Class ID", which is an unsigned 32-bit integer.

    This integer.</t>
	  <t>This document reserves the Transport class Class ID value 0 to represent "Best Effort the "Best-Effort Transport Class ID".</artwork>
        </figure> ID".</t></dd>
	</dl>

        <t>A Transport Class Route Target Extended community RT with TC ID 100
        is denoted as "transport-target:0:100".</t>
        <t>The VPN route import/export mechanisms specified in <xref
        target="RFC4364">BGP/MPLS BGP/MPLS IP VPNs</xref> VPNs (see <xref target="RFC4364" format="default"></xref>) and the Constrained Route
        Distribution mechanisms specified in <xref target="RFC4684">Route Route Target Constrain</xref> Constraint (see <xref target="RFC4684" format="default"></xref>) are applied using the Route Target extended
        community. These mechanisms are applied to BGP CT routes (AFI/SAFI:
        1/76 or 2/76) using "Transport the Transport Class Route Target Extended
        community".</t> RT".</t>
        <t>A BGP speaker that implements procedures described in this document
        and <xref target="RFC4684">Route Target Constrain</xref> MUST target="RFC4684" format="default"></xref> <bcp14>MUST</bcp14> also
        apply the RTC procedures to the Transport Class Route Target Extended
        communities RT
        carried on BGP CT routes (AFI/SAFI: 1/76 or 2/76). An RTC
        route is generated for each Route Target imported by locally
        provisioned Transport Classes.</t>
        <t>Further, when processing RT membership NLRIs containing a Transport
        Class Route Target Extended community RT received from external BGP
        peers, it is necessary to consider multiple EBGP External BGP (EBGP) paths for a given RTC
        prefix for building the outbound route filter, and filter: not just the best
        path. An implementation MAY <bcp14>MAY</bcp14> provide configuration to control how many
        EBGP RTC paths are considered.</t>
        <t>The Transport Class Route Target Extended community RT is carried on
        BGP CT family routes and is used to associate them with appropriate
        TRDBs at receiving BGP speakers. The Transport Target Class RT is carried
        unaltered on the BGP CT route across BGP CT negotiated sessions except
        for scenarios described in <xref target="non-agreeing"/>. target="non-agreeing" format="default"/>.
        Implementations should provide policy mechanisms to perform match,
        strip, or rewrite operations on a Transport Target Class RT just like any other
        BGP community.</t>
        <t>Defining a new type code for the Transport Class Route Target
        Extended community RT
        avoids conflicting with any VPN Route Target
        assignments already in use for service families.</t>

        <t>This document also reserves the <xref
        target="tc-rt-nt">Non-Transitive non-transitive version of the Transport Class extended
        community</xref> RT
        (see <xref target="tc-rt-nt" format="default"></xref>) for future use. The "Non-Transitive non-transitive Transport Class"
        Route Target Extended Community Class
        RT is not used. If received, it is
        considered equivalent in functionality to the Transitive transitive Transport
        Class Route Target Extended Community, RT, except for the difference in
        Transitive bit flag.</t>
      </section>
    </section>
    <section anchor="Nexthop_Resoln_Schm" title="Resolution Scheme"> numbered="true" toc="default">
      <name>Resolution Scheme</name>
      <t>A Resolution Scheme is a construct that consists of a specific TRDB
      or an ordered set of TRDBs. An overlay route is associated with a
      resolution scheme
      Resolution Scheme during import processing, processing based on the Mapping
      Community in the route.</t>
      <t>Resolution Schemes enable a BGP speaker to resolve next hop NH
      reachability for overlay routes over the appropriate underlay tunnels
      within the scope of the TRDBs. Longest Prefix Match (LPM) of the next
      hop NH is performed within the identified TRDB.</t>
      <t>An implementation may provide an option for the overlay route to
      resolve over less preferred less-preferred Transport Classes, should the resolution
      over a primary Transport Class fail.</t>
      <t>To accomplish this, the "Resolution Scheme" is configured with the
      primary Transport Class, Class and an ordered list of fallback Transport
      Classes. Two Resolution Schemes are considered equivalent in Intent if
      they consist of the same ordered set of TRDBs.</t>
      <t>Operators must ensure that Resolution Schemes for a mapping community Mapping Community
      are provisioned consistently on various nodes participating in a BGP CT
      network,
      network based on desired Intent and transport classes Transport Classes available in that
      domain.</t>
      <section anchor="Mapping_Comm" title="Mapping Community"> numbered="true" toc="default">
        <name>Mapping Community</name>
        <t>A "Mapping Community" is used to signal the desired Intent on an
        overlay route. At an ingress node receiving the route, it maps the
        overlay route to a "Resolution Scheme" used to resolve the route's
        next hop.</t>
        NH.</t>
        <t>A Mapping Community is a "role" and not a new type of community;
        any BGP Community Carrying Attribute (e.g. (e.g., Community or Extended
        Community) may play this role, besides role in addition to the other roles it may already
        be playing. For example, the Transport Class Route Target Extended
        Community RT
        plays a dual role, being a role: as Route Target as well as and a Mapping
        Community.</t>
        <t>Operator provisioning ensures that the ingress and egress SNs agree
        on the BGP CCA and community namespace to use for the Mapping
        Community.</t>
        <t>A Mapping Community maps to exactly one Resolution Scheme at
        a receiving BGP speaker. An implementation SHOULD <bcp14>SHOULD</bcp14> allow associating the association of
        multiple Mapping Communities to a Resolution Scheme. This helps with
        renumbering and migration scenarios.</t>

        <t>An example of mapping community a Mapping Community is a Color extended community "color:0:100", described in
        <xref target="RFC9012"/>, target="RFC9012" format="default"/>, or the "transport-target:0:100" described in
        <xref target="tc-rt"/> in this document.</t> target="tc-rt" format="default"/>.</t>
        <t>The first community on the overlay route that matches a Mapping
        Community of a locally configured Resolution Scheme is considered the
        effective Mapping Community for the route. The Resolution Scheme thus
        found is used when resolving the route's PNH. If a route contains more
        than one Mapping Community, it indicates that the route considers
        these distinct Mapping Communities as equivalent in Intent.</t>

        <t>If

        <t>On an overlay route, if more than one distinct Mapping Communities on an overlay route Community exists that map
        to distinct Resolution Schemes with having dissimilar Intents at a receiving
        node, it is considered a configuration error.</t>
        <t>Since a route can carry multiple communities, but only a single
        Resolution Scheme can be in effect for the route on any given router,
        it is incumbent on the operator to ensure that communities attached
        to a route will map to the desired Resolution Scheme at each point
        in the network.</t>
        <t>It should be noted that the Mapping Community role does not require
        applying Route Target Constrain Constraint procedures specified in RFC 4684.</t> <xref target="RFC4684"/>.</t>
      </section>
    </section>
    <section anchor="ct-family" title="BGP numbered="true" toc="default">
      <name>BGP Classful Transport Family"> Family</name>
      <t>The BGP Classful Transport (BGP CT) family uses the existing Address
      Family Identifier (AFI) of IPv4 or IPv6 and a new SAFI 76 "Classful
      Transport" that applies to both IPv4 and IPv6 AFIs.</t>
      <t>The AFI/SAFI 1/76 MUST <bcp14>MUST</bcp14> be negotiated as per the Multiprotocol
      Extensions capability described in Section 8 of <xref target="RFC4760"/> target="RFC4760" sectionFormat="of" section="8"/>
      to be able to send and receive BGP CT routes for IPv4 endpoint
      prefixes.</t>
      <t>The AFI/SAFI 2/76 MUST <bcp14>MUST</bcp14> be negotiated as per the Multiprotocol
      Extensions capability described in Section 8 of <xref target="RFC4760"/> target="RFC4760" sectionFormat="of" section="8"/>
      to be able to send and receive BGP CT routes for IPv6 endpoint
      prefixes.</t>
      <section anchor="ct-nlri" title="NLRI Encoding"> numbered="true" toc="default">
        <name>NLRI Encoding</name>
        <t>The "Classful Transport" SAFI NLRI has the same encoding as
        specified in Section 2 of <xref target="RFC8277"/>.</t> target="RFC8277" sectionFormat="of" section="2"/>.</t>
        <t>When the AFI/SAFI is 1/76, the Classful Transport BGP CT NLRI Prefix consists
        of an 8-byte RD followed by an IPv4 prefix. When AFI/SAFI is 2/76, the
        Classful Transport
        BGP CT NLRI Prefix consists of an 8-byte RD followed by an
        IPv6 prefix.</t>
        <t>The procedures described for AFI/SAFIs 1/4 or 1/128 in Section 2 of
        <xref target="RFC8277"/> target="RFC8277" sectionFormat="of" section="2"/> apply for AFI/SAFI 1/76 also. The procedures
        described for AFI/SAFIs 2/4 or 2/128 in Section 2 of <xref
        target="RFC8277"/> target="RFC8277" sectionFormat="of" section="2"/> apply for AFI/SAFI 2/76 also.</t>
        <t>BGP CT routes MAY <bcp14>MAY</bcp14> carry multiple labels in the NLRI, NLRI by negotiating
        the Multiple Labels Capability as described in Section 2.1 of <xref
        target="RFC8277"/></t> target="RFC8277" sectionFormat="of" section="2.1"/>.</t>
        <t>Properties received on a Classful Transport BGP CT route include the
        Transport Class Route Target extended community, RT, which is used to
        associate the route with the correct TRDBs on SNs and BNs in the
        network, and either an IPv4 or an IPv6 next hop.</t> NH.</t>
      </section>
      <section anchor="ct-nhop" title="Next numbered="true" toc="default">
        <name>Next Hop Encoding"> Encoding</name>
        <t>When the length of the Next hop Address field is 4, the next hop
        address is of type an IPv4 address.</t>
        <t>When the length of the Next hop Address field is 16 (or 32), the next
        hop address is of type an IPv6 address (potentially followed by the
        link-local IPv6 address of the next hop). This follows Section 3 in
        <xref target="RFC2545"/></t> target="RFC2545" sectionFormat="of" section="3"/>.</t>
        <t>When the length of Next hop Address field is 24 (or 48), the next
        hop address is of type a VPN-IPv6 with an 8-octet RD set to zero
        (potentially followed by the link-local VPN-IPv6 address of the next
        hop with an 8-octet RD set to zero). This follows Section 3.2.1.1 in
        <xref target="RFC4659"/></t> target="RFC4659" sectionFormat="of" section="3.2.1.1"/>.</t>
        <t>When the length of the Next hop Address field is 12, the next hop
        address is of type a VPN-IPv4 with 8-octet RD set to zero.</t>
        <t>If the length of the Next hop Address field contains any other
        values, it is considered an error and is handled via BGP session reset
        as per <xref section="7.11" target="RFC7606"/>.</t> target="RFC7606" format="default"/>.</t>
      </section>

      <section anchor="CTMultiEncap"
               title="Carrying multiple numbered="true" toc="default">
        <name>Carrying Multiple Types of Encapsulation Information"> Information</name>
        <t>To ease interoperability between nodes supporting different
        forwarding technologies, a BGP CT route allows carrying multiple
        types of encapsulation information.</t>
        <t>An MPLS Label label is carried using the encoding in <xref
        target="RFC8277"/>. target="RFC8277" format="default"/>. A node that does not support MPLS forwarding
        advertises the special label 3 (Implicit NULL) in the RFC 8277 MPLS
        Label field. label field (see <xref target="RFC8277"/>). The Implicit NULL label carried in BGP CT route indicates
        to a receiving node that it should not impose any BGP CT label for this
        route.</t>

        <t>The SID information for SR with respect to the MPLS Data Plane data plane is
        carried as specified in Prefix SID the Prefix-SID attribute defined as part of
        Section 3 in
        <xref target="RFC8669"/>.</t> target="RFC8669" sectionFormat="of" section="3"/>.</t>
        <t>The SID information for SR with respect to SRv6 Data Plane data plane is
        carried as specified in <xref target="SRv6-Support"/>.</t> target="SRv6-Support" format="default"/>.</t>
        <t>UDP tunneling information is carried using the Tunnel Encapsulation
        Attribute as specified in <xref target="RFC9012"/>.</t> target="RFC9012" format="default"/>.</t>
      </section>
      <section title="Comparison numbered="true" toc="default">
        <name>Comparison with Other Families using RFC-8277 Encoding"> Using Encoding from RFC 8277</name>
        <t>AFI/SAFI 1/128 (MPLS-labeled VPN address) (L3VPN) is an RFC8277 encoded a family encoded using <xref target="RFC8277"/> that carries service prefixes in the NLRI, where the prefixes
        come from the customer namespaces and are contextualized into separate
        user virtual service RIBs called VRFs as per [RFC4364].</t> <xref target="RFC4364"/>.</t>
        <t>AFI/SAFI 1/4 (BGP LU) is an RFC8277 encoded a family encoded using <xref target="RFC8277"/> that carries
        transport prefixes in the NLRI, where the prefixes come from the
        provider namespace.</t>
        <t>AFI/SAFI 1/76 (Classful Transport SAFI) (BGP CT) is an RFC8277 encoded a family encoded using <xref target="RFC8277"/> that carries transport prefixes in the NLRI, where the prefixes
        come from the provider namespace and are contextualized into separate
        TRDB, following mechanisms similar to RFC 4364 <xref target="RFC4364"/> procedures.</t>
        <t>It is worth noting that AFI/SAFI 1/128 has been used to carry
        transport prefixes in "L3VPN Inter-AS inter-AS Carrier's carrier" scenario as
        defined in Section 10 of <xref target="RFC4364"/>, target="RFC4364" sectionFormat="of" section="10"/>, where BGP LU/LDP
        prefixes in CsC VRF are advertised in AFI/SAFI 1/128 towards the
        remote-end client carrier.</t>
        <t>In this document, SAFI 76 (BGP CT) (CT) is used instead of reusing SAFI
        128 (L3VPN) for AFIs 1 or 2 to carry these transport routes because it
        is operationally advantageous to segregate transport and service
        prefixes into separate address families. For example, such an approach
        allows operators to safely enable a "per-prefix" label allocation label-allocation scheme
        for Classful Transport BGP CT prefixes, typically with a number of routes in
        the hundreds of thousands or less, without affecting SAFI 128 service
        prefixes
        prefixes, which may represent millions of routes, routes at the time of writing.
        The "per prefix" label allocation "per-prefix" label-allocation scheme localizes routing churn
        during topology changes.</t>
        <t>Service routes continue to be carried in their existing AFI/SAFIs
        without any change. For example, L3VPN (AFI/SAFI: 1/128 and 2/128),
        EVPN (AFI/SAFI: 25/70 ), VPLS Virtual Private LAN Service (VPLS) (AFI/SAFI: 25/65), or Internet (AFI/SAFI:
        1/1 or 2/1). These service routes can resolve over BGP CT (AFI/SAFI:
        1/76 or 2/76) transport routes.</t>
        <t>A new SAFI 76 for AFI 1 and AFI 2 also facilitates having a
        different distribution path of the transport family routes in a
        network than the service route distribution path. Service routes
        (Inet-VPN SAFI
        (SAFI 128) are exchanged over an EBGP multihop session
        between ASes with next hop the NH unchanged; whereas Classful Transport BGP CT
        routes (SAFI 76) are advertised over EBGP single-hop sessions with
        "next hop a
        "NH self" rewrite over inter-AS links.</t>
        <t>The BGP CT SAFI 76 for AFI 1 and 2 is conceptually similar to BGP
        LU SAFI 4, 4 in that it carries transport prefixes. The only difference
        is that it also carries in a Route Target an indication of which
        Transport Class the transport prefix belongs to, to and uses the RD to
        disambiguate multiple instances of the same transport prefix in a BGP
        Update.</t>
        UPDATE message.</t>
      </section>
    </section>
    <section title="Protocol Procedures"> numbered="true" toc="default">
      <name>Protocol Procedures</name>
      <t>This section summarizes the procedures followed by various nodes
      speaking Classful Transport BGP CT family.</t>
      <section title="Preparing numbered="true" toc="default">
        <name>Preparing the network Network to deploy Deploy Classful Transport planes">
        <t><list> Planes</name>

        <t>It is the responsibility of the operators to decide the Transport
        Classes to enable and use in their network. They are also expected to
        allocate a Transport Class Route Target RT to identify each Transport
        Class.</t>
        <t>Operators configure the Transport Classes on the SNs and BNs in the
        network with Transport Class Route Targets RTs and appropriate
            Route-Distinguishers.</t>
        Route Distinguishers.</t>
        <t>Implementations MAY <bcp14>MAY</bcp14> provide automatic generation and
        assignment of RD, RT values. They MAY <bcp14>MAY</bcp14> also provide a
        way to manually override the automatic mechanism in order to deal with
        any conflicts that may arise with existing RD, RT values in different
        network domains participating in the deployment.</t>
          </list></t>

      </section>
      <section title="Originating Classful Transport Routes">
        <t><list> numbered="true" toc="default">
        <name>Originating BGP CT Routes</name>

        <t>BGP CT routes are sent only to BGP peers that have negotiated the
        Multiprotocol Extensions capability described in Section 8 of
            [RFC4760] <xref
        target="RFC4760" sectionFormat="of" section="8"/> to be able to send
        and receive BGP CT routes.</t>
        <t>At the ingress node of the tunnel's home domain, the tunneling
        protocols install tunnel routes in the TRDB associated with the
        Transport Class to which the tunnel belongs.</t>

        <t>The egress node of the tunnel, i.e. i.e., the tunnel endpoint (EP),
        originates the BGP CT route with RD:EP in the NLRI, a Transport Class RT RT,
        and the PNH as the EP. This BGP CT route will be resolved over the tunnel
        route in TRDB at the ingress node. When the tunnel is up, the Classful
        Transport BGP route will become usable and get
            re-advertised readvertised by the
        ingress node to BGP peers in neighboring domains.</t>
        <t>Alternatively, the ingress node of the tunnel, which is also an
        ASBR/ABR in a tunnel's home domain, may originate the BGP CT route for
        the tunnel destination with NLRI RD:EP, RD:EP in the NLRI, attaching a Transport Class
        Route Target that identifies the Transport Class. This BGP CT route is
        advertised to EBGP peers and IBGP peers in neighboring domains.</t>
        <t>This originated route SHOULD NOT <bcp14>SHOULD NOT</bcp14> be advertised to
        the IBGP core that contains the tunnel. This may be implemented by
        mechanisms such as policy configuration. The impact of not prohibiting
        such advertisements is outside the scope of this document.</t>

            <t>Unique
        <t>A unique RD SHOULD <bcp14>SHOULD</bcp14> be used by the originator of a Classful
            Transport
        BGP CT route to disambiguate the multiple BGP
        advertisements for a transport endpoint. An administrator may use
        duplicate RDs based on local choice, understanding the impact on path
        diversity and troubleshooting, as described in <xref
            target="rd-lbl-usage"/>.</t>
          </list></t>
        target="rd-lbl-usage" format="default"/>.</t>
      </section>
      <section anchor="CTingress"
               title="Processing Classful Transport numbered="true" toc="default">
        <name>Processing BGP CT Routes by Ingress Nodes">
        <list> Nodes</name>
            <t>Upon receipt of a BGP CT route with a PNH EP that is not directly
          connected (e.g. (e.g., an IBGP-route), a Mapping Community (the Transport
          Class RT) on the route is used to decide to which resolution scheme Resolution Scheme
          this route is to be mapped.</t>
            <t>The resolution scheme Resolution Scheme for a Transport Class RT with Transport
          Class ID "C1" contains the TRDB of a Transport Class with same ID.
          The administrator MAY <bcp14>MAY</bcp14> customize the resolution scheme Resolution Scheme for Transport
          Class ID "C1" to map to a different ordered list of TRDBs. If the
          resolution scheme
          Resolution Scheme for TC ID "C1" is not found, the resolution scheme Resolution Scheme
          containing the "Best Effort" transport class Best-Effort TRDB is used.</t>
            <t>The routes in the TRDBs associated with a selected resolution
          scheme Resolution
          Scheme are used to resolve the received PNH EP. The order of TRDBs
          in the resolution scheme Resolution Scheme is followed when resolving the received
          PNH, such that a route in a backup TRDB is used only when a matching
          route was not found for EP in the primary TRDBs preceding it. This
          achieves the fallback desired by the resolution scheme.</t> Resolution Scheme.</t>
            <t>If the resolution process does not find a matching route for the EP
          in any of the associated TRDBs, the received BGP CT route MUST <bcp14>MUST</bcp14> be
          considered unresolvable. (See RFC 4271, Section 9.1.2.1).</t> <xref target="RFC4271" sectionFormat="of" section="9.1.2.1"/>.)</t>
            <t>The received BGP CT route MUST <bcp14>MUST</bcp14> be added to the TRDB corresponding
          to the Transport Class "C1", ID "C1" if the transport class TC is provisioned
          locally. This step applies only if the Transport Class RT is
          received on a BGP CT family route. The RD in the BGP CT NLRI prefix
          RD:EP is ignored when the BGP CT route for EP is added to the TRDB, TRDB
          so that overlay routes can resolve over this BGP CT tunnel route by
          performing a lookup for the EP. Please note that a TRDB is a logical
          database of tunnel routes belonging to the same Transport Class ID,
          hence ID;
          hence, it uses only uses the EP as the lookup key without (without RD or TC ID.</t> ID).</t>
            <t>If no Mapping Community was is found on a BGP CT route, the best
          effort resolution scheme Best-Effort Resolution Scheme is used for resolving to resolve the route's next hop,
          and the BGP CT route is not added to any TRDB.</t>
        </list>

      </section>
      <section title="Readvertising Classful Transport numbered="true" toc="default">
        <name>Readvertising BGP CT Route by Border Nodes">
        <list> Nodes</name>

            <t>This section describes the MPLS label handling when readvertising
          a BGP CT route with Next Hop set to Self. "NH self". When readvertising a BGP
          CT route with Next Hop set to Self, "NH self", a BN allocates an MPLS label to
          advertise upstream in Classful Transport the BGP CT NLRI. The BN also installs
          an MPLS route for that label that swaps the incoming label with the
          label received from the downstream BGP speaker (or pops the incoming
          label if the label received from the downstream BGP speaker was
          Implicit-NULL).
          Implicit NULL). The MPLS route then pushes received traffic to the
          transport tunnel or direct interface that the Classful Transport BGP CT
          route's PNH resolved over.</t>
            <t>The label SHOULD <bcp14>SHOULD</bcp14> be allocated with "per-prefix" label allocation label-allocation
          semantics. The IP prefix in the TRDB context (Transport-Class,
          IP-prefix) (Transport Class,
          IP prefix) is used as the key to do per-prefix "per-prefix" label allocation.
          This helps in avoiding BGP CT route churn throughout the CT network
          when an instability (e.g., link failure) is experienced in a domain.
          The failure is not propagated further than the BN closest to the
          failure. If a different label allocation label-allocation mode is used, the impact on
          end to end
          end-to-end convergence should be considered.</t>

            <t>The value of the advertised MPLS label is locally significant, significant
          and is dynamic by default. A BN may provide an option to allocate a
          value from a statically provisioned range. This can be achieved
          using a locally configured export policy, policy or via mechanisms such as
          the ones described related to BGP Prefix-SID as described in BGP (see <xref target="RFC8669">BGP
          Prefix-SID</xref>.</t>
        </list> target="RFC8669" format="default"></xref>).</t>

      </section>
      <section title="Border numbered="true" toc="default">
        <name>Border Nodes Receiving Classful Transport BGP CT Routes on EBGP">
        <list> EBGP</name>
            <t>If a route is received with a PNH that is known to be directly
          connected (for example, an EBGP single-hop neighbor address), the
          directly connected interface is checked for MPLS forwarding
          capability. No other next hop resolution process is performed since
          the inter-AS link can be used for any Transport Class.</t>
            <t>If the inter-AS links need to honor Transport Class, then the BN
          MUST
          <bcp14>MUST</bcp14> follow the procedures of an Ingress ingress node (<xref
          target="CTingress"/>) target="CTingress" format="default"/>) and perform the next hop resolution process.
          In order to make the link Transport Class aware, the route to the
          directly connected PNH is installed in the TRDB belonging to the
          associated Transport Class.</t>
        </list>

      </section>
      <section title="Avoiding numbered="true" toc="default">
        <name>Avoiding Path Hiding Through Route Reflectors">
        <list> Reflectors</name>
            <t>When multiple instances of a given RD:EP exist with different
          forwarding characteristics, then BGP ADD-PATH (see <xref target="RFC7911">BGP
          ADD-PATH</xref> target="RFC7911" format="default"></xref>) is helpful.</t>

            <t>When multiple BNs exist such that they advertise a an "RD:EP" prefix
          to Route Reflectors (RRs), the RRs may hide all but one of the BNs,
          unless BGP ADD-PATH (see <xref target="RFC7911">BGP ADD-PATH</xref> target="RFC7911" format="default"></xref>) is used for the
          Classful Transport
          BGP CT family. This is similar to L3VPN Option inter-AS option B
          scenarios.</t>
            <t>Hence, BGP ADD-PATH (see <xref target="RFC7911">BGP ADD-PATH</xref> SHOULD target="RFC7911" format="default"></xref>) <bcp14>SHOULD</bcp14> be used
          for Classful Transport family, the BGP CT family to avoid path-hiding path hiding through RRs so
          that the RR sends multiple CT routes for RD:EP to its clients. This
          improves the convergence time when the path via one of the multiple
          BNs fails.</t>
        </list>

      </section>
      <section title="Avoiding numbered="true" toc="default">
        <name>Avoiding Loops Between Route Reflectors in Forwarding Path">
        <list> Paths</name>
            <t>A pair of redundant ABRs, each acting as an RR with the next hop
          self,
          set to itself, may choose each other as the best path instead of the upstream
          ASBR, causing a traffic forwarding traffic-forwarding loop.</t>
            <t>This problem can happen for routes of any BGP address family,
          including BGP CT and BGP LU.</t>
            <t>Using one or more of the approaches described in <xref
          target="BGP-FWD-RR"/> softens target="I-D.ietf-idr-bgp-fwd-rr" format="default"/> lowers the possibility of such loops in a
          network with redundant ABRs.</t>
        </list>

      </section>
      <section title="Ingress numbered="true" toc="default">
        <name>Ingress Nodes Receiving Service Routes with a Mapping Community">
        <list> Community</name>

            <t>Upon receipt of a BGP service route (for example, AFI/SAFI: 1/1,
          2/1) with a PNH as the EP that is not directly connected (for example,
          an IBGP-route), a Mapping Community (for example, a Color Extended
          Community) on the route is used to decide to which resolution scheme Resolution Scheme
          this route is to be mapped.</t>
            <t>The resolution scheme Resolution Scheme for a Color Extended Community extended community with Color
          "C1" contains a TRDB for a Transport Class with same ID, ID followed by
          the Best Effort Best-Effort TRDB. The administrator MAY <bcp14>MAY</bcp14> customize the resolution
          scheme Resolution
          Scheme to map to a different ordered list of TRDBs. If the
          resolution scheme
          Resolution Scheme for TC ID "C1" is not found, the resolution scheme Resolution Scheme
          containing the "Best Effort" transport class Best-Effort TRDB is used.</t>
            <t>If no Mapping Community was found on the overlay route, the "Best
          Effort" resolution scheme
          Effort Resolution Scheme" is used for resolving the route's next
          hop. This behavior is backward compatible to behavior of an
          implementation that does not follow procedures described in this
          document.</t>
            <t>The routes in the TRDBs associated with the selected resolution
          scheme Resolution
          Scheme are used to resolve the received PNH EP. The order of TRDBs
          in a resolution scheme Resolution Scheme is followed when resolving the received PNH,
          such that a route in a backup TRDB is used only when a matching
          route was not found for the EP in the primary TRDBs preceding it. This
          achieves the fallback desired by the resolution scheme.</t> Resolution Scheme.</t>
            <t>If the resolution process does not find a Tunnel Route for the EP in
          any of the Transport Route Databases, the service route MUST <bcp14>MUST</bcp14> be
          considered unresolvable unresolvable. (See RFC 4271, Section 9.1.2.1).</t>
        </list> <xref target="RFC4271" sectionFormat="of" section="9.1.2.1"/>).</t>
        <t>Note: For an illustration of above procedures in a an MPLS network,
        refer to <xref target="CTProc"/>.</t> target="CTProc" format="default"/>.</t>
      </section>
      <section title="Best Effort numbered="true" toc="default">
        <name>Best-Effort Transport Class">
        <list> Class</name>
            <t>It is also possible to represent 'Best effort' a 'Best-Effort' SLA also as a Transport
          Class. Today, At the time of writing, BGP LU is used to extend the best effort intra domain best-effort intra-domain
          tunnels to other domains.</t>
            <t>Alternatively, BGP CT may also be used to carry the best effort best-effort
          tunnels. This document reserves the Transport Class ID value 0 to
          represent "Best Effort the "Best-Effort Transport Class ID". However, implementations
          SHOULD
          <bcp14>SHOULD</bcp14> provide configuration to use a different value for this
          purpose. Procedures to manage differences in Transport Class ID
          namespaces between domains are provided in <xref
          target="non-agreeing"/>.</t> target="non-agreeing" format="default"/>.</t>
            <t>The "Best Effort "Best-Effort Transport Class ID" value is used in the
          "Transport Class ID" field of the Transport Route Target Extended
          Community Class RT
          that is attached to the BGP CT route that advertises a
          best effort
          best-effort tunnel endpoint. The Thus, the RT thus formed is called the "Best
          Effort "Best-Effort Transport Class Route Target".</t> RT".</t>
            <t>When a BN or SN receives a BGP CT route with Best Effort Best-Effort
          Transport Class Route Target RT as the mapping community, Mapping Community, the Best
          effort resolution scheme Best-Effort Resolution Scheme is used for resolving the BGP next hop, and
          the resultant route is installed in the best effort best-effort transport route
          database. If no best effort best-effort tunnel was found to resolve the BGP next
          hop, the BGP CT route MUST <bcp14>MUST</bcp14> be considered unusable, unusable and not be
          propagated further.</t>
            <t>When a BGP speaker receives an overlay route without any explicit
          Mapping Community, and absent local policy, the best effort
          resolution scheme Best-Effort
          Resolution Scheme is used for resolving the BGP next hop on the
          route. This behavior is backward compatible to behavior of an
          implementation that does not follow procedures described in this
          document.</t>
            <t>Implementations MAY <bcp14>MAY</bcp14> provide configuration to selectively install
          BGP CT routes to the Forwarding Information Base (FIB), (FIB) to provide
          reachability for control plane control-plane peering towards endpoints in other
          domains.</t>
        </list>

      </section>
      <section title="Interaction anchor="bgp-att" numbered="true" toc="default">
        <name>Interaction with BGP Attributes Specifying Next Hop Address and Color"> Color</name>
        <t>The Tunnel Encapsulation Attribute, described in <xref
        target="RFC9012"/> target="RFC9012" format="default"/>, can be used to request a specific type of tunnel
        encapsulation. This attribute may apply to BGP service routes or
        transport routes, routes including BGP Classful Transport CT family routes.</t>
        <t>It should be noted that in such cases "Transport Class ID/Color"
        can exist in multiple places on the same route, and a precedence order
        needs to be established to determine which Transport Class the route's
        next hop should resolve over. This document specifies the following
        order of precedence, more specific precedence with more-specific scoping of Color preferred to less
        specific less-specific scoping: <list> </t>
        <ul spacing="normal">
          <li>
            <t>Color SubTLV, sub-TLV in the Tunnel Encapsulation Attribute.</t>
          </li>
          <li>
            <t>Transport Target Extended community, Class RT on a BGP CT route.</t>
          </li>
          <li>
            <t>Color Extended community, extended community on a BGP service route.</t>
          </list></t>
          </li>
        </ul>
        <t>Color specified in the Color subTLV sub-TLV in a TEA is a more specific more-specific
        indication of "Transport Class ID/Color" than Mapping Community
        (Transport Target) Class RT) on a BGP CT transport route, which is which, in turn turn, is
        more specific than a Service service route scoped Mapping Community (Color
        Extended
        extended community).</t>
        <t>Any BGP attributes or mechanisms defined in future that carry
        Transport Class ID/Color on the route are expected to specify the
        order of precedence relative to the above.</t>
      </section>
      <section title="Applicability numbered="true" toc="default">
        <name>Applicability to Flowspec Redirect to IP"> Redirect-to-IP</name>

        <t>Flowspec routes using Redirect to IP redirect-to-IP next hop is are described in <xref
        target="FLOWSPEC-REDIR-IP"/></t> target="I-D.ietf-idr-flowspec-redirect-ip" format="default"/>.</t>
        <t>Such Flowspec BGP routes with Redirect to IP redirect-to-IP next hop MAY <bcp14>MAY</bcp14> be
        attached with a Mapping Community (e.g. Color:0:100), (e.g., color:0:100), which allows
        redirecting the flow traffic over a tunnel to the IP next hop
        satisfying the desired SLA (e.g. (e.g., Transport Class color 100).</t>

        <t>Flowspec
        <t>The Flowspec BGP family acts as just another service that can make use
        of the BGP CT architecture to achieve Flow based flow-based forwarding with SLAs.</t>
      </section>
      <section anchor="IPv6-Applicability" title="Applicability numbered="true" toc="default">
        <name>Applicability to IPv6"> IPv6</name>
        <t>BGP CT procedures apply equally to IPv4 IPv4- and IPv6 enabled Intra-AS IPv6-enabled intra-AS
        or Inter-AS Option inter-AS option A, B, and C network. networks. This section describes
        the applicability of BGP CT to IPv6 at various layers.</t>
        <t>A network that is BGP CT enabled network supports IPv6 service families (for
        example, AFI/SAFI 2/1 or 2/128) and IPv6 transport signaling protocols
        like SRTEv6, LDPv6, or RSVP-TEv6.</t>
        <t>Procedures in this document also apply to a network with Pure IPv6
        core, that uses MPLS forwarding for intra-domain tunnels and inter-AS
        links. The BGP CTv6 family (AFI/SAFI: 2/76) is used to carry global IPv6
        address tunnel endpoints in the NLRI. Service family routes (for
        example, AFI/SAFI: 1/1, 2/1, 1/128, and 2/128) are also advertised with
        those Global IPv6 addresses as next hop.</t>
        <t>Procedures in this document also apply to a 6PE network with an
        IPv4 core, that which uses MPLS forwarding for intra-domain tunnels and
        Inter-AS
        inter-AS links. The BGP CTv6 family (AFI/SAFI: 2/76) is used to carry IPv4
        Mapped IPv6 address tunnel endpoints in the NLRI. IPv6 Service family
        routes (for example, AFI/SAFI: 2/1, 2/128) are also advertised with
        those IPv4 Mapped IPv6 addresses as next hop.</t>
        <t>The PE-CE attachment circuits may use IPv4 addresses only, IPv6
        addresses only, or both IPv4 and IPv6 addresses.</t>

        <t/>
      </section>
      <section anchor="SRv6-Support" title="SRv6 Support">
        <t>BGP numbered="true" toc="default">
        <name>SRv6 Support</name>
        <t>The BGP CT family (AFI/SAFI 2/76) may be used to set up inter-domain
        tunnels of a certain Transport Class, Class when using a Segment Routing over
        IPv6 (SRv6) data plane on the inter-AS links or as an intra-AS
        tunneling mechanism.</t>

        <t>Details of SRv6 Endpoint behaviors used by BGP CT and the
        procedures are specified and illustrated in a separate document (see <xref
        target="BGP-CT-SRv6"/>, along with illustration. target="I-D.ietf-idr-bgp-ct-srv6" format="default"/>). As noted in that
        document, a BGP CT route update for SRv6 includes a BGP attribute
        containing SRv6 SID information (e.g. Prefix SID [RFC9252]) (e.g., a BGP Prefix-SID <xref target="RFC9252"/>) with the
        Transposition scheme Scheme disabled.</t>
      </section>
      <section anchor="error-handling" title="Error Handling Considerations"> numbered="true" toc="default">
        <name>Error-Handling Considerations</name>
        <t>If a BGP speaker receives both transitive and non-transitive (see <xref
        target="tc-rt-t">Transitive</xref> target="tc-rt-t" format="default"></xref> and <xref
        target="tc-rt-nt">Non-Transitive</xref> target="tc-rt-nt" format="default"></xref>, respectively) versions of a Transport Class
        extended community on a route, only the Transitive transitive one is used.</t>
        <t>If a BGP speaker considers a received "Transport Class" extended
        community (Transitive (the transitive or Non-Transitive version), non-transitive version) or any other part of
        a BGP CT route invalid for some reason, but is able to successfully
        parse the NLRI and attributes, Treat-as-withdraw the treat-as-withdraw approach from <xref
        target="RFC7606"/> target="RFC7606" format="default"/> is used. The route is kept as Unusable, with
        appropriate diagnostic information, to aid troubleshooting.</t>
      </section>
    </section>
    <section anchor="CTProc" title="Illustration numbered="true" toc="default">
      <name>Illustration of BGP CT Procedures"> Procedures</name>
      <t>This section illustrates BGP CT procedures in an Inter-AS Option inter-AS option C
      MPLS network.</t>
      <t>All Illustrations illustrations in this document make use of <xref
      target="RFC6890"/> IP address ranges. ranges as described in <xref target="RFC6890" format="default"/>. The range 192.0.2.0/24 is used to
      represent transport endpoints like loopback addresses. The range
      203.0.113.0/24 is used to represent service route prefixes advertised in
      AFI/SAFIs: 1/1 or 1/128.</t>
      <t>Though this section illustrates using the use of IPv4, as described in <xref
      target="IPv6-Applicability"/> target="IPv6-Applicability" format="default"/>, these procedures work equally for IPv6
      as-well.</t>
      as well.</t>
      <section title="Reference Topology"> numbered="true" toc="default">
        <name>Reference Topology</name>
        <figure title="Multi-Domain BGP CT Network" anchor="CTProcTopo"><artset><artwork  type="svg"><svg anchor="CTProcTopo">
          <artset>
            <artwork type="svg">
              <svg xmlns="http://www.w3.org/2000/svg" version="1.1" height="320" width="584" width="560"
                viewBox="0 0 584 560 320" class="diagram" text-anchor="middle" font-family="monospace"
                font-size="13px" stroke-linecap="round">
                <path d="M 128,48 L 128,96" fill="none" stroke="black"/> stroke="black" />
                <path d="M 144,80 L 144,96" fill="none" stroke="black"/> stroke="black" />
                <path d="M 144,128 L 144,176" fill="none" stroke="black"/> stroke="black" />
                <path d="M 240,80 L 240,96" fill="none" stroke="black"/> stroke="black" />
                <path d="M 240,128 L 240,176" fill="none" stroke="black"/> stroke="black" />
                <path d="M 256,48 L 256,96" fill="none" stroke="black"/> stroke="black" />
                <path d="M 272,80 L 272,96" fill="none" stroke="black"/> stroke="black" />
                <path d="M 272,128 L 272,176" fill="none" stroke="black"/> stroke="black" />
                <path d="M 448,80 L 448,96" fill="none" stroke="black"/> stroke="black" />
                <path d="M 448,128 L 448,176" fill="none" stroke="black"/> stroke="black" />
                <path d="M 464,48 L 464,96" fill="none" stroke="black"/> stroke="black" />
                <path d="M 480,80 L 480,96" fill="none" stroke="black"/> stroke="black" />
                <path d="M 480,128 L 480,176" fill="none" stroke="black"/> stroke="black" />
                <path d="M 568,80 544,80 L 568,96" 544,96" fill="none" stroke="black"/> stroke="black" />
                <path d="M 568,128 544,128 L 568,176" 544,176" fill="none" stroke="black"/> stroke="black" />
                <path d="M 144,80 L 160,80" fill="none" stroke="black"/> stroke="black" />
                <path d="M 224,80 L 240,80" fill="none" stroke="black"/> stroke="black" />
                <path d="M 272,80 L 288,80" fill="none" stroke="black"/> stroke="black" />
                <path d="M 432,80 L 448,80" fill="none" stroke="black"/>
<path d="M 480,80 L 496,80" fill="none" stroke="black"/>
<path d="M 552,80 L 568,80" fill="none" stroke="black"/> stroke="black" />
                <path d="M 144,176 L 160,176" fill="none" stroke="black"/> stroke="black" />
                <path d="M 224,176 L 240,176" fill="none" stroke="black"/> stroke="black" />
                <path d="M 272,176 L 288,176" fill="none" stroke="black"/> stroke="black" />
                <path d="M 432,176 L 448,176" fill="none" stroke="black"/>
<path d="M 480,176 L 496,176" fill="none" stroke="black"/>
<path d="M 552,176 L 568,176" fill="none" stroke="black"/> stroke="black" />
                <path d="M 120,288 L 192,288" fill="none" stroke="black"/> stroke="black" />
                <path d="M 352,288 L 448,288" 432,288" fill="none" stroke="black"/> stroke="black" />
                <path d="M 344,96 L 376,160" fill="none" stroke="black"/> stroke="black" />
                <path d="M 336,160 L 368,96" fill="none" stroke="black"/> stroke="black" />
                <polygon class="arrowhead" points="456,288 444,282.4 444,293.6" points="440,288 428,282.4 428,293.6" fill="black" transform="rotate(0,448,288)"/>
                  transform="rotate(0,432,288)" />
                <g class="text">
                  <text x="132" y="36">[RR26]</text>
                  <text x="260" y="36">[RR27]</text>
                  <text x="468" y="36">[RR16]</text>
                  <text x="192" y="84">[ABR23]</text>
                  <text x="360" y="84">[ASBR21]-[ASBR13]</text>
                  <text x="524" y="84">[PE11]</text> x="512" y="84">-[PE11]</text>
                  <text x="80" y="116">[CE41]-[PE25]-[P28]</text>
                  <text x="256" y="116">[P29]</text>
                  <text x="464" y="116">[P15]</text>
                  <text x="556" x="532" y="116">[CE31]</text>
                  <text x="192" y="180">[ABR24]</text>
                  <text x="360" y="180">[ASBR22]-[ASBR14]</text>
                  <text x="524" y="180">[PE12]</text> x="512" y="180">-[PE12]</text>
                  <text x="56" y="228">:</text>
                  <text x="120" y="228">AS2</text>
                  <text x="192" y="228">:</text>
                  <text x="280" y="228">AS2</text>
                  <text x="352" y="228">:</text>
                  <text x="528" x="512" y="228">:</text>
                  <text x="32" y="244">AS4</text>
                  <text x="56" y="244">:</text>
                  <text x="124" y="244">region-1</text>
                  <text x="192" y="244">:</text>
                  <text x="276" y="244">region-2</text>
                  <text x="352" y="244">:</text>
                  <text x="424" y="244">AS1</text>
                  <text x="528" x="512" y="244">:</text>
                  <text x="568" x="544" y="244">AS3</text>
                  <text x="56" y="260">:</text>
                  <text x="192" y="260">:</text>
                  <text x="352" y="260">:</text>
                  <text x="528" x="512" y="260">:</text>
                  <text x="52" y="292">203.0.113.41</text>
                  <text x="232" y="292">Traffic</text>
                  <text x="304" y="292">Direction</text>
                  <text x="516" x="500" y="292">203.0.113.31</text>
                </g>
              </svg>
</artwork><artwork
            </artwork>
            <artwork type="ascii-art"><![CDATA[
             [RR26]          [RR27]                    [RR16]
               |               |                         |
               |               |                         |
               | +--[ABR23]--+ | +--[ASBR21]-[ASBR13]--+ | +--[PE11]--+ +-[PE11]+
               | |           | | |        \  /         | | |       |
[CE41]-[PE25]-[P28]          [P29]         \/          [P15]   [CE31]
                 |           |   |         /\          |   |       |
                 |           |   |        /  \         |   |       |
                 |           |   |       /    \        |   |       |
                 +--[ABR24]--+   +--[ASBR22]-[ASBR14]--+   +--[PE12]--+   +-[PE12]+

      :      AS2       :         AS2       :                   :
  AS4 :    region-1    :      region-2     :       AS1         :  AS3
      :                :                   :                   :

203.0.113.41  ---------- Traffic Direction ------------> ---------->  203.0.113.31

]]></artwork></artset></figure>

]]></artwork>
          </artset>
        </figure>

        <t>This example shows a provider MPLS network that consists of two
        ASes, AS1 and AS2. They are serving AS2, that serve customers AS3, AS4 AS3 and AS4, respectively.
        Traffic
        The traffic direction being described is from CE41 to CE31. CE31 may request a
        specific SLA (for example, mapped (mapped to Gold for this example), when
        traversing these provider networks.</t>

        <t>AS2 is further divided into two regions. There are three tunnel
        domains in the provider's space: AS1 space:</t>
	<ul>
	  <li>AS1 uses <xref target="RFC9350">ISIS
        Flex-Algo</xref> ISIS Flex-Algo (see<xref target="RFC9350" format="default"></xref>) intra-domain tunnels. AS2 </li>
	  <li>AS2 uses RSVP-TE intra-domain
        tunnels. MPLS
          tunnels.</li>
	</ul>
	<t>MPLS forwarding is used within these domains and on
        inter-domain links.</t>
        <t>The network exposes two Transport Classes: "Gold" with Transport
        Class ID 100, 100 and "Bronze" with Transport Class ID 200. These Transport
        Classes are provisioned at the PEs and the Border nodes (ABRs, (ABRs and ASBRs)
        in the network.</t>
        <t>The following tunnels exist for the Gold Transport Class.<list> Class:</t>
        <ul spacing="normal">
          <li>
            <t>PE25_to_ABR23_gold - RSVP-TE tunnel</t>
          </li>
          <li>
            <t>PE25_to_ABR24_gold - RSVP-TE tunnel</t>
          </li>
          <li>
            <t>ABR23_to_ASBR22_gold - RSVP-TE tunnel</t>
          </li>
          <li>
            <t>ASBR13_to_PE11_gold - SRTE tunnel</t>
          </li>
          <li>
            <t>ASBR14_to_PE11_gold - SRTE tunnel</t>
          </list></t>
          </li>
        </ul>
        <t>The following tunnels exist for Bronze Transport Class.<list> Class:</t>
        <ul spacing="normal">
          <li>
            <t>PE25_to_ABR23_bronze - RSVP-TE tunnel</t>
          </li>
          <li>
            <t>ABR23_to_ASBR21_bronze - RSVP-TE tunnel</t>
          </li>
          <li>
            <t>ABR23_to_ASBR22_bronze - RSVP-TE tunnel</t>
          </li>
          <li>
            <t>ABR24_to_ASBR21_bronze - RSVP-TE tunnel</t>
          </li>
          <li>
            <t>ASBR13_to_PE12_bronze - ISIS FlexAlgo Flex-Algo tunnel</t>
          </li>
          <li>
            <t>ASBR14_to_PE11_bronze - ISIS FlexAlgo Flex-Algo tunnel</t>
          </list></t>
          </li>
        </ul>
        <t>These tunnels are either provisioned or auto-discovered autodiscovered to belong
        to Transport Classes Class IDs 100 or 200.</t>
      </section>
      <section title="Service numbered="true" toc="default">
        <name>Service Layer Route Exchange"> Exchange</name>

        <t>Service nodes PE11, PE11 and PE12 negotiate service families (AFI: 1 (AFI/SAFIs: 1/1 and
        SAFIs 1, 128)
        1/128) on the BGP session with RR16. Service helpers RR16 and
        RR26 exchange these service routes with the next hop unchanged over a
        multihop EBGP session between the two AS. ASes. PE25 negotiates service
        families (AFI: 1 (AFI/SAFIs: 1/1 and SAFIs 1, 128) 1/128) with RR26.</t>
        <t>The PEs see each other as the next hop in the BGP Update UPDATE message for the
        service family routes. BGP ADD-PATH send and receive is are enabled on
        both directions on the EBGP multihop session between RR16 and RR26 for
        AFI:1
        AFI/SAFIs: 1/1 and SAFIs 1, 128. 1/128. BGP ADD-PATH send is negotiated in the RR to
        PE direction in each AS. This is to avoid path hiding of the path-hiding service
        routes at RR; the RR, i.e., AFI/SAFI 1/1 routes advertised by both PE11 and
        PE12. Or,
        PE12 or AFI/SAFI 1/128 routes originated by both PE11 and PE12 using
        the same RD.</t>
        <t>Forwarding happens using service routes installed at service nodes
        PE25, PE11, and PE12 only. Service routes received from CEs are not
        present in any other nodes' FIB in the network.</t>
        <t>As an example, CE31 advertises a route for prefix 203.0.113.31 with
        the next hop as self itself to PE11, PE11 and PE12. CE31 can attach a Mapping Community
        Color:0:100
        color:0:100 on this route, route to indicate its request for a Gold SLA. Or,
        PE11 can attach the same using locally configured policies.</t>

        <t>Consider,
        <t>Consider CE31 is getting VPN service from PE11. The
        RD1:203.0.113.31 route is readvertised in AFI/SAFI 1/128 by PE11 with
        the next hop self set to itself (192.0.2.11) and label V-L1, V-L1 to RR16 with the Mapping
        Community Color:0:100 color:0:100 attached. RR16 advertises this route with the BGP
        ADD-PATH ID set to RR26 RR26, which readvertises to PE25 with the next hop
        unchanged. Now, PE25 can resolve the PNH 192.0.2.11 using transport
        routes received in BGP CT or BGP LU.</t>
        <t>Using BGP ADD-PATH, service routes advertised by PE11 and PE12 for
        AFI:1 SAFIs 1, 128
        AFI/SAFIs: 1/1 and 1/128 reach PE25 via RR16, RR26 with the next hop
        unchanged, as PE11 or PE12.</t>
        <t>The IP FIB at the PE25 VRF will have a route for 203.0.113.31 with a
        next hop when resolved, resolved that points to a Gold tunnel in the ingress
        domain.</t>
      </section>
      <section title="Transport numbered="true" toc="default">
        <name>Transport Layer Route Propagation"> Propagation</name>
        <t>Egress nodes PE11, PE11 and PE12 negotiate a BGP CT family with transport
        ASBRs ASBR13, ASBR13 and ASBR14. These egress nodes originate BGP CT routes for
        tunnel endpoint addresses, addresses that are advertised as a next hop in BGP
        service routes. In this example, both PEs participate in transport
        classes Transport
        Classes Gold and Bronze. The protocol procedures are explained using
        the Gold SLA transport plane and plane; the Bronze SLA transport plane is
        used to highlight the path hiding path-hiding aspects.</t>

        <t>PE11
        <t>For Gold tunnels, PE11 is provisioned with transport class Transport Class having TC ID 100, RD value
        192.0.2.11:100
        192.0.2.11:100, and a transport-target:0:100 for Gold tunnels. And a
        Transport class 200 transport-target:0:100. For Bronze tunnels, PE11 is provisioned with
        Transport Class 200, RD value 192.0.2.11:200, and transport route
        target 0:200 for Bronze tunnels. transport-target:0:200.
        Similarly, for Gold tunnels, PE12 is provisioned with
        transport class
        Transport Class having TC ID 100, RD value 192.0.2.12:100 192.0.2.12:100, and a
        transport-target:0:100 for Gold tunnels. And transport class
        transport-target:0:100. For Bronze tunnels, PE12 is provisioned with Transport Class having TC ID 200, RD
        value 192.0.2.12:200 with transport-target:0:200 for Bronze tunnels. 192.0.2.12:200, and transport-target:0:200.
        Note that that, in this example, the BGP CT routes carry only the transport
        class route target, Transport
        Class RT and no IP address format route target.</t>
        <t>The RD value originated by an egress node is not modified by any
        BGP speakers when the route is readvertised to the ingress node. Thus,
        the RD can be used to identify the originator (unique RD provisioned)
        or set of originators (RD reused on multiple nodes).</t>
        <t>Similarly, these transport classes Transport Classes are also configured on ASBRs,
        ABRs
        ABRs, and PEs with same Transport Route Target Class RT and unique RDs.</t>
        <t>ASBR13 and ASBR14 negotiate BGP CT family with transport ASBRs
        ASBR21,
        ASBR21 and ASBR22 in neighboring AS. ASBR21, ASes. ASBR21 and ASBR22 negotiate BGP CT
        family with RR27 in region 2, which reflects BGP CT routes to ABR23, ABR23 and
        ABR24. ABR23, ABR23 and ABR24 negotiate BGP CT family with Ingress ingress node PE25 in
        region 1. The BGP LU family is also negotiated on these sessions alongside the
        BGP CT family. The BGP LU family carries "best effort" transport class routes, Best-Effort Transport Class routes;
        BGP CT carries Gold, Gold and Bronze transport class Transport Class routes.</t>
        <t>PE11 is provisioned to originate a BGP CT route for endpoint PE11,
        with a Gold SLA. This route is sent with NLRI RD prefix
        192.0.2.11:100:192.0.2.11, Label B-L0, next hop 192.0.2.11 192.0.2.11, and a route
        target Route
        Target extended community transport-target:0:100. Label B-L0 can
        either be Implicit Null NULL (Label 3) or an a UHP label.</t>
        <t>This route is received by ASBR13 and it resolves over the tunnel
        ASBR13_to_PE11_gold. The route is then readvertised by ASBR13 in BGP
        CT family to ASBRs ASBR21, ASBR22 according to export policy. This
        route is sent with same NLRI RD prefix 192.0.2.11:100:192.0.2.11,
        Label B-L1, the next hop self, set to itself, and transport-target:0:100. An MPLS swap route
        is installed at ASBR13 for B-L1 with a next hop pointing to
        ASBR13_to_PE11_gold tunnel.</t>
        <t>Similarly, ASBR14 also receives a BGP CT route for
        192.0.2.11:100:192.0.2.11 from PE11 PE11, and it resolves over the tunnel
        ASBR14_to_PE11_gold. The route is then readvertised by ASBR14 in the BGP
        CT family to ASBRs ASBR21, ASBR21 and ASBR22 according to export policy. This
        route is sent with the same NLRI RD prefix 192.0.2.11:100:192.0.2.11,
        Label B-L2, next hop self, set to itself, and transport-target:0:100. An MPLS swap route
        is installed at ASBR14 for B-L1 with a next hop pointing to
        ASBR14_to_PE11_gold tunnel.</t>
        <t>In the Bronze plane, the BGP CT route with a Bronze SLA to endpoint PE11
        is originated by PE11 with a an NLRI containing RD prefix
        192.0.2.11:200:192.0.2.11,
        192.0.2.11:200:192.0.2.11 and an appropriate label. The use of distinct
        RDs for Gold and Bronze allows both Gold and Bronze advertisements to
        traverse path selection pinchpoints path-selection pinch points without any path hiding at RRs or
        ASBRs. And route target Route Target extended community transport-target:0:200 lets
        the route resolve over Bronze tunnels in the network, similar to the
        process being described for the Gold SLA path.</t>
        <t>Moving back to the Gold plane, ASBR21 receives the Gold SLA BGP CT
        routes for NLRI RD prefix 192.0.2.11:100:192.0.2.11 over the single
        hop single-hop
        EBGP sessions from ASBR13, ASBR14, ASBR13 and ASBR14 and can compute ECMP/FRR
        towards them. ASBR21 readvertises the BGP CT route for
        192.0.2.11:100:192.0.2.11 with a next hop self set to itself (loopback address
        192.0.2.21) to RR27, advertising a new label label: B-L3. An MPLS swap route
        is installed for label B-L3 at ASBR21 to swap to received label B-L1, labels B-L1 and
        B-L2 and forward to ASBR13, ASBR13 and ASBR14 respectively, respectively; this is an ECMP
        route. RR27 readvertises this BGP CT route to ABR23, ABR23 and ABR24 with the label
        and next hop unchanged.</t>
        <t>Similarly, ASBR22 receives BGP CT route 192.0.2.11:100:192.0.2.11
        over the single hop single-hop EBGP sessions from ASBR13, ASBR13 and ASBR14, and it
        readvertises with the next hop self set to itself (loopback address 192.0.2.22) to RR27,
        advertising a new label label: B-L4. An MPLS swap route is installed for
        label B-L4 at ASBR22 to swap to received label B-L1, labels B-L1 and B-L2 and forward
        to ASBR13, ASBR14 ASBR13 and ASBR14, respectively. RR27 also readvertises this BGP CT route
        also
        to ABR23, ABR23 and ABR24 with the label and next hop unchanged.</t>
        <t>BGP ADD-PATH is enabled for the BGP CT family on the sessions between
        RR27 and ASBRs, the ASBRs and ABRs such that routes for 192.0.2.11:100:192.0.2.11
        with the next hops ASBR21 and ASBR22 are reflected to ABR23, ABR23 and ABR24
        without any path hiding. Thus, ABR23 is given visibility of both
        available next hops for the Gold SLA.</t>
        <t>ABR23 receives the route with next hop 192.0.2.21, 192.0.2.21 and label B-L3 from
        RR27. The route target "transport-target:0:100" transport-target:0:100 on this route acts as
        the Mapping Community, Community and instructs ABR23 to strictly resolve the next
        hop using transport class 100 routes in TC 100 TRDB only. ABR23 is unable to find a
        route for 192.0.2.21 with transport class 100. in the TC 100 TRDB. Thus, it considers this
        route unusable and does not propagate it further. This prunes ASBR21
        from the Gold SLA tunneled path.</t>
        <t>ABR23 also receives the route with next hop 192.0.2.22, 192.0.2.22 and label B-L4
        from RR27. The route target "transport-target:0:100" transport-target:0:100 on this route
        acts as the Mapping Community, Community and instructs ABR23 to strictly resolve the
        next hop using transport class 100 routes in TC 100 TRDB only. ABR23 successfully
        resolves the next hop to point to ABR23_to_ASBR22_gold tunnel. ABR23
        readvertises this BGP CT route with the next hop self set to itself (loopback address
        192.0.2.23) and a new label B-L5 to PE25. Swap A swap route for B-L5 is
        installed by ABR23 to swap to label B-L4, B-L4 and forward into
        ABR23_to_ASBR22_gold tunnel.</t>
        <t>PE25 receives the BGP CT route for prefix 192.0.2.11:100:192.0.2.11
        with label B-L5, next hop 192.0.2.23 192.0.2.23, and transport-target:0:100 from
        RR26. And it It similarly resolves the next hop 192.0.2.23 over transport
        class 100, pushing labels associated with PE25_to_ABR23_gold
        tunnel.</t>
        <t>In this manner, the Gold transport LSP "ASBR13_to_PE11_gold" in the
        egress domain is extended by BGP CT until the ingress node PE25 in the
        ingress domain, to create an end-to-end Gold SLA path. MPLS swap
        routes are installed at ASBR13, ASBR22 ASBR22, and ABR23, when propagating the
        PE11 BGP CT Gold transport class Transport Class route 192.0.2.11:100:192.0.2.11 with
        next hop self set to itself towards PE25.</t>

        <t>The
        <t>Thus formed, the BGP CT LSP thus formed, originates in PE25, PE25 and terminates in
        ASBR13 (assuming PE11 advertised Implicit Null), NULL), traversing over the
        Gold underlay LSPs in each domain. ASBR13 uses UHP to stitch the BGP
        CT LSP into the "ASBR13_to_PE11_gold" LSP to traverse the last domain,
        thus satisfying Gold SLA end-to-end.</t>
        <t>When PE25 receives service routes from RR26 with next hop
        192.0.2.11 and mapping community Color:0:100, Mapping Community color:0:100, it resolves over this
        BGP CT route 192.0.2.11:100:192.0.2.11. Thus, pushing label B-L5, B-L5 and
        pushing as the top label the labels associated with PE25_to_ABR23_gold
        tunnel.</t>
      </section>
      <section title="Data numbered="true" toc="default">
        <name>Data Plane View"> View</name>
        <section title="Steady State"> numbered="true" toc="default">
          <name>Steady State</name>
          <t>This section describes how the data plane looks in steady
          state.</t>
          <t>CE41 transmits an IP packet with the destination as 203.0.113.31. On
          receiving this packet, PE25 performs a lookup in the IP FIB
          associated with the CE41 interface. This lookup yields the service
          route that pushes the VPN service label V-L1, BGP CT label B-L5, and
          labels for PE25_to_ABR23_gold tunnel. Thus, PE25 encapsulates the IP
          packet in an MPLS packet with label labels V-L1 (innermost), B-L5, and top
          label as PE25_to_ABR23_gold tunnel. This MPLS packet is thus
          transmitted to ABR23 using the Gold SLA.</t>
          <t>ABR23 decapsulates the packet received on PE25_to_ABR23_gold
          tunnel as required, required and finds the MPLS packet with label B-L5. It
          performs a lookup for label B-L5 in the global MPLS FIB. This yields
          the route that swaps label B-L5 with label B-L4, B-L4 and pushes the top
          label provided by ABR23_to_ASBR22_gold tunnel. Thus, ABR23 transmits
          the MPLS packet with label B-L4 to ASBR22, ASBR22 on a tunnel that
          satisfies the Gold SLA.</t>
          <t>ASBR22 similarly performs a lookup for label B-L4 in the global MPLS
          FIB, finds the route that swaps label B-L4 with label B-L2, and
          forwards it to ASBR13 over the directly connected MPLS-enabled
          interface. This interface is a common resource not dedicated to any
          specific transport class, Transport Class, in this example.</t>
          <t>ASBR13 receives the MPLS packet with label B-L2, B-L2 and performs a
          lookup in the MPLS FIB, finds the route that pops label B-L2, and pushes
          labels associated with ASBR13_to_PE11_gold tunnel. This transmits
          the MPLS packet with VPN label V-L1 to PE11 using a tunnel that
          preserves the Gold SLA in AS 1.</t>
          <t>PE11 receives the MPLS packet with V-L1, V-L1 and performs VPN
          forwarding. Thus
          forwarding, thus transmitting the original IP payload from CE41 to
          CE31. The payload has traversed path satisfying the Gold SLA
          end-to-end.</t>
        </section>
        <section title="Local numbered="true" toc="default">
          <name>Local Repair of Primary Path"> Path</name>
          <t>This section describes how the data plane at ASBR22 reacts when
          the link between ASBR22 and ASBR13 experiences a failure, failure and an
          alternate path exists.</t>
          <t>Assuming the ASBR22_to_ASBR13 link goes down, such that traffic with
          a Gold SLA going to PE11 needs will need repair. ASBR22 has an alternate BGP CT
          route for 192.0.2.11:100:192.0.2.11 from ASBR14. This has been
          preprogrammed in forwarding by ASBR22 as an FRR backup next hop for
          label B-L4. This allows the Gold SLA traffic to be locally repaired
          at ASBR22 without the failure event propagated in the BGP CT
          network. In this case, ingress node PE25 will not know there was a
          failure, and traffic restoration will be independent of prefix scale
          (PIC).</t>
        </section>
        <section title="Absorbing numbered="true" toc="default">
          <name>Absorbing Failure of the Primary Path: Fallback to Best Effort Tunnels "> Best-Effort Tunnels</name>
          <t>This section describes how the data plane reacts when a Gold path
          experiences a failure, failure but no alternate path exists.</t>
          <t>Assume tunnel ABR23_to_ASBR22_gold goes down, such that now no
          end-to-end Gold path exists in the network. This makes the BGP CT
          route for RD prefix 192.0.2.11:100:192.0.2.11 is unusable at ABR23.
          This makes ABR23 send a BGP withdrawal for 192.0.2.11:100:192.0.2.11
          to PE25.</t>
          <t>The withdrawal for 192.0.2.11:100:192.0.2.11 allows PE25 to react
          to the loss of the Gold path to 192.0.2.11. Assuming PE25 is
          provisioned to use best effort transport class a Best-Effort Transport Class as the backup path,
          this withdrawal of a BGP CT route allows PE25 to adjust the next hop
          of the VPN Service-route service route to push the labels provided by the BGP LU
          route. That repairs the traffic to go via the best effort best-effort path. PE25
          can also be provisioned to use the Bronze transport class Transport Class as the backup
          path. The repair will happen in similar manner in that case
          as-well.</t>
          as well.</t>
          <t>Traffic repair to absorb the failure happens at ingress node
          PE25,
          PE25 in a service prefix scale independent manner. This is called
          PIC. manner (PIC). The repair time will be proportional to time taken for withdrawing
          the BGP CT route.</t>
          <t>These examples demonstrate the various levels of failsafe fail-safe
          mechanisms available to protect traffic in a BGP CT network.</t>
        </section>
      </section>
    </section>
    <section title="Scaling Considerations"> numbered="true" toc="default">
      <name>Scaling Considerations</name>
      <section anchor="secure-propagate"
               title="Avoiding numbered="true" toc="default">
        <name>Avoiding Unintended Spread of BGP CT Routes Across Domains">
        <list> Domains</name>
            <t><xref target="RFC8212"/> target="RFC8212" format="default"/> suggests BGP speakers require explicit
          configuration of both BGP Import and Export Policies in order to
          receive or send routes over EBGP sessions.</t>
            <t>It is recommended to follow this for BGP CT routes. It will
          prohibit unintended advertisement of transport routes throughout the
          BGP CT transport domain, which may span across multiple AS domains.
          This will conserve usage of resources for MPLS label labels and next hop resources hops in the
          network. An ASBR of a domain can be provisioned to allow routes with
          only the Transport Route Targets Class RTs that are required by SNs in the
          domain.</t>
        </list>
      </section>
      <section title="Constrained numbered="true" toc="default">
        <name>Constrained Distribution of PNHs to SNs (On-Demand Next Hop)">
        <list> Hop)</name>
            <t>This section describes how the number of Protocol Next hops Hops (PNHs)
          advertised to a an SN or BN can be constrained using BGP Classful
          Transport and RTC (see <xref target="RFC4684">Route Target Constrain
          (RTC)</xref>.</t> target="RFC4684" format="default"></xref>.</t>

            <t>An egress SN MAY <bcp14>MAY</bcp14> advertise a BGP CT route for RD:eSN with two
          Route Targets: transport-target:0:&lt;TC&gt; and a an RT carrying
          &lt;eSN&gt;:&lt;TC&gt;, where TC is the Transport Class identifier, identifier
          and eSN is the IP address used by the SN as BGP next hop in its service
          route advertisements.</t>
            <t>Note that such use of the IP address specific IP-address-specific route target
          &lt;eSN&gt;:&lt;TC&gt; is optional in a BGP CT network. It is
          required only if there is a requirement to prune the propagation of
          the transport route for an egress node eSN to only the set of
          ingress nodes that need it. When only the RT of
          transport-target:0:&lt;TC&gt; is used, the pruning happens in
          granularity of Transport Class ID (Color), and not BGP next hop; a
          BGP CT route will only be advertised into a domain with at least one
          PE that imports its transport class.</t> Transport Class.</t>
            <t>The transport-target:0:&lt;TC&gt; is the new type of route target
          (Transport Class RT) defined in this document. It is carried in the BGP
          extended community attribute (BGP attribute (attribute code 16).</t>
            <t>The RT carrying &lt;eSN&gt;:&lt;TC&gt; MAY <bcp14>MAY</bcp14> be an IP-address
          specific IP-address-specific regular RT (BGP attribute (attribute code 16), or IPv6-address
          specific RT (BGP attribute (attribute code 25). It should be noted that the
          Local Administrator field of these RTs can only carry two octets of
          information, and thus
          information; thus, the &lt;TC&gt; field in this approach is
          limited to a 2 octets 2-octet value. Future protocol extensions extension work is
          needed to define a BGP CCA that can accomodate accommodate an IPv4/IPv6 address
          along with a 4 octet 4-octet Local Administrator field.</t>
            <t>An ingress SN MAY <bcp14>MAY</bcp14> import BGP CT routes with a Route Target carrying
          &lt;eSN&gt;:&lt;TC&gt;. The ingress SN may learn the eSN values
          either
          by configuration, configuration or it may discover them from the BGP next
          hop field in the BGP VPN service routes received from the eSN. A BGP
          ingress SN receiving a BGP service route with a next hop of eSN
          generates a an RTC route for Route Target prefix &lt;Origin
          ASN&gt;:&lt;eSN&gt;/[80|176] in order to learn BGP CT transport
          routes to reach eSN. This allows constrained distribution of the
          transport routes to the PNHs actually required by iSN.</t>
            <t>When RTC is in use use, as described here, BGP CT routes will be
          constrained to follow the same path of propagation as the RTC
          routes. Therefore, a BN would learn the RTC routes advertised by
          ingress SNs and propagate further. This will allow constraining
          distribution of BGP CT routes for a PNH to only the necessary BNs in
          the network, closer to the egress SN.</t>
            <t>When the path of route propagation of BGP CT routes is the same
          as the RTC routes, a BN would learn the RTC routes advertised by
          ingress SNs and propagate further. This will allow constraining
          distribution of BGP CT routes for a PNH to only the necessary BNs in
          the network, closer to the egress SN.</t>
            <t>This mechanism provides "On Demand "On-Demand Next hop" Hop" of BGP CT routes,
          which help helps with the scaling of MPLS forwarding state at the SN and
          BN.</t>
            <t>However, the amount of state carried in RTC family may become
          proportional to the number of PNHs in the network. To strike a
          balance, the RTC route advertisements for &lt;Origin
          ASN&gt;:&lt;eSN&gt;/[80|176] MAY <bcp14>MAY</bcp14> be confined to the BNs in the home
          region of an ingress SN, or the BNs of a super core.</t>
            <t>Such a BN in the core of the network imports BGP CT routes with
          Transport-Target:0:&lt;TC&gt; and generates an RTC route for
          &lt;Origin ASN&gt;:0:&lt;TC&gt;/96, while not propagating the more
          specific RTC requests for specific PNHs. This lets the BN learn
          transport routes to all eSN nodes but confine confines their propagation to
          ingress SNs.</t>
        </list>

      </section>
      <section title="Limiting The numbered="true" toc="default">
        <name>Limiting the Visibility Scope of PE Loopback as PNHs">
        <list> PNHs</name>
            <t>It may be even more desirable to limit the number of PNHs that
          are globally visible in the network. This is possible using
          the mechanism described in <xref target="Appendix D"/>, such that
          advertisement of PE loopback addresses as next-hop in BGP service
          routes is confined to the region they belong to. An anycast
          IP-address called "Context Protocol Nexthop Address" (CPNH)
          abstracts the SNs in a region from other regions in the network.</t> target="Appendix_D" format="default"/>.</t>

            <t>Such that advertisement of PE loopback addresses as next-hop next hop in
          BGP service routes is confined to the region they belong to. An
          anycast IP-address called "Context Protocol Nexthop Address" (CPNH)
          abstracts the SNs in a region from other regions in the network.</t>
            <t>This provides much greater advantage in terms of scaling,
          convergence and security. Changes to implement this feature are
          required only on the local region's BNs and RRs, so legacy PE
          devices can also benefit from this approach.</t>
        </list>

      </section>
    </section>
    <section title="Operations numbered="true" toc="default">
      <name>Operations and Manageability Considerations"> Considerations</name>
      <section anchor="mpls-oam" title="MPLS OAM"> numbered="true" toc="default">
        <name>MPLS OAM</name>
        <t>MPLS OAM Operations, Administration, and Maintenance (OAM) procedures specified in <xref target="RFC8029"/> target="RFC8029" format="default"/> also
        apply to BGP Classful Transport.</t> CT.</t>
        <t>The 'Target Target FEC Stack' Stack sub-TLV for IPv4 Classful Transport BGP CT has a
        Sub-Type of 31744, 31744 and a length of 13. The Value field consists of the
        RD advertised with the Classful Transport BGP CT prefix, the IPv4 prefix
        (with trailing 0 bits to make 32 bits in all) all), and a prefix length
        encoded as shown in <xref target="FECv4"/>.</t> target="FECv4" format="default"/>.</t>
        <figure anchor="FECv4" suppress-title="false"
            title="Classful Transport anchor="FECv4">
          <name>BGP CT IPv4 FEC"> FEC</name>
          <artwork align="left" xml:space="preserve"> name="" type="" alt=""><![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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                      Route Distinguisher                      |
|                          (8 octets)                           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                         IPv4 prefix                           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prefix Length |                 Must Be Zero                  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork>
]]></artwork>
        </figure>
        <t>The 'Target Target FEC Stack' Stack sub-TLV for IPv6 Classful Transport BGP CT has a
        Sub-Type of 31745, 31745 and a length of 25. The Value field consists of the
        RD advertised with the Classful Transport BGP CT prefix, the IPv6 prefix
        (with trailing 0 bits to make 128 bits in all) and a prefix length
        encoded as shown in <xref target="FECv6"/>.</t> target="FECv6" format="default"/>.</t>
        <figure anchor="FECv6" suppress-title="false"
                title="Classful Transport anchor="FECv6">
          <name>BGP CT IPv6 FEC"> FEC</name>
          <artwork align="left" xml:space="preserve"> name="" type="" alt=""><![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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                      Route Distinguisher                      |
|                          (8 octets)                           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                         IPv6 prefix                           |
|                                                               |
|                                                               |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prefix Length |                 Must Be Zero                  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork>
]]></artwork>
        </figure>
        <t>These prefix layouts are inherited from Sections 3.2.5, 3.2.6 in <xref target="RFC8029"/></t>
        target="RFC8029" sectionFormat="bare" section="3.2.5"/> and <xref
        target="RFC8029" sectionFormat="bare" section="3.2.6"/> of <xref
        target="RFC8029" format="default"/>.</t>
      </section>
      <section anchor="rd-lbl-usage"
               title="Usage numbered="true" toc="default">
        <name>Usage of Route Distinguisher RD and Label Allocation Modes"> Label-Allocation Modes</name>
        <t>RDs aid in troubleshooting provider networks that deploy BGP CT, by
        uniquely identifying the originator of a route across an
        administrative domain that may either span multiple domains within a
        provider network or span closely coordinated provider networks.</t>
        <t>The use of RDs also provides an option for signaling forwarding
        diversity within the same Transport Class. A An SN can advertise an EP
        with the same Transport Class in multiple BGP CT routes with unique
        RDs.</t>
        <t>For example, unique "RDx:EP1" prefixes can be advertised by an SN
        for an EP1 to different upstream BNs with unique forwarding specific forwarding-specific
        encapsulation (e.g., Label), a Label) in order to collect traffic statistics at
        the SN for each BN. In the absence of an RD, duplicated Transport Class/Color Class / Color
        values will be needed in the transport network to achieve such use
        cases.</t>
        <t>The allocation of RDs is done at the point of origin of the BGP CT
        route. This can either be either an Egress egress SN or a BN. The default RD
        allocation mode is to use a unique RD per originating node for an EP.
        This mode allows for the ingress to uniquely identify each originated
        path. Alternatively, the same RD may be provisioned for multiple
        originators of the same EP. This mode can be used when the ingress
        does not require full visibility of all nodes originating an EP.</t>
        <t>A label is allocated for a BGP CT route when it is advertised with
        the next hop self set to itself by a an SN or a BN. An implementation may use different
        label allocation
        label-allocation modes with BGP CT. The Per-prefix is the recommended label allocation label-allocation
        mode is per-prefix as it provides better traffic convergence
        properties than per-next hop label allocation a per-NH label-allocation mode. Furthermore, BGP
        CT offers two flavors for per-prefix label allocation. The allocation:</t>
	<ul spacing="normal">
	  <li>The first
          flavor assigns a label for each unique "RD, EP". The EP".</li>
	  <li>The second flavor
        assigns a label for each unique "Transport Class, EP" while ignoring
          the RD.</t> RD.</li>
	</ul>
        <t>In a BGP CT network, the number of routes at an Ingress ingress PE is a
        function of unique EPs multiplied by BNs in the ingress domain that do have the
        next hop self. set to themselves. BGP CT provides flexible RD and Label allocation label-allocation modes
        to address operational requirements in a multi-domain network. The
        impacts on the control plane and forwarding behavior for these modes
        are detailed with an example in <xref target="CTRouteVis">Managing
        Transport Route Visibility</xref></t> target="CTRouteVis" format="default"></xref>.</t>
      </section>
      <section anchor="CTRouteVis" title="Managing Transport Route Visibility"> numbered="true" toc="default">
        <name>Managing Transport-Route Visibility</name>
        <t>This section details the usage of BGP CT RD and label allocation label-allocation
        modes to calibrate the level of path visibility and the amount of
        route and label scale in a multi-domain network.</t>
        <t>Consider a multi-domain BGP CT network as illustrated in the
        following <xref target="MultiDomainNetwork"/>:</t> target="MultiDomainNetwork" format="default"/>:</t>
        <figure title="Managing Transport Route anchor="MultiDomainNetwork">
          <name>Managing Transport-Route Visibility in Multi Domain Network" anchor="MultiDomainNetwork"><artset><artwork  type="svg"><svg Multi-Domain Networks</name>
          <artset>
            <artwork type="svg" name="" align="left" alt=""><svg xmlns="http://www.w3.org/2000/svg" version="1.1" height="400" width="432" viewBox="0 0 432 400" class="diagram" text-anchor="middle" font-family="monospace" font-size="13px" stroke-linecap="round">
                <path d="M 80,112 L 80,176" fill="none" stroke="black"/>
                <path d="M 80,208 L 80,272" fill="none" stroke="black"/>
                <path d="M 136,80 L 136,96" fill="none" stroke="black"/>
                <path d="M 136,128 L 136,144" fill="none" stroke="black"/>
                <path d="M 136,240 L 136,256" fill="none" stroke="black"/>
                <path d="M 136,288 L 136,304" fill="none" stroke="black"/>
                <path d="M 288,128 L 288,176" fill="none" stroke="black"/>
                <path d="M 288,288 L 288,336" fill="none" stroke="black"/>
                <path d="M 136,80 L 216,80" fill="none" stroke="black"/>
                <path d="M 312,80 L 328,80" fill="none" stroke="black"/>
                <path d="M 80,112 L 112,112" fill="none" stroke="black"/>
                <path d="M 304,112 L 328,112" fill="none" stroke="black"/>
                <path d="M 136,144 L 216,144" fill="none" stroke="black"/>
                <path d="M 312,144 L 328,144" fill="none" stroke="black"/>
                <path d="M 288,176 L 328,176" fill="none" stroke="black"/>
                <path d="M 136,240 L 216,240" fill="none" stroke="black"/>
                <path d="M 312,240 L 328,240" fill="none" stroke="black"/>
                <path d="M 80,272 L 112,272" fill="none" stroke="black"/>
                <path d="M 304,272 L 328,272" fill="none" stroke="black"/>
                <path d="M 136,304 L 216,304" fill="none" stroke="black"/>
                <path d="M 312,304 L 328,304" fill="none" stroke="black"/>
                <path d="M 288,336 L 328,336" fill="none" stroke="black"/>
                <path d="M 48,368 L 128,368" fill="none" stroke="black"/>
                <path d="M 288,368 L 352,368" fill="none" stroke="black"/>
                <path d="M 304,288 L 312,304" fill="none" stroke="black"/>
                <path d="M 304,128 L 312,144" fill="none" stroke="black"/>
                <path d="M 304,96 L 312,80" fill="none" stroke="black"/>
                <path d="M 304,256 L 312,240" fill="none" stroke="black"/>
                <polygon class="arrowhead" points="360,368 348,362.4 348,373.6" fill="black" transform="rotate(0,352,368)"/>
                <g class="text">
                  <text x="92" y="36">......................</text>
                  <text x="312" y="36">.............................</text>
                  <text x="8" y="52">:</text>
                  <text x="96" y="52">AS3</text>
                  <text x="176" y="52">:</text>
                  <text x="200" y="52">:</text>
                  <text x="312" y="52">AS1</text>
                  <text x="424" y="52">:</text>
                  <text x="8" y="68">:</text>
                  <text x="176" y="68">:</text>
                  <text x="200" y="68">:</text>
                  <text x="424" y="68">:</text>
                  <text x="8" y="84">:</text>
                  <text x="244" y="84">ASBR11</text>
                  <text x="348" y="84">PE11</text>
                  <text x="392" y="84">(EP1)</text>
                  <text x="424" y="84">:</text>
                  <text x="8" y="100">:</text>
                  <text x="176" y="100">:</text>
                  <text x="200" y="100">:</text>
                  <text x="272" y="100">\</text>
                  <text x="424" y="100">:</text>
                  <text x="8" y="116">:</text>
                  <text x="140" y="116">ASBR31</text>
                  <text x="176" y="116">:</text>
                  <text x="200" y="116">:</text>
                  <text x="288" y="116">[P]</text>
                  <text x="348" y="116">PE12</text>
                  <text x="392" y="116">(EP2)</text>
                  <text x="424" y="116">:</text>
                  <text x="8" y="132">:</text>
                  <text x="176" y="132">:</text>
                  <text x="200" y="132">:</text>
                  <text x="272" y="132">/</text>
                  <text x="424" y="132">:</text>
                  <text x="8" y="148">:</text>
                  <text x="244" y="148">ASBR12</text>
                  <text x="348" y="148">PE13</text>
                  <text x="392" y="148">(EP3)</text>
                  <text x="424" y="148">:</text>
                  <text x="8" y="164">:</text>
                  <text x="176" y="164">:</text>
                  <text x="200" y="164">:</text>
                  <text x="424" y="164">:</text>
                  <text x="8" y="180">:</text>
                  <text x="176" y="180">:</text>
                  <text x="200" y="180">:</text>
                  <text x="348" y="180">PE14</text>
                  <text x="392" y="180">(EP4)</text>
                  <text x="424" y="180">:</text>
                  <text x="8" y="196">:</text>
                  <text x="56" y="196">PE31--[P]</text>
                  <text x="176" y="196">:</text>
                  <text x="200" y="196">:</text>
                  <text x="424" y="196">:</text>
                  <text x="8" y="212">:</text>
                  <text x="176" y="212">:</text>
                  <text x="200" y="212">:</text>
                  <text x="424" y="212">:</text>
                  <text x="8" y="228">:</text>
                  <text x="176" y="228">:</text>
                  <text x="200" y="228">:</text>
                  <text x="424" y="228">:</text>
                  <text x="8" y="244">:</text>
                  <text x="244" y="244">ASBR21</text>
                  <text x="348" y="244">PE21</text>
                  <text x="392" y="244">(EP5)</text>
                  <text x="424" y="244">:</text>
                  <text x="8" y="260">:</text>
                  <text x="176" y="260">:</text>
                  <text x="200" y="260">:</text>
                  <text x="272" y="260">\</text>
                  <text x="424" y="260">:</text>
                  <text x="8" y="276">:</text>
                  <text x="140" y="276">ASBR32</text>
                  <text x="176" y="276">:</text>
                  <text x="200" y="276">:</text>
                  <text x="288" y="276">[P]</text>
                  <text x="348" y="276">PE22</text>
                  <text x="392" y="276">(EP6)</text>
                  <text x="424" y="276">:</text>
                  <text x="8" y="292">:</text>
                  <text x="176" y="292">:</text>
                  <text x="200" y="292">:</text>
                  <text x="272" y="292">/</text>
                  <text x="424" y="292">:</text>
                  <text x="8" y="308">:</text>
                  <text x="244" y="308">ASBR22</text>
                  <text x="348" y="308">PE22</text>
                  <text x="392" y="308">(EP7)</text>
                  <text x="424" y="308">:</text>
                  <text x="8" y="324">:</text>
                  <text x="176" y="324">:</text>
                  <text x="200" y="324">:</text>
                  <text x="424" y="324">:</text>
                  <text x="8" y="340">:</text>
                  <text x="176" y="340">:</text>
                  <text x="200" y="340">:</text>
                  <text x="348" y="340">PE24</text>
                  <text x="392" y="340">(EP8)</text>
                  <text x="424" y="340">:</text>
                  <text x="92" y="356">......................</text>
                  <text x="312" y="356">.............................</text>
                  <text x="168" y="372">Traffic</text>
                  <text x="240" y="372">Direction</text>
                </g>
              </svg>
</artwork><artwork  type="ascii-art"><![CDATA[
            </artwork>
            <artwork type="ascii-art" name="" align="left" alt=""><![CDATA[
   ......................  .............................
   :         AS3        :  :            AS1            :
   :                    :  :                           :
   :               +----------ASBR11     +--PE11 (EP1) :
   :               |    :  :        \   /              :
   :        +----ASBR31 :  :         [P]----PE12 (EP2) :
   :        |      |    :  :        / | \              :
   :        |      +----------ASBR12  |  +--PE13 (EP3) :
   :        |           :  :          |                :
   :        |           :  :          +-----PE14 (EP4) :
   : PE31--[P]          :  :                           :
   :        |           :  :                           :
   :        |           :  :                           :
   :        |      +----------ASBR21     +--PE21 (EP5) :
   :        |      |    :  :        \   /              :
   :        +----ASBR32 :  :         [P]----PE22 (EP6) :
   :               |    :  :        / | \              :
   :               +----------ASBR22  |  +--PE22 (EP7) :
   :                    :  :          |                :
   :                    :  :          +-----PE24 (EP8) :
   ......................  .............................
        ----------- Traffic Direction -------->
]]></artwork></artset></figure>
]]></artwork>
          </artset>
        </figure>
        <t>The following table provides a comparison of the BGP CT route and
        label scale, scale for varying endpoint path endpoint-path visibility at ingress node PE31
        for each TC. It analyzes scenarios where Unicast or Anycast EPs
        (EP-type) may be originated by different node roles (Origin), using
        different RD allocation modes (RD-Mode), (RD-Modes), and different Per-Prefix
        Label allocation
        label-allocation modes (PP-Mode).</t> (PP-Modes).</t>
        <figure title="Route anchor="RDLabelVis">
          <name>Route and Path Visibility at Ingress Node" anchor="RDLabelVis"><artset><artwork  type="svg"><svg Node</name>
          <artset>
            <artwork type="svg" name="" align="left" alt=""><svg xmlns="http://www.w3.org/2000/svg" version="1.1" height="320" width="432" viewBox="0 0 432 320" class="diagram" text-anchor="middle" font-family="monospace" font-size="13px" stroke-linecap="round">
                <path d="M 8,32 L 8,288" fill="none" stroke="black"/>
                <path d="M 80,32 L 80,288" fill="none" stroke="black"/>
                <path d="M 136,32 L 136,288" fill="none" stroke="black"/>
                <path d="M 200,32 L 200,288" fill="none" stroke="black"/>
                <path d="M 264,32 L 264,288" fill="none" stroke="black"/>
                <path d="M 344,32 L 344,288" fill="none" stroke="black"/>
                <path d="M 424,32 L 424,288" fill="none" stroke="black"/>
                <path d="M 8,32 L 424,32" fill="none" stroke="black"/>
                <path d="M 8,64 L 424,64" fill="none" stroke="black"/>
                <path d="M 16,144 L 72,144" fill="none" stroke="black"/>
                <path d="M 88,144 L 128,144" fill="none" stroke="black"/>
                <path d="M 144,144 L 192,144" fill="none" stroke="black"/>
                <path d="M 208,144 L 256,144" fill="none" stroke="black"/>
                <path d="M 272,144 L 336,144" fill="none" stroke="black"/>
                <path d="M 352,144 L 416,144" fill="none" stroke="black"/>
                <path d="M 8,288 L 424,288" fill="none" stroke="black"/>
                <g class="text">
                  <text x="40" y="52">EP-type</text>
                  <text x="108" y="52">Origin</text>
                  <text x="168" y="52">RD-Mode</text>
                  <text x="232" y="52">PP-Mode</text>
                  <text x="276" y="52">CT</text>
                  <text x="316" y="52">Routes</text>
                  <text x="356" y="52">CT</text>
                  <text x="396" y="52">Labels</text>
                  <text x="40" y="84">Unicast</text>
                  <text x="92" y="84">SN</text>
                  <text x="164" y="84">Unique</text>
                  <text x="224" y="84">TC,EP</text>
                  <text x="312" y="84">8</text>
                  <text x="384" y="84">8</text>
                  <text x="40" y="100">Unicast</text>
                  <text x="92" y="100">SN</text>
                  <text x="164" y="100">Unique</text>
                  <text x="224" y="100">RD,EP</text>
                  <text x="312" y="100">8</text>
                  <text x="384" y="100">8</text>
                  <text x="40" y="116">Unicast</text>
                  <text x="92" y="116">BN</text>
                  <text x="164" y="116">Unique</text>
                  <text x="224" y="116">TC,EP</text>
                  <text x="308" y="116">16</text>
                  <text x="384" y="116">8</text>
                  <text x="40" y="132">Unicast</text>
                  <text x="92" y="132">BN</text>
                  <text x="164" y="132">Unique</text>
                  <text x="224" y="132">RD,EP</text>
                  <text x="308" y="132">16</text>
                  <text x="380" y="132">16</text>
                  <text x="40" y="164">Anycast</text>
                  <text x="92" y="164">SN</text>
                  <text x="164" y="164">Unique</text>
                  <text x="224" y="164">TC,EP</text>
                  <text x="312" y="164">8</text>
                  <text x="384" y="164">2</text>
                  <text x="40" y="180">Anycast</text>
                  <text x="92" y="180">SN</text>
                  <text x="164" y="180">Unique</text>
                  <text x="224" y="180">RD,EP</text>
                  <text x="312" y="180">8</text>
                  <text x="384" y="180">8</text>
                  <text x="40" y="196">Anycast</text>
                  <text x="92" y="196">SN</text>
                  <text x="156" y="196">Same</text>
                  <text x="224" y="196">TC,EP</text>
                  <text x="312" y="196">2</text>
                  <text x="384" y="196">2</text>
                  <text x="40" y="212">Anycast</text>
                  <text x="92" y="212">SN</text>
                  <text x="156" y="212">Same</text>
                  <text x="224" y="212">RD,EP</text>
                  <text x="312" y="212">2</text>
                  <text x="384" y="212">2</text>
                  <text x="40" y="228">Anycast</text>
                  <text x="92" y="228">BN</text>
                  <text x="164" y="228">Unique</text>
                  <text x="224" y="228">TC,EP</text>
                  <text x="312" y="228">4</text>
                  <text x="384" y="228">2</text>
                  <text x="40" y="244">Anycast</text>
                  <text x="92" y="244">BN</text>
                  <text x="164" y="244">Unique</text>
                  <text x="224" y="244">RD,EP</text>
                  <text x="312" y="244">4</text>
                  <text x="384" y="244">4</text>
                  <text x="40" y="260">Anycast</text>
                  <text x="92" y="260">BN</text>
                  <text x="156" y="260">Same</text>
                  <text x="224" y="260">TC,EP</text>
                  <text x="312" y="260">2</text>
                  <text x="384" y="260">2</text>
                  <text x="40" y="276">Anycast</text>
                  <text x="92" y="276">BN</text>
                  <text x="156" y="276">Same</text>
                  <text x="224" y="276">RD,EP</text>
                  <text x="312" y="276">2</text>
                  <text x="384" y="276">2</text>
                </g>
              </svg>
</artwork><artwork  type="ascii-art"><![CDATA[
            </artwork>
            <artwork type="ascii-art" name="" align="left" alt=""><![CDATA[
      +--------+------+-------+-------+---------+---------+
      |EP-type |Origin|RD-Mode|PP-Mode|CT Routes|CT Labels|
      +--------+------+-------+-------+---------+---------+
      |Unicast |SN    |Unique |TC,EP  |     8   |    8    |
      |Unicast |SN    |Unique |RD,EP  |     8   |    8    |
      |Unicast |BN    |Unique |TC,EP  |    16   |    8    |
      |Unicast |BN    |Unique |RD,EP  |    16   |   16    |
      |--------|------|-------|-------|---------|---------|
      |Anycast |SN    |Unique |TC,EP  |     8   |    2    |
      |Anycast |SN    |Unique |RD,EP  |     8   |    8    |
      |Anycast |SN    |Same   |TC,EP  |     2   |    2    |
      |Anycast |SN    |Same   |RD,EP  |     2   |    2    |
      |Anycast |BN    |Unique |TC,EP  |     4   |    2    |
      |Anycast |BN    |Unique |RD,EP  |     4   |    4    |
      |Anycast |BN    |Same   |TC,EP  |     2   |    2    |
      |Anycast |BN    |Same   |RD,EP  |     2   |    2    |
      +--------+------+-------+-------+---------+---------+
]]></artwork></artset></figure>
]]></artwork>
          </artset>
        </figure>
        <t>In the table shown in <xref target="RDLabelVis"/>, target="RDLabelVis" format="default"/>, route scale at
        ingress node PE31 is proportional to path diversity in the ingress domain
        (number of ASBRs) and point of origination of the BGP CT route. TE
        granularity at ingress node PE31 is proportional to the number of
        unique CT labels received, which depends on PP-mode the PP-Mode and the path
        diversity in the ingress domain.</t>
        <t>Deploying unique RDs is strongly RECOMMENDED <bcp14>RECOMMENDED</bcp14> because it helps in
        troubleshooting by uniquely identifying the originator of a route and
        avoids path-hiding.</t> path hiding.</t>
        <t>In typical deployments deployments, originating BGP CT routes at the egress node
        (SN) is recommended. In this model, using either an "RD, EP" or "TC, EP"
        Per-Prefix label allocation label-allocation mode repairs traffic locally at the
        nearest BN for any failures in the network, network because the label value
        does not change.</t>
        <t>Originating at BNs with unique RDs induces more routes than when
        originating at egress SNs. In this model, use of the "TC, EP" Per-Prefix
        label allocation
        label-allocation mode repairs traffic locally at the nearest BN for
        any failures in the network, network because the label value does not
        change.</t>

        <t>The previous table in <xref target="RDLabelVis"/>
        <t><xref target="RDLabelVis" format="default"/> demonstrates that
        BGP CT allows an operator to control how much path visibility and
        forwarding diversity is desired in the network, network for both Unicast and
        Anycast endpoints.</t>
      </section>
    </section>
    <section anchor="CTdeploy" title="Deployment Considerations."> numbered="true" toc="default">
      <name>Deployment Considerations</name>
      <section title="Coordination numbered="true" toc="default">
        <name>Coordination Between Domains Using Different Community Namespaces"> Namespaces</name>
        <t>Cooperating Inter-AS Option inter-AS option C domains may sometimes not agree on
        RT, RD, Mapping community Community, or Transport Route Target Class RT values because of
        differences in community namespaces (e.g. (e.g., during network mergers or
        renumbering for expansion). Such deployments may deploy mechanisms to
        map and rewrite the Route Target values on domain boundaries, boundaries using
        per ASBR
        per-ASBR import policies. This is no different than any other BGP VPN
        family. Mechanisms used in inter-AS VPN deployments may be leveraged
        with the Classful Transport BGP CT family also.</t>
        <t>A resolution scheme Resolution Scheme allows association with multiple Mapping
        Communities. This minimizes service disruption during renumbering,
        network merger merger, or transition scenarios.</t>
        <t>The Transport Class Route Target Extended Community RT is useful to
        avoid collision with regular Route Target namespace used by service
        routes.</t>
      </section>
      <section title="Managing numbered="true" toc="default">
        <name>Managing Intent at Service and Transport layers."> Layers</name>
        <t><xref target="CTProc">Illustration of BGP CT Procedures </xref> target="CTProc" format="default"></xref>
        shows multiple domains that agree on a color name space namespace (Agreeing
        Color Domains) and contain tunnels with an equivalent set of colors
        (Homogenous Color Domains).</t>
        <t>However, in the real world, this may not always be guaranteed. Two
        domains may independently manage their color namespaces; these are
        known as Non-Agreeing Color Domains. Two domains may have tunnels with
        unequal sets of colors; these are known as Heterogeneous Color
        Domains.</t>
        <t>This section describes how BGP CT is deployed in such scenarios to
        preserve end-to-end Intent. Examples described in this section use
        Inter-AS Option
        inter-AS option C domains. Similar mechanisms will work for Inter-AS
        Option inter-AS
        option A and Inter-AS Option inter-AS option B scenarios as well.</t>
        <section title="Service numbered="true" toc="default">
          <name>Service Layer Color Management "> Management</name>
          <t>At the service layer, it is recommended that a global color
          namespace be maintained across multiple co-operating cooperating domains. BGP CT
          allows indirection using resolution schemes Resolution Schemes to be able to maintain a
          global namespace in the service layer. This is possible even if each
          domain independently maintains its own local transport color
          namespace.</t>
          <t>As explained in <xref target="Nexthop_Resoln_Schm">Next Hop
          Resolution Scheme</xref> , target="Nexthop_Resoln_Schm" format="default"></xref>, a mapping community Mapping Community carried on a service
          route maps to a resolution scheme. Resolution Scheme. The mapping community Mapping Community values for
          the service route can be abstract and are not required to match the
          transport color namespace. This abstract mapping community Mapping Community value
          representing a global service layer intent Intent is mapped to a local
          transport layer intent Intent available in each domain.</t>
          <t>In this manner, it is recommended to keep color namespace
          management at the service layer and the transport layer decoupled
          from each other. In the following sections sections, the service layer agrees
          on a single global namespace.</t>
        </section>
        <section anchor="non-agreeing"
                 title="Non-Agreeing numbered="true" toc="default">
          <name>Non-Agreeing Color Transport Domains">
          <t>Non-agreeing color domains Domains</name>
          <t>Non-Agreeing Color Domains require a mapping community Mapping Community rewrite on
          each domain boundary. This rewrite helps to map one domain's color
          namespace to another domain's color namespace.</t>
          <t>The following example illustrates how traffic is stitched and SLA
          is preserved when domains don't use the same namespace at the
          transport layer. Each domain specifies the same SLA using different
          color values.</t>

        <figure title="Transport Layer with Non-agreeing Color Domains" anchor="BGPCT_NON_AGREEING_COLOR_DOMAIN"><artset><artwork  type="svg"><svg
          anchor="BGPCT_NON_AGREEING_COLOR_DOMAIN">
          <artset>
            <artwork type="svg">
              <svg xmlns="http://www.w3.org/2000/svg" version="1.1" height="240" width="552" height="224" width="544"
                viewBox="0 0 552 240" 544 224" class="diagram" text-anchor="middle" font-family="monospace"
                font-size="13px" stroke-linecap="round">
                <path d="M 72,96 72,80 L 96,96" 96,80" fill="none" stroke="black"/> stroke="black" />
                <path d="M 168,96 168,80 L 184,96" 184,80" fill="none" stroke="black"/> stroke="black" />
                <path d="M 248,96 248,80 L 288,96" 288,80" fill="none" stroke="black"/> stroke="black" />
                <path d="M 360,96 360,80 L 376,96" 376,80" fill="none" stroke="black"/> stroke="black" />
                <path d="M 440,96 440,80 L 488,96" 480,80" fill="none" stroke="black"/> stroke="black" />
                <path d="M 96,208 96,192 L 176,208" 176,192" fill="none" stroke="black"/> stroke="black" />
                <path d="M 336,208 336,192 L 400,208" 400,192" fill="none" stroke="black"/> stroke="black" />
                <polygon class="arrowhead" points="408,208 396,202.4 396,213.6" points="408,192 396,186.4 396,197.6" fill="black" transform="rotate(0,400,208)"/>
                  transform="rotate(0,400,192)" />
                <g class="text">
                  <text x="88" y="52">.....................</text> y="36">.....................</text>
                  <text x="272" y="52">.......................</text> y="36">.......................</text>
                  <text x="460" y="52">......................</text> x="456" y="36">.....................</text>
                  <text x="8" y="68">:</text> y="52">:</text>
                  <text x="96" y="68">Gold(100)</text> y="52">Gold(100)</text>
                  <text x="168" y="68">:</text> y="52">:</text>
                  <text x="184" y="68">:</text> y="52">:</text>
                  <text x="280" y="68">Gold(300)</text> y="52">Gold(300)</text>
                  <text x="360" y="68">:</text> y="52">:</text>
                  <text x="376" y="68">:</text> y="52">:</text>
                  <text x="472" y="68">Gold(500)</text> y="52">Gold(500)</text>
                  <text x="544" y="68">:</text> x="536" y="52">:</text>
                  <text x="8" y="84">:</text> y="68">:</text>
                  <text x="168" y="84">:</text> y="68">:</text>
                  <text x="184" y="84">:</text> y="68">:</text>
                  <text x="360" y="84">:</text> y="68">:</text>
                  <text x="376" y="84">:</text> y="68">:</text>
                  <text x="544" y="84">:</text> x="536" y="68">:</text>
                  <text x="8" y="100">:</text> y="84">:</text>
                  <text x="44" y="100">[PE11]</text> y="84">[PE11]</text>
                  <text x="132" y="100">[ASBR11]</text> y="84">[ASBR11]</text>
                  <text x="216" y="100">[ASBR21</text> y="84">[ASBR21</text>
                  <text x="324" y="100">[ASBR22]</text> y="84">[ASBR22]</text>
                  <text x="408" y="100">[ASBR31</text> y="84">[ASBR31</text>
                  <text x="520" y="100">[PE31]:</text> x="512" y="84">[PE31]:</text>
                  <text x="8" y="116">:</text> y="100">:</text>
                  <text x="168" y="116">:</text> y="100">:</text>
                  <text x="184" y="116">:</text> y="100">:</text>
                  <text x="360" y="116">:</text> y="100">:</text>
                  <text x="376" y="116">:</text> y="100">:</text>
                  <text x="544" y="116">:</text> x="536" y="100">:</text>
                  <text x="8" y="132">:</text> y="116">:</text>
                  <text x="88" y="132">AS1</text> y="116">AS1</text>
                  <text x="168" y="132">:</text> y="116">:</text>
                  <text x="184" y="132">:</text> y="116">:</text>
                  <text x="280" y="132">AS2</text> y="116">AS2</text>
                  <text x="360" y="132">:</text> y="116">:</text>
                  <text x="376" y="132">:</text> y="116">:</text>
                  <text x="464" y="132">AS3</text> y="116">AS3</text>
                  <text x="544" y="132">:</text> x="536" y="116">:</text>
                  <text x="8" y="148">:</text> y="132">:</text>
                  <text x="168" y="148">:</text> y="132">:</text>
                  <text x="184" y="148">:</text> y="132">:</text>
                  <text x="360" y="148">:</text> y="132">:</text>
                  <text x="376" y="148">:</text> y="132">:</text>
                  <text x="544" y="148">:</text> x="536" y="132">:</text>
                  <text x="8" y="164">:</text> y="148">:</text>
                  <text x="104" y="164">Bronze(200)</text> y="148">Bronze(200)</text>
                  <text x="168" y="164">:</text> y="148">:</text>
                  <text x="184" y="164">:</text> y="148">:</text>
                  <text x="272" y="164">Bronze(400)</text> y="148">Bronze(400)</text>
                  <text x="360" y="164">:</text> y="148">:</text>
                  <text x="376" y="164">:</text> y="148">:</text>
                  <text x="464" y="164">Bronze(600)</text> y="148">Bronze(600)</text>
                  <text x="544" y="164">:</text> x="536" y="148">:</text>
                  <text x="88" y="180">.....................</text> y="164">.....................</text>
                  <text x="272" y="180">.......................</text> y="164">.......................</text>
                  <text x="460" y="180">......................</text> x="456" y="164">.....................</text>
                  <text x="216" y="212">Traffic</text> y="196">Traffic</text>
                  <text x="288" y="212">Direction</text> y="196">Direction</text>
                </g>
              </svg>
</artwork><artwork
            </artwork>
            <artwork type="ascii-art"><![CDATA[
  ..................... ....................... ...................... .....................
  :      Gold(100)    : :       Gold(300)     : :       Gold(500)   :
  :                   : :                     : :                   :
  : [PE11]----[ASBR11]---[ASBR21------[ASBR22]---[ASBR31-------[PE31]: [PE11]----[ASBR11]---[ASBR21------[ASBR22]---[ASBR31------[PE31]:
  :                   : :                     : :                   :
  :        AS1        : :          AS2        : :         AS3       :
  :                   : :                     : :                   :
  :      Bronze(200)  : :     Bronze(400)     : :     Bronze(600)   :
  ..................... ....................... ...................... .....................

             ----------- Traffic Direction -------->
]]></artwork></artset></figure>
]]></artwork>
          </artset>
        </figure>

         <t>In the topology shown in <xref
          target="BGPCT_NON_AGREEING_COLOR_DOMAIN"/>, target="BGPCT_NON_AGREEING_COLOR_DOMAIN" format="default"/>, we have three Autonomous
          Systems. All the nodes in the topology support BGP CT.</t>

          <t>In AS1

	  <ul spacing="normal">
          <li>In AS1, the Gold SLA is represented by color 100 and Bronze by
          200.</t>

          <t>In AS2
          200.</li>
          <li>In AS2, the Gold SLA is represented by color 300 and Bronze by
          400.</t>

          <t>In AS3
          400.</li>
          <li>In AS3, the Gold SLA is represented by color 500 and Bronze by
          600.</t>
          600.</li>
	  </ul>
          <t>Though the color values are different, they map to tunnels with
          sufficiently similar TE characteristics in each domain.</t>
          <t>The service route carries an abstract mapping community Mapping Community that maps
          to the required SLA. For example, Service service routes that need to
          resolve over Gold transport tunnels, tunnels carry a mapping community Mapping Community
          color:0:100500. In AS3 AS3, it maps to a resolution scheme Resolution Scheme containing
          TRDB with color 500 whereas 500; in AS2 AS2, it maps to a TRDB with color 300 300;
          and in AS1 AS1, it maps to a TRDB with color 100. Coordination is needed
          to provision the resolution schemes Resolution Schemes in each domain domain, as explained
          previously.</t>
          <t>At the AS boundary, the transport-class route-target Transport Class RT is rewritten
          for the BGP CT routes. In the previous topology, at ASBR31, the
          transport-target:0:500 for Gold tunnels is rewritten to
          transport-target:0:300 and then advertised to ASBR22. Similarly, the
          transport-target:0:300 for Gold tunnels are re-written rewritten to
          transport-target:0:100 at ASBR21 before advertising to ASBR11. At
          PE11, the transport route received with transport-target:0:100 will
          be added to the color 100 TRDB. The service route received with
          mapping community
          Mapping Community color:0:100500 at PE1 maps to the Gold TRDB and
          resolves over this transport route.</t>
          <t>Inter-domain traffic forwarding in the previous topology works as
          explained in <xref target="CTProc"/>.</t>

          <t>Transport-target re-write target="CTProc" format="default"/>.</t>
          <t>Transport Class RT rewrite requires co-ordination coordination of color values
          between domains in the transport layer. This method avoids the need
          to re-write rewrite service route mapping communities, keeping the service
          layer homogenous and simple to manage. Coordinating Transport Class
          RT between two adjacent color domains at a time is easier than
          coordinating service layer colors deployed in a global mesh of
          non-adjacent color domains. This basically allows localizing the
          problem to a pair of adjacent color domains and solving it.</t>
        </section>
        <section title="Heterogeneous numbered="true" toc="default">
          <name>Heterogeneous Agreeing Color Transport Domains"> Domains</name>
          <t>In a heterogeneous domains heterogeneous-domain scenario, it might not be possible to
          map a service layer intent Intent to the matching transport color, as the
          color might not be locally available in a domain.</t>
          <t>The following example illustrates how traffic is stitched, stitched when a
          transit AS contains more shades for an SLA path compared to Ingress ingress
          and Egress egress domains. This example shows how service routes can
          traverse through finer shades when available and take coarse shades
          otherwise.</t>

        <figure title="Transport Layer with Heterogenous Color Domains" anchor="BGPCT_HETERO_COLOR_DOMAIN"><artset><artwork  type="svg"><svg
          anchor="BGPCT_HETERO_COLOR_DOMAIN">
          <artset>
            <artwork type="svg">
              <svg xmlns="http://www.w3.org/2000/svg" version="1.1" height="256" width="552" height="240" width="544"
                viewBox="0 0 552 256" 544 240" class="diagram" text-anchor="middle" font-family="monospace"
                font-size="13px" stroke-linecap="round">
                <path d="M 72,112 72,96 L 96,112" 96,96" fill="none" stroke="black"/> stroke="black" />
                <path d="M 168,112 168,96 L 184,112" 184,96" fill="none" stroke="black"/> stroke="black" />
                <path d="M 248,112 248,96 L 288,112" 288,96" fill="none" stroke="black"/> stroke="black" />
                <path d="M 360,112 360,96 L 376,112" 376,96" fill="none" stroke="black"/> stroke="black" />
                <path d="M 440,112 440,96 L 488,112" 480,96" fill="none" stroke="black"/> stroke="black" />
                <path d="M 120,224 120,208 L 200,224" 200,208" fill="none" stroke="black"/> stroke="black" />
                <path d="M 360,224 360,208 L 424,224" 424,208" fill="none" stroke="black"/> stroke="black" />
                <polygon class="arrowhead" points="432,224 420,218.4 420,229.6" points="432,208 420,202.4 420,213.6" fill="black" transform="rotate(0,424,224)"/>
                  transform="rotate(0,424,208)" />
                <g class="text">
                  <text x="88" y="52">.....................</text> y="36">.....................</text>
                  <text x="272" y="52">.......................</text> y="36">.......................</text>
                  <text x="460" y="52">......................</text> x="456" y="36">.....................</text>
                  <text x="8" y="68">:</text> y="52">:</text>
                  <text x="168" y="68">:</text> y="52">:</text>
                  <text x="184" y="68">:</text> y="52">:</text>
                  <text x="276" y="68">Gold1(101)</text> y="52">Gold1(101)</text>
                  <text x="360" y="68">:</text> y="52">:</text>
                  <text x="376" y="68">:</text> y="52">:</text>
                  <text x="544" y="68">:</text> x="536" y="52">:</text>
                  <text x="8" y="84">:</text> y="68">:</text>
                  <text x="96" y="84">Gold(100)</text> y="68">Gold(100)</text>
                  <text x="168" y="84">:</text> y="68">:</text>
                  <text x="184" y="84">:</text> y="68">:</text>
                  <text x="276" y="84">Gold2(102)</text> y="68">Gold2(102)</text>
                  <text x="360" y="84">:</text> y="68">:</text>
                  <text x="376" y="84">:</text> y="68">:</text>
                  <text x="464" y="84">Gold(100)</text> y="68">Gold(100)</text>
                  <text x="544" y="84">:</text> x="536" y="68">:</text>
                  <text x="8" y="100">:</text> y="84">:</text>
                  <text x="168" y="100">:</text> y="84">:</text>
                  <text x="184" y="100">:</text> y="84">:</text>
                  <text x="360" y="100">:</text> y="84">:</text>
                  <text x="376" y="100">:</text> y="84">:</text>
                  <text x="544" y="100">:</text> x="536" y="84">:</text>
                  <text x="8" y="116">:</text> y="100">:</text>
                  <text x="44" y="116">[PE11]</text> y="100">[PE11]</text>
                  <text x="132" y="116">[ASBR11]</text> y="100">[ASBR11]</text>
                  <text x="216" y="116">[ASBR21</text> y="100">[ASBR21</text>
                  <text x="324" y="116">[ASBR22]</text> y="100">[ASBR22]</text>
                  <text x="408" y="116">[ASBR31</text> y="100">[ASBR31</text>
                  <text x="520" y="116">[PE31]:</text> x="512" y="100">[PE31]:</text>
                  <text x="8" y="132">:</text> y="116">:</text>
                  <text x="168" y="132">:</text> y="116">:</text>
                  <text x="184" y="132">:</text> y="116">:</text>
                  <text x="360" y="132">:</text> y="116">:</text>
                  <text x="376" y="132">:</text> y="116">:</text>
                  <text x="544" y="132">:</text> x="536" y="116">:</text>
                  <text x="8" y="148">:</text> y="132">:</text>
                  <text x="56" y="148">Metro</text> y="132">Metro</text>
                  <text x="112" y="148">Ingress</text> y="132">Ingress</text>
                  <text x="168" y="148">:</text> y="132">:</text>
                  <text x="184" y="148">:</text> y="132">:</text>
                  <text x="268" y="148">Core</text> y="132">Core</text>
                  <text x="360" y="148">:</text> y="132">:</text>
                  <text x="376" y="148">:</text> y="132">:</text>
                  <text x="432" y="148">Metro</text> y="132">Metro</text>
                  <text x="484" y="148">Egress</text> y="132">Egress</text>
                  <text x="544" y="148">:</text> x="536" y="132">:</text>
                  <text x="8" y="164">:</text> y="148">:</text>
                  <text x="168" y="164">:</text> y="148">:</text>
                  <text x="184" y="164">:</text> y="148">:</text>
                  <text x="360" y="164">:</text> y="148">:</text>
                  <text x="376" y="164">:</text> y="148">:</text>
                  <text x="544" y="164">:</text> x="536" y="148">:</text>
                  <text x="8" y="180">:</text> y="164">:</text>
                  <text x="88" y="180">AS1</text> y="164">AS1</text>
                  <text x="168" y="180">:</text> y="164">:</text>
                  <text x="184" y="180">:</text> y="164">:</text>
                  <text x="280" y="180">AS2</text> y="164">AS2</text>
                  <text x="360" y="180">:</text> y="164">:</text>
                  <text x="376" y="180">:</text> y="164">:</text>
                  <text x="464" y="180">AS3</text> y="164">AS3</text>
                  <text x="544" y="180">:</text> x="536" y="164">:</text>
                  <text x="88" y="196">.....................</text> y="180">.....................</text>
                  <text x="272" y="196">.......................</text> y="180">.......................</text>
                  <text x="460" y="196">......................</text> x="456" y="180">.....................</text>
                  <text x="240" y="228">Traffic</text> y="212">Traffic</text>
                  <text x="312" y="228">Direction</text> y="212">Direction</text>
                </g>
              </svg>
</artwork><artwork
            </artwork>
            <artwork type="ascii-art"><![CDATA[
  ..................... ....................... ...................... .....................
  :                   : :      Gold1(101)     : :                   :
  :      Gold(100)    : :      Gold2(102)     : :      Gold(100)    :
  :                   : :                     : :                   :
  : [PE11]----[ASBR11]---[ASBR21------[ASBR22]---[ASBR31-------[PE31]: [PE11]----[ASBR11]---[ASBR21------[ASBR22]---[ASBR31------[PE31]:
  :                   : :                     : :                   :
  :   Metro Ingress   : :        Core         : :    Metro Egress   :
  :                   : :                     : :                   :
  :        AS1        : :          AS2        : :         AS3       :
  ..................... ....................... ...................... .....................

                ----------- Traffic Direction -------->
]]></artwork></artset></figure>
]]></artwork>
          </artset>
        </figure>

          <t>In the preceding topology shown in <xref
          target="BGPCT_HETERO_COLOR_DOMAIN"/>, target="BGPCT_HETERO_COLOR_DOMAIN" format="default"/>, we have three Autonomous
          Systems. All the nodes in the topology support BGP CT.</t>

          <t>In AS1
	  <ul spacing="normal">
          <li>In AS1, the Gold SLA is represented by color 100.</t>

          <t>In AS2 100.</li>
          <li>In AS2, Gold has finer shades: Gold1 by color 101 and Gold2 by
          color 102.</t>

          <t>In AS3 102.</li>
          <li>In AS3, the Gold SLA is represented by color 100.</t> 100.</li>
	  </ul>
          <t>This problem can be solved by the two following approaches:</t> approaches described in Sections <xref target="dup_tun_ap" format="counter"/> and <xref target="cust_res_scheme" format="counter"/>.</t>
          <section title="Duplicate numbered="true" toc="default" anchor="dup_tun_ap">
            <name>Duplicate Tunnels Approach"> Approach</name>
            <t>In this approach, duplicate tunnels that satisfy the Gold SLA are
            configured in domains AS1 and AS3, but they are given fine grained fine-grained
            colors 101 and 102.</t>
            <t>These tunnels will be installed in TRDBs corresponding to
            transport classes of color colors 101 and 102.</t>
            <t>Overlay routes received with mapping community (e.g.: a Mapping Community (e.g.,
            transport-target or color community) can resolve over these
            tunnels in the TRDB with matching color colors by using resolution
            schemes.</t> Resolution
            Schemes.</t>
            <t>This approach consumes more resources in the transport and
            forwarding layer, layer because of the duplicate tunnels.</t>
          </section>
          <section title="Customized numbered="true" toc="default" anchor="cust_res_scheme">
            <name>Customized Resolution Schemes Approach"> Approach</name>
            <t>In this approach, resolution schemes Resolution Schemes in domains AS1 and AS3 are
            customized to map the received mapping community Mapping Community (e.g.,
            transport-target or color community) over available Gold SLA
            tunnels. This conserves resource usage with no additional state in
            the transport or forwarding planes.</t>
            <t>Service routes advertised by PE31 that need to resolve over
            Gold1 transport tunnels carry a mapping community Mapping Community color:0:101. In
            AS3 and AS1, where Gold1 is not available, it is mapped to color
            100 TRDB using a customized resolution scheme. Resolution Scheme. In AS2, Gold1 is
            available
            available, and it maps to color 101 TRDB.</t>
            <t>Similarly, service routes advertised by PE31 that need to
            resolve over Gold2 transport tunnels carry a mapping community Mapping Community
            color:0:102. In AS3 and AS1, where Gold2 is not available, it is
            mapped to color 100 TRDB using a customized resolution scheme. Resolution Scheme. In
            AS2, Gold2 is available available, and it maps to color 102 TRDB.</t>
            <t>To facilitate this, SN/BN SNs/BNs in all three AS ASes provision the
            transport classes 100, 101 101, and 102. SN  SNs and BN BNs in AS1 and AS3 are
            provisioned with customized resolution schemes Resolution Schemes that resolve routes
            with transport-target:0:101 or transport-target:0:102 using color
            100 TRDB.</t>
            <t>PE31 is provisioned to originate BGP CT route routes with color 101
            for endpoint PE31. This route is sent with an NLRI RD prefix RD1:PE31
            and route target Route Target extended community transport-target:0:101.</t>
            <t>Similarly, PE31 is provisioned to originate BGP CT route routes with
            color 102 for endpoint PE31. This route is sent with an NLRI RD
            prefix RD2:PE31 and route target Route Target extended community
            transport-target:0:102.</t>

            <t>Following
            <t>The following description explains the remaining procedures with
            color 101 as an example.</t>
            <t>At ASBR31, the route target "transport-target:0:101" Route Target role of transport-target:0:101 on this
            BGP CT route instructs gives instruction to add the route to color 101 TRDB. ASBR31
            is provisioned with a customized resolution scheme Resolution Scheme that resolves the
            routes carrying mapping community Mapping Community transport-target:0:101 to
            resolve using color 100 TRDB. This route is then re-advertised readvertised
            from color 101 TRDB to ASBR22 with route-target:0:101.</t>
            <t>At ASBR22, the BGP CT routes received with
            transport-target:0:101 will be added to color 101 TRDB and
            strictly resolve over tunnel routes in the same TRDB. This route
            is re-advertised readvertised to ASBR21 with transport-target:0:101.</t>
            <t>Similarly, at ASBR21, the BGP CT routes received with
            transport-target:0:101 will be added to color 101 TRDB and
            strictly resolve over tunnel routes in the same TRDB. This route
            is re-advertised readvertised to ASBR11 with transport-target:0:101.</t>
            <t>At ASBR11, the route target "transport-target:0:101" Route Target role of transport-target:0:101 on this
            BGP CT route instructs gives instruction to add the route to color 101 TRDB. ASBR11
            is provisioned with a customized resolution scheme Resolution Scheme that resolves
            the routes carrying transport-target:0:101 to use color 100 TRDB.
            This route is then re-advertised readvertised from color 101 TRDB to PE11 with
            transport-target:0:101.</t>
            <t>At PE11, the route target "transport-target:0:101" Route Target role of transport-target:0:101 on this BGP
            CT route instructs gives instruction to add the route to color 101 TRDB. PE11 is
            provisioned with a customized resolution scheme Resolution Scheme that resolves the
            routes carrying transport-target:0:101 to use color 100 TRDB.</t>
            <t>When PE11 receives the service route with the mapping community
            color:0:101 Mapping Community
            color:0:101, it directly resolves over the BGP CT route in color
            101 TRDB, which which, in turn turn, resolves over tunnel routes in color 100
            TRDB.</t>
            <t>Similar processing is done for color 102 routes also at ASBR31,
            ASBR22, ASBR21, ASBR11 ASBR11, and PE11.</t>
            <t>In doing so, PE11 can forward traffic via tunnels with color
            101, color 102 in the core domain, domain and color 100 in the metro
            domains.</t>
          </section>
        </section>
      </section>
      <section title="Migration Scenarios."> numbered="true" toc="default">
        <name>Migration Scenarios</name>
        <section title="BGP numbered="true" toc="default">
          <name>BGP CT Islands Connected via BGP LU Domain"> Domain</name>
          <t>This section explains how an end-to-end SLA can be achieved while
          transiting a domain that does not support BGP CT. BGP LU is used in
          such domains to connect the BGP CT islands.</t>
          <figure title="BGP anchor="BGPCTIsles">
            <name>BGP CT in AS1 and AS3 connected Connected by BGP LU in AS2" anchor="BGPCTIsles"><artset><artwork  type="svg"><svg AS2</name>
            <artset>
              <artwork type="svg" name="" align="left" alt=""><svg xmlns="http://www.w3.org/2000/svg" version="1.1" height="176" width="520" viewBox="0 0 520 176" class="diagram" text-anchor="middle" font-family="monospace" font-size="13px" stroke-linecap="round">
                  <path d="M 104,32 L 104,64" fill="none" stroke="black"/>
                  <path d="M 424,32 L 424,64" fill="none" stroke="black"/>
                  <path d="M 104,32 L 184,32" fill="none" stroke="black"/>
                  <path d="M 320,32 L 424,32" fill="none" stroke="black"/>
                  <path d="M 48,80 L 80,80" fill="none" stroke="black"/>
                  <path d="M 144,80 L 200,80" fill="none" stroke="black"/>
                  <path d="M 264,80 L 280,80" fill="none" stroke="black"/>
                  <path d="M 344,80 L 392,80" fill="none" stroke="black"/>
                  <path d="M 456,80 L 472,80" fill="none" stroke="black"/>
                  <path d="M 128,112 L 144,112" fill="none" stroke="black"/>
                  <path d="M 208,112 L 224,112" fill="none" stroke="black"/>
                  <path d="M 328,112 L 344,112" fill="none" stroke="black"/>
                  <path d="M 408,112 L 424,112" fill="none" stroke="black"/>
                  <path d="M 24,128 L 40,128" fill="none" stroke="black"/>
                  <path d="M 104,128 L 120,128" fill="none" stroke="black"/>
                  <path d="M 224,128 L 240,128" fill="none" stroke="black"/>
                  <path d="M 304,128 L 320,128" fill="none" stroke="black"/>
                  <path d="M 400,128 L 416,128" fill="none" stroke="black"/>
                  <path d="M 480,128 L 496,128" fill="none" stroke="black"/>
                  <path d="M 120,160 L 184,160" fill="none" stroke="black"/>
                  <path d="M 328,160 L 400,160" fill="none" stroke="black"/>
                  <polygon class="arrowhead" points="504,128 492,122.4 492,133.6" fill="black" transform="rotate(0,496,128)"/>
                  <polygon class="arrowhead" points="432,112 420,106.4 420,117.6" fill="black" transform="rotate(0,424,112)"/>
                  <polygon class="arrowhead" points="408,160 396,154.4 396,165.6" fill="black" transform="rotate(0,400,160)"/>
                  <polygon class="arrowhead" points="408,128 396,122.4 396,133.6" fill="black" transform="rotate(180,400,128)"/>
                  <polygon class="arrowhead" points="336,112 324,106.4 324,117.6" fill="black" transform="rotate(180,328,112)"/>
                  <polygon class="arrowhead" points="328,128 316,122.4 316,133.6" fill="black" transform="rotate(0,320,128)"/>
                  <polygon class="arrowhead" points="232,128 220,122.4 220,133.6" fill="black" transform="rotate(180,224,128)"/>
                  <polygon class="arrowhead" points="232,112 220,106.4 220,117.6" fill="black" transform="rotate(0,224,112)"/>
                  <polygon class="arrowhead" points="136,112 124,106.4 124,117.6" fill="black" transform="rotate(180,128,112)"/>
                  <polygon class="arrowhead" points="128,128 116,122.4 116,133.6" fill="black" transform="rotate(0,120,128)"/>
                  <polygon class="arrowhead" points="32,128 20,122.4 20,133.6" fill="black" transform="rotate(180,24,128)"/>
                  <g class="text">
                    <text x="204" y="36">EBGP</text>
                    <text x="260" y="36">Multihop</text>
                    <text x="308" y="36">CT</text>
                    <text x="64" y="68">AS3</text>
                    <text x="272" y="68">AS2</text>
                    <text x="464" y="68">AS1</text>
                    <text x="24" y="84">[PE31</text>
                    <text x="112" y="84">ASBR31]</text>
                    <text x="232" y="84">[ASBR22</text>
                    <text x="312" y="84">ASBR21]</text>
                    <text x="424" y="84">[ASBR11</text>
                    <text x="496" y="84">PE11]</text>
                    <text x="164" y="116">EBGP</text>
                    <text x="196" y="116">LU</text>
                    <text x="364" y="116">EBGP</text>
                    <text x="396" y="116">LU</text>
                    <text x="60" y="132">IBGP</text>
                    <text x="92" y="132">CT</text>
                    <text x="260" y="132">IBGP</text>
                    <text x="292" y="132">LU</text>
                    <text x="436" y="132">IBGP</text>
                    <text x="468" y="132">CT</text>
                    <text x="216" y="164">Traffic</text>
                    <text x="288" y="164">Direction</text>
                  </g>
                </svg>
</artwork><artwork  type="ascii-art"><![CDATA[
              </artwork>
              <artwork type="ascii-art" name="" align="left" alt=""><![CDATA[
            +----------EBGP Multihop CT-------------+
            |                                       |
      AS3   |                   AS2                 |   AS1
[PE31-----ASBR31]--------[ASBR22---ASBR21]-------[ASBR11---PE11]

               <--EBGP LU-->            <--EBGP LU-->
  <--IBGP CT-->            <--IBGP LU-->         <--IBGP CT-->

              ---------Traffic Direction--------->
]]></artwork></artset></figure>
]]></artwork>
            </artset>
          </figure>
          <t>In the preceding topology shown in <xref target="BGPCTIsles"/>, target="BGPCTIsles" format="default"/>,
          there are three AS domains. domains: AS1 and AS3 support BGP CT, while AS2
          does not support BGP CT.</t>
          <t>Nodes in AS1, AS2, and AS3 negotiate BGP LU family on IBGP
          sessions within the domain. Nodes in AS1 and AS3 negotiate BGP CT
          family on IBGP sessions within the domain. ASBR11 and ASBR21 as well
          as ASBR22 and ASBR31 negotiate BGP LU family on the EBGP session
          over directly connected inter-domain links. ASBR11 and ASBR31 have
          reachability to each other&rsquo;s other's loopbacks through BGP LU. ASBR11
          and ASBR31 negotiate BGP CT family over a multihop EBGP session
          formed using BGP LU reachability.</t>
          <t>The following tunnels exist for the Gold Transport Class<list> Class</t>
          <ul spacing="normal">
            <li>
              <t>PE11_to_ASBR11_gold - RSVP-TE tunnel</t>
            </li>
            <li>
              <t>ASBR11_to_PE11_gold - RSVP-TE tunnel</t>
            </li>
            <li>
              <t>PE31_to_ASBR31_gold - SRTE tunnel</t>
            </li>
            <li>
              <t>ASBR31_to_PE31_gold - SRTE tunnel</t>
            </list></t>
            </li>
          </ul>
          <t>The following tunnels exist for the Bronze Transport Class<list> Class</t>
          <ul spacing="normal">
            <li>
              <t>PE11_to_ASBR11_bronze - RSVP-TE tunnel</t>
            </li>
            <li>
              <t>ASBR11_to_PE11_bronze - RSVP-TE tunnel</t>
            </li>
            <li>
              <t>PE31_to_ASBR31_bronze - SRTE tunnel</t>
            </li>
            <li>
              <t>ASBR31_to_PE31_bronze - SRTE tunnel</t>
            </list></t>
            </li>
          </ul>
          <t>These tunnels are provisioned to belong to Transport Classes Gold
          and Bronze, and they are advertised between ASBR31 and ASBR11 with Next the next
          hop self.</t> set to themselves.</t>
          <t>In AS2, that which does not support BGP CT, a separate loopback may be
          used on ASBR22 and ASBR21 to represent Gold and Bronze SLAs, viz. namely
          ASBR22_lpbk_gold, ASBR22_lpbk_bronze, ASBR21_lpbk_gold ASBR21_lpbk_gold, and
          ASBR21_lpbk_bronze.</t>
          <t>Furthermore, the following tunnels exist in AS2 to satisfy the
          different SLAs, SLAs using per SLA loopback endpoints:<list> per-SLA-loopback endpoints:</t>
          <ul spacing="normal">
            <li>
              <t>ASBR21_to_ASBR22_lpbk_gold - RSVP-TE tunnel</t>
            </li>
            <li>
              <t>ASBR22_to_ASBR21_lpbk_gold - RSVP-TE tunnel</t>
            </li>
            <li>
              <t>ASBR21_to_ASBR22_lpbk_bronze - RSVP-TE tunnel</t>
            </li>
            <li>
              <t>ASBR22_to_ASBR21_lpbk_bronze - RSVP-TE tunnel</t>
            </list></t>

          <t>RD:PE11
            </li>
          </ul>
          <t>The RD:PE11 BGP CT route is originated from PE11 towards ASBR11 with
          transport-target 'gold.' ASBR11 readvertises this route with the next
          hop set to ASBR11_lpbk_gold on the EBGP multihop session towards
          ASBR31. ASBR11 originates a BGP LU route for endpoint ASBR11_lpbk_gold
          on an EBGP session to ASBR21 with a 'gold SLA' community, community and a BGP LU
          route for ASBR11_lpbk_bronze with a 'bronze SLA' community. The SLA
          community is used by ASBR31 to publish the BGP LU routes in the
          corresponding BGP CT TRDBs.</t>

          <t>ASBR21 readvertises the BGP LU route for endpoint
          ASBR11_lpbk_gold to ASBR22 with the next hop set by local policy config
          to the unique loopback ASBR21_lpbk_gold by matching the 'gold SLA'
          community received as part of BGP LU advertisement from ASBR11.
          ASBR22 receives this route and resolves the next hop over the
          ASBR22_to_ASBR21_lpbk_gold RSVP-TE tunnel. On successful resolution,
          ASBR22 readvertises this BGP LU route to ASBR31 with the next hop self set to itself
          and a new label.</t>

          <t>ASBR31 adds the ASBR11_lpbk_gold route received via EBGP LU from
          ASBR22 to a 'gold' TRDB based on the received 'gold SLA' community.
          ASBR31 uses this 'gold' TRDB route to resolve the next hop
          ASBR11_lpbk_gold received on the BGP CT route with transport-target
          'gold,' for the prefix RD:PE11 received over the EBGP multihop CT
          session, thus preserving the end-to-end SLA. Now ASBR31 readvertises
          the BGP CT route for RD:PE11 with the next hop as self set to itself, thus stitching
          with the BGP LU LSP in AS2. Intra-domain traffic forwarding in AS1
          and AS3 follows the procedures as explained in <xref
          target="CTProc">Illustration of CT Procedures</xref></t> target="CTProc" format="default"></xref>.</t>
          <t>In cases where an SLA cannot be preserved in AS2 because SLA
          specific SLA-specific
          tunnels and loopbacks don't exist in AS2, traffic can be
          carried over available SLAs (e.g.: best effort (e.g., best-effort SLA) by rewriting the
          next hop to an ASBR21 loopback assigned to the available SLA. This
          eases migration in case of a heterogeneous color domains as-well.</t> domain as well.</t>
        </section>
        <section title="BGP CT - numbered="true" toc="default">
          <name>BGP CT: Interoperability between Between MPLS and Other Forwarding Technologies "> Technologies</name>
          <t>This section describes how nodes supporting dissimilar
          encapsulation technologies can interoperate with each other when
          using the BGP CT family.</t>
          <section title="Interop numbered="true" toc="default">
            <name>Interoperation Between MPLS and SRv6 Nodes."> Nodes</name>
            <t>BGP speakers may carry MPLS label labels and SRv6 SID SIDs in BGP CT SAFI
            76 for AFIs AFI 1 or 2 routes using protocol encoding as described in
            <xref target="CTMultiEncap">Carrying Multiple Encapsulation
            information</xref></t> target="CTMultiEncap" format="default"></xref>.</t>
            <t>MPLS Labels labels are carried using RFC 8277 encoding, the encoding described in <xref target="RFC8277"/>, and SRv6 SID
            is SIDs
            are carried using Prefix SID the Prefix-SID attribute as specified in <xref
            target="SRv6-Support"/>.</t> target="SRv6-Support" format="default"/>.</t>
            <figure title="BGP anchor="BGPCT_MPLS_SRV6">
              <name>BGP CT Interop between Interoperation Between MPLS and SRv6 nodes" anchor="BGPCT_MPLS_SRV6"><artset><artwork  type="svg"><svg Nodes</name>
              <artset>
                <artwork type="svg" name="" align="left" alt=""><svg xmlns="http://www.w3.org/2000/svg" version="1.1" height="176" width="336" viewBox="0 0 336 176" class="diagram" text-anchor="middle" font-family="monospace" font-size="13px" stroke-linecap="round">
                    <path d="M 136,48 L 136,64" fill="none" stroke="black"/>
                    <path d="M 136,96 L 136,112" fill="none" stroke="black"/>
                    <path d="M 80,32 L 104,32" fill="none" stroke="black"/>
                    <path d="M 136,48 L 192,48" fill="none" stroke="black"/>
                    <path d="M 72,80 L 128,80" fill="none" stroke="black"/>
                    <path d="M 144,80 L 192,80" fill="none" stroke="black"/>
                    <path d="M 136,112 L 192,112" fill="none" stroke="black"/>
                    <path d="M 24,144 L 56,144" fill="none" stroke="black"/>
                    <path d="M 248,144 L 288,144" fill="none" stroke="black"/>
                    <path d="M 104,32 L 124,72" fill="none" stroke="black"/>
                    <polygon class="arrowhead" points="296,144 284,138.4 284,149.6" fill="black" transform="rotate(0,288,144)"/>
                    <polygon class="arrowhead" points="32,144 20,138.4 20,149.6" fill="black" transform="rotate(180,24,144)"/>
                    <g class="text">
                      <text x="64" y="36">RR1</text>
                      <text x="204" y="52">R2</text>
                      <text x="248" y="52">[MPLS</text>
                      <text x="280" y="52">+</text>
                      <text x="312" y="52">SRv6]</text>
                      <text x="60" y="84">R1</text>
                      <text x="136" y="84">P</text>
                      <text x="204" y="84">R3</text>
                      <text x="248" y="84">[MPLS</text>
                      <text x="296" y="84">only]</text>
                      <text x="24" y="100">[MPLS</text>
                      <text x="56" y="100">+</text>
                      <text x="88" y="100">SRv6]</text>
                      <text x="204" y="116">R4</text>
                      <text x="248" y="116">[SRv6</text>
                      <text x="296" y="116">only]</text>
                      <text x="120" y="148">Bidirectional</text>
                      <text x="208" y="148">Traffic</text>
                    </g>
                  </svg>
</artwork><artwork  type="ascii-art"><![CDATA[
                </artwork>
                <artwork type="ascii-art" name="" align="left" alt=""><![CDATA[
          RR1---+
                 \  +-------R2  [MPLS + SRv6]
                  \ |
          R1--------P-------R3  [MPLS only]
    [MPLS + SRv6]   |
                    +-------R4  [SRv6 only]

      <---- Bidirectional Traffic ----->
]]></artwork></artset></figure>
]]></artwork>
              </artset>
            </figure>
            <t>This example shows a provider network with a mix of devices
            with
            that have different forwarding capabilities. R1 and R2 support
            forwarding both MPLS and SRv6 packets. R3 supports forwarding MPLS
            packets only. R4 supports forwarding SRv6 packets only. All these
            nodes have a BGP session with Route Reflector RR1 RR1, which reflects
            routes between these nodes with the next hop unchanged. The BGP CT family
            is negotiated on these sessions.</t>
            <t>R1 and R2 send and receive both MPLS label labels and SRv6 SID SIDs in the
            BGP CT control plane routes. This allows them to be ingress and
            egress for both MPLS and SRv6 data planes. The MPLS label is carried
            using RFC 8277 encoding, the encoding described in <xref target="RFC8277"/>, and an SRv6 SID is carried using Prefix SID the Prefix-SID
            attribute as specified in <xref target="SRv6-Support"/>, target="SRv6-Support" format="default"/> without the
            Transposition Scheme. In this way, either MPLS or SRv6 forwarding
            can be used between R1 and R2.</t>
            <t>R1 and R3 send and receive an MPLS label in the BGP CT control
            plane routes using RFC 8277 encoding. the encoding described in <xref target="RFC8277"/>. This allows them to be
            ingress and egress for MPLS data plane. R1 will carry an SRv6 SID in
            the Prefix-SID attribute, which will not be used by R3. In order to
            interoperate with MPLS only MPLS-only device R3, R1 MUST NOT <bcp14>MUST NOT</bcp14> use the SRv6
            Transposition scheme Scheme described in <xref target="RFC9252"/>. target="RFC9252" format="default"/>. The
            encoding suggested in <xref target="SRv6-Support"/> target="SRv6-Support" format="default"/> is used by R1.
            MPLS forwarding will be used between R1 and R3.</t>
            <t>R1 and R4 send and receive SRv6 SID SIDs in the BGP CT control plane
            routes using the BGP Prefix-SID attribute, without a Transposition
            Scheme. This allows them to be ingress and egress for the SRv6 data
            plane. R4 will carry the special MPLS Label label with a value of 3
            (Implicit-NULL)
            (Implicit NULL) in RFC 8277 encoding, the encoding described in <xref target="RFC8277"/>, which tells R1 not to push
            any MPLS label for this BGP CT route towards R4. The MPLS Label label
            advertised by R1 in RFC 8277 an NLRI as described in <xref target="RFC8277"/> will not be used by R4. SRv6
            forwarding will be used between R1 and R4.</t>
            <t>Note that, in this example that example, R3 and R4 cannot communicate directly
            with each other, other because they don't support a common forwarding
            technology. The BGP CT routes received at R3, R3 and R4 from each other
            will remain unusable, unusable due to incompatible forwarding
            technology.</t>
          </section>
          <section title="Interop numbered="true" toc="default">
            <name>Interop Between Nodes Supporting MPLS and UDP Tunneling"> Tunneling</name>
            <t>This section describes how nodes supporting MPLS forwarding can
            interoperate with other nodes supporting UDP (or IP) tunneling, tunneling
            when using BGP CT family.</t>
            <t>MPLS Labels labels are carried using RFC 8277 encoding, the encoding described in <xref target="RFC8277"/>, and UDP (or
            IP) tunneling information is carried using the TEA attribute or the
            Encapsulation Extended Community extended community as specified in <xref
            target="RFC9012"/>.</t> target="RFC9012" format="default"/>.</t>
            <figure title="BGP anchor="BGPCT_MPLS_UDP">
              <name>BGP CT Interop between Between MPLS and UDP tunneling nodes" anchor="BGPCT_MPLS_UDP"><artset><artwork  type="svg"><svg Tunneling Nodes</name>
              <artset>
                <artwork type="svg" name="" align="left" alt=""><svg xmlns="http://www.w3.org/2000/svg" version="1.1" height="176" width="328" viewBox="0 0 328 176" class="diagram" text-anchor="middle" font-family="monospace" font-size="13px" stroke-linecap="round">
                    <path d="M 136,48 L 136,64" fill="none" stroke="black"/>
                    <path d="M 136,96 L 136,112" fill="none" stroke="black"/>
                    <path d="M 80,32 L 104,32" fill="none" stroke="black"/>
                    <path d="M 136,48 L 192,48" fill="none" stroke="black"/>
                    <path d="M 72,80 L 128,80" fill="none" stroke="black"/>
                    <path d="M 144,80 L 192,80" fill="none" stroke="black"/>
                    <path d="M 136,112 L 192,112" fill="none" stroke="black"/>
                    <path d="M 24,144 L 56,144" fill="none" stroke="black"/>
                    <path d="M 248,144 L 288,144" fill="none" stroke="black"/>
                    <path d="M 104,32 L 124,72" fill="none" stroke="black"/>
                    <polygon class="arrowhead" points="296,144 284,138.4 284,149.6" fill="black" transform="rotate(0,288,144)"/>
                    <polygon class="arrowhead" points="32,144 20,138.4 20,149.6" fill="black" transform="rotate(180,24,144)"/>
                    <g class="text">
                      <text x="64" y="36">RR1</text>
                      <text x="204" y="52">R2</text>
                      <text x="248" y="52">[MPLS</text>
                      <text x="280" y="52">+</text>
                      <text x="308" y="52">UDP]</text>
                      <text x="60" y="84">R1</text>
                      <text x="136" y="84">P</text>
                      <text x="204" y="84">R3</text>
                      <text x="248" y="84">[MPLS</text>
                      <text x="296" y="84">only]</text>
                      <text x="24" y="100">[MPLS</text>
                      <text x="56" y="100">+</text>
                      <text x="84" y="100">UDP]</text>
                      <text x="204" y="116">R4</text>
                      <text x="244" y="116">[UDP</text>
                      <text x="288" y="116">only]</text>
                      <text x="120" y="148">Bidirectional</text>
                      <text x="208" y="148">Traffic</text>
                    </g>
                  </svg>
</artwork><artwork  type="ascii-art"><![CDATA[
                </artwork>
                <artwork type="ascii-art" name="" align="left" alt=""><![CDATA[
                      RR1---+
                             \  +-------R2  [MPLS + UDP]
                              \ |
                      R1--------P-------R3  [MPLS only]
                [MPLS + UDP]    |
                                +-------R4  [UDP only]

                  <---- Bidirectional Traffic ----->
]]></artwork></artset></figure>
]]></artwork>
              </artset>
            </figure>
            <t>In this example, R1 and R2 support forwarding both MPLS and UDP
            tunneled packets. R3 supports forwarding MPLS packets only. R4
            supports forwarding UDP tunneled packets only. All these nodes
            have BGP session with Route Reflector RR1 RR1, which reflects routes
            between these nodes with the next hop unchanged. The BGP CT family is
            negotiated on these sessions.</t>
            <t>R1 and R2 send and receive both MPLS label labels and UDP tunneling
            info in the BGP CT control plane routes. This allows them to be
            ingress and egress for both MPLS and UDP tunneling data planes.
            The MPLS label is carried using RFC 8277 encoding. the encoding described in <xref target="RFC8277"/>. As specified in
            <xref target="RFC9012"/>, target="RFC9012" format="default"/>, UDP tunneling information is carried
            using TEA attribute (code the Tunnel Encapsulation Attribute (attribute code 23) or the "barebones" Tunnel TLV
            carried in Encapsulation Extended Community. extended community. Either MPLS or UDP
            tunneled
            tunnel forwarding can be used between R1 and R2.</t>
            <t>R1 and R3 send and receive MPLS label labels in the BGP CT control
            plane routes using RFC 8277 encoding. the encoding described in <xref target="RFC8277"/>. This allows them to be
            ingress and egress for MPLS data plane. R1 will carry UDP
            tunneling info in TEA attribute, the TEA, which will not be used by R3.
            MPLS forwarding will be used between R1 and R3.</t>
            <t>R1 and R4 send and receive UDP tunneling info in the BGP CT
            control plane routes using the BGP TEA attribute. TEA. This allows them to
            be ingress and egress for UDP tunneled data plane. R4 will carry
            special
            MPLS Label with value special label 3 (Implicit-NULL) (Implicit NULL) in RFC 8277
            encoding, the encoding described in <xref target="RFC8277"/>,
            which tells R1 not to push any MPLS label for this BGP
            CT route towards R4. The MPLS Label label advertised by R1 will not be
            used by R4. UDP tunneled forwarding will be used between R1 and
            R4.</t>
            <t>Note that, in this example that example, R3 and R4 cannot communicate
            directly with each other, other because they don't support a common
            forwarding technology. The BGP CT routes received at R3, R3 and R4
            from each other will remain unusable, unusable due to incompatible
            forwarding technology.</t>
          </section>
        </section>
      </section>
      <section title="MTU Considerations"> numbered="true" toc="default">
        <name>MTU Considerations</name>
        <t>Operators should coordinate the MTU of the intra-domain tunnels
        used to prevent Path MTU discovery problems that could appear in
        deployments. The encapsulation overhead due to the MPLS label stack or
        equivalent tunnel header in different forwarding architecture should
        also be considered when determining the Path MTU of the end-to-end BGP
        CT tunnel.</t>

        <t>The document <xref target="INTAREA-TUNNELS"/>
        <t><xref target="I-D.ietf-intarea-tunnels" format="default"/> discusses these
        considerations in more detail.</t>
      </section>
      <section title="Use numbered="true" toc="default">
        <name>Use of DSCP"> DSCP</name>
        <t>BGP CT specifies procedures for Intent Driven Service Mapping in a
        service provider network, network and defines the 'Transport Class' construct to
        represent an Intent.</t>
        <t>It may be desirable to allow a CE device to indicate in the data
        packet it sends what treatment it desires (the Intent) when the packet
        is forwarded within the provider network.</t>

        <t>Such an indication can be in the form of a DSCP code point (see <xref
        target="RFC2474"/> target="RFC2474" format="default"/>) in the IP header.</t>
        <t>In RFC2474, <xref target="RFC2474"/>, a Forwarding Class Selector maps to a PHB (Per-hop
        Behavior). The Transport Class construct is a PHB at the transport
        layer.</t>
        <figure title="Example anchor="Intent_PE_CE">
          <name>Example Topology with DSCP on PE-CE Links" anchor="Intent_PE_CE"><artset><artwork  type="svg"><svg Links</name>
          <artset>
            <artwork type="svg" name="" align="left" alt=""><svg xmlns="http://www.w3.org/2000/svg" version="1.1" height="128" width="432" viewBox="0 0 432 128" class="diagram" text-anchor="middle" font-family="monospace" font-size="13px" stroke-linecap="round">
                <path d="M 152,32 L 176,32" fill="none" stroke="black"/>
                <path d="M 216,32 L 256,32" fill="none" stroke="black"/>
                <path d="M 96,48 L 128,48" fill="none" stroke="black"/>
                <path d="M 176,48 L 192,48" fill="none" stroke="black"/>
                <path d="M 224,48 L 248,48" fill="none" stroke="black"/>
                <path d="M 296,48 L 328,48" fill="none" stroke="black"/>
                <path d="M 152,64 L 168,64" fill="none" stroke="black"/>
                <path d="M 224,64 L 256,64" fill="none" stroke="black"/>
                <path d="M 96,96 L 128,96" fill="none" stroke="black"/>
                <path d="M 272,96 L 304,96" fill="none" stroke="black"/>
                <polygon class="arrowhead" points="312,96 300,90.4 300,101.6" fill="black" transform="rotate(0,304,96)"/>
                <polygon class="arrowhead" points="264,64 252,58.4 252,69.6" fill="black" transform="rotate(0,256,64)"/>
                <polygon class="arrowhead" points="264,32 252,26.4 252,37.6" fill="black" transform="rotate(0,256,32)"/>
                <g class="text">
                  <text x="196" y="36">Gold</text>
                  <text x="72" y="52">[CE1]</text>
                  <text x="152" y="52">[PE1]</text>
                  <text x="208" y="52">[P]</text>
                  <text x="272" y="52">[PE2]</text>
                  <text x="352" y="52">[CE2]</text>
                  <text x="196" y="68">Bronze</text>
                  <text x="52" y="84">203.0.113.11</text>
                  <text x="380" y="84">203.0.113.22</text>
                  <text x="160" y="100">Traffic</text>
                  <text x="232" y="100">direction</text>
                </g>
              </svg>
</artwork><artwork  type="ascii-art"><![CDATA[
            </artwork>
            <artwork type="ascii-art" name="" align="left" alt=""><![CDATA[
                      ----Gold----->
          [CE1]-----[PE1]---[P]----[PE2]-----[CE2]
                      ---Bronze---->
    203.0.113.11                             203.0.113.22
               -----Traffic direction---->
]]></artwork></artset></figure>
]]></artwork>
          </artset>
        </figure>
        <t>Let PE1 be configured to map DSCP1 to the Gold Transport class, TC and
        DSCP2 to the Bronze Transport class. TC. Based on the DSCP code point received
        on the IP traffic from the CE device, PE1 forwards the IP packet over a
        Gold or Bronze TC tunnel. Thus, the forwarding is not based on just
        the destination IP address, address but also the DSCP code point. DSCP. This is
        known as Class Based Class-Based Forwarding (CBF).</t>
        <t>CBF is configured at the PE1 device, mapping the DSCP values to
        respective Transport Classes. This mapping (DSCP peering agreement) is
        communicated to CE device devices by out of band out-of-band mechanisms. This allows the
        administrator of CE1 to discover what transport classes Transport Classes exist in the
        provider network, network and which DSCP codepoint to encode so that traffic
        is forwarded using the desired Transport Class in the provided
        network. When the IP packet exits the provider network to CE2, PE2
        resets the DSCP code point based on the DSCP peering agreement with
        CE2.</t>
      </section>
    </section>
    <section title="Applicability numbered="true" toc="default">
      <name>Applicability to Network Slicing"> Slicing</name>
      <t>In Network Slicing, the IETF Network Slice Controller (IETF NSC) (NSC) is
      responsible for customizing and setting up the underlying transport
      (e.g.
      (e.g., RSVP-TE, SRTE tunnels with desired characteristics) and resources
      (e.g., polices/shapers) policies/shapers) in a transport network to create an IETF Network
      Slice.</t>
      <t>The Transport Class construct described in this document can be used
      to realize the "IETF Network Slice" described in Section 4 of <xref
      target="RFC9543"/></t> target="RFC9543" sectionFormat="of" section="4"/>.</t>
      <t>The NSC can use the Transport Class Identifier (Color value) to
      provision a transport tunnel in a specific IETF Network Slice.</t>
      <t>Furthermore, the NSC can use the Mapping Community on the service
      route to map traffic to the desired IETF Network Slice.</t>
    </section>
    <section anchor="IANA" title="IANA Considerations">
      <t>This document makes the following requests of IANA.</t> numbered="true" toc="default">

      <name>IANA Considerations</name>
      <section title="New numbered="true" toc="default">
        <name>New BGP SAFI"> SAFI</name>
        <t>IANA has assigned a BGP SAFI code 76 for "Classful Transport". Value
        76. IANA is requested to update the reference to this document.</t>

        <figure>
          <artwork>
Registry Group: Subsequent "Classful Transport (CT)" SAFI.</t>

	<dl spacing="normal" newline="false">
	  <dt>Registry Group:</dt><dd>Subsequent Address Family Identifiers (SAFI) Parameters

Registry Name: SAFI Values

       Value              Description
      -------------+--------------------------
        76            Classful Transport SAFI
</artwork>
        </figure> Parameters</dd>
	  <dt>Registry Name:</dt><dd><t>SAFI Values</t>

	  <table>
	    <thead>
	      <tr><th>Value</th><th>Description</th><th>Reference</th></tr>
	    </thead>
	    <tbody>
              <tr><td>76</td><td>Classful Transport (CT)</td><td>RFC 9832</td></tr>
	    </tbody>
	  </table>
	</dd>
      </dl>
        <t>This will be used to create new AFI,SAFI AFI/SAFI pairs for IPv4, IPv4 and IPv6
        Classful Transport families. viz:</t>

        <t><list style="symbols">
            <t>"IPv4, Classful Transport".
        BGP CT families, namely:</t>
        <ul spacing="normal">
          <li>
            <t>IPv4 BGP CT: AFI/SAFI = "1/76" 1/76, for carrying IPv4
            Classful Transport prefixes.</t>

            <t>"IPv6, Classful Transport".
          </li>
          <li>
            <t>IPv6 BGP CT: AFI/SAFI = "2/76" 2/76, for carrying IPv6
            Classful Transport prefixes.</t>
          </list></t>
          </li>
        </ul>
      </section>
      <section title="New numbered="true" toc="default">
        <name>New Format for BGP Extended Community"> Community</name>
        <t>IANA has assigned a Format type (Type high = 0xa) of Extended
        Community <xref target="RFC4360">EXT-COMM</xref> target="RFC4360" format="default"></xref> for the Transport Class
        from the following registries:<list> registries in the "Border Gateway Protocol (BGP) Extended Communities" registry group:</t>
        <ul spacing="normal">
          <li>
            <t>the "BGP Transitive Extended Community Types" registry, registry and</t>
          </li>
          <li>
            <t>the "BGP Non-Transitive Extended Community Types" registry.</t>
          </list></t>
          </li>
        </ul>
        <t>The same low-order six bits have been assigned for both
        allocations.</t>

        <t>IANA is requested to update the reference to this document.</t>

        <t>This document uses this new Format with subtype 0x2 (route target),
        as a transitive extended community. The Route Target thus formed is
        called "Transport Class" route target Class Route Target extended community.</t> community".</t>
        <t>The Non-Transitive non-transitive Transport Class Extended extended community with subtype
        0x2 (route target) is called the "Non-Transitive Transport Class route
        target Route
        Target extended community".</t>

        <t>Taking reference of
        <t>Following <xref target="RFC7153"/> , target="RFC7153" format="default"/>,
        assignments in the following
        assignments subsections have been made:</t> made.</t>
        <section title="Existing Registries"> numbered="true" toc="default">
          <name>Existing Registries</name>
          <section title="Registries numbered="true" toc="default">
            <name>Registries for the &quot;Type&quot; Field"> "Type" Field</name>
            <section anchor="tc-rt-t" title="Transitive Types"> numbered="true" toc="default">
              <name>Transitive Types</name>
              <t>This registry contains values of the high-order octet (the
              "Type" field) of a Transitive Extended Community.<figure>
                  <artwork>Registry Group: Border Community.</t>

	      <dl spacing="normal" newline="false">
		<dt>Registry Group:</dt><dd>Border Gateway Protocol (BGP) Extended Communities

Registry Name: BGP Communities</dd>
		<dt>Registry Name:</dt><dd><t>BGP Transitive Extended Community Types

       Type Value        Name
      --------------+---------------
         0x0a          Transport Class

  (Sub-Types Types</t>
		<table>
		  <thead>
		    <tr><th>Type Value</th><th>Name</th></tr>
		  </thead>
		  <tbody>
		    <tr><td>0x0a</td><td>Transport Class</td></tr>
		  </tbody>
		</table>
		<t>(Sub-Types are defined in the "Transitive Transport Class Extended Community Sub-Types"
   registry) </artwork>
                </figure></t> registry.)</t>
	      </dd>
	      </dl>
            </section>
            <section anchor="tc-rt-nt" title="Non-Transitive Types"> numbered="true" toc="default">
              <name>Non-Transitive Types</name>
              <t>This registry contains values of the high-order octet (the
              "Type" field) of a Non-transitive Non-Transitive Extended Community.<figure>
                  <artwork> Registry Group: Border Community.</t>

	      <dl spacing="normal" newline="false">
		<dt>Registry Group:</dt><dd>Border Gateway Protocol (BGP) Extended Communities

 Registry Name: BGP Communities</dd>
		<dt>Registry Name:</dt><dd><t>BGP Non-Transitive Extended Community Types

      Type Value         Name
     --------------+--------------------------------
         0x4a         Non-Transitive Transport Class

 (Sub-Types Types</t>
		<table>
		  <thead>
		    <tr><th>Type Value</th><th>Name</th></tr>
		  </thead>
		  <tbody>
		    <tr><td>0x4a</td><td>Non-Transitive Transport Class</td></tr>
		  </tbody>
		</table>
		<t>(Sub-Types are defined in the "Non-Transitive Transport
		Class Extended Community Sub-Types"
   registry)
 </artwork>
                </figure></t> registry.)</t>
	      </dd>
	      </dl>
            </section>
          </section>
        </section>
        <section title="New Registries"> numbered="true" toc="default">
          <name>New Registries</name>
          <section title="Transitive numbered="true" toc="default">
            <name>Transitive Transport Class Extended Community Sub-Types Registry"> Registry</name>
            <t>IANA is requested to add has added the following subregistry under the
            &ldquo;Border
            "Border Gateway Protocol (BGP) Extended
            Communities&rdquo;:</t>

            <figure>
              <artwork> Registry Group: Border
            Communities" registry group:</t>
	      <dl spacing="normal" newline="false">
		<dt>Registry Group:</dt><dd>Border Gateway Protocol (BGP) Extended Communities

 Registry Name: Transitive Communities</dd>
		<dt>Registry Name:</dt><dd>Transitive Transport Class Extended Community Sub-Types

 Note: Sub-Types</dd>
	      </dl>
	    <t>Note: This registry contains values of the second octet (the
	    "Sub-Type" field) of an extended community when the value of the
	    first octet (the "Type" field) is 0x0a.

 Range                 Registration Procedures
 -----------------+----------------------------
 0x00-0xBF           First 0x0a.</t>

	    <table>
	      <thead>
		<tr><th>Range</th><th>Registration Procedure</th></tr>
	      </thead>
	      <tbody>
		<tr><td>0x00-0xbf</td><td>First Come First Served
 0xC0-0xFF           IETF Review

 Sub-Type Value         Name
 -----------------+--------------
   0x02              Route Target
              </artwork>
            </figure> Served</td></tr>
		<tr><td>0xc0-0xff</td><td>IETF Review</td></tr>
	      </tbody>
	    </table>
	    <table>
	      <thead>
		<tr><td>Sub-Type Value</td><td>Name</td></tr>
	      </thead>
	      <tbody>
		<tr><td>0x02</td><td>Route Target</td></tr>
	      </tbody>
	    </table>

          </section>
          <section title="Non-Transitive numbered="true" toc="default">
            <name>Non-Transitive Transport Class Extended Community Sub-Types Registry"> Registry</name>
            <t>IANA is requested to add has added the following subregistry under the
            &ldquo;Border
            "Border Gateway Protocol (BGP) Extended
            Communities&rdquo;:</t>

            <figure>
              <artwork> Registry Group: Border
            Communities" registry group:</t>
	    <dl spacing="normal" newline="false">
	      <dt>Registry Group:</dt><dd>Border Gateway Protocol (BGP) Extended Communities

 Registry Name: Non-Transitive Communities</dd>
	      <dt>Registry Name:</dt><dd>Non-Transitive Transport Class Extended Community Sub-Types

 Note: Sub-Types</dd>
	    </dl>
	    <t>Note: This registry contains values of the second octet (the
	    "Sub-Type" field) of an extended community when the value of the
	    first octet (the "Type" field) is 0x4a.

 Range                 Registration Procedures
 -----------------+----------------------------
 0x00-0xBF           First 0x4a.</t>

	    <table>
	      <thead>
		<tr><th>Range</th><th>Registration Procedure</th></tr>
	      </thead>
	      <tbody>
		<tr><td>0x00-0xbf</td><td>First Come First Served
 0xC0-0xFF           IETF Review

 Sub-Type Value         Name
 -----------------+--------------
   0x02              Route Target

              </artwork>
            </figure> Served</td></tr>
		<tr><td>0xc0-0xff</td><td>IETF Review</td></tr>
	      </tbody>
	    </table>

	    <table>
	      <thead>
		<tr><th>Sub-Type Value</th><th>Name</th></tr>
	      </thead>
	      <tbody>
		<tr><td>0x02</td><td>Route Target</td></tr>
	      </tbody>
	    </table>

          </section>
        </section>
      </section>
      <section title="MPLS numbered="true" toc="default">
        <name>MPLS OAM Code Points"> Points</name>
        <t>The following two code points have been assigned for Target FEC
        Stack sub-TLVs:</t>

        <t><list style="symbols">
        <ul spacing="normal">
          <li>
            <t>IPv4 BGP Classful Transport</t>
          </li>
          <li>
            <t>IPv6 BGP Classful Transport</t>
          </list><figure>
            <artwork> Registry Group: Multiprotocol
          </li>
        </ul>

	<dl spacing="normal" newline="false">
	  <dt>Registry Group:</dt><dd>Multiprotocol Label Switching (MPLS) Label Switched Paths (LSPs) Ping Parameters

 Registry Name: Sub-TLVs Parameters</dd>
	  <dt>Registry Name:</dt><dd><t>Sub-TLVs for TLV Types 1, 16, and 21

  Sub-Type                Name
 -----------------+------------------------------
   31744              IPv4 21</t>
	  <table>
	    <thead>
	      <tr><th>Sub-Type</th><th>Name</th></tr>
	    </thead>
	    <tbody>
	      <tr><td>31744</td><td>IPv4 BGP Classful Transport
   31745              IPv6 Transport</td></tr>
	      <tr><td>31745</td><td>IPv6 BGP Classful Transport

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

        <t>IANA is requested to update the reference to this document.</t> Transport</td></tr>
	    </tbody>
	  </table>
	</dd>
      </dl>

      </section>
    </section>

      <section anchor="local-registries" title="Registries maintained by this document">
      <section title="Transport numbered="true" toc="default">
        <name>Transport Class ID"> ID Registry</name>
        <t>This RFC documents the "Transport Class ID" registry and its assigned values.  The value ranges in this registry are either assigned by this document reserves or reserved for Private Use.  Because the registry is complete, it is being published in this RFC rather than as an IANA-maintained registry.  However, note that IANA-related terminology <xref target="BCP26" format="default"/> is used here.</t>

	<t>Registry Name: Transport class Class ID</t>

	<t>The Registration Procedures are as follows:</t>

	  <table>
	    <thead>
	      <tr><th>Value</th><th>Registration Procedure</th></tr>
	    </thead>
	    <tbody>
	      <tr><td>0</td><td>IETF Review</td></tr>
	      <tr><td>1-4294967295</td><td>Private Use</td></tr>
	    </tbody>
	  </table>

<t>As shown in the table below, the Transport Class ID value 0 is Reserved to represent
        "Best Effort the "Best-Effort Transport Class ID".  This is used in the 'Transport Class ID' field of a Transport Route Target extended community Class RT that represents
        best effort transport class.</t>

        <t>Since all value ranges in this registry are already assigned or
        Private use, this registry will be maintained by this document. IANA
        does not need to maintain this registry.</t>

        <t><figure>
            <artwork> Registry Group: BGP Classful Transport (BGP CT)

 Registry Name: the Best-Effort Transport Class ID

  Value                 Name
 -----------------+--------------------------------
   0                Best Effort Class.</t>

	  <table>
	    <thead>
	      <tr><th>Value</th><th>Name</th></tr>
	    </thead>
	    <tbody>
	      <tr><td>0</td><td>Best-Effort Transport Class ID
   1-4294967295     Private Use

 Reference: This document.

 Registration Procedure(s)

  Value                 Registration Procedure
 -----------------+--------------------------------
   0                IETF Review
   1-4294967295     Private Use

              </artwork>
          </figure></t> ID</td></tr>
	      <tr><td>1-4294967295</td><td>Private Use</td></tr>
	    </tbody>
	  </table>

        <t>As noted in Sec 4 Sections <xref target="tc" format="counter"/> and Sec 7.10, <xref
        target="bgp-att" format="counter"/>, 'Transport Class ID' is
        interchangeable with 'Color'. For purposes of backward compatibility
        with usage of a 'Color' field in a Color extended community as specified
        in <xref target="RFC9012"/> target="RFC9012" format="default"/> and <xref target="RFC9256"/>,
        target="RFC9256" format="default"/>, the range 1-4294967295 uses
        'Private Use' as the Registration Procedure.</t>
      </section>
</section>
    <section anchor="Security" title="Security Considerations"> numbered="true" toc="default">
      <name>Security Considerations</name>
      <t>This document uses <xref target="RFC4760"/> the mechanisms from <xref target="RFC4760" format="default"/> to define new
      BGP address families (AFI/SAFI : 1/76 and 2/76) that carry transport layer
      endpoints. These address families are explicitly configured and
      negotiated between BGP speakers, which confines the propagation scope of
      this reachability information. These routes stay in the part of network
      where the new address family is negotiated, negotiated and don't leak out into
      the Internet. </t>
      <t>Furthermore, procedures defined in <xref target="secure-propagate"/> target="secure-propagate" format="default"/> mitigate
      the risk of unintended propagation of BGP CT routes across Inter-AS inter-AS
      boundaries even when a BGP CT family is negotiated. BGP import and export policies
      are used to control the BGP CT reachability information exchanged across AS boundaries.
      This mitigates the risk of advertising internal loopback addresses outside the
      administrative control of the provider network. </t>
      <t>This document does not change the underlying security issues inherent
      in the existing BGP protocol, such as those described in <xref
      target="RFC4271"/> target="RFC4271" format="default"/> and <xref target="RFC4272"/>.</t> target="RFC4272" format="default"/>.</t>
      <t>Additionally, BGP sessions SHOULD <bcp14>SHOULD</bcp14> be protected using the TCP
      Authentication Option <xref target="RFC5925"/> target="RFC5925" format="default"/> and the Generalized TTL
      Security Mechanism <xref target="RFC5082"/>.</t> target="RFC5082" format="default"/>.</t>
      <t>Using a separate BGP family and new RT (Transport Class RT) minimizes
      the possibility of these routes mixing with service routes.</t>
      <t>If redistributing between SAFI 76 and SAFI 4 routes for AFIs 1 or 2,
      there is a possibility of SAFI 4 routes mixing with SAFI 1 service
      routes. To avoid such scenarios, it is RECOMMENDED <bcp14>RECOMMENDED</bcp14> that implementations
      support keeping SAFI 76 and SAFI 4 transport routes in separate
      transport RIBs, distinct from service RIB that contain SAFI 1 service
      routes.</t>
      <t>BGP CT routes distribute label binding using <xref target="RFC8277"/> target="RFC8277" format="default"/>
      for the MPLS dataplane and hence data plane; hence, its security considerations apply.</t>
      <t>BGP CT routes distribute SRv6 SIDs for SRv6 dataplanes and hence data planes; hence,
      the security considerations of Section 9.3 of <xref target="RFC9252"/> target="RFC9252" sectionFormat="of" section="9.3"/>
      apply. Moreover, the SRv6 SID transposition scheme Transposition Scheme is disabled in BGP CT, as
      described in <xref target="SRv6-Support"/>, target="SRv6-Support" format="default"/>, to mitigate the risk of
      misinterpreting transposed SRv6 SID information as an MPLS label.</t>
      <t>As <xref target="RFC4272"/> target="RFC4272" format="default"/> 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>In order to mitigate the risk of the diversion of traffic from its
      intended destination, BGPsec solutions (<xref target="RFC8205"/> target="RFC8205" format="default"/> and
      Origin Validation <xref target="RFC8210"/><xref target="RFC6811"/>) target="RFC8210" format="default"/><xref target="RFC6811" format="default"/>) may
      be extended in future to work for non-Internet SAFIs (SAFIs other than
      1).</t>
      <t>The restriction of the applicability of the BGP CT SAFI 76 to its
      intended well-defined scope and utilizing <xref target="RFC8212"/> target="RFC8212" format="default"/> limits
      the likelihood of traffic diversions.</t>
    </section>
  </middle>
  <back>
    <references title="Normative References">
      <?rfc include="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8277.xml"?>

      <?rfc include="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7606.xml"?>

      <?rfc include="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"?>

      <?rfc include="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.2545.xml"?>

      <?rfc include="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.2474.xml"?>

      <?rfc include="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.4659.xml"?>

      <?rfc include="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.4271.xml"?>

      <?rfc include="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.4272.xml"?>

      <?rfc include="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.5082.xml"?>

      <?rfc include="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.5925.xml"?>

      <?rfc include="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6811.xml"?>

      <?rfc include="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.4364.xml"?>

      <?rfc include="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.4360.xml"?>

      <?rfc include="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.4684.xml"?>

      <?rfc include="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.4760.xml"?>

      <?rfc include="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7911.xml"?>

      <?rfc include="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8669.xml"?>

      <?rfc include="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.9012.xml"?>

      <?rfc include="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.9252.xml"?>

      <?rfc include="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"?>

      <?rfc include="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7153.xml"?>

      <?rfc include="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8029.xml"?>

      <?rfc include="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8212.xml"?>
    <displayreference target="I-D.ietf-idr-bgp-ct-srv6" to="BGP-CT-SRv6"/>
    <displayreference target="I-D.ietf-idr-bgp-fwd-rr" to="BGP-FWD-RR"/>
    <displayreference target="I-D.ietf-idr-multinexthop-attribute" to="MNH"/>
    <displayreference target="I-D.ietf-idr-flowspec-redirect-ip" to="FLOWSPEC-REDIR-IP"/>
    <displayreference target="I-D.kaliraj-bess-bgp-mpls-namespaces" to="MPLS-NS"/>
    <displayreference target="I-D.hr-spring-intentaware-routing-using-color" to="Intent-Routing-Color"/>
    <displayreference target="I-D.ietf-pce-pcep-color" to="PCEP-RSVP-COLOR"/>
    <displayreference target="I-D.ietf-pce-segment-routing-policy-cp" to="PCEP-SRPOLICY"/>
    <displayreference target="I-D.gredler-idr-bgplu-epe" to="BGP-LU-EPE"/>
    <displayreference target="I-D.ietf-intarea-tunnels" to="INTAREA-TUNNELS"/>
    <references>
      <name>References</name>
      <references>
        <name>Normative References</name>
        <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.7606.xml"/>
        <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.2545.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2474.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.4271.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.5082.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.4364.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.4684.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.7911.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.9012.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9252.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7153.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8029.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8212.xml"/>

<!--
draft-ietf-idr-sr-policy-safi-13
companion document RFC 9830, in EDIT as of 04/11/25.
Original cite tag [SRTE].
 -->
<reference anchor="SRTE"
                 target="https://datatracker.ietf.org/doc/html/draft-ietf-idr-sr-policy-safi-10"> anchor="RFC9830" target="https://www.rfc-editor.org/info/rfc9830">
  <front>
      <title>Advertising Segment Routing Policies in BGP</title>
      <author fullname="Ketan" initials="" role="editor"
                  surname="Talaulikar"/> initials="S." surname="Previdi" fullname="Stefano Previdi">
         <organization>Huawei Technologies</organization>
      </author>
      <author initials="C." surname="Filsfils" fullname="Clarence Filsfils">
         <organization>Cisco Systems</organization>
      </author>
      <author initials="K." surname="Talaulikar" fullname="Ketan Talaulikar" role="editor">
         <organization>Cisco Systems</organization>
      </author>
      <author fullname="Previdi" initials="S" surname="Previdi"/> initials="P." surname="Mattes" fullname="Paul Mattes">
         <organization>Microsoft</organization>
      </author>
      <author initials="D." surname="Jain" fullname="Dhanendra Jain">
         <organization>Google</organization>
      </author>
    <date day="07" month="11" year="2024"/> month="August" year='2025'/>
  </front>
  <seriesInfo name="RFC" value="9830"/>
  <seriesInfo name="DOI" value="10.17487/RFC9830"/>
</reference>

      </references>

    <references title="Informative References">
      <?rfc include="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.9350.xml"?>

      <?rfc include="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.9315.xml"?>

      <?rfc include="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6890.xml"?>

      <?rfc include="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.9256.xml"?>

      <?rfc include="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8205.xml"?>

      <?rfc include="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8210.xml"?>

      <?rfc include="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.9543.xml"?>
      <references>
        <name>Informative References</name>
        <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.9315.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6890.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.8205.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8210.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9543.xml"/>
	<xi:include href="https://bib.ietf.org/public/rfc/bibxml9/reference.BCP.26.xml"/>

<!-- [BGP-CT-SRv6]
draft-ietf-idr-bgp-ct-srv6-06
IESG State: Expired as of 8/15/25
-->

<reference anchor="BGP-CT-SRv6"
                 target="https://tools.ietf.org/html/draft-ietf-idr-bgp-ct-srv6-05"> anchor="I-D.ietf-idr-bgp-ct-srv6" target="https://datatracker.ietf.org/doc/html/draft-ietf-idr-bgp-ct-srv6-07">
   <front>
          <title abbrev="BGP-CT-SRv6">BGP
      <title>BGP CT - Adaptation to SRv6 dataplane</title>
      <author initials="K." surname="Vairavakkalai" fullname="Kaliraj Vairavakkalai" initials="" role="editor"
                  surname="Vairavakkalai"/> role="editor">
         <organization>Juniper Networks, Inc.</organization>
      </author>
      <author fullname="Natarajan initials="N." surname="Venkataraman" fullname="Natrajan Venkataraman" initials="" role="editor"
                  surname="Venkataraman"/> role="editor">
         <organization>Juniper Networks, Inc.</organization>
      </author>
      <date day="25" month="4" year="2024"/> month="August" day="22" year="2025" />
   </front>
   <seriesInfo name="Internet-Draft" value="draft-ietf-idr-bgp-ct-srv6-07" />

</reference>

<!-- [BGP-FWD-RR]
draft-ietf-idr-bgp-fwd-rr-03
IESG State: Expired as of 08/15/25.
-->

<reference anchor="BGP-FWD-RR"
                 target="https://tools.ietf.org/html/draft-ietf-idr-bgp-fwd-rr-02"> anchor="I-D.ietf-idr-bgp-fwd-rr" target="https://datatracker.ietf.org/doc/html/draft-ietf-idr-bgp-fwd-rr-04">
   <front>
          <title abbrev="BGP-FWD-RR">BGP
      <title>BGP Route Reflector in Forwarding
          Path</title> with Next Hop Self</title>
      <author initials="K." surname="Vairavakkalai" fullname="Kaliraj Vairavakkalai" initials="" role="editor"
                  surname="Vairavakkalai"/> role="editor">
         <organization>Juniper Networks, Inc.</organization>
      </author>
      <author fullname="Natarajan initials="N." surname="Venkataraman" fullname="Natrajan Venkataraman" initials="" role="editor"
                  surname="Venkataraman"/> role="editor">
         <organization>Juniper Networks, Inc.</organization>
      </author>
      <date day="17" month="3" year="2024"/> month="August" day="22" year="2025" />
   </front>
   <seriesInfo name="Internet-Draft" value="draft-ietf-idr-bgp-fwd-rr-04" />

</reference>

<!-- [MNH]
draft-ietf-idr-multinexthop-attribute-04
IESG State: I-D Exists as of 08/15/25.
-->

<reference anchor="MNH"
                 target="https://datatracker.ietf.org/doc/html/draft-ietf-idr-multinexthop-attribute-00"> anchor="I-D.ietf-idr-multinexthop-attribute" target="https://datatracker.ietf.org/doc/html/draft-ietf-idr-multinexthop-attribute-04">
   <front>
          <title abbrev="MNH">BGP
      <title>BGP MultiNexthop Attribute</title>
      <author initials="K." surname="Vairavakkalai" fullname="Kaliraj Vairavakkalai" initials="" role="editor"
                  surname="Vairavakkalai"/>

          <date day="17" month="03" year="2024"/>
        </front>
      </reference>

      <reference anchor="FLOWSPEC-REDIR-IP"
                 target="https://datatracker.ietf.org/doc/html/draft-ietf-idr-flowspec-redirect-ip-03">
        <front>
          <title abbrev="FLOWSPEC-REDIR-IP">BGP Flow-Spec Redirect to IP
          Action</title> role="editor">
         <organization>Juniper Networks, Inc.</organization>
      </author>
      <author fullname="Adam Simpson" initials="" role="editor"
                  surname="Simpson"/>

          <date day="08" month="09" year="2024"/>
        </front>
      </reference>

      <reference anchor="MPLS-NS"
                 target="https://datatracker.ietf.org/doc/html/draft-kaliraj-bess-bgp-sig-private-mpls-labels-09">
        <front>
          <title abbrev="MPLS namespaces">BGP signalled MPLS
          namespaces</title> initials="J. M." surname="Jeganathan" fullname="Jeyananth Minto Jeganathan">
         <organization>Juniper Networks, Inc.</organization>
      </author>
      <author fullname="Kaliraj" initials="" role="editor"
                  surname="Vairavakkalai"/>

          <date day="09" month="11" year="2024"/>
        </front>
      </reference>

      <reference anchor="Intent-Routing-Color"
                 target="https://datatracker.ietf.org/doc/html/draft-hr-spring-intentaware-routing-using-color-03">
        <front>
          <title abbrev="Intent-Routing-Color">Intent-aware Routing using
          Color</title> initials="M." surname="Nanduri" fullname="Mohan Nanduri">
         <organization>Microsoft</organization>
      </author>
      <author fullname="Shraddha" initials="" role="editor"
                  surname="Hegde"/> initials="A. R." surname="Lingala" fullname="Avinash Reddy Lingala">
         <organization>AT&amp;T</organization>
      </author>
      <date day="23" month="10" year="2023"/> month="March" day="25" year="2025" />
   </front>
   <seriesInfo name="Internet-Draft" value="draft-ietf-idr-multinexthop-attribute-04" />

</reference>

<!--  [FLOWSPEC-REDIR-IP]
draft-ietf-idr-flowspec-redirect-ip-03
IESG State: Expired as of 08/15/25.

Note to PE: Author name "akarch@cisco.com" matches info available on
datatracker: https://datatracker.ietf.org/person/akarch@cisco.com
-->

	<xi:include href="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-idr-flowspec-redirect-ip.xml"/>

<!-- [MPLS-NS]
draft-kaliraj-bess-bgp-sig-private-mpls-labels-09
IESG State: I-D Exists as of 04/11/25.
-->

<reference anchor="PCEP-RSVP-COLOR"
                 target="https://datatracker.ietf.org/doc/html/draft-ietf-pce-pcep-color-11"> anchor="I-D.kaliraj-bess-bgp-mpls-namespaces" target="https://datatracker.ietf.org/doc/html/draft-kaliraj-bess-bgp-mpls-namespaces-01">
   <front>
          <title abbrev="PCEP RSVP COLOR">Path Computation Element
          Protocol(PCEP) Extension for RSVP Color</title>

          <author fullname="Balaji" initials="" role="editor"
                  surname="Rajagopalan"/>
      <title>BGP Signaled MPLS Namespaces</title>
      <author fullname="Vishnu" initials="Pavan" role="editor"
                  surname="Beeram"/>

          <date day="17" month="02" year="2025"/>
        </front>
      </reference>

      <reference anchor="PCEP-SRPOLICY"
                 target="https://www.ietf.org/archive/id/draft-ietf-pce-segment-routing-policy-cp-14.html">
        <front>
          <title abbrev="PCEP SRPOLICY">PCEP Extensions for SR Policy
          Candidate Paths</title> initials="K." surname="Vairavakkalai" fullname="Kaliraj Vairavakkalai" role="editor">
         <organization>Juniper Networks, Inc.</organization>
      </author>
      <author fullname="Mike" initials="" role="editor"
                  surname="Koldychev"/> initials="J. M." surname="Jeganathan" fullname="Jeyananth Minto Jeganathan">
         <organization>Juniper Networks, Inc.</organization>
      </author>
      <author fullname="Siva" initials="" role="editor"
                  surname="Sivabalan"/> initials="P." surname="Ramadenu" fullname="Praveen Ramadenu">
         <organization>AT&amp;T</organization>
      </author>
      <author fullname="Colby" initials="" role="editor" surname="Barth"/> initials="I." surname="Means" fullname="Israel Means">
         <organization>AT&amp;T</organization>
      </author>
      <date day="09" month="02" year="2024"/> month="Aug" day="21" year="2025" />
   </front>
   <seriesInfo name="Internet-Draft" value="draft-kaliraj-bess-bgp-mpls-namespaces-01" />
</reference>

<!--  [Intent-Routing-Color]
draft-hr-spring-intentaware-routing-using-color-04
IESG State: Expired as of 8/15/25
-->
	<xi:include href="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.hr-spring-intentaware-routing-using-color.xml"/>

<!--  [PCEP-RSVP-COLOR]
draft-ietf-pce-pcep-color-12
IESG State: RFC Ed Queue RFC-Editor as of 8/15/25
-->

	<xi:include href="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-pce-pcep-color.xml"/>

<!--  [PCEP-SRPOLICY]
draft-ietf-pce-segment-routing-policy-cp-25
IESG State: RFC Ed Queue RFC-ED state as of 8/15/25
-->
	<xi:include href="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-pce-segment-routing-policy-cp.xml"/>

        <reference anchor="BGP-CT-UPDATE-PACKING-TEST"
                 target="https://raw.githubusercontent.com/ietf-wg-idr/draft-ietf-idr-bgp-ct/1a75d4d10d4df0f1fd7dcc041c2c868704b092c7/update-packing-test-results.txt"> anchor="PACKING-TEST" target="https://github.com/ietf-wg-idr/draft-ietf-idr-bgp-ct/blob/main/update-packing-test-results.txt">
          <front>
          <title abbrev="BGP-CT-UPDATE-PACKING-TEST">BGP CT Update packing
          Test Results</title>

          <author fullname="Kaliraj" initials="" role="editor"
                  surname="Vairavakkalai"/>
          <title>update-packing-test-results.txt</title>
	  <author/>
            <date day="25" month="06" year="2023"/>
          </front>
          <refcontent>1a75d4d</refcontent>
        </reference>

<!--  [BGP-LU-EPE]
draft-gredler-idr-bgplu-epe-16
IESG State: I-D Exists as of 8/15/25
-->
<reference anchor="BGP-LU-EPE"
                 target="https://datatracker.ietf.org/doc/html/draft-gredler-idr-bgplu-epe-15"> anchor="I-D.gredler-idr-bgplu-epe" target="https://datatracker.ietf.org/doc/html/draft-gredler-idr-bgplu-epe-16">
   <front>
          <title abbrev="BGP LU EPE">Egress
      <title>Egress Peer Engineering using BGP-LU</title>
      <author fullname="Hannes" initials="" role="editor"
                  surname="Gredler"/>

          <date day="16" month="06" year="2023"/>
        </front>
      </reference>

      <reference anchor="INTAREA-TUNNELS"
                 target="https://datatracker.ietf.org/doc/draft-ietf-intarea-tunnels/13/">
        <front>
          <title abbrev="INTAREA-TUNNELS">IP Tunnels in the Internet
          Architecture</title> initials="H." surname="Gredler" fullname="Hannes Gredler" role="editor">
         <organization>RtBrick Inc.</organization>
      </author>
      <author fullname="Dr. Joseph D Touch" initials="" role="editor"
                  surname="Touch"/> initials="K." surname="Vairavakkalai" fullname="Kaliraj Vairavakkalai" role="editor">
         <organization>Juniper Networks, Inc.</organization>
      </author>
      <author fullname="Mark Townsley" initials="" role="editor"
                  surname="Townsley"/> initials="C." surname="R" fullname="Chandrasekar R">
         <organization>Juniper Networks, Inc.</organization>
      </author>
      <author initials="B." surname="Rajagopalan" fullname="Balaji Rajagopalan">
         <organization>Juniper Networks, Inc.</organization>
      </author>
      <author initials="E." surname="Aries" fullname="Ebben Aries">
         <organization>Juniper Networks, Inc.</organization>
      </author>
      <author initials="L." surname="Fang" fullname="Luyuan Fang">
         <organization>eBay</organization>
      </author>
      <date day="26" month="03" year="2023"/> month="October" day="14" year="2024" />
   </front>
   <seriesInfo name="Internet-Draft" value="draft-gredler-idr-bgplu-epe-16" />

</reference>

<!--  [INTAREA-TUNNELS]
draft-ietf-intarea-tunnels-14
IESG State: I-D Exists in WG Last Call as of 8/15/25
-->

	<xi:include href="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-intarea-tunnels.xml"/>

      </references>
    </references>
    <section anchor="Appendix A" anchor="Appendix_A" numbered="true"
             title="Extensibility considerations"> toc="default">
      <name>Extensibility Considerations</name>
      <section title="Signaling numbered="true" toc="default">
        <name>Signaling Intent over a PE-CE Attachment Circuit"> Circuit</name>
        <t>It may be desirable to allow a CE device to indicate in the data
        packet it sends what treatment it desires (the Intent) when the packet
        is forwarded within the provider network.</t>

        <t>Section A.10 in <xref target="MNH">BGP MultiNexthop
        Attribute</xref>
        <t><xref section="A.10" target="I-D.ietf-idr-multinexthop-attribute" format="default"></xref> describes some mechanisms that enable such
        signaling.</t>
      </section>
      <section title="BGP numbered="true" toc="default">
        <name>BGP CT Egress TE"> TE</name>
        <t>Mechanisms described in <xref target="BGP-LU-EPE"/> target="I-D.gredler-idr-bgplu-epe" format="default"/> also applies apply to the
        BGP CT family.</t>
        <t>The Peer/32 or Peer/128 EPE route MAY <bcp14>MAY</bcp14> be originated in the BGP CT
        family with the appropriate Mapping Community (e.g. (e.g.,
        transport-target:0:100), thus allowing an EPE path to the peer that
        satisfies the desired SLA.</t>
      </section>
    </section>
    <section anchor="Appendix B" anchor="Appendix_B" numbered="true"
             title="Applicability toc="default">
      <name>Applicability to Intra-AS and different Different Inter-AS deployments."> Deployments</name>
      <t>As described in <xref target="RFC4364">BGP VPN</xref> Section 10, section="10" target="RFC4364" format="default"></xref>, in an Option option C network, service routes (VPN-IPv4) are
      neither maintained nor distributed by the ASBRs. Transport routes are
      maintained in the ASBRs and propagated in BGP LU or BGP CT.</t>
      <t><xref target="CTProc">Illustration of CT Procedures</xref> target="CTProc" format="default"></xref>
      illustrates how constructs of BGP CT work in an inter-AS Option option C
      deployment. The BGP CT constructs: AFI/SAFI 1/76, Transport Class Class, and
      Resolution Scheme are used in an inter-AS Option option C deployment.</t>
      <t>In Intra-AS intra-AS and Inter-AS inter-AS option A, A and option B scenarios, AFI/SAFI 1/76
      may not be used, but the Transport Class and Resolution Scheme
      mechanisms are used to provide service mapping.</t>
      <t>This section illustrates how BGP CT constructs work in Intra-AS intra-AS and
      Inter-AS Option A,
      inter-AS option A and option B deployment scenarios.</t>
      <section title="Intra-AS usecase"> numbered="true" toc="default">
        <name>Intra-AS Use Case</name>
        <section title="Topology"> numbered="true" toc="default">
          <name>Topology</name>
          <figure title="BGP anchor="BGPCT_INTRA_AS">
            <name>BGP CT Intra-AS" anchor="BGPCT_INTRA_AS"><artset><artwork  type="svg"><svg Intra-AS</name>
            <artset>
              <artwork type="svg" name="" align="left" alt=""><svg xmlns="http://www.w3.org/2000/svg" version="1.1" height="208" width="440" viewBox="0 0 440 208" class="diagram" text-anchor="middle" font-family="monospace" font-size="13px" stroke-linecap="round">
                  <path d="M 200,48 L 200,64" fill="none" stroke="black"/>
                  <path d="M 56,80 L 72,80" fill="none" stroke="black"/>
                  <path d="M 128,80 L 176,80" fill="none" stroke="black"/>
                  <path d="M 216,80 L 256,80" fill="none" stroke="black"/>
                  <path d="M 312,80 L 352,80" fill="none" stroke="black"/>
                  <path d="M 112,176 L 136,176" fill="none" stroke="black"/>
                  <path d="M 296,176 L 328,176" fill="none" stroke="black"/>
                  <polygon class="arrowhead" points="336,176 324,170.4 324,181.6" fill="black" transform="rotate(0,328,176)"/>
                  <g class="text">
                    <text x="204" y="36">[RR11]</text>
                    <text x="28" y="84">[CE21]</text>
                    <text x="100" y="84">[PE11]</text>
                    <text x="196" y="84">[P1]</text>
                    <text x="284" y="84">[PE12]</text>
                    <text x="380" y="84">[CE31]</text>
                    <text x="72" y="116">:</text>
                    <text x="312" y="116">:</text>
                    <text x="32" y="132">AS2</text>
                    <text x="72" y="132">:</text>
                    <text x="200" y="132">...AS1...</text>
                    <text x="312" y="132">:</text>
                    <text x="368" y="132">AS3</text>
                    <text x="72" y="148">:</text>
                    <text x="312" y="148">:</text>
                    <text x="52" y="180">203.0.113.21</text>
                    <text x="176" y="180">Traffic</text>
                    <text x="248" y="180">Direction</text>
                    <text x="388" y="180">203.0.113.31</text>
                  </g>
                </svg>
</artwork><artwork  type="ascii-art"><![CDATA[
              </artwork>
              <artwork type="ascii-art" name="" align="left" alt=""><![CDATA[
                          [RR11]
                            |
                            +
    [CE21]---[PE11]-------[P1]------[PE12]------[CE31]

            :                             :
      AS2   :           ...AS1...         :     AS3
            :                             :

    203.0.113.21 ---- Traffic Direction ----> 203.0.113.31
]]></artwork></artset></figure>

          <t>This example in <xref target="BGPCT_INTRA_AS"/>
]]></artwork>
            </artset>
          </figure>
          <t><xref target="BGPCT_INTRA_AS" format="default"/> shows a provider
          network Autonomous system System, AS1. It serves customers AS2, AS2 and AS3. Traffic
          direction being described is CE21 to CE31. CE31 may request a
          specific SLA (e.g. (e.g., Gold for this traffic), traffic) when traversing this
          provider network.</t>
        </section>
        <section title="Transport Layer"> numbered="true" toc="default">
          <name>Transport Layer</name>
          <t>AS1 uses RSVP-TE intra-domain tunnels between PE11 and PE12. And it uses
          LDP tunnels for best effort best-effort traffic.</t>
          <t>The network has two Transport classes: TCs: Gold with Transport Class TC ID 100, 100 and Bronze
          with Transport Class TC ID 200. These transport classes TCs
          are provisioned at the PEs. This creates the Resolution Schemes for
          these transport classes TCs at these PEs.</t>

          <t>Following
          <t>The following tunnels exist for the Gold transport class.<list> TC:</t>
          <ul spacing="normal">
            <li>
              <t>PE11_to_PE12_gold - RSVP-TE tunnel</t>
            </li>
            <li>
              <t>PE12_to_PE11_gold - RSVP-TE tunnel</t>
            </list></t>

          <t>Following
            </li>
          </ul>
          <t>The following tunnels exist for Bronze transport class.<list> TC:</t>
          <ul spacing="normal">
            <li>
              <t>PE11_to_PE12_bronze - RSVP-TE tunnel</t>
            </li>
            <li>
              <t>PE11_to_PE12_bronze - RSVP-TE tunnel</t>
            </list></t>
            </li>
          </ul>
          <t>These tunnels are provisioned to belong to transport class Transport Class 100 or
          200.</t>
        </section>
        <section title="Service numbered="true" toc="default">
          <name>Service Layer route exchange"> Route Exchange</name>
          <t>Service nodes PE11, PE11 and PE12 negotiate service families (AFI/SAFI
          1/128) on the BGP session with RR11. Service helper RR11 reflects
          service routes between the two PEs with the next hop unchanged. There
          are no tunnels for transport-class Transport Class 100 or 200 from RR11 to the
          PEs.</t>
          <t>Forwarding happens using service routes at service nodes PE11, PE11 and
          PE12. Routes received from CEs are not present in any other nodes'
          FIB in the provider network.</t>
          <t>CE31 advertises a route route, for example example, prefix 203.0.113.31 with the next
          hop self set to itself to PE12. CE31 can attach a Mapping Community Color:0:100 color:0:100 on
          this route, route to indicate its request for a Gold SLA. Or, PE12 can
          attach the same using locally configured policies.</t>

          <t>Consider,
          <t>Consider CE31 is getting VPN service from PE12. The
          RD:203.0.113.31 route is readvertised in AFI/SAFI 1/128 by PE12 with
          the next hop self set to itself (192.0.2.12) and label V-L1, V-L1 to RR11 with the Mapping
          Community Color:0:100 color:0:100 attached. This AFI/SAFI 1/128 route reaches
          PE11 via RR11 with the next hop unchanged as PE12 and label V-L1.
          Now PE11 can resolve the PNH 192.0.2.12 using the PE11_to_PE12_gold RSVP
          TE LSP.</t>
          <t>The IP FIB at PE11 VRF will have a route for 203.0.113.31 with a
          next hop when resolved using the Resolution Scheme belonging to the
          mapping community Color:0:100,
          Mapping Community color:0:100, points to a PE11_to_PE12_gold
          tunnel.</t>
          <t>BGP CT AFI/SAFI 1/76 is not used in this Intra-AS intra-AS deployment. But
          the Transport class Class and Resolution Scheme constructs are used to
          preserve end-to-end SLA.</t>
        </section>
      </section>
      <section title="Inter-AS option numbered="true" toc="default">
        <name>Inter-AS Option A usecase"> Use Case</name>
        <section title="Topology"> numbered="true" toc="default">
          <name>Topology</name>
        <figure title="BGP CT Inter-AS option A" anchor="BGPCT_INTERAS_A"><artset><artwork  type="svg"><svg anchor="BGPCT_INTERAS_A">
          <artset>
            <artwork type="svg">
              <svg xmlns="http://www.w3.org/2000/svg" version="1.1" height="192" width="624" width="560"
                viewBox="0 0 624 560 192" class="diagram" text-anchor="middle" font-family="monospace"
                font-size="13px" stroke-linecap="round">
                <path d="M 168,48 L 168,64" fill="none" stroke="black"/> stroke="black" />
                <path d="M 408,48 L 408,64" fill="none" stroke="black"/> stroke="black" />
                <path d="M 56,80 L 72,80" fill="none" stroke="black"/> stroke="black" />
                <path d="M 128,80 L 152,80" 144,80" fill="none" stroke="black"/> stroke="black" />
                <path d="M 192,80 184,80 L 216,80" 200,80" fill="none" stroke="black"/> stroke="black" />
                <path d="M 288,80 272,80 L 304,80" 288,80" fill="none" stroke="black"/> stroke="black" />
                <path d="M 376,80 360,80 L 392,80" 376,80" fill="none" stroke="black"/> stroke="black" />
                <path d="M 432,80 416,80 L 448,80" 432,80" fill="none" stroke="black"/> stroke="black" />
                <path d="M 504,80 488,80 L 528,80" 504,80" fill="none" stroke="black"/> stroke="black" />
                <path d="M 184,176 L 232,176" fill="none" stroke="black"/> stroke="black" />
                <path d="M 376,176 L 424,176" fill="none" stroke="black"/> stroke="black" />
                <polygon class="arrowhead" points="432,176 420,170.4 420,181.6" fill="black" transform="rotate(0,424,176)"/>
                  transform="rotate(0,424,176)" />
                <g class="text">
                  <text x="172" y="36">[RR11]</text>
                  <text x="412" y="36">[RR21]</text>
                  <text x="28" y="84">[CE31]</text>
                  <text x="100" y="84">[PE11]</text>
                  <text x="172" x="164" y="84">[P1]</text>
                  <text x="252" x="236" y="84">[ASBR11]</text>
                  <text x="340" x="324" y="84">[ASBR21]</text>
                  <text x="412" x="396" y="84">[P2]</text>
                  <text x="476" x="460" y="84">[PE21]</text>
                  <text x="556" x="532" y="84">[CE41]</text>
                  <text x="72" y="116">:</text>
                  <text x="296" x="280" y="116">:</text>
                  <text x="512" x="488" y="116">:</text>
                  <text x="32" y="132">AS3</text>
                  <text x="72" y="132">:</text>
                  <text x="200" x="184" y="132">..AS1..</text>
                  <text x="296" x="280" y="132">:</text>
                  <text x="376" x="360" y="132">..AS2..</text>
                  <text x="512" x="488" y="132">:</text>
                  <text x="560" x="536" y="132">AS4</text>
                  <text x="72" y="148">:</text>
                  <text x="296" x="280" y="148">:</text>
                  <text x="512" x="488" y="148">:</text>
                  <text x="52" y="180">203.0.113.31</text>
                  <text x="264" y="180">Traffic</text>
                  <text x="336" y="180">Direction</text>
                  <text x="572" x="508" y="180">203.0.113.41</text>
                </g>
              </svg>
</artwork><artwork
            </artwork>
            <artwork type="ascii-art"><![CDATA[
                  [RR11]                        [RR21]
                    |                             |
                    +                             +
[CE31]---[PE11]----[P1]----[ASBR11]---[ASBR21]---[P2]---[PE21]----[CE41]
[CE31]---[PE11]---[P1]---[ASBR11]---[ASBR21]---[P2]---[PE21]---[CE41]

        :                         :                         :
  AS3   :          ..AS1..        :      ..AS2..            :    AS4
        :                         :                         :

203.0.113.31          -------Traffic Direction------>    203.0.113.41
]]></artwork></artset></figure>
]]></artwork>
          </artset>
        </figure>

          <t>This example in <xref target="BGPCT_INTERAS_A"/> target="BGPCT_INTERAS_A" format="default"/> shows two
          provider network Autonomous systems AS1, AS2. They serve L3VPN
          customers AS3, AS4 respectively. The ASBRs ASBR11 and ASBR21 have IP
          VRFs connected directly. The inter-AS link is IP enabled with no
          MPLS forwarding.</t>
          <t>Traffic direction being described is CE31 to CE41. CE41 may
          request a specific SLA (e.g. (e.g., Gold for this traffic), when traversing
          these provider core networks.</t>
        </section>
        <section title="Transport Layer"> numbered="true" toc="default">
          <name>Transport Layer</name>
          <t>AS1 uses RSVP-TE intra-domain tunnels between PE11 and ASBR11.
          And LDP tunnels for best effort best-effort traffic. AS2 uses SRTE intra-domain
          tunnels between ASBR21 and PE21, and L-ISIS for best effort best-effort
          tunnels.</t>
          <t>The networks have two Transport classes: TCs: Gold with Transport
          Class TC ID 100,
          Bronze with Transport Class TC ID 200. These transport
          classes TCs
          are provisioned at the PEs and ASBRs. This creates the
          Resolution Schemes for these transport classes TCs at these PEs and
          ASBRs.</t>
          <t>Following tunnels exist for Gold transport class.<list> TC.</t>
          <ul spacing="normal">
            <li>
              <t>PE11_to_ASBR11_gold - RSVP-TE tunnel</t>
            </li>
            <li>
              <t>ASBR11_to_PE11_gold - RSVP-TE tunnel</t>
            </li>
            <li>
              <t>PE21_to_ASBR21_gold - SRTE tunnel</t>
            </li>
            <li>
              <t>ASBR21_to_PE21_gold - SRTE tunnel</t>
            </list></t>
            </li>
          </ul>
          <t>Following tunnels exist for Bronze transport class.<list> TC.</t>
          <ul spacing="normal">
            <li>
              <t>PE11_to_ASBR11_bronze - RSVP-TE tunnel</t>
            </li>
            <li>
              <t>ASBR11_to_PE11_bronze - RSVP-TE tunnel</t>
            </li>
            <li>
              <t>PE21_to_ASBR21_bronze - SRTE tunnel</t>
            </li>
            <li>
              <t>ASBR21_to_PE21_bronze - SRTE tunnel</t>
            </list></t>
            </li>
          </ul>
          <t>These tunnels are provisioned to belong to transport class TC 100 or
          200.</t>
        </section>
        <section title="Service numbered="true" toc="default">
          <name>Service Layer route exchange"> Route Exchange</name>
          <t>Service nodes PE11, ASBR11 negotiate service family (AFI/SAFI
          1/128) on the BGP session with RR11. Service helper RR11 reflects
          service routes between the PE11 and ASBR11 with next hop
          unchanged.</t>
          <t>Similarly, in AS2 PE21, ASBR21 negotiate service family (AFI/SAFI
          1/128) on the BGP session with RR21, which reflects service routes
          between the PE21 and ASBR21 with next hop unchanged.</t>
          <t>CE41 advertises a route for example prefix 203.0.113.41 with next
          hop self to PE21 VRF. CE41 can attach a Mapping Community
          Color:0:100
          color:0:100 on this route, to indicate its request for Gold SLA. Or,
          PE21 can attach the same using locally configured policies.</t>
          <t>Consider, CE41 is getting VPN service from PE21. The
          RD:203.0.113.41 route is readvertised in AFI/SAFI 1/128 by PE21 with
          next hop self (203.0.113.21) and label V-L1 to RR21 with the Mapping
          Community Color:0:100 color:0:100 attached. This AFI/SAFI 1/128 route reaches
          ASBR21 via RR21 with the next hop unchanged as PE21 and label V-L1.
          Now ASBR21 can resolve the PNH 203.0.113.21 using
          ASBR21_to_PE21_gold SRTE LSP.</t>
          <t>The IP FIB at ASBR21 VRF will have a route for 203.0.113.41 with
          a next hop resolved using Resolution Scheme associated with mapping
          community Color:0:100, color:0:100, pointing to ASBR21_to_PE21_gold tunnel.</t>
          <t>This route is readvertised with the next hop self set to itself by ASBR21 to ASBR11
          on a BGP session in the VRF. The single-hop EBGP session endpoints are
          interface addresses. ASBR21 and ASBR11 act like a CE to each other.
          The previously mentioned process repeats in AS1, AS1 until the route
          reaches PE11 and resolves over the PE11_to_ASBR11_gold RSVP TE
          tunnel.</t>
          <t>Traffic traverses as an unlabeled IP packet on the following legs:
          CE31-PE11, ASBR11-ASBR21, PE21-CE41. And it uses MPLS forwarding inside
          AS1, the
          AS1 and AS2 core.</t>
          <t>BGP CT AFI/SAFI 1/76 is not used in this Inter-AS Option inter-AS option B
          deployment. But the Transport class Class and Resolution Scheme constructs
          are used to preserve an end-to-end SLA.</t>
        </section>
      </section>
      <section title="Inter-AS option numbered="true" toc="default">
        <name>Inter-AS Option B usecase"> Use Case</name>
        <section title="Topology"> numbered="true" toc="default">
          <name>Topology</name>
                  <figure title="BGP CT Inter-AS option B" anchor="BGPCT_INTERAS_B"><artset><artwork  type="svg"><svg anchor="BGPCT_INTERAS_B">
          <artset>
            <artwork type="svg">
              <svg xmlns="http://www.w3.org/2000/svg" version="1.1" height="192" width="584" width="560"
                viewBox="0 0 584 560 192" class="diagram" text-anchor="middle" font-family="monospace"
                font-size="13px" stroke-linecap="round">
                <path d="M 168,48 L 168,64" fill="none" stroke="black"/> stroke="black" />
                <path d="M 408,48 L 408,64" fill="none" stroke="black"/> stroke="black" />
                <path d="M 56,80 L 72,80" fill="none" stroke="black"/> stroke="black" />
                <path d="M 128,80 L 152,80" 144,80" fill="none" stroke="black"/> stroke="black" />
                <path d="M 192,80 184,80 L 216,80" 200,80" fill="none" stroke="black"/> stroke="black" />
                <path d="M 288,80 272,80 L 304,80" 288,80" fill="none" stroke="black"/> stroke="black" />
                <path d="M 376,80 360,80 L 392,80" 376,80" fill="none" stroke="black"/> stroke="black" />
                <path d="M 432,80 416,80 L 448,80" 432,80" fill="none" stroke="black"/> stroke="black" />
                <path d="M 504,80 488,80 L 528,80" 504,80" fill="none" stroke="black"/> stroke="black" />
                <path d="M 184,176 L 208,176" fill="none" stroke="black"/> stroke="black" />
                <path d="M 368,176 L 400,176" fill="none" stroke="black"/> stroke="black" />
                <polygon class="arrowhead" points="408,176 396,170.4 396,181.6" fill="black" transform="rotate(0,400,176)"/>
                  transform="rotate(0,400,176)" />
                <g class="text">
                  <text x="172" y="36">[RR13]</text>
                  <text x="412" y="36">[RR23]</text>
                  <text x="28" y="84">[CE31]</text>
                  <text x="100" y="84">[PE11]</text>
                  <text x="172" x="164" y="84">[P1]</text>
                  <text x="252" x="236" y="84">[ASBR12]</text>
                  <text x="340" x="324" y="84">[ASBR21]</text>
                  <text x="412" x="396" y="84">[P2]</text>
                  <text x="476" x="460" y="84">[PE22]</text>
                  <text x="556" x="532" y="84">[CE41]</text>
                  <text x="72" y="116">:</text>
                  <text x="296" x="280" y="116">:</text>
                  <text x="512" x="472" y="116">:</text>
                  <text x="32" y="132">AS3</text>
                  <text x="72" y="132">:</text>
                  <text x="200" x="184" y="132">..AS1..</text>
                  <text x="296" x="280" y="132">:</text>
                  <text x="376" x="360" y="132">..AS2..</text>
                  <text x="512" x="472" y="132">:</text>
                  <text x="560" x="520" y="132">AS4</text>
                  <text x="72" y="148">:</text>
                  <text x="296" x="280" y="148">:</text>
                  <text x="512" x="472" y="148">:</text>
                  <text x="52" y="180">203.0.113.31</text>
                  <text x="248" y="180">Traffic</text>
                  <text x="320" y="180">Direction</text>
                  <text x="524" x="508" y="180">203.0.113.41</text>
                </g>
              </svg>
</artwork><artwork
            </artwork>
            <artwork type="ascii-art"><![CDATA[
                  [RR13]                        [RR23]
                    |                             |
                    +                             +
[CE31]---[PE11]----[P1]----[ASBR12]---[ASBR21]---[P2]---[PE22]----[CE41]
[CE31]---[PE11]---[P1]---[ASBR12]---[ASBR21]---[P2]---[PE22]---[CE41]

        :                         :                       :
  AS3   :          ..AS1..        :      ..AS2..          :    AS4
        :                         :                       :

203.0.113.31          ---- Traffic Direction ---->       203.0.113.41
]]></artwork></artset></figure>

          <t>This example in <xref target="BGPCT_INTERAS_B"/>
]]></artwork>
          </artset>
        </figure>

          <t><xref target="BGPCT_INTERAS_B" format="default"/> shows two
          provider network Autonomous systems Systems: AS1 and AS2. They serve L3VPN
          customers AS3 and AS4 AS4, respectively. The ASBRs ASBR12 and ASBR21
          don't have any IP VRFs. The inter-AS link is MPLS forwarding MPLS-forwarding
          enabled.</t>
          <t>Traffic direction being described is CE31 to CE41. CE41 may
          request a specific SLA (e.g. (e.g., Gold for this traffic), traffic) when traversing
          these provider core networks.</t>
        </section>
        <section title="Transport Layer"> numbered="true" toc="default">
          <name>Transport Layer</name>
          <t>AS1 uses RSVP-TE intra-domain tunnels between PE11 and ASBR21.
          And ASBR21
          and LDP tunnels for best effort best-effort traffic. AS2 uses SRTE intra-domain
          tunnels between ASBR21 and PE22, and PE22 along with L-ISIS for best effort best-effort
          tunnels.</t>
          <t>The networks have two Transport classes: TCs: Gold with Transport
          Class TC ID 100, 100
          and Bronze with Transport Class TC ID 200. These transport
          classes TCs
          are provisioned at the PEs and ASBRs. This creates the
          Resolution Schemes for these transport classes Transport Classes at these PEs and
          ASBRs.</t>

          <t>Following
          <t>The following tunnels exist for Gold transport class.<list> TC:</t>
          <ul spacing="normal">
            <li>
              <t>PE11_to_ASBR12_gold - RSVP-TE tunnel</t>
            </li>
            <li>
              <t>ASBR12_to_PE11_gold - RSVP-TE tunnel</t>
            </li>
            <li>
              <t>PE22_to_ASBR21_gold - SRTE tunnel</t>
            </li>
            <li>
              <t>ASBR21_to_PE22_gold - SRTE tunnel</t>
            </list></t>

          <t>Following
            </li>
          </ul>
          <t>The following tunnels exist for Bronze transport class.<list> TC:</t>
          <ul spacing="normal">
            <li>
              <t>PE11_to_ASBR12_bronze - RSVP-TE tunnel</t>
            </li>
            <li>
              <t>ASBR12_to_PE11_bronze - RSVP-TE tunnel</t>
            </li>
            <li>
              <t>PE22_to_ASBR21_bronze - SRTE tunnel</t>
            </li>
            <li>
              <t>ASBR21_to_PE22_bronze - SRTE tunnel</t>
            </list></t>
            </li>
          </ul>
          <t>These tunnels are provisioned to belong to transport class TC 100 or
          200.</t>
        </section>
        <section title="Service numbered="true" toc="default">
          <name>Service Layer route exchange"> Route Exchange</name>
          <t>Service nodes PE11, PE11 and ASBR12 negotiate service family (AFI/SAFI
          1/128) on the BGP session with RR13. Service helper RR13 reflects
          service routes between the PE11 and ASBR12 with the next hop
          unchanged.</t>
          <t>Similarly, in AS2 PE22, ASBR21 negotiate negotiates service family (AFI/SAFI
          1/128) on the BGP session with RR23, which reflects service routes
          between the PE22 and ASBR21 with the next hop unchanged.</t>
          <t>ASBR21 and ASBR12 negotiate AFI/SAFI 1/128 between them, them and
          readvertise L3VPN routes with the next hop self, set to themselves, allocating new labels.
          The single-hop EBGP session endpoints are interface addresses.</t>
          <t>CE41 advertises a route route, for example example, prefix 203.0.113.41 with the next
          hop self set to itself to PE22 VRF. CE41 can attach a Mapping Community
          Color:0:100
          color:0:100 on this route, route to indicate its request for the Gold SLA. Or,
          PE22 can attach the same using locally configured policies.</t>

          <t>Consider,
          <t>Consider CE41 is getting VPN service from PE22. The
          RD:203.0.113.41 route is readvertised in AFI/SAFI 1/128 by PE22 with
          the next hop self set to itself (192.0.2.22) and label V-L1 to RR23 with the Mapping
          Community Color:0:100 color:0:100 attached. This AFI/SAFI 1/128 route reaches
          ASBR21 via RR23 with the next hop unchanged as PE22 and label V-L1.
          Now ASBR21 can resolve the PNH 192.0.2.22 using ASBR21_to_PE22_gold
          SRTE LSP.</t>
          <t>Next, ASBR21 readvertises the RD:203.0.113.41 route with the next hop
          self
          set to itself to ASBR12 with a newly allocated MPLS label V-L2. Forwarding
          for this label is installed to Swap V-L1, and Push labels for
          ASBR21_to_PE22_gold tunnel.</t>
          <t>ASBR12 further readvertises the RD:203.0.113.41 route via RR13 to
          PE11 with the next hop self set to itself, 192.0.2.12. PE11 resolves the next hop
          192.0.2.12 over PE11_to_ASBR12_gold RSVP TE tunnel.</t>
          <t>Traffic traverses as the IP packet on the following legs: CE31-PE11
          and PE21-CE41. And it uses MPLS forwarding on the ASBR11-ASBR21 link, link and
          inside the AS1-AS2 core.</t>
          <t>BGP CT AFI/SAFI 1/76 is not used in this Inter-AS Option inter-AS option B
          deployment. But the Transport class Class and Resolution Scheme constructs
          are used to preserve an end-to-end SLA.</t>
        </section>
      </section>
    </section>
    <section anchor="Appendix C" anchor="Appendix_C" numbered="true"
             title="Why toc="default">
      <name>Why reuse RFC RFCs 8277 and RFC 4364?">
      <t>RFC 4364 4364?</name>
      <t><xref target="RFC4364"/> is one of the key design patterns produced by the networking
      industry. It introduced virtualization and allowed sharing of resources
      in the service provider space with multiple tenant networks, providing
      isolated and secure Layer3 Layer 3 VPN services. This design pattern has been
      reused since to provide other service layer virtualizations like Layer2 Layer 2
      virtualization (VPLS, L2VPN, EVPN), ISO virtualization, ATM
      virtualization, and Flowspec VPN.</t>
      <t>It is to be noted that these services have different NLRI encoding. encodings.
      The L3VPN Service service family that binds the MPLS label to an IP prefix use RFC 8277
      encoding, uses the encoding described in  <xref target="RFC8277"/>
      and others define different NLRI encodings.</t>
      <t>BGP CT reuses RFC 4364 the procedures described in <xref target="RFC4364"/> to slice a transport network into
      multiple transport planes that different service routes can bind to, to
      using color.</t>
      <t>BGP CT reuses RFC 8277 <xref target="RFC8277"/> because it precisely fits the purpose. viz. In
      a  That is, in
      an MPLS network, BGP CT needs to bind the MPLS label for transport endpoints endpoints,
      which are IPv4 or IPv6 endpoints, and disambiguate between multiple
      instances of those endpoints in multiple transport planes. Hence, use of the
      RD:IP_Prefix and carrying a Label for it as specified in RFC 8277 <xref target="RFC8277"/> works
      well for this purpose.</t>
      <t>Another advantage of using the precise encoding as defined in RFC
      4364 <xref
      target="RFC4364"/> and RFC 8277 <xref target="RFC8277"/> is that it allows to interoperate
      interoperation with BGP speakers that support SAFI 128 for AFIs 1 or
      2. This can be useful during
      transition, transition until all BGP speakers in the
      network support BGP CT.</t>
      <t>In the future, if RFC 8277 <xref target="RFC8277"/> evolves into a typed NLRI, NLRI that does not carry
      Label in the NLRI, BGP CT will be compatible with that as-well. as well. In
      essence, BGP CT encoding is compatible with existing deployed
      technologies (RFC 4364, RFC 8277) (<xref target="RFC4364"/> and <xref target="RFC8277"/>) and will adapt to any changes RFC 8277 mechanisms from <xref target="RFC8277"/>
      undergo in future.</t>
      <t>This approach leverages the benefits of time tested time-tested design patterns
      proposed in RFC 4364 <xref target="RFC4364"/> and RFC 8277. <xref target="RFC8277"/>. Moreover, this approach greatly
      reduces operational training costs and protocol compatibility
      considerations,
      considerations as it complements and works well with existing protocol
      machineries. This
      machinery: this problem does not need reinventing the wheel with a brand
      new NLRI and procedures.</t>
      <t>BGP CT design also avoids overloading RFC 8277 the NLRI MPLS Label label field from <xref target="RFC8277"/>
      with information related to non MPLS the non-MPLS data plane, plane because it leads to
      backward compatibility
      backward-compatibility issues.</t>
      <section numbered="true" title="Update packing considerations"> toc="default">
        <name>Update Packing Considerations</name>
        <t>BGP CT carries transport class Transport Class as an attribute. This means routes
        that don't share the same transport class Transport Class cannot be packed into the same
        Update
        BGP UPDATE message. Update packing in BGP CT will be similar to RFC 8277 family routes from <xref target="RFC8277"/>
        carrying attributes like communities or extended
        communities. Service families like AFI/SAFI 1/128 have considerably
        more scale than transport families like AFI/SAFI 1/4 or AFI/SAFI 1/76,
        which carry only loopbacks. Update packing mechanisms that scale for
        AFI/SAFI 1/128 routes will scale similarly for AFI/SAFI 1/76 routes
        also.</t>

        <t>Section 6.3.2.1 of <xref target="Intent-Routing-Color"/> routes.
        </t>
        <t><xref section="6.3.2.1" target="I-D.hr-spring-intentaware-routing-using-color" format="default"/> suggests
        scaling numbers for a transport network where BGP CT can be deployed.
        Experiments were conducted with this scale to find the convergence
        time with BGP CT for those scaling numbers. Scenarios involving BGP CT
        carrying IPv4 and IPv6 endpoints with an MPLS label were tested. Tests
        with BGP CT IPv6 endpoints and SRv6 SID are planned.</t>
        <t>Tests were conducted with a 1.9 million BGP CT route scale (387K
        endpoints in 5 transport classes). TCs). Initial convergence time for all
        cases was less than 2 minutes, which compares favorably with user
        expectation for such a scale. This experiment proves that carrying
        transport class
        Transport Class information as an attribute keeps BGP convergence
        within an acceptable range. Details of the experiment and test results
        are available in <xref target="BGP-CT-UPDATE-PACKING-TEST">BGP CT
        Update packing Test Results </xref>.</t> target="PACKING-TEST" format="default"></xref>.</t>
        <t>Furthermore, even in today's BGP LU deployments deployments, each egress node
        originates a BGP LU route for it's its loopback, with some attributes like
        community identifying the originating node or region, region and an AIGP
        attribute. These attributes may be unique per egress node, thus node; thus, they do not
        help with update packing in transport family routes.</t>
      </section>
    </section>
    <section anchor="Appendix D" anchor="Appendix_D" numbered="true"
             title="Scaling using toc="default">
      <name>Scaling Using BGP MPLS Namespaces"> Namespaces</name>
      <t>This document considers the scaling scenario suggested in Section 6.3.2.1
      of <xref target="Intent-Routing-Color"/> section="6.3.2.1" target="I-D.hr-spring-intentaware-routing-using-color" format="default"/> where 300K nodes exist in the
      network with 5 transport classes.</t> TCs.</t>
      <t>This may result in 1.5M transport layer routes and MPLS transit
      routes in all Border Nodes in the network, which may overwhelm the
      nodes' MPLS forwarding MPLS-forwarding resources.</t>

      <t>Section 6.2 of <xref target="MPLS-NS"/>
      <t><xref section="6.2" target="I-D.kaliraj-bess-bgp-mpls-namespaces" format="default"/> describes how MPLS Namespaces
      mechanism is used to scale such a network. This approach reduces the
      number of PNHs that are globally visible in the network, thus reducing
      forwarding resource usage network wide. Service route state is kept
      confined closer to network edge, and any churn is confined within the
      region containing the point of failure, which improves convergence
      also.</t>
    </section>

    <section anchor="Contributors" anchor="Acknowledgements" numbered="false" title="Contributors"> toc="default">
      <name>Acknowledgements</name>
      <t>The authors thank <contact fullname="Jeff Haas"/>, <contact
      fullname="John Scudder"/>, <contact fullname="Susan Hares"/>, <contact
      fullname="Dongjie (Jimmy)"/>, <contact fullname="Moses Nagarajah"/>,
      <contact fullname="Jeffrey (Zhaohui) Zhang"/>, <contact fullname="Joel
      Halpern"/>, <contact fullname="Jingrong Xie"/>, <contact
      fullname="Mohamed Boucadair"/>, <contact fullname="Greg Skinner"/>,
      <contact fullname="Simon Leinen"/>, <contact fullname="Navaneetha
      Krishnan"/>, <contact fullname="Ravi M R"/>, <contact
      fullname="Chandrasekar Ramachandran"/>, <contact fullname="Shradha
      Hegde"/>, <contact fullname="Colby Barth"/>, <contact fullname="Vishnu
      Pavan Beeram"/>, <contact fullname="Sunil Malali"/>, <contact
      fullname="William J Britto"/>, <contact fullname="R Shilpa"/>, <contact
      fullname="Ashish Kumar (FE)"/>, <contact fullname="Sunil Kumar Rawat"/>,
      <contact fullname="Abhishek Chakraborty"/>, <contact fullname="Richard
      Roberts"/>, <contact fullname="Krzysztof Szarkowicz"/>, <contact
      fullname="John E Drake"/>, <contact fullname="Srihari Sangli"/>,
      <contact fullname="Jim Uttaro"/>, <contact fullname="Luay Jalil"/>,
      <contact fullname="Keyur Patel"/>, <contact fullname="Ketan
      Talaulikar"/>, <contact fullname="Dhananjaya Rao"/>, <contact
      fullname="Swadesh Agarwal"/>, <contact fullname="Robert Raszuk"/>,
      <contact fullname="Ahmed Darwish"/>, <contact fullname="Aravind Srinivas
      Srinivasa Prabhakar"/>, <contact fullname="Moshiko Nayman"/>, <contact
      fullname="Chris Tripp"/>, <contact fullname="Gyan Mishra"/>, <contact
      fullname="Vijay Kestur"/>, and <contact fullname="Santosh Kolenchery"/>
      for all the valuable discussions, constructive criticisms, and review
      comments.</t>
      <t>The decision to not reuse SAFI 128 and create a new address family to
      carry these transport routes was based on suggestion made by <contact
      fullname="Richard Roberts"/> and <contact fullname="Krzysztof
      Szarkowicz"/>.</t>
      <t>Thanks to <contact fullname="John Scudder"/> for showing us with
      example how the Figures can be enhanced using SVG format.</t>
    </section>

 <section anchor="Co-Authors" anchor="Contributors" numbered="false" title="Co-Authors"> toc="default">
      <name>Contributors</name>

	<t>The following people contributed substantially to the content of this
   document and should be considered coauthors:</t>
        <author fullname="Reshma Das" initials="D." surname="Das">
          <organization>Juniper Networks, Inc.</organization>
          <address>
            <postal>
              <street>1133 Innovation Way,</street> Way</street>
              <city>Sunnyvale</city>
              <region>CA</region>
              <code>94089</code>

              <country>US</country>
              <country>United States of America</country>
            </postal>
            <email>dreshma@juniper.net</email>
          </address>
        </author>
        <author fullname="Israel Means" initials="I" surname="Means">
          <organization abbrev="">AT&amp;T</organization>
          <address>
            <postal>
              <street>2212 Avenida Mara,</street> Mara</street>
              <city>Chula Vista</city>
              <region>California</region>
              <code>91914</code>

              <country>USA</country>
              <country>United States of America</country>
            </postal>
            <email>israel.means@att.com</email>
          </address>
        </author>
        <author fullname="Csaba Mate" initials="CS" surname="Mate">
          <organization abbrev="">KIFU, Hungarian NREN</organization>
          <address>
            <postal>
              <street>35 Vaci street,</street> Street</street>
              <city>Budapest</city>
              <region/>
              <code>1134</code>
              <country>Hungary</country>
            </postal>
            <email>ietf@nop.hu</email>
          </address>
        </author>
        <author fullname="Deepak J Gowda" initials="J" surname="Gowda">
          <organization abbrev="">Extreme Networks</organization>
          <address>
            <postal>
              <street>55 Commerce Valley Drive West, Suite 300,</street> 300</street>
              <city>Thornhill, Toronto,</city> Toronto</city>
              <region>Ontario</region>
              <code>L3T 7V9</code>
              <country>Canada</country>
            </postal>
            <email>dgowda@extremenetworks.com</email>
          </address>
        </author>
      </section>

      <section anchor="Other Contributors" numbered="false"
               title="Other Contributors">
<t>We also acknowledge the contribution of the following individuals:</t>
        <author fullname="Balaji Rajagopalan" initials="B." surname="Rajagopalan">
          <organization>Juniper Networks, Inc.</organization>
          <address>
            <postal>
              <street>Electra, Exora Business Park~Marathahalli - Sarjapur
              Outer Ring Road,</street> Road</street>
              <city>Bangalore</city>
              <region>KA</region>
              <code>560103</code>
              <country>India</country>
            </postal>
            <email>balajir@juniper.net</email>
          </address>
        </author>
        <author fullname="Rajesh M" initials="M">
          <organization>Juniper Networks, Inc.</organization>
          <address>
            <postal>
              <street>Electra, Exora Business Park~Marathahalli - Sarjapur
              Outer Ring Road,</street> Road</street>
              <city>Bangalore</city>
              <region>KA</region>
              <code>560103</code>
              <country>India</country>
            </postal>
            <email>mrajesh@juniper.net</email>
          </address>
        </author>
        <author fullname="Chaitanya Yadlapalli" initials="C" surname="Yadlapalli">
          <organization abbrev="">AT&amp;T</organization>
          <address>
            <postal>
              <street>200 S Laurel Ave,</street>

              <city>Middletown,</city> Ave</street>
              <city>Middletown</city>
              <region>NJ</region>
              <code>07748</code>

              <country>USA</country>
              <country>United States of America</country>
            </postal>
            <email>cy098d@att.com</email>
          </address>
        </author>
        <author fullname="Mazen Khaddam" initials="M" surname="Khaddam">
          <organization abbrev="">Cox Communications Inc.</organization>
          <address>
            <postal>
              <street/>
              <city>Atlanta</city>
              <region>GA</region>
              <code/>

              <country>USA</country>
              <country>United States of America</country>
            </postal>
            <email>mazen.khaddam@cox.com</email>
          </address>
        </author>
        <author fullname="Rafal Jan Szarecki" initials="R" surname="Szarecki">
          <organization abbrev="">Google.</organization> abbrev="">Google</organization>
          <address>
            <postal>
              <street>1160 N Mathilda Ave, Bldg 5,</street>

              <city>Sunnyvale,</city> 5</street>
              <city>Sunnyvale</city>
              <region>CA</region>
              <code>94089</code>

              <country>USA</country>
              <country>United States of America</country>
            </postal>
            <email>szarecki@google.com</email>
          </address>
        </author>
        <author fullname="Xiaohu Xu" initials="X" surname="Xu">
          <organization abbrev="">China Mobile</organization>
          <address>
            <postal>
              <street/>
              <city>Beijing</city>
              <region/>
              <code/>
              <country>China</country>
            </postal>
            <email>xuxiaohu@cmss.chinamobile.com</email>
          </address>
        </author>
      </section>
    </section>

    <section anchor="Acknowledgements" numbered="false"
             title="Acknowledgements">
      <t>The authors thank Jeff Haas, John Scudder, Susan Hares, Dongjie
      (Jimmy), Moses Nagarajah, Jeffrey (Zhaohui) Zhang, Joel Halpern,
      Jingrong Xie, Mohamed Boucadair, Greg Skinner, Simon Leinen, Navaneetha
      Krishnan, Ravi M R, Chandrasekar Ramachandran, Shradha Hegde, Colby
      Barth, Vishnu Pavan Beeram, Sunil Malali, William J Britto, R Shilpa,
      Ashish Kumar (FE), Sunil Kumar Rawat, Abhishek Chakraborty, Richard
      Roberts, Krzysztof Szarkowicz, John E Drake, Srihari Sangli, Jim Uttaro,
      Luay Jalil, Keyur Patel, Ketan Talaulikar, Dhananjaya Rao, Swadesh
      Agarwal, Robert Raszuk, Ahmed Darwish, Aravind Srinivas Srinivasa
      Prabhakar, Moshiko Nayman, Chris Tripp, Gyan Mishra, Vijay Kestur,
      Santosh Kolenchery for all the valuable discussions, constructive
      criticisms, and review comments.</t>

      <t>The decision to not reuse SAFI 128 and create a new address-family to
      carry these transport-routes was based on suggestion made by Richard
      Roberts and Krzysztof Szarkowicz.</t>

      <t>Thanks to John Scudder for showing us with example how the Figures
      can be enhanced using SVG format.</t>
      </section>
  </back>
</rfc>