idnits 2.17.1 draft-ietf-mpls-spring-entropy-label-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (April 7, 2016) is 2941 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) == Outdated reference: A later version (-15) exists of draft-ietf-spring-segment-routing-07 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: Standards Track K. Kompella 5 Expires: October 9, 2016 Juniper 6 S. Sivabalan 7 Cisco 8 S. Litkowski 9 Orange 10 R. Shakir 11 J. Tantsura 13 April 7, 2016 15 Entropy labels for source routed tunnels with label stacks 16 draft-ietf-mpls-spring-entropy-label-03 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 October 9, 2016. 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 . . . . . . . . . . . . . . . . . . . 9 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. Lets L_N-P denote the label to be used 177 to reach the node SID of LSR P. Let L_A-Ln denote the label used for 178 the adjacency SID for link Ln. The LSR S must use the label stack 179 for traffic-engineering. However to achieve 180 good load balancing over the equal cost paths P2-P4-D, P2-P5-D and 181 the parallel links L3, L4, a mechanism such as Entropy labels 182 [RFC6790] should be adapted for source routed label stacks. Multiple 183 ways to apply entropy labels were considered and are documented in 184 Section 5 along with their tradeoffs. A recommended solution is 185 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 in its ability to read and process the 192 label stack in order to do multipath load balancing. This limitation 193 expressed in terms of the number of label stack entries that the LSR 194 can read is henceforth referred to 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. The RLD of an LSR is 198 a characteristic of the forwarding plane of that LSR's implementation 199 and determining it is outside the scope of this document. 201 In order for the EL to occur within the RLD of LSRs along the path 202 corresponding to a label stack, multiple pairs MAY be 203 inserted in the label stack as long as the tunnel's label below which 204 they are inserted are advertised with entropy label capability 205 enabled. The LSR that inserts pairs MAY have limitations 206 on the number of such pairs that it can insert and also the depth at 207 which it can insert them. If due to any limitation, the inserted ELs 208 are at positions such that an LSR along the path receives an MPLS 209 packet without an EL in the label stack within that LSR's RLD, then 210 the load balancing performed by that LSR would be poor. Special 211 attention should be paid when a forwarding adjacency LSP (FA-LSP) 212 [RFC4206] is used as a link along the path of a source routed LSP's 213 label stack, since the labels of the FA-LSP would additionally count 214 towards the depth of the label stack when calculating the appropriate 215 positions to insert the ELs. The recommendations for inserting pairs are: 218 o An LSR that is limited in the number of pairs that it 219 can insert SHOULD insert such pairs deeper in the stack. 221 o An LSR SHOULD try to insert pairs at positions so that 222 for the maximum number of transit LSRs, the EL occurs within the 223 RLD of the incoming packet to that LSR. 225 o An LSR SHOULD try to insert the minimum number of such pairs while 226 trying to satisfy the above criteria. 228 A sample algorithm to insert ELs is shown below. Implementations can 229 choose any algorithm as long as it follows the above recommendations. 231 Initialize the current EL insertion point to the 232 bottommost label in the stack that is EL-capable 233 while (local-node can push more pairs OR 234 insertion point is not above label stack) { 235 insert an pair below current insertion point 236 move new insertion point up from current insertion point until 237 ((last inserted EL is below the RLD) AND (RLD > 2) 238 AND 239 (new insertion point is EL-capable)) 240 set current insertion point to new insertion point 241 } 243 Figure 2: Algorithm to insert pairs in a label stack 245 When this algorithm is applied to the example described in Section 3 246 it will result in ELs being inserted in two positions, one below the 247 label L_N-D and another below L_N-P3. Thus the resulting label stack 248 would be 250 The RLD can be advertised via protocols and those extensions are 251 described in separate documents [I-D.xu-isis-mpls-elc] and 252 [I-D.xu-ospf-mpls-elc]. 254 The recommendations above are not expected to bring any additional 255 OAM considerations beyond those described in section 6 of [RFC6790]. 256 However, the OAM requirements and solutions for source routed tunnels 257 formed by label stacking are still under discussion and future 258 revisions of this document will address those if needed. 260 5. Options considered 262 Different options that were considered to arrive at the recommended 263 solution are documented in this section. 265 5.1. Single EL at the bottom of the stack of tunnels 267 In this option a single EL is used for the entire label stack. The 268 source LSR S encodes the entropy label (EL) at the bottom of the 269 label stack. In the example described in Section 3 it will result in 270 the label stack at LSR S to look like . Note that the notation in [RFC6790] 272 is used to describe the label stack. An issue with this approach is 273 that as the label stack grows due an increase in the number of SIDs, 274 the EL goes correspondingly deeper in the label stack. Hence transit 275 LSRs have to access a larger number of bytes in the packet header 276 when making forwarding decisions. In the example described in 277 Section 3 the LSR P1 would poorly load-balance traffic on the 278 parallel links L3, L4 since the EL is below the RLD of the packet 279 received by P1. A load balanced network design using this approach 280 must ensure that all intermediate LSRs have the capability to 281 traverse the maximum label stack depth as required for that 282 application that uses source routed stacking. 284 In the case where the hardware is capable of pushing a single pair at any depth, this option is the same as the recommended 286 solution in Section 4. 288 This option was discounted since there exist a number of hardware 289 implementations which have a low maximum readable label depth. 290 Choosing this option can lead to a loss of load-balancing using EL in 291 a significant part of the network but that is a critical requirement 292 in a service provider network. 294 5.2. An EL per tunnel in the stack 296 In this option each tunnel in the stack can be given its own EL. The 297 source LSR pushes an before pushing a tunnel label when 298 load balancing is required to direct traffic on that tunnel. In the 299 example described in Section 3, the source LSR S encoded label stack 300 would be where all the ELs 301 can be the same. Accessing the EL at an intermediate LSR is 302 independent of the depth of the label stack and hence independent of 303 the specific application that uses source routed tunnels with label 304 stacking in that network. A drawback is that the depth of the label 305 stack grows significantly, almost 3 times as the number of labels in 306 the label stack. The network design should ensure that source LSRs 307 should have the capability to push such a deep label stack. Also, 308 the bandwidth overhead and potential MTU issues of deep label stacks 309 should be accounted for in the network design. 311 In the case where the RLD is the minimum value (3) for all LSRs, all 312 LSRs are EL capable and the LSR that is inserting pairs has 313 no limit on how many it can insert then this option is the same as 314 the recommended solution in Section 4. 316 This option was discounted due to the existence of hardware 317 implementations that can push a limited number of labels on the label 318 stack. Choosing this option would result in a hardware requirement 319 to push two additional labels per tunnel label. Hence it would 320 restrict the number of tunnels that can form a LSP and constrain the 321 types of LSPs that can be created. This was considered unacceptable. 323 5.3. A re-usable EL for a stack of tunnels 325 In this option an LSR that terminates a tunnel re-uses the EL of the 326 terminated tunnel for the next inner tunnel. It does this by storing 327 the EL from the outer tunnel when that tunnel is terminated and re- 328 inserting it below the next inner tunnel label during the label swap 329 operation. The LSR that stacks tunnels should insert an EL below the 330 outermost tunnel. It should not insert ELs for any inner tunnels. 331 Also, the penultimate hop LSR of a segment must not pop the ELI and 332 EL even though they are exposed as the top labels since the 333 terminating LSR of that segment would re-use the EL for the next 334 segment. 336 In Section 3 above, the source LSR S encoded label stack would be 337 . At P1 the outgoing label stack 338 would be after it has load balanced 339 to one of the links L3 or L4. At P3 the outgoing label stack would 340 be . At P2 the outgoing label stack would be and it would load balance to one of the nexthop LSRs P4 or 342 P5. Accessing the EL at an intermediate LSR (e.g. P1) is 343 independent of the depth of the label stack and hence independent of 344 the specific use-case to which the label stack is applied. 346 This option was discounted due to the significant change in label 347 swap operations that would be required for existing hardware. 349 5.3.1. EL at top of stack 351 A slight variant of the re-usable EL option is to keep the EL at the 352 top of the stack rather than below the tunnel label. In this case 353 each LSR that is not terminating a segment should continue to keep 354 the received EL at the top of the stack when forwarding the packet 355 along the segment. An LSR that terminates a segment should use the 356 EL from the terminated segment at the top of the stack when 357 forwarding onto the next segment. 359 This option was discounted due to the significant change in label 360 swap operations that would be required for existing hardware. 362 5.4. ELs at readable label stack depths 364 In this option the source LSR inserts ELs for tunnels in the label 365 stack at depths such that each LSR along the path that must load 366 balance is able to access at least one EL. Note that the source LSR 367 may have to insert multiple ELs in the label stack at different 368 depths for this to work since intermediate LSRs may have differing 369 capabilities in accessing the depth of a label stack. The label 370 stack depth access value of intermediate LSRs must be known to create 371 such a label stack. How this value is determined is outside the 372 scope of this document. This value can be advertised using a 373 protocol such as an IGP. For the same Section 3 above, if LSR P1 374 needs to have the EL within a depth of 4, then the source LSR S 375 encoded label stack would be where all the ELs would typically have the same value. 378 In the case where the RLD has different values along the path and the 379 LSR that is inserting pairs has no limit on how many pairs 380 it can insert, and it knows the appropriate positions in the stack 381 where they should be inserted, then this option is the same as the 382 recommended solution in Section 4. 384 A variant of this solution was selected which balances the number of 385 labels that need to be pushed against the requirement for entropy. 387 6. Acknowledgements 389 The authors would like to thank John Drake, Loa Andersson, Curtis 390 Villamizar, Greg Mirsky, Markus Jork, Kamran Raza and Nobo Akiya for 391 their review comments and suggestions. 393 7. Contributors 395 Xiaohu Xu 396 Huawei 398 Email: xuxiaohu@huawei.com 400 Wim Hendrickx 401 Alcatel-Lucent 403 Email: wim.henderickx@alcatel-lucent.com 405 8. IANA Considerations 407 This memo includes no request to IANA. Note to RFC Editor: Remove 408 this section before publication. 410 9. Security Considerations 412 This document does not introduce any new security considerations 413 beyond those already listed in [RFC6790]. 415 10. References 417 10.1. Normative References 419 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 420 Requirement Levels", BCP 14, RFC 2119, 421 DOI 10.17487/RFC2119, March 1997, 422 . 424 [RFC6790] Kompella, K., Drake, J., Amante, S., Henderickx, W., and 425 L. Yong, "The Use of Entropy Labels in MPLS Forwarding", 426 RFC 6790, DOI 10.17487/RFC6790, November 2012, 427 . 429 10.2. Informative References 431 [I-D.ietf-spring-segment-routing] 432 Filsfils, C., Previdi, S., Decraene, B., Litkowski, S., 433 and R. Shakir, "Segment Routing Architecture", draft-ietf- 434 spring-segment-routing-07 (work in progress), December 435 2015. 437 [I-D.xu-isis-mpls-elc] 438 Xu, X., Kini, S., Sivabalan, S., Filsfils, C., and S. 439 Litkowski, "Signaling Entropy Label Capability Using IS- 440 IS", draft-xu-isis-mpls-elc-02 (work in progress), April 441 2015. 443 [I-D.xu-ospf-mpls-elc] 444 Xu, X., Kini, S., Sivabalan, S., Filsfils, C., and S. 445 Litkowski, "Signaling Entropy Label Capability Using 446 OSPF", draft-xu-ospf-mpls-elc-01 (work in progress), 447 October 2014. 449 [RFC4206] Kompella, K. and Y. Rekhter, "Label Switched Paths (LSP) 450 Hierarchy with Generalized Multi-Protocol Label Switching 451 (GMPLS) Traffic Engineering (TE)", RFC 4206, 452 DOI 10.17487/RFC4206, October 2005, 453 . 455 [RFC7325] Villamizar, C., Ed., Kompella, K., Amante, S., Malis, A., 456 and C. Pignataro, "MPLS Forwarding Compliance and 457 Performance Requirements", RFC 7325, DOI 10.17487/RFC7325, 458 August 2014, . 460 Authors' Addresses 462 Sriganesh Kini (editor) 464 Email: sriganeshkini@gmail.com 466 Kireeti Kompella 467 Juniper 469 Email: kireeti@juniper.net 471 Siva Sivabalan 472 Cisco 474 Email: msiva@cisco.com 476 Stephane Litkowski 477 Orange 479 Email: stephane.litkowski@orange.com 481 Rob Shakir 483 Email: rjs@rob.sh 485 Jeff Tantsura 487 Email: jefftant@gmail.com