idnits 2.17.1 draft-ietf-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 : ---------------------------------------------------------------------------- -- 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 (August 11, 2016) is 2815 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 6424 (Obsoleted by RFC 8029) ** Obsolete normative reference: RFC 7537 (Obsoleted by RFC 8029) Summary: 3 errors (**), 0 flaws (~~), 1 warning (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MPLS Working Group 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: February 12, 2017 Cisco 7 A. Malis 8 Huawei Technologies 9 S. Aldrin 10 Google 11 August 11, 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-04 17 Abstract 19 Multiprotocol Label Switching (MPLS) Label Switched Path (LSP) Ping 20 and Traceroute are methods used to test Equal-Cost Multipath (ECMP) 21 paths. Ping is known as a connectivity verification method and 22 Traceroute as a fault isolation method, as described in RFC 4379. 23 When an LSP is signaled using the Entropy Label (EL) described in RFC 24 6790, the ability for LSP Ping and Traceroute operations to discover 25 and exercise ECMP paths is lost for scenarios where LSRs apply 26 different load balancing techniques. One such scenario is when some 27 LSRs apply EL-based load balancing while other LSRs apply non-EL 28 based load balancing (e.g., IP). Another scenario is when an EL- 29 based LSP is stitched with another LSP which can be EL-based or non- 30 EL based. 32 This document extends the MPLS LSP Ping and Traceroute multipath 33 mechanisms in RFC 6424 to allow the ability of exercising LSPs which 34 make use of the EL. This document updates RFC 4379, RFC 6424, and 35 RFC 6790. 37 Requirements Language 39 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 40 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 41 document are to be interpreted as described in RFC 2119 [RFC2119]. 43 Status of This Memo 45 This Internet-Draft is submitted in full conformance with the 46 provisions of BCP 78 and BCP 79. 48 Internet-Drafts are working documents of the Internet Engineering 49 Task Force (IETF). Note that other groups may also distribute 50 working documents as Internet-Drafts. The list of current Internet- 51 Drafts is at http://datatracker.ietf.org/drafts/current/. 53 Internet-Drafts are draft documents valid for a maximum of six months 54 and may be updated, replaced, or obsoleted by other documents at any 55 time. It is inappropriate to use Internet-Drafts as reference 56 material or to cite them other than as "work in progress." 58 This Internet-Draft will expire on February 12, 2017. 60 Copyright Notice 62 Copyright (c) 2016 IETF Trust and the persons identified as the 63 document authors. All rights reserved. 65 This document is subject to BCP 78 and the IETF Trust's Legal 66 Provisions Relating to IETF Documents 67 (http://trustee.ietf.org/license-info) in effect on the date of 68 publication of this document. Please review these documents 69 carefully, as they describe your rights and restrictions with respect 70 to this document. Code Components extracted from this document must 71 include Simplified BSD License text as described in Section 4.e of 72 the Trust Legal Provisions and are provided without warranty as 73 described in the Simplified BSD License. 75 Table of Contents 77 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 78 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 79 1.2. Background . . . . . . . . . . . . . . . . . . . . . . . 4 80 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 5 81 3. Multipath Type 9 . . . . . . . . . . . . . . . . . . . . . . 7 82 4. Pseudowire Tracing . . . . . . . . . . . . . . . . . . . . . 7 83 5. Entropy Label FEC . . . . . . . . . . . . . . . . . . . . . . 8 84 6. DS Flags: L and E . . . . . . . . . . . . . . . . . . . . . . 9 85 7. New Multipath Information Type: TBD4 . . . . . . . . . . . . 10 86 8. Initiating LSR Procedures . . . . . . . . . . . . . . . . . . 11 87 9. Responder LSR Procedures . . . . . . . . . . . . . . . . . . 13 88 9.1. IP Based Load Balancer & Not Pushing ELI/EL . . . . . . . 14 89 9.2. IP Based Load Balancer & Pushes ELI/EL . . . . . . . . . 14 90 9.3. Label Based Load Balancer & Not Pushing ELI/EL . . . . . 15 91 9.4. Label Based Load Balancer & Pushes ELI/EL . . . . . . . . 16 92 9.5. Flow-Aware MS-PW Stitching LSR . . . . . . . . . . . . . 17 93 10. Supported and Unsupported Cases . . . . . . . . . . . . . . . 17 94 11. Security Considerations . . . . . . . . . . . . . . . . . . . 19 95 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 96 12.1. Entropy Label FEC . . . . . . . . . . . . . . . . . . . 19 97 12.2. DS Flags . . . . . . . . . . . . . . . . . . . . . . . . 19 98 12.3. Multipath Type . . . . . . . . . . . . . . . . . . . . . 20 99 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 20 100 14. Contributing Authors . . . . . . . . . . . . . . . . . . . . 20 101 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 102 15.1. Normative References . . . . . . . . . . . . . . . . . . 20 103 15.2. Informative References . . . . . . . . . . . . . . . . . 21 104 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21 106 1. Introduction 108 1.1. Terminology 110 The following acronyms and terms are used in this document: 112 o MPLS - Multiprotocol Label Switching. 114 o LSP - Label Switched Path. 116 o LSR - Label Switching Router. 118 o FEC - Forwarding Equivalent Class. 120 o ECMP - Equal-Cost Multipath. 122 o EL - Entropy Label. 124 o ELI - Entropy Label Indicator. 126 o GAL - Generic Associated Channel Label. 128 o MS-PW - Multi-Segment Pseudowire. 130 o Initiating LSR - LSR which sends an MPLS echo request. 132 o Responder LSR - LSR which receives an MPLS echo request and sends 133 an MPLS echo reply. 135 o IP-Based Load Balancer - LSR which load balances on fields from an 136 IP header (and possibly fields from upper layers), and does not 137 consider an entropy label from an MPLS label stack (i.e., flow 138 label [RFC6391] or entropy label [RFC6790]) for load balancing 139 purposes. 141 o Label-Based Load Balancer - LSR which load balances on an entropy 142 label from an MPLS label stack (i.e., flow label or entropy 143 label), and does not consider fields from an IP header (and 144 possibly fields from upper layers) for load balancing purposes. 146 o Label and IP-Based Load Balancer - LSR which load balances on both 147 entropy labels from an MPLS label stack and fields from an IP 148 header (and possibly fields from upper layers). 150 1.2. Background 152 MPLS implementations employ a wide variety of load balancing 153 techniques in terms of fields used for hash "keys". The mechanisms 154 in [RFC4379] and updated by [RFC6424] are designed to provide 155 multipath support for a subset of techniques. The intent of this 156 document is to provide multipath support for the supported techniques 157 which are compromised by the use of ELs [RFC6790]. Section 10 158 describes supported and unsupported cases, and it may be useful for 159 the reader to first review this section. 161 The Downstream Detailed Mapping (DDMAP) TLV [RFC6424] provides 162 multipath information which can be used by an LSP Ping initiator to 163 trace and validate ECMP paths between an ingress and egress. The 164 multipath information encodings defined by [RFC6424] are sufficient 165 when all the LSRs along the path(s), between ingress and egress, 166 consider the same set of "keys" as input for load balancing 167 algorithms, e.g. either all IP-based or all label-based. 169 With the introduction of [RFC6790], some LSRs may perform load 170 balancing based on labels while others may be IP-based. This results 171 in an LSP Ping initiator to not be able to trace and validate all the 172 ECMP paths in the following scenarios: 174 o One or more transit LSRs along an LSP with ELI/EL in label stack 175 do not perform ECMP load balancing based on EL (hashes based on 176 "keys" including the IP destination address). This scenario is 177 not only possible but quite common due to transit LSRs not 178 implementing [RFC6790] or transit LSRs implementing [RFC6790], but 179 not implementing the suggested transit LSR behavior in Section 4.3 180 of [RFC6790]. 182 o Two or more LSPs stitched together with at least one of these LSPs 183 pushing ELI/EL into the label stack. 185 These scenarios can be quite common because deployments of [RFC6790] 186 typically have a mixture of nodes that support ELI/EL and nodes that 187 do not. There will also typically be a mixture of areas that support 188 ELI/EL and areas that do not. 190 As pointed out in [RFC6790], the procedures of [RFC4379] (and 191 consequently of [RFC6424]) with respect to multipath information type 192 {9} are incomplete. However, [RFC6790] does not actually update 193 [RFC4379]. Further, the specific EL location is not clearly defined, 194 particularly in the case of Flow Aware Pseudowires [RFC6391]. This 195 document defines a new FEC Stack sub-TLV for the entropy label. 196 Section 3 of this document updates the procedures for multipath 197 information type {9} described in [RFC4379] and applicable to 198 [RFC6424]. The rest of this document describes extensions required 199 to restore ECMP discovery and tracing capabilities for the scenarios 200 described. 202 [RFC4379], [RFC6424], and this document will support IP-based load 203 balancers and label-based load balancers which limit their hash to 204 the first (top-most) or only entropy label in the label stack. Other 205 use cases (refer to Section 10) are out of scope. 207 2. Overview 209 [RFC4379] describes LSP traceroute as an operation where the 210 initiating LSR sends a series of MPLS echo requests towards the same 211 destination. The first packet in the series has the TTL set to 1. 212 When the echo reply is received from the LSR one hop away, the second 213 echo request in the series is sent with the TTL set to 2. For each 214 additional echo request the TLL is incremented by one until a 215 response is received from the intended destination. The initiating 216 LSR discovers and exercises ECMP by obtaining multipath information 217 from each transit LSR and using a specific destination IP address or 218 specific entropy label. 220 From here on, the notation {x, y, z} refers to multipath information 221 types x, y or z. Multipath information types are defined in 222 Section 3.3 of [RFC4379]. 224 The LSR initiating LSP Ping sends an MPLS echo request with multipath 225 information. This multipath information is described in the echo 226 request's DDMAP TLV, and may contain a set of IP addresses or a set 227 of labels. Multipath information types {2, 4, 8} carry a set of IP 228 addresses, and multipath information type {9} carries a set of 229 labels. The responder LSR (the receiver of the MPLS echo request) 230 will determine the subset of initiator-specified multipath 231 information which load balances to each downstream (outgoing 232 interface). The responder LSR sends an MPLS echo reply with 233 resulting multipath information per downstream (outgoing interface) 234 back to the initiating LSR. The initiating LSR is then able to use a 235 specific IP destination address or a specific label to exercise a 236 specific ECMP path on the responder LSR. 238 Current behavior is problematic in following scenarios: 240 o The initiating LSR sends IP multipath information, but the 241 responder LSR load balances on labels. 243 o The initiating LSR sends label multipath information, but the 244 responder LSR load balances on IP addresses. 246 o The initiating LSR sends existing multipath information to an LSR 247 which pushes ELI/EL in the label stack, but the initiating LSR can 248 only continue to discover and exercise specific paths of the ECMP, 249 if the LSR which pushes ELI/EL responds with both IP addresses and 250 the associated EL corresponding to each IP address. This is 251 because: 253 * An ELI/EL pushing LSR that is a stitching point will load 254 balance based on the IP address. 256 * Downstream LSR(s) of an ELI/EL pushing LSR may load balance 257 based on ELs. 259 o The initiating LSR sends existing multipath information to an ELI/ 260 EL pushing LSR, but the initiating LSR can only continue to 261 discover and exercise specific paths of ECMP, if the ELI/EL 262 pushing LSR responds with both labels and associated EL 263 corresponding to the label. This is because: 265 * An ELI/EL pushing LSR that is a stitching point will load 266 balance based on EL from the previous LSP and pushes a new EL. 268 * Downstream LSR(s) of ELI/EL pushing LSR may load balance based 269 on new ELs. 271 The above scenarios demonstrate the existing multipath information is 272 insufficient when LSP traceroute is used on an LSP with entropy 273 labels [RFC6790]. This document defines a new multipath information 274 type to be used in the DDMAP of MPLS echo request/reply packets for 275 [RFC6790] LSPs. 277 The responder LSR can reply with empty multipath information if no IP 278 address is set or label set is received with the multipath 279 information. An empty return is also possible if an initiating LSR 280 sends multipath information of one type, IP address or label, but the 281 responder LSR load balances on the other type. To disambiguate 282 between the two results, this document introduces new flags in the 283 DDMAP TLV to allow the responder LSR to describe the load balancing 284 technique being used. 286 All LSRs along the LSP need to be able to understand the new flags 287 and the new multipath information type. It is also required that the 288 initiating LSR can select both the IP destination address and label 289 to use when transmitting MPLS echo request packets. Two additional 290 DS Flags are defined for the DDMAP TLV in Section 6. These two flags 291 are used by the responder LSR to describe its load balance behavior 292 on a received MPLS echo request. 294 Note that the terms "IP-Based Load Balancer" and "Label-Based Load 295 Balancer" are in context of how a received MPLS echo request is 296 handled by the responder LSR. 298 3. Multipath Type 9 300 [RFC4379] defined multipath type {9} for tracing of LSPs where label 301 based load balancing is used. However, as pointed out in [RFC6790], 302 the procedures for using this type are incomplete as the specific 303 location of the label was not defined. It was assumed that the 304 presence of multipath type {9} implied the value of the bottom-of- 305 stack label should be varied by the values indicated by multipath to 306 determine the respective outgoing interfaces. 308 Section 5 defines a new FEC-Stack sub-TLV to indicate an entropy 309 label. These labels MAY appear anywhere in a label stack. 311 Multipath type {9} applies to the first label in the label stack that 312 corresponds to an EL-FEC. If no such label is found, it applies to 313 the label at the bottom of the label stack. 315 4. Pseudowire Tracing 317 This section defines procedures for tracing pseudowires. These 318 procedures pertain to the use of multipath information type {9} as 319 well as type {TBD4}. In all cases below, when a control word is in 320 use, the N-flag in the DDMAP MUST be set. Note that when a control 321 word is not in use, the returned DDMAPs may not be accurate. 323 In order to trace a non-flow-aware Pseudowire, the initiator includes 324 an EL-FEC instead of the appropriate PW-FEC at the bottom of the FEC 325 stack. Tracing in this way will cause compliant routers to return 326 the proper outgoing interface. Note that this procedure only traces 327 to the end of the MPLS LSP that is under test and will not verify the 328 PW FEC. To actually verify the PW FEC or in the case of a MS-PW, to 329 determine the next pseudowire label value, the initiator MUST repeat 330 that step of the trace (i.e., repeating the TTL value used) but with 331 the FEC Stack modified to contain the appropriate PW FEC. Note that 332 these procedures are applicable to scenarios where an initiator is 333 able to vary the bottom label (i.e., Pseudowire label). Possible 334 scenarios are tracing multiple non-flow-aware Pseudowires on the same 335 endpoints or tracing a non-flow-aware Pseudowire provisioned with 336 multiple Pseudowire labels. 338 In order to trace a flow-aware Pseudowire [RFC6391], the initiator 339 includes an EL FEC at the bottom of the FEC Stack and pushes the 340 appropriate PW FEC onto the FEC Stack. 342 In order to trace through non-compliant routers, the initiator forms 343 an MPLS echo request message and includes a DDMAP with multipath type 344 {9}. For a non-flow-aware Pseudowire it includes the appropriate PW 345 FEC in the FEC Stack. For a flow-aware Pseudowire, the initiator 346 includes a Nil FEC at the bottom of the FEC Stack and pushes the 347 appropriate PW FEC onto the FEC Stack. 349 5. Entropy Label FEC 351 The entropy label indicator (ELI) is a reserved label that has no 352 explicit FEC associated, and has label value 7 assigned from the 353 reserved range. Use the Nil FEC as the Target FEC Stack sub-TLV to 354 account for ELI in a Target FEC Stack TLV. 356 The entropy label (EL) is a special purpose label with the label 357 value being discretionary (i.e., the label value is not from the 358 reserved range). For LSP verification mechanics to perform its 359 purpose, it is necessary for a Target FEC Stack sub-TLV to clearly 360 describe the EL, particularly in the scenario where the label stack 361 does not carry ELI (e.g., flow-aware Pseudowire [RFC6391]). 362 Therefore, this document defines an EL FEC sub-TLV (TBD1, see 363 Section 12.1) to allow a Target FEC Stack sub-TLV to be added to the 364 Target FEC Stack to account for EL. 366 The Length is 4. Labels are 20-bit values treated as numbers. 368 0 1 2 3 369 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 370 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 371 | Label | MBZ | 372 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 374 Figure 1: Entropy Label FEC 376 Label is the actual label value inserted in the label stack; the MBZ 377 field MUST be zero when sent and ignored on receipt. 379 6. DS Flags: L and E 381 Two flags, L and E, are added to the DS Flags field of the DDMAP TLV. 382 Both flags MUST NOT be set in echo request packets when sending, and 383 SHOULD be ignored when received. Zero, one or both new flags MUST be 384 set in echo reply packets. 386 DS Flags 387 -------- 389 0 1 2 3 4 5 6 7 390 +-+-+-+-+-+-+-+-+ 391 | MBZ |L|E|I|N| 392 +-+-+-+-+-+-+-+-+ 394 RFC-Editor-Note: Please update the above figure to place the flag E 395 in the bit number TBD2 and the flag L in the bit number TBD3. 397 Flag Name and Meaning 398 ---- ---------------- 399 L Label-based load balance indicator 400 This flag MUST be set to zero in the echo request. An LSR 401 which performs load balancing on a label MUST set this 402 flag in the echo reply. An LSR which performs load 403 balancing on IP MUST NOT set this flag in the echo 404 reply. 406 E ELI/EL push indicator 407 This flag MUST be set to zero in the echo request. An LSR 408 which pushes ELI/EL MUST set this flag in the echo 409 reply. An LSR which does not push ELI/EL MUST NOT set 410 this flag in the echo reply. 412 The two flags result in four load balancing techniques which the echo 413 reply generating LSR can indicate: 415 o {L=0, E=0} LSR load balances based on IP and does not push ELI/EL. 417 o {L=0, E=1} LSR load balances based on IP and pushes ELI/EL. 419 o {L=1, E=0} LSR load balances based on labels and does not push 420 ELI/EL. 422 o {L=1, E=1} LSR load balances based on labels and pushes ELI/EL. 424 7. New Multipath Information Type: TBD4 426 One new multipath information type is added to be used in DDMAP TLV. 427 This new multipath type has the value of TBD4. 429 Key Type Multipath Information 430 --- ---------------- --------------------- 431 TBD4 IP and label set IP addresses and label prefixes 433 Multipath type TBD4 is comprised of three sections. The first 434 section describes the IP address set. The second section describes 435 the label set. The third section describes another label set which 436 associates to either the IP address set or the label set specified in 437 the other sections. 439 Multipath information type TBD4 has following format: 441 0 1 2 3 442 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 443 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 444 |IPMultipathType| IP Multipath Length | Reserved(MBZ) | 445 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 446 ~ ~ 447 | (IP Multipath Information) | 448 ~ ~ 449 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 450 |LbMultipathType| Label Multipath Length | Reserved(MBZ) | 451 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 452 ~ ~ 453 | (Label Multipath Information) | 454 ~ ~ 455 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 456 | Assoc Label Multipath Length | Reserved(MBZ) | 457 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 458 ~ ~ 459 | (Associated Label Multipath Information) | 460 ~ ~ 461 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 463 Figure 2: Multipath Information Type TBD4 465 o IPMultipathType 467 * 0 when "IP Multipath Information" is omitted. Otherwise, one 468 of the IP multipath information values: {2, 4, 8}. 470 o IP Multipath Information 471 * This section is omitted when "IPMultipathType" is 0. 472 Otherwise, this section reuses IP multipath information from 473 [RFC4379]. Specifically, multipath information for values {2, 474 4, 8} can be used. 476 o LbMultipathType 478 * 0 when "Label Multipath Information" is omitted. Otherwise, 479 label multipath information value {9}. 481 o Label Multipath Information 483 * This section is omitted when "LbMultipathType" is 0. 484 Otherwise, this section reuses label multipath information from 485 [RFC4379]. Specifically, multipath information for value {9} 486 can be used. 488 o Associated Label Multipath Information 490 * "Assoc Label Multipath Length" is a 16 bit field of multipath 491 information which indicates the length in octets of the 492 associated label multipath information. 494 * "Associated Label Multipath Information" is a list of labels 495 with each label described in 24 bits. This section MUST be 496 omitted in an MPLS echo request message. A midpoint which 497 pushes ELI/EL labels SHOULD include "Assoc Label Multipath 498 Information" in its MPLS echo reply message, along with either 499 "IP Multipath Information" or "Label Multipath Information". 500 Each specified associated label described in this section maps 501 to a specific IP address OR label described in the "IP 502 Multipath Information" section or "Label Multipath Information" 503 section. For example, if three IP addresses are specified in 504 the "IP Multipath Information" section, then there MUST be 505 three labels described in this section. The first label maps 506 to the first IP address specified, the second label maps to the 507 second IP address specified, and the third label maps to the 508 third IP address specified. 510 When a section is omitted, the length for that section MUST BE set to 511 zero. 513 8. Initiating LSR Procedures 515 The following procedure is described in terms of an EL_LSP boolean 516 maintained by the initiating LSR. This value controls the multipath 517 information type to be used in the transmitted echo request packets. 518 When the initiating LSR is transmitting an echo request packet with 519 DDMAP with a non-zero multipath information type, then the EL_LSP 520 boolean MUST be consulted to determine the multipath information type 521 to use. 523 In addition to procedures described in [RFC4379], as updated by 524 Section 3 and [RFC6424], the initiating LSR MUST operate with the 525 following procedures: 527 o When the initiating LSR pushes ELI/EL, initialize EL_LSP=True. 528 Else set EL_LSP=False. 530 o When the initiating LSR is transmitting a non-zero multipath 531 information type: 533 * If (EL_LSP), the initiating LSR MUST use multipath information 534 type {TBD4} unless the responder LSR cannot handle type {TBD4}. 535 When the initiating LSR is transmitting multipath information 536 type {TBD4}, both "IP Multipath Information" and "Label 537 Multipath Information" MUST be included, and "IP Associated 538 Label Multipath Information" MUST be omitted (NULL). 540 * Else the initiating LSR MAY use multipath information type {2, 541 4, 8, 9, TBD4}. When the initiating LSR is transmitting 542 multipath information type {TBD4} in this case, "IP Multipath 543 Information" MUST be included, and "Label Multipath 544 Information" and "IP Associated Label Multipath Information" 545 MUST be omitted (NULL). 547 o When the initiating LSR receives echo reply with {L=0, E=1} in DS 548 flags with valid contents, set EL_LSP=True. 550 In the following conditions, the initiating LSR may have lost the 551 ability to exercise specific ECMP paths. The initiating LSR MAY 552 continue with "best effort" in the following cases: 554 o Received echo reply contains empty multipath information. 556 o Received echo reply contains {L=0, E=} DS flags, but does not 557 contain IP multipath information. 559 o Received echo reply contains {L=1, E=} DS flags, but does not 560 contain label multipath information. 562 o Received echo reply contains {L=, E=1} DS flags, but does not 563 contain associated label multipath information. 565 o IP multipath information types {2, 4, 8} sent, and received echo 566 reply with {L=1, E=0} in DS flags. 568 o Multipath information type {TBD4} sent, and received echo reply 569 with multipath information type other than {TBD4}. 571 9. Responder LSR Procedures 573 Common Procedures: 575 o The responder LSR receiving an MPLS echo request packet MUST first 576 determine whether or not the initiating LSR supports this LSP Ping 577 and Traceroute extension for Entropy Labels. If either of the 578 following conditions are met, the responder LSR SHOULD determine 579 that the initiating LSR supports this LSP Ping and Traceroute 580 extension for entropy labels. 582 1. Received MPLS echo request contains the multipath information 583 type {TBD4}. 585 2. Received MPLS echo request contains a Target FEC Stack TLV 586 that includes the entropy label FEC. 588 If the initiating LSR is determined to not support this LSP Ping 589 and Traceroute extension for entropy labels, then the responder 590 LSR MUST NOT follow further procedures described in this section. 591 Specifically, MPLS echo reply packets: 593 * MUST have following DS Flags cleared (i.e., not set): "ELI/EL 594 push indicator" and "Label-based load balance indicator". 596 * MUST NOT use multipath information type {TBD4}. 598 o The responder LSR receiving an MPLS echo request packet with 599 multipath information type {TBD4} MUST validate the following 600 contents. Any deviation MUST result in the responder LSR to 601 consider the packet as malformed and return code 1 ("Malformed 602 echo request received") in the MPLS echo reply packet. 604 * IP multipath information MUST be included. 606 * Label multipath information MAY be included. 608 * IP associated label multipath information MUST be omitted 609 (NULL). 611 The following subsections describe expected responder LSR procedures 612 when the echo reply is to include DDMAP TLVs, based on the local load 613 balance technique being employed. In case the responder LSR performs 614 deviating load balance techniques on a per downstream basis, 615 appropriate procedures matched to each downstream load balance 616 technique MUST be followed. 618 9.1. IP Based Load Balancer & Not Pushing ELI/EL 620 o The responder MUST set {L=0, E=0} in DS flags. 622 o If multipath information type {2, 4, 8} is received, the responder 623 MUST comply with [RFC4379] and [RFC6424]. 625 o If multipath information type {9} is received, the responder MUST 626 reply with multipath type {0}. 628 o If multipath information type {TBD4} is received, the following 629 procedures are to be used: 631 * The responder MUST reply with multipath information type 632 {TBD4}. 634 * The "Label Multipath Information" and "Associated Label 635 Multipath Information" sections MUST be omitted (NULL). 637 * If no matching IP address is found, then the "IPMultipathType" 638 field MUST be set to multipath information type {0} and the "IP 639 Multipath Information" section MUST also be omitted (NULL). 641 * If at least one matching IP address is found, then the 642 "IPMultipathType" field MUST be set to appropriate multipath 643 information type {2, 4, 8} and the "IP Multipath Information" 644 section MUST be included. 646 9.2. IP Based Load Balancer & Pushes ELI/EL 648 o The responder MUST set {L=0, E=1} in DS flags. 650 o If multipath information type {9} is received, the responder MUST 651 reply with multipath type {0}. 653 o If multipath type {2, 4, 8, TBD4} is received, the following 654 procedures are to be used: 656 * The responder MUST respond with multipath type {TBD4}. See 657 Section 7 for details of multipath type {TBD4}. 659 * The "Label Multipath Information" section MUST be omitted 660 (i.e., it is not there). 662 * The IP address set specified in the received IP multipath 663 information MUST be used to determine the returning IP/Label 664 pairs. 666 * If the received multipath information type was {TBD4}, the 667 received "Label Multipath Information" sections MUST NOT be 668 used to determine the associated label portion of returning IP/ 669 Label pairs. 671 * If no matching IP address is found, then the "IPMultipathType" 672 field MUST be set to multipath information type {0} and the "IP 673 Multipath Information" section MUST be omitted. In addition, 674 the "Assoc Label Multipath Length" MUST be set to 0, and the 675 "Associated Label Multipath Information" section MUST also be 676 omitted. 678 * If at least one matching IP address is found, then the 679 "IPMultipathType" field MUST be set to appropriate multipath 680 information type {2, 4, 8} and the "IP Multipath Information" 681 section MUST be included. In addition, the "Associated Label 682 Multipath Information" section MUST be populated with a list of 683 labels corresponding to each IP address specified in the "IP 684 Multipath Information" section. "Assoc Label Multipath Length" 685 MUST be set to a value representing the length in octets of the 686 "Associated Label Multipath Information" field. 688 9.3. Label Based Load Balancer & Not Pushing ELI/EL 690 o The responder MUST set {L=1, E=0} in DS flags. 692 o If multipath information type {2, 4, 8} is received, the responder 693 MUST reply with multipath type {0}. 695 o If multipath information type {9} is received, the responder MUST 696 comply with [RFC4379] and [RFC6424] as updated by Section 3. 698 o If multipath information type {TBD4} is received, the following 699 procedures are to be used: 701 * The responder MUST reply with multipath information type 702 {TBD4}. 704 * The "IP Multipath Information" and "Associated Label Multipath 705 Information" sections MUST be omitted (NULL). 707 * If no matching label is found, then the "LbMultipathType" field 708 MUST be set to multipath information type {0} and the "Label 709 Multipath Information" section MUST also be omitted (NULL). 711 * If at least one matching label is found, then the 712 "LbMultipathType" field MUST be set to the appropriate 713 multipath information type {9} and the "Label Multipath 714 Information" section MUST be included. 716 9.4. Label Based Load Balancer & Pushes ELI/EL 718 o The responder MUST set {L=1, E=1} in DS flags. 720 o If multipath information type {2, 4, 8} is received, the responder 721 MUST reply with multipath type {0}. 723 o If multipath type {9, TBD4} is received, the following procedures 724 are to be used: 726 * The responder MUST respond with multipath type {TBD4}. 728 * The "IP Multipath Information" section MUST be omitted. 730 * The label set specified in the received label multipath 731 information MUST be used to determine the returning Label/Label 732 pairs. 734 * If received multipath information type was {TBD4}, received 735 "Label Multipath Information" sections MUST NOT be used to 736 determine the associated label portion of returning Label/Label 737 pairs. 739 * If no matching label is found, then the "LbMultipathType" field 740 MUST be set to multipath information type {0} and "Label 741 Multipath Information" section MUST be omitted. In addition, 742 "Assoc Label Multipath Length" MUST be set to 0, and the 743 "Associated Label Multipath Information" section MUST also be 744 omitted. 746 * If at least one matching label is found, then the 747 "LbMultipathType" field MUST be set to the appropriate 748 multipath information type {9} and the "Label Multipath 749 Information" section MUST be included. In addition, the 750 "Associated Label Multipath Information" section MUST be 751 populated with a list of labels corresponding to each label 752 specified in the "Label Multipath Information" section. "Assoc 753 Label Multipath Length" MUST be set to a value representing the 754 length in octets of the "Associated Label Multipath 755 Information" field. 757 9.5. Flow-Aware MS-PW Stitching LSR 759 A stitching LSR that cross-connects flow-aware Pseudowires behaves in 760 one of two ways: 762 o Load balances on the previous flow label, and carries over the 763 same flow label. For this case, the stitching LSR is to behave as 764 described in Section 9.3. 766 o Load balances on the previous flow label, and replaces the flow 767 label with a newly computed label. For this case, the stitching 768 LSR is to behave as described in Section 9.4. 770 10. Supported and Unsupported Cases 772 The MPLS architecture does not define strict rules on how 773 implementations are to identify hash "keys" for load balancing 774 purpose. As a result, implementations may be of the following load 775 balancer types: 777 1. IP-based load balancer. 778 2. Label-based load balancer. 779 3. Label- and IP-based load balancer. 781 For cases (2) and (3), an implementation can include different sets 782 of labels from the label stack for load balancing purpose. Thus the 783 following sub-cases are possible: 785 a. Entire label stack. 786 b. Top N labels from label stack where the number of labels in label 787 stack is >N. 788 c. Bottom N labels from label stack where the number of labels in 789 label stack is >N. 791 In a scenario where there is one flow label or entropy label present 792 in the label stack, the following further cases are possible for 793 (2b), (2c), (3b) and (3c): 795 1. N labels from label stack include flow label or entropy label. 796 2. N labels from label stack do not include flow label or entropy 797 label. 799 Also in a scenario where there are multiple entropy labels present in 800 the label stack, it is possible for implementations to employ 801 deviating techniques: 803 o Search for entropy stops at the first entropy label. 805 o Search for entropy includes any entropy label found plus continues 806 to search for entropy in the label stack. 808 Furthermore, handling of reserved (i.e., special) labels varies among 809 implementations: 811 o Reserved labels are used in the hash as any other label would be 812 (not a recommended practice). 813 o Reserved labels are skipped over and, for implementations limited 814 to N labels, the reserved labels do not count towards the limit of 815 N. 816 o Reserved labels are skipped over and, for implementations limited 817 to N labels, the reserved labels count towards the limit of N. 819 It is important to point this out since the presence of GAL will 820 affect those implementations which include reserved labels for load 821 balancing purposes. 823 As can be seen from the above, there are many types of potential load 824 balancing implementations. Attempting for any OAM tools to support 825 ECMP discovery and traversal over all types would require fairly 826 complex procedures. Complexities in OAM tools have minimal benefit 827 if the majority of implementations are expected to employ only a 828 small subset of the cases described above. 830 o Section 4.3 of [RFC6790] states that in implementations, for load 831 balancing purposes, parsing beyond the label stack after finding 832 an entropy label has "limited incremental value". Therefore, it 833 is expected that most implementations will be of types "IP-based 834 load balancer" or "Label-based load balancer". 836 o Section 2.4.5.1 of [RFC7325] recommends that searching for entropy 837 labels in the label stack should terminate upon finding the first 838 entropy label. Therefore, it is expected that implementations 839 will only include the first (top-most) entropy label when there 840 are multiple entropy labels in the label stack. 842 o It is expected that, in most cases, the number of labels in the 843 label stack will not exceed number of labels (N) which 844 implementations can include for load balancing purposes. 846 o It is expected that labels in the label stack, besides the flow 847 label and entropy label, are constant for the lifetime of a single 848 LSP multipath traceroute operation. Therefore, deviating load 849 balancing implementations with respect to reserved labels should 850 not affect this tool. 852 Thus [RFC4379], [RFC6424], and this document supports cases (1) and 853 (2a1), where only the first (top-most) entropy label is included when 854 there are multiple entropy labels in the label stack. 856 11. Security Considerations 858 This document extends the LSP Ping and Traceroute mechanisms to 859 discover and exercise ECMP paths when an LSP uses ELI/EL in the label 860 stack. Additional processing is required for responder and initiator 861 nodes. The responder node that pushes ELI/EL will need to compute 862 and return multipath data including associated EL. The initiator 863 node will need to store and handle both IP multipath and label 864 multipath information, and include destination IP addresses and/or 865 ELs in MPLS echo request packets as well as in multipath information 866 sent to downstream nodes. This document does not itself introduce 867 any new security considerations. The security measures described in 868 [RFC4379], [RFC6424], and [RFC6790] are applicable. [RFC6424] 869 provides guidelines if a network operator wants to prevent tracing or 870 does not want to expose details of the tunnel and [RFC6790] provides 871 guidance on the use of the EL. 873 12. IANA Considerations 875 12.1. Entropy Label FEC 877 The IANA is requested to assign a new sub-TLV from the "Sub-TLVs for 878 TLV Types 1, 16, and 21" section from the "Multi-Protocol Label 879 Switching (MPLS) Label Switched Paths (LSPs) Ping Parameters - TLVs" 880 registry ([IANA-MPLS-LSP-PING]). 882 Sub-Type Sub-TLV Name Reference 883 -------- ------------ --------- 884 TBD1 Entropy label FEC this document 886 12.2. DS Flags 888 The IANA is requested to assign new bit numbers from the "DS flags" 889 sub-registry from the "Multi-Protocol Label Switching (MPLS) Label 890 Switched Paths (LSPs) Ping Parameters - TLVs" registry 891 ([IANA-MPLS-LSP-PING]). 893 Note: the "DS flags" sub-registry is created by [RFC7537]. 895 Bit number Name Reference 896 ---------- ---------------------------------------- --------- 897 TBD2 E: ELI/EL push indicator this document 898 TBD3 L: Label-based load balance indicator this document 900 12.3. Multipath Type 902 The IANA is requested to assign a new value from the "Multipath Type" 903 sub-registry from the "Multi-Protocol Label Switching (MPLS) Label 904 Switched Paths (LSPs) Ping Parameters - TLVs" registry 905 ([IANA-MPLS-LSP-PING]). 907 Note: The "Multipath Type" sub-registry is created by [RFC7537]. 909 Value Meaning Reference 910 ---------- ---------------------------------------- --------- 911 TBD4 IP and label set this document 913 13. Acknowledgements 915 The authors would like to thank Loa Andersson, Curtis Villamizar, 916 Daniel King, Sriganesh Kini, Victor Ji, and Acee Lindem for 917 performing thorough reviews and providing valuable comments. 919 14. Contributing Authors 921 Nagendra Kumar 922 Cisco Systems, Inc. 923 Email: naikumar@cisco.com 925 15. References 927 15.1. Normative References 929 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 930 Requirement Levels", BCP 14, RFC 2119, 931 DOI 10.17487/RFC2119, March 1997, 932 . 934 [RFC4379] Kompella, K. and G. Swallow, "Detecting Multi-Protocol 935 Label Switched (MPLS) Data Plane Failures", RFC 4379, 936 DOI 10.17487/RFC4379, February 2006, 937 . 939 [RFC6424] Bahadur, N., Kompella, K., and G. Swallow, "Mechanism for 940 Performing Label Switched Path Ping (LSP Ping) over MPLS 941 Tunnels", RFC 6424, DOI 10.17487/RFC6424, November 2011, 942 . 944 [RFC6790] Kompella, K., Drake, J., Amante, S., Henderickx, W., and 945 L. Yong, "The Use of Entropy Labels in MPLS Forwarding", 946 RFC 6790, DOI 10.17487/RFC6790, November 2012, 947 . 949 [RFC7537] Decraene, B., Akiya, N., Pignataro, C., Andersson, L., and 950 S. Aldrin, "IANA Registries for LSP Ping Code Points", 951 RFC 7537, DOI 10.17487/RFC7537, May 2015, 952 . 954 15.2. Informative References 956 [IANA-MPLS-LSP-PING] 957 IANA, "Multi-Protocol Label Switching (MPLS) Label 958 Switched Paths (LSPs) Ping Parameters", 959 . 962 [RFC6391] Bryant, S., Ed., Filsfils, C., Drafz, U., Kompella, V., 963 Regan, J., and S. Amante, "Flow-Aware Transport of 964 Pseudowires over an MPLS Packet Switched Network", 965 RFC 6391, DOI 10.17487/RFC6391, November 2011, 966 . 968 [RFC7325] Villamizar, C., Ed., Kompella, K., Amante, S., Malis, A., 969 and C. Pignataro, "MPLS Forwarding Compliance and 970 Performance Requirements", RFC 7325, DOI 10.17487/RFC7325, 971 August 2014, . 973 Authors' Addresses 975 Nobo Akiya 976 Big Switch Networks 978 Email: nobo.akiya.dev@gmail.com 980 George Swallow 981 Cisco Systems, Inc. 983 Email: swallow@cisco.com 985 Carlos Pignataro 986 Cisco Systems, Inc. 988 Email: cpignata@cisco.com 990 Andrew G. Malis 991 Huawei Technologies 993 Email: agmalis@gmail.com 994 Sam Aldrin 995 Google 997 Email: aldrin.ietf@gmail.com