idnits 2.17.1 draft-akiya-mpls-lsp-ping-lag-multipath-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- 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 (November 29, 2014) is 3437 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 2, 2015 B. Decraene 7 Orange 8 J. Drake 9 Juniper Networks 10 November 29, 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-04 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 2, 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. Mechanism to Discover L2 ECMP Multipath . . . . . . . . . . . 5 71 3.1. Initiator LSR Procedures . . . . . . . . . . . . . . . . 5 72 3.2. Responder LSR Procedures . . . . . . . . . . . . . . . . 5 73 3.3. Additional Initiator LSR Procedures . . . . . . . . . . . 7 74 4. Mechanism to Validate L2 ECMP Traversal . . . . . . . . . . . 8 75 4.1. Initiator LSR Procedures . . . . . . . . . . . . . . . . 8 76 4.2. Responder LSR Procedures . . . . . . . . . . . . . . . . 9 77 4.3. Additional Initiator LSR Procedures . . . . . . . . . . . 9 78 5. LAG Interface Info TLV . . . . . . . . . . . . . . . . . . . 11 79 6. DDMAP TLV DS Flags: G . . . . . . . . . . . . . . . . . . . . 12 80 7. Interface Index Sub-TLV . . . . . . . . . . . . . . . . . . . 12 81 8. Detailed Interface and Label Stack TLV . . . . . . . . . . . 13 82 8.1. Sub-TLVs . . . . . . . . . . . . . . . . . . . . . . . . 15 83 8.1.1. Incoming Label Stack Sub-TLV . . . . . . . . . . . . 15 84 8.1.2. Incoming Interface Index Sub-TLV . . . . . . . . . . 16 85 9. Security Considerations . . . . . . . . . . . . . . . . . . . 17 86 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 87 10.1. LAG Interface Info TLV . . . . . . . . . . . . . . . . . 17 88 10.1.1. LAG Interface Info Flags . . . . . . . . . . . . . . 18 89 10.2. Interface Index Sub-TLV . . . . . . . . . . . . . . . . 18 90 10.2.1. Interface Index Flags . . . . . . . . . . . . . . . 18 91 10.3. Detailed Interface and Label Stack TLV . . . . . . . . . 19 92 10.3.1. Sub-TLVs for TLV Type TBD3 . . . . . . . . . . . . . 19 93 10.4. DS Flags . . . . . . . . . . . . . . . . . . . . . . . . 19 94 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 20 95 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 96 12.1. Normative References . . . . . . . . . . . . . . . . . . 20 97 12.2. Informative References . . . . . . . . . . . . . . . . . 20 98 Appendix A. LAG with L2 Switch Issues . . . . . . . . . . . . . 21 99 A.1. Equal Numbers of LAG Members . . . . . . . . . . . . . . 21 100 A.2. Deviating Numbers of LAG Members . . . . . . . . . . . . 21 101 A.3. LAG Only on Right . . . . . . . . . . . . . . . . . . . . 21 102 A.4. LAG Only on Left . . . . . . . . . . . . . . . . . . . . 22 103 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22 105 1. Introduction 107 1.1. Terminology 109 The following acronyms/terminologies are used in this document: 111 o MPLS - Multiprotocol Label Switching. 113 o LSP - Label Switched Path. 115 o LSR - Label Switching Router. 117 o ECMP - Equal-Cost Multipath. 119 o LAG - Link Aggregation Group. 121 o Initiator LSR - LSR which sends MPLS echo request. 123 o Responder LSR - LSR which receives MPLS echo request and sends 124 MPLS echo reply. 126 1.2. Background 128 The MPLS Label Switched Path (LSP) Ping and Traceroute as specified 129 in [RFC4379] are powerful tools designed to diagnose all available 130 layer 3 (L3) paths of LSPs, i.e. provides diagnostic coverage of L3 131 Equal-Cost Multipath (ECMP). In many MPLS networks, Link Aggregation 132 Group (LAG) as defined in [IEEE802.1AX], which provide Layer 2 (L2) 133 ECMP, are often used for various reasons. MPLS LSP Ping and 134 Traceroute tools were not designed to discover and exercise specific 135 paths of L2 ECMP. Result raises a limitation for following scenario 136 when LSP X traverses over LAG Y: 138 o Label switching of LSP X over one or more member links of LAG Y is 139 succeeding. 141 o Label switching of LSP X over one or more member links of LAG Y is 142 failing. 144 o MPLS echo request for LSP X over LAG Y is load balanced over a 145 member link which is label switching successfully. 147 With above scenario, MPLS LSP Ping and Traceroute will not be able to 148 detect the MPLS switching failure of problematic member link(s) of 149 the LAG. In other words, lack of L2 ECMP discovery and exercise 150 capability can produce an outcome where MPLS LSP Ping and Traceroute 151 can be blind to label switching failures over LAG interface that are 152 impacting MPLS traffic. It is, thus, desirable to extend the MPLS 153 LSP Ping and Traceroute to have deterministic diagnostic coverage of 154 LAG interfaces. 156 Creation of this document was motivated by issues encountered in live 157 networks. 159 2. Overview 161 This document defines an extension to the MPLS LSP Ping and 162 Traceroute to describe Multipath Information for LAG member links 163 separately, thus allowing MPLS LSP Ping and Traceroute to discover 164 and exercise specific paths of L2 ECMP over LAG interfaces. Reader 165 is expected to be familiar with mechanics of the MPLS LSP Ping and 166 Traceroute described in Section 3.3 of [RFC4379] and Downstream 167 Detailed Mapping TLV (DDMAP) described in Section 3.3 of [RFC6424]. 169 MPLS echo request carries a DDMAP and an optional TLV to indicate 170 that separate load balancing information for each L2 nexthop over LAG 171 is desired in MPLS echo reply. Responder LSR places the same 172 optional TLV in the MPLS echo reply to provide acknowledgement back 173 to the initiator. It also adds, for each downstream LAG member, a 174 load balance information (i.e. multipath information and interface 175 index). The following figure and the texts provides an example using 176 an LDP network. However the problem and the mechanism is applicable 177 to all types of LSPs which can traverse over LAG interfaces. 179 <----- LDP Network -----> 181 +-------+ 182 | | 183 A-------B=======C-------E 184 | | 185 +-------D-------+ 187 ---- Non-LAG 188 ==== LAG comprising of two member links 190 Figure 1: Example LDP Network 192 When node A is initiating LSP Traceroute to node E, node B will 193 return to node A load balance information for following entries. 195 1. Downstream C over Non-LAG (upper path). 197 2. First Downstream C over LAG (middle path). 199 3. Second Downstream C over LAG (middle path). 201 4. Downstream D over Non-LAG (lower path). 203 This document defines: 205 o In Section 3, a mechanism to discover L2 ECMP multipath 206 information; 208 o In Section 4, a mechanism to validate L2 ECMP traversal in some 209 LAG provisioning models; 211 o In Section 5, the LAG Interface Info TLV; 213 o In Section 6, the LAG Description Indicator flag; 215 o In Section 7, the Interface Index Sub-TLV; 217 o In Section 8, the Detailed Interface and Label Stack TLV; 219 o In Appendix A, issues with LAG having an L2 Switch. 221 Note that the mechanism described in this document does not impose 222 any changes to scenarios where an LSP is pinned down to a particular 223 LAG member (i.e. the LAG is not treated as one logical interface by 224 the LSP). 226 3. Mechanism to Discover L2 ECMP Multipath 228 3.1. Initiator LSR Procedures 230 The MPLS echo request carries a DDMAP and the LAG Interface Info TLV 231 (described in Section 5) to indicate that separate load balancing 232 information for each L2 nexthop over LAG is desired in MPLS echo 233 reply. 235 3.2. Responder LSR Procedures 237 Responder LSRs that understand the LAG Interface Info TLV but are 238 unable to describe outgoing LAG member links separately are to use 239 the following procedures: 241 o The responder LSR MUST add the LAG Interface Info TLV in the MPLS 242 echo reply. This will allow the initiator LSR to understand that 243 the responder LSR understood the LAG Interface Info TLV. 245 o The responder LSR MUST clear the Downstream LAG Info Accommodation 246 flag in the LAG Interface Info Flags field of the LAG Interface 247 Info TLV. This will allow the initiator LSR to understand that 248 the responder LSR understood the LAG Interface Info TLV but cannot 249 describe outgoing LAG member links separately in the DDMAP. 251 The responder LSRs that understands the LAG Interface Info TLV and 252 are able to describe outgoing LAG member links separately are to use 253 the follow procedures, regardless of whether or not outgoing 254 interfaces include LAG interfaces: 256 o The responder LSR MUST add the LAG Interface Info TLV in the MPLS 257 echo reply. 259 o The responder LSR MUST set the Downstream LAG Info Accommodation 260 flag in the LAG Interface Info Flags field of the LAG Interface 261 Info TLV. 263 o For each downstream that is a LAG interface: 265 * The responder LSR MUST add DDMAP in the MPLS echo reply. 267 * The responder LSR MUST set the LAG Description Indicator flag 268 in the DS Flags field (described in Section 6) of the DDMAP. 270 * In the DDMAP, Interface Index Sub-TLV and Multipath Data Sub- 271 TLV are to describe each LAG member link. All other fields of 272 the DDMAP are to describe the LAG interface. 274 * For each LAG member link of this LAG interface: 276 + The responder LSR MUST add an Interface Index Sub-TLV 277 (described in Section 7) with the LAG Member Link Indicator 278 flag set in the Interface Index Flags field, describing this 279 LAG member link. 281 + The responder LSR MUST add an Multipath Data Sub-TLV for 282 this LAG member link, if received DDMAP requested multipath 283 information. 285 Based on the procedures described above, every LAG member link will 286 have the Interface Index Sub-TLV and the Multipath Data Sub-TLV 287 entries in the DDMAP. When both the Interface Index Sub-TLV and the 288 Multipath Data Sub-TLV are placed in the DDMAP to describe a LAG 289 member link, Interface Index Sub-TLV MUST be added first with 290 Multipath Data Sub-TLV immediately following. 292 For example, a responder LSR possessing a LAG interface with two 293 member links would send the following DDMAP for this LAG interface: 295 0 1 2 3 296 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 297 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 298 | DDMAP fields describing LAG interface with DS Flags G set | 299 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 300 | Interface Index Sub-TLV of LAG member link #1 | 301 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 302 | Multipath Data Sub-TLV LAG member link #1 | 303 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 304 | Interface Index Sub-TLV of LAG member link #2 | 305 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 306 | Multipath Data Sub-TLV LAG member link #2 | 307 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 308 | Label Stack Sub-TLV | 309 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 311 Figure 2: Example of DDMAP in MPLS Echo Reply 313 3.3. Additional Initiator LSR Procedures 315 Above procedures allow an initiator LSR to: 317 o Require the responder LSR to always add the LAG Interface Info TLV 318 in the MPLS echo reply. This allows the initiator LSR to identify 319 whether or not the responder LSR understands the LAG Interface 320 Info TLV and can describe outgoing LAG member links separately. 322 o Utilize the value of the LAG Description Indicator flag in DS 323 Flags to identify whether each DDMAP describes a LAG interface or 324 a non-LAG interface. 326 o Obtain multipath information which is expected to traverse the 327 specific LAG member link described by corresponding interface 328 index. 330 When an initiator LSR receives a DDMAP containing LAG member 331 information from a downstream LSR with TTL=n, then the subsequent 332 DDMAP sent by the initiator LSR to the downstream LSR with TTL=n+1 333 through a particular LAG member link MUST be updated with following 334 procedures: 336 o The Interface Index Sub-TLVs MUST NOT be present in the sending 337 DDMAP. 339 o The Multipath Data Sub-TLVs SHOULD be updated to include just the 340 one corresponding to the LAG member link being traversed. The 341 initiator LSR MAY combine the Multipath Data Sub-TLVs for all LAG 342 member links into a single Multipath Data Sub-TLV, but there MUST 343 be only one Multipath Data Sub-TLV in the sending DDMAP. 345 o All other fields of the DDMAP are to comply with procedures 346 described in [RFC6424]. 348 Using the DDMAP example described in the Figure 2, the DDMAP being 349 sent by the initiator LSR through LAG member link #1 to the next 350 downstream LSR should be: 352 0 1 2 3 353 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 354 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 355 | DDMAP fields describing LAG interface with DS Flags G set | 356 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 357 | Multipath Data Sub-TLV LAG member link #1 | 358 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 359 | Label Stack Sub-TLV | 360 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 362 Figure 3: Example of DDMAP in MPLS Echo Request 364 4. Mechanism to Validate L2 ECMP Traversal 366 This document does not update the FEC validation procedures nor the 367 DDMAP validation procedures, specified in [RFC4379] and [RFC6424] 368 respectively. Rather this document provides the mechanism for the 369 initiator LSR to obtain additional information from the downstream 370 LSRs when incoming and/or outgoing interfaces are LAGs. With this 371 additional information, it is the responsibility of the initiator LSR 372 to validate the L2 ECMP traversal. 374 4.1. Initiator LSR Procedures 376 The MPLS echo request is sent with a DDMAP with DS Flags I set and 377 the optional LAG Interface Info TLV to indicate the request for 378 Detailed Interface and Label Stack TLV with additional LAG member 379 link information (i.e. interface index) in the MPLS echo reply. 381 4.2. Responder LSR Procedures 383 Responder LSRs that understands the LAG Interface Info TLV but unable 384 to describe incoming LAG member link are to use following procedures: 386 o The responder LSR MUST add the LAG Interface Info TLV in the MPLS 387 echo reply. This will allow the initiator LSR to understand that 388 the responder LSR understood the LAG Interface Info TLV. 390 o The responder LSR MUST clear The Upstream LAG Info Accommodation 391 flag in the LAG Interface Info Flags field of the LAG Interface 392 Info TLV. This will allow the initiator LSR to understand that 393 the responder LSR understood the LAG Interface Info TLV but cannot 394 describe incoming LAG member link. 396 The responder LSRs that understands the LAG Interface Info TLV and 397 able to describe incoming LAG member link MUST use the following 398 procedures, regardless of whether or not incoming interface was a LAG 399 interface: 401 o Add the LAG Interface Info TLV in the MPLS echo reply to provide 402 acknowledgement back to the initiator. The Upstream LAG Info 403 Accommodation flag MUST be set in the LAG Interface Info Flags 404 field. 406 o When the received DDMAP had DS Flags I set, add the Detailed 407 Interface and Label Stack TLV (described in Section 8) in the MPLS 408 echo reply. 410 o When the received DDMAP had DS Flags I set and incoming interface 411 was a LAG, add the Incoming Interface Index Sub-TLV (described in 412 Section 8.1.2). The LAG Member Link Indicator flag MUST be set in 413 the Interface Index Flags field, and the Interface Index field set 414 to the LAG member link which received the MPLS echo request. 416 These procedures allow initiator LSR to: 418 o Identify whether or not the responder LSR understands the LAG 419 Interface Info TLV and can describe the incoming LAG member links 420 (the responder LSR is mandated to always add the LAG Interface 421 Info TLV in the MPLS echo reply). 423 4.3. Additional Initiator LSR Procedures 425 Along with procedures described in Section 3, described procedures in 426 this section will allow an initiator LSR to know: 428 o The expected load balance information of every LAG member link, at 429 LSR with TTL=n. 431 o With specific entropy, the expected interface index of the 432 outgoing LAG member link at TTL=n. 434 o With specific entropy, the interface index of the incoming LAG 435 member link at TTL=n+1. 437 Expectation is that there's a relationship between the interface 438 index of the outgoing LAG member link at TTL=n and the interface 439 index of the incoming LAG member link at TTL=n+1 for all discovered 440 entropies. In other words, set of entropies that load balances to 441 outgoing LAG member link X at TTL=n should all reach the nexthop on 442 same incoming LAG member link Y at TTL=n+1. 444 With additional logics added in the initiator LSR, following checks 445 can be performed: 447 o Success case: 449 * Traversing LAG member=1 at TTL=n results in LAG member=1' as 450 the incoming interface at TTL=n+1. 452 * Traversing LAG member=2 at TTL=n results in LAG member=2' as 453 the incoming interface at TTL=n+1. 455 o Error case: 457 * Traversing LAG member=1 at TTL=n results in LAG member=1' as 458 the incoming interface at TTL=n+1. 460 * Traversing LAG member=2 at TTL=n results in LAG member=1' as 461 the incoming interface at TTL=n+1. 463 Note that defined procedures will provide a deterministic result for 464 LAG interfaces that are back-to-back connected between routers (i.e. 465 no L2 switch in between). If there is a L2 switch between LSR at 466 TTL=n and LSR at TTL=n+1, there is no guarantee that traversal of 467 every LAG member link at TTL=n will result in reaching different 468 interface index at TTL=n+1. Issues resulting from LAG with L2 switch 469 in between are further described in Appendix A. LAG provisioning 470 models in operated network should be considered when analyzing the 471 output of LSP Traceroute exercising L2 ECMPs. 473 5. LAG Interface Info TLV 475 The LAG Interface Info object is a new TLV that MAY be included in 476 the MPLS echo request message. An MPLS echo request MUST NOT include 477 more than one LAG Interface Info object. Presence of LAG Interface 478 Info object is a request that responder LSR describes upstream and 479 downstream LAG interfaces according to procedures defined in this 480 document. If the responder LSR is able to accommodate this request, 481 then the LAG Interface Info object MUST be included in the MPLS echo 482 reply message. 484 LAG Interface Info TLV Type is TBD1. Length is 4. The Value field 485 of LAG Interface TLV has following format: 487 0 1 2 3 488 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 489 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 490 | Type | Length | 491 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 492 | LAG Interface Info Flags | Must Be Zero | 493 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 495 Figure 4: LAG Interface Info TLV 497 LAG Interface Info Flags 499 LAG Interface Info Flags field is a bit vector with following 500 format. 502 0 1 503 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 504 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 505 | Must Be Zero (Reserved) |U|D| 506 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 508 Two flags are defined: U and D. The remaining flags MUST be set 509 to zero when sending and ignored on receipt. Both U and D flags 510 MUST be cleared in MPLS echo request message when sending, and 511 ignored on receipt. Either or both U and D flags MAY be set in 512 MPLS echo reply message. 514 Flag Name and Meaning 515 ---- ---------------- 517 U Upstream LAG Info Accommodation 519 When this flag is set, LSR is capable of placing Incoming 520 Interface Index Sub-TLV, describing LAG member link, in 521 the Detailed Interface and Label Stack TLV. 523 D Downstream LAG Info Accommodation 525 When this flag is set, LSR is capable of placing Interface 526 Index Sub-TLV and Multipath Data Sub-TLV, describing LAG 527 member link, in the Downstream Detailed Mapping TLV. 529 6. DDMAP TLV DS Flags: G 531 One flag, G, is added in DS Flags field of the DDMAP TLV. The G flag 532 of the DS Flags field has no meaning in the MPLS echo request 533 message. The G flag MUST therefore be cleared when sending, and 534 ignored on the receipt of the MPLS echo request message. In the MPLS 535 echo reply message, G flag MUST be set if the DDMAP TLV describes a 536 LAG interface. It MUST be cleared otherwise. 538 DS Flags 540 DS Flags G is added, in Bit Number TBD4, in DS Flags bit vector. 542 0 1 2 3 4 5 6 7 543 +-+-+-+-+-+-+-+-+ 544 | MBZ |G|MBZ|I|N| 545 +-+-+-+-+-+-+-+-+ 547 RFC-Editor-Note: Please update above figure to place the flag G in 548 the bit number TBD4. 550 Flag Name and Meaning 551 ---- ---------------- 553 G LAG Description Indicator 555 When this flag is set, DDMAP describes a LAG interface. 557 7. Interface Index Sub-TLV 559 The Interface Index object is a Sub-TLV that MAY be included in a 560 DDMAP TLV. Zero or more Interface Index object MAY appear in a DDMAP 561 TLV. The Interface Index Sub-TLV describes the index assigned by 562 local LSR to the egress interface. 564 Interface Index Sub-TLV Type is TBD2. Length is 8, and the Value 565 field has following format: 567 0 1 2 3 568 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 569 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 570 | Type | Length | 571 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 572 | Interface Index Flags | Must Be Zero | 573 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 574 | Interface Index | 575 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 577 Figure 5: Interface Index Sub-TLV 579 Interface Index Flags 581 Interface Index Flags field is a bit vector with following format. 583 0 1 584 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 585 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 586 | Must Be Zero (Reserved) |M| 587 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 589 One flag is defined: M. The remaining flags MUST be set to zero 590 when sending and ignored on receipt. 592 Flag Name and Meaning 593 ---- ---------------- 595 M LAG Member Link Indicator 597 When this flag is set, interface index described in 598 this sub-TLV is member of a LAG. 600 Interface Index 602 Index assigned by the LSR to this interface. 604 8. Detailed Interface and Label Stack TLV 606 The "Detailed Interface and Label Stack" object is a TLV that MAY be 607 included in a MPLS echo reply message to report the interface on 608 which the MPLS echo request message was received and the label stack 609 that was on the packet when it was received. A responder LSR MUST 610 NOT insert more than one instance of this TLV. This TLV allows the 611 initiator LSR to obtain the exact interface and label stack 612 information as it appears at the responder LSR. 614 Detailed Interface and Label Stack TLV Type is TBD3. Length is K + 615 Sub-TLV Length (sum of Sub-TLVs). K is the sum of all fields of this 616 TLV prior to Sub-TLVs, but the length of K depends on the Address 617 Type. Details of this information is described below. The Value 618 field has following format: 620 0 1 2 3 621 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 622 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 623 | Type | Length | 624 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 625 | Address Type | Must Be Zero | 626 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 627 | IP Address (4 or 16 octets) | 628 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 629 | Interface (4 or 16 octets) | 630 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 631 | Must Be Zero | Sub-TLV Length | 632 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 633 . . 634 . List of Sub-TLVs . 635 . . 636 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 638 Figure 6: Detailed Interface and Label Stack TLV 640 The Detailed Interface and Label Stack TLV format is derived from the 641 Interface and Label Stack TLV format (from [RFC4379]). Two changes 642 are introduced. First is that label stack, which is of variable 643 length, is converted into a sub-TLV. Second is that a new sub-TLV is 644 added to describe an interface index. The fields of Detailed 645 Interface and Label Stack TLV have the same use and meaning as in 646 [RFC4379]. A summary of the fields taken from the Interface and 647 Label Stack TLV is as below: 649 Address Type 651 The Address Type indicates if the interface is numbered or 652 unnumbered. It also determines the length of the IP Address 653 and Interface fields. The resulting total for the initial part 654 of the TLV is listed in the table below as "K Octets". The 655 Address Type is set to one of the following values: 657 Type # Address Type K Octets 658 ------ ------------ -------- 659 1 IPv4 Numbered 16 660 2 IPv4 Unnumbered 16 661 3 IPv6 Numbered 40 662 4 IPv6 Unnumbered 28 664 IP Address and Interface 666 IPv4 addresses and interface indices are encoded in 4 octets; 667 IPv6 addresses are encoded in 16 octets. 669 If the interface upon which the echo request message was 670 received is numbered, then the Address Type MUST be set to IPv4 671 Numbered or IPv6 Numbered, the IP Address MUST be set to either 672 the LSR's Router ID or the interface address, and the Interface 673 MUST be set to the interface address. 675 If the interface is unnumbered, the Address Type MUST be either 676 IPv4 Unnumbered or IPv6 Unnumbered, the IP Address MUST be the 677 LSR's Router ID, and the Interface MUST be set to the index 678 assigned to the interface. 680 Note: Usage of IPv6 Unnumbered has the same issue as [RFC4379], 681 described in Section 3.4.2 of [I-D.ietf-mpls-ipv6-only-gap]. A 682 solution should be considered an applied to both [RFC4379] and 683 this document. 685 Sub-TLV Length 687 Total length in octets of the sub-TLVs associated with this 688 TLV. 690 8.1. Sub-TLVs 692 This section defines the sub-TLVs that MAY be included as part of the 693 Detailed Interface and Label Stack TLV. 695 Sub-Type Value Field 696 --------- ------------ 697 1 Incoming Label stack 698 2 Incoming Interface Index 700 8.1.1. Incoming Label Stack Sub-TLV 702 The Incoming Label Stack sub-TLV contains the label stack as received 703 by the LSR. If any TTL values have been changed by this LSR, they 704 SHOULD be restored. 706 Incoming Label Stack Sub-TLV Type is 1. Length is variable, and the 707 Value field has following format: 709 0 1 2 3 710 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 711 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 712 | Type | Length | 713 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 714 | Label | TC |S| TTL | 715 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 716 . . 717 . . 718 . . 719 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 720 | Label | TC |S| TTL | 721 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 723 Figure 7: Incoming Label Stack Sub-TLV 725 8.1.2. Incoming Interface Index Sub-TLV 727 The Incoming Interface Index object is a Sub-TLV that MAY be included 728 in a Detailed Interface and Label Stack TLV. The Incoming Interface 729 Index Sub-TLV describes the index assigned by this LSR to the 730 interface which received the MPLS echo request message. 732 Incoming Interface Index Sub-TLV Type is 2. Length is 8, and the 733 Value field has the same format as the Interface Index Sub-TLV 734 described in Section 7, and has following format: 736 0 1 2 3 737 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 738 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 739 | Type | Length | 740 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 741 | Interface Index Flags | Must Be Zero | 742 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 743 | Interface Index | 744 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 746 Figure 8: Incoming Interface Index Sub-TLV 748 Interface Index Flags 750 Interface Index Flags field is a bit vector with following format. 752 0 1 753 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 754 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 755 | Must Be Zero (Reserved) |M| 756 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 758 One flag is defined: M. The remaining flags MUST be set to zero 759 when sent and ignored on receipt. 761 Flag Name and Meaning 762 ---- ---------------- 764 M LAG Member Link Indicator 766 When this flag is set, the interface index described in 767 this sub-TLV is a member of a LAG. 769 Interface Index 771 Index assigned by the LSR to this interface. 773 9. Security Considerations 775 This document extends LSP Traceroute mechanism to discover and 776 exercise L2 ECMP paths. As result of supporting the code points and 777 procedures described in this document, additional processing are 778 required by initiator LSRs and responder LSRs, especially to compute 779 and handle increasing number of multipath information. Due to 780 additional processing, it is critical that proper security measures 781 described in [RFC4379] and [RFC6424] are followed. 783 The LSP Traceroute allows an initiator LSR to discover the paths of 784 tested LSPs, providing deep knowledge of the MPLS network. Exposing 785 such information to a malicious user is considered dangerous. To 786 prevent leakage of vital information to untrusted users, a responder 787 LSR MUST only accept MPLS echo request messages from trusted sources 788 via filtering source IP address field of received MPLS echo request 789 messages. 791 10. IANA Considerations 793 10.1. LAG Interface Info TLV 795 The IANA is requested to assign new value TBD1 for LAG Interface Info 796 TLV from the "Multiprotocol Label Switching Architecture (MPLS) Label 797 Switched Paths (LSPs) Ping Parameters - TLVs" registry. 799 Value Meaning Reference 800 ----- ------- --------- 801 TBD1 LAG Interface Info TLV this document 803 10.1.1. LAG Interface Info Flags 805 The IANA is requested to create and maintain a registry entitled "LAG 806 Interface Info Flags" with following registration procedures: 808 Registry Name: LAG Interface Info Flags 810 Bit number Name Reference 811 ---------- ---------------------------------------- --------- 812 15 D: Downstream LAG Info Accommodation this document 813 14 U: Upstream LAG Info Accommodation this document 814 0-13 Unassigned 816 Assignments of LAG Interface Info Flags are via Standards Action 817 [RFC5226]. 819 10.2. Interface Index Sub-TLV 821 The IANA is requested to assign new value TBD2 for Interface Index 822 Sub-TLV from the "Multiprotocol Label Switching Architecture (MPLS) 823 Label Switched Paths (LSPs) Ping Parameters - TLVs" registry, "Sub- 824 TLVs for TLV Types 20" sub-registry. 826 Value Meaning Reference 827 ----- ------- --------- 828 TBD2 Interface Index Sub-TLV this document 830 10.2.1. Interface Index Flags 832 The IANA is requested to create and maintain a registry entitled 833 "Interface Index Flags" with following registration procedures: 835 Registry Name: Interface Index Flags 837 Bit number Name Reference 838 ---------- ---------------------------------------- --------- 839 15 M: LAG Member Link Indicator this document 840 0-14 Unassigned 842 Assignments of Interface Index Flags are via Standards Action 843 [RFC5226]. 845 Note that this registry is used by the Interface Index Flags field of 846 the Interface Index Sub-TLV which may be present in the "Downstream 847 Detailed Mapping" TLV and the Incoming Interface Index Sub-TLV which 848 may be present in the "Detailed Interface and Label Stack" TLV. 850 10.3. Detailed Interface and Label Stack TLV 852 The IANA is requested to assign new value TBD3 for Detailed Interface 853 and Label Stack TLV from the "Multiprotocol Label Switching 854 Architecture (MPLS) Label Switched Paths (LSPs) Ping Parameters - 855 TLVs" registry ([IANA-MPLS-LSP-PING]). 857 Value Meaning Reference 858 ----- ------- --------- 859 TBD3 Detailed Interface and Label Stack TLV this document 861 10.3.1. Sub-TLVs for TLV Type TBD3 863 The IANA is requested to create and maintain a sub-registry entitled 864 "Sub-TLVs for TLV Type TBD3" under "Multiprotocol Label Switching 865 Architecture (MPLS) Label Switched Paths (LSPs) Ping Parameters - 866 TLVs" registry. 868 Initial values for this sub-registry, "Sub-TLVs for TLV Types TBD3", 869 are described below. 871 Sub-Type Name Reference 872 --------- ---------------------------------------- --------- 873 1 Incoming Label Stack this document 874 2 Incoming Interface Index this document 875 4-65535 Unassigned 877 Assignments of Sub-Types are via Standards Action [RFC5226]. 879 10.4. DS Flags 881 The IANA is requested to assign a new bit number from the "DS flags" 882 sub-registry from the "Multi-Protocol Label Switching (MPLS) Label 883 Switched Paths (LSPs) Ping Parameters - TLVs" registry 884 ([IANA-MPLS-LSP-PING]). 886 Note: the "DS flags" sub-registry is created by 887 [I-D.ietf-mpls-lsp-ping-registry]. 889 Bit number Name Reference 890 ---------- ---------------------------------------- --------- 891 TBD4 G: LAG Description Indicator this document 893 11. Acknowledgements 895 Authors would like to thank Nagendra Kumar and Sam Aldrin for 896 providing useful comments and suggestions. Authors would like to 897 thank Loa Andersson for performing a detailed review and providing 898 number of comments. 900 12. References 902 12.1. Normative References 904 [I-D.ietf-mpls-lsp-ping-registry] 905 Decraene, B., Akiya, N., Pignataro, C., Andersson, L., and 906 S. Aldrin, "IANA registries for LSP ping Code Points", 907 draft-ietf-mpls-lsp-ping-registry-00 (work in progress), 908 November 2014. 910 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 911 Requirement Levels", BCP 14, RFC 2119, March 1997. 913 [RFC4379] Kompella, K. and G. Swallow, "Detecting Multi-Protocol 914 Label Switched (MPLS) Data Plane Failures", RFC 4379, 915 February 2006. 917 [RFC6424] Bahadur, N., Kompella, K., and G. Swallow, "Mechanism for 918 Performing Label Switched Path Ping (LSP Ping) over MPLS 919 Tunnels", RFC 6424, November 2011. 921 12.2. Informative References 923 [I-D.ietf-mpls-ipv6-only-gap] 924 George, W. and C. Pignataro, "Gap Analysis for Operating 925 IPv6-only MPLS Networks", draft-ietf-mpls-ipv6-only-gap-04 926 (work in progress), November 2014. 928 [IANA-MPLS-LSP-PING] 929 IANA, "Multi-Protocol Label Switching (MPLS) Label 930 Switched Paths (LSPs) Ping Parameters", 931 . 934 [IEEE802.1AX] 935 IEEE Std. 802.1AX, "IEEE Standard for Local and 936 metropolitan area networks - Link Aggregation", November 937 2008. 939 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 940 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 941 May 2008. 943 Appendix A. LAG with L2 Switch Issues 945 Several flavors of "LAG with L2 switch" provisioning models are 946 described in this section, with MPLS data plane ECMP traversal 947 validation issues with each. 949 A.1. Equal Numbers of LAG Members 951 R1 ==== S1 ==== R2 953 The issue with this LAG provisioning model is that packets traversing 954 a LAG member from R1 to S1 can get load balanced by S1 towards R2. 955 Therefore, MPLS echo request messages traversing specific LAG member 956 from R1 to S1 can actually reach R2 via any LAG members, and sender 957 of MPLS echo request messages have no knowledge of this nor no way to 958 control this traversal. In the worst case, MPLS echo request 959 messages with specific entropies to exercise every LAG members from 960 R1 to S1 can all reach R2 via same LAG member. Thus it is impossible 961 for MPLS echo request sender to verify that packets intended to 962 traverse specific LAG member from R1 to S1 did actually traverse that 963 LAG member, and to deterministically exercise "receive" processing of 964 every LAG member on R2. 966 A.2. Deviating Numbers of LAG Members 968 ____ 969 R1 ==== S1 ==== R2 971 There are deviating number of LAG members on the two sides of the L2 972 switch. The issue with this LAG provisioning model is the same as 973 previous model, sender of MPLS echo request messages have no 974 knowledge of L2 load balance algorithm nor entropy values to control 975 the traversal. 977 A.3. LAG Only on Right 979 R1 ---- S1 ==== R2 981 The issue with this LAG provisioning model is that there is no way 982 for MPLS echo request sender to deterministically exercise both LAG 983 members from S1 to R2. And without such, "receive" processing of R2 984 on each LAG member cannot be verified. 986 A.4. LAG Only on Left 988 R1 ==== S1 ---- R2 990 MPLS echo request sender has knowledge of how to traverse both LAG 991 members from R1 to S1. However, both types of packets will terminate 992 on the non-LAG interface at R2. It becomes impossible for MPLS echo 993 request sender to know that MPLS echo request messages intended to 994 traverse a specific LAG member from R1 to S1 did indeed traverse that 995 LAG member. 997 Authors' Addresses 999 Nobo Akiya 1000 Cisco Systems 1002 Email: nobo@cisco.com 1004 George Swallow 1005 Cisco Systems 1007 Email: swallow@cisco.com 1009 Stephane Litkowski 1010 Orange 1012 Email: stephane.litkowski@orange.com 1014 Bruno Decraene 1015 Orange 1017 Email: bruno.decraene@orange.com 1019 John E. Drake 1020 Juniper Networks 1022 Email: jdrake@juniper.net