idnits 2.17.00 (12 Aug 2021) /tmp/idnits28133/draft-ietf-mpls-lsp-ping-lag-multipath-08.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 (April 04, 2019) is 1136 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: October 6, 2019 S. Litkowski 7 B. Decraene 8 Orange 9 J. Drake 10 Juniper Networks 11 M. Chen 12 Huawei 13 April 04, 2019 15 Label Switched Path (LSP) Ping/Trace Multipath Support for 16 Link Aggregation Group (LAG) Interfaces 17 draft-ietf-mpls-lsp-ping-lag-multipath-08 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 October 6, 2019. 56 Copyright Notice 58 Copyright (c) 2019 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 . . . . . . . . . . . . . . . . . . . . . . . 4 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 . . . . . . . . . 14 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 . . . . . . . . . . . . . . . 16 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. Rate Limiting On Echo Request/Reply Messages . . . . . . . . 21 99 12. Security Considerations . . . . . . . . . . . . . . . . . . . 21 100 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 101 13.1. LSR Capability TLV . . . . . . . . . . . . . . . . . . . 21 102 13.1.1. LSR Capability Flags . . . . . . . . . . . . . . . . 22 103 13.2. Local Interface Index Sub-TLV . . . . . . . . . . . . . 22 104 13.2.1. Interface Index Flags . . . . . . . . . . . . . . . 22 105 13.3. Remote Interface Index Sub-TLV . . . . . . . . . . . . . 23 106 13.4. Detailed Interface and Label Stack TLV . . . . . . . . . 23 107 13.4.1. Sub-TLVs for TLV Type TBD4 . . . . . . . . . . . . . 23 108 13.4.2. Interface and Label Stack Address Types . . . . . . 24 109 13.5. DS Flags . . . . . . . . . . . . . . . . . . . . . . . . 24 110 14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 24 111 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 25 112 15.1. Normative References . . . . . . . . . . . . . . . . . . 25 113 15.2. Informative References . . . . . . . . . . . . . . . . . 25 114 Appendix A. LAG with intermediate L2 Switch Issues . . . . . . . 26 115 A.1. Equal Numbers of LAG Members . . . . . . . . . . . . . . 26 116 A.2. Deviating Numbers of LAG Members . . . . . . . . . . . . 26 117 A.3. LAG Only on Right . . . . . . . . . . . . . . . . . . . . 27 118 A.4. LAG Only on Left . . . . . . . . . . . . . . . . . . . . 27 119 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27 121 1. Introduction 123 1.1. Terminology 125 The following acronyms/terms are used in this document: 127 o MPLS - Multiprotocol Label Switching. 129 o LSP - Label Switched Path. 131 o LSR - Label Switching Router. 133 o ECMP - Equal-Cost Multipath. 135 o LAG - Link Aggregation Group. 137 o Initiator LSR - The LSR which sends the MPLS echo request message. 139 o Responder LSR - The LSR which receives the MPLS echo request 140 message and sends the MPLS echo reply message. 142 1.2. Background 144 The MPLS Label Switched Path (LSP) Ping and Traceroute mechanisms 145 [RFC8029] are powerful tools designed to diagnose all available Layer 146 3 (L3) paths of LSPs, including diagnostic coverage of L3 Equal-Cost 147 Multipath (ECMP). In many MPLS networks, Link Aggregation Group 148 (LAG) as defined in [IEEE802.1AX], which provides Layer 2 (L2) ECMP, 149 is often used for various reasons. MPLS LSP Ping and Traceroute 150 tools were not designed to discover and exercise specific paths of L2 151 ECMP. This raises a limitation for the following scenario when an 152 LSP traverses over a LAG: 154 o Label switching over some member links of the LAG is successful, 155 but fails over other member links of the LAG. 157 o MPLS echo request for the LSP over the LAG is load balanced on one 158 of the member links which is label switching successfully. 160 With the above scenario, MPLS LSP Ping and Traceroute will not be 161 able to detect the label switching failure of the problematic member 162 link(s) of the LAG. In other words, lack of L2 ECMP diagnostic 163 coverage can produce an outcome where MPLS LSP Ping and Traceroute 164 can be blind to label switching failures over a problematic LAG 165 interface. It is, thus, desirable to extend the MPLS LSP Ping and 166 Traceroute to have deterministic diagnostic coverage of LAG 167 interfaces. 169 The need for a solution of this problem was motivated by issues 170 encountered in live networks. 172 2. Overview of Solution 174 This document defines a new TLV to discover the capabilities of a 175 responder LSR and extensions for use with the MPLS LSP Ping and 176 Traceroute mechanisms to describe Multipath Information for 177 individual LAG member links, thus allowing MPLS LSP Ping and 178 Traceroute to discover and exercise specific paths of L2 ECMP over 179 LAG interfaces. The reader is expected to be familiar with mechanics 180 Downstream Detailed Mapping TLV (DDMAP) described in Section 3.4 of 181 [RFC8029]. 183 The solution consists of the MPLS echo request containing a DDMAP TLV 184 and the new LSR Capability TLV to indicate that separate load 185 balancing information for each L2 nexthop over LAG is desired in the 186 MPLS echo reply. The Responder LSR places the same LSR Capability 187 TLV in the MPLS echo reply to provide acknowledgement back to the 188 initiator LSR. It also adds, for each downstream LAG member, load 189 balance information (i.e., multipath information and interface 190 index). This mechanism is applicable to all types of LSPs which can 191 traverse over LAG interfaces. Many LAGs are built from p2p links, 192 with router X and router X+1 having direct connectivity and the same 193 number of LAG members. It is possible to build LAGs asymmetrically 194 by using Ethernet switches between two routers. Appendix A lists 195 some use cases for which the mechanisms defined in this document may 196 not be applicable. Note that the mechanisms described in this 197 document do not impose any changes to scenarios where an LSP is 198 pinned down to a particular LAG member (i.e. the LAG is not treated 199 as one logical interface by the LSP). 201 The following figure and description provides an example using an LDP 202 network. 204 <----- LDP Network -----> 206 +-------+ 207 | | 208 A-------B=======C-------E 209 | | 210 +-------D-------+ 212 ---- Non-LAG 213 ==== LAG comprising of two member links 215 Figure 1: Example LDP Network 217 When node A is initiating LSP Traceroute to node E, node B will 218 return to node A load balance information for following entries. 220 1. Downstream C over Non-LAG (upper path). 222 2. First Downstream C over LAG (middle path). 224 3. Second Downstream C over LAG (middle path). 226 4. Downstream D over Non-LAG (lower path). 228 This document defines: 230 o In Section 3, a mechanism to discover capabilities of responder 231 LSRs; 233 o In Section 4, a mechanism to discover L2 ECMP multipath 234 information; 236 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; 241 o In Section 8, the Local Interface Index Sub-TLV; 243 o In Section 9, the Remote Interface Index Sub-TLV; 245 o In Section 10, the Detailed Interface and Label Stack TLV; 247 3. LSR Capability Discovery 249 The MPLS Ping operates by an initiator LSR sending an MPLS echo 250 request message and receiving back a corresponding MPLS echo reply 251 message from a responder LSR. The MPLS Traceroute operates in a 252 similar way except the initiator LSR potentially sends multiple MPLS 253 echo request messages with incrementing TTL values. 255 There have been many extensions to the MPLS Ping and Traceroute 256 mechanisms over the years. Thus it is often useful, and sometimes 257 necessary, for the initiator LSR to deterministically disambiguate 258 the differences between: 260 o The responder LSR sent the MPLS echo reply message with contents C 261 because it has feature X, Y and Z implemented. 263 o The responder LSR sent the MPLS echo reply message with contents C 264 because it has subset of features X, Y and Z implemented but not 265 all. 267 o The responder LSR sent the MPLS echo reply message with contents C 268 because it does not have features X, Y and Z implemented. 270 To allow the initiator LSR to disambiguate the above differences, 271 this document defines the LSR Capability TLV (described in 272 Section 6). When the initiator LSR wishes to discover the 273 capabilities of the responder LSR, the initiator LSR includes the LSR 274 Capability TLV in the MPLS echo request message. When the responder 275 LSR receives an MPLS echo request message with the LSR Capability TLV 276 included, if it knows the LSR Capability TLV, then it MUST include 277 the LSR Capability TLV in the MPLS echo reply message with the LSR 278 Capability TLV describing features and extensions supported by the 279 local LSR. Otherwise, an MPLS echo reply must be sent back to the 280 initiator LSR with the return code set to "One or more of the TLVs 281 was not understood", according to the rules as defined Section 3 of 282 [RFC8029]. Then the initiator LSR can send another MPLS echo request 283 without including the LSR Capability TLV. 285 It is RECOMMENDED that implementations supporting the LAG Multipath 286 extensions defined in this document include the LSR Capability TLV in 287 MPLS echo request messages. 289 3.1. Initiator LSR Procedures 291 If an initiator LSR does not know what capabilities a responder LSR 292 can support, it can send an MPLS each request message and carry the 293 LSR Capability TLV to the responder to discover the capabilities that 294 the responder LSR can support. 296 3.2. Responder LSR Procedures 298 When a responder LSR received an MPLS echo request message that 299 carries the LSR Capability TLV, the following procedures are used: 301 If the responder knows how to process the LSR Capability TLV, the 302 following procedures are used: 304 o The responder LSR MUST include the LSR Capability TLV in the MPLS 305 echo reply message. 307 o If the responder LSR understands the "LAG Description Indicator 308 flag": 310 * Set the "Downstream LAG Info Accommodation flag" if the 311 responder LSR is capable of describing outgoing LAG member 312 links separately; otherwise, clear the "Downstream LAG Info 313 Accommodation flag". 315 * Set the "Upstream LAG Info Accommodation flag" if responder LSR 316 is capable of describing incoming LAG member links separately; 317 otherwise, clear the "Upstream LAG Info Accommodation flag". 319 4. Mechanism to Discover L2 ECMP Multipath 321 4.1. Initiator LSR Procedures 323 Through the "LSR Capability Discovery" as defined in Section 3, the 324 initiator LSR can understand whether the responder LSR can describe 325 incoming/outgoing LAG member links separately in the DDMAP TLV. 327 Once the initiator LSR knows that a responder can support this 328 mechanism, then it sends an MPLS echo request carrying a DDMAP TLV 329 with the "LAG Description Indicator flag" (G) set to the responder 330 LSR. The "LAG Description Indicator flag" (G) indicates that 331 separate load balancing information for each L2 nexthop over a LAG is 332 desired in the MPLS echo reply. The new "LAG Description Indicator 333 flag" is described in Section 7. 335 4.2. Responder LSR Procedures 337 When a responder LSR received an MPLS echo request message with the 338 "LAG Description Indicator flag" set in the DDMAP TLV, if the 339 responder LSR understands the "LAG Description Indicator flag" and is 340 capable of describing outgoing LAG member links separately, the 341 following procedures are used, regardless of whether or not outgoing 342 interfaces include LAG interfaces: 344 o For each downstream that is a LAG interface: 346 * The responder LSR MUST include a DDMAP TLV when sending the 347 MPLS echo reply. There is a single DDMAP TLV for the LAG 348 interface, with member links described using sub-TLVs. 350 * The responder LSR MUST set the "LAG Description Indicator flag" 351 in the DS Flags field of the DDMAP TLV. 353 * In the DDMAP TLV, the Local Interface Index Sub-TLV, Remote 354 Interface Index Sub-TLV and Multipath Data Sub-TLV are used to 355 describe each LAG member link. All other fields of the DDMAP 356 TLV are used to describe the LAG interface. 358 * For each LAG member link of the LAG interface: 360 + The responder LSR MUST add a Local Interface Index Sub-TLV 361 (described in Section 8) with the "LAG Member Link Indicator 362 flag" set in the Interface Index Flags field, describing the 363 interface index of this outgoing LAG member link (the local 364 interface index is assigned by the local LSR). 366 + The responder LSR MAY add a Remote Interface Index Sub-TLV 367 (described in Section 9) with the "LAG Member Link Indicator 368 flag" set in the Interface Index Flags field, describing the 369 interface index of the incoming LAG member link on the 370 downstream LSR (this interface index is assigned by the 371 downstream LSR). How the local LSR obtains the interface 372 index of the LAG member link on the downstream LSR is 373 outside the scope of this document. 375 + The responder LSR MUST add an Multipath Data Sub-TLV for 376 this LAG member link, if the received DDMAP TLV requested 377 multipath information. 379 Based on the procedures described above, every LAG member link will 380 have a Local Interface Index Sub-TLV and a Multipath Data Sub-TLV 381 entries in the DDMAP TLV. The order of the Sub-TLVs in the DDMAP TLV 382 for a LAG member link MUST be Local Interface Index Sub-TLV 383 immediately followed by Multipath Data Sub-TLV except as follows. A 384 LAG member link MAY also have a corresponding Remote Interface Index 385 Sub-TLV. When a Local Interface Index Sub-TLV, a Remote Interface 386 Index-Sub-TLV and a Multipath Data Sub-TLV are placed in the DDMAP 387 TLV to describe a LAG member link, they MUST be placed in the order 388 of Local Interface Index Sub-TLV, Remote Interface Index-Sub-TLV and 389 Multipath Data Sub-TLV. The block of local interface index, 390 (optional remote interface index) and multipath data sub-TLVs for 391 each member link MUST appear adjacent to each other in order of 392 increasing local interface index. 394 A responder LSR possessing a LAG interface with two member links 395 would send the following DDMAP for this LAG interface: 397 0 1 2 3 398 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 399 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 400 ~ DDMAP fields describing LAG interface with DS Flags G set ~ 401 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 402 | Local Interface Index Sub-TLV of LAG member link #1 | 403 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 404 | Remote Interface Index Sub-TLV of LAG member link #1 | 405 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 406 | Multipath Data Sub-TLV LAG member link #1 | 407 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 408 | Local Interface Index Sub-TLV of LAG member link #2 | 409 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 410 | Remote Interface Index Sub-TLV of LAG member link #2 | 411 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 412 | Multipath Data Sub-TLV LAG member link #2 | 413 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 414 | Label Stack Sub-TLV | 415 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 417 Figure 2: Example of DDMAP in MPLS Echo Reply 419 When none of the received multipath information maps to a particular 420 LAG member link, then the responder LSR MUST still place the Local 421 Interface Index Sub-TLV and the Multipath Data Sub-TLV for that LAG 422 member link in the DDMAP TLV. The value of Multipath Length field of 423 the Multipath Data Sub-TLV is set to zero. 425 4.3. Additional Initiator LSR Procedures 427 The procedures above allow an initiator LSR to: 429 o Identify whether or not the responder LSR can describe outgoing 430 LAG member links separately, by looking at the LSR Capability TLV. 432 o Utilize the value of the "LAG Description Indicator flag" in DS 433 Flags to identify whether each received DDMAP TLV describes a LAG 434 interface or a non-LAG interface. 436 o Obtain multipath information which is expected to traverse the 437 specific LAG member link described by corresponding interface 438 index. 440 When an initiator LSR receives a DDMAP containing LAG member 441 information from a downstream LSR with TTL=n, then the subsequent 442 DDMAP sent by the initiator LSR to the downstream LSR with TTL=n+1 443 through a particular LAG member link MUST be updated with following 444 procedures: 446 o The Local Interface Index Sub-TLVs MUST be removed in the sending 447 DDMAP. 449 o If the Remote Interface Index Sub-TLVs were present and the 450 initiator LSR is traversing over a specific LAG member link, then 451 the Remote Interface Index Sub-TLV corresponding to the LAG member 452 link being traversed SHOULD be included in the sending DDMAP. All 453 other Remote Interface Index Sub-TLVs MUST be removed from the 454 sending DDMAP. 456 o The Multipath Data Sub-TLVs MUST be updated to include just one 457 Multipath Data Sub-TLV. The initiator LSR MAY just keep the 458 Multipath Data Sub-TLV corresponding to the LAG member link being 459 traversed, or combine the Multipath Data Sub-TLVs for all LAG 460 member links into a single Multipath Data Sub-TLV when diagnosing 461 further downstream LSRs. 463 o All other fields of the DDMAP are to comply with procedures 464 described in [RFC8029]. 466 Figure 3 is an example that shows how to use the DDMAP TLV to notify 467 which member link (link #1 in the example) will be chosen to send the 468 MPLS echo request message to the next downstream LSR: 470 0 1 2 3 471 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 472 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 473 ~ DDMAP fields describing LAG interface with DS Flags G set ~ 474 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 475 |[OPTIONAL] Remote Interface Index Sub-TLV of LAG member link #1| 476 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 477 | Multipath Data Sub-TLV LAG member link #1 | 478 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 479 | Label Stack Sub-TLV | 480 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 482 Figure 3: Example of DDMAP in MPLS Echo Request 484 5. Mechanism to Validate L2 ECMP Traversal 486 Section 4 defines the responder LSR procedures to construct a DDMAP 487 for a downstream LAG. The Remote Interface Index Sub-TLVs that 488 describes the incoming LAG member links of the downstream LSR is 489 optional, because this information from the downstream LSR is often 490 not available on the responder LSR. In such case, the traversal of 491 LAG member links can be validated with procedures described in 492 Section 5.1. If LSRs can provide the Remote Interface Index Sub- 493 TLVs, then the validation procedures described in Section 5.2 can be 494 used. 496 5.1. Incoming LAG Member Links Verification 498 Without downstream LSRs returning remote Interface Index Sub-TLVs in 499 the DDMAP, validation of the LAG member link traversal requires that 500 initiator LSR traverses all available LAG member links and taking the 501 results through a logic. This section provides the mechanism for the 502 initiator LSR to obtain additional information from the downstream 503 LSRs and describes the additional logic in the initiator LSR to 504 validate the L2 ECMP traversal. 506 5.1.1. Initiator LSR Procedures 508 An MPLS echo request carrying a DDMAP TLV with the "Interface and 509 Label Stack Object Request flag" and "LAG Description Indicator flag" 510 set is sent to indicate the request for Detailed Interface and Label 511 Stack TLV with additional LAG member link information (i.e. 512 interface index) in the MPLS echo reply. 514 5.1.2. Responder LSR Procedures 516 When received an echo request with the "LAG Description Indicator 517 flag" set, a responder LSR that understands the "LAG Description 518 Indicator flag" and is capable of describing incoming LAG member link 519 SHOULD use the following procedures, regardless of whether or not 520 incoming interface was a LAG interface: 522 o When the "I" flag ( "Interface and Label Stack Object Request 523 flag") of the DDMAP TLV in the received MPLS echo request is set: 525 * The responder LSR MUST add the Detailed Interface and Label 526 Stack TLV (described in Section 10) in the MPLS echo reply. 528 * If the incoming interface is a LAG, the responder LSR MUST add 529 the Incoming Interface Index Sub-TLV (described in 530 Section 10.1.2) in the Detailed Interface and Label Stack TLV. 531 The "LAG Member Link Indicator flag" MUST be set in the 532 Interface Index Flags field, and the Interface Index field set 533 to the LAG member link which received the MPLS echo request. 535 These procedures allow initiator LSR to: 537 o Utilize the Incoming Interface Index Sub-TLV in the Detailed 538 Interface and Label Stack TLV to derive, if the incoming interface 539 is a LAG, the identity of the incoming LAG member. 541 5.1.3. Additional Initiator LSR Procedures 543 Along with procedures described in Section 4, the procedures 544 described in this section will allow an initiator LSR to know: 546 o The expected load balance information of every LAG member link, at 547 LSR with TTL=n. 549 o With specific entropy, the expected interface index of the 550 outgoing LAG member link at TTL=n. 552 o With specific entropy, the interface index of the incoming LAG 553 member link at TTL=n+1. 555 Depending on the LAG traffic division algorithm, the messages may or 556 may not traverse different member links. The expectation is that 557 there's a relationship between the interface index of the outgoing 558 LAG member link at TTL=n and the interface index of the incoming LAG 559 member link at TTL=n+1 for all entropies examined. In other words, 560 set of entropies that load balances to outgoing LAG member link X at 561 TTL=n should all reach the nexthop on same incoming LAG member link Y 562 at TTL=n+1. 564 With additional logic, the initiator LSR can perform the following 565 checks in a scenario where the initiator LSR knows that there is a 566 LAG, with two LAG members, between TTL=n and TTL=n+1, and has the 567 multipath information to traverse the two LAG member links. 569 The initiator LSR sends two MPLS echo request messages to traverse 570 the two LAG member links at TTL=n+1: 572 o Success case: 574 * One MPLS echo request message reaches TTL=n+1 on an LAG member 575 link 1. 577 * The other MPLS echo request message reaches TTL=n+1 on an LAG 578 member link 2. 580 The two MPLS echo request messages sent by the initiator LSR reach 581 at the immediate downstream LSR from two different LAG member 582 links. 584 o Error case: 586 * One MPLS echo request message reaches TTL=n+1 on an LAG member 587 link 1. 589 * The other MPLS echo request message also reaches TTL=n+1 on an 590 LAG member link 1. 592 * One or both MPLS echo request messages cannot reach the 593 immediate downstream LSR on whichever link. 595 One or two MPLS echo request messages sent by the initiator LSR 596 cannot reach the immediate downstream LSR, or the two MPLS echo 597 request messages reach at the immediate downstream LSR from the 598 same LAG member link. 600 Note that the above defined procedures will provide a deterministic 601 result for LAG interfaces that are back-to-back connected between 602 LSRs (i.e. no L2 switch in between). If there is a L2 switch between 603 the LSR at TTL=n and the LSR at TTL=n+1, there is no guarantee that 604 traversal of every LAG member link at TTL=n will result in reaching 605 from different interface at TTL=n+1. Issues resulting from LAG with 606 L2 switch in between are further described in Appendix A. LAG 607 provisioning models in operated network should be considered when 608 analyzing the output of LSP Traceroute exercising L2 ECMPs. 610 5.2. Individual End-to-End Path Verification 612 When the Remote Interface Index Sub-TLVs are available from an LSR 613 with TTL=n, then the validation of LAG member link traversal can be 614 performed by the downstream LSR of TTL=n+1. The initiator LSR 615 follows the procedures described in Section 4.3. 617 The DDMAP validation procedures for the downstream responder LSR are 618 then updated to include the comparison of the incoming LAG member 619 link to the interface index described in the Remote Interface Index 620 Sub-TLV in the DDMAP TLV. Failure of this comparison results in the 621 return code being set to "Downstream Mapping Mismatch (5)". 623 6. LSR Capability TLV 625 This document defines a new TLV which is referred to as the "LSR 626 Capability TLV. It MAY be included in the MPLS echo request message 627 and the MPLS echo reply message. An MPLS echo request message and an 628 MPLS echo reply message MUST NOT include more than one LSR Capability 629 TLV. The presence of an LSR Capability TLV in an MPLS echo request 630 message is a request that a responder LSR includes an LSR Capability 631 TLV in the MPLS echo reply message, with the LSR Capability TLV 632 describing features and extensions that the responder LSR supports. 634 The format of the LSR Capability TLV is as below: 636 LSR Capability TLV Type is TBD1. Length is 4. The value field of 637 the LSR Capability TLV has following format: 639 0 1 2 3 640 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 641 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 642 | Type | Length | 643 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 644 | LSR Capability Flags | 645 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 647 Figure 4: LSR Capability TLV 649 Where: 651 The Type field is 2 octets in length and the value is TBD1. 653 The Length field is 2 octets in length, and the value is 4. 655 The "LSR Capability Flags" field is 4 octets in length, this 656 document defines the following flags: 658 0 1 2 3 659 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 660 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 661 | Reserved (Must Be Zero) |U|D| 662 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 664 This document defines two flags. The unallocated flags MUST be 665 set to zero when sending and ignored on receipt. Both the U and 666 the D flag MUST be cleared in the MPLS echo request message when 667 sending, and ignored on receipt. Neither, either or both the U 668 and the D flag MAY be set in the MPLS echo reply message. 670 Flag Name and Meaning 671 ---- ---------------- 673 U Upstream LAG Info Accommodation 675 An LSR sets this flag when the LSR is capable of 676 describing a LAG member link in the Incoming Interface 677 Index Sub-TLV in the Detailed Interface and 678 Label Stack TLV. 680 D Downstream LAG Info Accommodation 682 An LSR sets this flag when the LSR is capable of 683 describing LAG member links in the Local Interface 684 Index Sub-TLV and the Multipath Data Sub-TLV in the 685 Downstream Detailed Mapping TLV. 687 7. LAG Description Indicator Flag: G 689 This document defines a new flag, the "G" flag (LAG Description 690 Indicator), in the DS Flags field of the DDMAP TLV. 692 The "G" flag in the MPLS echo request message indicates the request 693 for detailed LAG information from the responder LSR. In the MPLS 694 echo reply message, the "G" flag MUST be set if the DDMAP TLV 695 describes a LAG interface. It MUST be cleared otherwise. 697 The "G" flag is defined as below: 699 The Bit Number is TBD5. 701 0 1 2 3 4 5 6 7 702 +-+-+-+-+-+-+-+-+ 703 | MBZ |G|E|L|I|N| 704 +-+-+-+-+-+-+-+-+ 705 RFC-Editor-Note: Please update above figure to place the G flag in 706 the bit number TBD5. 708 Flag Name and Meaning 709 ---- ---------------- 711 G LAG Description Indicator 713 When this flag is set in the MPLS echo request, the responder LSR 714 is requested to respond with detailed LAG information. When this 715 flag is set in the MPLS echo reply, the corresponding DDMAP TLV 716 describes a LAG interface. 718 8. Local Interface Index Sub-TLV 720 The Local Interface Index Sub-TLV describes the interface index 721 assigned by the local LSR to an egress interface. One or more Local 722 Interface Index sub-TLVs MAY appear in a DDMAP TLV. 724 The format of the Local Interface Index Sub-TLV is below: 726 0 1 2 3 727 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 728 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 729 | Type | Length | 730 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 731 | Local Interface Index | 732 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 734 Figure 5: Local Interface Index Sub-TLV 736 Where: 738 o The "Type" field is 2 octets in length, the value is TBD2. 740 o The "Length" filed 2 octets in length, and the value is 4. 742 o The "Local Interface Index" field is 4 octets in length, it is an 743 interface index assigned by a local LSR to an egress interface. 744 It's normally an unsigned integer and in network byte order. 746 9. Remote Interface Index Sub-TLV 748 The Remote Interface Index Sub-TLV is an optional TLV, it describes 749 the interface index assigned by a downstream LSR to an ingress 750 interface. One or more Remote Interface Index sub-TLVs MAY appear in 751 a DDMAP TLV. 753 The format of the Remote Interface Index Sub-TLV is as below: 755 0 1 2 3 756 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 757 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 758 | Type | Length | 759 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 760 | Remote Interface Index | 761 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 763 Figure 6: Remote Interface Index Sub-TLV 765 Where: 767 o The "Type" field is 2 octets in length, and the value is TBD3. 769 o The "Length" field is 2 octets in length, and the value is 4. 771 o The "Remote Interface Index" is 4 octets in length, it is an 772 interface index assigned by a downstream LSR to an ingress 773 interface. It's normally an unsigned integer and in network byte 774 order. 776 10. Detailed Interface and Label Stack TLV 778 The "Detailed Interface and Label Stack" object is a TLV that MAY be 779 included in an MPLS echo reply message to report the interface on 780 which the MPLS echo request message was received and the label stack 781 that was on the packet when it was received. A responder LSR MUST 782 NOT insert more than one instance of this TLV into the MPLS echo 783 reply message. This TLV allows the initiator LSR to obtain the exact 784 interface and label stack information as it appears at the responder 785 LSR. 787 Detailed Interface and Label Stack TLV Type is TBD4. Length is K + 788 Sub-TLV Length (sum of Sub-TLVs). K is the sum of all fields of this 789 TLV prior to Sub-TLVs, but the length of K depends on the Address 790 Type. Details of this information is described below. The Value 791 field has following format: 793 0 1 2 3 794 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 795 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 796 | Type | Length | 797 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 798 | Address Type | Reserved (Must Be Zero) | 799 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 800 | IP Address (4 or 16 octets) | 801 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 802 | Interface (4 or 16 octets) | 803 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 804 . . 805 . List of Sub-TLVs . 806 . . 807 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 809 Figure 7: Detailed Interface and Label Stack TLV 811 The Detailed Interface and Label Stack TLV format is derived from the 812 Interface and Label Stack TLV format (from [RFC8029]). Two changes 813 are introduced. The first is that the label stack is converted into 814 a sub-TLV. The second is that a new sub-TLV is added to describe an 815 interface index. The other fields of Detailed Interface and Label 816 Stack TLV have the same use and meaning as in [RFC8029]. A summary 817 of these fields is as below: 819 Address Type 821 The Address Type indicates if the interface is numbered or 822 unnumbered. It also determines the length of the IP Address 823 and Interface fields. The resulting total length of the 824 initial part of the TLV is listed as "K Octets". The Address 825 Type is set to one of the following values: 827 Type # Address Type K Octets 828 ------ ------------ -------- 829 1 IPv4 Numbered 16 830 2 IPv4 Unnumbered 16 831 3 IPv6 Numbered 40 832 4 IPv6 Unnumbered 28 834 IP Address and Interface 836 IPv4 addresses and interface indices are encoded in 4 octets; 837 IPv6 addresses are encoded in 16 octets. 839 If the interface upon which the echo request message was 840 received is numbered, then the Address Type MUST be set to IPv4 841 Numbered or IPv6 Numbered, the IP Address MUST be set to either 842 the LSR's Router ID or the interface address, and the Interface 843 MUST be set to the interface address. 845 If the interface is unnumbered, the Address Type MUST be either 846 IPv4 Unnumbered or IPv6 Unnumbered, the IP Address MUST be the 847 LSR's Router ID, and the Interface MUST be set to the index 848 assigned to the interface. 850 Note: Usage of IPv6 Unnumbered has the same issue as [RFC8029], 851 described in Section 3.4.2 of [RFC7439]. A solution should be 852 considered an applied to both [RFC8029] and this document. 854 10.1. Sub-TLVs 856 This section defines the sub-TLVs that MAY be included as part of the 857 Detailed Interface and Label Stack TLV. Two sub-TLVs are defined: 859 Sub-Type Sub-TLV Name 860 --------- ------------ 861 1 Incoming Label stack 862 2 Incoming Interface Index 864 10.1.1. Incoming Label Stack Sub-TLV 866 The Incoming Label Stack sub-TLV contains the label stack as received 867 by an LSR. If any TTL values have been changed by this LSR, they 868 SHOULD be restored. 870 Incoming Label Stack Sub-TLV Type is 1. Length is variable, and its 871 format is as below: 873 0 1 2 3 874 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 875 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 876 | Type | Length | 877 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 878 | Label | TC |S| TTL | 879 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 880 . . 881 . . 882 . . 883 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 884 | Label | TC |S| TTL | 885 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 887 Figure 8: Incoming Label Stack Sub-TLV 889 10.1.2. Incoming Interface Index Sub-TLV 891 The Incoming Interface Index object is a Sub-TLV that MAY be included 892 in a Detailed Interface and Label Stack TLV. The Incoming Interface 893 Index Sub-TLV describes the index assigned by a local LSR to the 894 interface which received the MPLS echo request message. 896 Incoming Interface Index Sub-TLV Type is 2. Length is 8, and its 897 format is as below: 899 0 1 2 3 900 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 901 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 902 | Type | Length | 903 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 904 | Interface Index Flags | Reserved (Must Be Zero) | 905 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 906 | Incoming Interface Index | 907 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 909 Figure 9: Incoming Interface Index Sub-TLV 911 Interface Index Flags 913 Interface Index Flags field is a bit vector with following format. 915 0 1 916 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 917 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 918 | Reserved (Must Be Zero) |M| 919 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 921 One flag is defined: M. The remaining flags MUST be set to zero 922 when sending and ignored on receipt. 924 Flag Name and Meaning 925 ---- ---------------- 927 M LAG Member Link Indicator 929 When this flag is set, interface index described in 930 this sub-TLV is a member of a LAG. 932 Incoming Interface Index 934 An Index assigned by the LSR to this interface. It's normally an 935 unsigned integer and in network byte order. 937 11. Rate Limiting On Echo Request/Reply Messages 939 For an LSP path, it may be over several LAGs. Each LAG may have many 940 member links. To exercise all the links, many Echo Request/Reply 941 messages will be sent in a short period. It's possible that those 942 messages may traverse a common path as a burst. Under some 943 circumstances this might cause congestion at the common path. To 944 avoid potential congestion, it is RECOMMENDED that implementations to 945 randomly delay the Echo Request and Reply messages at the Initiating 946 LSRs and Responder LSRs. Rate limiting of ping traffic is further 947 specified in [RFC8029] (Section 5) and [RFC6425] (Section 4.1) which 948 apply to this document as well. 950 12. Security Considerations 952 This document extends LSP Traceroute mechanism [RFC8029] to discover 953 and exercise L2 ECMP paths to determine problematic member link(s) of 954 a LAG. These on-demand diagnostic mechanisms are used by an operator 955 within an MPLS control domain. 957 [RFC8029] reviews the possible attacks and approaches to mitigate 958 possible threats when using these mechanisms. 960 To prevent leakage of vital information to untrusted users, a 961 responder LSR MUST only accept MPLS echo request messages from 962 designated trusted sources via filtering source IP address field of 963 received MPLS echo request messages. As noted in [RFC8029], spoofing 964 attacks only have a small window of opportunity. If these messages 965 are indeed hijacked (non-delivery) by an intermediate node, the use 966 of these mechanisms will determine the data plane is not working (as 967 it should). Hijacking of a responder node such that it provides a 968 legitimate reply would involve compromising the node itself and the 969 MPLS control domain. [RFC5920] provides additional MPLS network-wide 970 operation recommendations to avoid attacks and recommendations to 971 follow. Please note that source IP address filtering provides only a 972 weak form of access control and is not, in general, a reliable 973 security mechanism. Nonetheless, it is required here in the absence 974 of any more robust mechanisms that might be used. 976 13. IANA Considerations 978 13.1. LSR Capability TLV 980 The IANA is requested to assign new value TBD1 (from the range 981 4-16383) for LSR Capability TLV from the "Multiprotocol Label 982 Switching Architecture (MPLS) Label Switched Paths (LSPs) Ping 983 Parameters - TLVs" registry. 985 Value Meaning Reference 986 ----- ------- --------- 987 TBD1 LSR Capability TLV this document 989 13.1.1. LSR Capability Flags 991 The IANA is requested to create and maintain a registry entitled "LSR 992 Capability Flags" with following registration procedures: 994 Registry Name: LAG Interface Info Flags 996 Bit number Name Reference 997 ---------- ---------------------------------------- --------- 998 31 D: Downstream LAG Info Accommodation this document 999 30 U: Upstream LAG Info Accommodation this document 1000 0-29 Unassigned 1002 Assignments of LSR Capability Flags are via Standards Action 1003 [RFC8126]. 1005 13.2. Local Interface Index Sub-TLV 1007 The IANA is requested to assign new value TBD2 (from the range 1008 4-16383) for the Local Interface Index Sub-TLV from the 1009 "Multiprotocol Label Switching Architecture (MPLS) Label Switched 1010 Paths (LSPs) Ping Parameters - TLVs" registry, "Sub-TLVs for TLV 1011 Types 20" sub-registry. 1013 Value Meaning Reference 1014 ----- ------- --------- 1015 TBD2 Local Interface Index Sub-TLV this document 1017 13.2.1. Interface Index Flags 1019 The IANA is requested to create and maintain a registry entitled 1020 "Interface Index Flags" with following registration procedures: 1022 Registry Name: Interface Index Flags 1024 Bit number Name Reference 1025 ---------- ---------------------------------------- --------- 1026 15 M: LAG Member Link Indicator this document 1027 0-14 Unassigned 1029 Assignments of Interface Index Flags are via Standards Action 1030 [RFC8126]. 1032 Note that this registry is used by the Interface Index Flags field of 1033 following Sub-TLVs: 1035 o The Local Interface Index Sub-TLV which may be present in the 1036 "Downstream Detailed Mapping" TLV. 1038 o The Remote Interface Index Sub-TLV which may be present in the 1039 "Downstream Detailed Mapping" TLV. 1041 o The Incoming Interface Index Sub-TLV which may be present in the 1042 "Detailed Interface and Label Stack" TLV. 1044 13.3. Remote Interface Index Sub-TLV 1046 The IANA is requested to assign new value TBD3 (from the range 1047 32768-49161) for the Remote Interface Index Sub-TLV from the 1048 "Multiprotocol Label Switching Architecture (MPLS) Label Switched 1049 Paths (LSPs) Ping Parameters - TLVs" registry, "Sub-TLVs for TLV 1050 Types 20" sub-registry. 1052 Value Meaning Reference 1053 ----- ------- --------- 1054 TBD3 Remote Interface Index Sub-TLV this document 1056 13.4. Detailed Interface and Label Stack TLV 1058 The IANA is requested to assign new value TBD4 (from the range 1059 4-16383) for Detailed Interface and Label Stack TLV from the 1060 "Multiprotocol Label Switching Architecture (MPLS) Label Switched 1061 Paths (LSPs) Ping Parameters - TLVs" registry ([IANA-MPLS-LSP-PING]). 1063 Value Meaning Reference 1064 ----- ------- --------- 1065 TBD4 Detailed Interface and Label Stack TLV this document 1067 13.4.1. Sub-TLVs for TLV Type TBD4 1069 The IANA is requested to create and maintain a sub-registry entitled 1070 "Sub-TLVs for TLV Type TBD4" under "Multiprotocol Label Switching 1071 Architecture (MPLS) Label Switched Paths (LSPs) Ping Parameters - 1072 TLVs" registry. 1074 Initial values for this sub-registry, "Sub-TLVs for TLV Types TBD4", 1075 are described below. 1077 Sub-Type Name Reference 1078 ----------- -------------------------------------- --------- 1079 1 Incoming Label Stack this document 1080 2 Incoming Interface Index this document 1081 3-16383 Unassigned (mandatory TLVs) 1082 16384-31743 Specification Required 1083 32768-49161 Unassigned (optional TLVs) 1084 49162-64511 Specification Required 1086 Assignments of Sub-Types in the mandatory and optional spaces are via 1087 Standards Action [RFC8126]. Assignments of Sub-Types in the 1088 Specification Required space is via Specification Required [RFC8126]. 1090 13.4.2. Interface and Label Stack Address Types 1092 Since the "Detailed Interface and Label Stack TLV" shares the 1093 "Interface and Label Stack Address Types" with the "Interface and 1094 Label Stack TLV". IANA is requested to update the "Interface and 1095 Label Stack Address Types" registry to reflect this. 1097 For example, change the registry name to "Interface and Label Stack 1098 and Detailed Interface and Label Stack Address Types", and add a 1099 reference to this document. 1101 13.5. DS Flags 1103 The IANA is requested to assign a new bit number from the "DS flags" 1104 sub-registry from the "Multi-Protocol Label Switching (MPLS) Label 1105 Switched Paths (LSPs) Ping Parameters - TLVs" registry 1106 ([IANA-MPLS-LSP-PING]). 1108 Note: the "DS flags" sub-registry is created by [RFC8029]. 1110 Bit number Name Reference 1111 ---------- ---------------------------------------- --------- 1112 TBD5 G: LAG Description Indicator this document 1114 14. Acknowledgements 1116 The authors would like to thank Nagendra Kumar, Sam Aldrin, for 1117 providing useful comments and suggestions. The authors would like to 1118 thank Loa Andersson for performing a detailed review and providing 1119 number of comments. 1121 The authors also would like to extend sincere thanks to the MPLS RT 1122 review members who took time to review and provide comments. The 1123 members are Eric Osborne, Mach Chen and Yimin Shen. The suggestion 1124 by Mach Chen to generalize and create the LSR Capability TLV was 1125 tremendously helpful for this document and likely for future 1126 documents extending the MPLS LSP Ping and Traceroute mechanisms. The 1127 suggestion by Yimin Shen to create two separate validation procedures 1128 had a big impact to the contents of this document. 1130 15. References 1132 15.1. Normative References 1134 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1135 Requirement Levels", BCP 14, RFC 2119, 1136 DOI 10.17487/RFC2119, March 1997, 1137 . 1139 [RFC8029] Kompella, K., Swallow, G., Pignataro, C., Ed., Kumar, N., 1140 Aldrin, S., and M. Chen, "Detecting Multiprotocol Label 1141 Switched (MPLS) Data-Plane Failures", RFC 8029, 1142 DOI 10.17487/RFC8029, March 2017, 1143 . 1145 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 1146 Writing an IANA Considerations Section in RFCs", BCP 26, 1147 RFC 8126, DOI 10.17487/RFC8126, June 2017, 1148 . 1150 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1151 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1152 May 2017, . 1154 15.2. Informative References 1156 [IANA-MPLS-LSP-PING] 1157 IANA, "Multi-Protocol Label Switching (MPLS) Label 1158 Switched Paths (LSPs) Ping Parameters", 1159 . 1162 [IEEE802.1AX] 1163 IEEE Std. 802.1AX, "IEEE Standard for Local and 1164 metropolitan area networks - Link Aggregation", November 1165 2008. 1167 [RFC5920] Fang, L., Ed., "Security Framework for MPLS and GMPLS 1168 Networks", RFC 5920, DOI 10.17487/RFC5920, July 2010, 1169 . 1171 [RFC6425] Saxena, S., Ed., Swallow, G., Ali, Z., Farrel, A., 1172 Yasukawa, S., and T. Nadeau, "Detecting Data-Plane 1173 Failures in Point-to-Multipoint MPLS - Extensions to LSP 1174 Ping", RFC 6425, DOI 10.17487/RFC6425, November 2011, 1175 . 1177 [RFC7439] George, W., Ed. and C. Pignataro, Ed., "Gap Analysis for 1178 Operating IPv6-Only MPLS Networks", RFC 7439, 1179 DOI 10.17487/RFC7439, January 2015, 1180 . 1182 Appendix A. LAG with intermediate L2 Switch Issues 1184 Several flavors of "LAG with L2 switch" provisioning models and the 1185 corresponding MPLS data plane ECMP traversal validation issues are 1186 described in this section . 1188 A.1. Equal Numbers of LAG Members 1190 R1 ==== S1 ==== R2 1192 The issue with this LAG provisioning model is that packets traversing 1193 a LAG member from Router 1 (R1) to intermediate L2 switch (S1) can 1194 get load balanced by S1 towards Router 2 (R2). Therefore, MPLS echo 1195 request messages traversing a specific LAG member from R1 to S1 can 1196 actually reach R2 via any of the LAG members, and the sender of MPLS 1197 echo request messages has no knowledge of this nor no way to control 1198 this traversal. In the worst case, MPLS echo request messages with 1199 specific entropies to exercise every LAG members from R1 to S1 can 1200 all reach R2 via same LAG member. Thus it is impossible for MPLS 1201 echo request sender to verify that packets intended to traverse 1202 specific LAG member from R1 to S1 did actually traverse that LAG 1203 member, and to deterministically exercise "receive" processing of 1204 every LAG member on R2. (Notes, AFAICT there's not a better option 1205 than "try a bunch of entropy labels and see what responses you can 1206 get back" and that's the same remedy in all the described 1207 topologies.) 1209 A.2. Deviating Numbers of LAG Members 1211 ____ 1212 R1 ==== S1 ==== R2 1214 There are deviating number of LAG members on the two sides of the L2 1215 switch. The issue with this LAG provisioning model is the same as 1216 previous model, sender of MPLS echo request messages have no 1217 knowledge of L2 load balance algorithm nor entropy values to control 1218 the traversal. 1220 A.3. LAG Only on Right 1222 R1 ---- S1 ==== R2 1224 The issue with this LAG provisioning model is that there is no way 1225 for MPLS echo request sender to deterministically exercise both LAG 1226 members from S1 to R2. And without such, "receive" processing of R2 1227 on each LAG member cannot be verified. 1229 A.4. LAG Only on Left 1231 R1 ==== S1 ---- R2 1233 MPLS echo request sender has knowledge of how to traverse both LAG 1234 members from R1 to S1. However, both types of packets will terminate 1235 on the non-LAG interface at R2. It becomes impossible for MPLS echo 1236 request sender to know that MPLS echo request messages intended to 1237 traverse a specific LAG member from R1 to S1 did indeed traverse that 1238 LAG member. 1240 Authors' Addresses 1242 Nobo Akiya 1243 Big Switch Networks 1245 Email: nobo.akiya.dev@gmail.com 1247 George Swallow 1248 Cisco Systems 1250 Email: swallow@cisco.com 1252 Stephane Litkowski 1253 Orange 1255 Email: stephane.litkowski@orange.com 1257 Bruno Decraene 1258 Orange 1260 Email: bruno.decraene@orange.com 1261 John E. Drake 1262 Juniper Networks 1264 Email: jdrake@juniper.net 1266 Mach(Guoyi) Chen 1267 Huawei 1269 Email: mach.chen@huawei.com