idnits 2.17.1 draft-ietf-mpls-spring-entropy-label-04.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 8, 2016) is 2842 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-15) exists of draft-ietf-spring-segment-routing-09 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 S. Kini, Ed. 3 Internet-Draft 4 Intended status: Informational K. Kompella 5 Expires: January 9, 2017 Juniper 6 S. Sivabalan 7 Cisco 8 S. Litkowski 9 Orange 10 R. Shakir 12 J. Tantsura 13 July 8, 2016 15 Entropy labels for source routed tunnels with label stacks 16 draft-ietf-mpls-spring-entropy-label-04 18 Abstract 20 Source routed tunnels with label stacking is a technique that can be 21 leveraged to provide a method to steer a packet through a controlled 22 set of segments. This can be applied to the Multi Protocol Label 23 Switching (MPLS) data plane. Entropy label (EL) is a technique used 24 in MPLS to improve load balancing. This document examines and 25 describes how ELs are to be applied to source routed tunnels with 26 label stacks. 28 Status of This Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at http://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on January 9, 2017. 45 Copyright Notice 47 Copyright (c) 2016 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (http://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 63 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 64 2. Abbreviations and Terminology . . . . . . . . . . . . . . . . 3 65 3. Use-case requiring multipath load balancing . . . . . . . . . 4 66 4. Recommended EL solution for SPRING . . . . . . . . . . . . . 5 67 5. Options considered . . . . . . . . . . . . . . . . . . . . . 6 68 5.1. Single EL at the bottom of the stack of tunnels . . . . . 6 69 5.2. An EL per tunnel in the stack . . . . . . . . . . . . . . 7 70 5.3. A re-usable EL for a stack of tunnels . . . . . . . . . . 8 71 5.3.1. EL at top of stack . . . . . . . . . . . . . . . . . 8 72 5.4. ELs at readable label stack depths . . . . . . . . . . . 8 73 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 74 7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 9 75 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 76 9. Security Considerations . . . . . . . . . . . . . . . . . . . 10 77 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 78 10.1. Normative References . . . . . . . . . . . . . . . . . . 10 79 10.2. Informative References . . . . . . . . . . . . . . . . . 10 80 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 82 1. Introduction 84 The source routed tunnels with label stacking paradigm is leveraged 85 by techniques such as Segment Routing (SR) 86 [I-D.ietf-spring-segment-routing] to steer a packet through a set of 87 segments. This can be directly applied to the MPLS data plane, but 88 it has implications on the label stack depth. 90 Clarifying statements on label stack depth have been provided in 91 [RFC7325] but the RFC does not address the case of source routed 92 stacked MPLS tunnels as described in 94 [I-D.ietf-spring-segment-routing] where deeper label stacks are more 95 prevalent. 97 Entropy label (EL) [RFC6790] is a technique used in the MPLS data 98 plane to provide entropy for load balancing. When using LSP 99 hierarchies there are implications on how [RFC6790] should be 100 applied. The current document addresses the case where the hierarchy 101 is created at a single LSR as required by source routed tunnels with 102 label stacks. 104 A use-case requiring load balancing with source routed tunnels with 105 label stacks is given in Section 3. A recommended solution is 106 described in Section 4 keeping in consideration the limitations of 107 implementations when applying [RFC6790] to deeper label stacks. 108 Options that were considered to arrive at the recommended solution 109 are documented for historical purposes in Section 5. 111 1.1. Requirements Language 113 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 114 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 115 document are to be interpreted as described in RFC 2119 [RFC2119]. 117 Although this document is not a protocol specification, the use of 118 this language clarifies the instructions to protocol designers 119 producing solutions that satisfy the requirements set out in this 120 document. 122 2. Abbreviations and Terminology 124 EL - Entropy Label 126 ELI - Entropy Label Identifier 128 ELC - Entropy Label Capability 130 SR - Segment Routing 132 ECMP - Equal Cost Multi Paths 134 MPLS - Multiprotocol Label Switching 136 SID - Segment Identifier 138 RLD - Readable Label Depth 140 OAM - Operation, Administration and Maintenance 142 3. Use-case requiring multipath load balancing 144 +------+ 145 | | 146 +-------| P3 |-----+ 147 | +-----| |---+ | 148 L3| |L4 +------+ L1| |L2 +----+ 149 | | | | +--| P4 |--+ 150 +-----+ +-----+ +-----+ | +----+ | +-----+ 151 | S |-----| P1 |------------| P2 |--+ +--| D | 152 | | | | | |--+ +--| | 153 +-----+ +-----+ +-----+ | +----+ | +-----+ 154 +--| P5 |--+ 155 +----+ 157 S=Source LSR, D=Destination LSR, P1,P2,P3,P4,P5=Transit LSRs, 158 L1,L2,L3,L4=Links 160 Figure 1: Traffic engineering use-case 162 Traffic-engineering (TE) is one of the applications of MPLS and is 163 also a requirement for source routed tunnels with label stacks. 164 Consider the topology shown in Figure 1. Lets say the LSR P1 has a 165 limitation that it can only look four labels deep in the stack to do 166 multipath decisions. All other transit LSRs in the figure can read 167 deep label stacks and the LSR S can insert as many pairs as 168 needed. The LSR S requires data to be sent to LSR D along a traffic- 169 engineered path that goes over the link L1. Good load balancing is 170 also required across equal cost paths (including parallel links). To 171 engineer traffic along a path that takes link L1, the label stack 172 that LSR S creates consists of a label to the node SID of LSR P3, 173 stacked over the label for the adjacency SID of link L1 and that in 174 turn is stacked over the label to the node SID of LSR D. For 175 simplicity lets assume that all LSRs use the same label space for 176 source routed label stacks. Let L_N-Px denote the label to be used 177 to reach the node SID of LSR Px. Let L_A-Ln denote the label used 178 for the adjacency SID for link Ln. The LSR S must use the label 179 stack for traffic-engineering. However to 180 achieve good load balancing over the equal cost paths P2-P4-D, 181 P2-P5-D and the parallel links L3, L4, a mechanism such as Entropy 182 labels [RFC6790] should be adapted for source routed label stacks. 183 Multiple ways to apply entropy labels were considered and are 184 documented in Section 5 along with their tradeoffs. A recommended 185 solution is described in Section 4. 187 4. Recommended EL solution for SPRING 189 The solution described in this section follows [RFC6790]. 191 An LSR may have a limitation on the depth of the label stack that it 192 can read and process in order to do multipath load balancing. This 193 limitation expressed in terms of the number of label stack entries 194 that the LSR can read is defined as the Readable Label Depth (RLD) 195 capability of that LSR. If an EL does not occur within the RLD of an 196 LSR in the label stack of the MPLS packet that it receives, then it 197 would lead to poor load balancing at that LSR. Hence an ELI, EL pair 198 MUST be within the RLD of the LSR in order for the LSR to use the EL 199 during load balancing. The RLD of an LSR is a characteristic of the 200 forwarding plane of that LSR's implementation and determining it is 201 outside the scope of this document. 203 In order for the EL to occur within the RLD of LSRs along the path 204 corresponding to a label stack, multiple pairs MAY be 205 inserted in the label stack as long as the tunnel's label below which 206 they are inserted are advertised with entropy label capability 207 enabled. The ELs among multiple pairs inserted in the 208 stack may be same or different. The LSR that inserts pairs 209 MAY have limitations on the number of such pairs that it can insert 210 and also the depth at which it can insert them. If due to any 211 limitation, the inserted ELs are at positions such that an LSR along 212 the path receives an MPLS packet without an EL in the label stack 213 within that LSR's RLD, then the load balancing performed by that LSR 214 would be poor. Special attention should be paid when a forwarding 215 adjacency LSP (FA-LSP) [RFC4206] is used as a link along the path of 216 a source routed LSP's label stack, since the labels of the FA-LSP 217 would additionally count towards the depth of the label stack when 218 calculating the appropriate positions to insert the ELs. The 219 recommendations for inserting pairs are: 221 o An LSR that is limited in the number of pairs that it 222 can insert SHOULD insert such pairs deeper in the stack. 224 o An LSR SHOULD try to insert pairs at positions so that 225 for the maximum number of transit LSRs, the EL occurs within the 226 RLD of the incoming packet to that LSR. 228 o An LSR SHOULD try to insert the minimum number of such pairs while 229 trying to satisfy the above criteria. 231 A sample algorithm that follows the above recommendations to insert 232 ELs is shown below. For node SIDs, the minimum value of RLDs of LSRs 233 on that node segment should be used. 235 Initialize the current EL insertion point to the 236 bottommost label in the stack that is EL-capable 237 while (local-node can push more pairs OR 238 insertion point is not above label stack) { 239 insert an pair below current insertion point 240 move new insertion point up from current insertion point until 241 ((last inserted EL is below the RLD) AND (RLD > 2) 242 AND 243 (new insertion point is EL-capable)) 244 set current insertion point to new insertion point 245 } 247 Figure 2: Algorithm to insert pairs in a label stack 249 When this algorithm is applied to the example described in Section 3 250 it will result in ELs being inserted in two positions, one below the 251 label L_N-D and another below L_N-P3. Thus the resulting label stack 252 would be 254 The RLD can be advertised via protocols and those extensions are 255 described in separate documents [I-D.xu-isis-mpls-elc] and 256 [I-D.xu-ospf-mpls-elc]. 258 It should be noted that the above algorithm is a sample and other 259 algorithms that optimize for other criteria and provide additional 260 tuning parameters to give operators the control of the optimization 261 criteria may be developed. 263 The recommendations above are not expected to bring any additional 264 OAM considerations beyond those described in section 6 of [RFC6790]. 265 However, the OAM requirements and solutions for source routed tunnels 266 formed by label stacking are still under discussion and future 267 revisions of this document will address those if needed. 269 5. Options considered 271 Different options that were considered to arrive at the recommended 272 solution are documented in this section. 274 5.1. Single EL at the bottom of the stack of tunnels 276 In this option a single EL is used for the entire label stack. The 277 source LSR S encodes the entropy label (EL) at the bottom of the 278 label stack. In the example described in Section 3, it will result 279 in the label stack at LSR S to look like . Note that the notation in [RFC6790] 281 is used to describe the label stack. An issue with this approach is 282 that as the label stack grows due an increase in the number of SIDs, 283 the EL goes correspondingly deeper in the label stack. Hence transit 284 LSRs have to access a larger number of bytes in the packet header 285 when making forwarding decisions. In the example described in 286 Section 3, the LSR P1 would poorly load-balance traffic on the 287 parallel links L3, L4 since the EL is below the RLD of the packet 288 received by P1. A load balanced network design using this approach 289 must ensure that all intermediate LSRs have the capability to 290 traverse the maximum label stack depth as required for that 291 application that uses source routed stacking. 293 In the case where the hardware is capable of pushing a single pair at any depth, this option is the same as the recommended 295 solution in Section 4. 297 This option was rejected since there exist a number of hardware 298 implementations which have a low maximum readable label depth. 299 Choosing this option can lead to a loss of load-balancing using EL in 300 a significant part of the network but that is a critical requirement 301 in a service provider network. 303 5.2. An EL per tunnel in the stack 305 In this option each tunnel in the stack can be given its own EL. The 306 source LSR pushes an before pushing a tunnel label when 307 load balancing is required to direct traffic on that tunnel. In the 308 example described in Section 3, the source LSR S encoded label stack 309 would be where all the ELs 310 can be the same. Accessing the EL at an intermediate LSR is 311 independent of the depth of the label stack and hence independent of 312 the specific application that uses source routed tunnels with label 313 stacking in that network. A drawback is that the depth of the label 314 stack grows significantly, almost 3 times as the number of labels in 315 the label stack. The network design should ensure that source LSRs 316 should have the capability to push such a deep label stack. Also, 317 the bandwidth overhead and potential MTU issues of deep label stacks 318 should be accounted for in the network design. 320 In the case where the RLD is the minimum value (3) for all LSRs, all 321 LSRs are EL capable and the LSR that is inserting pairs has 322 no limit on how many it can insert then this option is the same as 323 the recommended solution in Section 4. 325 This option was rejected due to the existence of hardware 326 implementations that can push a limited number of labels on the label 327 stack. Choosing this option would result in a hardware requirement 328 to push two additional labels per tunnel label. Hence it would 329 restrict the number of tunnels that can be stacked in a LSP and hence 330 constrain the types of LSPs that can be created. This was considered 331 unacceptable. 333 5.3. A re-usable EL for a stack of tunnels 335 In this option an LSR that terminates a tunnel re-uses the EL of the 336 terminated tunnel for the next inner tunnel. It does this by storing 337 the EL from the outer tunnel when that tunnel is terminated and re- 338 inserting it below the next inner tunnel label during the label swap 339 operation. The LSR that stacks tunnels should insert an EL below the 340 outermost tunnel. It should not insert ELs for any inner tunnels. 341 Also, the penultimate hop LSR of a segment must not pop the ELI and 342 EL even though they are exposed as the top labels since the 343 terminating LSR of that segment would re-use the EL for the next 344 segment. 346 In Section 3 above, the source LSR S encoded label stack would be 347 . At P1 the outgoing label stack 348 would be after it has load balanced 349 to one of the links L3 or L4. At P3 the outgoing label stack would 350 be . At P2 the outgoing label stack would be and it would load balance to one of the nexthop LSRs P4 or 352 P5. Accessing the EL at an intermediate LSR (e.g. P1) is 353 independent of the depth of the label stack and hence independent of 354 the specific use-case to which the label stack is applied. 356 This option was rejected due to the significant change in label swap 357 operations that would be required for existing hardware. 359 5.3.1. EL at top of stack 361 A slight variant of the re-usable EL option is to keep the EL at the 362 top of the stack rather than below the tunnel label. In this case 363 each LSR that is not terminating a segment should continue to keep 364 the received EL at the top of the stack when forwarding the packet 365 along the segment. An LSR that terminates a segment should use the 366 EL from the terminated segment at the top of the stack when 367 forwarding onto the next segment. 369 This option was rejected due to the significant change in label swap 370 operations that would be required for existing hardware. 372 5.4. ELs at readable label stack depths 374 In this option the source LSR inserts ELs for tunnels in the label 375 stack at depths such that each LSR along the path that must load 376 balance is able to access at least one EL. Note that the source LSR 377 may have to insert multiple ELs in the label stack at different 378 depths for this to work since intermediate LSRs may have differing 379 capabilities in accessing the depth of a label stack. The label 380 stack depth access value of intermediate LSRs must be known to create 381 such a label stack. How this value is determined is outside the 382 scope of this document. This value can be advertised using a 383 protocol such as an IGP. 385 Applying this method to the example in Section 3 above, if LSR P1 386 needs to have the EL within a depth of 4, then the source LSR S 387 encoded label stack would be where all the ELs would typically have the same value. 390 In the case where the RLD has different values along the path and the 391 LSR that is inserting pairs has no limit on how many pairs 392 it can insert, and it knows the appropriate positions in the stack 393 where they should be inserted, then this option is the same as the 394 recommended solution in Section 4. 396 Note that a refinement of this solution which balances the number of 397 pushed labels against the desired entropy is the solution described 398 in Section 4. 400 6. Acknowledgements 402 The authors would like to thank John Drake, Loa Andersson, Curtis 403 Villamizar, Greg Mirsky, Markus Jork, Kamran Raza and Nobo Akiya for 404 their review comments and suggestions. 406 7. Contributors 408 Xiaohu Xu 409 Huawei 411 Email: xuxiaohu@huawei.com 413 Wim Hendrickx 414 Alcatel-Lucent 416 Email: wim.henderickx@alcatel-lucent.com 418 8. IANA Considerations 420 This memo includes no request to IANA. Note to RFC Editor: Remove 421 this section before publication. 423 9. Security Considerations 425 This document does not introduce any new security considerations 426 beyond those already listed in [RFC6790]. 428 10. References 430 10.1. Normative References 432 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 433 Requirement Levels", BCP 14, RFC 2119, 434 DOI 10.17487/RFC2119, March 1997, 435 . 437 [RFC6790] Kompella, K., Drake, J., Amante, S., Henderickx, W., and 438 L. Yong, "The Use of Entropy Labels in MPLS Forwarding", 439 RFC 6790, DOI 10.17487/RFC6790, November 2012, 440 . 442 10.2. Informative References 444 [I-D.ietf-spring-segment-routing] 445 Filsfils, C., Previdi, S., Decraene, B., Litkowski, S., 446 and R. Shakir, "Segment Routing Architecture", draft-ietf- 447 spring-segment-routing-09 (work in progress), July 2016. 449 [I-D.xu-isis-mpls-elc] 450 Xu, X., Kini, S., Sivabalan, S., Filsfils, C., and S. 451 Litkowski, "Signaling Entropy Label Capability Using IS- 452 IS", draft-xu-isis-mpls-elc-02 (work in progress), April 453 2015. 455 [I-D.xu-ospf-mpls-elc] 456 Xu, X., Kini, S., Sivabalan, S., Filsfils, C., and S. 457 Litkowski, "Signaling Entropy Label Capability Using 458 OSPF", draft-xu-ospf-mpls-elc-01 (work in progress), 459 October 2014. 461 [RFC4206] Kompella, K. and Y. Rekhter, "Label Switched Paths (LSP) 462 Hierarchy with Generalized Multi-Protocol Label Switching 463 (GMPLS) Traffic Engineering (TE)", RFC 4206, 464 DOI 10.17487/RFC4206, October 2005, 465 . 467 [RFC7325] Villamizar, C., Ed., Kompella, K., Amante, S., Malis, A., 468 and C. Pignataro, "MPLS Forwarding Compliance and 469 Performance Requirements", RFC 7325, DOI 10.17487/RFC7325, 470 August 2014, . 472 Authors' Addresses 474 Sriganesh Kini (editor) 476 Email: sriganeshkini@gmail.com 478 Kireeti Kompella 479 Juniper 481 Email: kireeti@juniper.net 483 Siva Sivabalan 484 Cisco 486 Email: msiva@cisco.com 488 Stephane Litkowski 489 Orange 491 Email: stephane.litkowski@orange.com 493 Rob Shakir 495 Email: rjs@rob.sh 497 Jeff Tantsura 499 Email: jefftant@gmail.com