idnits 2.17.1 draft-akiya-mpls-entropy-lsp-ping-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 (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 (November 22, 2014) is 3442 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 (-03) exists of draft-ietf-mpls-lsp-ping-registry-00 ** Obsolete normative reference: RFC 4379 (Obsoleted by RFC 8029) -- Obsolete informational reference (is this intentional?): RFC 6424 (Obsoleted by RFC 8029) Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 3 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 G. Swallow 4 Updates: 4379,6424,6790 (if approved) C. Pignataro 5 Intended status: Standards Track Cisco Systems 6 Expires: May 26, 2015 A. Malis 7 S. Aldrin 8 Huawei Technologies 9 November 22, 2014 11 Label Switched Path (LSP) and Pseudowire (PW) Ping/Trace over 12 MPLS Network using Entropy Labels (EL) 13 draft-akiya-mpls-entropy-lsp-ping-04 15 Abstract 17 The Multiprotocol Label Switching (MPLS) Label Switched Path (LSP) 18 Ping and Traceroute are used to exercise specific paths of Equal-Cost 19 Multipath (ECMP). When LSP is signaled to use Entropy Label (EL) 20 described in RFC6790, the ability for LSP Ping and Traceroute 21 operation to discover and exercise ECMP paths has been lost in 22 scenarios which LSRs apply deviating load balance techniques. One 23 such scenario is when some LSRs apply EL based load balancing while 24 other LSRs apply non-EL based load balancing (ex: IP). Another 25 scenario is when EL based LSP is stitched with another LSP which can 26 be EL based or non-EL based. 28 This document extends the MPLS LSP Ping and Traceroute mechanisms to 29 restore the ability of exercising specific paths of ECMP over LSP 30 which make use of Entropy Label. This document updates RFC4379, 31 RFC6424 and RFC6790. 33 Requirements Language 35 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 36 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 37 document are to be interpreted as described in RFC 2119 [RFC2119]. 39 Status of This Memo 41 This Internet-Draft is submitted in full conformance with the 42 provisions of BCP 78 and BCP 79. 44 Internet-Drafts are working documents of the Internet Engineering 45 Task Force (IETF). Note that other groups may also distribute 46 working documents as Internet-Drafts. The list of current Internet- 47 Drafts is at http://datatracker.ietf.org/drafts/current/. 49 Internet-Drafts are draft documents valid for a maximum of six months 50 and may be updated, replaced, or obsoleted by other documents at any 51 time. It is inappropriate to use Internet-Drafts as reference 52 material or to cite them other than as "work in progress." 54 This Internet-Draft will expire on May 26, 2015. 56 Copyright Notice 58 Copyright (c) 2014 IETF Trust and the persons identified as the 59 document authors. All rights reserved. 61 This document is subject to BCP 78 and the IETF Trust's Legal 62 Provisions Relating to IETF Documents 63 (http://trustee.ietf.org/license-info) in effect on the date of 64 publication of this document. Please review these documents 65 carefully, as they describe your rights and restrictions with respect 66 to this document. Code Components extracted from this document must 67 include Simplified BSD License text as described in Section 4.e of 68 the Trust Legal Provisions and are provided without warranty as 69 described in the Simplified BSD License. 71 Table of Contents 73 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 74 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 75 1.2. Prerequisite . . . . . . . . . . . . . . . . . . . . . . 4 76 1.3. Background . . . . . . . . . . . . . . . . . . . . . . . 4 77 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 5 78 3. Multipath Type 9 . . . . . . . . . . . . . . . . . . . . . . 7 79 4. Pseudowire Tracing . . . . . . . . . . . . . . . . . . . . . 7 80 5. Initiating LSR Procedures . . . . . . . . . . . . . . . . . . 8 81 6. Responder LSR Procedures . . . . . . . . . . . . . . . . . . 9 82 6.1. IP Based Load Balancer & Not Pushing ELI/EL . . . . . . . 9 83 6.2. IP Based Load Balancer & Pushes ELI/EL . . . . . . . . . 10 84 6.3. Label Based Load Balancer & Not Pushing ELI/EL . . . . . 11 85 6.4. Label Based Load Balancer & Pushes ELI/EL . . . . . . . . 11 86 6.5. Flow Aware MS-PW Stitching LSR . . . . . . . . . . . . . 12 87 7. Entropy Label FEC . . . . . . . . . . . . . . . . . . . . . . 13 88 8. DS Flags: L and E . . . . . . . . . . . . . . . . . . . . . . 13 89 9. New Multipath Information Type: TBD4 . . . . . . . . . . . . 14 90 10. Supported and Unsupported Cases . . . . . . . . . . . . . . . 16 91 11. Security Considerations . . . . . . . . . . . . . . . . . . . 18 92 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 93 12.1. DS Flags . . . . . . . . . . . . . . . . . . . . . . . . 18 94 12.2. Multpath Type . . . . . . . . . . . . . . . . . . . . . 18 95 12.3. Entropy Label FEC . . . . . . . . . . . . . . . . . . . 19 96 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 19 97 14. Contributing Authors . . . . . . . . . . . . . . . . . . . . 19 98 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 99 15.1. Normative References . . . . . . . . . . . . . . . . . . 19 100 15.2. Informative References . . . . . . . . . . . . . . . . . 20 101 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20 103 1. Introduction 105 1.1. Terminology 107 The following acronyms/terminologies are used in this document: 109 o MPLS - Multiprotocol Label Switching. 111 o LSP - Label Switched Path. 113 o LSR - Label Switching Router. 115 o FEC - Forwarding Equivalent Class. 117 o ECMP - Equal-Cost Multipath. 119 o EL - Entropy Label. 121 o ELI - Entropy Label Indicator. 123 o GAL - Generic Associated Channel Label. 125 o MS-PW - Multi-Segment Pseudowire. 127 o Initiating LSR - LSR which sends MPLS echo request. 129 o Responder LSR - LSR which receives MPLS echo request and sends 130 MPLS echo reply. 132 o IP Based Load Balancer - LSR which load balances on fields from IP 133 header (and possibly fields from upper layers), and does not 134 consider entropy label from label stack (i.e. Flow Label or 135 Entropy Label) for load balancing purpose. 137 o Label Based Load Balancer - LSR which load balances on entropy 138 label from label stack (i.e. Flow Label or Entropy Label), and 139 does not consider fields from IP header (and possibly fields from 140 upper layers) for load balancing purpose. 142 o Label and IP Based Load Balancer - LSR which load balances on both 143 labels from label stack (including Flow Label or Entropy Label if 144 present) and fields from IP header (and possibly fields from upper 145 layers). 147 1.2. Prerequisite 149 MPLS implementations employ wide variety of load balancing techniques 150 in terms of fields used for hash "keys". [RFC4379] and [RFC6424] are 151 designed to provide multipath support for subset of techniques. 152 Intent of this document is to restore multipath support for those 153 supported techniques which have been compromised by the introduction 154 of [RFC6790] (i.e. Entropy Labels). Section 10 describes supported 155 and unsupported cases, and it may be useful for one to visit this 156 section first. 158 1.3. Background 160 Section 3.3.1 of [RFC4379] specifies multipath information encoding 161 in Downstream Mapping TLV (Section 3.3 of [RFC4379]) and Downstream 162 Detailed Mapping TLV (Section 3.3 of [RFC6424]) which can be used by 163 LSP Ping initiator to trace and validate all ECMP paths between 164 ingress and egress. These encodings are sufficient when all the LSRs 165 along the path(s), between ingress and egress, consider same set of 166 "keys" as input for load balancing algorithm: all IP based or all 167 label based. 169 With introduction of [RFC6790], it is quite normal to see set of LSRs 170 performing load balancing based on EL/ELI while others still follow 171 the traditional way (IP based). This results in LSP Ping initiator 172 not be able to trace and validate all ECMP paths in following 173 scenarios: 175 o One or more transit LSRs along LSP with ELI/EL in label stack do 176 not perform ECMP load balancing based on EL (hashes based on 177 "keys" including IP destination address). This scenario is not 178 only possible but quite common due transit LSRs not implementing 179 [RFC6790] or transit LSRs implementing [RFC6790] but not 180 implementing suggested transit LSR behavior in Section 4.3 of 181 [RFC6790]. 183 o Two or more LSPs stitched together with at least one of these LSP 184 pushing ELI/EL in label stack. Such scenarios are described in 185 [I-D.ravisingh-mpls-el-for-seamless-mpls]. 187 These scenarios will be quite common because every deployment of 188 [RFC6790] will invariably end up with nodes that support ELI/EL and 189 nodes that do not. There will typically be areas that support ELI/EL 190 and areas that do not. 192 As pointed out in [RFC6790] the procedures of [RFC4379] with respect 193 to multipath information type {9} are incomplete. However [RFC6790] 194 does not actually update [RFC4379]. Further the specific EL location 195 is not clearly defined, particularly in the case of Flow Aware 196 Pseudowires [RFC6391]. This document defines a new FEC Stack sub-TLV 197 for the Entropy Label. Section 3 of this document updates the 198 procedures for multipath information type {9} described in [RFC4379]. 199 Rest of this document describes extensions required to restore ECMP 200 discovery and tracing capabilities for scenarios described. 202 2. Overview 204 [RFC4379] describes LSP traceroute as an operation where the 205 initiating LSR send a series of MPLS echo requests towards the same 206 destination. The first packet in the series have the TTL set to 1. 207 When the echo reply is received from the LSR one hop away the second 208 echo request in the series is sent with the TTL set to 2, for each 209 echo request the TLL is incremented by one until a response is 210 received from the intended destination. Initiating LSR discovers and 211 exercises ECMP by obtaining multipath information from each transit 212 LSR and using specific destination IP address or specific entropy 213 label. 215 Notion of {x, y, z} from here on refers to Multipath information 216 types x, y or z. 218 LSP Ping initiating LSR sends MPLS echo request with multipath 219 information. This multipath information is described in DSMAP/DDMAP 220 TLV of echo request, and may contain set of IP addresses or set of 221 labels. Multipath information types {2, 4, 8} carry set of IP 222 addresses and multipath information type {9} carries set of labels. 223 Responder LSR (receiver of MPLS echo request) will determine the 224 subset of initiator specified multipath information which load 225 balances to each downstream (outgoing interface). Responder LSR 226 sends MPLS echo reply with resulting multipath information per 227 downstream (outgoing interface) back to the initiating LSR. 228 Initiating LSR is then able to use specific IP destination address or 229 specific label to exercise specific ECMP path on the responder LSR. 231 Current behavior is problematic in following scenarios: 233 o Initiating LSR sends IP multipath information, but responder LSR 234 load balances on labels. 236 o Initiating LSR sends label multipath information, but responder 237 LSR load balances on IP addresses. 239 o Initiating LSR sends existing multipath information to LSR which 240 pushes ELI/EL in label stack, but the initiating LSR can only 241 continue to discover and exercise specific path of ECMP, if the 242 LSR which pushes ELI/EL responds with both IP addresses and 243 associated EL corresponding to each IP address. This is because: 245 * ELI/EL pushing LSR that is a stitching point will load balance 246 based on IP address. 248 * Downstream LSR(s) of ELI/EL pushing LSR may load balance based 249 on ELs. 251 o Initiating LSR sends one of existing multipath information to ELI/ 252 EL pushing LSR, but initiating LSR can only continue to discover 253 and exercise specific path of ECMP if ELI/EL pushing LSR responds 254 with both labels and associated EL corresponding to label. This 255 is because: 257 * ELI/EL pushing LSR that is a stitching point will load balance 258 based on EL from previous LSP and pushes new EL. 260 * Downstream LSR(s) of ELI/EL pushing LSR may load balance based 261 on new ELs. 263 The above scenarios point to how the existing multipath information 264 is insufficient when LSP traceroute is operated on an LSP with 265 Entropy Labels described by [RFC6790]. Therefore, this document 266 defines a multipath information type to be used in the DSMAP/DDMAP of 267 MPLS echo request/reply packets in Section 9. 269 In addition, responder LSR can reply with empty multipath information 270 if no IP address set or label set from received multipath information 271 matched load balancing to a downstream. Empty return is also 272 possible if initiating LSR sends multipath information of one type, 273 IP address or label, but responder LSR load balances on the other 274 type. To disambiguate between the two results, this document 275 introduces new flags in the DSMAP/DDMAP TLV to allow responder LSR to 276 describe the load balance technique being used. 278 It is required that all LSRs along the LSP understand new flags as 279 well as new multipath information type. It is also required that 280 initiating LSR can select both IP destination address and label to 281 use on transmitting MPLS echo request packets. Two additional DS 282 Flags are defined for the DSMAP and DDMAP TLVs in Section 8. These 283 two flags are used by the responder LSR to describe its load balance 284 behavior on received MPLS echo request. 286 Note that the terms "IP Based Load Balancer", "Label Based Load 287 Balancer" and "Label Based Load Balancer" are in context of how 288 received MPLS echo request is handled by the responder LSR. 290 3. Multipath Type 9 292 This section defines to which labels multipath type {9} applies. 294 [RFC4379] defined multipath type {9} for tracing of LSPs where label 295 based load-balancing is used. However, as pointed out in [RFC6790], 296 the procedures for using this type are incomplete as the specific 297 location of the label was not defined. It was assumed that the 298 presence of multipath type {9} implied the value of the bottom-of- 299 stack label should be varied by the values indicated by multipath to 300 determine their respective out-going interfaces. 302 Section 7 defines a new FEC-Stack sub-TLV to indicate an entropy 303 label. These labels may appear anywhere in a label stack. 305 Multipath type {9} applies to the first label in the label-stack that 306 corresponds to an EL-FEC. If no such label is found, it applies to 307 the label at the bottom of the label stack. 309 4. Pseudowire Tracing 311 This section defines procedures for tracing pseudowires. These 312 procedures pertain to the use of multipath information type {9} as 313 well as type {TBD4}. In all cases below, when a control word is in 314 use the N-flag in the DDMAP or DSMAP MUST be set. Note that when a 315 control word is not in use the returned DDMAPs or DSMAPs may not be 316 accurate. 318 In order to trace a non Flow-Aware Pseudowire the initiator includes 319 an EL-FEC instead of the appropriate PW-FEC at the bottom of the FEC- 320 Stack. Tracing in this way will cause compliant routers to return 321 the proper outgoing interface. Note that this procedure only traces 322 to the end of the MPLS LSP that is under test and will not verify the 323 PW FEC. To actually verify the PW-FEC or in the case of a MS-PW, to 324 determine the next pseudowire label value, the initiator MUST repeat 325 that step of the trace, (i.e., repeating the TTL value used) but with 326 the FEC-Stack modified to contain the appropriate PW-FEC. Note that 327 these procedures are applicable to scenarios which an initiator is 328 able to vary the bottom label (i.e. pseudowire label). Possible 329 scenarios are tracing multiple non Flow-Aware Pseudowires on the same 330 endpoints or tracing a non Flow-Aware Pseudowire provisioned with 331 multiple pseudowire labels. 333 In order to trace a Flow Aware Pseudowire, the initiator includes an 334 EL-FEC at the bottom of the FEC-Stack and pushes the appropriate PW- 335 FEC onto the FEC-Stack. 337 In order to trace through non-compliant routers the initiator forms 338 an MPLS echo request message and includes a DDMAP or DSMAP with 339 multipath type {9}. For a non Flow-Aware Pseudowire it includes the 340 appropriate PW-FEC in the FEC-Stack. For a Flow Aware Pseudowire, 341 the initiator includes a NIL-FEC at the bottom of the FEC-Stack and 342 pushes the appropriate PW-FEC onto the FEC-Stack. 344 5. Initiating LSR Procedures 346 In order to facilitate the flow of the following text we speak in 347 terms of a boolean called EL_LSP maintained by the initiating LSR. 348 This value controls the multipath information type to be used in 349 transmitted echo request packets. When the initiating LSR is 350 transmitting an echo request packet with DSMAP/DDMAP with a non-zero 351 multipath information type, then EL_LSP boolean MUST be consulted to 352 determine the multipath information type to use. 354 In addition to procedures described in [RFC4379] as updated by 355 Section 3 and [RFC6424], initiating LSR MUST operate with following 356 procedures. 358 o When the initiating LSR pushes ELI/EL, initialize EL_LSP=True. 359 Else set EL_LSP=False. 361 o When the initiating LSR is transmitting non-zero multipath 362 information type: 364 * If (EL_LSP), the initiating LSR MUST use multipath information 365 type {TBD4} unless same responder LSR cannot handle type 366 {TBD4}. 368 * Else the initiating LSR MAY use multipath information type {2, 369 4, 8, 9}. 371 o When the initiating LSR is transmitting multipath information type 372 {TBD4}, both "IP Multipath Information" and "Label Multipath 373 Information" MUST be included, and "IP Associated Label Multipath 374 Information" MUST be omitted (NULL). 376 o When the initiating LSR receives echo reply with {L=0, E=1} in DS 377 flags with valid contents, set EL_LSP=True. 379 In following conditions, the initiating LSR may have lost the ability 380 to exercise specific ECMP paths. The initiating LSR MAY continue 381 with "best effort". 383 o Received echo reply contains empty multipath information. 385 o Received echo reply contains {L=0, E=} DS flags, but does not 386 contain IP multipath information. 388 o Received echo reply contains {L=1, E=} DS flags, but does not 389 contain label multipath information. 391 o Received echo reply contains {L=, E=1} DS flags, but does not 392 contain associated label multipath information. 394 o IP multipath information types {2, 4, 8} sent, and received echo 395 reply with {L=1, E=0} in DS flags. 397 o Multipath information type {TBD4} sent, and received echo reply 398 with multipath information type other than {TBD4}. 400 6. Responder LSR Procedures 402 Common Procedures: The responder LSR receiving an MPLS echo request 403 packet with multipath information type {TBD4} MUST validate following 404 contents. Any deviation MUST result in the responder LSR to consider 405 the packet as malformed and return code 1 (Malformed echo request 406 received) in the MPLS echo reply packet. 408 o IP multipath information MUST be included. 410 o Label multipath information MUST be included. 412 o IP associated label multipath information MUST be omitted (NULL). 414 Following subsections describe expected responder LSR procedures when 415 echo reply is to include DSMAP/DDMAP TLVs, based on local load 416 balance technique being employed. In case the responder LSR performs 417 deviating load balance techniques per downstream basis, appropriate 418 procedures matching to each downstream load balance technique MUST be 419 operated. 421 6.1. IP Based Load Balancer & Not Pushing ELI/EL 423 o The responder MUST set {L=0, E=0} in DS flags. 425 o If multipath information type {2, 4, 8} is received, the responder 426 MUST comply with [RFC4379] and [RFC6424]. 428 o If multipath information type {9} is received, the responder MUST 429 reply with multipath type {0}. 431 o If multipath information type {TBD4} is received, following 432 procedures are to be used: 434 * The responder MUST reply with multipath information type 435 {TBD4}. 437 * "Label Multipath Information" and "Associated Label Multipath 438 Information" sections MUST be omitted (NULL). 440 * If no matching IP address is found, then "IPMultipathType" 441 field MUST be set to multipath information type {0} and "IP 442 Multipath Information" section MUST also be omitted (NULL). 444 * If at least one matching IP address is found, then 445 "IPMultipathType" field MUST be set to appropriate multipath 446 information type {2, 4, 8} and "IP Multipath Information" 447 section MUST be included. 449 6.2. IP Based Load Balancer & Pushes ELI/EL 451 o The responder MUST set {L=0, E=1} in DS flags. 453 o If multipath information type {9} is received, the responder MUST 454 reply with multipath type {0}. 456 o If multipath type {2, 4, 8, TBD4} is received, following 457 procedures are to be used: 459 * The responder MUST respond with multipath type {TBD4}. See 460 Section 9 for details of multipath type {TBD4}. 462 * "Label Multipath Information" section MUST be omitted (i.e. is 463 it not there). 465 * IP address set specified in received IP multipath information 466 MUST be used to determine the returning IP/Label pairs. 468 * If received multipath information type was {TBD4}, received 469 "Label Multipath Information" sections MUST NOT be used to 470 determine the associated label portion of returning IP/Label 471 pairs. 473 * If no matching IP address is found, then "IPMultipathType" 474 field MUST be set to multipath information type {0} and "IP 475 Multipath Information" section MUST be omitted. In addition, 476 "Assoc Label Multipath Length" MUST be set to 0, and 477 "Associated Label Multipath Information" section MUST also be 478 omitted. 480 * If at least one matching IP address is found, then 481 "IPMultipathType" field MUST be set to appropriate multipath 482 information type {2, 4, 8} and "IP Multipath Information" 483 section MUST be included. In addition, "Associated Label 484 Multipath Information" section MUST be populated with list of 485 labels corresponding to each IP address specified in "IP 486 Multipath Information" section. "Assoc Label Multipath Length" 487 MUST be set to a value representing length in octets of 488 "Associated Label Multipath Information" field. 490 6.3. Label Based Load Balancer & Not Pushing ELI/EL 492 o The responder MUST set {L=1, E=0} in DS flags. 494 o If multipath information type {2, 4, 8} is received, the responder 495 MUST reply with multipath type {0}. 497 o If multipath information type {9} is received, the responder MUST 498 comply with [RFC4379] and [RFC6424] as updated by Section 3. 500 o If multipath information type {TBD4} is received, following 501 procedures are to be used: 503 * The responder MUST reply with multipath information type 504 {TBD4}. 506 * "IP Multipath Information" and "Associated Label Multipath 507 Information" sections MUST be omitted (NULL). 509 * If no matching label is found, then "LbMultipathType" field 510 MUST be set to multipath information type {0} and "Label 511 Multipath Information" section MUST also be omitted (NULL). 513 * If at least one matching label is found, then "LbMultipathType" 514 field MUST be set to appropriate multipath information type {9} 515 and "Label Multipath Information" section MUST be included. 517 6.4. Label Based Load Balancer & Pushes ELI/EL 519 o The responder MUST set {L=1, E=1} in DS flags. 521 o If multipath information type {2, 4, 8} is received, the responder 522 MUST reply with multipath type {0}. 524 o If multipath type {9, TBD4} is received, following procedures are 525 to be used: 527 * The responder MUST respond with multipath type {TBD4}. 529 * "IP Multipath Information" section MUST be omitted. 531 * Label set specified in received label multipath information 532 MUST be used to determine the returning Label/Label pairs. 534 * If received multipath information type was {TBD4}, received 535 "Label Multipath Information" sections MUST NOT be used to 536 determine the associated label portion of returning Label/Label 537 pairs. 539 * If no matching label is found, then "LbMultipathType" field 540 MUST be set to multipath information type {0} and "Label 541 Multipath Information" section MUST be omitted. In addition, 542 "Assoc Label Multipath Length" MUST be set to 0, and 543 "Associated Label Multipath Information" section MUST also be 544 omitted. 546 * If at least one matching label is found, then "LbMultipathType" 547 field MUST be set to appropriate multipath information type {9} 548 and "Label Multipath Information" section MUST be included. In 549 addition, "Associated Label Multipath Information" section MUST 550 be populated with list of labels corresponding to each label 551 specified in "Label Multipath Information" section. "Assoc 552 Label Multipath Length" MUST be set to a value representing 553 length in octets of "Associated Label Multipath Information" 554 field. 556 6.5. Flow Aware MS-PW Stitching LSR 558 Stitching LSR that cross-connects Flow Aware Pseudowires behave in 559 one of two ways: 561 o Load balances on previous Flow Label, and carries over same Flow 562 Label. For this case, stitching LSR is to behave as procedures 563 described in Section 6.3. 565 o Load balances on previous Flow Label, and replaces Flow Label with 566 newly computed. For this case, stitching LSR is to behave as 567 procedures described in Section 6.4. 569 7. Entropy Label FEC 571 Entropy Label Indicator (ELI) is a reserved label that has no 572 explicit FEC associated, and has label value 7 assigned from the 573 reserved range. Use Nil FEC as Target FEC Stack sub-TLV to account 574 for ELI in a Target FEC Stack TLV. 576 Entropy Label (EL) is a special purpose label with label value being 577 discretionary (i.e. label value may not be from the reserved range). 578 For LSP verification mechanics to perform its purpose, it is 579 necessary for a Target FEC Stack sub-TLV to clearly describe EL, 580 particularly in the scenario where label stack does not carry ELI 581 (ex: Flow Aware Pseudowire [RFC6391]). Therefore, this document 582 defines a EL FEC to allow a Target FEC Stack sub-TLV to be added to 583 the Target FEC Stack to account for EL. 585 The Length is 4. Labels are 20-bit values treated as numbers. 587 0 1 2 3 588 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 589 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 590 | Label | MBZ | 591 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 593 Figure 1: Entropy Label FEC 595 Label is the actual label value inserted in the label stack; the MBZ 596 fields MUST be zero when sent and ignored on receipt. 598 8. DS Flags: L and E 600 Two flags, L and E, are added in DS Flags field of the DSMAP/DDMAP 601 TLVs. Both flags MUST NOT be set in echo request packets when 602 sending, and ignored when received. Zero, one or both new flags MUST 603 be set in echo reply packets. 605 DS Flags 606 -------- 608 0 1 2 3 4 5 6 7 609 +-+-+-+-+-+-+-+-+ 610 | MBZ |L|E|I|N| 611 +-+-+-+-+-+-+-+-+ 613 RFC-Editor-Note: Please update above figure to place the flag E in 614 the bit number TBD2 and the flag L in the bit number TBD3. 616 Flag Name and Meaning 617 ---- ---------------- 618 L Label based load balance indicator 619 This flag MUST be set to zero in the echo request. LSR 620 which performs load balancing on a label MUST set this 621 flag in the echo reply. LSR which performs load 622 balancing on IP MUST NOT set this flag in the echo 623 reply. 625 E ELI/EL push indicator 626 This flag MUST be set to zero in the echo request. LSR 627 which pushes ELI/EL MUST set this flag in the echo 628 reply. LSR which does not push ELI/EL MUST NOT set 629 this flag in the echo reply. 631 Two flags result in four load balancing techniques which echo reply 632 generating LSR can indicate: 634 o {L=0, E=0} LSR load balances based on IP and does not push ELI/EL. 636 o {L=0, E=1} LSR load balances based on IP and pushes ELI/EL. 638 o {L=1, E=0} LSR load balances based on label and does not push ELI/ 639 EL. 641 o {L=1, E=1} LSR load balances based on label and pushes ELI/EL. 643 9. New Multipath Information Type: TBD4 645 One new multipath information type is added to be used in DSMAP/DDMAP 646 TLVs. New multipath type has value of TBD4. 648 Key Type Multipath Information 649 --- ---------------- --------------------- 650 TBD4 IP and label set IP addresses and label prefixes 652 Multipath type TBD4 is comprised of three sections. One section to 653 describe IP address set. One section to describe label set. One 654 section to describe another label set which associates to either IP 655 address set or label set specified in the other section. 657 Multipath information type TBD4 has following format: 659 0 1 2 3 660 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 661 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 662 |IPMultipathType| Reserved(MBZ) | IP Multipath Length | 663 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 664 ~ ~ 665 | (IP Multipath Information) | 666 ~ ~ 667 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 668 |LbMultipathType| Reserved(MBZ) | Label Multipath Length | 669 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 670 ~ ~ 671 | (Label Multipath Information) | 672 ~ ~ 673 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 674 | Reserved(MBZ) | Assoc Label Multipath Length | 675 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 676 ~ ~ 677 | (Associated Label Multipath Information) | 678 ~ ~ 679 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 681 Figure 2: Multipath Information Type TBD4 683 o IPMultipathType 685 * 0 when "IP Multipath Information" is omitted. Otherwise one of 686 IP multipath information values: {2, 4, 8}. 688 o IP Multipath Information 690 * This section is omitted when "IPMultipathType" is 0. Otherwise 691 this section reuses IP multipath information from [RFC4379]. 692 Specifically, multipath information for values {2, 4, 8} can be 693 used. 695 o LbMultipathType 697 * 0 when "Label Multipath Information" is omitted. Otherwise 698 label multipath information value {9}. 700 o Label Multipath Information 702 * This section is omitted when "LbMultipathType" is 0. Otherwise 703 this section reuses label multipath information from [RFC4379]. 704 Specifically, multipath information for value {9} can be used. 706 o Associated Label Multipath Information 707 * "Assoc Label Multipath Length" is a 16 bit field of multipath 708 information which indicates length in octets of the associated 709 label multipath information. 711 * "Associated Label Multipath Information" is a list of labels 712 with each label described in 24 bits. This section MUST be 713 omitted in an MPLS echo request message. A midpoint which 714 pushes ELI/EL labels SHOULD include "Assoc Label Multipath 715 Information" in its MPLS echo reply message, along with either 716 "IP Multipath Information" or "Label Multipath Information". 717 Each specified associated label described in this section maps 718 to specific IP address OR label described in the "IP Multipath 719 Information" section or "Label Multipath Information" section. 720 For example, if 3 IP addresses are specified in the "IP 721 Multipath Information" section, then there MUST be 3 labels 722 described in this section. First label maps to the lowest IP 723 address specified, second label maps to the second lowest IP 724 address specified and third label maps to the third lowest IP 725 address specified. 727 10. Supported and Unsupported Cases 729 MPLS architecture never defined strict rules on how implementations 730 are to identify hash "keys" for load balancing purpose. As result, 731 implementations may be of following load balancer types: 733 1. IP Based Load Balancer. 734 2. Label Based Load Balancer. 735 3. Label and IP Based Load Balancer. 737 For cases (2) and (3), implementation can include different sets of 738 labels from the label stack for load balancing purpose. Thus 739 following sub-cases are possible: 741 a. Entire label stack. 742 b. Top N labels from label stack where number of labels in label 743 stack is >N. 744 c. Bottom N labels from label stack where number of labels in label 745 stack is >N. 747 In a scenario where there is one Flow Label or Entropy Label present 748 in the label stack, following further cases are possible for (2b), 749 (2c), (3b) and (3c): 751 1. N labels from label stack include Flow Label or Entropy Label. 752 2. N labels from label stack does not include Flow Label or Entropy 753 Label. 755 Also in a scenario where there are multiple Entropy Labels present in 756 the label stack, it is possible for implementations to employ 757 deviating techniques: 759 o Search for entropy stops at the first Entropy Label. 760 o Search for entropy includes any Entropy Label found plus continues 761 to search for entropy in the label stack. 763 Furthermore, handling of reserved (i.e. special) labels varies among 764 implementations: 766 o Reserved labels are used in the hash as any other label would be 767 (a bad practice). 768 o Reserved labels are skipped over and, for implementations limited 769 to N labels, the reserved labels do not count towards the limit of 770 N. 771 o Reserved labels are skipped over and, for implementations limited 772 to N labels, the reserved labels count towards the limit of N. 774 It is important to point this out since presence of GAL will affect 775 those implementations which include reserved labels for load 776 balancing purpose. 778 As can be seen from above, there are many flavors of potential load 779 balancing implementations. Attempting for any OAM tools to support 780 ECMP discovery and traversal over all flavors of such will require 781 fairly complex procedures and implementations to support those 782 complex procedures. Complexities in OAM tools will produce minimal 783 benefits if majority of implementations are expected to employ small 784 subset of cases described above. 786 o Section 4.3 of [RFC6790] states that implementations, for load 787 balancing purpose, parsing beyond the label stack after finding 788 Entropy Label is "limited incremental value". Therefore, it is 789 expected that most implementations will be of types "IP Based Load 790 Balancer" or "Label Based Load Balancer". 792 o Section 2.4.5.1 of [I-D.ietf-mpls-forwarding] recommends that 793 search for entropies from the label stack should terminate upon 794 finding the first Entropy Label. Therefore, it is expected that 795 implementations will only include the first (top-most) Entropy 796 Label when there are multiple Entropy Labels in the label stack. 798 o It is expected that, in most cases, number of labels in the label 799 stack will not exceed number of labels (N) which implementations 800 can include for load balancing purpose. 802 o It is expected that labels in the label stack, besides Flow Label 803 and Entropy Label, are constant for the lifetime of a single LSP 804 multipath traceroute operation. Therefore, deviating load 805 balancing implementations with respect to reserved labels should 806 not affect this tool. 808 Thus [RFC4379], [RFC6424] and this document will support cases (1) 809 and (2a1), where only the first (top-most) Entropy Label is included 810 when there are multiple Entropy Labels in the label stack. 812 11. Security Considerations 814 This document extends LSP Traceroute mechanism to discover and 815 exercise ECMP paths when LSP uses ELI/EL in label stack. Additional 816 processings are required for responder and initiator nodes. 817 Responder node that pushes ELI/EL will need to compute and return 818 multipath data including associated EL. Initiator node will need to 819 store and handle both IP multipath and label multipath information, 820 and include destination IP addresses and/or ELs in MPLS echo request 821 packet as well as in carried multipath information to downstream 822 nodes. Due to additional processing, it is critical that proper 823 security measures described in [RFC4379] and [RFC6424] are followed. 825 12. IANA Considerations 827 12.1. DS Flags 829 The IANA is requested to assign new bit numbers from the "DS flags" 830 sub-registry from the "Multi-Protocol Label Switching (MPLS) Label 831 Switched Paths (LSPs) Ping Parameters - TLVs" registry 832 ([IANA-MPLS-LSP-PING]). 834 Note: the "DS flags" sub-registry is created by 835 [I-D.ietf-mpls-lsp-ping-registry]. 837 Bit number Name Reference 838 ---------- ---------------------------------------- --------- 839 TBD2 E: ELI/EL push indicator this document 840 TBD3 L: Label based load balance indicator this document 842 12.2. Multpath Type 844 The IANA is requested to assign a new value from the "Multipath Type" 845 sub-registry from the "Multi-Protocol Label Switching (MPLS) Label 846 Switched Paths (LSPs) Ping Parameters - TLVs" registry 847 ([IANA-MPLS-LSP-PING]). 849 Note: the "Multipath Type" sub-registry is created by 850 [I-D.ietf-mpls-lsp-ping-registry]. 852 Value Meaning Reference 853 ---------- ---------------------------------------- --------- 854 TBD4 IP and label set this document 856 12.3. Entropy Label FEC 858 The IANA is requested to assign a new sub-TLV from the "Sub-TLVs for 859 TLV Types 1 and 16" section from the "Multi-Protocol Label Switching 860 (MPLS) Label Switched Paths (LSPs) Ping Parameters - TLVs" registry 861 ([IANA-MPLS-LSP-PING]). 863 Sub-Type Sub-TLV Name Reference 864 -------- ------------ --------- 865 TBD1 Entropy Label FEC this document 867 13. Acknowledgements 869 Authors would like to thank Loa Andersson, Curtis Villamizar, Daniel 870 King and Sriganesh Kini for performing thorough review and providing 871 valuable comments. 873 14. Contributing Authors 875 Nagendra Kumar 876 Cisco Systems 877 Email: naikumar@cisco.com 879 15. References 881 15.1. Normative References 883 [I-D.ietf-mpls-lsp-ping-registry] 884 Decraene, B., Akiya, N., Pignataro, C., Andersson, L., and 885 S. Aldrin, "IANA registries for LSP ping Code Points", 886 draft-ietf-mpls-lsp-ping-registry-00 (work in progress), 887 November 2014. 889 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 890 Requirement Levels", BCP 14, RFC 2119, March 1997. 892 [RFC4379] Kompella, K. and G. Swallow, "Detecting Multi-Protocol 893 Label Switched (MPLS) Data Plane Failures", RFC 4379, 894 February 2006. 896 [RFC6790] Kompella, K., Drake, J., Amante, S., Henderickx, W., and 897 L. Yong, "The Use of Entropy Labels in MPLS Forwarding", 898 RFC 6790, November 2012. 900 15.2. Informative References 902 [I-D.ietf-mpls-forwarding] 903 Villamizar, C., Kompella, K., Amante, S., Malis, A., and 904 C. Pignataro, "MPLS Forwarding Compliance and Performance 905 Requirements", draft-ietf-mpls-forwarding-09 (work in 906 progress), March 2014. 908 [I-D.ravisingh-mpls-el-for-seamless-mpls] 909 Singh, R., Shen, Y., and J. Drake, "Entropy label for 910 seamless MPLS", draft-ravisingh-mpls-el-for-seamless- 911 mpls-04 (work in progress), October 2014. 913 [IANA-MPLS-LSP-PING] 914 IANA, "Multi-Protocol Label Switching (MPLS) Label 915 Switched Paths (LSPs) Ping Parameters", 916 . 919 [RFC6391] Bryant, S., Filsfils, C., Drafz, U., Kompella, V., Regan, 920 J., and S. Amante, "Flow-Aware Transport of Pseudowires 921 over an MPLS Packet Switched Network", RFC 6391, November 922 2011. 924 [RFC6424] Bahadur, N., Kompella, K., and G. Swallow, "Mechanism for 925 Performing Label Switched Path Ping (LSP Ping) over MPLS 926 Tunnels", RFC 6424, November 2011. 928 Authors' Addresses 930 Nobo Akiya 931 Cisco Systems 933 Email: nobo@cisco.com 935 George Swallow 936 Cisco Systems 938 Email: swallow@cisco.com 939 Carlos Pignataro 940 Cisco Systems 942 Email: cpignata@cisco.com 944 Andrew G. Malis 945 Huawei Technologies 947 Email: agmalis@gmail.com 949 Sam Aldrin 950 Huawei Technologies 952 Email: aldrin.ietf@gmail.com