idnits 2.17.1 draft-akiya-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 : ---------------------------------------------------------------------------- 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 (July 4, 2014) is 3585 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) == Outdated reference: A later version (-04) exists of draft-ravisingh-mpls-el-for-seamless-mpls-01 -- Obsolete informational reference (is this intentional?): RFC 5226 (Obsoleted by RFC 8126) -- Obsolete informational reference (is this intentional?): RFC 6424 (Obsoleted by RFC 8029) Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 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 G. Swallow 4 Updates: 4379,6424,6790 (if approved) C. Pignataro 5 Intended status: Standards Track Cisco Systems 6 Expires: January 5, 2015 A. Malis 7 S. Aldrin 8 Huawei Technologies 9 July 4, 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-02 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 January 5, 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 . . . . . . . . . . . . . . . . . . . . . . 12 88 8. DS Flags: L and E . . . . . . . . . . . . . . . . . . . . . . 13 89 9. New Multipath Information Type: 10 . . . . . . . . . . . . . 14 90 10. Supported and Unsupported Cases . . . . . . . . . . . . . . . 16 91 11. Security Considerations . . . . . . . . . . . . . . . . . . . 18 92 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 93 12.1. New Sub-Registries . . . . . . . . . . . . . . . . . . . 18 94 12.1.1. DS Flags . . . . . . . . . . . . . . . . . . . . . . 18 95 12.1.2. Multipath Type . . . . . . . . . . . . . . . . . . . 19 96 12.2. Entropy Label FEC . . . . . . . . . . . . . . . . . . . 19 98 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 20 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 {10}. In all cases below, when a control word is in use 316 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 {10} unless same responder LSR cannot handle type {10}. 369 * Else the initiating LSR MAY use multipath information type {2, 370 4, 8, 9}. 372 o When the initiating LSR is transmitting multipath information type 373 {10}, both "IP Multipath Information" and "Label Multipath 374 Information" MUST be included, and "IP Associated Label Multipath 375 Information" MUST be omitted (NULL). 377 o When the initiating LSR receives echo reply with {L=0, E=1} in DS 378 flags with valid contents, set EL_LSP=True. 380 In following conditions, the initiating LSR may have lost the ability 381 to exercise specific ECMP paths. The initiating LSR MAY continue 382 with "best effort". 384 o Received echo reply contains empty multipath information. 386 o Received echo reply contains {L=0, E=} DS flags, but does not 387 contain IP multipath information. 389 o Received echo reply contains {L=1, E=} DS flags, but does not 390 contain label multipath information. 392 o Received echo reply contains {L=, E=1} DS flags, but does not 393 contain associated label multipath information. 395 o IP multipath information types {2, 4, 8} sent, and received echo 396 reply with {L=1, E=0} in DS flags. 398 o Multipath information type {10} sent, and received echo reply with 399 multipath information type other than {10}. 401 6. Responder LSR Procedures 403 Common Procedures: The responder LSR receiving an MPLS echo request 404 packet with multipath information type {10} MUST validate following 405 contents. Any deviation MUST result in the responder LSR to consider 406 the packet as malformed and return code 1 (Malformed echo request 407 received) in the MPLS echo reply packet. 409 o IP multipath information MUST be included. 411 o Label multipath information MUST be included. 413 o IP associated label multipath information MUST be omitted (NULL). 415 Following subsections describe expected responder LSR procedures when 416 echo reply is to include DSMAP/DDMAP TLVs, based on local load 417 balance technique being employed. In case the responder LSR performs 418 deviating load balance techniques per downstream basis, appropriate 419 procedures matching to each downstream load balance technique MUST be 420 operated. 422 6.1. IP Based Load Balancer & Not Pushing ELI/EL 424 o The responder MUST set {L=0, E=0} in DS flags. 426 o If multipath information type {2, 4, 8} is received, the responder 427 MUST comply with [RFC4379] and [RFC6424]. 429 o If multipath information type {9} is received, the responder MUST 430 reply with multipath type {0}. 432 o If multipath information type {10} is received, following 433 procedures are to be used: 435 * The responder MUST reply with multipath information type {10}. 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, 10} is received, following procedures 457 are to be used: 459 * The responder MUST respond with multipath type {10}. See 460 Section 9 for details of multipath type {10}. 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 {10}, 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 {10} is received, following 501 procedures are to be used: 503 * The responder MUST reply with multipath information type {10}. 505 * "IP Multipath Information" and "Associated Label Multipath 506 Information" sections MUST be omitted (NULL). 508 * If no matching label is found, then "LbMultipathType" field 509 MUST be set to multipath information type {0} and "Label 510 Multipath Information" section MUST also be omitted (NULL). 512 * If at least one matching label is found, then "LbMultipathType" 513 field MUST be set to appropriate multipath information type {9} 514 and "Label Multipath Information" section MUST be included. 516 6.4. Label Based Load Balancer & Pushes ELI/EL 518 o The responder MUST set {L=1, E=1} in DS flags. 520 o If multipath information type {2, 4, 8} is received, the responder 521 MUST reply with multipath type {0}. 523 o If multipath type {9, 10} is received, following procedures are to 524 be used: 526 * The responder MUST respond with multipath type {10}. 528 * "IP Multipath Information" section MUST be omitted. 530 * Label set specified in received label multipath information 531 MUST be used to determine the returning Label/Label pairs. 533 * If received multipath information type was {10}, received 534 "Label Multipath Information" sections MUST NOT be used to 535 determine the associated label portion of returning Label/Label 536 pairs. 538 * If no matching label is found, then "LbMultipathType" field 539 MUST be set to multipath information type {0} and "Label 540 Multipath Information" section MUST be omitted. In addition, 541 "Assoc Label Multipath Length" MUST be set to 0, and 542 "Associated Label Multipath Information" section MUST also be 543 omitted. 545 * If at least one matching label is found, then "LbMultipathType" 546 field MUST be set to appropriate multipath information type {9} 547 and "Label Multipath Information" section MUST be included. In 548 addition, "Associated Label Multipath Information" section MUST 549 be populated with list of labels corresponding to each label 550 specified in "Label Multipath Information" section. "Assoc 551 Label Multipath Length" MUST be set to a value representing 552 length in octets of "Associated Label Multipath Information" 553 field. 555 6.5. Flow Aware MS-PW Stitching LSR 557 Stitching LSR that cross-connects Flow Aware Pseudowires behave in 558 one of two ways: 560 o Load balances on previous Flow Label, and carries over same Flow 561 Label. For this case, stitching LSR is to behave as procedures 562 described in Section 6.3. 564 o Load balances on previous Flow Label, and replaces Flow Label with 565 newly computed. For this case, stitching LSR is to behave as 566 procedures described in Section 6.4. 568 7. Entropy Label FEC 570 Entropy Label Indicator (ELI) is a reserved label that has no 571 explicit FEC associated, and has label value 7 assigned from the 572 reserved range. Use Nil FEC as Target FEC Stack sub-TLV to account 573 for ELI in a Target FEC Stack TLV. 575 Entropy Label (EL) is a special purpose label with label value being 576 discretionary (i.e. label value may not be from the reserved range). 577 For LSP verification mechanics to perform its purpose, it is 578 necessary for a Target FEC Stack sub-TLV to clearly describe EL, 579 particularly in the scenario where label stack does not carry ELI 580 (ex: Flow Aware Pseudowire [RFC6391]). Therefore, this document 581 defines a EL FEC to allow a Target FEC Stack sub-TLV to be added to 582 the Target FEC Stack to account for EL. 584 The Length is 4. Labels are 20-bit values treated as numbers. 586 0 1 2 3 587 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 588 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 589 | Label | MBZ | 590 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 592 Figure 1: Entropy Label FEC 594 Label is the actual label value inserted in the label stack; the MBZ 595 fields MUST be zero when sent and ignored on receipt. 597 8. DS Flags: L and E 599 Two flags, L and E, are added in DS Flags field of the DSMAP/DDMAP 600 TLVs. Both flags MUST NOT be set in echo request packets when 601 sending, and ignored when received. Zero, one or both new flags MUST 602 be set in echo reply packets. 604 DS Flags 605 -------- 607 0 1 2 3 4 5 6 7 608 +-+-+-+-+-+-+-+-+ 609 | MBZ |L|E|I|N| 610 +-+-+-+-+-+-+-+-+ 612 Flag Name and Meaning 613 ---- ---------------- 614 L Label based load balance indicator 615 This flag MUST be set to zero in the echo request. LSR 616 which performs load balancing on a label MUST set this 617 flag in the echo reply. LSR which performs load 618 balancing on IP MUST NOT set this flag in the echo 619 reply. 621 E ELI/EL push indicator 622 This flag MUST be set to zero in the echo request. LSR 623 which pushes ELI/EL MUST set this flag in the echo 624 reply. LSR which does not push ELI/EL MUST NOT set 625 this flag in the echo reply. 627 Two flags result in four load balancing techniques which echo reply 628 generating LSR can indicate: 630 o {L=0, E=0} LSR load balances based on IP and does not push ELI/EL. 632 o {L=0, E=1} LSR load balances based on IP and pushes ELI/EL. 634 o {L=1, E=0} LSR load balances based on label and does not push ELI/ 635 EL. 637 o {L=1, E=1} LSR load balances based on label and pushes ELI/EL. 639 9. New Multipath Information Type: 10 641 One new multipath information type is added to be used in DSMAP/DDMAP 642 TLVs. New multipath type has value of 10. 644 Key Type Multipath Information 645 --- ---------------- --------------------- 646 10 IP and label set IP addresses and label prefixes 648 Multipath type 10 is comprised of three sections. One section to 649 describe IP address set. One section to describe label set. One 650 section to describe another label set which associates to either IP 651 address set or label set specified in the other section. 653 Multipath information type 10 has following format: 655 0 1 2 3 656 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 657 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 658 |IPMultipathType| Reserved(MBZ) | IP Multipath Length | 659 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 660 ~ ~ 661 | (IP Multipath Information) | 662 ~ ~ 663 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 664 |LbMultipathType| Reserved(MBZ) | Label Multipath Length | 665 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 666 ~ ~ 667 | (Label Multipath Information) | 668 ~ ~ 669 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 670 | Reserved(MBZ) | Assoc Label Multipath Length | 671 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 672 ~ ~ 673 | (Associated Label Multipath Information) | 674 ~ ~ 675 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 677 Figure 2: Multipath Information Type 10 679 o IPMultipathType 681 * 0 when "IP Multipath Information" is omitted. Otherwise one of 682 IP multipath information values: {2, 4, 8}. 684 o IP Multipath Information 686 * This section is omitted when "IPMultipathType" is 0. Otherwise 687 this section reuses IP multipath information from [RFC4379]. 688 Specifically, multipath information for values {2, 4, 8} can be 689 used. 691 o LbMultipathType 693 * 0 when "Label Multipath Information" is omitted. Otherwise 694 label multipath information value {9}. 696 o Label Multipath Information 698 * This section is omitted when "LbMultipathType" is 0. Otherwise 699 this section reuses label multipath information from [RFC4379]. 700 Specifically, multipath information for value {9} can be used. 702 o Associated Label Multipath Information 703 * "Assoc Label Multipath Length" is a 16 bit field of multipath 704 information which indicates length in octets of the associated 705 label multipath information. 707 * "Associated Label Multipath Information" is a list of labels 708 with each label described in 24 bits. This section MUST be 709 omitted in an MPLS echo request message. A midpoint which 710 pushes ELI/EL labels SHOULD include "Assoc Label Multipath 711 Information" in its MPLS echo reply message, along with either 712 "IP Multipath Information" or "Label Multipath Information". 713 Each specified associated label described in this section maps 714 to specific IP address OR label described in the "IP Multipath 715 Information" section or "Label Multipath Information" section. 716 For example, if 3 IP addresses are specified in the "IP 717 Multipath Information" section, then there MUST be 3 labels 718 described in this section. First label maps to the lowest IP 719 address specified, second label maps to the second lowest IP 720 address specified and third label maps to the third lowest IP 721 address specified. 723 10. Supported and Unsupported Cases 725 MPLS architecture never defined strict rules on how implementations 726 are to identify hash "keys" for load balancing purpose. As result, 727 implementations may be of following load balancer types: 729 1. IP Based Load Balancer. 730 2. Label Based Load Balancer. 731 3. Label and IP Based Load Balancer. 733 For cases (2) and (3), implementation can include different sets of 734 labels from the label stack for load balancing purpose. Thus 735 following sub-cases are possible: 737 a. Entire label stack. 738 b. Top N labels from label stack where number of labels in label 739 stack is >N. 740 c. Bottom N labels from label stack where number of labels in label 741 stack is >N. 743 In a scenario where there is one Flow Label or Entropy Label present 744 in the label stack, following further cases are possible for (2b), 745 (2c), (3b) and (3c): 747 1. N labels from label stack include Flow Label or Entropy Label. 748 2. N labels from label stack does not include Flow Label or Entropy 749 Label. 751 Also in a scenario where there are multiple Entropy Labels present in 752 the label stack, it is possible for implementations to employ 753 deviating techniques: 755 o Search for entropy stops at the first Entropy Label. 756 o Search for entropy includes any Entropy Label found plus continues 757 to search for entropy in the label stack. 759 Furthermore, handling of reserved (i.e. special) labels varies among 760 implementations: 762 o Reserved labels are used in the hash as any other label would be 763 (a bad practice). 764 o Reserved labels are skipped over and, for implementations limited 765 to N labels, the reserved labels do not count towards the limit of 766 N. 767 o Reserved labels are skipped over and, for implementations limited 768 to N labels, the reserved labels count towards the limit of N. 770 It is important to point this out since presence of GAL will affect 771 those implementations which include reserved labels for load 772 balancing purpose. 774 As can be seen from above, there are many flavors of potential load 775 balancing implementations. Attempting for any OAM tools to support 776 ECMP discovery and traversal over all flavors of such will require 777 fairly complex procedures and implementations to support those 778 complex procedures. Complexities in OAM tools will produce minimal 779 benefits if majority of implementations are expected to employ small 780 subset of cases described above. 782 o Section 4.3 of [RFC6790] states that implementations, for load 783 balancing purpose, parsing beyond the label stack after finding 784 Entropy Label is "limited incremental value". Therefore, it is 785 expected that most implementations will be of types "IP Based Load 786 Balancer" or "Label Based Load Balancer". 788 o Section 2.4.5.1 of [I-D.ietf-mpls-forwarding] recommends that 789 search for entropies from the label stack should terminate upon 790 finding the first Entropy Label. Therefore, it is expected that 791 implementations will only include the first (top-most) Entropy 792 Label when there are multiple Entropy Labels in the label stack. 794 o It is expected that, in most cases, number of labels in the label 795 stack will not exceed number of labels (N) which implementations 796 can include for load balancing purpose. 798 o It is expected that labels in the label stack, besides Flow Label 799 and Entropy Label, are constant for the lifetime of a single LSP 800 multipath traceroute operation. Therefore, deviating load 801 balancing implementations with respect to reserved labels should 802 not affect this tool. 804 Thus [RFC4379], [RFC6424] and this document will support cases (1) 805 and (2a1), where only the first (top-most) Entropy Label is included 806 when there are multiple Entropy Labels in the label stack. 808 11. Security Considerations 810 This document extends LSP Traceroute mechanism to discover and 811 exercise ECMP paths when LSP uses ELI/EL in label stack. Additional 812 processings are required for responder and initiator nodes. 813 Responder node that pushes ELI/EL will need to compute and return 814 multipath data including associated EL. Initiator node will need to 815 store and handle both IP multipath and label multipath information, 816 and include destination IP addresses and/or ELs in MPLS echo request 817 packet as well as in carried multipath information to downstream 818 nodes. Due to additional processing, it is critical that proper 819 security measures described in [RFC4379] and [RFC6424] are followed. 821 12. IANA Considerations 823 12.1. New Sub-Registries 825 [RFC4379] defines the Downstream Mapping TLV, which has the Type 2 826 assigned from the "Multi-Protocol Label Switching (MPLS) Label 827 Switched Paths (LSPs) Ping Parameters - TLVs" registry. [RFC6424] 828 defines the Downstream Detailed Mapping TLV, which has the Type 20 829 assigned from the "Multi-Protocol Label Switching (MPLS) Label 830 Switched Paths (LSPs) Ping Parameters - TLVs" registry. Both TLVs 831 shares two fields: "DS Flags" and "Multipath Type". This document 832 requires allocation of new values in both the "DS Flags" and 833 "Multipath Type" fields, which are not maintained by IANA today. 834 Therefore, this document requests IANA to create new registries 835 within [IANA-MPLS-LSP-PING] protocol to maintain "DS Flags" and 836 "Multipath Type" fields. Name of registries and initial values are 837 described in immediate sub-sections to follow. 839 12.1.1. DS Flags 840 Bit number Name Reference 841 ---------- ---------------------------------------- --------- 842 7 N: Treat as a Non-IP Packet RFC4379 843 6 I: Interface and Label Stack Object Request RFC4379 844 5 E: ELI/EL push indicator this document 845 4 L: Label based load balance indicator this document 846 3-0 Unassigned 848 Assignments of DS Flags are via Standards Action [RFC5226] or IESG 849 Approval [RFC5226]. 851 Note that "DS Flags" is a field included in two TLVs defined in 852 "Multi-Protocol Label Switching (MPLS) Label Switched Paths (LSPs) 853 Ping Parameters - TLVs" registry: Downstream Mapping TLV (value 2) 854 and Downstream Detailed Mapping TLV (value 20). Modification to "DS 855 Flags" registry will affect both TLVs. 857 12.1.2. Multipath Type 859 Value Meaning Reference 860 ---------- ---------------------------------------- --------- 861 0 no multipath RFC4379 862 1 Unassigned 863 2 IP address RFC4379 864 3 Unassigned 865 4 IP address range RFC4379 866 5-7 Unassigned 867 8 Bit-masked IP address set RFC4379 868 9 Bit-masked label set RFC4379 869 10 IP and label set this document 870 11-255 Unassigned 872 Assignments of Multipath Type are via IETF Review [RFC5226] or IESG 873 Approval [RFC5226]. 875 Note that "Multipath Type" is a field included in two TLVs defined in 876 "Multi-Protocol Label Switching (MPLS) Label Switched Paths (LSPs) 877 Ping Parameters - TLVs" registry: Downstream Mapping TLV (value 2) 878 and Downstream Detailed Mapping TLV (value 20). Modification to 879 "Multipath Type" registry will affect both TLVs. 881 12.2. Entropy Label FEC 883 IANA is requested to assign a new sub-TLV from the "Sub-TLVs for TLV 884 Types 1 and 16" section from "Multi-Protocol Label Switching (MPLS) 885 Label Switched Paths (LSPs) Ping Parameters - TLVs" registry. 887 Sub-Type Sub-TLV Name Reference 888 -------- ------------ --------- 889 TBD1 Entropy Label FEC this document 891 13. Acknowledgements 893 Authors would like to thank Loa Andersson, Curtis Villamizar, Daniel 894 King and Sriganesh Kini for performing thorough review and providing 895 valuable comments. 897 14. Contributing Authors 899 Nagendra Kumar 900 Cisco Systems 901 Email: naikumar@cisco.com 903 15. References 905 15.1. Normative References 907 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 908 Requirement Levels", BCP 14, RFC 2119, March 1997. 910 [RFC4379] Kompella, K. and G. Swallow, "Detecting Multi-Protocol 911 Label Switched (MPLS) Data Plane Failures", RFC 4379, 912 February 2006. 914 [RFC6790] Kompella, K., Drake, J., Amante, S., Henderickx, W., and 915 L. Yong, "The Use of Entropy Labels in MPLS Forwarding", 916 RFC 6790, November 2012. 918 15.2. Informative References 920 [I-D.ietf-mpls-forwarding] 921 Villamizar, C., Kompella, K., Amante, S., Malis, A., and 922 C. Pignataro, "MPLS Forwarding Compliance and Performance 923 Requirements", draft-ietf-mpls-forwarding-09 (work in 924 progress), March 2014. 926 [I-D.ravisingh-mpls-el-for-seamless-mpls] 927 Singh, R., Shen, Y., and J. Drake, "Entropy label for 928 seamless MPLS", draft-ravisingh-mpls-el-for-seamless- 929 mpls-01 (work in progress), October 2013. 931 [IANA-MPLS-LSP-PING] 932 IANA, "Multi-Protocol Label Switching (MPLS) Label 933 Switched Paths (LSPs) Ping Parameters", 934 . 937 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 938 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 939 May 2008. 941 [RFC6391] Bryant, S., Filsfils, C., Drafz, U., Kompella, V., Regan, 942 J., and S. Amante, "Flow-Aware Transport of Pseudowires 943 over an MPLS Packet Switched Network", RFC 6391, November 944 2011. 946 [RFC6424] Bahadur, N., Kompella, K., and G. Swallow, "Mechanism for 947 Performing Label Switched Path Ping (LSP Ping) over MPLS 948 Tunnels", RFC 6424, November 2011. 950 Authors' Addresses 952 Nobo Akiya 953 Cisco Systems 955 Email: nobo@cisco.com 957 George Swallow 958 Cisco Systems 960 Email: swallow@cisco.com 962 Carlos Pignataro 963 Cisco Systems 965 Email: cpignata@cisco.com 967 Andrew G. Malis 968 Huawei Technologies 970 Email: agmalis@gmail.com 971 Sam Aldrin 972 Huawei Technologies 974 Email: aldrin.ietf@gmail.com