idnits 2.17.1 draft-akiya-mpls-lsp-ping-lag-multipath-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- 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 (December 21, 2014) is 3385 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) == Outdated reference: A later version (-03) exists of draft-ietf-mpls-lsp-ping-registry-00 ** Obsolete normative reference: RFC 4379 (Obsoleted by RFC 8029) ** Obsolete normative reference: RFC 6424 (Obsoleted by RFC 8029) -- Obsolete informational reference (is this intentional?): RFC 5226 (Obsoleted by RFC 8126) Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 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 G. Swallow 4 Updates: 4379,6424 (if approved) Cisco Systems 5 Intended status: Standards Track S. Litkowski 6 Expires: June 24, 2015 B. Decraene 7 Orange 8 J. Drake 9 Juniper Networks 10 December 21, 2014 12 Label Switched Path (LSP) Ping/Trace Multipath Support for 13 Link Aggregation Group (LAG) Interfaces 14 draft-akiya-mpls-lsp-ping-lag-multipath-05 16 Abstract 18 This document defines an extension to the MPLS Label Switched Path 19 (LSP) Ping and Traceroute as specified in RFC 4379. The extension 20 allows the MPLS LSP Ping and Traceroute to discover and exercise 21 specific paths of Layer 2 (L2) Equal-Cost Multipath (ECMP) over Link 22 Aggregation Group (LAG) interfaces. 24 This document updates RFC4379 and RFC6424. 26 Requirements Language 28 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 29 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 30 document are to be interpreted as described in RFC 2119 [RFC2119]. 32 Status of This Memo 34 This Internet-Draft is submitted in full conformance with the 35 provisions of BCP 78 and BCP 79. 37 Internet-Drafts are working documents of the Internet Engineering 38 Task Force (IETF). Note that other groups may also distribute 39 working documents as Internet-Drafts. The list of current Internet- 40 Drafts is at http://datatracker.ietf.org/drafts/current/. 42 Internet-Drafts are draft documents valid for a maximum of six months 43 and may be updated, replaced, or obsoleted by other documents at any 44 time. It is inappropriate to use Internet-Drafts as reference 45 material or to cite them other than as "work in progress." 47 This Internet-Draft will expire on June 24, 2015. 49 Copyright Notice 51 Copyright (c) 2014 IETF Trust and the persons identified as the 52 document authors. All rights reserved. 54 This document is subject to BCP 78 and the IETF Trust's Legal 55 Provisions Relating to IETF Documents 56 (http://trustee.ietf.org/license-info) in effect on the date of 57 publication of this document. Please review these documents 58 carefully, as they describe your rights and restrictions with respect 59 to this document. Code Components extracted from this document must 60 include Simplified BSD License text as described in Section 4.e of 61 the Trust Legal Provisions and are provided without warranty as 62 described in the Simplified BSD License. 64 Table of Contents 66 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 67 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 68 1.2. Background . . . . . . . . . . . . . . . . . . . . . . . 3 69 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 4 70 3. LSR Capability Discovery . . . . . . . . . . . . . . . . . . 6 71 4. Mechanism to Discover L2 ECMP Multipath . . . . . . . . . . . 7 72 4.1. Initiator LSR Procedures . . . . . . . . . . . . . . . . 7 73 4.2. Responder LSR Procedures . . . . . . . . . . . . . . . . 7 74 4.3. Additional Initiator LSR Procedures . . . . . . . . . . . 9 75 5. Mechanism to Validate L2 ECMP Traversal . . . . . . . . . . . 10 76 5.1. Incoming LAG Member Links Verification . . . . . . . . . 11 77 5.1.1. Initiator LSR Procedures . . . . . . . . . . . . . . 11 78 5.1.2. Responder LSR Procedures . . . . . . . . . . . . . . 11 79 5.1.3. Additional Initiator LSR Procedures . . . . . . . . . 12 80 5.2. Individual End-to-End Path Verification . . . . . . . . . 13 81 6. LSR Capability TLV . . . . . . . . . . . . . . . . . . . . . 14 82 7. LAG Description Indicator Flag: G . . . . . . . . . . . . . . 15 83 8. Local Interface Index Sub-TLV . . . . . . . . . . . . . . . . 16 84 9. Remote Interface Index Sub-TLV . . . . . . . . . . . . . . . 17 85 10. Detailed Interface and Label Stack TLV . . . . . . . . . . . 18 86 10.1. Sub-TLVs . . . . . . . . . . . . . . . . . . . . . . . . 20 87 10.1.1. Incoming Label Stack Sub-TLV . . . . . . . . . . . . 20 88 10.1.2. Incoming Interface Index Sub-TLV . . . . . . . . . . 20 89 11. Security Considerations . . . . . . . . . . . . . . . . . . . 21 90 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 91 12.1. LSR Capability TLV . . . . . . . . . . . . . . . . . . . 22 92 12.1.1. LSR Capability Flags . . . . . . . . . . . . . . . . 22 93 12.2. Local Interface Index Sub-TLV . . . . . . . . . . . . . 22 94 12.2.1. Interface Index Flags . . . . . . . . . . . . . . . 23 95 12.3. Remote Interface Index Sub-TLV . . . . . . . . . . . . . 23 96 12.4. Detailed Interface and Label Stack TLV . . . . . . . . . 23 97 12.4.1. Sub-TLVs for TLV Type TBD4 . . . . . . . . . . . . . 24 98 12.5. DS Flags . . . . . . . . . . . . . . . . . . . . . . . . 24 99 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 24 100 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 25 101 14.1. Normative References . . . . . . . . . . . . . . . . . . 25 102 14.2. Informative References . . . . . . . . . . . . . . . . . 25 103 Appendix A. LAG with L2 Switch Issues . . . . . . . . . . . . . 26 104 A.1. Equal Numbers of LAG Members . . . . . . . . . . . . . . 26 105 A.2. Deviating Numbers of LAG Members . . . . . . . . . . . . 26 106 A.3. LAG Only on Right . . . . . . . . . . . . . . . . . . . . 26 107 A.4. LAG Only on Left . . . . . . . . . . . . . . . . . . . . 27 108 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27 110 1. Introduction 112 1.1. Terminology 114 The following acronyms/terms are used in this document: 116 o MPLS - Multiprotocol Label Switching. 118 o LSP - Label Switched Path. 120 o LSR - Label Switching Router. 122 o ECMP - Equal-Cost Multipath. 124 o LAG - Link Aggregation Group. 126 o Initiator LSR - LSR which sends MPLS echo request. 128 o Responder LSR - LSR which receives MPLS echo request and sends 129 MPLS echo reply. 131 1.2. Background 133 The MPLS Label Switched Path (LSP) Ping and Traceroute as specified 134 in [RFC4379] are powerful tools designed to diagnose all available 135 layer 3 (L3) paths of LSPs, i.e., provides diagnostic coverage of L3 136 Equal-Cost Multipath (ECMP). In many MPLS networks, Link Aggregation 137 Group (LAG) as defined in [IEEE802.1AX], which provide Layer 2 (L2) 138 ECMP, are often used for various reasons. MPLS LSP Ping and 139 Traceroute tools were not designed to discover and exercise specific 140 paths of L2 ECMP. The result raises a limitation for following 141 scenario when LSP X traverses over LAG Y: 143 o Label switching of LSP X over one or more member links of LAG Y 144 have succeeded. 146 o Label switching of LSP X over one or more member links of LAG Y 147 have failed. 149 o MPLS echo request for LSP X over LAG Y is load balanced over a 150 member link which is label switching successfully. 152 With the above scenario, MPLS LSP Ping and Traceroute will not be 153 able to detect the label switching failure of problematic member 154 link(s) of the LAG. In other words, lack of L2 ECMP diagnostic 155 coverage can produce an outcome where MPLS LSP Ping and Traceroute 156 can be blind to label switching failures over problematic LAG 157 interface. It is, thus, desirable to extend the MPLS LSP Ping and 158 Traceroute to have deterministic diagnostic coverage of LAG 159 interfaces. 161 Creation of this document was motivated by issues encountered in live 162 networks. 164 2. Overview 166 This document defines an extension to the MPLS LSP Ping and 167 Traceroute to describe Multipath Information for LAG member links 168 separately, thus allowing MPLS LSP Ping and Traceroute to discover 169 and exercise specific paths of L2 ECMP over LAG interfaces. Reader 170 is expected to be familiar with mechanics of the MPLS LSP Ping and 171 Traceroute described in Section 3.3 of [RFC4379] and Downstream 172 Detailed Mapping TLV (DDMAP) described in Section 3.3 of [RFC6424]. 174 MPLS echo request carries a DDMAP and an optional TLV to indicate 175 that separate load balancing information for each L2 nexthop over LAG 176 is desired in MPLS echo reply. Responder LSR places the same 177 optional TLV in the MPLS echo reply to provide acknowledgement back 178 to the initiator. It also adds, for each downstream LAG member, a 179 load balance information (i.e. multipath information and interface 180 index). The following figure and the texts provides an example using 181 an LDP network. However the problem and the mechanism is applicable 182 to all types of LSPs which can traverse over LAG interfaces. 184 <----- LDP Network -----> 186 +-------+ 187 | | 188 A-------B=======C-------E 189 | | 190 +-------D-------+ 192 ---- Non-LAG 193 ==== LAG comprising of two member links 195 Figure 1: Example LDP Network 197 When node A is initiating LSP Traceroute to node E, node B will 198 return to node A load balance information for following entries. 200 1. Downstream C over Non-LAG (upper path). 202 2. First Downstream C over LAG (middle path). 204 3. Second Downstream C over LAG (middle path). 206 4. Downstream D over Non-LAG (lower path). 208 This document defines: 210 o In Section 3, a mechanism discover capabilities of responder LSRs; 212 o In Section 4, a mechanism to discover L2 ECMP multipath 213 information; 215 o In Section 5, a mechanism to validate L2 ECMP traversal in some 216 LAG provisioning models; 218 o In Section 6, the LSR Capability TLV; 220 o In Section 7, the LAG Description Indicator flag; 222 o In Section 8, the Local Interface Index Sub-TLV; 224 o In Section 9, the Remote Interface Index Sub-TLV; 226 o In Section 10, the Detailed Interface and Label Stack TLV; 228 o In Appendix A, issues with LAG having an L2 Switch. 230 Note that the mechanism described in this document does not impose 231 any changes to scenarios where an LSP is pinned down to a particular 232 LAG member (i.e. the LAG is not treated as one logical interface by 233 the LSP). 235 Also note that many LAGs are built from p2p links, and thus router X 236 and router X+1 have the same number of LAG members. It is possible 237 to build LAGs asymmetrically by using Ethernet switches in the 238 middle. Appendix A lists some cases which this document does not 239 address; if an operator deploys LAGs in a manner similar to what's 240 shown in Appendix A, the mechanisms in this document may not suit 241 them. 243 3. LSR Capability Discovery 245 The MPLS Ping operates by an initiator LSR sending an MPLS echo 246 request message and receiving back a corresponding MPLS echo reply 247 message from a responder LSR. The MPLS Traceroute operates in a 248 similar way except the initiator LSR potentially sends multiple MPLS 249 echo request messages with incrementing TTL values. 251 There has been many extensions to the MPLS Ping and Traceroute 252 mechanism over the years. Thus it is often useful, and sometimes 253 necessary, for the initiator LSR to deterministically disambiguate 254 the difference between: 256 o The responder LSR sent the MPLS echo reply message with contents C 257 because it has feature X, Y and Z implemented. 259 o The responder LSR sent the MPLS echo reply message with contents C 260 because it has subset of features X, Y and Z implemented but not 261 all. 263 o The responder LSR sent the MPLS echo reply message with contents C 264 because it does not have features X, Y and Z implemented. 266 To allow the initiator LSR to disambiguate the above differences, 267 this document defines the LSR Capability TLV (described in 268 Section 6). When the initiator LSR wishes to discover the 269 capabilities of the responder LSR, the initiator LSR includes the LSR 270 Capability TLV in the MPLS echo request message. When the responder 271 LSR receives an MPLS echo reply message with the LSR Capability TLV 272 included, then the responder LSR MUST include the LSR Capability TLV 273 in the MPLS echo reply message with the LSR Capability TLV describing 274 features and extensions supported by the local LSR. 276 It is RECOMMENDED that implementations supporting the LAG Multipath 277 extensions defined in this document include the LSR Capability TLV in 278 MPLS echo request messages. 280 4. Mechanism to Discover L2 ECMP Multipath 282 4.1. Initiator LSR Procedures 284 The MPLS echo request carries a DDMAP with the "LAG Description 285 Indicator flag" (G) set in the DS Flags to indicate that separate 286 load balancing information for each L2 nexthop over LAG is desired in 287 MPLS echo reply. The new "LAG Description Indicator flag" is 288 described in Section 7. 290 4.2. Responder LSR Procedures 292 This section describes the handling of the new TLVs by nodes which 293 understand the "LAG Description Indicator flag". There are two cases 294 - nodes which understand the "LAG Description Indicator flag" but 295 which for some reason cannot describe LAG members separately, and 296 nodes which both understand the "LAG Description Indicator flag" and 297 are able to describe LAG members separately. Note that Section 6, 298 Section 8 and Section 9 describe the new TLVs referenced by this 299 section , and looking over the definition of the new TLVs first may 300 make it easier to read this section. 302 A responder LSR that understand the "LAG Description Indicator flag" 303 but is not capable of describing outgoing LAG member links separately 304 uses the following procedures: 306 o If the received MPLS echo request message had the LSR Capability 307 TLV, the responder LSR MUST include the LSR Capability TLV in the 308 MPLS echo reply message. 310 o The responder LSR MUST clear the "Downstream LAG Info 311 Accommodation flag" in the LSR Capability Flags field of the LSR 312 Capability TLV. This will allow the initiator LSR to understand 313 that the responder LSR cannot describe outgoing LAG member links 314 separately in the DDMAP. 316 A responder LSR that understands the "LAG Description Indicator flag" 317 and is capable of describing outgoing LAG member links separately 318 uses the follow procedures, regardless of whether or not outgoing 319 interfaces include LAG interfaces: 321 o If the received MPLS echo request message had the LSR Capability 322 TLV, the responder LSR MUST include the LSR Capability TLV in the 323 MPLS echo reply message. 325 o The responder LSR MUST set the "Downstream LAG Info Accommodation 326 flag" in the LSR Capability Flags field of the LSR Capability TLV. 328 o For each downstream that is a LAG interface: 330 * The responder LSR MUST add DDMAP in the MPLS echo reply. 332 * The responder LSR MUST set the "LAG Description Indicator flag" 333 in the DS Flags field of the DDMAP. 335 * In the DDMAP, Local Interface Index Sub-TLV, Remote Interface 336 Index Sub-TLV and Multipath Data Sub-TLV are to describe each 337 LAG member link. All other fields of the DDMAP are to describe 338 the LAG interface. 340 * For each LAG member link of this LAG interface: 342 + The responder LSR MUST add a Local Interface Index Sub-TLV 343 (described in Section 8) with the "LAG Member Link Indicator 344 flag" set in the Interface Index Flags field, describing the 345 interface index of this outgoing LAG member link (the local 346 interface index is assigned by the local LSR). 348 + The responder LSR MAY add a Remote Interface Index Sub-TLV 349 (described in Section 9) with the "LAG Member Link Indicator 350 flag" set in the Interface Index Flags field, describing the 351 interface index of the incoming LAG member link on the 352 downstream LSR (this interface index is assigned by the 353 downstream LSR). How the local LSR obtains the interface 354 index of the LAG member link on the downstream LSR is 355 outside the scope of this document. 357 + The responder LSR MUST add an Multipath Data Sub-TLV for 358 this LAG member link, if received DDMAP requested multipath 359 information. 361 Based on the procedures described above, every LAG member link will 362 have a Local Interface Index Sub-TLV and a Multipath Data Sub-TLV 363 entries in the DDMAP. The order of the Sub-TLVs in the DDMAP for a 364 LAG member link MUST be Local Interface Index Sub-TLV immediately 365 followed by Multipath Data Sub-TLV. A LAG member link may also have 366 a corresponding Remote Interface Index Sub-TLV. When a Local 367 Interface Index Sub-TLV, a Remote Interface Index-Sub-TLV and a 368 Multipath Data Sub-TLV are placed in the DDMAP to describe a LAG 369 member link, they MUST be placed in the order of Local Interface 370 Index Sub-TLV, Remote Interface Index-Sub-TLV and Multipath Data Sub- 371 TLV. 373 A responder LSR possessing a LAG interface with two member links 374 would send the following DDMAP for this LAG interface: 376 0 1 2 3 377 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 378 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 379 ~ DDMAP fields describing LAG interface with DS Flags G set ~ 380 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 381 |[MANDATORY] Local Interface Index Sub-TLV of LAG member link #1| 382 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 383 |[OPTIONAL] Remote Interface Index Sub-TLV of LAG member link #1| 384 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 385 |[MANDATORY] Multipath Data Sub-TLV LAG member link #1 | 386 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 387 |[MANDATORY] Local Interface Index Sub-TLV of LAG member link #2| 388 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 389 |[OPTIONAL] Remote Interface Index Sub-TLV of LAG member link #2| 390 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 391 |[MANDATORY] Multipath Data Sub-TLV LAG member link #2 | 392 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 393 | Label Stack Sub-TLV | 394 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 396 Figure 2: Example of DDMAP in MPLS Echo Reply 398 When none of the received multipath information maps to a particular 399 LAG member link, then the responder LSR MUST still place the Local 400 Interface Index Sub-TLV and the Multipath Data Sub-TLV for that LAG 401 member link in the DDMAP, with the Multipath Length field of the 402 Multipath Data Sub-TLV being zero. 404 4.3. Additional Initiator LSR Procedures 406 The procedures above allow an initiator LSR to: 408 o Identify whether or not the responder LSR can describe outgoing 409 LAG member links separately, by looking at the LSR Capability TLV. 411 o Utilize the value of the "LAG Description Indicator flag" in DS 412 Flags to identify whether each received DDMAP describes a LAG 413 interface or a non-LAG interface. 415 o Obtain multipath information which is expected to traverse the 416 specific LAG member link described by corresponding interface 417 index. 419 When an initiator LSR receives a DDMAP containing LAG member 420 information from a downstream LSR with TTL=n, then the subsequent 421 DDMAP sent by the initiator LSR to the downstream LSR with TTL=n+1 422 through a particular LAG member link MUST be updated with following 423 procedures: 425 o The Local Interface Index Sub-TLVs MUST be removed in the sending 426 DDMAP. 428 o If the Remote Interface Index Sub-TLVs were present and the 429 initiator LSR is traversing over a specific LAG member link, then 430 the Remote Interface Index Sub-TLV corresponding to the LAG member 431 link being traversed SHOULD be included in the sending DDMAP. All 432 other Remote Interface Index Sub-TLVs MUST be removed from the 433 sending DDMAP. 435 o The Multipath Data Sub-TLVs MUST be updated to include just one 436 Multipath Data Sub-TLV. The initiator MAY keep just the Multipath 437 Data Sub-TLV corresponding to the LAG member link being traversed, 438 or combine the Multipath Data Sub-TLVs for all LAG member links 439 into a single Multipath Data Sub-TLV when diagnosing further 440 downstream LSRs. 442 o All other fields of the DDMAP are to comply with procedures 443 described in [RFC6424]. 445 Using the DDMAP example described in the Figure 2, the DDMAP being 446 sent by the initiator LSR through LAG member link #1 to the next 447 downstream LSR should be: 449 0 1 2 3 450 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 451 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 452 ~ DDMAP fields describing LAG interface with DS Flags G set ~ 453 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 454 |[OPTIONAL] Remote Interface Index Sub-TLV of LAG member link #1| 455 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 456 | Multipath Data Sub-TLV LAG member link #1 | 457 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 458 | Label Stack Sub-TLV | 459 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 461 Figure 3: Example of DDMAP in MPLS Echo Request 463 5. Mechanism to Validate L2 ECMP Traversal 465 Section 4 defines the responder LSR procedures to constructs a DDMAP 466 for a downstream LAG, and also defines that inclusion of the Remote 467 Interface Index Sub-TLVs describing the incoming LAG member links of 468 the downstream LSR is optional. The reason why it is optional for 469 the responder LSR to include the Remote Interface Index Sub-TLVs is 470 that this information from the downstream LSR is often not available 471 on the responder LSR. In such case, the traversal of LAG member 472 links can be validated with procedures described in Section 5.1. If 473 LSRs can provide the Remote Interface Index Sub-TLVs in DDMAP 474 objects, then the validation procedures described in Section 5.2 can 475 be used. 477 5.1. Incoming LAG Member Links Verification 479 Without downstream LSRs returning remote Interface Index Sub-TLVs in 480 the DDMAP, validation of the LAG member link traversal requires that 481 initiator LSR traverses all available LAG member links and taking the 482 results through a logic. This section provides the mechanism for the 483 initiator LSR to obtain additional information from the downstream 484 LSRs and describes the additional logic in the initiator LSR to 485 validate the L2 ECMP traversal. 487 5.1.1. Initiator LSR Procedures 489 The MPLS echo request is sent with a DDMAP with the "Interface and 490 Label Stack Object Request flag" and "LAG Description Indicator flag" 491 set in the DS Flags to indicate the request for Detailed Interface 492 and Label Stack TLV with additional LAG member link information (i.e. 493 interface index) in the MPLS echo reply. 495 5.1.2. Responder LSR Procedures 497 A responder LSR that understands the "LAG Description Indicator flag" 498 but is not capable of describing incoming LAG member link is to use 499 following procedures: 501 o If the received MPLS echo request message had the LSR Capability 502 TLV, the responder LSR MUST include the LSR Capability TLV in the 503 MPLS echo reply message. 505 o The responder LSR MUST clear the "Upstream LAG Info Accommodation 506 flag" in the LSR Capability Flags field of the LSR Capability TLV. 507 This will allow the initiator LSR to understand that the responder 508 LSR cannot describe incoming LAG member link. 510 A responder LSR that understands the "LAG Description Indicator flag" 511 and is capable of describing incoming LAG member link MUST use the 512 following procedures, regardless of whether or not incoming interface 513 was a LAG interface: 515 o If the received MPLS echo request message had the LSR Capability 516 TLV, the responder LSR MUST include the LSR Capability TLV in the 517 MPLS echo reply message. 519 o The responder LSR MUST set the "Upstream LAG Info Accommodation 520 flag" in the LSR Capability Flags field of the LSR Capability TLV. 522 o When the received DDMAP had "Interface and Label Stack Object 523 Request flag" set in the DS Flags field, the responder LSR MUST 524 add the Detailed Interface and Label Stack TLV (described in 525 Section 10) in the MPLS echo reply. 527 o When the received DDMAP had "Interface and Label Stack Object 528 Request flag" set in the DS Flags field and the incoming interface 529 was a LAG, the responder LSR MUST add the Incoming Interface Index 530 Sub-TLV (described in Section 10.1.2) in the Detailed Interface 531 and Label Stack TLV. The "LAG Member Link Indicator flag" MUST be 532 set in the Interface Index Flags field, and the Interface Index 533 field set to the LAG member link which received the MPLS echo 534 request. 536 These procedures allow initiator LSR to: 538 o Identify whether or not the responder LSR can describe the 539 incoming LAG member link, by looking at the LSR Capability TLV. 541 o Utilize the Incoming Interface Index Sub-TLV in the Detailed 542 Interface and Label Stack TLV to identify, if the incoming 543 interface was a LAG, the identity of the incoming LAG member. 545 5.1.3. Additional Initiator LSR Procedures 547 Along with procedures described in Section 4, the procedures 548 described in this section will allow an initiator LSR to know: 550 o The expected load balance information of every LAG member link, at 551 LSR with TTL=n. 553 o With specific entropy, the expected interface index of the 554 outgoing LAG member link at TTL=n. 556 o With specific entropy, the interface index of the incoming LAG 557 member link at TTL=n+1. 559 Expectation is that there's a relationship between the interface 560 index of the outgoing LAG member link at TTL=n and the interface 561 index of the incoming LAG member link at TTL=n+1 for all discovered 562 entropies. In other words, set of entropies that load balances to 563 outgoing LAG member link X at TTL=n should all reach the nexthop on 564 same incoming LAG member link Y at TTL=n+1. 566 With additional logics, the initiator LSR can perform following 567 checks in a scenario where the initiator knows that there is a LAG, 568 with two LAG members, between TTL=n and TTL=n+1, and has the 569 multipath information to traverse the two LAG members. 571 The initiator LSR sends two MPLS echo request messages to traverse 572 the two LAG members at TTL=1: 574 o Success case: 576 * One MPLS echo request message reaches TTL=n+1 on an LAG member 577 1. 579 * The other MPLS echo request message reaches TTL=n+1 on an LAG 580 member 2. 582 The two MPLS echo request messages sent by the initiator LSR reach 583 two different LAG members at the immediate downstream LSR. 585 o Error case: 587 * One MPLS echo request message reaches TTL=n+1 on an LAG member 588 1. 590 * The other MPLS echo request message also reaches TTL=n+1 on an 591 LAG member 1. 593 One or two MPLS echo request messages sent by the initiator LSR 594 does not reach the immediate downstream LSR, or the two MPLS echo 595 request messages reach a same LAG member at the immediate 596 downstream LSR. 598 Note that defined procedures will provide a deterministic result for 599 LAG interfaces that are back-to-back connected between routers (i.e. 600 no L2 switch in between). If there is a L2 switch between LSR at 601 TTL=n and LSR at TTL=n+1, there is no guarantee that traversal of 602 every LAG member link at TTL=n will result in reaching different 603 interface index at TTL=n+1. Issues resulting from LAG with L2 switch 604 in between are further described in Appendix A. LAG provisioning 605 models in operated network should be considered when analyzing the 606 output of LSP Traceroute exercising L2 ECMPs. 608 5.2. Individual End-to-End Path Verification 610 When the Remote Interface Index Sub-TLVs are available from an LSR 611 with TTL=n, then the validation of LAG member link traversal can be 612 performed by the downstream LSR of TTL=n+1. The initiator LSR 613 follows the procedures described in Section 4.3. 615 The DDMAP validation procedures by the downstream responder LSR are 616 then updated to include the comparison of the incoming LAG member 617 link (which MPLS echo request was received on) to the interface index 618 described in the Remote Interface Index Sub-TLV in the DDMAP. 620 Failure of this comparison results in the return code being set to 621 "Downstream Mapping Mismatch (5)". 623 A responder LSR that is not able to perform the above additional 624 DDMAP validation procedures is considered to lack the upstream LAG 625 capability. Thus, if the received MPLS echo request contained the 626 LSR Capability TLV, then the responder LSR MUST include the LSR 627 Capability TLV in the MPLS echo reply and the LSR Capability TLV MUST 628 have the "Upstream LAG Info Accomodation flag" cleared. 630 6. LSR Capability TLV 632 The LSR Capability object is a new TLV that MAY be included in the 633 MPLS echo request message and the MPLS echo reply message. An MPLS 634 echo request message and an MPLS echo reply message MUST NOT include 635 more than one LSR Capability object. Presence of an LSR Capability 636 object in an MPLS echo request message is a request that a responder 637 LSR includes an LSR Capability object in the MPLS echo reply message, 638 with the LSR Capability object describing features and extensions 639 supported. When the received MPLS echo request message contains an 640 LSR Capability object, an responder LSR MUST include the LSR 641 Capability object in the MPLS echo reply message. 643 LSR Capability TLV Type is TBD1. Length is 4. The value field of 644 the LSR Capability TLV has following format: 646 0 1 2 3 647 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 648 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 649 | Type | Length | 650 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 651 | LSR Capability Flags | 652 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 654 Figure 4: LSR Capability TLV 656 LSR Capability Flags 658 The LSR Capability Flags field is a bit vector with following 659 format: 661 0 1 2 3 662 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 663 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 664 | Must Be Zero (Reserved) |U|D| 665 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 666 Two flags are defined: U and D. The remaining flags MUST be set 667 to zero when sending and ignored on receipt. Both U and D flags 668 MUST be cleared in MPLS echo request message when sending, and 669 ignored on receipt. Neither, either or both U and D flags MAY be 670 set in MPLS echo reply message. 672 Flag Name and Meaning 673 ---- ---------------- 675 U Upstream LAG Info Accommodation 677 An LSR sets this flag when the node is capable of 678 describing a LAG member link in the Incoming Interface 679 Index Sub-TLV in the in the Detailed Interface and 680 Label Stack TLV. 682 D Downstream LAG Info Accommodation 684 An LSR sets this flag when the node is capable of 685 describing LAG member links in the Local Interface 686 Index Sub-TLV and the Multipath Data Sub-TLV in the 687 Downstream Detailed Mapping TLV. 689 7. LAG Description Indicator Flag: G 691 One flag, G, is added in DS Flags field of the DDMAP TLV. The G flag 692 of the DS Flags field in the MPLS echo request message indicates the 693 request for detailed LAG information from the responder LSR. In the 694 MPLS echo reply message, the G flag MUST be set if the DDMAP TLV 695 describes a LAG interface. It MUST be cleared otherwise. 697 DS Flags 699 DS Flags G is added, in Bit Number TBD5, in DS Flags bit vector. 701 0 1 2 3 4 5 6 7 702 +-+-+-+-+-+-+-+-+ 703 | MBZ |G|MBZ|I|N| 704 +-+-+-+-+-+-+-+-+ 706 RFC-Editor-Note: Please update above figure to place the flag G in 707 the bit number TBD5. 709 Flag Name and Meaning 710 ---- ---------------- 712 G LAG Description Indicator 714 When this flag is set in the MPLS echo request, responder is 715 requested to respond with detailed LAG information. When this 716 flag is set in the MPLS echo reply, the corresponding DDMAP 717 describes a LAG interface. 719 8. Local Interface Index Sub-TLV 721 The Local Interface Index object is a Sub-TLV that MAY be included in 722 a DDMAP TLV. Zero or more Local Interface Index object MAY appear in 723 a DDMAP TLV. The Local Interface Index Sub-TLV describes the index 724 assigned by the local LSR to the egress interface. 726 The Local Interface Index Sub-TLV Type is TBD2. Length is 8, and the 727 Value field has following format: 729 0 1 2 3 730 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 731 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 732 | Type | Length | 733 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 734 | Interface Index Flags | Must Be Zero | 735 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 736 | Local Interface Index | 737 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 739 Figure 5: Local Interface Index Sub-TLV 741 Interface Index Flags 743 Interface Index Flags field is a bit vector with following format. 745 0 1 746 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 747 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 748 | Must Be Zero (Reserved) |M| 749 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 751 One flag is defined: M. The remaining flags MUST be set to zero 752 when sending and ignored on receipt. 754 Flag Name and Meaning 755 ---- ---------------- 757 M LAG Member Link Indicator 759 When this flag is set, interface index described in 760 this sub-TLV is a member of a LAG. 762 Local Interface Index 764 An Index assigned by the LSR to this interface. 766 9. Remote Interface Index Sub-TLV 768 The Remote Interface Index object is a Sub-TLV that MAY be included 769 in a DDMAP TLV. Zero or more Remote Interface Index object MAY 770 appear in a DDMAP TLV. The Remote Interface Index Sub-TLV describes 771 the index assigned by the downstream LSR to the ingress interface. 773 The Remote Interface Index Sub-TLV Type is TBD3. Length is 8, and 774 the Value field has following format: 776 0 1 2 3 777 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 778 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 779 | Type | Length | 780 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 781 | Interface Index Flags | Must Be Zero | 782 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 783 | Remote Interface Index | 784 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 786 Figure 6: Remote Interface Index Sub-TLV 788 Interface Index Flags 790 Interface Index Flags field is a bit vector with following format. 792 0 1 793 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 794 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 795 | Must Be Zero (Reserved) |M| 796 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 798 One flag is defined: M. The remaining flags MUST be set to zero 799 when sending and ignored on receipt. 801 Flag Name and Meaning 802 ---- ---------------- 804 M LAG Member Link Indicator 806 When this flag is set, interface index described in 807 this sub-TLV is a member of a LAG. 809 Remote Interface Index 811 An Index assigned by the downstream LSR to the ingress interface. 813 10. Detailed Interface and Label Stack TLV 815 The "Detailed Interface and Label Stack" object is a TLV that MAY be 816 included in a MPLS echo reply message to report the interface on 817 which the MPLS echo request message was received and the label stack 818 that was on the packet when it was received. A responder LSR MUST 819 NOT insert more than one instance of this TLV. This TLV allows the 820 initiator LSR to obtain the exact interface and label stack 821 information as it appears at the responder LSR. 823 Detailed Interface and Label Stack TLV Type is TBD4. Length is K + 824 Sub-TLV Length (sum of Sub-TLVs). K is the sum of all fields of this 825 TLV prior to Sub-TLVs, but the length of K depends on the Address 826 Type. Details of this information is described below. The Value 827 field has following format: 829 0 1 2 3 830 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 831 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 832 | Type | Length | 833 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 834 | Address Type | Must Be Zero | 835 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 836 | IP Address (4 or 16 octets) | 837 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 838 | Interface (4 or 16 octets) | 839 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 840 | Must Be Zero | Sub-TLV Length | 841 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 842 . . 843 . List of Sub-TLVs . 844 . . 845 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 847 Figure 7: Detailed Interface and Label Stack TLV 849 The Detailed Interface and Label Stack TLV format is derived from the 850 Interface and Label Stack TLV format (from [RFC4379]). Two changes 851 are introduced. First is that label stack, which is of variable 852 length, is converted into a sub-TLV. Second is that a new sub-TLV is 853 added to describe an interface index. The fields of Detailed 854 Interface and Label Stack TLV have the same use and meaning as in 855 [RFC4379]. A summary of the fields taken from the Interface and 856 Label Stack TLV is as below: 858 Address Type 860 The Address Type indicates if the interface is numbered or 861 unnumbered. It also determines the length of the IP Address 862 and Interface fields. The resulting total for the initial part 863 of the TLV is listed in the table below as "K Octets". The 864 Address Type is set to one of the following values: 866 Type # Address Type K Octets 867 ------ ------------ -------- 868 1 IPv4 Numbered 16 869 2 IPv4 Unnumbered 16 870 3 IPv6 Numbered 40 871 4 IPv6 Unnumbered 28 873 IP Address and Interface 875 IPv4 addresses and interface indices are encoded in 4 octets; 876 IPv6 addresses are encoded in 16 octets. 878 If the interface upon which the echo request message was 879 received is numbered, then the Address Type MUST be set to IPv4 880 Numbered or IPv6 Numbered, the IP Address MUST be set to either 881 the LSR's Router ID or the interface address, and the Interface 882 MUST be set to the interface address. 884 If the interface is unnumbered, the Address Type MUST be either 885 IPv4 Unnumbered or IPv6 Unnumbered, the IP Address MUST be the 886 LSR's Router ID, and the Interface MUST be set to the index 887 assigned to the interface. 889 Note: Usage of IPv6 Unnumbered has the same issue as [RFC4379], 890 described in Section 3.4.2 of [I-D.ietf-mpls-ipv6-only-gap]. A 891 solution should be considered an applied to both [RFC4379] and 892 this document. 894 Sub-TLV Length 895 Total length in octets of the sub-TLVs associated with this 896 TLV. 898 10.1. Sub-TLVs 900 This section defines the sub-TLVs that MAY be included as part of the 901 Detailed Interface and Label Stack TLV. 903 Sub-Type Value Field 904 --------- ------------ 905 1 Incoming Label stack 906 2 Incoming Interface Index 908 10.1.1. Incoming Label Stack Sub-TLV 910 The Incoming Label Stack sub-TLV contains the label stack as received 911 by the LSR. If any TTL values have been changed by this LSR, they 912 SHOULD be restored. 914 Incoming Label Stack Sub-TLV Type is 1. Length is variable, and the 915 Value field has following format: 917 0 1 2 3 918 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 919 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 920 | Type | Length | 921 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 922 | Label | TC |S| TTL | 923 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 924 . . 925 . . 926 . . 927 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 928 | Label | TC |S| TTL | 929 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 931 Figure 8: Incoming Label Stack Sub-TLV 933 10.1.2. Incoming Interface Index Sub-TLV 935 The Incoming Interface Index object is a Sub-TLV that MAY be included 936 in a Detailed Interface and Label Stack TLV. The Incoming Interface 937 Index Sub-TLV describes the index assigned by this LSR to the 938 interface which received the MPLS echo request message. 940 Incoming Interface Index Sub-TLV Type is 2. Length is 8, and the 941 Value field has the same format as the Local Interface Index Sub-TLV 942 described in Section 8, and has following format: 944 0 1 2 3 945 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 946 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 947 | Type | Length | 948 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 949 | Interface Index Flags | Must Be Zero | 950 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 951 | Incoming Interface Index | 952 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 954 Figure 9: Incoming Interface Index Sub-TLV 956 Interface Index Flags 958 Interface Index Flags field is a bit vector with following format. 960 0 1 961 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 962 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 963 | Must Be Zero (Reserved) |M| 964 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 966 One flag is defined: M. The remaining flags MUST be set to zero 967 when sending and ignored on receipt. 969 Flag Name and Meaning 970 ---- ---------------- 972 M LAG Member Link Indicator 974 When this flag is set, interface index described in 975 this sub-TLV is a member of a LAG. 977 Incoming Interface Index 979 An Index assigned by the LSR to this interface. 981 11. Security Considerations 983 This document extends LSP Traceroute mechanism to discover and 984 exercise L2 ECMP paths. As a result of supporting the code points 985 and procedures described in this document, additional processing are 986 required by initiator LSRs and responder LSRs, especially to compute 987 and handle increasing number of multipath information. Due to 988 additional processing, it is critical that proper security measures 989 described in [RFC4379] and [RFC6424] are followed. 991 The LSP Traceroute allows an initiator LSR to discover the paths of 992 tested LSPs, providing deep knowledge of the MPLS network. Exposing 993 such information to a malicious user is considered dangerous. To 994 prevent leakage of vital information to untrusted users, a responder 995 LSR MUST only accept MPLS echo request messages from trusted sources 996 via filtering source IP address field of received MPLS echo request 997 messages. 999 12. IANA Considerations 1001 12.1. LSR Capability TLV 1003 The IANA is requested to assign new value TBD1 for LSR Capability TLV 1004 from the "Multiprotocol Label Switching Architecture (MPLS) Label 1005 Switched Paths (LSPs) Ping Parameters - TLVs" registry. 1007 Value Meaning Reference 1008 ----- ------- --------- 1009 TBD1 LSR Capability TLV this document 1011 12.1.1. LSR Capability Flags 1013 The IANA is requested to create and maintain a registry entitled "LSR 1014 Capability Flags" with following registration procedures: 1016 Registry Name: LAG Interface Info Flags 1018 Bit number Name Reference 1019 ---------- ---------------------------------------- --------- 1020 31 D: Downstream LAG Info Accommodation this document 1021 30 U: Upstream LAG Info Accommodation this document 1022 0-29 Unassigned 1024 Assignments of LSR Capability Flags are via Standards Action 1025 [RFC5226]. 1027 12.2. Local Interface Index Sub-TLV 1029 The IANA is requested to assign new value TBD2 (from the range 1030 4-31743) for the Local Interface Index Sub-TLV from the 1031 "Multiprotocol Label Switching Architecture (MPLS) Label Switched 1032 Paths (LSPs) Ping Parameters - TLVs" registry, "Sub-TLVs for TLV 1033 Types 20" sub-registry. 1035 Value Meaning Reference 1036 ----- ------- --------- 1037 TBD2 Local Interface Index Sub-TLV this document 1039 12.2.1. Interface Index Flags 1041 The IANA is requested to create and maintain a registry entitled 1042 "Interface Index Flags" with following registration procedures: 1044 Registry Name: Interface Index Flags 1046 Bit number Name Reference 1047 ---------- ---------------------------------------- --------- 1048 15 M: LAG Member Link Indicator this document 1049 0-14 Unassigned 1051 Assignments of Interface Index Flags are via Standards Action 1052 [RFC5226]. 1054 Note that this registry is used by the Interface Index Flags field of 1055 following Sub-TLVs: 1057 o The Local Interface Index Sub-TLV which may be present in the 1058 "Downstream Detailed Mapping" TLV. 1060 o The Remote Interface Index Sub-TLV which may be present in the 1061 "Downstream Detailed Mapping" TLV. 1063 o The Incoming Interface Index Sub-TLV which may be present in the 1064 "Detailed Interface and Label Stack" TLV. 1066 12.3. Remote Interface Index Sub-TLV 1068 The IANA is requested to assign new value TBD3 (from the range 1069 32768-49161) for the Remote Interface Index Sub-TLV from the 1070 "Multiprotocol Label Switching Architecture (MPLS) Label Switched 1071 Paths (LSPs) Ping Parameters - TLVs" registry, "Sub-TLVs for TLV 1072 Types 20" sub-registry. 1074 Value Meaning Reference 1075 ----- ------- --------- 1076 TBD3 Remote Interface Index Sub-TLV this document 1078 12.4. Detailed Interface and Label Stack TLV 1080 The IANA is requested to assign new value TBD4 for Detailed Interface 1081 and Label Stack TLV from the "Multiprotocol Label Switching 1082 Architecture (MPLS) Label Switched Paths (LSPs) Ping Parameters - 1083 TLVs" registry ([IANA-MPLS-LSP-PING]). 1085 Value Meaning Reference 1086 ----- ------- --------- 1087 TBD4 Detailed Interface and Label Stack TLV this document 1089 12.4.1. Sub-TLVs for TLV Type TBD4 1091 The IANA is requested to create and maintain a sub-registry entitled 1092 "Sub-TLVs for TLV Type TBD4" under "Multiprotocol Label Switching 1093 Architecture (MPLS) Label Switched Paths (LSPs) Ping Parameters - 1094 TLVs" registry. 1096 Initial values for this sub-registry, "Sub-TLVs for TLV Types TBD4", 1097 are described below. 1099 Sub-Type Name Reference 1100 ----------- -------------------------------------- --------- 1101 1 Incoming Label Stack this document 1102 2 Incoming Interface Index this document 1103 3-16383 Unassigned (mandatory TLVs) 1104 16384-31743 Experimental 1105 32768-49161 Unassigned (optional TLVs) 1106 49162-64511 Experimental 1108 Assignments of Sub-Types in the mandatory and optional spaces are are 1109 via Standards Action [RFC5226]. Assignments of Sub-Types in the 1110 experimental space is via Specification Required [RFC5226]. 1112 12.5. DS Flags 1114 The IANA is requested to assign a new bit number from the "DS flags" 1115 sub-registry from the "Multi-Protocol Label Switching (MPLS) Label 1116 Switched Paths (LSPs) Ping Parameters - TLVs" registry 1117 ([IANA-MPLS-LSP-PING]). 1119 Note: the "DS flags" sub-registry is created by 1120 [I-D.ietf-mpls-lsp-ping-registry]. 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 [I-D.ietf-mpls-lsp-ping-registry] 1147 Decraene, B., Akiya, N., Pignataro, C., Andersson, L., and 1148 S. Aldrin, "IANA registries for LSP ping Code Points", 1149 draft-ietf-mpls-lsp-ping-registry-00 (work in progress), 1150 November 2014. 1152 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1153 Requirement Levels", BCP 14, RFC 2119, March 1997. 1155 [RFC4379] Kompella, K. and G. Swallow, "Detecting Multi-Protocol 1156 Label Switched (MPLS) Data Plane Failures", RFC 4379, 1157 February 2006. 1159 [RFC6424] Bahadur, N., Kompella, K., and G. Swallow, "Mechanism for 1160 Performing Label Switched Path Ping (LSP Ping) over MPLS 1161 Tunnels", RFC 6424, November 2011. 1163 14.2. Informative References 1165 [I-D.ietf-mpls-ipv6-only-gap] 1166 George, W. and C. Pignataro, "Gap Analysis for Operating 1167 IPv6-only MPLS Networks", draft-ietf-mpls-ipv6-only-gap-04 1168 (work in progress), November 2014. 1170 [IANA-MPLS-LSP-PING] 1171 IANA, "Multi-Protocol Label Switching (MPLS) Label 1172 Switched Paths (LSPs) Ping Parameters", 1173 . 1176 [IEEE802.1AX] 1177 IEEE Std. 802.1AX, "IEEE Standard for Local and 1178 metropolitan area networks - Link Aggregation", November 1179 2008. 1181 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 1182 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 1183 May 2008. 1185 Appendix A. LAG with L2 Switch Issues 1187 Several flavors of "LAG with L2 switch" provisioning models are 1188 described in this section, with MPLS data plane ECMP traversal 1189 validation issues with each. 1191 A.1. Equal Numbers of LAG Members 1193 R1 ==== S1 ==== R2 1195 The issue with this LAG provisioning model is that packets traversing 1196 a LAG member from R1 to S1 can get load balanced by S1 towards R2. 1197 Therefore, MPLS echo request messages traversing specific LAG member 1198 from R1 to S1 can actually reach R2 via any LAG members, and sender 1199 of MPLS echo request messages have no knowledge of this nor no way to 1200 control this traversal. In the worst case, MPLS echo request 1201 messages with specific entropies to exercise every LAG members from 1202 R1 to S1 can all reach R2 via same LAG member. Thus it is impossible 1203 for MPLS echo request sender to verify that packets intended to 1204 traverse specific LAG member from R1 to S1 did actually traverse that 1205 LAG member, and to deterministically exercise "receive" processing of 1206 every LAG member on R2. 1208 A.2. Deviating Numbers of LAG Members 1210 ____ 1211 R1 ==== S1 ==== R2 1213 There are deviating number of LAG members on the two sides of the L2 1214 switch. The issue with this LAG provisioning model is the same as 1215 previous model, sender of MPLS echo request messages have no 1216 knowledge of L2 load balance algorithm nor entropy values to control 1217 the traversal. 1219 A.3. LAG Only on Right 1221 R1 ---- S1 ==== R2 1223 The issue with this LAG provisioning model is that there is no way 1224 for MPLS echo request sender to deterministically exercise both LAG 1225 members from S1 to R2. And without such, "receive" processing of R2 1226 on each LAG member cannot be verified. 1228 A.4. LAG Only on Left 1230 R1 ==== S1 ---- R2 1232 MPLS echo request sender has knowledge of how to traverse both LAG 1233 members from R1 to S1. However, both types of packets will terminate 1234 on the non-LAG interface at R2. It becomes impossible for MPLS echo 1235 request sender to know that MPLS echo request messages intended to 1236 traverse a specific LAG member from R1 to S1 did indeed traverse that 1237 LAG member. 1239 Authors' Addresses 1241 Nobo Akiya 1242 Cisco Systems 1244 Email: nobo@cisco.com 1246 George Swallow 1247 Cisco Systems 1249 Email: swallow@cisco.com 1251 Stephane Litkowski 1252 Orange 1254 Email: stephane.litkowski@orange.com 1256 Bruno Decraene 1257 Orange 1259 Email: bruno.decraene@orange.com 1261 John E. Drake 1262 Juniper Networks 1264 Email: jdrake@juniper.net