rfc9832v1.txt   rfc9832.txt 
Internet Engineering Task Force (IETF) K. Vairavakkalai, Ed. Internet Engineering Task Force (IETF) K. Vairavakkalai, Ed.
Request for Comments: 9832 N. Venkataraman, Ed. Request for Comments: 9832 N. Venkataraman, Ed.
Category: Experimental Juniper Networks, Inc. Category: Experimental Juniper Networks, Inc.
ISSN: 2070-1721 August 2025 ISSN: 2070-1721 September 2025
BGP Classful Transport Planes BGP Classful Transport Planes
Abstract Abstract
This document specifies a mechanism referred to as "Intent-Driven 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 Level Agreement (SLA). This is achieved by defining new constructs
to group underlay routes with sufficiently similar TE characteristics to group underlay routes with sufficiently similar TE characteristics
into identifiable classes (called "Transport Classes" or "TCs"), that into identifiable classes (called "Transport Classes" or "TCs"), that
overlay routes use as an ordered set to resolve reachability overlay routes use as an ordered set to resolve reachability
(Resolution Schemes) towards service endpoints. These constructs can (Resolution Schemes) towards service endpoints. These constructs can
be used, for example, to realize the "IETF Network Slice" defined in be used, for example, to realize the "IETF Network Slice" defined in
the TEAS Network Slices framework. the TEAS Network Slices framework (RFC 9543).
Additionally, this document specifies protocol procedures for BGP 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 that may span multiple cooperating administrative domains. These
domains may be administered either by the same provider or by closely domains may be administered either by the same provider or by closely
coordinating providers. A new BGP address family that leverages the coordinating providers. A new BGP address family that leverages the
procedures described in "BGP/MPLS IP Virtual Private Networks (VPNs)" procedures described in RFC 4364 ("BGP/MPLS IP Virtual Private
(RFC 4364) and follows the NLRI encoding described in RFC 8277 Networks (VPNs)") and follows the NLRI encoding described in RFC 8277
("Using BGP to Bind MPLS Labels to Address Prefixes") is defined to ("Using BGP to Bind MPLS Labels to Address Prefixes") is defined to
enable each advertised underlay route to be identified by its class. enable each advertised underlay route to be identified by its class.
This new address family is called "BGP Classful Transport" (or "BGP This new address family is called "BGP Classful Transport" (or "BGP
CT"). CT").
Status of This Memo Status of This Memo
This document is not an Internet Standards Track specification; it is This document is not an Internet Standards Track specification; it is
published for examination, experimental implementation, and published for examination, experimental implementation, and
evaluation. evaluation.
skipping to change at line 79 skipping to change at line 79
1. Introduction 1. Introduction
2. Terminology 2. Terminology
2.1. Abbreviations 2.1. Abbreviations
2.2. Definitions and Notations 2.2. Definitions and Notations
2.3. Requirements Language 2.3. Requirements Language
3. Architecture Overview 3. Architecture Overview
4. Transport Class 4. Transport Class
4.1. Classifying TE Tunnels 4.1. Classifying TE Tunnels
4.2. Transport Route Database (TRDB) 4.2. Transport Route Database (TRDB)
4.3. "Transport Class" Route Target Extended Community 4.3. Transport Class Route Target
5. Resolution Scheme 5. Resolution Scheme
5.1. Mapping Community 5.1. Mapping Community
6. BGP Classful Transport Family 6. BGP Classful Transport Family
6.1. NLRI Encoding 6.1. NLRI Encoding
6.2. Next Hop Encoding 6.2. Next Hop Encoding
6.3. Carrying Multiple Encapsulation Information 6.3. Carrying Multiple Types of Encapsulation Information
6.4. Comparison with Other Families Using Encoding from RFC 8277 6.4. Comparison with Other Families Using Encoding from RFC 8277
7. Protocol Procedures 7. Protocol Procedures
7.1. Preparing the Network to Deploy Classful Transport Planes 7.1. Preparing the Network to Deploy Classful Transport Planes
7.2. Originating Classful Transport Routes 7.2. Originating BGP CT Routes
7.3. Processing Classful Transport Routes by Ingress Nodes 7.3. Processing BGP CT Routes by Ingress Nodes
7.4. Readvertising Classful Transport Route by Border Nodes 7.4. Readvertising BGP CT Route by Border Nodes
7.5. Border Nodes Receiving Classful Transport Routes on EBGP 7.5. Border Nodes Receiving BGP CT Routes on EBGP
7.6. Avoiding Path Hiding Through Route Reflectors 7.6. Avoiding Path Hiding Through Route Reflectors
7.7. Avoiding Loops Between Route Reflectors in Forwarding Paths 7.7. Avoiding Loops Between Route Reflectors in Forwarding Paths
7.8. Ingress Nodes Receiving Service Routes with a Mapping 7.8. Ingress Nodes Receiving Service Routes with a Mapping
Community Community
7.9. Best-Effort Transport Class 7.9. Best-Effort Transport Class
7.10. Interaction with BGP Attributes Specifying Next Hop Address 7.10. Interaction with BGP Attributes Specifying Next Hop Address
and Color and Color
7.11. Applicability to Flowspec Redirect-to-IP 7.11. Applicability to Flowspec Redirect-to-IP
7.12. Applicability to IPv6 7.12. Applicability to IPv6
7.13. SRv6 Support 7.13. SRv6 Support
7.14. Error-Handling Considerations 7.14. Error-Handling Considerations
8. Illustration of BGP CT Procedures 8. Illustration of BGP CT Procedures
8.1. Reference Topology 8.1. Reference Topology
8.2. Service-Layer Route Exchange 8.2. Service Layer Route Exchange
8.3. Transport-Layer Route Propagation 8.3. Transport Layer Route Propagation
8.4. Data Plane View 8.4. Data Plane View
8.4.1. Steady State 8.4.1. Steady State
8.4.2. Local Repair of Primary Path 8.4.2. Local Repair of Primary Path
8.4.3. Absorbing Failure of the Primary Path: Fallback to 8.4.3. Absorbing Failure of the Primary Path: Fallback to
Best-Effort Tunnels Best-Effort Tunnels
9. Scaling Considerations 9. Scaling Considerations
9.1. Avoiding Unintended Spread of BGP CT Routes Across Domains 9.1. Avoiding Unintended Spread of BGP CT Routes Across Domains
9.2. Constrained Distribution of PNHs to SNs (On-Demand Next 9.2. Constrained Distribution of PNHs to SNs (On-Demand Next
Hop) Hop)
9.3. Limiting the Visibility Scope of PE Loopback as PNHs 9.3. Limiting the Visibility Scope of PE Loopback as PNHs
10. Operations and Manageability Considerations 10. Operations and Manageability Considerations
10.1. MPLS OAM 10.1. MPLS OAM
10.2. Usage of RD and Label-Allocation Modes 10.2. Usage of RD and Label-Allocation Modes
10.3. Managing Transport-Route Visibility 10.3. Managing Transport-Route Visibility
11. Deployment Considerations 11. Deployment Considerations
11.1. Coordination Between Domains Using Different Community 11.1. Coordination Between Domains Using Different Community
Namespaces Namespaces
11.2. Managing Intent at Service and Transport Layers 11.2. Managing Intent at Service and Transport Layers
11.2.1. Service-Layer Color Management 11.2.1. Service Layer Color Management
11.2.2. Non-Agreeing Color Transport Domains 11.2.2. Non-Agreeing Color Transport Domains
11.2.3. Heterogeneous Agreeing Color Transport Domains 11.2.3. Heterogeneous Agreeing Color Transport Domains
11.3. Migration Scenarios 11.3. Migration Scenarios
11.3.1. BGP CT Islands Connected via BGP LU Domain 11.3.1. BGP CT Islands Connected via BGP LU Domain
11.3.2. BGP CT: Interoperability Between MPLS and Other 11.3.2. BGP CT: Interoperability Between MPLS and Other
Forwarding Technologies Forwarding Technologies
11.4. MTU Considerations 11.4. MTU Considerations
11.5. Use of DSCP 11.5. Use of DSCP
12. Applicability to Network Slicing 12. Applicability to Network Slicing
13. IANA Considerations 13. IANA Considerations
skipping to change at line 155 skipping to change at line 155
16.1. Normative References 16.1. Normative References
16.2. Informative References 16.2. Informative References
Appendix A. Extensibility Considerations Appendix A. Extensibility Considerations
A.1. Signaling Intent over a PE-CE Attachment Circuit A.1. Signaling Intent over a PE-CE Attachment Circuit
A.2. BGP CT Egress TE A.2. BGP CT Egress TE
Appendix B. Applicability to Intra-AS and Different Inter-AS Appendix B. Applicability to Intra-AS and Different Inter-AS
Deployments Deployments
B.1. Intra-AS Use Case B.1. Intra-AS Use Case
B.1.1. Topology B.1.1. Topology
B.1.2. Transport Layer B.1.2. Transport Layer
B.1.3. Service-Layer Route Exchange B.1.3. Service Layer Route Exchange
B.2. Inter-AS Option A Use Case B.2. Inter-AS Option A Use Case
B.2.1. Topology B.2.1. Topology
B.2.2. Transport Layer B.2.2. Transport Layer
B.2.3. Service Layer Route Exchange B.2.3. Service Layer Route Exchange
B.3. Inter-AS Option B Use Case B.3. Inter-AS Option B Use Case
B.3.1. Topology B.3.1. Topology
B.3.2. Transport Layer B.3.2. Transport Layer
B.3.3. Service-Layer Route Exchange B.3.3. Service Layer Route Exchange
Appendix C. Why reuse RFCs 8277 and 4364? Appendix C. Why reuse RFCs 8277 and 4364?
C.1. Update Packing Considerations C.1. Update Packing Considerations
Appendix D. Scaling Using BGP MPLS Namespaces Appendix D. Scaling Using BGP MPLS Namespaces
Acknowledgements Acknowledgements
Contributors Contributors
Authors' Addresses Authors' Addresses
1. Introduction 1. Introduction
Provider networks typically span across multiple domains where each Provider networks typically span across multiple domains where each
skipping to change at line 189 skipping to change at line 189
[RFC9315] defines "Intent" as: [RFC9315] defines "Intent" as:
| A set of operational goals (that a network should meet) and | A set of operational goals (that a network should meet) and
| outcomes (that a network is supposed to deliver) defined in a | outcomes (that a network is supposed to deliver) defined in a
| declarative manner without specifying how to achieve or implement | declarative manner without specifying how to achieve or implement
| them. | them.
This document prescribes constructs and procedures to realize This document prescribes constructs and procedures to realize
"Intent" and enable provider networks to forward service traffic "Intent" and enable provider networks to forward service traffic
based on service-specific intent from end-to-end across service based on service specific Intent from end-to-end across service
endpoints. endpoints.
The mechanisms described in this document achieve "Intent-Driven The mechanisms described in this document achieve "Intent Driven
Service Mapping" between any pair of service endpoints by: Service Mapping" between any pair of service endpoints by:
* Provisioning end-to-end "intent-aware" paths using BGP. For * Provisioning end-to-end "Intent aware" paths using BGP. For
example, a low-latency path or a best-effort path. example, a low-latency path or a best-effort path.
* Expressing a desired intent. For example, use a low-latency path * Expressing a desired Intent. For example, use a low-latency path
with a fallback to the best-effort path. with a fallback to the best-effort path.
* Forwarding service traffic "only" using end-to-end "intent-aware" * Forwarding service traffic "only" using end-to-end "Intent aware"
paths honoring that desired intent. paths honoring that desired Intent.
The constructs and procedures defined in this document apply equally The constructs and procedures defined in this document apply equally
to intra-AS and inter-AS (a.k.a. multi-AS) deployments in the style to intra-AS and inter-AS (a.k.a. multi-AS) deployments in the style
of Option A, Option B, and Option C (Section 10 of [RFC4364]) in of option A, option B, and option C (Section 10 of [RFC4364]) in
provider networks. provider networks.
Such networks provision intra-domain transport tunnels between a pair Such networks provision intra-domain transport tunnels between a pair
of endpoints, typically a service node or a border node that service of endpoints, typically a service node or a border node that service
traffic traverses through. These tunnels are signaled using various traffic traverses through. These tunnels are signaled using various
tunneling protocols depending on the forwarding architecture used in tunneling protocols depending on the forwarding architecture used in
the domain, which can be Multiprotocol Label Switching (MPLS), the domain, which can be Multiprotocol Label Switching (MPLS),
Internet Protocol version 4 (IPv4), or Internet Protocol version 6 Internet Protocol version 4 (IPv4), or Internet Protocol version 6
(IPv6). (IPv6).
skipping to change at line 231 skipping to change at line 231
tunneling technologies are detailed in this document. In some tunneling technologies are detailed in this document. In some
examples, only MPLS Traffic Engineering (TE) is described. Other examples, only MPLS Traffic Engineering (TE) is described. Other
tunneling technologies have been described in detail in other tunneling technologies have been described in detail in other
documents (and only an overview has been included in this document). documents (and only an overview has been included in this document).
For example, the details for Segment Routing over IPv6 (SRv6) are For example, the details for Segment Routing over IPv6 (SRv6) are
provided in [BGP-CT-SRv6] and an overview is provided in provided in [BGP-CT-SRv6] and an overview is provided in
Section 7.13. Section 7.13.
Customers need to be able to express desired Intent to the network, 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. "Intent aware" tunnels for these classes.
This document introduces a new BGP address family called "BGP This document introduces a new BGP address family called "BGP
Classful Transport", which extends/stitches intent-aware intra-domain Classful Transport (BGP CT)", which extends/stitches Intent aware
tunnels belonging to the same class across domain boundaries to intra-domain tunnels belonging to the same class across domain
establish end-to-end intent-aware paths between service endpoints. boundaries to establish end-to-end Intent aware paths between service
endpoints.
[Intent-Routing-Color] describes various use cases and applications [Intent-Routing-Color] describes various use cases and applications
of the procedures described in this document. of the procedures described in this document.
Appendix C provides an outline of the design philosophy behind this Appendix C provides an outline of the design philosophy behind this
specification. In particular, readers who are already familiar with specification. In particular, readers who are already familiar with
one or more BGP VPN technologies may want to review this appendix one or more BGP VPN technologies may want to review this appendix
before reading the main body of the specification. before reading the main body of the specification.
2. Terminology 2. Terminology
skipping to change at line 320 skipping to change at line 321
PNH: Protocol Next Hop (address carried in a BGP UPDATE message) PNH: Protocol Next Hop (address carried in a BGP UPDATE message)
RD: Route Distinguisher RD: Route Distinguisher
RD:EP: Route Distinguisher and Endpoint (in a BGP Prefix) RD:EP: Route Distinguisher and Endpoint (in a BGP Prefix)
RSVP-TE: Resource Reservation Protocol - Traffic Engineering RSVP-TE: Resource Reservation Protocol - Traffic Engineering
RT: Route Target (as used in Route Target extended community) RT: Route Target (as used in Route Target extended community)
RTC: Route Target Constrain [RFC4684] RTC: Route Target Constraint [RFC4684]
SAFI: Subsequent Address Family Identifier SAFI: Subsequent Address Family Identifier
SID: Segment Identifier SID: Segment Identifier
SLA: Service Level Agreement SLA: Service Level Agreement
SN: Service Node SN: Service Node
SR: Segment Routing SR: Segment Routing
skipping to change at line 342 skipping to change at line 343
SRTE: Segment Routing Traffic Engineering SRTE: Segment Routing Traffic Engineering
TC: Transport Class TC: Transport Class
TC ID: Transport Class Identifier TC ID: Transport Class Identifier
TC-BE: Transport Class - Best Effort TC-BE: Transport Class - Best Effort
TE: Traffic Engineering TE: Traffic Engineering
TEA: Tunnel Encapsulation Attribute (attribute type code 23) TEA: Tunnel Encapsulation Attribute (attribute code 23)
TRDB: Transport Route Database TRDB: Transport Route Database
UHP: Ultimate Hop Popping UHP: Ultimate Hop Popping
VRF: Virtual Routing and Forwarding (used with a table) VRF: Virtual Routing and Forwarding (used with a table)
2.2. Definitions and Notations 2.2. Definitions and Notations
BGP CCA: BGP CCA:
A BGP attribute that carries community. Examples of BGP CCAs are A BGP attribute that carries community. Examples of BGP CCAs are
COMMUNITIES (attribute code 8), EXTENDED COMMUNITIES (attribute COMMUNITIES (attribute code 8), EXTENDED COMMUNITIES (attribute
code 16), IPv6 Address Specific Extended Community (attribute code code 16), IPv6 Address Specific Extended Community (attribute code
25), and LARGE_COMMUNITY (attribute code 32). 25), and LARGE_COMMUNITY (attribute code 32).
color:0:100: color:0:100 or col-100:
This notation denotes a Color Extended Community as defined in This notation denotes a Color extended community as defined in
[RFC9012] with the "Flags" field set to 0 and the "Color" field [RFC9012] with the "Flags" field set to 0 and the "Color Value"
set to 100. field set to 100.
End-to-End Tunnel: End-to-End Tunnel:
A tunnel spanning several adjacent tunnel domains created by A tunnel spanning several adjacent tunnel domains created by
"stitching" them together using MPLS labels or an equivalent "stitching" them together using MPLS labels or an equivalent
identifier based on the forwarding architecture. identifier based on the forwarding architecture.
Import processing: Import processing:
Receive-side processing of an overlay route, including things like Receive-side processing of an overlay route, including things like
import-policy application, resolution-scheme selection, and NH import-policy application, Resolution Scheme selection, and NH
resolution. resolution.
Mapping Community: Mapping Community:
Any BGP CCA (e.g., Community, Extended Community) on an overlay Any BGP CCA (e.g., Community, Extended Community) on an overlay
route that maps to a Resolution Scheme. For example, color:0:100, route that maps to a Resolution Scheme. For example, color:0:100,
transport-target:0:100. transport-target:0:100.
Provider Namespace: Provider Namespace:
Internal Infrastructure address space in a provider network Internal Infrastructure address space in a provider network
managed by the Operator. managed by the operator.
Resolution Scheme: Resolution Scheme:
A construct comprising of an ordered set of TRDBs to resolve NH A construct comprising of an ordered set of TRDBs to resolve NH
reachability for realizing a desired intent. reachability for realizing a desired Intent.
Service Family: Service Family:
A BGP address family used for advertising routes for destinations A BGP address family used for advertising routes for destinations
in "data traffic". For example, AFI/SAFIs 1/1 or 1/128. in "data traffic". For example, AFI/SAFIs 1/1 or 1/128.
Service Prefix: Service Prefix:
A destination in "data traffic". Routes to these prefixes are A destination in "data traffic". Routes to these prefixes are
carried in a Service family. carried in a Service Family.
Transport Family: Transport Family:
A BGP address family used for advertising tunnels, which are, in A BGP address family used for advertising tunnels, which are, in
turn, used by service routes for resolution. For example, AFI/ turn, used by service routes for resolution. For example, AFI/
SAFIs 1/4 or 1/76. SAFIs 1/4 or 1/76.
Transport Tunnel: Transport Tunnel:
A tunnel over which a service may place traffic. Such a tunnel A tunnel over which a service may place traffic. Such a tunnel
can be provisioned or signaled using a variety of means. For can be provisioned or signaled using a variety of means. For
example, Generic Routing Encapsulation (GRE), UDP, LDP, RSVP-TE, example, Generic Routing Encapsulation (GRE), UDP, LDP, RSVP-TE,
IGP Flexible Algorithm (FLEX-ALGO), or SRTE. IGP Flexible Algorithm (Flex-Algo), or SRTE.
Transport, Transport Layer: Transport Layer:
A layer in the network that contains Transport Tunnels and A layer in the network that contains Transport Tunnels and
Transport Families. Transport Families.
Tunnel Route: Tunnel Route:
A Route to Tunnel Destination/Endpoint that is installed at the A Route to Tunnel Destination/Endpoint that is installed at the
headend (ingress) of the tunnel. headend (ingress) of the tunnel.
Tunnel Domain: Tunnel Domain:
A domain of the network containing SNs and BNs under a single A domain of the network containing SNs and BNs under a single
administrative control that has tunnels between them. administrative control that has tunnels between them.
skipping to change at line 437 skipping to change at line 438
Transport Class: Transport Class:
A construct to group transport tunnels offering similar SLAs (see A construct to group transport tunnels offering similar SLAs (see
Section 4.1). Section 4.1).
Transport Class RT: Transport Class RT:
A Route Target extended community used to identify a specific A Route Target extended community used to identify a specific
Transport Class. Transport Class.
transport-target:0:100: transport-target:0:100:
This notation denotes a Transport Class Route Target extended This notation denotes a Transport Class RT as defined in this
community as defined in this document with the "Transport Class document with the "Transport Class ID" field set to 100.
ID" field set to 100.
Transport Route Database: Transport Route Database:
At the SN and BN, a Transport Class has an associated TRDB that At the SN and BN, a Transport Class has an associated TRDB that
collects its tunnel routes. collects its tunnel routes.
Transport Plane: Transport Plane:
An end-to-end plane consisting of transport tunnels belonging to An end-to-end plane consisting of transport tunnels belonging to
the same Transport Class. the same Transport Class.
2.3. Requirements Language 2.3. Requirements Language
skipping to change at line 463 skipping to change at line 463
"OPTIONAL" in this document are to be interpreted as described in "OPTIONAL" in this document are to be interpreted as described in
BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
3. Architecture Overview 3. Architecture Overview
This section describes the BGP CT architecture with a brief This section describes the BGP CT architecture with a brief
illustration: illustration:
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
Figure 1: BGP CT Overview with Example Topology Figure 1: BGP CT Overview with Example Topology
To achieve end-to-end "Intent-Driven Service Mapping", this document To achieve end-to-end "Intent Driven Service Mapping", this document
defines the following constructs and BGP extensions: defines the following constructs and BGP extensions:
* The "Transport Class" construct (see Section 4) to group underlay * The "Transport Class" construct (see Section 4) to group underlay
tunnels. tunnels.
* The "Resolution Scheme" construct (see Section 5) for overlay * The "Resolution Scheme" construct (see Section 5) for overlay
routes with Mapping Communities to resolve NH reachability from routes with Mapping Communities to resolve NH reachability from
either one or an ordered set of Transport Classes. either one or an ordered set of Transport Classes.
* The "BGP Classful Transport" (see Section 6) address family to * The "BGP Classful Transport" (see Section 6) address family to
extend these constructs to adjacent domains. extend these constructs to adjacent domains.
Figure 1 depicts the intra-AS and inter-AS application of these Figure 1 depicts the intra-AS and inter-AS application of these
constructs. Interactions between SN1 and PE11 describe the Intra-AS constructs. Interactions between SN1 and PE11 describe the intra-AS
usage. Interactions between PE21 and PE11 describe the Inter-AS usage. Interactions between PE21 and PE11 describe the inter-AS
usage. usage.
The example topology is an Inter-AS option C network (Section 10 of The example topology is an inter-AS option C network (Section 10 of
[RFC4364]) with two AS domains; each domain contains tunnels serving [RFC4364]) with two AS domains; each domain contains tunnels serving
two Intents, e.g., 'low-latency' denoted by color 100 and 'high- two Intents, e.g., 'low-latency' denoted by color 100 and 'high-
bandwidth' denoted by color 200. AS1 is an RSVP-TE network; AS2 is bandwidth' denoted by color 200. AS1 is an RSVP-TE network; AS2 is
an SRTE network. BGP CT and BGP LU are transport families used an SRTE network. BGP CT and BGP LU are transport families used
between the two AS domains. IP1, IP2, and IP3 are service prefixes between the two AS domains. IP1, IP2, and IP3 are service prefixes
(AFI/SAFI: 1/1) behind egress PE11. (AFI/SAFI: 1/1) behind egress PE11.
PE21, SN11, and PE11 are the SNs in this network. SN11 is an ingress 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 PE with intra-domain reachability to PE11. PE21 is an ingress PE
with inter-domain reachability to PE11. with inter-domain reachability to PE11.
skipping to change at line 534 skipping to change at line 534
The tunneling mechanisms are made "Transport Class" aware. They The tunneling mechanisms are made "Transport Class" aware. They
publish their underlay tunnels for a Transport Class into an publish their underlay tunnels for a Transport Class into an
associated TRDB (see Section 4.2). In Figure 1, RSVP-TE publishes associated TRDB (see Section 4.2). In Figure 1, RSVP-TE publishes
its underlay tunnels into TRDBs created for Transport Classes 100 and its underlay tunnels into TRDBs created for Transport Classes 100 and
200 at BN11 and SN11 within AS1; Similarly, SR-TE publishes its 200 at BN11 and SN11 within AS1; Similarly, SR-TE publishes its
underlay tunnels into TRDBs created for Transport Classes 100 and 200 underlay tunnels into TRDBs created for Transport Classes 100 and 200
at PE21 within AS2. at PE21 within AS2.
Resolution Schemes are used to realize Intent. A Resolution Scheme Resolution Schemes are used to realize Intent. A Resolution Scheme
is identified by its "Mapping Community" and contains an ordered list is identified by its "Mapping Community" and contains an ordered list
of transport classes. Overlay routes carry an indication of the of Transport Classes. Overlay routes carry an indication of the
desired Intent using a BGP community, which assumes the role of desired Intent using a BGP community, which assumes the role of
"Mapping Community". "Mapping Community".
Egress SN "PE11" advertises service routes with desired Mapping Egress SN "PE11" advertises service routes with desired Mapping
Community, e.g., color:0:100. Community, e.g., color:0:100.
For the Intra-AS case, SN1 maps this intra-AS route on RSVP-TE 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 tunnels with TC ID 100 by using the Resolution Scheme for
color:0:100. color:0:100.
For the Inter-AS case, the underlay route in a TRDB is advertised in 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 BGP to extend an underlay tunnel to adjacent domains. A new BGP
transport family called "BGP Classful Transport", also known as BGP 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 CT (AFI/SAFIs 1/76, 2/76), is defined for this purpose. BGP CT makes
it possible to advertise multiple tunnels to the same destination it possible to advertise multiple tunnels to the same destination
address, thus avoiding the need for multiple loopbacks on the eSN. address, thus avoiding the need for multiple loopbacks on the eSN.
The BGP CT address family carries transport prefixes across tunnel 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" (AFI/SAFIs 1/4 or 2/4). It disseminates "Transport Class"
information for the transport prefixes across the participating information for the transport prefixes across the participating
domains while avoiding the need of per-transport class loopback. domains while avoiding the need of per-TC loopback. This is not
This is not possible with BGP LU without using per-color loopback. possible with BGP LU without using per-color loopback. This
This dissemination makes the end-to-end network a "Transport Class" dissemination makes the end-to-end network a "Transport Class" aware
aware tunneled network. tunneled network.
In Figure 1, BGP CT routes are originated at BN11 in AS1 with NH In Figure 1, BGP CT routes are originated at BN11 in AS1 with NH
"self" towards BN21 in AS2 to extend available RSVP-TE tunnels for "self" towards BN21 in AS2 to extend available RSVP-TE tunnels for
Transport Classes 100 and 200 in AS1. BN21 propagates these routes Transport Classes 100 and 200 in AS1. BN21 propagates these routes
with NH "self" to PE21, which resolves the BGP CT routes over SRTE with NH "self" to PE21, which resolves the BGP CT routes over SRTE
tunnels belonging to same transport class, thus forming a BGP CT tunnels belonging to same Transport Class, thus forming a BGP CT
tunnel for each TC ID at PE21. tunnel for each TC ID at PE21.
PE21 maps the Inter-AS service routes received with color:0:100 from 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 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 for color:0:100. Note that this procedure is same as that followed
by SN1 in the Intra-AS case. by SN1 in the intra-AS case.
The following text illustrates how CT architecture provides tiered The following text illustrates how CT architecture provides tiered
fallback options at a per-route granularity. Figure 1 shows the fallback options at a per-route granularity. Figure 1 shows the
Resolution Schemes in use, which make the following NH resolution Resolution Schemes in use, which make the following NH resolution
happen at SN11 (Intra-AS) and PE21 (Inter-AS) for the service routes happen at SN11 (intra-AS) and PE21 (inter-AS) for the service routes
of prefixes IP1, IP2, and IP3: of prefixes IP1, IP2, and IP3:
* Resolve IP1 NH over available tunnels in TRDB for Transport Class * Resolve IP1 NH over available tunnels in TRDB for Transport Class
100 with fallback to TRDB for best effort. 100 with fallback to TRDB for best effort.
* Resolve IP2 NH over available tunnels in TRDB for Transport Class * Resolve IP2 NH over available tunnels in TRDB for Transport Class
200 with fallback to TRDB for best effort. 200 with fallback to TRDB for best effort.
* Resolve IP3 NH over available tunnels in TRDB for Transport Class * Resolve IP3 NH over available tunnels in TRDB for Transport Class
100 with fallback to TRDB for Transport Class 200. 100 with fallback to TRDB for Transport Class 200.
skipping to change at line 619 skipping to change at line 619
attributes. Creation of a Transport Class instantiates its attributes. Creation of a Transport Class instantiates its
corresponding TRDB and Resolution Schemes on that node. corresponding TRDB and Resolution Schemes on that node.
All nodes within a domain agree on a common Transport Class ID All nodes within a domain agree on a common Transport Class ID
namespace. However, two cooperating domains may not always agree on namespace. However, two cooperating domains may not always agree on
the same namespace. Procedures to manage differences in Transport the same namespace. Procedures to manage differences in Transport
Class ID namespaces between cooperating domains are specified in Class ID namespaces between cooperating domains are specified in
Section 11.2.2. Section 11.2.2.
Transport Class ID conveys the Color of tunnels in a Transport Class. Transport Class ID conveys the Color of tunnels in a Transport Class.
The terms "Transport Class ID" and "Color" are used interchangeably The terms 'Transport Class ID' and 'Color' are used interchangeably
in this document. in this document.
4.1. Classifying TE Tunnels 4.1. Classifying TE Tunnels
TE tunnels can be classified into a Transport Class based on the TE 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 tunneling protocols exist, their TE attributes and characteristics
may not be equal but sufficiently similar. Some examples of such may not be equal but sufficiently similar. Some examples of such
classifications are as follows: classifications are as follows:
* Tunnels (RSVP-TE, IGP FLEX-ALGO, SR-TE) that support latency * Tunnels (RSVP-TE, IGP Flex-Algo, SR-TE) that support latency
sensitive routing. sensitive routing.
* RSVP-TE tunnels that only go over admin-group with Green links. * RSVP-TE tunnels that only go over admin-group with Green links.
* Tunnels (RSVP-TE, SR-TE) that offer FRR. * Tunnels (RSVP-TE, SR-TE) that offer FRR.
* Tunnels (RSVP-TE, SR-TE) that share resources in the network based * Tunnels (RSVP-TE, SR-TE) that share resources in the network based
on Shared Risk Link Groups defined by TE policy. on Shared Risk Link Groups defined by TE policy.
* Tunnels (RSVP-TE, SR-TE, BGP CT) that avoid certain nodes in the * Tunnels (RSVP-TE, SR-TE, BGP CT) that avoid certain nodes in the
skipping to change at line 655 skipping to change at line 655
An operator may configure an SN/BN to classify a tunnel into an 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 Transport Class aware is implementation specific and outside the
scope of this document. scope of this document.
When a tunnel is made Transport Class aware, it causes the Tunnel 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 Class. These routes are used to resolve overlay routes, including
BGP CT. The BGP CT routes may be further readvertised to adjacent BGP CT. The BGP CT routes may be further readvertised to adjacent
domains to extend these tunnels. While readvertising BGP CT routes, domains to extend these tunnels. While readvertising BGP CT routes,
the "Transport Class" identifier is encoded as part of the Transport the "Transport Class ID" is encoded as part of the Transport Class
Class RT, which is a new Route Target extended community defined in RT, which is a new Route Target extended community defined in
Section 4.3. Section 4.3.
An SN/BN receiving the transport routes via BGP with sufficient An 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 with the corresponding Transport Class. For those tunnel routes with the corresponding Transport Class. For
example, in BGP CT family routes, the Transport Class RT indicates example, in BGP CT family routes, the Transport Class RT indicates
the Transport Class. For BGP LU family routes, import processing the Transport Class. For BGP LU family routes, import processing
based on communities or Inter-AS source-peer may be used to place the based on communities or inter-AS source-peer may be used to place the
route in the desired Transport Class. route in the desired Transport Class.
When the tunnel route is received via [RFC9830] with "Color:Endpoint" When the tunnel route is received via [RFC9830] with "Color:Endpoint"
as the NLRI that encodes the Transport Class as an integer 'Color' in as the NLRI that encodes the Transport Class as an integer 'Color' in
its Policy Color field, the 'Color' is mapped to a Transport Class its Policy Color field, the 'Color' is mapped to a Transport Class
during the import processing. The SRTE tunnel route for this during the import processing. The SRTE tunnel route for this
'Endpoint' is installed in the corresponding TRDB. The SRTE tunnel 'Endpoint' is installed in the corresponding TRDB. The SRTE tunnel
will be extended by a BGP CT advertisement with NLRI 'RD:Endpoint', will be extended by a BGP CT advertisement with NLRI RD:EP, Transport
Transport Class RT, and a new label. The MPLS swap route thus Class RT, and a new label. The MPLS swap route thus installed for
installed for the new label will pop the label and forward the the new label will pop the label and forward the decapsulated traffic
decapsulated traffic into the path determined by the SRTE route for into the path determined by the SRTE route for further encapsulation.
further encapsulation.
[PCEP-SRPOLICY] extends the Path Computation Element Communication [PCEP-SRPOLICY] extends the Path Computation Element Communication
Protocol (PCEP) to signal attributes of an SR Policy that include Protocol (PCEP) to signal attributes of an SR Policy that include
Color. This Color is mapped to a Transport Class thus associating Color. This Color is mapped to a Transport Class thus associating
the SR Policy with the desired Transport Class. the SR Policy with the desired Transport Class.
Similarly, [PCEP-RSVP-COLOR] extends PCEP to carry the Color Similarly, [PCEP-RSVP-COLOR] extends PCEP to carry the Color
attribute for its use with RSVP-TE LSPs. This Color is mapped to a attribute for its use with RSVP-TE LSPs. This Color is mapped to a
Transport Class thus associating the RSVP-TE LSP with the desired Transport Class thus associating the RSVP-TE LSP with the desired
Transport Class. Transport Class.
skipping to change at line 706 skipping to change at line 705
representing the core transport region. representing the core transport region.
An implementation may realize the TRDB as a "Routing Table" referred An implementation may realize the TRDB as a "Routing Table" referred
to in Section 9.1.2.1 of [RFC4271], which is used only for resolving to in Section 9.1.2.1 of [RFC4271], which is used only for resolving
NH reachability in the control plane. An implementation may choose a NH reachability in the 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 adhering to the procedures defined in this document. The tunnel
routes in a TRDB require no footprint in the forwarding plane unless routes in a TRDB require no footprint in the forwarding plane unless
they are used to resolve an NH. they are used to resolve an NH.
SNs or BNs originate routes for the "Classful Transport" address SNs or BNs originate routes for the BGP CT address family from the
family from the TRDB. These routes have "RD:Endpoint" in the NLRI, TRDB. These routes have RD:EP in the NLRI, carry a Transport Class
carry a Transport Class RT, and an MPLS label or equivalent RT, and an MPLS label or equivalent identifier in different
identifier in different forwarding architecture. "Classful forwarding architecture. BGP CT family routes received with
Transport" family routes received with Transport Class RT are Transport Class RT are installed into their respective TRDB.
installed into their respective TRDB.
4.3. "Transport Class" Route Target Extended Community 4.3. Transport Class Route Target
This section defines a new type of Route Target called a "Transport This section defines a new type of Route Target called a "Transport
Class" Route Target extended community (also known as a "Transport Class Route Target extended community" (also known as a "Transport
Target"). The procedures for use of this extended community with BGP Class RT"). The procedures for use of this extended community with
CT routes (AFI/SAFI: 1/76 or 2/76) are described below. BGP CT routes (AFI/SAFI: 1/76 or 2/76) are described below.
The "Transport Class" Route Target extended community is a transitive The Transport Class RT is a transitive extended community [RFC4360]
extended community [RFC4360] of extended type, which has the format of extended type, which has the format as shown in Figure 2.
as shown in Figure 2.
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: "Transport Class" Route Target Extended Community Figure 2: Transport Class RT
Type: A 1-octet field that MUST be set to 0xa to indicate 'Transport Type: A 1-octet field that MUST be set to 0xa to indicate 'Transport
Class'. Class'.
SubType: A 1-octet field that MUST be set to 0x2 to indicate 'Route SubType: A 1-octet field that MUST be set to 0x2 to indicate 'Route
Target'. Target'.
Reserved: A 2-octet reserved bits field. Reserved: A 2-octet reserved bits field.
This field MUST be set to zero on transmission. This field MUST be set to zero on transmission.
This field SHOULD be ignored on reception and MUST be left This field SHOULD be ignored on reception and MUST be left
unaltered. unaltered.
Transport Class ID: This field is encoded in 4 octets. Transport Class ID: This field is encoded in 4 octets.
This field contains the "Transport Class" identifier, which is an This field contains the "Transport Class ID", which is an unsigned
unsigned 32-bit integer. 32-bit integer.
This document reserves the Transport class ID value 0 to represent This document reserves the Transport Class ID value 0 to represent
the "Best-Effort Transport Class ID". the "Best-Effort Transport Class ID".
A "Transport Class" Route Target extended community with TC ID 100 is A Transport Class RT with TC ID 100 is denoted as "transport-
denoted as "transport-target:0:100". target:0:100".
The VPN route import/export mechanisms specified in BGP/MPLS IP VPNs The VPN route import/export mechanisms specified in BGP/MPLS IP VPNs
(see [RFC4364]) and the Constrained Route Distribution mechanisms (see [RFC4364]) and the Constrained Route Distribution mechanisms
specified in Route Target Constrain (see [RFC4684]) are applied using specified in Route Target Constraint (see [RFC4684]) are applied
the Route Target extended community. These mechanisms are applied to using the Route Target extended community. These mechanisms are
BGP CT routes (AFI/SAFI: 1/76 or 2/76) using the "Transport Class applied to BGP CT routes (AFI/SAFI: 1/76 or 2/76) using the Transport
Route Target extended community". Class RT".
A BGP speaker that implements procedures described in this document A BGP speaker that implements procedures described in this document
and [RFC4684] MUST also apply the RTC procedures to the Transport and [RFC4684] MUST also apply the RTC procedures to the Transport
Class Route Target extended communities carried on BGP CT routes Class RT carried on BGP CT routes (AFI/SAFI: 1/76 or 2/76). An RTC
(AFI/SAFI: 1/76 or 2/76). An RTC route is generated for each Route route is generated for each Route Target imported by locally
Target imported by locally provisioned Transport Classes. provisioned Transport Classes.
Further, when processing RT membership NLRIs containing a Transport Further, when processing RT membership NLRIs containing a Transport
Class Route Target extended community received from external BGP Class RT received from external BGP peers, it is necessary to
peers, it is necessary to consider multiple External BGP (EBGP) paths consider multiple External BGP (EBGP) paths for a given RTC prefix
for a given RTC prefix for building the outbound route filter: not for building the outbound route filter: not just the best path. An
just the best path. An implementation MAY provide configuration to implementation MAY provide configuration to control how many EBGP RTC
control how many EBGP RTC paths are considered. paths are considered.
The Transport Class Route Target extended community is carried on BGP The Transport Class RT is carried on BGP CT family routes and is used
CT family routes and is used to associate them with appropriate TRDBs to associate them with appropriate TRDBs at receiving BGP speakers.
at receiving BGP speakers. The Transport Target is carried unaltered The Transport Class RT is carried unaltered on the BGP CT route
on the BGP CT route across BGP CT negotiated sessions except for across BGP CT negotiated sessions except for scenarios described in
scenarios described in Section 11.2.2. Implementations should Section 11.2.2. Implementations should provide policy mechanisms to
provide policy mechanisms to perform match, strip, or rewrite perform match, strip, or rewrite operations on a Transport Class RT
operations on a Transport Target just like any other BGP community. just like any other BGP community.
Defining a new type code for the Transport Class Route Target Defining a new type code for the Transport Class RT avoids
extended community avoids conflicting with any VPN Route Target conflicting with any VPN Route Target assignments already in use for
assignments already in use for service families. service families.
This document also reserves the Non-Transitive version of the This document also reserves the non-transitive version of the
Transport Class extended community (see Section 13.2.1.1.2) for Transport Class RT (see Section 13.2.1.1.2) for future use. The non-
future use. The "Non-Transitive Transport Class" Route Target transitive Transport Class RT is not used. If received, it is
extended community is not used. If received, it is considered considered equivalent in functionality to the transitive Transport
equivalent in functionality to the Transitive Transport Class Route Class RT, except for the difference in Transitive bit flag.
Target extended community, except for the difference in Transitive
bit flag.
5. Resolution Scheme 5. Resolution Scheme
A Resolution Scheme is a construct that consists of a specific TRDB 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. Community in the route.
Resolution Schemes enable a BGP speaker to resolve NH reachability Resolution Schemes enable a BGP speaker to resolve NH reachability
for overlay routes over the appropriate underlay tunnels within the for overlay routes over the appropriate underlay tunnels within the
scope of the TRDBs. Longest Prefix Match (LPM) of the NH is scope of the TRDBs. Longest Prefix Match (LPM) of the NH is
performed within the identified TRDB. performed within the identified TRDB.
An implementation may provide an option for the overlay route to 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. over a primary Transport Class fail.
To accomplish this, the "Resolution Scheme" is configured with the 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 Classes. Two Resolution Schemes are considered equivalent in Intent
if they consist of the same ordered set of TRDBs. if they consist of the same ordered set of TRDBs.
Operators must ensure that Resolution Schemes for a mapping community Operators must ensure that Resolution Schemes for a Mapping Community
are provisioned consistently on various nodes participating in a BGP are provisioned consistently on various nodes participating in a BGP
CT network based on desired Intent and transport classes available in CT network based on desired Intent and Transport Classes available in
that domain. that domain.
5.1. Mapping Community 5.1. Mapping Community
A "Mapping Community" is used to signal the desired Intent on an 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
NH. NH.
A Mapping Community is a "role" and not a new type of community; any A Mapping Community is a "role" and not a new type of community; any
BGP Community Carrying Attribute (e.g., Community or Extended BGP Community Carrying Attribute (e.g., Community or Extended
Community) may play this role in addition to the other roles it may Community) may play this role in addition to the other roles it may
already be playing. For example, the Transport Class Route Target already be playing. For example, the Transport Class RT plays a dual
extended community plays a dual role: as Route Target and a Mapping role: as Route Target and a Mapping Community.
Community.
Operator provisioning ensures that the ingress and egress SNs agree 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. Community.
A Mapping Community maps to exactly one Resolution Scheme at a A Mapping Community maps to exactly one Resolution Scheme at a
receiving BGP speaker. An implementation SHOULD allow the receiving BGP speaker. An implementation SHOULD allow the
association of multiple Mapping Communities to a Resolution Scheme. association of multiple Mapping Communities to a Resolution Scheme.
This helps with renumbering and migration scenarios. This helps with renumbering and migration scenarios.
An example of a mapping community is "color:0:100", described in An example of a Mapping Community is a Color extended community
[RFC9012], or the "transport-target:0:100" described in Section 4.3. "color:0:100", described in [RFC9012], or the "transport-
target:0:100" described in Section 4.3.
The first community on the overlay route that matches a Mapping 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 effective Mapping Community for the route. The Resolution Scheme
thus found is used when resolving the route's PNH. If a route thus found is used when resolving the route's PNH. If a route
contains more than one Mapping Community, it indicates that the route contains more than one Mapping Community, it indicates that the route
considers these distinct Mapping Communities as equivalent in Intent. considers these distinct Mapping Communities as equivalent in Intent.
If more than one distinct Mapping Community on an overlay route map On an overlay route, if more than one Mapping Community exists that
to distinct Resolution Schemes with dissimilar Intents at a receiving map to distinct Resolution Schemes having dissimilar Intents at a
node, it is considered a configuration error. receiving node, it is considered a configuration error.
Since a route can carry multiple communities, but only a single 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 in to a route will map to the desired Resolution Scheme at each point in
the network. the network.
It should be noted that the Mapping Community role does not require It should be noted that the Mapping Community role does not require
applying Route Target Constrain procedures specified in [RFC4684]. applying Route Target Constraint procedures specified in [RFC4684].
6. BGP Classful Transport Family 6. BGP Classful Transport Family
The BGP Classful Transport (BGP CT) family uses the existing Address 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. Transport" that applies to both IPv4 and IPv6 AFIs.
The AFI/SAFI 1/76 MUST be negotiated as per the Multiprotocol The AFI/SAFI 1/76 MUST be negotiated as per the Multiprotocol
Extensions capability described in Section 8 of [RFC4760] to be able Extensions capability described in Section 8 of [RFC4760] to be able
to send and receive BGP CT routes for IPv4 endpoint prefixes. to send and receive BGP CT routes for IPv4 endpoint prefixes.
The AFI/SAFI 2/76 MUST be negotiated as per the Multiprotocol The AFI/SAFI 2/76 MUST be negotiated as per the Multiprotocol
Extensions capability described in Section 8 of [RFC4760] to be able Extensions capability described in Section 8 of [RFC4760] to be able
to send and receive BGP CT routes for IPv6 endpoint prefixes. to send and receive BGP CT routes for IPv6 endpoint prefixes.
6.1. NLRI Encoding 6.1. NLRI Encoding
The "Classful Transport" SAFI NLRI has the same encoding as specified The "Classful Transport" SAFI NLRI has the same encoding as specified
in Section 2 of [RFC8277]. in Section 2 of [RFC8277].
When the AFI/SAFI is 1/76, the Classful Transport NLRI Prefix When the AFI/SAFI is 1/76, the BGP CT NLRI Prefix consists of an
consists of an 8-byte RD followed by an IPv4 prefix. When AFI/SAFI 8-byte RD followed by an IPv4 prefix. When AFI/SAFI is 2/76, the BGP
is 2/76, the Classful Transport NLRI Prefix consists of an 8-byte RD CT NLRI Prefix consists of an 8-byte RD followed by an IPv6 prefix.
followed by an IPv6 prefix.
The procedures described for AFI/SAFIs 1/4 or 1/128 in Section 2 of The procedures described for AFI/SAFIs 1/4 or 1/128 in Section 2 of
[RFC8277] apply for AFI/SAFI 1/76 also. The procedures described for [RFC8277] apply for AFI/SAFI 1/76 also. The procedures described for
AFI/SAFIs 2/4 or 2/128 in Section 2 of [RFC8277] apply for AFI/SAFI AFI/SAFIs 2/4 or 2/128 in Section 2 of [RFC8277] apply for AFI/SAFI
2/76 also. 2/76 also.
BGP CT routes MAY carry multiple labels in the NLRI by negotiating BGP CT routes MAY carry multiple labels in the NLRI by negotiating
the Multiple Labels Capability as described in Section 2.1 of the Multiple Labels Capability as described in Section 2.1 of
[RFC8277]. [RFC8277].
Properties received on a Classful Transport route include the Properties received on a BGP CT route include the Transport Class RT,
Transport Class Route Target extended community, which is used to which is used to associate the route with the correct TRDBs on SNs
associate the route with the correct TRDBs on SNs and BNs in the and BNs in the network, and either an IPv4 or an IPv6 NH.
network, and either an IPv4 or an IPv6 NH.
6.2. Next Hop Encoding 6.2. Next Hop Encoding
When the length of the Next hop Address field is 4, the next hop When the length of the Next hop Address field is 4, the next hop
address is an IPv4 address. address is an IPv4 address.
When the length of the Next hop Address field is 16 (or 32), the next When the length of the Next hop Address field is 16 (or 32), the next
hop address is an IPv6 address (potentially followed by the link- hop address is an IPv6 address (potentially followed by the link-
local IPv6 address of the next hop). This follows Section 3 of local IPv6 address of the next hop). This follows Section 3 of
[RFC2545]. [RFC2545].
skipping to change at line 930 skipping to change at line 923
followed by the link-local VPN-IPv6 address of the next hop with an 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 of [RFC4659]. 8-octet RD set to zero). This follows Section 3.2.1.1 of [RFC4659].
When the length of the Next hop Address field is 12, the next hop When the length of the Next hop Address field is 12, the next hop
address is a VPN-IPv4 with 8-octet RD set to zero. address is a VPN-IPv4 with 8-octet RD set to zero.
If the length of the Next hop Address field contains any other If the length of the Next hop Address field contains any other
values, it is considered an error and is handled via BGP session values, it is considered an error and is handled via BGP session
reset as per Section 7.11 of [RFC7606]. reset as per Section 7.11 of [RFC7606].
6.3. Carrying Multiple Encapsulation Information 6.3. Carrying Multiple Types of Encapsulation Information
To ease interoperability between nodes supporting different 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. types of encapsulation information.
An MPLS Label is carried using the encoding in [RFC8277]. A node An MPLS label is carried using the encoding in [RFC8277]. A node
that does not support MPLS forwarding advertises the special label 3 that does not support MPLS forwarding advertises the special label 3
(Implicit NULL) in the MPLS Label field (see [RFC8277]). The (Implicit NULL) in the MPLS label field (see [RFC8277]). The
Implicit NULL label carried in BGP CT route indicates to a receiving Implicit NULL label carried in BGP CT route indicates to a receiving
node that it should not impose any BGP CT label for this route. node that it should not impose any BGP CT label for this route.
The SID information for SR with respect to the MPLS data plane is The SID information for SR with respect to the MPLS data plane is
carried as specified in the Prefix SID attribute defined as part of carried as specified in the Prefix-SID attribute defined as part of
Section 3 of [RFC8669]. Section 3 of [RFC8669].
The SID information for SR with respect to SRv6 data plane is carried The SID information for SR with respect to SRv6 data plane is carried
as specified in Section 7.13. as specified in Section 7.13.
UDP tunneling information is carried using the Tunnel Encapsulation UDP tunneling information is carried using the Tunnel Encapsulation
Attribute as specified in [RFC9012]. Attribute as specified in [RFC9012].
6.4. Comparison with Other Families Using Encoding from RFC 8277 6.4. Comparison with Other Families Using Encoding from RFC 8277
AFI/SAFI 1/128 (MPLS-labeled VPN address) is a family encoded using AFI/SAFI 1/128 (L3VPN) is a family encoded using [RFC8277] that
[RFC8277] that carries service prefixes in the NLRI, where the carries service prefixes in the NLRI, where the prefixes come from
prefixes come from the customer namespaces and are contextualized the customer namespaces and are contextualized into separate user
into separate user virtual service RIBs called VRFs as per [RFC4364]. virtual service RIBs called VRFs as per [RFC4364].
AFI/SAFI 1/4 (BGP LU) is a family encoded using [RFC8277] that AFI/SAFI 1/4 (BGP LU) is a family encoded using [RFC8277] that
carries transport prefixes in the NLRI, where the prefixes come from carries transport prefixes in the NLRI, where the prefixes come from
the provider namespace. the provider namespace.
AFI/SAFI 1/76 (Classful Transport SAFI) is a family encoded using AFI/SAFI 1/76 (BGP CT) is a family encoded using [RFC8277] that
[RFC8277] that carries transport prefixes in the NLRI, where the carries transport prefixes in the NLRI, where the prefixes come from
prefixes come from the provider namespace and are contextualized into the provider namespace and are contextualized into separate TRDB,
separate TRDB, following mechanisms similar to [RFC4364] procedures. following mechanisms similar to [RFC4364] procedures.
It is worth noting that AFI/SAFI 1/128 has been used to carry 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 [RFC4364], where BGP LU/LDP prefixes in CsC defined in Section 10 of [RFC4364], where BGP LU/LDP prefixes in CsC
VRF are advertised in AFI/SAFI 1/128 towards the remote-end client VRF are advertised in AFI/SAFI 1/128 towards the remote-end client
carrier. carrier.
In this document, SAFI 76 (BGP CT) is used instead of reusing SAFI In this document, SAFI 76 (CT) is used instead of reusing SAFI 128
128 (L3VPN) for AFIs 1 or 2 to carry these transport routes because (L3VPN) for AFIs 1 or 2 to carry these transport routes because it is
it is operationally advantageous to segregate transport and service operationally advantageous to segregate transport and service
prefixes into separate address families. For example, such an prefixes into separate address families. For example, such an
approach allows operators to safely enable a "per-prefix" label- approach allows operators to safely enable a "per-prefix" label-
allocation scheme for Classful Transport prefixes, typically with a allocation scheme for BGP CT prefixes, typically with a number of
number of routes in the hundreds of thousands or less, without routes in the hundreds of thousands or less, without affecting SAFI
affecting SAFI 128 service prefixes, which may represent millions of 128 service prefixes, which may represent millions of routes at the
routes at the time of writing. The "per-prefix" label-allocation time of writing. The "per-prefix" label-allocation scheme localizes
scheme localizes routing churn during topology changes. routing churn during topology changes.
Service routes continue to be carried in their existing AFI/SAFIs 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 ), Virtual Private LAN Service (VPLS) (AFI/ EVPN (AFI/SAFI: 25/70 ), Virtual Private LAN Service (VPLS) (AFI/
SAFI: 25/65), or Internet (AFI/SAFI: 1/1 or 2/1). These service SAFI: 25/65), or Internet (AFI/SAFI: 1/1 or 2/1). These service
routes can resolve over BGP CT (AFI/SAFI: 1/76 or 2/76) transport routes can resolve over BGP CT (AFI/SAFI: 1/76 or 2/76) transport
routes. routes.
A new SAFI 76 for AFI 1 and AFI 2 also facilitates having a different A new SAFI 76 for AFI 1 and AFI 2 also facilitates having a different
distribution path of the transport family routes in a network than distribution path of the transport family routes in a network than
the service route distribution path. Service routes (Inet-VPN SAFI the service route distribution path. Service routes (SAFI 128) are
128) are exchanged over an EBGP multihop session between ASes with exchanged over an EBGP multihop session between ASes with the NH
the NH unchanged; whereas Classful Transport routes (SAFI 76) are unchanged; whereas BGP CT routes (SAFI 76) are advertised over EBGP
advertised over EBGP single-hop sessions with a "NH self" rewrite single-hop sessions with a "NH self" rewrite over inter-AS links.
over inter-AS links.
The BGP CT SAFI 76 for AFI 1 and 2 is conceptually similar to BGP LU 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 is SAFI 4 in that it carries transport prefixes. The only difference is
that it also carries in a Route Target an indication of which 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 message. UPDATE message.
7. Protocol Procedures 7. Protocol Procedures
This section summarizes the procedures followed by various nodes This section summarizes the procedures followed by various nodes
speaking Classful Transport family. speaking BGP CT family.
7.1. Preparing the Network to Deploy Classful Transport Planes 7.1. Preparing the Network to Deploy Classful Transport Planes
It is the responsibility of the operators to decide the Transport It is the responsibility of the operators to decide the Transport
Classes to enable and use in their network. They are also expected Classes to enable and use in their network. They are also expected
to allocate a Transport Class Route Target to identify each Transport to allocate a Transport Class RT to identify each Transport Class.
Class.
Operators configure the Transport Classes on the SNs and BNs in the Operators configure the Transport Classes on the SNs and BNs in the
network with Transport Class Route Targets and appropriate Route network with Transport Class RTs and appropriate Route
Distinguishers. Distinguishers.
Implementations MAY provide automatic generation and assignment of Implementations MAY provide automatic generation and assignment of
RD, RT values. They MAY also provide a way to manually override the RD, RT values. They MAY also provide a way to manually override the
automatic mechanism in order to deal with any conflicts that may automatic mechanism in order to deal with any conflicts that may
arise with existing RD, RT values in different network domains arise with existing RD, RT values in different network domains
participating in the deployment. participating in the deployment.
7.2. Originating Classful Transport Routes 7.2. Originating BGP CT Routes
BGP CT routes are sent only to BGP peers that have negotiated the BGP CT routes are sent only to BGP peers that have negotiated the
Multiprotocol Extensions capability described in Section 8 of Multiprotocol Extensions capability described in Section 8 of
[RFC4760] to be able to send and receive BGP CT routes. [RFC4760] to be able to send and receive BGP CT routes.
At the ingress node of the tunnel's home domain, the tunneling At the ingress node of the tunnel's home domain, the tunneling
protocols install tunnel routes in the TRDB associated with the protocols install tunnel routes in the TRDB associated with the
Transport Class to which the tunnel belongs. Transport Class to which the tunnel belongs.
The egress node of the tunnel, i.e., the tunnel endpoint (EP), The egress node of the tunnel, i.e., the tunnel endpoint (EP),
originates the BGP CT route with RD:EP in the NLRI, a Transport Class originates the BGP CT route with RD:EP in the NLRI, a Transport Class
RT, and a PNH as the EP. This BGP CT route will be resolved over the RT, and the PNH as the EP. This BGP CT route will be resolved over
tunnel route in TRDB at the ingress node. When the tunnel is up, the the tunnel route in TRDB at the ingress node. When the tunnel is up,
Classful Transport BGP route will become usable and get readvertised the Classful Transport BGP route will become usable and get
by the ingress node to BGP peers in neighboring domains. readvertised by the ingress node to BGP peers in neighboring domains.
Alternatively, the ingress node of the tunnel, which is also an ASBR/ 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 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 tunnel destination with RD:EP in the NLRI, attaching a Transport
Class Route Target that identifies the Transport Class. This BGP CT Class Route Target that identifies the Transport Class. This BGP CT
route is advertised to EBGP peers and IBGP peers in neighboring route is advertised to EBGP peers and IBGP peers in neighboring
domains. domains.
This originated route SHOULD NOT be advertised to the IBGP core that This originated route SHOULD NOT be advertised to the IBGP core that
contains the tunnel. This may be implemented by mechanisms such as contains the tunnel. This may be implemented by mechanisms such as
policy configuration. The impact of not prohibiting such policy configuration. The impact of not prohibiting such
advertisements is outside the scope of this document. advertisements is outside the scope of this document.
A unique RD SHOULD be used by the originator of a Classful Transport A unique RD SHOULD be used by the originator of a BGP CT route to
route to disambiguate the multiple BGP advertisements for a transport disambiguate the multiple BGP advertisements for a transport
endpoint. An administrator may use duplicate RDs based on local endpoint. An administrator may use duplicate RDs based on local
choice, understanding the impact on path diversity and choice, understanding the impact on path diversity and
troubleshooting, as described in Section 10.2. troubleshooting, as described in Section 10.2.
7.3. Processing Classful Transport Routes by Ingress Nodes 7.3. Processing BGP CT Routes by Ingress Nodes
Upon receipt of a BGP CT route with a PNH EP that is not directly Upon receipt of a BGP CT route with a PNH EP that is not directly
connected (e.g., an IBGP-route), a Mapping Community (the Transport connected (e.g., an IBGP-route), a Mapping Community (the Transport
Class RT) on the route is used to decide to which resolution scheme Class RT) on the route is used to decide to which Resolution Scheme
this route is to be mapped. this route is to be mapped.
The resolution scheme for a Transport Class RT with Transport Class The Resolution Scheme for a Transport Class RT with Transport Class
ID "C1" contains the TRDB of a Transport Class with same ID. The ID "C1" contains the TRDB of a Transport Class with same ID. The
administrator MAY customize the resolution scheme for Transport Class administrator MAY customize the Resolution Scheme for Transport Class
ID "C1" to map to a different ordered list of TRDBs. If the ID "C1" 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. containing the Best-Effort TRDB is used.
The routes in the TRDBs associated with a selected resolution scheme The routes in the TRDBs associated with a selected Resolution Scheme
are used to resolve the received PNH EP. The order of TRDBs in the are used to resolve the received PNH EP. The order of TRDBs in the
resolution scheme is followed when resolving the received PNH, such Resolution Scheme is followed when resolving the received PNH, such
that a route in a backup TRDB is used only when a matching route was that a route in a backup TRDB is used only when a matching route was
not found for EP in the primary TRDBs preceding it. This achieves not found for EP in the primary TRDBs preceding it. This achieves
the fallback desired by the resolution scheme. the fallback desired by the Resolution Scheme.
If the resolution process does not find a matching route for the EP If the resolution process does not find a matching route for the EP
in any of the associated TRDBs, the received BGP CT route MUST be in any of the associated TRDBs, the received BGP CT route MUST be
considered unresolvable. (See Section 9.1.2.1 of [RFC4271].) considered unresolvable. (See Section 9.1.2.1 of [RFC4271].)
The received BGP CT route MUST be added to the TRDB corresponding to The received BGP CT route MUST be added to the TRDB corresponding to
the Transport Class ID "C1" if the transport class is provisioned the Transport Class ID "C1" if the TC is provisioned locally. This
locally. This step applies only if the Transport Class RT is step applies only if the Transport Class RT is received on a BGP CT
received on a BGP CT family route. The RD in the BGP CT NLRI prefix family route. The RD in the BGP CT NLRI prefix RD:EP is ignored when
RD:EP is ignored when the BGP CT route for EP is added to the TRDB so the BGP CT route for EP is added to the TRDB so that overlay routes
that overlay routes can resolve over this BGP CT tunnel route by can resolve over this BGP CT tunnel route by performing a lookup for
performing a lookup for the EP. Please note that a TRDB is a logical the EP. Please note that a TRDB is a logical database of tunnel
database of tunnel routes belonging to the same Transport Class ID; routes belonging to the same Transport Class ID; hence, it only uses
hence, it only uses the EP as the lookup key (without RD or TC ID). the EP as the lookup key (without RD or TC ID).
If no Mapping Community is found on a BGP CT route, the best-effort If no Mapping Community is found on a BGP CT route, the Best-Effort
resolution scheme is used to resolve the route's next hop, and the Resolution Scheme is used to resolve the route's next hop, and the
BGP CT route is not added to any TRDB. BGP CT route is not added to any TRDB.
7.4. Readvertising Classful Transport Route by Border Nodes 7.4. Readvertising BGP CT Route by Border Nodes
This section describes the MPLS label handling when readvertising a This section describes the MPLS label handling when readvertising a
BGP CT route with "NH self". When readvertising a BGP CT route with BGP CT route with "NH self". When readvertising a BGP CT route with
"NH self", a BN allocates an MPLS label to advertise upstream in the "NH self", a BN allocates an MPLS label to advertise upstream in the
Classful Transport NLRI. The BN also installs an MPLS route for that BGP CT NLRI. The BN also installs an MPLS route for that label that
label that swaps the incoming label with the label received from the swaps the incoming label with the label received from the downstream
downstream BGP speaker (or pops the incoming label if the label BGP speaker (or pops the incoming label if the label received from
received from the downstream BGP speaker was Implicit-NULL). The the downstream BGP speaker was Implicit NULL). The MPLS route then
MPLS route then pushes received traffic to the transport tunnel or pushes received traffic to the transport tunnel or direct interface
direct interface that the Classful Transport route's PNH resolved that the BGP CT route's PNH resolved over.
over.
The label SHOULD be allocated with "per-prefix" label-allocation The label SHOULD be allocated with "per-prefix" label-allocation
semantics. The IP prefix in the TRDB context (Transport-Class, IP- semantics. The IP prefix in the TRDB context (Transport Class, IP
prefix) is used as the key to "per-prefix" label allocation. This prefix) is used as the key to "per-prefix" label allocation. This
helps in avoiding BGP CT route churn throughout the CT network when helps in avoiding BGP CT route churn throughout the CT network when
an instability (e.g., link failure) is experienced in a domain. The an instability (e.g., link failure) is experienced in a domain. The
failure is not propagated further than the BN closest to the failure. failure is not propagated further than the BN closest to the failure.
If a different label-allocation mode is used, the impact on end-to- If a different label-allocation mode is used, the impact on end-to-
end convergence should be considered. end convergence should be considered.
The value of the advertised MPLS label is locally significant and is The value of the advertised MPLS label is locally significant and is
dynamic by default. A BN may provide an option to allocate a value dynamic by default. A BN may provide an option to allocate a value
from a statically provisioned range. This can be achieved using a from a statically provisioned range. This can be achieved using a
locally configured export policy or via mechanisms such as the ones locally configured export policy or via mechanisms such as the ones
described related to BGP Prefix-SID as described in BGP (see described related to BGP Prefix-SID as described in BGP (see
[RFC8669]). [RFC8669]).
7.5. Border Nodes Receiving Classful Transport Routes on EBGP 7.5. Border Nodes Receiving BGP CT Routes on EBGP
If a route is received with a PNH that is known to be directly If a route is received with a PNH that is known to be directly
connected (for example, an EBGP single-hop neighbor address), the 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. the inter-AS link can be used for any Transport Class.
If the inter-AS links need to honor Transport Class, then the BN MUST If the inter-AS links need to honor Transport Class, then the BN MUST
follow the procedures of an Ingress node (Section 7.3) and perform follow the procedures of an ingress node (Section 7.3) and perform
the next hop resolution process. In order to make the link Transport the next hop resolution process. In order to make the link Transport
Class aware, the route to the directly connected PNH is installed in Class aware, the route to the directly connected PNH is installed in
the TRDB belonging to the associated Transport Class. the TRDB belonging to the associated Transport Class.
7.6. Avoiding Path Hiding Through Route Reflectors 7.6. Avoiding Path Hiding Through Route Reflectors
When multiple instances of a given RD:EP exist with different When multiple instances of a given RD:EP exist with different
forwarding characteristics, BGP ADD-PATH (see [RFC7911]) is helpful. forwarding characteristics, BGP ADD-PATH (see [RFC7911]) is helpful.
When multiple BNs exist such that they advertise an "RD:EP" prefix to When multiple BNs exist such that they advertise an "RD:EP" prefix to
Route Reflectors (RRs), the RRs may hide all but one of the BNs, Route Reflectors (RRs), the RRs may hide all but one of the BNs,
unless BGP ADD-PATH (see [RFC7911]) is used for the Classful unless BGP ADD-PATH (see [RFC7911]) is used for the BGP CT family.
Transport family. This is similar to L3VPN Option B scenarios. This is similar to L3VPN inter-AS option B scenarios.
Hence, BGP ADD-PATH (see [RFC7911]) SHOULD be used for the Classful Hence, BGP ADD-PATH (see [RFC7911]) SHOULD be used for the BGP CT
Transport family to avoid path hiding through RRs so that the RR family to avoid path hiding through RRs so that the RR sends multiple
sends multiple CT routes for RD:EP to its clients. This improves the CT routes for RD:EP to its clients. This improves the convergence
convergence time when the path via one of the multiple BNs fails. time when the path via one of the multiple BNs fails.
7.7. Avoiding Loops Between Route Reflectors in Forwarding Paths 7.7. Avoiding Loops Between Route Reflectors in Forwarding Paths
A pair of redundant ABRs, each acting as an RR with the next hop set A pair of redundant ABRs, each acting as an RR with the next hop set
to itself, may choose each other as the best path instead of the to itself, may choose each other as the best path instead of the
upstream ASBR, causing a traffic-forwarding loop. upstream ASBR, causing a traffic-forwarding loop.
This problem can happen for routes of any BGP address family, This problem can happen for routes of any BGP address family,
including BGP CT and BGP LU. including BGP CT and BGP LU.
Using one or more of the approaches described in [BGP-FWD-RR] lowers Using one or more of the approaches described in [BGP-FWD-RR] lowers
the possibility of such loops in a network with redundant ABRs. the possibility of such loops in a network with redundant ABRs.
7.8. Ingress Nodes Receiving Service Routes with a Mapping Community 7.8. Ingress Nodes Receiving Service Routes with a Mapping Community
Upon receipt of a BGP service route (for example, AFI/SAFI: 1/1, 2/1) Upon receipt of a BGP service route (for example, AFI/SAFI: 1/1, 2/1)
with a PNH as the EP that is not directly connected (for example, an with a PNH as the EP that is not directly connected (for example, an
IBGP-route), a Mapping Community (for example, a Color Extended IBGP-route), a Mapping Community (for example, a Color Extended
Community) on the route is used to decide to which resolution scheme Community) on the route is used to decide to which Resolution Scheme
this route is to be mapped. this route is to be mapped.
The resolution scheme for a Color Extended Community with Color "C1" The Resolution Scheme for a Color extended community with Color "C1"
contains a TRDB for a Transport Class with same ID followed by the contains a TRDB for a Transport Class with same ID followed by the
Best-Effort TRDB. The administrator MAY customize the resolution Best-Effort TRDB. The administrator MAY customize the 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. containing the Best-Effort TRDB is used.
If no Mapping Community was found on the overlay route, the "Best If no Mapping Community was found on the overlay route, the "Best
Effort" resolution scheme is used for resolving the route's next hop. Effort Resolution Scheme" is used for resolving the route's next hop.
This behavior is backward compatible to behavior of an implementation This behavior is backward compatible to behavior of an implementation
that does not follow procedures described in this document. that does not follow procedures described in this document.
The routes in the TRDBs associated with the selected resolution The routes in the TRDBs associated with the 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 route such that a route in a backup TRDB is used only when a matching route
was not found for the EP in the primary TRDBs preceding it. This was not found for the EP in the primary TRDBs preceding it. This
achieves the fallback desired by the resolution scheme. achieves the fallback desired by the Resolution Scheme.
If the resolution process does not find a Tunnel Route for the EP in If the resolution process does not find a Tunnel Route for the EP in
any of the Transport Route Databases, the service route MUST be any of the Transport Route Databases, the service route MUST be
considered unresolvable. (See Section 9.1.2.1 of [RFC4271]). considered unresolvable. (See Section 9.1.2.1 of [RFC4271]).
Note: For an illustration of above procedures in an MPLS network, Note: For an illustration of above procedures in an MPLS network,
refer to Section 8. refer to Section 8.
7.9. Best-Effort Transport Class 7.9. Best-Effort Transport Class
It is also possible to represent a 'Best-effort' SLA as a Transport It is also possible to represent a 'Best-Effort' SLA as a Transport
Class. At the time of writing, BGP LU is used to extend the best- Class. At the time of writing, BGP LU is used to extend the best-
effort intra-domain tunnels to other domains. effort intra-domain tunnels to other domains.
Alternatively, BGP CT may also be used to carry the best-effort 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 the "Best-Effort Transport Class ID". However, represent the "Best-Effort Transport Class ID". However,
implementations SHOULD provide configuration to use a different value implementations SHOULD provide configuration to use a different value
for this purpose. Procedures to manage differences in Transport for this purpose. Procedures to manage differences in Transport
Class ID namespaces between domains are provided in Section 11.2.2. Class ID namespaces between domains are provided in Section 11.2.2.
The "Best-Effort Transport Class ID" value is used in the "Transport The "Best-Effort Transport Class ID" value is used in the "Transport
Class ID" field of the Transport Route Target extended community that Class ID" field of the Transport Class RT that is attached to the BGP
is attached to the BGP CT route that advertises a best-effort tunnel CT route that advertises a best-effort tunnel endpoint. Thus, the RT
endpoint. Thus, the RT formed is called the "Best-Effort Transport formed is called the "Best-Effort Transport Class RT".
Class Route Target".
When a BN or SN receives a BGP CT route with Best-Effort Transport When a BN or SN receives a BGP CT route with Best-Effort Transport
Class Route Target as the mapping community, the Best-effort Class RT as the Mapping Community, the Best-Effort Resolution Scheme
resolution scheme is used for resolving the BGP next hop, and the is used for resolving the BGP next hop, and the resultant route is
resultant route is installed in the best-effort transport route installed in the best-effort transport route database. If no best-
database. If no best-effort tunnel was found to resolve the BGP next effort tunnel was found to resolve the BGP next hop, the BGP CT route
hop, the BGP CT route MUST be considered unusable and not be MUST be considered unusable and not be propagated further.
propagated further.
When a BGP speaker receives an overlay route without any explicit 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. document.
Implementations MAY provide configuration to selectively install BGP Implementations MAY provide configuration to selectively install BGP
CT routes to the Forwarding Information Base (FIB) to provide 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. domains.
7.10. Interaction with BGP Attributes Specifying Next Hop Address and 7.10. Interaction with BGP Attributes Specifying Next Hop Address and
Color Color
The Tunnel Encapsulation Attribute, described in [RFC9012], can be The Tunnel Encapsulation Attribute, described in [RFC9012], can be
used to request a specific type of tunnel encapsulation. This used to request a specific type of tunnel encapsulation. This
attribute may apply to BGP service routes or transport routes attribute may apply to BGP service routes or transport routes
including BGP Classful Transport family routes. including BGP CT family routes.
It should be noted that in such cases "Transport Class ID/Color" can 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 exist in multiple places on the same route, and a precedence order
needs to be established to determine which Transport Class the needs to be established to determine which Transport Class the
route's next hop should resolve over. This document specifies the route's next hop should resolve over. This document specifies the
following order of precedence with more-specific scoping of Color following order of precedence with more-specific scoping of Color
preferred to less-specific scoping: preferred to less-specific scoping:
* Color sub-TLV in the Tunnel Encapsulation Attribute. * Color sub-TLV in the Tunnel Encapsulation Attribute.
* Transport Target extended community on a BGP CT route. * Transport Class RT on a BGP CT route.
* Color Extended Community on a BGP service route. * Color extended community on a BGP service route.
Color specified in the Color sub-TLV in a TEA is a more-specific 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, 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). extended community).
Any BGP attributes or mechanisms defined in future that carry 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. order of precedence relative to the above.
7.11. Applicability to Flowspec Redirect-to-IP 7.11. Applicability to Flowspec Redirect-to-IP
Flowspec routes using redirect-to-IP next hop are described in Flowspec routes using redirect-to-IP next hop are described in
[FLOWSPEC-REDIR-IP]. [FLOWSPEC-REDIR-IP].
Such Flowspec BGP routes with redirect-to-IP next hop MAY be attached Such Flowspec BGP routes with redirect-to-IP next hop MAY be attached
with a Mapping Community (e.g., Color:0:100), which allows 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). satisfying the desired SLA (e.g., Transport Class color 100).
The Flowspec BGP family acts as just another service that can make The Flowspec BGP family acts as just another service that can make
use of the BGP CT architecture to achieve flow-based forwarding with use of the BGP CT architecture to achieve flow-based forwarding with
SLAs. SLAs.
7.12. Applicability to IPv6 7.12. Applicability to IPv6
BGP CT procedures apply equally to IPv4- and IPv6-enabled Intra-AS or BGP CT procedures apply equally to IPv4- and IPv6-enabled intra-AS or
Inter-AS Option A, B, and C networks. This section describes the inter-AS option A, B, and C networks. This section describes the
applicability of BGP CT to IPv6 at various layers. applicability of BGP CT to IPv6 at various layers.
A network that is BGP CT enabled supports IPv6 service families (for A network that is BGP CT enabled supports IPv6 service families (for
example, AFI/SAFI 2/1 or 2/128) and IPv6 transport signaling example, AFI/SAFI 2/1 or 2/128) and IPv6 transport signaling
protocols like SRTEv6, LDPv6, or RSVP-TEv6. protocols like SRTEv6, LDPv6, or RSVP-TEv6.
Procedures in this document also apply to a network with Pure IPv6 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. The BGP CTv6 family (AFI/SAFI: 2/76) is used to carry global links. The BGP CTv6 family (AFI/SAFI: 2/76) is used to carry global
IPv6 address tunnel endpoints in the NLRI. Service family routes IPv6 address tunnel endpoints in the NLRI. Service family routes
(for example, AFI/SAFI: 1/1, 2/1, 1/128, and 2/128) are also (for example, AFI/SAFI: 1/1, 2/1, 1/128, and 2/128) are also
advertised with those Global IPv6 addresses as next hop. advertised with those Global IPv6 addresses as next hop.
Procedures in this document also apply to a 6PE network with an IPv4 Procedures in this document also apply to a 6PE network with an IPv4
core, which uses MPLS forwarding for intra-domain tunnels and Inter- core, which uses MPLS forwarding for intra-domain tunnels and inter-
AS links. The BGP CTv6 family (AFI/SAFI: 2/76) is used to carry IPv4 AS links. The BGP CTv6 family (AFI/SAFI: 2/76) is used to carry IPv4
Mapped IPv6 address tunnel endpoints in the NLRI. IPv6 Service Mapped IPv6 address tunnel endpoints in the NLRI. IPv6 Service
family routes (for example, AFI/SAFI: 2/1, 2/128) are also advertised family routes (for example, AFI/SAFI: 2/1, 2/128) are also advertised
with those IPv4 Mapped IPv6 addresses as next hop. with those IPv4 Mapped IPv6 addresses as next hop.
The PE-CE attachment circuits may use IPv4 addresses only, IPv6 The PE-CE attachment circuits may use IPv4 addresses only, IPv6
addresses only, or both IPv4 and IPv6 addresses. addresses only, or both IPv4 and IPv6 addresses.
7.13. SRv6 Support 7.13. SRv6 Support
The BGP CT family (AFI/SAFI 2/76) may be used to set up inter-domain The BGP CT family (AFI/SAFI 2/76) may be used to set up inter-domain
tunnels of a certain Transport Class when using a Segment Routing 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 over IPv6 (SRv6) data plane on the inter-AS links or as an intra-AS
tunneling mechanism. tunneling mechanism.
Details of SRv6 Endpoint behaviors used by BGP CT and the procedures Details of SRv6 Endpoint behaviors used by BGP CT and the procedures
are specified and illustrated in a separate document (see are specified and illustrated in a separate document (see
[BGP-CT-SRv6]). As noted in that document, a BGP CT route update for [BGP-CT-SRv6]). As noted in that document, a BGP CT route update for
SRv6 includes a BGP attribute containing SRv6 SID information (e.g., SRv6 includes a BGP attribute containing SRv6 SID information (e.g.,
a BGP Prefix-SID [RFC9252]) with the Transposition scheme disabled. a BGP Prefix-SID [RFC9252]) with the Transposition Scheme disabled.
7.14. Error-Handling Considerations 7.14. Error-Handling Considerations
If a BGP speaker receives both Transitive and Non-Transitive (see If a BGP speaker receives both transitive and non-transitive (see
Section 13.2.1.1.1 and Section 13.2.1.1.2, respectievely) versions of Section 13.2.1.1.1 and Section 13.2.1.1.2, respectively) versions of
a Transport Class extended community on a route, only the Transitive a Transport Class extended community on a route, only the transitive
one is used. one is used.
If a BGP speaker considers a received "Transport Class" extended If a BGP speaker considers a received "Transport Class" extended
community (the Transitive or Non-Transitive version) or any other community (the transitive or non-transitive version) or any other
part of a BGP CT route invalid for some reason, but is able to part of a BGP CT route invalid for some reason, but is able to
successfully parse the NLRI and attributes, the treat-as-withdraw successfully parse the NLRI and attributes, the treat-as-withdraw
approach from [RFC7606] is used. The route is kept as Unusable, with approach from [RFC7606] is used. The route is kept as Unusable, with
appropriate diagnostic information, to aid troubleshooting. appropriate diagnostic information, to aid troubleshooting.
8. Illustration of BGP CT Procedures 8. Illustration of BGP CT Procedures
This section illustrates BGP CT procedures in an Inter-AS Option C This section illustrates BGP CT procedures in an inter-AS option C
MPLS network. MPLS network.
All illustrations in this document make use of IP address ranges as All illustrations in this document make use of IP address ranges as
described in [RFC6890]. The range 192.0.2.0/24 is used to represent described in [RFC6890]. The range 192.0.2.0/24 is used to represent
transport endpoints like loopback addresses. The range transport endpoints like loopback addresses. The range
203.0.113.0/24 is used to represent service route prefixes advertised 203.0.113.0/24 is used to represent service route prefixes advertised
in AFI/SAFIs: 1/1 or 1/128. in AFI/SAFIs: 1/1 or 1/128.
Though this section illustrates the use of IPv4, as described in Though this section illustrates the use of IPv4, as described in
Section 7.12, these procedures work equally for IPv6 as well. Section 7.12, these procedures work equally for IPv6 as well.
8.1. Reference Topology 8.1. Reference Topology
[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
Figure 3: Multi-Domain BGP CT Network Figure 3: Multi-Domain BGP CT Network
This example shows a provider MPLS network that consists of two ASes, This example shows a provider MPLS network that consists of two ASes,
AS1 and AS2, that serve customers AS3 and AS4, respectively. The AS1 and AS2, that serve customers AS3 and AS4, respectively. The
traffic direction being described is from CE41 to CE31. CE31 may traffic direction being described is from CE41 to CE31. CE31 may
request a specific SLA (mapped to Gold for this example), when request a specific SLA (mapped to Gold for this example), when
traversing these provider networks. traversing these provider networks.
AS2 is further divided into two regions. There are three tunnel AS2 is further divided into two regions. There are three tunnel
domains in the provider's space: domains in the provider's space:
skipping to change at line 1423 skipping to change at line 1411
The following tunnels exist for Bronze Transport Class: The following tunnels exist for Bronze Transport Class:
* PE25_to_ABR23_bronze - RSVP-TE tunnel * PE25_to_ABR23_bronze - RSVP-TE tunnel
* ABR23_to_ASBR21_bronze - RSVP-TE tunnel * ABR23_to_ASBR21_bronze - RSVP-TE tunnel
* ABR23_to_ASBR22_bronze - RSVP-TE tunnel * ABR23_to_ASBR22_bronze - RSVP-TE tunnel
* ABR24_to_ASBR21_bronze - RSVP-TE tunnel * ABR24_to_ASBR21_bronze - RSVP-TE tunnel
* ASBR13_to_PE12_bronze - ISIS FlexAlgo tunnel * ASBR13_to_PE12_bronze - ISIS Flex-Algo tunnel
* ASBR14_to_PE11_bronze - ISIS FlexAlgo tunnel * ASBR14_to_PE11_bronze - ISIS Flex-Algo tunnel
These tunnels are either provisioned or autodiscovered to belong to These tunnels are either provisioned or autodiscovered to belong to
Transport Class IDs 100 or 200. Transport Class IDs 100 or 200.
8.2. Service-Layer Route Exchange 8.2. Service Layer Route Exchange
Service nodes PE11 and PE12 negotiate service families (AFI: 1 and Service nodes PE11 and PE12 negotiate service families (AFI/SAFIs:
SAFIs 1, 128) on the BGP session with RR16. Service helpers RR16 and 1/1 and 1/128) on the BGP session with RR16. Service helpers RR16
RR26 exchange these service routes with the next hop unchanged over a and RR26 exchange these service routes with the next hop unchanged
multihop EBGP session between the two ASes. PE25 negotiates service over a multihop EBGP session between the two ASes. PE25 negotiates
families (AFI: 1 and SAFIs 1, 128) with RR26. service families (AFI/SAFIs: 1/1 and 1/128) with RR26.
The PEs see each other as the next hop in the BGP UPDATE message for The PEs see each other as the next hop in the BGP UPDATE message for
the service family routes. BGP ADD-PATH send and receive are enabled the service family routes. BGP ADD-PATH send and receive are enabled
on both directions on the EBGP multihop session between RR16 and RR26 on 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 for 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 the path-hiding RR to PE direction in each AS. This is to avoid the path-hiding
service routes at the RR, i.e., AFI/SAFI 1/1 routes advertised by service 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 both PE11 and PE12 or AFI/SAFI 1/128 routes originated by both PE11
and PE12 using the same RD. and PE12 using the same RD.
Forwarding happens using service routes installed at service nodes Forwarding happens using service routes installed at service nodes
PE25, PE11, and 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. present in any other nodes' FIB in the network.
As an example, CE31 advertises a route for prefix 203.0.113.31 with As an example, CE31 advertises a route for prefix 203.0.113.31 with
the next hop as itself to PE11 and PE12. CE31 can attach a Mapping the next hop as itself to PE11 and PE12. CE31 can attach a Mapping
Community Color:0:100 on this route to indicate its request for a Community color:0:100 on this route to indicate its request for a
Gold SLA. Or, PE11 can attach the same using locally configured Gold SLA. Or, PE11 can attach the same using locally configured
policies. policies.
Consider CE31 getting VPN service from PE11. The RD1:203.0.113.31 Consider CE31 getting VPN service from PE11. The RD1:203.0.113.31
route is readvertised in AFI/SAFI 1/128 by PE11 with the next hop set route is readvertised in AFI/SAFI 1/128 by PE11 with the next hop set
to itself (192.0.2.11) and label V-L1 to RR16 with the Mapping to itself (192.0.2.11) and label V-L1 to RR16 with the Mapping
Community Color:0:100 attached. RR16 advertises this route with the 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 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 hop unchanged. Now, PE25 can resolve the PNH 192.0.2.11 using
transport routes received in BGP CT or BGP LU. transport routes received in BGP CT or BGP LU.
Using BGP ADD-PATH, service routes advertised by PE11 and PE12 for 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. unchanged, as PE11 or PE12.
The IP FIB at the PE25 VRF will have a route for 203.0.113.31 with a The IP FIB at the 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 the ingress
domain. domain.
8.3. Transport-Layer Route Propagation 8.3. Transport Layer Route Propagation
Egress nodes PE11 and PE12 negotiate a BGP CT family with transport Egress nodes PE11 and PE12 negotiate a BGP CT family with transport
ASBRs ASBR13 and ASBR14. These egress nodes originate BGP CT routes ASBRs ASBR13 and ASBR14. These egress nodes originate BGP CT routes
for tunnel endpoint addresses that are advertised as a next hop in for tunnel endpoint addresses that are advertised as a next hop in
BGP service routes. In this example, both PEs participate in BGP service routes. In this example, both PEs participate in
transport classes Gold and Bronze. The protocol procedures are Transport Classes Gold and Bronze. The protocol procedures are
explained using the Gold SLA transport plane; the Bronze SLA explained using the Gold SLA transport plane; the Bronze SLA
transport plane is used to highlight the path-hiding aspects. transport plane is used to highlight the path-hiding aspects.
For Gold tunnels, PE11 is provisioned with transport class 100, RD For Gold tunnels, PE11 is provisioned with Transport Class having TC
value 192.0.2.11:100, and a transport-target:0:100. For Bronze ID 100, RD value 192.0.2.11:100, and a transport-target:0:100. For
tunnels, PE11 is provisioned with Transport class 200, RD value Bronze tunnels, PE11 is provisioned with Transport Class 200, RD
192.0.2.11:200, and transport route target 0:200. Similarly, for value 192.0.2.11:200, and transport-target:0:200. Similarly, for
Gold tunnels, PE12 is provisioned with transport class 100, RD value Gold tunnels, PE12 is provisioned with Transport Class having TC ID
192.0.2.12:100, and a transport-target:0:100. For Bronze tunnels, 100, RD value 192.0.2.12:100, and a transport-target:0:100. For
PE12 is provisioned with transport class 200, RD value Bronze tunnels, PE12 is provisioned with Transport Class having TC ID
192.0.2.12:200, and transport-target:0:200. Note that, in this 200, RD value 192.0.2.12:200, and transport-target:0:200. Note that,
example, the BGP CT routes carry only the transport class route in this example, the BGP CT routes carry only the Transport Class RT
target and no IP address format route target. and no IP address format route target.
The RD value originated by an egress node is not modified by any BGP 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, 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). or set of originators (RD reused on multiple nodes).
Similarly, these transport classes are also configured on ASBRs, Similarly, these Transport Classes are also configured on ASBRs,
ABRs, and PEs with same Transport Route Target and unique RDs. ABRs, and PEs with same Transport Class RT and unique RDs.
ASBR13 and ASBR14 negotiate BGP CT family with transport ASBRs ASBR21 ASBR13 and ASBR14 negotiate BGP CT family with transport ASBRs ASBR21
and ASBR22 in neighboring ASes. ASBR21 and ASBR22 negotiate BGP CT and ASBR22 in neighboring ASes. ASBR21 and ASBR22 negotiate BGP CT
family with RR27 in region 2, which reflects BGP CT routes to ABR23 family with RR27 in region 2, which reflects BGP CT routes to ABR23
and ABR24. ABR23 and ABR24 negotiate BGP CT family with Ingress node and ABR24. ABR23 and ABR24 negotiate BGP CT family with ingress node
PE25 in region 1. The BGP LU family is also negotiated on these PE25 in region 1. The BGP LU family is also negotiated on these
sessions alongside the BGP CT family. The BGP LU family carries sessions alongside the BGP CT family. The BGP LU family carries
"best-effort" transport class routes; BGP CT carries Gold and Bronze Best-Effort Transport Class routes; BGP CT carries Gold and Bronze
transport class routes. Transport Class routes.
PE11 is provisioned to originate a BGP CT route for endpoint PE11, PE11 is provisioned to originate a BGP CT route for endpoint PE11,
with a 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 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 Route Target extended community transport-target:0:100. Label B-L0
can either be Implicit Null (Label 3) or a UHP label. can either be Implicit NULL (Label 3) or a UHP label.
This route is received by ASBR13 and it resolves over the tunnel 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, the next hop set to itself, and transport-target:0:100. Label B-L1, the next hop set to itself, and transport-target:0:100.
An MPLS swap route is installed at ASBR13 for B-L1 with a next hop An MPLS swap route is installed at ASBR13 for B-L1 with a next hop
pointing to ASBR13_to_PE11_gold tunnel. pointing to ASBR13_to_PE11_gold tunnel.
Similarly, ASBR14 also receives a BGP CT route for Similarly, ASBR14 also receives a BGP CT route for
skipping to change at line 1538 skipping to change at line 1526
BGP CT family to ASBRs ASBR21 and ASBR22 according to export policy. BGP CT family to ASBRs ASBR21 and ASBR22 according to export policy.
This route is sent with the same NLRI RD prefix This route is sent with the same NLRI RD prefix
192.0.2.11:100:192.0.2.11, Label B-L2, next hop set to itself, and 192.0.2.11:100:192.0.2.11, Label B-L2, next hop set to itself, and
transport-target:0:100. An MPLS swap route is installed at ASBR14 transport-target:0:100. An MPLS swap route is installed at ASBR14
for B-L1 with a next hop pointing to ASBR14_to_PE11_gold tunnel. for B-L1 with a next hop pointing to ASBR14_to_PE11_gold tunnel.
In the Bronze plane, the BGP CT route with a Bronze SLA to endpoint In the Bronze plane, the BGP CT route with a Bronze SLA to endpoint
PE11 is originated by PE11 with an NLRI containing RD prefix PE11 is originated by PE11 with an NLRI containing RD prefix
192.0.2.11:200:192.0.2.11 and an appropriate label. The use of 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 distinct RDs for Gold and Bronze allows both Gold and Bronze
advertisements to traverse path-selection pinchpoints without any advertisements to traverse path-selection pinch points without any
path hiding at RRs or ASBRs. And Route Target extended community path hiding at RRs or ASBRs. And Route Target extended community
transport-target:0:200 lets the route resolve over Bronze tunnels in transport-target:0:200 lets the route resolve over Bronze tunnels in
the network, similar to the process being described for the Gold SLA the network, similar to the process being described for the Gold SLA
path. path.
Moving back to the Gold plane, ASBR21 receives the Gold SLA BGP CT 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 EBGP sessions from ASBR13 and ASBR14 and can compute ECMP/FRR hop EBGP sessions from ASBR13 and ASBR14 and can compute ECMP/FRR
towards them. ASBR21 readvertises the BGP CT route for towards them. ASBR21 readvertises the BGP CT route for
192.0.2.11:100:192.0.2.11 with a next hop set to itself (loopback 192.0.2.11:100:192.0.2.11 with a next hop set to itself (loopback
skipping to change at line 1571 skipping to change at line 1559
RR27 also readvertises this BGP CT route to ABR23 and ABR24 with the RR27 also readvertises this BGP CT route to ABR23 and ABR24 with the
label and next hop unchanged. label and next hop unchanged.
BGP ADD-PATH is enabled for the BGP CT family on the sessions between BGP ADD-PATH is enabled for the BGP CT family on the sessions between
RR27 and the ASBRs and ABRs such that routes for 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 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 reflected to ABR23 and ABR24 without any path hiding. Thus, ABR23 is
given visibility of both available next hops for the Gold SLA. given visibility of both available next hops for the Gold SLA.
ABR23 receives the route with next hop 192.0.2.21 and label B-L3 from ABR23 receives the route with next hop 192.0.2.21 and label B-L3 from
RR27. The route target "transport-target:0:100" on this route acts RR27. The transport-target:0:100 on this route acts as the Mapping
as the Mapping Community and instructs ABR23 to strictly resolve the Community and instructs ABR23 to strictly resolve the next hop using
next hop using transport class 100 routes only. ABR23 is unable to routes in TC 100 TRDB only. ABR23 is unable to find a route for
find a route for 192.0.2.21 with transport class 100. Thus, it 192.0.2.21 in the TC 100 TRDB. Thus, it considers this route
considers this route unusable and does not propagate it further. unusable and does not propagate it further. This prunes ASBR21 from
This prunes ASBR21 from the Gold SLA tunneled path. the Gold SLA tunneled path.
ABR23 also receives the route with next hop 192.0.2.22 and label B-L4 ABR23 also receives the route with next hop 192.0.2.22 and label B-L4
from RR27. The route target "transport-target:0:100" on this route from RR27. The transport-target:0:100 on this route acts as the
acts as the Mapping Community and instructs ABR23 to strictly resolve Mapping Community and instructs ABR23 to strictly resolve the next
the next hop using transport class 100 routes only. ABR23 hop using routes in TC 100 TRDB only. ABR23 successfully resolves
successfully resolves the next hop to point to ABR23_to_ASBR22_gold the next hop to point to ABR23_to_ASBR22_gold tunnel. ABR23
tunnel. ABR23 readvertises this BGP CT route with the next hop set readvertises this BGP CT route with the next hop set to itself
to itself (loopback address 192.0.2.23) and a new label B-L5 to PE25. (loopback address 192.0.2.23) and a new label B-L5 to PE25. A swap
A swap route for B-L5 is installed by ABR23 to swap to label B-L4 and route for B-L5 is installed by ABR23 to swap to label B-L4 and
forward into ABR23_to_ASBR22_gold tunnel. forward into ABR23_to_ASBR22_gold tunnel.
PE25 receives the BGP CT route for prefix 192.0.2.11:100:192.0.2.11 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. 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 tunnel. class 100, pushing labels associated with PE25_to_ABR23_gold tunnel.
In this manner, the Gold transport LSP "ASBR13_to_PE11_gold" in the 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 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 the ingress domain, to create an end-to-end Gold SLA path. MPLS swap
routes are installed at ASBR13, ASBR22, and ABR23, when propagating 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 the PE11 BGP CT Gold Transport Class route 192.0.2.11:100:192.0.2.11
with next hop set to itself towards PE25. with next hop set to itself towards PE25.
Thus formed, the BGP CT LSP originates in PE25 and terminates in Thus formed, the BGP CT LSP 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 CT LSP into the "ASBR13_to_PE11_gold" LSP to traverse the last
domain, thus satisfying Gold SLA end-to-end. domain, thus satisfying Gold SLA end-to-end.
When PE25 receives service routes from RR26 with next hop 192.0.2.11 When PE25 receives service routes from RR26 with next hop 192.0.2.11
and mapping community Color:0:100, it resolves over this BGP CT route 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 pushing as 192.0.2.11:100:192.0.2.11. Thus, pushing label B-L5 and pushing as
the top label the labels associated with PE25_to_ABR23_gold tunnel. the top label the labels associated with PE25_to_ABR23_gold tunnel.
8.4. Data Plane View 8.4. Data Plane View
8.4.1. Steady State 8.4.1. Steady State
This section describes how the data plane looks in steady state. This section describes how the data plane looks in steady state.
CE41 transmits an IP packet with the destination 203.0.113.31. On CE41 transmits an IP packet with the destination 203.0.113.31. On
skipping to change at line 1638 skipping to change at line 1626
lookup for label B-L5 in the global MPLS FIB. This yields the route 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 label that swaps label B-L5 with label B-L4 and pushes the top label
provided by ABR23_to_ASBR22_gold tunnel. Thus, ABR23 transmits the provided by ABR23_to_ASBR22_gold tunnel. Thus, ABR23 transmits the
MPLS packet with label B-L4 to ASBR22 on a tunnel that satisfies the MPLS packet with label B-L4 to ASBR22 on a tunnel that satisfies the
Gold SLA. Gold SLA.
ASBR22 similarly performs a lookup for label B-L4 in the global MPLS ASBR22 similarly performs a lookup for label B-L4 in the global MPLS
FIB, finds the route that swaps label B-L4 with label B-L2, and FIB, finds the route that swaps label B-L4 with label B-L2, and
forwards it 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. specific Transport Class, in this example.
ASBR13 receives the MPLS packet with label B-L2 and performs a lookup 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 pushes in the MPLS FIB, finds the route that pops label B-L2, and pushes
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 the Gold SLA in AS 1. preserves the Gold SLA in AS 1.
PE11 receives the MPLS packet with V-L1 and performs VPN forwarding, PE11 receives the MPLS packet with V-L1 and performs VPN forwarding,
thus transmitting the original IP payload from CE41 to CE31. The thus transmitting the original IP payload from CE41 to CE31. The
payload has traversed path satisfying the Gold SLA end-to-end. payload has traversed path satisfying the Gold SLA end-to-end.
skipping to change at line 1679 skipping to change at line 1667
experiences a failure but no alternate path exists. experiences a failure but no alternate path exists.
Assume tunnel ABR23_to_ASBR22_gold goes down, such that now no end- Assume tunnel ABR23_to_ASBR22_gold goes down, such that now no end-
to-end Gold path exists in the network. This makes the BGP CT route 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 unusable at ABR23. This 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 to makes ABR23 send a BGP withdrawal for 192.0.2.11:100:192.0.2.11 to
PE25. PE25.
The withdrawal for 192.0.2.11:100:192.0.2.11 allows PE25 to react to 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 the loss of the Gold path to 192.0.2.11. Assuming PE25 is
provisioned to use a best-effort transport class as the backup path, provisioned to use a Best-Effort Transport Class as the backup path,
this withdrawal of a 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. route. That repairs the traffic to go via the best-effort path.
PE25 can also be provisioned to use the Bronze transport class as the PE25 can also be provisioned to use the Bronze Transport Class as the
backup path. The repair will happen in similar manner in that case backup path. The repair will happen in similar manner in that case
as well. as well.
Traffic repair to absorb the failure happens at ingress node PE25 in Traffic repair to absorb the failure happens at ingress node PE25 in
a service prefix scale independent manner (PIC). The repair time a service prefix scale independent manner (PIC). The repair time
will be proportional to time taken for withdrawing the BGP CT route. will be proportional to time taken for withdrawing the BGP CT route.
These examples demonstrate the various levels of failsafe mechanisms These examples demonstrate the various levels of fail-safe mechanisms
available to protect traffic in a BGP CT network. available to protect traffic in a BGP CT network.
9. Scaling Considerations 9. Scaling Considerations
9.1. Avoiding Unintended Spread of BGP CT Routes Across Domains 9.1. Avoiding Unintended Spread of BGP CT Routes Across Domains
[RFC8212] suggests BGP speakers require explicit configuration of [RFC8212] suggests BGP speakers require explicit configuration of
both BGP Import and Export Policies in order to receive or send both BGP Import and Export Policies in order to receive or send
routes over EBGP sessions. routes over EBGP sessions.
It is recommended to follow this for BGP CT routes. It will prohibit It is recommended to follow this for BGP CT routes. It will prohibit
unintended advertisement of transport routes throughout the BGP CT unintended advertisement of transport routes throughout the BGP CT
transport domain, which may span across multiple AS domains. This transport domain, which may span across multiple AS domains. This
will conserve usage resources for MPLS labels and next hops in the will conserve usage resources for MPLS labels and next hops in the
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.
domain.
9.2. Constrained Distribution of PNHs to SNs (On-Demand Next Hop) 9.2. Constrained Distribution of PNHs to SNs (On-Demand Next Hop)
This section describes how the number of Protocol Next Hops (PNHs) This section describes how the number of Protocol Next Hops (PNHs)
advertised to an SN or BN can be constrained using BGP Classful advertised to an SN or BN can be constrained using BGP Classful
Transport and RTC (see [RFC4684]. Transport and RTC (see [RFC4684].
An egress SN MAY advertise a BGP CT route for RD:eSN with two Route An egress SN MAY advertise a BGP CT route for RD:eSN with two Route
Targets: transport-target:0:<TC> and an RT carrying <eSN>:<TC>, where Targets: transport-target:0:<TC> and an RT carrying <eSN>:<TC>, where
TC is the Transport Class identifier and eSN is the IP address used TC is the Transport Class identifier and eSN is the IP address used
by the SN as BGP next hop in its service route advertisements. by the SN as BGP next hop in its service route advertisements.
Note that such use of the IP-address-specific route target <eSN>:<TC> Note that such use of the IP-address-specific route target <eSN>:<TC>
is optional in a BGP CT network. It is required only if there is a is optional in a BGP CT network. It is required only if there is a
requirement to prune the propagation of the transport route for an requirement to prune the propagation of the transport route for an
egress node eSN to only the set of ingress nodes that need it. When egress node eSN to only the set of ingress nodes that need it. When
only the RT of transport-target:0:<TC> is used, the pruning happens only the RT of transport-target:0:<TC> is used, the pruning happens
in granularity of Transport Class ID (Color), not BGP next hop; a BGP in 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 PE CT route will only be advertised into a domain with at least one PE
that imports its transport class. that imports its Transport Class.
The transport-target:0:<TC> is the new type of route target The transport-target:0:<TC> is the new type of route target
(Transport Class RT) defined in this document. It is carried in the (Transport Class RT) defined in this document. It is carried in the
BGP extended community attribute (BGP attribute code 16). BGP extended community attribute (attribute code 16).
The RT carrying <eSN>:<TC> MAY be an IP-address-specific regular RT The RT carrying <eSN>:<TC> MAY be an IP-address-specific regular RT
(BGP attribute code 16), or IPv6-address specific RT (BGP attribute (attribute code 16), or IPv6-address specific RT (attribute code 25).
code 25). It should be noted that the Local Administrator field of It should be noted that the Local Administrator field of these RTs
these RTs can only carry two octets of information; thus, the <TC> can only carry two octets of information; thus, the <TC> field in
field in this approach is limited to a 2-octet value. Future this approach is limited to a 2-octet value. Future protocol
protocol extension work is needed to define a BGP CCA that can extension work is needed to define a BGP CCA that can accommodate an
accomodate an IPv4/IPv6 address along with a 4-octet Local IPv4/IPv6 address along with a 4-octet Local Administrator field.
Administrator field.
An ingress SN MAY import BGP CT routes with a Route Target carrying An ingress SN MAY import BGP CT routes with a Route Target carrying
<eSN>:<TC>. The ingress SN may learn the eSN values by configuration <eSN>:<TC>. The ingress SN may learn the eSN values by configuration
or it may discover them from the BGP next hop field in the BGP VPN or it may discover them from the BGP next hop field in the BGP VPN
service routes received from the eSN. A BGP ingress SN receiving a service routes received from the eSN. A BGP ingress SN receiving a
BGP service route with a next hop of eSN generates an RTC route for BGP service route with a next hop of eSN generates an RTC route for
Route Target prefix <Origin ASN>:<eSN>/[80|176] in order to learn BGP Route Target prefix <Origin ASN>:<eSN>/[80|176] in order to learn BGP
CT transport routes to reach eSN. This allows constrained CT transport routes to reach eSN. This allows constrained
distribution of the transport routes to the PNHs actually required by distribution of the transport routes to the PNHs actually required by
iSN. iSN.
skipping to change at line 1785 skipping to change at line 1771
Such a BN in the core of the network imports BGP CT routes with Such a BN in the core of the network imports BGP CT routes with
Transport-Target:0:<TC> and generates an RTC route for <Origin Transport-Target:0:<TC> and generates an RTC route for <Origin
ASN>:0:<TC>/96, while not propagating the more specific RTC requests ASN>:0:<TC>/96, while not propagating the more specific RTC requests
for specific PNHs. This lets the BN learn transport routes to all for specific PNHs. This lets the BN learn transport routes to all
eSN nodes but confines their propagation to ingress SNs. eSN nodes but confines their propagation to ingress SNs.
9.3. Limiting the Visibility Scope of PE Loopback as PNHs 9.3. Limiting the Visibility Scope of PE Loopback as PNHs
It may be even more desirable to limit the number of PNHs that are It may be even more desirable to limit the number of PNHs that are
globally visible in the network. This is possible using the globally visible in the network. This is possible using the
mechanism described in Appendix D, such that advertisement of PE mechanism described in Appendix D.
loopback addresses as next hops in BGP service routes is confined to
the region they belong to. An anycast IP address called a "Context
Protocol Nexthop" (or "CPNH") address abstracts the SNs in a region
from other regions in the network.
Such that advertisement of PE loopback addresses as next hop in BGP Such that advertisement of PE loopback addresses as next hop in BGP
service routes is confined to the region they belong to. An anycast service routes is confined to the region they belong to. An anycast
IP-address called "Context Protocol Nexthop Address" (CPNH) abstracts IP-address called "Context Protocol Nexthop Address" (CPNH) abstracts
the SNs in a region from other regions in the network. the SNs in a region from other regions in the network.
This provides much greater advantage in terms of scaling, convergence This provides much greater advantage in terms of scaling, convergence
and security. Changes to implement this feature are required only on and security. Changes to implement this feature are required only on
the local region's BNs and RRs, so legacy PE devices can also benefit the local region's BNs and RRs, so legacy PE devices can also benefit
from this approach. from this approach.
10. Operations and Manageability Considerations 10. Operations and Manageability Considerations
10.1. MPLS OAM 10.1. MPLS OAM
MPLS Operations, Administration, and Maintenance (OAM) procedures MPLS Operations, Administration, and Maintenance (OAM) procedures
specified in [RFC8029] also apply to BGP Classful Transport. specified in [RFC8029] also apply to BGP CT.
The Target FEC Stack sub-TLV for IPv4 Classful Transport has a Sub- The Target FEC Stack sub-TLV for IPv4 BGP CT has a Sub-Type of 31744
Type of 31744 and a length of 13. The Value field consists of the RD and a length of 13. The Value field consists of the RD advertised
advertised with the Classful Transport prefix, the IPv4 prefix (with with the BGP CT prefix, the IPv4 prefix (with trailing 0 bits to make
trailing 0 bits to make 32 bits in all), and a prefix length encoded 32 bits in all), and a prefix length encoded as shown in Figure 4.
as shown in Figure 4.
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: Classful Transport IPv4 FEC Figure 4: BGP CT IPv4 FEC
The Target FEC Stack sub-TLV for IPv6 Classful Transport has a Sub- The Target FEC Stack sub-TLV for IPv6 BGP CT has a Sub-Type of 31745
Type of 31745 and a length of 25. The Value field consists of the RD and a length of 25. The Value field consists of the RD advertised
advertised with the Classful Transport prefix, the IPv6 prefix (with with the BGP CT prefix, the IPv6 prefix (with trailing 0 bits to make
trailing 0 bits to make 128 bits in all) and a prefix length encoded 128 bits in all) and a prefix length encoded as shown in Figure 5.
as shown in Figure 5.
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: Classful Transport IPv6 FEC Figure 5: BGP CT IPv6 FEC
These prefix layouts are inherited from Sections 3.2.5 and 3.2.6 of These prefix layouts are inherited from Sections 3.2.5 and 3.2.6 of
[RFC8029]. [RFC8029].
10.2. Usage of RD and Label-Allocation Modes 10.2. Usage of RD and Label-Allocation Modes
RDs aid in troubleshooting provider networks that deploy BGP CT, by 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. provider network or span closely coordinated provider networks.
skipping to change at line 1872 skipping to change at line 1852
RDs. RDs.
For example, unique "RDx:EP1" prefixes can be advertised by an SN for For example, unique "RDx:EP1" prefixes can be advertised by an SN for
an EP1 to different upstream BNs with unique forwarding-specific an EP1 to different upstream BNs with unique forwarding-specific
encapsulation (e.g., a Label) in order to collect traffic statistics encapsulation (e.g., a Label) in order to collect traffic statistics
at the SN for each BN. In the absence of an RD, duplicated Transport at the SN for each BN. In the absence of an RD, duplicated Transport
Class / Color values will be needed in the transport network to Class / Color values will be needed in the transport network to
achieve such use cases. achieve such use cases.
The allocation of RDs is done at the point of origin of the BGP CT The allocation of RDs is done at the point of origin of the BGP CT
route. This can be either 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. does not require full visibility of all nodes originating an EP.
A label is allocated for a BGP CT route when it is advertised with A label is allocated for a BGP CT route when it is advertised with
the next hop set to itself by an SN or a BN. An implementation may the next hop set to itself by an SN or a BN. An implementation may
use different label-allocation modes with BGP CT. Per-prefix is the use different label-allocation modes with BGP CT. Per-prefix is the
recommended label-allocation mode as it provides better traffic recommended label-allocation mode as it provides better traffic
convergence properties than a per-NH label-allocation mode. convergence properties than a per-NH label-allocation mode.
Furthermore, BGP CT offers two flavors for per-prefix label Furthermore, BGP CT offers two flavors for per-prefix label
allocation: allocation:
* The first flavor assigns a label for each unique "RD, EP". * The first flavor assigns a label for each unique "RD, EP".
* The second flavor assigns a label for each unique "Transport * The second flavor assigns a label for each unique "Transport
Class, EP" while ignoring the RD. Class, EP" while ignoring the RD.
In a BGP CT network, the number of routes at an Ingress PE is a 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 function of unique EPs multiplied by BNs in the ingress domain that
have the next hop set to themselves. BGP CT provides flexible RD and have the next hop set to themselves. BGP CT provides flexible RD and
label-allocation modes to address operational requirements in a label-allocation modes to address operational requirements in a
multi-domain network. The impacts on the control plane and multi-domain network. The impacts on the control plane and
forwarding behavior for these modes are detailed with an example in forwarding behavior for these modes are detailed with an example in
Section 10.3. Section 10.3.
10.3. Managing Transport-Route Visibility 10.3. Managing Transport-Route Visibility
This section details the usage of BGP CT RD and label-allocation This section details the usage of BGP CT RD and label-allocation
skipping to change at line 1992 skipping to change at line 1972
change. change.
Figure 7 demonstrates that BGP CT allows an operator to control how Figure 7 demonstrates that BGP CT allows an operator to control how
much path visibility and forwarding diversity is desired in the much path visibility and forwarding diversity is desired in the
network for both Unicast and Anycast endpoints. network for both Unicast and Anycast endpoints.
11. Deployment Considerations 11. Deployment Considerations
11.1. Coordination Between Domains Using Different Community Namespaces 11.1. Coordination Between Domains Using Different Community Namespaces
Cooperating Inter-AS Option C domains may sometimes not agree on RT, Cooperating inter-AS option C domains may sometimes not agree on RT,
RD, Mapping community, or Transport Route Target values because of RD, Mapping Community, or Transport Class RT values because of
differences in community namespaces (e.g., during network mergers or differences in community namespaces (e.g., during network mergers or
renumbering for expansion). Such deployments may deploy mechanisms renumbering for expansion). Such deployments may deploy mechanisms
to map and rewrite the Route Target values on domain boundaries using to map and rewrite the Route Target values on domain boundaries using
per-ASBR import policies. This is no different than any other BGP per-ASBR import policies. This is no different than any other BGP
VPN family. Mechanisms used in inter-AS VPN deployments may be VPN family. Mechanisms used in inter-AS VPN deployments may be
leveraged with the Classful Transport family also. leveraged with the BGP CT family also.
A resolution scheme allows association with multiple Mapping 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. network merger, or transition scenarios.
The Transport Class Route Target extended community is useful to The Transport Class RT is useful to avoid collision with regular
avoid collision with regular Route Target namespace used by service Route Target namespace used by service routes.
routes.
11.2. Managing Intent at Service and Transport Layers 11.2. Managing Intent at Service and Transport Layers
Section 8 shows multiple domains that agree on a color namespace Section 8 shows multiple domains that agree on a color namespace
(Agreeing Color Domains) and contain tunnels with an equivalent set (Agreeing Color Domains) and contain tunnels with an equivalent set
of colors (Homogenous Color Domains). of colors (Homogenous Color Domains).
However, in the real world, this may not always be guaranteed. Two 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 known as Non-Agreeing Color Domains. Two domains may have tunnels
with unequal sets of colors; these are known as Heterogeneous Color with unequal sets of colors; these are known as Heterogeneous Color
Domains. Domains.
This section describes how BGP CT is deployed in such scenarios to 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. option A and inter-AS option B scenarios as well.
11.2.1. Service-Layer Color Management 11.2.1. Service Layer Color Management
At the service layer, it is recommended that a global color namespace At the service layer, it is recommended that a global color namespace
be maintained across multiple cooperating domains. BGP CT allows be maintained across multiple cooperating domains. BGP CT allows
indirection using resolution schemes to be able to maintain a global indirection using Resolution Schemes to be able to maintain a global
namespace in the service layer. This is possible even if each domain namespace in the service layer. This is possible even if each domain
independently maintains its own local transport color namespace. independently maintains its own local transport color namespace.
As explained in Section 5, a mapping community carried on a service As explained in Section 5, 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. transport layer Intent available in each domain.
In this manner, it is recommended to keep color namespace management In this manner, it is recommended to keep color namespace management
at the service layer and the transport layer decoupled from each at the service layer and the transport layer decoupled from each
other. In the following sections, the service layer agrees on a other. In the following sections, the service layer agrees on a
single global namespace. single global namespace.
11.2.2. Non-Agreeing Color Transport Domains 11.2.2. Non-Agreeing Color Transport Domains
Non-Agreeing Color Domains require a mapping community rewrite on 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. namespace to another domain's color namespace.
The following example illustrates how traffic is stitched and SLA is The following example illustrates how traffic is stitched and SLA is
preserved when domains don't use the same namespace at the transport preserved when domains don't use the same namespace at the transport
layer. Each domain specifies the same SLA using different color layer. Each domain specifies the same SLA using different color
values. values.
..................... ....................... ...................... ..................... ....................... .....................
: Gold(100) : : Gold(300) : : Gold(500) : : Gold(100) : : Gold(300) : : Gold(500) :
: : : : : : : : : : : :
: [PE11]----[ASBR11]---[ASBR21------[ASBR22]---[ASBR31-------[PE31]: : [PE11]----[ASBR11]---[ASBR21------[ASBR22]---[ASBR31------[PE31]:
: : : : : : : : : : : :
: AS1 : : AS2 : : AS3 : : AS1 : : AS2 : : AS3 :
: : : : : : : : : : : :
: Bronze(200) : : Bronze(400) : : Bronze(600) : : Bronze(200) : : Bronze(400) : : Bronze(600) :
..................... ....................... ...................... ..................... ....................... .....................
----------- Traffic Direction --------> ----------- Traffic Direction -------->
Figure 8: Transport Layer with Non-Agreeing Color Domains Figure 8: Transport Layer with Non-agreeing Color Domains
In the topology shown in Figure 8, we have three Autonomous Systems. In the topology shown in Figure 8, we have three Autonomous Systems.
All the nodes in the topology support BGP CT. All the nodes in the topology support BGP CT.
* In AS1, the Gold SLA is represented by color 100 and Bronze by * In AS1, the Gold SLA is represented by color 100 and Bronze by
200. 200.
* In AS2, the Gold SLA is represented by color 300 and Bronze by * In AS2, the Gold SLA is represented by color 300 and Bronze by
400. 400.
* In AS3, the Gold SLA is represented by color 500 and Bronze by * In AS3, the Gold SLA is represented by color 500 and Bronze by
600. 600.
Though the color values are different, they map to tunnels with Though the color values are different, they map to tunnels with
sufficiently similar TE characteristics in each domain. sufficiently similar TE characteristics in each domain.
The service route carries an abstract mapping community that maps to The service route carries an abstract Mapping Community that maps to
the required SLA. For example, service routes that need to resolve the required SLA. For example, service routes that need to resolve
over Gold transport tunnels carry a mapping community color:0:100500. over Gold transport tunnels carry a Mapping Community color:0:100500.
In AS3, it maps to a resolution scheme containing a TRDB with color In AS3, it maps to a Resolution Scheme containing TRDB with color
500; in AS2, it maps to a TRDB with color 300; and in AS1, it maps to 500; in AS2, it maps to TRDB with color 300; and in AS1, it maps to
a TRDB with color 100. Coordination is needed to provision the TRDB with color 100. Coordination is needed to provision the
resolution schemes in each domain, as explained previously. Resolution Schemes in each domain, as explained previously.
At the AS boundary, the transport-class route-target is rewritten for At the AS boundary, the Transport Class RT is rewritten for the BGP
the BGP CT routes. In the previous topology, at ASBR31, the CT routes. In the previous topology, at ASBR31, the transport-
transport-target:0:500 for Gold tunnels is rewritten to transport- target:0:500 for Gold tunnels is rewritten to transport-target:0:300
target:0:300 and then advertised to ASBR22. Similarly, the and then advertised to ASBR22. Similarly, the transport-target:0:300
transport-target:0:300 for Gold tunnels are rewritten to transport- for Gold tunnels are rewritten to transport-target:0:100 at ASBR21
target:0:100 at ASBR21 before advertising to ASBR11. At PE11, the before advertising to ASBR11. At PE11, the transport route received
transport route received with transport-target:0:100 will be added to with transport-target:0:100 will be added to the color 100 TRDB. The
the color 100 TRDB. The service route received with mapping service route received with Mapping Community color:0:100500 at PE1
community color:0:100500 at PE1 maps to the Gold TRDB and resolves maps to the Gold TRDB and resolves over this transport route.
over this transport route.
Inter-domain traffic forwarding in the previous topology works as Inter-domain traffic forwarding in the previous topology works as
explained in Section 8. explained in Section 8.
Transport-target rewrite requires coordination of color values Transport Class RT rewrite requires coordination 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 rewrite 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 non- coordinating service layer colors deployed in a global mesh of non-
adjacent color domains. This basically allows localizing the problem adjacent color domains. This basically allows localizing the problem
to a pair of adjacent color domains and solving it. to a pair of adjacent color domains and solving it.
11.2.3. Heterogeneous Agreeing Color Transport Domains 11.2.3. Heterogeneous Agreeing Color Transport Domains
In a heterogeneous-domain scenario, it might not be possible to map a In a heterogeneous-domain scenario, it might not be possible to map a
service-layer intent to the matching transport color, as the color service layer Intent to the matching transport color, as the color
might not be locally available in a domain. might not be locally available in a domain.
The following example illustrates how traffic is stitched when a 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. otherwise.
..................... ....................... ...................... ..................... ....................... .....................
: : : Gold1(101) : : : : : : Gold1(101) : : :
: Gold(100) : : Gold2(102) : : Gold(100) : : Gold(100) : : Gold2(102) : : Gold(100) :
: : : : : : : : : : : :
: [PE11]----[ASBR11]---[ASBR21------[ASBR22]---[ASBR31-------[PE31]: : [PE11]----[ASBR11]---[ASBR21------[ASBR22]---[ASBR31------[PE31]:
: : : : : : : : : : : :
: Metro Ingress : : Core : : Metro Egress : : Metro Ingress : : Core : : Metro Egress :
: : : : : : : : : : : :
: AS1 : : AS2 : : AS3 : : AS1 : : AS2 : : AS3 :
..................... ....................... ...................... ..................... ....................... .....................
----------- Traffic Direction --------> ----------- Traffic Direction -------->
Figure 9: Transport Layer with Heterogenous Color Domains Figure 9: Transport Layer with Heterogeneous Color Domains
In Figure 9, we have three Autonomous Systems. All the nodes in the In Figure 9, we have three Autonomous Systems. All the nodes in the
topology support BGP CT. topology support BGP CT.
* In AS1, the Gold SLA is represented by color 100. * In AS1, the Gold SLA is represented by color 100.
* In AS2, Gold has finer shades: Gold1 by color 101 and Gold2 by * In AS2, Gold has finer shades: Gold1 by color 101 and Gold2 by
color 102. color 102.
* In AS3, the Gold SLA is represented by color 100. * In AS3, the Gold SLA is represented by color 100.
skipping to change at line 2166 skipping to change at line 2144
11.2.3.1. Duplicate Tunnels Approach 11.2.3.1. Duplicate Tunnels Approach
In this approach, duplicate tunnels that satisfy the Gold SLA are 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. colors 101 and 102.
These tunnels will be installed in TRDBs corresponding to transport These tunnels will be installed in TRDBs corresponding to transport
classes of colors 101 and 102. classes of colors 101 and 102.
Overlay routes received with a mapping community (e.g., transport- Overlay routes received with a Mapping Community (e.g., transport-
target or color community) can resolve over these tunnels in the TRDB target or color community) can resolve over these tunnels in the TRDB
with matching colors by using resolution schemes. with matching colors by using Resolution Schemes.
This approach consumes more resources in the transport and forwarding This approach consumes more resources in the transport and forwarding
layer because of the duplicate tunnels. layer because of the duplicate tunnels.
11.2.3.2. Customized Resolution Schemes Approach 11.2.3.2. Customized Resolution Schemes Approach
In this approach, resolution schemes in domains AS1 and AS3 are In this approach, Resolution Schemes in domains AS1 and AS3 are
customized to map the received mapping community (e.g., transport- customized to map the received Mapping Community (e.g., transport-
target or color community) over available Gold SLA tunnels. This target or color community) over available Gold SLA tunnels. This
conserves resource usage with no additional state in the transport or conserves resource usage with no additional state in the transport or
forwarding planes. forwarding planes.
Service routes advertised by PE31 that need to resolve over Gold1 Service routes advertised by PE31 that need to resolve over Gold1
transport tunnels carry a mapping community color:0:101. In AS3 and transport tunnels carry a Mapping Community color:0:101. In AS3 and
AS1, where Gold1 is not available, it is mapped to color 100 TRDB AS1, where Gold1 is not available, it is mapped to color 100 TRDB
using a customized resolution scheme. In AS2, Gold1 is available, using a customized Resolution Scheme. In AS2, Gold1 is available,
and it maps to color 101 TRDB. and it maps to color 101 TRDB.
Similarly, service routes advertised by PE31 that need to resolve Similarly, service routes advertised by PE31 that need to resolve
over Gold2 transport tunnels carry a mapping community color:0:102. over Gold2 transport tunnels carry a Mapping Community color:0:102.
In AS3 and AS1, where Gold2 is not available, it is mapped to color In AS3 and AS1, where Gold2 is not available, it is mapped to color
100 TRDB using a customized resolution scheme. In AS2, Gold2 is 100 TRDB using a customized Resolution Scheme. In AS2, Gold2 is
available, and it maps to color 102 TRDB. available, and it maps to color 102 TRDB.
To facilitate this, SNs/BNs in all three ASes provision the transport To facilitate this, SNs/BNs in all three ASes provision the transport
classes 100, 101, and 102. SNs and BNs in AS1 and AS3 are classes 100, 101, and 102. SNs and BNs 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 100 with transport-target:0:101 or transport-target:0:102 using color 100
TRDB. TRDB.
PE31 is provisioned to originate BGP CT routes with color 101 for PE31 is provisioned to originate BGP CT routes with color 101 for
endpoint PE31. This route is sent with an NLRI RD prefix RD1:PE31 endpoint PE31. This route is sent with an NLRI RD prefix RD1:PE31
and Route Target extended community transport-target:0:101. and Route Target extended community transport-target:0:101.
Similarly, PE31 is provisioned to originate BGP CT routes with color Similarly, PE31 is provisioned to originate BGP CT routes with color
102 for endpoint PE31. This route is sent with an NLRI RD prefix 102 for endpoint PE31. This route is sent with an NLRI RD prefix
RD2:PE31 and Route Target extended community transport-target:0:102. RD2:PE31 and Route Target extended community transport-target:0:102.
The following description explains the remaining procedures with The following description explains the remaining procedures with
color 101 as an example. color 101 as an example.
At ASBR31, the route target "transport-target:0:101" on this BGP CT At ASBR31, the Route Target role of transport-target:0:101 on this
route gives instruction to add the route to color 101 TRDB. ASBR31 BGP CT route gives instruction to add the route to color 101 TRDB.
is provisioned with a customized resolution scheme that resolves the ASBR31 is provisioned with a customized Resolution Scheme that
routes carrying mapping community transport-target:0:101 to resolve resolves the routes carrying Mapping Community transport-target:0:101
using color 100 TRDB. This route is then readvertised from color 101 to resolve using color 100 TRDB. This route is then readvertised
TRDB to ASBR22 with route-target:0:101. from color 101 TRDB to ASBR22 with route-target:0:101.
At ASBR22, the BGP CT routes received with transport-target:0:101 At ASBR22, the BGP CT routes received with transport-target:0:101
will be added to color 101 TRDB and strictly resolve over tunnel will be added to color 101 TRDB and strictly resolve over tunnel
routes in the same TRDB. This route is readvertised to ASBR21 with routes in the same TRDB. This route is readvertised to ASBR21 with
transport-target:0:101. transport-target:0:101.
Similarly, at ASBR21, the BGP CT routes received with transport- Similarly, at ASBR21, the BGP CT routes received with transport-
target:0:101 will be added to color 101 TRDB and strictly resolve target:0:101 will be added to color 101 TRDB and strictly resolve
over tunnel routes in the same TRDB. This route is readvertised to over tunnel routes in the same TRDB. This route is readvertised to
ASBR11 with transport-target:0:101. ASBR11 with transport-target:0:101.
At ASBR11, the route target "transport-target:0:101" on this BGP CT At ASBR11, the Route Target role of transport-target:0:101 on this
route gives instruction to add the route to color 101 TRDB. ASBR11 BGP CT route gives instruction to add the route to color 101 TRDB.
is provisioned with a customized resolution scheme that resolves the ASBR11 is provisioned with a customized Resolution Scheme that
routes carrying transport-target:0:101 to use color 100 TRDB. This resolves the routes carrying transport-target:0:101 to use color 100
route is then readvertised from color 101 TRDB to PE11 with TRDB. This route is then readvertised from color 101 TRDB to PE11
transport-target:0:101. with transport-target:0:101.
At PE11, the route target "transport-target:0:101" on this BGP CT At PE11, the Route Target role of transport-target:0:101 on this BGP
route gives instruction 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. routes carrying transport-target:0:101 to use color 100 TRDB.
When PE11 receives the service route with the mapping community When PE11 receives the service route with the Mapping Community
color:0:101, it directly resolves over the BGP CT route in color 101 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 TRDB. TRDB, which, in turn, resolves over tunnel routes in color 100 TRDB.
Similar processing is done for color 102 routes also at ASBR31, Similar processing is done for color 102 routes also at ASBR31,
ASBR22, ASBR21, ASBR11, and PE11. ASBR22, ASBR21, ASBR11, and PE11.
In doing so, PE11 can forward traffic via tunnels with color 101, In doing so, PE11 can forward traffic via tunnels with color 101,
color 102 in the core domain and color 100 in the metro domains. color 102 in the core domain and color 100 in the metro domains.
11.3. Migration Scenarios 11.3. Migration Scenarios
skipping to change at line 2369 skipping to change at line 2347
This section describes how nodes supporting dissimilar encapsulation This section describes how nodes supporting dissimilar encapsulation
technologies can interoperate when using the BGP CT family. technologies can interoperate when using the BGP CT family.
11.3.2.1. Interoperation Between MPLS and SRv6 Nodes 11.3.2.1. Interoperation Between MPLS and SRv6 Nodes
BGP speakers may carry MPLS labels and SRv6 SIDs in BGP CT SAFI 76 BGP speakers may carry MPLS labels and SRv6 SIDs in BGP CT SAFI 76
for AFI 1 or 2 routes using protocol encoding as described in for AFI 1 or 2 routes using protocol encoding as described in
Section 6.3. Section 6.3.
MPLS Labels are carried using the encoding described in [RFC8277], MPLS labels are carried using the encoding described in [RFC8277],
and SRv6 SIDs are carried using the Prefix SID attribute as specified and SRv6 SIDs are carried using the Prefix-SID attribute as specified
in Section 7.13. in Section 7.13.
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 ----->
skipping to change at line 2396 skipping to change at line 2374
MPLS and SRv6 packets. R3 supports forwarding MPLS packets only. R4 MPLS and SRv6 packets. R3 supports forwarding MPLS packets only. R4
supports forwarding SRv6 packets only. All these nodes have a BGP supports forwarding SRv6 packets only. All these nodes have a BGP
session with Route Reflector RR1, which reflects routes between these session with Route Reflector RR1, which reflects routes between these
nodes with the next hop unchanged. The BGP CT family is negotiated nodes with the next hop unchanged. The BGP CT family is negotiated
on these sessions. on these sessions.
R1 and R2 send and receive both MPLS labels and SRv6 SIDs in the BGP R1 and R2 send and receive both MPLS labels and SRv6 SIDs in the BGP
CT control plane routes. This allows them to be ingress and egress CT control plane routes. This allows them to be ingress and egress
for both MPLS and SRv6 data planes. The MPLS label is carried using for both MPLS and SRv6 data planes. The MPLS label is carried using
the encoding described in [RFC8277], and an SRv6 SID is carried using the encoding described in [RFC8277], and an SRv6 SID is carried using
the Prefix SID attribute as specified in Section 7.13 without the the Prefix-SID attribute as specified in Section 7.13 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. can be used between R1 and R2.
R1 and R3 send and receive an MPLS label in the BGP CT control plane R1 and R3 send and receive an MPLS label in the BGP CT control plane
routes using the encoding described in [RFC8277]. This allows them routes using the encoding described in [RFC8277]. This allows them
to be ingress and egress for MPLS data plane. R1 will carry an SRv6 to be ingress and egress for MPLS data plane. R1 will carry an SRv6
SID in the Prefix SID attribute, which will not be used by R3. In SID in the Prefix-SID attribute, which will not be used by R3. In
order to interoperate with MPLS-only device R3, R1 MUST NOT use the order to interoperate with MPLS-only device R3, R1 MUST NOT use the
SRv6 Transposition scheme described in [RFC9252]. The encoding SRv6 Transposition Scheme described in [RFC9252]. The encoding
suggested in Section 7.13 is used by R1. MPLS forwarding will be suggested in Section 7.13 is used by R1. MPLS forwarding will be
used between R1 and R3. used between R1 and R3.
R1 and R4 send and receive SRv6 SIDs in the BGP CT control plane R1 and R4 send and receive SRv6 SIDs in the BGP CT control plane
routes using the BGP Prefix SID attribute, without a Transposition routes using the BGP Prefix-SID attribute, without a Transposition
Scheme. This allows them to be ingress and egress for the SRv6 data Scheme. This allows them to be ingress and egress for the SRv6 data
plane. R4 will carry the special MPLS label with a value of 3 plane. R4 will carry the special MPLS label with a value of 3
(Implicit-NULL) in the encoding described in [RFC8277], which tells (Implicit NULL) in the encoding described in [RFC8277], which tells
R1 not to push any MPLS label for this BGP CT route towards R4. The R1 not to push any MPLS label for this BGP CT route towards R4. The
MPLS label advertised by R1 in an NLRI as described in [RFC8277] will MPLS label advertised by R1 in an NLRI as described in [RFC8277] will
not be used by R4. SRv6 forwarding will be used between R1 and R4. not be used by R4. SRv6 forwarding will be used between R1 and R4.
Note that, in this example, R3 and R4 cannot communicate directly Note that, in this example, 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 and R4 from each other
will remain unusable due to incompatible forwarding technology. will remain unusable due to incompatible forwarding technology.
11.3.2.2. Interop Between Nodes Supporting MPLS and UDP Tunneling 11.3.2.2. Interop Between Nodes Supporting MPLS and UDP Tunneling
This section describes how nodes supporting MPLS forwarding can This section describes how nodes supporting MPLS forwarding can
interoperate with other nodes supporting UDP (or IP) tunneling when interoperate with other nodes supporting UDP (or IP) tunneling when
using BGP CT family. using BGP CT family.
MPLS Labels are carried using the encoding described in [RFC8277], MPLS labels are carried using the encoding described in [RFC8277],
and UDP (or IP) tunneling information is carried using the TEA and UDP (or IP) tunneling information is carried using the TEA
attribute or the Encapsulation Extended Community as specified in attribute or the Encapsulation extended community as specified in
[RFC9012]. [RFC9012].
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 ----->
skipping to change at line 2457 skipping to change at line 2435
supports forwarding UDP tunneled packets only. All these nodes have supports forwarding UDP tunneled packets only. All these nodes have
BGP session with Route Reflector RR1, which reflects routes between BGP session with Route Reflector RR1, which reflects routes between
these nodes with the next hop unchanged. The BGP CT family is these nodes with the next hop unchanged. The BGP CT family is
negotiated on these sessions. negotiated on these sessions.
R1 and R2 send and receive both MPLS labels and UDP tunneling info in R1 and R2 send and receive both MPLS labels and UDP tunneling info in
the BGP CT control plane routes. This allows them to be ingress and the BGP CT control plane routes. This allows them to be ingress and
egress for both MPLS and UDP tunneling data planes. The MPLS label egress for both MPLS and UDP tunneling data planes. The MPLS label
is carried using the encoding described in [RFC8277]. As specified is carried using the encoding described in [RFC8277]. As specified
in [RFC9012], UDP tunneling information is carried using the Tunnel in [RFC9012], UDP tunneling information is carried using the Tunnel
Encasulation Attribute (code 23) or the "barebones" Tunnel TLV Encapsulation Attribute (attribute code 23) or the "barebones" Tunnel
carried in Encapsulation Extended Community. Either MPLS or UDP TLV carried in Encapsulation extended community. Either MPLS or UDP
tunnel forwarding can be used between R1 and R2. tunnel forwarding can be used between R1 and R2.
R1 and R3 send and receive MPLS labels in the BGP CT control plane R1 and R3 send and receive MPLS labels in the BGP CT control plane
routes using the encoding described in [RFC8277]. This allows them routes using the encoding described in [RFC8277]. This allows them
to be ingress and egress for MPLS data plane. R1 will carry UDP to be ingress and egress for MPLS data plane. R1 will carry UDP
tunneling info in the TEA, which will not be used by R3. MPLS tunneling info in the TEA, which will not be used by R3. MPLS
forwarding will be used between R1 and R3. forwarding will be used between R1 and R3.
R1 and R4 send and receive UDP tunneling info in the BGP CT control R1 and R4 send and receive UDP tunneling info in the BGP CT control
plane routes using the BGP TEA. This allows them to be ingress and plane routes using the BGP TEA. This allows them to be ingress and
egress for UDP tunneled data plane. R4 will carry special MPLS Label egress for UDP tunneled data plane. R4 will carry MPLS special label
with value 3 (Implicit-NULL) in the encoding described in [RFC8277], 3 (Implicit NULL) in the encoding described in [RFC8277], which tells
which tells R1 not to push any MPLS label for this BGP CT route R1 not to push any MPLS label for this BGP CT route towards R4. The
towards R4. The MPLS Label advertised by R1 will not be used by R4. MPLS label advertised by R1 will not be used by R4. UDP tunneled
UDP tunneled forwarding will be used between R1 and R4. forwarding will be used between R1 and R4.
Note that, in this example, R3 and R4 cannot communicate directly Note that, in this example, 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 and R4 from each other
will remain unusable due to incompatible forwarding technology. will remain unusable due to incompatible forwarding technology.
11.4. MTU Considerations 11.4. MTU Considerations
Operators should coordinate the MTU of the intra-domain tunnels used Operators should coordinate the MTU of the intra-domain tunnels used
to prevent Path MTU discovery problems that could appear in to prevent Path MTU discovery problems that could appear in
deployments. The encapsulation overhead due to the MPLS label stack deployments. The encapsulation overhead due to the MPLS label stack
or equivalent tunnel header in different forwarding architecture or equivalent tunnel header in different forwarding architecture
should also be considered when determining the Path MTU of the end- should also be considered when determining the Path MTU of the end-
to-end BGP CT tunnel. to-end BGP CT tunnel.
[INTAREA-TUNNELS] discusses these considerations in more detail. [INTAREA-TUNNELS] discusses these considerations in more detail.
11.5. Use of DSCP 11.5. Use of DSCP
BGP CT specifies procedures for Intent-Driven Service Mapping in a BGP CT specifies procedures for Intent Driven Service Mapping in a
service provider network and defines the 'Transport Class' construct service provider network and defines the 'Transport Class' construct
to represent an Intent. to represent an Intent.
It may be desirable to allow a CE device to indicate in the data 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 it sends what treatment it desires (the Intent) when the
packet is forwarded within the provider network. packet is forwarded within the provider network.
Such an indication can be in the form of a DSCP (see [RFC2474]) in Such an indication can be in the form of a DSCP (see [RFC2474]) in
the IP header. the IP header.
skipping to change at line 2516 skipping to change at line 2494
layer. layer.
----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---->
Figure 13: Example Topology with DSCP on PE-CE Links Figure 13: Example Topology with DSCP on PE-CE Links
Let PE1 be configured to map DSCP1 to the Gold Transport class and Let PE1 be configured to map DSCP1 to the Gold TC and DSCP2 to the
DSCP2 to the Bronze Transport class. Based on the DSCP received on Bronze TC. Based on the DSCP received on the IP traffic from the CE
the IP traffic from the CE device, PE1 forwards the IP packet over a device, PE1 forwards the IP packet over a Gold or Bronze TC tunnel.
Gold or Bronze TC tunnel. Thus, the forwarding is not based on just Thus, the forwarding is not based on just the destination IP address
the destination IP address but also the DSCP. This is known as but also the DSCP. This is known as Class-Based Forwarding (CBF).
Class-Based Forwarding (CBF).
CBF is configured at the PE1 device, mapping the DSCP values to CBF is configured at the PE1 device, mapping the DSCP values to
respective Transport Classes. This mapping (DSCP peering agreement) respective Transport Classes. This mapping (DSCP peering agreement)
is communicated to CE devices by out-of-band mechanisms. This allows is 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 to encode so that traffic is the provider network and which DSCP to encode so that traffic is
forwarded using the desired Transport Class in the provided network. forwarded using the desired Transport Class in the provided network.
When the IP packet exits the provider network to CE2, PE2 resets the When the IP packet exits the provider network to CE2, PE2 resets the
DSCP based on the DSCP peering agreement with CE2. DSCP based on the DSCP peering agreement with CE2.
12. Applicability to Network Slicing 12. Applicability to Network Slicing
In Network Slicing, the IETF Network Slice Controller (NSC) is 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 (e.g., RSVP-TE, SRTE tunnels with desired characteristics) and
skipping to change at line 2554 skipping to change at line 2531
The NSC can use the Transport Class Identifier (Color value) to The NSC can use the Transport Class Identifier (Color value) to
provision a transport tunnel in a specific IETF Network Slice. provision a transport tunnel in a specific IETF Network Slice.
Furthermore, the NSC can use the Mapping Community on the service Furthermore, the NSC can use the Mapping Community on the service
route to map traffic to the desired IETF Network Slice. route to map traffic to the desired IETF Network Slice.
13. IANA Considerations 13. IANA Considerations
13.1. New BGP SAFI 13.1. New BGP SAFI
IANA has assigned BGP SAFI code 76 for the "Classful Transport SAFI". IANA has assigned BGP SAFI code 76 for the "Classful Transport (CT)"
SAFI.
Registry Group: Subsequent Address Family Identifiers (SAFI) Registry Group: Subsequent Address Family Identifiers (SAFI)
Parameters Parameters
Registry Name: SAFI Values Registry Name: SAFI Values
+=======+=========================+===========+ +=======+=========================+===========+
| Value | Description | Reference | | Value | Description | Reference |
+=======+=========================+===========+ +=======+=========================+===========+
| 76 | Classful Transport SAFI | RFC 9832 | | 76 | Classful Transport (CT) | RFC 9832 |
+-------+-------------------------+-----------+ +-------+-------------------------+-----------+
Table 1 Table 1
This will be used to create new AFI/SAFI pairs for IPv4 and IPv6 This will be used to create new AFI/SAFI pairs for IPv4 and IPv6 BGP
Classful Transport families, namely: CT families, namely:
* "IPv4, Classful Transport" AFI/SAFI = "1/76" for carrying IPv4 * IPv4 BGP CT: AFI/SAFI = 1/76, for carrying IPv4 prefixes.
Classful Transport prefixes.
* "IPv6, Classful Transport" AFI/SAFI = "2/76" for carrying IPv6 * IPv6 BGP CT: AFI/SAFI = 2/76, for carrying IPv6 prefixes.
Classful Transport prefixes.
13.2. New Format for BGP Extended Community 13.2. New Format for BGP Extended Community
IANA has assigned a Format type (Type high = 0xa) of Extended IANA has assigned a Format type (Type high = 0xa) of Extended
Community [RFC4360] for the Transport Class from the following Community [RFC4360] for the Transport Class from the following
registries in the "Border Gateway Protocol (BGP) Extended registries in the "Border Gateway Protocol (BGP) Extended
Communities" registry group: Communities" registry group:
* the "BGP Transitive Extended Community Types" registry and * the "BGP Transitive Extended Community Types" registry and
* the "BGP Non-Transitive Extended Community Types" registry. * the "BGP Non-Transitive Extended Community Types" registry.
The same low-order six bits have been assigned for both allocations. The same low-order six bits have been assigned for both allocations.
This document uses this new Format with subtype 0x2 (route target), 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. called "Transport Class Route Target extended community".
The Non-Transitive Transport Class extended community with subtype The non-transitive Transport Class extended community with subtype
0x2 (route target) is called the "Non-Transitive Transport Class 0x2 (route target) is called the "Non-Transitive Transport Class
Route Target extended community". Route Target extended community".
Taking a reference of [RFC7153], the assignments in the following Following [RFC7153], assignments in the following subsections have
subsections have been made. been made.
13.2.1. Existing Registries 13.2.1. Existing Registries
13.2.1.1. Registries for the "Type" Field 13.2.1.1. Registries for the "Type" Field
13.2.1.1.1. Transitive Types 13.2.1.1.1. Transitive Types
This registry contains values of the high-order octet (the "Type" This registry contains values of the high-order octet (the "Type"
field) of a Transitive Extended Community. field) of a Transitive Extended Community.
skipping to change at line 2664 skipping to change at line 2640
Registry Group: Border Gateway Protocol (BGP) Extended Communities Registry Group: Border Gateway Protocol (BGP) Extended Communities
Registry Name: Transitive Transport Class Extended Community Sub- Registry Name: Transitive Transport Class Extended Community Sub-
Types Types
Note: This registry contains values of the second octet (the "Sub- Note: This registry contains values of the second octet (the "Sub-
Type" field) of an extended community when the value of the first Type" field) of an extended community when the value of the first
octet (the "Type" field) is 0x0a. octet (the "Type" field) is 0x0a.
+===========+=========================+ +===========+=========================+
| Range | Registration Procedures | | Range | Registration Procedure |
+===========+=========================+ +===========+=========================+
| 0x00-0xbf | First Come First Served | | 0x00-0xbf | First Come First Served |
+-----------+-------------------------+ +-----------+-------------------------+
| 0xc0-0xff | IETF Review | | 0xc0-0xff | IETF Review |
+-----------+-------------------------+ +-----------+-------------------------+
Table 4 Table 4
+----------------+--------------+ +----------------+--------------+
| Sub-Type Value | Name | | Sub-Type Value | Name |
skipping to change at line 2697 skipping to change at line 2673
Registry Group: Border Gateway Protocol (BGP) Extended Communities Registry Group: Border Gateway Protocol (BGP) Extended Communities
Registry Name: Non-Transitive Transport Class Extended Community Registry Name: Non-Transitive Transport Class Extended Community
Sub-Types Sub-Types
Note: This registry contains values of the second octet (the "Sub- Note: This registry contains values of the second octet (the "Sub-
Type" field) of an extended community when the value of the first Type" field) of an extended community when the value of the first
octet (the "Type" field) is 0x4a. octet (the "Type" field) is 0x4a.
+===========+=========================+ +===========+=========================+
| Range | Registration Procedures | | Range | Registration Procedure |
+===========+=========================+ +===========+=========================+
| 0x00-0xbf | First Come First Served | | 0x00-0xbf | First Come First Served |
+-----------+-------------------------+ +-----------+-------------------------+
| 0xc0-0xff | IETF Review | | 0xc0-0xff | IETF Review |
+-----------+-------------------------+ +-----------+-------------------------+
Table 6 Table 6
+================+==============+ +================+==============+
| Sub-Type Value | Name | | Sub-Type Value | Name |
skipping to change at line 2749 skipping to change at line 2725
This RFC documents the "Transport Class ID" registry and its assigned This RFC documents the "Transport Class ID" registry and its assigned
values. The value ranges in this registry are either assigned by values. The value ranges in this registry are either assigned by
this document or reserved for Private Use. Because the registry is this document or reserved for Private Use. Because the registry is
complete, it is being published in this RFC rather than as an IANA- complete, it is being published in this RFC rather than as an IANA-
maintained registry. However, note that IANA-related terminology maintained registry. However, note that IANA-related terminology
[BCP26] is used here. [BCP26] is used here.
Registry Name: Transport Class ID Registry Name: Transport Class ID
The registration procedures are as follows: The Registration Procedures are as follows:
+==============+========================+ +==============+========================+
| Value | Registration Procedure | | Value | Registration Procedure |
+==============+========================+ +==============+========================+
| 0 | IETF Review | | 0 | IETF Review |
+--------------+------------------------+ +--------------+------------------------+
| 1-4294967295 | Private Use | | 1-4294967295 | Private Use |
+--------------+------------------------+ +--------------+------------------------+
Table 9 Table 9
As shown in the table below, the Transport Class ID value 0 is As shown in the table below, the Transport Class ID value 0 is
Reserved to represent the "Best-Effort Transport Class ID". This is Reserved to represent the "Best-Effort Transport Class ID". This is
used in the 'Transport Class ID' field of a Transport Route Target used in the 'Transport Class ID' field of a Transport Class RT that
extended community that represents the best-effort transport class. represents the Best-Effort Transport Class.
+==============+================================+ +==============+================================+
| Value | Name | | Value | Name |
+==============+================================+ +==============+================================+
| 0 | Best-Effort Transport Class ID | | 0 | Best-Effort Transport Class ID |
+--------------+--------------------------------+ +--------------+--------------------------------+
| 1-4294967295 | Private Use | | 1-4294967295 | Private Use |
+--------------+--------------------------------+ +--------------+--------------------------------+
Table 10 Table 10
As noted in Sections 4 and 7.10, 'Transport Class ID' is As noted in Sections 4 and 7.10, 'Transport Class ID' is
interchangeable with 'Color'. For purposes of backward compatibility interchangeable with 'Color'. For purposes of backward compatibility
with usage of a 'Color' field in a Color Extended Community as with usage of a 'Color' field in a Color extended community as
specified in [RFC9012] and [RFC9256], the range 1-4294967295 uses specified in [RFC9012] and [RFC9256], the range 1-4294967295 uses
'Private Use' as the Registration Procedure. 'Private Use' as the Registration Procedure.
15. Security Considerations 15. Security Considerations
This document uses the mechanisms from [RFC4760] to define new BGP This document uses the mechanisms from [RFC4760] to define new BGP
address families (AFI/SAFI : 1/76 and 2/76) that carry transport- address families (AFI/SAFI : 1/76 and 2/76) that carry transport
layer endpoints. These address families are explicitly configured layer endpoints. These address families are explicitly configured
and negotiated between BGP speakers, which confines the propagation and negotiated between BGP speakers, which confines the propagation
scope of this reachability information. These routes stay in the scope of this reachability information. These routes stay in the
part of network where the new address family is negotiated and don't part of network where the new address family is negotiated and don't
leak out into the Internet. leak out into the Internet.
Furthermore, procedures defined in Section 9.1 mitigate the risk of Furthermore, procedures defined in Section 9.1 mitigate the risk of
unintended propagation of BGP CT routes across Inter-AS boundaries unintended propagation of BGP CT routes across inter-AS boundaries
even when a BGP CT family is negotiated. BGP import and export even when a BGP CT family is negotiated. BGP import and export
policies are used to control the BGP CT reachability information policies are used to control the BGP CT reachability information
exchanged across AS boundaries. This mitigates the risk of exchanged across AS boundaries. This mitigates the risk of
advertising internal loopback addresses outside the administrative advertising internal loopback addresses outside the administrative
control of the provider network. control of the provider network.
This document does not change the underlying security issues inherent This document does not change the underlying security issues inherent
in the existing BGP protocol, such as those described in [RFC4271] in the existing BGP protocol, such as those described in [RFC4271]
and [RFC4272]. and [RFC4272].
skipping to change at line 2823 skipping to change at line 2799
routes. To avoid such scenarios, it is RECOMMENDED that routes. To avoid such scenarios, it is RECOMMENDED that
implementations support keeping SAFI 76 and SAFI 4 transport routes implementations support keeping SAFI 76 and SAFI 4 transport routes
in separate transport RIBs, distinct from service RIB that contain in separate transport RIBs, distinct from service RIB that contain
SAFI 1 service routes. SAFI 1 service routes.
BGP CT routes distribute label binding using [RFC8277] for the MPLS BGP CT routes distribute label binding using [RFC8277] for the MPLS
data plane; hence, its security considerations apply. data plane; hence, its security considerations apply.
BGP CT routes distribute SRv6 SIDs for SRv6 data planes; hence, the BGP CT routes distribute SRv6 SIDs for SRv6 data planes; hence, the
security considerations of Section 9.3 of [RFC9252] apply. Moreover, security considerations of Section 9.3 of [RFC9252] apply. Moreover,
the SRv6 SID transposition scheme is disabled in BGP CT, as described the SRv6 SID Transposition Scheme is disabled in BGP CT, as described
in Section 7.13, to mitigate the risk of misinterpreting transposed in Section 7.13, to mitigate the risk of misinterpreting transposed
SRv6 SID information as an MPLS label. SRv6 SID information as an MPLS label.
As [RFC4272] discusses, BGP is vulnerable to traffic-diversion As [RFC4272] discusses, BGP is vulnerable to traffic-diversion
attacks. This SAFI route adds a new means by which an attacker could attacks. This SAFI route adds a new means by which an attacker could
cause the traffic to be diverted from its normal path. Potential cause the traffic to be diverted from its normal path. Potential
consequences include "hijacking" of traffic (insertion of an consequences include "hijacking" of traffic (insertion of an
undesired node in the path, which allows for inspection or undesired node in the path, which allows for inspection or
modification of traffic, or avoidance of security controls) or denial modification of traffic, or avoidance of security controls) or denial
of service (directing traffic to a node that doesn't desire to of service (directing traffic to a node that doesn't desire to
skipping to change at line 2965 skipping to change at line 2941
<https://www.rfc-editor.org/info/rfc9012>. <https://www.rfc-editor.org/info/rfc9012>.
[RFC9252] Dawra, G., Ed., Talaulikar, K., Ed., Raszuk, R., Decraene, [RFC9252] Dawra, G., Ed., Talaulikar, K., Ed., Raszuk, R., Decraene,
B., Zhuang, S., and J. Rabadan, "BGP Overlay Services B., Zhuang, S., and J. Rabadan, "BGP Overlay Services
Based on Segment Routing over IPv6 (SRv6)", RFC 9252, Based on Segment Routing over IPv6 (SRv6)", RFC 9252,
DOI 10.17487/RFC9252, July 2022, DOI 10.17487/RFC9252, July 2022,
<https://www.rfc-editor.org/info/rfc9252>. <https://www.rfc-editor.org/info/rfc9252>.
[RFC9830] Previdi, S., Filsfils, C., Talaulikar, K., Ed., Mattes, [RFC9830] Previdi, S., Filsfils, C., Talaulikar, K., Ed., Mattes,
P., and D. Jain, "Advertising Segment Routing Policies in P., and D. Jain, "Advertising Segment Routing Policies in
BGP", RFC 9830, DOI 10.17487/RFC9830, August 2025, BGP", RFC 9830, DOI 10.17487/RFC9830, September 2025,
<https://www.rfc-editor.org/info/rfc9830>. <https://www.rfc-editor.org/info/rfc9830>.
16.2. Informative References 16.2. Informative References
[BCP26] Best Current Practice 26, [BCP26] Best Current Practice 26,
<https://www.rfc-editor.org/info/bcp26>. <https://www.rfc-editor.org/info/bcp26>.
At the time of writing, this BCP comprises the following: At the time of writing, this BCP comprises the following:
Cotton, M., Leiba, B., and T. Narten, "Guidelines for Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP 26, Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, DOI 10.17487/RFC8126, June 2017, RFC 8126, DOI 10.17487/RFC8126, June 2017,
<https://www.rfc-editor.org/info/rfc8126>. <https://www.rfc-editor.org/info/rfc8126>.
[BGP-CT-SRv6] [BGP-CT-SRv6]
Vairavakkalai, K., Ed. and N. Venkataraman, Ed., "BGP CT - Vairavakkalai, K., Ed. and N. Venkataraman, Ed., "BGP CT -
Adaptation to SRv6 dataplane", Work in Progress, Internet- Adaptation to SRv6 dataplane", Work in Progress, Internet-
Draft, draft-ietf-idr-bgp-ct-srv6-06, 9 November 2024, Draft, draft-ietf-idr-bgp-ct-srv6-07, 22 August 2025,
<https://datatracker.ietf.org/doc/html/draft-ietf-idr-bgp- <https://datatracker.ietf.org/doc/html/draft-ietf-idr-bgp-
ct-srv6-06>. ct-srv6-07>.
[BGP-CT-UPDATE-PACKING-TEST]
"update-packing-test-results.txt", 1a75d4d, 25 June 2023,
<https://github.com/ietf-wg-idr/draft-ietf-idr-bgp-
ct/blob/main/update-packing-test-results.txt>.
[BGP-FWD-RR] [BGP-FWD-RR]
Vairavakkalai, K., Ed. and N. Venkataraman, Ed., "BGP Vairavakkalai, K., Ed. and N. Venkataraman, Ed., "BGP
Route Reflector with Next Hop Self", Work in Progress, Route Reflector with Next Hop Self", Work in Progress,
Internet-Draft, draft-ietf-idr-bgp-fwd-rr-03, 17 September Internet-Draft, draft-ietf-idr-bgp-fwd-rr-04, 22 August
2024, <https://datatracker.ietf.org/doc/html/draft-ietf- 2025, <https://datatracker.ietf.org/doc/html/draft-ietf-
idr-bgp-fwd-rr-03>. idr-bgp-fwd-rr-04>.
[BGP-LU-EPE] [BGP-LU-EPE]
Gredler, H., Ed., Vairavakkalai, K., Ed., R, C., Gredler, H., Ed., Vairavakkalai, K., Ed., R, C.,
Rajagopalan, B., Aries, E., and L. Fang, "Egress Peer Rajagopalan, B., Aries, E., and L. Fang, "Egress Peer
Engineering using BGP-LU", Work in Progress, Internet- Engineering using BGP-LU", Work in Progress, Internet-
Draft, draft-gredler-idr-bgplu-epe-16, 14 October 2024, Draft, draft-gredler-idr-bgplu-epe-16, 14 October 2024,
<https://datatracker.ietf.org/doc/html/draft-gredler-idr- <https://datatracker.ietf.org/doc/html/draft-gredler-idr-
bgplu-epe-16>. bgplu-epe-16>.
[FLOWSPEC-REDIR-IP] [FLOWSPEC-REDIR-IP]
Uttaro, J., Haas, J., akarch@cisco.com, Ray, S., Haas, J., Henderickx, W., and A. Simpson, "BGP Flow-Spec
Mohapatra, P., Henderickx, W., Simpson, A., and M. Texier, Redirect-to-IP Action", Work in Progress, Internet-Draft,
"BGP Flow-Spec Redirect-to-IP Action", Work in Progress, draft-ietf-idr-flowspec-redirect-ip-04, 2 September 2025,
Internet-Draft, draft-ietf-idr-flowspec-redirect-ip-03, 8 <https://datatracker.ietf.org/doc/html/draft-ietf-idr-
September 2024, <https://datatracker.ietf.org/doc/html/ flowspec-redirect-ip-04>.
draft-ietf-idr-flowspec-redirect-ip-03>.
[INTAREA-TUNNELS] [INTAREA-TUNNELS]
Touch, J. D. and M. Townsley, "IP Tunnels in the Internet Touch, J. D. and M. Townsley, "IP Tunnels in the Internet
Architecture", Work in Progress, Internet-Draft, draft- Architecture", Work in Progress, Internet-Draft, draft-
ietf-intarea-tunnels-15, 9 May 2025, ietf-intarea-tunnels-15, 9 May 2025,
<https://datatracker.ietf.org/doc/html/draft-ietf-intarea- <https://datatracker.ietf.org/doc/html/draft-ietf-intarea-
tunnels-15>. tunnels-15>.
[Intent-Routing-Color] [Intent-Routing-Color]
Hegde, S., Rao, D., Uttaro, J., Bogdanov, A., and L. Hegde, S., Rao, D., Uttaro, J., Bogdanov, A., and L.
skipping to change at line 3038 skipping to change at line 3008
[MNH] Vairavakkalai, K., Ed., Jeganathan, J. M., Nanduri, M., [MNH] Vairavakkalai, K., Ed., Jeganathan, J. M., Nanduri, M.,
and A. R. Lingala, "BGP MultiNexthop Attribute", Work in and A. R. Lingala, "BGP MultiNexthop Attribute", Work in
Progress, Internet-Draft, draft-ietf-idr-multinexthop- Progress, Internet-Draft, draft-ietf-idr-multinexthop-
attribute-04, 25 March 2025, attribute-04, 25 March 2025,
<https://datatracker.ietf.org/doc/html/draft-ietf-idr- <https://datatracker.ietf.org/doc/html/draft-ietf-idr-
multinexthop-attribute-04>. multinexthop-attribute-04>.
[MPLS-NS] Vairavakkalai, K., Ed., Jeganathan, J. M., Ramadenu, P., [MPLS-NS] Vairavakkalai, K., Ed., Jeganathan, J. M., Ramadenu, P.,
and I. Means, "BGP Signaled MPLS Namespaces", Work in and I. Means, "BGP Signaled MPLS Namespaces", Work in
Progress, Internet-Draft, draft-kaliraj-bess-bgp-sig- Progress, Internet-Draft, draft-kaliraj-bess-bgp-mpls-
private-mpls-labels-09, 9 November 2024, namespaces-01, 21 August 2025,
<https://datatracker.ietf.org/doc/html/draft-kaliraj-bess- <https://datatracker.ietf.org/doc/html/draft-kaliraj-bess-
bgp-sig-private-mpls-labels-09>. bgp-mpls-namespaces-01>.
[PACKING-TEST]
"update-packing-test-results.txt", 1a75d4d, 25 June 2023,
<https://github.com/ietf-wg-idr/draft-ietf-idr-bgp-
ct/blob/main/update-packing-test-results.txt>.
[PCEP-RSVP-COLOR] [PCEP-RSVP-COLOR]
Rajagopalan, B., Beeram, V. P., Peng, S., Koldychev, M., Rajagopalan, B., Beeram, V. P., Peng, S., Koldychev, M.,
and G. S. Mishra, "Path Computation Element Protocol and G. S. Mishra, "Path Computation Element Protocol
(PCEP) Extension for Color", Work in Progress, Internet- (PCEP) Extension for Color", Work in Progress, Internet-
Draft, draft-ietf-pce-pcep-color-12, 26 February 2025, Draft, draft-ietf-pce-pcep-color-12, 26 February 2025,
<https://datatracker.ietf.org/doc/html/draft-ietf-pce- <https://datatracker.ietf.org/doc/html/draft-ietf-pce-
pcep-color-12>. pcep-color-12>.
[PCEP-SRPOLICY] [PCEP-SRPOLICY]
skipping to change at line 3118 skipping to change at line 3093
Mechanisms described in [BGP-LU-EPE] also apply to the BGP CT family. Mechanisms described in [BGP-LU-EPE] also apply to the BGP CT family.
The Peer/32 or Peer/128 EPE route MAY be originated in the BGP CT The Peer/32 or Peer/128 EPE route MAY be originated in the BGP CT
family with the appropriate Mapping Community (e.g., transport- family with the appropriate Mapping Community (e.g., transport-
target:0:100), thus allowing an EPE path to the peer that satisfies target:0:100), thus allowing an EPE path to the peer that satisfies
the desired SLA. the desired SLA.
Appendix B. Applicability to Intra-AS and Different Inter-AS Appendix B. Applicability to Intra-AS and Different Inter-AS
Deployments Deployments
As described in Section 10 of [RFC4364], in an Option C network, As described in Section 10 of [RFC4364], in an option C network,
service routes (VPN-IPv4) are neither maintained nor distributed by service routes (VPN-IPv4) are neither maintained nor distributed by
the ASBRs. Transport routes are maintained in the ASBRs and the ASBRs. Transport routes are maintained in the ASBRs and
propagated in BGP LU or BGP CT. propagated in BGP LU or BGP CT.
Section 8 illustrates how constructs of BGP CT work in an inter-AS Section 8 illustrates how constructs of BGP CT work in an inter-AS
Option C deployment. The BGP CT constructs: AFI/SAFI 1/76, Transport option C deployment. The BGP CT constructs: AFI/SAFI 1/76, Transport
Class, and Resolution Scheme are used in an inter-AS Option C Class, and Resolution Scheme are used in an inter-AS option C
deployment. deployment.
In Intra-AS and Inter-AS option A and option B scenarios, AFI/SAFI In intra-AS and inter-AS option A and option B scenarios, AFI/SAFI
1/76 may not be used, but the Transport Class and Resolution Scheme 1/76 may not be used, but the Transport Class and Resolution Scheme
mechanisms are used to provide service mapping. mechanisms are used to provide service mapping.
This section illustrates how BGP CT constructs work in Intra-AS and This section illustrates how BGP CT constructs work in intra-AS and
Inter-AS Option A and B deployment scenarios. inter-AS option A and option B deployment scenarios.
B.1. Intra-AS Use Case B.1. Intra-AS Use Case
B.1.1. Topology B.1.1. Topology
[RR11] [RR11]
| |
+ +
[CE21]---[PE11]-------[P1]------[PE12]------[CE31] [CE21]---[PE11]-------[P1]------[PE12]------[CE31]
skipping to change at line 3162 skipping to change at line 3137
Figure 14 shows a provider network Autonomous System, AS1. It serves Figure 14 shows a provider network Autonomous System, AS1. It serves
customers AS2 and AS3. Traffic direction being described is CE21 to customers AS2 and AS3. Traffic direction being described is CE21 to
CE31. CE31 may request a specific SLA (e.g., Gold for this traffic) CE31. CE31 may request a specific SLA (e.g., Gold for this traffic)
when traversing this provider network. when traversing this provider network.
B.1.2. Transport Layer B.1.2. Transport Layer
AS1 uses RSVP-TE intra-domain tunnels between PE11 and PE12. And it AS1 uses RSVP-TE intra-domain tunnels between PE11 and PE12. And it
uses LDP tunnels for best-effort traffic. uses LDP tunnels for best-effort traffic.
The network has two Transport classes: Gold with Transport Class ID The network has two TCs: Gold with TC ID 100 and Bronze with TC ID
100 and Bronze with Transport Class ID 200. These transport classes 200. These TCs are provisioned at the PEs. This creates the
are provisioned at the PEs. This creates the Resolution Schemes for Resolution Schemes for these TCs at these PEs.
these transport classes at these PEs.
The following tunnels exist for the Gold transport class: The following tunnels exist for the Gold TC:
* PE11_to_PE12_gold - RSVP-TE tunnel * PE11_to_PE12_gold - RSVP-TE tunnel
* PE12_to_PE11_gold - RSVP-TE tunnel * PE12_to_PE11_gold - RSVP-TE tunnel
The following tunnels exist for Bronze transport class: The following tunnels exist for Bronze TC:
* PE11_to_PE12_bronze - RSVP-TE tunnel * PE11_to_PE12_bronze - RSVP-TE tunnel
* PE11_to_PE12_bronze - RSVP-TE tunnel * PE11_to_PE12_bronze - RSVP-TE tunnel
These tunnels are provisioned to belong to transport class 100 or These tunnels are provisioned to belong to Transport Class 100 or
200. 200.
B.1.3. Service-Layer Route Exchange B.1.3. Service Layer Route Exchange
Service nodes PE11 and PE12 negotiate service families (AFI/SAFI 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 the next hop unchanged. 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 There are no tunnels for Transport Class 100 or 200 from RR11 to the
PEs. PEs.
Forwarding happens using service routes at service nodes PE11 and Forwarding happens using service routes at service nodes PE11 and
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. FIB in the provider network.
CE31 advertises a route, for example, prefix 203.0.113.31 with the CE31 advertises a route, for example, prefix 203.0.113.31 with the
next hop set to itself to PE12. CE31 can attach a Mapping Community next hop set to itself to PE12. CE31 can attach a Mapping Community
Color:0:100 on this route to indicate its request for a Gold SLA. color:0:100 on this route to indicate its request for a Gold SLA.
Or, PE12 can attach the same using locally configured policies. Or, PE12 can attach the same using locally configured policies.
Consider CE31 getting VPN service from PE12. The RD:203.0.113.31 Consider CE31 getting VPN service from PE12. The RD:203.0.113.31
route is readvertised in AFI/SAFI 1/128 by PE12 with the next hop set route is readvertised in AFI/SAFI 1/128 by PE12 with the next hop set
to itself (192.0.2.12) and label V-L1 to RR11 with the Mapping to itself (192.0.2.12) and label V-L1 to RR11 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
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 the PE11_to_PE12_gold Now PE11 can resolve the PNH 192.0.2.12 using the PE11_to_PE12_gold
RSVP TE LSP. RSVP TE LSP.
The IP FIB at PE11 VRF will have a route for 203.0.113.31 with a next The IP FIB at PE11 VRF will have a route for 203.0.113.31 with a next
hop when resolved using the Resolution Scheme belonging to the hop when resolved using the Resolution Scheme belonging to the
mapping community Color:0:100, points to a PE11_to_PE12_gold tunnel. Mapping Community color:0:100, points to a PE11_to_PE12_gold tunnel.
BGP CT AFI/SAFI 1/76 is not used in this Intra-AS deployment. But 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. preserve end-to-end SLA.
B.2. Inter-AS Option A Use Case B.2. Inter-AS Option A Use Case
B.2.1. Topology B.2.1. Topology
[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
Figure 15: BGP CT Inter-AS Option A Figure 15: BGP CT Inter-AS option A
This example in Figure 15 shows two provider network Autonomous This example in Figure 15 shows two provider network Autonomous
systems AS1, AS2. They serve L3VPN customers AS3, AS4 respectively. systems AS1, AS2. They serve L3VPN customers AS3, AS4 respectively.
The ASBRs ASBR11 and ASBR21 have IP VRFs connected directly. The The ASBRs ASBR11 and ASBR21 have IP VRFs connected directly. The
inter-AS link is IP enabled with no MPLS forwarding. inter-AS link is IP enabled with no MPLS forwarding.
Traffic direction being described is CE31 to CE41. CE41 may request Traffic direction being described is CE31 to CE41. CE41 may request
a specific SLA (e.g., Gold for this traffic), when traversing these a specific SLA (e.g., Gold for this traffic), when traversing these
provider core networks. provider core networks.
B.2.2. Transport Layer B.2.2. Transport Layer
AS1 uses RSVP-TE intra-domain tunnels between PE11 and ASBR11. And AS1 uses RSVP-TE intra-domain tunnels between PE11 and ASBR11. And
LDP tunnels for best-effort traffic. AS2 uses SRTE intra-domain LDP tunnels for best-effort traffic. AS2 uses SRTE intra-domain
tunnels between ASBR21 and PE21, and L-ISIS for best-effort tunnels. tunnels between ASBR21 and PE21, and L-ISIS for best-effort tunnels.
The networks have two Transport classes: Gold with Transport Class ID The networks have two TCs: Gold with TC ID 100, Bronze with TC ID
100, Bronze with Transport Class ID 200. These transport classes are 200. These TCs are provisioned at the PEs and ASBRs. This creates
provisioned at the PEs and ASBRs. This creates the Resolution the Resolution Schemes for these TCs at these PEs and ASBRs.
Schemes for these transport classes at these PEs and ASBRs.
Following tunnels exist for Gold transport class. Following tunnels exist for Gold TC.
* PE11_to_ASBR11_gold - RSVP-TE tunnel * PE11_to_ASBR11_gold - RSVP-TE tunnel
* ASBR11_to_PE11_gold - RSVP-TE tunnel * ASBR11_to_PE11_gold - RSVP-TE tunnel
* PE21_to_ASBR21_gold - SRTE tunnel * PE21_to_ASBR21_gold - SRTE tunnel
* ASBR21_to_PE21_gold - SRTE tunnel * ASBR21_to_PE21_gold - SRTE tunnel
Following tunnels exist for Bronze transport class. Following tunnels exist for Bronze TC.
* PE11_to_ASBR11_bronze - RSVP-TE tunnel * PE11_to_ASBR11_bronze - RSVP-TE tunnel
* ASBR11_to_PE11_bronze - RSVP-TE tunnel * ASBR11_to_PE11_bronze - RSVP-TE tunnel
* PE21_to_ASBR21_bronze - SRTE tunnel * PE21_to_ASBR21_bronze - SRTE tunnel
* ASBR21_to_PE21_bronze - SRTE tunnel * ASBR21_to_PE21_bronze - SRTE tunnel
These tunnels are provisioned to belong to transport class 100 or These tunnels are provisioned to belong to TC 100 or 200.
200.
B.2.3. Service Layer Route Exchange B.2.3. Service Layer Route Exchange
Service nodes PE11, ASBR11 negotiate service family (AFI/SAFI 1/128) Service nodes PE11, ASBR11 negotiate service family (AFI/SAFI 1/128)
on the BGP session with RR11. Service helper RR11 reflects service on the BGP session with RR11. Service helper RR11 reflects service
routes between the PE11 and ASBR11 with next hop unchanged. routes between the PE11 and ASBR11 with next hop unchanged.
Similarly, in AS2 PE21, ASBR21 negotiate service family (AFI/SAFI 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. between the PE21 and ASBR21 with next hop unchanged.
CE41 advertises a route for example prefix 203.0.113.41 with next hop CE41 advertises a route for example prefix 203.0.113.41 with next hop
self to PE21 VRF. CE41 can attach a Mapping Community Color:0:100 on self to PE21 VRF. CE41 can attach a Mapping Community color:0:100 on
this route, to indicate its request for Gold SLA. Or, PE21 can this route, to indicate its request for Gold SLA. Or, PE21 can
attach the same using locally configured policies. attach the same using locally configured policies.
Consider, CE41 is getting VPN service from PE21. The RD:203.0.113.41 Consider, CE41 is getting VPN service from PE21. The RD:203.0.113.41
route is readvertised in AFI/SAFI 1/128 by PE21 with next hop self route is readvertised in AFI/SAFI 1/128 by PE21 with next hop self
(203.0.113.21) and label V-L1 to RR21 with the Mapping Community (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 ASBR21 via color:0:100 attached. This AFI/SAFI 1/128 route reaches ASBR21 via
RR21 with the next hop unchanged as PE21 and label V-L1. Now ASBR21 RR21 with the next hop unchanged as PE21 and label V-L1. Now ASBR21
can resolve the PNH 203.0.113.21 using ASBR21_to_PE21_gold SRTE LSP. can resolve the PNH 203.0.113.21 using ASBR21_to_PE21_gold SRTE LSP.
The IP FIB at ASBR21 VRF will have a route for 203.0.113.41 with a 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 next hop resolved using Resolution Scheme associated with mapping
community Color:0:100, pointing to ASBR21_to_PE21_gold tunnel. community color:0:100, pointing to ASBR21_to_PE21_gold tunnel.
This route is readvertised with the next hop set to itself by ASBR21 This route is readvertised with the next hop set to itself by ASBR21
to ASBR11 on a BGP session in the VRF. The single-hop EBGP session to ASBR11 on a BGP session in the VRF. The single-hop EBGP session
endpoints are interface addresses. ASBR21 and ASBR11 act like a CE endpoints are interface addresses. ASBR21 and ASBR11 act like a CE
to each other. The previously mentioned process repeats in AS1 until to each other. The previously mentioned process repeats in AS1 until
the route reaches PE11 and resolves over the PE11_to_ASBR11_gold RSVP the route reaches PE11 and resolves over the PE11_to_ASBR11_gold RSVP
TE tunnel. TE tunnel.
Traffic traverses as an unlabeled IP packet on the following legs: Traffic traverses as an unlabeled IP packet on the following legs:
CE31-PE11, ASBR11-ASBR21, PE21-CE41. And it uses MPLS forwarding CE31-PE11, ASBR11-ASBR21, PE21-CE41. And it uses MPLS forwarding
inside the AS1 and AS2 core. inside the AS1 and AS2 core.
BGP CT AFI/SAFI 1/76 is not used in this Inter-AS Option B 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. are used to preserve an end-to-end SLA.
B.3. Inter-AS Option B Use Case B.3. Inter-AS Option B Use Case
B.3.1. Topology B.3.1. Topology
[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
Figure 16: BGP CT Inter-AS Option B Figure 16: BGP CT Inter-AS option B
Figure 16 shows two provider network Autonomous Systems: AS1 and AS2. Figure 16 shows two provider network Autonomous Systems: AS1 and AS2.
They serve L3VPN customers AS3 and AS4, respectively. The ASBRs They serve L3VPN customers AS3 and AS4, respectively. The ASBRs
ASBR12 and ASBR21 don't have any IP VRFs. The inter-AS link is MPLS- ASBR12 and ASBR21 don't have any IP VRFs. The inter-AS link is MPLS-
forwarding enabled. forwarding enabled.
Traffic direction being described is CE31 to CE41. CE41 may request Traffic direction being described is CE31 to CE41. CE41 may request
a specific SLA (e.g., Gold for this traffic) when traversing these a specific SLA (e.g., Gold for this traffic) when traversing these
provider core networks. provider core networks.
B.3.2. Transport Layer B.3.2. Transport Layer
AS1 uses RSVP-TE intra-domain tunnels between PE11 and ASBR21 and LDP AS1 uses RSVP-TE intra-domain tunnels between PE11 and ASBR21 and LDP
tunnels for best-effort traffic. AS2 uses SRTE intra-domain tunnels tunnels for best-effort traffic. AS2 uses SRTE intra-domain tunnels
between ASBR21 and PE22 along with L-ISIS for best-effort tunnels. between ASBR21 and PE22 along with L-ISIS for best-effort tunnels.
The networks have two Transport classes: Gold with Transport Class ID The networks have two TCs: Gold with TC ID 100 and Bronze with TC ID
100 and Bronze with Transport Class ID 200. These transport classes 200. These TCs are provisioned at the PEs and ASBRs. This creates
are provisioned at the PEs and ASBRs. This creates the Resolution the Resolution Schemes for these Transport Classes at these PEs and
Schemes for these transport classes at these PEs and ASBRs. ASBRs.
The following tunnels exist for Gold transport class: The following tunnels exist for Gold TC:
* PE11_to_ASBR12_gold - RSVP-TE tunnel * PE11_to_ASBR12_gold - RSVP-TE tunnel
* ASBR12_to_PE11_gold - RSVP-TE tunnel * ASBR12_to_PE11_gold - RSVP-TE tunnel
* PE22_to_ASBR21_gold - SRTE tunnel * PE22_to_ASBR21_gold - SRTE tunnel
* ASBR21_to_PE22_gold - SRTE tunnel * ASBR21_to_PE22_gold - SRTE tunnel
The following tunnels exist for Bronze transport class: The following tunnels exist for Bronze TC:
* PE11_to_ASBR12_bronze - RSVP-TE tunnel * PE11_to_ASBR12_bronze - RSVP-TE tunnel
* ASBR12_to_PE11_bronze - RSVP-TE tunnel * ASBR12_to_PE11_bronze - RSVP-TE tunnel
* PE22_to_ASBR21_bronze - SRTE tunnel * PE22_to_ASBR21_bronze - SRTE tunnel
* ASBR21_to_PE22_bronze - SRTE tunnel * ASBR21_to_PE22_bronze - SRTE tunnel
These tunnels are provisioned to belong to transport class 100 or These tunnels are provisioned to belong to TC 100 or 200.
200.
B.3.3. Service-Layer Route Exchange B.3.3. Service Layer Route Exchange
Service nodes PE11 and ASBR12 negotiate service family (AFI/SAFI 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 the next hop service routes between the PE11 and ASBR12 with the next hop
unchanged. unchanged.
Similarly, in AS2 PE22, ASBR21 negotiates service family (AFI/SAFI Similarly, in AS2 PE22, ASBR21 negotiates 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 PE22 and ASBR21 with the next hop unchanged. between PE22 and ASBR21 with the next hop unchanged.
ASBR21 and ASBR12 negotiate AFI/SAFI 1/128 between them and ASBR21 and ASBR12 negotiate AFI/SAFI 1/128 between them and
readvertise L3VPN routes with the next hop set to themselves, readvertise L3VPN routes with the next hop set to themselves,
allocating new labels. The single-hop EBGP session endpoints are allocating new labels. The single-hop EBGP session endpoints are
interface addresses. interface addresses.
CE41 advertises a route, for example, prefix 203.0.113.41 with the CE41 advertises a route, for example, prefix 203.0.113.41 with the
next hop set to itself to PE22 VRF. CE41 can attach a Mapping next hop set to itself to PE22 VRF. CE41 can attach a Mapping
Community Color:0:100 on this route to indicate its request for the Community color:0:100 on this route to indicate its request for the
Gold SLA. Or, PE22 can attach the same using locally configured Gold SLA. Or, PE22 can attach the same using locally configured
policies. policies.
Consider CE41 getting VPN service from PE22. The RD:203.0.113.41 Consider CE41 getting VPN service from PE22. The RD:203.0.113.41
route is readvertised in AFI/SAFI 1/128 by PE22 with the next hop set route is readvertised in AFI/SAFI 1/128 by PE22 with the next hop set
to itself (192.0.2.22) and label V-L1 to RR23 with the Mapping to itself (192.0.2.22) and label V-L1 to RR23 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 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. SRTE LSP.
Next, ASBR21 readvertises the RD:203.0.113.41 route with the next hop Next, ASBR21 readvertises the RD:203.0.113.41 route with the next hop
set to itself to ASBR12 with a newly allocated MPLS label V-L2. set to itself to ASBR12 with a newly allocated MPLS label V-L2.
Forwarding for this label is installed to Swap V-L1, and Push labels Forwarding for this label is installed to Swap V-L1, and Push labels
for ASBR21_to_PE22_gold tunnel. for ASBR21_to_PE22_gold tunnel.
ASBR12 further readvertises the RD:203.0.113.41 route via RR13 to ASBR12 further readvertises the RD:203.0.113.41 route via RR13 to
PE11 with the next hop set to itself, 192.0.2.12. PE11 resolves the PE11 with the next hop set to itself, 192.0.2.12. PE11 resolves the
next hop 192.0.2.12 over PE11_to_ASBR12_gold RSVP TE tunnel. next hop 192.0.2.12 over PE11_to_ASBR12_gold RSVP TE tunnel.
Traffic traverses as the IP packet on the following legs: CE31-PE11 Traffic traverses as the IP packet on the following legs: CE31-PE11
and PE21-CE41. And it uses MPLS forwarding on the ASBR11-ASBR21 link and PE21-CE41. And it uses MPLS forwarding on the ASBR11-ASBR21 link
and inside the AS1-AS2 core. and inside the AS1-AS2 core.
BGP CT AFI/SAFI 1/76 is not used in this Inter-AS Option B 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. are used to preserve an end-to-end SLA.
Appendix C. Why reuse RFCs 8277 and 4364? Appendix C. Why reuse RFCs 8277 and 4364?
[RFC4364] is one of the key design patterns produced by the [RFC4364] is one of the key design patterns produced by the
networking industry. It introduced virtualization and allowed networking industry. It introduced virtualization and allowed
sharing of resources in the service provider space with multiple sharing of resources in the service provider space with multiple
tenant networks, providing isolated and secure Layer 3 VPN services. tenant networks, providing isolated and secure Layer 3 VPN services.
This design pattern has been reused since to provide other service- This design pattern has been reused since to provide other service
layer virtualizations like Layer 2 virtualization (VPLS, L2VPN, layer virtualizations like Layer 2 virtualization (VPLS, L2VPN,
EVPN), ISO virtualization, ATM virtualization, and Flowspec VPN. EVPN), ISO virtualization, ATM virtualization, and Flowspec VPN.
It is to be noted that these services have different NLRI encodings. It is to be noted that these services have different NLRI encodings.
The L3VPN Service family that binds the MPLS label to an IP prefix The L3VPN service family that binds the MPLS label to an IP prefix
uses the encoding described in [RFC8277] and others define different uses the encoding described in [RFC8277] and others define different
NLRI encodings. NLRI encodings.
BGP CT reuses the procedures described in [RFC4364] to slice a BGP CT reuses the procedures described in [RFC4364] to slice a
transport network into multiple transport planes that different transport network into multiple transport planes that different
service routes can bind to using color. service routes can bind to using color.
BGP CT reuses [RFC8277] because it precisely fits the purpose. That BGP CT reuses [RFC8277] because it precisely fits the purpose. That
is, in an MPLS network, BGP CT needs to bind the MPLS label for is, in an MPLS network, BGP CT needs to bind the MPLS label for
transport endpoints, which are IPv4 or IPv6 endpoints, and transport endpoints, which are IPv4 or IPv6 endpoints, and
skipping to change at line 3466 skipping to change at line 3437
In the future, if [RFC8277] evolves into a typed NLRI that does not In the future, if [RFC8277] evolves into a typed NLRI that does not
carry Label in the NLRI, BGP CT will be compatible with that as well. carry Label in the NLRI, BGP CT will be compatible with that as well.
In essence, BGP CT encoding is compatible with existing deployed In essence, BGP CT encoding is compatible with existing deployed
technologies ([RFC4364] and [RFC8277]) and will adapt to any changes technologies ([RFC4364] and [RFC8277]) and will adapt to any changes
mechanisms from [RFC8277] undergo in future. mechanisms from [RFC8277] undergo in future.
This approach leverages the benefits of time-tested design patterns This approach leverages the benefits of time-tested design patterns
proposed in [RFC4364] and [RFC8277]. Moreover, this approach greatly proposed in [RFC4364] and [RFC8277]. Moreover, 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 considerations as it complements and works well with existing
protocol machineries: this problem does not need a brand new NLRI and protocol machinery: this problem does not need a brand new NLRI and
procedures. procedures.
BGP CT design also avoids overloading the NLRI MPLS Label field from BGP CT design also avoids overloading the NLRI MPLS label field from
[RFC8277] with information related to the non-MPLS data plane because [RFC8277] with information related to the non-MPLS data plane because
it leads to backward-compatibility issues. it leads to backward-compatibility issues.
C.1. Update Packing Considerations C.1. Update Packing Considerations
BGP CT carries transport class as an attribute. This means routes BGP CT carries Transport Class as an attribute. This means routes
that don't share the same transport class cannot be packed into the that don't share the same Transport Class cannot be packed into the
same BGP UPDATE message. Update packing in BGP CT will be similar to same BGP UPDATE message. Update packing in BGP CT will be similar to
family routes from [RFC8277] carrying attributes like communities or family routes from [RFC8277] carrying attributes like communities or
extended communities. Service families like AFI/SAFI 1/128 have extended communities. Service families like AFI/SAFI 1/128 have
considerably more scale than transport families like AFI/SAFI 1/4 or considerably more scale than transport families like AFI/SAFI 1/4 or
AFI/SAFI 1/76, which carry only loopbacks. Update packing mechanisms AFI/SAFI 1/76, which carry only loopbacks. Update packing mechanisms
that scale for AFI/SAFI 1/128 routes will scale similarly for AFI/ that scale for AFI/SAFI 1/128 routes will scale similarly for AFI/
SAFI 1/76 routes. SAFI 1/76 routes.
Section 6.3.2.1 of [Intent-Routing-Color] suggests scaling numbers Section 6.3.2.1 of [Intent-Routing-Color] suggests scaling numbers
for a transport network where BGP CT can be deployed. Experiments for a transport network where BGP CT can be deployed. Experiments
were conducted with this scale to find the convergence time with BGP were conducted with this scale to find the convergence time with BGP
CT for those scaling numbers. Scenarios involving BGP CT carrying CT for those scaling numbers. Scenarios involving BGP CT carrying
IPv4 and IPv6 endpoints with an MPLS label were tested. Tests with IPv4 and IPv6 endpoints with an MPLS label were tested. Tests with
BGP CT IPv6 endpoints and SRv6 SID are planned. BGP CT IPv6 endpoints and SRv6 SID are planned.
Tests were conducted with a 1.9 million BGP CT route scale (387K Tests were conducted with a 1.9 million BGP CT route scale (387K
endpoints in 5 transport classes). Initial convergence time for all endpoints in 5 TCs). Initial convergence time for all cases was less
cases was less than 2 minutes, which compares favorably with user than 2 minutes, which compares favorably with user expectation for
expectation for such a scale. This experiment proves that carrying such a scale. This experiment proves that carrying Transport Class
transport-class information as an attribute keeps BGP convergence information as an attribute keeps BGP convergence within an
within an acceptable range. Details of the experiment and test acceptable range. Details of the experiment and test results are
results are available in [BGP-CT-UPDATE-PACKING-TEST]. available in [PACKING-TEST].
Furthermore, even in today's BGP LU deployments, each egress node Furthermore, even in today's BGP LU deployments, each egress node
originates a BGP LU route for its loopback, with some attributes like originates a BGP LU route for its loopback, with some attributes like
community identifying the originating node or region and an AIGP community identifying the originating node or region and an AIGP
attribute. These attributes may be unique per egress node; thus, attribute. These attributes may be unique per egress node; thus,
they do not help with update packing in transport family routes. they do not help with update packing in transport family routes.
Appendix D. Scaling Using BGP MPLS Namespaces Appendix D. Scaling Using BGP MPLS Namespaces
This document considers the scaling scenario suggested in This document considers the scaling scenario suggested in
Section 6.3.2.1 of [Intent-Routing-Color] where 300K nodes exist in Section 6.3.2.1 of [Intent-Routing-Color] where 300K nodes exist in
the network with 5 transport classes. the network with 5 TCs.
This may result in 1.5M transport layer routes and MPLS transit 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. nodes' MPLS-forwarding resources.
Section 6.2 of [MPLS-NS] describes how MPLS Namespaces mechanism is Section 6.2 of [MPLS-NS] describes how MPLS Namespaces mechanism is
used to scale such a network. This approach reduces the number of used to scale such a network. This approach reduces the number of
PNHs that are globally visible in the network, thus reducing 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. also.
Acknowledgements Acknowledgements
The authors thank Jeff Haas, John Scudder, Susan Hares, Dongjie The authors thank Jeff Haas, John Scudder, Susan Hares, Dongjie
(Jimmy), Moses Nagarajah, Jeffrey (Zhaohui) Zhang, Joel Halpern, (Jimmy), Moses Nagarajah, Jeffrey (Zhaohui) Zhang, Joel Halpern,
Jingrong Xie, Mohamed Boucadair, Greg Skinner, Simon Leinen, Jingrong Xie, Mohamed Boucadair, Greg Skinner, Simon Leinen,
Navaneetha Krishnan, Ravi M R, Chandrasekar Ramachandran, Shradha Navaneetha Krishnan, Ravi M R, Chandrasekar Ramachandran, Shradha
 End of changes. 287 change blocks. 
588 lines changed or deleted 559 lines changed or added

This html diff was produced by rfcdiff 1.48.