rfc9832xml2.original.xml   rfc9832.xml 
<?xml version="1.0" encoding="US-ASCII"?> <?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?> <!DOCTYPE rfc [
<?rfc tocompact="yes"?> <!ENTITY nbsp "&#160;">
<?rfc tocdepth="3"?> <!ENTITY zwsp "&#8203;">
<?rfc tocindent="yes"?> <!ENTITY nbhy "&#8209;">
<?rfc symrefs="yes"?> <!ENTITY wj "&#8288;">
<?rfc sortrefs="yes"?> ]>
<?rfc comments="yes"?>
<?rfc inline="yes"?> <rfc xmlns:xi="http://www.w3.org/2001/XInclude" category="exp" docName="draft-ie
<?rfc compact="yes"?> tf-idr-bgp-ct-39" number="9832" consensus="true" ipr="trust200902" obsoletes=""
<?rfc subcompact="no"?> updates="" submissionType="IETF" xml:lang="en" tocInclude="true" tocDepth="3" sy
<rfc category="exp" docName="draft-ietf-idr-bgp-ct-39" ipr="trust200902"> mRefs="true" sortRefs="true" version="3">
<front> <front>
<title abbrev="BGP Classful Transport Planes">BGP Classful Transport <title abbrev="BGP Classful Transport Planes">BGP Classful Transport
Planes</title> Planes</title>
<seriesInfo name="RFC" value="9832"/>
<author fullname="Kaliraj Vairavakkalai" initials="K." role="editor" <author fullname="Kaliraj Vairavakkalai" initials="K." role="editor" surname
surname="Vairavakkalai"> ="Vairavakkalai">
<organization>Juniper Networks, Inc.</organization> <organization>Juniper Networks, Inc.</organization>
<address> <address>
<postal> <postal>
<street>1133 Innovation Way,</street> <street>1133 Innovation Way</street>
<city>Sunnyvale</city> <city>Sunnyvale</city>
<region>CA</region> <region>CA</region>
<code>94089</code> <code>94089</code>
<country>United States of America</country>
<country>US</country>
</postal> </postal>
<email>kaliraj@juniper.net</email> <email>kaliraj@juniper.net</email>
</address> </address>
</author> </author>
<author fullname="Natrajan Venkataraman" initials="N." role="editor" surname
<author fullname="Natrajan Venkataraman" initials="N." role="editor" ="Venkataraman">
surname="Venkataraman">
<organization>Juniper Networks, Inc.</organization> <organization>Juniper Networks, Inc.</organization>
<address> <address>
<postal> <postal>
<street>1133 Innovation Way,</street> <street>1133 Innovation Way</street>
<city>Sunnyvale</city> <city>Sunnyvale</city>
<region>CA</region> <region>CA</region>
<code>94089</code> <code>94089</code>
<country>United States of America</country>
<country>US</country>
</postal> </postal>
<email>natv@juniper.net</email> <email>natv@juniper.net</email>
</address> </address>
</author> </author>
<date month="September" year="2025"/>
<date day="28" month="2" year="2025"/> <area>RTG</area>
<workgroup>idr</workgroup>
<keyword>BGP-CT, CT, Intent Based Routing, BGP Service Mapping</keyword>
<abstract> <abstract>
<t>This document specifies a mechanism referred to as "Intent Driven <t>This document specifies a mechanism referred to as "Intent Driven
Service Mapping". The mechanism uses BGP to express intent based Service Mapping". The mechanism uses BGP to express Intent based
association of overlay routes with underlay routes having specific association of overlay routes with underlay routes having specific
Traffic Engineering (TE) characteristics satisfying a certain Service Traffic Engineering (TE) characteristics satisfying a certain Service
Level Agreement (SLA). This is achieved by defining new constructs to Level Agreement (SLA). This is achieved by defining new constructs to
group underlay routes with sufficiently similar TE characteristics into group underlay routes with sufficiently similar TE characteristics into
identifiable classes (called "Transport Classes"), that overlay routes identifiable classes (called "Transport Classes" or "TCs"), that overlay r outes
use as an ordered set to resolve reachability (Resolution Schemes) use as an ordered set to resolve reachability (Resolution Schemes)
towards service endpoints. These constructs can be used, for example, to towards service endpoints. These constructs can be used, for example, to
realize the "IETF Network Slice" defined in TEAS Network Slices 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 <t>Additionally, this document specifies protocol procedures for BGP
that enable dissemination of service mapping information in a network that enable dissemination of service mapping information in a network
that may span multiple cooperating administrative domains. These domains that may span multiple cooperating administrative domains. These domains
may be administered either by the same provider or by closely may be administered either by the same provider or by closely
coordinating providers. A new BGP address family that leverages RFC 4364 coordinating providers. A new BGP address family that leverages the proced
("BGP/MPLS IP Virtual Private Networks (VPNs)") procedures and follows ures described in RFC 4364
RFC 8277 ("Using BGP to Bind MPLS Labels to Address Prefixes") NLRI ("BGP/MPLS IP Virtual Private Networks (VPNs)") and follows the NLRI encod
encoding is defined to enable each advertised underlay route to be ing described in
RFC 8277 ("Using BGP to Bind MPLS Labels to Address Prefixes") is defined
to enable each advertised underlay route to be
identified by its class. This new address family is called "BGP Classful 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> </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> </front>
<middle> <middle>
<section title="Introduction"> <section numbered="true" toc="default">
<name>Introduction</name>
<t>Provider networks typically span across multiple domains where each <t>Provider networks typically span across multiple domains where each
domain can either represent an Autonomous System (AS) or an Interior domain can either represent an Autonomous System (AS) or an Interior
Gateway Protocol (IGP) region within an AS. In these networks, several Gateway Protocol (IGP) region within an AS. In these networks, several
services are provisioned between different pairs of service endpoints services are provisioned between different pairs of service endpoints
(e.g., Provider Edge (PE) nodes), that can either be in the same domain (e.g., Provider Edge (PE) nodes) that can be either in the same domain
or across different domains.</t> or across different domains.</t>
<t><xref target="RFC9315" format="default"/> defines "Intent" as:</t>
<t><xref target="RFC9315"></xref> defines "Intent" as, "A set of operation <blockquote><t>A set of operational
al
goals (that a network should meet) and outcomes (that a network is suppose d goals (that a network should meet) and outcomes (that a network is suppose d
to deliver) defined in a declarative manner without specifying how to achi eve to deliver) defined in a declarative manner without specifying how to achi eve
or implement them.".</t> or implement them.</t></blockquote>
<t> This document prescribes constructs and procedures <t> This document prescribes constructs and procedures
to realize "Intent", and enable provider networks to be able to forward to realize "Intent" and enable provider networks to forward
service traffic based on service specific intent, end-to-end across servic service traffic based on service specific Intent from end-to-end across se
e rvice
endpoints.</t> endpoints.</t>
<t>The mechanisms described in this document achieve "Intent Driven <t>The mechanisms described in this document achieve "Intent Driven
Service Mapping" between any pair of service endpoints by:<list> Service Mapping" between any pair of service endpoints by:</t>
<t>Provisioning end-to-end "intent-aware" paths using BGP. For <ul spacing="normal">
example, low latency path, best effort path.</t> <li>
<t>Provisioning end-to-end "Intent aware" paths using BGP. For
<t>Expressing a desired intent. For example, use low latency path example, a low-latency path or a best-effort path.</t>
with fallback to the best effort path.</t> </li>
<li>
<t>Forwarding service traffic "only" using end-to-end "intent-aware" <t>Expressing a desired Intent. For example, use a low-latency path
paths honoring that desired intent.</t> with a fallback to the best-effort path.</t>
</list></t> </li>
<li>
<t>Forwarding service traffic "only" using end-to-end "Intent aware"
paths honoring that desired Intent.</t>
</li>
</ul>
<t>The constructs and procedures defined in this document apply equally <t>The constructs and procedures defined in this document apply equally
to intra-AS as well as inter-AS (a.k.a. multi-AS) Option A, Option B and to intra-AS and inter-AS (a.k.a. multi-AS) deployments in the style of opt
Option C (Section 10, <xref target="RFC4364"/>) style deployments in ion A, option B, and
option C (<xref target="RFC4364" sectionFormat="of" section="10"/>) in
provider networks.</t> provider networks.</t>
<t>Such networks provision intra-domain transport tunnels between a pair <t>Such networks provision intra-domain transport tunnels between a pair
of endpoints, typically a service node or a border node that service traff ic of endpoints, typically a service node or a border node that service traff ic
traverses through. These tunnels are signaled using various tunneling traverses through. These tunnels are signaled using various tunneling
protocols depending on the forwarding architecture used in the domain, protocols depending on the forwarding architecture used in the domain,
which can be Multiprotocol Label Switching (MPLS), Internet Protocol which can be Multiprotocol Label Switching (MPLS), Internet Protocol
version 4 (IPv4), or Internet Protocol version 6 (IPv6).</t> version 4 (IPv4), or Internet Protocol version 6 (IPv6).</t>
<t>The mechanisms defined in this document allow different tunneling <t>The mechanisms defined in this document allow different tunneling
technologies to become Transport Class aware. These can be applied technologies to become TC aware. These can be applied
homogeneously to intra-domain tunneling technologies used in existing homogeneously to intra-domain tunneling technologies used in existing
brownfield networks as well as new greenfield networks. For clarity, brownfield networks as well as new greenfield networks. For clarity,
only some tunneling technologies are detailed in this document. In some only some tunneling technologies are detailed in this document. In some
examples only MPLS Traffic Engineering (TE) examples are described. examples, only MPLS Traffic Engineering (TE) is described.
Other tunneling technologies have been described in detail in other Other tunneling technologies have been described in detail in other
documents and only an overview has been included in this document. For documents (and only an overview has been included in this document). For
example, the details for Segment Routing (SRv6) are provided in <xref example, the details for Segment Routing over IPv6 (SRv6) are provided in
target="BGP-CT-SRv6"/>, and an overview is provided in <xref <xref target="I-D.ietf-idr-bgp-ct-srv6" format="default"/> and an overview is pr
target="SRv6-Support"/>.</t> ovided in <xref target="SRv6-Support" format="default"/>.</t>
<t>Customers need to be able to express desired Intent to the network, <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 and the network needs to have constructs able to enact the customer's
intent. The network constructs defined in this document are used to Intent. The network constructs defined in this document are used to
classify and group these intra-domain tunnels based on various classify and group these intra-domain tunnels based on various
characteristics, like TE characteristics (e.g., low latency), into characteristics, like TE characteristics (e.g., low-latency), into
identifiable classes that can pass "intent-aware" traffic. These identifiable classes that can pass "Intent aware" traffic. These
constructs enable services to signal their intent to use one or more constructs enable services to signal their Intent to use one or more
identifiable classes, and mechanisms to selectively map traffic onto identifiable classes and mechanisms to selectively map traffic onto
"intent-aware" tunnels for these classes.</t> "Intent aware" tunnels for these classes.</t>
<t>This document introduces a new BGP address family called "BGP <t>This document introduces a new BGP address family called "BGP
Classful Transport", that extends/stitches intent-aware intra-domain Classful Transport (BGP CT)", which extends/stitches Intent aware intra-do
tunnels belonging to the same class across domain boundaries, to main
establish end-to-end intent-aware paths between service endpoints.</t> tunnels belonging to the same class across domain boundaries to
establish end-to-end Intent aware paths between service endpoints.</t>
<t><xref target="Intent-Routing-Color"/> describes various use cases and <t><xref target="I-D.hr-spring-intentaware-routing-using-color" format="de
fault"/> describes various use cases and
applications of the procedures described in this document.</t> applications of the procedures described in this document.</t>
<t><xref target="Appendix_C" format="default"/> provides an outline of the
<t><xref target="Appendix C"/> provides an outline of the design design
philosophy behind this specification. In particular, readers who are philosophy behind this specification. In particular, readers who are
already familiar with one or more BGP VPN technologies may want to already familiar with one or more BGP VPN technologies may want to
review this appendix before reading the main body of the review this appendix before reading the main body of the
specification.</t> specification.</t>
</section> </section>
<section 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 BGP CT or BGP LU
routes with NH self)</dd>
<dt>AFI:</dt><dd>Address Family Identifier</dd>
<dt>AS:</dt><dd>Autonomous System</dd>
<dt>ASBR:</dt><dd>Autonomous System Border Router</dd>
<dt>ASN:</dt><dd>Autonomous System Number</dd>
<dt>BGP VPN:</dt><dd>VPNs built using RD or RT; architecture described
in <xref target="RFC4364"/></dd>
<dt>BGP LU:</dt><dd>BGP Labeled Unicast family (AFI/SAFIs 1/4, 2/4)</dd>
<dt>BGP CT:</dt><dd>BGP Classful Transport family (AFI/SAFIs 1/76, 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)</dd>
<dt>DSCP:</dt><dd>Differentiated Services Code Point</dd>
<dt>EP:</dt><dd>Endpoint (of a tunnel, e.g., a loopback address in the ne
twork)</dd>
<dt>EPE:</dt><dd>Egress Peer Engineering</dd>
<dt>eSN:</dt><dd>Egress Service Node</dd>
<dt>FEC:</dt><dd>Forwarding Equivalence Class</dd>
<dt>FRR:</dt><dd>Fast Reroute (Preprogrammed NH leg in forwarding)</dd>
<dt>iSN:</dt><dd>Ingress Service Node</dd>
<dt>L-ISIS:</dt><dd>Labeled ISIS (see RFC 8667)</dd>
<dt>LSP:</dt><dd>Label Switched Path</dd>
<dt>MPLS:</dt><dd>Multiprotocol Label Switching</dd>
<dt>NH:</dt><dd>Next Hop</dd>
<dt>NLRI:</dt><dd>Network Layer Reachability Information</dd>
<dt>PE:</dt><dd>Provider Edge</dd>
<dt>PIC:</dt><dd>Prefix Independent Convergence</dd>
<dt>PNH:</dt><dd>Protocol Next Hop (address carried in a BGP UPDATE messa
ge)</dd>
<dt>RD:</dt><dd>Route Distinguisher</dd>
<dt>RD:EP:</dt><dd>Route Distinguisher and
Endpoint (in a BGP Prefix)</dd>
<dt>RSVP-TE:</dt><dd>Resource Reservation Protocol - Traffic Engineering<
/dd>
<dt>RT:</dt><dd>Route Target (as used in Route Target extended community)
</dd>
<dt>RTC:</dt><dd>Route Target Constraint <xref target="RFC4684"/></dd>
<dt>SAFI:</dt><dd>Subsequent Address Family Identifier</dd>
<dt>SID:</dt><dd>Segment Identifier</dd>
<dt>SLA:</dt><dd>Service Level Agreement</dd>
<dt>SN:</dt><dd>Service Node</dd>
<dt>SR:</dt><dd>Segment Routing</dd>
<dt>SRTE:</dt><dd>Segment Routing Traffic Engineering</dd>
<dt>TC:</dt><dd>Transport Class</dd>
<dt>TC ID:</dt><dd>Transport Class Identifier</dd>
<dt>TC-BE:</dt><dd>Transport Class - Best Effort</dd>
<dt>TE:</dt><dd>Traffic Engineering</dd>
<dt>TEA:</dt><dd>Tunnel Encapsulation Attribute (attribute code 23)</dd>
<dt>TRDB:</dt><dd>Transport Route Database</dd>
<dt>UHP:</dt><dd>Ultimate Hop Popping</dd>
<dt>VRF:</dt><dd>Virtual Routing and Forwarding (used with a table)</dd>
</dl>
</section>
<section numbered="true" toc="default">
<name>Definitions and Notations</name>
<section title="Terminology"> <dl spacing="normal" newline="true">
<t>ABR: Area Border Router (Readvertises BGP CT or BGP LU routes with
next hop self)</t>
<t>AFI: Address Family Identifier</t>
<t>AS: Autonomous System</t>
<t>ASBR: Autonomous System Border Router</t>
<t>ASN: Autonomous System Number</t>
<t>BGP VPN: VPNs built using RD, RT; architecture described in
RFC4364</t>
<t>BGP LU: BGP Labeled Unicast family (AFI/SAFIs 1/4, 2/4)</t>
<t>BGP CT: 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 Carrier VPN</t>
<t>DSCP: Differentiated Services Code Point</t>
<t>EP: Endpoint of a tunnel, e.g. a loopback address in the network</t>
<t>EPE: Egress Peer Engineering</t>
<t>eSN: Egress Service Node</t>
<t>FEC: Forwarding Equivalence Class</t>
<t>FRR: Fast ReRoute (Pre-programmed next hop leg in forwarding)</t>
<t>iSN: Ingress Service Node</t>
<t>L-ISIS: Labeled ISIS (RFC 8667)</t>
<t>LSP: Label Switched Path</t>
<t>MPLS: Multi Protocol Label Switching</t>
<t>NLRI: Network Layer Reachability Information</t>
<t>PE: Provider Edge</t>
<t>PIC: Prefix scale Independent Convergence</t>
<t>PNH: Protocol Next Hop address carried in a BGP Update message</t>
<t>RD: Route Distinguisher</t>
<t>RD:EP : BGP CT Prefix consisting of Route Distinguisher and
Endpoint</t>
<t>RSVP-TE: Resource Reservation Protocol - Traffic Engineering</t>
<t>RT: Route Target extended community</t>
<t>RTC: Route Target Constrain (RFC 4684)</t>
<t>SAFI: Subsequent Address Family Identifier</t>
<t>SID: Segment Identifier</t>
<t>SLA: Service Level Agreement</t>
<t>SN: Service Node</t>
<t>SR: Segment Routing</t>
<t>SRTE: Segment Routing Traffic Engineering</t>
<t>TC: Transport Class</t>
<t>TC ID: Transport Class Identifier</t>
<t>TC-BE: Best Effort Transport Class</t>
<t>TE: Traffic Engineering</t>
<t>TEA: Tunnel Encapsulation Attribute, attribute type code 23</t>
<t>TRDB: Transport Route Database</t>
<t>UHP: Ultimate Hop Pop</t>
<t>VRF: Virtual Routing and Forwarding table</t>
<section title="Definitions and Notations">
<t>BGP Community Carrying Attribute (CCA) : A BGP attribute that
carries community. Examples of BGP CCA are: COMMUNITIES (attribute
code 8), EXTENDED COMMUNITIES (attribute code 16), IPv6 Address
Specific Extended Community (attribute code 25), LARGE_COMMUNITY
(attribute code 32).</t>
<t>color:0:100 : This notation denotes a Color extended community as
defined in RFC 9012 with the Flags field set to 0 and the color field
set to 100.</t>
<t>End to End Tunnel: 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 processing of an overlay route,
including things like import policy application, resolution scheme
selection and next hop resolution.</t>
<t>Mapping Community: 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 Infrastructure address space in
Provider network managed by the Operator.</t>
<t>Resolution Scheme: A construct comprising of an ordered set of
TRDBs to resolve next hop reachability, for realizing a desired
intent.</t>
<t>Service Family: 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 in "data traffic". Routes to these
prefixes are carried in a Service family.</t>
<t>Transport Family: A BGP address family used for advertising
tunnels, which are in turn used by service routes for resolution. For
example, AFI/SAFIs 1/4 or 1/76.</t>
<t>Transport Tunnel : 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 layer in the network that contains
Transport Tunnels and Transport Families.</t>
<t>Tunnel Route: A Route to Tunnel Destination/Endpoint that is
installed at the headend (ingress) of the tunnel.</t>
<t>Tunnel Domain: A domain of the network containing Service Nodes
(SNs) and Border Nodes (BNs) under a single administrative control
that has tunnels between them.</t>
<t>Brownfield network: 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, and
should consider continuity of service.</t>
<t>Greenfield network: A new network deployment which can make choice
of new technology or hardware as needed, with fewer constraints than
brownfield network.</t>
<t>Transport Class: A construct to group transport tunnels offering
similar SLA (Ref: Sec 4.1).</t>
<t>Transport Class RT: A Route Target Extended Community used to
identify a specific Transport Class.</t>
<t>transport-target:0:100 : This notation denotes a Transport Class RT <dt>BGP CCA:</dt><dd>A BGP attribute
extended community as defined in this document with the "Transport that carries community. Examples of BGP CCAs are COMMUNITIES
Class ID" field set to 100.</t> (attribute code 8), EXTENDED COMMUNITIES (attribute code 16), IPv6
Address Specific Extended Community (attribute code 25), and
LARGE_COMMUNITY (attribute code 32).</dd>
<t>Transport Route Database: At the SN and BN, a Transport Class has <dt>color:0:100 or col-100:</dt><dd>This notation denotes a Color exte
an associated Transport Route Database that collects its Tunnel nded
Routes.</t> community as defined in <xref target="RFC9012"/> with the "Flags" fiel
d set to 0 and
the "Color Value" field set to 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.</dd>
<dt>Import processing:</dt><dd>Receive-side processing of an overlay
route, including things like import-policy application, Resolution Sch
eme selection, and NH resolution.</dd>
<t>Transport Plane: An end-to-end plane consisting of transport <dt>Mapping Community:</dt><dd>Any BGP CCA (e.g., Community,
tunnels belonging to the same Transport Class.</t> Extended Community) on an overlay route that maps to a Resolution
Scheme. For example, color:0:100, transport-target:0:100.</dd>
<dt>Provider Namespace:</dt><dd>Internal Infrastructure address
space in a provider network managed by the operator.</dd>
<dt>Resolution Scheme:</dt><dd>A construct comprising of an ordered
set of TRDBs to resolve NH reachability for realizing a
desired 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.</dd>
<dt>Service Prefix:</dt><dd>A destination in "data traffic". Routes
to these prefixes are carried in a Service Family.</dd>
<dt>Transport Family:</dt><dd>A BGP address family used for
advertising tunnels, which are, in turn, used by service routes for
resolution. For example, AFI/SAFIs 1/4 or 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 Flexible Algorithm (Flex-Algo), or SRTE.</dd>
<dt>Transport Layer:</dt><dd>A layer in the network that
contains Transport Tunnels and Transport Families.</dd>
<dt>Tunnel Route:</dt><dd>A Route to Tunnel Destination/Endpoint
that is installed at the headend (ingress) of the tunnel.</dd>
<dt>Tunnel Domain:</dt><dd>A domain of the network containing
SNs and BNs under a single
administrative control that has tunnels between 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 and should consider continuity of
service.</dd>
<dt>Greenfield network:</dt><dd>A new network deployment that can
make choices of new technology or hardware as needed with fewer
constraints than brownfield network.</dd>
<dt>Transport Class:</dt><dd>A construct to group transport tunnels
offering similar SLAs (see <xref target="tc-te"/>).</dd>
<dt>Transport Class RT:</dt><dd>A Route Target extended community
used to identify a specific Transport Class.</dd>
<dt>transport-target:0:100:</dt><dd>This notation denotes a
Transport Class RT as defined in this document
with the "Transport Class ID" field set to 100.</dd>
<dt>Transport Route Database:</dt><dd>At the SN and BN, a Transport
Class has an associated TRDB that collects its
tunnel routes.</dd>
<dt>Transport Plane:</dt><dd>An end-to-end plane consisting of
transport tunnels belonging to the same Transport Class.</dd>
</dl>
</section> </section>
</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 title="Architecture Overview"> </section>
<section numbered="true" toc="default">
<name>Architecture Overview</name>
<t>This section describes the BGP CT architecture with a brief <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><a rtwork type="svg"><svg xmlns="http://www.w3.org/2000/svg" version="1.1" height= "496" width="560" viewBox="0 0 560 496" class="diagram" text-anchor="middle" fon t-family="monospace" font-size="13px" stroke-linecap="round"> <figure title="BGP CT Overview with Example Topology" anchor="ArchOv"><artset><a rtwork type="svg"><svg xmlns="http://www.w3.org/2000/svg" version="1.1" height= "496" width="536" viewBox="0 0 536 496" class="diagram" text-anchor="middle" fon t-family="monospace" font-size="13px" stroke-linecap="round">
<path d="M 24,240 L 24,320" fill="none" stroke="black"/> <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 424,64 L 424,96" fill="none" stroke="black"/>
<path d="M 472,240 L 472,320" 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 240,32 L 344,32" fill="none" stroke="black"/>
<path d="M 360,32 L 384,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 104,64 L 176,64" fill="none" stroke="black"/>
<path d="M 328,64 L 376,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 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 2 56,114" fill="none" stroke="black"/> <path d="M 240,110 L 256,110" fill="none" stroke="black"/><path d="M 240,114 L 2 56,114" fill="none" stroke="black"/>
<path d="M 312,112 L 328,112" fill="none" stroke="black"/> <path d="M 312,112 L 328,112" fill="none" stroke="black"/>
skipping to change at line 410 skipping to change at line 344
<polygon class="arrowhead" points="56,288 44,282.4 44,293.6" fill="black" transf orm="rotate(180,48,288)"/> <polygon class="arrowhead" points="56,288 44,282.4 44,293.6" fill="black" transf orm="rotate(180,48,288)"/>
<polygon class="arrowhead" points="56,240 44,234.4 44,245.6" fill="black" transf orm="rotate(180,48,240)"/> <polygon class="arrowhead" points="56,240 44,234.4 44,245.6" fill="black" transf orm="rotate(180,48,240)"/>
<g class="text"> <g class="text">
<text x="132" y="36">INET</text> <text x="132" y="36">INET</text>
<text x="212" y="36">[RR21]</text> <text x="212" y="36">[RR21]</text>
<text x="352" y="36">&lt;</text> <text x="352" y="36">&lt;</text>
<text x="412" y="36">[RR11]</text> <text x="412" y="36">[RR11]</text>
<text x="144" y="52">Service</text> <text x="144" y="52">Service</text>
<text x="192" y="52">/</text> <text x="192" y="52">/</text>
<text x="424" y="52">|</text> <text x="424" y="52">|</text>
<text x="496" y="52">IP1,color:0:100</text> <text x="480" y="52">IP1,col-100</text>
<text x="60" y="68">[PE21]</text> <text x="60" y="68">[PE21]</text>
<text x="96" y="68">&lt;</text> <text x="96" y="68">&lt;</text>
<text x="248" y="68">:</text> <text x="248" y="68">:</text>
<text x="284" y="68">[SN11]</text> <text x="284" y="68">[SN11]</text>
<text x="320" y="68">&lt;</text> <text x="320" y="68">&lt;</text>
<text x="496" y="68">IP2,color:0:200</text> <text x="480" y="68">IP2,col-200</text>
<text x="248" y="84">:</text> <text x="248" y="84">:</text>
<text x="480" y="84">IP3,100:200</text> <text x="480" y="84">IP3,100:200</text>
<text x="116" y="100">_(</text> <text x="116" y="100">_(</text>
<text x="148" y="100">.)</text> <text x="148" y="100">.)</text>
<text x="248" y="100">:</text> <text x="248" y="100">:</text>
<text x="356" y="100">_(</text> <text x="356" y="100">_(</text>
<text x="388" y="100">.)</text> <text x="388" y="100">.)</text>
<text x="512" y="100">^^^^^^^^^^^</text> <text x="496" y="100">^^^^^^^</text>
<text x="104" y="116">(</text> <text x="104" y="116">(</text>
<text x="156" y="116">_)</text> <text x="156" y="116">_)</text>
<text x="204" y="116">--[BN21]</text> <text x="204" y="116">--[BN21]</text>
<text x="284" y="116">[BN11]</text> <text x="284" y="116">[BN11]</text>
<text x="344" y="116">(</text> <text x="344" y="116">(</text>
<text x="424" y="116">_)-[PE11]</text> <text x="424" y="116">_)-[PE11]</text>
<text x="504" y="116">Mapping</text> <text x="496" y="116">Mapping</text>
<text x="116" y="132">(.</text> <text x="116" y="132">(.</text>
<text x="144" y="132">)</text> <text x="144" y="132">)</text>
<text x="248" y="132">:</text> <text x="248" y="132">:</text>
<text x="356" y="132">(.</text> <text x="356" y="132">(.</text>
<text x="384" y="132">)</text> <text x="384" y="132">)</text>
<text x="504" y="132">Community</text> <text x="496" y="132">Community</text>
<text x="248" y="148">Inter-AS-Link</text> <text x="248" y="148">Inter-AS-Link</text>
<text x="248" y="164">:</text> <text x="248" y="164">:</text>
<text x="248" y="180">[.......AS2:SR-TE........]:[.......AS1:RSVP-TE......]</tex t> <text x="248" y="180">[.......AS2:SR-TE........]:[.......AS1:RSVP-TE......]</tex t>
<text x="200" y="196">Traffic</text> <text x="200" y="196">Traffic</text>
<text x="272" y="196">Direction</text> <text x="272" y="196">Direction</text>
<text x="96" y="228">[PE21]--&lt;</text> <text x="96" y="228">[PE21]--&lt;</text>
<text x="180" y="228">[BN21]</text> <text x="180" y="228">[BN21]</text>
<text x="320" y="228">[BN21]--&lt;</text> <text x="320" y="228">[BN21]--&lt;</text>
<text x="404" y="228">[BN11]</text> <text x="404" y="228">[BN11]</text>
<text x="40" y="244">&lt;</text> <text x="40" y="244">&lt;</text>
<text x="152" y="244">RD1:PE11(L3),PNH=BN21</text> <text x="152" y="244">RD1:PE11(L3),PNH=BN21</text>
<text x="248" y="244">:</text> <text x="248" y="244">:</text>
<text x="264" y="244">&lt;</text> <text x="264" y="244">&lt;</text>
<text x="376" y="244">RD1:PE11(L1),PNH=BN11</text> <text x="376" y="244">RD1:PE11(L1),PNH=BN11</text>
<text x="140" y="260">transport-target:0:100</text> <text x="140" y="260">transport-target:0:100</text>
<text x="248" y="260">:</text> <text x="248" y="260">:</text>
<text x="364" y="260">transport-target:0:100</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="248" y="276">:</text>
<text x="516" y="276">Classful</text> <text x="496" y="276">BGP</text>
<text x="524" y="276">CT</text>
<text x="40" y="292">&lt;</text> <text x="40" y="292">&lt;</text>
<text x="152" y="292">RD2:PE11(L4),PNH=BN21</text> <text x="152" y="292">RD2:PE11(L4),PNH=BN21</text>
<text x="248" y="292">:</text> <text x="248" y="292">:</text>
<text x="264" y="292">&lt;</text> <text x="264" y="292">&lt;</text>
<text x="376" y="292">RD2:PE11(L2),PNH=BN11</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="140" y="308">transport-target:0:200</text>
<text x="248" y="308">:</text> <text x="248" y="308">:</text>
<text x="364" y="308">transport-target:0:200</text> <text x="364" y="308">transport-target:0:200</text>
<text x="140" y="324">^^^^^^^^^^^^^^^^^^^^^^</text> <text x="140" y="324">^^^^^^^^^^^^^^^^^^^^^^</text>
<text x="440" y="324">^^^</text> <text x="440" y="324">^^^</text>
<text x="112" y="340">Route</text> <text x="112" y="340">Route</text>
<text x="164" y="340">Target</text> <text x="164" y="340">Target</text>
<text x="200" y="340">&amp;</text> <text x="200" y="340">&amp;</text>
<text x="336" y="340">Transport</text> <text x="336" y="340">Transport</text>
<text x="400" y="340">Class</text> <text x="400" y="340">Class</text>
skipping to change at line 508 skipping to change at line 441
<text x="120" y="484">Schemes</text> <text x="120" y="484">Schemes</text>
<text x="208" y="484">Transport</text> <text x="208" y="484">Transport</text>
<text x="272" y="484">Route</text> <text x="272" y="484">Route</text>
<text x="308" y="484">DB</text> <text x="308" y="484">DB</text>
<text x="384" y="484">Transport</text> <text x="384" y="484">Transport</text>
<text x="448" y="484">Class</text> <text x="448" y="484">Class</text>
</g> </g>
</svg> </svg>
</artwork><artwork type="ascii-art"><![CDATA[ </artwork><artwork type="ascii-art"><![CDATA[
INET [RR21]--------------<<---[RR11] INET [RR21]--------------<<---[RR11]
Service / / | IP1,color:0:100 Service / / | IP1,col-100
[PE21] <<--------+ : [SN11] <<-----+ ^ IP2,color:0:200 [PE21] <<--------+ : [SN11] <<-----+ ^ IP2,col-200
\ ___ : \ ___ | IP3,100:200 \ ___ : \ ___ | IP3,100:200
\ _( .) : \ _( .) | ^^^^^^^^^^^ \ _( .) : \ _( .) | ^^^^^^^
+-- ( _) --[BN21]===[BN11]--- ( _)-[PE11] Mapping +-- ( _) --[BN21]===[BN11]--- ( _)-[PE11] Mapping
(.__) : (.__) Community (.__) : (.__) Community
Inter-AS-Link Inter-AS-Link
: :
[.......AS2:SR-TE........]:[.......AS1:RSVP-TE......] [.......AS2:SR-TE........]:[.......AS1:RSVP-TE......]
---------Traffic Direction-----------> ---------Traffic Direction----------->
.-- [PE21]--<<--[BN21] [BN21]--<<--[BN11] --. .-- [PE21]--<<--[BN21] [BN21]--<<--[BN11] --.
| <<--RD1:PE11(L3),PNH=BN21 : <<--RD1:PE11(L1),PNH=BN11 | | <<--RD1:PE11(L3),PNH=BN21 : <<--RD1:PE11(L1),PNH=BN11 |
| transport-target:0:100 : transport-target:0:100 | BGP | transport-target:0:100 : transport-target:0:100 |
| : | Classful | : | BGP CT
| <<--RD2:PE11(L4),PNH=BN21 : <<--RD2:PE11(L2),PNH=BN11 | Transport | <<--RD2:PE11(L4),PNH=BN21 : <<--RD2:PE11(L2),PNH=BN11 |
| transport-target:0:200 : transport-target:0:200 | | transport-target:0:200 : transport-target:0:200 |
| ^^^^^^^^^^^^^^^^^^^^^^ ^^^ | | ^^^^^^^^^^^^^^^^^^^^^^ ^^^ |
'-- Route Target & Transport Class ID--' '-- Route Target & Transport Class ID--'
Mapping Community Mapping Community
Intents at SN11 and PE21: Intents at SN11 and PE21:
Scheme1: color:0:100, (TRDB[TC-100], TRDB[TC-BE]) Scheme1: color:0:100, (TRDB[TC-100], TRDB[TC-BE])
Scheme2: color:0:200, (TRDB[TC-200], TRDB[TC-BE]) Scheme2: color:0:200, (TRDB[TC-200], TRDB[TC-BE])
Scheme3: 100:200, (TRDB[TC-100], TRDB[TC-200]) Scheme3: 100:200, (TRDB[TC-100], TRDB[TC-200])
^^^^^^^ ^^^^ ^^^^^^ ^^^^^^^ ^^^^ ^^^^^^
Resolution Schemes Transport Route DB Transport Class Resolution Schemes Transport Route DB Transport Class
]]></artwork></artset></figure> ]]></artwork></artset></figure>
<t>To achieve end-to-end "Intent Driven Service Mapping", this document <t>To achieve end-to-end "Intent Driven Service Mapping", this document
defines the following constructs and BGP extensions:<list> defines the following constructs and BGP extensions:</t>
<t>The <xref target="tc">"Transport Class"</xref> construct to group <ul spacing="normal">
<li>
<t>The "Transport Class" construct (see <xref target="tc" format="defa
ult"></xref>) to group
underlay tunnels.</t> underlay tunnels.</t>
</li>
<t>The <xref target="Nexthop_Resoln_Schm">"Resolution Scheme"</xref> <li>
construct for overlay routes with Mapping Community to resolve next <t>The "Resolution Scheme" construct (see <xref target="Nexthop_Resoln
hop reachability from either one or an ordered set of Transport _Schm" format="default"></xref>)
for overlay routes with Mapping Communities to resolve NH reachability
from either one or an ordered set of Transport
Classes.</t> Classes.</t>
</li>
<t>The <xref target="ct-family">"BGP Classful Transport"</xref> <li>
<t>The "BGP Classful Transport" (see <xref target="ct-family" format="
default"></xref>)
address family to extend these constructs to adjacent domains.</t> address family to extend these constructs to adjacent domains.</t>
</list><xref target="ArchOv"/> depicts the intra-AS and inter-AS </li>
</ul>
<t><xref target="ArchOv" format="default"/> depicts the intra-AS and inter
-AS
application of these constructs. Interactions between SN1 and PE11 describ e application of these constructs. Interactions between SN1 and PE11 describ e
the Intra-AS usage. Interactions between PE21 and PE11 describe the Inter- the intra-AS usage. Interactions between PE21 and PE11 describe the inter-
AS usage.</t> AS usage.</t>
<t> The example topology is an inter-AS
<t> The example topology is an Inter-AS option C network (<xref target="RFC4364" sectionFormat="of" section="10"/>
option C (Section 10, <xref target="RFC4364"/>) network with two AS domain ) with two AS domains;
s, each domain contains tunnels serving two Intents, e.g., 'low-latency' deno
each domain contains tunnels serving two Intents, e.g. 'low-latency' denot ted
ed by color 100 and 'high-bandwidth' denoted by color 200. AS1 is an RSVP-TE
by color 100 and 'high-bandwidth' denoted by color 200. AS1 is a RSVP-TE network; AS2 is an SRTE network. BGP CT and BGP LU are transport families
network, AS2 is a SRTE network. BGP CT and BGP LU are transport families used between the two AS domains. IP1, IP2, and IP3 are service prefixes
used between the two AS domains. IP1, IP2, IP3 are service prefixes
(AFI/SAFI: 1/1) behind egress PE11.</t> (AFI/SAFI: 1/1) behind egress PE11.</t>
<t>PE21, SN11, and PE11 are the SNs in this network. SN11 is an ingress
<t>PE21, SN11 and PE11 are the SNs in this network. SN11 is an ingress PE with intra-domain reachability to PE11. PE21 is an ingress PE with
PE with intra domain reachability to PE11. PE21 is an ingress PE with inter-domain reachability to PE11.</t>
inter domain reachability to PE11.</t>
<t>The tunneling mechanisms are made "Transport Class" aware. They <t>The tunneling mechanisms are made "Transport Class" aware. They
publish their underlay tunnels for a Transport Class into an associated publish their underlay tunnels for a Transport Class into an associated TR
<xref target="trdb">"Transport Route Database" (TRDB)</xref>. In <xref DB
target="ArchOv"/>, RSVP-TE publishes its underlay tunnels into TRDBs (see <xref target="trdb" format="default"></xref>). In <xref target="ArchO
created for Transport Class 100 and 200 at BN11 and SN11 within AS1; v" format="default"/>, RSVP-TE publishes its underlay tunnels into TRDBs
created for Transport Classes 100 and 200 at BN11 and SN11 within AS1;
Similarly, SR-TE publishes its underlay tunnels into TRDBs created for Similarly, SR-TE publishes its underlay tunnels into TRDBs created for
Transport Class 100 and 200 at PE21 within AS2.</t> Transport Classes 100 and 200 at PE21 within AS2.</t>
<t>Resolution Schemes are used to realize Intent. A Resolution Scheme is <t>Resolution Schemes are used to realize Intent. A Resolution Scheme is
identified by its "Mapping Community", and contains an ordered list of identified by its "Mapping Community" and contains an ordered list of
transport classes. Overlay routes carry an indication of the desired Transport Classes. Overlay routes carry an indication of the desired
Intent using a BGP community which assumes the role of "Mapping Community" Intent using a BGP community, which assumes the role of "Mapping Community
.</t> ".</t>
<t>Egress SN "PE11" advertises service routes with desired Mapping Commun
<t>Egress SN "PE11" advertises service routes with desired Mapping Commun ity, e.g., color:0:100.</t>
ity <t>For the intra-AS case, SN1 maps this intra-AS route on RSVP-TE
e.g. color:0:100.</t>
<t>For the 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> tunnels with TC ID 100 by using the Resolution Scheme for color:0:100.</t>
<t>For the inter-AS case, the underlay route in a TRDB is advertised
<t>For the Inter-AS case, the underlay route in a TRDB is advertised
in BGP to extend an underlay tunnel to adjacent domains. A new BGP in BGP to extend an underlay tunnel to adjacent domains. A new BGP
transport family called "BGP Classful Transport", also known as BGP CT transport family called "BGP Classful Transport", also known as BGP CT
(AFI/SAFIs 1/76, 2/76) is defined for this purpose. BGP CT makes it (AFI/SAFIs 1/76, 2/76), is defined for this purpose. BGP CT makes it
possible to advertise multiple tunnels to the same destination address, possible to advertise multiple tunnels to the same destination address,
thus avoiding the need for multiple loopbacks on the Egress Service Node thus avoiding the need for multiple loopbacks on the eSN.</t>
(eSN).</t>
<t>The BGP CT address family carries transport prefixes across tunnel <t>The BGP CT address family carries transport prefixes across tunnel
domain boundaries. Its design and operation are analogous to BGP LU domain boundaries. Its design and operation are analogous to BGP LU
(AFI/SAFIs 1/4 or 2/4). It disseminates "Transport Class" information (AFI/SAFIs 1/4 or 2/4). It disseminates "Transport Class" information
for the transport prefixes across the participating domains while for the transport prefixes across the participating domains while
avoiding the need of per-transport class loopback. This is not possible avoiding the need of per-TC loopback. This is not possible
with BGP LU without using per-color loopback. This dissemination makes with BGP LU without using per-color loopback. This dissemination makes
the end-to-end network a "Transport Class" aware tunneled network.</t> the end-to-end network a "Transport Class" aware tunneled network.</t>
<t>In <xref target="ArchOv" format="default"/>, BGP CT routes are originat
<t>In <xref target="ArchOv"/>, BGP CT routes are originated at BN11 in ed at BN11 in
AS1 with next hop "self" towards BN21 in AS2 to extend available RSVP-TE AS1 with NH "self" towards BN21 in AS2 to extend available RSVP-TE
tunnels for Transport Class 100 and 200 in AS1. BN21 propagates these tunnels for Transport Classes 100 and 200 in AS1. BN21 propagates these
routes with next hop "self" to PE21, which resolves the BGP CT routes routes with NH "self" to PE21, which resolves the BGP CT routes
over SRTE tunnels belonging to same transport class. Thus forming a over SRTE tunnels belonging to same Transport Class, thus forming a
BGP CT tunnel for each TC ID at PE21.</t> BGP CT tunnel for each TC ID at PE21.</t>
<t>PE21 maps the inter-AS service routes received with color:0:100 from
<t>PE21 maps the 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 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 color:0:100. Note that this procedure is same as that followed by SN1
in the Intra-AS case.</t> in the intra-AS case.</t>
<t>The following text illustrates how CT architecture provides tiered <t>The following text illustrates how CT architecture provides tiered
fallback options at a per-route granularity. <xref target="ArchOv"/>, fallback options at a per-route granularity. <xref target="ArchOv" format=
shows the Resolution Schemes in use, which make the following next hop "default"/>
resolution happen at SN11 (Intra-AS) and PE21 (Inter-AS) for the service shows the Resolution Schemes in use, which make the following NH
routes of prefixes IP1, IP2, IP3:<list> resolution happen at SN11 (intra-AS) and PE21 (inter-AS) for the service
<t>Resolve IP1 next hop over available tunnels in TRDB for Transport routes of prefixes IP1, IP2, and IP3:</t>
<ul spacing="normal">
<li>
<t>Resolve IP1 NH over available tunnels in TRDB for Transport
Class 100 with fallback to TRDB for best effort.</t> Class 100 with fallback to TRDB for best effort.</t>
</li>
<t>Resolve IP2 next hop over available tunnels in TRDB for Transport <li>
<t>Resolve IP2 NH over available tunnels in TRDB for Transport
Class 200 with fallback to TRDB for best effort.</t> Class 200 with fallback to TRDB for best effort.</t>
</li>
<t>Resolve IP3 next hop over available tunnels in TRDB for Transport <li>
<t>Resolve IP3 NH over available tunnels in TRDB for Transport
Class 100 with fallback to TRDB for Transport Class 200.</t> Class 100 with fallback to TRDB for Transport Class 200.</t>
</list>In <xref target="ArchOv"/>, SN11 resolves IP1, IP2 and IP3 </li>
directly over RSVP-TE tunnels in AS1. PE21 resolves IP1, IP2 and IP3 </ul>
<t>In <xref target="ArchOv" format="default"/>, SN11 resolves IP1, IP2, an
d IP3
directly over RSVP-TE tunnels in AS1. PE21 resolves IP1, IP2, and IP3
over extended BGP CT tunnels that resolve over SR-TE tunnels in AS2.</t> over extended BGP CT tunnels that resolve over SR-TE tunnels in AS2.</t>
<t>This document describes procedures using MPLS forwarding <t>This document describes procedures using MPLS forwarding
architecture. However, these procedures would work in a similar manner architecture. However, these procedures would work in a similar manner
for non-MPLS forwarding architectures as well. <xref target="SRv6-Support" for non-MPLS forwarding architectures as well. <xref target="SRv6-Support"
/> format="default"/>
describes the application of BGP CT over SRv6 data plane.</t> describes the application of BGP CT over the SRv6 data plane.</t>
</section> </section>
<section anchor="tc" numbered="true" toc="default">
<section anchor="tc" title="Transport Class"> <name>Transport Class</name>
<t>Transport Class is a construct that groups transport tunnels offering <t>Transport Class is a construct that groups transport tunnels offering
similar SLA within the administrative domain of a provider network or similar SLAs within the administrative domain of a provider network or
closely coordinated provider networks.</t> closely coordinated provider networks.</t>
<t>A Transport Class is uniquely identified by a 32-bit "Transport Class <t>A Transport Class is uniquely identified by a 32-bit "Transport Class
ID", that is assigned by the operator. The operator consistently ID" that is assigned by the operator. The operator consistently
provisions a Transport Class on participating nodes (SNs and BNs) in a provisions a Transport Class on participating nodes (SNs and BNs) in a
domain with its unique Transport Class ID.</t> domain with its unique Transport Class ID.</t>
<t>A Transport Class is also configured with RD and import/export RT <t>A Transport Class is also configured with RD and import/export RT
attributes. Creation of a Transport Class instantiates its corresponding attributes. Creation of a Transport Class instantiates its corresponding
TRDB and Resolution Schemes on that node.</t> TRDB and Resolution Schemes on that node.</t>
<t>All nodes within a domain agree on a common Transport Class ID <t>All nodes within a domain agree on a common Transport Class ID
namespace. However, two co-operating domains may not always agree on the namespace. However, two cooperating domains may not always agree on the
same namespace. Procedures to manage differences in Transport Class ID same namespace. Procedures to manage differences in Transport Class ID
namespaces between co-operating domains are specified in <xref namespaces between cooperating domains are specified in <xref target="non-
target="non-agreeing"/>.</t> agreeing" format="default"/>.</t>
<t>Transport Class ID conveys the Color of tunnels in a Transport Class. <t>Transport Class ID conveys the Color of tunnels in a Transport Class.
The terms 'Transport Class ID' and 'Color' are used interchangeably in The terms 'Transport Class ID' and 'Color' are used interchangeably in
this document.</t> this document.</t>
<section anchor="tc-te" numbered="true" toc="default">
<section anchor="tc-te" title="Classifying TE tunnels"> <name>Classifying TE Tunnels</name>
<t>TE tunnels can be classified into a Transport Class based on the TE <t>TE tunnels can be classified into a Transport Class based on the TE
attributes they possess and the TE characteristics that the operator attributes they possess and the TE characteristics that the operator
defines for that Transport Class. Due to the fact that multiple TE defines for that Transport Class. Due to the fact that multiple TE
tunneling protocols exist, their TE attributes and characteristics may tunneling protocols exist, their TE attributes and characteristics may
not be equal but sufficiently similar. Some examples of such not be equal but sufficiently similar. Some examples of such
classifications are as follows:<list> classifications are as follows:</t>
<t>Tunnels (RSVP-TE, IGP FLEX-ALGO, SR-TE) that support latency <ul spacing="normal">
<li>
<t>Tunnels (RSVP-TE, IGP Flex-Algo, SR-TE) that support latency
sensitive routing.</t> sensitive routing.</t>
</li>
<t>RSVP-TE Tunnels that only go over admin-group with Green <li>
<t>RSVP-TE tunnels that only go over admin-group with Green
links.</t> links.</t>
</li>
<t>Tunnels (RSVP-TE, SR-TE) that offer Fast Reroute.</t> <li>
<t>Tunnels (RSVP-TE, SR-TE) that offer FRR.</t>
</li>
<li>
<t>Tunnels (RSVP-TE, SR-TE) that share resources in the network <t>Tunnels (RSVP-TE, SR-TE) that share resources in the network
based on Shared Risk Link Groups defined by TE policy.</t> 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 <t>Tunnels (RSVP-TE, SR-TE, BGP CT) that avoid certain nodes in
the network based on RSVP-TE ERO, SR-TE policy or BGP policy.</t> the network based on RSVP-TE Explicit Route Object (ERO), SR-TE poli
</list></t> cy, or BGP policy.</t>
</li>
<t>An operator may configure a SN/BN to classify a tunnel into an </ul>
<t>An operator may configure an SN/BN to classify a tunnel into an
appropriate Transport Class. How exactly these tunnels are made appropriate Transport Class. How exactly these tunnels are made
Transport Class aware is implementation specific and outside the scope Transport Class aware is implementation specific and outside the scope
of this document.</t> of this document.</t>
<t>When a tunnel is made Transport Class aware, it causes the Tunnel <t>When a tunnel is made Transport Class aware, it causes the Tunnel
Route to be installed in the corresponding TRDB of that Transport Route to be installed in the corresponding TRDB of that Transport
Class. These routes are used to resolve overlay routes, including BGP Class. These routes are used to resolve overlay routes, including BGP
CT. The BGP CT routes may be further readvertised to adjacent domains CT. The BGP CT routes may be further readvertised to adjacent domains
to extend these tunnels. While readvertising BGP CT routes, the to extend these tunnels. While readvertising BGP CT routes, the
"Transport Class" identifier is encoded as part of the Transport Class "Transport Class ID" is encoded as part of the Transport Class
RT, which is a new Route Target extended community defined in <xref RT, which is a new Route Target extended community defined in <xref targ
target="tc-rt"/>.</t> et="tc-rt" format="default"/>.</t>
<t>An SN/BN receiving the transport routes via BGP with sufficient
<t>A SN/BN receiving the transport routes via BGP with sufficient
signaling information to identify a Transport Class can associate signaling information to identify a Transport Class can associate
those tunnel routes to the corresponding Transport Class. For example, those tunnel routes with the corresponding Transport Class. For example,
in BGP CT family routes, the Transport Class RT indicates the in BGP CT family routes, the Transport Class RT indicates the
Transport Class. For BGP LU family routes, import processing based on Transport Class. For BGP LU family routes, import processing based on
Communities or Inter-AS source-peer may be used to place the route in communities or inter-AS source-peer may be used to place the route in
the desired Transport Class.</t> the desired Transport Class.</t>
<t>When the tunnel route is received via <xref target="RFC9830" format="
<t>When the tunnel route is received via <xref target="SRTE"/> with default"/> with
"Color:Endpoint" as the NLRI that encodes the Transport Class as an "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 integer 'Color' in its Policy Color field, the 'Color' is mapped to a
Transport Class during the import processing. The SRTE tunnel route Transport Class during the import processing. The SRTE tunnel route
for this 'Endpoint' is installed in the corresponding TRDB. The SRTE for this 'Endpoint' is installed in the corresponding TRDB. The SRTE
tunnel will be extended by a BGP CT advertisement with NLRI tunnel will be extended by a BGP CT advertisement with NLRI
'RD:Endpoint', Transport Class RT and a new label. The MPLS swap route RD:EP, Transport Class RT, and a new label. The MPLS swap route
thus installed for the new label will pop the label and forward the thus installed for the new label will pop the label and forward the
decapsulated traffic into the path determined by the SRTE route for decapsulated traffic into the path determined by the SRTE route for
further encapsulation.</t> further encapsulation.</t>
<t><xref target="I-D.ietf-pce-segment-routing-policy-cp" format="default
<t><xref target="PCEP-SRPOLICY"/> extends Path Computation Element "/> extends the Path Computation Element
Communication Protocol (PCEP) to signal attributes of an SR Policy Communication Protocol (PCEP) to signal attributes of an SR Policy
which include Color. This Color is mapped to a Transport Class thus that include Color. This Color is mapped to a Transport Class thus
associating the SR Policy with the desired Transport Class.</t> associating the SR Policy with the desired Transport Class.</t>
<t>Similarly, <xref target="I-D.ietf-pce-pcep-color" format="default"/>
<t>Similarly, <xref target="PCEP-RSVP-COLOR"/> extends PCEP to carry extends PCEP to carry
the Color attribute for its use with RSVP-TE LSPs . This Color is the Color attribute for its use with RSVP-TE LSPs. This Color is
mapped to a Transport Class thus associating the RSVP-TE LSP with the mapped to a Transport Class thus associating the RSVP-TE LSP with the
desired Transport Class.</t> desired Transport Class.</t>
</section> </section>
<section anchor="trdb" numbered="true" toc="default">
<section anchor="trdb" title="Transport Route Database"> <name>Transport Route Database (TRDB)</name>
<t>A Transport Route Database (TRDB) is a logical collection of <t>A TRDB is a logical collection of
transport routes pertaining to the same Transport Class. In any node, transport routes pertaining to the same Transport Class. In any node,
every Transport Class has an associated TRDB. Resolution Schemes every Transport Class has an associated TRDB. Resolution Schemes
resolve next hop reachability for EP using the transport routes within resolve NH reachability for EP using the transport routes within
the scope of the TRDBs.</t> the scope of the TRDBs.</t>
<t>Tunnel EP addresses in a TRDB belong to the provider
<t>Tunnel endpoint addresses (EP) in a TRDB belong to the "Provider namespace representing the core transport region.</t>
Namespace" representing the core transport region.</t>
<t>An implementation may realize the TRDB as a "Routing Table" <t>An implementation may realize the TRDB as a "Routing Table"
referred in <eref referred to in <xref target="RFC4271" sectionFormat="of" section="9.1.2.
target="https://www.rfc-editor.org/rfc/rfc4271#section-9.1.2.1">Section 1"/>, which is used only for resolving NH
9.1.2.1 of RFC4271</eref> which is used only for resolving next hop reachability in the control plane. An implementation may choose a
reachability in control plane. An implementation may choose a
different datastructure to realize this logical construct while still different datastructure to realize this logical construct while still
adhering to the procedures defined in this document. The tunnel routes adhering to the procedures defined in this document. The tunnel routes
in a TRDB require no footprint in the forwarding plane unless they are in a TRDB require no footprint in the forwarding plane unless they are
used to resolve a next hop.</t> used to resolve an NH.</t>
<t>SNs or BNs originate routes for the BGP CT address
<t>SNs or BNs originate routes for the "Classful Transport" address family from the TRDB. These routes have RD:EP in the NLRI,
family from the TRDB. These routes have "RD:Endpoint" in the NLRI,
carry a Transport Class RT, and an MPLS label or equivalent identifier carry a Transport Class RT, and an MPLS label or equivalent identifier
in different forwarding architecture. "Classful Transport" family in different forwarding architecture. BGP CT family
routes received with Transport Class RT are installed into their routes received with Transport Class RT are installed into their
respective TRDB.</t> respective TRDB.</t>
</section> </section>
<section anchor="tc-rt" numbered="true" toc="default">
<section anchor="tc-rt" <name>Transport Class Route Target</name>
title="&quot;Transport Class&quot; Route Target Extended Communit <t>This section defines a new type of Route Target called a
y"> "Transport Class Route Target extended community" (also known as a
<t>This section defines a new type of Route Target, called a "Transport Class RT"). The procedures for use of this extended community
"Transport Class" Route Target Extended Community; also known as a
Transport Target. The procedures for use of this extended community
with BGP CT routes (AFI/SAFI: 1/76 or 2/76) are described below.</t> with BGP CT routes (AFI/SAFI: 1/76 or 2/76) are described below.</t>
<t>The "Transport Class" Route Target Extended Community is a <t>The Transport Class RT is a
transitive extended community <xref target="RFC4360">EXT-COMM</xref> transitive extended community <xref target="RFC4360" format="default"></
of extended type, which has the format as shown in <xref xref>
target="TCExtCom"/>.</t> of extended type, which has the format as shown in <xref target="TCExtCo
m" format="default"/>.</t>
<figure anchor="TCExtCom" suppress-title="false" <figure anchor="TCExtCom">
title="&quot;Transport Class&quot; Route Target Extended Communi <name>Transport Class RT</name>
ty"> <artwork align="left" name="" type="" alt=""><![CDATA[
<artwork align="left" xml:space="preserve">
0 1 2 3 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 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 | | Type= 0xa | SubType= 0x02 | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Transport Class ID | | Transport Class ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>
</figure>
Type: 1-octet field MUST be set to 0xa to indicate 'Transport Class'.
SubType: 1-octet field MUST be set to 0x2 to indicate 'Route Target'.
Reserved: 2-octet reserved bits field. <dl spacing="normal" newline="false">
This field MUST be set to zero on transmission. <dt>Type:</dt>
This field SHOULD be ignored on reception, and <dd>A 1-octet field that <bcp14>MUST</bcp14> be set to 0xa to indicate
MUST be left unaltered. 'Transport Class'.</dd>
Transport Class ID: This field is encoded in 4 octets. <dt>SubType:</dt>
<dd>A 1-octet field that <bcp14>MUST</bcp14> be set to 0x2 to indicate
'Route Target'.</dd>
This field contains the "Transport Class" identifier, <dt>Reserved:</dt>
which is an unsigned 32-bit integer. <dd><t>A 2-octet reserved bits field.</t>
<t>This field <bcp14>MUST</bcp14> be set to zero on transmission.</t>
<t>This field <bcp14>SHOULD</bcp14> be ignored on reception and <bcp14
>MUST</bcp14> be left unaltered.</t>
</dd>
This document reserves the Transport class ID value 0 to <dt>Transport Class ID:</dt>
represent "Best Effort Transport Class ID".</artwork> <dd><t>This field is encoded in 4 octets.</t>
</figure> <t>This field contains the "Transport Class ID", which is an unsigned 3
2-bit integer.</t>
<t>This document reserves the Transport Class ID value 0 to represent t
he "Best-Effort Transport Class ID".</t></dd>
</dl>
<t>A Transport Class Route Target Extended community with TC ID 100 <t>A Transport Class RT with TC ID 100
is denoted as "transport-target:0:100".</t> is denoted as "transport-target:0:100".</t>
<t>The VPN route import/export mechanisms specified in BGP/MPLS IP VPNs
<t>The VPN route import/export mechanisms specified in <xref (see <xref target="RFC4364" format="default"></xref>) and the Constrained Route
target="RFC4364">BGP/MPLS IP VPNs</xref> and the Constrained Route Distribution mechanisms specified in Route Target Constraint (see <xref
Distribution mechanisms specified in <xref target="RFC4684">Route target="RFC4684" format="default"></xref>) are applied using the Route Target ex
Target Constrain</xref> are applied using the Route Target extended tended
community. These mechanisms are applied to BGP CT routes (AFI/SAFI: community. These mechanisms are applied to BGP CT routes (AFI/SAFI:
1/76 or 2/76) using "Transport Class Route Target Extended 1/76 or 2/76) using the Transport Class RT".</t>
community".</t>
<t>A BGP speaker that implements procedures described in this document <t>A BGP speaker that implements procedures described in this document
and <xref target="RFC4684">Route Target Constrain</xref> MUST also and <xref target="RFC4684" format="default"></xref> <bcp14>MUST</bcp14>
apply the RTC procedures to the Transport Class Route Target Extended also
communities carried on BGP CT routes (AFI/SAFI: 1/76 or 2/76). An RTC apply the RTC procedures to the Transport Class 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 route is generated for each Route Target imported by locally
provisioned Transport Classes.</t> provisioned Transport Classes.</t>
<t>Further, when processing RT membership NLRIs containing a Transport
<t>Further, when processing RT membership NLRIs containing Transport Class RT received from external BGP
Class Route Target Extended community received from external BGP peers, it is necessary to consider multiple External BGP (EBGP) paths fo
peers, it is necessary to consider multiple EBGP paths for a given RTC r a given RTC
prefix for building the outbound route filter, and not just the best prefix for building the outbound route filter: not just the best
path. An implementation MAY provide configuration to control how many path. An implementation <bcp14>MAY</bcp14> provide configuration to cont
rol how many
EBGP RTC paths are considered.</t> EBGP RTC paths are considered.</t>
<t>The Transport Class RT is carried on
<t>The Transport Class Route Target Extended community is carried on
BGP CT family routes and is used to associate them with appropriate BGP CT family routes and is used to associate them with appropriate
TRDBs at receiving BGP speakers. The Transport Target is carried TRDBs at receiving BGP speakers. The Transport Class RT is carried
unaltered on the BGP CT route across BGP CT negotiated sessions except unaltered on the BGP CT route across BGP CT negotiated sessions except
for scenarios described in <xref target="non-agreeing"/>. for scenarios described in <xref target="non-agreeing" format="default"/ >.
Implementations should provide policy mechanisms to perform match, Implementations should provide policy mechanisms to perform match,
strip, or rewrite operations on a Transport Target just like any other strip, or rewrite operations on a Transport Class RT just like any other
BGP community.</t> BGP community.</t>
<t>Defining a new type code for the Transport Class RT
<t>Defining a new type code for the Transport Class Route Target avoids conflicting with any VPN Route Target
Extended community avoids conflicting with any VPN Route Target
assignments already in use for service families.</t> assignments already in use for service families.</t>
<t>This document also reserves the <xref <t>This document also reserves the non-transitive version of the Transpo
target="tc-rt-nt">Non-Transitive version of Transport Class extended rt Class RT
community</xref> for future use. The "Non-Transitive Transport Class" (see <xref target="tc-rt-nt" format="default"></xref>) for future use. T
Route Target Extended Community is not used. If received, it is he non-transitive Transport Class
considered equivalent in functionality to the Transitive Transport RT is not used. If received, it is
Class Route Target Extended Community, except for the difference in considered equivalent in functionality to the transitive Transport
Class RT, except for the difference in
Transitive bit flag.</t> Transitive bit flag.</t>
</section> </section>
</section> </section>
<section anchor="Nexthop_Resoln_Schm" numbered="true" toc="default">
<section anchor="Nexthop_Resoln_Schm" title="Resolution Scheme"> <name>Resolution Scheme</name>
<t>A Resolution Scheme is a construct that consists of a specific TRDB <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 or an ordered set of TRDBs. An overlay route is associated with a
resolution scheme during import processing, based on the Mapping Resolution Scheme during import processing based on the Mapping
Community in the route.</t> Community in the route.</t>
<t>Resolution Schemes enable a BGP speaker to resolve NH
<t>Resolution Schemes enable a BGP speaker to resolve next hop
reachability for overlay routes over the appropriate underlay tunnels reachability for overlay routes over the appropriate underlay tunnels
within the scope of the TRDBs. Longest Prefix Match (LPM) of the next within the scope of the TRDBs. Longest Prefix Match (LPM) of the NH is per
hop is performed within the identified TRDB.</t> formed within the identified TRDB.</t>
<t>An implementation may provide an option for the overlay route to <t>An implementation may provide an option for the overlay route to
resolve over less preferred Transport Classes, should the resolution resolve over less-preferred Transport Classes, should the resolution
over a primary Transport Class fail.</t> over a primary Transport Class fail.</t>
<t>To accomplish this, the "Resolution Scheme" is configured with the <t>To accomplish this, the "Resolution Scheme" is configured with the
primary Transport Class, and an ordered list of fallback Transport primary Transport Class and an ordered list of fallback Transport
Classes. Two Resolution Schemes are considered equivalent in Intent if Classes. Two Resolution Schemes are considered equivalent in Intent if
they consist of the same ordered set of TRDBs.</t> they consist of the same ordered set of TRDBs.</t>
<t>Operators must ensure that Resolution Schemes for a Mapping Community
<t>Operators must ensure that Resolution Schemes for a mapping community
are provisioned consistently on various nodes participating in a BGP CT are provisioned consistently on various nodes participating in a BGP CT
network, based on desired Intent and transport classes available in that network based on desired Intent and Transport Classes available in that
domain.</t> domain.</t>
<section anchor="Mapping_Comm" numbered="true" toc="default">
<section anchor="Mapping_Comm" title="Mapping Community"> <name>Mapping Community</name>
<t>A "Mapping Community" is used to signal the desired Intent on an <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. At an ingress node receiving the route, it maps the
overlay route to a "Resolution Scheme" used to resolve the route's 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; <t>A Mapping Community is a "role" and not a new type of community;
any BGP Community Carrying Attribute (e.g. Community or Extended any BGP Community Carrying Attribute (e.g., Community or Extended
Community) may play this role, besides the other roles it may already Community) may play this role in addition to the other roles it may alre
be playing. For example, the Transport Class Route Target Extended ady
Community plays a dual role, being a Route Target as well as a Mapping be playing. For example, the Transport Class RT
plays a dual role: as Route Target and a Mapping
Community.</t> Community.</t>
<t>Operator provisioning ensures that the ingress and egress SNs agree <t>Operator provisioning ensures that the ingress and egress SNs agree
on the BGP CCA and community namespace to use for the Mapping on the BGP CCA and community namespace to use for the Mapping
Community.</t> Community.</t>
<t>A Mapping Community maps to exactly one Resolution Scheme at <t>A Mapping Community maps to exactly one Resolution Scheme at
receiving BGP speaker. An implementation SHOULD allow associating a receiving BGP speaker. An implementation <bcp14>SHOULD</bcp14> allow t he association of
multiple Mapping Communities to a Resolution Scheme. This helps with multiple Mapping Communities to a Resolution Scheme. This helps with
renumbering and migration scenarios.</t> renumbering and migration scenarios.</t>
<t>An example of mapping community is "color:0:100", described in <t>An example of a Mapping Community is a Color extended community "colo
<xref target="RFC9012"/>, or the "transport-target:0:100" described in r:0:100", described in
<xref target="tc-rt"/> in this document.</t> <xref target="RFC9012" format="default"/>, or the "transport-target:0:10
0" described in
<xref target="tc-rt" format="default"/>.</t>
<t>The first community on the overlay route that matches a Mapping <t>The first community on the overlay route that matches a Mapping
Community of a locally configured Resolution Scheme is considered the Community of a locally configured Resolution Scheme is considered the
effective Mapping Community for the route. The Resolution Scheme thus effective Mapping Community for the route. The Resolution Scheme thus
found is used when resolving the route's PNH. If a route contains more found is used when resolving the route's PNH. If a route contains more
than one Mapping Community, it indicates that the route considers than one Mapping Community, it indicates that the route considers
these distinct Mapping Communities as equivalent in Intent.</t> these distinct Mapping Communities as equivalent in Intent.</t>
<t>If more than one distinct Mapping Communities on an overlay route <t>On an overlay route, if more than one Mapping Community exists that m
map to distinct Resolution Schemes with dissimilar Intents at a ap
receiving node, it is considered a configuration error.</t> to distinct Resolution Schemes 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 <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, Resolution Scheme can be in effect for the route on any given router,
it is incumbent on the operator to ensure that communities attached it is incumbent on the operator to ensure that communities attached
to a route will map to the desired Resolution Scheme at each point to a route will map to the desired Resolution Scheme at each point
in the network.</t> in the network.</t>
<t>It should be noted that the Mapping Community role does not require <t>It should be noted that the Mapping Community role does not require
applying Route Target Constrain procedures specified in RFC 4684.</t> applying Route Target Constraint procedures specified in <xref target="R FC4684"/>.</t>
</section> </section>
</section> </section>
<section anchor="ct-family" numbered="true" toc="default">
<section anchor="ct-family" title="BGP Classful Transport Family"> <name>BGP Classful Transport Family</name>
<t>The BGP Classful Transport (BGP CT) family uses the existing Address <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 Family Identifier (AFI) of IPv4 or IPv6 and a new SAFI 76 "Classful
Transport" that applies to both IPv4 and IPv6 AFIs.</t> Transport" that applies to both IPv4 and IPv6 AFIs.</t>
<t>The AFI/SAFI 1/76 <bcp14>MUST</bcp14> be negotiated as per the Multipro
<t>The AFI/SAFI 1/76 MUST be negotiated as per the Multiprotocol tocol
Extensions capability described in Section 8 of <xref target="RFC4760"/> Extensions capability described in <xref target="RFC4760" sectionFormat="o
f" section="8"/>
to be able to send and receive BGP CT routes for IPv4 endpoint to be able to send and receive BGP CT routes for IPv4 endpoint
prefixes.</t> prefixes.</t>
<t>The AFI/SAFI 2/76 <bcp14>MUST</bcp14> be negotiated as per the Multipro
<t>The AFI/SAFI 2/76 MUST be negotiated as per the Multiprotocol tocol
Extensions capability described in Section 8 of <xref target="RFC4760"/> Extensions capability described in <xref target="RFC4760" sectionFormat="o
f" section="8"/>
to be able to send and receive BGP CT routes for IPv6 endpoint to be able to send and receive BGP CT routes for IPv6 endpoint
prefixes.</t> prefixes.</t>
<section anchor="ct-nlri" numbered="true" toc="default">
<section anchor="ct-nlri" title="NLRI Encoding"> <name>NLRI Encoding</name>
<t>The "Classful Transport" SAFI NLRI has the same encoding as <t>The "Classful Transport" SAFI NLRI has the same encoding as
specified in Section 2 of <xref target="RFC8277"/>.</t> specified in <xref target="RFC8277" sectionFormat="of" section="2"/>.</t
>
<t>When AFI/SAFI is 1/76, the Classful Transport NLRI Prefix consists <t>When the AFI/SAFI is 1/76, the BGP CT NLRI Prefix consists
of an 8-byte RD followed by an IPv4 prefix. When AFI/SAFI is 2/76, the of an 8-byte RD followed by an IPv4 prefix. When AFI/SAFI is 2/76, the
Classful Transport NLRI Prefix consists of an 8-byte RD followed by an BGP CT NLRI Prefix consists of an 8-byte RD followed by an
IPv6 prefix.</t> IPv6 prefix.</t>
<t>The procedures described for AFI/SAFIs 1/4 or 1/128 in
<t>The procedures described for AFI/SAFIs 1/4 or 1/128 in Section 2 of <xref target="RFC8277" sectionFormat="of" section="2"/> apply for AFI/SA
<xref target="RFC8277"/> apply for AFI/SAFI 1/76 also. The procedures FI 1/76 also. The procedures
described for AFI/SAFIs 2/4 or 2/128 in Section 2 of <xref described for AFI/SAFIs 2/4 or 2/128 in <xref target="RFC8277" sectionFo
target="RFC8277"/> apply for AFI/SAFI 2/76 also.</t> rmat="of" section="2"/> apply for AFI/SAFI 2/76 also.</t>
<t>BGP CT routes <bcp14>MAY</bcp14> carry multiple labels in the NLRI by
<t>BGP CT routes MAY carry multiple labels in the NLRI, by negotiating negotiating
the Multiple Labels Capability as described in Section 2.1 of <xref the Multiple Labels Capability as described in <xref target="RFC8277" se
target="RFC8277"/></t> ctionFormat="of" section="2.1"/>.</t>
<t>Properties received on a BGP CT route include the
<t>Properties received on a Classful Transport route include the Transport Class RT, which is used to
Transport Class Route Target extended community, which is used to
associate the route with the correct TRDBs on SNs and BNs in the associate the route with the correct TRDBs on SNs and BNs in the
network, and either an IPv4 or an IPv6 next hop.</t> network, and either an IPv4 or an IPv6 NH.</t>
</section> </section>
<section anchor="ct-nhop" numbered="true" toc="default">
<section anchor="ct-nhop" title="Next Hop Encoding"> <name>Next Hop Encoding</name>
<t>When the length of the Next hop Address field is 4, the next hop <t>When the length of the Next hop Address field is 4, the next hop
address is of type IPv4 address.</t> address is an IPv4 address.</t>
<t>When the length of the Next hop Address field is 16 (or 32), the next
<t>When the length of Next hop Address field is 16 (or 32), the next hop address is an IPv6 address (potentially followed by the
hop address is of type IPv6 address (potentially followed by the link-local IPv6 address of the next hop). This follows
link-local IPv6 address of the next hop). This follows Section 3 in <xref target="RFC2545" sectionFormat="of" section="3"/>.</t>
<xref target="RFC2545"/></t>
<t>When the length of Next hop Address field is 24 (or 48), the next <t>When the length of Next hop Address field is 24 (or 48), the next
hop address is of type VPN-IPv6 with an 8-octet RD set to zero hop address is a VPN-IPv6 with an 8-octet RD set to zero
(potentially followed by the link-local VPN-IPv6 address of the next (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 hop with an 8-octet RD set to zero). This follows
<xref target="RFC4659"/></t> <xref 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 <t>When the length of the Next hop Address field is 12, the next hop
address is of type VPN-IPv4 with 8-octet RD set to zero.</t> address is a VPN-IPv4 with 8-octet RD set to zero.</t>
<t>If the length of the Next hop Address field contains any other <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 values, it is considered an error and is handled via BGP session reset
as per <xref section="7.11" target="RFC7606"/>.</t> as per <xref section="7.11" target="RFC7606" format="default"/>.</t>
</section> </section>
<section anchor="CTMultiEncap" <section anchor="CTMultiEncap" numbered="true" toc="default">
title="Carrying multiple Encapsulation Information"> <name>Carrying Multiple Types of Encapsulation Information</name>
<t>To ease interoperability between nodes supporting different <t>To ease interoperability between nodes supporting different
forwarding technologies, a BGP CT route allows carrying multiple forwarding technologies, a BGP CT route allows carrying multiple
encapsulation information.</t> types of encapsulation information.</t>
<t>An MPLS label is carried using the encoding in <xref target="RFC8277"
<t>An MPLS Label is carried using the encoding in <xref format="default"/>. A node that does not support MPLS forwarding
target="RFC8277"/>. A node that does not support MPLS forwarding advertises the special label 3 (Implicit NULL) in the MPLS label field (
advertises the special label 3 (Implicit NULL) in the RFC 8277 MPLS see <xref target="RFC8277"/>). The Implicit NULL label carried in BGP CT route i
Label field. The Implicit NULL label carried in BGP CT route indicates ndicates
to receiving node that it should not impose any BGP CT label for this to a receiving node that it should not impose any BGP CT label for this
route.</t> route.</t>
<t>The SID information for SR with respect to MPLS Data Plane is <t>The SID information for SR with respect to the MPLS data plane is
carried as specified in Prefix SID attribute defined as part of carried as specified in the Prefix-SID attribute defined as part of
Section 3 in <xref target="RFC8669"/>.</t> <xref target="RFC8669" sectionFormat="of" section="3"/>.</t>
<t>The SID information for SR with respect to SRv6 data plane is
<t>The SID information for SR with respect to SRv6 Data Plane is carried as specified in <xref target="SRv6-Support" format="default"/>.<
carried as specified in <xref target="SRv6-Support"/>.</t> /t>
<t>UDP tunneling information is carried using the Tunnel Encapsulation
<t>UDP tunneling information is carried using Tunnel Encapsulation Attribute as specified in <xref target="RFC9012" format="default"/>.</t>
Attribute as specified in <xref target="RFC9012"/>.</t>
</section> </section>
<section numbered="true" toc="default">
<section title="Comparison with Other Families using RFC-8277 Encoding"> <name>Comparison with Other Families Using Encoding from RFC 8277</name>
<t>AFI/SAFI 1/128 (MPLS-labeled VPN address) is an RFC8277 encoded <t>AFI/SAFI 1/128 (L3VPN) is a family encoded using <xref target="RFC827
family that carries service prefixes in the NLRI, where the prefixes 7"/> that carries service prefixes in the NLRI, where the prefixes
come from the customer namespaces and are contextualized into separate come from the customer namespaces and are contextualized into separate
user virtual service RIBs called VRFs as per [RFC4364].</t> user virtual service RIBs called VRFs as per <xref target="RFC4364"/>.</
t>
<t>AFI/SAFI 1/4 (BGP LU) is an RFC8277 encoded family that carries <t>AFI/SAFI 1/4 (BGP LU) is a family encoded using <xref target="RFC8277
"/> that carries
transport prefixes in the NLRI, where the prefixes come from the transport prefixes in the NLRI, where the prefixes come from the
provider namespace.</t> provider namespace.</t>
<t>AFI/SAFI 1/76 (BGP CT) is a family encoded using <xref target="RFC827
<t>AFI/SAFI 1/76 (Classful Transport SAFI) is an RFC8277 encoded 7"/> that carries transport prefixes in the NLRI, where the prefixes
family that carries transport prefixes in the NLRI, where the prefixes
come from the provider namespace and are contextualized into separate come from the provider namespace and are contextualized into separate
TRDB, following mechanisms similar to RFC 4364 procedures.</t> TRDB, following mechanisms similar to <xref target="RFC4364"/> procedure
s.</t>
<t>It is worth noting that AFI/SAFI 1/128 has been used to carry <t>It is worth noting that AFI/SAFI 1/128 has been used to carry
transport prefixes in "L3VPN Inter-AS Carrier's carrier" scenario as transport prefixes in "L3VPN inter-AS Carrier's carrier" scenario as
defined in Section 10 of <xref target="RFC4364"/>, where BGP LU/LDP defined in <xref target="RFC4364" sectionFormat="of" section="10"/>, whe
re BGP LU/LDP
prefixes in CsC VRF are advertised in AFI/SAFI 1/128 towards the prefixes in CsC VRF are advertised in AFI/SAFI 1/128 towards the
remote-end client carrier.</t> remote-end client carrier.</t>
<t>In this document, SAFI 76 (CT) is used instead of reusing SAFI
<t>In this document, SAFI 76 (BGP CT) is used instead of reusing SAFI
128 (L3VPN) for AFIs 1 or 2 to carry these transport routes because it 128 (L3VPN) for AFIs 1 or 2 to carry these transport routes because it
is operationally advantageous to segregate transport and service is operationally advantageous to segregate transport and service
prefixes into separate address families. For example, such an approach prefixes into separate address families. For example, such an approach
allows operators to safely enable "per-prefix" label allocation scheme allows operators to safely enable a "per-prefix" label-allocation scheme
for Classful Transport prefixes, typically with a number of routes in for BGP CT prefixes, typically with a number of routes in
the hundreds of thousands or less, without affecting SAFI 128 service the hundreds of thousands or less, without affecting SAFI 128 service
prefixes which may represent millions of routes, at time of writing. prefixes, which may represent millions of routes at the time of writing.
The "per prefix" label allocation scheme localizes routing churn The "per-prefix" label-allocation scheme localizes routing churn
during topology changes.</t> during topology changes.</t>
<t>Service routes continue to be carried in their existing AFI/SAFIs <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), without any change. For example, L3VPN (AFI/SAFI: 1/128 and 2/128),
EVPN (AFI/SAFI: 25/70 ), VPLS (AFI/SAFI: 25/65), Internet (AFI/SAFI: EVPN (AFI/SAFI: 25/70 ), Virtual Private LAN Service (VPLS) (AFI/SAFI: 2 5/65), or Internet (AFI/SAFI:
1/1 or 2/1). These service routes can resolve over BGP CT (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> 1/76 or 2/76) transport routes.</t>
<t>A new SAFI 76 for AFI 1 and AFI 2 also facilitates having a <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 different distribution path of the transport family routes in a
network than the service route distribution path. Service routes network than the service route distribution path. Service routes
(Inet-VPN SAFI 128) are exchanged over an EBGP multihop session (SAFI 128) are exchanged over an EBGP multihop session
between ASes with next hop unchanged; whereas Classful Transport between ASes with the NH unchanged; whereas BGP CT
routes (SAFI 76) are advertised over EBGP single-hop sessions with routes (SAFI 76) are advertised over EBGP single-hop sessions with a
"next hop self" rewrite over inter-AS links.</t> "NH self" rewrite over inter-AS links.</t>
<t>The BGP CT SAFI 76 for AFI 1 and 2 is conceptually similar to BGP <t>The BGP CT SAFI 76 for AFI 1 and 2 is conceptually similar to BGP
LU SAFI 4, in that it carries transport prefixes. The only difference LU SAFI 4 in that it carries transport prefixes. The only difference
is that it also carries in a Route Target an indication of which is that it also carries in a Route Target an indication of which
Transport Class the transport prefix belongs to, and uses the RD to Transport Class the transport prefix belongs to and uses the RD to
disambiguate multiple instances of the same transport prefix in a BGP disambiguate multiple instances of the same transport prefix in a BGP
Update.</t> UPDATE message.</t>
</section> </section>
</section> </section>
<section numbered="true" toc="default">
<section title="Protocol Procedures"> <name>Protocol Procedures</name>
<t>This section summarizes the procedures followed by various nodes <t>This section summarizes the procedures followed by various nodes
speaking Classful Transport family.</t> speaking BGP CT family.</t>
<section numbered="true" toc="default">
<section title="Preparing the network to deploy Classful Transport planes" <name>Preparing the Network to Deploy Classful Transport Planes</name>
>
<t><list>
<t>It is 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 to identify each
Transport Class.</t>
<t>Operators configure the Transport Classes on the SNs and BNs in <t>It is the responsibility of the operators to decide the Transport
the network with Transport Class Route Targets and appropriate Classes to enable and use in their network. They are also expected to
Route-Distinguishers.</t> allocate a Transport Class RT to identify each Transport
Class.</t>
<t>Operators configure the Transport Classes on the SNs and BNs in the
network with Transport Class RTs and appropriate
Route Distinguishers.</t>
<t>Implementations <bcp14>MAY</bcp14> provide automatic generation and
assignment of RD, RT values. They <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>
<t>Implementations MAY provide automatic generation and assignment
of RD, RT values. They MAY 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>
<section numbered="true" toc="default">
<name>Originating BGP CT Routes</name>
<section title="Originating Classful Transport Routes"> <t>BGP CT routes are sent only to BGP peers that have negotiated the
<t><list> Multiprotocol Extensions capability described in <xref
<t>BGP CT routes are sent only to BGP peers that have negotiated target="RFC4760" sectionFormat="of" section="8"/> to be able to send
the Multiprotocol Extensions capability described in Section 8 of and receive BGP CT routes.</t>
[RFC4760] 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
<t>At the ingress node of the tunnel's home domain, the tunneling Transport Class to which the tunnel belongs.</t>
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. the tunnel endpoint (EP),
originates the BGP CT route with RD:EP in the NLRI, Transport
Class RT and PNH as 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 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 tunnel's home domain, may originate the BGP CT route
for the tunnel destination with NLRI RD:EP, 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 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 RD SHOULD be used by the originator of a Classful <t>The egress node of the tunnel, i.e., the tunnel endpoint (EP),
Transport route to disambiguate the multiple BGP advertisements originates the BGP CT route with RD:EP in the NLRI, a Transport Class RT
for a transport endpoint. An administrator may use duplicate RDs ,
based on local choice, understanding the impact on path diversity and the PNH as the EP. This BGP CT route will be resolved over the tunne
and troubleshooting, as described in <xref l
target="rd-lbl-usage"/>.</t> route in TRDB at the ingress node. When the tunnel is up, the Classful
</list></t> Transport BGP route will become usable and get 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 RD:EP in the NLRI, attaching a Transport Cla
ss
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 <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>A unique RD <bcp14>SHOULD</bcp14> be used by the originator of a
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" format="default"/>.</t>
</section> </section>
<section anchor="CTingress" numbered="true" toc="default">
<section anchor="CTingress" <name>Processing BGP CT Routes by Ingress Nodes</name>
title="Processing Classful Transport Routes by Ingress Nodes"> <t>Upon receipt of a BGP CT route with a PNH EP that is not directly
<list> connected (e.g., an IBGP-route), a Mapping Community (the Transport
<t>Upon receipt of a BGP CT route with a PNH EP that is not directly Class RT) on the route is used to decide to which Resolution Scheme
connected (e.g. an IBGP-route), a Mapping Community (the Transport
Class RT) on the route is used to decide to which resolution scheme
this route is to be mapped.</t> this route is to be mapped.</t>
<t>The Resolution Scheme for a Transport Class RT with Transport
<t>The resolution scheme for a Transport Class RT with Transport
Class ID "C1" contains the TRDB of a Transport Class with same ID. Class ID "C1" contains the TRDB of a Transport Class with same ID.
The administrator MAY customize the resolution scheme for Transport The administrator <bcp14>MAY</bcp14> customize the Resolution Scheme f
Class "C1" to map to a different ordered list of TRDBs. If the or Transport
resolution scheme for TC ID "C1" is not found, the resolution scheme Class ID "C1" to map to a different ordered list of TRDBs. If the
containing the "Best Effort" transport class TRDB is used.</t> Resolution Scheme for TC ID "C1" is not found, the Resolution Scheme
containing the Best-Effort TRDB is used.</t>
<t>The routes in the TRDBs associated with selected resolution <t>The routes in the TRDBs associated with a selected Resolution
scheme are used to resolve the received PNH EP. The order of TRDBs Scheme are used to resolve the received PNH EP. The order of TRDBs
in the resolution scheme is followed when resolving the received in the Resolution Scheme is followed when resolving the received
PNH, such that a route in a backup TRDB is used only when a matching 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 route was not found for EP in the primary TRDBs preceding it. This
achieves the fallback desired by the resolution scheme.</t> achieves the fallback desired by the Resolution Scheme.</t>
<t>If the resolution process does not find a matching route for the
<t>If the resolution process does not find a matching route for EP EP
in any of the associated TRDBs, the received BGP CT route MUST be in any of the associated TRDBs, the received BGP CT route <bcp14>MUST<
considered unresolvable. (See RFC 4271, Section 9.1.2.1).</t> /bcp14> be
considered unresolvable. (See <xref target="RFC4271" sectionFormat="of
<t>The received BGP CT route MUST be added to the TRDB corresponding " section="9.1.2.1"/>.)</t>
to the Transport Class "C1", if the transport class is provisioned <t>The received BGP CT route <bcp14>MUST</bcp14> be added to the TRD
B corresponding
to the Transport Class ID "C1" if the TC is provisioned
locally. This step applies only if the Transport Class RT is 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 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, RD:EP is ignored when the BGP CT route for EP is added to the TRDB
so that overlay routes can resolve over this BGP CT tunnel route by so that overlay routes can resolve over this BGP CT tunnel route by
performing a lookup for EP. Please note that a TRDB is a logical 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, database of tunnel routes belonging to the same Transport Class ID;
hence it uses only the EP as the lookup key without RD or TC ID.</t> hence, it only uses the EP as the lookup key (without RD or TC ID).</t
>
<t>If no Mapping Community was found on a BGP CT route, the best <t>If no Mapping Community is found on a BGP CT route, the Best-Effo
effort resolution scheme is used for resolving the route's next hop, rt Resolution Scheme is used to resolve the route's next hop,
and the BGP CT route is not added to any TRDB.</t> and the BGP CT route is not added to any TRDB.</t>
</list>
</section> </section>
<section numbered="true" toc="default">
<name>Readvertising BGP CT Route by Border Nodes</name>
<section title="Readvertising Classful Transport Route by Border Nodes"> <t>This section describes the MPLS label handling when readvertising
<list> a BGP CT route with "NH self". When readvertising a BGP
<t>This section describes the MPLS label handling when readvertising CT route with "NH self", a BN allocates an MPLS label to
a BGP CT route with Next Hop set to Self. When readvertising a BGP advertise upstream in the BGP CT NLRI. The BN also installs
CT route with Next Hop set to Self, a BN allocates an MPLS label to
advertise upstream in Classful Transport NLRI. The BN also installs
an MPLS route for that label that swaps the incoming label with the 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 received from the downstream BGP speaker (or pops the incoming
label if the label received from the downstream BGP speaker was label if the label received from the downstream BGP speaker was
Implicit-NULL). The MPLS route then pushes received traffic to the Implicit NULL). The MPLS route then pushes received traffic to the
transport tunnel or direct interface that the Classful Transport transport tunnel or direct interface that the BGP CT
route's PNH resolved over.</t> route's PNH resolved over.</t>
<t>The label <bcp14>SHOULD</bcp14> be allocated with "per-prefix" la
<t>The label SHOULD be allocated with "per-prefix" label allocation bel-allocation
semantics. The IP prefix in the TRDB context (Transport-Class, semantics. The IP prefix in the TRDB context (Transport Class,
IP-prefix) is used as the key to do per-prefix label allocation. IP prefix) is used as the key to "per-prefix" label allocation.
This helps in avoiding BGP CT route churn throughout the CT network This helps in avoiding BGP CT route churn throughout the CT network
when an instability (e.g., link failure) is experienced in a domain. when an instability (e.g., link failure) is experienced in a domain.
The failure is not propagated further than the BN closest to the The failure is not propagated further than the BN closest to the
failure. If a different label allocation mode is used, the impact on failure. If a different label-allocation mode is used, the impact on
end to end convergence should be considered.</t> end-to-end convergence should be considered.</t>
<t>The value of the advertised MPLS label is locally significant, <t>The value of the advertised MPLS label is locally significant
and is dynamic by default. A BN may provide an option to allocate a and is dynamic by default. A BN may provide an option to allocate a
value from a statically provisioned range. This can be achieved value from a statically provisioned range. This can be achieved
using locally configured export policy, or via mechanisms such as using a locally configured export policy or via mechanisms such as
the ones described in <xref target="RFC8669">BGP the ones described related to BGP Prefix-SID as described in BGP (see
Prefix-SID</xref>.</t> <xref target="RFC8669" format="default"></xref>).</t>
</list>
</section>
<section title="Border Nodes Receiving Classful Transport Routes on EBGP"> </section>
<list> <section numbered="true" toc="default">
<t>If a route is received with a PNH that is known to be directly <name>Border Nodes Receiving BGP CT Routes on EBGP</name>
connected (for example, EBGP single-hop neighbor address), the <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 directly connected interface is checked for MPLS forwarding
capability. No other next hop resolution process is performed since capability. No other next hop resolution process is performed since
the inter-AS link can be used for any Transport Class.</t> 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
<t>If the inter-AS links need to honor Transport Class, then the BN <bcp14>MUST</bcp14> follow the procedures of an ingress node (<xref ta
MUST follow procedures of an Ingress node (<xref rget="CTingress" format="default"/>) and perform the next hop resolution process
target="CTingress"/>) and perform the next hop resolution process. .
In order to make the link Transport Class aware, the route to In order to make the link Transport Class aware, the route to the
directly connected PNH is installed in the TRDB belonging to the directly connected PNH is installed in the TRDB belonging to the
associated Transport Class.</t> associated Transport Class.</t>
</list>
</section>
<section title="Avoiding Path Hiding Through Route Reflectors"> </section>
<list> <section numbered="true" toc="default">
<t>When multiple instances of a given RD:EP exist with different <name>Avoiding Path Hiding Through Route Reflectors</name>
forwarding characteristics, then <xref target="RFC7911">BGP <t>When multiple instances of a given RD:EP exist with different
ADD-PATH</xref> is helpful.</t> forwarding characteristics, BGP ADD-PATH (see <xref target="RFC7911" f
ormat="default"></xref>) is helpful.</t>
<t>When multiple BNs exist such that they advertise a "RD:EP" prefix <t>When multiple BNs exist such that they advertise an "RD:EP" prefi x
to Route Reflectors (RRs), the RRs may hide all but one of the BNs, to Route Reflectors (RRs), the RRs may hide all but one of the BNs,
unless <xref target="RFC7911">BGP ADD-PATH</xref> is used for the unless BGP ADD-PATH (see <xref target="RFC7911" format="default"></xre
Classful Transport family. This is similar to L3VPN Option B f>) is used for the
BGP CT family. This is similar to L3VPN inter-AS option B
scenarios.</t> scenarios.</t>
<t>Hence, BGP ADD-PATH (see <xref target="RFC7911" format="default">
<t>Hence, <xref target="RFC7911">BGP ADD-PATH</xref> SHOULD be used </xref>) <bcp14>SHOULD</bcp14> be used
for Classful Transport family, to avoid path-hiding through RRs so for the BGP CT family to avoid path hiding through RRs so
that the RR sends multiple CT routes for RD:EP to its clients. This 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 improves the convergence time when the path via one of the multiple
BNs fails.</t> BNs fails.</t>
</list>
</section>
<section title="Avoiding Loops Between Route Reflectors in Forwarding Path </section>
"> <section numbered="true" toc="default">
<list> <name>Avoiding Loops Between Route Reflectors in Forwarding Paths</name>
<t>A pair of redundant ABRs, each acting as an RR with next hop <t>A pair of redundant ABRs, each acting as an RR with the next hop
self, may choose each other as best path instead of the upstream set to itself, may choose each other as the best path instead of the u
ASBR, causing a traffic forwarding loop.</t> pstream
ASBR, causing a traffic-forwarding loop.</t>
<t>This problem can happen for routes of any BGP address family, <t>This problem can happen for routes of any BGP address family,
including BGP CT and BGP LU.</t> including BGP CT and BGP LU.</t>
<t>Using one or more of the approaches described in <xref target="I-
<t>Using one or more of the approaches described in <xref D.ietf-idr-bgp-fwd-rr" format="default"/> lowers the possibility of such loops i
target="BGP-FWD-RR"/> softens the possibility of such loops in a n a
network with redundant ABRs.</t> network with redundant ABRs.</t>
</list>
</section> </section>
<section numbered="true" toc="default">
<name>Ingress Nodes Receiving Service Routes with a Mapping Community</n
ame>
<section title="Ingress Nodes Receiving Service Routes with a Mapping Comm <t>Upon receipt of a BGP service route (for example, AFI/SAFI: 1/1,
unity"> 2/1) with a PNH as the EP that is not directly connected (for example,
<list> an IBGP-route), a Mapping Community (for example, a Color Extended
<t>Upon receipt of a BGP service route (for example, AFI/SAFI: 1/1, Community) on the route is used to decide to which Resolution Scheme
2/1) with a PNH as EP that is not directly connected (for example,
an IBGP-route), a Mapping Community (for example, Color Extended
Community) on the route is used to decide to which resolution scheme
this route is to be mapped.</t> this route is to be mapped.</t>
<t>The Resolution Scheme for a Color extended community with Color
<t>The resolution scheme for a Color Extended Community with Color "C1" contains a TRDB for a Transport Class with same ID followed by
"C1" contains a TRDB for a Transport Class with same ID, followed by the Best-Effort TRDB. The administrator <bcp14>MAY</bcp14> customize t
the Best Effort TRDB. The administrator MAY customize the resolution he Resolution
scheme to map to a different ordered list of TRDBs. If the Scheme to map to a different ordered list of TRDBs. If the
resolution scheme for TC ID "C1" is not found, the resolution scheme Resolution Scheme for TC ID "C1" is not found, the Resolution Scheme
containing the "Best Effort" transport class TRDB is used.</t> containing the Best-Effort TRDB is used.</t>
<t>If no Mapping Community was found on the overlay route, the "Best
<t>If no Mapping Community was found on the overlay route, the "Best Effort Resolution Scheme" is used for resolving the route's next
Effort" resolution scheme is used for resolving the route's next
hop. This behavior is backward compatible to behavior of an hop. This behavior is backward compatible to behavior of an
implementation that does not follow procedures described in this implementation that does not follow procedures described in this
document.</t> document.</t>
<t>The routes in the TRDBs associated with the selected Resolution
<t>The routes in the TRDBs associated with selected resolution Scheme are used to resolve the received PNH EP. The order of TRDBs
scheme are used to resolve the received PNH EP. The order of TRDBs in a Resolution Scheme is followed when resolving the received PNH,
in a resolution scheme is followed when resolving the received PNH,
such that a route in a backup TRDB is used only when a matching 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 route was not found for the EP in the primary TRDBs preceding it. This
achieves the fallback desired by the resolution scheme.</t> achieves the fallback desired by the Resolution Scheme.</t>
<t>If the resolution process does not find a Tunnel Route for the EP
<t>If the resolution process does not find a Tunnel Route for EP in in
any of the Transport Route Databases, the service route MUST be any of the Transport Route Databases, the service route <bcp14>MUST</b
considered unresolvable (See RFC 4271, Section 9.1.2.1).</t> cp14> be
</list> considered unresolvable. (See <xref target="RFC4271" sectionFormat="of
" section="9.1.2.1"/>).</t>
<t>Note: For an illustration of above procedures in a MPLS network, <t>Note: For an illustration of above procedures in an MPLS network,
refer to <xref target="CTProc"/>.</t> refer to <xref target="CTProc" format="default"/>.</t>
</section> </section>
<section numbered="true" toc="default">
<section title="Best Effort Transport Class"> <name>Best-Effort Transport Class</name>
<list> <t>It is also possible to represent a 'Best-Effort' SLA as a Transpo
<t>It is possible to represent 'Best effort' SLA also as a Transport rt
Class. Today, BGP LU is used to extend the best effort intra domain Class. At the time of writing, BGP LU is used to extend the best-effor
t intra-domain
tunnels to other domains.</t> tunnels to other domains.</t>
<t>Alternatively, BGP CT may also be used to carry the best-effort
<t>Alternatively, BGP CT may also be used to carry the best effort
tunnels. This document reserves the Transport Class ID value 0 to tunnels. This document reserves the Transport Class ID value 0 to
represent "Best Effort Transport Class ID". However, implementations represent the "Best-Effort Transport Class ID". However, implementatio
SHOULD provide configuration to use a different value for this ns
<bcp14>SHOULD</bcp14> provide configuration to use a different value f
or this
purpose. Procedures to manage differences in Transport Class ID purpose. Procedures to manage differences in Transport Class ID
namespaces between domains are provided in <xref namespaces between domains are provided in <xref target="non-agreeing"
target="non-agreeing"/>.</t> format="default"/>.</t>
<t>The "Best-Effort Transport Class ID" value is used in the
<t>The "Best Effort Transport Class ID" value is used in the "Transport Class ID" field of the Transport Class RT
"Transport Class ID" field of Transport Route Target Extended that is attached to the BGP CT route that advertises a
Community that is attached to the BGP CT route that advertises a best-effort tunnel endpoint. Thus, the RT formed is called the "Best-E
best effort tunnel endpoint. The RT thus formed is called the "Best ffort Transport Class RT".</t>
Effort Transport Class Route Target".</t> <t>When a BN or SN receives a BGP CT route with Best-Effort
Transport Class RT as the Mapping Community, the Best-Effort Resolutio
<t>When a BN or SN receives a BGP CT route with Best Effort n Scheme is used for resolving the BGP next hop, and
Transport Class Route Target as the mapping community, the Best the resultant route is installed in the best-effort transport route
effort resolution scheme is used for resolving the BGP next hop, and database. If no best-effort tunnel was found to resolve the BGP next
the resultant route is installed in the best effort transport route hop, the BGP CT route <bcp14>MUST</bcp14> be considered unusable and n
database. If no best effort tunnel was found to resolve the BGP next ot be
hop, the BGP CT route MUST be considered unusable, and not be
propagated further.</t> propagated further.</t>
<t>When a BGP speaker receives an overlay route without any explicit
<t>When a BGP speaker receives an overlay route without any explicit Mapping Community, and absent local policy, the Best-Effort
Mapping Community, and absent local policy, the best effort Resolution Scheme is used for resolving the BGP next hop on the
resolution scheme is used for resolving the BGP next hop on the
route. This behavior is backward compatible to behavior of an route. This behavior is backward compatible to behavior of an
implementation that does not follow procedures described in this implementation that does not follow procedures described in this
document.</t> document.</t>
<t>Implementations <bcp14>MAY</bcp14> provide configuration to selec
<t>Implementations MAY provide configuration to selectively install tively install
BGP CT routes to the Forwarding Information Base (FIB), to provide BGP CT routes to the Forwarding Information Base (FIB) to provide
reachability for control plane peering towards endpoints in other reachability for control-plane peering towards endpoints in other
domains.</t> domains.</t>
</list>
</section>
<section title="Interaction with BGP Attributes Specifying Next Hop Addres </section>
s and Color"> <section anchor="bgp-att" numbered="true" toc="default">
<t>The Tunnel Encapsulation Attribute, described in <xref <name>Interaction with BGP Attributes Specifying Next Hop Address and Co
target="RFC9012"/> can be used to request a specific type of tunnel lor</name>
<t>The Tunnel Encapsulation Attribute, described in <xref target="RFC901
2" format="default"/>, can be used to request a specific type of tunnel
encapsulation. This attribute may apply to BGP service routes or encapsulation. This attribute may apply to BGP service routes or
transport routes, including BGP Classful Transport family routes.</t> transport routes including BGP CT family routes.</t>
<t>It should be noted that in such cases "Transport Class ID/Color" <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 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 needs to be established to determine which Transport Class the route's
next hop should resolve over. This document specifies the following next hop should resolve over. This document specifies the following
order of precedence, more specific scoping of Color preferred to less order of precedence with more-specific scoping of Color preferred to les
specific scoping: <list> s-specific scoping: </t>
<t>Color SubTLV, in Tunnel Encapsulation Attribute.</t> <ul spacing="normal">
<li>
<t>Transport Target Extended community, on BGP CT route.</t> <t>Color sub-TLV in the Tunnel Encapsulation Attribute.</t>
</li>
<t>Color Extended community, on BGP service route.</t> <li>
</list></t> <t>Transport Class RT on a BGP CT route.</t>
</li>
<t>Color specified in the Color subTLV in a TEA is a more specific <li>
<t>Color extended community on a BGP service route.</t>
</li>
</ul>
<t>Color specified in the Color sub-TLV in a TEA is a more-specific
indication of "Transport Class ID/Color" than Mapping Community indication of "Transport Class ID/Color" than Mapping Community
(Transport Target) on a BGP CT transport route, which is in turn is (Transport Class RT) on a BGP CT transport route, which, in turn, is
more specific than a Service route scoped Mapping Community (Color more specific than a service route scoped Mapping Community (Color
Extended community).</t> extended community).</t>
<t>Any BGP attributes or mechanisms defined in future that carry <t>Any BGP attributes or mechanisms defined in future that carry
Transport Class ID/Color on the route are expected to specify the Transport Class ID/Color on the route are expected to specify the
order of precedence relative to the above.</t> order of precedence relative to the above.</t>
</section> </section>
<section numbered="true" toc="default">
<name>Applicability to Flowspec Redirect-to-IP</name>
<section title="Applicability to Flowspec Redirect to IP"> <t>Flowspec routes using redirect-to-IP next hop are described in <xref
<t>Flowspec routes using Redirect to IP next hop is described in <xref target="I-D.ietf-idr-flowspec-redirect-ip" format="default"/>.</t>
target="FLOWSPEC-REDIR-IP"/></t> <t>Such Flowspec BGP routes with redirect-to-IP next hop <bcp14>MAY</bcp
14> be
<t>Such Flowspec BGP routes with Redirect to IP next hop MAY be attached with a Mapping Community (e.g., color:0:100), which allows
attached with a Mapping Community (e.g. Color:0:100), which allows
redirecting the flow traffic over a tunnel to the IP next hop redirecting the flow traffic over a tunnel to the IP next hop
satisfying the desired SLA (e.g. Transport Class color 100).</t> satisfying the desired SLA (e.g., Transport Class color 100).</t>
<t>The Flowspec BGP family acts as just another service that can make us
<t>Flowspec BGP family acts as just another service that can make use e
of BGP CT architecture to achieve Flow based forwarding with SLAs.</t> of the BGP CT architecture to achieve flow-based forwarding with SLAs.</
t>
</section> </section>
<section anchor="IPv6-Applicability" numbered="true" toc="default">
<section anchor="IPv6-Applicability" title="Applicability to IPv6"> <name>Applicability to IPv6</name>
<t>BGP CT procedures apply equally to IPv4 and IPv6 enabled Intra-AS <t>BGP CT procedures apply equally to IPv4- and IPv6-enabled intra-AS
or Inter-AS Option A, B, C network. This section describes or inter-AS option A, B, and C networks. This section describes
applicability of BGP CT to IPv6 at various layers.</t> the applicability of BGP CT to IPv6 at various layers.</t>
<t>A network that is BGP CT enabled supports IPv6 service families (for
<t>A BGP CT enabled network supports IPv6 service families (for
example, AFI/SAFI 2/1 or 2/128) and IPv6 transport signaling protocols example, AFI/SAFI 2/1 or 2/128) and IPv6 transport signaling protocols
like SRTEv6, LDPv6, RSVP-TEv6.</t> like SRTEv6, LDPv6, or RSVP-TEv6.</t>
<t>Procedures in this document also apply to a network with Pure IPv6 <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 core, that uses MPLS forwarding for intra-domain tunnels and inter-AS
links. BGP CTv6 family (AFI/SAFI: 2/76) is used to carry global IPv6 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 address tunnel endpoints in the NLRI. Service family routes (for
example, AFI/SAFI: 1/1, 2/1, 1/128, 2/128) are also advertised with example, AFI/SAFI: 1/1, 2/1, 1/128, and 2/128) are also advertised with
those Global IPv6 addresses as next hop.</t> those Global IPv6 addresses as next hop.</t>
<t>Procedures in this document also apply to a 6PE network with an <t>Procedures in this document also apply to a 6PE network with an
IPv4 core, that uses MPLS forwarding for intra-domain tunnels and IPv4 core, which uses MPLS forwarding for intra-domain tunnels and
Inter-AS links. BGP CTv6 family (AFI/SAFI: 2/76) is used to carry IPv4 inter-AS links. The BGP CTv6 family (AFI/SAFI: 2/76) is used to carry IP
v4
Mapped IPv6 address tunnel endpoints in the NLRI. IPv6 Service family Mapped IPv6 address tunnel endpoints in the NLRI. IPv6 Service family
routes (for example, AFI/SAFI: 2/1, 2/128) are also advertised with routes (for example, AFI/SAFI: 2/1, 2/128) are also advertised with
those IPv4 Mapped IPv6 addresses as next hop.</t> those IPv4 Mapped IPv6 addresses as next hop.</t>
<t>The PE-CE attachment circuits may use IPv4 addresses only, IPv6 <t>The PE-CE attachment circuits may use IPv4 addresses only, IPv6
addresses only, or both IPv4 and IPv6 addresses.</t> addresses only, or both IPv4 and IPv6 addresses.</t>
<t/>
</section> </section>
<section anchor="SRv6-Support" numbered="true" toc="default">
<section anchor="SRv6-Support" title="SRv6 Support"> <name>SRv6 Support</name>
<t>BGP CT family (AFI/SAFI 2/76) may be used to set up inter-domain <t>The BGP CT family (AFI/SAFI 2/76) may be used to set up inter-domain
tunnels of a certain Transport Class, when using Segment Routing over tunnels of a certain Transport Class when using a Segment Routing over
IPv6 (SRv6) data plane on the inter-AS links or as an intra-AS IPv6 (SRv6) data plane on the inter-AS links or as an intra-AS
tunneling mechanism.</t> tunneling mechanism.</t>
<t>Details of SRv6 Endpoint behaviors used by BGP CT and the <t>Details of SRv6 Endpoint behaviors used by BGP CT and the
procedures are specified in a separate document <xref procedures are specified and illustrated in a separate document (see <xr
target="BGP-CT-SRv6"/>, along with illustration. As noted in that ef target="I-D.ietf-idr-bgp-ct-srv6" format="default"/>). As noted in that
document, BGP CT route update for SRv6 includes a BGP attribute document, a BGP CT route update for SRv6 includes a BGP attribute
containing SRv6 SID information (e.g. Prefix SID [RFC9252]) with containing SRv6 SID information (e.g., a BGP Prefix-SID <xref target="RF
Transposition scheme disabled.</t> C9252"/>) with the
Transposition Scheme disabled.</t>
</section> </section>
<section anchor="error-handling" numbered="true" toc="default">
<section anchor="error-handling" title="Error Handling Considerations"> <name>Error-Handling Considerations</name>
<t>If a BGP speaker receives both <xref <t>If a BGP speaker receives both transitive and non-transitive (see <xr
target="tc-rt-t">Transitive</xref> and <xref ef target="tc-rt-t" format="default"></xref> and <xref target="tc-rt-nt" format=
target="tc-rt-nt">Non-Transitive</xref> versions of Transport Class "default"></xref>, respectively) versions of a Transport Class
extended community on a route, only the Transitive one is used.</t> extended community on a route, only the transitive one is used.</t>
<t>If a BGP speaker considers a received "Transport Class" extended <t>If a BGP speaker considers a received "Transport Class" extended
community (Transitive or Non-Transitive version), or any other part of community (the transitive or non-transitive version) or any other part o f
a BGP CT route invalid for some reason, but is able to successfully a BGP CT route invalid for some reason, but is able to successfully
parse the NLRI and attributes, Treat-as-withdraw approach from <xref parse the NLRI and attributes, the treat-as-withdraw approach from <xref
target="RFC7606"/> is used. The route is kept as Unusable, with target="RFC7606" format="default"/> is used. The route is kept as Unusable, wit
h
appropriate diagnostic information, to aid troubleshooting.</t> appropriate diagnostic information, to aid troubleshooting.</t>
</section> </section>
</section> </section>
<section anchor="CTProc" numbered="true" toc="default">
<section anchor="CTProc" title="Illustration of BGP CT Procedures"> <name>Illustration of BGP CT Procedures</name>
<t>This section illustrates BGP CT procedures in an Inter-AS Option C <t>This section illustrates BGP CT procedures in an inter-AS option C
MPLS network.</t> MPLS network.</t>
<t>All illustrations in this document make use of IP address ranges as des
<t>All Illustrations in this document make use of <xref cribed in <xref target="RFC6890" format="default"/>. The range 192.0.2.0/24 is u
target="RFC6890"/> IP address ranges. The range 192.0.2.0/24 is used to sed to
represent transport endpoints like loopback addresses. The range represent transport endpoints like loopback addresses. The range
203.0.113.0/24 is used to represent service route prefixes advertised in 203.0.113.0/24 is used to represent service route prefixes advertised in
AFI/SAFIs: 1/1 or 1/128.</t> AFI/SAFIs: 1/1 or 1/128.</t>
<t>Though this section illustrates the use of IPv4, as described in <xref
<t>Though this section illustrates using IPv4, as described in <xref target="IPv6-Applicability" format="default"/>, these procedures work equally fo
target="IPv6-Applicability"/> these procedures work equally for IPv6 r IPv6
as-well.</t> as well.</t>
<section numbered="true" toc="default">
<section title="Reference Topology"> <name>Reference Topology</name>
<figure title="Multi-Domain BGP CT Network" anchor="CTProcTopo">
<figure title="Multi-Domain BGP CT Network" anchor="CTProcTopo"><artset><artwork <artset>
type="svg"><svg xmlns="http://www.w3.org/2000/svg" version="1.1" height="320" <artwork type="svg">
width="584" viewBox="0 0 584 320" class="diagram" text-anchor="middle" font-fami <svg xmlns="http://www.w3.org/2000/svg" version="1.1" height="320"
ly="monospace" font-size="13px" stroke-linecap="round"> width="560"
<path d="M 128,48 L 128,96" fill="none" stroke="black"/> viewBox="0 0 560 320" class="diagram" text-anchor="middle" font-
<path d="M 144,80 L 144,96" fill="none" stroke="black"/> family="monospace"
<path d="M 144,128 L 144,176" fill="none" stroke="black"/> font-size="13px" stroke-linecap="round">
<path d="M 240,80 L 240,96" fill="none" stroke="black"/> <path d="M 128,48 L 128,96" fill="none" stroke="black" />
<path d="M 240,128 L 240,176" fill="none" stroke="black"/> <path d="M 144,80 L 144,96" fill="none" stroke="black" />
<path d="M 256,48 L 256,96" fill="none" stroke="black"/> <path d="M 144,128 L 144,176" fill="none" stroke="black" />
<path d="M 272,80 L 272,96" fill="none" stroke="black"/> <path d="M 240,80 L 240,96" fill="none" stroke="black" />
<path d="M 272,128 L 272,176" fill="none" stroke="black"/> <path d="M 240,128 L 240,176" fill="none" stroke="black" />
<path d="M 448,80 L 448,96" fill="none" stroke="black"/> <path d="M 256,48 L 256,96" fill="none" stroke="black" />
<path d="M 448,128 L 448,176" fill="none" stroke="black"/> <path d="M 272,80 L 272,96" fill="none" stroke="black" />
<path d="M 464,48 L 464,96" fill="none" stroke="black"/> <path d="M 272,128 L 272,176" fill="none" stroke="black" />
<path d="M 480,80 L 480,96" fill="none" stroke="black"/> <path d="M 448,80 L 448,96" fill="none" stroke="black" />
<path d="M 480,128 L 480,176" fill="none" stroke="black"/> <path d="M 448,128 L 448,176" fill="none" stroke="black" />
<path d="M 568,80 L 568,96" fill="none" stroke="black"/> <path d="M 464,48 L 464,96" fill="none" stroke="black" />
<path d="M 568,128 L 568,176" fill="none" stroke="black"/> <path d="M 480,80 L 480,96" fill="none" stroke="black" />
<path d="M 144,80 L 160,80" fill="none" stroke="black"/> <path d="M 480,128 L 480,176" fill="none" stroke="black" />
<path d="M 224,80 L 240,80" fill="none" stroke="black"/> <path d="M 544,80 L 544,96" fill="none" stroke="black" />
<path d="M 272,80 L 288,80" fill="none" stroke="black"/> <path d="M 544,128 L 544,176" fill="none" stroke="black" />
<path d="M 432,80 L 448,80" fill="none" stroke="black"/> <path d="M 144,80 L 160,80" fill="none" stroke="black" />
<path d="M 480,80 L 496,80" fill="none" stroke="black"/> <path d="M 224,80 L 240,80" fill="none" stroke="black" />
<path d="M 552,80 L 568,80" fill="none" stroke="black"/> <path d="M 272,80 L 288,80" fill="none" stroke="black" />
<path d="M 144,176 L 160,176" fill="none" stroke="black"/> <path d="M 432,80 L 448,80" fill="none" stroke="black" />
<path d="M 224,176 L 240,176" fill="none" stroke="black"/> <path d="M 144,176 L 160,176" fill="none" stroke="black" />
<path d="M 272,176 L 288,176" fill="none" stroke="black"/> <path d="M 224,176 L 240,176" fill="none" stroke="black" />
<path d="M 432,176 L 448,176" fill="none" stroke="black"/> <path d="M 272,176 L 288,176" fill="none" stroke="black" />
<path d="M 480,176 L 496,176" fill="none" stroke="black"/> <path d="M 432,176 L 448,176" fill="none" stroke="black" />
<path d="M 552,176 L 568,176" fill="none" stroke="black"/> <path d="M 120,288 L 192,288" fill="none" stroke="black" />
<path d="M 120,288 L 192,288" fill="none" stroke="black"/> <path d="M 352,288 L 432,288" fill="none" stroke="black" />
<path d="M 352,288 L 448,288" fill="none" stroke="black"/> <path d="M 344,96 L 376,160" fill="none" stroke="black" />
<path d="M 344,96 L 376,160" fill="none" stroke="black"/> <path d="M 336,160 L 368,96" fill="none" stroke="black" />
<path d="M 336,160 L 368,96" fill="none" stroke="black"/> <polygon class="arrowhead" points="440,288 428,282.4 428,293.6"
<polygon class="arrowhead" points="456,288 444,282.4 444,293.6" fill="black" tra fill="black"
nsform="rotate(0,448,288)"/> transform="rotate(0,432,288)" />
<g class="text"> <g class="text">
<text x="132" y="36">[RR26]</text> <text x="132" y="36">[RR26]</text>
<text x="260" y="36">[RR27]</text> <text x="260" y="36">[RR27]</text>
<text x="468" y="36">[RR16]</text> <text x="468" y="36">[RR16]</text>
<text x="192" y="84">[ABR23]</text> <text x="192" y="84">[ABR23]</text>
<text x="360" y="84">[ASBR21]-[ASBR13]</text> <text x="360" y="84">[ASBR21]-[ASBR13]</text>
<text x="524" y="84">[PE11]</text> <text x="512" y="84">-[PE11]</text>
<text x="80" y="116">[CE41]-[PE25]-[P28]</text> <text x="80" y="116">[CE41]-[PE25]-[P28]</text>
<text x="256" y="116">[P29]</text> <text x="256" y="116">[P29]</text>
<text x="464" y="116">[P15]</text> <text x="464" y="116">[P15]</text>
<text x="556" y="116">[CE31]</text> <text x="532" y="116">[CE31]</text>
<text x="192" y="180">[ABR24]</text> <text x="192" y="180">[ABR24]</text>
<text x="360" y="180">[ASBR22]-[ASBR14]</text> <text x="360" y="180">[ASBR22]-[ASBR14]</text>
<text x="524" y="180">[PE12]</text> <text x="512" y="180">-[PE12]</text>
<text x="56" y="228">:</text> <text x="56" y="228">:</text>
<text x="120" y="228">AS2</text> <text x="120" y="228">AS2</text>
<text x="192" y="228">:</text> <text x="192" y="228">:</text>
<text x="280" y="228">AS2</text> <text x="280" y="228">AS2</text>
<text x="352" y="228">:</text> <text x="352" y="228">:</text>
<text x="528" y="228">:</text> <text x="512" y="228">:</text>
<text x="32" y="244">AS4</text> <text x="32" y="244">AS4</text>
<text x="56" y="244">:</text> <text x="56" y="244">:</text>
<text x="124" y="244">region-1</text> <text x="124" y="244">region-1</text>
<text x="192" y="244">:</text> <text x="192" y="244">:</text>
<text x="276" y="244">region-2</text> <text x="276" y="244">region-2</text>
<text x="352" y="244">:</text> <text x="352" y="244">:</text>
<text x="424" y="244">AS1</text> <text x="424" y="244">AS1</text>
<text x="528" y="244">:</text> <text x="512" y="244">:</text>
<text x="568" y="244">AS3</text> <text x="544" y="244">AS3</text>
<text x="56" y="260">:</text> <text x="56" y="260">:</text>
<text x="192" y="260">:</text> <text x="192" y="260">:</text>
<text x="352" y="260">:</text> <text x="352" y="260">:</text>
<text x="528" y="260">:</text> <text x="512" y="260">:</text>
<text x="52" y="292">203.0.113.41</text> <text x="52" y="292">203.0.113.41</text>
<text x="232" y="292">Traffic</text> <text x="232" y="292">Traffic</text>
<text x="304" y="292">Direction</text> <text x="304" y="292">Direction</text>
<text x="516" y="292">203.0.113.31</text> <text x="500" y="292">203.0.113.31</text>
</g> </g>
</svg> </svg>
</artwork><artwork type="ascii-art"><![CDATA[ </artwork>
<artwork type="ascii-art"><![CDATA[
[RR26] [RR27] [RR16] [RR26] [RR27] [RR16]
| | | | | |
| | | | | |
| +--[ABR23]--+ | +--[ASBR21]-[ASBR13]--+ | +--[PE11]--+ | +--[ABR23]--+ | +--[ASBR21]-[ASBR13]--+ | +-[PE11]+
| | | | | \ / | | | | | | | | | \ / | | | |
[CE41]-[PE25]-[P28] [P29] \/ [P15] [CE31] [CE41]-[PE25]-[P28] [P29] \/ [P15] [CE31]
| | | /\ | | | | | | /\ | | |
| | | / \ | | | | | | / \ | | |
| | | / \ | | | | | | / \ | | |
+--[ABR24]--+ +--[ASBR22]-[ASBR14]--+ +--[PE12]--+ +--[ABR24]--+ +--[ASBR22]-[ASBR14]--+ +-[PE12]+
: AS2 : AS2 : : : AS2 : AS2 : :
AS4 : region-1 : region-2 : AS1 : AS3 AS4 : region-1 : region-2 : AS1 : AS3
: : : : : : : :
203.0.113.41 ---------- Traffic Direction ------------> 203.0.113.31 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 <t>This example shows a provider MPLS network that consists of two
ASes, AS1 and AS2. They are serving customers AS3, AS4 respectively. ASes, AS1 and AS2, that serve customers AS3 and AS4, respectively.
Traffic direction being described is CE41 to CE31. CE31 may request a The traffic direction being described is from CE41 to CE31. CE31 may req
specific SLA (for example, mapped to Gold for this example), when uest a
specific SLA (mapped to Gold for this example), when
traversing these provider networks.</t> traversing these provider networks.</t>
<t>AS2 is further divided into two regions. There are three tunnel <t>AS2 is further divided into two regions. There are three tunnel
domains in provider's space: AS1 uses <xref target="RFC9350">ISIS domains in the provider's space:</t>
Flex-Algo</xref> intra-domain tunnels. AS2 uses RSVP-TE intra-domain <ul>
tunnels. MPLS forwarding is used within these domains and on <li>AS1 uses ISIS Flex-Algo (see<xref target="RFC9350" format="default"
></xref>) intra-domain tunnels. </li>
<li>AS2 uses RSVP-TE intra-domain
tunnels.</li>
</ul>
<t>MPLS forwarding is used within these domains and on
inter-domain links.</t> inter-domain links.</t>
<t>The network exposes two Transport Classes: "Gold" with Transport <t>The network exposes two Transport Classes: "Gold" with Transport
Class ID 100, "Bronze" with Transport Class ID 200. These Transport Class ID 100 and "Bronze" with Transport Class ID 200. These Transport
Classes are provisioned at the PEs and the Border nodes (ABRs, ASBRs) Classes are provisioned at the PEs and the Border nodes (ABRs and ASBRs)
in the network.</t> in the network.</t>
<t>The following tunnels exist for the Gold Transport Class:</t>
<t>The following tunnels exist for Gold Transport Class.<list> <ul spacing="normal">
<li>
<t>PE25_to_ABR23_gold - RSVP-TE tunnel</t> <t>PE25_to_ABR23_gold - RSVP-TE tunnel</t>
</li>
<li>
<t>PE25_to_ABR24_gold - RSVP-TE tunnel</t> <t>PE25_to_ABR24_gold - RSVP-TE tunnel</t>
</li>
<li>
<t>ABR23_to_ASBR22_gold - RSVP-TE tunnel</t> <t>ABR23_to_ASBR22_gold - RSVP-TE tunnel</t>
</li>
<li>
<t>ASBR13_to_PE11_gold - SRTE tunnel</t> <t>ASBR13_to_PE11_gold - SRTE tunnel</t>
</li>
<li>
<t>ASBR14_to_PE11_gold - SRTE tunnel</t> <t>ASBR14_to_PE11_gold - SRTE tunnel</t>
</list></t> </li>
</ul>
<t>The following tunnels exist for Bronze Transport Class.<list> <t>The following tunnels exist for Bronze Transport Class:</t>
<ul spacing="normal">
<li>
<t>PE25_to_ABR23_bronze - RSVP-TE tunnel</t> <t>PE25_to_ABR23_bronze - RSVP-TE tunnel</t>
</li>
<li>
<t>ABR23_to_ASBR21_bronze - RSVP-TE tunnel</t> <t>ABR23_to_ASBR21_bronze - RSVP-TE tunnel</t>
</li>
<li>
<t>ABR23_to_ASBR22_bronze - RSVP-TE tunnel</t> <t>ABR23_to_ASBR22_bronze - RSVP-TE tunnel</t>
</li>
<li>
<t>ABR24_to_ASBR21_bronze - RSVP-TE tunnel</t> <t>ABR24_to_ASBR21_bronze - RSVP-TE tunnel</t>
</li>
<t>ASBR13_to_PE12_bronze - ISIS FlexAlgo tunnel</t> <li>
<t>ASBR13_to_PE12_bronze - ISIS Flex-Algo tunnel</t>
<t>ASBR14_to_PE11_bronze - ISIS FlexAlgo tunnel</t> </li>
</list></t> <li>
<t>ASBR14_to_PE11_bronze - ISIS Flex-Algo tunnel</t>
<t>These tunnels are either provisioned or auto-discovered to belong </li>
to Transport Classes 100 or 200.</t> </ul>
<t>These tunnels are either provisioned or autodiscovered to belong
to Transport Class IDs 100 or 200.</t>
</section> </section>
<section numbered="true" toc="default">
<name>Service Layer Route Exchange</name>
<section title="Service Layer Route Exchange"> <t>Service nodes PE11 and PE12 negotiate service families (AFI/SAFIs: 1/
<t>Service nodes PE11, PE12 negotiate service families (AFI: 1 and 1 and
SAFIs 1, 128) on the BGP session with RR16. Service helpers RR16 and 1/128) on the BGP session with RR16. Service helpers RR16 and
RR26 exchange these service routes with next hop unchanged over a RR26 exchange these service routes with the next hop unchanged over a
multihop EBGP session between the two AS. PE25 negotiates service multihop EBGP session between the two ASes. PE25 negotiates service
families (AFI: 1 and SAFIs 1, 128) with RR26.</t> families (AFI/SAFIs: 1/1 and 1/128) with RR26.</t>
<t>The PEs see each other as the next hop in the BGP UPDATE message for
<t>The PEs see each other as next hop in the BGP Update for the the
service family routes. BGP ADD-PATH send and receive is enabled on service family routes. BGP ADD-PATH send and receive are enabled on
both directions on the EBGP multihop session between RR16 and RR26 for both directions on the EBGP multihop session between RR16 and RR26 for
AFI:1 and SAFIs 1, 128. BGP ADD-PATH send is negotiated in the RR to AFI/SAFIs: 1/1 and 1/128. BGP ADD-PATH send is negotiated in the RR to
PE direction in each AS. This is to avoid path hiding of service PE direction in each AS. This is to avoid the path-hiding service
routes at RR; i.e., AFI/SAFI 1/1 routes advertised by both PE11 and routes at the RR, i.e., AFI/SAFI 1/1 routes advertised by both PE11 and
PE12. Or, AFI/SAFI 1/128 routes originated by both PE11 and PE12 using PE12 or AFI/SAFI 1/128 routes originated by both PE11 and PE12 using
same RD.</t> the same RD.</t>
<t>Forwarding happens using service routes installed at service nodes <t>Forwarding happens using service routes installed at service nodes
PE25, PE11, PE12 only. Service routes received from CEs are not PE25, PE11, and PE12 only. Service routes received from CEs are not
present in any other nodes' FIB in the network.</t> 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 <t>As an example, CE31 advertises a route for prefix 203.0.113.31 with
next hop as self to PE11, PE12. CE31 can attach a Mapping Community the next hop as itself to PE11 and PE12. CE31 can attach a Mapping Commu
Color:0:100 on this route, to indicate its request for Gold SLA. Or, nity
color:0:100 on this route to indicate its request for a Gold SLA. Or,
PE11 can attach the same using locally configured policies.</t> PE11 can attach the same using locally configured policies.</t>
<t>Consider CE31 getting VPN service from PE11. The
<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 RD1:203.0.113.31 route is readvertised in AFI/SAFI 1/128 by PE11 with
next hop self (192.0.2.11) and label V-L1, to RR16 with the Mapping the next hop set to itself (192.0.2.11) and label V-L1 to RR16 with the
Community Color:0:100 attached. RR16 advertises this route with BGP Mapping
ADD-PATH ID to RR26 which readvertises to PE25 with next hop Community color:0:100 attached. RR16 advertises this route with the BGP
ADD-PATH ID set to RR26, which readvertises to PE25 with the next hop
unchanged. Now, PE25 can resolve the PNH 192.0.2.11 using transport unchanged. Now, PE25 can resolve the PNH 192.0.2.11 using transport
routes received in BGP CT or BGP LU.</t> routes received in BGP CT or BGP LU.</t>
<t>Using BGP ADD-PATH, service routes advertised by PE11 and PE12 for <t>Using BGP ADD-PATH, service routes advertised by PE11 and PE12 for
AFI:1 SAFIs 1, 128 reach PE25 via RR16, RR26 with the next hop AFI/SAFIs: 1/1 and 1/128 reach PE25 via RR16, RR26 with the next hop
unchanged, as PE11 or PE12.</t> 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
<t>The IP FIB at PE25 VRF will have a route for 203.0.113.31 with a next hop when resolved that points to a Gold tunnel in the ingress
next hop when resolved, that points to a Gold tunnel in ingress
domain.</t> domain.</t>
</section> </section>
<section numbered="true" toc="default">
<section title="Transport Layer Route Propagation"> <name>Transport Layer Route Propagation</name>
<t>Egress nodes PE11, PE12 negotiate BGP CT family with transport <t>Egress nodes PE11 and PE12 negotiate a BGP CT family with transport
ASBRs ASBR13, ASBR14. These egress nodes originate BGP CT routes for ASBRs ASBR13 and ASBR14. These egress nodes originate BGP CT routes for
tunnel endpoint addresses, that are advertised as next hop in BGP tunnel endpoint addresses that are advertised as a next hop in BGP
service routes. In this example, both PEs participate in transport service routes. In this example, both PEs participate in Transport
classes Gold and Bronze. The protocol procedures are explained using Classes Gold and Bronze. The protocol procedures are explained using
the Gold SLA transport plane and the Bronze SLA transport plane is the Gold SLA transport plane; the Bronze SLA transport plane is
used to highlight the path hiding aspects.</t> used to highlight the path-hiding aspects.</t>
<t>For Gold tunnels, PE11 is provisioned with Transport Class having TC
<t>PE11 is provisioned with transport class 100, RD value ID 100, RD value
192.0.2.11:100 and a transport-target:0:100 for Gold tunnels. And a 192.0.2.11:100, and a transport-target:0:100. For Bronze tunnels, PE11 i
Transport class 200 with RD value 192.0.2.11:200, and transport route s provisioned with
target 0:200 for Bronze tunnels. Similarly, PE12 is provisioned with Transport Class 200, RD value 192.0.2.11:200, and transport-target:0:200
transport class 100, RD value 192.0.2.12:100 and a .
transport-target:0:100 for Gold tunnels. And transport class 200, RD Similarly, for Gold tunnels, PE12 is provisioned with
value 192.0.2.12:200 with transport-target:0:200 for Bronze tunnels. Transport Class having TC ID 100, RD value 192.0.2.12:100, and a
Note that in this example, the BGP CT routes carry only the transport transport-target:0:100. For Bronze tunnels, PE12 is provisioned with Tra
class route target, and no IP address format route target.</t> nsport Class having TC ID 200, RD
value 192.0.2.12:200, and transport-target:0:200.
Note that, in this example, the BGP CT routes carry only the 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 <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, BGP speakers when the route is readvertised to the ingress node. Thus,
the RD can be used to identify the originator (unique RD provisioned) the RD can be used to identify the originator (unique RD provisioned)
or set of originators (RD reused on multiple nodes).</t> or set of originators (RD reused on multiple nodes).</t>
<t>Similarly, these Transport Classes are also configured on ASBRs,
<t>Similarly, these transport classes are also configured on ASBRs, ABRs, and PEs with same Transport Class RT and unique RDs.</t>
ABRs and PEs with same Transport Route Target and unique RDs.</t>
<t>ASBR13 and ASBR14 negotiate BGP CT family with transport ASBRs <t>ASBR13 and ASBR14 negotiate BGP CT family with transport ASBRs
ASBR21, ASBR22 in neighboring AS. ASBR21, ASBR22 negotiate BGP CT ASBR21 and ASBR22 in neighboring ASes. ASBR21 and ASBR22 negotiate BGP C
family with RR27 in region 2, which reflects BGP CT routes to ABR23, T
ABR24. ABR23, ABR24 negotiate BGP CT family with Ingress node PE25 in family with RR27 in region 2, which reflects BGP CT routes to ABR23 and
region 1. BGP LU family is also negotiated on these sessions alongside ABR24. ABR23 and ABR24 negotiate BGP CT family with ingress node PE25 in
BGP CT family. BGP LU carries "best effort" transport class routes, region 1. The BGP LU family is also negotiated on these sessions alongsi
BGP CT carries Gold, Bronze transport class routes.</t> de the
BGP CT family. The BGP LU family carries Best-Effort Transport Class rou
tes;
BGP CT carries Gold and Bronze Transport Class routes.</t>
<t>PE11 is provisioned to originate a BGP CT route for endpoint PE11, <t>PE11 is provisioned to originate a BGP CT route for endpoint PE11,
with Gold SLA. This route is sent with NLRI RD prefix 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 and a route 192.0.2.11:100:192.0.2.11, Label B-L0, next hop 192.0.2.11, and a Route
target extended community transport-target:0:100. Label B-L0 can Target extended community transport-target:0:100. Label B-L0 can
either be Implicit Null (Label 3) or an UHP label.</t> either be Implicit NULL (Label 3) or a UHP label.</t>
<t>This route is received by ASBR13 and it resolves over the tunnel <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 ASBR13_to_PE11_gold. The route is then readvertised by ASBR13 in BGP
CT family to ASBRs ASBR21, ASBR22 according to export policy. This 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, route is sent with same NLRI RD prefix 192.0.2.11:100:192.0.2.11,
Label B-L1, next hop self, and transport-target:0:100. MPLS swap route Label B-L1, the next hop set to itself, and transport-target:0:100. An M PLS swap route
is installed at ASBR13 for B-L1 with a next hop pointing to is installed at ASBR13 for B-L1 with a next hop pointing to
ASBR13_to_PE11_gold tunnel.</t> ASBR13_to_PE11_gold tunnel.</t>
<t>Similarly, ASBR14 also receives a BGP CT route for <t>Similarly, ASBR14 also receives a BGP CT route for
192.0.2.11:100:192.0.2.11 from PE11 and it resolves over the tunnel 192.0.2.11:100:192.0.2.11 from PE11, and it resolves over the tunnel
ASBR14_to_PE11_gold. The route is then readvertised by ASBR14 in BGP ASBR14_to_PE11_gold. The route is then readvertised by ASBR14 in the BGP
CT family to ASBRs ASBR21, ASBR22 according to export policy. This CT family to ASBRs 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, route is sent with the same NLRI RD prefix 192.0.2.11:100:192.0.2.11,
Label B-L2, next hop self, and transport-target:0:100. MPLS swap route Label B-L2, next hop 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 is installed at ASBR14 for B-L1 with a next hop pointing to
ASBR14_to_PE11_gold tunnel.</t> ASBR14_to_PE11_gold tunnel.</t>
<t>In the Bronze plane, the BGP CT route with a Bronze SLA to endpoint P
<t>In the Bronze plane, BGP CT route with Bronze SLA to endpoint PE11 E11
is originated by PE11 with a NLRI containing RD prefix is originated by PE11 with an NLRI containing RD prefix
192.0.2.11:200:192.0.2.11, and appropriate label. The use of distinct 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 RDs for Gold and Bronze allows both Gold and Bronze advertisements to
traverse path selection pinchpoints without any path hiding at RRs or traverse path-selection pinch points without any path hiding at RRs or
ASBRs. And route target extended community transport-target:0:200 lets ASBRs. And Route Target extended community transport-target:0:200 lets
the route resolve over Bronze tunnels in the network, similar to the the route resolve over Bronze tunnels in the network, similar to the
process being described for Gold SLA path.</t> process being described for the Gold SLA path.</t>
<t>Moving back to the Gold plane, ASBR21 receives the Gold SLA BGP CT <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 routes for NLRI RD prefix 192.0.2.11:100:192.0.2.11 over the single-hop
hop EBGP sessions from ASBR13, ASBR14, and can compute ECMP/FRR EBGP sessions from ASBR13 and ASBR14 and can compute ECMP/FRR
towards them. ASBR21 readvertises BGP CT route for towards them. ASBR21 readvertises the BGP CT route for
192.0.2.11:100:192.0.2.11 with next hop self (loopback address 192.0.2.11:100:192.0.2.11 with a next hop set to itself (loopback addres
192.0.2.21) to RR27, advertising a new label B-L3. An MPLS swap route s
is installed for label B-L3 at ASBR21 to swap to received label B-L1, 192.0.2.21) to RR27, advertising a new label: B-L3. An MPLS swap route
B-L2 and forward to ASBR13, ASBR14 respectively, this is an ECMP is installed for label B-L3 at ASBR21 to swap to received labels B-L1 an
route. RR27 readvertises this BGP CT route to ABR23, ABR24 with label d
B-L2 and forward to ASBR13 and ASBR14 respectively; this is an ECMP
route. RR27 readvertises this BGP CT route to ABR23 and ABR24 with the l
abel
and next hop unchanged.</t> and next hop unchanged.</t>
<t>Similarly, ASBR22 receives BGP CT route 192.0.2.11:100:192.0.2.11 <t>Similarly, ASBR22 receives BGP CT route 192.0.2.11:100:192.0.2.11
over the single hop EBGP sessions from ASBR13, ASBR14, and over the single-hop EBGP sessions from ASBR13 and ASBR14, and it
readvertises with next hop self (loopback address 192.0.2.22) to RR27, readvertises with the next hop set to itself (loopback address 192.0.2.2
advertising a new label B-L4. An MPLS swap route is installed for 2) to RR27,
label B-L4 at ASBR22 to swap to received label B-L1, B-L2 and forward advertising a new label: B-L4. An MPLS swap route is installed for
to ASBR13, ASBR14 respectively. RR27 readvertises this BGP CT route label B-L4 at ASBR22 to swap to received labels B-L1 and B-L2 and forwar
also to ABR23, ABR24 with label and next hop unchanged.</t> d
to ASBR13 and ASBR14, respectively. RR27 also readvertises this BGP CT r
<t>BGP ADD-PATH is enabled for BGP CT family on the sessions between oute
RR27 and ASBRs, ABRs such that routes for 192.0.2.11:100:192.0.2.11 to ABR23 and ABR24 with the label and next hop unchanged.</t>
with the next hops ASBR21 and ASBR22 are reflected to ABR23, ABR24 <t>BGP ADD-PATH is enabled for the BGP CT family on the sessions between
RR27 and 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 and ABR24
without any path hiding. Thus, ABR23 is given visibility of both without any path hiding. Thus, ABR23 is given visibility of both
available next hops for Gold SLA.</t> available next hops for the Gold SLA.</t>
<t>ABR23 receives the route with next hop 192.0.2.21 and label B-L3 from
<t>ABR23 receives the route with next hop 192.0.2.21, label B-L3 from RR27. The transport-target:0:100 on this route acts as
RR27. The route target "transport-target:0:100" on this route acts as the Mapping Community and instructs ABR23 to strictly resolve the next
Mapping Community, and instructs ABR23 to strictly resolve the next hop using routes in TC 100 TRDB only. ABR23 is unable to find a
hop using transport class 100 routes only. ABR23 is unable to find a route for 192.0.2.21 in the TC 100 TRDB. Thus, it considers this
route for 192.0.2.21 with transport class 100. Thus, it considers this
route unusable and does not propagate it further. This prunes ASBR21 route unusable and does not propagate it further. This prunes ASBR21
from Gold SLA tunneled path.</t> from the Gold SLA tunneled path.</t>
<t>ABR23 also receives the route with next hop 192.0.2.22 and label B-L4
<t>ABR23 also receives the route with next hop 192.0.2.22, label B-L4 from RR27. The transport-target:0:100 on this route
from RR27. The route target "transport-target:0:100" on this route acts as the Mapping Community and instructs ABR23 to strictly resolve th
acts as Mapping Community, and instructs ABR23 to strictly resolve the e
next hop using transport class 100 routes only. ABR23 successfully next hop using routes in TC 100 TRDB only. ABR23 successfully
resolves the next hop to point to ABR23_to_ASBR22_gold tunnel. ABR23 resolves the next hop to point to ABR23_to_ASBR22_gold tunnel. ABR23
readvertises this BGP CT route with next hop self (loopback address readvertises this BGP CT route with the next hop set to itself (loopback
192.0.2.23) and a new label B-L5 to PE25. Swap route for B-L5 is address
installed by ABR23 to swap to label B-L4, and forward into 192.0.2.23) and a new label B-L5 to PE25. A swap route for B-L5 is
installed by ABR23 to swap to label B-L4 and forward into
ABR23_to_ASBR22_gold tunnel.</t> ABR23_to_ASBR22_gold tunnel.</t>
<t>PE25 receives the BGP CT route for prefix 192.0.2.11:100:192.0.2.11 <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 and transport-target:0:100 from with label B-L5, next hop 192.0.2.23, and transport-target:0:100 from
RR26. And it similarly resolves the next hop 192.0.2.23 over transport RR26. It similarly resolves the next hop 192.0.2.23 over transport
class 100, pushing labels associated with PE25_to_ABR23_gold class 100, pushing labels associated with PE25_to_ABR23_gold
tunnel.</t> tunnel.</t>
<t>In this manner, the Gold transport LSP "ASBR13_to_PE11_gold" in the <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 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 ingress domain, to create an end-to-end Gold SLA path. MPLS swap
routes are installed at ASBR13, ASBR22 and ABR23, when propagating the routes are installed at ASBR13, ASBR22, and ABR23, when propagating the
PE11 BGP CT Gold transport class route 192.0.2.11:100:192.0.2.11 with PE11 BGP CT Gold Transport Class route 192.0.2.11:100:192.0.2.11 with
next hop self towards PE25.</t> next hop set to itself towards PE25.</t>
<t>Thus formed, the BGP CT LSP originates in PE25 and terminates in
<t>The BGP CT LSP thus formed, originates in PE25, and terminates in ASBR13 (assuming PE11 advertised Implicit NULL), traversing over the
ASBR13 (assuming PE11 advertised Implicit Null), traversing over the
Gold underlay LSPs in each domain. ASBR13 uses UHP to stitch the BGP 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, CT LSP into the "ASBR13_to_PE11_gold" LSP to traverse the last domain,
thus satisfying Gold SLA end-to-end.</t> thus satisfying Gold SLA end-to-end.</t>
<t>When PE25 receives service routes from RR26 with next hop <t>When PE25 receives service routes from RR26 with next hop
192.0.2.11 and mapping community Color:0:100, it resolves over this 192.0.2.11 and 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, and BGP CT route 192.0.2.11:100:192.0.2.11. Thus, pushing label B-L5 and
pushing as top label the labels associated with PE25_to_ABR23_gold pushing as the top label the labels associated with PE25_to_ABR23_gold
tunnel.</t> tunnel.</t>
</section> </section>
<section numbered="true" toc="default">
<section title="Data Plane View"> <name>Data Plane View</name>
<section title="Steady State"> <section numbered="true" toc="default">
<name>Steady State</name>
<t>This section describes how the data plane looks in steady <t>This section describes how the data plane looks in steady
state.</t> state.</t>
<t>CE41 transmits an IP packet with the destination 203.0.113.31. On
<t>CE41 transmits an IP packet with destination as 203.0.113.31. On
receiving this packet, PE25 performs a lookup in the IP FIB receiving this packet, PE25 performs a lookup in the IP FIB
associated with the CE41 interface. This lookup yields the service 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 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 labels for PE25_to_ABR23_gold tunnel. Thus, PE25 encapsulates the IP
packet in an MPLS packet with label V-L1 (innermost), B-L5, and top packet in an MPLS packet with labels V-L1 (innermost), B-L5, and top
label as PE25_to_ABR23_gold tunnel. This MPLS packet is thus label PE25_to_ABR23_gold tunnel. This MPLS packet is thus
transmitted to ABR23 using Gold SLA.</t> transmitted to ABR23 using the Gold SLA.</t>
<t>ABR23 decapsulates the packet received on PE25_to_ABR23_gold <t>ABR23 decapsulates the packet received on PE25_to_ABR23_gold
tunnel as required, and finds the MPLS packet with label B-L5. It tunnel as 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 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, and pushes the top the route that swaps label B-L5 with label B-L4 and pushes the top
label provided by ABR23_to_ASBR22_gold tunnel. Thus, ABR23 transmits label provided by ABR23_to_ASBR22_gold tunnel. Thus, ABR23 transmits
the MPLS packet with label B-L4 to ASBR22, on a tunnel that the MPLS packet with label B-L4 to ASBR22 on a tunnel that
satisfies Gold SLA.</t> satisfies the Gold SLA.</t>
<t>ASBR22 similarly performs a lookup for label B-L4 in the global MPL
<t>ASBR22 similarly performs a lookup for label B-L4 in global MPLS S
FIB, finds the route that swaps label B-L4 with label B-L2, and FIB, finds the route that swaps label B-L4 with label B-L2, and
forwards to ASBR13 over the directly connected MPLS-enabled forwards it to ASBR13 over the directly connected MPLS-enabled
interface. This interface is a common resource not dedicated to any interface. This interface is a common resource not dedicated to any
specific transport class, in this example.</t> specific Transport Class, in this example.</t>
<t>ASBR13 receives the MPLS packet with label B-L2 and performs a
<t>ASBR13 receives the MPLS packet with label B-L2, and performs a lookup in the MPLS FIB, finds the route that pops label B-L2, and push
lookup in MPLS FIB, finds the route that pops label B-L2, and pushes es
labels associated with ASBR13_to_PE11_gold tunnel. This transmits labels associated with ASBR13_to_PE11_gold tunnel. This transmits
the MPLS packet with VPN label V-L1 to PE11 using a tunnel that the MPLS packet with VPN label V-L1 to PE11 using a tunnel that
preserves Gold SLA in AS 1.</t> preserves the Gold SLA in AS 1.</t>
<t>PE11 receives the MPLS packet with V-L1 and performs VPN
<t>PE11 receives the MPLS packet with V-L1, and performs VPN forwarding, thus transmitting the original IP payload from CE41 to
forwarding. Thus transmitting the original IP payload from CE41 to CE31. The payload has traversed path satisfying the Gold SLA
CE31. The payload has traversed path satisfying Gold SLA
end-to-end.</t> end-to-end.</t>
</section> </section>
<section numbered="true" toc="default">
<section title="Local Repair of Primary Path"> <name>Local Repair of Primary Path</name>
<t>This section describes how the data plane at ASBR22 reacts when <t>This section describes how the data plane at ASBR22 reacts when
the link between ASBR22 and ASBR13 experiences a failure, and an the link between ASBR22 and ASBR13 experiences a failure and an
alternate path exists.</t> alternate path exists.</t>
<t>Assuming the ASBR22_to_ASBR13 link goes down, traffic with
<t>Assuming ASBR22_to_ASBR13 link goes down, such that traffic with a Gold SLA going to PE11 will need repair. ASBR22 has an alternate BGP
Gold SLA going to PE11 needs repair. ASBR22 has an alternate BGP CT CT
route for 192.0.2.11:100:192.0.2.11 from ASBR14. This has been route for 192.0.2.11:100:192.0.2.11 from ASBR14. This has been
preprogrammed in forwarding by ASBR22 as FRR backup next hop for 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 label B-L4. This allows the Gold SLA traffic to be locally repaired
at ASBR22 without the failure event propagated in the BGP CT at ASBR22 without the failure event propagated in the BGP CT
network. In this case, ingress node PE25 will not know there was a network. In this case, ingress node PE25 will not know there was a
failure, and traffic restoration will be independent of prefix scale failure, and traffic restoration will be independent of prefix scale
(PIC).</t> (PIC).</t>
</section> </section>
<section numbered="true" toc="default">
<section title="Absorbing Failure of Primary Path: Fallback to Best Effo <name>Absorbing Failure of the Primary Path: Fallback to Best-Effort T
rt Tunnels "> unnels</name>
<t>This section describes how the data plane reacts when a Gold path <t>This section describes how the data plane reacts when a Gold path
experiences a failure, but no alternate path exists.</t> experiences a failure but no alternate path exists.</t>
<t>Assume tunnel ABR23_to_ASBR22_gold goes down, such that now no <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 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. route for RD prefix 192.0.2.11:100:192.0.2.11 unusable at ABR23.
This makes ABR23 send a BGP withdrawal for 192.0.2.11:100:192.0.2.11 This makes ABR23 send a BGP withdrawal for 192.0.2.11:100:192.0.2.11
to PE25.</t> to PE25.</t>
<t>The withdrawal for 192.0.2.11:100:192.0.2.11 allows PE25 to react <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 to the loss of the Gold path to 192.0.2.11. Assuming PE25 is
provisioned to use best effort transport class as the backup path, provisioned to use a Best-Effort Transport Class as the backup path,
this withdrawal of BGP CT route allows PE25 to adjust the next hop this withdrawal of a BGP CT route allows PE25 to adjust the next hop
of the VPN Service-route to push the labels provided by the BGP LU of the VPN service route to push the labels provided by the BGP LU
route. That repairs the traffic to go via the best effort path. PE25 route. That repairs the traffic to go via the best-effort path. PE25
can also be provisioned to use Bronze transport class as the backup can also be provisioned to use the Bronze Transport Class as the backu
p
path. The repair will happen in similar manner in that case 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 <t>Traffic repair to absorb the failure happens at ingress node
PE25, in a service prefix scale independent manner. This is called PE25 in a service prefix scale independent manner (PIC). The repair ti
PIC. The repair time will be proportional to time taken for withdrawin me will be proportional to time taken for withdrawing
g
the BGP CT route.</t> the BGP CT route.</t>
<t>These examples demonstrate the various levels of fail-safe
<t>These examples demonstrate the various levels of failsafe
mechanisms available to protect traffic in a BGP CT network.</t> mechanisms available to protect traffic in a BGP CT network.</t>
</section> </section>
</section> </section>
</section> </section>
<section numbered="true" toc="default">
<section title="Scaling Considerations"> <name>Scaling Considerations</name>
<section anchor="secure-propagate" <section anchor="secure-propagate" numbered="true" toc="default">
title="Avoiding Unintended Spread of BGP CT Routes Across Domains <name>Avoiding Unintended Spread of BGP CT Routes Across Domains</name>
"> <t><xref target="RFC8212" format="default"/> suggests BGP speakers r
<list> equire explicit
<t><xref target="RFC8212"/> suggests BGP speakers require explicit
configuration of both BGP Import and Export Policies in order to configuration of both BGP Import and Export Policies in order to
receive or send routes over EBGP sessions.</t> receive or send routes over EBGP sessions.</t>
<t>It is recommended to follow this for BGP CT routes. It will
<t>It is recommended to follow this for BGP CT routes. It will
prohibit unintended advertisement of transport routes throughout the prohibit unintended advertisement of transport routes throughout the
BGP CT transport domain, which may span across multiple AS domains. BGP CT transport domain, which may span across multiple AS domains.
This will conserve usage of MPLS label and next hop resources in the This will conserve usage resources for MPLS labels and next hops in th e
network. An ASBR of a domain can be provisioned to allow routes with network. An ASBR of a domain can be provisioned to allow routes with
only the Transport Route Targets that are required by SNs in the only the Transport Class RTs that are required by SNs in the
domain.</t> domain.</t>
</list>
</section> </section>
<section numbered="true" toc="default">
<name>Constrained Distribution of PNHs to SNs (On-Demand Next Hop)</name
>
<t>This section describes how the number of Protocol Next Hops (PNHs
)
advertised to an SN or BN can be constrained using BGP Classful
Transport and RTC (see <xref target="RFC4684" format="default"></xref>
.</t>
<section title="Constrained Distribution of PNHs to SNs (On-Demand Next Ho <t>An egress SN <bcp14>MAY</bcp14> advertise a BGP CT route for RD:e
p)"> SN with two
<list> Route Targets: transport-target:0:&lt;TC&gt; and an RT carrying
<t>This section describes how the number of Protocol Next hops &lt;eSN&gt;:&lt;TC&gt;, where TC is the Transport Class identifier
advertised to a SN or BN can be constrained using BGP Classful and eSN is the IP address used by the SN as BGP next hop in its servic
Transport and <xref target="RFC4684">Route Target Constrain e
(RTC)</xref>.</t>
<t>An egress SN MAY advertise a BGP CT route for RD:eSN with two
Route Targets: transport-target:0:&lt;TC&gt; and a RT carrying
&lt;eSN&gt;:&lt;TC&gt;, where TC is the Transport Class identifier,
and eSN is the IP address used by SN as BGP next hop in its service
route advertisements.</t> route advertisements.</t>
<t>Note that such use of the IP-address-specific route target
<t>Note that such use of the IP address specific route target
&lt;eSN&gt;:&lt;TC&gt; is optional in a BGP CT network. It is &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 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 the transport route for an egress node eSN to only the set of
ingress nodes that need it. When only RT of ingress nodes that need it. When only the RT of
transport-target:0:&lt;TC&gt; is used, the pruning happens in transport-target:0:&lt;TC&gt; is used, the pruning happens in
granularity of Transport Class ID (Color), and not BGP next hop; a granularity of Transport Class ID (Color), not BGP next hop; a
BGP CT route will only be advertised into a domain with at least one BGP CT route will only be advertised into a domain with at least one
PE that imports its transport class.</t> PE that imports its Transport Class.</t>
<t>The transport-target:0:&lt;TC&gt; is the new type of route target
<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 BG
(Transport Class RT) defined in this document. It is carried in BGP P
extended community attribute (BGP attribute code 16).</t> extended community attribute (attribute code 16).</t>
<t>The RT carrying &lt;eSN&gt;:&lt;TC&gt; <bcp14>MAY</bcp14> be an I
<t>The RT carrying &lt;eSN&gt;:&lt;TC&gt; MAY be an IP-address P-address-specific regular RT (attribute code 16), or IPv6-address
specific regular RT (BGP attribute code 16), or IPv6-address specific RT (attribute code 25). It should be noted that the
specific RT (BGP attribute code 25). It should be noted that the
Local Administrator field of these RTs can only carry two octets of Local Administrator field of these RTs can only carry two octets of
information, and thus the &lt;TC&gt; field in this approach is information; thus, the &lt;TC&gt; field in this approach is
limited to a 2 octets value. Future protocol extensions work is limited to a 2-octet value. Future protocol extension work is
needed to define a BGP CCA that can accomodate an IPv4/IPv6 address needed to define a BGP CCA that can accommodate an IPv4/IPv6 address
along with a 4 octet Local Administrator field.</t> along with a 4-octet Local Administrator field.</t>
<t>An ingress SN <bcp14>MAY</bcp14> import BGP CT routes with a Rout
<t>An ingress SN MAY import BGP CT routes with Route Target carrying e Target carrying
&lt;eSN&gt;:&lt;TC&gt;. The ingress SN may learn the eSN values &lt;eSN&gt;:&lt;TC&gt;. The ingress SN may learn the eSN values
either by configuration, or it may discover them from the BGP next by configuration or it may discover them from the BGP next
hop field in the BGP VPN service routes received from eSN. A BGP hop field in the BGP VPN service routes received from the eSN. A BGP
ingress SN receiving a BGP service route with next hop of eSN ingress SN receiving a BGP service route with a next hop of eSN
generates a RTC route for Route Target prefix &lt;Origin generates an RTC route for Route Target prefix &lt;Origin
ASN&gt;:&lt;eSN&gt;/[80|176] in order to learn BGP CT transport ASN&gt;:&lt;eSN&gt;/[80|176] in order to learn BGP CT transport
routes to reach eSN. This allows constrained distribution of the routes to reach eSN. This allows constrained distribution of the
transport routes to the PNHs actually required by iSN.</t> transport routes to the PNHs actually required by iSN.</t>
<t>When RTC is in use, as described here, BGP CT routes will be
<t>When RTC is in use as described here, BGP CT routes will be
constrained to follow the same path of propagation as the RTC constrained to follow the same path of propagation as the RTC
routes. Therefore, a BN would learn the RTC routes advertised by routes. Therefore, a BN would learn the RTC routes advertised by
ingress SNs and propagate further. This will allow constraining ingress SNs and propagate further. This will allow constraining
distribution of BGP CT routes for a PNH to only the necessary BNs in distribution of BGP CT routes for a PNH to only the necessary BNs in
the network, closer to the egress SN.</t> the network, closer to the egress SN.</t>
<t>When the path of route propagation of BGP CT routes is the same
<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 as the RTC routes, a BN would learn the RTC routes advertised by
ingress SNs and propagate further. This will allow constraining ingress SNs and propagate further. This will allow constraining
distribution of BGP CT routes for a PNH to only the necessary BNs in distribution of BGP CT routes for a PNH to only the necessary BNs in
the network, closer to the egress SN.</t> the network, closer to the egress SN.</t>
<t>This mechanism provides "On-Demand Next Hop" of BGP CT routes,
<t>This mechanism provides "On Demand Next hop" of BGP CT routes, which helps with the scaling of MPLS forwarding state at the SN and
which help with the scaling of MPLS forwarding state at SN and
BN.</t> BN.</t>
<t>However, the amount of state carried in RTC family may become
<t>However, the amount of state carried in RTC family may become
proportional to the number of PNHs in the network. To strike a proportional to the number of PNHs in the network. To strike a
balance, the RTC route advertisements for &lt;Origin balance, the RTC route advertisements for &lt;Origin
ASN&gt;:&lt;eSN&gt;/[80|176] MAY be confined to the BNs in the home ASN&gt;:&lt;eSN&gt;/[80|176] <bcp14>MAY</bcp14> be confined to the BNs in the home
region of an ingress SN, or the BNs of a super core.</t> 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
<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 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 &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 specific RTC requests for specific PNHs. This lets the BN learn
transport routes to all eSN nodes but confine their propagation to transport routes to all eSN nodes but confines their propagation to
ingress SNs.</t> ingress SNs.</t>
</list>
</section>
<section title="Limiting The Visibility Scope of PE Loopback as PNHs"> </section>
<list> <section numbered="true" toc="default">
<t>It may be even more desirable to limit the number of PNHs that <name>Limiting the Visibility Scope of PE Loopback as 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 are globally visible in the network. This is possible using
mechanism described in <xref target="Appendix D"/>, such that the mechanism described in <xref target="Appendix_D" format="default"/
advertisement of PE loopback addresses as next-hop in BGP service >.</t>
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>Such that advertisement of PE loopback addresses as next-hop in <t>Such that advertisement of PE loopback addresses as next hop in
BGP service routes is confined to the region they belong to. An BGP service routes is confined to the region they belong to. An
anycast IP-address called "Context Protocol Nexthop Address" (CPNH) anycast IP-address called "Context Protocol Nexthop Address" (CPNH)
abstracts the SNs in a region from other regions in the network.</t> abstracts the SNs in a region from other regions in the network.</t>
<t>This provides much greater advantage in terms of scaling,
<t>This provides much greater advantage in terms of scaling,
convergence and security. Changes to implement this feature are convergence and security. Changes to implement this feature are
required only on the local region's BNs and RRs, so legacy PE required only on the local region's BNs and RRs, so legacy PE
devices can also benefit from this approach.</t> devices can also benefit from this approach.</t>
</list>
</section> </section>
</section> </section>
<section numbered="true" toc="default">
<section title="Operations and Manageability Considerations"> <name>Operations and Manageability Considerations</name>
<section anchor="mpls-oam" title="MPLS OAM"> <section anchor="mpls-oam" numbered="true" toc="default">
<t>MPLS OAM procedures specified in <xref target="RFC8029"/> also <name>MPLS OAM</name>
apply to BGP Classful Transport.</t> <t>MPLS Operations, Administration, and Maintenance (OAM) procedures spe
cified in <xref target="RFC8029" format="default"/> also
<t>The 'Target FEC Stack' sub-TLV for IPv4 Classful Transport has a apply to BGP CT.</t>
Sub-Type of 31744, and a length of 13. The Value field consists of the <t>The Target FEC Stack sub-TLV for IPv4 BGP CT has a
RD advertised with the Classful Transport prefix, the IPv4 prefix Sub-Type of 31744 and a length of 13. The Value field consists of the
(with trailing 0 bits to make 32 bits in all) and a prefix length RD advertised with the BGP CT prefix, the IPv4 prefix
encoded as shown in <xref target="FECv4"/>.</t> (with trailing 0 bits to make 32 bits in all), and a prefix length
encoded as shown in <xref target="FECv4" format="default"/>.</t>
<figure anchor="FECv4" suppress-title="false" <figure anchor="FECv4">
title="Classful Transport IPv4 FEC"> <name>BGP CT IPv4 FEC</name>
<artwork align="left" xml:space="preserve"> <artwork align="left" name="" type="" alt=""><![CDATA[
0 1 2 3 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 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 | | Route Distinguisher |
| (8 octets) | | (8 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 prefix | | IPv4 prefix |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prefix Length | Must Be Zero | | Prefix Length | Must Be Zero |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork> ]]></artwork>
</figure> </figure>
<t>The Target FEC Stack sub-TLV for IPv6 BGP CT has a
<t>The 'Target FEC Stack' sub-TLV for IPv6 Classful Transport has a Sub-Type of 31745 and a length of 25. The Value field consists of the
Sub-Type of 31745, and a length of 25. The Value field consists of the RD advertised with the BGP CT prefix, the IPv6 prefix
RD advertised with the Classful Transport prefix, the IPv6 prefix
(with trailing 0 bits to make 128 bits in all) and a prefix length (with trailing 0 bits to make 128 bits in all) and a prefix length
encoded as shown in <xref target="FECv6"/>.</t> encoded as shown in <xref target="FECv6" format="default"/>.</t>
<figure anchor="FECv6">
<figure anchor="FECv6" suppress-title="false" <name>BGP CT IPv6 FEC</name>
title="Classful Transport IPv6 FEC"> <artwork align="left" name="" type="" alt=""><![CDATA[
<artwork align="left" xml:space="preserve"> 0 1 2 3
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
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 |
| Route Distinguisher | | (8 octets) |
| (8 octets) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv6 prefix |
| IPv6 prefix | | |
| | | |
| | | |
| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Prefix Length | Must Be Zero |
| Prefix Length | Must Be Zero | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ]]></artwork>
</artwork>
</figure> </figure>
<t>These prefix layouts are inherited from Sections <xref
<t>These prefix layouts are inherited from Sections 3.2.5, 3.2.6 in target="RFC8029" sectionFormat="bare" section="3.2.5"/> and <xref
<xref target="RFC8029"/></t> target="RFC8029" sectionFormat="bare" section="3.2.6"/> of <xref
target="RFC8029" format="default"/>.</t>
</section> </section>
<section anchor="rd-lbl-usage" numbered="true" toc="default">
<section anchor="rd-lbl-usage" <name>Usage of RD and Label-Allocation Modes</name>
title="Usage of Route Distinguisher and Label Allocation Modes">
<t>RDs aid in troubleshooting provider networks that deploy BGP CT, by <t>RDs aid in troubleshooting provider networks that deploy BGP CT, by
uniquely identifying the originator of a route across an uniquely identifying the originator of a route across an
administrative domain that may either span multiple domains within a administrative domain that may either span multiple domains within a
provider network or span closely coordinated provider networks.</t> provider network or span closely coordinated provider networks.</t>
<t>The use of RDs also provides an option for signaling forwarding <t>The use of RDs also provides an option for signaling forwarding
diversity within the same Transport Class. A SN can advertise an EP diversity within the same Transport Class. An SN can advertise an EP
with the same Transport Class in multiple BGP CT routes with unique with the same Transport Class in multiple BGP CT routes with unique
RDs.</t> RDs.</t>
<t>For example, unique "RDx:EP1" prefixes can be advertised by an SN <t>For example, unique "RDx:EP1" prefixes can be advertised by an SN
for an EP1 to different upstream BNs with unique forwarding specific for an EP1 to different upstream BNs with unique forwarding-specific
encapsulation (e.g., Label), in order to collect traffic statistics at encapsulation (e.g., a Label) in order to collect traffic statistics at
the SN for each BN. In absence of RD, duplicated Transport Class/Color the SN for each BN. In the absence of an RD, duplicated Transport Class
/ Color
values will be needed in the transport network to achieve such use values will be needed in the transport network to achieve such use
cases.</t> cases.</t>
<t>The allocation of RDs is done at the point of origin of the BGP CT <t>The allocation of RDs is done at the point of origin of the BGP CT
route. This can either be an Egress SN or a BN. The default RD route. This can be either an egress SN or a BN. The default RD
allocation mode is to use a unique RD per originating node for an EP. 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 This mode allows for the ingress to uniquely identify each originated
path. Alternatively, the same RD may be provisioned for multiple path. Alternatively, the same RD may be provisioned for multiple
originators of the same EP. This mode can be used when the ingress 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> 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 <t>A label is allocated for a BGP CT route when it is advertised with
next hop self by a SN or a BN. An implementation may use different the next hop set to itself by an SN or a BN. An implementation may use d
label allocation modes with BGP CT. The recommended label allocation ifferent
mode is per-prefix as it provides better traffic convergence label-allocation modes with BGP CT. Per-prefix is the recommended label-
properties than per-next hop label allocation mode. Furthermore, BGP allocation
CT offers two flavors for per-prefix label allocation. The first mode as it provides better traffic convergence
flavor assigns a label for each unique "RD, EP". The second flavor properties than a per-NH label-allocation mode. Furthermore, BGP
CT offers two flavors for per-prefix label allocation:</t>
<ul spacing="normal">
<li>The first
flavor assigns a label for each unique "RD, EP".</li>
<li>The second flavor
assigns a label for each unique "Transport Class, EP" while ignoring assigns a label for each unique "Transport Class, EP" while ignoring
the RD.</t> the RD.</li>
</ul>
<t>In a BGP CT network, the number of routes at an Ingress PE is a <t>In a BGP CT network, the number of routes at an ingress PE is a
function of unique EPs multiplied by BNs in the ingress domain that do function of unique EPs multiplied by BNs in the ingress domain that have
next hop self. BGP CT provides flexible RD and Label allocation modes the
next hop set to themselves. BGP CT provides flexible RD and label-alloca
tion modes
to address operational requirements in a multi-domain network. The to address operational requirements in a multi-domain network. The
impacts on the control plane and forwarding behavior for these modes impacts on the control plane and forwarding behavior for these modes
are detailed with an example in <xref target="CTRouteVis">Managing are detailed with an example in <xref target="CTRouteVis" format="defaul
Transport Route Visibility</xref></t> t"></xref>.</t>
</section> </section>
<section anchor="CTRouteVis" numbered="true" toc="default">
<section anchor="CTRouteVis" title="Managing Transport Route Visibility"> <name>Managing Transport-Route Visibility</name>
<t>This section details the usage of BGP CT RD and label allocation <t>This section details the usage of BGP CT RD and label-allocation
modes to calibrate the level of path visibility and the amount of modes to calibrate the level of path visibility and the amount of
route and label scale in a multi-domain network.</t> route and label scale in a multi-domain network.</t>
<t>Consider a multi-domain BGP CT network as illustrated in the <t>Consider a multi-domain BGP CT network as illustrated in the
following <xref target="MultiDomainNetwork"/>:</t> following <xref target="MultiDomainNetwork" format="default"/>:</t>
<figure anchor="MultiDomainNetwork">
<figure title="Managing Transport Route Visibility in Multi Domain Network" anch <name>Managing Transport-Route Visibility in Multi-Domain Networks</na
or="MultiDomainNetwork"><artset><artwork type="svg"><svg xmlns="http://www.w3.o me>
rg/2000/svg" version="1.1" height="400" width="432" viewBox="0 0 432 400" class= <artset>
"diagram" text-anchor="middle" font-family="monospace" font-size="13px" stroke-l <artwork type="svg" name="" align="left" alt=""><svg xmlns="http://w
inecap="round"> ww.w3.org/2000/svg" version="1.1" height="400" width="432" viewBox="0 0 432 400"
<path d="M 80,112 L 80,176" fill="none" stroke="black"/> class="diagram" text-anchor="middle" font-family="monospace" font-size="13px" s
<path d="M 80,208 L 80,272" fill="none" stroke="black"/> troke-linecap="round">
<path d="M 136,80 L 136,96" fill="none" stroke="black"/> <path d="M 80,112 L 80,176" fill="none" stroke="black"/>
<path d="M 136,128 L 136,144" fill="none" stroke="black"/> <path d="M 80,208 L 80,272" fill="none" stroke="black"/>
<path d="M 136,240 L 136,256" fill="none" stroke="black"/> <path d="M 136,80 L 136,96" fill="none" stroke="black"/>
<path d="M 136,288 L 136,304" fill="none" stroke="black"/> <path d="M 136,128 L 136,144" fill="none" stroke="black"/>
<path d="M 288,128 L 288,176" fill="none" stroke="black"/> <path d="M 136,240 L 136,256" fill="none" stroke="black"/>
<path d="M 288,288 L 288,336" fill="none" stroke="black"/> <path d="M 136,288 L 136,304" fill="none" stroke="black"/>
<path d="M 136,80 L 216,80" fill="none" stroke="black"/> <path d="M 288,128 L 288,176" fill="none" stroke="black"/>
<path d="M 312,80 L 328,80" fill="none" stroke="black"/> <path d="M 288,288 L 288,336" fill="none" stroke="black"/>
<path d="M 80,112 L 112,112" fill="none" stroke="black"/> <path d="M 136,80 L 216,80" fill="none" stroke="black"/>
<path d="M 304,112 L 328,112" fill="none" stroke="black"/> <path d="M 312,80 L 328,80" fill="none" stroke="black"/>
<path d="M 136,144 L 216,144" fill="none" stroke="black"/> <path d="M 80,112 L 112,112" fill="none" stroke="black"/>
<path d="M 312,144 L 328,144" fill="none" stroke="black"/> <path d="M 304,112 L 328,112" fill="none" stroke="black"/>
<path d="M 288,176 L 328,176" fill="none" stroke="black"/> <path d="M 136,144 L 216,144" fill="none" stroke="black"/>
<path d="M 136,240 L 216,240" fill="none" stroke="black"/> <path d="M 312,144 L 328,144" fill="none" stroke="black"/>
<path d="M 312,240 L 328,240" fill="none" stroke="black"/> <path d="M 288,176 L 328,176" fill="none" stroke="black"/>
<path d="M 80,272 L 112,272" fill="none" stroke="black"/> <path d="M 136,240 L 216,240" fill="none" stroke="black"/>
<path d="M 304,272 L 328,272" fill="none" stroke="black"/> <path d="M 312,240 L 328,240" fill="none" stroke="black"/>
<path d="M 136,304 L 216,304" fill="none" stroke="black"/> <path d="M 80,272 L 112,272" fill="none" stroke="black"/>
<path d="M 312,304 L 328,304" fill="none" stroke="black"/> <path d="M 304,272 L 328,272" fill="none" stroke="black"/>
<path d="M 288,336 L 328,336" fill="none" stroke="black"/> <path d="M 136,304 L 216,304" fill="none" stroke="black"/>
<path d="M 48,368 L 128,368" fill="none" stroke="black"/> <path d="M 312,304 L 328,304" fill="none" stroke="black"/>
<path d="M 288,368 L 352,368" fill="none" stroke="black"/> <path d="M 288,336 L 328,336" fill="none" stroke="black"/>
<path d="M 304,288 L 312,304" fill="none" stroke="black"/> <path d="M 48,368 L 128,368" fill="none" stroke="black"/>
<path d="M 304,128 L 312,144" fill="none" stroke="black"/> <path d="M 288,368 L 352,368" fill="none" stroke="black"/>
<path d="M 304,96 L 312,80" fill="none" stroke="black"/> <path d="M 304,288 L 312,304" fill="none" stroke="black"/>
<path d="M 304,256 L 312,240" fill="none" stroke="black"/> <path d="M 304,128 L 312,144" fill="none" stroke="black"/>
<polygon class="arrowhead" points="360,368 348,362.4 348,373.6" fill="black" tra <path d="M 304,96 L 312,80" fill="none" stroke="black"/>
nsform="rotate(0,352,368)"/> <path d="M 304,256 L 312,240" fill="none" stroke="black"/>
<g class="text"> <polygon class="arrowhead" points="360,368 348,362.4 348,373.6"
<text x="92" y="36">......................</text> fill="black" transform="rotate(0,352,368)"/>
<text x="312" y="36">.............................</text> <g class="text">
<text x="8" y="52">:</text> <text x="92" y="36">......................</text>
<text x="96" y="52">AS3</text> <text x="312" y="36">.............................</text>
<text x="176" y="52">:</text> <text x="8" y="52">:</text>
<text x="200" y="52">:</text> <text x="96" y="52">AS3</text>
<text x="312" y="52">AS1</text> <text x="176" y="52">:</text>
<text x="424" y="52">:</text> <text x="200" y="52">:</text>
<text x="8" y="68">:</text> <text x="312" y="52">AS1</text>
<text x="176" y="68">:</text> <text x="424" y="52">:</text>
<text x="200" y="68">:</text> <text x="8" y="68">:</text>
<text x="424" y="68">:</text> <text x="176" y="68">:</text>
<text x="8" y="84">:</text> <text x="200" y="68">:</text>
<text x="244" y="84">ASBR11</text> <text x="424" y="68">:</text>
<text x="348" y="84">PE11</text> <text x="8" y="84">:</text>
<text x="392" y="84">(EP1)</text> <text x="244" y="84">ASBR11</text>
<text x="424" y="84">:</text> <text x="348" y="84">PE11</text>
<text x="8" y="100">:</text> <text x="392" y="84">(EP1)</text>
<text x="176" y="100">:</text> <text x="424" y="84">:</text>
<text x="200" y="100">:</text> <text x="8" y="100">:</text>
<text x="272" y="100">\</text> <text x="176" y="100">:</text>
<text x="424" y="100">:</text> <text x="200" y="100">:</text>
<text x="8" y="116">:</text> <text x="272" y="100">\</text>
<text x="140" y="116">ASBR31</text> <text x="424" y="100">:</text>
<text x="176" y="116">:</text> <text x="8" y="116">:</text>
<text x="200" y="116">:</text> <text x="140" y="116">ASBR31</text>
<text x="288" y="116">[P]</text> <text x="176" y="116">:</text>
<text x="348" y="116">PE12</text> <text x="200" y="116">:</text>
<text x="392" y="116">(EP2)</text> <text x="288" y="116">[P]</text>
<text x="424" y="116">:</text> <text x="348" y="116">PE12</text>
<text x="8" y="132">:</text> <text x="392" y="116">(EP2)</text>
<text x="176" y="132">:</text> <text x="424" y="116">:</text>
<text x="200" y="132">:</text> <text x="8" y="132">:</text>
<text x="272" y="132">/</text> <text x="176" y="132">:</text>
<text x="424" y="132">:</text> <text x="200" y="132">:</text>
<text x="8" y="148">:</text> <text x="272" y="132">/</text>
<text x="244" y="148">ASBR12</text> <text x="424" y="132">:</text>
<text x="348" y="148">PE13</text> <text x="8" y="148">:</text>
<text x="392" y="148">(EP3)</text> <text x="244" y="148">ASBR12</text>
<text x="424" y="148">:</text> <text x="348" y="148">PE13</text>
<text x="8" y="164">:</text> <text x="392" y="148">(EP3)</text>
<text x="176" y="164">:</text> <text x="424" y="148">:</text>
<text x="200" y="164">:</text> <text x="8" y="164">:</text>
<text x="424" y="164">:</text> <text x="176" y="164">:</text>
<text x="8" y="180">:</text> <text x="200" y="164">:</text>
<text x="176" y="180">:</text> <text x="424" y="164">:</text>
<text x="200" y="180">:</text> <text x="8" y="180">:</text>
<text x="348" y="180">PE14</text> <text x="176" y="180">:</text>
<text x="392" y="180">(EP4)</text> <text x="200" y="180">:</text>
<text x="424" y="180">:</text> <text x="348" y="180">PE14</text>
<text x="8" y="196">:</text> <text x="392" y="180">(EP4)</text>
<text x="56" y="196">PE31--[P]</text> <text x="424" y="180">:</text>
<text x="176" y="196">:</text> <text x="8" y="196">:</text>
<text x="200" y="196">:</text> <text x="56" y="196">PE31--[P]</text>
<text x="424" y="196">:</text> <text x="176" y="196">:</text>
<text x="8" y="212">:</text> <text x="200" y="196">:</text>
<text x="176" y="212">:</text> <text x="424" y="196">:</text>
<text x="200" y="212">:</text> <text x="8" y="212">:</text>
<text x="424" y="212">:</text> <text x="176" y="212">:</text>
<text x="8" y="228">:</text> <text x="200" y="212">:</text>
<text x="176" y="228">:</text> <text x="424" y="212">:</text>
<text x="200" y="228">:</text> <text x="8" y="228">:</text>
<text x="424" y="228">:</text> <text x="176" y="228">:</text>
<text x="8" y="244">:</text> <text x="200" y="228">:</text>
<text x="244" y="244">ASBR21</text> <text x="424" y="228">:</text>
<text x="348" y="244">PE21</text> <text x="8" y="244">:</text>
<text x="392" y="244">(EP5)</text> <text x="244" y="244">ASBR21</text>
<text x="424" y="244">:</text> <text x="348" y="244">PE21</text>
<text x="8" y="260">:</text> <text x="392" y="244">(EP5)</text>
<text x="176" y="260">:</text> <text x="424" y="244">:</text>
<text x="200" y="260">:</text> <text x="8" y="260">:</text>
<text x="272" y="260">\</text> <text x="176" y="260">:</text>
<text x="424" y="260">:</text> <text x="200" y="260">:</text>
<text x="8" y="276">:</text> <text x="272" y="260">\</text>
<text x="140" y="276">ASBR32</text> <text x="424" y="260">:</text>
<text x="176" y="276">:</text> <text x="8" y="276">:</text>
<text x="200" y="276">:</text> <text x="140" y="276">ASBR32</text>
<text x="288" y="276">[P]</text> <text x="176" y="276">:</text>
<text x="348" y="276">PE22</text> <text x="200" y="276">:</text>
<text x="392" y="276">(EP6)</text> <text x="288" y="276">[P]</text>
<text x="424" y="276">:</text> <text x="348" y="276">PE22</text>
<text x="8" y="292">:</text> <text x="392" y="276">(EP6)</text>
<text x="176" y="292">:</text> <text x="424" y="276">:</text>
<text x="200" y="292">:</text> <text x="8" y="292">:</text>
<text x="272" y="292">/</text> <text x="176" y="292">:</text>
<text x="424" y="292">:</text> <text x="200" y="292">:</text>
<text x="8" y="308">:</text> <text x="272" y="292">/</text>
<text x="244" y="308">ASBR22</text> <text x="424" y="292">:</text>
<text x="348" y="308">PE22</text> <text x="8" y="308">:</text>
<text x="392" y="308">(EP7)</text> <text x="244" y="308">ASBR22</text>
<text x="424" y="308">:</text> <text x="348" y="308">PE22</text>
<text x="8" y="324">:</text> <text x="392" y="308">(EP7)</text>
<text x="176" y="324">:</text> <text x="424" y="308">:</text>
<text x="200" y="324">:</text> <text x="8" y="324">:</text>
<text x="424" y="324">:</text> <text x="176" y="324">:</text>
<text x="8" y="340">:</text> <text x="200" y="324">:</text>
<text x="176" y="340">:</text> <text x="424" y="324">:</text>
<text x="200" y="340">:</text> <text x="8" y="340">:</text>
<text x="348" y="340">PE24</text> <text x="176" y="340">:</text>
<text x="392" y="340">(EP8)</text> <text x="200" y="340">:</text>
<text x="424" y="340">:</text> <text x="348" y="340">PE24</text>
<text x="92" y="356">......................</text> <text x="392" y="340">(EP8)</text>
<text x="312" y="356">.............................</text> <text x="424" y="340">:</text>
<text x="168" y="372">Traffic</text> <text x="92" y="356">......................</text>
<text x="240" y="372">Direction</text> <text x="312" y="356">.............................</text>
</g> <text x="168" y="372">Traffic</text>
</svg> <text x="240" y="372">Direction</text>
</artwork><artwork type="ascii-art"><![CDATA[ </g>
</svg>
</artwork>
<artwork type="ascii-art" name="" align="left" alt=""><![CDATA[
...................... ............................. ...................... .............................
: AS3 : : AS1 : : AS3 : : AS1 :
: : : : : : : :
: +----------ASBR11 +--PE11 (EP1) : : +----------ASBR11 +--PE11 (EP1) :
: | : : \ / : : | : : \ / :
: +----ASBR31 : : [P]----PE12 (EP2) : : +----ASBR31 : : [P]----PE12 (EP2) :
: | | : : / | \ : : | | : : / | \ :
: | +----------ASBR12 | +--PE13 (EP3) : : | +----------ASBR12 | +--PE13 (EP3) :
: | : : | : : | : : | :
: | : : +-----PE14 (EP4) : : | : : +-----PE14 (EP4) :
skipping to change at line 2234 skipping to change at line 2009
: | : : : : | : : :
: | +----------ASBR21 +--PE21 (EP5) : : | +----------ASBR21 +--PE21 (EP5) :
: | | : : \ / : : | | : : \ / :
: +----ASBR32 : : [P]----PE22 (EP6) : : +----ASBR32 : : [P]----PE22 (EP6) :
: | : : / | \ : : | : : / | \ :
: +----------ASBR22 | +--PE22 (EP7) : : +----------ASBR22 | +--PE22 (EP7) :
: : : | : : : : | :
: : : +-----PE24 (EP8) : : : : +-----PE24 (EP8) :
...................... ............................. ...................... .............................
----------- Traffic Direction --------> ----------- Traffic Direction -------->
]]></artwork></artset></figure> ]]></artwork>
</artset>
</figure>
<t>The following table provides a comparison of the BGP CT route and <t>The following table provides a comparison of the BGP CT route and
label scale, for varying endpoint path visibility at ingress node PE31 label scale for varying endpoint-path visibility at ingress node PE31
for each TC. It analyzes scenarios where Unicast or Anycast EPs for each TC. It analyzes scenarios where Unicast or Anycast EPs
(EP-type) may be originated by different node roles (Origin), using (EP-type) may be originated by different node roles (Origin), using
different RD allocation modes (RD-Mode), and different Per-Prefix different RD allocation modes (RD-Modes), and different Per-Prefix
Label allocation modes (PP-Mode).</t> label-allocation modes (PP-Modes).</t>
<figure anchor="RDLabelVis">
<figure title="Route and Path Visibility at Ingress Node" anchor="RDLabelVis"><a <name>Route and Path Visibility at Ingress Node</name>
rtset><artwork type="svg"><svg xmlns="http://www.w3.org/2000/svg" version="1.1" <artset>
height="320" width="432" viewBox="0 0 432 320" class="diagram" text-anchor="mid <artwork type="svg" name="" align="left" alt=""><svg xmlns="http://w
dle" font-family="monospace" font-size="13px" stroke-linecap="round"> ww.w3.org/2000/svg" version="1.1" height="320" width="432" viewBox="0 0 432 320"
<path d="M 8,32 L 8,288" fill="none" stroke="black"/> class="diagram" text-anchor="middle" font-family="monospace" font-size="13px" s
<path d="M 80,32 L 80,288" fill="none" stroke="black"/> troke-linecap="round">
<path d="M 136,32 L 136,288" fill="none" stroke="black"/> <path d="M 8,32 L 8,288" fill="none" stroke="black"/>
<path d="M 200,32 L 200,288" fill="none" stroke="black"/> <path d="M 80,32 L 80,288" fill="none" stroke="black"/>
<path d="M 264,32 L 264,288" fill="none" stroke="black"/> <path d="M 136,32 L 136,288" fill="none" stroke="black"/>
<path d="M 344,32 L 344,288" fill="none" stroke="black"/> <path d="M 200,32 L 200,288" fill="none" stroke="black"/>
<path d="M 424,32 L 424,288" fill="none" stroke="black"/> <path d="M 264,32 L 264,288" fill="none" stroke="black"/>
<path d="M 8,32 L 424,32" fill="none" stroke="black"/> <path d="M 344,32 L 344,288" fill="none" stroke="black"/>
<path d="M 8,64 L 424,64" fill="none" stroke="black"/> <path d="M 424,32 L 424,288" fill="none" stroke="black"/>
<path d="M 16,144 L 72,144" fill="none" stroke="black"/> <path d="M 8,32 L 424,32" fill="none" stroke="black"/>
<path d="M 88,144 L 128,144" fill="none" stroke="black"/> <path d="M 8,64 L 424,64" fill="none" stroke="black"/>
<path d="M 144,144 L 192,144" fill="none" stroke="black"/> <path d="M 16,144 L 72,144" fill="none" stroke="black"/>
<path d="M 208,144 L 256,144" fill="none" stroke="black"/> <path d="M 88,144 L 128,144" fill="none" stroke="black"/>
<path d="M 272,144 L 336,144" fill="none" stroke="black"/> <path d="M 144,144 L 192,144" fill="none" stroke="black"/>
<path d="M 352,144 L 416,144" fill="none" stroke="black"/> <path d="M 208,144 L 256,144" fill="none" stroke="black"/>
<path d="M 8,288 L 424,288" fill="none" stroke="black"/> <path d="M 272,144 L 336,144" fill="none" stroke="black"/>
<g class="text"> <path d="M 352,144 L 416,144" fill="none" stroke="black"/>
<text x="40" y="52">EP-type</text> <path d="M 8,288 L 424,288" fill="none" stroke="black"/>
<text x="108" y="52">Origin</text> <g class="text">
<text x="168" y="52">RD-Mode</text> <text x="40" y="52">EP-type</text>
<text x="232" y="52">PP-Mode</text> <text x="108" y="52">Origin</text>
<text x="276" y="52">CT</text> <text x="168" y="52">RD-Mode</text>
<text x="316" y="52">Routes</text> <text x="232" y="52">PP-Mode</text>
<text x="356" y="52">CT</text> <text x="276" y="52">CT</text>
<text x="396" y="52">Labels</text> <text x="316" y="52">Routes</text>
<text x="40" y="84">Unicast</text> <text x="356" y="52">CT</text>
<text x="92" y="84">SN</text> <text x="396" y="52">Labels</text>
<text x="164" y="84">Unique</text> <text x="40" y="84">Unicast</text>
<text x="224" y="84">TC,EP</text> <text x="92" y="84">SN</text>
<text x="312" y="84">8</text> <text x="164" y="84">Unique</text>
<text x="384" y="84">8</text> <text x="224" y="84">TC,EP</text>
<text x="40" y="100">Unicast</text> <text x="312" y="84">8</text>
<text x="92" y="100">SN</text> <text x="384" y="84">8</text>
<text x="164" y="100">Unique</text> <text x="40" y="100">Unicast</text>
<text x="224" y="100">RD,EP</text> <text x="92" y="100">SN</text>
<text x="312" y="100">8</text> <text x="164" y="100">Unique</text>
<text x="384" y="100">8</text> <text x="224" y="100">RD,EP</text>
<text x="40" y="116">Unicast</text> <text x="312" y="100">8</text>
<text x="92" y="116">BN</text> <text x="384" y="100">8</text>
<text x="164" y="116">Unique</text> <text x="40" y="116">Unicast</text>
<text x="224" y="116">TC,EP</text> <text x="92" y="116">BN</text>
<text x="308" y="116">16</text> <text x="164" y="116">Unique</text>
<text x="384" y="116">8</text> <text x="224" y="116">TC,EP</text>
<text x="40" y="132">Unicast</text> <text x="308" y="116">16</text>
<text x="92" y="132">BN</text> <text x="384" y="116">8</text>
<text x="164" y="132">Unique</text> <text x="40" y="132">Unicast</text>
<text x="224" y="132">RD,EP</text> <text x="92" y="132">BN</text>
<text x="308" y="132">16</text> <text x="164" y="132">Unique</text>
<text x="380" y="132">16</text> <text x="224" y="132">RD,EP</text>
<text x="40" y="164">Anycast</text> <text x="308" y="132">16</text>
<text x="92" y="164">SN</text> <text x="380" y="132">16</text>
<text x="164" y="164">Unique</text> <text x="40" y="164">Anycast</text>
<text x="224" y="164">TC,EP</text> <text x="92" y="164">SN</text>
<text x="312" y="164">8</text> <text x="164" y="164">Unique</text>
<text x="384" y="164">2</text> <text x="224" y="164">TC,EP</text>
<text x="40" y="180">Anycast</text> <text x="312" y="164">8</text>
<text x="92" y="180">SN</text> <text x="384" y="164">2</text>
<text x="164" y="180">Unique</text> <text x="40" y="180">Anycast</text>
<text x="224" y="180">RD,EP</text> <text x="92" y="180">SN</text>
<text x="312" y="180">8</text> <text x="164" y="180">Unique</text>
<text x="384" y="180">8</text> <text x="224" y="180">RD,EP</text>
<text x="40" y="196">Anycast</text> <text x="312" y="180">8</text>
<text x="92" y="196">SN</text> <text x="384" y="180">8</text>
<text x="156" y="196">Same</text> <text x="40" y="196">Anycast</text>
<text x="224" y="196">TC,EP</text> <text x="92" y="196">SN</text>
<text x="312" y="196">2</text> <text x="156" y="196">Same</text>
<text x="384" y="196">2</text> <text x="224" y="196">TC,EP</text>
<text x="40" y="212">Anycast</text> <text x="312" y="196">2</text>
<text x="92" y="212">SN</text> <text x="384" y="196">2</text>
<text x="156" y="212">Same</text> <text x="40" y="212">Anycast</text>
<text x="224" y="212">RD,EP</text> <text x="92" y="212">SN</text>
<text x="312" y="212">2</text> <text x="156" y="212">Same</text>
<text x="384" y="212">2</text> <text x="224" y="212">RD,EP</text>
<text x="40" y="228">Anycast</text> <text x="312" y="212">2</text>
<text x="92" y="228">BN</text> <text x="384" y="212">2</text>
<text x="164" y="228">Unique</text> <text x="40" y="228">Anycast</text>
<text x="224" y="228">TC,EP</text> <text x="92" y="228">BN</text>
<text x="312" y="228">4</text> <text x="164" y="228">Unique</text>
<text x="384" y="228">2</text> <text x="224" y="228">TC,EP</text>
<text x="40" y="244">Anycast</text> <text x="312" y="228">4</text>
<text x="92" y="244">BN</text> <text x="384" y="228">2</text>
<text x="164" y="244">Unique</text> <text x="40" y="244">Anycast</text>
<text x="224" y="244">RD,EP</text> <text x="92" y="244">BN</text>
<text x="312" y="244">4</text> <text x="164" y="244">Unique</text>
<text x="384" y="244">4</text> <text x="224" y="244">RD,EP</text>
<text x="40" y="260">Anycast</text> <text x="312" y="244">4</text>
<text x="92" y="260">BN</text> <text x="384" y="244">4</text>
<text x="156" y="260">Same</text> <text x="40" y="260">Anycast</text>
<text x="224" y="260">TC,EP</text> <text x="92" y="260">BN</text>
<text x="312" y="260">2</text> <text x="156" y="260">Same</text>
<text x="384" y="260">2</text> <text x="224" y="260">TC,EP</text>
<text x="40" y="276">Anycast</text> <text x="312" y="260">2</text>
<text x="92" y="276">BN</text> <text x="384" y="260">2</text>
<text x="156" y="276">Same</text> <text x="40" y="276">Anycast</text>
<text x="224" y="276">RD,EP</text> <text x="92" y="276">BN</text>
<text x="312" y="276">2</text> <text x="156" y="276">Same</text>
<text x="384" y="276">2</text> <text x="224" y="276">RD,EP</text>
</g> <text x="312" y="276">2</text>
</svg> <text x="384" y="276">2</text>
</artwork><artwork type="ascii-art"><![CDATA[ </g>
</svg>
</artwork>
<artwork type="ascii-art" name="" align="left" alt=""><![CDATA[
+--------+------+-------+-------+---------+---------+ +--------+------+-------+-------+---------+---------+
|EP-type |Origin|RD-Mode|PP-Mode|CT Routes|CT Labels| |EP-type |Origin|RD-Mode|PP-Mode|CT Routes|CT Labels|
+--------+------+-------+-------+---------+---------+ +--------+------+-------+-------+---------+---------+
|Unicast |SN |Unique |TC,EP | 8 | 8 | |Unicast |SN |Unique |TC,EP | 8 | 8 |
|Unicast |SN |Unique |RD,EP | 8 | 8 | |Unicast |SN |Unique |RD,EP | 8 | 8 |
|Unicast |BN |Unique |TC,EP | 16 | 8 | |Unicast |BN |Unique |TC,EP | 16 | 8 |
|Unicast |BN |Unique |RD,EP | 16 | 16 | |Unicast |BN |Unique |RD,EP | 16 | 16 |
|--------|------|-------|-------|---------|---------| |--------|------|-------|-------|---------|---------|
|Anycast |SN |Unique |TC,EP | 8 | 2 | |Anycast |SN |Unique |TC,EP | 8 | 2 |
|Anycast |SN |Unique |RD,EP | 8 | 8 | |Anycast |SN |Unique |RD,EP | 8 | 8 |
|Anycast |SN |Same |TC,EP | 2 | 2 | |Anycast |SN |Same |TC,EP | 2 | 2 |
|Anycast |SN |Same |RD,EP | 2 | 2 | |Anycast |SN |Same |RD,EP | 2 | 2 |
|Anycast |BN |Unique |TC,EP | 4 | 2 | |Anycast |BN |Unique |TC,EP | 4 | 2 |
|Anycast |BN |Unique |RD,EP | 4 | 4 | |Anycast |BN |Unique |RD,EP | 4 | 4 |
|Anycast |BN |Same |TC,EP | 2 | 2 | |Anycast |BN |Same |TC,EP | 2 | 2 |
|Anycast |BN |Same |RD,EP | 2 | 2 | |Anycast |BN |Same |RD,EP | 2 | 2 |
+--------+------+-------+-------+---------+---------+ +--------+------+-------+-------+---------+---------+
]]></artwork></artset></figure> ]]></artwork>
</artset>
<t>In the table shown in <xref target="RDLabelVis"/>, route scale at </figure>
ingress node PE31 is proportional to path diversity in ingress domain <t>In <xref target="RDLabelVis" format="default"/>, route scale at
(number of ASBRs) and point of origination of BGP CT route. TE ingress node PE31 is proportional to path diversity in the ingress domai
n
(number of ASBRs) and point of origination of the BGP CT route. TE
granularity at ingress node PE31 is proportional to the number of granularity at ingress node PE31 is proportional to the number of
unique CT labels received, which depends on PP-mode and the path unique CT labels received, which depends on the PP-Mode and the path
diversity in ingress domain.</t> diversity in the ingress domain.</t>
<t>Deploying unique RDs is strongly <bcp14>RECOMMENDED</bcp14> because i
<t>Deploying unique RDs is strongly RECOMMENDED because it helps in t helps in
troubleshooting by uniquely identifying the originator of a route and troubleshooting by uniquely identifying the originator of a route and
avoids path-hiding.</t> avoids path hiding.</t>
<t>In typical deployments, originating BGP CT routes at the egress node
<t>In typical deployments originating BGP CT routes at the egress node (SN) is recommended. In this model, using either an "RD, EP" or "TC, EP"
(SN) is recommended. In this model, using either "RD, EP" or "TC, EP" Per-Prefix label-allocation mode repairs traffic locally at the
Per-Prefix label allocation mode repairs traffic locally at the nearest BN for any failures in the network because the label value
nearest BN for any failures in the network, because the label value
does not change.</t> does not change.</t>
<t>Originating at BNs with unique RDs induces more routes than when <t>Originating at BNs with unique RDs induces more routes than when
originating at egress SNs. In this model, use of "TC, EP" Per-Prefix originating at egress SNs. In this model, use of the "TC, EP" Per-Prefix
label allocation mode repairs traffic locally at the nearest BN for label-allocation mode repairs traffic locally at the nearest BN for
any failures in the network, because the label value does not any failures in the network because the label value does not
change.</t> change.</t>
<t><xref target="RDLabelVis" format="default"/> demonstrates that
<t>The previous table in <xref target="RDLabelVis"/> demonstrates that
BGP CT allows an operator to control how much path visibility and BGP CT allows an operator to control how much path visibility and
forwarding diversity is desired in the network, for both Unicast and forwarding diversity is desired in the network for both Unicast and
Anycast endpoints.</t> Anycast endpoints.</t>
</section> </section>
</section> </section>
<section anchor="CTdeploy" numbered="true" toc="default">
<section anchor="CTdeploy" title="Deployment Considerations."> <name>Deployment Considerations</name>
<section title="Coordination Between Domains Using Different Community Nam <section numbered="true" toc="default">
espaces"> <name>Coordination Between Domains Using Different Community Namespaces<
<t>Cooperating Inter-AS Option C domains may sometimes not agree on /name>
RT, RD, Mapping community or Transport Route Target values because of <t>Cooperating inter-AS option C domains may sometimes not agree on
differences in community namespaces (e.g. during network mergers or RT, RD, Mapping Community, or Transport Class RT values because of
differences in community namespaces (e.g., during network mergers or
renumbering for expansion). Such deployments may deploy mechanisms to renumbering for expansion). Such deployments may deploy mechanisms to
map and rewrite the Route Target values on domain boundaries, using map and rewrite the Route Target values on domain boundaries using
per ASBR import policies. This is no different than any other BGP VPN per-ASBR import policies. This is no different than any other BGP VPN
family. Mechanisms used in inter-AS VPN deployments may be leveraged family. Mechanisms used in inter-AS VPN deployments may be leveraged
with the Classful Transport family also.</t> with the BGP CT family also.</t>
<t>A Resolution Scheme allows association with multiple Mapping
<t>A resolution scheme allows association with multiple Mapping
Communities. This minimizes service disruption during renumbering, Communities. This minimizes service disruption during renumbering,
network merger or transition scenarios.</t> network merger, or transition scenarios.</t>
<t>The Transport Class RT is useful to
<t>The Transport Class Route Target Extended Community is useful to
avoid collision with regular Route Target namespace used by service avoid collision with regular Route Target namespace used by service
routes.</t> routes.</t>
</section> </section>
<section numbered="true" toc="default">
<section title="Managing Intent at Service and Transport layers."> <name>Managing Intent at Service and Transport Layers</name>
<t><xref target="CTProc">Illustration of BGP CT Procedures </xref> <t><xref target="CTProc" format="default"></xref>
shows multiple domains that agree on a color name space (Agreeing shows multiple domains that agree on a color namespace (Agreeing
Color Domains) and contain tunnels with equivalent set of colors Color Domains) and contain tunnels with an equivalent set of colors
(Homogenous Color Domains).</t> (Homogenous Color Domains).</t>
<t>However, in the real world, this may not always be guaranteed. Two <t>However, in the real world, this may not always be guaranteed. Two
domains may independently manage their color namespaces; these are domains may independently manage their color namespaces; these are
known as Non-Agreeing Color Domains. Two domains may have tunnels with known as Non-Agreeing Color Domains. Two domains may have tunnels with
unequal sets of colors; these are known as Heterogeneous Color unequal sets of colors; these are known as Heterogeneous Color
Domains.</t> Domains.</t>
<t>This section describes how BGP CT is deployed in such scenarios to <t>This section describes how BGP CT is deployed in such scenarios to
preserve end-to-end Intent. Examples described in this section use preserve end-to-end Intent. Examples described in this section use
Inter-AS Option C domains. Similar mechanisms will work for Inter-AS inter-AS option C domains. Similar mechanisms will work for inter-AS
Option A and Inter-AS Option B scenarios as well.</t> option A and inter-AS option B scenarios as well.</t>
<section numbered="true" toc="default">
<section title="Service Layer Color Management "> <name>Service Layer Color Management</name>
<t>At the service layer, it is recommended that a global color <t>At the service layer, it is recommended that a global color
namespace be maintained across multiple co-operating domains. BGP CT namespace be maintained across multiple cooperating domains. BGP CT
allows indirection using resolution schemes to be able to maintain a allows indirection using Resolution Schemes to be able to maintain a
global namespace in the service layer. This is possible even if each global namespace in the service layer. This is possible even if each
domain independently maintains its own local transport color domain independently maintains its own local transport color
namespace.</t> namespace.</t>
<t>As explained in <xref target="Nexthop_Resoln_Schm" format="default"
<t>As explained in <xref target="Nexthop_Resoln_Schm">Next Hop ></xref>, a Mapping Community carried on a service
Resolution Scheme</xref> , a mapping community carried on a service route maps to a Resolution Scheme. The Mapping Community values for
route maps to a resolution scheme. The mapping community values for
the service route can be abstract and are not required to match the the service route can be abstract and are not required to match the
transport color namespace. This abstract mapping community value transport color namespace. This abstract Mapping Community value
representing a global service layer intent is mapped to a local representing a global service layer Intent is mapped to a local
transport layer intent available in each domain.</t> transport layer Intent available in each domain.</t>
<t>In this manner, it is recommended to keep color namespace <t>In this manner, it is recommended to keep color namespace
management at the service layer and the transport layer decoupled management at the service layer and the transport layer decoupled
from each other. In the following sections the service layer agrees from each other. In the following sections, the service layer agrees
on a single global namespace.</t> on a single global namespace.</t>
</section> </section>
<section anchor="non-agreeing" numbered="true" toc="default">
<section anchor="non-agreeing" <name>Non-Agreeing Color Transport Domains</name>
title="Non-Agreeing Color Transport Domains"> <t>Non-Agreeing Color Domains require a Mapping Community rewrite on
<t>Non-agreeing color domains require a mapping community rewrite on
each domain boundary. This rewrite helps to map one domain's color each domain boundary. This rewrite helps to map one domain's color
namespace to another domain's color namespace.</t> namespace to another domain's color namespace.</t>
<t>The following example illustrates how traffic is stitched and SLA <t>The following example illustrates how traffic is stitched and SLA
is preserved when domains don't use the same namespace at the is preserved when domains don't use the same namespace at the
transport layer. Each domain specifies the same SLA using different transport layer. Each domain specifies the same SLA using different
color values.</t> color values.</t>
<figure title="Transport Layer with Non-agreeing Color Domains" anchor="BGPCT_NO <figure title="Transport Layer with Non-agreeing Color Domains"
N_AGREEING_COLOR_DOMAIN"><artset><artwork type="svg"><svg xmlns="http://www.w3. anchor="BGPCT_NON_AGREEING_COLOR_DOMAIN">
org/2000/svg" version="1.1" height="240" width="552" viewBox="0 0 552 240" class <artset>
="diagram" text-anchor="middle" font-family="monospace" font-size="13px" stroke- <artwork type="svg">
linecap="round"> <svg xmlns="http://www.w3.org/2000/svg" version="1.1" height="224"
<path d="M 72,96 L 96,96" fill="none" stroke="black"/> width="544"
<path d="M 168,96 L 184,96" fill="none" stroke="black"/> viewBox="0 0 544 224" class="diagram" text-anchor="middle" font-
<path d="M 248,96 L 288,96" fill="none" stroke="black"/> family="monospace"
<path d="M 360,96 L 376,96" fill="none" stroke="black"/> font-size="13px" stroke-linecap="round">
<path d="M 440,96 L 488,96" fill="none" stroke="black"/> <path d="M 72,80 L 96,80" fill="none" stroke="black" />
<path d="M 96,208 L 176,208" fill="none" stroke="black"/> <path d="M 168,80 L 184,80" fill="none" stroke="black" />
<path d="M 336,208 L 400,208" fill="none" stroke="black"/> <path d="M 248,80 L 288,80" fill="none" stroke="black" />
<polygon class="arrowhead" points="408,208 396,202.4 396,213.6" fill="black" tra <path d="M 360,80 L 376,80" fill="none" stroke="black" />
nsform="rotate(0,400,208)"/> <path d="M 440,80 L 480,80" fill="none" stroke="black" />
<g class="text"> <path d="M 96,192 L 176,192" fill="none" stroke="black" />
<text x="88" y="52">.....................</text> <path d="M 336,192 L 400,192" fill="none" stroke="black" />
<text x="272" y="52">.......................</text> <polygon class="arrowhead" points="408,192 396,186.4 396,197.6"
<text x="460" y="52">......................</text> fill="black"
<text x="8" y="68">:</text> transform="rotate(0,400,192)" />
<text x="96" y="68">Gold(100)</text> <g class="text">
<text x="168" y="68">:</text> <text x="88" y="36">.....................</text>
<text x="184" y="68">:</text> <text x="272" y="36">.......................</text>
<text x="280" y="68">Gold(300)</text> <text x="456" y="36">.....................</text>
<text x="360" y="68">:</text> <text x="8" y="52">:</text>
<text x="376" y="68">:</text> <text x="96" y="52">Gold(100)</text>
<text x="472" y="68">Gold(500)</text> <text x="168" y="52">:</text>
<text x="544" y="68">:</text> <text x="184" y="52">:</text>
<text x="8" y="84">:</text> <text x="280" y="52">Gold(300)</text>
<text x="168" y="84">:</text> <text x="360" y="52">:</text>
<text x="184" y="84">:</text> <text x="376" y="52">:</text>
<text x="360" y="84">:</text> <text x="472" y="52">Gold(500)</text>
<text x="376" y="84">:</text> <text x="536" y="52">:</text>
<text x="544" y="84">:</text> <text x="8" y="68">:</text>
<text x="8" y="100">:</text> <text x="168" y="68">:</text>
<text x="44" y="100">[PE11]</text> <text x="184" y="68">:</text>
<text x="132" y="100">[ASBR11]</text> <text x="360" y="68">:</text>
<text x="216" y="100">[ASBR21</text> <text x="376" y="68">:</text>
<text x="324" y="100">[ASBR22]</text> <text x="536" y="68">:</text>
<text x="408" y="100">[ASBR31</text> <text x="8" y="84">:</text>
<text x="520" y="100">[PE31]:</text> <text x="44" y="84">[PE11]</text>
<text x="8" y="116">:</text> <text x="132" y="84">[ASBR11]</text>
<text x="168" y="116">:</text> <text x="216" y="84">[ASBR21</text>
<text x="184" y="116">:</text> <text x="324" y="84">[ASBR22]</text>
<text x="360" y="116">:</text> <text x="408" y="84">[ASBR31</text>
<text x="376" y="116">:</text> <text x="512" y="84">[PE31]:</text>
<text x="544" y="116">:</text> <text x="8" y="100">:</text>
<text x="8" y="132">:</text> <text x="168" y="100">:</text>
<text x="88" y="132">AS1</text> <text x="184" y="100">:</text>
<text x="168" y="132">:</text> <text x="360" y="100">:</text>
<text x="184" y="132">:</text> <text x="376" y="100">:</text>
<text x="280" y="132">AS2</text> <text x="536" y="100">:</text>
<text x="360" y="132">:</text> <text x="8" y="116">:</text>
<text x="376" y="132">:</text> <text x="88" y="116">AS1</text>
<text x="464" y="132">AS3</text> <text x="168" y="116">:</text>
<text x="544" y="132">:</text> <text x="184" y="116">:</text>
<text x="8" y="148">:</text> <text x="280" y="116">AS2</text>
<text x="168" y="148">:</text> <text x="360" y="116">:</text>
<text x="184" y="148">:</text> <text x="376" y="116">:</text>
<text x="360" y="148">:</text> <text x="464" y="116">AS3</text>
<text x="376" y="148">:</text> <text x="536" y="116">:</text>
<text x="544" y="148">:</text> <text x="8" y="132">:</text>
<text x="8" y="164">:</text> <text x="168" y="132">:</text>
<text x="104" y="164">Bronze(200)</text> <text x="184" y="132">:</text>
<text x="168" y="164">:</text> <text x="360" y="132">:</text>
<text x="184" y="164">:</text> <text x="376" y="132">:</text>
<text x="272" y="164">Bronze(400)</text> <text x="536" y="132">:</text>
<text x="360" y="164">:</text> <text x="8" y="148">:</text>
<text x="376" y="164">:</text> <text x="104" y="148">Bronze(200)</text>
<text x="464" y="164">Bronze(600)</text> <text x="168" y="148">:</text>
<text x="544" y="164">:</text> <text x="184" y="148">:</text>
<text x="88" y="180">.....................</text> <text x="272" y="148">Bronze(400)</text>
<text x="272" y="180">.......................</text> <text x="360" y="148">:</text>
<text x="460" y="180">......................</text> <text x="376" y="148">:</text>
<text x="216" y="212">Traffic</text> <text x="464" y="148">Bronze(600)</text>
<text x="288" y="212">Direction</text> <text x="536" y="148">:</text>
</g> <text x="88" y="164">.....................</text>
</svg> <text x="272" y="164">.......................</text>
</artwork><artwork type="ascii-art"><![CDATA[ <text x="456" y="164">.....................</text>
<text x="216" y="196">Traffic</text>
..................... ....................... ...................... <text x="288" y="196">Direction</text>
: Gold(100) : : Gold(300) : : Gold(500) : </g>
: : : : : : </svg>
: [PE11]----[ASBR11]---[ASBR21------[ASBR22]---[ASBR31-------[PE31]: </artwork>
: : : : : : <artwork type="ascii-art"><![CDATA[
: AS1 : : AS2 : : AS3 : ..................... ....................... .....................
: : : : : : : Gold(100) : : Gold(300) : : Gold(500) :
: Bronze(200) : : Bronze(400) : : Bronze(600) : : : : : : :
..................... ....................... ...................... : [PE11]----[ASBR11]---[ASBR21------[ASBR22]---[ASBR31------[PE31]:
: : : : : :
: AS1 : : AS2 : : AS3 :
: : : : : :
: Bronze(200) : : Bronze(400) : : Bronze(600) :
..................... ....................... .....................
----------- Traffic Direction --------> ----------- Traffic Direction -------->
]]></artwork></artset></figure> ]]></artwork>
</artset>
</figure>
<t>In the topology shown in <xref <t>In the topology shown in <xref target="BGPCT_NON_AGREEING_COLOR_DOMA
target="BGPCT_NON_AGREEING_COLOR_DOMAIN"/>, we have three Autonomous IN" format="default"/>, we have three Autonomous
Systems. All the nodes in the topology support BGP CT.</t> Systems. All the nodes in the topology support BGP CT.</t>
<t>In AS1 Gold SLA is represented by color 100 and Bronze by <ul spacing="normal">
200.</t> <li>In AS1, the Gold SLA is represented by color 100 and Bronze by
200.</li>
<t>In AS2 Gold SLA is represented by color 300 and Bronze by <li>In AS2, the Gold SLA is represented by color 300 and Bronze by
400.</t> 400.</li>
<li>In AS3, the Gold SLA is represented by color 500 and Bronze by
<t>In AS3 Gold SLA is represented by color 500 and Bronze by 600.</li>
600.</t> </ul>
<t>Though the color values are different, they map to tunnels with <t>Though the color values are different, they map to tunnels with
sufficiently similar TE characteristics in each domain.</t> sufficiently similar TE characteristics in each domain.</t>
<t>The service route carries an abstract Mapping Community that maps
<t>The service route carries an abstract mapping community that maps to the required SLA. For example, service routes that need to
to the required SLA. For example, Service routes that need to resolve over Gold transport tunnels carry a Mapping Community
resolve over Gold transport tunnels, carry a mapping community color:0:100500. In AS3, it maps to a Resolution Scheme containing
color:0:100500. In AS3 it maps to a resolution scheme containing TRDB with color 500; in AS2, it maps to TRDB with color 300;
TRDB with color 500 whereas in AS2 it maps to a TRDB with color 300 and in AS1, it maps to TRDB with color 100. Coordination is needed
and in AS1 it maps to a TRDB with color 100. Coordination is needed to provision the Resolution Schemes in each domain, as explained
to provision the resolution schemes in each domain as explained
previously.</t> previously.</t>
<t>At the AS boundary, the Transport Class RT is rewritten
<t>At the AS boundary, the transport-class route-target is rewritten
for the BGP CT routes. In the previous topology, at ASBR31, the 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:500 for Gold tunnels is rewritten to
transport-target:0:300 and then advertised to ASBR22. Similarly, the transport-target:0:300 and then advertised to ASBR22. Similarly, the
transport-target:0:300 for Gold tunnels are re-written to transport-target:0:300 for Gold tunnels are rewritten to
transport-target:0:100 at ASBR21 before advertising to ASBR11. At transport-target:0:100 at ASBR21 before advertising to ASBR11. At
PE11, the transport route received with transport-target:0:100 will PE11, the transport route received with transport-target:0:100 will
be added to the color 100 TRDB. The service route received with be added to the color 100 TRDB. The service route received with
mapping community color:0:100500 at PE1 maps to the Gold TRDB and Mapping Community color:0:100500 at PE1 maps to the Gold TRDB and
resolves over this transport route.</t> resolves over this transport route.</t>
<t>Inter-domain traffic forwarding in the previous topology works as <t>Inter-domain traffic forwarding in the previous topology works as
explained in <xref target="CTProc"/>.</t> explained in <xref target="CTProc" format="default"/>.</t>
<t>Transport Class RT rewrite requires coordination of color values
<t>Transport-target re-write requires co-ordination of color values
between domains in the transport layer. This method avoids the need between domains in the transport layer. This method avoids the need
to re-write service route mapping communities, keeping the service to rewrite service route mapping communities, keeping the service
layer homogenous and simple to manage. Coordinating Transport Class layer homogenous and simple to manage. Coordinating Transport Class
RT between two adjacent color domains at a time is easier than RT between two adjacent color domains at a time is easier than
coordinating service layer colors deployed in a global mesh of coordinating service layer colors deployed in a global mesh of
non-adjacent color domains. This basically allows localizing the non-adjacent color domains. This basically allows localizing the
problem to a pair of adjacent color domains and solving it.</t> problem to a pair of adjacent color domains and solving it.</t>
</section> </section>
<section numbered="true" toc="default">
<section title="Heterogeneous Agreeing Color Transport Domains"> <name>Heterogeneous Agreeing Color Transport Domains</name>
<t>In a heterogeneous domains scenario, it might not be possible to <t>In a heterogeneous-domain scenario, it might not be possible to
map a service layer intent to the matching transport color, as the map a service layer Intent to the matching transport color, as the
color might not be locally available in a domain.</t> color might not be locally available in a domain.</t>
<t>The following example illustrates how traffic is stitched when a
<t>The following example illustrates how traffic is stitched, when a transit AS contains more shades for an SLA path compared to ingress
transit AS contains more shades for an SLA path compared to Ingress and egress domains. This example shows how service routes can
and Egress domains. This example shows how service routes can
traverse through finer shades when available and take coarse shades traverse through finer shades when available and take coarse shades
otherwise.</t> otherwise.</t>
<figure title="Transport Layer with Heterogenous Color Domains" anchor="BGPCT_HE <figure title="Transport Layer with Heterogeneous Color Domains"
TERO_COLOR_DOMAIN"><artset><artwork type="svg"><svg xmlns="http://www.w3.org/20 anchor="BGPCT_HETERO_COLOR_DOMAIN">
00/svg" version="1.1" height="256" width="552" viewBox="0 0 552 256" class="diag <artset>
ram" text-anchor="middle" font-family="monospace" font-size="13px" stroke-lineca <artwork type="svg">
p="round"> <svg xmlns="http://www.w3.org/2000/svg" version="1.1" height="240"
<path d="M 72,112 L 96,112" fill="none" stroke="black"/> width="544"
<path d="M 168,112 L 184,112" fill="none" stroke="black"/> viewBox="0 0 544 240" class="diagram" text-anchor="middle" font-
<path d="M 248,112 L 288,112" fill="none" stroke="black"/> family="monospace"
<path d="M 360,112 L 376,112" fill="none" stroke="black"/> font-size="13px" stroke-linecap="round">
<path d="M 440,112 L 488,112" fill="none" stroke="black"/> <path d="M 72,96 L 96,96" fill="none" stroke="black" />
<path d="M 120,224 L 200,224" fill="none" stroke="black"/> <path d="M 168,96 L 184,96" fill="none" stroke="black" />
<path d="M 360,224 L 424,224" fill="none" stroke="black"/> <path d="M 248,96 L 288,96" fill="none" stroke="black" />
<polygon class="arrowhead" points="432,224 420,218.4 420,229.6" fill="black" tra <path d="M 360,96 L 376,96" fill="none" stroke="black" />
nsform="rotate(0,424,224)"/> <path d="M 440,96 L 480,96" fill="none" stroke="black" />
<g class="text"> <path d="M 120,208 L 200,208" fill="none" stroke="black" />
<text x="88" y="52">.....................</text> <path d="M 360,208 L 424,208" fill="none" stroke="black" />
<text x="272" y="52">.......................</text> <polygon class="arrowhead" points="432,208 420,202.4 420,213.6"
<text x="460" y="52">......................</text> fill="black"
<text x="8" y="68">:</text> transform="rotate(0,424,208)" />
<text x="168" y="68">:</text> <g class="text">
<text x="184" y="68">:</text> <text x="88" y="36">.....................</text>
<text x="276" y="68">Gold1(101)</text> <text x="272" y="36">.......................</text>
<text x="360" y="68">:</text> <text x="456" y="36">.....................</text>
<text x="376" y="68">:</text> <text x="8" y="52">:</text>
<text x="544" y="68">:</text> <text x="168" y="52">:</text>
<text x="8" y="84">:</text> <text x="184" y="52">:</text>
<text x="96" y="84">Gold(100)</text> <text x="276" y="52">Gold1(101)</text>
<text x="168" y="84">:</text> <text x="360" y="52">:</text>
<text x="184" y="84">:</text> <text x="376" y="52">:</text>
<text x="276" y="84">Gold2(102)</text> <text x="536" y="52">:</text>
<text x="360" y="84">:</text> <text x="8" y="68">:</text>
<text x="376" y="84">:</text> <text x="96" y="68">Gold(100)</text>
<text x="464" y="84">Gold(100)</text> <text x="168" y="68">:</text>
<text x="544" y="84">:</text> <text x="184" y="68">:</text>
<text x="8" y="100">:</text> <text x="276" y="68">Gold2(102)</text>
<text x="168" y="100">:</text> <text x="360" y="68">:</text>
<text x="184" y="100">:</text> <text x="376" y="68">:</text>
<text x="360" y="100">:</text> <text x="464" y="68">Gold(100)</text>
<text x="376" y="100">:</text> <text x="536" y="68">:</text>
<text x="544" y="100">:</text> <text x="8" y="84">:</text>
<text x="8" y="116">:</text> <text x="168" y="84">:</text>
<text x="44" y="116">[PE11]</text> <text x="184" y="84">:</text>
<text x="132" y="116">[ASBR11]</text> <text x="360" y="84">:</text>
<text x="216" y="116">[ASBR21</text> <text x="376" y="84">:</text>
<text x="324" y="116">[ASBR22]</text> <text x="536" y="84">:</text>
<text x="408" y="116">[ASBR31</text> <text x="8" y="100">:</text>
<text x="520" y="116">[PE31]:</text> <text x="44" y="100">[PE11]</text>
<text x="8" y="132">:</text> <text x="132" y="100">[ASBR11]</text>
<text x="168" y="132">:</text> <text x="216" y="100">[ASBR21</text>
<text x="184" y="132">:</text> <text x="324" y="100">[ASBR22]</text>
<text x="360" y="132">:</text> <text x="408" y="100">[ASBR31</text>
<text x="376" y="132">:</text> <text x="512" y="100">[PE31]:</text>
<text x="544" y="132">:</text> <text x="8" y="116">:</text>
<text x="8" y="148">:</text> <text x="168" y="116">:</text>
<text x="56" y="148">Metro</text> <text x="184" y="116">:</text>
<text x="112" y="148">Ingress</text> <text x="360" y="116">:</text>
<text x="168" y="148">:</text> <text x="376" y="116">:</text>
<text x="184" y="148">:</text> <text x="536" y="116">:</text>
<text x="268" y="148">Core</text> <text x="8" y="132">:</text>
<text x="360" y="148">:</text> <text x="56" y="132">Metro</text>
<text x="376" y="148">:</text> <text x="112" y="132">Ingress</text>
<text x="432" y="148">Metro</text> <text x="168" y="132">:</text>
<text x="484" y="148">Egress</text> <text x="184" y="132">:</text>
<text x="544" y="148">:</text> <text x="268" y="132">Core</text>
<text x="8" y="164">:</text> <text x="360" y="132">:</text>
<text x="168" y="164">:</text> <text x="376" y="132">:</text>
<text x="184" y="164">:</text> <text x="432" y="132">Metro</text>
<text x="360" y="164">:</text> <text x="484" y="132">Egress</text>
<text x="376" y="164">:</text> <text x="536" y="132">:</text>
<text x="544" y="164">:</text> <text x="8" y="148">:</text>
<text x="8" y="180">:</text> <text x="168" y="148">:</text>
<text x="88" y="180">AS1</text> <text x="184" y="148">:</text>
<text x="168" y="180">:</text> <text x="360" y="148">:</text>
<text x="184" y="180">:</text> <text x="376" y="148">:</text>
<text x="280" y="180">AS2</text> <text x="536" y="148">:</text>
<text x="360" y="180">:</text> <text x="8" y="164">:</text>
<text x="376" y="180">:</text> <text x="88" y="164">AS1</text>
<text x="464" y="180">AS3</text> <text x="168" y="164">:</text>
<text x="544" y="180">:</text> <text x="184" y="164">:</text>
<text x="88" y="196">.....................</text> <text x="280" y="164">AS2</text>
<text x="272" y="196">.......................</text> <text x="360" y="164">:</text>
<text x="460" y="196">......................</text> <text x="376" y="164">:</text>
<text x="240" y="228">Traffic</text> <text x="464" y="164">AS3</text>
<text x="312" y="228">Direction</text> <text x="536" y="164">:</text>
</g> <text x="88" y="180">.....................</text>
</svg> <text x="272" y="180">.......................</text>
</artwork><artwork type="ascii-art"><![CDATA[ <text x="456" y="180">.....................</text>
<text x="240" y="212">Traffic</text>
..................... ....................... ...................... <text x="312" y="212">Direction</text>
: : : Gold1(101) : : : </g>
: Gold(100) : : Gold2(102) : : Gold(100) : </svg>
: : : : : : </artwork>
: [PE11]----[ASBR11]---[ASBR21------[ASBR22]---[ASBR31-------[PE31]: <artwork type="ascii-art"><![CDATA[
: : : : : : ..................... ....................... .....................
: Metro Ingress : : Core : : Metro Egress : : : : Gold1(101) : : :
: : : : : : : Gold(100) : : Gold2(102) : : Gold(100) :
: AS1 : : AS2 : : AS3 : : : : : : :
..................... ....................... ...................... : [PE11]----[ASBR11]---[ASBR21------[ASBR22]---[ASBR31------[PE31]:
: : : : : :
: Metro Ingress : : Core : : Metro Egress :
: : : : : :
: AS1 : : AS2 : : AS3 :
..................... ....................... .....................
----------- Traffic Direction --------> ----------- Traffic Direction -------->
]]></artwork></artset></figure> ]]></artwork>
</artset>
</figure>
<t>In the preceding topology shown in <xref <t>In <xref target="BGPCT_HETERO_COLOR_DOMAIN" format="default"/>, we
target="BGPCT_HETERO_COLOR_DOMAIN"/>, we have three Autonomous have three Autonomous
Systems. All the nodes in the topology support BGP CT.</t> Systems. All the nodes in the topology support BGP CT.</t>
<ul spacing="normal">
<t>In AS1 Gold SLA is represented by color 100.</t> <li>In AS1, the Gold SLA is represented by color 100.</li>
<li>In AS2, Gold has finer shades: Gold1 by color 101 and Gold2 by
<t>In AS2 Gold has finer shades: Gold1 by color 101 and Gold2 by color 102.</li>
color 102.</t> <li>In AS3, the Gold SLA is represented by color 100.</li>
</ul>
<t>In AS3 Gold SLA is represented by color 100.</t> <t>This problem can be solved by the two approaches described in Secti
ons <xref target="dup_tun_ap" format="counter"/> and <xref target="cust_res_sche
<t>This problem can be solved by the two following approaches:</t> me" format="counter"/>.</t>
<section numbered="true" toc="default" anchor="dup_tun_ap">
<section title="Duplicate Tunnels Approach"> <name>Duplicate Tunnels Approach</name>
<t>In this approach, duplicate tunnels that satisfy Gold SLA are <t>In this approach, duplicate tunnels that satisfy the Gold SLA are
configured in domains AS1 and AS3, but they are given fine grained configured in domains AS1 and AS3, but they are given fine-grained
colors 101 and 102.</t> colors 101 and 102.</t>
<t>These tunnels will be installed in TRDBs corresponding to <t>These tunnels will be installed in TRDBs corresponding to
transport classes of color 101 and 102.</t> transport classes of colors 101 and 102.</t>
<t>Overlay routes received with a Mapping Community (e.g.,
<t>Overlay routes received with mapping community (e.g.:
transport-target or color community) can resolve over these transport-target or color community) can resolve over these
tunnels in the TRDB with matching color by using resolution tunnels in the TRDB with matching colors by using Resolution
schemes.</t> Schemes.</t>
<t>This approach consumes more resources in the transport and <t>This approach consumes more resources in the transport and
forwarding layer, because of the duplicate tunnels.</t> forwarding layer because of the duplicate tunnels.</t>
</section> </section>
<section numbered="true" toc="default" anchor="cust_res_scheme">
<section title="Customized Resolution Schemes Approach"> <name>Customized Resolution Schemes Approach</name>
<t>In this approach, resolution schemes in domains AS1 and AS3 are <t>In this approach, Resolution Schemes in domains AS1 and AS3 are
customized to map the received mapping community (e.g., customized to map the received Mapping Community (e.g.,
transport-target or color community) over available Gold SLA transport-target or color community) over available Gold SLA
tunnels. This conserves resource usage with no additional state in tunnels. This conserves resource usage with no additional state in
the transport or forwarding planes.</t> the transport or forwarding planes.</t>
<t>Service routes advertised by PE31 that need to resolve over <t>Service routes advertised by PE31 that need to resolve over
Gold1 transport tunnels carry a mapping community color:0:101. In Gold1 transport tunnels carry a Mapping Community color:0:101. In
AS3 and AS1, where Gold1 is not available, it is mapped to color AS3 and AS1, where Gold1 is not available, it is mapped to color
100 TRDB using a customized resolution scheme. In AS2, Gold1 is 100 TRDB using a customized Resolution Scheme. In AS2, Gold1 is
available and it maps to color 101 TRDB.</t> available, and it maps to color 101 TRDB.</t>
<t>Similarly, service routes advertised by PE31 that need to <t>Similarly, service routes advertised by PE31 that need to
resolve over Gold2 transport tunnels carry a mapping community resolve over Gold2 transport tunnels carry a Mapping Community
color:0:102. In AS3 and AS1, where Gold2 is not available, it is color:0:102. In AS3 and AS1, where Gold2 is not available, it is
mapped to color 100 TRDB using a customized resolution scheme. In mapped to color 100 TRDB using a customized Resolution Scheme. In
AS2, Gold2 is available and it maps to color 102 TRDB.</t> AS2, Gold2 is available, and it maps to color 102 TRDB.</t>
<t>To facilitate this, SNs/BNs in all three ASes provision the
<t>To facilitate this, SN/BN in all three AS provision the transport classes 100, 101, and 102. SNs and BNs in AS1 and AS3 are
transport classes 100, 101 and 102. SN and BN in AS1 and AS3 are provisioned with customized Resolution Schemes that resolve routes
provisioned with customized resolution schemes that resolve routes
with transport-target:0:101 or transport-target:0:102 using color with transport-target:0:101 or transport-target:0:102 using color
100 TRDB.</t> 100 TRDB.</t>
<t>PE31 is provisioned to originate BGP CT routes with color 101
<t>PE31 is provisioned to originate BGP CT route with color 101 for endpoint PE31. This route is sent with an NLRI RD prefix RD1:PE3
for endpoint PE31. This route is sent with NLRI RD prefix RD1:PE31 1
and route target extended community transport-target:0:101.</t> and Route Target extended community transport-target:0:101.</t>
<t>Similarly, PE31 is provisioned to originate BGP CT routes with
<t>Similarly, PE31 is provisioned to originate BGP CT route with color 102 for endpoint PE31. This route is sent with an NLRI RD
color 102 for endpoint PE31. This route is sent with NLRI RD prefix RD2:PE31 and Route Target extended community
prefix RD2:PE31 and route target extended community
transport-target:0:102.</t> transport-target:0:102.</t>
<t>The following description explains the remaining procedures with
<t>Following description explains the remaining procedures with color 101 as an example.</t>
color 101 as example.</t> <t>At ASBR31, the Route Target role of transport-target:0:101 on thi
s
<t>At ASBR31, the route target "transport-target:0:101" on this BGP CT route gives instruction to add the route to color 101 TRDB. A
BGP CT route instructs to add the route to color 101 TRDB. ASBR31 SBR31
is provisioned with customized resolution scheme that resolves the is provisioned with a customized Resolution Scheme that resolves the
routes carrying mapping community transport-target:0:101 to routes carrying Mapping Community transport-target:0:101 to
resolve using color 100 TRDB. This route is then re-advertised resolve using color 100 TRDB. This route is then readvertised
from color 101 TRDB to ASBR22 with route-target:0:101.</t> from color 101 TRDB to ASBR22 with route-target:0:101.</t>
<t>At ASBR22, the BGP CT routes received with <t>At ASBR22, the BGP CT routes received with
transport-target:0:101 will be added to color 101 TRDB and transport-target:0:101 will be added to color 101 TRDB and
strictly resolve over tunnel routes in the same TRDB. This route strictly resolve over tunnel routes in the same TRDB. This route
is re-advertised to ASBR21 with transport-target:0:101.</t> is readvertised to ASBR21 with transport-target:0:101.</t>
<t>Similarly, at ASBR21, the BGP CT routes received with <t>Similarly, at ASBR21, the BGP CT routes received with
transport-target:0:101 will be added to color 101 TRDB and transport-target:0:101 will be added to color 101 TRDB and
strictly resolve over tunnel routes in the same TRDB. This route strictly resolve over tunnel routes in the same TRDB. This route
is re-advertised to ASBR11 with transport-target:0:101.</t> is readvertised to ASBR11 with transport-target:0:101.</t>
<t>At ASBR11, the Route Target role of transport-target:0:101 on thi
<t>At ASBR11, the route target "transport-target:0:101" on this s
BGP CT route instructs to add the route to color 101 TRDB. ASBR11 BGP CT route gives instruction to add the route to color 101 TRDB. A
is provisioned with a customized resolution scheme that resolves SBR11
is provisioned with a customized Resolution Scheme that resolves
the routes carrying transport-target:0:101 to use color 100 TRDB. the routes carrying transport-target:0:101 to use color 100 TRDB.
This route is then re-advertised from color 101 TRDB to PE11 with This route is then readvertised from color 101 TRDB to PE11 with
transport-target:0:101.</t> transport-target:0:101.</t>
<t>At PE11, the Route Target role of transport-target:0:101 on this
<t>At PE11, the route target "transport-target:0:101" on this BGP BGP
CT route instructs to add the route to color 101 TRDB. PE11 is CT route gives instruction to add the route to color 101 TRDB. PE11
provisioned with a customized resolution scheme that resolves the is
provisioned with a customized Resolution Scheme that resolves the
routes carrying transport-target:0:101 to use color 100 TRDB.</t> routes carrying transport-target:0:101 to use color 100 TRDB.</t>
<t>When PE11 receives the service route with the Mapping Community
<t>When PE11 receives the service route with the mapping community color:0:101, it directly resolves over the BGP CT route in color
color:0:101 it directly resolves over the BGP CT route in color 101 TRDB, which, in turn, resolves over tunnel routes in color 100
101 TRDB, which in turn resolves over tunnel routes in color 100
TRDB.</t> TRDB.</t>
<t>Similar processing is done for color 102 routes also at ASBR31, <t>Similar processing is done for color 102 routes also at ASBR31,
ASBR22, ASBR21, ASBR11 and PE11.</t> ASBR22, ASBR21, ASBR11, and PE11.</t>
<t>In doing so, PE11 can forward traffic via tunnels with color <t>In doing so, PE11 can forward traffic via tunnels with color
101, color 102 in the core domain, and color 100 in the metro 101, color 102 in the core domain and color 100 in the metro
domains.</t> domains.</t>
</section> </section>
</section> </section>
</section> </section>
<section numbered="true" toc="default">
<section title="Migration Scenarios."> <name>Migration Scenarios</name>
<section title="BGP CT Islands Connected via BGP LU Domain"> <section numbered="true" toc="default">
<t>This section explains how end-to-end SLA can be achieved while <name>BGP CT Islands Connected via BGP LU 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 transiting a domain that does not support BGP CT. BGP LU is used in
such domains to connect the BGP CT islands.</t> such domains to connect the BGP CT islands.</t>
<figure anchor="BGPCTIsles">
<figure title="BGP CT in AS1 and AS3 connected by BGP LU in AS2" anchor="BGPCTIs <name>BGP CT in AS1 and AS3 Connected by BGP LU in AS2</name>
les"><artset><artwork type="svg"><svg xmlns="http://www.w3.org/2000/svg" versio <artset>
n="1.1" height="176" width="520" viewBox="0 0 520 176" class="diagram" text-anch <artwork type="svg" name="" align="left" alt=""><svg xmlns="http:/
or="middle" font-family="monospace" font-size="13px" stroke-linecap="round"> /www.w3.org/2000/svg" version="1.1" height="176" width="520" viewBox="0 0 520 17
<path d="M 104,32 L 104,64" fill="none" stroke="black"/> 6" class="diagram" text-anchor="middle" font-family="monospace" font-size="13px"
<path d="M 424,32 L 424,64" fill="none" stroke="black"/> stroke-linecap="round">
<path d="M 104,32 L 184,32" fill="none" stroke="black"/> <path d="M 104,32 L 104,64" fill="none" stroke="black"/>
<path d="M 320,32 L 424,32" fill="none" stroke="black"/> <path d="M 424,32 L 424,64" fill="none" stroke="black"/>
<path d="M 48,80 L 80,80" fill="none" stroke="black"/> <path d="M 104,32 L 184,32" fill="none" stroke="black"/>
<path d="M 144,80 L 200,80" fill="none" stroke="black"/> <path d="M 320,32 L 424,32" fill="none" stroke="black"/>
<path d="M 264,80 L 280,80" fill="none" stroke="black"/> <path d="M 48,80 L 80,80" fill="none" stroke="black"/>
<path d="M 344,80 L 392,80" fill="none" stroke="black"/> <path d="M 144,80 L 200,80" fill="none" stroke="black"/>
<path d="M 456,80 L 472,80" fill="none" stroke="black"/> <path d="M 264,80 L 280,80" fill="none" stroke="black"/>
<path d="M 128,112 L 144,112" fill="none" stroke="black"/> <path d="M 344,80 L 392,80" fill="none" stroke="black"/>
<path d="M 208,112 L 224,112" fill="none" stroke="black"/> <path d="M 456,80 L 472,80" fill="none" stroke="black"/>
<path d="M 328,112 L 344,112" fill="none" stroke="black"/> <path d="M 128,112 L 144,112" fill="none" stroke="black"/>
<path d="M 408,112 L 424,112" fill="none" stroke="black"/> <path d="M 208,112 L 224,112" fill="none" stroke="black"/>
<path d="M 24,128 L 40,128" fill="none" stroke="black"/> <path d="M 328,112 L 344,112" fill="none" stroke="black"/>
<path d="M 104,128 L 120,128" fill="none" stroke="black"/> <path d="M 408,112 L 424,112" fill="none" stroke="black"/>
<path d="M 224,128 L 240,128" fill="none" stroke="black"/> <path d="M 24,128 L 40,128" fill="none" stroke="black"/>
<path d="M 304,128 L 320,128" fill="none" stroke="black"/> <path d="M 104,128 L 120,128" fill="none" stroke="black"/>
<path d="M 400,128 L 416,128" fill="none" stroke="black"/> <path d="M 224,128 L 240,128" fill="none" stroke="black"/>
<path d="M 480,128 L 496,128" fill="none" stroke="black"/> <path d="M 304,128 L 320,128" fill="none" stroke="black"/>
<path d="M 120,160 L 184,160" fill="none" stroke="black"/> <path d="M 400,128 L 416,128" fill="none" stroke="black"/>
<path d="M 328,160 L 400,160" fill="none" stroke="black"/> <path d="M 480,128 L 496,128" fill="none" stroke="black"/>
<polygon class="arrowhead" points="504,128 492,122.4 492,133.6" fill="black" tra <path d="M 120,160 L 184,160" fill="none" stroke="black"/>
nsform="rotate(0,496,128)"/> <path d="M 328,160 L 400,160" fill="none" stroke="black"/>
<polygon class="arrowhead" points="432,112 420,106.4 420,117.6" fill="black" tra <polygon class="arrowhead" points="504,128 492,122.4 492,133.6
nsform="rotate(0,424,112)"/> " fill="black" transform="rotate(0,496,128)"/>
<polygon class="arrowhead" points="408,160 396,154.4 396,165.6" fill="black" tra <polygon class="arrowhead" points="432,112 420,106.4 420,117.6
nsform="rotate(0,400,160)"/> " fill="black" transform="rotate(0,424,112)"/>
<polygon class="arrowhead" points="408,128 396,122.4 396,133.6" fill="black" tra <polygon class="arrowhead" points="408,160 396,154.4 396,165.6
nsform="rotate(180,400,128)"/> " fill="black" transform="rotate(0,400,160)"/>
<polygon class="arrowhead" points="336,112 324,106.4 324,117.6" fill="black" tra <polygon class="arrowhead" points="408,128 396,122.4 396,133.6
nsform="rotate(180,328,112)"/> " fill="black" transform="rotate(180,400,128)"/>
<polygon class="arrowhead" points="328,128 316,122.4 316,133.6" fill="black" tra <polygon class="arrowhead" points="336,112 324,106.4 324,117.6
nsform="rotate(0,320,128)"/> " fill="black" transform="rotate(180,328,112)"/>
<polygon class="arrowhead" points="232,128 220,122.4 220,133.6" fill="black" tra <polygon class="arrowhead" points="328,128 316,122.4 316,133.6
nsform="rotate(180,224,128)"/> " fill="black" transform="rotate(0,320,128)"/>
<polygon class="arrowhead" points="232,112 220,106.4 220,117.6" fill="black" tra <polygon class="arrowhead" points="232,128 220,122.4 220,133.6
nsform="rotate(0,224,112)"/> " fill="black" transform="rotate(180,224,128)"/>
<polygon class="arrowhead" points="136,112 124,106.4 124,117.6" fill="black" tra <polygon class="arrowhead" points="232,112 220,106.4 220,117.6
nsform="rotate(180,128,112)"/> " fill="black" transform="rotate(0,224,112)"/>
<polygon class="arrowhead" points="128,128 116,122.4 116,133.6" fill="black" tra <polygon class="arrowhead" points="136,112 124,106.4 124,117.6
nsform="rotate(0,120,128)"/> " fill="black" transform="rotate(180,128,112)"/>
<polygon class="arrowhead" points="32,128 20,122.4 20,133.6" fill="black" transf <polygon class="arrowhead" points="128,128 116,122.4 116,133.6
orm="rotate(180,24,128)"/> " fill="black" transform="rotate(0,120,128)"/>
<g class="text"> <polygon class="arrowhead" points="32,128 20,122.4 20,133.6" f
<text x="204" y="36">EBGP</text> ill="black" transform="rotate(180,24,128)"/>
<text x="260" y="36">Multihop</text> <g class="text">
<text x="308" y="36">CT</text> <text x="204" y="36">EBGP</text>
<text x="64" y="68">AS3</text> <text x="260" y="36">Multihop</text>
<text x="272" y="68">AS2</text> <text x="308" y="36">CT</text>
<text x="464" y="68">AS1</text> <text x="64" y="68">AS3</text>
<text x="24" y="84">[PE31</text> <text x="272" y="68">AS2</text>
<text x="112" y="84">ASBR31]</text> <text x="464" y="68">AS1</text>
<text x="232" y="84">[ASBR22</text> <text x="24" y="84">[PE31</text>
<text x="312" y="84">ASBR21]</text> <text x="112" y="84">ASBR31]</text>
<text x="424" y="84">[ASBR11</text> <text x="232" y="84">[ASBR22</text>
<text x="496" y="84">PE11]</text> <text x="312" y="84">ASBR21]</text>
<text x="164" y="116">EBGP</text> <text x="424" y="84">[ASBR11</text>
<text x="196" y="116">LU</text> <text x="496" y="84">PE11]</text>
<text x="364" y="116">EBGP</text> <text x="164" y="116">EBGP</text>
<text x="396" y="116">LU</text> <text x="196" y="116">LU</text>
<text x="60" y="132">IBGP</text> <text x="364" y="116">EBGP</text>
<text x="92" y="132">CT</text> <text x="396" y="116">LU</text>
<text x="260" y="132">IBGP</text> <text x="60" y="132">IBGP</text>
<text x="292" y="132">LU</text> <text x="92" y="132">CT</text>
<text x="436" y="132">IBGP</text> <text x="260" y="132">IBGP</text>
<text x="468" y="132">CT</text> <text x="292" y="132">LU</text>
<text x="216" y="164">Traffic</text> <text x="436" y="132">IBGP</text>
<text x="288" y="164">Direction</text> <text x="468" y="132">CT</text>
</g> <text x="216" y="164">Traffic</text>
</svg> <text x="288" y="164">Direction</text>
</artwork><artwork type="ascii-art"><![CDATA[ </g>
</svg>
</artwork>
<artwork type="ascii-art" name="" align="left" alt=""><![CDATA[
+----------EBGP Multihop CT-------------+ +----------EBGP Multihop CT-------------+
| | | |
AS3 | AS2 | AS1 AS3 | AS2 | AS1
[PE31-----ASBR31]--------[ASBR22---ASBR21]-------[ASBR11---PE11] [PE31-----ASBR31]--------[ASBR22---ASBR21]-------[ASBR11---PE11]
<--EBGP LU--> <--EBGP LU--> <--EBGP LU--> <--EBGP LU-->
<--IBGP CT--> <--IBGP LU--> <--IBGP CT--> <--IBGP CT--> <--IBGP LU--> <--IBGP CT-->
---------Traffic Direction---------> ---------Traffic Direction--------->
]]></artwork></artset></figure> ]]></artwork>
</artset>
<t>In the preceding topology shown in <xref target="BGPCTIsles"/>, </figure>
there are three AS domains. AS1 and AS3 support BGP CT, while AS2 <t>In the preceding topology shown in <xref target="BGPCTIsles" format
="default"/>,
there are three AS domains: AS1 and AS3 support BGP CT, while AS2
does not support BGP CT.</t> does not support BGP CT.</t>
<t>Nodes in AS1, AS2, and AS3 negotiate BGP LU family on IBGP <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 sessions within the domain. Nodes in AS1 and AS3 negotiate BGP CT
family on IBGP sessions within the domain. ASBR11 and ASBR21 as well family on IBGP sessions within the domain. ASBR11 and ASBR21 as well
as ASBR22 and ASBR31 negotiate BGP LU family on the EBGP session as ASBR22 and ASBR31 negotiate BGP LU family on the EBGP session
over directly connected inter-domain links. ASBR11 and ASBR31 have over directly connected inter-domain links. ASBR11 and ASBR31 have
reachability to each other&rsquo;s loopbacks through BGP LU. ASBR11 reachability to each other's loopbacks through BGP LU. ASBR11
and ASBR31 negotiate BGP CT family over a multihop EBGP session and ASBR31 negotiate BGP CT family over a multihop EBGP session
formed using BGP LU reachability.</t> formed using BGP LU reachability.</t>
<t>The following tunnels exist for the Gold Transport Class</t>
<t>The following tunnels exist for Gold Transport Class<list> <ul spacing="normal">
<li>
<t>PE11_to_ASBR11_gold - RSVP-TE tunnel</t> <t>PE11_to_ASBR11_gold - RSVP-TE tunnel</t>
</li>
<li>
<t>ASBR11_to_PE11_gold - RSVP-TE tunnel</t> <t>ASBR11_to_PE11_gold - RSVP-TE tunnel</t>
</li>
<li>
<t>PE31_to_ASBR31_gold - SRTE tunnel</t> <t>PE31_to_ASBR31_gold - SRTE tunnel</t>
</li>
<li>
<t>ASBR31_to_PE31_gold - SRTE tunnel</t> <t>ASBR31_to_PE31_gold - SRTE tunnel</t>
</list></t> </li>
</ul>
<t>The following tunnels exist for Bronze Transport Class<list> <t>The following tunnels exist for the Bronze Transport Class</t>
<ul spacing="normal">
<li>
<t>PE11_to_ASBR11_bronze - RSVP-TE tunnel</t> <t>PE11_to_ASBR11_bronze - RSVP-TE tunnel</t>
</li>
<li>
<t>ASBR11_to_PE11_bronze - RSVP-TE tunnel</t> <t>ASBR11_to_PE11_bronze - RSVP-TE tunnel</t>
</li>
<li>
<t>PE31_to_ASBR31_bronze - SRTE tunnel</t> <t>PE31_to_ASBR31_bronze - SRTE tunnel</t>
</li>
<li>
<t>ASBR31_to_PE31_bronze - SRTE tunnel</t> <t>ASBR31_to_PE31_bronze - SRTE tunnel</t>
</list></t> </li>
</ul>
<t>These tunnels are provisioned to belong to Transport Classes Gold <t>These tunnels are provisioned to belong to Transport Classes Gold
and Bronze, and are advertised between ASBR31 and ASBR11 with Next and Bronze, and they are advertised between ASBR31 and ASBR11 with the
hop self.</t> next
hop set to themselves.</t>
<t>In AS2, that does not support BGP CT, a separate loopback may be <t>In AS2, which does not support BGP CT, a separate loopback may be
used on ASBR22 and ASBR21 to represent Gold and Bronze SLAs, viz. used on ASBR22 and ASBR21 to represent Gold and Bronze SLAs, namely
ASBR22_lpbk_gold, ASBR22_lpbk_bronze, ASBR21_lpbk_gold and ASBR22_lpbk_gold, ASBR22_lpbk_bronze, ASBR21_lpbk_gold, and
ASBR21_lpbk_bronze.</t> ASBR21_lpbk_bronze.</t>
<t>Furthermore, the following tunnels exist in AS2 to satisfy the <t>Furthermore, the following tunnels exist in AS2 to satisfy the
different SLAs, using per SLA loopback endpoints:<list> different SLAs using per-SLA-loopback endpoints:</t>
<ul spacing="normal">
<li>
<t>ASBR21_to_ASBR22_lpbk_gold - RSVP-TE tunnel</t> <t>ASBR21_to_ASBR22_lpbk_gold - RSVP-TE tunnel</t>
</li>
<li>
<t>ASBR22_to_ASBR21_lpbk_gold - RSVP-TE tunnel</t> <t>ASBR22_to_ASBR21_lpbk_gold - RSVP-TE tunnel</t>
</li>
<li>
<t>ASBR21_to_ASBR22_lpbk_bronze - RSVP-TE tunnel</t> <t>ASBR21_to_ASBR22_lpbk_bronze - RSVP-TE tunnel</t>
</li>
<li>
<t>ASBR22_to_ASBR21_lpbk_bronze - RSVP-TE tunnel</t> <t>ASBR22_to_ASBR21_lpbk_bronze - RSVP-TE tunnel</t>
</list></t> </li>
</ul>
<t>RD:PE11 BGP CT route is originated from PE11 towards ASBR11 with <t>The RD:PE11 BGP CT route is originated from PE11 towards ASBR11 wit
transport-target 'gold.' ASBR11 readvertises this route with next h
transport-target 'gold.' ASBR11 readvertises this route with the next
hop set to ASBR11_lpbk_gold on the EBGP multihop session towards hop set to ASBR11_lpbk_gold on the EBGP multihop session towards
ASBR31. ASBR11 originates BGP LU route for endpoint ASBR11_lpbk_gold ASBR31. ASBR11 originates a BGP LU route for endpoint ASBR11_lpbk_gold
on EBGP session to ASBR21 with a 'gold SLA' community, and BGP LU on an EBGP session to ASBR21 with a 'gold SLA' community and a BGP LU
route for ASBR11_lpbk_bronze with a 'bronze SLA' community. The SLA 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 community is used by ASBR31 to publish the BGP LU routes in the
corresponding BGP CT TRDBs.</t> corresponding BGP CT TRDBs.</t>
<t>ASBR21 readvertises the BGP LU route for endpoint <t>ASBR21 readvertises the BGP LU route for endpoint
ASBR11_lpbk_gold to ASBR22 with next hop set by local policy config ASBR11_lpbk_gold to ASBR22 with the next hop set by local policy confi g
to the unique loopback ASBR21_lpbk_gold by matching the 'gold SLA' to the unique loopback ASBR21_lpbk_gold by matching the 'gold SLA'
community received as part of BGP LU advertisement from ASBR11. community received as part of BGP LU advertisement from ASBR11.
ASBR22 receives this route and resolves the next hop over the ASBR22 receives this route and resolves the next hop over the
ASBR22_to_ASBR21_lpbk_gold RSVP-TE tunnel. On successful resolution, ASBR22_to_ASBR21_lpbk_gold RSVP-TE tunnel. On successful resolution,
ASBR22 readvertises this BGP LU route to ASBR31 with next hop self ASBR22 readvertises this BGP LU route to ASBR31 with the next hop set to itself
and a new label.</t> and a new label.</t>
<t>ASBR31 adds the ASBR11_lpbk_gold route received via EBGP LU from <t>ASBR31 adds the ASBR11_lpbk_gold route received via EBGP LU from
ASBR22 to 'gold' TRDB based on the received 'gold SLA' community. ASBR22 to a 'gold' TRDB based on the received 'gold SLA' community.
ASBR31 uses this 'gold' TRDB route to resolve the next hop ASBR31 uses this 'gold' TRDB route to resolve the next hop
ASBR11_lpbk_gold received on BGP CT route with transport-target ASBR11_lpbk_gold received on the BGP CT route with transport-target
'gold,' for the prefix RD:PE11 received over the EBGP multihop CT 'gold,' for the prefix RD:PE11 received over the EBGP multihop CT
session, thus preserving the end-to-end SLA. Now ASBR31 readvertises session, thus preserving the end-to-end SLA. Now ASBR31 readvertises
the BGP CT route for RD:PE11 with next hop as self thus stitching the BGP CT route for RD:PE11 with the next hop set to itself, thus sti tching
with the BGP LU LSP in AS2. Intra-domain traffic forwarding in AS1 with the BGP LU LSP in AS2. Intra-domain traffic forwarding in AS1
and AS3 follows the procedures as explained in <xref and AS3 follows the procedures as explained in <xref target="CTProc" f
target="CTProc">Illustration of CT Procedures</xref></t> ormat="default"></xref>.</t>
<t>In cases where an SLA cannot be preserved in AS2 because SLA-specif
<t>In cases where an SLA cannot be preserved in AS2 because SLA ic
specific tunnels and loopbacks don't exist in AS2, traffic can be tunnels and loopbacks don't exist in AS2, traffic can be
carried over available SLAs (e.g.: best effort SLA) by rewriting the carried over available SLAs (e.g., best-effort SLA) by rewriting the
next hop to ASBR21 loopback assigned to the available SLA. This next hop to an ASBR21 loopback assigned to the available SLA. This
eases migration in case of heterogeneous color domains as-well.</t> eases migration in case of a heterogeneous color domain as well.</t>
</section> </section>
<section numbered="true" toc="default">
<section title="BGP CT - Interoperability between MPLS and Other Forward <name>BGP CT: Interoperability Between MPLS and Other Forwarding Techn
ing Technologies "> ologies</name>
<t>This section describes how nodes supporting dissimilar <t>This section describes how nodes supporting dissimilar
encapsulation technologies can interoperate with each other when encapsulation technologies can interoperate when
using BGP CT family.</t> using the BGP CT family.</t>
<section numbered="true" toc="default">
<section title="Interop Between MPLS and SRv6 Nodes."> <name>Interoperation Between MPLS and SRv6 Nodes</name>
<t>BGP speakers may carry MPLS label and SRv6 SID in BGP CT SAFI <t>BGP speakers may carry MPLS labels and SRv6 SIDs in BGP CT SAFI
76 for AFIs 1 or 2 routes using protocol encoding as described in 76 for AFI 1 or 2 routes using protocol encoding as described in
<xref target="CTMultiEncap">Carrying Multiple Encapsulation <xref target="CTMultiEncap" format="default"></xref>.</t>
information</xref></t> <t>MPLS labels are carried using the encoding described in <xref tar
get="RFC8277"/>, and SRv6 SIDs
<t>MPLS Labels are carried using RFC 8277 encoding, and SRv6 SID are carried using the Prefix-SID attribute as specified in <xref tar
is carried using Prefix SID attribute as specified in <xref get="SRv6-Support" format="default"/>.</t>
target="SRv6-Support"/>.</t> <figure anchor="BGPCT_MPLS_SRV6">
<name>BGP CT Interoperation Between MPLS and SRv6 Nodes</name>
<figure title="BGP CT Interop between MPLS and SRv6 nodes" anchor="BGPCT_MPLS_SR <artset>
V6"><artset><artwork type="svg"><svg xmlns="http://www.w3.org/2000/svg" version <artwork type="svg" name="" align="left" alt=""><svg xmlns="http
="1.1" height="176" width="336" viewBox="0 0 336 176" class="diagram" text-ancho ://www.w3.org/2000/svg" version="1.1" height="176" width="336" viewBox="0 0 336
r="middle" font-family="monospace" font-size="13px" stroke-linecap="round"> 176" class="diagram" text-anchor="middle" font-family="monospace" font-size="13p
<path d="M 136,48 L 136,64" fill="none" stroke="black"/> x" stroke-linecap="round">
<path d="M 136,96 L 136,112" fill="none" stroke="black"/> <path d="M 136,48 L 136,64" fill="none" stroke="black"/>
<path d="M 80,32 L 104,32" fill="none" stroke="black"/> <path d="M 136,96 L 136,112" fill="none" stroke="black"/>
<path d="M 136,48 L 192,48" fill="none" stroke="black"/> <path d="M 80,32 L 104,32" fill="none" stroke="black"/>
<path d="M 72,80 L 128,80" fill="none" stroke="black"/> <path d="M 136,48 L 192,48" fill="none" stroke="black"/>
<path d="M 144,80 L 192,80" fill="none" stroke="black"/> <path d="M 72,80 L 128,80" fill="none" stroke="black"/>
<path d="M 136,112 L 192,112" fill="none" stroke="black"/> <path d="M 144,80 L 192,80" fill="none" stroke="black"/>
<path d="M 24,144 L 56,144" fill="none" stroke="black"/> <path d="M 136,112 L 192,112" fill="none" stroke="black"/>
<path d="M 248,144 L 288,144" fill="none" stroke="black"/> <path d="M 24,144 L 56,144" fill="none" stroke="black"/>
<path d="M 104,32 L 124,72" fill="none" stroke="black"/> <path d="M 248,144 L 288,144" fill="none" stroke="black"/>
<polygon class="arrowhead" points="296,144 284,138.4 284,149.6" fill="black" tra <path d="M 104,32 L 124,72" fill="none" stroke="black"/>
nsform="rotate(0,288,144)"/> <polygon class="arrowhead" points="296,144 284,138.4 284,149
<polygon class="arrowhead" points="32,144 20,138.4 20,149.6" fill="black" transf .6" fill="black" transform="rotate(0,288,144)"/>
orm="rotate(180,24,144)"/> <polygon class="arrowhead" points="32,144 20,138.4 20,149.6"
<g class="text"> fill="black" transform="rotate(180,24,144)"/>
<text x="64" y="36">RR1</text> <g class="text">
<text x="204" y="52">R2</text> <text x="64" y="36">RR1</text>
<text x="248" y="52">[MPLS</text> <text x="204" y="52">R2</text>
<text x="280" y="52">+</text> <text x="248" y="52">[MPLS</text>
<text x="312" y="52">SRv6]</text> <text x="280" y="52">+</text>
<text x="60" y="84">R1</text> <text x="312" y="52">SRv6]</text>
<text x="136" y="84">P</text> <text x="60" y="84">R1</text>
<text x="204" y="84">R3</text> <text x="136" y="84">P</text>
<text x="248" y="84">[MPLS</text> <text x="204" y="84">R3</text>
<text x="296" y="84">only]</text> <text x="248" y="84">[MPLS</text>
<text x="24" y="100">[MPLS</text> <text x="296" y="84">only]</text>
<text x="56" y="100">+</text> <text x="24" y="100">[MPLS</text>
<text x="88" y="100">SRv6]</text> <text x="56" y="100">+</text>
<text x="204" y="116">R4</text> <text x="88" y="100">SRv6]</text>
<text x="248" y="116">[SRv6</text> <text x="204" y="116">R4</text>
<text x="296" y="116">only]</text> <text x="248" y="116">[SRv6</text>
<text x="120" y="148">Bidirectional</text> <text x="296" y="116">only]</text>
<text x="208" y="148">Traffic</text> <text x="120" y="148">Bidirectional</text>
</g> <text x="208" y="148">Traffic</text>
</svg> </g>
</artwork><artwork type="ascii-art"><![CDATA[ </svg>
</artwork>
<artwork type="ascii-art" name="" align="left" alt=""><![CDATA[
RR1---+ RR1---+
\ +-------R2 [MPLS + SRv6] \ +-------R2 [MPLS + SRv6]
\ | \ |
R1--------P-------R3 [MPLS only] R1--------P-------R3 [MPLS only]
[MPLS + SRv6] | [MPLS + SRv6] |
+-------R4 [SRv6 only] +-------R4 [SRv6 only]
<---- Bidirectional Traffic -----> <---- Bidirectional Traffic ----->
]]></artwork></artset></figure> ]]></artwork>
</artset>
</figure>
<t>This example shows a provider network with a mix of devices <t>This example shows a provider network with a mix of devices
with different forwarding capabilities. R1 and R2 support that have different forwarding capabilities. R1 and R2 support
forwarding both MPLS and SRv6 packets. R3 supports forwarding MPLS forwarding both MPLS and SRv6 packets. R3 supports forwarding MPLS
packets only. R4 supports forwarding SRv6 packets only. All these packets only. R4 supports forwarding SRv6 packets only. All these
nodes have BGP session with Route Reflector RR1 which reflects nodes have a BGP session with Route Reflector RR1, which reflects
routes between these nodes with next hop unchanged. BGP CT family routes between these nodes with the next hop unchanged. The BGP CT f
amily
is negotiated on these sessions.</t> is negotiated on these sessions.</t>
<t>R1 and R2 send and receive both MPLS labels and SRv6 SIDs in the
<t>R1 and R2 send and receive both MPLS label and SRv6 SID in the
BGP CT control plane routes. This allows them to be ingress and BGP CT control plane routes. This allows them to be ingress and
egress for both MPLS and SRv6 data planes. MPLS label is carried egress for both MPLS and SRv6 data planes. The MPLS label is carried
using RFC 8277 encoding, and SRv6 SID is carried using Prefix SID using the encoding described in <xref target="RFC8277"/>, and an SRv
attribute as specified in <xref target="SRv6-Support"/>, without 6 SID is carried using the Prefix-SID
attribute as specified in <xref target="SRv6-Support" format="defaul
t"/> without the
Transposition Scheme. In this way, either MPLS or SRv6 forwarding Transposition Scheme. In this way, either MPLS or SRv6 forwarding
can be used between R1 and R2.</t> can be used between R1 and R2.</t>
<t>R1 and R3 send and receive an MPLS label in the BGP CT control
<t>R1 and R3 send and receive MPLS label in the BGP CT control plane routes using the encoding described in <xref target="RFC8277"/
plane routes using RFC 8277 encoding. This allows them to be >. This allows them to be
ingress and egress for MPLS data plane. R1 will carry SRv6 SID in ingress and egress for MPLS data plane. R1 will carry an SRv6 SID in
Prefix-SID attribute, which will not be used by R3. In order to the Prefix-SID attribute, which will not be used by R3. In order to
interoperate with MPLS only device R3, R1 MUST NOT use SRv6 interoperate with MPLS-only device R3, R1 <bcp14>MUST NOT</bcp14> us
Transposition scheme described in <xref target="RFC9252"/>. The e the SRv6
encoding suggested in <xref target="SRv6-Support"/> is used by R1. Transposition Scheme described in <xref target="RFC9252" format="def
ault"/>. The
encoding suggested in <xref target="SRv6-Support" format="default"/>
is used by R1.
MPLS forwarding will be used between R1 and R3.</t> MPLS forwarding will be used between R1 and R3.</t>
<t>R1 and R4 send and receive SRv6 SIDs in the BGP CT control plane
<t>R1 and R4 send and receive SRv6 SID in the BGP CT control plane routes using the BGP Prefix-SID attribute, without a Transposition
routes using BGP Prefix-SID attribute, without Transposition Scheme. This allows them to be ingress and egress for the SRv6 data
Scheme. This allows them to be ingress and egress for SRv6 data plane. R4 will carry the special MPLS label with a value of 3
plane. R4 will carry the special MPLS Label with value 3 (Implicit NULL) in the encoding described in <xref target="RFC8277"/
(Implicit-NULL) in RFC 8277 encoding, which tells R1 not to push >, which tells R1 not to push
any MPLS label for this BGP CT route towards R4. The MPLS Label any MPLS label for this BGP CT route towards R4. The MPLS label
advertised by R1 in RFC 8277 NLRI will not be used by R4. SRv6 advertised by R1 in an NLRI as described in <xref target="RFC8277"/>
will not be used by R4. SRv6
forwarding will be used between R1 and R4.</t> forwarding will be used between R1 and R4.</t>
<t>Note that, in this example, R3 and R4 cannot communicate directly
<t>Note in this example that R3 and R4 cannot communicate directly with each other because they don't support a common forwarding
with each other, because they don't support a common forwarding technology. The BGP CT routes received at R3 and R4 from each other
technology. The BGP CT routes received at R3, R4 from each other will remain unusable due to incompatible forwarding
will remain unusable, due to incompatible forwarding
technology.</t> technology.</t>
</section> </section>
<section numbered="true" toc="default">
<section title="Interop Between Nodes Supporting MPLS and UDP Tunnelin <name>Interop Between Nodes Supporting MPLS and UDP Tunneling</name>
g">
<t>This section describes how nodes supporting MPLS forwarding can <t>This section describes how nodes supporting MPLS forwarding can
interoperate with other nodes supporting UDP (or IP) tunneling, interoperate with other nodes supporting UDP (or IP) tunneling
when using BGP CT family.</t> when using BGP CT family.</t>
<t>MPLS labels are carried using the encoding described in <xref tar
<t>MPLS Labels are carried using RFC 8277 encoding, and UDP (or get="RFC8277"/>, and UDP (or
IP) tunneling information is carried using TEA attribute or the IP) tunneling information is carried using the TEA attribute or the
Encapsulation Extended Community as specified in <xref Encapsulation extended community as specified in <xref target="RFC90
target="RFC9012"/>.</t> 12" format="default"/>.</t>
<figure anchor="BGPCT_MPLS_UDP">
<figure title="BGP CT Interop between MPLS and UDP tunneling nodes" anchor="BGPC <name>BGP CT Interop Between MPLS and UDP Tunneling Nodes</name>
T_MPLS_UDP"><artset><artwork type="svg"><svg xmlns="http://www.w3.org/2000/svg" <artset>
version="1.1" height="176" width="328" viewBox="0 0 328 176" class="diagram" te <artwork type="svg" name="" align="left" alt=""><svg xmlns="http
xt-anchor="middle" font-family="monospace" font-size="13px" stroke-linecap="roun ://www.w3.org/2000/svg" version="1.1" height="176" width="328" viewBox="0 0 328
d"> 176" class="diagram" text-anchor="middle" font-family="monospace" font-size="13p
<path d="M 136,48 L 136,64" fill="none" stroke="black"/> x" stroke-linecap="round">
<path d="M 136,96 L 136,112" fill="none" stroke="black"/> <path d="M 136,48 L 136,64" fill="none" stroke="black"/>
<path d="M 80,32 L 104,32" fill="none" stroke="black"/> <path d="M 136,96 L 136,112" fill="none" stroke="black"/>
<path d="M 136,48 L 192,48" fill="none" stroke="black"/> <path d="M 80,32 L 104,32" fill="none" stroke="black"/>
<path d="M 72,80 L 128,80" fill="none" stroke="black"/> <path d="M 136,48 L 192,48" fill="none" stroke="black"/>
<path d="M 144,80 L 192,80" fill="none" stroke="black"/> <path d="M 72,80 L 128,80" fill="none" stroke="black"/>
<path d="M 136,112 L 192,112" fill="none" stroke="black"/> <path d="M 144,80 L 192,80" fill="none" stroke="black"/>
<path d="M 24,144 L 56,144" fill="none" stroke="black"/> <path d="M 136,112 L 192,112" fill="none" stroke="black"/>
<path d="M 248,144 L 288,144" fill="none" stroke="black"/> <path d="M 24,144 L 56,144" fill="none" stroke="black"/>
<path d="M 104,32 L 124,72" fill="none" stroke="black"/> <path d="M 248,144 L 288,144" fill="none" stroke="black"/>
<polygon class="arrowhead" points="296,144 284,138.4 284,149.6" fill="black" tra <path d="M 104,32 L 124,72" fill="none" stroke="black"/>
nsform="rotate(0,288,144)"/> <polygon class="arrowhead" points="296,144 284,138.4 284,149
<polygon class="arrowhead" points="32,144 20,138.4 20,149.6" fill="black" transf .6" fill="black" transform="rotate(0,288,144)"/>
orm="rotate(180,24,144)"/> <polygon class="arrowhead" points="32,144 20,138.4 20,149.6"
<g class="text"> fill="black" transform="rotate(180,24,144)"/>
<text x="64" y="36">RR1</text> <g class="text">
<text x="204" y="52">R2</text> <text x="64" y="36">RR1</text>
<text x="248" y="52">[MPLS</text> <text x="204" y="52">R2</text>
<text x="280" y="52">+</text> <text x="248" y="52">[MPLS</text>
<text x="308" y="52">UDP]</text> <text x="280" y="52">+</text>
<text x="60" y="84">R1</text> <text x="308" y="52">UDP]</text>
<text x="136" y="84">P</text> <text x="60" y="84">R1</text>
<text x="204" y="84">R3</text> <text x="136" y="84">P</text>
<text x="248" y="84">[MPLS</text> <text x="204" y="84">R3</text>
<text x="296" y="84">only]</text> <text x="248" y="84">[MPLS</text>
<text x="24" y="100">[MPLS</text> <text x="296" y="84">only]</text>
<text x="56" y="100">+</text> <text x="24" y="100">[MPLS</text>
<text x="84" y="100">UDP]</text> <text x="56" y="100">+</text>
<text x="204" y="116">R4</text> <text x="84" y="100">UDP]</text>
<text x="244" y="116">[UDP</text> <text x="204" y="116">R4</text>
<text x="288" y="116">only]</text> <text x="244" y="116">[UDP</text>
<text x="120" y="148">Bidirectional</text> <text x="288" y="116">only]</text>
<text x="208" y="148">Traffic</text> <text x="120" y="148">Bidirectional</text>
</g> <text x="208" y="148">Traffic</text>
</svg> </g>
</artwork><artwork type="ascii-art"><![CDATA[ </svg>
</artwork>
<artwork type="ascii-art" name="" align="left" alt=""><![CDATA[
RR1---+ RR1---+
\ +-------R2 [MPLS + UDP] \ +-------R2 [MPLS + UDP]
\ | \ |
R1--------P-------R3 [MPLS only] R1--------P-------R3 [MPLS only]
[MPLS + UDP] | [MPLS + UDP] |
+-------R4 [UDP only] +-------R4 [UDP only]
<---- Bidirectional Traffic -----> <---- Bidirectional Traffic ----->
]]></artwork></artset></figure> ]]></artwork>
</artset>
</figure>
<t>In this example, R1 and R2 support forwarding both MPLS and UDP <t>In this example, R1 and R2 support forwarding both MPLS and UDP
tunneled packets. R3 supports forwarding MPLS packets only. R4 tunneled packets. R3 supports forwarding MPLS packets only. R4
supports forwarding UDP tunneled packets only. All these nodes supports forwarding UDP tunneled packets only. All these nodes
have BGP session with Route Reflector RR1 which reflects routes have BGP session with Route Reflector RR1, which reflects routes
between these nodes with next hop unchanged. BGP CT family is between these nodes with the next hop unchanged. The BGP CT family i
s
negotiated on these sessions.</t> negotiated on these sessions.</t>
<t>R1 and R2 send and receive both MPLS labels and UDP tunneling
<t>R1 and R2 send and receive both MPLS label and UDP tunneling
info in the BGP CT control plane routes. This allows them to be info in the BGP CT control plane routes. This allows them to be
ingress and egress for both MPLS and UDP tunneling data planes. ingress and egress for both MPLS and UDP tunneling data planes.
MPLS label is carried using RFC 8277 encoding. As specified in The MPLS label is carried using the encoding described in <xref targ
<xref target="RFC9012"/>, UDP tunneling information is carried et="RFC8277"/>. As specified in
using TEA attribute (code 23) or the "barebones" Tunnel TLV <xref target="RFC9012" format="default"/>, UDP tunneling information
carried in Encapsulation Extended Community. Either MPLS or UDP is carried
tunneled forwarding can be used between R1 and R2.</t> using the Tunnel Encapsulation Attribute (attribute code 23) or the
"barebones" Tunnel TLV
<t>R1 and R3 send and receive MPLS label in the BGP CT control carried in Encapsulation extended community. Either MPLS or UDP
plane routes using RFC 8277 encoding. This allows them to be tunnel forwarding can be used between R1 and R2.</t>
<t>R1 and R3 send and receive MPLS labels in the BGP CT control
plane routes using the encoding described in <xref target="RFC8277"/
>. This allows them to be
ingress and egress for MPLS data plane. R1 will carry UDP ingress and egress for MPLS data plane. R1 will carry UDP
tunneling info in TEA attribute, which will not be used by R3. tunneling info in the TEA, which will not be used by R3.
MPLS forwarding will be used between R1 and R3.</t> MPLS forwarding will be used between R1 and R3.</t>
<t>R1 and R4 send and receive UDP tunneling info in the BGP CT <t>R1 and R4 send and receive UDP tunneling info in the BGP CT
control plane routes using BGP TEA attribute. This allows them to control plane routes using the BGP TEA. This allows them to
be ingress and egress for UDP tunneled data plane. R4 will carry be ingress and egress for UDP tunneled data plane. R4 will carry
special MPLS Label with value 3 (Implicit-NULL) in RFC 8277 MPLS special label 3 (Implicit NULL) in the encoding described in <x
encoding, which tells R1 not to push any MPLS label for this BGP ref target="RFC8277"/>,
CT route towards R4. The MPLS Label advertised by R1 will not be which tells R1 not to push any MPLS label for this BGP
CT route towards R4. The MPLS label advertised by R1 will not be
used by R4. UDP tunneled forwarding will be used between R1 and used by R4. UDP tunneled forwarding will be used between R1 and
R4.</t> R4.</t>
<t>Note that, in this example, R3 and R4 cannot communicate
<t>Note in this example that R3 and R4 cannot communicate directly with each other because they don't support a common
directly with each other, because they don't support a common forwarding technology. The BGP CT routes received at R3 and R4
forwarding technology. The BGP CT routes received at R3, R4 from each other will remain unusable due to incompatible
from each other will remain unusable, due to incompatible
forwarding technology.</t> forwarding technology.</t>
</section> </section>
</section> </section>
</section> </section>
<section numbered="true" toc="default">
<section title="MTU Considerations"> <name>MTU Considerations</name>
<t>Operators should coordinate the MTU of the intra-domain tunnels <t>Operators should coordinate the MTU of the intra-domain tunnels
used to prevent Path MTU discovery problems that could appear in used to prevent Path MTU discovery problems that could appear in
deployments. The encapsulation overhead due to the MPLS label stack or deployments. The encapsulation overhead due to the MPLS label stack or
equivalent tunnel header in different forwarding architecture should equivalent tunnel header in different forwarding architecture should
also be considered when determining the Path MTU of the end-to-end BGP also be considered when determining the Path MTU of the end-to-end BGP
CT tunnel.</t> CT tunnel.</t>
<t><xref target="I-D.ietf-intarea-tunnels" format="default"/> discusses
<t>The document <xref target="INTAREA-TUNNELS"/> discusses these these
considerations in more detail.</t> considerations in more detail.</t>
</section> </section>
<section numbered="true" toc="default">
<section title="Use of DSCP"> <name>Use of DSCP</name>
<t>BGP CT specifies procedures for Intent Driven Service Mapping in a <t>BGP CT specifies procedures for Intent Driven Service Mapping in a
service provider network, and defines 'Transport Class' construct to service provider network and defines the 'Transport Class' construct to
represent an Intent.</t> represent an Intent.</t>
<t>It may be desirable to allow a CE device to indicate in the data <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 packet it sends what treatment it desires (the Intent) when the packet
is forwarded within the provider network.</t> is forwarded within the provider network.</t>
<t>Such an indication can be in form of DSCP code point <xref <t>Such an indication can be in the form of a DSCP (see <xref target="RF
target="RFC2474"/> in the IP header.</t> C2474" format="default"/>) in the IP header.</t>
<t>In <xref target="RFC2474"/>, a Forwarding Class Selector maps to a PH
<t>In RFC2474, a Forwarding Class Selector maps to a PHB (Per-hop B (Per-hop
Behavior). The Transport Class construct is a PHB at transport Behavior). The Transport Class construct is a PHB at the transport
layer.</t> layer.</t>
<figure anchor="Intent_PE_CE">
<figure title="Example Topology with DSCP on PE-CE Links" anchor="Intent_PE_CE"> <name>Example Topology with DSCP on PE-CE Links</name>
<artset><artwork type="svg"><svg xmlns="http://www.w3.org/2000/svg" version="1. <artset>
1" height="128" width="432" viewBox="0 0 432 128" class="diagram" text-anchor="m <artwork type="svg" name="" align="left" alt=""><svg xmlns="http://w
iddle" font-family="monospace" font-size="13px" stroke-linecap="round"> ww.w3.org/2000/svg" version="1.1" height="128" width="432" viewBox="0 0 432 128"
<path d="M 152,32 L 176,32" fill="none" stroke="black"/> class="diagram" text-anchor="middle" font-family="monospace" font-size="13px" s
<path d="M 216,32 L 256,32" fill="none" stroke="black"/> troke-linecap="round">
<path d="M 96,48 L 128,48" fill="none" stroke="black"/> <path d="M 152,32 L 176,32" fill="none" stroke="black"/>
<path d="M 176,48 L 192,48" fill="none" stroke="black"/> <path d="M 216,32 L 256,32" fill="none" stroke="black"/>
<path d="M 224,48 L 248,48" fill="none" stroke="black"/> <path d="M 96,48 L 128,48" fill="none" stroke="black"/>
<path d="M 296,48 L 328,48" fill="none" stroke="black"/> <path d="M 176,48 L 192,48" fill="none" stroke="black"/>
<path d="M 152,64 L 168,64" fill="none" stroke="black"/> <path d="M 224,48 L 248,48" fill="none" stroke="black"/>
<path d="M 224,64 L 256,64" fill="none" stroke="black"/> <path d="M 296,48 L 328,48" fill="none" stroke="black"/>
<path d="M 96,96 L 128,96" fill="none" stroke="black"/> <path d="M 152,64 L 168,64" fill="none" stroke="black"/>
<path d="M 272,96 L 304,96" fill="none" stroke="black"/> <path d="M 224,64 L 256,64" fill="none" stroke="black"/>
<polygon class="arrowhead" points="312,96 300,90.4 300,101.6" fill="black" trans <path d="M 96,96 L 128,96" fill="none" stroke="black"/>
form="rotate(0,304,96)"/> <path d="M 272,96 L 304,96" fill="none" stroke="black"/>
<polygon class="arrowhead" points="264,64 252,58.4 252,69.6" fill="black" transf <polygon class="arrowhead" points="312,96 300,90.4 300,101.6" fi
orm="rotate(0,256,64)"/> ll="black" transform="rotate(0,304,96)"/>
<polygon class="arrowhead" points="264,32 252,26.4 252,37.6" fill="black" transf <polygon class="arrowhead" points="264,64 252,58.4 252,69.6" fil
orm="rotate(0,256,32)"/> l="black" transform="rotate(0,256,64)"/>
<g class="text"> <polygon class="arrowhead" points="264,32 252,26.4 252,37.6" fil
<text x="196" y="36">Gold</text> l="black" transform="rotate(0,256,32)"/>
<text x="72" y="52">[CE1]</text> <g class="text">
<text x="152" y="52">[PE1]</text> <text x="196" y="36">Gold</text>
<text x="208" y="52">[P]</text> <text x="72" y="52">[CE1]</text>
<text x="272" y="52">[PE2]</text> <text x="152" y="52">[PE1]</text>
<text x="352" y="52">[CE2]</text> <text x="208" y="52">[P]</text>
<text x="196" y="68">Bronze</text> <text x="272" y="52">[PE2]</text>
<text x="52" y="84">203.0.113.11</text> <text x="352" y="52">[CE2]</text>
<text x="380" y="84">203.0.113.22</text> <text x="196" y="68">Bronze</text>
<text x="160" y="100">Traffic</text> <text x="52" y="84">203.0.113.11</text>
<text x="232" y="100">direction</text> <text x="380" y="84">203.0.113.22</text>
</g> <text x="160" y="100">Traffic</text>
</svg> <text x="232" y="100">direction</text>
</artwork><artwork type="ascii-art"><![CDATA[ </g>
</svg>
</artwork>
<artwork type="ascii-art" name="" align="left" alt=""><![CDATA[
----Gold-----> ----Gold----->
[CE1]-----[PE1]---[P]----[PE2]-----[CE2] [CE1]-----[PE1]---[P]----[PE2]-----[CE2]
---Bronze----> ---Bronze---->
203.0.113.11 203.0.113.22 203.0.113.11 203.0.113.22
-----Traffic direction----> -----Traffic direction---->
]]></artwork></artset></figure> ]]></artwork>
</artset>
<t>Let PE1 be configured to map DSCP1 to Gold Transport class, and </figure>
DSCP2 to Bronze Transport class. Based on the DSCP code point received <t>Let PE1 be configured to map DSCP1 to the Gold TC and
on the IP traffic from CE device, PE1 forwards the IP packet over a DSCP2 to the Bronze TC. Based on the DSCP 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 Gold or Bronze TC tunnel. Thus, the forwarding is not based on just
the destination IP address, but also the DSCP code point. This is the destination IP address but also the DSCP. This is
known as Class Based Forwarding (CBF).</t> known as Class-Based Forwarding (CBF).</t>
<t>CBF is configured at the PE1 device, mapping the DSCP values to <t>CBF is configured at the PE1 device, mapping the DSCP values to
respective Transport Classes. This mapping (DSCP peering agreement) is respective Transport Classes. This mapping (DSCP peering agreement) is
communicated to CE device by out of band mechanisms. This allows the communicated to CE devices by out-of-band mechanisms. This allows the
administrator of CE1 to discover what transport classes exist in the administrator of CE1 to discover what Transport Classes exist in the
provider network, and which DSCP codepoint to encode so that traffic provider network and which DSCP to encode so that traffic
is forwarded using the desired Transport Class in the provided is forwarded using the desired Transport Class in the provided
network. When the IP packet exits the provider network to CE2, PE2 network. When the IP packet exits the provider network to CE2, PE2
resets the DSCP code point based on DSCP peering agreement with resets the DSCP based on the DSCP peering agreement with
CE2.</t> CE2.</t>
</section> </section>
</section> </section>
<section numbered="true" toc="default">
<section title="Applicability to Network Slicing"> <name>Applicability to Network Slicing</name>
<t>In Network Slicing, the Network Slice Controller (IETF NSC) is <t>In Network Slicing, the IETF Network Slice Controller (NSC) is
responsible for customizing and setting up the underlying transport responsible for customizing and setting up the underlying transport
(e.g. RSVP-TE, SRTE tunnels with desired characteristics) and resources (e.g., RSVP-TE, SRTE tunnels with desired characteristics) and resources
(e.g., polices/shapers) in a transport network to create an IETF Network (e.g., policies/shapers) in a transport network to create an IETF Network
Slice.</t> Slice.</t>
<t>The Transport Class construct described in this document can be used <t>The Transport Class construct described in this document can be used
to realize the "IETF Network Slice" described in Section 4 of <xref to realize the "IETF Network Slice" described in <xref target="RFC9543" se
target="RFC9543"/></t> ctionFormat="of" section="4"/>.</t>
<t>The NSC can use the Transport Class Identifier (Color value) to <t>The NSC can use the Transport Class Identifier (Color value) to
provision a transport tunnel in a specific IETF Network Slice.</t> provision a transport tunnel in a specific IETF Network Slice.</t>
<t>Furthermore, the NSC can use the Mapping Community on the service <t>Furthermore, the NSC can use the Mapping Community on the service
route to map traffic to the desired IETF Network Slice.</t> route to map traffic to the desired IETF Network Slice.</t>
</section> </section>
<section anchor="IANA" numbered="true" toc="default">
<section anchor="IANA" title="IANA Considerations"> <name>IANA Considerations</name>
<t>This document makes the following requests of IANA.</t> <section numbered="true" toc="default">
<name>New BGP SAFI</name>
<section title="New BGP SAFI"> <t>IANA has assigned BGP SAFI code 76 for the "Classful Transport (CT)"
<t>IANA has assigned a BGP SAFI code for "Classful Transport". Value SAFI.</t>
76. IANA is requested to update the reference to this document.</t>
<figure>
<artwork>
Registry Group: Subsequent Address Family Identifiers (SAFI) Parameters
Registry Name: SAFI Values
Value Description
-------------+--------------------------
76 Classful Transport SAFI
</artwork>
</figure>
<t>This will be used to create new AFI,SAFI pairs for IPv4, IPv6
Classful Transport families. viz:</t>
<t><list style="symbols"> <dl spacing="normal" newline="false">
<t>"IPv4, Classful Transport". AFI/SAFI = "1/76" for carrying IPv4 <dt>Registry Group:</dt><dd>Subsequent Address Family Identifiers (SAFI
Classful Transport prefixes.</t> ) Parameters</dd>
<dt>Registry Name:</dt><dd><t>SAFI Values</t>
<t>"IPv6, Classful Transport". AFI/SAFI = "2/76" for carrying IPv6 <table>
Classful Transport prefixes.</t> <thead>
</list></t> <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 pairs for IPv4 and IPv6
BGP CT families, namely:</t>
<ul spacing="normal">
<li>
<t>IPv4 BGP CT: AFI/SAFI = 1/76, for carrying IPv4 prefixes.</t>
</li>
<li>
<t>IPv6 BGP CT: AFI/SAFI = 2/76, for carrying IPv6 prefixes.</t>
</li>
</ul>
</section> </section>
<section numbered="true" toc="default">
<section title="New Format for BGP Extended Community"> <name>New Format for BGP Extended Community</name>
<t>IANA has assigned a Format type (Type high = 0xa) of Extended <t>IANA has assigned a Format type (Type high = 0xa) of Extended
Community <xref target="RFC4360">EXT-COMM</xref> for Transport Class Community <xref target="RFC4360" format="default"></xref> for the Transp
from the following registries:<list> ort Class
<t>the "BGP Transitive Extended Community Types" registry, and</t> from the following registries in the "Border Gateway Protocol (BGP) Exte
nded Communities" registry group:</t>
<ul spacing="normal">
<li>
<t>the "BGP Transitive Extended Community Types" registry and</t>
</li>
<li>
<t>the "BGP Non-Transitive Extended Community Types" registry.</t> <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 <t>The same low-order six bits have been assigned for both
allocations.</t> 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), <t>This document uses this new Format with subtype 0x2 (route target),
as a transitive extended community. The Route Target thus formed is as a transitive extended community. The Route Target thus formed is
called "Transport Class" route target extended community.</t> called "Transport Class Route Target extended community".</t>
<t>The non-transitive Transport Class extended community with subtype
<t>The Non-Transitive Transport Class Extended community with subtype 0x2 (route target) is called the "Non-Transitive Transport Class Route
0x2 (route target) is called the "Non-Transitive Transport Class route Target extended community".</t>
target extended community".</t> <t>Following <xref target="RFC7153" format="default"/>,
assignments in the following subsections have been made.</t>
<t>Taking reference of <xref target="RFC7153"/> , the following <section numbered="true" toc="default">
assignments have been made:</t> <name>Existing Registries</name>
<section numbered="true" toc="default">
<section title="Existing Registries"> <name>Registries for the "Type" Field</name>
<section title="Registries for the &quot;Type&quot; Field"> <section anchor="tc-rt-t" numbered="true" toc="default">
<section anchor="tc-rt-t" title="Transitive Types"> <name>Transitive Types</name>
<t>This registry contains values of the high-order octet (the <t>This registry contains values of the high-order octet (the
"Type" field) of a Transitive Extended Community.<figure> "Type" field) of a Transitive Extended Community.</t>
<artwork>Registry Group: Border Gateway Protocol (BGP) Extende
d Communities
Registry Name: BGP Transitive Extended Community Types
Type Value Name
--------------+---------------
0x0a Transport Class
(Sub-Types are defined in the <dl spacing="normal" newline="false">
"Transitive Transport Class Extended Community Sub-Types" <dt>Registry Group:</dt><dd>Border Gateway Protocol (BGP) Extende
registry) </artwork> d Communities</dd>
</figure></t> <dt>Registry Name:</dt><dd><t>BGP Transitive Extended Community T
ypes</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 Exte
nded Community Sub-Types" registry.)</t>
</dd>
</dl>
</section> </section>
<section anchor="tc-rt-nt" numbered="true" toc="default">
<section anchor="tc-rt-nt" title="Non-Transitive Types"> <name>Non-Transitive Types</name>
<t>This registry contains values of the high-order octet (the <t>This registry contains values of the high-order octet (the
"Type" field) of a Non-transitive Extended Community.<figure> "Type" field) of a Non-Transitive Extended Community.</t>
<artwork> Registry Group: Border Gateway Protocol (BGP) Extend
ed Communities
Registry Name: BGP Non-Transitive Extended Community Types
Type Value Name
--------------+--------------------------------
0x4a Non-Transitive Transport Class
(Sub-Types are defined in the <dl spacing="normal" newline="false">
"Non-Transitive Transport Class Extended Community Sub-Types" <dt>Registry Group:</dt><dd>Border Gateway Protocol (BGP) Extende
registry) d Communities</dd>
</artwork> <dt>Registry Name:</dt><dd><t>BGP Non-Transitive Extended Communi
</figure></t> ty 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.)</t>
</dd>
</dl>
</section> </section>
</section> </section>
</section> </section>
<section numbered="true" toc="default">
<name>New Registries</name>
<section numbered="true" toc="default">
<name>Transitive Transport Class Extended Community Sub-Types Regist
ry</name>
<t>IANA has added the following subregistry under the
"Border Gateway Protocol (BGP) Extended
Communities" registry group:</t>
<dl spacing="normal" newline="false">
<dt>Registry Group:</dt><dd>Border Gateway Protocol (BGP) Extende
d Communities</dd>
<dt>Registry Name:</dt><dd>Transitive Transport Class Extended Co
mmunity 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.</t>
<section title="New Registries"> <table>
<section title="Transitive Transport Class Extended Community Sub-Type <thead>
s Registry"> <tr><th>Range</th><th>Registration Procedure</th></tr>
<t>IANA is requested to add the following subregistry under the </thead>
&ldquo;Border Gateway Protocol (BGP) Extended <tbody>
Communities&rdquo;:</t> <tr><td>0x00-0xbf</td><td>First Come First Served</td></tr>
<tr><td>0xc0-0xff</td><td>IETF Review</td></tr>
<figure> </tbody>
<artwork> Registry Group: Border Gateway Protocol (BGP) Extended C </table>
ommunities <table>
<thead>
Registry Name: Transitive Transport Class Extended Community Sub-Types <tr><td>Sub-Type Value</td><td>Name</td></tr>
</thead>
Note: <tbody>
This registry contains values of the second octet (the <tr><td>0x02</td><td>Route Target</td></tr>
"Sub-Type" field) of an extended community when the value of the </tbody>
first octet (the "Type" field) is 0x0a. </table>
Range Registration Procedures
-----------------+----------------------------
0x00-0xBF First Come First Served
0xC0-0xFF IETF Review
Sub-Type Value Name
-----------------+--------------
0x02 Route Target
</artwork>
</figure>
</section> </section>
<section numbered="true" toc="default">
<name>Non-Transitive Transport Class Extended Community Sub-Types Re
gistry</name>
<t>IANA has added the following subregistry under the
"Border Gateway Protocol (BGP) Extended
Communities" registry group:</t>
<dl spacing="normal" newline="false">
<dt>Registry Group:</dt><dd>Border Gateway Protocol (BGP) Extended
Communities</dd>
<dt>Registry Name:</dt><dd>Non-Transitive Transport Class Extended
Community 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.</t>
<section title="Non-Transitive Transport Class Extended Community Sub- <table>
Types Registry"> <thead>
<t>IANA is requested to add the following subregistry under the <tr><th>Range</th><th>Registration Procedure</th></tr>
&ldquo;Border Gateway Protocol (BGP) Extended </thead>
Communities&rdquo;:</t> <tbody>
<tr><td>0x00-0xbf</td><td>First Come First Served</td></tr>
<figure> <tr><td>0xc0-0xff</td><td>IETF Review</td></tr>
<artwork> Registry Group: Border Gateway Protocol (BGP) Extended C </tbody>
ommunities </table>
Registry Name: Non-Transitive Transport Class Extended Community Sub-Types
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 Come First Served
0xC0-0xFF IETF Review
Sub-Type Value Name <table>
-----------------+-------------- <thead>
0x02 Route Target <tr><th>Sub-Type Value</th><th>Name</th></tr>
</thead>
<tbody>
<tr><td>0x02</td><td>Route Target</td></tr>
</tbody>
</table>
</artwork>
</figure>
</section> </section>
</section> </section>
</section> </section>
<section numbered="true" toc="default">
<section title="MPLS OAM Code Points"> <name>MPLS OAM Code Points</name>
<t>The following two code points have been assigned for Target FEC <t>The following two code points have been assigned for Target FEC
Stack sub-TLVs:</t> Stack sub-TLVs:</t>
<ul spacing="normal">
<t><list style="symbols"> <li>
<t>IPv4 BGP Classful Transport</t> <t>IPv4 BGP Classful Transport</t>
</li>
<li>
<t>IPv6 BGP Classful Transport</t> <t>IPv6 BGP Classful Transport</t>
</list><figure> </li>
<artwork> Registry Group: Multiprotocol Label Switching (MPLS) </ul>
Label Switched Paths (LSPs) Ping Parameters
Registry Name: Sub-TLVs for TLV Types 1, 16, and 21
Sub-Type Name
-----------------+------------------------------
31744 IPv4 BGP Classful Transport
31745 IPv6 BGP Classful Transport
</artwork> <dl spacing="normal" newline="false">
</figure></t> <dt>Registry Group:</dt><dd>Multiprotocol Label Switching (MPLS) Label
Switched Paths (LSPs) Ping Parameters</dd>
<dt>Registry Name:</dt><dd><t>Sub-TLVs for TLV Types 1, 16, and 21</t>
<table>
<thead>
<tr><th>Sub-Type</th><th>Name</th></tr>
</thead>
<tbody>
<tr><td>31744</td><td>IPv4 BGP Classful Transport</td></tr>
<tr><td>31745</td><td>IPv6 BGP Classful Transport</td></tr>
</tbody>
</table>
</dd>
</dl>
<t>IANA is requested to update the reference to this document.</t>
</section> </section>
</section> </section>
<section anchor="local-registries" title="Registries maintained by this document <section numbered="true" toc="default">
"> <name>Transport Class ID Registry</name>
<section title="Transport Class ID"> <t>This RFC documents the "Transport Class ID" registry and its assigned
<t>This document reserves the Transport class ID value 0 to represent values. The value ranges in this registry are either assigned by this document
"Best Effort Transport Class ID". This is used in the 'Transport Class or reserved for Private Use. Because the registry is complete, it is being pub
ID' field of Transport Route Target extended community that represents lished in this RFC rather than as an IANA-maintained registry. However, note th
best effort transport class.</t> at IANA-related terminology <xref target="BCP26" format="default"/> is used here
.</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: Transport Class ID
Value Name <t>Registry Name: Transport Class ID</t>
-----------------+--------------------------------
0 Best Effort Transport Class ID
1-4294967295 Private Use
Reference: This document. <t>The Registration Procedures are as follows:</t>
Registration Procedure(s) <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>
Value Registration Procedure <t>As shown in the table below, the Transport Class ID value 0 is Reserved to re
-----------------+-------------------------------- present the "Best-Effort Transport Class ID". This is used in the 'Transport Cl
0 IETF Review ass ID' field of a Transport Class RT that represents the Best-Effort Transport
1-4294967295 Private Use Class.</t>
</artwork> <table>
</figure></t> <thead>
<tr><th>Value</th><th>Name</th></tr>
</thead>
<tbody>
<tr><td>0</td><td>Best-Effort Transport Class ID</td></tr>
<tr><td>1-4294967295</td><td>Private Use</td></tr>
</tbody>
</table>
<t>As noted in Sec 4 and Sec 7.10, 'Transport Class ID' is <t>As noted in Sections <xref target="tc" format="counter"/> and <xref
target="bgp-att" format="counter"/>, 'Transport Class ID' is
interchangeable with 'Color'. For purposes of backward compatibility interchangeable with 'Color'. For purposes of backward compatibility
with usage of 'Color' field in Color extended community as specified with usage of a 'Color' field in a Color extended community as specified
in <xref target="RFC9012"/> and <xref target="RFC9256"/>, the range in <xref target="RFC9012" format="default"/> and <xref
1-4294967295 uses 'Private Use' as Registration Procedure.</t> target="RFC9256" format="default"/>, the range 1-4294967295 uses
'Private Use' as the Registration Procedure.</t>
</section> </section>
</section> <section anchor="Security" numbered="true" toc="default">
<section anchor="Security" title="Security Considerations"> <name>Security Considerations</name>
<t>This document uses <xref target="RFC4760"/> mechanisms to define new <t>This document uses the mechanisms from <xref target="RFC4760" format="d
BGP address families (AFI/SAFI : 1/76 and 2/76) that carry transport efault"/> to define new
layer endpoints. These address families are explicitly configured and 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 negotiated between BGP speakers, which confines the propagation scope of
this reachability information. These routes stay in the part of network this reachability information. These routes stay in the part of network
where the new address family is negotiated, and don't leak out into where the new address family is negotiated and don't leak out into
the Internet. </t> the Internet. </t>
<t>Furthermore, procedures defined in <xref target="secure-propagate" form
<t>Furthermore, procedures defined in <xref target="secure-propagate"/> mi at="default"/> mitigate
tigate the risk of unintended propagation of BGP CT routes across inter-AS
the risk of unintended propagation of BGP CT routes across Inter-AS boundaries even when a BGP CT family is negotiated. BGP import and export
boundaries even when BGP CT family is negotiated. BGP import and export po policies
licies
are used to control the BGP CT reachability information exchanged across A S boundaries. are used to control the BGP CT reachability information exchanged across A S boundaries.
This mitigates the risk of advertising internal loopback addresses outside the This mitigates the risk of advertising internal loopback addresses outside the
administrative control of the provider network. </t> administrative control of the provider network. </t>
<t>This document does not change the underlying security issues inherent <t>This document does not change the underlying security issues inherent
in the existing BGP protocol, such as those described in <xref in the existing BGP protocol, such as those described in <xref target="RFC
target="RFC4271"/> and <xref target="RFC4272"/>.</t> 4271" format="default"/> and <xref target="RFC4272" format="default"/>.</t>
<t>Additionally, BGP sessions <bcp14>SHOULD</bcp14> be protected using the
<t>Additionally, BGP sessions SHOULD be protected using TCP TCP
Authentication Option <xref target="RFC5925"/> and the Generalized TTL Authentication Option <xref target="RFC5925" format="default"/> and the Ge
Security Mechanism <xref target="RFC5082"/>.</t> neralized TTL
Security Mechanism <xref target="RFC5082" format="default"/>.</t>
<t>Using a separate BGP family and new RT (Transport Class RT) minimizes <t>Using a separate BGP family and new RT (Transport Class RT) minimizes
the possibility of these routes mixing with service routes.</t> 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, <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 there is a possibility of SAFI 4 routes mixing with SAFI 1 service
routes. To avoid such scenarios, it is RECOMMENDED that implementations routes. To avoid such scenarios, it is <bcp14>RECOMMENDED</bcp14> that imp lementations
support keeping SAFI 76 and SAFI 4 transport routes in separate support keeping SAFI 76 and SAFI 4 transport routes in separate
transport RIBs, distinct from service RIB that contain SAFI 1 service transport RIBs, distinct from service RIB that contain SAFI 1 service
routes.</t> routes.</t>
<t>BGP CT routes distribute label binding using <xref target="RFC8277" for
<t>BGP CT routes distribute label binding using <xref target="RFC8277"/> mat="default"/>
for MPLS dataplane and hence its security considerations apply.</t> for the MPLS data plane; hence, its security considerations apply.</t>
<t>BGP CT routes distribute SRv6 SIDs for SRv6 data planes; hence,
<t>BGP CT routes distribute SRv6 SIDs for SRv6 dataplanes and hence the security considerations of <xref target="RFC9252" sectionFormat="of" s
security considerations of Section 9.3 of <xref target="RFC9252"/> ection="9.3"/>
apply. Moreover, SRv6 SID transposition scheme is disabled in BGP CT, as apply. Moreover, the SRv6 SID Transposition Scheme is disabled in BGP CT,
described in <xref target="SRv6-Support"/>, to mitigate the risk of as
described in <xref target="SRv6-Support" format="default"/>, to mitigate t
he risk of
misinterpreting transposed SRv6 SID information as an MPLS label.</t> misinterpreting transposed SRv6 SID information as an MPLS label.</t>
<t>As <xref target="RFC4272" format="default"/> discusses, BGP is vulnerab
<t>As <xref target="RFC4272"/> discusses, BGP is vulnerable to le to
traffic-diversion attacks. This SAFI routes adds a new means by which an traffic-diversion attacks. This SAFI route adds a new means by which an
attacker could cause the traffic to be diverted from its normal path. attacker could cause the traffic to be diverted from its normal path.
Potential consequences include "hijacking" of traffic (insertion of an Potential consequences include "hijacking" of traffic (insertion of an
undesired node in the path, which allows for inspection or modification undesired node in the path, which allows for inspection or modification
of traffic, or avoidance of security controls) or denial of service of traffic, or avoidance of security controls) or denial of service
(directing traffic to a node that doesn't desire to receive it).</t> (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 <t>In order to mitigate the risk of the diversion of traffic from its
intended destination, BGPsec solutions (<xref target="RFC8205"/> and intended destination, BGPsec solutions (<xref target="RFC8205" format="def
Origin Validation <xref target="RFC8210"/><xref target="RFC6811"/>) may ault"/> and
Origin Validation <xref target="RFC8210" format="default"/><xref target="R
FC6811" format="default"/>) may
be extended in future to work for non-Internet SAFIs (SAFIs other than be extended in future to work for non-Internet SAFIs (SAFIs other than
1).</t> 1).</t>
<t>The restriction of the applicability of the BGP CT SAFI 76 to its <t>The restriction of the applicability of the BGP CT SAFI 76 to its
intended well-defined scope and utilizing <xref target="RFC8212"/> limits intended well-defined scope and utilizing <xref target="RFC8212" format="d efault"/> limits
the likelihood of traffic diversions.</t> the likelihood of traffic diversions.</t>
</section> </section>
</middle> </middle>
<back> <back>
<references title="Normative References"> <displayreference target="I-D.ietf-idr-bgp-ct-srv6" to="BGP-CT-SRv6"/>
<?rfc include="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference. <displayreference target="I-D.ietf-idr-bgp-fwd-rr" to="BGP-FWD-RR"/>
RFC.8277.xml"?> <displayreference target="I-D.ietf-idr-multinexthop-attribute" to="MNH"/>
<displayreference target="I-D.ietf-idr-flowspec-redirect-ip" to="FLOWSPEC-RE
<?rfc include="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference. DIR-IP"/>
RFC.7606.xml"?> <displayreference target="I-D.kaliraj-bess-bgp-mpls-namespaces" to="MPLS-NS"
/>
<?rfc include="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference. <displayreference target="I-D.hr-spring-intentaware-routing-using-color" to=
RFC.2119.xml"?> "Intent-Routing-Color"/>
<displayreference target="I-D.ietf-pce-pcep-color" to="PCEP-RSVP-COLOR"/>
<?rfc include="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference. <displayreference target="I-D.ietf-pce-segment-routing-policy-cp" to="PCEP-S
RFC.2545.xml"?> RPOLICY"/>
<displayreference target="I-D.gredler-idr-bgplu-epe" to="BGP-LU-EPE"/>
<?rfc include="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference. <displayreference target="I-D.ietf-intarea-tunnels" to="INTAREA-TUNNELS"/>
RFC.2474.xml"?> <references>
<name>References</name>
<?rfc include="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference. <references>
RFC.4659.xml"?> <name>Normative References</name>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
<?rfc include="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference. 277.xml"/>
RFC.4271.xml"?> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
606.xml"/>
<?rfc include="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference. <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2
RFC.4272.xml"?> 119.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2
<?rfc include="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference. 545.xml"/>
RFC.5082.xml"?> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2
474.xml"/>
<?rfc include="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference. <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4
RFC.5925.xml"?> 659.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4
<?rfc include="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference. 271.xml"/>
RFC.6811.xml"?> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4
272.xml"/>
<?rfc include="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference. <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5
RFC.4364.xml"?> 082.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5
<?rfc include="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference. 925.xml"/>
RFC.4360.xml"?> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6
811.xml"/>
<?rfc include="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference. <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4
RFC.4684.xml"?> 364.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4
<?rfc include="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference. 360.xml"/>
RFC.4760.xml"?> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4
684.xml"/>
<?rfc include="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference. <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4
RFC.7911.xml"?> 760.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
<?rfc include="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference. 911.xml"/>
RFC.8669.xml"?> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
669.xml"/>
<?rfc include="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference. <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
RFC.9012.xml"?> 012.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
<?rfc include="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference. 252.xml"/>
RFC.9252.xml"?> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
174.xml"/>
<?rfc include="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference. <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
RFC.8174.xml"?> 153.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
<?rfc include="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference. 029.xml"/>
RFC.7153.xml"?> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
212.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"?>
<reference anchor="SRTE"
target="https://datatracker.ietf.org/doc/html/draft-ietf-idr-sr
-policy-safi-10">
<front>
<title>Advertising Segment Routing Policies in BGP</title>
<author fullname="Ketan" initials="" role="editor"
surname="Talaulikar"/>
<author fullname="Previdi" initials="S" surname="Previdi"/>
<date day="07" month="11" year="2024"/>
</front>
</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"?>
<reference anchor="BGP-CT-SRv6"
target="https://tools.ietf.org/html/draft-ietf-idr-bgp-ct-srv6-
05">
<front>
<title abbrev="BGP-CT-SRv6">BGP CT - Adaptation to SRv6
dataplane</title>
<author fullname="Kaliraj Vairavakkalai" initials="" role="editor"
surname="Vairavakkalai"/>
<author fullname="Natarajan Venkataraman" initials="" role="editor"
surname="Venkataraman"/>
<date day="25" month="4" year="2024"/>
</front>
</reference>
<reference anchor="BGP-FWD-RR"
target="https://tools.ietf.org/html/draft-ietf-idr-bgp-fwd-rr-0
2">
<front>
<title abbrev="BGP-FWD-RR">BGP Route Reflector in Forwarding
Path</title>
<author fullname="Kaliraj Vairavakkalai" initials="" role="editor"
surname="Vairavakkalai"/>
<author fullname="Natarajan Venkataraman" initials="" role="editor"
surname="Venkataraman"/>
<date day="17" month="3" year="2024"/>
</front>
</reference>
<reference anchor="MNH"
target="https://datatracker.ietf.org/doc/html/draft-ietf-idr-mu
ltinexthop-attribute-00">
<front>
<title abbrev="MNH">BGP MultiNexthop Attribute</title>
<author 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-fl
owspec-redirect-ip-03">
<front>
<title abbrev="FLOWSPEC-REDIR-IP">BGP Flow-Spec Redirect to IP
Action</title>
<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-bes
s-bgp-sig-private-mpls-labels-09">
<front>
<title abbrev="MPLS namespaces">BGP signalled MPLS
namespaces</title>
<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-i
ntentaware-routing-using-color-03">
<front>
<title abbrev="Intent-Routing-Color">Intent-aware Routing using
Color</title>
<author fullname="Shraddha" initials="" role="editor"
surname="Hegde"/>
<date day="23" month="10" year="2023"/>
</front>
</reference>
<reference anchor="PCEP-RSVP-COLOR"
target="https://datatracker.ietf.org/doc/html/draft-ietf-pce-pc
ep-color-11">
<front>
<title abbrev="PCEP RSVP COLOR">Path Computation Element
Protocol(PCEP) Extension for RSVP Color</title>
<author fullname="Balaji" initials="" role="editor" <!--
surname="Rajagopalan"/> draft-ietf-idr-sr-policy-safi-13
companion document RFC 9830, in EDIT as of 04/11/25.
Original cite tag [SRTE].
-->
<reference anchor="RFC9830" target="https://www.rfc-editor.org/info/rfc9830">
<front>
<title>Advertising Segment Routing Policies in BGP</title>
<author 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" rol
e="editor">
<organization>Cisco Systems</organization>
</author>
<author initials="P." surname="Mattes" fullname="Paul Mattes">
<organization>Microsoft</organization>
</author>
<author initials="D." surname="Jain" fullname="Dhanendra Jain">
<organization>Google</organization>
</author>
<date month="September" year='2025'/>
</front>
<seriesInfo name="RFC" value="9830"/>
<seriesInfo name="DOI" value="10.17487/RFC9830"/>
</reference>
<author fullname="Vishnu" initials="Pavan" role="editor" </references>
surname="Beeram"/> <references>
<name>Informative References</name>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
350.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
315.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6
890.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
256.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
205.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
210.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
543.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml9/reference.BCP.2
6.xml"/>
<date day="17" month="02" year="2025"/> <reference anchor="I-D.ietf-idr-bgp-ct-srv6" target="https://datatracker.ietf.or
</front> g/doc/html/draft-ietf-idr-bgp-ct-srv6-07">
</reference> <front>
<title>BGP CT - Adaptation to SRv6 dataplane</title>
<author initials="K." surname="Vairavakkalai" fullname="Kaliraj Vairavakka
lai" role="editor">
<organization>Juniper Networks, Inc.</organization>
</author>
<author initials="N." surname="Venkataraman" fullname="Natrajan Venkataram
an" role="editor">
<organization>Juniper Networks, Inc.</organization>
</author>
<date month="August" day="22" year="2025" />
</front>
<seriesInfo name="Internet-Draft" value="draft-ietf-idr-bgp-ct-srv6-07" />
<reference anchor="PCEP-SRPOLICY" </reference>
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>
<author fullname="Mike" initials="" role="editor" <reference anchor="I-D.ietf-idr-bgp-fwd-rr" target="https://datatracker.ietf.org
surname="Koldychev"/> /doc/html/draft-ietf-idr-bgp-fwd-rr-04">
<front>
<title>BGP Route Reflector with Next Hop Self</title>
<author initials="K." surname="Vairavakkalai" fullname="Kaliraj Vairavakka
lai" role="editor">
<organization>Juniper Networks, Inc.</organization>
</author>
<author initials="N." surname="Venkataraman" fullname="Natrajan Venkataram
an" role="editor">
<organization>Juniper Networks, Inc.</organization>
</author>
<date month="August" day="22" year="2025" />
</front>
<seriesInfo name="Internet-Draft" value="draft-ietf-idr-bgp-fwd-rr-04" />
<author fullname="Siva" initials="" role="editor" </reference>
surname="Sivabalan"/>
<author fullname="Colby" initials="" role="editor" surname="Barth"/> <reference anchor="I-D.ietf-idr-multinexthop-attribute" target="https://datatrac
ker.ietf.org/doc/html/draft-ietf-idr-multinexthop-attribute-04">
<front>
<title>BGP MultiNexthop Attribute</title>
<author initials="K." surname="Vairavakkalai" fullname="Kaliraj Vairavakka
lai" role="editor">
<organization>Juniper Networks, Inc.</organization>
</author>
<author initials="J. M." surname="Jeganathan" fullname="Jeyananth Minto Je
ganathan">
<organization>Juniper Networks, Inc.</organization>
</author>
<author initials="M." surname="Nanduri" fullname="Mohan Nanduri">
<organization>Microsoft</organization>
</author>
<author initials="A. R." surname="Lingala" fullname="Avinash Reddy Lingala
">
<organization>AT&amp;T</organization>
</author>
<date month="March" day="25" year="2025" />
</front>
<seriesInfo name="Internet-Draft" value="draft-ietf-idr-multinexthop-attribut
e-04" />
<date day="09" month="02" year="2024"/> </reference>
</front>
</reference>
<reference anchor="BGP-CT-UPDATE-PACKING-TEST" <xi:include href="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.i
target="https://raw.githubusercontent.com/ietf-wg-idr/draft-iet etf-idr-flowspec-redirect-ip.xml"/>
f-idr-bgp-ct/1a75d4d10d4df0f1fd7dcc041c2c868704b092c7/update-packing-test-result
s.txt">
<front>
<title abbrev="BGP-CT-UPDATE-PACKING-TEST">BGP CT Update packing
Test Results</title>
<author fullname="Kaliraj" initials="" role="editor" <reference anchor="I-D.kaliraj-bess-bgp-mpls-namespaces" target="https://datatra
surname="Vairavakkalai"/> cker.ietf.org/doc/html/draft-kaliraj-bess-bgp-mpls-namespaces-01">
<front>
<title>BGP Signaled MPLS Namespaces</title>
<author initials="K." surname="Vairavakkalai" fullname="Kaliraj Vairavakka
lai" role="editor">
<organization>Juniper Networks, Inc.</organization>
</author>
<author initials="J. M." surname="Jeganathan" fullname="Jeyananth Minto Je
ganathan">
<organization>Juniper Networks, Inc.</organization>
</author>
<author initials="P." surname="Ramadenu" fullname="Praveen Ramadenu">
<organization>AT&amp;T</organization>
</author>
<author initials="I." surname="Means" fullname="Israel Means">
<organization>AT&amp;T</organization>
</author>
<date month="Aug" day="21" year="2025" />
</front>
<seriesInfo name="Internet-Draft" value="draft-kaliraj-bess-bgp-mpls-namespac
es-01" />
</reference>
<date day="25" month="06" year="2023"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.h
</front> r-spring-intentaware-routing-using-color.xml"/>
</reference>
<reference anchor="BGP-LU-EPE" <xi:include href="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.i
target="https://datatracker.ietf.org/doc/html/draft-gredler-idr etf-pce-pcep-color.xml"/>
-bgplu-epe-15">
<front>
<title abbrev="BGP LU EPE">Egress Peer Engineering using
BGP-LU</title>
<author fullname="Hannes" initials="" role="editor" <xi:include href="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.i
surname="Gredler"/> etf-pce-segment-routing-policy-cp.xml"/>
<date day="16" month="06" year="2023"/> <reference anchor="PACKING-TEST" target="https://github.com/ietf-wg-idr/
</front> draft-ietf-idr-bgp-ct/blob/main/update-packing-test-results.txt">
</reference> <front>
<title>update-packing-test-results.txt</title>
<author/>
<date day="25" month="06" year="2023"/>
</front>
<refcontent>1a75d4d</refcontent>
</reference>
<reference anchor="INTAREA-TUNNELS" <reference anchor="I-D.gredler-idr-bgplu-epe" target="https://datatracker.ietf.o
target="https://datatracker.ietf.org/doc/draft-ietf-intarea-tun rg/doc/html/draft-gredler-idr-bgplu-epe-16">
nels/13/"> <front>
<front> <title>Egress Peer Engineering using BGP-LU</title>
<title abbrev="INTAREA-TUNNELS">IP Tunnels in the Internet <author initials="H." surname="Gredler" fullname="Hannes Gredler" role="ed
Architecture</title> itor">
<organization>RtBrick Inc.</organization>
</author>
<author initials="K." surname="Vairavakkalai" fullname="Kaliraj Vairavakka
lai" role="editor">
<organization>Juniper Networks, Inc.</organization>
</author>
<author 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 month="October" day="14" year="2024" />
</front>
<seriesInfo name="Internet-Draft" value="draft-gredler-idr-bgplu-epe-16" />
<author fullname="Dr. Joseph D Touch" initials="" role="editor" </reference>
surname="Touch"/>
<author fullname="Mark Townsley" initials="" role="editor" <xi:include href="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.i
surname="Townsley"/> etf-intarea-tunnels.xml"/>
<date day="26" month="03" year="2023"/> </references>
</front>
</reference>
</references> </references>
<section anchor="Appendix_A" numbered="true" toc="default">
<section anchor="Appendix A" numbered="true" <name>Extensibility Considerations</name>
title="Extensibility considerations"> <section numbered="true" toc="default">
<section title="Signaling Intent over PE-CE Attachment Circuit"> <name>Signaling Intent over a PE-CE Attachment Circuit</name>
<t>It may be desirable to allow a CE device to indicate in the data <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 packet it sends what treatment it desires (the Intent) when the packet
is forwarded within the provider network.</t> is forwarded within the provider network.</t>
<t><xref section="A.10" target="I-D.ietf-idr-multinexthop-attribute" for
<t>Section A.10 in <xref target="MNH">BGP MultiNexthop mat="default"></xref> describes some mechanisms that enable such
Attribute</xref> describes some mechanisms that enable such
signaling.</t> signaling.</t>
</section> </section>
<section numbered="true" toc="default">
<section title="BGP CT Egress TE"> <name>BGP CT Egress TE</name>
<t>Mechanisms described in <xref target="BGP-LU-EPE"/> also applies to <t>Mechanisms described in <xref target="I-D.gredler-idr-bgplu-epe" form
at="default"/> also apply to the
BGP CT family.</t> BGP CT family.</t>
<t>The Peer/32 or Peer/128 EPE route <bcp14>MAY</bcp14> be originated in
<t>The Peer/32 or Peer/128 EPE route MAY be originated in BGP CT the BGP CT
family with appropriate Mapping Community (e.g. family with the appropriate Mapping Community (e.g.,
transport-target:0:100), thus allowing an EPE path to the peer that transport-target:0:100), thus allowing an EPE path to the peer that
satisfies the desired SLA.</t> satisfies the desired SLA.</t>
</section> </section>
</section> </section>
<section anchor="Appendix_B" numbered="true" toc="default">
<section anchor="Appendix B" numbered="true" <name>Applicability to Intra-AS and Different Inter-AS Deployments</name>
title="Applicability to Intra-AS and different Inter-AS deployments <t>As described in <xref section="10" target="RFC4364" format="default"></
."> xref>, in an option C network, service routes (VPN-IPv4) are
<t>As described in <xref target="RFC4364">BGP VPN</xref> Section 10, in neither maintained nor distributed by the ASBRs. Transport routes are
an Option C network, service routes (VPN-IPv4) are neither maintained maintained in the ASBRs and propagated in BGP LU or BGP CT.</t>
nor distributed by the ASBRs. Transport routes are maintained in the <t><xref target="CTProc" format="default"></xref>
ASBRs and propagated in BGP LU or BGP CT.</t> illustrates how constructs of BGP CT work in an inter-AS option C
deployment. The BGP CT constructs: AFI/SAFI 1/76, Transport Class, and
<t><xref target="CTProc">Illustration of CT Procedures</xref> Resolution Scheme are used in an inter-AS option C deployment.</t>
illustrates how constructs of BGP CT work in an inter-AS Option C <t>In intra-AS and inter-AS option A and option B scenarios, AFI/SAFI 1/76
deployment. The BGP CT constructs: AFI/SAFI 1/76, Transport Class and
Resolution Scheme are used in an inter-AS Option C deployment.</t>
<t>In Intra-AS and Inter-AS option A, option B scenarios, AFI/SAFI 1/76
may not be used, but the Transport Class and Resolution Scheme may not be used, but the Transport Class and Resolution Scheme
mechanisms are used to provide service mapping.</t> mechanisms are used to provide service mapping.</t>
<t>This section illustrates how BGP CT constructs work in intra-AS and
<t>This section illustrates how BGP CT constructs work in Intra-AS and inter-AS option A and option B deployment scenarios.</t>
Inter-AS Option A, B deployment scenarios.</t> <section numbered="true" toc="default">
<name>Intra-AS Use Case</name>
<section title="Intra-AS usecase"> <section numbered="true" toc="default">
<section title="Topology"> <name>Topology</name>
<figure title="BGP CT Intra-AS" anchor="BGPCT_INTRA_AS"><artset><artwork type=" <figure anchor="BGPCT_INTRA_AS">
svg"><svg xmlns="http://www.w3.org/2000/svg" version="1.1" height="208" width="4 <name>BGP CT Intra-AS</name>
40" viewBox="0 0 440 208" class="diagram" text-anchor="middle" font-family="mono <artset>
space" font-size="13px" stroke-linecap="round"> <artwork type="svg" name="" align="left" alt=""><svg xmlns="http:/
<path d="M 200,48 L 200,64" fill="none" stroke="black"/> /www.w3.org/2000/svg" version="1.1" height="208" width="440" viewBox="0 0 440 20
<path d="M 56,80 L 72,80" fill="none" stroke="black"/> 8" class="diagram" text-anchor="middle" font-family="monospace" font-size="13px"
<path d="M 128,80 L 176,80" fill="none" stroke="black"/> stroke-linecap="round">
<path d="M 216,80 L 256,80" fill="none" stroke="black"/> <path d="M 200,48 L 200,64" fill="none" stroke="black"/>
<path d="M 312,80 L 352,80" fill="none" stroke="black"/> <path d="M 56,80 L 72,80" fill="none" stroke="black"/>
<path d="M 112,176 L 136,176" fill="none" stroke="black"/> <path d="M 128,80 L 176,80" fill="none" stroke="black"/>
<path d="M 296,176 L 328,176" fill="none" stroke="black"/> <path d="M 216,80 L 256,80" fill="none" stroke="black"/>
<polygon class="arrowhead" points="336,176 324,170.4 324,181.6" fill="black" tra <path d="M 312,80 L 352,80" fill="none" stroke="black"/>
nsform="rotate(0,328,176)"/> <path d="M 112,176 L 136,176" fill="none" stroke="black"/>
<g class="text"> <path d="M 296,176 L 328,176" fill="none" stroke="black"/>
<text x="204" y="36">[RR11]</text> <polygon class="arrowhead" points="336,176 324,170.4 324,181.6
<text x="28" y="84">[CE21]</text> " fill="black" transform="rotate(0,328,176)"/>
<text x="100" y="84">[PE11]</text> <g class="text">
<text x="196" y="84">[P1]</text> <text x="204" y="36">[RR11]</text>
<text x="284" y="84">[PE12]</text> <text x="28" y="84">[CE21]</text>
<text x="380" y="84">[CE31]</text> <text x="100" y="84">[PE11]</text>
<text x="72" y="116">:</text> <text x="196" y="84">[P1]</text>
<text x="312" y="116">:</text> <text x="284" y="84">[PE12]</text>
<text x="32" y="132">AS2</text> <text x="380" y="84">[CE31]</text>
<text x="72" y="132">:</text> <text x="72" y="116">:</text>
<text x="200" y="132">...AS1...</text> <text x="312" y="116">:</text>
<text x="312" y="132">:</text> <text x="32" y="132">AS2</text>
<text x="368" y="132">AS3</text> <text x="72" y="132">:</text>
<text x="72" y="148">:</text> <text x="200" y="132">...AS1...</text>
<text x="312" y="148">:</text> <text x="312" y="132">:</text>
<text x="52" y="180">203.0.113.21</text> <text x="368" y="132">AS3</text>
<text x="176" y="180">Traffic</text> <text x="72" y="148">:</text>
<text x="248" y="180">Direction</text> <text x="312" y="148">:</text>
<text x="388" y="180">203.0.113.31</text> <text x="52" y="180">203.0.113.21</text>
</g> <text x="176" y="180">Traffic</text>
</svg> <text x="248" y="180">Direction</text>
</artwork><artwork type="ascii-art"><![CDATA[ <text x="388" y="180">203.0.113.31</text>
</g>
</svg>
</artwork>
<artwork type="ascii-art" name="" align="left" alt=""><![CDATA[
[RR11] [RR11]
| |
+ +
[CE21]---[PE11]-------[P1]------[PE12]------[CE31] [CE21]---[PE11]-------[P1]------[PE12]------[CE31]
: : : :
AS2 : ...AS1... : AS3 AS2 : ...AS1... : AS3
: : : :
203.0.113.21 ---- Traffic Direction ----> 203.0.113.31 203.0.113.21 ---- Traffic Direction ----> 203.0.113.31
]]></artwork></artset></figure> ]]></artwork>
</artset>
<t>This example in <xref target="BGPCT_INTRA_AS"/> shows a provider </figure>
network Autonomous system AS1. It serves customers AS2, AS3. Traffic <t><xref target="BGPCT_INTRA_AS" format="default"/> shows a provider
network Autonomous System, AS1. It serves customers AS2 and AS3. Traff
ic
direction being described is CE21 to CE31. CE31 may request a direction being described is CE21 to CE31. CE31 may request a
specific SLA (e.g. Gold for this traffic), when traversing this specific SLA (e.g., Gold for this traffic) when traversing this
provider network.</t> provider network.</t>
</section> </section>
<section numbered="true" toc="default">
<section title="Transport Layer"> <name>Transport Layer</name>
<t>AS1 uses RSVP-TE intra-domain tunnels between PE11 and PE12. And <t>AS1 uses RSVP-TE intra-domain tunnels between PE11 and PE12. And it
LDP tunnels for best effort traffic.</t> uses
LDP tunnels for best-effort traffic.</t>
<t>The network has two Transport classes: Gold with Transport Class <t>The network has two TCs: Gold with TC ID 100 and Bronze
ID 100, Bronze with Transport Class ID 200. These transport classes with TC ID 200. These TCs
are provisioned at the PEs. This creates the Resolution Schemes for are provisioned at the PEs. This creates the Resolution Schemes for
these transport classes at these PEs.</t> these TCs at these PEs.</t>
<t>The following tunnels exist for the Gold TC:</t>
<t>Following tunnels exist for Gold transport class.<list> <ul spacing="normal">
<li>
<t>PE11_to_PE12_gold - RSVP-TE tunnel</t> <t>PE11_to_PE12_gold - RSVP-TE tunnel</t>
</li>
<li>
<t>PE12_to_PE11_gold - RSVP-TE tunnel</t> <t>PE12_to_PE11_gold - RSVP-TE tunnel</t>
</list></t> </li>
</ul>
<t>Following tunnels exist for Bronze transport class.<list> <t>The following tunnels exist for Bronze TC:</t>
<ul spacing="normal">
<li>
<t>PE11_to_PE12_bronze - RSVP-TE tunnel</t> <t>PE11_to_PE12_bronze - RSVP-TE tunnel</t>
</li>
<li>
<t>PE11_to_PE12_bronze - RSVP-TE tunnel</t> <t>PE11_to_PE12_bronze - RSVP-TE tunnel</t>
</list></t> </li>
</ul>
<t>These tunnels are provisioned to belong to transport class 100 or <t>These tunnels are provisioned to belong to Transport Class 100 or
200.</t> 200.</t>
</section> </section>
<section numbered="true" toc="default">
<section title="Service Layer route exchange"> <name>Service Layer Route Exchange</name>
<t>Service nodes PE11, PE12 negotiate service families (AFI/SAFI <t>Service nodes PE11 and PE12 negotiate service families (AFI/SAFI
1/128) on the BGP session with RR11. Service helper RR11 reflects 1/128) on the BGP session with RR11. Service helper RR11 reflects
service routes between the two PEs with next hop unchanged. There service routes between the two PEs with the next hop unchanged. There
are no tunnels for transport-class 100 or 200 from RR11 to the are no tunnels for Transport Class 100 or 200 from RR11 to the
PEs.</t> PEs.</t>
<t>Forwarding happens using service routes at service nodes PE11 and
<t>Forwarding happens using service routes at service nodes PE11,
PE12. Routes received from CEs are not present in any other nodes' PE12. Routes received from CEs are not present in any other nodes'
FIB in the provider network.</t> FIB in the provider network.</t>
<t>CE31 advertises a route, for example, prefix 203.0.113.31 with the
<t>CE31 advertises a route for example prefix 203.0.113.31 with next next
hop self to PE12. CE31 can attach a Mapping Community Color:0:100 on hop set to itself to PE12. CE31 can attach a Mapping Community color:0
this route, to indicate its request for Gold SLA. Or, PE12 can :100 on
this route to indicate its request for a Gold SLA. Or, PE12 can
attach the same using locally configured policies.</t> attach the same using locally configured policies.</t>
<t>Consider CE31 getting VPN service from PE12. The
<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 RD:203.0.113.31 route is readvertised in AFI/SAFI 1/128 by PE12 with
next hop self (192.0.2.12) and label V-L1, to RR11 with the Mapping the next hop set to itself (192.0.2.12) and label V-L1 to RR11 with th
Community Color:0:100 attached. This AFI/SAFI 1/128 route reaches e Mapping
Community 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. 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 PE11_to_PE12_gold RSVP Now PE11 can resolve the PNH 192.0.2.12 using the PE11_to_PE12_gold RS VP
TE LSP.</t> TE LSP.</t>
<t>The IP FIB at PE11 VRF will have a route for 203.0.113.31 with a <t>The IP FIB at PE11 VRF will have a route for 203.0.113.31 with a
next hop when resolved using Resolution Scheme belonging to the next hop when resolved using the Resolution Scheme belonging to the
mapping community Color:0:100, points to a PE11_to_PE12_gold Mapping Community color:0:100, points to a PE11_to_PE12_gold
tunnel.</t> tunnel.</t>
<t>BGP CT AFI/SAFI 1/76 is not used in this intra-AS deployment. But
<t>BGP CT AFI/SAFI 1/76 is not used in this Intra-AS deployment. But the Transport Class and Resolution Scheme constructs are used to
the Transport class and Resolution Scheme constructs are used to
preserve end-to-end SLA.</t> preserve end-to-end SLA.</t>
</section> </section>
</section> </section>
<section numbered="true" toc="default">
<section title="Inter-AS option A usecase"> <name>Inter-AS Option A Use Case</name>
<section title="Topology"> <section numbered="true" toc="default">
<figure title="BGP CT Inter-AS option A" anchor="BGPCT_INTERAS_A"><artset><artwo <name>Topology</name>
rk type="svg"><svg xmlns="http://www.w3.org/2000/svg" version="1.1" height="192 <figure title="BGP CT Inter-AS option A" anchor="BGPCT_INTERAS_A">
" width="624" viewBox="0 0 624 192" class="diagram" text-anchor="middle" font-fa <artset>
mily="monospace" font-size="13px" stroke-linecap="round"> <artwork type="svg">
<path d="M 168,48 L 168,64" fill="none" stroke="black"/> <svg xmlns="http://www.w3.org/2000/svg" version="1.1" height="192"
<path d="M 408,48 L 408,64" fill="none" stroke="black"/> width="560"
<path d="M 56,80 L 72,80" fill="none" stroke="black"/> viewBox="0 0 560 192" class="diagram" text-anchor="middle" font-
<path d="M 128,80 L 152,80" fill="none" stroke="black"/> family="monospace"
<path d="M 192,80 L 216,80" fill="none" stroke="black"/> font-size="13px" stroke-linecap="round">
<path d="M 288,80 L 304,80" fill="none" stroke="black"/> <path d="M 168,48 L 168,64" fill="none" stroke="black" />
<path d="M 376,80 L 392,80" fill="none" stroke="black"/> <path d="M 408,48 L 408,64" fill="none" stroke="black" />
<path d="M 432,80 L 448,80" fill="none" stroke="black"/> <path d="M 56,80 L 72,80" fill="none" stroke="black" />
<path d="M 504,80 L 528,80" fill="none" stroke="black"/> <path d="M 128,80 L 144,80" fill="none" stroke="black" />
<path d="M 184,176 L 232,176" fill="none" stroke="black"/> <path d="M 184,80 L 200,80" fill="none" stroke="black" />
<path d="M 376,176 L 424,176" fill="none" stroke="black"/> <path d="M 272,80 L 288,80" fill="none" stroke="black" />
<polygon class="arrowhead" points="432,176 420,170.4 420,181.6" fill="black" tra <path d="M 360,80 L 376,80" fill="none" stroke="black" />
nsform="rotate(0,424,176)"/> <path d="M 416,80 L 432,80" fill="none" stroke="black" />
<g class="text"> <path d="M 488,80 L 504,80" fill="none" stroke="black" />
<text x="172" y="36">[RR11]</text> <path d="M 184,176 L 232,176" fill="none" stroke="black" />
<text x="412" y="36">[RR21]</text> <path d="M 376,176 L 424,176" fill="none" stroke="black" />
<text x="28" y="84">[CE31]</text> <polygon class="arrowhead" points="432,176 420,170.4 420,181.6"
<text x="100" y="84">[PE11]</text> fill="black"
<text x="172" y="84">[P1]</text> transform="rotate(0,424,176)" />
<text x="252" y="84">[ASBR11]</text> <g class="text">
<text x="340" y="84">[ASBR21]</text> <text x="172" y="36">[RR11]</text>
<text x="412" y="84">[P2]</text> <text x="412" y="36">[RR21]</text>
<text x="476" y="84">[PE21]</text> <text x="28" y="84">[CE31]</text>
<text x="556" y="84">[CE41]</text> <text x="100" y="84">[PE11]</text>
<text x="72" y="116">:</text> <text x="164" y="84">[P1]</text>
<text x="296" y="116">:</text> <text x="236" y="84">[ASBR11]</text>
<text x="512" y="116">:</text> <text x="324" y="84">[ASBR21]</text>
<text x="32" y="132">AS3</text> <text x="396" y="84">[P2]</text>
<text x="72" y="132">:</text> <text x="460" y="84">[PE21]</text>
<text x="200" y="132">..AS1..</text> <text x="532" y="84">[CE41]</text>
<text x="296" y="132">:</text> <text x="72" y="116">:</text>
<text x="376" y="132">..AS2..</text> <text x="280" y="116">:</text>
<text x="512" y="132">:</text> <text x="488" y="116">:</text>
<text x="560" y="132">AS4</text> <text x="32" y="132">AS3</text>
<text x="72" y="148">:</text> <text x="72" y="132">:</text>
<text x="296" y="148">:</text> <text x="184" y="132">..AS1..</text>
<text x="512" y="148">:</text> <text x="280" y="132">:</text>
<text x="52" y="180">203.0.113.31</text> <text x="360" y="132">..AS2..</text>
<text x="264" y="180">Traffic</text> <text x="488" y="132">:</text>
<text x="336" y="180">Direction</text> <text x="536" y="132">AS4</text>
<text x="572" y="180">203.0.113.41</text> <text x="72" y="148">:</text>
</g> <text x="280" y="148">:</text>
</svg> <text x="488" y="148">:</text>
</artwork><artwork type="ascii-art"><![CDATA[ <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="508" y="180">203.0.113.41</text>
</g>
</svg>
</artwork>
<artwork type="ascii-art"><![CDATA[
[RR11] [RR21] [RR11] [RR21]
| | | |
+ + + +
[CE31]---[PE11]----[P1]----[ASBR11]---[ASBR21]---[P2]---[PE21]----[CE41] [CE31]---[PE11]---[P1]---[ASBR11]---[ASBR21]---[P2]---[PE21]---[CE41]
: : : : : :
AS3 : ..AS1.. : ..AS2.. : AS4 AS3 : ..AS1.. : ..AS2.. : AS4
: : : : : :
203.0.113.31 -------Traffic Direction------> 203.0.113.41 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"/> shows two <t>This example in <xref target="BGPCT_INTERAS_A" format="default"/> s hows two
provider network Autonomous systems AS1, AS2. They serve L3VPN provider network Autonomous systems AS1, AS2. They serve L3VPN
customers AS3, AS4 respectively. The ASBRs ASBR11 and ASBR21 have IP customers AS3, AS4 respectively. The ASBRs ASBR11 and ASBR21 have IP
VRFs connected directly. The inter-AS link is IP enabled with no VRFs connected directly. The inter-AS link is IP enabled with no
MPLS forwarding.</t> MPLS forwarding.</t>
<t>Traffic direction being described is CE31 to CE41. CE41 may <t>Traffic direction being described is CE31 to CE41. CE41 may
request a specific SLA (e.g. Gold for this traffic), when traversing request a specific SLA (e.g., Gold for this traffic), when traversing
these provider core networks.</t> these provider core networks.</t>
</section> </section>
<section numbered="true" toc="default">
<section title="Transport Layer"> <name>Transport Layer</name>
<t>AS1 uses RSVP-TE intra-domain tunnels between PE11 and ASBR11. <t>AS1 uses RSVP-TE intra-domain tunnels between PE11 and ASBR11.
And LDP tunnels for best effort traffic. AS2 uses SRTE intra-domain And LDP tunnels for best-effort traffic. AS2 uses SRTE intra-domain
tunnels between ASBR21 and PE21, and L-ISIS for best effort tunnels between ASBR21 and PE21, and L-ISIS for best-effort
tunnels.</t> tunnels.</t>
<t>The networks have two TCs: Gold with TC ID 100,
<t>The networks have two Transport classes: Gold with Transport Bronze with TC ID 200. These TCs
Class ID 100, Bronze with Transport Class ID 200. These transport are provisioned at the PEs and ASBRs. This creates the
classes are provisioned at the PEs and ASBRs. This creates the Resolution Schemes for these TCs at these PEs and
Resolution Schemes for these transport classes at these PEs and
ASBRs.</t> ASBRs.</t>
<t>Following tunnels exist for Gold TC.</t>
<t>Following tunnels exist for Gold transport class.<list> <ul spacing="normal">
<li>
<t>PE11_to_ASBR11_gold - RSVP-TE tunnel</t> <t>PE11_to_ASBR11_gold - RSVP-TE tunnel</t>
</li>
<li>
<t>ASBR11_to_PE11_gold - RSVP-TE tunnel</t> <t>ASBR11_to_PE11_gold - RSVP-TE tunnel</t>
</li>
<li>
<t>PE21_to_ASBR21_gold - SRTE tunnel</t> <t>PE21_to_ASBR21_gold - SRTE tunnel</t>
</li>
<li>
<t>ASBR21_to_PE21_gold - SRTE tunnel</t> <t>ASBR21_to_PE21_gold - SRTE tunnel</t>
</list></t> </li>
</ul>
<t>Following tunnels exist for Bronze transport class.<list> <t>Following tunnels exist for Bronze TC.</t>
<ul spacing="normal">
<li>
<t>PE11_to_ASBR11_bronze - RSVP-TE tunnel</t> <t>PE11_to_ASBR11_bronze - RSVP-TE tunnel</t>
</li>
<li>
<t>ASBR11_to_PE11_bronze - RSVP-TE tunnel</t> <t>ASBR11_to_PE11_bronze - RSVP-TE tunnel</t>
</li>
<li>
<t>PE21_to_ASBR21_bronze - SRTE tunnel</t> <t>PE21_to_ASBR21_bronze - SRTE tunnel</t>
</li>
<li>
<t>ASBR21_to_PE21_bronze - SRTE tunnel</t> <t>ASBR21_to_PE21_bronze - SRTE tunnel</t>
</list></t> </li>
</ul>
<t>These tunnels are provisioned to belong to transport class 100 or <t>These tunnels are provisioned to belong to TC 100 or
200.</t> 200.</t>
</section> </section>
<section numbered="true" toc="default">
<section title="Service Layer route exchange"> <name>Service Layer Route Exchange</name>
<t>Service nodes PE11, ASBR11 negotiate service family (AFI/SAFI <t>Service nodes PE11, ASBR11 negotiate service family (AFI/SAFI
1/128) on the BGP session with RR11. Service helper RR11 reflects 1/128) on the BGP session with RR11. Service helper RR11 reflects
service routes between the PE11 and ASBR11 with next hop service routes between the PE11 and ASBR11 with next hop
unchanged.</t> unchanged.</t>
<t>Similarly, in AS2 PE21, ASBR21 negotiate service family (AFI/SAFI <t>Similarly, in AS2 PE21, ASBR21 negotiate service family (AFI/SAFI
1/128) on the BGP session with RR21, which reflects service routes 1/128) on the BGP session with RR21, which reflects service routes
between the PE21 and ASBR21 with next hop unchanged.</t> between the PE21 and ASBR21 with next hop unchanged.</t>
<t>CE41 advertises a route for example prefix 203.0.113.41 with next <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 hop self to PE21 VRF. CE41 can attach a Mapping Community
Color:0:100 on this route, to indicate its request for Gold SLA. Or, color:0:100 on this route, to indicate its request for Gold SLA. Or,
PE21 can attach the same using locally configured policies.</t> PE21 can attach the same using locally configured policies.</t>
<t>Consider, CE41 is getting VPN service from PE21. The <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 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 next hop self (203.0.113.21) and label V-L1 to RR21 with the Mapping
Community Color:0:100 attached. This AFI/SAFI 1/128 route reaches Community 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. 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 Now ASBR21 can resolve the PNH 203.0.113.21 using
ASBR21_to_PE21_gold SRTE LSP.</t> ASBR21_to_PE21_gold SRTE LSP.</t>
<t>The IP FIB at ASBR21 VRF will have a route for 203.0.113.41 with <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 a next hop resolved using Resolution Scheme associated with mapping
community Color:0:100, pointing to ASBR21_to_PE21_gold tunnel.</t> community color:0:100, pointing to ASBR21_to_PE21_gold tunnel.</t>
<t>This route is readvertised with the next hop set to itself by ASBR2
<t>This route is readvertised with next hop self by ASBR21 to ASBR11 1 to ASBR11
on BGP session in the VRF. The single-hop EBGP session endpoints are 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. interface addresses. ASBR21 and ASBR11 act like a CE to each other.
The previously mentioned process repeats in AS1, until the route The previously mentioned process repeats in AS1 until the route
reaches PE11 and resolves over PE11_to_ASBR11_gold RSVP TE reaches PE11 and resolves over the PE11_to_ASBR11_gold RSVP TE
tunnel.</t> tunnel.</t>
<t>Traffic traverses as an unlabeled IP packet on the following legs:
<t>Traffic traverses as unlabeled IP packet on the following legs: CE31-PE11, ASBR11-ASBR21, PE21-CE41. And it uses MPLS forwarding insid
CE31-PE11, ASBR11-ASBR21, PE21-CE41. And uses MPLS forwarding inside e the
AS1, AS2 core.</t> AS1 and AS2 core.</t>
<t>BGP CT AFI/SAFI 1/76 is not used in this inter-AS option B
<t>BGP CT AFI/SAFI 1/76 is not used in this Inter-AS Option B deployment. But the Transport Class and Resolution Scheme constructs
deployment. But the Transport class and Resolution Scheme constructs are used to preserve an end-to-end SLA.</t>
are used to preserve end-to-end SLA.</t>
</section> </section>
</section> </section>
<section numbered="true" toc="default">
<section title="Inter-AS option B usecase"> <name>Inter-AS Option B Use Case</name>
<section title="Topology"> <section numbered="true" toc="default">
<figure title="BGP CT Inter-AS option B" anchor="BGPCT_INTERAS_B"><artset><artwo <name>Topology</name>
rk type="svg"><svg xmlns="http://www.w3.org/2000/svg" version="1.1" height="192 <figure title="BGP CT Inter-AS option B" anchor="BGPCT_INTERAS
" width="584" viewBox="0 0 584 192" class="diagram" text-anchor="middle" font-fa _B">
mily="monospace" font-size="13px" stroke-linecap="round"> <artset>
<path d="M 168,48 L 168,64" fill="none" stroke="black"/> <artwork type="svg">
<path d="M 408,48 L 408,64" fill="none" stroke="black"/> <svg xmlns="http://www.w3.org/2000/svg" version="1.1" height="192"
<path d="M 56,80 L 72,80" fill="none" stroke="black"/> width="560"
<path d="M 128,80 L 152,80" fill="none" stroke="black"/> viewBox="0 0 560 192" class="diagram" text-anchor="middle" font-
<path d="M 192,80 L 216,80" fill="none" stroke="black"/> family="monospace"
<path d="M 288,80 L 304,80" fill="none" stroke="black"/> font-size="13px" stroke-linecap="round">
<path d="M 376,80 L 392,80" fill="none" stroke="black"/> <path d="M 168,48 L 168,64" fill="none" stroke="black" />
<path d="M 432,80 L 448,80" fill="none" stroke="black"/> <path d="M 408,48 L 408,64" fill="none" stroke="black" />
<path d="M 504,80 L 528,80" fill="none" stroke="black"/> <path d="M 56,80 L 72,80" fill="none" stroke="black" />
<path d="M 184,176 L 208,176" fill="none" stroke="black"/> <path d="M 128,80 L 144,80" fill="none" stroke="black" />
<path d="M 368,176 L 400,176" fill="none" stroke="black"/> <path d="M 184,80 L 200,80" fill="none" stroke="black" />
<polygon class="arrowhead" points="408,176 396,170.4 396,181.6" fill="black" tra <path d="M 272,80 L 288,80" fill="none" stroke="black" />
nsform="rotate(0,400,176)"/> <path d="M 360,80 L 376,80" fill="none" stroke="black" />
<g class="text"> <path d="M 416,80 L 432,80" fill="none" stroke="black" />
<text x="172" y="36">[RR13]</text> <path d="M 488,80 L 504,80" fill="none" stroke="black" />
<text x="412" y="36">[RR23]</text> <path d="M 184,176 L 208,176" fill="none" stroke="black" />
<text x="28" y="84">[CE31]</text> <path d="M 368,176 L 400,176" fill="none" stroke="black" />
<text x="100" y="84">[PE11]</text> <polygon class="arrowhead" points="408,176 396,170.4 396,181.6"
<text x="172" y="84">[P1]</text> fill="black"
<text x="252" y="84">[ASBR12]</text> transform="rotate(0,400,176)" />
<text x="340" y="84">[ASBR21]</text> <g class="text">
<text x="412" y="84">[P2]</text> <text x="172" y="36">[RR13]</text>
<text x="476" y="84">[PE22]</text> <text x="412" y="36">[RR23]</text>
<text x="556" y="84">[CE41]</text> <text x="28" y="84">[CE31]</text>
<text x="72" y="116">:</text> <text x="100" y="84">[PE11]</text>
<text x="296" y="116">:</text> <text x="164" y="84">[P1]</text>
<text x="512" y="116">:</text> <text x="236" y="84">[ASBR12]</text>
<text x="32" y="132">AS3</text> <text x="324" y="84">[ASBR21]</text>
<text x="72" y="132">:</text> <text x="396" y="84">[P2]</text>
<text x="200" y="132">..AS1..</text> <text x="460" y="84">[PE22]</text>
<text x="296" y="132">:</text> <text x="532" y="84">[CE41]</text>
<text x="376" y="132">..AS2..</text> <text x="72" y="116">:</text>
<text x="512" y="132">:</text> <text x="280" y="116">:</text>
<text x="560" y="132">AS4</text> <text x="472" y="116">:</text>
<text x="72" y="148">:</text> <text x="32" y="132">AS3</text>
<text x="296" y="148">:</text> <text x="72" y="132">:</text>
<text x="512" y="148">:</text> <text x="184" y="132">..AS1..</text>
<text x="52" y="180">203.0.113.31</text> <text x="280" y="132">:</text>
<text x="248" y="180">Traffic</text> <text x="360" y="132">..AS2..</text>
<text x="320" y="180">Direction</text> <text x="472" y="132">:</text>
<text x="524" y="180">203.0.113.41</text> <text x="520" y="132">AS4</text>
</g> <text x="72" y="148">:</text>
</svg> <text x="280" y="148">:</text>
</artwork><artwork type="ascii-art"><![CDATA[ <text 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="508" y="180">203.0.113.41</text>
</g>
</svg>
</artwork>
<artwork type="ascii-art"><![CDATA[
[RR13] [RR23] [RR13] [RR23]
| | | |
+ + + +
[CE31]---[PE11]----[P1]----[ASBR12]---[ASBR21]---[P2]---[PE22]----[CE41] [CE31]---[PE11]---[P1]---[ASBR12]---[ASBR21]---[P2]---[PE22]---[CE41]
: : : : : :
AS3 : ..AS1.. : ..AS2.. : AS4 AS3 : ..AS1.. : ..AS2.. : AS4
: : : : : :
203.0.113.31 ---- Traffic Direction ----> 203.0.113.41 203.0.113.31 ---- Traffic Direction ----> 203.0.113.41
]]></artwork></artset></figure> ]]></artwork>
</artset>
</figure>
<t>This example in <xref target="BGPCT_INTERAS_B"/> shows two <t><xref target="BGPCT_INTERAS_B" format="default"/> shows two
provider network Autonomous systems AS1 and AS2. They serve L3VPN provider network Autonomous Systems: AS1 and AS2. They serve L3VPN
customers AS3 and AS4 respectively. The ASBRs ASBR12 and ASBR21 customers AS3 and AS4, respectively. The ASBRs ASBR12 and ASBR21
don't have any IP VRFs. The inter-AS link is MPLS forwarding don't have any IP VRFs. The inter-AS link is MPLS-forwarding
enabled.</t> enabled.</t>
<t>Traffic direction being described is CE31 to CE41. CE41 may <t>Traffic direction being described is CE31 to CE41. CE41 may
request a specific SLA (e.g. Gold for this traffic), when traversing request a specific SLA (e.g., Gold for this traffic) when traversing
these provider core networks.</t> these provider core networks.</t>
</section> </section>
<section numbered="true" toc="default">
<section title="Transport Layer"> <name>Transport Layer</name>
<t>AS1 uses RSVP-TE intra-domain tunnels between PE11 and ASBR21. <t>AS1 uses RSVP-TE intra-domain tunnels between PE11 and ASBR21
And LDP tunnels for best effort traffic. AS2 uses SRTE intra-domain and LDP tunnels for best-effort traffic. AS2 uses SRTE intra-domain
tunnels between ASBR21 and PE22, and L-ISIS for best effort tunnels between ASBR21 and PE22 along with L-ISIS for best-effort
tunnels.</t> tunnels.</t>
<t>The networks have two TCs: Gold with TC ID 100
<t>The networks have two Transport classes: Gold with Transport and Bronze with TC ID 200. These TCs
Class ID 100, Bronze with Transport Class ID 200. These transport are provisioned at the PEs and ASBRs. This creates the
classes are provisioned at the PEs and ASBRs. This creates the Resolution Schemes for these Transport Classes at these PEs and
Resolution Schemes for these transport classes at these PEs and
ASBRs.</t> ASBRs.</t>
<t>The following tunnels exist for Gold TC:</t>
<t>Following tunnels exist for Gold transport class.<list> <ul spacing="normal">
<li>
<t>PE11_to_ASBR12_gold - RSVP-TE tunnel</t> <t>PE11_to_ASBR12_gold - RSVP-TE tunnel</t>
</li>
<li>
<t>ASBR12_to_PE11_gold - RSVP-TE tunnel</t> <t>ASBR12_to_PE11_gold - RSVP-TE tunnel</t>
</li>
<li>
<t>PE22_to_ASBR21_gold - SRTE tunnel</t> <t>PE22_to_ASBR21_gold - SRTE tunnel</t>
</li>
<li>
<t>ASBR21_to_PE22_gold - SRTE tunnel</t> <t>ASBR21_to_PE22_gold - SRTE tunnel</t>
</list></t> </li>
</ul>
<t>Following tunnels exist for Bronze transport class.<list> <t>The following tunnels exist for Bronze TC:</t>
<ul spacing="normal">
<li>
<t>PE11_to_ASBR12_bronze - RSVP-TE tunnel</t> <t>PE11_to_ASBR12_bronze - RSVP-TE tunnel</t>
</li>
<li>
<t>ASBR12_to_PE11_bronze - RSVP-TE tunnel</t> <t>ASBR12_to_PE11_bronze - RSVP-TE tunnel</t>
</li>
<li>
<t>PE22_to_ASBR21_bronze - SRTE tunnel</t> <t>PE22_to_ASBR21_bronze - SRTE tunnel</t>
</li>
<li>
<t>ASBR21_to_PE22_bronze - SRTE tunnel</t> <t>ASBR21_to_PE22_bronze - SRTE tunnel</t>
</list></t> </li>
</ul>
<t>These tunnels are provisioned to belong to transport class 100 or <t>These tunnels are provisioned to belong to TC 100 or
200.</t> 200.</t>
</section> </section>
<section numbered="true" toc="default">
<section title="Service Layer route exchange"> <name>Service Layer Route Exchange</name>
<t>Service nodes PE11, ASBR12 negotiate service family (AFI/SAFI <t>Service nodes PE11 and ASBR12 negotiate service family (AFI/SAFI
1/128) on the BGP session with RR13. Service helper RR13 reflects 1/128) on the BGP session with RR13. Service helper RR13 reflects
service routes between the PE11 and ASBR12 with next hop service routes between the PE11 and ASBR12 with the next hop
unchanged.</t> unchanged.</t>
<t>Similarly, in AS2 PE22, ASBR21 negotiates service family (AFI/SAFI
<t>Similarly, in AS2 PE22, ASBR21 negotiate service family (AFI/SAFI
1/128) on the BGP session with RR23, which reflects service routes 1/128) on the BGP session with RR23, which reflects service routes
between the PE22 and ASBR21 with next hop unchanged.</t> between PE22 and ASBR21 with the next hop unchanged.</t>
<t>ASBR21 and ASBR12 negotiate AFI/SAFI 1/128 between them and
<t>ASBR21 and ASBR12 negotiate AFI/SAFI 1/128 between them, and readvertise L3VPN routes with the next hop set to themselves, allocati
readvertise L3VPN routes with next hop self, allocating new labels. ng new labels.
The single-hop EBGP session endpoints are interface addresses.</t> The single-hop EBGP session endpoints are interface addresses.</t>
<t>CE41 advertises a route, for example, prefix 203.0.113.41 with the
<t>CE41 advertises a route for example prefix 203.0.113.41 with next next
hop self to PE22 VRF. CE41 can attach a Mapping Community hop set to itself to PE22 VRF. CE41 can attach a Mapping Community
Color:0:100 on this route, to indicate its request for Gold SLA. Or, color:0:100 on this route to indicate its request for the Gold SLA. Or
,
PE22 can attach the same using locally configured policies.</t> PE22 can attach the same using locally configured policies.</t>
<t>Consider CE41 getting VPN service from PE22. The
<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 RD:203.0.113.41 route is readvertised in AFI/SAFI 1/128 by PE22 with
next hop self (192.0.2.22) and label V-L1 to RR23 with the Mapping the next hop set to itself (192.0.2.22) and label V-L1 to RR23 with th
Community Color:0:100 attached. This AFI/SAFI 1/128 route reaches e Mapping
Community 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. 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 Now ASBR21 can resolve the PNH 192.0.2.22 using ASBR21_to_PE22_gold
SRTE LSP.</t> SRTE LSP.</t>
<t>Next, ASBR21 readvertises the RD:203.0.113.41 route with the next h
<t>Next, ASBR21 readvertises the RD:203.0.113.41 route with next hop op
self to ASBR12 with a newly allocated MPLS label V-L2. Forwarding set to itself to ASBR12 with a newly allocated MPLS label V-L2. Forwar
ding
for this label is installed to Swap V-L1, and Push labels for for this label is installed to Swap V-L1, and Push labels for
ASBR21_to_PE22_gold tunnel.</t> ASBR21_to_PE22_gold tunnel.</t>
<t>ASBR12 further readvertises the RD:203.0.113.41 route via RR13 to <t>ASBR12 further readvertises the RD:203.0.113.41 route via RR13 to
PE11 with next hop self 192.0.2.12. PE11 resolves the next hop PE11 with the next hop set to itself, 192.0.2.12. PE11 resolves the ne xt hop
192.0.2.12 over PE11_to_ASBR12_gold RSVP TE tunnel.</t> 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
<t>Traffic traverses as IP packet on the following legs: CE31-PE11 and PE21-CE41. And it uses MPLS forwarding on the ASBR11-ASBR21 link a
and PE21-CE41. And uses MPLS forwarding on ASBR11-ASBR21 link, and nd
inside AS1-AS2 core.</t> inside the AS1-AS2 core.</t>
<t>BGP CT AFI/SAFI 1/76 is not used in this inter-AS option B
<t>BGP CT AFI/SAFI 1/76 is not used in this Inter-AS Option B deployment. But the Transport Class and Resolution Scheme constructs
deployment. But the Transport class and Resolution Scheme constructs are used to preserve an end-to-end SLA.</t>
are used to preserve end-to-end SLA.</t>
</section> </section>
</section> </section>
</section> </section>
<section anchor="Appendix_C" numbered="true" toc="default">
<section anchor="Appendix C" numbered="true" <name>Why reuse RFCs 8277 and 4364?</name>
title="Why reuse RFC 8277 and RFC 4364?"> <t><xref target="RFC4364"/> is one of the key design patterns produced by
<t>RFC 4364 is one of the key design patterns produced by networking the networking
industry. It introduced virtualization and allowed sharing of resources industry. It introduced virtualization and allowed sharing of resources
in service provider space with multiple tenant networks, providing in the service provider space with multiple tenant networks, providing
isolated and secure Layer3 VPN services. This design pattern has been isolated and secure Layer 3 VPN services. This design pattern has been
reused since to provide other service layer virtualizations like Layer2 reused since to provide other service layer virtualizations like Layer 2
virtualization (VPLS, L2VPN, EVPN), ISO virtualization, ATM virtualization (VPLS, L2VPN, EVPN), ISO virtualization, ATM
virtualization, Flowspec VPN.</t> virtualization, and Flowspec VPN.</t>
<t>It is to be noted that these services have different NLRI encodings.
<t>It is to be noted that these services have different NLRI encoding. The L3VPN service family that binds the MPLS label to an IP prefix uses th
L3VPN Service family that binds MPLS label to an IP prefix use RFC 8277 e encoding described in <xref target="RFC8277"/>
encoding, and others define different NLRI encodings.</t> and others define different NLRI encodings.</t>
<t>BGP CT reuses the procedures described in <xref target="RFC4364"/> to s
<t>BGP CT reuses RFC 4364 procedures to slice a transport network into lice a transport network into
multiple transport planes that different service routes can bind to, multiple transport planes that different service routes can bind to
using color.</t> using color.</t>
<t>BGP CT reuses <xref target="RFC8277"/> because it precisely fits the pu
<t>BGP CT reuses RFC 8277 because it precisely fits the purpose. viz. In rpose. That is, in
a MPLS network, BGP CT needs to bind MPLS label for transport endpoints an MPLS network, BGP CT needs to bind the MPLS label for transport endpoin
ts,
which are IPv4 or IPv6 endpoints, and disambiguate between multiple which are IPv4 or IPv6 endpoints, and disambiguate between multiple
instances of those endpoints in multiple transport planes. Hence, use of instances of those endpoints in multiple transport planes. Hence, use of t
RD:IP_Prefix and carrying a Label for it as specified in RFC 8277 works he
RD:IP_Prefix and carrying a Label for it as specified in <xref target="RFC
8277"/> works
well for this purpose.</t> well for this purpose.</t>
<t>Another advantage of using the precise encoding as defined in <xref
<t>Another advantage of using the precise encoding as defined in RFC target="RFC4364"/> and <xref target="RFC8277"/> is that it allows
4364 and RFC 8277 is that it allows to interoperate with BGP speakers interoperation with BGP speakers that support SAFI 128 for AFIs 1 or
that support SAFI 128 for AFIs 1 or 2. This can be useful during 2. This can be useful during transition until all BGP speakers in the
transition, until all BGP speakers in the network support BGP CT.</t> network support BGP CT.</t>
<t>In the future, if <xref target="RFC8277"/> evolves into a typed NLRI th
<t>In future, if RFC 8277 evolves into a typed NLRI, that does not carry at does not carry
Label in the NLRI, BGP CT will be compatible with that as-well. In Label in the NLRI, BGP CT will be compatible with that as well. In
essence, BGP CT encoding is compatible with existing deployed essence, BGP CT encoding is compatible with existing deployed
technologies (RFC 4364, RFC 8277) and will adapt to any changes RFC 8277 technologies (<xref target="RFC4364"/> and <xref target="RFC8277"/>) and w
mechanisms undergo in future.</t> ill adapt to any changes mechanisms from <xref target="RFC8277"/>
undergo in future.</t>
<t>This approach leverages the benefits of time tested design patterns <t>This approach leverages the benefits of time-tested design patterns
proposed in RFC 4364 and RFC 8277. Moreover, this approach greatly proposed in <xref target="RFC4364"/> and <xref target="RFC8277"/>. Moreove
r, this approach greatly
reduces operational training costs and protocol compatibility reduces operational training costs and protocol compatibility
considerations, as it complements and works well with existing protocol considerations as it complements and works well with existing protocol
machineries. This problem does not need reinventing the wheel with brand machinery: this problem does not need a brand
new NLRI and procedures.</t> new NLRI and procedures.</t>
<t>BGP CT design also avoids overloading the NLRI MPLS label field from <x
<t>BGP CT design also avoids overloading RFC 8277 NLRI MPLS Label field ref target="RFC8277"/>
with information related to non MPLS data plane, because it leads to with information related to the non-MPLS data plane because it leads to
backward compatibility issues.</t> backward-compatibility issues.</t>
<section numbered="true" toc="default">
<section numbered="true" title="Update packing considerations"> <name>Update Packing Considerations</name>
<t>BGP CT carries transport class as an attribute. This means routes <t>BGP CT carries Transport Class as an attribute. This means routes
that don't share the same transport class cannot be packed into same that don't share the same Transport Class cannot be packed into the same
Update message. Update packing in BGP CT will be similar to RFC 8277 BGP UPDATE message. Update packing in BGP CT will be similar to family r
family routes carrying attributes like communities or extended outes from <xref target="RFC8277"/>
carrying attributes like communities or extended
communities. Service families like AFI/SAFI 1/128 have considerably 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, 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 which carry only loopbacks. Update packing mechanisms that scale for
AFI/SAFI 1/128 routes will scale similarly for AFI/SAFI 1/76 routes AFI/SAFI 1/128 routes will scale similarly for AFI/SAFI 1/76 routes.
also.</t> </t>
<t><xref section="6.3.2.1" target="I-D.hr-spring-intentaware-routing-usi
<t>Section 6.3.2.1 of <xref target="Intent-Routing-Color"/> suggests ng-color" format="default"/> suggests
scaling numbers for transport network where BGP CT can be deployed. scaling numbers for a transport network where BGP CT can be deployed.
Experiments were conducted with this scale to find the convergence Experiments were conducted with this scale to find the convergence
time with BGP CT for those scaling numbers. Scenarios involving BGP CT time with BGP CT for those scaling numbers. Scenarios involving BGP CT
carrying IPv4 and IPv6 endpoints with MPLS label were tested. Tests carrying IPv4 and IPv6 endpoints with an MPLS label were tested. Tests
with BGP CT IPv6 endpoints and SRv6 SID are planned.</t> 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
<t>Tests were conducted with 1.9 million BGP CT route scale (387K endpoints in 5 TCs). Initial convergence time for all
endpoints in 5 transport classes). Initial convergence time for all
cases was less than 2 minutes, which compares favorably with user cases was less than 2 minutes, which compares favorably with user
expectation for such a scale. This experiment proves that carrying expectation for such a scale. This experiment proves that carrying
transport class information as an attribute keeps BGP convergence Transport Class information as an attribute keeps BGP convergence
within acceptable range. Details of the experiment and test results within an acceptable range. Details of the experiment and test results
are available in <xref target="BGP-CT-UPDATE-PACKING-TEST">BGP CT are available in <xref target="PACKING-TEST" format="default"></xref>.</
Update packing Test Results </xref>.</t> t>
<t>Furthermore, even in today's BGP LU deployments, each egress node
<t>Furthermore, even in today's BGP LU deployments each egress node originates a BGP LU route for its loopback, with some attributes like
originates BGP LU route for it's loopback, with some attributes like community identifying the originating node or region and an AIGP
community identifying the originating node or region, and AIGP attribute. These attributes may be unique per egress node; thus, they do
attribute. These attributes may be unique per egress node, thus do not not
help with update packing in transport family routes.</t> help with update packing in transport family routes.</t>
</section> </section>
</section> </section>
<section anchor="Appendix_D" numbered="true" toc="default">
<section anchor="Appendix D" numbered="true" <name>Scaling Using BGP MPLS Namespaces</name>
title="Scaling using BGP MPLS Namespaces"> <t>This document considers the scaling scenario suggested in <xref section
<t>This document considers scaling scenario suggested in Section 6.3.2.1 ="6.3.2.1" target="I-D.hr-spring-intentaware-routing-using-color" format="defaul
of <xref target="Intent-Routing-Color"/> where 300K nodes exist in the t"/> where 300K nodes exist in the
network with 5 transport classes.</t> network with 5 TCs.</t>
<t>This may result in 1.5M transport layer routes and MPLS transit <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 routes in all Border Nodes in the network, which may overwhelm the
nodes' MPLS forwarding resources.</t> nodes' MPLS-forwarding resources.</t>
<t><xref section="6.2" target="I-D.kaliraj-bess-bgp-mpls-namespaces" forma
<t>Section 6.2 of <xref target="MPLS-NS"/> describes how MPLS Namespaces t="default"/> describes how MPLS Namespaces
mechanism is used to scale such a network. This approach reduces the mechanism is used to scale such a network. This approach reduces the
number of PNHs that are globally visible in the network, thus reducing number of PNHs that are globally visible in the network, thus reducing
forwarding resource usage network wide. Service route state is kept forwarding resource usage network wide. Service route state is kept
confined closer to network edge, and any churn is confined within the confined closer to network edge, and any churn is confined within the
region containing the point of failure, which improves convergence region containing the point of failure, which improves convergence
also.</t> also.</t>
</section> </section>
<section anchor="Contributors" numbered="false" title="Contributors"> <section anchor="Acknowledgements" numbered="false" toc="default">
<section anchor="Co-Authors" numbered="false" title="Co-Authors"> <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="Contributors" numbered="false" 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"> <author fullname="Reshma Das" initials="D." surname="Das">
<organization>Juniper Networks, Inc.</organization> <organization>Juniper Networks, Inc.</organization>
<address> <address>
<postal> <postal>
<street>1133 Innovation Way,</street> <street>1133 Innovation Way</street>
<city>Sunnyvale</city> <city>Sunnyvale</city>
<region>CA</region> <region>CA</region>
<code>94089</code> <code>94089</code>
<country>United States of America</country>
<country>US</country>
</postal> </postal>
<email>dreshma@juniper.net</email> <email>dreshma@juniper.net</email>
</address> </address>
</author> </author>
<author fullname="Israel Means" initials="I" surname="Means"> <author fullname="Israel Means" initials="I" surname="Means">
<organization abbrev="">AT&amp;T</organization> <organization abbrev="">AT&amp;T</organization>
<address> <address>
<postal> <postal>
<street>2212 Avenida Mara,</street> <street>2212 Avenida Mara</street>
<city>Chula Vista</city> <city>Chula Vista</city>
<region>California</region> <region>California</region>
<code>91914</code> <code>91914</code>
<country>United States of America</country>
<country>USA</country>
</postal> </postal>
<email>israel.means@att.com</email> <email>israel.means@att.com</email>
</address> </address>
</author> </author>
<author fullname="Csaba Mate" initials="CS" surname="Mate"> <author fullname="Csaba Mate" initials="CS" surname="Mate">
<organization abbrev="">KIFU, Hungarian NREN</organization> <organization abbrev="">KIFU, Hungarian NREN</organization>
<address> <address>
<postal> <postal>
<street>35 Vaci street,</street> <street>35 Vaci Street</street>
<city>Budapest</city> <city>Budapest</city>
<region/> <region/>
<code>1134</code> <code>1134</code>
<country>Hungary</country> <country>Hungary</country>
</postal> </postal>
<email>ietf@nop.hu</email> <email>ietf@nop.hu</email>
</address> </address>
</author> </author>
<author fullname="Deepak J Gowda" initials="J" surname="Gowda"> <author fullname="Deepak J Gowda" initials="J" surname="Gowda">
<organization abbrev="">Extreme Networks</organization> <organization abbrev="">Extreme Networks</organization>
<address> <address>
<postal> <postal>
<street>55 Commerce Valley Drive West, Suite 300,</street> <street>55 Commerce Valley Drive West, Suite 300</street>
<city>Thornhill, Toronto</city>
<city>Thornhill, Toronto,</city>
<region>Ontario</region> <region>Ontario</region>
<code>L3T 7V9</code> <code>L3T 7V9</code>
<country>Canada</country> <country>Canada</country>
</postal> </postal>
<email>dgowda@extremenetworks.com</email> <email>dgowda@extremenetworks.com</email>
</address> </address>
</author> </author>
</section> <t>We also acknowledge the contribution of the following individuals:</t>
<author fullname="Balaji Rajagopalan" initials="B." surname="Rajagopalan
<section anchor="Other Contributors" numbered="false" ">
title="Other Contributors">
<author fullname="Balaji Rajagopalan" initials="B."
surname="Rajagopalan">
<organization>Juniper Networks, Inc.</organization> <organization>Juniper Networks, Inc.</organization>
<address> <address>
<postal> <postal>
<street>Electra, Exora Business Park~Marathahalli - Sarjapur <street>Electra, Exora Business Park~Marathahalli - Sarjapur
Outer Ring Road,</street> Outer Ring Road</street>
<city>Bangalore</city> <city>Bangalore</city>
<region>KA</region> <region>KA</region>
<code>560103</code> <code>560103</code>
<country>India</country> <country>India</country>
</postal> </postal>
<email>balajir@juniper.net</email> <email>balajir@juniper.net</email>
</address> </address>
</author> </author>
<author fullname="Rajesh M" initials="M"> <author fullname="Rajesh M" initials="M">
<organization>Juniper Networks, Inc.</organization> <organization>Juniper Networks, Inc.</organization>
<address> <address>
<postal> <postal>
<street>Electra, Exora Business Park~Marathahalli - Sarjapur <street>Electra, Exora Business Park~Marathahalli - Sarjapur
Outer Ring Road,</street> Outer Ring Road</street>
<city>Bangalore</city> <city>Bangalore</city>
<region>KA</region> <region>KA</region>
<code>560103</code> <code>560103</code>
<country>India</country> <country>India</country>
</postal> </postal>
<email>mrajesh@juniper.net</email> <email>mrajesh@juniper.net</email>
</address> </address>
</author> </author>
<author fullname="Chaitanya Yadlapalli" initials="C" surname="Yadlapalli
<author fullname="Chaitanya Yadlapalli" initials="C" ">
surname="Yadlapalli">
<organization abbrev="">AT&amp;T</organization> <organization abbrev="">AT&amp;T</organization>
<address> <address>
<postal> <postal>
<street>200 S Laurel Ave,</street> <street>200 S Laurel Ave</street>
<city>Middletown</city>
<city>Middletown,</city>
<region>NJ</region> <region>NJ</region>
<code>07748</code> <code>07748</code>
<country>United States of America</country>
<country>USA</country>
</postal> </postal>
<email>cy098d@att.com</email> <email>cy098d@att.com</email>
</address> </address>
</author> </author>
<author fullname="Mazen Khaddam" initials="M" surname="Khaddam"> <author fullname="Mazen Khaddam" initials="M" surname="Khaddam">
<organization abbrev="">Cox Communications Inc.</organization> <organization abbrev="">Cox Communications Inc.</organization>
<address> <address>
<postal> <postal>
<street/> <street/>
<city>Atlanta</city> <city>Atlanta</city>
<region>GA</region> <region>GA</region>
<code/> <code/>
<country>United States of America</country>
<country>USA</country>
</postal> </postal>
<email>mazen.khaddam@cox.com</email> <email>mazen.khaddam@cox.com</email>
</address> </address>
</author> </author>
<author fullname="Rafal Jan Szarecki" initials="R" surname="Szarecki"> <author fullname="Rafal Jan Szarecki" initials="R" surname="Szarecki">
<organization abbrev="">Google.</organization> <organization abbrev="">Google</organization>
<address> <address>
<postal> <postal>
<street>1160 N Mathilda Ave, Bldg 5,</street> <street>1160 N Mathilda Ave, Bldg 5</street>
<city>Sunnyvale</city>
<city>Sunnyvale,</city>
<region>CA</region> <region>CA</region>
<code>94089</code> <code>94089</code>
<country>United States of America</country>
<country>USA</country>
</postal> </postal>
<email>szarecki@google.com</email> <email>szarecki@google.com</email>
</address> </address>
</author> </author>
<author fullname="Xiaohu Xu" initials="X" surname="Xu"> <author fullname="Xiaohu Xu" initials="X" surname="Xu">
<organization abbrev="">China Mobile</organization> <organization abbrev="">China Mobile</organization>
<address> <address>
<postal> <postal>
<street/> <street/>
<city>Beijing</city> <city>Beijing</city>
<region/> <region/>
<code/> <code/>
<country>China</country> <country>China</country>
</postal> </postal>
<email>xuxiaohu@cmss.chinamobile.com</email> <email>xuxiaohu@cmss.chinamobile.com</email>
</address> </address>
</author> </author>
</section> </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> </back>
</rfc> </rfc>
 End of changes. 727 change blocks. 
3352 lines changed or deleted 3312 lines changed or added

This html diff was produced by rfcdiff 1.48.