idnits 2.17.1 draft-kaliraj-bess-bgp-sig-private-mpls-labels-00.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 (June 22, 2017) is 2492 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 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: December 24, 2017 June 22, 2017 7 BGP signalled private MPLS-labels 8 draft-kaliraj-bess-bgp-sig-private-mpls-labels-00 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 http://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 December 24, 2017. 51 Copyright Notice 53 Copyright (c) 2017 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 (http://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 . . . . . . . . . . . . . . . . . . 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. "Private Label" routes . . . . . . . . . . . . . . . 10 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 . . . . . . . . . . . . 12 89 6.3. Standard BGP API to a MPLS network's forwarding-plane . . 13 90 6.4. Traffic engineering and Security advantages . . . . . . . 13 91 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 92 8. Security Considerations . . . . . . . . . . . . . . . . . . . 14 93 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14 94 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 95 11. Normative References . . . . . . . . . . . . . . . . . . . . 14 96 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 98 1. Introduction 100 The MPLS-forwarding-layer in a core network is a shared resource. 101 The MPLS FIB at nodes in this layer contains labels that are 102 dynamically allocated and locally significant at that node. 104 For some usecases like upstream-label-allocation, it is useful to be 105 able to create virtual private MPLS-forwarding-layers over this 106 shared MPLS-forwarding-layer. This allows installing deterministic 107 private label-values in the private-FIBs in this private forwarding- 108 layer, while preserving the "locally significant" nature of the 109 underlying shared 'public' MPLS-forwarding-layer. 111 It can be noted that, mechanism described in this document is nothing 112 but a [RFC-4364] style BGP VPN where the FEC is MPLS-Label, instead 113 of IP-prefix. This document defines new address-families (AFI: MPLS, 114 SAFI: VPN-Unicast, Unicast) and associated signaling mechanisms to 115 create and use MPLS forwarding-contexts in a network. The concepts 116 of MPLS-Context-tables and upstream allocation are described in [RFC- 117 5331]. 119 BGP speakers participating in the private MPLS FIB layer create 120 instances of "MPLS forwarding-context" FIBs, which are identified 121 using a "Context-Protocol-Nexthop (CPNH)". A Context-label MAY be 122 advertised in conjunction with the Context Protocol Nexthop (CPNH) 123 using new BGP address-family to other speakers. 125 2. Motivation 127 A provider's core network consists of a global-domain (default 128 forwarding-tables in P and PE nodes) that is shared by all tenants in 129 the network and may also contain multiple private user-domains (e.g. 130 VRF route tables). 132 The global MPLS forwarding-layer can be viewed as the collection of 133 all default MPLS forwarding-tables. This global MPLS Fib layer 134 contains labels locally significant to each node. The "local- 135 significance of labels" gives the nodes freedom to participate in 136 MPLS-forwarding with whatever label-ranges they can support in 137 forwarding hardware. 139 In emerging usecases some applications using the MPLS-network may 140 benefit from a "static labels" view of the MPLS-network. In some 141 other usecases, a standard mechanism to do Upstream label-allocation 142 is beneficial. 144 It is desirable to leave the global MPLS FIB layer intact, and build 145 private MPLS FIB-layers on top of it to achieve these requirements. 147 The private-MPLS-FIBs can then be used by the applications as 148 desired. The private MPLS-FIBs need to be created only at the nodes 149 in the network where predictable label-values (external label 150 allocation) is desired. E.g. P-routers that need to act as a 151 "Detour-nodes" or "Service-Forwarding-Helpers" that need to mirror 152 service-labels. 154 In other words, provisioning of these private MPLS-FIBs can be 155 gradual and can co-exist with nodes not supporting the feature 156 described in this document. These private-MPLS-FIBs can be stitched 157 together using either the Context-labels over the existing shared 158 MPLS-network tunnels, or 'private' context-interfaces - to form the 159 "private MPLS-FIB layer". 161 An application can then install the routes with desired label-values 162 in the private forwarding-contexts with desired forwarding-semantics. 164 3. Constructs and building blocks 166 The building-blocks that construct a private MPLS plane are described 167 in this section. 169 3.1. Context Protocol Nexthop Address 171 A private MPLS plane (just "MPLS plane" here-after) is identified by 172 an IP-address called Context Protocol Nexthop (CPNH). This address 173 is unique in the core-network, like any other loopback address. 175 A loopback-address uniquely identifies a specific node in the 176 network, and we call it Global Protocol Nexthop (GPNH) in this 177 document. The CPNH address uniquely identifies a "MPLS-plane". 179 Each node that has forwarding-context for a MPLS-plane MUST be 180 configured with the same CPNH but a different RD, such that the 181 RD:CPNH will uniquely identify that node in the MPLS-plane. 183 3.2. MPLS context FIB 185 An instance of a MPLS forwarding-table at a node in the private MPLS- 186 plane. This Private MPLS FIB contains the private-label routes. 188 A node can have context-FIB for multiple MPLS-planes. The same 189 label-value can have a different forwarding-semantic in each MPLS- 190 plane. Thus the applications using that MPLS-plane get a 191 deterministic label-value independent of other applications using 192 other MPLS-planes. 194 The terms "private MPLS FIB-layer" and "private MPLS-plane" are used 195 interchangeably in this document. 197 3.3. Context Label 199 A context-label is a non-reserved dynamically allocated label, that 200 is installed in the global MPLS FIB, and points to a MPLS-Context- 201 FIB. The Context-Label have forwarding semantics as follows in the 202 global MPLS-FIB: 204 Context-Label -> Pop and Lookup in MPLS-Context-Fib 206 Advertising the "Context-Label in conjunction with the GPNH" tells 207 the network how to reach a "RD:CPNH". 209 3.4. Roles of nodes in a MPLS-plane 211 The node roles in a MPLS-plane can be classified into "edge nodes" 212 (call them PLER) or "transit-nodes" (call them PLSR). 214 3.4.1. Edge-nodes (PLER) 216 Private Label Edge-routers (PLER) have MPLS context-FIB that belong 217 to the MPLS-plane. They advertise the presence of this context-FIB, 218 and private-label routes from this FIB, using new BGP AFI/SAFI 219 described in this document. 221 3.4.2. Transit-nodes (PLSR) 223 Private Label Transit-nodes do label-swap forwarding for the Context- 224 Labels they see in the Context-Protocol-Nexthop advertisement routes 225 going thru them. They basically stitch/extend the label switched 226 path to a RD:CPNH when they re-advertise the CPNH routes with 227 nexthop-self. 229 PLSRs dont have 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 MPLS-traffic arriving with private-labels hits the correct private 237 MPLS-FIB by virtue of either arriving on a "private network- 238 interface" that is attached to the FIB, or arriving on a shared 239 network-interface with a "Context-label". 241 To send data traffic into this private MPLS FIB-layer, the 242 application MUST use as handle either a "Context-label" advertised by 243 a node or a "Private-interface" owned by the application at the node. 245 The Context-Label is the only label-value the application needs to 246 learn from the network (PLER node it is connected to), to be able to 247 use the private MPLS-plane. The application can decide the value of 248 the labels to be programmed in the private MPLS-FIBs. 250 Once the packet enters the private MPLS plane at an edge-node (PLER), 251 the node will forward the packet to the next node (PLSR or PLER), by 252 pushing the Context-label advertised by that next-node, and the 253 transport-label to reach that node's GPNH. This will repeat until 254 the packet reaches the private MPLS-FIB that originated that private 255 MPLS-label. 257 At each PLER in the MPLS-plane, the private-label value remains the 258 same, and points towards the same resource attached to the MPLS- 259 plane. This allows the applications using the MPLS-network a static- 260 labels view of the resourses attached to the private MPLS-plane. 262 At each PLSR in the MPLS-plane, the context-label value will change 263 (be swapped in forwarding), but is transparent to the application. 265 4. Terminology 267 P-router : A Provider core router, also called a LSR 269 LSR : Label Switch Router (pure transport node speaking LDP, RSVP 270 etc) 272 PLSR: a transit node in a private MPLS-plane. It has a forwarding- 273 context for private-labels. 275 PLER: an edge node in a private MPLS-plane. It has a forwarding- 276 context for private-labels. 278 Detour-router : A P-router that is used as a loose-hop in a traffic- 279 engineered path 281 PE-router : Provider Edge router, that hosts a service (Internet, 282 L3VPN etc) 284 SE-router : Service Edge router. Same as PE. 286 SFH-router : Service Forwarding Helper. A node helping an SE-router 287 with service-traffic forwarding, using Service-routes mirrored by the 288 SE. 290 MPLS FIB : MPLS Forwarding table 292 Global MPLS FIB : Global MPLS Forwarding table, to which shared- 293 interfaces are connected 295 Private MPLS FIB : Private MPLS Forwarding table, to which private- 296 interfaces are connected 298 Private MPLS FIB Layer : The group of Private MPLS FIBs in the 299 network, connected together via Context-Labels 301 Context-Label : Locally-significant Non-reserved label pointing to a 302 private MPLS FIB 304 Context nexthop IP-address (CPNH) : An IP-address that identifies the 305 "Private MPLS FIB Layer". RD:CPNH identifies a Private MPLS FIB at a 306 node. 308 Global nexthop IP-address (GPNH) : Global Protocol Nexthop address. 309 E.g. a loopback address used as transport tunnel end-point. 311 5. BGP families, routes and encoding 313 This section describes the new constructs defined by this document. 315 5.1. New address-families 317 This document defines a new AFI: "MPLS". And two new address- 318 families. 320 5.1.1. AFI: MPLS, SAFI: 128 322 This address-family is used to exchange private label-routes into 323 private MPLS-FIBs at routers that are connected using a common 324 network-interface. 326 Routes in this family contain Route-Target extended-community 327 identifying the private-FIB-Layer (VPN) the route belongs to. This 328 address-family also advertises the Context-Label that the receiving 329 router uses to access the private MPLS-FIB. The Context-Label is 330 required when the connecting-interface is a shared common interface 331 that terminates into the global MPLS FIB. The Context-Label 332 installed in the global MPLS-FIB points to the private MPLS-FIB. 334 5.1.2. AFI: MPLS, SAFI: 1 336 This address-family is used to exchange private label-routes in 337 private MPLS-FIBs to routers that are connected using a private 338 network-interface. 340 Because the interface is private, and terminates directly into the 341 private MPLS-FIB, a Context-Label is not required to access the 342 private MPLS-FIB. 344 5.2. Routes and Operational procedures 346 5.2.1. "Context-Nexthop" discovery route 348 NLRI prefix 350 +--------------------------------------------+ 351 | Route Type = 1 (2 octets) | 352 +--------------------------------------------+ 353 | Route Distinguisher (RD) (8 octets) | 354 +--------------------------------------------+ 355 | NH-Len in bits (1 octets) | 356 +--------------------------------------------+ 357 | Context-Nexthop IP-address | 358 +--------------------------------------------+ 360 The Context-NH discovery route contains the following path- 361 attributes: 363 o The BGP MultiNexthop-attribute [BGP_MULTI_NH] with forwarding- 364 semantic: 366 * Push to GPNH (for AFI, SAFI: "MPLS, VpnUni"), 367 OR 369 * Forward to GPNH (for AFI, SAFI: "MPLS, Uni") 371 o Route-Target extended community, identifying the private FIB-layer 372 MultiNexthop BGP-attribute 374 +--------------------------------------------+ 375 | MultiNH.NumNexthops = 1 | 376 +--------------------------------------------+ 377 | FwdSemanticsTLV.FwdAction = Push | 378 +--------------------------------------------+ 379 | NhopDescrType = Labeled-IP-Nhop | 380 + + 381 | Nexthop-Leg = (Context-Label, GPNH) | 382 +--------------------------------------------+ 384 The "Context-Nexthop discovery route" is originated by each speaker 385 who acts as a PLER. The "RD:Context-nexthop" uniquely identifies the 386 private-FIB at the speaker. The "Context-nexthop address" uniquely 387 identifies the private-FIB-layer. 389 A speaker (re)advertising a Context-Nexthop discovery-route with 390 "next-hop self" MUST allocate a new Context-Label with a forwarding 391 semantic of "Swap Received-Context-Label, Forward to Received-GPNH". 392 This new Context-label along with self-GPNH is advertised in the 393 Multinexthop-attribute [MULTI_NH] attached to the re-advertised 394 Context-nexthop discovery route. 396 5.2.1.1. Crossing Tunneled domain boundary 398 "Nexthop-attributes" include BGP Nexthop attribute (code 3), Nexthop- 399 field inside MP_Reach attribute (code 14) or the Multi-Nexthop BGP 400 attribute (code TBD). Two nodes are deemed to be in same tunneled- 401 domain-boundary if they have some sort of transport-tunnel 402 reachability between them (LDP, RSVP, BGP-LU). 404 A node receiving a "Context-nexthop discovery route" MAY re-advertise 405 it to other BGP speakers who have negotiated the address-family 406 carrying the route. While doing so, the node SHOULD NOT reset the 407 RD:GPNH next-hop address carried in the "Nexthop-attributes" if the 408 re-advertisement does not cross tunneled-domain boundaries. 410 If a Context-nexthop discovery route is re-advertised across 411 tunneled-domain-boundaries, the re-advertising node MUST set nexthop- 412 address carried in the "Nexthop-attributes" to Self's GPNH, and 413 allocate a new non-reserved label. The route advertised further MUST 414 carry a Multi-nexthop attribute with a forwarding semantic of: 416 o "SWAP and Forward to Received-GPNH". 418 This new-context-label is installed in the global MPLS FIB at the 419 advertising node. And is used as the Context-Label in the re- 420 advertised RD:CPNH route's Multi-Nexthop attribute, with a 421 forwarding-semantic of: 423 o "Push and Forward to Advertising-GPNH" 425 . 427 5.2.2. "Private Label" routes 429 NLRI prefix (Private Label route) 431 +--------------------------------------------+ 432 | Route Type = 2 (2 octets) | 433 +--------------------------------------------+ 434 | Route Distinguisher (RD) (8 octets) | 435 +--------------------------------------------+ 436 | 3107 Private Label value | 437 +--------------------------------------------+ 439 Private-Label-Value: The (upstream assigned) label value 441 Attributes on this route: 443 o The Multi-nexthop attribute with forwarding-semantic: 445 * "Forward to RD:CPNH" 447 o Route-Target extended-community, identifying the private FIB-layer 449 MultiNexthop BGP-attribute (Private Label route) 451 +--------------------------------------------+ 452 | MultiNH.Num-Nexthops = 1 | 453 +--------------------------------------------+ 454 | FwdSemanticsTLV.FwdAction = Forward | 455 +--------------------------------------------+ 456 | NHDescrTLV.NhopDescrType = RD-IP-Nhop | 457 + + 458 | "RD:CPNH" advertised in Type1 route | 459 +--------------------------------------------+ 461 A speaker MAY readvertise a private-label-route without changing the 462 Nexthop (RD:CPNH) carried in it, if the speaker is a pure PLSR. 464 If it does alter the nexthop to SelfRD:CPNH, it SHOULD act as a PLER, 465 and for e.g. originate a "Context-Nexthop discovery route" for prefix 466 "SelfRD:CPNH". 468 Even if the speaker sets nexthop-address to Self because of regular 469 BGP readvertisement-rules, new label MUST NOT be allocated, and the 470 received NLRI "RD:Private-Label1" MUST be re-advertised as-is. Such 471 that value of label "Private-Label1" doesn't change while the packet 472 traverses multiple nodes in the private-MPLS-FIB-layer. 474 The Route-target attached to the route is the one identifying the 475 private MPLS FIB layer (VPN). The Private-label routes resolve over 476 the Context-nexthop route that belong to the same VPN. 478 A node receiving a "Private-Label route" RD:L1 MUST install the label 479 L1 in the private MPLS Forwarding-context idenfied by the Route- 480 Target attached to the route. 482 The label route MUST be installed with forwarding-semantic as 483 specified in the received Multi-nexthop attribute. As an example, a 484 Detour node MAY receive the private-label-route with a forwarding- 485 semantic of "Forward to RD:CPNH" operation. And an Egress node MAY 486 receive a private-label-route with a forwarding-semantic pointing to 487 a resource it houses. Note that such a Private-label BGP-route MAY 488 be received from external-application also. 490 5.2.2.1. Resolving received Private Label-routes 492 A node receiving a "Context-nexthop discovery route" MUST be capable 493 of using either the CPNH or the RD:CPNH carried in the NLRI, to 494 resolve other routes received with this CPNH address or RD:CPNH in 495 the "Nexthop-attributes". 497 The receiver of a private-label route MUST recursively resolve the 498 received nexthop (RD:CPNH) over the Context-Nexthop discovery-route 499 for prefix "RD:CPNH" to determine the label stack "Context-Label, 500 Transport-Label" to push, so that the MPLS packet with private-label 501 reaches the private MPLS FIB originating the route. 503 If a node receives multiple "Context-nexthop discovery route" for a 504 CPNH, it SHOULD run path-selection after stripping the RD, to find 505 the closest ingress to the private-MPLS-plane identified by the CPNH. 506 This best path SHOULD be used to resolve a received private-label- 507 route. 509 6. Example of Usecases 511 6.1. Mezanine transport layer in a Seamless-MPLS network 513 Typically service-routes in a MPLS network bind to the following 514 entities that identify point-of-presence of a service: 516 o Protocol Nexthop - PE loopback address (GPNH) 518 o Service Label - PE advertised locally signifcant label that 519 identifies the service 521 In this model, whenever a PE is taken out of service the GPNH 522 changes, and Service-Label changes - which causes maintenance a heavy 523 convergence event. Because the service-routes with massive-scale 524 need to be readvertised with new service-label or PE-address. 526 An alternate model could be: to advertise the Service-routes with a 527 protocol-nexthop of CPNH (without RD), with a forwarding-semantic of: 529 o "Push , and Forward to CPNH" 531 This model fully decouples the service-layer from the transport-layer 532 identifiers, by making the Service-routes refer to the CPNH and 533 Private-Labels. Thus the underlying transport-layer can change 534 (nodes representing a Private-label can be added or removed) without 535 any changes to the service-routes. Which present good scaling 536 properties for the network. 538 This model also allows anycast traffic forwarding to any resource in 539 the network. Multiple PEs can advertise the same Private-Label to 540 identify a specific service (e.g. peering with an AS) they are 541 offering. 543 Once the service-route traffic enters the private-FIB-layer, at the 544 closest entry-point determined by path-selection of CPNH auto- 545 discovery routes; then the Private-Labels (with pre-determined 546 values) pushed will determine the loose hop path taken by the traffic 547 and also the destination-resource. 549 6.2. Service Forwarding Helper usecase 551 In a virtualized environment a Service-PE node (that comprises of a 552 vCP and multiple vFPs) can mirror MPLS labels (GL1) in its global 553 MPLS-FIB to a private forwarding context at an upstream node (SFH) 554 with information on which vFPs are optimal exit-points for that 555 label. Such that the SFH can optimally forward traffic to GL1 to the 556 right vFPs, thus avoiding intra fabric traffic hops. 558 To do this, the service-PE advertises a private-label route with 559 RD:GL1 to the SFH node. The route is advertised with a Multi-nexthop 560 attribute with one or more legs that have a "Forward to SEPx" 561 semantics. Where SEPx is one of many exit-points at the Service-PE 562 node. 564 6.3. Standard BGP API to a MPLS network's forwarding-plane 566 This mechanism facilitates predictable (external-allocator 567 determined) label-values, using a standard BGP-family as the API. It 568 gives the external applications a separate MPLS-FIB to play with, 569 totally separate from other applications. 571 This also avoids vendor specific-API dependencies for external- 572 allocators (controller softwares), and vice-versa. 574 This mechanism also increases the overal MPLS label-space available 575 in the network, because it creates per-app label-forwarding-contexts 576 (namespaces), instead of reserving/splitting the global MPLS FIB 577 among various applications. 579 6.4. Traffic engineering and Security advantages 581 o Ability of ingress to steer mpls-traffic thru specific detour 582 loose-hop nodes using predictable-labels' stack. 584 o Provide label-spoofing protection at edge-nodes - by virtue of 585 using separate mpls-forwarding-contexts 587 o Allow private-MPLS label usage to spread across multiple-domains/ 588 AS and work seamlessly with existing technologies like Inter-AS 589 VPN option C. 591 7. IANA Considerations 593 This document makes following requests of IANA. 595 New BGP AFI code: 597 o for "MPLS" 599 Which will be used to create new BGP AFI-SAFI pairs: 601 o MPLS Uni(SAFI:1), 603 o MPLS VpnUni(SAFI:128) 605 . 607 New NLRI Route-types for these AFI SAFIs: 609 o Type 1: Context-Nexthop-Discovery-route. 611 o Type 2: Private-Label route 613 Note to RFC Editor: this section may be removed on publication as an 614 RFC. 616 8. Security Considerations 618 Using separate mpls-forwarding-contexts for separate applications and 619 stitching them into separate MPLS-planes increases the security 620 attributes of the MPLS network. 622 9. Acknowledgements 624 The authors thank Jeffrey (Zhaohui) Zhang, Ron Bonica, Jeff Haas and 625 John Scudder for the valuable discussions. 627 10. References 629 [MULTI_NH] https://www.ietf.org/id/draft-kaliraj-idr-multinexthop- 630 attribute-00.txt 632 [RFC-4364] BGP/MPLS IP Virtual Private Networks (VPNs) 634 [RFC-5331] MPLS Upstream Label Assignment and Context-Specific Label 635 Space 637 11. Normative References 639 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 640 Requirement Levels", BCP 14, RFC 2119, 641 DOI 10.17487/RFC2119, March 1997, 642 . 644 Authors' Addresses 646 Kaliraj Vairavakkalai 647 Juniper Networks, Inc. 648 1194 N. Mathilda Ave. 649 Sunnyvale, CA 94089 650 US 652 Email: kaliraj@juniper.net 653 Minto Jeyananth 654 Juniper Networks, Inc. 655 1194 N. Mathilda Ave. 656 Sunnyvale, CA 94089 657 US 659 Email: kaliraj@juniper.net