idnits 2.17.1 draft-ravisingh-mpls-el-for-seamless-mpls-01.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 46 instances of lines with control characters in the document. -- The abstract seems to indicate that this document updates RFC6790, but the header doesn't have an 'Updates:' line to match this. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 393 has weird spacing: '...covered by th...' == Line 823 has weird spacing: '...s where a lab...' == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: Preventing insertion of multiple (ELI+EL)s: At an ingress LER, the router SHOULD not insert an (ELI+EL) for an LSP if the packet already contains an ELI. -- The document date (October 21, 2013) is 3840 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: 'RFC2119' is mentioned on line 154, but not defined == Unused Reference: 'ISSUE-DEEP' is defined on line 960, but no explicit reference was found in the text ** Downref: Normative reference to an Informational draft: draft-leymann-mpls-seamless-mpls (ref. 'S-MPLS') -- Obsolete informational reference (is this intentional?): RFC 3107 (ref. 'LU-BGP') (Obsoleted by RFC 8277) Summary: 2 errors (**), 0 flaws (~~), 6 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MPLS Working Group R. Singh 3 INTERNET-DRAFT Y. Shen 4 Intended Status: Proposed Standard J. Drake 5 Expires: April 24, 2014 Juniper Networks 6 October 21, 2013 8 Entropy label for seamless MPLS 9 draft-ravisingh-mpls-el-for-seamless-mpls-01 11 Abstract 13 This document describes how entropy labels can be used for load 14 balancing in a seamless MPLS architecture. The definition of the 15 control plane and data plane behavior at LSP stitching points; and at 16 the ingress of an LSP in a hierarchy of LSPs, as described in this 17 document, brings the benefits of entropy labels to seamless MPLS as 18 MPLS deployments proliferate in the access and aggregation networks. 20 This document updates RFC 6790. 22 Status of this Memo 24 This Internet-Draft is submitted to IETF in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF), its areas, and its working groups. Note that 29 other groups may also distribute working documents as 30 Internet-Drafts. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 The list of current Internet-Drafts can be accessed at 38 http://www.ietf.org/1id-abstracts.html 40 The list of Internet-Draft Shadow Directories can be accessed at 41 http://www.ietf.org/shadow.html 43 This Internet-Draft will expire on August 22, 2013. 45 Copyright and License Notice 46 Copyright (c) 2013 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (http://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 62 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 5 63 3. Key attributes of the entropy label solution: Summary from 64 [EL-RFC] . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 65 4. Problems and Motivation . . . . . . . . . . . . . . . . . . . . 6 66 4.1 EL applicability for seamless MPLS . . . . . . . . . . . . . 7 67 4.2 EL for LSP stitching . . . . . . . . . . . . . . . . . . . . 7 68 4.2.1 Spectrum of EL usage behaviors required to be 69 supported for stitched LSPs . . . . . . . . . . . . . . 8 70 4.2.1.1 Entropy label for per-segment LSP . . . . . . . . . 9 71 4.2.1.2 Entropy label for notional-segment-LSP(s) . . . . . 9 72 4.2.1.3 Entropy label for e2e LSP . . . . . . . . . . . . . 10 73 4.3 EL for LSP hierarchy . . . . . . . . . . . . . . . . . . . . 10 74 4.3.1 Possibility of unnecessary reduction of max-payload of 75 the LSP: . . . . . . . . . . . . . . . . . . . . . . . . 10 76 4.3.2 Possibility of EL being non-usable for load-balancing: . 11 77 5. EL for LSP stitching/hierarchy . . . . . . . . . . . . . . . . 13 78 5.1 Additional EL abstractions: specific to LSP 79 stitching/hierarchy . . . . . . . . . . . . . . . . . . . . 13 80 5.2 New abstractions: EL applicability for LSP stitching . . . . 13 81 5.2.1 Signaling . . . . . . . . . . . . . . . . . . . . . . . 13 82 5.2.1.1 Signaling ELC at stitching points (Translation 83 rules) . . . . . . . . . . . . . . . . . . . . . . . 14 84 5.2.2 Data plane aspects . . . . . . . . . . . . . . . . . . . 15 85 5.2.2.1 Stitching: Differing EL dispositions . . . . . . . . 15 86 5.3 New abstractions: EL applicability for LSP hierarchy . . . . 18 87 5.3.1 Management plane: . . . . . . . . . . . . . . . . . . . 18 88 5.3.2 Data plane aspects . . . . . . . . . . . . . . . . . . . 18 89 6. Use-cases . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 90 6.1 Carrier of carrier L3VPN . . . . . . . . . . . . . . . . . . 20 91 6.2 Inter-AS L3VPN: Option C . . . . . . . . . . . . . . . . . . 21 93 7. Security considerations . . . . . . . . . . . . . . . . . . . . 21 94 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 21 95 9. IANA considerations . . . . . . . . . . . . . . . . . . . . . . 21 96 9 References . . . . . . . . . . . . . . . . . . . . . . . . . . 21 97 9.1 Normative References . . . . . . . . . . . . . . . . . . . 21 98 9.2 Informative References . . . . . . . . . . . . . . . . . . 22 99 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23 101 1 Introduction 103 [EL-RFC] specifies a way to implement load-balancing in an MPLS 104 network such that sub-flows of an LSP may be identified and sent on 105 different paths through the network. This is achieved by using 106 entropy labels (ELs) to abstract out the flow-identifying information 107 into the entropy label and inserting the entropy label underneath the 108 LSP label. The transit LSRs perform the load-balancing hash- 109 computation, on the label-stack alone, to effect a good load- 110 balancing outcome without a need to parse inner headers. 112 The key feature of [EL-RFC] is that it defines the EL in the context 113 of a given LSP. [EL-RFC] defines the signaling extensions by which 114 entropy label capability might be signaled for LSPs setup by RSVP-TE, 115 LDP or [LU-BGP]. While that works well for individual LSPs, there are 116 additional issues to consider for the seamless MPLS architecture [S- 117 MPLS]. 119 The currently-under-definition framework for seamless MPLS proposes 120 an architecture ([S-MPLS]) that shall enable the setting-up of MPLS 121 LSPs from access nodes to access nodes using a medley of signaling 122 protocols and statically configured LSPs. There are special EL- 123 related considerations that need to be dealt with to make EL more 124 suitable for seamless MPLS. 126 This document defines additional abstractions and rules for the use 127 of entropy-label with LSP stitching/hierarchy to enable the use of 128 ELs for the seamless MPLS architecture. This document describes how 129 entropy labels may be used when the LSP has been setup by stitching 130 LSP segments or by tunneling the LSP over other LSPs. It is 131 conceivable that different signaling protocols are in use to create 132 an e2e LSP. 134 LSP stitching is the process of connecting LSP segments in the data 135 plane to form a single e2e data plane LSP. This is achieved by 136 setting up LSP segments through signaling or through management 137 action, and then signaling an e2e LSP that "uses" these LSP segments 138 as hops in its path. The procedures for LSP stitching are described 139 in [STITCHING]. Labeled data traffic flowing over e2e MPLS LSPs, that 140 have been setup using multiple different protocols (by stitching 141 together segments), would benefit from having the entropy label be 142 included in it. 144 LSP hierarchy is defined in [MPLS-ARCH] and [GMPLS-HIER]. Usage of 145 entropy label in LSP hierarchies has some peculiar practical issues 146 that will benefit from some additional flexibility in inserting ELs 147 for a specific layer in an LSP hierarchy. 149 2. Terminology 151 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 152 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 153 document are to be interpreted as described in RFC 2119 [RFC2119]. 155 The following acronyms/terms are used: 157 e2e: End to end LSP that has been setup by stitching together LSP 158 segments 160 ECMP: Equal Cost Multi-Path 162 EL: Entropy Label 164 ELC: Entropy Label Capability or Entropy Label Capable 166 ELI: Entropy Label Indicator 168 Intrinsic ELC: Entropy label capability/capable as in [EL-RFC]. In 169 this document, an LSP is considered to be 170 "intrinsically" EL-capable when the: 171 - the ingress of the LSP has the ability to compute 172 and PUSH the EL before PUSHing the ELI before 173 PUSHing the LSP label; and 174 - the egress/PHR of the LSP-segment has the ability 175 to POP the (ELI+EL) at the egress/PHR while 176 POPing-transport-label/ELI-is-top-label 177 respectively. 179 LAG: Link Aggregation Group 181 LER: Label Edge Router 183 LSP: Label Switched Path 185 LSR: Label Switching Router 187 Notional ingress: Ingress LER for an LSP segment that is inserting 188 the (ELI+EL) on data traffic going over an e2e LSP 190 Notional egress: egress LER for an LSP segment that is removing the 191 (ELI+EL) from data traffic going over an e2e LSP 193 Notional LSP segment: the portion of the e2e LSP between a notional 194 ingress and a notional egress 196 PHP: Penultimate Hop Popping 198 PHR: Penultimate Hop Router 200 UHP: Ultimate Hop Popping 202 NOTE: this document references the (ELI+EL) pair simply as EL when 203 the presence of the ELI is of no significance for the issue 204 being described. The presence of ELI is mandatory as per 205 [EL-RFC] when EL is in use. 207 3. Key attributes of the entropy label solution: Summary from [EL-RFC] 208 - Transport-label-PUSHing router inserts (ELI+EL) 209 The (ELI+EL) insertion is done, if at all, by a router that is 210 PUSHing the transport LSP's label. 212 - Ingress-LER (transport-label-PUSHing-router) inserts (ELI+EL) 213 only if the PHR/egress has signaled ability to strip it off. 215 - Transport-label-POPing router POPs (ELI+EL) PHR/egress of the 216 LSP is responsible for POPing off the (ELI+EL) after it has 217 been exposed as the top label on the packet due to POPing the 218 transport label. The removal of the (ELI+EL) is done either 219 when the ELI is the top label; or when the ELI is next label 220 below the top label being POPed. 222 - Max-payload size for the LSP gets reduced by 8 bytes after the 223 insertion of the (ELI+EL). 225 4. Problems and Motivation 227 [EL-RFC] defines EL signaling/usage suitable for single-segment LSPs. 228 However, as MPLS proliferates in the network access leading to the 229 setup of e2e LSPs using LSP stitching and hierarchies, there is a 230 need to define the EL behavior for LSP stitching and LSP hierarchies. 232 [EL-RFC] does not explicitly specify the EL-signaling-interaction 233 between stitched LSPs segments. Similarly, peculiarities in the data- 234 plane related to LSP stitching need further specification. Likewise, 235 the signaling and data-plane peculiarities for using EL over LSP 236 hierarchies could be further specified. 238 It is desirable to get the benefits of EL even for stitched LSPs. 240 Certain aspects peculiar to stitched LSPs need additional handling to 241 increase the applicability of [EL-RFC]. [EL-RFC] needs to be extended 242 to define the behavior for LSP stitching and LSP hierarchies 243 (tunneling) when using EL. 245 The sub-sections below list the specific additional requirements for 246 making entropy label more deployable when used with LSP stitching, 247 and LSP hierarchy. 249 4.1 EL applicability for seamless MPLS 251 The seamless MPLS architecture relies on the use of LSP stitching and 252 hierarchy to signal an e2e LSP between access-nodes, such that the 253 e2e LSP is going over aggregation/transport/cores nodes. 255 The signaling of such e2e LSPs is enabled by using the 256 stitching/hierarchy mechanisms that exist, using [LU-BGP]/LDP/RSVP. 258 The rules of section 5 provide a general-purpose way for the use of 259 ELs across e2e LSPs by defining: 261 - the rules of ELC propagation at stitching points; 263 - the data-plane guidelines for the stitching point LSR; and 265 - the data-plane guidelines for LSP hierarchies for inserting 266 (ELI+EL) at ingress LER of an LSP in an LSP hierarchy. 268 4.2 EL for LSP stitching 270 A stitched e2e LSP might be stitched from greater than 2 segment LSPs 271 (along the length of the e2e LSP), with 2 LSPs forming the stitch at 272 each stitching point. 274 An LSP segment is considered to be intrinsically EL capable when it 275 supports the attributes summarized in section 3. 277 Some of the segment LSPs in the e2e LSP may intrinsically support EL 278 and some may not. So, the e2e LSP may not intrinsically support EL 279 from end to end. However, to obtain the benefits of EL for stitched 280 LSPs, it is important that an EL should be present on the data 281 packets traversing as many segments of the e2e LSP as is possible 282 within data plane abilities of the routers on the way. 284 In using EL with LSP stitching, the aims are BOTH of the following: 285 a. Get EL benefits wherever possible: on all segments where 286 possible. Just because a given segment does not support EL 287 is not a reason to deny EL benefits to other segments of the 288 e2e LSP. 290 b. Not run into data-plane problems where an 291 intermediate-segment whose ingress LER can not look deeper 292 to remove EL when the subsequent segment does not support EL. 294 - Independent setup of LSP segments: 296 LSP stitching typically relies on LSP segments that have been 297 independently setup. In an e2e LSP (made of stitched segments), it is 298 unlikely that all of the stitching points (i.e., segment LSP end 299 points) as well as the ultimate ingress and ultimate egress support 300 EL as defined in section 3. 302 However, there would be individual LSP segments that would completely 303 satisfy the requirements of section 2 (i.e. are intrinsically EL 304 capable). This document describes how EL may be used for (portions 305 of) the e2e LSP while still working within the framework for [EL- 306 RFC]. 308 S---A---B---C---D 310 In the above topology, for an e2e LSP from S to D, the segments AB 311 and CD could be intrinsically EL capable while the segments SA, & BC 312 may not be. For data traffic going over the LSP from S to D, using EL 313 on the segments AB and CD would be beneficial for load-balancing over 314 LAGs/ECMP. 316 - Dealing with different protocols being used to setup the segments 317 of the e2e LSP. 319 4.2.1 Spectrum of EL usage behaviors required to be supported for 320 stitched LSPs 322 To cater for an incremental deployment of intrinsically-ELC routers 323 in a network, the multiple different modes for EL use with LSP 324 stitching need to be to be supported. 326 The spectrum of supported behaviors are listed below by referencing 327 the following diagram. 329 S1 S2 S3 S4 331 A-----------B-----------C-----------D-----------E 333 LSP segments S1, S2, S3, S4 are between LERs A/B/C/D/E. There may or 334 may not be other routers between the per-segment ingress<->egress 335 LERs. 337 Transport LSP signaling protocol: could be any: LDP/RSVP/([LU-BGP] 338 tunneled over RSVP/LDP). 340 4.2.1.1 Entropy label for per-segment LSP 342 Each of the segments will have their independent EL capability based 343 on BOTH the: 345 - Per-segment ingress having the ability to insert the EL. 347 - Per-segment egress (or PH router) having the ability to strip 348 the EL. 350 This is very similar to [EL-RFC] with the additional data-plane rule 351 of section 5.2.2.1 "A. Rationalizing EL for the outgoing LSP 352 segment:". 354 Reasoning for why per-segment EL may be attractive for certain use 355 scenarios: 357 Opportunity to get benefits on those segments where EL benefits are 358 available. Even though the e2e LSP may not support ELC, this allows 359 the EL benefits on those segments that are EL-capable. 361 4.2.1.2 Entropy label for notional-segment-LSP(s) 363 In the case of stitched LSPs, it is useful to: 365 - Insert EL at first per-segment ingress LER (per-segment ingress 366 LER closest to the e2e ingress LER) that has the ability to 367 insert EL. 368 - Carry the EL on the data packets as far along the stitched LSP as 369 the last per-segment egress LER that ability to strip the EL 370 on a series of contiguous EL-supporting segments. 372 The above is enabled by the rules of section "5.2.1.1 Signaling ELC 373 at stitching points (Translation rules)". 375 The benefit of using EL with notional-segment LSPs: 377 An operator might be able to use EL for the MPLS traffic on its path 378 to a stitching point even though the stitching-point router (or its 379 PHR) itself may not have the data-plane capabilities required as in 380 [EL-RFC]. 382 Additionally, even if the stitching-point (or its PHR) do have the 383 data-plane capabilities of [EL-RFC], it is just more efficient to 384 forward the data packets without having to strip the EL and then 385 reinsert the EL when the downstream segment is also intrinsically 386 ELC. 388 4.2.1.3 Entropy label for e2e LSP 390 This correspond to having the notional-LSP and the e2e LSP being the 391 same. 393 This is covered by the rules of section 5.2.1.1 "Signaling ELC at 394 stitching points (Translation rules):" with the additional 395 requirement that the data-plane be exactly the same as [EL-RFC], 396 i.e. 397 the (ELI+EL) insertion is done by a label PUSHing router, 398 the (ELI+EL) POP is done by the PHR/egress for the e2e LSP. 400 4.3 EL for LSP hierarchy 402 For the purpose of highlighting the problem to be addressed and the 403 resultant requirements to be met, the following diagram is presented 404 as an example. 406 Let there be an LSP hierarchy with the ingress for the different 407 levels of LSP hierarchy being at different routers, such that each 408 LSP in the hierarchy is intrinsically EL capable. The individual LSPs 409 in the hierarchy could be a single-segment LSP or a stitched e2e LSP. 411 S1 D1 412 \ --------- / 413 A===B===C===D===E 414 / --------- \ 415 S2 D2 417 In the above topology, let there be the following LSPs: 419 L1: B->D 420 L2: A->E, tunneled through LSP L1 421 L3: S1->D1, tunneled through LSP L2 422 L4: S2->D2, tunneled through LSP L2 424 All of the LSPs above are assumed to be intrinsically EL capable. 426 4.3.1 Possibility of unnecessary reduction of max-payload of the LSP: 428 Even though the aim of using EL is to get better load-balancing 429 support, in some cases the insertion of (ELI+EL) may unnecessarily 430 reduce the effective payload of an LSP. 432 In above diagram, as per [EL-RFC] for a data packet on LSP L3, the 433 insertion of (ELI+EL) for each of the 3 LSPs: L1, L2 and L3 is not 434 explicitly prohibited. As a result it is possible that the packet on 435 LSP L3, might end up with 3 (ELI+EL)s (one for each LSP level in the 436 hierarchy) thus reducing the effective payload of the LSP L3. 437 Likewise for L4. The presence of the (ELI+EL) for the outer LSPs L1 438 and L2 is not strictly useful for load-balancing the data traffic on 439 the LSPs L3 and L4. 441 The solution for this issue is presented in section 5.3.2: it relies 442 on inserting the (ELI+EL) in the context of only 1 LSP in a 443 hierarchy. 445 This issues results in the following requirement for EL usage in the 446 presence of LSP hierarchies: 447 - Desirability of having a single (ELI+EL) on data packets over an 448 LSP hierarchy: The LSP for which the (ELI+EL) is inserted, is 449 preferably the innermost intrinsically EL-capable LSP, as the 450 notion of a user-flow is more specifically indicated by fields 451 deeper inside the packet headers. Having an EL be present deeper 452 in the packet provides load-balancing benefits of EL for the 453 traversal of the packet across a longer stretch of the network. 455 If there is to be only 1 (ELI+EL) in the label stack, it imposes an 456 additional data plane requirement on the ingress LER as described in 457 section 5.3.2. 459 4.3.2 Possibility of EL being non-usable for load-balancing: Even though 460 the aim of using EL is to get better load-balancing, in some cases 461 the insertion of (ELI+EL) may actually offer no load-balancing 462 benefits at all. Whether the presence of an EL offers load-balancing 463 benefits on a given transit router, depends on: 465 - whether the transit router has a LAG or an ECMP as an outgoing 466 interface for the LSP, AND 467 - whether the forwarding ASICs of the transit routers have the 468 ability to include the EL (appearing at a specific position in 469 the label stack) in the hash computation, either by: 470 + looking up the ELI and then picking the EL, or 471 + computing the hash on the maximum number of labels that it can 472 pick from the label-stack for hash-computation which 473 happens to also include the EL. 475 When the EL on a packet is outside the portion-of-the-label-stack 476 that the ASIC of a transit router can use for hash computation, the 477 forwarding hardware may include only the top few labels or the bottom 478 few labels in the hash computation. This may prevent the inclusion of 479 EL for hash-computation. 481 In the above diagram, for a data packet going over LSP L3 let the 482 issue of section 4.3.1 have been resolved by the router S1 inserting 483 the (ELI+EL) underneath the label for LSP L3 and none of the other 484 routers inserting the (ELI+EL). When this data packet arrives at 485 router C, its label stack looks thus: 487 Label-LSP1 | Label-LSP2 | Label-LSP3 | ELI | EL 488 Top-label -> Bottom label 490 Let's say that the router C is able to include only the top 4 labels 491 in a label stack for the hash-computation due to the ability of its 492 forwarding ASICs. 494 So, the router C is not able to get the benefit of the presence of 495 the EL in the data packet. If the only ECMP/LAG in this network is 496 the link between C&D, then the presence of the EL serves no purpose 497 for the above network example and it ends up reducing the payload 498 capacity of the LSPs L3 and L4 by 8 bytes. 500 This example could be further generalized in the case of seamless 501 MPLS, where there may be deeper LSP hierarchies. 503 A transit router that has the ability to hash on an EL (based on its 504 depth in the label stack) does not have multiple paths; while another 505 router that has multiple paths and the ability hash on the EL 506 (appearing at a specific depth in the label stack) is unable to do so 507 as the EL appears outside the depth of the label stack that may be 508 included in the hash. In neither of the foregoing cases is the 509 presence of an EL helpful. 511 This translates into a requirement for EL: Flexibility in choice of 512 LSP tunnel for which EL is inserted: 514 There is a need to have a way by which to include an EL underneath a 515 specific label in a label-hierarchy based on it serving the most 516 useful purpose (i.e. taking into consideration location of multiple- 517 forwarding-paths and stack-depth-concerns). 519 [EL-RFC] has no way of influencing the insertion of (ELI+EL) at a 520 certain LSP level in the stack. Thus, there is a need for a mechanism 521 by which one of the many intrinsically-EL-capable LSPs in an LSP 522 hierarchy could be picked for inserting the (ELI+EL). 524 5. EL for LSP stitching/hierarchy 525 5.1 Additional EL abstractions: specific to LSP stitching/hierarchy 527 Given the previous sections, following additional abstractions need 528 to be defined to make EL more useful for LSP stitching and hierarchy. 530 5.2 New abstractions: EL applicability for LSP stitching 531 5.2.1 Signaling 533 New abstractions need to be defined to handle the differences in the 534 use of ELs for stitched-LSPs as compared to their use for single- 535 segment LSPs. 537 The differences are: 539 - Notion of ingress for EL insertion: 540 (ELI+EL) insertion might not necessarily be done by a 541 label-PUSHing router. A stitching point where the label is being 542 swapped might do the (ELI+EL) insertion, and serves as a 543 "notional ingress". 545 - Notion of egress for EL: 546 "Notional-egress" might not be the segment egress for the segment 547 of the notional-ingress. 548 Even though certain stitching-points (segment LERs) might not 549 support POPing (ELI+EL), it may be acceptable to let the (ELI+EL) 550 continue to be on the packet since the egress of a subsequent 551 segment has the capability to POP the (ELI+EL) (which may not 552 necessarily be along with POPing the transport label). A 553 "notional-ingress and notional-egress" pair might actually be the 554 segment-ingress and segment-egress for different LSP segments that 555 are part of the same e2e LSP. 557 The portion of the stitched e2e LSP, between a notional-ingress and a 558 notional-egress is referred to as the "notional-LSP-segment" in this 559 document. 561 As a packet traverses an e2e LSP, it may have an (ELI+EL) imposed on 562 it and then removed at different routers. 564 It is desirable for there to not be more than one instance of an 565 (ELI+EL) to appear on a packet at any given time. However, the 566 insertion followed by removal of an (ELI+EL) may happen more than 567 once as the packet traverses the e2e LSP. Each router doing the 568 (ELI+EL) insertion is the notional-ingress and each router doing the 569 (ELI+EL) removal is the notional-egress (or notion EL-stripping-PH- 570 router). 572 Thus, there may be more than 1 "notional ingress" for EL insertion, 573 and there may be more than 1 "notional egress" for EL removal. 575 For each notional "ingress ingress", there will be a "notional 576 egress" with the "notional ingress"es and "notional egress"es 577 alternating along the path of the e2e LSP when there are more than 1 578 notional ingress and egress for an e2e LSP. 580 In the simplest case, this boils down to the case of there being just 581 one notional ingress and one notional egress; and the notional 582 ingress coincides with the e2e ingress, and the notional-egress 583 coincides with the e2e egress. That is the case that [EL-RFC] 584 addresses. 586 Separation of control/data-plane implies that certain routers 588 - Might be running software that supports signaling ELC and 589 understanding an egress' ELC. 590 - However, might not have the capability to insert (ELI+EL). 592 Such routers should not be allowed to play a spoil-sport in 593 preventing EL benefits for traffic traversing over them via stitched 594 LSPs. In other words, such routers can not act as notional-ingress or 595 notional-egress. However, the presence of such per-segment 596 ingress/egress routers on the path of a notional segment-LSP should 597 not prevent the notional segment-LSP from benefiting from the use of 598 EL. 600 5.2.1.1 Signaling ELC at stitching points (Translation rules) 602 The rules for propagating ELC, at stitching points, from a downstream 603 segment LSP to an upstream segment LSP are listed in this section. 605 There is benefit in propagating ELC across stitching points is to not 606 have to re-compute the EL at different segment ingress for those 607 segments that are EL capable, including when the LSP segments have 608 been setup using different protocols. 610 Additionally, in certain cases it should be possible to get benefits 611 of (ELI+EL) on LSP segments that are not "intrinsically EL capable", 612 where the lack of "intrinsic EL capability" is due to: 613 - The per-segment ingress does not support EL insertion. 614 - The per-segment PHR/egress does not support EL POPing. 616 However, such a stitching point might support ELC signaling. 618 At a stitching point, when 2 LSP segments: L1 (incoming LSP) and L2 619 (the outgoing LSP) are being stitched, the following rules should be 620 followed by stitching point in signaling its ELC. 622 A. Segment-egress: 624 1. A segment-egress signals ELC for an LSP-segment L1 when: 625 a. The segment-egress is intrinsically ELC, or 626 b. When it is not intrinsically-ELC, however segment-egress for 627 LSP-segment L2 (downstream of L1)- for which this 628 stitching-point is segment-ingress - is signaling ELC. 629 [This handles the case: Support the signaling even though it 630 may not support the data-plane behavior.] 632 2. A segment-egress MUST NOT signal ELC if BOTH of the following 633 are true: 634 a. It is also segment-ingress for another LSP-segment whose 635 segment-egress is not signaling ELC. 636 b. This router does not have the ability to remove an (ELI+EL) 637 inserted by the segment-ingress for the LSP-segment for 638 which this router is the segment-egress. 640 B. Segment-ingress: 642 The following is relevant only for RSVP as defined in [EL-RFC]. 643 When this router acting as segment-egress for an LSP L1 (that is 644 stitched to downstream LSP L2) is signaling ELC for L1, then this 645 router must signal ELC in its Path messages using the mechanism 646 defined in [EL-RFC]. 648 This is relevant only in the context of bidirectional LSPs. 650 5.2.2 Data plane aspects 651 5.2.2.1 Stitching: Differing EL dispositions 653 At a stitching point, when 2 LSP segments: L1 (incoming LSP) and L2 654 (the outgoing LSP) are being stitched, the following rules should be 655 followed by the stitching point in its data-plane behavior. 657 A. Rationalizing EL for the outgoing LSP segment: 658 When the LSP segments L1 and L2 differ in their ELC, the stitching 659 point router needs to take the following data-plane actions 660 depending on its role for the e2e LSP: 662 a. Notional egress behavior: 663 When L1 intrinsically supports ELC and L2 does not, then 664 the stitching-point router must remove the (ELI+EL), if 665 present under top label, from the received data packets 666 before effectively SWAPing the top label. In other words, 667 in the presence of the ELI, the operations performed 668 should be: 670 POP(IncomingLabel), POP(ELI+EL), PUSH(OutgoingLabel) 671 or alternately: 672 POP, POP, SWAP(OutgoingLabel) 674 Translation rule "A 2" of section 5.2.1.1 would have ensured that 675 the above is doable at the stitching point. 677 b. Notional ingress behavior: 678 When L1 does not intrinsically support ELC and L2 does, then the 679 stitching point router must POP the incoming label, insert 680 (ELI+EL) before PUSHing the label for the LSP segment L2. 682 The label operations performed would be: 683 POP(IncomingLabel), PUSH(EL), PUSH(ELI), PUSH(OutgoingLabel), 684 or 685 SWAP(EL), PUSH(ELI), PUSH(OutgoingLabel) 687 c. Implicit notional ingress behavior: 688 When L1 is intrinsically ELC and so is L2, the arriving data 689 traffic should already have (ELI+EL) on it. 691 However, it is possible that due to local configuration on the 692 notional-ingress, (ELI+EL) is not being inserted. In that 693 case, traffic arriving on L1 will not have (ELI+EL) on it. 695 In that case, this stitching-point is the "implicit notional 696 ingress" and it should insert (ELI+EL) just as if it were a 697 "notional ingress". 699 B. Preventing multiple (ELI+EL) pairs underneath a given forwarding 700 label in the stack: 702 A segment-ingress that is intrinsically-EL-capable should have 703 the ability to inspect received data packets to check whether an 704 (ELI+EL) already exists on the data packet underneath the top 705 label. 707 Not causing multiple ELs on a data packet: 708 When both the LSP segments L1 and L2 support ELC, the 709 stitching point router SHOULD insert an (ELI+EL) only if the 710 incoming packet does not contain an (ELI+EL) underneath the 711 top label. In that case, the label operations are as below: 712 POP(IncomingLabel), PUSH(ELI+EL), PUSH(OutgoingLabel) 714 If the incoming packet already contains an (ELI+EL) underneath the 715 top label, an additional (ELI+EL) MUST NOT be inserted on the 716 packet underneath the top label that is being effectively SWAPed. 718 This prevents a segment ingress from inserting an (ELI+EL) when 719 the notional ingress has already inserted an (ELI+EL). 721 C. Rationalizing EL insertion (at stitching-point) for LSP hierarchy: 723 A stitching point router that is intrinsically-EL-capable should 724 have the ability to inspect received data packets to check whether 725 an (ELI+EL) already exists, underneath any label in the 726 label-stack. 728 If the router has such a ability, then this router MUST NOT insert 729 an (ELI+EL) as in "A a" above. 731 This helps to prevent multiple (ELI+EL)s on the packet inserted 732 (at a stitching point) in the context of different transport 733 labels in a label hierarchy. 735 D. Notional ingress role change at a router: 737 This role can change due to local configuration on the router or 738 due to segment egress starting/stopping to signal ELC possibly due 739 to a configuration change at the segment egress or due to a 740 configuration change at this router. 741 When this router becomes a notional ingress, it reacts to the 742 change as in "A b" above. 744 When this router stops being a notional ingress, this router 745 stops inserting the (ELI+EL) underneath the top label that this 746 router is 747 SWAPing(if this router is stitching point), or 748 PUSHING (if this router is e2e ingress). 750 E. Notional egress role change at a router: 752 This role can change due to local configuration on the router or 753 due the egress of a downstream stitched LSP segment starting to 754 signal ELC. 756 When this router becomes a notional egress, it reacts to the 757 change as in "A a" above. 759 When this router stops being a notional egress, this router stops 760 performing the label operation described in "A a" above. Instead 761 this router now starts to simply SWAP the top label. 763 5.3 New abstractions: EL applicability for LSP hierarchy 764 5.3.1 Management plane: 766 Moving the (ELI+EL) underneath a different LSP's transport label: 767 There are 2 ways to handle the issue of section 4.3.2: 768 - Configuration at the ingress LER: a configuration option should 769 exist by which an operator can disable the insertion of (ELI+EL) 770 on a per-LSP basis. The specific level in the LSP hierarchy for 771 which to enable this configuration is based on operator knowledge 772 based on: 773 * Knowledge of transit routers that need EL benefits : those 774 routers that have a multi-path (LAG or LSP ECMP) as egress 775 interface. 776 * The label hashing abilities of such routers: information 777 about the specific number of labels in the label-stack that 778 can be used in the hash computation; and any constraints 779 about the position of the labels that can be used for 780 computation when the label stack is larger than a certain 781 ASIC-specific threshold. 783 - Configuration-based rewrite of the label stack at the ingress LER 784 of an intrinsically-EL-capable LSP: 786 An operator will know the forwarding characteristics (with 787 regards to the number of labels that can be included in the hash 788 computation) of the transit routers across the path of the e2e 789 LSP that is part of an LSP hierarchy. 791 By making such a configuration, the operator can ensure that the 792 EL will appear in the label stack such that all transit routers 793 shall be able to include the as part of the hash computation. 795 The configuration would cause the label stack of the outgoing 796 packet to have its extant (ELI+EL) removed, and an (ELI+EL) 797 inserted just underneath the label of the LSP for which this 798 ingress LER is setup to insert (ELI+EL). 800 5.3.2 Data plane aspects 802 Preventing insertion of multiple (ELI+EL)s: 803 At an ingress LER, the router SHOULD not insert an (ELI+EL) for an 804 LSP if the packet already contains an ELI. 806 This ensures that for a data packet on a hierarchy of LSPs, there 807 will be only 1 instance of an (ELI+EL). This helps to prevent the 808 issue of section 4.3.1. 810 This also ensures that when multiple LSPs in an LSP hierarchy are 811 intrinsically-EL-capable, the (ELI+EL) will be inserted just 812 underneath the transport label of the innermost LSP in the hierarchy. 813 However, based on section 5.3.1 there is a way by which to modify the 814 level in the LSP hierarchy for which an (ELI+EL) is inserted. 816 A more specific case of this is already covered in section "5.2.2.1 817 C. Rationalizing EL insertion (at stitching-point) for LSP 818 hierarchy:". 820 6. Use-cases 822 In this document, the definition of LSP-stitching is broadened to 823 refer to not just [STITCHING] but also to those cases where a label 824 advertised by one label distribution protocol being: 825 - removed at one router (by PH POP) followed by a label PUSH for a 826 label distributed by another protocol at the router downstream 827 of the PH router of the previous protocol's LSP. Such a router 828 which is PUSHing a label for a subsequent protocol is also 829 referred to as a stitching-point router in this document. 831 - SWAPed at a router for a label distributed by another protocol 832 is also referred to as a stitching-point in this document. 834 The list of use-cases of this draft stems from the following: 835 A. Not having to insert/remove (ELI+EL) multiple times along an e2e 836 labeled path, due to the EL capability not getting signaled e2e. In 837 other words, not having to remove (ELI+EL) at a stitching point only 838 to re-insert it. 840 The lack of e2e EL capability signaling could be either due to 841 administrative controls (as in [STITCHING]); or due to a label 842 advertised by one label distribution protocol being removed at one 843 router (which also causes the removal of (ELI+EL)) and a label 844 distributed by a subsequent router being PUSHed along with (ELI+EL) 845 at that router. 847 B. On an e2e labeled transport-LSP path, it may be possible to get 848 the load-balancing benefits of EL on (segment of) the e2e LSP even 849 though not every stitching point router (as defined above) may 850 intrinsically support EL for the LSP terminating at it. 852 6.1 Carrier of carrier L3VPN 853 ----- 854 ======= / A1 855 ---- | | ____CE1 | 856 / \ -------- / \ ------ / | | 857 | A2 CE2- / AS2 \ | | / PE1 \ / 858 \ / \ / \_ / \_ _/ Carrier| ---- 859 ---- -PE2 | | Carrier's | | cust. | 860 | | | carrier | | | 861 | ASBR1|--ASBR2 ASBR3--|ASBR4 | ---- 862 | Carrier | | | | | / \ 863 | cust. / | AS1 | | AS2 | CE5 A5 | 864 \ / \ | | PE4__/\ / 865 ---PE3-------/ | | \ / ----- 866 / | \ / -------- 867 ---- / | ---- | | 868 / \ | / \ ============ 869 | A3 CE3 -CE4 A4| 870 \ / \ / 871 ---- ---- 872 A = Customer site n 873 CE = Customer Edge Device 874 PE = Provider Edge Router 876 In the above figure, the "carrier's carrier" is providing L3VPN 877 service to a carrier customer (carrier cust.) is itself an L3VPN 878 provider. 879 Let the sites A be the sites of the same L3VPN. 880 In order to provide L3VPN service to the sites A, there is 881 effectively an e2e LSP between each pair of PEs. For PEs in the same 882 carrier customer site, the e2e LSP is an RSVP or LDP LSP. eg. Between 883 PE2 and PE3. 884 For PEs that are across the carrier-customer's core, there is an e2e 885 LSP created by advertising a BGP label for the remote PE's loopback 886 address. The BGP label advertised from ASBR2 to ASBR1 rides-on top of 887 the RSVP or LDP label in the carrier's-carrier core. 889 eg. For having an e2e LSP from PE1 to PE2, a BGP label is advertised 890 for PE1's loopback into the carrier customer's site on the left. This 891 label could be dealt with by ASBR1 in two ways: 892 a. Advertising it into LDP in the carrier customer's site (on 893 the left), or 894 b. By advertising it over an iBGP session to PE2. 896 In the former case (LDP advertising a FEC for PE1), this document 897 makes possible for ASBR1 to not have to remove the EL (inserted by 898 PE2) and let it be removed by a either a stitching point (ASBR2 or 899 ASBR3 or ASBR4) or the egress PE1. This is facilitated by the 900 translation rules of section 5.2.1.1. The same also facilitates 901 traffic with EL to be carried over stitching points such that the EL 902 is eventually removed by the last-EL-capable stitching point or the 903 EL capable e2e egress. 905 Each carrier (carrier's carrier; and carrier-customer) will have LAGs 906 and LDP ECMP paths in its network. 908 6.2 Inter-AS L3VPN: Option C 910 Option C is conceptually similar to CoC L3VPN from a point of view of 911 setting up the e2e LSP. Therefore, similar EL use-cases also exist 912 for Option C. 914 This applies for both L3VPN and also BGP-VPLS. 916 7. Security considerations 918 Security considerations as listed in section 9 of [EL-RFC] apply. 920 8. Acknowledgments 922 Many thanks to Adrian Farrel for his inputs on the stitching 923 scenarios, and suggesting editorial improvements. 925 Thanks to the EL team (Sudharsana Venkataraman, Nitin Singh, Ramji 926 Vijayaraghavan, Jie Yan, Abhishek Tripathi) for discussions on some 927 of these topics. 929 9. IANA considerations 931 None. 933 9 References 935 9.1 Normative References 937 [EL-RFC] Kompella, K., Drake, J., Amante, S., Henderickx, W., 938 L. Yong, "The Use of Entropy Labels in MPLS Forwarding", 939 RFC-6790, November 2012. 941 [GMPLS-HIER] Kompella, K., Y. Rekhter, "Label Switched Paths (LSP) 942 Hierarchy with Generalized Multi-Protocol Label 943 Switching (GMPLS)", RFC-4206, October 2005. 945 [MPLS-ARCH] Rosen, E., Viswanathan, A., R. Callon, "Multiprotocol 946 Label Switching Architecture", RFC-3031, January 2001. 948 [S-MPLS] Leymann, N., Decraene, B., Filsfils, C., 949 Konstantynowicz, M., Steinberg, D., "Seamless MPLS 950 Architecture", draft-leymann-mpls-seamless-mpls, 951 October 2012. 953 [STITCHING] Ayyangar, A., Kompella, K., Vasseur, JP., A. Farrel, 954 "Label Switched Path Stitching with Generalized 955 Multiprotocol Label Switching Traffic Engineering 956 (GMPLS TE)", RFC 5150, February 2008. 958 9.2 Informative References 960 [ISSUE-DEEP] K. Kompella, "Deep Label Stacks", 961 http://tools.ietf.org/agenda/84/slides/slides-84-mpls- 962 15.pdf, August 2012 964 [LU-BGP] Rekhter, Y., E. Rosen, "Carrying Label Information in 965 BGP-4", RFC-3107, May 2001. 967 Authors' Addresses 969 Ravi Singh 970 Juniper Networks 971 1194 N. Mathilda Ave. 972 Sunnyvale, CA 94089 973 US 975 EMail: ravis@juniper.net 977 Yimin Shen 978 Juniper Networks 979 10 Technology Park Drive 980 Westford, MA 01886 981 US 983 EMail: yshen@juniper.net 985 John Drake 986 Juniper Networks 987 1194 N. Mathilda Ave. 988 Sunnyvale, CA 94089 989 US 991 EMail: jdrake@juniper.net