idnits 2.17.00 (12 Aug 2021) /tmp/idnits15805/draft-ietf-mpls-spring-entropy-label-02.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 (January 26, 2016) is 2307 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: draft-ietf-spring-segment-routing has been published as RFC 8402 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 Ericsson 4 Intended status: Standards Track K. Kompella 5 Expires: July 29, 2016 Juniper 6 S. Sivabalan 7 Cisco 8 S. Litkowski 9 Orange 10 R. Shakir 12 X. Xu 13 Huawei 14 W. Hendrickx 15 Alcatel-Lucent 16 J. Tantsura 17 Ericsson 18 January 26, 2016 20 Entropy labels for source routed tunnels with label stacks 21 draft-ietf-mpls-spring-entropy-label-02 23 Abstract 25 Source routed tunnels with label stacking is a technique that can be 26 leveraged to provide a method to steer a packet through a controlled 27 set of segments. This can be applied to the Multi Protocol Label 28 Switching (MPLS) data plane. Entropy label (EL) is a technique used 29 in MPLS to improve load balancing. This document examines and 30 describes how ELs are to be applied to source routed tunnels with 31 label stacks. 33 Status of This Memo 35 This Internet-Draft is submitted in full conformance with the 36 provisions of BCP 78 and BCP 79. 38 Internet-Drafts are working documents of the Internet Engineering 39 Task Force (IETF). Note that other groups may also distribute 40 working documents as Internet-Drafts. The list of current Internet- 41 Drafts is at http://datatracker.ietf.org/drafts/current/. 43 Internet-Drafts are draft documents valid for a maximum of six months 44 and may be updated, replaced, or obsoleted by other documents at any 45 time. It is inappropriate to use Internet-Drafts as reference 46 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on July 29, 2016. 50 Copyright Notice 52 Copyright (c) 2016 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (http://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the Simplified BSD License. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 68 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 69 2. Abbreviations and Terminology . . . . . . . . . . . . . . . . 3 70 3. Use-case requiring multipath load balancing . . . . . . . . . 4 71 4. Recommended EL solution for SPRING . . . . . . . . . . . . . 5 72 5. Options considered . . . . . . . . . . . . . . . . . . . . . 6 73 5.1. Single EL at the bottom of the stack of tunnels . . . . . 6 74 5.2. An EL per tunnel in the stack . . . . . . . . . . . . . . 7 75 5.3. A re-usable EL for a stack of tunnels . . . . . . . . . . 8 76 5.3.1. EL at top of stack . . . . . . . . . . . . . . . . . 8 77 5.4. ELs at readable label stack depths . . . . . . . . . . . 8 78 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 79 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 80 8. Security Considerations . . . . . . . . . . . . . . . . . . . 9 81 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 82 9.1. Normative References . . . . . . . . . . . . . . . . . . 9 83 9.2. Informative References . . . . . . . . . . . . . . . . . 10 84 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 86 1. Introduction 88 The source routed tunnels with label stacking paradigm is leveraged 89 by techniques such as Segment Routing (SR) 90 [I-D.ietf-spring-segment-routing] to steer a packet through a set of 91 segments. This can be directly applied to the MPLS data plane, but 92 it has implications on the label stack depth. 94 Clarifying statements on label stack depth have been provided in 95 [RFC7325] but the RFC does not address the case of source routed 96 stacked MPLS tunnels as described in 98 [I-D.ietf-spring-segment-routing] where deeper label stacks are more 99 prevalent. 101 Entropy label (EL) [RFC6790] is a technique used in the MPLS data 102 plane to provide entropy for load balancing. When using LSP 103 hierarchies there are implications on how [RFC6790] should be 104 applied. The current document addresses the case where the hierarchy 105 is created at a single LSR as required by source routed tunnels with 106 label stacks. 108 A use-case requiring load balancing with source routed tunnels with 109 label stacks is given in Section 3. A recommended solution is 110 described in Section 4 keeping in consideration the limitations of 111 implementations when applying [RFC6790] to deeper label stacks. 112 Options that were considered to arrive at the recommended solution 113 are documented for historical purposes in Section 5. 115 1.1. Requirements Language 117 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 118 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 119 document are to be interpreted as described in RFC 2119 [RFC2119]. 121 Although this document is not a protocol specification, the use of 122 this language clarifies the instructions to protocol designers 123 producing solutions that satisfy the requirements set out in this 124 document. 126 2. Abbreviations and Terminology 128 EL - Entropy Label 130 ELI - Entropy Label Identifier 132 ELC - Entropy Label Capability 134 SR - Segment Routing 136 ECMP - Equal Cost Multi Paths 138 MPLS - Multiprotocol Label Switching 140 SID - Segment Identifier 142 RLD - Readable Label Depth 144 OAM - Operation, Administration and Maintenance 146 3. Use-case requiring multipath load balancing 148 +------+ 149 | | 150 +-------| P3 |-----+ 151 | +-----| |---+ | 152 L3| |L4 +------+ L1| |L2 +----+ 153 | | | | +--| P4 |--+ 154 +-----+ +-----+ +-----+ | +----+ | +-----+ 155 | S |-----| P1 |------------| P2 |--+ +--| D | 156 | | | | | |--+ +--| | 157 +-----+ +-----+ +-----+ | +----+ | +-----+ 158 +--| P5 |--+ 159 +----+ 161 S=Source LSR, D=Destination LSR, P1,P2,P3,P4,P5=Transit LSRs, 162 L1,L2,L3,L4=Links 164 Figure 1: Traffic engineering use-case 166 Traffic-engineering (TE) is one of the applications of MPLS and is 167 also a requirement for source routed tunnels with label stacks. 168 Consider the topology shown in Figure 1. Lets say the LSR P1 has a 169 limitation that it can only look four labels deep in the stack to do 170 multipath decisions. All other transit LSRs in the figure can read 171 deep label stacks and the LSR S can insert as many pairs as 172 needed. The LSR S requires data to be sent to LSR D along a traffic- 173 engineered path that goes over the link L1. Good load balancing is 174 also required across equal cost paths (including parallel links). To 175 engineer traffic along a path that takes link L1, the label stack 176 that LSR S creates consists of a label to the node SID of LSR P3, 177 stacked over the label for the adjacency SID of link L1 and that in 178 turn is stacked over the label to the node SID of LSR D. For 179 simplicity lets assume that all LSRs use the same label space for 180 source routed label stacks. Lets L_N-P denote the label to be used 181 to reach the node SID of LSR P. Let L_A-Ln denote the label used for 182 the adjacency SID for link Ln. The LSR S must use the label stack 183 for traffic-engineering. However to achieve 184 good load balancing over the equal cost paths P2-P4-D, P2-P5-D and 185 the parallel links L3, L4, a mechanism such as Entropy labels 186 [RFC6790] should be adapted for source routed label stacks. Multiple 187 ways to apply entropy labels were considered and are documented in 188 Section 5 along with their tradeoffs. A recommended solution is 189 described in Section 4. 191 4. Recommended EL solution for SPRING 193 The solution described in this section follows [RFC6790]. 195 An LSR may have a limitation in its ability to read and process the 196 label stack in order to do multipath load balancing. This limitation 197 expressed in terms of the number of label stack entries that the LSR 198 can read is henceforth referred to as the Readable Label Depth (RLD) 199 capability of that LSR. If an EL does not occur within the RLD of an 200 LSR in the label stack of the MPLS packet that it receives, then it 201 would lead to poor load balancing at that LSR. The RLD of an LSR is 202 a characteristic of the forwarding plane of that LSR's implementation 203 and determining it is outside the scope of this document. 205 In order for the EL to occur within the RLD of LSRs along the path 206 corresponding to a label stack, multiple pairs MAY be 207 inserted in the label stack as long as the tunnel's label below which 208 they are inserted are advertised with entropy label capability 209 enabled. The LSR that inserts pairs MAY have limitations 210 on the number of such pairs that it can insert and also the depth at 211 which it can insert them. If due to any limitation, the inserted ELs 212 are at positions such that an LSR along the path receives an MPLS 213 packet without an EL in the label stack within that LSR's RLD, then 214 the load balancing performed by that LSR would be poor. Special 215 attention should be paid when a forwarding adjacency LSP (FA-LSP) 216 [RFC4206] is used as a link along the path of a source routed LSP's 217 label stack, since the labels of the FA-LSP would additionally count 218 towards the depth of the label stack when calculating the appropriate 219 positions to insert the ELs. The recommendations for inserting pairs are: 222 o An LSR that is limited in the number of pairs that it 223 can insert SHOULD insert such pairs deeper in the stack. 225 o An LSR SHOULD try to insert pairs at positions so that 226 for the maximum number of transit LSRs, the EL occurs within the 227 RLD of the incoming packet to that LSR. 229 o An LSR SHOULD try to insert the minimum number of such pairs while 230 trying to satisfy the above criteria. 232 A sample algorithm to insert ELs is shown below. Implementations can 233 choose any algorithm as long as it follows the above recommendations. 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 The recommendations above are not expected to bring any additional 259 OAM considerations beyond those described in section 6 of [RFC6790]. 260 However, the OAM requirements and solutions for source routed tunnels 261 formed by label stacking are still under discussion and future 262 revisions of this document will address those if needed. 264 5. Options considered 266 Different options that were considered to arrive at the recommended 267 solution are documented in this section. 269 5.1. Single EL at the bottom of the stack of tunnels 271 In this option a single EL is used for the entire label stack. The 272 source LSR S encodes the entropy label (EL) at the bottom of the 273 label stack. In the example described in Section 3 it will result in 274 the label stack at LSR S to look like . Note that the notation in [RFC6790] 276 is used to describe the label stack. An issue with this approach is 277 that as the label stack grows due an increase in the number of SIDs, 278 the EL goes correspondingly deeper in the label stack. Hence transit 279 LSRs have to access a larger number of bytes in the packet header 280 when making forwarding decisions. In the example described in 281 Section 3 the LSR P1 would poorly load-balance traffic on the 282 parallel links L3, L4 since the EL is below the RLD of the packet 283 received by P1. A load balanced network design using this approach 284 must ensure that all intermediate LSRs have the capability to 285 traverse the maximum label stack depth as required for that 286 application that uses source routed stacking. 288 In the case where the hardware is capable of pushing a single pair at any depth, this option is the same as the recommended 290 solution in Section 4. 292 This option was discounted since there exist a number of hardware 293 implementations which have a low maximum readable label depth. 294 Choosing this option can lead to a loss of load-balancing using EL in 295 a significant part of the network but that is a critical requirement 296 in a service provider network. 298 5.2. An EL per tunnel in the stack 300 In this option each tunnel in the stack can be given its own EL. The 301 source LSR pushes an before pushing a tunnel label when 302 load balancing is required to direct traffic on that tunnel. In the 303 example described in Section 3, the source LSR S encoded label stack 304 would be where all the ELs 305 can be the same. Accessing the EL at an intermediate LSR is 306 independent of the depth of the label stack and hence independent of 307 the specific application that uses source routed tunnels with label 308 stacking in that network. A drawback is that the depth of the label 309 stack grows significantly, almost 3 times as the number of labels in 310 the label stack. The network design should ensure that source LSRs 311 should have the capability to push such a deep label stack. Also, 312 the bandwidth overhead and potential MTU issues of deep label stacks 313 should be accounted for in the network design. 315 In the case where the RLD is the minimum value (3) for all LSRs, all 316 LSRs are EL capable and the LSR that is inserting pairs has 317 no limit on how many it can insert then this option is the same as 318 the recommended solution in Section 4. 320 This option was discounted due to the existence of hardware 321 implementations that can push a limited number of labels on the label 322 stack. Choosing this option would result in a hardware requirement 323 to push two additional labels per tunnel label. Hence it would 324 restrict the number of tunnels that can form a LSP and constrain the 325 types of LSPs that can be created. This was considered unacceptable. 327 5.3. A re-usable EL for a stack of tunnels 329 In this option an LSR that terminates a tunnel re-uses the EL of the 330 terminated tunnel for the next inner tunnel. It does this by storing 331 the EL from the outer tunnel when that tunnel is terminated and re- 332 inserting it below the next inner tunnel label during the label swap 333 operation. The LSR that stacks tunnels should insert an EL below the 334 outermost tunnel. It should not insert ELs for any inner tunnels. 335 Also, the penultimate hop LSR of a segment must not pop the ELI and 336 EL even though they are exposed as the top labels since the 337 terminating LSR of that segment would re-use the EL for the next 338 segment. 340 In Section 3 above, the source LSR S encoded label stack would be 341 . At P1 the outgoing label stack 342 would be after it has load balanced 343 to one of the links L3 or L4. At P3 the outgoing label stack would 344 be . At P2 the outgoing label stack would be and it would load balance to one of the nexthop LSRs P4 or 346 P5. Accessing the EL at an intermediate LSR (e.g. P1) is 347 independent of the depth of the label stack and hence independent of 348 the specific use-case to which the label stack is applied. 350 This option was discounted due to the significant change in label 351 swap operations that would be required for existing hardware. 353 5.3.1. EL at top of stack 355 A slight variant of the re-usable EL option is to keep the EL at the 356 top of the stack rather than below the tunnel label. In this case 357 each LSR that is not terminating a segment should continue to keep 358 the received EL at the top of the stack when forwarding the packet 359 along the segment. An LSR that terminates a segment should use the 360 EL from the terminated segment at the top of the stack when 361 forwarding onto the next segment. 363 This option was discounted due to the significant change in label 364 swap operations that would be required for existing hardware. 366 5.4. ELs at readable label stack depths 368 In this option the source LSR inserts ELs for tunnels in the label 369 stack at depths such that each LSR along the path that must load 370 balance is able to access at least one EL. Note that the source LSR 371 may have to insert multiple ELs in the label stack at different 372 depths for this to work since intermediate LSRs may have differing 373 capabilities in accessing the depth of a label stack. The label 374 stack depth access value of intermediate LSRs must be known to create 375 such a label stack. How this value is determined is outside the 376 scope of this document. This value can be advertised using a 377 protocol such as an IGP. For the same Section 3 above, if LSR P1 378 needs to have the EL within a depth of 4, then the source LSR S 379 encoded label stack would be where all the ELs would typically have the same value. 382 In the case where the RLD has different values along the path and the 383 LSR that is inserting pairs has no limit on how many pairs 384 it can insert, and it knows the appropriate positions in the stack 385 where they should be inserted, then this option is the same as the 386 recommended solution in Section 4. 388 A variant of this solution was selected which balances the number of 389 labels that need to be pushed against the requirement for entropy. 391 6. Acknowledgements 393 The authors would like to thank John Drake, Loa Andersson, Curtis 394 Villamizar, Greg Mirsky, Markus Jork, Kamran Raza and Nobo Akiya for 395 their review comments and suggestions. 397 7. IANA Considerations 399 This memo includes no request to IANA. Note to RFC Editor: Remove 400 this section before publication. 402 8. Security Considerations 404 This document does not introduce any new security considerations 405 beyond those already listed in [RFC6790]. 407 9. References 409 9.1. Normative References 411 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 412 Requirement Levels", BCP 14, RFC 2119, 413 DOI 10.17487/RFC2119, March 1997, 414 . 416 [RFC6790] Kompella, K., Drake, J., Amante, S., Henderickx, W., and 417 L. Yong, "The Use of Entropy Labels in MPLS Forwarding", 418 RFC 6790, DOI 10.17487/RFC6790, November 2012, 419 . 421 9.2. Informative References 423 [I-D.ietf-spring-segment-routing] 424 Filsfils, C., Previdi, S., Decraene, B., Litkowski, S., 425 and r. rjs@rob.sh, "Segment Routing Architecture", draft- 426 ietf-spring-segment-routing-07 (work in progress), 427 December 2015. 429 [I-D.xu-isis-mpls-elc] 430 Xu, X., Kini, S., Sivabalan, S., Filsfils, C., and S. 431 Litkowski, "Signaling Entropy Label Capability Using IS- 432 IS", draft-xu-isis-mpls-elc-02 (work in progress), April 433 2015. 435 [I-D.xu-ospf-mpls-elc] 436 Xu, X., Kini, S., Sivabalan, S., Filsfils, C., and S. 437 Litkowski, "Signaling Entropy Label Capability Using 438 OSPF", draft-xu-ospf-mpls-elc-01 (work in progress), 439 October 2014. 441 [RFC4206] Kompella, K. and Y. Rekhter, "Label Switched Paths (LSP) 442 Hierarchy with Generalized Multi-Protocol Label Switching 443 (GMPLS) Traffic Engineering (TE)", RFC 4206, 444 DOI 10.17487/RFC4206, October 2005, 445 . 447 [RFC7325] Villamizar, C., Ed., Kompella, K., Amante, S., Malis, A., 448 and C. Pignataro, "MPLS Forwarding Compliance and 449 Performance Requirements", RFC 7325, DOI 10.17487/RFC7325, 450 August 2014, . 452 Authors' Addresses 454 Sriganesh Kini (editor) 455 Ericsson 457 Email: sriganesh.kini@ericsson.com 459 Kireeti Kompella 460 Juniper 462 Email: kireeti@juniper.net 463 Siva Sivabalan 464 Cisco 466 Email: msiva@cisco.com 468 Stephane Litkowski 469 Orange 471 Email: stephane.litkowski@orange.com 473 Rob Shakir 475 Email: rjs@rob.sh 477 Xiaohu Xu 478 Huawei 480 Email: xuxiaohu@huawei.com 482 Wim Hendrickx 483 Alcatel-Lucent 485 Email: wim.henderickx@alcatel-lucent.com 487 Jeff Tantsura 488 Ericsson 490 Email: jeff.tantsura@ericsson.com