idnits 2.17.1 draft-akiya-mpls-lsp-ping-lag-multipath-03.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 22, 2014) is 3442 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) == Outdated reference: A later version (-04) exists of draft-ietf-mpls-ipv6-only-gap-03 -- Obsolete informational reference (is this intentional?): RFC 5226 (Obsoleted by RFC 8126) Summary: 2 errors (**), 0 flaws (~~), 3 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: May 26, 2015 B. Decraene 7 Orange 8 J. Drake 9 Juniper Networks 10 November 22, 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-03 16 Abstract 18 This document defines an extension to the Multiprotocol Label 19 Switching (MPLS) Label Switched Path (LSP) Ping and Traceroute to 20 describe Multipath Information for Link Aggregation (LAG) member 21 links separately, thus allowing MPLS LSP Ping and Traceroute to 22 discover and exercise specific paths of layer 2 (L2) Equal-Cost 23 Multipath (ECMP) over LAG interfaces. 25 This document updates RFC4379 and RFC6424. 27 Requirements Language 29 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 30 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 31 document are to be interpreted as described in RFC 2119 [RFC2119]. 33 Status of This Memo 35 This Internet-Draft is submitted in full conformance with the 36 provisions of BCP 78 and BCP 79. 38 Internet-Drafts are working documents of the Internet Engineering 39 Task Force (IETF). Note that other groups may also distribute 40 working documents as Internet-Drafts. The list of current Internet- 41 Drafts is at http://datatracker.ietf.org/drafts/current/. 43 Internet-Drafts are draft documents valid for a maximum of six months 44 and may be updated, replaced, or obsoleted by other documents at any 45 time. It is inappropriate to use Internet-Drafts as reference 46 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on May 26, 2015. 50 Copyright Notice 52 Copyright (c) 2014 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (http://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the Simplified BSD License. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 68 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 69 1.2. Background . . . . . . . . . . . . . . . . . . . . . . . 3 70 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 4 71 3. Mechanism to Discover L2 ECMP Multipath . . . . . . . . . . . 5 72 4. Mechanism to Validate L2 ECMP Traversal . . . . . . . . . . . 7 73 5. LAG Interface Info TLV . . . . . . . . . . . . . . . . . . . 9 74 6. DDMAP TLV DS Flags: G . . . . . . . . . . . . . . . . . . . . 11 75 7. Interface Index Sub-TLV . . . . . . . . . . . . . . . . . . . 11 76 8. Detailed Interface and Label Stack TLV . . . . . . . . . . . 12 77 8.1. Sub-TLVs . . . . . . . . . . . . . . . . . . . . . . . . 14 78 8.1.1. Incoming Label Stack Sub-TLV . . . . . . . . . . . . 14 79 8.1.2. Incoming Interface Index Sub-TLV . . . . . . . . . . 15 80 9. Security Considerations . . . . . . . . . . . . . . . . . . . 16 81 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 82 10.1. LAG Interface Info TLV . . . . . . . . . . . . . . . . . 16 83 10.2. Interface Index Sub-TLV . . . . . . . . . . . . . . . . 16 84 10.3. Detailed Interface and Label Stack TLV . . . . . . . . . 17 85 10.4. DS Flags . . . . . . . . . . . . . . . . . . . . . . . . 17 86 10.5. New Sub-Registry . . . . . . . . . . . . . . . . . . . . 17 87 10.5.1. Sub-TLVs for TLV Type TBD3 . . . . . . . . . . . . . 17 88 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 18 89 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 90 12.1. Normative References . . . . . . . . . . . . . . . . . . 18 91 12.2. Informative References . . . . . . . . . . . . . . . . . 18 92 Appendix A. LAG with L2 Switch Issues . . . . . . . . . . . . . 19 93 A.1. Equal Numbers of LAG Members . . . . . . . . . . . . . . 19 94 A.2. Deviating Numbers of LAG Members . . . . . . . . . . . . 19 95 A.3. LAG Only on Right . . . . . . . . . . . . . . . . . . . . 19 96 A.4. LAG Only on Left . . . . . . . . . . . . . . . . . . . . 19 97 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20 99 1. Introduction 101 1.1. Terminology 103 The following acronyms/terminologies are used in this document: 105 o MPLS - Multiprotocol Label Switching. 107 o LSP - Label Switched Path. 109 o LSR - Label Switching Router. 111 o ECMP - Equal-Cost Multipath. 113 o LAG - Link Aggregation. 115 o Initiating LSR - LSR which sends MPLS echo request. 117 o Responder LSR - LSR which receives MPLS echo request and sends 118 MPLS echo reply. 120 1.2. Background 122 The Multiprotocol Label Switching (MPLS) Label Switched Path (LSP) 123 Ping and Traceroute [RFC4379] are powerful tools designed to diagnose 124 all available layer 3 (L3) paths of LSPs, i.e. provides diagnostic 125 coverage of L3 Equal-Cost Multipath (ECMP). In many MPLS networks, 126 Link Aggregation (LAG) as defined in [IEEE802.1AX], which provide 127 layer 2 (L2) ECMP, are often used for various reasons. MPLS LSP Ping 128 and Traceroute tools were not designed to discover and exercise 129 specific paths of L2 ECMP. Result raises a limitation for following 130 scenario when LSP X traverses over LAG Y: 132 o MPLS switching of LSP X over one or more member links of LAG Y is 133 succeeding. 135 o MPLS switching of LSP X over one or more member links of LAG Y is 136 failing. 138 o MPLS echo request for LSP X over LAG Y is load balanced over a 139 member link which is MPLS switching successfully. 141 With above scenario, MPLS LSP Ping and Traceroute will not be able to 142 detect the MPLS switching failure of problematic member link(s) of 143 the LAG. In other words, lack of L2 ECMP discovery and exercise 144 capability can produce an outcome where MPLS LSP Ping and Traceroute 145 can be blind to MPLS switching failures over LAG interface that are 146 impacting MPLS traffic. It is, thus, desirable to extend the MPLS 147 LSP Ping and Traceroute to have deterministic diagnostic coverage of 148 LAG interfaces. 150 2. Overview 152 This document defines an extension to the MPLS LSP Ping and 153 Traceroute to describe Multipath Information for LAG member links 154 separately, thus allowing MPLS LSP Ping and Traceroute to discover 155 and exercise specific paths of L2 ECMP over LAG interfaces. Reader 156 is expected to be familiar with mechanics of the MPLS LSP Ping and 157 Traceroute described in Section 3.3 of [RFC4379] and Downstream 158 Detailed Mapping TLV (DDMAP) described in Section 3.3 of [RFC6424]. 160 MPLS echo request carries a DDMAP and an optional TLV to indicate 161 that separate load balancing information for each L2 nexthop over LAG 162 is desired in MPLS echo reply. Responder LSR places the same 163 optional TLV in the MPLS echo reply to provide acknowledgement back 164 to the initiator. It also adds, for each downstream LAG member, a 165 load balance information (i.e. multipath information and interface 166 index). For example: 168 <----- LDP Network -----> 170 +-------+ 171 | | 172 A-------B=======C-------E 173 | | 174 +-------D-------+ 176 ---- Non-LAG 177 ==== LAG comprising of two member links 179 Figure 1: Example LDP Network 181 When node A is initiating LSP Traceroute to node E, node B will 182 return to node A load balance information for following entries. 184 1. Downstream C over Non-LAG (upper path). 186 2. First Downstream C over LAG (middle path). 188 3. Second Downstream C over LAG (middle path). 190 4. Downstream D over Non-LAG (lower path). 192 This document defines: 194 o In Section 3, a mechanism to discover L2 ECMP multipath 195 information; 197 o In Section 4, a mechanism to validate L2 ECMP traversal in some 198 LAG provisioning models; 200 o In Section 5, the LAG Interface Info TLV; 202 o In Section 6, the LAG Description Indicator flag; 204 o In Section 7, the Interface Index Sub-TLV; 206 o In Section 8, the Detailed Interface and Label Stack TLV; 208 o In Appendix A, issues with LAG having an L2 Switch. 210 Note that the mechanism described in this document does not impose 211 any changes to scenarios where an LSP is pinned down to a particular 212 LAG member (i.e. the LAG is not treated as one logical interface by 213 the LSP). 215 3. Mechanism to Discover L2 ECMP Multipath 217 The MPLS echo request carries a DDMAP and the LAG Interface Info TLV 218 (described in Section 5) to indicate that separate load balancing 219 information for each L2 nexthop over LAG is desired in MPLS echo 220 reply. Responder LSRs that understand the LAG Interface Info TLV but 221 unable to describe outgoing LAG member links separately MUST add the 222 LAG Interface Info TLV in the MPLS echo reply to provide 223 acknowledgement back to the initiating LSR. The Downstream LAG Info 224 Accommodation flag MUST NOT be set in LAG Interface Info Flags. The 225 responder LSRs that understands the LAG Interface Info TLV and able 226 to describe outgoing LAG member links separately MUST use the follow 227 procedures, regardless of whether or not outgoing interfaces include 228 LAG interfaces: 230 o MUST add the LAG Interface Info TLV in the MPLS echo reply to 231 provide acknowledgement back to the initiator. The Downstream LAG 232 Info Accommodation flag MUST be set in the LAG Interface Info 233 Flags field. 235 o For each downstream that is a LAG interface: 237 * MUST add DDMAP in the MPLS echo reply. 239 * MUST set the LAG Description Indicator flag in the DS Flags 240 field (described in Section 6) of the DDMAP. 242 * In the DDMAP, Interface Index Sub-TLV and Multipath Data Sub- 243 TLV are to describe each LAG member link. All other fields of 244 the DDMAP are to describe the LAG interface. 246 * For each LAG member link of this LAG interface: 248 + MUST add an Interface Index Sub-TLV (described in Section 7) 249 with the LAG Member Link Indicator flag set in the Interface 250 Index Flags field, describing this LAG member link. 252 + MUST add an Multipath Data Sub-TLV for this LAG member link, 253 if received DDMAP requested multipath information. 255 When both the Interface Index Sub-TLV and the Multipath Data Sub-TLV 256 is placed in the DDMAP to describe a LAG member link, Interface Index 257 Sub-TLV MUST be added first with Multipath Data Sub-TLV immediately 258 following. 260 For example, a responder LSR possessing a LAG interface with two 261 member links would send the following DDMAP for this LAG interface: 263 0 1 2 3 264 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 265 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 266 | DDMAP fields describing LAG interface with DS Flags G set | 267 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 268 | Interface Index Sub-TLV of LAG member link #1 | 269 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 270 | Multipath Data Sub-TLV LAG member link #1 | 271 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 272 | Interface Index Sub-TLV of LAG member link #2 | 273 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 274 | Multipath Data Sub-TLV LAG member link #2 | 275 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 276 | Label Stack Sub-TLV | 277 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 279 Figure 2: Example of DDMAP in MPLS Echo Reply 281 These procedures allow initiating LSR to: 283 o Mandate the responder LSR to always add the LAG Interface Info TLV 284 in the MPLS echo reply. This allows the initiating LSR to 285 identify whether or not the responder LSR understands the LAG 286 Interface Info TLV and can describe outgoing LAG member links 287 separately. 289 o Utilize the value of the LAG Description Indicator flag in DS 290 Flags to identify whether each DDMAP describes a LAG interface or 291 a non-LAG interface. 293 o Obtain multipath information which is expected to traverse the 294 specific LAG member link described by corresponding interface 295 index. 297 When an initiating LSR receives a DDMAP containing LAG member 298 information from a downstream LSR with TTL=n, then the subsequent 299 DDMAP sent by the initiating LSR to the downstream LSR with TTL=n+1 300 through a particular LAG member link MUST be updated with following 301 procedures: 303 o The Interface Index Sub-TLVs MUST NOT be present in the sending 304 DDMAP. 306 o The Multipath Data Sub-TLVs SHOULD be updated to include just the 307 one corresponding to the LAG member link being traversed. The 308 initiating LSR MAY combine the Multipath Data Sub-TLVs for all LAG 309 member links into a single Multipath Data Sub-TLV, but there MUST 310 be only one Multipath Data Sub-TLV in the sending DDMAP. 312 o All other fields of the DDMAP are to comply with procedures 313 described in [RFC6424]. 315 Using the DDMAP example described in the Figure 2, the DDMAP being 316 sent by the initiating LSR through LAG member link #1 to the next 317 downstream LSR should be: 319 0 1 2 3 320 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 321 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 322 | DDMAP fields describing LAG interface with DS Flags G set | 323 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 324 | Multipath Data Sub-TLV LAG member link #1 | 325 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 326 | Label Stack Sub-TLV | 327 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 329 Figure 3: Example of DDMAP in MPLS Echo Request 331 4. Mechanism to Validate L2 ECMP Traversal 333 This document does not update the FEC validation procedures nor the 334 DDMAP validation procedures. Rather this document provides the 335 mechanism for the initiating LSR to obtain additional information 336 from the downstream LSRs when incoming and/or outgoing interfaces are 337 LAGs. With this additional information, it is the responsibility of 338 the initiating LSR to validate the L2 ECMP traversal. 340 The MPLS echo request is sent with a DDMAP with DS Flags I set and 341 the optional LAG Interface Info TLV to indicate the request for 342 Detailed Interface and Label Stack TLV with additional LAG member 343 link information (i.e. interface index) in the MPLS echo reply. 344 Responder LSRs that understands the LAG Interface Info TLV but unable 345 to describe incoming LAG member link MUST add the LAG Interface Info 346 TLV in the MPLS echo reply to provide acknowledgement back to the 347 initiator. The Upstream LAG Info Accommodation flag MUST NOT be set 348 in LAG Interface Info Flags. The responder LSRs that understands the 349 LAG Interface Info TLV and able to describe incoming LAG member link 350 MUST use the following procedures, regardless of whether or not 351 incoming interface was a LAG interface: 353 o Add the LAG Interface Info TLV in the MPLS echo reply to provide 354 acknowledgement back to the initiator. The Upstream LAG Info 355 Accommodation flag MUST be set in the LAG Interface Info Flags 356 field. 358 o When the received DDMAP had DS Flags I set, add the Detailed 359 Interface and Label Stack TLV (described in Section 8) in the MPLS 360 echo reply. 362 o When the received DDMAP had DS Flags I set and incoming interface 363 was a LAG, add the Incoming Interface Index Sub-TLV (described in 364 Section 8.1.2). The LAG Member Link Indicator flag MUST be set in 365 the Interface Index Flags field, and the Interface Index field set 366 to the LAG member link which received the MPLS echo request. 368 These procedures allow initiating LSR to: 370 o Identify whether or not the responder LSR understands the LAG 371 Interface Info TLV and can describe the incoming LAG member links 372 (the responder LSR is mandated to always add the LAG Interface 373 Info TLV in the MPLS echo reply). 375 Along with procedures described in Section 3, described procedures in 376 this section will allow an initiating LSR to know: 378 o The expected load balance information of every LAG member link, at 379 LSR with TTL=n. 381 o With specific entropy, the expected interface index of the 382 outgoing LAG member link at TTL=n. 384 o With specific entropy, the interface index of the incoming LAG 385 member link at TTL=n+1. 387 Expectation is that there's a relationship between the interface 388 index of the outgoing LAG member link at TTL=n and the interface 389 index of the incoming LAG member link at TTL=n+1 for all discovered 390 entropies. In other words, set of entropies that load balances to 391 outgoing LAG member link X at TTL=n should all reach the nexthop on 392 same incoming LAG member link Y at TTL=n+1. 394 With additional logics added in the initiating LSR, following checks 395 can be performed: 397 o Success case: 399 * Traversing LAG member=1 at TTL=n results in LAG member=1' as 400 the incoming interface at TTL=n+1. 402 * Traversing LAG member=2 at TTL=n results in LAG member=2' as 403 the incoming interface at TTL=n+1. 405 o Error case: 407 * Traversing LAG member=1 at TTL=n results in LAG member=1' as 408 the incoming interface at TTL=n+1. 410 * Traversing LAG member=2 at TTL=n results in LAG member=1' as 411 the incoming interface at TTL=n+1. 413 Note that defined procedures will provide a deterministic result for 414 LAG interfaces that are back-to-back connected between routers (i.e. 415 no L2 switch in between). If there is a L2 switch between LSR at 416 TTL=n and LSR at TTL=n+1, there is no guarantee that traversal of 417 every LAG member link at TTL=n will result in reaching different 418 interface index at TTL=n+1. Issues resulting from LAG with L2 switch 419 in between are further described in Appendix A. LAG provisioning 420 models in operated network should be considered when analyzing the 421 output of LSP Traceroute exercising L2 ECMPs. 423 5. LAG Interface Info TLV 425 The LAG Interface Info object is a new TLV that MAY be included in 426 the MPLS echo request message. An MPLS echo request MUST NOT include 427 more than one LAG Interface Info object. Presence of LAG Interface 428 Info object is a request that responder LSR describes upstream and 429 downstream LAG interfaces according to procedures defined in this 430 document. If the responder LSR is able to accommodate this request, 431 then the LAG Interface Info object MUST be included in the MPLS echo 432 reply message. 434 LAG Interface Info TLV Type is TBD1. Length is 4. The Value field 435 of LAG Interface TLV has following format: 437 0 1 2 3 438 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 439 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 440 | LAG Interface Info Flags | Must Be Zero | 441 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 443 Figure 4: LAG Interface Info TLV 445 LAG Interface Info Flags 447 LAG Interface Info Flags field is a bit vector with following 448 format. 450 0 1 451 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 452 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 453 | Must Be Zero (Reserved) |U|D| 454 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 456 Two flags are defined: U and D. The remaining flags MUST be set 457 to zero when sending and ignored on receipt. Both U and D flags 458 MUST be cleared in MPLS echo request message when sending, and 459 ignored on receipt. Either or both U and D flags MAY be set in 460 MPLS echo reply message. 462 Flag Name and Meaning 463 ---- ---------------- 465 U Upstream LAG Info Accommodation 467 When this flag is set, LSR is capable of placing Incoming 468 Interface Index Sub-TLV, describing LAG member link, in 469 the Detailed Interface and Label Stack TLV. 471 D Downstream LAG Info Accommodation 473 When this flag is set, LSR is capable of placing Interface 474 Index Sub-TLV and Multipath Data Sub-TLV, describing LAG 475 member link, in the Downstream Detailed Mapping TLV. 477 6. DDMAP TLV DS Flags: G 479 One flag, G, is added in DS Flags field of the DDMAP TLV. In the 480 MPLS echo request message, G flag MUST be cleared when sending, and 481 ignored on receipt. In the MPLS echo reply message, G flag MUST be 482 set if the DDMAP TLV describes a LAG interface. It MUST be cleared 483 otherwise. 485 DS Flags 487 DS Flags G is added, in Bit Number TBD4, in DS Flags bit vector. 489 0 1 2 3 4 5 6 7 490 +-+-+-+-+-+-+-+-+ 491 | MBZ |G|MBZ|I|N| 492 +-+-+-+-+-+-+-+-+ 494 RFC-Editor-Note: Please update above figure to place the flag G in 495 the bit number TBD4. 497 Flag Name and Meaning 498 ---- ---------------- 500 G LAG Description Indicator 502 When this flag is set, DDMAP describes a LAG interface. 504 7. Interface Index Sub-TLV 506 The Interface Index object is a Sub-TLV that MAY be included in a 507 DDMAP TLV. Zero or more Interface Index object MAY appear in a DDMAP 508 TLV. The Interface Index Sub-TLV describes the index assigned by 509 local LSR to the egress interface. 511 Interface Index Sub-TLV Type is TBD2. Length is 8, and the Value 512 field has following format: 514 0 1 2 3 515 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 516 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 517 | Interface Index Flags | Must Be Zero | 518 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 519 | Interface Index | 520 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 522 Figure 5: Interface Index Sub-TLV 524 Interface Index Flags 525 Interface Index Flags field is a bit vector with following format. 527 0 1 528 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 529 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 530 | Must Be Zero (Reserved) |M| 531 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 533 One flag is defined: M. The remaining flags MUST be set to zero 534 when sending and ignored on receipt. 536 Flag Name and Meaning 537 ---- ---------------- 539 M LAG Member Link Indicator 541 When this flag is set, interface index described in 542 this sub-TLV is member of a LAG. 544 Interface Index 546 Index assigned by the LSR to this interface. 548 8. Detailed Interface and Label Stack TLV 550 The Detailed Interface and Label Stack object is a TLV that MAY be 551 included in a MPLS echo reply message to report the interface on 552 which the MPLS echo request message was received and the label stack 553 that was on the packet when it was received. A responder LSR MUST 554 NOT insert more than one instance of this TLV. This TLV allows the 555 initiating LSR to obtain the exact interface and label stack 556 information as it appears at the responder LSR. 558 Detailed Interface and Label Stack TLV Type is TBD3. Length is K + 559 Sub-TLV Length, and the Value field has following format: 561 0 1 2 3 562 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 563 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 564 | Address Type | Must Be Zero | 565 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 566 | IP Address (4 or 16 octets) | 567 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 568 | Interface (4 or 16 octets) | 569 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 570 | Must Be Zero | Sub-TLV Length | 571 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 572 . . 573 . List of Sub-TLVs . 574 . . 575 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 577 Figure 6: Detailed Interface and Label Stack TLV 579 The Detailed Interface and Label Stack TLV format is derived from the 580 Interface and Label Stack TLV format (from [RFC4379]). Two changes 581 are introduced. First is that label stack, which is of variable 582 length, is converted into a sub-TLV. Second is that a new sub-TLV is 583 added to describe an interface index. The fields of Detailed 584 Interface and Label Stack TLV have the same use and meaning as in 585 [RFC4379]. A summary of the fields taken from the Interface and 586 Label Stack TLV is as below: 588 Address Type 590 The Address Type indicates if the interface is numbered or 591 unnumbered. It also determines the length of the IP Address 592 and Interface fields. The resulting total for the initial part 593 of the TLV is listed in the table below as "K Octets". The 594 Address Type is set to one of the following values: 596 Type # Address Type K Octets 597 ------ ------------ -------- 598 1 IPv4 Numbered 16 599 2 IPv4 Unnumbered 16 600 3 IPv6 Numbered 40 601 4 IPv6 Unnumbered 28 603 IP Address and Interface 605 IPv4 addresses and interface indices are encoded in 4 octets; 606 IPv6 addresses are encoded in 16 octets. 608 If the interface upon which the echo request message was 609 received is numbered, then the Address Type MUST be set to IPv4 610 Numbered or IPv6 Numbered, the IP Address MUST be set to either 611 the LSR's Router ID or the interface address, and the Interface 612 MUST be set to the interface address. 614 If the interface is unnumbered, the Address Type MUST be either 615 IPv4 Unnumbered or IPv6 Unnumbered, the IP Address MUST be the 616 LSR's Router ID, and the Interface MUST be set to the index 617 assigned to the interface. 619 Note: Usage of IPv6 Unnumbered has the same issue as [RFC4379], 620 described in Section 3.4.2 of [I-D.ietf-mpls-ipv6-only-gap]. A 621 solution should be considered an applied to both [RFC4379] and 622 this document. 624 Sub-TLV Length 626 Total length in octets of the sub-TLVs associated with this 627 TLV. 629 8.1. Sub-TLVs 631 This section defines the sub-TLVs that MAY be included as part of the 632 Detailed Interface and Label Stack TLV. 634 Sub-Type Value Field 635 --------- ------------ 636 1 Incoming Label stack 637 2 Incoming Interface Index 639 8.1.1. Incoming Label Stack Sub-TLV 641 The Incoming Label Stack sub-TLV contains the label stack as received 642 by the LSR. If any TTL values have been changed by this LSR, they 643 SHOULD be restored. 645 Incoming Label Stack Sub-TLV Type is 1. Length is variable, and the 646 Value field has following format: 648 0 1 2 3 649 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 650 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 651 | Label | TC |S| TTL | 652 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 653 . . 654 . . 655 . . 656 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 657 | Label | TC |S| TTL | 658 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 660 Figure 7: Incoming Label Stack Sub-TLV 662 8.1.2. Incoming Interface Index Sub-TLV 664 The Incoming Interface Index object is a Sub-TLV that MAY be included 665 in a Detailed Interface and Label Stack TLV. The Incoming Interface 666 Index Sub-TLV describes the index assigned by this LSR to the 667 interface which received the MPLS echo request message. 669 Incoming Interface Index Sub-TLV Type is 2. Length is 8, and the 670 Value field has following format: 672 0 1 2 3 673 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 674 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 675 | Interface Index Flags | Must Be Zero | 676 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 677 | Interface Index | 678 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 680 Figure 8: Incoming Interface Index Sub-TLV 682 Interface Index Flags 684 Interface Index Flags field is a bit vector with following format. 686 0 1 687 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 688 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 689 | Must Be Zero (Reserved) |M| 690 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 692 One flag is defined: M. The remaining flags MUST be set to zero 693 when sent and ignored on receipt. 695 Flag Name and Meaning 696 ---- ---------------- 698 M LAG Member Link Indicator 700 When this flag is set, the interface index described in 701 this sub-TLV is a member of a LAG. 703 Interface Index 705 Index assigned by the LSR to this interface. 707 9. Security Considerations 709 This document extends LSP Traceroute mechanism to discover and 710 exercise L2 ECMP paths. Additional processing are required for 711 initiating LSR and responder LSR, especially to compute and handle 712 increasing number of multipath information. Due to additional 713 processing, it is critical that proper security measures described in 714 [RFC4379] and [RFC6424] are followed. 716 10. IANA Considerations 718 10.1. LAG Interface Info TLV 720 The IANA is requested to assign new value TBD1 for LAG Interface Info 721 TLV from the "Multiprotocol Label Switching Architecture (MPLS) Label 722 Switched Paths (LSPs) Ping Parameters - TLVs" registry. 724 Value Meaning Reference 725 ----- ------- --------- 726 TBD1 LAG Interface Info TLV this document 728 10.2. Interface Index Sub-TLV 730 The IANA is requested to assign new value TBD2 for Interface Index 731 Sub-TLV from the "Multiprotocol Label Switching Architecture (MPLS) 732 Label Switched Paths (LSPs) Ping Parameters - TLVs" registry, "Sub- 733 TLVs for TLV Types 20" sub-registry. 735 Value Meaning Reference 736 ----- ------- --------- 737 TBD2 Interface Index Sub-TLV this document 739 10.3. Detailed Interface and Label Stack TLV 741 The IANA is requested to assign new value TBD3 for Detailed Interface 742 and Label Stack TLV from the "Multiprotocol Label Switching 743 Architecture (MPLS) Label Switched Paths (LSPs) Ping Parameters - 744 TLVs" registry ([IANA-MPLS-LSP-PING]). 746 Value Meaning Reference 747 ----- ------- --------- 748 TBD3 Detailed Interface and Label Stack TLV this document 750 10.4. DS Flags 752 The IANA is requested to assign a new bit number from the "DS flags" 753 sub-registry from the "Multi-Protocol Label Switching (MPLS) Label 754 Switched Paths (LSPs) Ping Parameters - TLVs" registry 755 ([IANA-MPLS-LSP-PING]). 757 Note: the "DS flags" sub-registry is created by 758 [I-D.ietf-mpls-lsp-ping-registry]. 760 Bit number Name Reference 761 ---------- ---------------------------------------- --------- 762 TBD4 G: LAG Description Indicator this document 764 10.5. New Sub-Registry 766 10.5.1. Sub-TLVs for TLV Type TBD3 768 The IANA is requested to make a new "Sub-TLVs for TLV Type TBD3" sub- 769 registry under "Multiprotocol Label Switching Architecture (MPLS) 770 Label Switched Paths (LSPs) Ping Parameters - TLVs" registry. 772 Initial values for this sub-registry, "Sub-TLVs for TLV Types TBD3", 773 are described below. 775 Sub-Type Name Reference 776 --------- ---------------------------------------- --------- 777 1 Incoming Label Stack this document 778 2 Incoming Interface Index this document 779 4-65535 Unassigned 781 Assignments of Sub-Types are via Standards Action [RFC5226]. 783 11. Acknowledgements 785 Authors would like to thank Nagendra Kumar and Sam Aldrin for 786 providing useful comments and suggestions. 788 12. References 790 12.1. Normative References 792 [I-D.ietf-mpls-lsp-ping-registry] 793 Decraene, B., Akiya, N., Pignataro, C., Andersson, L., and 794 S. Aldrin, "IANA registries for LSP ping Code Points", 795 draft-ietf-mpls-lsp-ping-registry-00 (work in progress), 796 November 2014. 798 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 799 Requirement Levels", BCP 14, RFC 2119, March 1997. 801 [RFC4379] Kompella, K. and G. Swallow, "Detecting Multi-Protocol 802 Label Switched (MPLS) Data Plane Failures", RFC 4379, 803 February 2006. 805 [RFC6424] Bahadur, N., Kompella, K., and G. Swallow, "Mechanism for 806 Performing Label Switched Path Ping (LSP Ping) over MPLS 807 Tunnels", RFC 6424, November 2011. 809 12.2. Informative References 811 [I-D.ietf-mpls-ipv6-only-gap] 812 George, W. and C. Pignataro, "Gap Analysis for Operating 813 IPv6-only MPLS Networks", draft-ietf-mpls-ipv6-only-gap-03 814 (work in progress), October 2014. 816 [IANA-MPLS-LSP-PING] 817 IANA, "Multi-Protocol Label Switching (MPLS) Label 818 Switched Paths (LSPs) Ping Parameters", 819 . 822 [IEEE802.1AX] 823 IEEE Std. 802.1AX, "IEEE Standard for Local and 824 metropolitan area networks - Link Aggregation", November 825 2008. 827 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 828 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 829 May 2008. 831 Appendix A. LAG with L2 Switch Issues 833 Several flavors of "LAG with L2 switch" provisioning models are 834 described in this section, with MPLS data plane ECMP traversal 835 validation issues with each. 837 A.1. Equal Numbers of LAG Members 839 R1 ==== S1 ==== R2 841 The issue with this LAG provisioning model is that packets traversing 842 a LAG member from R1 to S1 can get load balanced by S1 towards R2. 843 Therefore, MPLS echo request messages traversing specific LAG member 844 from R1 to S1 can actually reach R2 via any LAG members, and sender 845 of MPLS echo request messages have no knowledge of this nor no way to 846 control this traversal. In the worst case, MPLS echo request 847 messages with specific entropies to exercise every LAG members from 848 R1 to S1 can all reach R2 via same LAG member. Thus it is impossible 849 for MPLS echo request sender to verify that packets intended to 850 traverse specific LAG member from R1 to S1 did actually traverse that 851 LAG member, and to deterministically exercise "receive" processing of 852 every LAG member on R2. 854 A.2. Deviating Numbers of LAG Members 856 ____ 857 R1 ==== S1 ==== R2 859 There are deviating number of LAG members on the two sides of the L2 860 switch. The issue with this LAG provisioning model is the same as 861 previous model, sender of MPLS echo request messages have no 862 knowledge of L2 load balance algorithm nor entropy values to control 863 the traversal. 865 A.3. LAG Only on Right 867 R1 ---- S1 ==== R2 869 The issue with this LAG provisioning model is that there is no way 870 for MPLS echo request sender to deterministically exercise both LAG 871 members from S1 to R2. And without such, "receive" processing of R2 872 on each LAG member cannot be verified. 874 A.4. LAG Only on Left 876 R1 ==== S1 ---- R2 877 MPLS echo request sender has knowledge of how to traverse both LAG 878 members from R1 to S1. However, both types of packets will terminate 879 on the non-LAG interface at R2. It becomes impossible for MPLS echo 880 request sender to know that MPLS echo request messages intended to 881 traverse a specific LAG member from R1 to S1 did indeed traverse that 882 LAG member. 884 Authors' Addresses 886 Nobo Akiya 887 Cisco Systems 889 Email: nobo@cisco.com 891 George Swallow 892 Cisco Systems 894 Email: swallow@cisco.com 896 Stephane Litkowski 897 Orange 899 Email: stephane.litkowski@orange.com 901 Bruno Decraene 902 Orange 904 Email: bruno.decraene@orange.com 906 John E. Drake 907 Juniper Networks 909 Email: jdrake@juniper.net