idnits 2.17.00 (12 Aug 2021) /tmp/idnits22859/draft-kaliraj-idr-bgp-classful-transport-planes-14.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 29 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document date (26 April 2022) is 18 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'TBD' is mentioned on line 808, but not defined == Missing Reference: 'RR26' is mentioned on line 870, but not defined == Missing Reference: 'RR27' is mentioned on line 870, but not defined == Missing Reference: 'RR16' is mentioned on line 870, but not defined == Missing Reference: 'CE41' is mentioned on line 875, but not defined == Missing Reference: 'PE25' is mentioned on line 875, but not defined == Missing Reference: 'P28' is mentioned on line 875, but not defined == Missing Reference: 'P29' is mentioned on line 875, but not defined == Missing Reference: 'P15' is mentioned on line 875, but not defined == Missing Reference: 'CE31' is mentioned on line 875, but not defined -- Possible downref: Non-RFC (?) normative reference: ref. 'MPLS-NAMESPACES' -- Possible downref: Non-RFC (?) normative reference: ref. 'PCEP-RSVP-COLOR' -- Possible downref: Non-RFC (?) normative reference: ref. 'RTC-Ext' -- Possible downref: Non-RFC (?) normative reference: ref. 'Seamless-SR' == Outdated reference: A later version (-17) exists of draft-ietf-idr-segment-routing-te-policy-08 -- Possible downref: Non-RFC (?) normative reference: ref. 'SRV6-INTER-DOMAIN' -- Possible downref: Non-RFC (?) normative reference: ref. 'SRV6-MPLS-AGRWL' -- Possible downref: Non-RFC (?) normative reference: ref. 'SRV6-SERVICES' Summary: 0 errors (**), 0 flaws (~~), 12 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group K. Vairavakkalai, Ed. 3 Internet-Draft N. Venkataraman 4 Intended status: Standards Track B. Rajagopalan 5 Expires: 28 October 2022 Juniper Networks, Inc. 6 G. Mishra 7 Verizon Communications Inc. 8 M. Khaddam 9 Cox Communications Inc. 10 X. Xu 11 Capitalonline. 12 R. Szarecki 13 Google. 14 J. Gowda 15 Extreme Networks 16 Yadlapalli 17 ATT 18 26 April 2022 20 BGP Classful Transport Planes 21 draft-kaliraj-idr-bgp-classful-transport-planes-14 23 Abstract 25 This document specifies a mechanism, referred to as "service 26 mapping", to express association of overlay routes with underlay 27 routes satisfying a certain SLA, using BGP. The document describes a 28 framework for classifying underlay routes into transport classes, and 29 mapping service routes to specific transport class. 31 The "Transport class" construct maps to a desired SLA, and can be 32 used to realize the "Topology Slice" in 5G Network slicing 33 architecture. 35 This document specifies BGP protocol procedures that enable 36 dissemination of such service mapping information that may span 37 multiple co-operating administrative domains. These domains may be 38 administetered by the same provider or closely co-ordinating provider 39 networks. 41 It makes it possible to advertise multiple tunnels to the same 42 destination address, thus avoiding need of multiple loopbacks on the 43 egress node. 45 A new BGP transport layer address family (SAFI 76) is defined for 46 this purpose that uses RFC-4364 technology and follows RFC-8277 NLRI 47 encoding. This new address family is called "BGP Classful 48 Transport", aka BGP CT. 50 It carries transport prefixes across tunnel domain boundaries (e.g. 51 in Inter-AS Option-C networks), parallel to BGP LU (SAFI 4) . It 52 disseminates "Transport class" information for the transport prefixes 53 across the participating domains, which is not possible with BGP LU. 54 This makes the end-to-end network a "Transport Class" aware tunneled 55 network. 57 Requirements Language 59 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 60 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 61 document are to be interpreted as described in RFC 2119 [RFC2119]. 63 Status of This Memo 65 This Internet-Draft is submitted in full conformance with the 66 provisions of BCP 78 and BCP 79. 68 Internet-Drafts are working documents of the Internet Engineering 69 Task Force (IETF). Note that other groups may also distribute 70 working documents as Internet-Drafts. The list of current Internet- 71 Drafts is at https://datatracker.ietf.org/drafts/current/. 73 Internet-Drafts are draft documents valid for a maximum of six months 74 and may be updated, replaced, or obsoleted by other documents at any 75 time. It is inappropriate to use Internet-Drafts as reference 76 material or to cite them other than as "work in progress." 78 This Internet-Draft will expire on 28 October 2022. 80 Copyright Notice 82 Copyright (c) 2022 IETF Trust and the persons identified as the 83 document authors. All rights reserved. 85 This document is subject to BCP 78 and the IETF Trust's Legal 86 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 87 license-info) in effect on the date of publication of this document. 88 Please review these documents carefully, as they describe your rights 89 and restrictions with respect to this document. Code Components 90 extracted from this document must include Revised BSD License text as 91 described in Section 4.e of the Trust Legal Provisions and are 92 provided without warranty as described in the Revised BSD License. 94 Table of Contents 96 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 97 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 98 3. Transport Class . . . . . . . . . . . . . . . . . . . . . . . 6 99 4. "Transport Class" Route Target Extended Community . . . . . . 7 100 5. Transport RIB . . . . . . . . . . . . . . . . . . . . . . . . 9 101 6. Transport Routing Instance . . . . . . . . . . . . . . . . . 9 102 7. Nexthop Resolution Scheme . . . . . . . . . . . . . . . . . . 9 103 8. BGP Classful Transport Family NLRI . . . . . . . . . . . . . 10 104 9. Comparison with other families using RFC-8277 encoding . . . 11 105 10. Protocol Procedures . . . . . . . . . . . . . . . . . . . . . 12 106 11. Scaling considerations . . . . . . . . . . . . . . . . . . . 15 107 11.1. Avoiding unintended spread of CT routes across 108 domains. . . . . . . . . . . . . . . . . . . . . . . . . 15 109 11.2. Constrained distribution of PNHs to SNs (On Demand 110 Nexthop) . . . . . . . . . . . . . . . . . . . . . . . . 16 111 11.3. Limiting scope of visibility of PE loopback as PNHs . . 17 112 12. OAM considerations . . . . . . . . . . . . . . . . . . . . . 17 113 13. Applicability to Network Slicing . . . . . . . . . . . . . . 18 114 14. SRv6 support . . . . . . . . . . . . . . . . . . . . . . . . 19 115 15. Illustration of procedures with example topology . . . . . . 19 116 15.1. Topology . . . . . . . . . . . . . . . . . . . . . . . . 19 117 15.2. Service Layer route exchange . . . . . . . . . . . . . . 21 118 15.3. Transport Layer route propagation . . . . . . . . . . . 21 119 15.4. Data plane view . . . . . . . . . . . . . . . . . . . . 23 120 15.4.1. Steady state . . . . . . . . . . . . . . . . . . . . 23 121 15.4.2. Absorbing failure of primary path . . . . . . . . . 24 122 16. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 123 16.1. New BGP SAFI . . . . . . . . . . . . . . . . . . . . . . 25 124 16.2. New Format for BGP Extended Community . . . . . . . . . 25 125 16.2.1. Existing registries to be modified . . . . . . . . . 25 126 16.2.2. New registries to be created . . . . . . . . . . . . 26 127 16.3. MPLS OAM code points . . . . . . . . . . . . . . . . . . 27 128 17. Security Considerations . . . . . . . . . . . . . . . . . . . 27 129 18. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 27 130 19. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 28 131 20. Normative References . . . . . . . . . . . . . . . . . . . . 28 132 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 30 134 1. Introduction 136 To facilitate service mapping, the tunnels in a network can be 137 grouped by the purpose they serve into a "Transport Class". The 138 tunnels could be created using any signaling protocol, such as LDP, 139 RSVP, BGP LU or SPRING. The tunnels could also use native IP or 140 IPv6, as long as they can carry MPLS payload. Tunnels may exist 141 between different pair of end points. Multiple tunnels may exist 142 between the same pair of end points. 144 Thus, a Transport Class consists of tunnels created by various 145 protocols that satisfy the properties of the class. For example, a 146 "Gold" transport class may consist of tunnels that traverse the 147 shortest path with fast re-route protection, a "Silver" transport 148 class may hold tunnels that traverse shortest paths without 149 protection, a "To NbrAS Foo" transport class may hold tunnels that 150 exit to neighboring AS Foo, and so on. 152 The extensions specified in this document can be used to create a BGP 153 transport tunnel that potentially spans domains, while preserving its 154 Transport Class. Examples of domain are Autonomous System (AS), or 155 IGP area. Within each domain, there is a second level underlay 156 tunnel used by BGP to cross the domain. The second level underlay 157 tunnels could be hetrogeneous: Each domain may use a different type 158 of tunnel (e.g. MPLS, IP, GRE), or use a differnet signaling 159 protocol. A domain boundary is demarcated by a rewrite of BGP 160 nexthop to 'self' while re-advertising tunnel routes in BGP. 161 Examples of domain boundary are inter-AS links and inter-region ABRs. 162 The path uses MPLS label-switching when crossing domain boundary and 163 uses the native intra-AS tunnel of the desired transport class when 164 traversing within a domain. 166 Overlay routes carry sufficient indication of the Transport Classes 167 they should be encapsulated over, in form of BGP community called the 168 "Mapping community". Based on the mapping community, "route 169 resolution" procedure on the ingress node selects from the 170 corresponding Transport Class an appropriate tunnel whose destination 171 matches (LPM) the nexthop of the overlay route. If the overlay route 172 is carried in BGP, the protocol nexthop (or, PNH) is generally 173 carried as an attribute of the route. 175 The PNH of the overlay route is also referred to as "service 176 endpoint" (SEP). The service endpoint may exist in the same domain 177 as the service ingress node or lie in a different domain, adjacent or 178 non-adjacent. In the former case, reachability to the SEP is 179 provided by an intra-domain tunneling protocol, and in the latter 180 case, reachability to the SEP is via BGP transport families. 182 In this architecture, the intra-domain transport protocols (e.g. 183 RSVP, SRTE) are also "Transport Class aware", and they publish 184 ingress routes in Transport RIB associated with the Transport Class, 185 at the tunnel ingress node. These routes are then redistributed into 186 BGP CT to be advertised to adjacent domains. It is outside the scope 187 of this document how exactly the transport protocols are made 188 transport class aware, though configuration on the tunnel ingress 189 node is a simple mechanism to achieve it. 191 This document describes mechanisms to: 193 Model a "Transport Class" as "Transport RIB" on a router, 194 consisting of tunnel ingress routes of a certain class. 196 Enable service routes to resolve over an intended Transport Class 197 by virtue of carrying the appropriate "Mapping community". Which 198 results in using the corresponding Transport RIB for finding 199 nexthop reachability. 201 Advertise tunnel ingress routes in a Transport RIB via BGP without 202 any path hiding, using BGP VPN technology and Add-path. Such that 203 overlay routes in the receiving domains can also resolve over 204 tunnels of associated Transport Class. 206 Provide a way for co-operating domains to reconcile any 207 differences in extended community namespaces, and interoperate 208 between different transport signaling protocols in each domain. 210 In this document we focus mainly on MPLS as the intra-domain 211 transport tunnel forwarding, but the mechanisms described here would 212 work in similar manner for non-MPLS (e.g. IP, GRE, UDP) transport 213 tunnel forwarding technologies too. 215 This document assumes MPLS forwarding when crossing domain 216 boundaries, as that is the defacto standard in deployed networks 217 today. But mechanisms specified in this document can also support 218 different forwarding technologies (e.g. SRv6). 219 Section [SRV6-INTER-DOMAIN]in this document describes adaptation of 220 BGP CT over SRv6 data plane. 222 The document Seamless Segment Routing [Seamless-SR] describes various 223 use cases and applications of procedures described in this document. 225 2. Terminology 227 LSP: Label Switched Path. 229 TE : Traffic Engineering. 231 SN : Service Node. 233 BN : Border Node. 235 TN : Transport Node, P-router. 237 BGP-VPN : VPNs built using RFC4364 mechanisms. 239 RT : Route-Target extended community. 241 RD : Route-Distinguisher. 243 PNH : Protocol-Nexthop address carried in a BGP Update message. 245 SEP : Service End point, the PNH of a Service route. 247 LPM : Longest Prefix Match. 249 Service Family : BGP address family used for advertising routes for 250 "data traffic", as opposed to tunnels. 252 Transport Family : BGP address family used for advertising tunnels, 253 which are in turn used by service routes for resolution. 255 Transport Tunnel : A tunnel over which a service may place traffic. 256 These tunnels can be GRE, UDP, LDP, RSVP, or SR-TE. 258 Tunnel Domain : A domain of the network containing SN and BN, under a 259 single administrative control that has a tunnel between SN and BN. 260 An end-to-end tunnel spanning several adjacent tunnel domains can be 261 created by "stitching" them together using labels. 263 Transport Class : A group of transport tunnels offering the same type 264 of service. 266 Transport Class RT : A Route-Target extended community used to 267 identify a specific Transport Class. 269 Transport RIB : At the SN and BN, a Transport Class has an associted 270 Transport RIB that holds its tunnel routes. 272 Transport Plane : An end to end plane comprising of transport tunnels 273 belonging to same transport class. Tunnels of same transport class 274 are stitched together by BGP route readvertisements with nexthop- 275 self, to span across domain boundaries using Label-Swap forwarding 276 mechanism similar to Inter-AS option-b. 278 Mapping Community : BGP Community/Extended-community on a service 279 route, that maps it to resolve over a Transport Class. 281 3. Transport Class 283 A Transport Class is defined as a set of transport tunnels that share 284 certain characteristics useful for underlay selection. 286 On the wire, a transport class is represented as the Transport Class 287 RT, which is a new Route-Target extended community. 289 A Transport Class is configured at SN and BN, along with attributes 290 like RD and Route-Target. Creation of a Transport Class instantiates 291 the associated Transport RIB and a Transport routing instance to 292 contain them all. 294 The operator may configure a SN/BN to classify a tunnel into an 295 appropriate Transport Class, which causes the tunnel's ingress routes 296 to be installed in the corresponding Transport RIB. At a BN, these 297 tunnel routes may then be advertised into BGP CT. 299 Alternatively, a router receiving the transport routes in BGP with 300 appropriate signaling information can associate those ingress routes 301 to the appropriate Transport Class. E.g. for Classful Transport 302 family (SAFI 76) routes, the Transport Class RT indicates the 303 Transport Class. For BGP LU family(SAFI 4) routes, import processing 304 based on Communities or inter-AS source-peer may be used to place the 305 route in the desired Transport Class. 307 When the ingress route is received via SRTE [SRTE], which encodes the 308 Transport Class as an integer 'Color' in the NLRI as 309 "Color:Endpoint", the 'Color' is mapped to a Transport Class during 310 import processing. SRTE ingress route for 'Endpoint' is installed in 311 that transport class. The SRTE route when advertised out to BGP 312 speakers will then be advertised in Classful Transport family with 313 Transport Class RT and a new label. The MPLS swap route thus 314 installed for the new label will pop the label and deliver 315 decapsulated traffic into the path determined by SRTE route. 317 RFC8664 [RFC8664] extends PCEP to carry SRTE Color. This color 318 association thus learnt is also mapped to a Transport Class thus 319 associating the PCEP signaled SRTE LSP with the desired Transport 320 Class. 322 Similarly, PCEP-RSVP-COLOR [PCEP-RSVP-COLOR] extends PCEP to carry 323 RSVP Color. This color association thus learnt is also mapped to a 324 Transport Class thus associating the PCEP signaled RSVP LSP with the 325 desired Transport Class. 327 4. "Transport Class" Route Target Extended Community 329 This document defines a new type of Route Target, called "Transport 330 Class" Route Target Extended Community. 332 "Transport Class" Route Target extended community is a transitive 333 extended community EXT-COMM [RFC4360] of extended-type, with a new 334 Format (Type high = 0xa) and SubType as 0x2 (Route Target). 336 This new Route Target Format has the following encoding: 338 0 1 2 3 339 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 340 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 341 | Type= 0xa | SubType= 0x02 | Reserved | 342 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 343 | Transport Class ID | 344 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 346 "Transport Class" Route Target Extended Community 348 Type: 1 octet 350 Type field contains value 0xa. 352 SubType: 1 octet 354 Subtype field contain 0x2. This indicates 'Route Target'. 356 Transport Class ID: 4 octets 358 The least significant 32-bits of the value field contain the 359 "Transport Class" identifier, which is a 32-bit integer. 361 The remaining 2 octets after SubType field are Reserved, they MUST 362 be set to zero by originator, and ignored, left unaltered by 363 receiver. 365 The "Transport class" Route Target Extended community follows the 366 mechanisms for VPN route import, export as specified in BGP-VPN 367 [RFC4364], and follows the Route Target Contrain mechanisms as 368 specified in VPN-RTC [RFC4684] 370 A BGP speaker that implements RT Constraint VPN-RTC [RFC4684] MUST 371 apply the RT Constraint procedures to the "Transport class" Route 372 Target Extended community as-well. 374 The Transport Class Route Target Extended community is carried on 375 Classful Transport family routes, and allows associating them with 376 appropriate Transport RIBs at receiving BGP speakers. 378 Use of the Transport Class Route Target Extended community with a new 379 Type code avoids conflicts with any VPN Route Target assignments 380 already in use for service families. 382 5. Transport RIB 384 A Transport RIB is a routing-only RIB that is not installed in 385 forwarding path. However, the routes in this RIB are used to resolve 386 reachability of overlay routes' PNH. Transport RIB is created when 387 the Transport Class it represents is configured. 389 Overlay routes that want to use a specific Transport Class confine 390 the scope of nexthop resolution to the set of routes contained in the 391 corresponding Transport RIB. This Transport RIB is the "Routing 392 Table" referred in Section 9.1.2.1 RFC4271 (https://www.rfc- 393 editor.org/rfc/rfc4271#section-9.1.2.1) 395 Routes in a Transport RIB are exported out in 'Classful Transport' 396 address family. 398 6. Transport Routing Instance 400 A BGP VPN routing instance that is a container for the Transport RIB. 401 It imports, and exports routes in this RIB with Transport Class RT. 402 Tunnel destination addresses in this routing instance's context come 403 from the "provider namespace". This is different from user VRFs for 404 e.g., which contain prefixes in "customer namespace" 406 The Transport Routing instance uses the RD and RT configured for the 407 Transport Class. 409 7. Nexthop Resolution Scheme 411 An implementation may provide an option for the service route to 412 resolve over less preferred Transport Classes, should the resolution 413 over preferred, or "primary" Transport Class fail. 415 To accomplish this, the set of service routes may be associated with 416 a user-configured "resolution scheme", which consists of the primary 417 Transport Class, and optionally, an ordered list of fallback 418 Transport Classes. 420 A community called as "Mapping Community" is configured for a 421 "resolution scheme". A Mapping community maps to exactly one 422 resolution scheme. A resolution scheme comprises of one primary 423 transport class and optionally one or more fallback transport 424 classes. 426 A BGP route is associated with a resolution scheme during import 427 processing. The first community on the route that matches a mapping 428 community of a locally configured resolution scheme is considered the 429 effective mapping community for the route. The resolution scheme 430 thus found is used when resolving the route's PNH. If a route 431 contains more than one mapping community, it indicates that the route 432 considers these multiple mapping communities as equivalent. So the 433 first community that maps to a resolution scheme is chosen. 435 A transport route received in BGP Classful Transport family SHOULD 436 use a resolution scheme that contains the primary Transport Class 437 without any fallback to best effort tunnels. The primary Transport 438 Class is identified by the Transport Class RT carried on the route. 439 Thus Transport Class RT serves as the Mapping Community for Classful 440 Transport routes. 442 A service route received in a BGP service family MAY map to a 443 resolution scheme that contains the primary Transport Class 444 identified by the mapping community on the route, and a fallback to 445 best effort tunnels transport class. The primary Transport Class is 446 identified by the Mapping community carried on the route. For e.g. 447 the Extended Color community may serve as the Mapping Community for 448 service routes. Color:0: MAY map to a resolution scheme that has 449 primary transport class , and a fallback to best-effort transport 450 class. 452 8. BGP Classful Transport Family NLRI 454 The Classful Transport (CT) family will use the existing AFI of IPv4 455 or IPv6, and a new SAFI 76 "Classful Transport" that will apply to 456 both IPv4 and IPv6 AFIs. These AFI, SAFI pair of values MUST be 457 negotiated in Multiprotocol Extensions capability described in 458 [RFC4760] to be able to send and receive BGP CT routes. 460 The "Classful Transport" SAFI NLRI itself is encoded as specified in 461 https://tools.ietf.org/html/rfc8277#section-2 [RFC8277]. 463 When AFI is IPv4 the "Prefix" portion of Classful Transport family 464 NLRI consists of an 8-byte RD followed by an IPv4 prefix. When AFI 465 is IPv6 the "Prefix" consists of an 8-byte RD followed by an IPv6 466 prefix. 468 Attributes on a Classful Transport route include the Transport Class 469 Route-Target extended community, which is used to leak the route into 470 the right Transport RIBs on SNs and BNs in the network. 472 SAFI 76 routes can be sent with either IPv4 or IPv6 nexthop. The 473 type of nexthop is inferred from the length of nexthop. 475 When the length of Next Hop Address field is 24 (or 48) the nexthop 476 address is of type VPN-IPv6 with 8-octet RD set to zero (potentially 477 followed by the link-local VPN-IPv6 address of the next hop with an 478 8-octet RD set to zero). 480 When the length of Next Hop Address field is 12 the nexthop address 481 is of type VPN-IPv4 with 8-octet RD set to zero. 483 9. Comparison with other families using RFC-8277 encoding 485 SAFI 128 (Inet-VPN) is a RF8277 encoded family that carries service 486 prefixes in the NLRI, where the prefixes come from the customer 487 namespaces, and are contexualized into separate user virtual service 488 RIBs called VRFs, using RFC4364 procedures. 490 SAFI 4 (BGP LU) is a RFC8277 encoded family that carries transport 491 prefixes in the NLRI, where the prefixes come from the provider 492 namespace. 494 SAFI 76 (Classful Transport) is a RFC8277 encoded family that carries 495 transport prefixes in the NLRI, where the prefixes come from the 496 provider namespace, but are contexualized into separate Transport 497 RIBs, using RFC4364 procedures. 499 It is worth noting that SAFI 128 has been used to carry transport 500 prefixes in "L3VPN Inter-AS Carrier's carrier" scenario, where BGP 501 LU/LDP prefixes in CsC VRF are advertised in SAFI 128 towards the 502 remote-end baby carrier. 504 In this document a new AFI/SAFI is used instead of reusing SAFI 128 505 to carry these transport routes, because it is operationally 506 advantageous to segregate transport and service prefixes into 507 separate address families, RIBs. E.g. It allows to safely enable 508 "per-prefix" label allocation scheme for Classful Transport prefixes 509 without affecting SAFI 128 service prefixes which may have huge 510 scale. "per prefix" label allocation scheme keeps the routing churn 511 local during topology changes. 513 A new family also facilitates having a different readvertisement path 514 of the transport family routes in a network than the service route 515 readvertisement path. viz. Service routes (Inet-VPN) are exchanged 516 over an EBGP multihop session between Autonomous systems with nexthop 517 unchanged; whereas Classful Transport routes are readvertised over 518 EBGP single hop sessions with "nexthop-self" rewrite over inter-AS 519 links. 521 The Classful Transport family is similar in vein to BGP LU, in that 522 it carries transport prefixes. The only difference is, it also 523 carries in Route Target an indication of which Transport Class the 524 transport prefix belongs to, and uses RD to disambiguate multiple 525 instances of the same transport prefix in a BGP Update. 527 10. Protocol Procedures 529 This section summarizes the procedures followed by various nodes 530 speaking Classful Transport family 532 Preparing the network for deploying Classful Transport planes 534 Operator decides on the Transport Classes that exist in the 535 network, and allocates a Route-Target to identify each Transport 536 Class. 538 Operator configures Transport Classes on the SNs and BNs in the 539 network with unique Route-Distinguishers and Route-Targets. 541 Implementations may provide automatic generation and assignment of 542 RD, RT values for a transport routing instance; they MAY also 543 provide a way to manually override the automatic mechanism, in 544 order to deal with any conflicts that may arise with existing RD, 545 RT values in the different network domains participating in a 546 deployment. 548 Origination of Classful Transport route: 550 At the ingress node of the tunnel's home domain, the tunneling 551 protocols install routes in the Transport RIB associated with the 552 Transport Class the tunnel belongs to. 554 The ingress node then advertises this tunnel destination into BGP 555 as a Classful Transport family route with NLRI RD:TunnelEndpoint, 556 attaching a 'Transport Class' Route Target that identifies the 557 Transport Class. This BGP CT route is advertised to EBGP peers 558 and IBGP peers which are RR-clients. This route MUST NOT be 559 advertised to the IBGP peers who are not RR-clients. 561 Alternatively, the egress node of the tunnel i.e. the tunnel 562 endpoint can originate the same BGP Classful Transport route, with 563 NLRI RD:TunnelEndpoint and PNH TunnelEndpoint, which will resolve 564 over the tunnel route at the ingress node. When the tunnel is up, 565 the Classful Transport BGP route will become usable and get re- 566 advertised. 568 Unique RD SHOULD be used by the originator of a Classful Transport 569 route to disambiguate the multiple BGP advertisements for a 570 transport end point. 572 Ingress node receiving Classful Transport route 574 On receiving a BGP Classful Transport route with a PNH that is not 575 directly connected, e.g. an IBGP-route, a mapping community on the 576 route (the Transport Class RT) indicates which Transport Class 577 this route maps to. The routes in the associated Transport RIB 578 are used to resolve the received PNH. If there does not exist a 579 route in the Transport RIB matching the PNH, the Classful 580 Transport route is considered unusable, and MUST NOT be re- 581 advertised further. 583 Border node readvertising Classful Transport route with nexthop self: 585 The BN allocates an MPLS label to advertise upstream in Classful 586 Transport NLRI. The BN also installs an MPLS swap-route for that 587 label that swaps the incoming label with a label received from the 588 downstream BGP speaker, or pops the incoming label. And then 589 pushes received traffic to the transport tunnel or direct 590 interface that the Classful Transport route's PNH resolved over. 592 The label SHOULD be allocated with "per-prefix" label allocation 593 semantics. RD is stripped from the BGP CT NLRI prefix when a BGP 594 CT route is leaked to a Transport RIB. The IP prefix in the 595 transport RIB context (IP-prefix, Transport-Class) is used as the 596 key to do per-prefix label allocation. This helps in avoiding BGP 597 CT route churn through out the CT network when a failure happens 598 in a domain. The failure is not propagated further than the BN 599 closest to the failure. 601 The value of advertised MPLS label is locally significant, and is 602 dynamic by default. The BN may provide option to allocate a value 603 from a statically carved out range. This can be achieved using 604 locally configured export policy, or via mechanisms described in 605 BGP Prefix-SID [RFC8669]. 607 Border node receiving Classful Transport route on EBGP : 609 If the route is received with PNH that is known to be directly 610 connected, e.g. EBGP single-hop peering address, the directly 611 connected interface is checked for MPLS forwarding capability. No 612 other nexthop resolution process is performed, as the inter-AS 613 link can be used for any Transport Class. 615 If the inter-AS links should honor Transport Class, then the BN 616 SHOULD follow procedures of an Ingress node described above, and 617 perform nexthop resolution process. The interface routes SHOULD 618 be installed in the Transport RIB belonging to the associated 619 Transport Class. 621 Avoiding path-hiding through Route Reflectors 623 When multiple BNs exist that advertise a RDn:PEn prefix to RRs, 624 the RRs may hide all but one of the BNs, unless ADDPATH [RFC7911] 625 is used for the Classful Transport family. This is similar to 626 L3VPN option-B scenarios. Hence ADDPATH SHOULD be used for 627 Classful Transport family, to avoid path-hiding through RRs. 629 Avoiding loop between Route Reflectors in forwarding path 631 Pair of redundant ABRs acting as RR with nexthop-self may chose 632 each other as best path instead of the upstream ASBR, causing a 633 traffic forwarding loop. 635 Implementations SHOULD provide a way to alter the tie-breaking 636 rule specified in BGP RR [RFC4456] to tie-break on CLUSTER_LIST 637 step before ROUTER-ID step, when performing path selection for BGP 638 CT routes. RFC4456 considers pure RR which is not in forwarding 639 path. When RR is in forwarding path and reflects routes with 640 nexthop-self, which is the case for ABR BNs in a BGP transport 641 network, this rule may cause loops. This document suggests the 642 following modification to the BGP Decision Process Tie Breaking 643 rules (Sect. 9.1.2.2, [RFC4271]) when doing path selection for BGP 644 CT family routes: 646 The following rule SHOULD be inserted between Steps e) and f): a 647 BGP Speaker SHOULD prefer a route with the shorter CLUSTER_LIST 648 length. The CLUSTER_LIST length is zero if a route does not carry 649 the CLUSTER_LIST attribute. 651 Some deployment considerations can also help in avoiding this 652 problem: 654 - IGP metric should be assigned such that "ABR to redundant ABR" 655 cost is inferior than "ABR to upstream ASBR" cost. 657 - Tunnels belonging to special Transport classes SHOULD NOT be 658 provisioned between ABR to ABRs. This will ensure that the 659 route received from an ABR with nexthop-self will not be usable 660 at a redundant ABR. 662 This avoids possibility of such loops altogether, irrespective of 663 whether the path selection modification mentioned above is 664 implemented. 666 Ingress node receiving service route with mapping community 668 Service routes received with mapping community resolve using 669 Transport RIBs determined by the resolution scheme. If the 670 resolution process does not find an usable Classful Transport 671 route or tunnel route in any of the Transport RIBs, the service 672 route MUST be considered unusable for forwarding purpose. 674 Coordinating between domains using different community namespaces. 676 Cooperating option-C domains may sometimes not agree on RT, RD, 677 Mapping-community or Transport Route Target values because of 678 differences in community namespaces; e.g. during network mergers 679 or renumbering for expansion. Such deployments may deploy 680 mechanisms to map and rewrite the Route-target values on domain 681 boundaries, using per ASBR import policies. This is no different 682 than any other BGP VPN family. Mechanisms employed in inter-AS 683 VPN deployments may be used with the Classful Transport family 684 also. 686 The resolution schemes SHOULD allow association with multiple 687 mapping communities. This helps with renumbering, network 688 mergers, or transitions. 690 Though RD can also be rewritten on domain boundaries, deploying 691 unique RDs is strongly RECOMMENDED, because it helps in trouble 692 shooting by uniquely identifying originator of a route, and avoids 693 path-hiding. 695 This document defines a new format of Route-Target extended- 696 community to carry Transport Class, this avoids collision with 697 regular Route Target namespace used by service routes. 699 11. Scaling considerations 701 11.1. Avoiding unintended spread of CT routes across domains. 703 RFC8212 [RFC8212] suggests BGP speakers require explicit 704 configuration of both BGP Import and Export Policies for any EBGP 705 sessions, in order to receive or send routes on EBGP sessions. 707 It is recommended to follow this for BGP CT routes. It will prohibit 708 unintended advertisement of transport routes through out the BGP CT 709 transport domain which may span multiple AS. This will conserve 710 usage of MPLS label and nexthop resources in the network. An ASBR of 711 a domain can be provisioned to allow routes with only the Transport 712 targets that are required by SNs in the domain. 714 11.2. Constrained distribution of PNHs to SNs (On Demand Nexthop) 716 This section describes how the number of Protocol Nexthops 717 advertised to a SN or BN can be constrained using BGP Classsful 718 Transport and VPN RTC [RFC4684] 720 An egress SN MAY advertise BGP CT route for RD:eSN with two Route 721 Targets: transport-target:0: and a RT carrying :. 722 Where TC is the Transport Class identifier, and eSN is the IP- 723 address used by SN as BGP nexthop in it's service route 724 advertisements. 726 transport-target:0: is the new type of route target (Transport 727 Class RT) defined in this document. It is carried in BGP extended 728 community attribute (BGP attribute code 16). 730 The RT carrying : MAY be an IP-address specific regular 731 RT (BGP attribute code 16), IPv6-address specific RT (BGP 732 attribute code 25), or a Wide-communities based RT (BGP attribute 733 code 34) as described in RTC-Ext [RTC-Ext] 735 An ingress SN MAY import BGP CT routes with Route Target carrying: 736 :. The ingress SN MAY learn the eSN values either by 737 configuration, or it MAY discover them from the BGP nexthop field 738 in the BGP VPN service routes received from eSN. A BGP ingress SN 739 receiving a BGP service route with nexthop of eSN SHOULD generate 740 a RTC/Extended-RTC route for Route Target prefix :/[80|176] in order to learn BGP CT transport routes to 742 reach eSN. This allows constrained distribution of the transport 743 routes to the PNHs actually required by iSN. 745 When path of route propogation of BGP CT routes is same as the RTC 746 routes, a BN would learn the RTC routes advertised by ingress SNs 747 and propagate further. This will allow constraining distribution 748 of BGP CT routes for a PNH to only the necessary BNs in the 749 network, closer to the egress SN. 751 This mechanism provides "On Demand Nexthop" of BGP CT routes, 752 which help with scaling of MPLS forwarding state at SN and BN. 754 But the amount of state carried in RTC family may become 755 proportional to number of PNHs in the network. To strike a 756 balance, the RTC route advertisements for :/[80|176] MAY be confined to the BNs in home region of 758 ingress-SN, or the BNs of a super core. 760 Such a BN in the core of the network SHOULD import BGP CT routes 761 with Transport Class Route Target: 0:, and generate a RTC 762 route for :0:/96, while not propagating the more 763 specific RTC requests for specific PNHs. This will let the BN 764 learn transport routes to all eSN nodes. But confine their 765 propagation to ingress-SNs. 767 11.3. Limiting scope of visibility of PE loopback as PNHs 769 It may be even more desirable to limit the number of PNHs that are 770 globaly visible in the network. This is possible using mechanism 771 described in MPLS Namespaces [MPLS-NAMESPACES] 773 Such that advertisement of PE loopback addresses as next-hop in BGP 774 service routes is confined to the region they belong to. An anycast 775 IP-address called "Context Protocol Nexthop Address" abstracts the 776 PEs in a region from other regions in the network, swapping the PE 777 scoped service label with a CPNH scoped private namespace label. 779 This provides much greater advantage in terms of scaling and 780 convergence. Changes to implement this feature are required only on 781 the region's BNs and RR. 783 12. OAM considerations 785 Standard MPLS OAM procedures specified in [RFC8029] also apply to BGP 786 Classful Transport. 788 The 'Target FEC Stack' sub-TLV for IPv4 Classful Transport has a Sub- 789 Type of [TBD], and a length of 13. The Value field consists of the 790 RD advertised with the Classful Transport prefix, the IPv4 prefix 791 (with trailing 0 bits to make 32 bits in all), and a prefix length, 792 encoded as follows: 794 0 1 2 3 795 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 796 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 797 | Route Distinguisher | 798 | (8 octets) | 799 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 800 | IPv4 prefix | 801 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 802 | Prefix Length | Must Be Zero | 803 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 805 Figure 1: Classful Transport IPv4 FEC 807 The 'Target FEC Stack' sub-TLV for IPv6 Classful Transport has a Sub- 808 Type of [TBD], and a length of 25. The Value field consists of the 809 RD advertised with the Classful Transport prefix, the IPv6 prefix 810 (with trailing 0 bits to make 128 bits in all), and a prefix length, 811 encoded as follows: 813 0 1 2 3 814 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 815 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 816 | Route Distinguisher | 817 | (8 octets) | 818 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 819 | IPv6 prefix | 820 | | 821 | | 822 | | 823 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 824 | Prefix Length | Must Be Zero | 825 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 827 Figure 2: Classful Transport IPv6 FEC 829 13. Applicability to Network Slicing 831 In Network Slicing, the Transport Slice Controller (TSC) sets up the 832 Topology (e.g. RSVP, SR-TE tunnels with desired characteristics) and 833 resources (e.g. polices/shapers) in a transport network to create a 834 Transport slice. The Transport class construct described in this 835 document represents the "Topology Slice" portion of this equation. 837 The TSC can use the Transport Class Identifier (Color value) to 838 provision a transport tunnel in a specific Topology Slice. 840 Further, Network slice controller can use the Mapping community on 841 the service route to map traffic to the desired Transport slice. 843 14. SRv6 support 845 This section describes how BGP CT may be used to set up inter domain 846 tunnels of a certain Transport Class, when using Segment Routing over 847 IPv6 (SRv6) data plane on the inter AS links or as intra-AS tunneling 848 mechanism. 850 RFC8986, [SRV6-INTER-DOMAIN] specify the SRv6 Endpoint behaviors (End 851 USD, End.BM, End.B6.Encaps and End.Replace, End.ReplaceB6, 852 respectively). These are leveraged for BGP CT with SRv6 data plane. 854 The BGP Classful Transport route update for SRv6 MUST include the BGP 855 Prefix-SID attribute along with SRv6 SID information as specified in 856 [SRV6-SERVICES]. It may also include SRv6 SID structure for 857 Transposition as specified in [SRV6-SERVICES]. It should be noted 858 that prefixes carried in BGP CT family are transport layer end- 859 points, e.g. PE loopback addresses. Thus the SRv6 SID carried in a 860 BGP CT route is also a transport layer identifier. 862 This document extends the usage of "SRv6 label route tunnel" TLV to 863 AFI=1/2 SAFI 76. "SRv6 label route tunnel" is the TLV of the BGP 864 Prefix-SID Attribute as specified in [SRV6-MPLS-AGRWL]. 866 15. Illustration of procedures with example topology 868 15.1. Topology 870 [RR26] [RR27] [RR16] 871 | | | 872 | | | 873 |+-[ABR23]--+|+--[ASBR21]---[ASBR13]-+|+--[PE11]--+ 874 || ||| ` / ||| | 875 [CE41]--[PE25]--[P28] [P29] `/ [P15] [CE31] 876 | | | /` | | | 877 | | | / ` | | | 878 | | | / ` | | | 879 +--[ABR24]--+ +--[ASBR22]---[ASBR14]-+ +--[PE12]--+ 881 | | | | 882 + + + + 883 CE | region-1 | region-2 | |CE 884 AS4 ...AS2... AS1 AS3 886 41.41.41.41 ------------ Traffic Direction ----------> 31.31.31.31 887 This example shows a provider network that comprises of two 888 Autonomous systems, AS1, AS2. They are serving customers AS3, AS4 889 respectively. Traffic direction being described is CE41 to CE31. 890 CE31 may request a specific SLA, e.g. Gold for this traffic, when 891 traversing these provider networks. 893 AS2 is further divided into two regions. So there are three tunnel 894 domains in provider space. AS1 uses ISIS Flex-Algo intra-domain 895 tunnels, whereas AS2 uses RSVP intra-domain tunnels. 897 The network has two Transport classes: Gold with transport class id 898 100, Bronze with transport class id 200. These transport classes are 899 provisioned at the PEs and the Border nodes (ABRs, ASBRs) in the 900 network. 902 Following tunnels exist for Gold transport class. 904 PE25_to_ABR23_gold - RSVP tunnel 906 PE25_to_ABR24_gold - RSVP tunnel 908 ABR23_to_ASBR22_gold - RSVP tunnel 910 ASBR13_to_PE11_gold - ISIS FlexAlgo tunnel 912 ASBR14_to_PE11_gold - ISIS FlexAlgo tunnel 914 Following tunnels exist for Bronze transport class. 916 PE25_to_ABR23_bronze - RSVP tunnel 918 ABR23_to_ASBR21_bronze - RSVP tunnel 920 ABR23_to_ASBR22_bronze - RSVP tunnel 922 ABR24_to_ASBR21_bronze - RSVP tunnel 924 ASBR13_to_PE12_bronze - ISIS FlexAlgo tunnel 926 ASBR14_to_PE11_bronze - ISIS FlexAlgo tunnel 928 These tunnels are either provisioned or auto-discovered to belong to 929 transport class 100 or 200. 931 15.2. Service Layer route exchange 933 Service nodes PE11, PE12 negotiate service families (SAFI 1, 128) on 934 the BGP session with RR16. Service helpers RR16, RR26 have multihop 935 EBGP session to exchange service routes between the two AS. 936 Similarly PE25 negotiates service families with RR26. 938 Forwarding happens using service routes at service nodes PE25, PE11, 939 PE12 only. Routes received from CEs are not present in any other 940 nodes' FIB in the network. 942 CE31 advertises a route for example prefix 31.31.31.31 with nexthop 943 self to PE11, PE12. CE31 can attach a mapping community Color:0:100 944 on this route, to indicate its request for Gold SLA. Or, PE11 can 945 attach the same using locally configured policies. Let us assume 946 CE31 is getting VPN service from PE25. 948 The 31.31.31.31 route is readvertised in SAFI 128 by PE11 with 949 nexthop self (1.1.1.1) and label V-L1, to RR16 with the mapping 950 community Color:0:100 attached. This SAFI 128 route reaches PE25 via 951 RR16, RR26 with the nexthop unchanged, as PE11 and label V-L1. Now 952 PE25 can resolve the PNH 1.1.1.1 using transport routes received in 953 BGP CT or BGP LU. 955 The IP FIB at PE25 will have a route for 31.31.31.31 with a nexthop 956 thus found, that points to a Gold tunnel in ingress domain. 958 15.3. Transport Layer route propagation 960 ASBR13 negotiates BGP CT family with transport ASBRs ASBR21, ASBR22. 961 They negotiate BGP CT family with RR27 in region 2. ABR23, ABR24 962 negotiate BGP CT family with RR27 in region 2 and RR26 in region 1. 963 PE25 receives BGP CT routes from RR26. BGP LU family is also 964 negotiated on these sessions alongside BGP CT family. BGP LU carries 965 "best effort" transport class routes, BGP CT carries gold, bronze 966 transport class routes. 968 ASBR13 is provisioned with transport class 100, RD value 1.1.1.3:10 969 and a transport route target 0:100. And a Transport class 200 with 970 RD value 1.1.1.3:20, and transport route target 0:200. 972 Similarly, these transport classes are also configured on ASBRs, ABRs 973 and PEs, with same transport route target, but unique RDs. 975 Ingress route for ASBR13_to_PE11_gold is advertised by ASBR13 in BGP 976 CT family to ASBRs ASBR21, ASBR22. This route is sent with a NLRI 977 containing RD prefix 1.1.1.3:10:1.1.1.1, Label B-L1 and a route 978 target extended community transport-target:0:100. MPLS swap route is 979 installed at ASBR13 for B-L1 with a nexthop pointing to 980 ASBR13_to_PE11_gold tunnel. 982 Ingress route for ASBR13_to_PE11_bronze is advertised by ASBR13 in 983 BGP CT family to ASBRs ASBR21, ASBR22. This route is sent with a 984 NLRI containing RD prefix 1.1.1.3:20:1.1.1.1, Label B-L2 and a route 985 target extended community transport-target:0:200. MPLS swap route is 986 installed at ASBR13 for label B-L2 with a nexthop pointing to 987 ASBR13_to_PE11_bronze tunnel 989 ASBR21 receives BGP CT route 1.1.1.3:10:1.1.1.1 over the single hop 990 EBGP sesion, and readvertises with nexthop self (loopback adderss 991 2.2.2.1) to RR27, advertising a new label B-L3. MPLS swap route is 992 installed for label B-L3 at ASBR21 to swap to received label B-L1 and 993 forwards to ASBR13. RR27 readvertises this BGP CT route to ABR23, 994 ABR24. 996 ASBR22 receives BGP CT route 1.1.1.3:10:1.1.1.1 over the single hop 997 EBGP sesion, and readvertises with nexthop self (loopback adderss 998 2.2.2.2) to RR27, advertising a new label B-L4. MPLS swap route is 999 installed for label B-L4 at ASBR22 to swap to received label B-L2 and 1000 forwards to ASBR13. RR27 readvertises this BGP CT route to ABR23, 1001 ABR24. 1003 Addpath is enabled for BGP CT family on the sessions between RR27 and 1004 ASBRs, ABRs. Such that routes for 1.1.1.3:10:1.1.1.1 with the 1005 nexthops ASBR21 and ASBR22 are reflected to ABR23, ABR24 without any 1006 path hiding. Thus giving ABR23 visibiity of both available nexthops 1007 for Gold SLA. 1009 ABR23 receives the route with nexthop 2.2.2.1, label B-L3 from RR27. 1010 The route target "transport-target:0:100" on this route acts as 1011 mapping community, and instructs ABR23 to strictly resolve the 1012 nexthop using transport class 100 routes only. ABR23 is unable to 1013 find a route for 2.2.2.1 with transport class 100. Thus it considers 1014 this route unusable and does not propagate it further. This prunes 1015 ASBR21 from Gold SLA tunneled path. 1017 ABR23 also receives the route with nexthop 2.2.2.2, label B-L4 from 1018 RR27. The route target "transport-target:0:100" on this route acts 1019 as mapping community, and instructs ABR23 to strictly resolve the 1020 nexthop using transport class 100 routes only. ABR23 successfully 1021 resolves the nexthop to point to ABR23_to_ASBR22_gold tunnel. ABR23 1022 readvertises this route with nexthop self (loopback address 2.2.2.3) 1023 and a new label B-L5 to RR26. Swap route for B-L5 is installed by 1024 ABR23 to swap to label B-L4, and forward into ABR23_to_ASBR22_gold 1025 tunnel. 1027 RR26 reflects the route from ABR23 to PE25. PE25 receives the BGP CT 1028 route for prefix 1.1.1.3:10:1.1.1.1 with label B-L5, nexthop 2.2.2.3 1029 and transport-target:0:100 from RR26. And it similarly resolves the 1030 nexthop 2.2.2.3 over transport class 100, pushing labels associated 1031 with PE25_to_ABR23_gold tunnel. 1033 In this manner, the Gold transport LSP "ASBR13_to_PE11_gold" in 1034 egress-domain is extended by BGP CT until the ingress-node PE25 in 1035 ingress domain, to create an end-to-end Gold SLA path. MPLS swap 1036 routes are installed at ASBR13, ASBR22 and ABR23, when propagating 1037 the PE11 BGP CT Gold transport class route 1.1.1.3:10:1.1.1.1 with 1038 nexthop self towards PE25. 1040 The BGP CT LSP thus formed, originates in PE25, and terminates in 1041 ASBR13, traversing over the Gold underlay LSPs in each domain. 1042 ASBR13 uses UHP to stitch the BGP CT LSP into the 1043 "ASBR13_to_PE11_gold" LSP to traverse the last domain, thus 1044 satisfying Gold SLA end-to-end. 1046 When PE25 receives service route with nexthop 1.1.1.1 and mapping 1047 community Color:0:100, it resolves over this BGP CT route 1048 1.1.1.3:10:1.1.1.1. Thus pushing label B-L5, and pushing as top 1049 label the labels associated with PE25_to_ABR23_gold tunnel. 1051 15.4. Data plane view 1053 15.4.1. Steady state 1055 This section describes how the data plane looks like in steady state. 1057 CE41 transmits an IP packet with destination as 31.31.31.31. On 1058 receiving this packet PE25 performs a lookup in the IP FIB associated 1059 with the CE41 interface. This lookup yeids the service route that 1060 pushes the VPN service label V-L1, BGP CT label B-L5, and labels for 1061 PE25_to_ABR23_gold tunnel. Thus PE25 encapsulates the IP packet in 1062 MPLS packet with label V-L1(innermost), B-L5, and top label as 1063 PE25_to_ABR23_gold tunnel. This MPLS packet is thus transmitted to 1064 ABR23 using Gold SLA. 1066 ABR23 decapsulates the packet received on PE25_to_ABR23_gold tunnel 1067 as required, and finds the MPLS packet with label B-L5. It performs 1068 lookup for label B-L5 in the global MPLS FIB. This yields the route 1069 that swaps label B-L5 with label B-L4, and pushes top label provided 1070 by ABR23_to_ASBR22_gold tunnel. Thus ABR23 transmits the MPLS packet 1071 with label B-L4 to ASBR22, on a tunnel that satisfies Gold SLA. 1073 ASBR22 similarly performs a lookup for label B-L4 in global MPLS FIB, 1074 finds the route that swaps label B-L4 with label B-L2, and forwards 1075 to ASBR13 over the directly connected MPLS enabled interface. This 1076 interface is a common resource not dedicated to any specific 1077 transport class, in this example. 1079 ASBR13 receives the MPLS packet with label B-L2, and performs a 1080 lookup in MPLS FIB, finds the route that pops label B-L2, and pushes 1081 labels associated with ASBR13_to_PE11_gold tunnel. This transmits 1082 the MPLS packet with VPN label V-L1 to PE11, using a tunnel that 1083 preserves Gold SLA in AS 1. 1085 PE11 receives the MPLS packet with V-L1, and performs VPN forwarding. 1086 Thus transmitting the original IP payload from CE41 to CE31. The 1087 payload has traversed path satisfying Gold SLA end-to-end. 1089 15.4.2. Absorbing failure of primary path 1091 This section describes how the data plane reacts when gold path 1092 experiences a failure. 1094 Let us assume tunnel ABR23_to_ASBR22_gold goes down, such that now 1095 end-to-end Gold path does not exist in the network. This makes the 1096 BGP CT route for RD prefix 1.1.1.1:10:1.1.1.1 unusable at ABR23. 1097 This makes ABR23 send a BGP withdrawal for 1.1.1.1:10:1.1.1.1 to 1098 RR26, which then withdraws the prefix from PE25. 1100 Withdrawal for 1.1.1.1:10:1.1.1.1 allows PE25 to react to the loss of 1101 gold path to 1.1.1.1. Let us assume PE25 is provisioned to use best- 1102 effort transport class as the backup path. This withdrawal of BGP CT 1103 route allows PE25 to adjust the nexthop of the VPN Service-route to 1104 push the labels provided by the BGP LU route. That repairs the 1105 traffic to go via best effort path. PE25 can also be provisioned to 1106 use Bronze transport class as the backup path. The repair will 1107 happen in similar manner in that case as-well. 1109 Traffic repair to absorb the failure happens at ingress node PE25, in 1110 a service prefix scale independent manner. This is called PIC 1111 (Prefix scale Independent Convergence). The repair time will be 1112 proportional to time taken for withdrawing the BGP CT route. 1114 16. IANA Considerations 1116 This document makes following requests of IANA. 1118 16.1. New BGP SAFI 1120 New BGP SAFI code for "Classful Transport". Value 76. 1122 This will be used to create new AFI,SAFI pairs for IPv4, IPv6 1123 Classful Transport families. viz: 1125 * "Inet, Classful Transport". AFI/SAFI = "1/76" for carrying IPv4 1126 Classful Transport prefixes. 1128 * "Inet6, Classful Transport". AFI/SAFI = "2/76" for carrying IPv6 1129 Classful Transport prefixes. 1131 16.2. New Format for BGP Extended Community 1133 Please assign a new Format (Type high = 0xa) of extended community 1134 EXT-COMM [RFC4360] called "Transport Class" from the following 1135 registries: 1137 the "BGP Transitive Extended Community Types" registry, and 1139 the "BGP Non-Transitive Extended Community Types" registry. 1141 Please assign the same low-order six bits for both allocations. 1143 This document uses this new Format with subtype 0x2 (route target), 1144 as a transitive extended community. 1146 The Route Target thus formed is called "Transport Class" route target 1147 extended community. 1149 Taking reference of RFC7153 [RFC7153] , following requests are made: 1151 16.2.1. Existing registries to be modified 1153 16.2.1.1. Registries for the "Type" Field 1155 16.2.1.1.1. Transitive Types 1157 This registry contains values of the high-order octet (the "Type" 1158 field) of a Transitive Extended Community. 1160 Registry Name: BGP Transitive Extended Community Types 1162 TYPE VALUE NAME 1163 + 0x0a Transitive Transport Class Extended 1164 + Community (Sub-Types are defined in the 1165 + "Transitive Transport Class Extended 1166 + Community Sub-Types" registry) 1168 16.2.1.1.2. Non-Transitive Types 1170 This registry contains values of the high-order octet (the "Type" 1171 field) of a Non-transitive Extended Community. 1173 Registry Name: BGP Non-Transitive Extended Community Types 1175 TYPE VALUE NAME 1177 + 0x4a Non-Transitive Transport Class Extended 1178 + Community (Sub-Types are defined in the 1179 + "Non-Transitive Transport Class Extended 1180 + Community Sub-Types" registry) 1182 16.2.2. New registries to be created 1184 16.2.2.1. Transitive "Transport Class" Extended Community Sub-Types 1185 Registry 1187 This registry contains values of the second octet (the "Sub-Type" 1188 field) of an extended community when the value of the first octet 1189 (the "Type" field) is 0x07. 1191 Registry Name: Transitive Transport Class Extended 1192 Community Sub-Types 1194 RANGE REGISTRATION PROCEDURE 1196 0x00-0xBF First Come First Served 1197 0xC0-0xFF IETF Review 1199 SUB-TYPE VALUE NAME 1201 0x02 Route Target 1203 16.2.2.2. Non-Transitive "Transport Class" Extended Community Sub-Types 1204 Registry 1206 This registry contains values of the second octet (the "Sub-Type" 1207 field) of an extended community when the value of the first octet 1208 (the "Type" field) is 0x47. 1210 Registry Name: Non-Transitive Transport Class Extended 1211 Community Sub-Types 1213 RANGE REGISTRATION PROCEDURE 1215 0x00-0xBF First Come First Served 1216 0xC0-0xFF IETF Review 1218 SUB-TYPE VALUE NAME 1220 0x02 Route Target 1222 16.3. MPLS OAM code points 1224 The following two code points are sought for Target FEC Stack sub- 1225 TLVs: 1227 * IPv4 BGP Classful Transport 1229 * IPv6 BGP Classful Transport 1231 17. Security Considerations 1233 Mechanisms described in this document carry Transport routes in a new 1234 BGP address family. That minimizes possibility of these routes 1235 leaking outside the expected domain or mixing with service routes. 1237 When redistributing between SAFI 4 and SAFI 76 Classful Transport 1238 routes, there is a possibility of SAFI 4 routes mixing with SAFI 1 1239 service routes. To avoid such scenarios, it is RECOMMENDED that 1240 implementations support keeping SAFI 4 routes in a separate transport 1241 RIB, distinct from service RIB that contain SAFI 1 service routes. 1243 18. Contributors 1245 Rajesh M 1246 Juniper Networks, Inc. 1247 Electra, Exora Business Park~Marathahalli - Sarjapur Outer Ring Road, 1248 Bangalore 560103 1249 KA 1250 India 1251 Email: mrajesh@juniper.net 1253 19. Acknowledgements 1255 The authors thank Jeff Haas, John Scudder, Navaneetha Krishnan, Ravi 1256 M R, Chandrasekar Ramachandran, Shradha Hegde, Richard Roberts, 1257 Krzysztof Szarkowicz, John E Drake, Srihari Sangli, Vijay Kestur, 1258 Santosh Kolenchery, Robert Raszuk, Ahmed Darwish for the valuable 1259 discussions and review comments. 1261 The decision to not reuse SAFI 128 and create a new address-family to 1262 carry these transport-routes was based on suggestion made by Richard 1263 Roberts and Krzysztof Szarkowicz. 1265 20. Normative References 1267 [MPLS-NAMESPACES] 1268 Vairavakkalai, Ed., "BGP signalled MPLS-namespaces", 11 1269 June 2021, . 1272 [PCEP-RSVP-COLOR] 1273 Rajagopalan, Ed., "Path Computation Element Protocol(PCEP) 1274 Extension for RSVP Color", 15 January 2021, 1275 . 1278 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1279 Requirement Levels", BCP 14, RFC 2119, 1280 DOI 10.17487/RFC2119, March 1997, 1281 . 1283 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 1284 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 1285 DOI 10.17487/RFC4271, January 2006, 1286 . 1288 [RFC4360] Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended 1289 Communities Attribute", RFC 4360, DOI 10.17487/RFC4360, 1290 February 2006, . 1292 [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private 1293 Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February 1294 2006, . 1296 [RFC4456] Bates, T., Chen, E., and R. Chandra, "BGP Route 1297 Reflection: An Alternative to Full Mesh Internal BGP 1298 (IBGP)", RFC 4456, DOI 10.17487/RFC4456, April 2006, 1299 . 1301 [RFC4684] Marques, P., Bonica, R., Fang, L., Martini, L., Raszuk, 1302 R., Patel, K., and J. Guichard, "Constrained Route 1303 Distribution for Border Gateway Protocol/MultiProtocol 1304 Label Switching (BGP/MPLS) Internet Protocol (IP) Virtual 1305 Private Networks (VPNs)", RFC 4684, DOI 10.17487/RFC4684, 1306 November 2006, . 1308 [RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, 1309 "Multiprotocol Extensions for BGP-4", RFC 4760, 1310 DOI 10.17487/RFC4760, January 2007, 1311 . 1313 [RFC7153] Rosen, E. and Y. Rekhter, "IANA Registries for BGP 1314 Extended Communities", RFC 7153, DOI 10.17487/RFC7153, 1315 March 2014, . 1317 [RFC7911] Walton, D., Retana, A., Chen, E., and J. Scudder, 1318 "Advertisement of Multiple Paths in BGP", RFC 7911, 1319 DOI 10.17487/RFC7911, July 2016, 1320 . 1322 [RFC8029] Kompella, K., Swallow, G., Pignataro, C., Ed., Kumar, N., 1323 Aldrin, S., and M. Chen, "Detecting Multiprotocol Label 1324 Switched (MPLS) Data-Plane Failures", RFC 8029, 1325 DOI 10.17487/RFC8029, March 2017, 1326 . 1328 [RFC8212] Mauch, J., Snijders, J., and G. Hankins, "Default External 1329 BGP (EBGP) Route Propagation Behavior without Policies", 1330 RFC 8212, DOI 10.17487/RFC8212, July 2017, 1331 . 1333 [RFC8277] Rosen, E., "Using BGP to Bind MPLS Labels to Address 1334 Prefixes", RFC 8277, DOI 10.17487/RFC8277, October 2017, 1335 . 1337 [RFC8664] Sivabalan, S., Filsfils, C., Tantsura, J., Henderickx, W., 1338 and J. Hardwick, "Path Computation Element Communication 1339 Protocol (PCEP) Extensions for Segment Routing", RFC 8664, 1340 DOI 10.17487/RFC8664, December 2019, 1341 . 1343 [RFC8669] Previdi, S., Filsfils, C., Lindem, A., Ed., Sreekantiah, 1344 A., and H. Gredler, "Segment Routing Prefix Segment 1345 Identifier Extensions for BGP", RFC 8669, 1346 DOI 10.17487/RFC8669, December 2019, 1347 . 1349 [RTC-Ext] Zhang, Z., Ed., "Route Target Constrain Extension", 12 1350 July 2020, . 1353 [Seamless-SR] 1354 Hegde, Ed., "Seamless Segment Routing", 17 November 2020, 1355 . 1358 [SRTE] Previdi, S., Ed., "Advertising Segment Routing Policies in 1359 BGP", 18 November 2019, . 1362 [SRV6-INTER-DOMAIN] 1363 K A, Ed., "SRv6 inter-domain mapping SIDs", 10 January 1364 2021, . 1367 [SRV6-MPLS-AGRWL] 1368 Agrawal, Ed., "SRv6 and MPLS interworking", 22 February 1369 2021, . 1372 [SRV6-SERVICES] 1373 Dawra, Ed., "SRv6 BGP based Overlay Services", 11 April 1374 2021, . 1377 Authors' Addresses 1379 Kaliraj Vairavakkalai (editor) 1380 Juniper Networks, Inc. 1381 1133 Innovation Way, 1382 Sunnyvale, CA 94089 1383 United States of America 1384 Email: kaliraj@juniper.net 1386 Natrajan Venkataraman 1387 Juniper Networks, Inc. 1388 1133 Innovation Way, 1389 Sunnyvale, CA 94089 1390 United States of America 1391 Email: natv@juniper.net 1392 Balaji Rajagopalan 1393 Juniper Networks, Inc. 1394 Electra, Exora Business Park~Marathahalli - Sarjapur Outer Ring Road, 1395 Bangalore 560103 1396 KA 1397 India 1398 Email: balajir@juniper.net 1400 Gyan Mishra 1401 Verizon Communications Inc. 1402 13101 Columbia Pike 1403 Silver Spring, MD 20904 1404 United States of America 1405 Email: gyan.s.mishra@verizon.com 1407 Mazen Khaddam 1408 Cox Communications Inc. 1409 Atlanta, GA 1410 United States of America 1411 Email: mazen.khaddam@cox.com 1413 Xiaohu Xu 1414 Capitalonline. 1415 Beijing 1416 China 1417 Email: xiaohu.xu@capitalonline.net 1419 Rafal Jan Szarecki 1420 Google. 1421 1160 N Mathilda Ave, Bldg 5, 1422 Sunnyvale,, CA 94089 1423 United States of America 1424 Email: szarecki@google.com 1426 Deepak J Gowda 1427 Extreme Networks 1428 55 Commerce Valley Drive West, Suite 300, 1429 Thornhill, Toronto, Ontario L3T 7V9 1430 Canada 1431 Email: dgowda@extremenetworks.com 1432 Chaitanya Yadlapalli 1433 ATT 1434 200 S Laurel Ave, 1435 Middletown,, NJ 07748 1436 United States of America 1437 Email: cy098d@att.com