idnits 2.17.1 draft-ietf-mpls-entropy-lsp-ping-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 : ---------------------------------------------------------------------------- -- The draft header indicates that this document updates RFC6790, but the abstract doesn't seem to directly say this. It does mention RFC6790 though, so this could be OK. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC4379, updated by this document, for RFC5378 checks: 2002-03-27) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (January 4, 2016) is 3034 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) ** Obsolete normative reference: RFC 4379 (Obsoleted by RFC 8029) ** Obsolete normative reference: RFC 7537 (Obsoleted by RFC 8029) -- Obsolete informational reference (is this intentional?): RFC 6424 (Obsoleted by RFC 8029) Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force N. Akiya 3 Internet-Draft Big Switch Networks 4 Updates: 4379, 6424, 6790 (if approved) G. Swallow 5 Intended status: Standards Track C. Pignataro 6 Expires: July 7, 2016 Cisco 7 A. Malis 8 Huawei Technologies 9 S. Aldrin 10 Google 11 January 4, 2016 13 Label Switched Path (LSP) and Pseudowire (PW) Ping/Trace over 14 MPLS Network using Entropy Labels (EL) 15 draft-ietf-mpls-entropy-lsp-ping-02 17 Abstract 19 The Multiprotocol Label Switching (MPLS) Label Switched Path (LSP) 20 Ping and Traceroute are used to exercise specific paths of Equal-Cost 21 Multipath (ECMP). When LSP is signaled to use Entropy Label (EL) 22 described in RFC 6790, the ability for LSP Ping and Traceroute 23 operation to discover and exercise ECMP paths has been lost in 24 scenarios which LSRs apply deviating load balance techniques. One 25 such scenario is when some LSRs apply EL based load balancing while 26 other LSRs apply non-EL based load balancing (ex: IP). Another 27 scenario is when EL based LSP is stitched with another LSP which can 28 be EL based or non-EL based. 30 This document extends the MPLS LSP Ping and Traceroute mechanisms to 31 restore the ability of exercising specific paths of ECMP over LSP 32 which make use of the Entropy Label. This document updates RFC 4379, 33 RFC 6424, and RFC 6790. 35 Requirements Language 37 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 38 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 39 document are to be interpreted as described in RFC 2119 [RFC2119]. 41 Status of This Memo 43 This Internet-Draft is submitted in full conformance with the 44 provisions of BCP 78 and BCP 79. 46 Internet-Drafts are working documents of the Internet Engineering 47 Task Force (IETF). Note that other groups may also distribute 48 working documents as Internet-Drafts. The list of current Internet- 49 Drafts is at http://datatracker.ietf.org/drafts/current/. 51 Internet-Drafts are draft documents valid for a maximum of six months 52 and may be updated, replaced, or obsoleted by other documents at any 53 time. It is inappropriate to use Internet-Drafts as reference 54 material or to cite them other than as "work in progress." 56 This Internet-Draft will expire on July 7, 2016. 58 Copyright Notice 60 Copyright (c) 2016 IETF Trust and the persons identified as the 61 document authors. All rights reserved. 63 This document is subject to BCP 78 and the IETF Trust's Legal 64 Provisions Relating to IETF Documents 65 (http://trustee.ietf.org/license-info) in effect on the date of 66 publication of this document. Please review these documents 67 carefully, as they describe your rights and restrictions with respect 68 to this document. Code Components extracted from this document must 69 include Simplified BSD License text as described in Section 4.e of 70 the Trust Legal Provisions and are provided without warranty as 71 described in the Simplified BSD License. 73 Table of Contents 75 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 76 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 77 1.2. Prerequisite . . . . . . . . . . . . . . . . . . . . . . 4 78 1.3. Background . . . . . . . . . . . . . . . . . . . . . . . 4 79 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 5 80 3. Multipath Type 9 . . . . . . . . . . . . . . . . . . . . . . 7 81 4. Pseudowire Tracing . . . . . . . . . . . . . . . . . . . . . 7 82 5. Initiating LSR Procedures . . . . . . . . . . . . . . . . . . 8 83 6. Responder LSR Procedures . . . . . . . . . . . . . . . . . . 9 84 6.1. IP Based Load Balancer & Not Pushing ELI/EL . . . . . . . 10 85 6.2. IP Based Load Balancer & Pushes ELI/EL . . . . . . . . . 11 86 6.3. Label Based Load Balancer & Not Pushing ELI/EL . . . . . 12 87 6.4. Label Based Load Balancer & Pushes ELI/EL . . . . . . . . 12 88 6.5. Flow Aware MS-PW Stitching LSR . . . . . . . . . . . . . 13 89 7. Entropy Label FEC . . . . . . . . . . . . . . . . . . . . . . 13 90 8. DS Flags: L and E . . . . . . . . . . . . . . . . . . . . . . 14 91 9. New Multipath Information Type: TBD4 . . . . . . . . . . . . 15 92 10. Supported and Unsupported Cases . . . . . . . . . . . . . . . 16 93 11. Security Considerations . . . . . . . . . . . . . . . . . . . 18 94 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 95 12.1. DS Flags . . . . . . . . . . . . . . . . . . . . . . . . 19 96 12.2. Multpath Type . . . . . . . . . . . . . . . . . . . . . 19 97 12.3. Entropy Label FEC . . . . . . . . . . . . . . . . . . . 19 98 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 19 99 14. Contributing Authors . . . . . . . . . . . . . . . . . . . . 20 100 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 101 15.1. Normative References . . . . . . . . . . . . . . . . . . 20 102 15.2. Informative References . . . . . . . . . . . . . . . . . 20 103 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21 105 1. Introduction 107 1.1. Terminology 109 The following acronyms/terminologies are used in this document: 111 o MPLS - Multiprotocol Label Switching. 113 o LSP - Label Switched Path. 115 o LSR - Label Switching Router. 117 o FEC - Forwarding Equivalent Class. 119 o ECMP - Equal-Cost Multipath. 121 o EL - Entropy Label. 123 o ELI - Entropy Label Indicator. 125 o GAL - Generic Associated Channel Label. 127 o MS-PW - Multi-Segment Pseudowire. 129 o Initiating LSR - LSR which sends MPLS echo request. 131 o Responder LSR - LSR which receives MPLS echo request and sends 132 MPLS echo reply. 134 o IP Based Load Balancer - LSR which load balances on fields from IP 135 header (and possibly fields from upper layers), and does not 136 consider entropy label from label stack (i.e. Flow Label or 137 Entropy Label) for load balancing purpose. 139 o Label Based Load Balancer - LSR which load balances on entropy 140 label from label stack (i.e. Flow Label or Entropy Label), and 141 does not consider fields from IP header (and possibly fields from 142 upper layers) for load balancing purpose. 144 o Label and IP Based Load Balancer - LSR which load balances on both 145 labels from label stack (including Flow Label or Entropy Label if 146 present) and fields from IP header (and possibly fields from upper 147 layers). 149 1.2. Prerequisite 151 MPLS implementations employ wide variety of load balancing techniques 152 in terms of fields used for hash "keys". [RFC4379] and [RFC6424] are 153 designed to provide multipath support for subset of techniques. 154 Intent of this document is to restore multipath support for those 155 supported techniques which have been compromised by the introduction 156 of [RFC6790] (i.e. Entropy Labels). Section 10 describes supported 157 and unsupported cases, and it may be useful for one to visit this 158 section first. 160 1.3. Background 162 Section 3.3.1 of [RFC4379] specifies multipath information encoding 163 in Downstream Mapping TLV (Section 3.3 of [RFC4379]) and Downstream 164 Detailed Mapping TLV (Section 3.3 of [RFC6424]) which can be used by 165 LSP Ping initiator to trace and validate all ECMP paths between 166 ingress and egress. These encodings are sufficient when all the LSRs 167 along the path(s), between ingress and egress, consider same set of 168 "keys" as input for load balancing algorithm: all IP based or all 169 label based. 171 With introduction of [RFC6790], it is quite normal to see set of LSRs 172 performing load balancing based on EL/ELI while others still follow 173 the traditional way (IP based). This results in LSP Ping initiator 174 not be able to trace and validate all ECMP paths in following 175 scenarios: 177 o One or more transit LSRs along LSP with ELI/EL in label stack do 178 not perform ECMP load balancing based on EL (hashes based on 179 "keys" including IP destination address). This scenario is not 180 only possible but quite common due transit LSRs not implementing 181 [RFC6790] or transit LSRs implementing [RFC6790] but not 182 implementing suggested transit LSR behavior in Section 4.3 of 183 [RFC6790]. 185 o Two or more LSPs stitched together with at least one of these LSP 186 pushing ELI/EL in label stack. Such scenarios are described in 187 [I-D.ravisingh-mpls-el-for-seamless-mpls]. 189 These scenarios will be quite common because every deployment of 190 [RFC6790] will invariably end up with nodes that support ELI/EL and 191 nodes that do not. There will typically be areas that support ELI/EL 192 and areas that do not. 194 As pointed out in [RFC6790] the procedures of [RFC4379] with respect 195 to multipath information type {9} are incomplete. However [RFC6790] 196 does not actually update [RFC4379]. Further the specific EL location 197 is not clearly defined, particularly in the case of Flow Aware 198 Pseudowires [RFC6391]. This document defines a new FEC Stack sub-TLV 199 for the Entropy Label. Section 3 of this document updates the 200 procedures for multipath information type {9} described in [RFC4379]. 201 Rest of this document describes extensions required to restore ECMP 202 discovery and tracing capabilities for scenarios described. 204 2. Overview 206 [RFC4379] describes LSP traceroute as an operation where the 207 initiating LSR send a series of MPLS echo requests towards the same 208 destination. The first packet in the series have the TTL set to 1. 209 When the echo reply is received from the LSR one hop away the second 210 echo request in the series is sent with the TTL set to 2, for each 211 echo request the TLL is incremented by one until a response is 212 received from the intended destination. Initiating LSR discovers and 213 exercises ECMP by obtaining multipath information from each transit 214 LSR and using specific destination IP address or specific entropy 215 label. 217 Notion of {x, y, z} from here on refers to Multipath information 218 types x, y or z. 220 LSP Ping initiating LSR sends MPLS echo request with multipath 221 information. This multipath information is described in DSMAP/DDMAP 222 TLV of echo request, and may contain set of IP addresses or set of 223 labels. Multipath information types {2, 4, 8} carry set of IP 224 addresses and multipath information type {9} carries set of labels. 225 Responder LSR (receiver of MPLS echo request) will determine the 226 subset of initiator specified multipath information which load 227 balances to each downstream (outgoing interface). Responder LSR 228 sends MPLS echo reply with resulting multipath information per 229 downstream (outgoing interface) back to the initiating LSR. 230 Initiating LSR is then able to use specific IP destination address or 231 specific label to exercise specific ECMP path on the responder LSR. 233 Current behavior is problematic in following scenarios: 235 o Initiating LSR sends IP multipath information, but responder LSR 236 load balances on labels. 238 o Initiating LSR sends label multipath information, but responder 239 LSR load balances on IP addresses. 241 o Initiating LSR sends existing multipath information to LSR which 242 pushes ELI/EL in label stack, but the initiating LSR can only 243 continue to discover and exercise specific path of ECMP, if the 244 LSR which pushes ELI/EL responds with both IP addresses and 245 associated EL corresponding to each IP address. This is because: 247 * ELI/EL pushing LSR that is a stitching point will load balance 248 based on IP address. 250 * Downstream LSR(s) of ELI/EL pushing LSR may load balance based 251 on ELs. 253 o Initiating LSR sends one of existing multipath information to ELI/ 254 EL pushing LSR, but initiating LSR can only continue to discover 255 and exercise specific path of ECMP if ELI/EL pushing LSR responds 256 with both labels and associated EL corresponding to label. This 257 is because: 259 * ELI/EL pushing LSR that is a stitching point will load balance 260 based on EL from previous LSP and pushes new EL. 262 * Downstream LSR(s) of ELI/EL pushing LSR may load balance based 263 on new ELs. 265 The above scenarios point to how the existing multipath information 266 is insufficient when LSP traceroute is operated on an LSP with 267 Entropy Labels described by [RFC6790]. Therefore, this document 268 defines a multipath information type to be used in the DSMAP/DDMAP of 269 MPLS echo request/reply packets in Section 9. 271 In addition, responder LSR can reply with empty multipath information 272 if no IP address set or label set from received multipath information 273 matched load balancing to a downstream. Empty return is also 274 possible if initiating LSR sends multipath information of one type, 275 IP address or label, but responder LSR load balances on the other 276 type. To disambiguate between the two results, this document 277 introduces new flags in the DSMAP/DDMAP TLV to allow responder LSR to 278 describe the load balance technique being used. 280 It is required that all LSRs along the LSP understand new flags as 281 well as new multipath information type. It is also required that 282 initiating LSR can select both IP destination address and label to 283 use on transmitting MPLS echo request packets. Two additional DS 284 Flags are defined for the DSMAP and DDMAP TLVs in Section 8. These 285 two flags are used by the responder LSR to describe its load balance 286 behavior on received MPLS echo request. 288 Note that the terms "IP Based Load Balancer", "Label Based Load 289 Balancer" and "Label Based Load Balancer" are in context of how 290 received MPLS echo request is handled by the responder LSR. 292 3. Multipath Type 9 294 This section defines to which labels multipath type {9} applies. 296 [RFC4379] defined multipath type {9} for tracing of LSPs where label 297 based load-balancing is used. However, as pointed out in [RFC6790], 298 the procedures for using this type are incomplete as the specific 299 location of the label was not defined. It was assumed that the 300 presence of multipath type {9} implied the value of the bottom-of- 301 stack label should be varied by the values indicated by multipath to 302 determine their respective out-going interfaces. 304 Section 7 defines a new FEC-Stack sub-TLV to indicate an entropy 305 label. These labels may appear anywhere in a label stack. 307 Multipath type {9} applies to the first label in the label-stack that 308 corresponds to an EL-FEC. If no such label is found, it applies to 309 the label at the bottom of the label stack. 311 4. Pseudowire Tracing 313 This section defines procedures for tracing pseudowires. These 314 procedures pertain to the use of multipath information type {9} as 315 well as type {TBD4}. In all cases below, when a control word is in 316 use the N-flag in the DDMAP or DSMAP MUST be set. Note that when a 317 control word is not in use the returned DDMAPs or DSMAPs may not be 318 accurate. 320 In order to trace a non Flow-Aware Pseudowire the initiator includes 321 an EL-FEC instead of the appropriate PW-FEC at the bottom of the FEC- 322 Stack. Tracing in this way will cause compliant routers to return 323 the proper outgoing interface. Note that this procedure only traces 324 to the end of the MPLS LSP that is under test and will not verify the 325 PW FEC. To actually verify the PW-FEC or in the case of a MS-PW, to 326 determine the next pseudowire label value, the initiator MUST repeat 327 that step of the trace, (i.e., repeating the TTL value used) but with 328 the FEC-Stack modified to contain the appropriate PW-FEC. Note that 329 these procedures are applicable to scenarios which an initiator is 330 able to vary the bottom label (i.e. pseudowire label). Possible 331 scenarios are tracing multiple non Flow-Aware Pseudowires on the same 332 endpoints or tracing a non Flow-Aware Pseudowire provisioned with 333 multiple pseudowire labels. 335 In order to trace a Flow Aware Pseudowire, the initiator includes an 336 EL-FEC at the bottom of the FEC-Stack and pushes the appropriate PW- 337 FEC onto the FEC-Stack. 339 In order to trace through non-compliant routers the initiator forms 340 an MPLS echo request message and includes a DDMAP or DSMAP with 341 multipath type {9}. For a non Flow-Aware Pseudowire it includes the 342 appropriate PW-FEC in the FEC-Stack. For a Flow Aware Pseudowire, 343 the initiator includes a NIL-FEC at the bottom of the FEC-Stack and 344 pushes the appropriate PW-FEC onto the FEC-Stack. 346 5. Initiating LSR Procedures 348 In order to facilitate the flow of the following text we speak in 349 terms of a boolean called EL_LSP maintained by the initiating LSR. 350 This value controls the multipath information type to be used in 351 transmitted echo request packets. When the initiating LSR is 352 transmitting an echo request packet with DSMAP/DDMAP with a non-zero 353 multipath information type, then EL_LSP boolean MUST be consulted to 354 determine the multipath information type to use. 356 In addition to procedures described in [RFC4379] as updated by 357 Section 3 and [RFC6424], initiating LSR MUST operate with following 358 procedures. 360 o When the initiating LSR pushes ELI/EL, initialize EL_LSP=True. 361 Else set EL_LSP=False. 363 o When the initiating LSR is transmitting non-zero multipath 364 information type: 366 * If (EL_LSP), the initiating LSR MUST use multipath information 367 type {TBD4} unless same responder LSR cannot handle type 368 {TBD4}. When the initiating LSR is transmitting multipath 369 information type {TBD4} in this case, both "IP Multipath 370 Information" and "Label Multipath Information" MUST be 371 included, and "IP Associated Label Multipath Information" MUST 372 be omitted (NULL). 374 * Else the initiating LSR MAY use multipath information type {2, 375 4, 8, 9, TBD4}. When the initiating LSR is transmitting 376 multipath information type {TBD4} in this case, "IP Multipath 377 Information" MUST be included, and "Label Multipath 378 Information" and "IP Associated Label Multipath Information" 379 MUST be omitted (NULL). 381 o When the initiating LSR receives echo reply with {L=0, E=1} in DS 382 flags with valid contents, set EL_LSP=True. 384 In following conditions, the initiating LSR may have lost the ability 385 to exercise specific ECMP paths. The initiating LSR MAY continue 386 with "best effort". 388 o Received echo reply contains empty multipath information. 390 o Received echo reply contains {L=0, E=} DS flags, but does not 391 contain IP multipath information. 393 o Received echo reply contains {L=1, E=} DS flags, but does not 394 contain label multipath information. 396 o Received echo reply contains {L=, E=1} DS flags, but does not 397 contain associated label multipath information. 399 o IP multipath information types {2, 4, 8} sent, and received echo 400 reply with {L=1, E=0} in DS flags. 402 o Multipath information type {TBD4} sent, and received echo reply 403 with multipath information type other than {TBD4}. 405 6. Responder LSR Procedures 407 Common Procedures: 409 o The responder LSR receiving an MPLS echo request packet MUST first 410 determine whether or not the initiating LSR supports this LSP Ping 411 and Traceroute extension for Entropy Labels. If either of the 412 following conditions are met, the responder LSR SHOULD determine 413 that the initiating LSR supports this LSP Ping and Traceroute 414 extension for Entropy Labels. 416 1. Received MPLS echo request contains the multipath information 417 type {TBD4}. 419 2. Received MPLS echo request contains a Target FEC Stack TLV 420 that includes the Entropy Label FEC. 422 If the initiating LSR is determined to not support this LSP Ping 423 and Traceroute extension for Entropy Labels, then the responder 424 LSR MUST NOT follow further procedures described in this section. 425 Specifically, MPLS echo reply packets: 427 * MUST have following DS Flags cleared (i.e., not set): "ELI/EL 428 push indicator" and "Label based load balance indicator". 430 * MUST NOT use multipath information type {TBD4}. 432 o The responder LSR receiving an MPLS echo request packet with 433 multipath information type {TBD4} MUST validate following 434 contents. Any deviation MUST result in the responder LSR to 435 consider the packet as malformed and return code 1 (Malformed echo 436 request received) in the MPLS echo reply packet. 438 * IP multipath information MUST be included. 440 * Label multipath information MAY be included. 442 * IP associated label multipath information MUST be omitted 443 (NULL). 445 Following subsections describe expected responder LSR procedures when 446 echo reply is to include DSMAP/DDMAP TLVs, based on local load 447 balance technique being employed. In case the responder LSR performs 448 deviating load balance techniques per downstream basis, appropriate 449 procedures matching to each downstream load balance technique MUST be 450 operated. 452 6.1. IP Based Load Balancer & Not Pushing ELI/EL 454 o The responder MUST set {L=0, E=0} in DS flags. 456 o If multipath information type {2, 4, 8} is received, the responder 457 MUST comply with [RFC4379] and [RFC6424]. 459 o If multipath information type {9} is received, the responder MUST 460 reply with multipath type {0}. 462 o If multipath information type {TBD4} is received, following 463 procedures are to be used: 465 * The responder MUST reply with multipath information type 466 {TBD4}. 468 * "Label Multipath Information" and "Associated Label Multipath 469 Information" sections MUST be omitted (NULL). 471 * If no matching IP address is found, then "IPMultipathType" 472 field MUST be set to multipath information type {0} and "IP 473 Multipath Information" section MUST also be omitted (NULL). 475 * If at least one matching IP address is found, then 476 "IPMultipathType" field MUST be set to appropriate multipath 477 information type {2, 4, 8} and "IP Multipath Information" 478 section MUST be included. 480 6.2. IP Based Load Balancer & Pushes ELI/EL 482 o The responder MUST set {L=0, E=1} in DS flags. 484 o If multipath information type {9} is received, the responder MUST 485 reply with multipath type {0}. 487 o If multipath type {2, 4, 8, TBD4} is received, following 488 procedures are to be used: 490 * The responder MUST respond with multipath type {TBD4}. See 491 Section 9 for details of multipath type {TBD4}. 493 * "Label Multipath Information" section MUST be omitted (i.e. is 494 it not there). 496 * IP address set specified in received IP multipath information 497 MUST be used to determine the returning IP/Label pairs. 499 * If received multipath information type was {TBD4}, received 500 "Label Multipath Information" sections MUST NOT be used to 501 determine the associated label portion of returning IP/Label 502 pairs. 504 * If no matching IP address is found, then "IPMultipathType" 505 field MUST be set to multipath information type {0} and "IP 506 Multipath Information" section MUST be omitted. In addition, 507 "Assoc Label Multipath Length" MUST be set to 0, and 508 "Associated Label Multipath Information" section MUST also be 509 omitted. 511 * If at least one matching IP address is found, then 512 "IPMultipathType" field MUST be set to appropriate multipath 513 information type {2, 4, 8} and "IP Multipath Information" 514 section MUST be included. In addition, "Associated Label 515 Multipath Information" section MUST be populated with list of 516 labels corresponding to each IP address specified in "IP 517 Multipath Information" section. "Assoc Label Multipath Length" 518 MUST be set to a value representing length in octets of 519 "Associated Label Multipath Information" field. 521 6.3. Label Based Load Balancer & Not Pushing ELI/EL 523 o The responder MUST set {L=1, E=0} in DS flags. 525 o If multipath information type {2, 4, 8} is received, the responder 526 MUST reply with multipath type {0}. 528 o If multipath information type {9} is received, the responder MUST 529 comply with [RFC4379] and [RFC6424] as updated by Section 3. 531 o If multipath information type {TBD4} is received, following 532 procedures are to be used: 534 * The responder MUST reply with multipath information type 535 {TBD4}. 537 * "IP Multipath Information" and "Associated Label Multipath 538 Information" sections MUST be omitted (NULL). 540 * If no matching label is found, then "LbMultipathType" field 541 MUST be set to multipath information type {0} and "Label 542 Multipath Information" section MUST also be omitted (NULL). 544 * If at least one matching label is found, then "LbMultipathType" 545 field MUST be set to appropriate multipath information type {9} 546 and "Label Multipath Information" section MUST be included. 548 6.4. Label Based Load Balancer & Pushes ELI/EL 550 o The responder MUST set {L=1, E=1} in DS flags. 552 o If multipath information type {2, 4, 8} is received, the responder 553 MUST reply with multipath type {0}. 555 o If multipath type {9, TBD4} is received, following procedures are 556 to be used: 558 * The responder MUST respond with multipath type {TBD4}. 560 * "IP Multipath Information" section MUST be omitted. 562 * Label set specified in received label multipath information 563 MUST be used to determine the returning Label/Label pairs. 565 * If received multipath information type was {TBD4}, received 566 "Label Multipath Information" sections MUST NOT be used to 567 determine the associated label portion of returning Label/Label 568 pairs. 570 * If no matching label is found, then "LbMultipathType" field 571 MUST be set to multipath information type {0} and "Label 572 Multipath Information" section MUST be omitted. In addition, 573 "Assoc Label Multipath Length" MUST be set to 0, and 574 "Associated Label Multipath Information" section MUST also be 575 omitted. 577 * If at least one matching label is found, then "LbMultipathType" 578 field MUST be set to appropriate multipath information type {9} 579 and "Label Multipath Information" section MUST be included. In 580 addition, "Associated Label Multipath Information" section MUST 581 be populated with list of labels corresponding to each label 582 specified in "Label Multipath Information" section. "Assoc 583 Label Multipath Length" MUST be set to a value representing 584 length in octets of "Associated Label Multipath Information" 585 field. 587 6.5. Flow Aware MS-PW Stitching LSR 589 Stitching LSR that cross-connects Flow Aware Pseudowires behave in 590 one of two ways: 592 o Load balances on previous Flow Label, and carries over same Flow 593 Label. For this case, stitching LSR is to behave as procedures 594 described in Section 6.3. 596 o Load balances on previous Flow Label, and replaces Flow Label with 597 newly computed. For this case, stitching LSR is to behave as 598 procedures described in Section 6.4. 600 7. Entropy Label FEC 602 Entropy Label Indicator (ELI) is a reserved label that has no 603 explicit FEC associated, and has label value 7 assigned from the 604 reserved range. Use Nil FEC as Target FEC Stack sub-TLV to account 605 for ELI in a Target FEC Stack TLV. 607 Entropy Label (EL) is a special purpose label with label value being 608 discretionary (i.e. label value may not be from the reserved range). 609 For LSP verification mechanics to perform its purpose, it is 610 necessary for a Target FEC Stack sub-TLV to clearly describe EL, 611 particularly in the scenario where label stack does not carry ELI 612 (ex: Flow Aware Pseudowire [RFC6391]). Therefore, this document 613 defines a EL FEC to allow a Target FEC Stack sub-TLV to be added to 614 the Target FEC Stack to account for EL. 616 The Length is 4. Labels are 20-bit values treated as numbers. 618 0 1 2 3 619 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 620 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 621 | Label | MBZ | 622 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 624 Figure 1: Entropy Label FEC 626 Label is the actual label value inserted in the label stack; the MBZ 627 fields MUST be zero when sent and ignored on receipt. 629 8. DS Flags: L and E 631 Two flags, L and E, are added in DS Flags field of the DSMAP/DDMAP 632 TLVs. Both flags MUST NOT be set in echo request packets when 633 sending, and ignored when received. Zero, one or both new flags MUST 634 be set in echo reply packets. 636 DS Flags 637 -------- 639 0 1 2 3 4 5 6 7 640 +-+-+-+-+-+-+-+-+ 641 | MBZ |L|E|I|N| 642 +-+-+-+-+-+-+-+-+ 644 RFC-Editor-Note: Please update above figure to place the flag E in 645 the bit number TBD2 and the flag L in the bit number TBD3. 647 Flag Name and Meaning 648 ---- ---------------- 649 L Label based load balance indicator 650 This flag MUST be set to zero in the echo request. LSR 651 which performs load balancing on a label MUST set this 652 flag in the echo reply. LSR which performs load 653 balancing on IP MUST NOT set this flag in the echo 654 reply. 656 E ELI/EL push indicator 657 This flag MUST be set to zero in the echo request. LSR 658 which pushes ELI/EL MUST set this flag in the echo 659 reply. LSR which does not push ELI/EL MUST NOT set 660 this flag in the echo reply. 662 Two flags result in four load balancing techniques which echo reply 663 generating LSR can indicate: 665 o {L=0, E=0} LSR load balances based on IP and does not push ELI/EL. 667 o {L=0, E=1} LSR load balances based on IP and pushes ELI/EL. 669 o {L=1, E=0} LSR load balances based on label and does not push ELI/ 670 EL. 672 o {L=1, E=1} LSR load balances based on label and pushes ELI/EL. 674 9. New Multipath Information Type: TBD4 676 One new multipath information type is added to be used in DSMAP/DDMAP 677 TLVs. New multipath type has value of TBD4. 679 Key Type Multipath Information 680 --- ---------------- --------------------- 681 TBD4 IP and label set IP addresses and label prefixes 683 Multipath type TBD4 is comprised of three sections. One section to 684 describe IP address set. One section to describe label set. One 685 section to describe another label set which associates to either IP 686 address set or label set specified in the other section. 688 Multipath information type TBD4 has following format: 690 0 1 2 3 691 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 692 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 693 |IPMultipathType| IP Multipath Length | Reserved(MBZ) | 694 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 695 ~ ~ 696 | (IP Multipath Information) | 697 ~ ~ 698 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 699 |LbMultipathType| Label Multipath Length | Reserved(MBZ) | 700 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 701 ~ ~ 702 | (Label Multipath Information) | 703 ~ ~ 704 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 705 | Assoc Label Multipath Length | Reserved(MBZ) | 706 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 707 ~ ~ 708 | (Associated Label Multipath Information) | 709 ~ ~ 710 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 712 Figure 2: Multipath Information Type TBD4 714 o IPMultipathType 715 * 0 when "IP Multipath Information" is omitted. Otherwise one of 716 IP multipath information values: {2, 4, 8}. 718 o IP Multipath Information 720 * This section is omitted when "IPMultipathType" is 0. Otherwise 721 this section reuses IP multipath information from [RFC4379]. 722 Specifically, multipath information for values {2, 4, 8} can be 723 used. 725 o LbMultipathType 727 * 0 when "Label Multipath Information" is omitted. Otherwise 728 label multipath information value {9}. 730 o Label Multipath Information 732 * This section is omitted when "LbMultipathType" is 0. Otherwise 733 this section reuses label multipath information from [RFC4379]. 734 Specifically, multipath information for value {9} can be used. 736 o Associated Label Multipath Information 738 * "Assoc Label Multipath Length" is a 16 bit field of multipath 739 information which indicates length in octets of the associated 740 label multipath information. 742 * "Associated Label Multipath Information" is a list of labels 743 with each label described in 24 bits. This section MUST be 744 omitted in an MPLS echo request message. A midpoint which 745 pushes ELI/EL labels SHOULD include "Assoc Label Multipath 746 Information" in its MPLS echo reply message, along with either 747 "IP Multipath Information" or "Label Multipath Information". 748 Each specified associated label described in this section maps 749 to specific IP address OR label described in the "IP Multipath 750 Information" section or "Label Multipath Information" section. 751 For example, if 3 IP addresses are specified in the "IP 752 Multipath Information" section, then there MUST be 3 labels 753 described in this section. First label maps to the lowest IP 754 address specified, second label maps to the second lowest IP 755 address specified and third label maps to the third lowest IP 756 address specified. 758 10. Supported and Unsupported Cases 760 MPLS architecture never defined strict rules on how implementations 761 are to identify hash "keys" for load balancing purpose. As result, 762 implementations may be of following load balancer types: 764 1. IP Based Load Balancer. 765 2. Label Based Load Balancer. 766 3. Label and IP Based Load Balancer. 768 For cases (2) and (3), implementation can include different sets of 769 labels from the label stack for load balancing purpose. Thus 770 following sub-cases are possible: 772 a. Entire label stack. 773 b. Top N labels from label stack where number of labels in label 774 stack is >N. 775 c. Bottom N labels from label stack where number of labels in label 776 stack is >N. 778 In a scenario where there is one Flow Label or Entropy Label present 779 in the label stack, following further cases are possible for (2b), 780 (2c), (3b) and (3c): 782 1. N labels from label stack include Flow Label or Entropy Label. 783 2. N labels from label stack does not include Flow Label or Entropy 784 Label. 786 Also in a scenario where there are multiple Entropy Labels present in 787 the label stack, it is possible for implementations to employ 788 deviating techniques: 790 o Search for entropy stops at the first Entropy Label. 791 o Search for entropy includes any Entropy Label found plus continues 792 to search for entropy in the label stack. 794 Furthermore, handling of reserved (i.e. special) labels varies among 795 implementations: 797 o Reserved labels are used in the hash as any other label would be 798 (a bad practice). 799 o Reserved labels are skipped over and, for implementations limited 800 to N labels, the reserved labels do not count towards the limit of 801 N. 802 o Reserved labels are skipped over and, for implementations limited 803 to N labels, the reserved labels count towards the limit of N. 805 It is important to point this out since presence of GAL will affect 806 those implementations which include reserved labels for load 807 balancing purpose. 809 As can be seen from above, there are many flavors of potential load 810 balancing implementations. Attempting for any OAM tools to support 811 ECMP discovery and traversal over all flavors of such will require 812 fairly complex procedures and implementations to support those 813 complex procedures. Complexities in OAM tools will produce minimal 814 benefits if majority of implementations are expected to employ small 815 subset of cases described above. 817 o Section 4.3 of [RFC6790] states that implementations, for load 818 balancing purpose, parsing beyond the label stack after finding 819 Entropy Label is "limited incremental value". Therefore, it is 820 expected that most implementations will be of types "IP Based Load 821 Balancer" or "Label Based Load Balancer". 823 o Section 2.4.5.1 of [RFC7325] recommends that search for entropies 824 from the label stack should terminate upon finding the first 825 Entropy Label. Therefore, it is expected that implementations 826 will only include the first (top-most) Entropy Label when there 827 are multiple Entropy Labels in the label stack. 829 o It is expected that, in most cases, number of labels in the label 830 stack will not exceed number of labels (N) which implementations 831 can include for load balancing purpose. 833 o It is expected that labels in the label stack, besides Flow Label 834 and Entropy Label, are constant for the lifetime of a single LSP 835 multipath traceroute operation. Therefore, deviating load 836 balancing implementations with respect to reserved labels should 837 not affect this tool. 839 Thus [RFC4379], [RFC6424] and this document will support cases (1) 840 and (2a1), where only the first (top-most) Entropy Label is included 841 when there are multiple Entropy Labels in the label stack. 843 11. Security Considerations 845 This document extends LSP Traceroute mechanism to discover and 846 exercise ECMP paths when LSP uses ELI/EL in label stack. Additional 847 processings are required for responder and initiator nodes. 848 Responder node that pushes ELI/EL will need to compute and return 849 multipath data including associated EL. Initiator node will need to 850 store and handle both IP multipath and label multipath information, 851 and include destination IP addresses and/or ELs in MPLS echo request 852 packet as well as in carried multipath information to downstream 853 nodes. Due to additional processing, it is critical that proper 854 security measures described in [RFC4379] and [RFC6424] are followed. 856 12. IANA Considerations 858 12.1. DS Flags 860 The IANA is requested to assign new bit numbers from the "DS flags" 861 sub-registry from the "Multi-Protocol Label Switching (MPLS) Label 862 Switched Paths (LSPs) Ping Parameters - TLVs" registry 863 ([IANA-MPLS-LSP-PING]). 865 Note: the "DS flags" sub-registry is created by [RFC7537]. 867 Bit number Name Reference 868 ---------- ---------------------------------------- --------- 869 TBD2 E: ELI/EL push indicator this document 870 TBD3 L: Label based load balance indicator this document 872 12.2. Multpath Type 874 The IANA is requested to assign a new value from the "Multipath Type" 875 sub-registry from the "Multi-Protocol Label Switching (MPLS) Label 876 Switched Paths (LSPs) Ping Parameters - TLVs" registry 877 ([IANA-MPLS-LSP-PING]). 879 Note: the "Multipath Type" sub-registry is created by [RFC7537]. 881 Value Meaning Reference 882 ---------- ---------------------------------------- --------- 883 TBD4 IP and label set this document 885 12.3. Entropy Label FEC 887 The IANA is requested to assign a new sub-TLV from the "Sub-TLVs for 888 TLV Types 1 and 16" section from the "Multi-Protocol Label Switching 889 (MPLS) Label Switched Paths (LSPs) Ping Parameters - TLVs" registry 890 ([IANA-MPLS-LSP-PING]). 892 Sub-Type Sub-TLV Name Reference 893 -------- ------------ --------- 894 TBD1 Entropy Label FEC this document 896 13. Acknowledgements 898 Authors would like to thank Loa Andersson, Curtis Villamizar, Daniel 899 King, Sriganesh Kini and Victor Ji for performing thorough review and 900 providing valuable comments. 902 14. Contributing Authors 904 Nagendra Kumar 905 Cisco Systems, Inc. 906 Email: naikumar@cisco.com 908 15. References 910 15.1. Normative References 912 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 913 Requirement Levels", BCP 14, RFC 2119, 914 DOI 10.17487/RFC2119, March 1997, 915 . 917 [RFC4379] Kompella, K. and G. Swallow, "Detecting Multi-Protocol 918 Label Switched (MPLS) Data Plane Failures", RFC 4379, 919 DOI 10.17487/RFC4379, February 2006, 920 . 922 [RFC6790] Kompella, K., Drake, J., Amante, S., Henderickx, W., and 923 L. Yong, "The Use of Entropy Labels in MPLS Forwarding", 924 RFC 6790, DOI 10.17487/RFC6790, November 2012, 925 . 927 [RFC7537] Decraene, B., Akiya, N., Pignataro, C., Andersson, L., and 928 S. Aldrin, "IANA Registries for LSP Ping Code Points", 929 RFC 7537, DOI 10.17487/RFC7537, May 2015, 930 . 932 15.2. Informative References 934 [I-D.ravisingh-mpls-el-for-seamless-mpls] 935 Singh, R., Shen, Y., and J. Drake, "Entropy label for 936 seamless MPLS", draft-ravisingh-mpls-el-for-seamless- 937 mpls-04 (work in progress), October 2014. 939 [IANA-MPLS-LSP-PING] 940 IANA, "Multi-Protocol Label Switching (MPLS) Label 941 Switched Paths (LSPs) Ping Parameters", 942 . 945 [RFC6391] Bryant, S., Ed., Filsfils, C., Drafz, U., Kompella, V., 946 Regan, J., and S. Amante, "Flow-Aware Transport of 947 Pseudowires over an MPLS Packet Switched Network", 948 RFC 6391, DOI 10.17487/RFC6391, November 2011, 949 . 951 [RFC6424] Bahadur, N., Kompella, K., and G. Swallow, "Mechanism for 952 Performing Label Switched Path Ping (LSP Ping) over MPLS 953 Tunnels", RFC 6424, DOI 10.17487/RFC6424, November 2011, 954 . 956 [RFC7325] Villamizar, C., Ed., Kompella, K., Amante, S., Malis, A., 957 and C. Pignataro, "MPLS Forwarding Compliance and 958 Performance Requirements", RFC 7325, DOI 10.17487/RFC7325, 959 August 2014, . 961 Authors' Addresses 963 Nobo Akiya 964 Big Switch Networks 966 Email: nobo.akiya.dev@gmail.com 968 George Swallow 969 Cisco Systems, Inc. 971 Email: swallow@cisco.com 973 Carlos Pignataro 974 Cisco Systems, Inc. 976 Email: cpignata@cisco.com 978 Andrew G. Malis 979 Huawei Technologies 981 Email: agmalis@gmail.com 983 Sam Aldrin 984 Google 986 Email: aldrin.ietf@gmail.com