idnits 2.17.1 draft-ietf-mpls-lsp-ping-lag-multipath-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC4379, updated by this document, for RFC5378 checks: 2002-03-27) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 23, 2015) is 3200 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 4379 (Obsoleted by RFC 8029) ** Obsolete normative reference: RFC 6424 (Obsoleted by RFC 8029) ** Obsolete normative reference: RFC 7537 (Obsoleted by RFC 8029) -- Obsolete informational reference (is this intentional?): RFC 5226 (Obsoleted by RFC 8126) Summary: 3 errors (**), 0 flaws (~~), 1 warning (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force N. Akiya 3 Internet-Draft Big Switch Networks 4 Updates: 4379,6424 (if approved) G. Swallow 5 Intended status: Standards Track Cisco Systems 6 Expires: January 24, 2016 S. Litkowski 7 B. Decraene 8 Orange 9 J. Drake 10 Juniper Networks 11 July 23, 2015 13 Label Switched Path (LSP) Ping/Trace Multipath Support for 14 Link Aggregation Group (LAG) Interfaces 15 draft-ietf-mpls-lsp-ping-lag-multipath-01 17 Abstract 19 This document defines an extension to the MPLS Label Switched Path 20 (LSP) Ping and Traceroute as specified in RFC 4379. The extension 21 allows the MPLS LSP Ping and Traceroute to discover and exercise 22 specific paths of Layer 2 (L2) Equal-Cost Multipath (ECMP) over Link 23 Aggregation Group (LAG) interfaces. 25 This document updates RFC4379 and RFC6424. 27 Requirements Language 29 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 30 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 31 document are to be interpreted as described in RFC 2119 [RFC2119]. 33 Status of This Memo 35 This Internet-Draft is submitted in full conformance with the 36 provisions of BCP 78 and BCP 79. 38 Internet-Drafts are working documents of the Internet Engineering 39 Task Force (IETF). Note that other groups may also distribute 40 working documents as Internet-Drafts. The list of current Internet- 41 Drafts is at http://datatracker.ietf.org/drafts/current/. 43 Internet-Drafts are draft documents valid for a maximum of six months 44 and may be updated, replaced, or obsoleted by other documents at any 45 time. It is inappropriate to use Internet-Drafts as reference 46 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on January 24, 2016. 50 Copyright Notice 52 Copyright (c) 2015 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (http://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the Simplified BSD License. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 68 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 69 1.2. Background . . . . . . . . . . . . . . . . . . . . . . . 3 70 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 4 71 3. LSR Capability Discovery . . . . . . . . . . . . . . . . . . 6 72 4. Mechanism to Discover L2 ECMP Multipath . . . . . . . . . . . 7 73 4.1. Initiator LSR Procedures . . . . . . . . . . . . . . . . 7 74 4.2. Responder LSR Procedures . . . . . . . . . . . . . . . . 7 75 4.3. Additional Initiator LSR Procedures . . . . . . . . . . . 9 76 5. Mechanism to Validate L2 ECMP Traversal . . . . . . . . . . . 10 77 5.1. Incoming LAG Member Links Verification . . . . . . . . . 11 78 5.1.1. Initiator LSR Procedures . . . . . . . . . . . . . . 11 79 5.1.2. Responder LSR Procedures . . . . . . . . . . . . . . 11 80 5.1.3. Additional Initiator LSR Procedures . . . . . . . . . 12 81 5.2. Individual End-to-End Path Verification . . . . . . . . . 13 82 6. LSR Capability TLV . . . . . . . . . . . . . . . . . . . . . 14 83 7. LAG Description Indicator Flag: G . . . . . . . . . . . . . . 15 84 8. Local Interface Index Sub-TLV . . . . . . . . . . . . . . . . 16 85 9. Remote Interface Index Sub-TLV . . . . . . . . . . . . . . . 17 86 10. Detailed Interface and Label Stack TLV . . . . . . . . . . . 18 87 10.1. Sub-TLVs . . . . . . . . . . . . . . . . . . . . . . . . 20 88 10.1.1. Incoming Label Stack Sub-TLV . . . . . . . . . . . . 20 89 10.1.2. Incoming Interface Index Sub-TLV . . . . . . . . . . 20 90 11. Security Considerations . . . . . . . . . . . . . . . . . . . 21 91 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 92 12.1. LSR Capability TLV . . . . . . . . . . . . . . . . . . . 22 93 12.1.1. LSR Capability Flags . . . . . . . . . . . . . . . . 22 94 12.2. Local Interface Index Sub-TLV . . . . . . . . . . . . . 22 95 12.2.1. Interface Index Flags . . . . . . . . . . . . . . . 23 96 12.3. Remote Interface Index Sub-TLV . . . . . . . . . . . . . 23 97 12.4. Detailed Interface and Label Stack TLV . . . . . . . . . 23 98 12.4.1. Sub-TLVs for TLV Type TBD4 . . . . . . . . . . . . . 24 99 12.5. DS Flags . . . . . . . . . . . . . . . . . . . . . . . . 24 100 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 24 101 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 25 102 14.1. Normative References . . . . . . . . . . . . . . . . . . 25 103 14.2. Informative References . . . . . . . . . . . . . . . . . 25 104 Appendix A. LAG with L2 Switch Issues . . . . . . . . . . . . . 26 105 A.1. Equal Numbers of LAG Members . . . . . . . . . . . . . . 26 106 A.2. Deviating Numbers of LAG Members . . . . . . . . . . . . 26 107 A.3. LAG Only on Right . . . . . . . . . . . . . . . . . . . . 27 108 A.4. LAG Only on Left . . . . . . . . . . . . . . . . . . . . 27 109 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27 111 1. Introduction 113 1.1. Terminology 115 The following acronyms/terms are used in this document: 117 o MPLS - Multiprotocol Label Switching. 119 o LSP - Label Switched Path. 121 o LSR - Label Switching Router. 123 o ECMP - Equal-Cost Multipath. 125 o LAG - Link Aggregation Group. 127 o Initiator LSR - LSR which sends MPLS echo request. 129 o Responder LSR - LSR which receives MPLS echo request and sends 130 MPLS echo reply. 132 1.2. Background 134 The MPLS Label Switched Path (LSP) Ping and Traceroute as specified 135 in [RFC4379] are powerful tools designed to diagnose all available 136 layer 3 (L3) paths of LSPs, i.e., provides diagnostic coverage of L3 137 Equal-Cost Multipath (ECMP). In many MPLS networks, Link Aggregation 138 Group (LAG) as defined in [IEEE802.1AX], which provide Layer 2 (L2) 139 ECMP, are often used for various reasons. MPLS LSP Ping and 140 Traceroute tools were not designed to discover and exercise specific 141 paths of L2 ECMP. The result raises a limitation for following 142 scenario when LSP X traverses over LAG Y: 144 o Label switching of LSP X over one or more member links of LAG Y 145 have succeeded. 147 o Label switching of LSP X over one or more member links of LAG Y 148 have failed. 150 o MPLS echo request for LSP X over LAG Y is load balanced over a 151 member link which is label switching successfully. 153 With the above scenario, MPLS LSP Ping and Traceroute will not be 154 able to detect the label switching failure of problematic member 155 link(s) of the LAG. In other words, lack of L2 ECMP diagnostic 156 coverage can produce an outcome where MPLS LSP Ping and Traceroute 157 can be blind to label switching failures over problematic LAG 158 interface. It is, thus, desirable to extend the MPLS LSP Ping and 159 Traceroute to have deterministic diagnostic coverage of LAG 160 interfaces. 162 Creation of this document was motivated by issues encountered in live 163 networks. 165 2. Overview 167 This document defines an extension to the MPLS LSP Ping and 168 Traceroute to describe Multipath Information for LAG member links 169 separately, thus allowing MPLS LSP Ping and Traceroute to discover 170 and exercise specific paths of L2 ECMP over LAG interfaces. Reader 171 is expected to be familiar with mechanics of the MPLS LSP Ping and 172 Traceroute described in Section 3.3 of [RFC4379] and Downstream 173 Detailed Mapping TLV (DDMAP) described in Section 3.3 of [RFC6424]. 175 MPLS echo request carries a DDMAP and an optional TLV to indicate 176 that separate load balancing information for each L2 nexthop over LAG 177 is desired in MPLS echo reply. Responder LSR places the same 178 optional TLV in the MPLS echo reply to provide acknowledgement back 179 to the initiator. It also adds, for each downstream LAG member, a 180 load balance information (i.e. multipath information and interface 181 index). The following figure and the texts provides an example using 182 an LDP network. However the problem and the mechanism is applicable 183 to all types of LSPs which can traverse over LAG interfaces. 185 <----- LDP Network -----> 187 +-------+ 188 | | 189 A-------B=======C-------E 190 | | 191 +-------D-------+ 193 ---- Non-LAG 194 ==== LAG comprising of two member links 196 Figure 1: Example LDP Network 198 When node A is initiating LSP Traceroute to node E, node B will 199 return to node A load balance information for following entries. 201 1. Downstream C over Non-LAG (upper path). 203 2. First Downstream C over LAG (middle path). 205 3. Second Downstream C over LAG (middle path). 207 4. Downstream D over Non-LAG (lower path). 209 This document defines: 211 o In Section 3, a mechanism discover capabilities of responder LSRs; 213 o In Section 4, a mechanism to discover L2 ECMP multipath 214 information; 216 o In Section 5, a mechanism to validate L2 ECMP traversal in some 217 LAG provisioning models; 219 o In Section 6, the LSR Capability TLV; 221 o In Section 7, the LAG Description Indicator flag; 223 o In Section 8, the Local Interface Index Sub-TLV; 225 o In Section 9, the Remote Interface Index Sub-TLV; 227 o In Section 10, the Detailed Interface and Label Stack TLV; 229 o In Appendix A, issues with LAG having an L2 Switch. 231 Note that the mechanism described in this document does not impose 232 any changes to scenarios where an LSP is pinned down to a particular 233 LAG member (i.e. the LAG is not treated as one logical interface by 234 the LSP). 236 Also note that many LAGs are built from p2p links, and thus router X 237 and router X+1 have the same number of LAG members. It is possible 238 to build LAGs asymmetrically by using Ethernet switches in the 239 middle. Appendix A lists some cases which this document does not 240 address; if an operator deploys LAGs in a manner similar to what's 241 shown in Appendix A, the mechanisms in this document may not suit 242 them. 244 3. LSR Capability Discovery 246 The MPLS Ping operates by an initiator LSR sending an MPLS echo 247 request message and receiving back a corresponding MPLS echo reply 248 message from a responder LSR. The MPLS Traceroute operates in a 249 similar way except the initiator LSR potentially sends multiple MPLS 250 echo request messages with incrementing TTL values. 252 There has been many extensions to the MPLS Ping and Traceroute 253 mechanism over the years. Thus it is often useful, and sometimes 254 necessary, for the initiator LSR to deterministically disambiguate 255 the difference between: 257 o The responder LSR sent the MPLS echo reply message with contents C 258 because it has feature X, Y and Z implemented. 260 o The responder LSR sent the MPLS echo reply message with contents C 261 because it has subset of features X, Y and Z implemented but not 262 all. 264 o The responder LSR sent the MPLS echo reply message with contents C 265 because it does not have features X, Y and Z implemented. 267 To allow the initiator LSR to disambiguate the above differences, 268 this document defines the LSR Capability TLV (described in 269 Section 6). When the initiator LSR wishes to discover the 270 capabilities of the responder LSR, the initiator LSR includes the LSR 271 Capability TLV in the MPLS echo request message. When the responder 272 LSR receives an MPLS echo reply message with the LSR Capability TLV 273 included, then the responder LSR MUST include the LSR Capability TLV 274 in the MPLS echo reply message with the LSR Capability TLV describing 275 features and extensions supported by the local LSR. 277 It is RECOMMENDED that implementations supporting the LAG Multipath 278 extensions defined in this document include the LSR Capability TLV in 279 MPLS echo request messages. 281 4. Mechanism to Discover L2 ECMP Multipath 283 4.1. Initiator LSR Procedures 285 The MPLS echo request carries a DDMAP with the "LAG Description 286 Indicator flag" (G) set in the DS Flags to indicate that separate 287 load balancing information for each L2 nexthop over LAG is desired in 288 MPLS echo reply. The new "LAG Description Indicator flag" is 289 described in Section 7. 291 4.2. Responder LSR Procedures 293 This section describes the handling of the new TLVs by nodes which 294 understand the "LAG Description Indicator flag". There are two cases 295 - nodes which understand the "LAG Description Indicator flag" but 296 which for some reason cannot describe LAG members separately, and 297 nodes which both understand the "LAG Description Indicator flag" and 298 are able to describe LAG members separately. Note that Section 6, 299 Section 8 and Section 9 describe the new TLVs referenced by this 300 section , and looking over the definition of the new TLVs first may 301 make it easier to read this section. 303 A responder LSR that understand the "LAG Description Indicator flag" 304 but is not capable of describing outgoing LAG member links separately 305 uses the following procedures: 307 o If the received MPLS echo request message had the LSR Capability 308 TLV, the responder LSR MUST include the LSR Capability TLV in the 309 MPLS echo reply message. 311 o The responder LSR MUST clear the "Downstream LAG Info 312 Accommodation flag" in the LSR Capability Flags field of the LSR 313 Capability TLV. This will allow the initiator LSR to understand 314 that the responder LSR cannot describe outgoing LAG member links 315 separately in the DDMAP. 317 A responder LSR that understands the "LAG Description Indicator flag" 318 and is capable of describing outgoing LAG member links separately 319 uses the follow procedures, regardless of whether or not outgoing 320 interfaces include LAG interfaces: 322 o If the received MPLS echo request message had the LSR Capability 323 TLV, the responder LSR MUST include the LSR Capability TLV in the 324 MPLS echo reply message. 326 o The responder LSR MUST set the "Downstream LAG Info Accommodation 327 flag" in the LSR Capability Flags field of the LSR Capability TLV. 329 o For each downstream that is a LAG interface: 331 * The responder LSR MUST add DDMAP in the MPLS echo reply. 333 * The responder LSR MUST set the "LAG Description Indicator flag" 334 in the DS Flags field of the DDMAP. 336 * In the DDMAP, Local Interface Index Sub-TLV, Remote Interface 337 Index Sub-TLV and Multipath Data Sub-TLV are to describe each 338 LAG member link. All other fields of the DDMAP are to describe 339 the LAG interface. 341 * For each LAG member link of this LAG interface: 343 + The responder LSR MUST add a Local Interface Index Sub-TLV 344 (described in Section 8) with the "LAG Member Link Indicator 345 flag" set in the Interface Index Flags field, describing the 346 interface index of this outgoing LAG member link (the local 347 interface index is assigned by the local LSR). 349 + The responder LSR MAY add a Remote Interface Index Sub-TLV 350 (described in Section 9) with the "LAG Member Link Indicator 351 flag" set in the Interface Index Flags field, describing the 352 interface index of the incoming LAG member link on the 353 downstream LSR (this interface index is assigned by the 354 downstream LSR). How the local LSR obtains the interface 355 index of the LAG member link on the downstream LSR is 356 outside the scope of this document. 358 + The responder LSR MUST add an Multipath Data Sub-TLV for 359 this LAG member link, if received DDMAP requested multipath 360 information. 362 Based on the procedures described above, every LAG member link will 363 have a Local Interface Index Sub-TLV and a Multipath Data Sub-TLV 364 entries in the DDMAP. The order of the Sub-TLVs in the DDMAP for a 365 LAG member link MUST be Local Interface Index Sub-TLV immediately 366 followed by Multipath Data Sub-TLV. A LAG member link may also have 367 a corresponding Remote Interface Index Sub-TLV. When a Local 368 Interface Index Sub-TLV, a Remote Interface Index-Sub-TLV and a 369 Multipath Data Sub-TLV are placed in the DDMAP to describe a LAG 370 member link, they MUST be placed in the order of Local Interface 371 Index Sub-TLV, Remote Interface Index-Sub-TLV and Multipath Data Sub- 372 TLV. 374 A responder LSR possessing a LAG interface with two member links 375 would send the following DDMAP for this LAG interface: 377 0 1 2 3 378 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 379 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 380 ~ DDMAP fields describing LAG interface with DS Flags G set ~ 381 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 382 |[MANDATORY] Local Interface Index Sub-TLV of LAG member link #1| 383 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 384 |[OPTIONAL] Remote Interface Index Sub-TLV of LAG member link #1| 385 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 386 |[MANDATORY] Multipath Data Sub-TLV LAG member link #1 | 387 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 388 |[MANDATORY] Local Interface Index Sub-TLV of LAG member link #2| 389 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 390 |[OPTIONAL] Remote Interface Index Sub-TLV of LAG member link #2| 391 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 392 |[MANDATORY] Multipath Data Sub-TLV LAG member link #2 | 393 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 394 | Label Stack Sub-TLV | 395 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 397 Figure 2: Example of DDMAP in MPLS Echo Reply 399 When none of the received multipath information maps to a particular 400 LAG member link, then the responder LSR MUST still place the Local 401 Interface Index Sub-TLV and the Multipath Data Sub-TLV for that LAG 402 member link in the DDMAP, with the Multipath Length field of the 403 Multipath Data Sub-TLV being zero. 405 4.3. Additional Initiator LSR Procedures 407 The procedures above allow an initiator LSR to: 409 o Identify whether or not the responder LSR can describe outgoing 410 LAG member links separately, by looking at the LSR Capability TLV. 412 o Utilize the value of the "LAG Description Indicator flag" in DS 413 Flags to identify whether each received DDMAP describes a LAG 414 interface or a non-LAG interface. 416 o Obtain multipath information which is expected to traverse the 417 specific LAG member link described by corresponding interface 418 index. 420 When an initiator LSR receives a DDMAP containing LAG member 421 information from a downstream LSR with TTL=n, then the subsequent 422 DDMAP sent by the initiator LSR to the downstream LSR with TTL=n+1 423 through a particular LAG member link MUST be updated with following 424 procedures: 426 o The Local Interface Index Sub-TLVs MUST be removed in the sending 427 DDMAP. 429 o If the Remote Interface Index Sub-TLVs were present and the 430 initiator LSR is traversing over a specific LAG member link, then 431 the Remote Interface Index Sub-TLV corresponding to the LAG member 432 link being traversed SHOULD be included in the sending DDMAP. All 433 other Remote Interface Index Sub-TLVs MUST be removed from the 434 sending DDMAP. 436 o The Multipath Data Sub-TLVs MUST be updated to include just one 437 Multipath Data Sub-TLV. The initiator MAY keep just the Multipath 438 Data Sub-TLV corresponding to the LAG member link being traversed, 439 or combine the Multipath Data Sub-TLVs for all LAG member links 440 into a single Multipath Data Sub-TLV when diagnosing further 441 downstream LSRs. 443 o All other fields of the DDMAP are to comply with procedures 444 described in [RFC6424]. 446 Using the DDMAP example described in the Figure 2, the DDMAP being 447 sent by the initiator LSR through LAG member link #1 to the next 448 downstream LSR should be: 450 0 1 2 3 451 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 452 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 453 ~ DDMAP fields describing LAG interface with DS Flags G set ~ 454 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 455 |[OPTIONAL] Remote Interface Index Sub-TLV of LAG member link #1| 456 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 457 | Multipath Data Sub-TLV LAG member link #1 | 458 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 459 | Label Stack Sub-TLV | 460 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 462 Figure 3: Example of DDMAP in MPLS Echo Request 464 5. Mechanism to Validate L2 ECMP Traversal 466 Section 4 defines the responder LSR procedures to constructs a DDMAP 467 for a downstream LAG, and also defines that inclusion of the Remote 468 Interface Index Sub-TLVs describing the incoming LAG member links of 469 the downstream LSR is optional. The reason why it is optional for 470 the responder LSR to include the Remote Interface Index Sub-TLVs is 471 that this information from the downstream LSR is often not available 472 on the responder LSR. In such case, the traversal of LAG member 473 links can be validated with procedures described in Section 5.1. If 474 LSRs can provide the Remote Interface Index Sub-TLVs in DDMAP 475 objects, then the validation procedures described in Section 5.2 can 476 be used. 478 5.1. Incoming LAG Member Links Verification 480 Without downstream LSRs returning remote Interface Index Sub-TLVs in 481 the DDMAP, validation of the LAG member link traversal requires that 482 initiator LSR traverses all available LAG member links and taking the 483 results through a logic. This section provides the mechanism for the 484 initiator LSR to obtain additional information from the downstream 485 LSRs and describes the additional logic in the initiator LSR to 486 validate the L2 ECMP traversal. 488 5.1.1. Initiator LSR Procedures 490 The MPLS echo request is sent with a DDMAP with the "Interface and 491 Label Stack Object Request flag" and "LAG Description Indicator flag" 492 set in the DS Flags to indicate the request for Detailed Interface 493 and Label Stack TLV with additional LAG member link information (i.e. 494 interface index) in the MPLS echo reply. 496 5.1.2. Responder LSR Procedures 498 A responder LSR that understands the "LAG Description Indicator flag" 499 but is not capable of describing incoming LAG member link is to use 500 following procedures: 502 o If the received MPLS echo request message had the LSR Capability 503 TLV, the responder LSR MUST include the LSR Capability TLV in the 504 MPLS echo reply message. 506 o The responder LSR MUST clear the "Upstream LAG Info Accommodation 507 flag" in the LSR Capability Flags field of the LSR Capability TLV. 508 This will allow the initiator LSR to understand that the responder 509 LSR cannot describe incoming LAG member link. 511 A responder LSR that understands the "LAG Description Indicator flag" 512 and is capable of describing incoming LAG member link MUST use the 513 following procedures, regardless of whether or not incoming interface 514 was a LAG interface: 516 o If the received MPLS echo request message had the LSR Capability 517 TLV, the responder LSR MUST include the LSR Capability TLV in the 518 MPLS echo reply message. 520 o The responder LSR MUST set the "Upstream LAG Info Accommodation 521 flag" in the LSR Capability Flags field of the LSR Capability TLV. 523 o When the received DDMAP had "Interface and Label Stack Object 524 Request flag" set in the DS Flags field, the responder LSR MUST 525 add the Detailed Interface and Label Stack TLV (described in 526 Section 10) in the MPLS echo reply. 528 o When the received DDMAP had "Interface and Label Stack Object 529 Request flag" set in the DS Flags field and the incoming interface 530 was a LAG, the responder LSR MUST add the Incoming Interface Index 531 Sub-TLV (described in Section 10.1.2) in the Detailed Interface 532 and Label Stack TLV. The "LAG Member Link Indicator flag" MUST be 533 set in the Interface Index Flags field, and the Interface Index 534 field set to the LAG member link which received the MPLS echo 535 request. 537 These procedures allow initiator LSR to: 539 o Identify whether or not the responder LSR can describe the 540 incoming LAG member link, by looking at the LSR Capability TLV. 542 o Utilize the Incoming Interface Index Sub-TLV in the Detailed 543 Interface and Label Stack TLV to identify, if the incoming 544 interface was a LAG, the identity of the incoming LAG member. 546 5.1.3. Additional Initiator LSR Procedures 548 Along with procedures described in Section 4, the procedures 549 described in this section will allow an initiator LSR to know: 551 o The expected load balance information of every LAG member link, at 552 LSR with TTL=n. 554 o With specific entropy, the expected interface index of the 555 outgoing LAG member link at TTL=n. 557 o With specific entropy, the interface index of the incoming LAG 558 member link at TTL=n+1. 560 Expectation is that there's a relationship between the interface 561 index of the outgoing LAG member link at TTL=n and the interface 562 index of the incoming LAG member link at TTL=n+1 for all discovered 563 entropies. In other words, set of entropies that load balances to 564 outgoing LAG member link X at TTL=n should all reach the nexthop on 565 same incoming LAG member link Y at TTL=n+1. 567 With additional logics, the initiator LSR can perform following 568 checks in a scenario where the initiator knows that there is a LAG, 569 with two LAG members, between TTL=n and TTL=n+1, and has the 570 multipath information to traverse the two LAG members. 572 The initiator LSR sends two MPLS echo request messages to traverse 573 the two LAG members at TTL=1: 575 o Success case: 577 * One MPLS echo request message reaches TTL=n+1 on an LAG member 578 1. 580 * The other MPLS echo request message reaches TTL=n+1 on an LAG 581 member 2. 583 The two MPLS echo request messages sent by the initiator LSR reach 584 two different LAG members at the immediate downstream LSR. 586 o Error case: 588 * One MPLS echo request message reaches TTL=n+1 on an LAG member 589 1. 591 * The other MPLS echo request message also reaches TTL=n+1 on an 592 LAG member 1. 594 One or two MPLS echo request messages sent by the initiator LSR 595 does not reach the immediate downstream LSR, or the two MPLS echo 596 request messages reach a same LAG member at the immediate 597 downstream LSR. 599 Note that defined procedures will provide a deterministic result for 600 LAG interfaces that are back-to-back connected between routers (i.e. 601 no L2 switch in between). If there is a L2 switch between LSR at 602 TTL=n and LSR at TTL=n+1, there is no guarantee that traversal of 603 every LAG member link at TTL=n will result in reaching different 604 interface index at TTL=n+1. Issues resulting from LAG with L2 switch 605 in between are further described in Appendix A. LAG provisioning 606 models in operated network should be considered when analyzing the 607 output of LSP Traceroute exercising L2 ECMPs. 609 5.2. Individual End-to-End Path Verification 611 When the Remote Interface Index Sub-TLVs are available from an LSR 612 with TTL=n, then the validation of LAG member link traversal can be 613 performed by the downstream LSR of TTL=n+1. The initiator LSR 614 follows the procedures described in Section 4.3. 616 The DDMAP validation procedures by the downstream responder LSR are 617 then updated to include the comparison of the incoming LAG member 618 link (which MPLS echo request was received on) to the interface index 619 described in the Remote Interface Index Sub-TLV in the DDMAP. 621 Failure of this comparison results in the return code being set to 622 "Downstream Mapping Mismatch (5)". 624 A responder LSR that is not able to perform the above additional 625 DDMAP validation procedures is considered to lack the upstream LAG 626 capability. Thus, if the received MPLS echo request contained the 627 LSR Capability TLV, then the responder LSR MUST include the LSR 628 Capability TLV in the MPLS echo reply and the LSR Capability TLV MUST 629 have the "Upstream LAG Info Accomodation flag" cleared. 631 6. LSR Capability TLV 633 The LSR Capability object is a new TLV that MAY be included in the 634 MPLS echo request message and the MPLS echo reply message. An MPLS 635 echo request message and an MPLS echo reply message MUST NOT include 636 more than one LSR Capability object. Presence of an LSR Capability 637 object in an MPLS echo request message is a request that a responder 638 LSR includes an LSR Capability object in the MPLS echo reply message, 639 with the LSR Capability object describing features and extensions 640 supported. When the received MPLS echo request message contains an 641 LSR Capability object, an responder LSR MUST include the LSR 642 Capability object in the MPLS echo reply message. 644 LSR Capability TLV Type is TBD1. Length is 4. The value field of 645 the LSR Capability TLV has following format: 647 0 1 2 3 648 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 649 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 650 | Type | Length | 651 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 652 | LSR Capability Flags | 653 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 655 Figure 4: LSR Capability TLV 657 LSR Capability Flags 659 The LSR Capability Flags field is a bit vector with following 660 format: 662 0 1 2 3 663 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 664 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 665 | Must Be Zero (Reserved) |U|D| 666 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 667 Two flags are defined: U and D. The remaining flags MUST be set 668 to zero when sending and ignored on receipt. Both U and D flags 669 MUST be cleared in MPLS echo request message when sending, and 670 ignored on receipt. Neither, either or both U and D flags MAY be 671 set in MPLS echo reply message. 673 Flag Name and Meaning 674 ---- ---------------- 676 U Upstream LAG Info Accommodation 678 An LSR sets this flag when the node is capable of 679 describing a LAG member link in the Incoming Interface 680 Index Sub-TLV in the in the Detailed Interface and 681 Label Stack TLV. 683 D Downstream LAG Info Accommodation 685 An LSR sets this flag when the node is capable of 686 describing LAG member links in the Local Interface 687 Index Sub-TLV and the Multipath Data Sub-TLV in the 688 Downstream Detailed Mapping TLV. 690 7. LAG Description Indicator Flag: G 692 One flag, G, is added in DS Flags field of the DDMAP TLV. The G flag 693 of the DS Flags field in the MPLS echo request message indicates the 694 request for detailed LAG information from the responder LSR. In the 695 MPLS echo reply message, the G flag MUST be set if the DDMAP TLV 696 describes a LAG interface. It MUST be cleared otherwise. 698 DS Flags 700 DS Flags G is added, in Bit Number TBD5, in DS Flags bit vector. 702 0 1 2 3 4 5 6 7 703 +-+-+-+-+-+-+-+-+ 704 | MBZ |G|MBZ|I|N| 705 +-+-+-+-+-+-+-+-+ 707 RFC-Editor-Note: Please update above figure to place the flag G in 708 the bit number TBD5. 710 Flag Name and Meaning 711 ---- ---------------- 713 G LAG Description Indicator 715 When this flag is set in the MPLS echo request, responder is 716 requested to respond with detailed LAG information. When this 717 flag is set in the MPLS echo reply, the corresponding DDMAP 718 describes a LAG interface. 720 8. Local Interface Index Sub-TLV 722 The Local Interface Index object is a Sub-TLV that MAY be included in 723 a DDMAP TLV. Zero or more Local Interface Index object MAY appear in 724 a DDMAP TLV. The Local Interface Index Sub-TLV describes the index 725 assigned by the local LSR to the egress interface. 727 The Local Interface Index Sub-TLV Type is TBD2. Length is 8, and the 728 Value field has following format: 730 0 1 2 3 731 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 732 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 733 | Type | Length | 734 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 735 | Interface Index Flags | Must Be Zero | 736 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 737 | Local Interface Index | 738 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 740 Figure 5: Local Interface Index Sub-TLV 742 Interface Index Flags 744 Interface Index Flags field is a bit vector with following format. 746 0 1 747 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 748 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 749 | Must Be Zero (Reserved) |M| 750 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 752 One flag is defined: M. The remaining flags MUST be set to zero 753 when sending and ignored on receipt. 755 Flag Name and Meaning 756 ---- ---------------- 758 M LAG Member Link Indicator 760 When this flag is set, interface index described in 761 this sub-TLV is a member of a LAG. 763 Local Interface Index 765 An Index assigned by the LSR to this interface. 767 9. Remote Interface Index Sub-TLV 769 The Remote Interface Index object is a Sub-TLV that MAY be included 770 in a DDMAP TLV. Zero or more Remote Interface Index object MAY 771 appear in a DDMAP TLV. The Remote Interface Index Sub-TLV describes 772 the index assigned by the downstream LSR to the ingress interface. 774 The Remote Interface Index Sub-TLV Type is TBD3. Length is 8, and 775 the Value field has following format: 777 0 1 2 3 778 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 779 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 780 | Type | Length | 781 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 782 | Interface Index Flags | Must Be Zero | 783 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 784 | Remote Interface Index | 785 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 787 Figure 6: Remote Interface Index Sub-TLV 789 Interface Index Flags 791 Interface Index Flags field is a bit vector with following format. 793 0 1 794 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 795 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 796 | Must Be Zero (Reserved) |M| 797 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 799 One flag is defined: M. The remaining flags MUST be set to zero 800 when sending and ignored on receipt. 802 Flag Name and Meaning 803 ---- ---------------- 805 M LAG Member Link Indicator 807 When this flag is set, interface index described in 808 this sub-TLV is a member of a LAG. 810 Remote Interface Index 812 An Index assigned by the downstream LSR to the ingress interface. 814 10. Detailed Interface and Label Stack TLV 816 The "Detailed Interface and Label Stack" object is a TLV that MAY be 817 included in a MPLS echo reply message to report the interface on 818 which the MPLS echo request message was received and the label stack 819 that was on the packet when it was received. A responder LSR MUST 820 NOT insert more than one instance of this TLV. This TLV allows the 821 initiator LSR to obtain the exact interface and label stack 822 information as it appears at the responder LSR. 824 Detailed Interface and Label Stack TLV Type is TBD4. Length is K + 825 Sub-TLV Length (sum of Sub-TLVs). K is the sum of all fields of this 826 TLV prior to Sub-TLVs, but the length of K depends on the Address 827 Type. Details of this information is described below. The Value 828 field has following format: 830 0 1 2 3 831 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 832 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 833 | Type | Length | 834 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 835 | Address Type | Must Be Zero | 836 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 837 | IP Address (4 or 16 octets) | 838 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 839 | Interface (4 or 16 octets) | 840 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 841 | Must Be Zero | Sub-TLV Length | 842 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 843 . . 844 . List of Sub-TLVs . 845 . . 846 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 848 Figure 7: Detailed Interface and Label Stack TLV 850 The Detailed Interface and Label Stack TLV format is derived from the 851 Interface and Label Stack TLV format (from [RFC4379]). Two changes 852 are introduced. First is that label stack, which is of variable 853 length, is converted into a sub-TLV. Second is that a new sub-TLV is 854 added to describe an interface index. The fields of Detailed 855 Interface and Label Stack TLV have the same use and meaning as in 856 [RFC4379]. A summary of the fields taken from the Interface and 857 Label Stack TLV is as below: 859 Address Type 861 The Address Type indicates if the interface is numbered or 862 unnumbered. It also determines the length of the IP Address 863 and Interface fields. The resulting total for the initial part 864 of the TLV is listed in the table below as "K Octets". The 865 Address Type is set to one of the following values: 867 Type # Address Type K Octets 868 ------ ------------ -------- 869 1 IPv4 Numbered 16 870 2 IPv4 Unnumbered 16 871 3 IPv6 Numbered 40 872 4 IPv6 Unnumbered 28 874 IP Address and Interface 876 IPv4 addresses and interface indices are encoded in 4 octets; 877 IPv6 addresses are encoded in 16 octets. 879 If the interface upon which the echo request message was 880 received is numbered, then the Address Type MUST be set to IPv4 881 Numbered or IPv6 Numbered, the IP Address MUST be set to either 882 the LSR's Router ID or the interface address, and the Interface 883 MUST be set to the interface address. 885 If the interface is unnumbered, the Address Type MUST be either 886 IPv4 Unnumbered or IPv6 Unnumbered, the IP Address MUST be the 887 LSR's Router ID, and the Interface MUST be set to the index 888 assigned to the interface. 890 Note: Usage of IPv6 Unnumbered has the same issue as [RFC4379], 891 described in Section 3.4.2 of [I-D.ietf-mpls-ipv6-only-gap]. A 892 solution should be considered an applied to both [RFC4379] and 893 this document. 895 Sub-TLV Length 896 Total length in octets of the sub-TLVs associated with this 897 TLV. 899 10.1. Sub-TLVs 901 This section defines the sub-TLVs that MAY be included as part of the 902 Detailed Interface and Label Stack TLV. 904 Sub-Type Value Field 905 --------- ------------ 906 1 Incoming Label stack 907 2 Incoming Interface Index 909 10.1.1. Incoming Label Stack Sub-TLV 911 The Incoming Label Stack sub-TLV contains the label stack as received 912 by the LSR. If any TTL values have been changed by this LSR, they 913 SHOULD be restored. 915 Incoming Label Stack Sub-TLV Type is 1. Length is variable, and the 916 Value field has following format: 918 0 1 2 3 919 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 920 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 921 | Type | Length | 922 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 923 | Label | TC |S| TTL | 924 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 925 . . 926 . . 927 . . 928 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 929 | Label | TC |S| TTL | 930 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 932 Figure 8: Incoming Label Stack Sub-TLV 934 10.1.2. Incoming Interface Index Sub-TLV 936 The Incoming Interface Index object is a Sub-TLV that MAY be included 937 in a Detailed Interface and Label Stack TLV. The Incoming Interface 938 Index Sub-TLV describes the index assigned by this LSR to the 939 interface which received the MPLS echo request message. 941 Incoming Interface Index Sub-TLV Type is 2. Length is 8, and the 942 Value field has the same format as the Local Interface Index Sub-TLV 943 described in Section 8, and has following format: 945 0 1 2 3 946 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 947 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 948 | Type | Length | 949 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 950 | Interface Index Flags | Must Be Zero | 951 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 952 | Incoming Interface Index | 953 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 955 Figure 9: Incoming Interface Index Sub-TLV 957 Interface Index Flags 959 Interface Index Flags field is a bit vector with following format. 961 0 1 962 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 963 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 964 | Must Be Zero (Reserved) |M| 965 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 967 One flag is defined: M. The remaining flags MUST be set to zero 968 when sending and ignored on receipt. 970 Flag Name and Meaning 971 ---- ---------------- 973 M LAG Member Link Indicator 975 When this flag is set, interface index described in 976 this sub-TLV is a member of a LAG. 978 Incoming Interface Index 980 An Index assigned by the LSR to this interface. 982 11. Security Considerations 984 This document extends LSP Traceroute mechanism to discover and 985 exercise L2 ECMP paths. As a result of supporting the code points 986 and procedures described in this document, additional processing are 987 required by initiator LSRs and responder LSRs, especially to compute 988 and handle increasing number of multipath information. Due to 989 additional processing, it is critical that proper security measures 990 described in [RFC4379] and [RFC6424] are followed. 992 The LSP Traceroute allows an initiator LSR to discover the paths of 993 tested LSPs, providing deep knowledge of the MPLS network. Exposing 994 such information to a malicious user is considered dangerous. To 995 prevent leakage of vital information to untrusted users, a responder 996 LSR MUST only accept MPLS echo request messages from trusted sources 997 via filtering source IP address field of received MPLS echo request 998 messages. 1000 12. IANA Considerations 1002 12.1. LSR Capability TLV 1004 The IANA is requested to assign new value TBD1 for LSR Capability TLV 1005 from the "Multiprotocol Label Switching Architecture (MPLS) Label 1006 Switched Paths (LSPs) Ping Parameters - TLVs" registry. 1008 Value Meaning Reference 1009 ----- ------- --------- 1010 TBD1 LSR Capability TLV this document 1012 12.1.1. LSR Capability Flags 1014 The IANA is requested to create and maintain a registry entitled "LSR 1015 Capability Flags" with following registration procedures: 1017 Registry Name: LAG Interface Info Flags 1019 Bit number Name Reference 1020 ---------- ---------------------------------------- --------- 1021 31 D: Downstream LAG Info Accommodation this document 1022 30 U: Upstream LAG Info Accommodation this document 1023 0-29 Unassigned 1025 Assignments of LSR Capability Flags are via Standards Action 1026 [RFC5226]. 1028 12.2. Local Interface Index Sub-TLV 1030 The IANA is requested to assign new value TBD2 (from the range 1031 4-31743) for the Local Interface Index Sub-TLV from the 1032 "Multiprotocol Label Switching Architecture (MPLS) Label Switched 1033 Paths (LSPs) Ping Parameters - TLVs" registry, "Sub-TLVs for TLV 1034 Types 20" sub-registry. 1036 Value Meaning Reference 1037 ----- ------- --------- 1038 TBD2 Local Interface Index Sub-TLV this document 1040 12.2.1. Interface Index Flags 1042 The IANA is requested to create and maintain a registry entitled 1043 "Interface Index Flags" with following registration procedures: 1045 Registry Name: Interface Index Flags 1047 Bit number Name Reference 1048 ---------- ---------------------------------------- --------- 1049 15 M: LAG Member Link Indicator this document 1050 0-14 Unassigned 1052 Assignments of Interface Index Flags are via Standards Action 1053 [RFC5226]. 1055 Note that this registry is used by the Interface Index Flags field of 1056 following Sub-TLVs: 1058 o The Local Interface Index Sub-TLV which may be present in the 1059 "Downstream Detailed Mapping" TLV. 1061 o The Remote Interface Index Sub-TLV which may be present in the 1062 "Downstream Detailed Mapping" TLV. 1064 o The Incoming Interface Index Sub-TLV which may be present in the 1065 "Detailed Interface and Label Stack" TLV. 1067 12.3. Remote Interface Index Sub-TLV 1069 The IANA is requested to assign new value TBD3 (from the range 1070 32768-49161) for the Remote Interface Index Sub-TLV from the 1071 "Multiprotocol Label Switching Architecture (MPLS) Label Switched 1072 Paths (LSPs) Ping Parameters - TLVs" registry, "Sub-TLVs for TLV 1073 Types 20" sub-registry. 1075 Value Meaning Reference 1076 ----- ------- --------- 1077 TBD3 Remote Interface Index Sub-TLV this document 1079 12.4. Detailed Interface and Label Stack TLV 1081 The IANA is requested to assign new value TBD4 for Detailed Interface 1082 and Label Stack TLV from the "Multiprotocol Label Switching 1083 Architecture (MPLS) Label Switched Paths (LSPs) Ping Parameters - 1084 TLVs" registry ([IANA-MPLS-LSP-PING]). 1086 Value Meaning Reference 1087 ----- ------- --------- 1088 TBD4 Detailed Interface and Label Stack TLV this document 1090 12.4.1. Sub-TLVs for TLV Type TBD4 1092 The IANA is requested to create and maintain a sub-registry entitled 1093 "Sub-TLVs for TLV Type TBD4" under "Multiprotocol Label Switching 1094 Architecture (MPLS) Label Switched Paths (LSPs) Ping Parameters - 1095 TLVs" registry. 1097 Initial values for this sub-registry, "Sub-TLVs for TLV Types TBD4", 1098 are described below. 1100 Sub-Type Name Reference 1101 ----------- -------------------------------------- --------- 1102 1 Incoming Label Stack this document 1103 2 Incoming Interface Index this document 1104 3-16383 Unassigned (mandatory TLVs) 1105 16384-31743 Experimental 1106 32768-49161 Unassigned (optional TLVs) 1107 49162-64511 Experimental 1109 Assignments of Sub-Types in the mandatory and optional spaces are are 1110 via Standards Action [RFC5226]. Assignments of Sub-Types in the 1111 experimental space is via Specification Required [RFC5226]. 1113 12.5. DS Flags 1115 The IANA is requested to assign a new bit number from the "DS flags" 1116 sub-registry from the "Multi-Protocol Label Switching (MPLS) Label 1117 Switched Paths (LSPs) Ping Parameters - TLVs" registry 1118 ([IANA-MPLS-LSP-PING]). 1120 Note: the "DS flags" sub-registry is created by [RFC7537]. 1122 Bit number Name Reference 1123 ---------- ---------------------------------------- --------- 1124 TBD5 G: LAG Description Indicator this document 1126 13. Acknowledgements 1128 The authors would like to thank Nagendra Kumar and Sam Aldrin for 1129 providing useful comments and suggestions. The authors would like to 1130 thank Loa Andersson for performing a detailed review and providing 1131 number of comments. 1133 The authors also would like to extend sincere thanks to the MPLS RT 1134 review members who took time to review and provide comments. The 1135 members are Eric Osborne, Mach Chen and Yimin Shen. The suggestion 1136 by Mach Chen to generalize and create the LSR Capability TLV was 1137 tremendously helpful for this document and likely for future 1138 documents extending the MPLS LSP Ping and Traceroute mechanism. The 1139 suggestion by Yimin Shen to create two separate validation procedures 1140 had a big impact to the contents of this document. 1142 14. References 1144 14.1. Normative References 1146 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1147 Requirement Levels", BCP 14, RFC 2119, 1148 DOI 10.17487/RFC2119, March 1997, 1149 . 1151 [RFC4379] Kompella, K. and G. Swallow, "Detecting Multi-Protocol 1152 Label Switched (MPLS) Data Plane Failures", RFC 4379, 1153 DOI 10.17487/RFC4379, February 2006, 1154 . 1156 [RFC6424] Bahadur, N., Kompella, K., and G. Swallow, "Mechanism for 1157 Performing Label Switched Path Ping (LSP Ping) over MPLS 1158 Tunnels", RFC 6424, DOI 10.17487/RFC6424, November 2011, 1159 . 1161 [RFC7537] Decraene, B., Akiya, N., Pignataro, C., Andersson, L., and 1162 S. Aldrin, "IANA Registries for LSP Ping Code Points", 1163 RFC 7537, DOI 10.17487/RFC7537, May 2015, 1164 . 1166 14.2. Informative References 1168 [I-D.ietf-mpls-ipv6-only-gap] 1169 George, W. and C. Pignataro, "Gap Analysis for Operating 1170 IPv6-only MPLS Networks", draft-ietf-mpls-ipv6-only-gap-04 1171 (work in progress), November 2014. 1173 [IANA-MPLS-LSP-PING] 1174 IANA, "Multi-Protocol Label Switching (MPLS) Label 1175 Switched Paths (LSPs) Ping Parameters", 1176 . 1179 [IEEE802.1AX] 1180 IEEE Std. 802.1AX, "IEEE Standard for Local and 1181 metropolitan area networks - Link Aggregation", November 1182 2008. 1184 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 1185 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 1186 DOI 10.17487/RFC5226, May 2008, 1187 . 1189 Appendix A. LAG with L2 Switch Issues 1191 Several flavors of "LAG with L2 switch" provisioning models are 1192 described in this section, with MPLS data plane ECMP traversal 1193 validation issues with each. 1195 A.1. Equal Numbers of LAG Members 1197 R1 ==== S1 ==== R2 1199 The issue with this LAG provisioning model is that packets traversing 1200 a LAG member from R1 to S1 can get load balanced by S1 towards R2. 1201 Therefore, MPLS echo request messages traversing specific LAG member 1202 from R1 to S1 can actually reach R2 via any LAG members, and sender 1203 of MPLS echo request messages have no knowledge of this nor no way to 1204 control this traversal. In the worst case, MPLS echo request 1205 messages with specific entropies to exercise every LAG members from 1206 R1 to S1 can all reach R2 via same LAG member. Thus it is impossible 1207 for MPLS echo request sender to verify that packets intended to 1208 traverse specific LAG member from R1 to S1 did actually traverse that 1209 LAG member, and to deterministically exercise "receive" processing of 1210 every LAG member on R2. 1212 A.2. Deviating Numbers of LAG Members 1214 ____ 1215 R1 ==== S1 ==== R2 1217 There are deviating number of LAG members on the two sides of the L2 1218 switch. The issue with this LAG provisioning model is the same as 1219 previous model, sender of MPLS echo request messages have no 1220 knowledge of L2 load balance algorithm nor entropy values to control 1221 the traversal. 1223 A.3. LAG Only on Right 1225 R1 ---- S1 ==== R2 1227 The issue with this LAG provisioning model is that there is no way 1228 for MPLS echo request sender to deterministically exercise both LAG 1229 members from S1 to R2. And without such, "receive" processing of R2 1230 on each LAG member cannot be verified. 1232 A.4. LAG Only on Left 1234 R1 ==== S1 ---- R2 1236 MPLS echo request sender has knowledge of how to traverse both LAG 1237 members from R1 to S1. However, both types of packets will terminate 1238 on the non-LAG interface at R2. It becomes impossible for MPLS echo 1239 request sender to know that MPLS echo request messages intended to 1240 traverse a specific LAG member from R1 to S1 did indeed traverse that 1241 LAG member. 1243 Authors' Addresses 1245 Nobo Akiya 1246 Big Switch Networks 1248 Email: nobo.akiya.dev@gmail.com 1250 George Swallow 1251 Cisco Systems 1253 Email: swallow@cisco.com 1255 Stephane Litkowski 1256 Orange 1258 Email: stephane.litkowski@orange.com 1260 Bruno Decraene 1261 Orange 1263 Email: bruno.decraene@orange.com 1264 John E. Drake 1265 Juniper Networks 1267 Email: jdrake@juniper.net