idnits 2.17.1 draft-kaliraj-bess-bgp-sig-private-mpls-labels-03.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 12, 2021) is 1013 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Missing Reference: 'RFC3032' is mentioned on line 470, but not defined Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group K. Vairavakkalai 3 Internet-Draft M. Jeyananth 4 Intended status: Experimental Juniper Networks, Inc. 5 Expires: January 13, 2022 July 12, 2021 7 BGP signalled MPLS-namespaces 8 draft-kaliraj-bess-bgp-sig-private-mpls-labels-03 10 Abstract 12 The MPLS-forwarding-layer in a core network is a shared resource. 13 The MPLS FIB at nodes in this layer contains labels that are 14 dynamically allocated and locally significant at that node. 16 For some usecases like upstream-label-allocation, it is useful to be 17 able to create virtual private MPLS-forwarding-layers over this 18 shared MPLS-forwarding-layer. This allows installing deterministic 19 private label-values in the private-FIBs created at nodes 20 participating in this private MPLS forwarding-layer, while preserving 21 the "locally significant" nature of the underlying shared 'public' 22 MPLS-forwarding-layer. 24 This specification describes the procedures to create such virtual 25 private MPLS-forwarding layers (private MPLS-planes) using a new BGP 26 family. And gives a few example use-cases on how this private 27 forwarding-layers can be used. 29 Requirements Language 31 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 32 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 33 document are to be interpreted as described in RFC 2119 [RFC2119]. 35 Status of This Memo 37 This Internet-Draft is submitted in full conformance with the 38 provisions of BCP 78 and BCP 79. 40 Internet-Drafts are working documents of the Internet Engineering 41 Task Force (IETF). Note that other groups may also distribute 42 working documents as Internet-Drafts. The list of current Internet- 43 Drafts is at https://datatracker.ietf.org/drafts/current/. 45 Internet-Drafts are draft documents valid for a maximum of six months 46 and may be updated, replaced, or obsoleted by other documents at any 47 time. It is inappropriate to use Internet-Drafts as reference 48 material or to cite them other than as "work in progress." 49 This Internet-Draft will expire on January 13, 2022. 51 Copyright Notice 53 Copyright (c) 2021 IETF Trust and the persons identified as the 54 document authors. All rights reserved. 56 This document is subject to BCP 78 and the IETF Trust's Legal 57 Provisions Relating to IETF Documents 58 (https://trustee.ietf.org/license-info) in effect on the date of 59 publication of this document. Please review these documents 60 carefully, as they describe your rights and restrictions with respect 61 to this document. Code Components extracted from this document must 62 include Simplified BSD License text as described in Section 4.e of 63 the Trust Legal Provisions and are provided without warranty as 64 described in the Simplified BSD License. 66 Table of Contents 68 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 69 2. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 3 70 3. Constructs and building blocks . . . . . . . . . . . . . . . 4 71 3.1. Context Protocol Nexthop Address . . . . . . . . . . . . 4 72 3.2. MPLS context FIB . . . . . . . . . . . . . . . . . . . . 4 73 3.3. Context Label . . . . . . . . . . . . . . . . . . . . . . 5 74 3.4. Roles of nodes in a MPLS-plane . . . . . . . . . . . . . 5 75 3.4.1. Edge-nodes (PLER) . . . . . . . . . . . . . . . . . . 5 76 3.4.2. Transit-nodes (PLSR) . . . . . . . . . . . . . . . . 5 77 3.5. Sending traffic into the MPLS plane . . . . . . . . . . . 5 78 4. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 79 5. BGP families, routes and encoding . . . . . . . . . . . . . . 7 80 5.1. New address-families for "MPLS namespace signaling" . . . 7 81 5.1.1. AFI: MPLS, SAFI: 128 . . . . . . . . . . . . . . . . 7 82 5.1.2. AFI: MPLS, SAFI: 1 . . . . . . . . . . . . . . . . . 8 83 5.2. Routes and Operational procedures . . . . . . . . . . . . 8 84 5.2.1. "Context-Nexthop" discovery route . . . . . . . . . . 8 85 5.2.2. MPLS namespace "Private Label" routes . . . . . . . . 9 86 6. Example of Usecases . . . . . . . . . . . . . . . . . . . . . 12 87 6.1. Mezanine transport layer in a Seamless-MPLS network . . . 12 88 6.2. Service Forwarding Helper usecase . . . . . . . . . . . . 13 89 6.3. Standard BGP API to a MPLS network's forwarding-plane . . 13 90 6.4. Traffic engineering and Security advantages . . . . . . . 14 91 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 92 8. Security Considerations . . . . . . . . . . . . . . . . . . . 14 93 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14 94 10. Normative References . . . . . . . . . . . . . . . . . . . . 14 95 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 97 1. Introduction 99 The MPLS-forwarding-layer in a core network is a shared resource. 100 The MPLS FIB at nodes in this layer contains labels that are 101 dynamically allocated and locally significant at that node. 103 For some usecases like upstream-label-allocation, it is useful to be 104 able to create virtual private MPLS-forwarding-layers over this 105 shared MPLS-forwarding-layer. This allows installing deterministic 106 private label-values in the private-FIBs in this private forwarding- 107 layer, while preserving the "locally significant" nature of the 108 underlying shared 'public' MPLS-forwarding-layer. 110 It can be noted that, mechanism described in this document is nothing 111 but a [RFC4364] style BGP VPN where the FEC is MPLS-Label, instead of 112 IP-prefix. This document defines new address-families (AFI: MPLS, 113 SAFI: VPN-Unicast, Unicast) and associated signaling mechanisms to 114 create and use MPLS forwarding-contexts in a network. The concepts 115 of MPLS-Context-tables and upstream allocation are described in 116 [RFC5331]. 118 BGP speakers participating in the private MPLS FIB layer create 119 instances of "MPLS forwarding-context" FIBs, which are identified 120 using a "Context-Protocol-Nexthop (CPNH)". A Context-label MAY be 121 advertised in conjunction with the Context Protocol Nexthop (CPNH) 122 using new BGP address-family to other speakers. 124 2. Motivation 126 A provider's core network consists of a global-domain (default 127 forwarding-tables in P and PE nodes) that is shared by all tenants in 128 the network and may also contain multiple private user-domains (e.g. 129 VRF route tables). 131 The global MPLS forwarding-layer can be viewed as the collection of 132 all default MPLS forwarding-tables. This global MPLS Fib layer 133 contains labels locally significant to each node. The "local- 134 significance of labels" gives the nodes freedom to participate in 135 MPLS-forwarding with whatever label-ranges they can support in 136 forwarding hardware. 138 In emerging usecases some applications using the MPLS-network may 139 benefit from a "static labels" view of the MPLS-network. In some 140 other usecases, a standard mechanism to do Upstream label-allocation 141 is beneficial. 143 It is desirable to leave the global MPLS FIB layer intact, and build 144 private MPLS FIB-layers on top of it to achieve these requirements. 146 The private-MPLS-FIBs can then be used by the applications as 147 desired. The private MPLS-FIBs need to be created only at the nodes 148 in the network where predictable label-values (external label 149 allocation) is desired. E.g. P-routers that need to act as a 150 "Detour-nodes" or "Service-Forwarding-Helpers" that need to mirror 151 service-labels. 153 In other words, provisioning of these private MPLS-FIBs can be 154 gradual and can co-exist with nodes not supporting the feature 155 described in this document. These private-MPLS-FIBs can be stitched 156 together using either the Context-labels over the existing shared 157 MPLS-network tunnels, or 'private' context-interfaces - to form the 158 "private MPLS-FIB layer". 160 An application can then install the routes with desired label-values 161 in the private forwarding-contexts with desired forwarding-semantics. 163 3. Constructs and building blocks 165 The building-blocks that construct a private MPLS plane are described 166 in this section. 168 3.1. Context Protocol Nexthop Address 170 A private MPLS plane (just "MPLS plane" here-after) is identified by 171 an IP-address called Context Protocol Nexthop (CPNH). This address 172 is unique in the core-network, like any other loopback address. 174 A loopback-address uniquely identifies a specific node in the 175 network, and we call it Global Protocol Nexthop (GPNH) in this 176 document. The CPNH address uniquely identifies a "MPLS-plane". 178 Each node that has forwarding-context for a MPLS-plane MUST be 179 configured with the same CPNH but a different RD, such that the 180 RD:CPNH will uniquely identify that node in the MPLS-plane. 182 3.2. MPLS context FIB 184 An instance of a MPLS forwarding-table at a node in the private MPLS- 185 plane. This Private MPLS FIB contains the private-label routes. 187 A node can have context-FIB for multiple MPLS-planes. The same 188 label-value can have a different forwarding-semantic in each MPLS- 189 plane. Thus the applications using that MPLS-plane get a 190 deterministic label-value independent of other applications using 191 other MPLS-planes. 193 The terms "private MPLS FIB-layer" and "private MPLS-plane" are used 194 interchangeably in this document. 196 3.3. Context Label 198 A context-label is a non-reserved dynamically allocated label, that 199 is installed in the global MPLS FIB, and points to a MPLS-Context- 200 FIB. The Context-Label have forwarding semantics as follows in the 201 global MPLS-FIB: 203 Context-Label -> Pop and Lookup in MPLS-Context-Fib 205 Advertising the "Context-Label in conjunction with the GPNH" tells 206 the network how to reach a "RD:CPNH". 208 3.4. Roles of nodes in a MPLS-plane 210 The node roles in a MPLS-plane can be classified into "edge nodes" 211 (call them PLER) or "transit-nodes" (call them PLSR). 213 3.4.1. Edge-nodes (PLER) 215 Private Label Edge-routers (PLER) have MPLS context-FIB that belong 216 to the MPLS-plane. They advertise the presence of this context-FIB 217 using transport layer address families like BGP-CT [BGP-CT] or BGP- 218 LU, and private-label routes from this FIB are advertused using new 219 BGP AFI/SAFI described in this document. 221 3.4.2. Transit-nodes (PLSR) 223 These are just Border-nodes that do label-swap forwarding for the 224 Context-Labels they see in the Context-Protocol-Nexthop advertisement 225 routes (BGP-CT or BGP-LU) going thru them. They basically stitch/ 226 extend the label switched path to a PLER's CPNH when they re- 227 advertise the CPNH routes with nexthop-self. 229 PLSRs dont have MPLS context-FIBs. PLSRs dont have Context Protocol- 230 Nexthop. Because they dont have Private label routes to originate. 232 However a node in the network can play both roles, of PLER and PLSR. 234 3.5. Sending traffic into the MPLS plane 236 At a PLER, MPLS-traffic arriving with private-label hits the correct 237 private MPLS-FIB by virtue of either arriving on a "private network- 238 interface" that is attached to the MPLS context-FIB, or arriving with 239 a "Context-label" on a network-interface attached to the global MPLS- 240 FIB. 242 To send data traffic into this private MPLS plane, the sender MUST 243 use as handle either a "Context-label" advertised by a node or a 244 "Private-interface" owned by the MPLS context-FIB at the node. The 245 MPLS context-FIB is created for an application that needs a private 246 MPLS-plane. 248 The Context-Label is the only dynamic label-value the application 249 needs to learn from the network (PLER node it is connected to), to be 250 able to use the private MPLS-plane. The application can chose 251 predictable value for the labels to be programmed in the private 252 MPLS-FIBs. 254 Once the packet enters the private MPLS plane at an edge-node (PLER), 255 the node will forward the packet to the next node (PLSR or PLER), by 256 pushing the Context-label advertised by that next-node, and the 257 transport-label to reach that node's GPNH. This will repeat until 258 the packet reaches the PLER's private MPLS-FIB that originated that 259 private MPLS-label. 261 At each PLER in the MPLS-plane, the private-label value remains the 262 same, and points towards the same resource attached to the MPLS- 263 plane. This allows the applications using the MPLS-network a static- 264 labels view of the resourses attached to the private MPLS-plane. 266 At each PLSR in the MPLS-plane, the context-label value will change 267 (be swapped in forwarding), but is transparent to the application. 269 4. Terminology 271 P-router : A Provider core router, also called a LSR 273 LSR : Label Switch Router (pure transport node speaking LDP, RSVP 274 etc) 276 PLSR: a BGP-CT or BGP-LU transit node in a private MPLS-plane, that 277 does label-swap forwarding for Context-Label. 279 PLER: an edge node in a private MPLS-plane. It has a forwarding- 280 context for private-labels. 282 Detour-router : A BGP border node that is used as a loose-hop in a 283 traffic-engineered path 285 PE-router : Provider Edge router, that hosts a service (Internet, 286 L3VPN etc) 288 SE-router : Service Edge router. Same as PE. 290 SFH-router : Service Forwarding Helper. A node helping an SE-router 291 with service-traffic forwarding, using Service-routes mirrored by the 292 SE. 294 MPLS FIB : MPLS Forwarding table 296 Global MPLS FIB : Global MPLS Forwarding table, to which shared- 297 interfaces are connected 299 Private MPLS FIB : Private MPLS Forwarding table, to which private- 300 interfaces are connected 302 Private MPLS FIB Layer (Private MPLS plane): The group of Private 303 MPLS FIBs in the network, connected together via Context-Labels 305 Context-Label : Locally-significant Non-reserved label pointing to a 306 private MPLS FIB 308 Context nexthop IP-address (CPNH) : An IP-address that identifies the 309 "Private MPLS FIB Layer". RD:CPNH identifies a Private MPLS FIB at a 310 specific BGP node. 312 Global nexthop IP-address (GPNH) : Global Protocol Nexthop address. 313 E.g. a loopback address used as transport tunnel end-point. 315 5. BGP families, routes and encoding 317 This section describes the new constructs defined by this document. 319 5.1. New address-families for "MPLS namespace signaling" 321 This document defines a new AFI: "MPLS" (IANA code TBD). And two new 322 address-families, using SAFIs 128 and 1. These address families are 323 used to signal "MPLS namespaces" in BGP. To send or receive routes 324 of these address families, these AFI, SAFI pair of values MUST be 325 negotiated in Multiprotocol Extensions capability described in 326 RFC4760 [RFC4760] 328 5.1.1. AFI: MPLS, SAFI: 128 330 This address-family is used to exchange private label-routes in 331 private MPLS-FIBs at routers that are connected using a common 332 network interface. The private label route has NLRI prefix format 333 "RD:PrivateLabel" and contains Route-Target extended-community 334 identifying the private-FIB-Layer (VPN) the route belongs to. The 335 nexthop of these routes is set to either the GPNH or the CPNH of the 336 BGP-speaker advertising the RFC-8277 label. 338 Any transport layer protocol is used to advertise the Context-Label 339 that the receiving router uses to send traffic into the private MPLS- 340 FIB. The Context-Label installed in the global MPLS-FIB points to 341 the private MPLS-FIB. The Context-Label is required when the 342 connecting-interface is a shared common interface that terminates 343 into the global MPLS FIB. 345 Routes of this address-family can be sent with either IPv4 or IPv6 346 nexthop. The type of nexthop is inferred from the length of the 347 nexthop. 349 When the length of Next Hop Address field is 24 (or 48) the nexthop 350 address is of type VPN-IPv6 with 8-octet RD set to zero (potentially 351 followed by the link-local VPN-IPv6 address of the next hop with an 352 8-octet RD). 354 When the length of Next Hop Address field is 12 the nexthop address 355 is of type VPN-IPv4 with 8-octet RD. 357 5.1.2. AFI: MPLS, SAFI: 1 359 This address-family is used to exchange private label-routes in 360 private MPLS-FIBs to routers that are connected using a private 361 network-interface. 363 Because the interface is private, and terminates directly into the 364 private MPLS-FIB, a Context-Label is not required to access the 365 private MPLS-FIB and NLRI prefix format is just "PrivateLabel/24", 366 without the RD. 368 Routes of this address-family can be sent with either IPv4 or IPv6 369 nexthop. The type of nexthop is inferred from the length of the 370 nexthop. 372 When the length of Next Hop Address field is 16 (or 32) the nexthop 373 address is of type IPv6 (potentially followed by the link-local IPv6 374 address of the next hop). 376 When the length of Next Hop Address field is 4 the nexthop address is 377 a 4 octet IPv4 address. 379 5.2. Routes and Operational procedures 381 5.2.1. "Context-Nexthop" discovery route 383 The Context-NH discovery route may be a BGP-LU or [BGP-CT] family 384 route that carries CPNH in the "Prefix" portion of the NLRI. And the 385 Context-Label is carried in the "Label" field in the [RFC8277] format 386 NLRI. 388 This route is advertised with the following path-attributes: 390 o BGP Nexthop attribute (code 14, MP_REACH) carrying GPNH address. 392 o Route-Target extended community, identifying the Transport class, 393 if applicable. 395 The "Context-Nexthop discovery route" is originated by each speaker 396 who acts as a PLER. The "RD:Context-nexthop" uniquely identifies the 397 private-MPLS-FIB at the speaker. The "Context-nexthop address" 398 uniquely identifies the private-MPLS-plane in the network. The 399 Context-Label advertised in this route has a local forwarding 400 semantic of "Pop, Lookup in Private-MPLS-FIB". 402 A BGP speaker readvertising a BGP-CT Context-Nexthop for RD:CPNH 403 discovery-route MUST follow the mechanisms described in [BGP-CT]. 404 Specifically when re-advertising with "next-hop self" MUST allocate a 405 new Label with a forwarding semantic of "Swap Received-Context-Label, 406 Forward to Received-GPNH". This extends reachability to the CPNH 407 across tunnel domains. 409 5.2.2. MPLS namespace "Private Label" routes 411 The Private Label routes are carried in the new address-family "MPLS 412 VpnUnicast" (AFI:MPLS, SAFI:128) aka "MPLS-namespace signaling", 413 defined in this document. 415 The NLRI format follows the specifications in [RFC8277], with the 416 "Prefix" portion of the NLRI comprising of the RD and "Private MPLS 417 Label" encoded as shown below. 419 In a MP_REACH_NLRI attribute whose AFI/SAFI is MPLS/128, the "Length" 420 field will be 112 bits or less, comprising of the Label, RD and 421 "Private MPLS Label". 423 In a MP_REACH_NLRI attribute whose AFI/SAFI is MPLS/1, the "Length" 424 field will be 48 bits or less, comprising of the Label, and "Private 425 MPLS Label". 427 NLRI Prefix (Private Label route, AFI:MPLS, SAFI:128) 429 This picture shows NLRI format when the RFC-8277 Multiple Labels 430 Capability is not used: 432 0 1 2 3 433 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 434 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 435 | Length | Label |Rsrv |S| 436 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 437 | Route Distinguisher (RD) (8 octets) | 438 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 439 | Route Distinguisher (RD cont.) | 440 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 441 | Private MPLS Label |Rsrv |S| 442 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 444 Fig 1: RFC-8277 NLRI with one Label. 446 - Length: 447 The Length field consists of a single octet. It specifies the 448 length in bits of the remainder of the NLRI field. 450 In a MP_REACH_NLRI attribute whose AFI/SAFI is MPLS/128, the 451 "Length" field will be 112 bits or less, comprising of the 452 Label, RD and "Private MPLS Label". 454 As specified in [RFC4760], the actual length of the NLRI field 455 will be the number of bits specified in the Length field, 456 rounded up to the nearest integral number of octets. 458 - Label: 459 The Label field is a 20-bit field containing an MPLS label value 460 (see [RFC3032]). This label is locally significant, downstream 461 allocated at the speaker identified in the BGP Nexthop field 462 in MP_REACH_NLRI (code 14). This label is pushed in nexthop of 463 the route installed in MPLS context FIB at receiving router. 465 - Route Distinguisher (RD): 466 The 8 byte Route Distinguisher as specified in [RFC4760]. 468 - Private MPLS Label: 469 The "Private MPLS Label" field is a 20-bit field containing an 470 MPLS label value (see [RFC3032]). This is an upstream assigned 471 MPLS label, used as destination of route installed in MPLS 472 context FIB at the receiving router. 474 - Rsrv: 475 This 3-bit field SHOULD be set to zero on transmission and 476 MUST be ignored on reception. 478 - S: 479 This 1-bit field MUST be set to one on transmission and MUST 480 be ignored on reception. 482 Attributes on this route: 484 o BGP Nexthop attribute (code 14, MP_REACH) carrying a GPNH address. 485 (OR) 487 o The Multi-nexthop attribute [MULTI-NH] with forwarding-semantic: 489 * "Forward to RD:CPNH" 491 o Route-Target extended-community, identifying the private FIB-layer 493 MultiNexthop BGP-attribute (Private Label route) 495 +--------------------------------------------+ 496 | MultiNH.Num-Nexthops = 1 | 497 +--------------------------------------------+ 498 | FwdSemanticsTLV.FwdAction = Forward | 499 +--------------------------------------------+ 500 | NHDescrTLV.NhopDescrType = RD:CPNH or GPNH| 501 +--------------------------------------------+ 503 Fig 2: MultiNexthop attr of Private Label route 505 A speaker MAY readvertise a private-label-route without changing the 506 Nexthop (RD:CPNH) carried in it, if the speaker is a pure PLSR. 508 If it does alter the nexthop to SelfRD:CPNH, it SHOULD act as a PLER, 509 and for e.g. originate a "Context-Nexthop discovery route" for prefix 510 "SelfRD:CPNH". 512 Even if the speaker sets nexthop-address to Self because of regular 513 BGP readvertisement-rules, Label Prefix MUST NOT be altered, and the 514 received NLRI "RD:Private-Label1" MUST be re-advertised as-is. Such 515 that value of label "Private-Label1" doesn't change while the packet 516 traverses multiple nodes in the private-MPLS-FIB-layer. 518 The Route-target attached to the route is the one identifying the 519 private MPLS FIB layer (VPN). The Private-label routes resolve over 520 the Context-nexthop route that belong to the same VPN. 522 A node receiving a "Private-Label route" RD:L1 MUST install the label 523 L1 in the private MPLS Forwarding-context idenfied by the Route- 524 Target attached to the route. 526 The label route MUST be installed with forwarding-semantic as 527 specified in the received Multi-nexthop attribute. As an example, a 528 Detour node MAY receive the private-label-route with a forwarding- 529 semantic of "Forward to RD:CPNH" operation. And an Egress node MAY 530 receive a private-label-route with a forwarding-semantic pointing to 531 a resource it houses. Note that such a Private-label BGP-route MAY 532 be received from external-application also. 534 5.2.2.1. Resolving received Private Label-routes 536 A node receiving a "Context-nexthop discovery route" MUST be capable 537 of using either the CPNH or the RD:CPNH carried in the NLRI, to 538 resolve other routes received with this CPNH address or RD:CPNH in 539 the "Nexthop-attributes". 541 The receiver of a private-label route MUST recursively resolve the 542 received nexthop (RD:CPNH) over the Context-Nexthop discovery-route 543 for prefix "RD:CPNH" to determine the label stack "Context-Label, 544 Transport-Label" to push, so that the MPLS packet with private-label 545 reaches the private MPLS FIB originating the route. 547 If a node receives multiple "Context-nexthop discovery route" for a 548 CPNH, it SHOULD run path-selection after stripping the RD, to find 549 the closest ingress to the private-MPLS-plane identified by the CPNH. 550 This best path SHOULD be used to resolve a received private-label- 551 route. 553 6. Example of Usecases 555 6.1. Mezanine transport layer in a Seamless-MPLS network 557 Typically service-routes in a MPLS network bind to the following 558 entities that identify point-of-presence of a service: 560 o Protocol Nexthop - PE loopback address (GPNH) 562 o Service Label - PE advertised locally signifcant label that 563 identifies the service 565 In this model, whenever a PE is taken out of service the GPNH 566 changes, and Service-Label changes - which causes maintenance a heavy 567 convergence event. Because the service-routes with massive-scale 568 need to be readvertised with new service-label or PE-address. 570 An alternate model could be: to advertise the Service-routes with a 571 protocol-nexthop of CPNH (without RD), with a forwarding-semantic of: 573 o "Push , and Forward to CPNH" 574 This model fully decouples the service-layer from the transport-layer 575 identifiers, by making the Service-routes refer to the CPNH and 576 Private-Labels. Thus the underlying transport-layer can change 577 (nodes representing a Private-label can be added or removed) without 578 any changes to the service-routes. Which present good scaling 579 properties for the network. 581 This model also allows anycast traffic forwarding to any resource in 582 the network. Multiple PEs can advertise the same Private-Label to 583 identify a specific service (e.g. peering with an AS) they are 584 offering. 586 Once the service-route traffic enters the private-FIB-layer, at the 587 closest entry-point determined by path-selection of CPNH auto- 588 discovery routes; then the Private-Labels (with pre-determined 589 values) pushed will determine the loose hop path taken by the traffic 590 and also the destination-resource. 592 6.2. Service Forwarding Helper usecase 594 In a virtualized environment a Service-PE node (that comprises of a 595 vCP and multiple vFPs) can mirror MPLS labels (GL1) in its global 596 MPLS-FIB to a private forwarding context at an upstream node (SFH) 597 with information on which vFPs are optimal exit-points for that 598 label. Such that the SFH can optimally forward traffic to GL1 to the 599 right vFPs, thus avoiding intra fabric traffic hops. 601 To do this, the service-PE advertises a private-label route with 602 RD:GL1 to the SFH node. The route is advertised with a Multi-nexthop 603 attribute with one or more legs that have a "Forward to SEPx" 604 semantics. Where SEPx is one of many exit-points at the Service-PE 605 node. 607 6.3. Standard BGP API to a MPLS network's forwarding-plane 609 This mechanism facilitates predictable (external-allocator 610 determined) label-values, using a standard BGP-family as the API. It 611 gives the external applications a separate MPLS-FIB to play with, 612 totally separate from other applications. 614 This also avoids vendor specific-API dependencies for external- 615 allocators (controller softwares), and vice-versa. 617 This mechanism also increases the overal MPLS label-space available 618 in the network, because it creates per-app label-forwarding-contexts 619 (namespaces), instead of reserving/splitting the global MPLS FIB 620 among various applications. 622 6.4. Traffic engineering and Security advantages 624 o Ability of ingress to steer mpls-traffic thru specific detour 625 loose-hop nodes using predictable-labels' stack. 627 o Provide label-spoofing protection at edge-nodes - by virtue of 628 using separate mpls-forwarding-contexts 630 o Allow private-MPLS label usage to spread across multiple-domains/ 631 AS and work seamlessly with existing technologies like Inter-AS 632 VPN option C. 634 7. IANA Considerations 636 This document makes following requests of IANA. 638 New BGP AFI code: 640 o for "MPLS" 642 Note to RFC Editor: this section may be removed on publication as an 643 RFC. 645 8. Security Considerations 647 Using separate mpls-forwarding-contexts for separate applications and 648 stitching them into separate MPLS-planes increases the security 649 attributes of the MPLS network. 651 9. Acknowledgements 653 The authors thank Jeffrey (Zhaohui) Zhang, Ron Bonica, Jeff Haas and 654 John Scudder for the valuable discussions. 656 10. Normative References 658 [BGP-CT] Vairavakkalai, K., "BGP Classful Transport Planes", June 659 2021, . 662 [MULTI-NH] 663 Vairavakkalai, K., "BGP MultiNexthop attribute", June 664 2021, . 667 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 668 Requirement Levels", BCP 14, RFC 2119, 669 DOI 10.17487/RFC2119, March 1997, 670 . 672 [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private 673 Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February 674 2006, . 676 [RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, 677 "Multiprotocol Extensions for BGP-4", RFC 4760, 678 DOI 10.17487/RFC4760, January 2007, 679 . 681 [RFC5331] Aggarwal, R., Rekhter, Y., and E. Rosen, "MPLS Upstream 682 Label Assignment and Context-Specific Label Space", 683 RFC 5331, DOI 10.17487/RFC5331, August 2008, 684 . 686 [RFC8277] Rosen, E., "Using BGP to Bind MPLS Labels to Address 687 Prefixes", RFC 8277, DOI 10.17487/RFC8277, October 2017, 688 . 690 Authors' Addresses 692 Kaliraj Vairavakkalai 693 Juniper Networks, Inc. 694 1133 Innovation Way, 695 Sunnyvale, CA 94089 696 US 698 Email: kaliraj@juniper.net 700 Minto Jeyananth 701 Juniper Networks, Inc. 702 1133 Innovation Way, 703 Sunnyvale, CA 94089 704 US 706 Email: minto@juniper.net