idnits 2.17.1 draft-ietf-mpls-entropy-lsp-ping-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- -- 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 (May 18, 2016) is 2893 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: November 19, 2016 Cisco 7 A. Malis 8 Huawei Technologies 9 S. Aldrin 10 Google 11 May 18, 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-03 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 November 19, 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". The mechanisms in [RFC4379] 153 updated by [RFC6424] are designed to provide multipath support for 154 subset of techniques. Intent of this document is to restore 155 multipath support for those supported techniques which have been 156 compromised by the introduction of [RFC6790] (i.e. Entropy Labels). 157 Section 10 describes supported and unsupported cases, and it may be 158 useful for one to visit this section first. 160 1.3. Background 162 Section 3.3.1 of [RFC4379] specifies multipath information encoding 163 in Downstream Mapping (DSMAP) TLV (Section 3.3 of [RFC4379]) and 164 Downstream Detailed Mapping (DDMAP) TLV (Section 3.3 of [RFC6424]) 165 which can be used by LSP Ping initiator to trace and validate all 166 ECMP paths between ingress and egress. While the multipath 167 information encoding is common to both the Downstream Mapping (DSMAP) 168 TLV and the Downstream Detailed Mapping (DDMAP) TLV, the former has 169 been deprecated by [RFC6424] and this specification only concerns 170 itself with the latter. The multipath information encodings are 171 sufficient when all the LSRs along the path(s), between ingress and 172 egress, consider same set of "keys" as input for load balancing 173 algorithm: all IP based or all label based. 175 With introduction of [RFC6790], it is quite normal to see set of LSRs 176 performing load balancing based on EL/ELI while others still follow 177 the traditional way (IP based). This results in LSP Ping initiator 178 not be able to trace and validate all ECMP paths in following 179 scenarios: 181 o One or more transit LSRs along LSP with ELI/EL in label stack do 182 not perform ECMP load balancing based on EL (hashes based on 183 "keys" including IP destination address). This scenario is not 184 only possible but quite common due transit LSRs not implementing 185 [RFC6790] or transit LSRs implementing [RFC6790] but not 186 implementing suggested transit LSR behavior in Section 4.3 of 187 [RFC6790]. 189 o Two or more LSPs stitched together with at least one of these LSP 190 pushing ELI/EL in label stack. Such scenarios are described in 191 [I-D.ravisingh-mpls-el-for-seamless-mpls]. 193 These scenarios will be quite common because every deployment of 194 [RFC6790] will invariably end up with nodes that support ELI/EL and 195 nodes that do not. There will typically be areas that support ELI/EL 196 and areas that do not. 198 As pointed out in [RFC6790] the procedures of [RFC4379] (and 199 consequently of [RFC6424]) with respect to multipath information type 200 {9} are incomplete. However [RFC6790] does not actually update 201 [RFC4379]. Further the specific EL location is not clearly defined, 202 particularly in the case of Flow Aware Pseudowires [RFC6391]. This 203 document defines a new FEC Stack sub-TLV for the Entropy Label. 204 Section 3 of this document updates the procedures for multipath 205 information type {9} described in [RFC4379] and applicable to 206 [RFC6424]. The rest of this document describes extensions required 207 to restore ECMP discovery and tracing capabilities for scenarios 208 described. 210 2. Overview 212 [RFC4379] describes LSP traceroute as an operation where the 213 initiating LSR send a series of MPLS echo requests towards the same 214 destination. The first packet in the series have the TTL set to 1. 215 When the echo reply is received from the LSR one hop away the second 216 echo request in the series is sent with the TTL set to 2, for each 217 echo request the TLL is incremented by one until a response is 218 received from the intended destination. Initiating LSR discovers and 219 exercises ECMP by obtaining multipath information from each transit 220 LSR and using specific destination IP address or specific entropy 221 label. 223 Notion of {x, y, z} from here on refers to Multipath information 224 types x, y or z. 226 LSP Ping initiating LSR sends MPLS echo request with multipath 227 information. This multipath information is described in DDMAP TLV of 228 echo request, and may contain set of IP addresses or set of labels. 229 Multipath information types {2, 4, 8} carry set of IP addresses and 230 multipath information type {9} carries set of labels. Responder LSR 231 (receiver of MPLS echo request) will determine the subset of 232 initiator specified multipath information which load balances to each 233 downstream (outgoing interface). Responder LSR sends MPLS echo reply 234 with resulting multipath information per downstream (outgoing 235 interface) back to the initiating LSR. Initiating LSR is then able 236 to use specific IP destination address or specific label to exercise 237 specific ECMP path on the responder LSR. 239 Current behavior is problematic in following scenarios: 241 o Initiating LSR sends IP multipath information, but responder LSR 242 load balances on labels. 244 o Initiating LSR sends label multipath information, but responder 245 LSR load balances on IP addresses. 247 o Initiating LSR sends existing multipath information to LSR which 248 pushes ELI/EL in label stack, but the initiating LSR can only 249 continue to discover and exercise specific path of ECMP, if the 250 LSR which pushes ELI/EL responds with both IP addresses and 251 associated EL corresponding to each IP address. This is because: 253 * ELI/EL pushing LSR that is a stitching point will load balance 254 based on IP address. 256 * Downstream LSR(s) of ELI/EL pushing LSR may load balance based 257 on ELs. 259 o Initiating LSR sends one of existing multipath information to ELI/ 260 EL pushing LSR, but initiating LSR can only continue to discover 261 and exercise specific path of ECMP if ELI/EL pushing LSR responds 262 with both labels and associated EL corresponding to label. This 263 is because: 265 * ELI/EL pushing LSR that is a stitching point will load balance 266 based on EL from previous LSP and pushes new EL. 268 * Downstream LSR(s) of ELI/EL pushing LSR may load balance based 269 on new ELs. 271 The above scenarios point to how the existing multipath information 272 is insufficient when LSP traceroute is operated on an LSP with 273 Entropy Labels described by [RFC6790]. Therefore, this document 274 defines a multipath information type to be used in the DDMAP of MPLS 275 echo request/reply packets in Section 9. 277 In addition, responder LSR can reply with empty multipath information 278 if no IP address set or label set from received multipath information 279 matched load balancing to a downstream. Empty return is also 280 possible if initiating LSR sends multipath information of one type, 281 IP address or label, but responder LSR load balances on the other 282 type. To disambiguate between the two results, this document 283 introduces new flags in the DDMAP TLV to allow responder LSR to 284 describe the load balance technique being used. 286 It is required that all LSRs along the LSP understand new flags as 287 well as new multipath information type. It is also required that 288 initiating LSR can select both IP destination address and label to 289 use on transmitting MPLS echo request packets. Two additional DS 290 Flags are defined for the DDMAP TLV in Section 8. These two flags 291 are used by the responder LSR to describe its load balance behavior 292 on received MPLS echo request. 294 Note that the terms "IP Based Load Balancer", "Label Based Load 295 Balancer" and "Label Based Load Balancer" are in context of how 296 received MPLS echo request is handled by the responder LSR. 298 3. Multipath Type 9 300 This section defines to which labels multipath type {9} applies. 302 [RFC4379] defined multipath type {9} for tracing of LSPs where label 303 based load-balancing is used. However, as pointed out in [RFC6790], 304 the procedures for using this type are incomplete as the specific 305 location of the label was not defined. It was assumed that the 306 presence of multipath type {9} implied the value of the bottom-of- 307 stack label should be varied by the values indicated by multipath to 308 determine their respective out-going interfaces. 310 Section 7 defines a new FEC-Stack sub-TLV to indicate an entropy 311 label. These labels may appear anywhere in a label stack. 313 Multipath type {9} applies to the first label in the label-stack that 314 corresponds to an EL-FEC. If no such label is found, it applies to 315 the label at the bottom of the label stack. 317 4. Pseudowire Tracing 319 This section defines procedures for tracing pseudowires. These 320 procedures pertain to the use of multipath information type {9} as 321 well as type {TBD4}. In all cases below, when a control word is in 322 use the N-flag in the DDMAP MUST be set. Note that when a control 323 word is not in use the returned DDMAPs may not be accurate. 325 In order to trace a non Flow-Aware Pseudowire the initiator includes 326 an EL-FEC instead of the appropriate PW-FEC at the bottom of the FEC- 327 Stack. Tracing in this way will cause compliant routers to return 328 the proper outgoing interface. Note that this procedure only traces 329 to the end of the MPLS LSP that is under test and will not verify the 330 PW FEC. To actually verify the PW-FEC or in the case of a MS-PW, to 331 determine the next pseudowire label value, the initiator MUST repeat 332 that step of the trace, (i.e., repeating the TTL value used) but with 333 the FEC-Stack modified to contain the appropriate PW-FEC. Note that 334 these procedures are applicable to scenarios which an initiator is 335 able to vary the bottom label (i.e. pseudowire label). Possible 336 scenarios are tracing multiple non Flow-Aware Pseudowires on the same 337 endpoints or tracing a non Flow-Aware Pseudowire provisioned with 338 multiple pseudowire labels. 340 In order to trace a Flow Aware Pseudowire, the initiator includes an 341 EL-FEC at the bottom of the FEC-Stack and pushes the appropriate PW- 342 FEC onto the FEC-Stack. 344 In order to trace through non-compliant routers the initiator forms 345 an MPLS echo request message and includes a DDMAP with multipath type 346 {9}. For a non Flow-Aware Pseudowire it includes the appropriate PW- 347 FEC in the FEC-Stack. For a Flow Aware Pseudowire, the initiator 348 includes a NIL-FEC at the bottom of the FEC-Stack and pushes the 349 appropriate PW-FEC onto the FEC-Stack. 351 5. Initiating LSR Procedures 353 In order to facilitate the flow of the following text we speak in 354 terms of a boolean called EL_LSP maintained by the initiating LSR. 355 This value controls the multipath information type to be used in 356 transmitted echo request packets. When the initiating LSR is 357 transmitting an echo request packet with DDMAP with a non-zero 358 multipath information type, then EL_LSP boolean MUST be consulted to 359 determine the multipath information type to use. 361 In addition to procedures described in [RFC4379] as updated by 362 Section 3 and [RFC6424], initiating LSR MUST operate with following 363 procedures. 365 o When the initiating LSR pushes ELI/EL, initialize EL_LSP=True. 366 Else set EL_LSP=False. 368 o When the initiating LSR is transmitting non-zero multipath 369 information type: 371 * If (EL_LSP), the initiating LSR MUST use multipath information 372 type {TBD4} unless same responder LSR cannot handle type 373 {TBD4}. When the initiating LSR is transmitting multipath 374 information type {TBD4} in this case, both "IP Multipath 375 Information" and "Label Multipath Information" MUST be 376 included, and "IP Associated Label Multipath Information" MUST 377 be omitted (NULL). 379 * Else the initiating LSR MAY use multipath information type {2, 380 4, 8, 9, TBD4}. When the initiating LSR is transmitting 381 multipath information type {TBD4} in this case, "IP Multipath 382 Information" MUST be included, and "Label Multipath 383 Information" and "IP Associated Label Multipath Information" 384 MUST be omitted (NULL). 386 o When the initiating LSR receives echo reply with {L=0, E=1} in DS 387 flags with valid contents, set EL_LSP=True. 389 In following conditions, the initiating LSR may have lost the ability 390 to exercise specific ECMP paths. The initiating LSR MAY continue 391 with "best effort". 393 o Received echo reply contains empty multipath information. 395 o Received echo reply contains {L=0, E=} DS flags, but does not 396 contain IP multipath information. 398 o Received echo reply contains {L=1, E=} DS flags, but does not 399 contain label multipath information. 401 o Received echo reply contains {L=, E=1} DS flags, but does not 402 contain associated label multipath information. 404 o IP multipath information types {2, 4, 8} sent, and received echo 405 reply with {L=1, E=0} in DS flags. 407 o Multipath information type {TBD4} sent, and received echo reply 408 with multipath information type other than {TBD4}. 410 6. Responder LSR Procedures 412 Common Procedures: 414 o The responder LSR receiving an MPLS echo request packet MUST first 415 determine whether or not the initiating LSR supports this LSP Ping 416 and Traceroute extension for Entropy Labels. If either of the 417 following conditions are met, the responder LSR SHOULD determine 418 that the initiating LSR supports this LSP Ping and Traceroute 419 extension for Entropy Labels. 421 1. Received MPLS echo request contains the multipath information 422 type {TBD4}. 424 2. Received MPLS echo request contains a Target FEC Stack TLV 425 that includes the Entropy Label FEC. 427 If the initiating LSR is determined to not support this LSP Ping 428 and Traceroute extension for Entropy Labels, then the responder 429 LSR MUST NOT follow further procedures described in this section. 430 Specifically, MPLS echo reply packets: 432 * MUST have following DS Flags cleared (i.e., not set): "ELI/EL 433 push indicator" and "Label based load balance indicator". 435 * MUST NOT use multipath information type {TBD4}. 437 o The responder LSR receiving an MPLS echo request packet with 438 multipath information type {TBD4} MUST validate following 439 contents. Any deviation MUST result in the responder LSR to 440 consider the packet as malformed and return code 1 (Malformed echo 441 request received) in the MPLS echo reply packet. 443 * IP multipath information MUST be included. 445 * Label multipath information MAY be included. 447 * IP associated label multipath information MUST be omitted 448 (NULL). 450 Following subsections describe expected responder LSR procedures when 451 echo reply is to include DDMAP TLVs, based on local load balance 452 technique being employed. In case the responder LSR performs 453 deviating load balance techniques per downstream basis, appropriate 454 procedures matching to each downstream load balance technique MUST be 455 operated. 457 6.1. IP Based Load Balancer & Not Pushing ELI/EL 459 o The responder MUST set {L=0, E=0} in DS flags. 461 o If multipath information type {2, 4, 8} is received, the responder 462 MUST comply with [RFC4379] and [RFC6424]. 464 o If multipath information type {9} is received, the responder MUST 465 reply with multipath type {0}. 467 o If multipath information type {TBD4} is received, following 468 procedures are to be used: 470 * The responder MUST reply with multipath information type 471 {TBD4}. 473 * "Label Multipath Information" and "Associated Label Multipath 474 Information" sections MUST be omitted (NULL). 476 * If no matching IP address is found, then "IPMultipathType" 477 field MUST be set to multipath information type {0} and "IP 478 Multipath Information" section MUST also be omitted (NULL). 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. 485 6.2. IP Based Load Balancer & Pushes ELI/EL 487 o The responder MUST set {L=0, E=1} in DS flags. 489 o If multipath information type {9} is received, the responder MUST 490 reply with multipath type {0}. 492 o If multipath type {2, 4, 8, TBD4} is received, following 493 procedures are to be used: 495 * The responder MUST respond with multipath type {TBD4}. See 496 Section 9 for details of multipath type {TBD4}. 498 * "Label Multipath Information" section MUST be omitted (i.e. is 499 it not there). 501 * IP address set specified in received IP multipath information 502 MUST be used to determine the returning IP/Label pairs. 504 * If received multipath information type was {TBD4}, received 505 "Label Multipath Information" sections MUST NOT be used to 506 determine the associated label portion of returning IP/Label 507 pairs. 509 * If no matching IP address is found, then "IPMultipathType" 510 field MUST be set to multipath information type {0} and "IP 511 Multipath Information" section MUST be omitted. In addition, 512 "Assoc Label Multipath Length" MUST be set to 0, and 513 "Associated Label Multipath Information" section MUST also be 514 omitted. 516 * If at least one matching IP address is found, then 517 "IPMultipathType" field MUST be set to appropriate multipath 518 information type {2, 4, 8} and "IP Multipath Information" 519 section MUST be included. In addition, "Associated Label 520 Multipath Information" section MUST be populated with list of 521 labels corresponding to each IP address specified in "IP 522 Multipath Information" section. "Assoc Label Multipath Length" 523 MUST be set to a value representing length in octets of 524 "Associated Label Multipath Information" field. 526 6.3. Label Based Load Balancer & Not Pushing ELI/EL 528 o The responder MUST set {L=1, E=0} in DS flags. 530 o If multipath information type {2, 4, 8} is received, the responder 531 MUST reply with multipath type {0}. 533 o If multipath information type {9} is received, the responder MUST 534 comply with [RFC4379] and [RFC6424] as updated by Section 3. 536 o If multipath information type {TBD4} is received, following 537 procedures are to be used: 539 * The responder MUST reply with multipath information type 540 {TBD4}. 542 * "IP Multipath Information" and "Associated Label Multipath 543 Information" sections MUST be omitted (NULL). 545 * If no matching label is found, then "LbMultipathType" field 546 MUST be set to multipath information type {0} and "Label 547 Multipath Information" section MUST also be omitted (NULL). 549 * If at least one matching label is found, then "LbMultipathType" 550 field MUST be set to appropriate multipath information type {9} 551 and "Label Multipath Information" section MUST be included. 553 6.4. Label Based Load Balancer & Pushes ELI/EL 555 o The responder MUST set {L=1, E=1} in DS flags. 557 o If multipath information type {2, 4, 8} is received, the responder 558 MUST reply with multipath type {0}. 560 o If multipath type {9, TBD4} is received, following procedures are 561 to be used: 563 * The responder MUST respond with multipath type {TBD4}. 565 * "IP Multipath Information" section MUST be omitted. 567 * Label set specified in received label multipath information 568 MUST be used to determine the returning Label/Label pairs. 570 * If received multipath information type was {TBD4}, received 571 "Label Multipath Information" sections MUST NOT be used to 572 determine the associated label portion of returning Label/Label 573 pairs. 575 * If no matching label is found, then "LbMultipathType" field 576 MUST be set to multipath information type {0} and "Label 577 Multipath Information" section MUST be omitted. In addition, 578 "Assoc Label Multipath Length" MUST be set to 0, and 579 "Associated Label Multipath Information" section MUST also be 580 omitted. 582 * If at least one matching label is found, then "LbMultipathType" 583 field MUST be set to appropriate multipath information type {9} 584 and "Label Multipath Information" section MUST be included. In 585 addition, "Associated Label Multipath Information" section MUST 586 be populated with list of labels corresponding to each label 587 specified in "Label Multipath Information" section. "Assoc 588 Label Multipath Length" MUST be set to a value representing 589 length in octets of "Associated Label Multipath Information" 590 field. 592 6.5. Flow Aware MS-PW Stitching LSR 594 Stitching LSR that cross-connects Flow Aware Pseudowires behave in 595 one of two ways: 597 o Load balances on previous Flow Label, and carries over same Flow 598 Label. For this case, stitching LSR is to behave as procedures 599 described in Section 6.3. 601 o Load balances on previous Flow Label, and replaces Flow Label with 602 newly computed. For this case, stitching LSR is to behave as 603 procedures described in Section 6.4. 605 7. Entropy Label FEC 607 Entropy Label Indicator (ELI) is a reserved label that has no 608 explicit FEC associated, and has label value 7 assigned from the 609 reserved range. Use Nil FEC as Target FEC Stack sub-TLV to account 610 for ELI in a Target FEC Stack TLV. 612 Entropy Label (EL) is a special purpose label with label value being 613 discretionary (i.e. label value may not be from the reserved range). 614 For LSP verification mechanics to perform its purpose, it is 615 necessary for a Target FEC Stack sub-TLV to clearly describe EL, 616 particularly in the scenario where label stack does not carry ELI 617 (ex: Flow Aware Pseudowire [RFC6391]). Therefore, this document 618 defines a EL FEC to allow a Target FEC Stack sub-TLV to be added to 619 the Target FEC Stack to account for EL. 621 The Length is 4. Labels are 20-bit values treated as numbers. 623 0 1 2 3 624 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 625 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 626 | Label | MBZ | 627 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 629 Figure 1: Entropy Label FEC 631 Label is the actual label value inserted in the label stack; the MBZ 632 fields MUST be zero when sent and ignored on receipt. 634 8. DS Flags: L and E 636 Two flags, L and E, are added in DS Flags field of the DDMAP TLV. 637 Both flags MUST NOT be set in echo request packets when sending, and 638 ignored when received. Zero, one or both new flags MUST be set in 639 echo reply packets. 641 DS Flags 642 -------- 644 0 1 2 3 4 5 6 7 645 +-+-+-+-+-+-+-+-+ 646 | MBZ |L|E|I|N| 647 +-+-+-+-+-+-+-+-+ 649 RFC-Editor-Note: Please update above figure to place the flag E in 650 the bit number TBD2 and the flag L in the bit number TBD3. 652 Flag Name and Meaning 653 ---- ---------------- 654 L Label based load balance indicator 655 This flag MUST be set to zero in the echo request. LSR 656 which performs load balancing on a label MUST set this 657 flag in the echo reply. LSR which performs load 658 balancing on IP MUST NOT set this flag in the echo 659 reply. 661 E ELI/EL push indicator 662 This flag MUST be set to zero in the echo request. LSR 663 which pushes ELI/EL MUST set this flag in the echo 664 reply. LSR which does not push ELI/EL MUST NOT set 665 this flag in the echo reply. 667 Two flags result in four load balancing techniques which echo reply 668 generating LSR can indicate: 670 o {L=0, E=0} LSR load balances based on IP and does not push ELI/EL. 672 o {L=0, E=1} LSR load balances based on IP and pushes ELI/EL. 674 o {L=1, E=0} LSR load balances based on label and does not push ELI/ 675 EL. 677 o {L=1, E=1} LSR load balances based on label and pushes ELI/EL. 679 9. New Multipath Information Type: TBD4 681 One new multipath information type is added to be used in DDMAP TLV. 682 New multipath type has value of TBD4. 684 Key Type Multipath Information 685 --- ---------------- --------------------- 686 TBD4 IP and label set IP addresses and label prefixes 688 Multipath type TBD4 is comprised of three sections. One section to 689 describe IP address set. One section to describe label set. One 690 section to describe another label set which associates to either IP 691 address set or label set specified in the other section. 693 Multipath information type TBD4 has following format: 695 0 1 2 3 696 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 697 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 698 |IPMultipathType| IP Multipath Length | Reserved(MBZ) | 699 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 700 ~ ~ 701 | (IP Multipath Information) | 702 ~ ~ 703 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 704 |LbMultipathType| Label Multipath Length | Reserved(MBZ) | 705 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 706 ~ ~ 707 | (Label Multipath Information) | 708 ~ ~ 709 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 710 | Assoc Label Multipath Length | Reserved(MBZ) | 711 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 712 ~ ~ 713 | (Associated Label Multipath Information) | 714 ~ ~ 715 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 717 Figure 2: Multipath Information Type TBD4 719 o IPMultipathType 720 * 0 when "IP Multipath Information" is omitted. Otherwise one of 721 IP multipath information values: {2, 4, 8}. 723 o IP Multipath Information 725 * This section is omitted when "IPMultipathType" is 0. Otherwise 726 this section reuses IP multipath information from [RFC4379]. 727 Specifically, multipath information for values {2, 4, 8} can be 728 used. 730 o LbMultipathType 732 * 0 when "Label Multipath Information" is omitted. Otherwise 733 label multipath information value {9}. 735 o Label Multipath Information 737 * This section is omitted when "LbMultipathType" is 0. Otherwise 738 this section reuses label multipath information from [RFC4379]. 739 Specifically, multipath information for value {9} can be used. 741 o Associated Label Multipath Information 743 * "Assoc Label Multipath Length" is a 16 bit field of multipath 744 information which indicates length in octets of the associated 745 label multipath information. 747 * "Associated Label Multipath Information" is a list of labels 748 with each label described in 24 bits. This section MUST be 749 omitted in an MPLS echo request message. A midpoint which 750 pushes ELI/EL labels SHOULD include "Assoc Label Multipath 751 Information" in its MPLS echo reply message, along with either 752 "IP Multipath Information" or "Label Multipath Information". 753 Each specified associated label described in this section maps 754 to specific IP address OR label described in the "IP Multipath 755 Information" section or "Label Multipath Information" section. 756 For example, if 3 IP addresses are specified in the "IP 757 Multipath Information" section, then there MUST be 3 labels 758 described in this section. First label maps to the lowest IP 759 address specified, second label maps to the second lowest IP 760 address specified and third label maps to the third lowest IP 761 address specified. 763 10. Supported and Unsupported Cases 765 MPLS architecture never defined strict rules on how implementations 766 are to identify hash "keys" for load balancing purpose. As result, 767 implementations may be of following load balancer types: 769 1. IP Based Load Balancer. 770 2. Label Based Load Balancer. 771 3. Label and IP Based Load Balancer. 773 For cases (2) and (3), implementation can include different sets of 774 labels from the label stack for load balancing purpose. Thus 775 following sub-cases are possible: 777 a. Entire label stack. 778 b. Top N labels from label stack where number of labels in label 779 stack is >N. 780 c. Bottom N labels from label stack where number of labels in label 781 stack is >N. 783 In a scenario where there is one Flow Label or Entropy Label present 784 in the label stack, following further cases are possible for (2b), 785 (2c), (3b) and (3c): 787 1. N labels from label stack include Flow Label or Entropy Label. 788 2. N labels from label stack does not include Flow Label or Entropy 789 Label. 791 Also in a scenario where there are multiple Entropy Labels present in 792 the label stack, it is possible for implementations to employ 793 deviating techniques: 795 o Search for entropy stops at the first Entropy Label. 796 o Search for entropy includes any Entropy Label found plus continues 797 to search for entropy in the label stack. 799 Furthermore, handling of reserved (i.e. special) labels varies among 800 implementations: 802 o Reserved labels are used in the hash as any other label would be 803 (a bad practice). 804 o Reserved labels are skipped over and, for implementations limited 805 to N labels, the reserved labels do not count towards the limit of 806 N. 807 o Reserved labels are skipped over and, for implementations limited 808 to N labels, the reserved labels count towards the limit of N. 810 It is important to point this out since presence of GAL will affect 811 those implementations which include reserved labels for load 812 balancing purpose. 814 As can be seen from above, there are many flavors of potential load 815 balancing implementations. Attempting for any OAM tools to support 816 ECMP discovery and traversal over all flavors of such will require 817 fairly complex procedures and implementations to support those 818 complex procedures. Complexities in OAM tools will produce minimal 819 benefits if majority of implementations are expected to employ small 820 subset of cases described above. 822 o Section 4.3 of [RFC6790] states that implementations, for load 823 balancing purpose, parsing beyond the label stack after finding 824 Entropy Label is "limited incremental value". Therefore, it is 825 expected that most implementations will be of types "IP Based Load 826 Balancer" or "Label Based Load Balancer". 828 o Section 2.4.5.1 of [RFC7325] recommends that search for entropies 829 from the label stack should terminate upon finding the first 830 Entropy Label. Therefore, it is expected that implementations 831 will only include the first (top-most) Entropy Label when there 832 are multiple Entropy Labels in the label stack. 834 o It is expected that, in most cases, number of labels in the label 835 stack will not exceed number of labels (N) which implementations 836 can include for load balancing purpose. 838 o It is expected that labels in the label stack, besides Flow Label 839 and Entropy Label, are constant for the lifetime of a single LSP 840 multipath traceroute operation. Therefore, deviating load 841 balancing implementations with respect to reserved labels should 842 not affect this tool. 844 Thus [RFC4379], [RFC6424] and this document will support cases (1) 845 and (2a1), where only the first (top-most) Entropy Label is included 846 when there are multiple Entropy Labels in the label stack. 848 11. Security Considerations 850 This document extends LSP Traceroute mechanism to discover and 851 exercise ECMP paths when LSP uses ELI/EL in label stack. Additional 852 processings are required for responder and initiator nodes. 853 Responder node that pushes ELI/EL will need to compute and return 854 multipath data including associated EL. Initiator node will need to 855 store and handle both IP multipath and label multipath information, 856 and include destination IP addresses and/or ELs in MPLS echo request 857 packet as well as in carried multipath information to downstream 858 nodes. Due to additional processing, it is critical that proper 859 security measures described in [RFC4379] and [RFC6424] are followed. 861 12. IANA Considerations 863 12.1. DS Flags 865 The IANA is requested to assign new bit numbers from the "DS flags" 866 sub-registry from the "Multi-Protocol Label Switching (MPLS) Label 867 Switched Paths (LSPs) Ping Parameters - TLVs" registry 868 ([IANA-MPLS-LSP-PING]). 870 Note: the "DS flags" sub-registry is created by [RFC7537]. 872 Bit number Name Reference 873 ---------- ---------------------------------------- --------- 874 TBD2 E: ELI/EL push indicator this document 875 TBD3 L: Label based load balance indicator this document 877 12.2. Multpath Type 879 The IANA is requested to assign a new value from the "Multipath Type" 880 sub-registry from the "Multi-Protocol Label Switching (MPLS) Label 881 Switched Paths (LSPs) Ping Parameters - TLVs" registry 882 ([IANA-MPLS-LSP-PING]). 884 Note: the "Multipath Type" sub-registry is created by [RFC7537]. 886 Value Meaning Reference 887 ---------- ---------------------------------------- --------- 888 TBD4 IP and label set this document 890 12.3. Entropy Label FEC 892 The IANA is requested to assign a new sub-TLV from the "Sub-TLVs for 893 TLV Types 1 and 16" section from the "Multi-Protocol Label Switching 894 (MPLS) Label Switched Paths (LSPs) Ping Parameters - TLVs" registry 895 ([IANA-MPLS-LSP-PING]). 897 Sub-Type Sub-TLV Name Reference 898 -------- ------------ --------- 899 TBD1 Entropy Label FEC this document 901 13. Acknowledgements 903 Authors would like to thank Loa Andersson, Curtis Villamizar, Daniel 904 King, Sriganesh Kini and Victor Ji for performing thorough review and 905 providing valuable comments. 907 14. Contributing Authors 909 Nagendra Kumar 910 Cisco Systems, Inc. 911 Email: naikumar@cisco.com 913 15. References 915 15.1. Normative References 917 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 918 Requirement Levels", BCP 14, RFC 2119, 919 DOI 10.17487/RFC2119, March 1997, 920 . 922 [RFC4379] Kompella, K. and G. Swallow, "Detecting Multi-Protocol 923 Label Switched (MPLS) Data Plane Failures", RFC 4379, 924 DOI 10.17487/RFC4379, February 2006, 925 . 927 [RFC6790] Kompella, K., Drake, J., Amante, S., Henderickx, W., and 928 L. Yong, "The Use of Entropy Labels in MPLS Forwarding", 929 RFC 6790, DOI 10.17487/RFC6790, November 2012, 930 . 932 [RFC7537] Decraene, B., Akiya, N., Pignataro, C., Andersson, L., and 933 S. Aldrin, "IANA Registries for LSP Ping Code Points", 934 RFC 7537, DOI 10.17487/RFC7537, May 2015, 935 . 937 15.2. Informative References 939 [I-D.ravisingh-mpls-el-for-seamless-mpls] 940 Singh, R., Shen, Y., and J. Drake, "Entropy label for 941 seamless MPLS", draft-ravisingh-mpls-el-for-seamless- 942 mpls-04 (work in progress), October 2014. 944 [IANA-MPLS-LSP-PING] 945 IANA, "Multi-Protocol Label Switching (MPLS) Label 946 Switched Paths (LSPs) Ping Parameters", 947 . 950 [RFC6391] Bryant, S., Ed., Filsfils, C., Drafz, U., Kompella, V., 951 Regan, J., and S. Amante, "Flow-Aware Transport of 952 Pseudowires over an MPLS Packet Switched Network", 953 RFC 6391, DOI 10.17487/RFC6391, November 2011, 954 . 956 [RFC6424] Bahadur, N., Kompella, K., and G. Swallow, "Mechanism for 957 Performing Label Switched Path Ping (LSP Ping) over MPLS 958 Tunnels", RFC 6424, DOI 10.17487/RFC6424, November 2011, 959 . 961 [RFC7325] Villamizar, C., Ed., Kompella, K., Amante, S., Malis, A., 962 and C. Pignataro, "MPLS Forwarding Compliance and 963 Performance Requirements", RFC 7325, DOI 10.17487/RFC7325, 964 August 2014, . 966 Authors' Addresses 968 Nobo Akiya 969 Big Switch Networks 971 Email: nobo.akiya.dev@gmail.com 973 George Swallow 974 Cisco Systems, Inc. 976 Email: swallow@cisco.com 978 Carlos Pignataro 979 Cisco Systems, Inc. 981 Email: cpignata@cisco.com 983 Andrew G. Malis 984 Huawei Technologies 986 Email: agmalis@gmail.com 988 Sam Aldrin 989 Google 991 Email: aldrin.ietf@gmail.com