idnits 2.17.1 draft-ietf-mpls-lsp-ping-lag-multipath-05.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 : ---------------------------------------------------------------------------- ** There is 1 instance of too long lines in the document, the longest one being 1 character in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (October 23, 2018) is 2010 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) No issues found here. Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). 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: 8029 (if approved) G. Swallow 5 Intended status: Standards Track Cisco Systems 6 Expires: April 26, 2019 S. Litkowski 7 B. Decraene 8 Orange 9 J. Drake 10 Juniper Networks 11 M. Chen 12 Huawei 13 October 23, 2018 15 Label Switched Path (LSP) Ping/Trace Multipath Support for 16 Link Aggregation Group (LAG) Interfaces 17 draft-ietf-mpls-lsp-ping-lag-multipath-05 19 Abstract 21 This document defines extensions to the MPLS Label Switched Path 22 (LSP) Ping and Traceroute mechanisms as specified in RFC 8029. The 23 extensions allow the MPLS LSP Ping and Traceroute mechanisms to 24 discover and exercise specific paths of Layer 2 (L2) Equal-Cost 25 Multipath (ECMP) over Link Aggregation Group (LAG) interfaces. 26 Additionally, a mechanism is defined to enable determination of the 27 capabilities of an LSR supported. 29 This document updates RFC8029. 31 Requirements Language 33 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 34 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 35 "OPTIONAL" in this document are to be interpreted as described in 36 BCP14 [RFC2119][RFC8174] when, and only when, they appear in all 37 capitals, as shown here. 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 https://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 April 26, 2019. 56 Copyright Notice 58 Copyright (c) 2018 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 (https://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. Background . . . . . . . . . . . . . . . . . . . . . . . 3 76 2. Overview of Solution . . . . . . . . . . . . . . . . . . . . 4 77 3. LSR Capability Discovery . . . . . . . . . . . . . . . . . . 6 78 3.1. Initiator LSR Procedures . . . . . . . . . . . . . . . . 7 79 3.2. Responder LSR Procedures . . . . . . . . . . . . . . . . 7 80 4. Mechanism to Discover L2 ECMP Multipath . . . . . . . . . . . 7 81 4.1. Initiator LSR Procedures . . . . . . . . . . . . . . . . 7 82 4.2. Responder LSR Procedures . . . . . . . . . . . . . . . . 8 83 4.3. Additional Initiator LSR Procedures . . . . . . . . . . . 10 84 5. Mechanism to Validate L2 ECMP Traversal . . . . . . . . . . . 11 85 5.1. Incoming LAG Member Links Verification . . . . . . . . . 11 86 5.1.1. Initiator LSR Procedures . . . . . . . . . . . . . . 11 87 5.1.2. Responder LSR Procedures . . . . . . . . . . . . . . 12 88 5.1.3. Additional Initiator LSR Procedures . . . . . . . . . 12 89 5.2. Individual End-to-End Path Verification . . . . . . . . . 13 90 6. LSR Capability TLV . . . . . . . . . . . . . . . . . . . . . 14 91 7. LAG Description Indicator Flag: G . . . . . . . . . . . . . . 15 92 8. Local Interface Index Sub-TLV . . . . . . . . . . . . . . . . 16 93 9. Remote Interface Index Sub-TLV . . . . . . . . . . . . . . . 17 94 10. Detailed Interface and Label Stack TLV . . . . . . . . . . . 17 95 10.1. Sub-TLVs . . . . . . . . . . . . . . . . . . . . . . . . 19 96 10.1.1. Incoming Label Stack Sub-TLV . . . . . . . . . . . . 19 97 10.1.2. Incoming Interface Index Sub-TLV . . . . . . . . . . 20 98 11. Security Considerations . . . . . . . . . . . . . . . . . . . 21 99 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 100 12.1. LSR Capability TLV . . . . . . . . . . . . . . . . . . . 21 101 12.1.1. LSR Capability Flags . . . . . . . . . . . . . . . . 21 102 12.2. Local Interface Index Sub-TLV . . . . . . . . . . . . . 22 103 12.2.1. Interface Index Flags . . . . . . . . . . . . . . . 22 104 12.3. Remote Interface Index Sub-TLV . . . . . . . . . . . . . 22 105 12.4. Detailed Interface and Label Stack TLV . . . . . . . . . 23 106 12.4.1. Sub-TLVs for TLV Type TBD4 . . . . . . . . . . . . . 23 107 12.5. DS Flags . . . . . . . . . . . . . . . . . . . . . . . . 23 108 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 24 109 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 24 110 14.1. Normative References . . . . . . . . . . . . . . . . . . 24 111 14.2. Informative References . . . . . . . . . . . . . . . . . 24 112 Appendix A. LAG with intermediate L2 Switch Issues . . . . . . . 25 113 A.1. Equal Numbers of LAG Members . . . . . . . . . . . . . . 25 114 A.2. Deviating Numbers of LAG Members . . . . . . . . . . . . 25 115 A.3. LAG Only on Right . . . . . . . . . . . . . . . . . . . . 26 116 A.4. LAG Only on Left . . . . . . . . . . . . . . . . . . . . 26 117 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26 119 1. Introduction 121 1.1. Terminology 123 The following acronyms/terms are used in this document: 125 o MPLS - Multiprotocol Label Switching. 127 o LSP - Label Switched Path. 129 o LSR - Label Switching Router. 131 o ECMP - Equal-Cost Multipath. 133 o LAG - Link Aggregation Group. 135 o Initiator LSR - LSR which sends MPLS echo request. 137 o Responder LSR - LSR which receives MPLS echo request and sends 138 MPLS echo reply. 140 1.2. Background 142 The MPLS Label Switched Path (LSP) Ping and Traceroute mechanisms 143 [RFC8029] are powerful tools designed to diagnose all available Layer 144 3 (L3) paths of LSPs, including diagnostic coverage of L3 Equal-Cost 145 Multipath (ECMP). In many MPLS networks, Link Aggregation Group 146 (LAG) as defined in [IEEE802.1AX], which provides Layer 2 (L2) ECMP, 147 is often used for various reasons. MPLS LSP Ping and Traceroute 148 tools were not designed to discover and exercise specific paths of L2 149 ECMP. This raises a limitation for the following scenario when an 150 LSP traverses over a LAG: 152 o Label switching over some member links of the LAG is successful, 153 but will be failed over other member links of the LAG. 155 o MPLS echo request for the LSP over the LAG is load balanced on one 156 of the member links which is label switching successfully. 158 With the above scenarios, MPLS LSP Ping and Traceroute will not be 159 able to detect the label switching failure of the problematic member 160 link(s) of the LAG. In other words, lack of L2 ECMP diagnostic 161 coverage can produce an outcome where MPLS LSP Ping and Traceroute 162 can be blind to label switching failures over a problematic LAG 163 interface. It is, thus, desirable to extend the MPLS LSP Ping and 164 Traceroute to have deterministic diagnostic coverage of LAG 165 interfaces. 167 The need for a solution of this problem was motivated by issues 168 encountered in live networks. 170 2. Overview of Solution 172 This document defines an optional TLV to discover the capabilities of 173 a responder LSR and extensions for use with the MPLS LSP Ping and 174 Traceroute mechanisms to describe Multipath Information for 175 individual LAG member links, thus allowing MPLS LSP Ping and 176 Traceroute to discover and exercise specific paths of L2 ECMP over 177 LAG interfaces. The reader is expected to be familiar with mechanics 178 of Downstream Mapping described in Section 3.3 of [RFC8029] and 179 Downstream Detailed Mapping TLV (DDMAP) described in Section 3.4 of 180 [RFC8029]. 182 The solution consists of the MPLS echo request containing a DDMAP TLV 183 and the optional LSR capability TLV to indicate that separate load 184 balancing information for each L2 nexthop over LAG is desired in the 185 MPLS echo reply. The Responder LSR places the same optional LSR 186 capability TLV in the MPLS echo reply to provide acknowledgement back 187 to the initiator LSR. It also adds, for each downstream LAG member, 188 load balance information (i.e., multipath information and interface 189 index). This mechanism is applicable to all types of LSPs which can 190 traverse over LAG interfaces. Many LAGs are built from p2p links, 191 with router X and router X+1 having direct connectivity and the same 192 number of LAG members. It is possible to build LAGs asymmetrically 193 by using Ethernet switches between two routers. Appendix A lists 194 some use cases for which the mechanisms defined in this document may 195 not be applicable. Note that the mechanisms described in this 196 document do not impose any changes to scenarios where an LSP is 197 pinned down to a particular LAG member (i.e. the LAG is not treated 198 as one logical interface by the LSP). 200 The following figure and description provides an example using an LDP 201 network. 203 <----- LDP Network -----> 205 +-------+ 206 | | 207 A-------B=======C-------E 208 | | 209 +-------D-------+ 211 ---- Non-LAG 212 ==== LAG comprising of two member links 214 Figure 1: Example LDP Network 216 When node A is initiating LSP Traceroute to node E, node B will 217 return to node A load balance information for following entries. 219 1. Downstream C over Non-LAG (upper path). 221 2. First Downstream C over LAG (middle path). 223 3. Second Downstream C over LAG (middle path). 225 4. Downstream D over Non-LAG (lower path). 227 This document defines: 229 o In Section 3, a mechanism to discover capabilities of responder 230 LSRs; 232 o In Section 4, a mechanism to discover L2 ECMP multipath 233 information; 235 o In Section 5, a mechanism to validate L2 ECMP traversal; 237 o In Section 6, the LSR Capability TLV; 239 o In Section 7, the LAG Description Indicator flag; 240 o In Section 8, the Local Interface Index Sub-TLV; 242 o In Section 9, the Remote Interface Index Sub-TLV; 244 o In Section 10, the Detailed Interface and Label Stack TLV; 246 3. LSR Capability Discovery 248 The MPLS Ping operates by an initiator LSR sending an MPLS echo 249 request message and receiving back a corresponding MPLS echo reply 250 message from a responder LSR. The MPLS Traceroute operates in a 251 similar way except the initiator LSR potentially sends multiple MPLS 252 echo request messages with incrementing TTL values. 254 There have been many extensions to the MPLS Ping and Traceroute 255 mechanism over the years. Thus it is often useful, and sometimes 256 necessary, for the initiator LSR to deterministically disambiguate 257 the differences between: 259 o The responder LSR sent the MPLS echo reply message with contents C 260 because it has feature X, Y and Z implemented. 262 o The responder LSR sent the MPLS echo reply message with contents C 263 because it has subset of features X, Y and Z implemented but not 264 all. 266 o The responder LSR sent the MPLS echo reply message with contents C 267 because it does not have features X, Y and Z implemented. 269 To allow the initiator LSR to disambiguate the above differences, 270 this document defines the LSR Capability TLV (described in 271 Section 6). When the initiator LSR wishes to discover the 272 capabilities of the responder LSR, the initiator LSR includes the LSR 273 Capability TLV in the MPLS echo request message. When the responder 274 LSR receives an MPLS echo request message with the LSR Capability TLV 275 included, if it knows the LSR Capability TLV, then it MUST include 276 the LSR Capability TLV in the MPLS echo reply message with the LSR 277 Capability TLV describing features and extensions supported by the 278 local LSR. Otherwise, an MPLS echo reply MUST be sent back to the 279 initiator LSR with the return code set to "One or more of the TLVs 280 was not understood". Then the initiator LSR can send another MPLS 281 echo request without including the LSR Capability TLV. 283 It is RECOMMENDED that implementations supporting the LAG Multipath 284 extensions defined in this document include the LSR Capability TLV in 285 MPLS echo request messages. 287 3.1. Initiator LSR Procedures 289 If an initiator LSR does not know what capabilities a responder LSR 290 can support, it can send an MPLS each request message and carry the 291 LSR Capability TLV to the responder to discover the capabilities that 292 the responder LSR can support. 294 3.2. Responder LSR Procedures 296 When a responder LSR received an MPLS echo request message that 297 carries the LSR Capability TLV, the following procedures are used: 299 If the responder knows how to process the LSR Capability TLV, the 300 following procedures are used: 302 o The responder LSR MUST include the LSR Capability TLV in the MPLS 303 echo reply message. 305 o If the responder LSR understands the "LAG Description Indicator 306 flag": 308 * Set the "Downstream LAG Info Accommodation flag" if the 309 responder LSR is capable of describing outgoing LAG member 310 links separately; otherwise, clear the "Downstream LAG Info 311 Accommodation flag". 313 * Set the "Upstream LAG Info Accommodation flag" if responder LSR 314 is capable of describing incoming LAG member links separately; 315 otherwise, clear the "Upstream LAG Info Accommodation flag". 317 o If the responder LSR does not understand the "LAG Description 318 Indicator flag": 320 * Clear both the "Downstream LAG Info Accommodation flag" and the 321 "Upstream LAG Info Accommodation flag". 323 If the responder does not know the LSR Capability TLV, an MPLS echo 324 reply with the return code set to "One or more of the TLVs was not 325 understood" MUST be sent back to the initiator LSR. 327 4. Mechanism to Discover L2 ECMP Multipath 329 4.1. Initiator LSR Procedures 331 Through the "LSR Capability Discovery" as defined in Section 3, the 332 initiator LSR can understand whether the responder LSR can describe 333 incoming/outgoing LAG member links separately in the DDMAP TLV. 335 Once the initiator LSR knows the capabilities that a responder 336 supports, then it sends an MPLS echo request carrying a DDMAP with 337 the "LAG Description Indicator flag" (G) set to the responder LSR. 338 The "LAG Description Indicator flag" (G) indicates that separate load 339 balancing information for each L2 nexthop over a LAG is desired in 340 the MPLS echo reply. The new "LAG Description Indicator flag" is 341 described in Section 7. 343 4.2. Responder LSR Procedures 345 When a responder LSR received an MPLS echo request message with the 346 "LAG Description Indicator flag" set, if the responder LSR 347 understands the "LAG Description Indicator flag" and is capable of 348 describing outgoing LAG member links separately, the following 349 procedures are used, regardless of whether or not outgoing interfaces 350 include LAG interfaces: 352 o For each downstream that is a LAG interface: 354 * The responder LSR MUST include a DDMAP TLV when sending the 355 MPLS echo reply. 357 * The responder LSR MUST set the "LAG Description Indicator flag" 358 in the DS Flags field of the DDMAP TLV. 360 * In the DDMAP TLV, the Local Interface Index Sub-TLV, Remote 361 Interface Index Sub-TLV and Multipath Data Sub-TLV are used to 362 describe each LAG member link. All other fields of the DDMAP 363 TLV are used to describe the LAG interface. 365 * For each LAG member link of the LAG interface: 367 + The responder LSR MUST add a Local Interface Index Sub-TLV 368 (described in Section 8) with the "LAG Member Link Indicator 369 flag" set in the Interface Index Flags field, describing the 370 interface index of this outgoing LAG member link (the local 371 interface index is assigned by the local LSR). 373 + The responder LSR MAY add a Remote Interface Index Sub-TLV 374 (described in Section 9) with the "LAG Member Link Indicator 375 flag" set in the Interface Index Flags field, describing the 376 interface index of the incoming LAG member link on the 377 downstream LSR (this interface index is assigned by the 378 downstream LSR). How the local LSR obtains the interface 379 index of the LAG member link on the downstream LSR is 380 outside the scope of this document. 382 + The responder LSR MUST add an Multipath Data Sub-TLV for 383 this LAG member link, if the received DDMAP TLV requested 384 multipath information. 386 Based on the procedures described above, every LAG member link will 387 have a Local Interface Index Sub-TLV and a Multipath Data Sub-TLV 388 entries in the DDMAP TLV. The order of the Sub-TLVs in the DDMAP TLV 389 for a LAG member link MUST be Local Interface Index Sub-TLV 390 immediately followed by Multipath Data Sub-TLV. A LAG member link 391 may also have a corresponding Remote Interface Index Sub-TLV. When a 392 Local Interface Index Sub-TLV, a Remote Interface Index-Sub-TLV and a 393 Multipath Data Sub-TLV are placed in the DDMAP TLV to describe a LAG 394 member link, they MUST be placed in the order of Local Interface 395 Index Sub-TLV, Remote Interface Index-Sub-TLV and Multipath Data Sub- 396 TLV. 398 A responder LSR possessing a LAG interface with two member links 399 would send the following DDMAP for this LAG interface: 401 0 1 2 3 402 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 403 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 404 ~ DDMAP fields describing LAG interface with DS Flags G set ~ 405 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 406 |[MANDATORY] Local Interface Index Sub-TLV of LAG member link #1| 407 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 408 |[OPTIONAL] Remote Interface Index Sub-TLV of LAG member link #1| 409 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 410 |[MANDATORY] Multipath Data Sub-TLV LAG member link #1 | 411 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 412 |[MANDATORY] Local Interface Index Sub-TLV of LAG member link #2| 413 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 414 |[OPTIONAL] Remote Interface Index Sub-TLV of LAG member link #2| 415 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 416 |[MANDATORY] Multipath Data Sub-TLV LAG member link #2 | 417 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 418 | Label Stack Sub-TLV | 419 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 421 Figure 2: Example of DDMAP in MPLS Echo Reply 423 When none of the received multipath information maps to a particular 424 LAG member link, then the responder LSR MUST still place the Local 425 Interface Index Sub-TLV and the Multipath Data Sub-TLV for that LAG 426 member link in the DDMAP TLV, the value of Multipath Length field of 427 the Multipath Data Sub-TLV is set to zero. 429 4.3. Additional Initiator LSR Procedures 431 The procedures above allow an initiator LSR to: 433 o Identify whether or not the responder LSR can describe outgoing 434 LAG member links separately, by looking at the LSR Capability TLV. 436 o Utilize the value of the "LAG Description Indicator flag" in DS 437 Flags to identify whether each received DDMAP TLV describes a LAG 438 interface or a non-LAG interface. 440 o Obtain multipath information which is expected to traverse the 441 specific LAG member link described by corresponding interface 442 index. 444 When an initiator LSR receives a DDMAP containing LAG member 445 information from a downstream LSR with TTL=n, then the subsequent 446 DDMAP sent by the initiator LSR to the downstream LSR with TTL=n+1 447 through a particular LAG member link MUST be updated with following 448 procedures: 450 o The Local Interface Index Sub-TLVs MUST be removed in the sending 451 DDMAP. 453 o If the Remote Interface Index Sub-TLVs were present and the 454 initiator LSR is traversing over a specific LAG member link, then 455 the Remote Interface Index Sub-TLV corresponding to the LAG member 456 link being traversed SHOULD be included in the sending DDMAP. All 457 other Remote Interface Index Sub-TLVs MUST be removed from the 458 sending DDMAP. 460 o The Multipath Data Sub-TLVs MUST be updated to include just one 461 Multipath Data Sub-TLV. The initiator LSR MAY just keep the 462 Multipath Data Sub-TLV corresponding to the LAG member link being 463 traversed, or combine the Multipath Data Sub-TLVs for all LAG 464 member links into a single Multipath Data Sub-TLV when diagnosing 465 further downstream LSRs. 467 o All other fields of the DDMAP are to comply with procedures 468 described in [RFC8029]. 470 Figure 3 is an example that shows how to use the DDMAP TLV to notify 471 which member link (link #1 in the example) will be chosen to send the 472 MPLS echo request message to the next downstream LSR: 474 0 1 2 3 475 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 476 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 477 ~ DDMAP fields describing LAG interface with DS Flags G set ~ 478 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 479 |[OPTIONAL] Remote Interface Index Sub-TLV of LAG member link #1| 480 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 481 | Multipath Data Sub-TLV LAG member link #1 | 482 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 483 | Label Stack Sub-TLV | 484 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 486 Figure 3: Example of DDMAP in MPLS Echo Request 488 5. Mechanism to Validate L2 ECMP Traversal 490 Section 4 defines the responder LSR procedures to constructs a DDMAP 491 for a downstream LAG. The Remote Interface Index Sub-TLVs that 492 describes the incoming LAG member links of the downstream LSR is 493 optional, because this information from the downstream LSR is often 494 not available on the responder LSR. In such case, the traversal of 495 LAG member links can be validated with procedures described in 496 Section 5.1. If LSRs can provide the Remote Interface Index Sub- 497 TLVs, then the validation procedures described in Section 5.2 can be 498 used. 500 5.1. Incoming LAG Member Links Verification 502 Without downstream LSRs returning remote Interface Index Sub-TLVs in 503 the DDMAP, validation of the LAG member link traversal requires that 504 initiator LSR traverses all available LAG member links and taking the 505 results through a logic. This section provides the mechanism for the 506 initiator LSR to obtain additional information from the downstream 507 LSRs and describes the additional logic in the initiator LSR to 508 validate the L2 ECMP traversal. 510 5.1.1. Initiator LSR Procedures 512 An MPLS echo request carrying a DDMAP TLV with the "Interface and 513 Label Stack Object Request flag" and "LAG Description Indicator flag" 514 set is sent to indicate the request for Detailed Interface and Label 515 Stack TLV with additional LAG member link information (i.e. 516 interface index) in the MPLS echo reply. 518 5.1.2. Responder LSR Procedures 520 A responder LSR that understands the "LAG Description Indicator flag" 521 and is capable of describing incoming LAG member link MUST use the 522 following procedures, regardless of whether or not incoming interface 523 was a LAG interface: 525 o When the "I" flag ( "Interface and Label Stack Object Request 526 flag") of the DDMAP TLV in the received MPLS echo request is set: 528 * The responder LSR MUST add the Detailed Interface and Label 529 Stack TLV (described in Section 10) in the MPLS echo reply. 531 * If the incoming interface is a LAG, the responder LSR MUST add 532 the Incoming Interface Index Sub-TLV (described in 533 Section 10.1.2) in the Detailed Interface and Label Stack TLV. 534 The "LAG Member Link Indicator flag" MUST be set in the 535 Interface Index Flags field, and the Interface Index field set 536 to the LAG member link which received the MPLS echo request. 538 These procedures allow initiator LSR to: 540 o Utilize the Incoming Interface Index Sub-TLV in the Detailed 541 Interface and Label Stack TLV to derive, if the incoming interface 542 is a LAG, the identity of the incoming LAG member. 544 5.1.3. Additional Initiator LSR Procedures 546 Along with procedures described in Section 4, the procedures 547 described in this section will allow an initiator LSR to know: 549 o The expected load balance information of every LAG member link, at 550 LSR with TTL=n. 552 o With specific entropy, the expected interface index of the 553 outgoing LAG member link at TTL=n. 555 o With specific entropy, the interface index of the incoming LAG 556 member link at TTL=n+1. 558 Expectation is that there's a relationship between the interface 559 index of the outgoing LAG member link at TTL=n and the interface 560 index of the incoming LAG member link at TTL=n+1 for all discovered 561 entropies. In other words, set of entropies that load balances to 562 outgoing LAG member link X at TTL=n should all reach the nexthop on 563 same incoming LAG member link Y at TTL=n+1. 565 With additional logics, the initiator LSR can perform the following 566 checks in a scenario where the initiator LSR knows that there is a 567 LAG, with two LAG members, between TTL=n and TTL=n+1, and has the 568 multipath information to traverse the two LAG member links. 570 The initiator LSR sends two MPLS echo request messages to traverse 571 the two LAG member links at TTL=n+1: 573 o Success case: 575 * One MPLS echo request message reaches TTL=n+1 on an LAG member 576 link 1. 578 * The other MPLS echo request message reaches TTL=n+1 on an LAG 579 member link 2. 581 The two MPLS echo request messages sent by the initiator LSR reach 582 at the immediate downstream LSR from two different LAG member 583 links. 585 o Error case: 587 * One MPLS echo request message reaches TTL=n+1 on an LAG member 588 link 1. 590 * The other MPLS echo request message also reaches TTL=n+1 on an 591 LAG member link 1. 593 One or two MPLS echo request messages sent by the initiator LSR 594 cannot reach the immediate downstream LSR, or the two MPLS echo 595 request messages reach at the immediate downstream LSR from the 596 same LAG member link. 598 Note that the above defined procedures will provide a deterministic 599 result for LAG interfaces that are back-to-back connected between 600 LSRs (i.e. no L2 switch in between). If there is a L2 switch between 601 the LSR at TTL=n and the LSR at TTL=n+1, there is no guarantee that 602 traversal of every LAG member link at TTL=n will result in reaching 603 from different interface at TTL=n+1. Issues resulting from LAG with 604 L2 switch in between are further described in Appendix A. LAG 605 provisioning models in operated network should be considered when 606 analyzing the output of LSP Traceroute exercising L2 ECMPs. 608 5.2. Individual End-to-End Path Verification 610 When the Remote Interface Index Sub-TLVs are available from an LSR 611 with TTL=n, then the validation of LAG member link traversal can be 612 performed by the downstream LSR of TTL=n+1. The initiator LSR 613 follows the procedures described in Section 4.3. 615 The DDMAP validation procedures for the downstream responder LSR are 616 then updated to include the comparison of the incoming LAG member 617 link to the interface index described in the Remote Interface Index 618 Sub-TLV in the DDMAP TLV. Failure of this comparison results in the 619 return code being set to "Downstream Mapping Mismatch (5)". 621 6. LSR Capability TLV 623 This document defines a new optional TLV which is referred to as the 624 "LSR Capability TLV. It MAY be included in the MPLS echo request 625 message and the MPLS echo reply message. An MPLS echo request 626 message and an MPLS echo reply message MUST NOT include more than one 627 LSR Capability TLV. The presence of an LSR Capability TLV in an MPLS 628 echo request message is a request that a responder LSR includes an 629 LSR Capability TLV in the MPLS echo reply message, with the LSR 630 Capability TLV describing features and extensions that the responder 631 LSR supports. 633 When a responder LSR received an MPLS echo request message that 634 carries an LSR Capability TLV, if the responder LSR knows how to 635 process the LSR Capability TLV, an LSR Capability TLV MUST be 636 included in the MPLS echo reply message. Otherwise, if the responder 637 does not know the LSR Capability TLV, an MPLS echo reply with the 638 return code set to "One or more of the TLVs was not understood" MUST 639 be sent back to the initiator LSR. 641 The format of the LSR Capability TLV is as below: 643 LSR Capability TLV Type is TBD1. Length is 4. The value field of 644 the LSR Capability TLV has following format: 646 0 1 2 3 647 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 648 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 649 | Type | Length | 650 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 651 | LSR Capability Flags | 652 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 654 Figure 4: LSR Capability TLV 656 Where: 658 The Type is 2 octets in length and the value is TBD1. 660 The Length filed is 2 octets in length, and the value is 4. 662 The LSR Capability Flags is 4 octets in length, this document 663 defines following flags: 665 0 1 2 3 666 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 667 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 668 | Must Be Zero (Reserved) |U|D| 669 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 671 This document defines two flags. The remaining flags MUST be set 672 to zero when sending and ignored on receipt. Both the U and the D 673 flag MUST be cleared in the MPLS echo request message when 674 sending, and ignored on receipt. Neither, either or both the U 675 and the D flag MAY be set in the MPLS echo reply message. 677 Flag Name and Meaning 678 ---- ---------------- 680 U Upstream LAG Info Accommodation 682 An LSR sets this flag when the LSR is capable of 683 describing a LAG member link in the Incoming Interface 684 Index Sub-TLV in the Detailed Interface and 685 Label Stack TLV. 687 D Downstream LAG Info Accommodation 689 An LSR sets this flag when the LSR is capable of 690 describing LAG member links in the Local Interface 691 Index Sub-TLV and the Multipath Data Sub-TLV in the 692 Downstream Detailed Mapping TLV. 694 7. LAG Description Indicator Flag: G 696 This document defines a flag, the "G" flag (LAG Description 697 Indicator), in the DS Flags field of the DDMAP TLV. 699 The "G" flag in the MPLS echo request message indicates the request 700 for detailed LAG information from the responder LSR. In the MPLS 701 echo reply message, the "G" flag MUST be set if the DDMAP TLV 702 describes a LAG interface. It MUST be cleared otherwise. 704 The "G" flag is defined as below: 706 The Bit Number is TBD5. 708 0 1 2 3 4 5 6 7 709 +-+-+-+-+-+-+-+-+ 710 | MBZ |G|MBZ|I|N| 711 +-+-+-+-+-+-+-+-+ 713 RFC-Editor-Note: Please update above figure to place the G flag in 714 the bit number TBD5. 716 Flag Name and Meaning 717 ---- ---------------- 719 G LAG Description Indicator 721 When this flag is set in the MPLS echo request, the responder LSR 722 is requested to respond with detailed LAG information. When this 723 flag is set in the MPLS echo reply, the corresponding DDMAP TLV 724 describes a LAG interface. 726 8. Local Interface Index Sub-TLV 728 The Local Interface Index Sub-TLV is an optional TLV, it describes 729 the interface index assigned by the local LSR to an egress interface. 730 One or more Local Interface Index sub-TLVs MAY appear in a DDMAP TLV. 732 The format of the Local Interface Index Sub-TLV is below: 734 0 1 2 3 735 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 736 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 737 | Type | Length | 738 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 739 | Local Interface Index | 740 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 742 Figure 5: Local Interface Index Sub-TLV 744 Where: 746 o The "Type" field is 2 octets in length, the value is TBD2. 748 o The "Length" filed 2 octets in length, and the value is 4. 750 o The "Local Interface Index" field is 4 octets in length, it is an 751 interface index assigned by a local LSR to an egress interface. 753 9. Remote Interface Index Sub-TLV 755 The Remote Interface Index Sub-TLV is an optional TLV, it describes 756 the interface index assigned by a downstream LSR to an ingress 757 interface. One or more Remote Interface Index sub-TLVs MAY appear in 758 a DDMAP TLV. 760 The format of the Remote Interface Index Sub-TLV is as below: 762 0 1 2 3 763 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 764 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 765 | Type | Length | 766 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 767 | Remote Interface Index | 768 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 770 Figure 6: Remote Interface Index Sub-TLV 772 Where: 774 o The "Type" field is 2 octets in length, and the value is TBD3. 776 o The "Length" field is 2 octets in length, and the value is 4. 778 o The "Remote Interface Index" is 4 octets in length, it is an 779 interface index assigned by a downstream LSR to an ingress 780 interface. 782 10. Detailed Interface and Label Stack TLV 784 The "Detailed Interface and Label Stack" object is a TLV that MAY be 785 included in an MPLS echo reply message to report the interface on 786 which the MPLS echo request message was received and the label stack 787 that was on the packet when it was received. A responder LSR MUST 788 NOT insert more than one instance of this TLV into the MPLS echo 789 reply message. This TLV allows the initiator LSR to obtain the exact 790 interface and label stack information as it appears at the responder 791 LSR. 793 Detailed Interface and Label Stack TLV Type is TBD4. Length is K + 794 Sub-TLV Length (sum of Sub-TLVs). K is the sum of all fields of this 795 TLV prior to Sub-TLVs, but the length of K depends on the Address 796 Type. Details of this information is described below. The Value 797 field has following format: 799 0 1 2 3 800 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 801 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 802 | Type | Length | 803 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 804 | Address Type | Must Be Zero | 805 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 806 | IP Address (4 or 16 octets) | 807 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 808 | Interface (4 or 16 octets) | 809 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 810 . . 811 . List of Sub-TLVs . 812 . . 813 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 815 Figure 7: Detailed Interface and Label Stack TLV 817 The Detailed Interface and Label Stack TLV format is derived from the 818 Interface and Label Stack TLV format (from [RFC8029]). Two changes 819 are introduced. The first is that the label stack is converted into 820 a sub-TLV. The second is that a new sub-TLV is added to describe an 821 interface index. These fields of Detailed Interface and Label Stack 822 TLV have the same use and meaning as in [RFC8029]. A summary of 823 these fields is as below: 825 Address Type 827 The Address Type indicates if the interface is numbered or 828 unnumbered. It also determines the length of the IP Address 829 and Interface fields. The resulting total length of the 830 initial part of the TLV is listed as "K Octets". The Address 831 Type is set to one of the following values: 833 Type # Address Type K Octets 834 ------ ------------ -------- 835 1 IPv4 Numbered 16 836 2 IPv4 Unnumbered 16 837 3 IPv6 Numbered 40 838 4 IPv6 Unnumbered 28 840 IP Address and Interface 842 IPv4 addresses and interface indices are encoded in 4 octets; 843 IPv6 addresses are encoded in 16 octets. 845 If the interface upon which the echo request message was 846 received is numbered, then the Address Type MUST be set to IPv4 847 Numbered or IPv6 Numbered, the IP Address MUST be set to either 848 the LSR's Router ID or the interface address, and the Interface 849 MUST be set to the interface address. 851 If the interface is unnumbered, the Address Type MUST be either 852 IPv4 Unnumbered or IPv6 Unnumbered, the IP Address MUST be the 853 LSR's Router ID, and the Interface MUST be set to the index 854 assigned to the interface. 856 Note: Usage of IPv6 Unnumbered has the same issue as [RFC8029], 857 described in Section 3.4.2 of [RFC7439]. A solution should be 858 considered an applied to both [RFC8029] and this document. 860 10.1. Sub-TLVs 862 This section defines the sub-TLVs that MAY be included as part of the 863 Detailed Interface and Label Stack TLV. Two sub-TLVs are defined: 865 Sub-Type Sub-TLV Name 866 --------- ------------ 867 1 Incoming Label stack 868 2 Incoming Interface Index 870 10.1.1. Incoming Label Stack Sub-TLV 872 The Incoming Label Stack sub-TLV contains the label stack as received 873 by an LSR. If any TTL values have been changed by this LSR, they 874 SHOULD be restored. 876 Incoming Label Stack Sub-TLV Type is 1. Length is variable, and its 877 format is as below: 879 0 1 2 3 880 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 881 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 882 | Type | Length | 883 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 884 | Label | TC |S| TTL | 885 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 886 . . 887 . . 888 . . 889 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 890 | Label | TC |S| TTL | 891 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 893 Figure 8: Incoming Label Stack Sub-TLV 895 10.1.2. Incoming Interface Index Sub-TLV 897 The Incoming Interface Index object is a Sub-TLV that MAY be included 898 in a Detailed Interface and Label Stack TLV. The Incoming Interface 899 Index Sub-TLV describes the index assigned by a local LSR to the 900 interface which received the MPLS echo request message. 902 Incoming Interface Index Sub-TLV Type is 2. Length is 8, and its 903 format is as below: 905 0 1 2 3 906 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 907 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 908 | Type | Length | 909 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 910 | Interface Index Flags | Must Be Zero | 911 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 912 | Incoming Interface Index | 913 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 915 Figure 9: Incoming Interface Index Sub-TLV 917 Interface Index Flags 919 Interface Index Flags field is a bit vector with following format. 921 0 1 922 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 923 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 924 | Must Be Zero (Reserved) |M| 925 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 927 One flag is defined: M. The remaining flags MUST be set to zero 928 when sending and ignored on receipt. 930 Flag Name and Meaning 931 ---- ---------------- 933 M LAG Member Link Indicator 935 When this flag is set, interface index described in 936 this sub-TLV is a member of a LAG. 938 Incoming Interface Index 940 An Index assigned by the LSR to this interface. 942 11. Security Considerations 944 This document extends LSP Traceroute mechanism to discover and 945 exercise L2 ECMP paths. As a result of supporting the code points 946 and procedures described in this document, additional processing are 947 required by initiator LSRs and responder LSRs, especially to compute 948 and handle the additional multipath information. Due to additional 949 processing, it is critical that proper security measures described in 950 [RFC8029] are followed. 952 The LSP Traceroute allows an initiator LSR to discover the paths of 953 tested LSPs, providing detailed knowledge of the MPLS network. 954 Exposing such information to a malicious user is considered 955 dangerous. To prevent leakage of vital information to untrusted 956 users, a responder LSR MUST only accept MPLS echo request messages 957 from trusted sources via filtering source IP address field of 958 received MPLS echo request messages.[RFC8029] provides additional 959 recommendations to avoid attacks and recommendations to follow if an 960 operator desires to prevent tracing. 962 12. IANA Considerations 964 12.1. LSR Capability TLV 966 The IANA is requested to assign new value TBD1 for LSR Capability TLV 967 from the "Multiprotocol Label Switching Architecture (MPLS) Label 968 Switched Paths (LSPs) Ping Parameters - TLVs" registry. 970 Value Meaning Reference 971 ----- ------- --------- 972 TBD1 LSR Capability TLV this document 974 12.1.1. LSR Capability Flags 976 The IANA is requested to create and maintain a registry entitled "LSR 977 Capability Flags" with following registration procedures: 979 Registry Name: LAG Interface Info Flags 981 Bit number Name Reference 982 ---------- ---------------------------------------- --------- 983 31 D: Downstream LAG Info Accommodation this document 984 30 U: Upstream LAG Info Accommodation this document 985 0-29 Unassigned 987 Assignments of LSR Capability Flags are via Standards Action 988 [RFC8126]. 990 12.2. Local Interface Index Sub-TLV 992 The IANA is requested to assign new value TBD2 (from the range 993 4-31743) for the Local Interface Index Sub-TLV from the 994 "Multiprotocol Label Switching Architecture (MPLS) Label Switched 995 Paths (LSPs) Ping Parameters - TLVs" registry, "Sub-TLVs for TLV 996 Types 20" sub-registry. 998 Value Meaning Reference 999 ----- ------- --------- 1000 TBD2 Local Interface Index Sub-TLV this document 1002 12.2.1. Interface Index Flags 1004 The IANA is requested to create and maintain a registry entitled 1005 "Interface Index Flags" with following registration procedures: 1007 Registry Name: Interface Index Flags 1009 Bit number Name Reference 1010 ---------- ---------------------------------------- --------- 1011 15 M: LAG Member Link Indicator this document 1012 0-14 Unassigned 1014 Assignments of Interface Index Flags are via Standards Action 1015 [RFC8126]. 1017 Note that this registry is used by the Interface Index Flags field of 1018 following Sub-TLVs: 1020 o The Local Interface Index Sub-TLV which may be present in the 1021 "Downstream Detailed Mapping" TLV. 1023 o The Remote Interface Index Sub-TLV which may be present in the 1024 "Downstream Detailed Mapping" TLV. 1026 o The Incoming Interface Index Sub-TLV which may be present in the 1027 "Detailed Interface and Label Stack" TLV. 1029 12.3. Remote Interface Index Sub-TLV 1031 The IANA is requested to assign new value TBD3 (from the range 1032 32768-49161) for the Remote Interface Index Sub-TLV from the 1033 "Multiprotocol Label Switching Architecture (MPLS) Label Switched 1034 Paths (LSPs) Ping Parameters - TLVs" registry, "Sub-TLVs for TLV 1035 Types 20" sub-registry. 1037 Value Meaning Reference 1038 ----- ------- --------- 1039 TBD3 Remote Interface Index Sub-TLV this document 1041 12.4. Detailed Interface and Label Stack TLV 1043 The IANA is requested to assign new value TBD4 for Detailed Interface 1044 and Label Stack TLV from the "Multiprotocol Label Switching 1045 Architecture (MPLS) Label Switched Paths (LSPs) Ping Parameters - 1046 TLVs" registry ([IANA-MPLS-LSP-PING]). 1048 Value Meaning Reference 1049 ----- ------- --------- 1050 TBD4 Detailed Interface and Label Stack TLV this document 1052 12.4.1. Sub-TLVs for TLV Type TBD4 1054 The IANA is requested to create and maintain a sub-registry entitled 1055 "Sub-TLVs for TLV Type TBD4" under "Multiprotocol Label Switching 1056 Architecture (MPLS) Label Switched Paths (LSPs) Ping Parameters - 1057 TLVs" registry. 1059 Initial values for this sub-registry, "Sub-TLVs for TLV Types TBD4", 1060 are described below. 1062 Sub-Type Name Reference 1063 ----------- -------------------------------------- --------- 1064 1 Incoming Label Stack this document 1065 2 Incoming Interface Index this document 1066 3-16383 Unassigned (mandatory TLVs) 1067 16384-31743 Experimental 1068 32768-49161 Unassigned (optional TLVs) 1069 49162-64511 Experimental 1071 Assignments of Sub-Types in the mandatory and optional spaces are via 1072 Standards Action [RFC8126]. Assignments of Sub-Types in the 1073 experimental space is via Specification Required [RFC8126]. 1075 12.5. DS Flags 1077 The IANA is requested to assign a new bit number from the "DS flags" 1078 sub-registry from the "Multi-Protocol Label Switching (MPLS) Label 1079 Switched Paths (LSPs) Ping Parameters - TLVs" registry 1080 ([IANA-MPLS-LSP-PING]). 1082 Note: the "DS flags" sub-registry is created by [RFC8029]. 1084 Bit number Name Reference 1085 ---------- ---------------------------------------- --------- 1086 TBD5 G: LAG Description Indicator this document 1088 13. Acknowledgements 1090 The authors would like to thank Nagendra Kumar, Sam Aldrin, for 1091 providing useful comments and suggestions. The authors would like to 1092 thank Loa Andersson for performing a detailed review and providing 1093 number of comments. 1095 The authors also would like to extend sincere thanks to the MPLS RT 1096 review members who took time to review and provide comments. The 1097 members are Eric Osborne, Mach Chen and Yimin Shen. The suggestion 1098 by Mach Chen to generalize and create the LSR Capability TLV was 1099 tremendously helpful for this document and likely for future 1100 documents extending the MPLS LSP Ping and Traceroute mechanism. The 1101 suggestion by Yimin Shen to create two separate validation procedures 1102 had a big impact to the contents of this document. 1104 14. References 1106 14.1. Normative References 1108 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1109 Requirement Levels", BCP 14, RFC 2119, 1110 DOI 10.17487/RFC2119, March 1997, 1111 . 1113 [RFC8029] Kompella, K., Swallow, G., Pignataro, C., Ed., Kumar, N., 1114 Aldrin, S., and M. Chen, "Detecting Multiprotocol Label 1115 Switched (MPLS) Data-Plane Failures", RFC 8029, 1116 DOI 10.17487/RFC8029, March 2017, 1117 . 1119 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1120 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1121 May 2017, . 1123 14.2. Informative References 1125 [IANA-MPLS-LSP-PING] 1126 IANA, "Multi-Protocol Label Switching (MPLS) Label 1127 Switched Paths (LSPs) Ping Parameters", 1128 . 1131 [IEEE802.1AX] 1132 IEEE Std. 802.1AX, "IEEE Standard for Local and 1133 metropolitan area networks - Link Aggregation", November 1134 2008. 1136 [RFC7439] George, W., Ed. and C. Pignataro, Ed., "Gap Analysis for 1137 Operating IPv6-Only MPLS Networks", RFC 7439, 1138 DOI 10.17487/RFC7439, January 2015, 1139 . 1141 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 1142 Writing an IANA Considerations Section in RFCs", BCP 26, 1143 RFC 8126, DOI 10.17487/RFC8126, June 2017, 1144 . 1146 Appendix A. LAG with intermediate L2 Switch Issues 1148 Several flavors of "LAG with L2 switch" provisioning models and the 1149 corresponding MPLS data plane ECMP traversal validation issues are 1150 described in this section . 1152 A.1. Equal Numbers of LAG Members 1154 R1 ==== S1 ==== R2 1156 The issue with this LAG provisioning model is that packets traversing 1157 a LAG member from Router 1 (R1) to intermediate L2 switch (S1) can 1158 get load balanced by S1 towards Router 2 (R2). Therefore, MPLS echo 1159 request messages traversing a specific LAG member from R1 to S1 can 1160 actually reach R2 via any of the LAG members, and the sender of MPLS 1161 echo request messages has no knowledge of this nor no way to control 1162 this traversal. In the worst case, MPLS echo request messages with 1163 specific entropies to exercise every LAG members from R1 to S1 can 1164 all reach R2 via same LAG member. Thus it is impossible for MPLS 1165 echo request sender to verify that packets intended to traverse 1166 specific LAG member from R1 to S1 did actually traverse that LAG 1167 member, and to deterministically exercise "receive" processing of 1168 every LAG member on R2. 1170 A.2. Deviating Numbers of LAG Members 1172 ____ 1173 R1 ==== S1 ==== R2 1175 There are deviating number of LAG members on the two sides of the L2 1176 switch. The issue with this LAG provisioning model is the same as 1177 previous model, sender of MPLS echo request messages have no 1178 knowledge of L2 load balance algorithm nor entropy values to control 1179 the traversal. 1181 A.3. LAG Only on Right 1183 R1 ---- S1 ==== R2 1185 The issue with this LAG provisioning model is that there is no way 1186 for MPLS echo request sender to deterministically exercise both LAG 1187 members from S1 to R2. And without such, "receive" processing of R2 1188 on each LAG member cannot be verified. 1190 A.4. LAG Only on Left 1192 R1 ==== S1 ---- R2 1194 MPLS echo request sender has knowledge of how to traverse both LAG 1195 members from R1 to S1. However, both types of packets will terminate 1196 on the non-LAG interface at R2. It becomes impossible for MPLS echo 1197 request sender to know that MPLS echo request messages intended to 1198 traverse a specific LAG member from R1 to S1 did indeed traverse that 1199 LAG member. 1201 Authors' Addresses 1203 Nobo Akiya 1204 Big Switch Networks 1206 Email: nobo.akiya.dev@gmail.com 1208 George Swallow 1209 Cisco Systems 1211 Email: swallow@cisco.com 1213 Stephane Litkowski 1214 Orange 1216 Email: stephane.litkowski@orange.com 1218 Bruno Decraene 1219 Orange 1221 Email: bruno.decraene@orange.com 1222 John E. Drake 1223 Juniper Networks 1225 Email: jdrake@juniper.net 1227 Mach(Guoyi) Chen 1228 Huawei 1230 Email: mach.chen@huawei.com