idnits 2.17.1 draft-akiya-mpls-lsp-ping-lag-multipath-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC4379, updated by this document, for RFC5378 checks: 2002-03-27) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (August 12, 2014) is 3517 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 4379 (Obsoleted by RFC 8029) ** Obsolete normative reference: RFC 6424 (Obsoleted by RFC 8029) == Outdated reference: A later version (-04) exists of draft-akiya-mpls-entropy-lsp-ping-02 == Outdated reference: A later version (-04) exists of draft-ietf-mpls-ipv6-only-gap-01 -- 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: February 13, 2015 B. Decraene 7 Orange 8 J. Drake 9 Juniper Networks 10 August 12, 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-01 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 February 13, 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. New Sub-Registry . . . . . . . . . . . . . . . . . . . . 17 86 10.4.1. DS Flags . . . . . . . . . . . . . . . . . . . . . . 17 87 10.4.2. Sub-TLVs for TLV Type TBD3 . . . . . . . . . . . . . 18 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 . . . . . . . . . . . . 20 95 A.3. LAG Only on Right . . . . . . . . . . . . . . . . . . . . 20 96 A.4. LAG Only on Left . . . . . . . . . . . . . . . . . . . . 20 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 3, in DS Flags bit vector. 489 0 1 2 3 4 5 6 7 490 +-+-+-+-+-+-+-+-+ 491 | MBZ |G|MBZ|I|N| 492 +-+-+-+-+-+-+-+-+ 494 Flag Name and Meaning 495 ---- ---------------- 497 G LAG Description Indicator 499 When this flag is set, DDMAP describes a LAG interface. 501 7. Interface Index Sub-TLV 503 The Interface Index object is a Sub-TLV that MAY be included in a 504 DDMAP TLV. Zero or more Interface Index object MAY appear in a DDMAP 505 TLV. The Interface Index Sub-TLV describes the index assigned by 506 local LSR to the egress interface. 508 Interface Index Sub-TLV Type is TBD2. Length is 8, and the Value 509 field has following format: 511 0 1 2 3 512 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 513 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 514 | Interface Index Flags | Must Be Zero | 515 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 516 | Interface Index | 517 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 519 Figure 5: Interface Index Sub-TLV 521 Interface Index Flags 523 Interface Index Flags field is a bit vector with following format. 525 0 1 526 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 527 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 528 | Must Be Zero (Reserved) |M| 529 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 531 One flag is defined: M. The remaining flags MUST be set to zero 532 when sending and ignored on receipt. 534 Flag Name and Meaning 535 ---- ---------------- 537 M LAG Member Link Indicator 539 When this flag is set, interface index described in 540 this sub-TLV is member of a LAG. 542 Interface Index 544 Index assigned by the LSR to this interface. 546 8. Detailed Interface and Label Stack TLV 548 The Detailed Interface and Label Stack object is a TLV that MAY be 549 included in a MPLS echo reply message to report the interface on 550 which the MPLS echo request message was received and the label stack 551 that was on the packet when it was received. A responder LSR MUST 552 NOT insert more than one instance of this TLV. This TLV allows the 553 initiating LSR to obtain the exact interface and label stack 554 information as it appears at the responder LSR. 556 Detailed Interface and Label Stack TLV Type is TBD3. Length is K + 557 Sub-TLV Length, and the Value field has following format: 559 0 1 2 3 560 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 561 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 562 | Address Type | Must Be Zero | 563 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 564 | IP Address (4 or 16 octets) | 565 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 566 | Interface (4 or 16 octets) | 567 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 568 | Must Be Zero | Sub-TLV Length | 569 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 570 . . 571 . List of Sub-TLVs . 572 . . 573 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 575 Figure 6: Detailed Interface and Label Stack TLV 577 The Detailed Interface and Label Stack TLV format is derived from the 578 Interface and Label Stack TLV format (from [RFC4379]). Two changes 579 are introduced. First is that label stack, which is of variable 580 length, is converted into a sub-TLV. Second is that a new sub-TLV is 581 added to describe an interface index. The fields of Detailed 582 Interface and Label Stack TLV have the same use and meaning as in 583 [RFC4379]. A summary of the fields taken from the Interface and 584 Label Stack TLV is as below: 586 Address Type 588 The Address Type indicates if the interface is numbered or 589 unnumbered. It also determines the length of the IP Address 590 and Interface fields. The resulting total for the initial part 591 of the TLV is listed in the table below as "K Octets". The 592 Address Type is set to one of the following values: 594 Type # Address Type K Octets 595 ------ ------------ -------- 596 1 IPv4 Numbered 16 597 2 IPv4 Unnumbered 16 598 3 IPv6 Numbered 40 599 4 IPv6 Unnumbered 28 601 IP Address and Interface 603 IPv4 addresses and interface indices are encoded in 4 octets; 604 IPv6 addresses are encoded in 16 octets. 606 If the interface upon which the echo request message was 607 received is numbered, then the Address Type MUST be set to IPv4 608 Numbered or IPv6 Numbered, the IP Address MUST be set to either 609 the LSR's Router ID or the interface address, and the Interface 610 MUST be set to the interface address. 612 If the interface is unnumbered, the Address Type MUST be either 613 IPv4 Unnumbered or IPv6 Unnumbered, the IP Address MUST be the 614 LSR's Router ID, and the Interface MUST be set to the index 615 assigned to the interface. 617 Note: Usage of IPv6 Unnumbered has the same issue as [RFC4379], 618 described in Section 3.4.2 of [I-D.ietf-mpls-ipv6-only-gap]. A 619 solution should be considered an applied to both [RFC4379] and 620 this document. 622 Sub-TLV Length 624 Total length in octets of the sub-TLVs associated with this 625 TLV. 627 8.1. Sub-TLVs 629 This section defines the sub-TLVs that MAY be included as part of the 630 Detailed Interface and Label Stack TLV. 632 Sub-Type Value Field 633 --------- ------------ 634 1 Incoming Label stack 635 2 Incoming Interface Index 637 8.1.1. Incoming Label Stack Sub-TLV 639 The Incoming Label Stack sub-TLV contains the label stack as received 640 by the LSR. If any TTL values have been changed by this LSR, they 641 SHOULD be restored. 643 Incoming Label Stack Sub-TLV Type is 1. Length is variable, and the 644 Value field 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 | Label | TC |S| TTL | 650 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 651 . . 652 . . 653 . . 654 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 655 | Label | TC |S| TTL | 656 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 658 Figure 7: Incoming Label Stack Sub-TLV 660 8.1.2. Incoming Interface Index Sub-TLV 662 The Incoming Interface Index object is a Sub-TLV that MAY be included 663 in a Detailed Interface and Label Stack TLV. The Incoming Interface 664 Index Sub-TLV describes the index assigned by this LSR to the 665 interface which received the MPLS echo request message. 667 Incoming Interface Index Sub-TLV Type is 2. Length is 8, and the 668 Value field has following format: 670 0 1 2 3 671 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 672 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 673 | Interface Index Flags | Must Be Zero | 674 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 675 | Interface Index | 676 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 678 Figure 8: Incoming Interface Index Sub-TLV 680 Interface Index Flags 682 Interface Index Flags field is a bit vector with following format. 684 0 1 685 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 686 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 687 | Must Be Zero (Reserved) |M| 688 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 690 One flag is defined: M. The remaining flags MUST be set to zero 691 when sent and ignored on receipt. 693 Flag Name and Meaning 694 ---- ---------------- 696 M LAG Member Link Indicator 698 When this flag is set, the interface index described in 699 this sub-TLV is a member of a LAG. 701 Interface Index 703 Index assigned by the LSR to this interface. 705 9. Security Considerations 707 This document extends LSP Traceroute mechanism to discover and 708 exercise L2 ECMP paths. Additional processing are required for 709 initiating LSR and responder LSR, especially to compute and handle 710 increasing number of multipath information. Due to additional 711 processing, it is critical that proper security measures described in 712 [RFC4379] and [RFC6424] are followed. 714 10. IANA Considerations 716 10.1. LAG Interface Info TLV 718 The IANA is requested to assign new value TBD1 for LAG Interface Info 719 TLV from the "Multiprotocol Label Switching Architecture (MPLS) Label 720 Switched Paths (LSPs) Ping Parameters - TLVs" registry. 722 Value Meaning Reference 723 ----- ------- --------- 724 TBD1 LAG Interface Info TLV this document 726 10.2. Interface Index Sub-TLV 728 The IANA is requested to assign new value TBD2 for Interface Index 729 Sub-TLV from the "Multiprotocol Label Switching Architecture (MPLS) 730 Label Switched Paths (LSPs) Ping Parameters - TLVs" registry, "Sub- 731 TLVs for TLV Types 20" sub-registry. 733 Value Meaning Reference 734 ----- ------- --------- 735 TBD2 Interface Index Sub-TLV this document 737 10.3. Detailed Interface and Label Stack TLV 739 The IANA is requested to assign new value TBD3 for Detailed Interface 740 and Label Stack TLV from the "Multiprotocol Label Switching 741 Architecture (MPLS) Label Switched Paths (LSPs) Ping Parameters - 742 TLVs" registry. 744 Value Meaning Reference 745 ----- ------- --------- 746 TBD3 Detailed Interface and Label Stack TLV this document 748 10.4. New Sub-Registry 750 10.4.1. DS Flags 752 [RFC4379] defines the Downstream Mapping TLV, which has the Type 2 753 assigned from the "Multi-Protocol Label Switching (MPLS) Label 754 Switched Paths (LSPs) Ping Parameters - TLVs" registry. [RFC6424] 755 defines the Downstream Detailed Mapping TLV, which has the Type 20 756 assigned from the "Multi-Protocol Label Switching (MPLS) Label 757 Switched Paths (LSPs) Ping Parameters - TLVs" registry. DSMAP has 758 been deprecated by DDMAP, but both TLVs shares a field: "DS Flags". 759 This document requires allocation of a new value in the "DS Flags" 760 field, which is not maintained by IANA today. Therefore, this 761 document requests IANA to create new registries within 762 [IANA-MPLS-LSP-PING] protocol to maintain "DS Flags" field. Initial 763 values for this registry, "DS Flags", are described below. 765 Bit number Name Reference 766 ---------- ---------------------------------------- --------- 767 7 N: Treat as a Non-IP Packet RFC4379 768 6 I: Interface and Label Stack Object Request RFC4379 769 5-4 Unassigned 770 3 G: LAG Description Indicator this document 771 2-0 Unassigned 773 Assignments of DS Flags are via Standards Action [RFC5226] or IESG 774 Approval [RFC5226]. 776 Note that "DS Flags" is a field included in two TLVs defined in 777 "Multi-Protocol Label Switching (MPLS) Label Switched Paths (LSPs) 778 Ping Parameters - TLVs" registry: Downstream Mapping TLV (value 2) 779 and Downstream Detailed Mapping TLV (value 20). Modification to "DS 780 Flags" registry will affect both TLVs. 782 Also note that [I-D.akiya-mpls-entropy-lsp-ping] makes request to 783 create a new retry for "DS Flags", with new values being added for 784 Bit Number 4 and 5. If [I-D.akiya-mpls-entropy-lsp-ping] becomes RFC 785 and "DS Flags" IANA registry is created as result, then this document 786 simply requests Bit Number 3 (G: LAG Description Indicator) to be 787 added to the registry. 789 10.4.2. Sub-TLVs for TLV Type TBD3 791 The IANA is requested to make a new "Sub-TLVs for TLV Type TBD3" sub- 792 registry under "Multiprotocol Label Switching Architecture (MPLS) 793 Label Switched Paths (LSPs) Ping Parameters - TLVs" registry. 794 Initial values for this sub-registry, "Sub-TLVs for TLV Types TBD3", 795 are described below. 797 Sub-Type Name Reference 798 --------- ---------------------------------------- --------- 799 1 Incoming Label Stack this document 800 2 Incoming Interface Index this document 801 4-65535 Unassigned 803 Assignments of Sub-Types are via Standards Action [RFC5226] or IESG 804 Approval [RFC5226]. 806 11. Acknowledgements 808 Authors would like to thank Nagendra Kumar and Sam Aldrin for 809 providing useful comments and suggestions. 811 12. References 813 12.1. Normative References 815 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 816 Requirement Levels", BCP 14, RFC 2119, March 1997. 818 [RFC4379] Kompella, K. and G. Swallow, "Detecting Multi-Protocol 819 Label Switched (MPLS) Data Plane Failures", RFC 4379, 820 February 2006. 822 [RFC6424] Bahadur, N., Kompella, K., and G. Swallow, "Mechanism for 823 Performing Label Switched Path Ping (LSP Ping) over MPLS 824 Tunnels", RFC 6424, November 2011. 826 12.2. Informative References 828 [I-D.akiya-mpls-entropy-lsp-ping] 829 Akiya, N., Swallow, G., Pignataro, C., Malis, A., and S. 830 Aldrin, "Label Switched Path (LSP) and Pseudowire (PW) 831 Ping/Trace over MPLS Network using Entropy Labels (EL)", 832 draft-akiya-mpls-entropy-lsp-ping-02 (work in progress), 833 July 2014. 835 [I-D.ietf-mpls-ipv6-only-gap] 836 George, W. and C. Pignataro, "Gap Analysis for Operating 837 IPv6-only MPLS Networks", draft-ietf-mpls-ipv6-only-gap-01 838 (work in progress), July 2014. 840 [IANA-MPLS-LSP-PING] 841 IANA, "Multi-Protocol Label Switching (MPLS) Label 842 Switched Paths (LSPs) Ping Parameters", 843 . 846 [IEEE802.1AX] 847 IEEE Std. 802.1AX, "IEEE Standard for Local and 848 metropolitan area networks - Link Aggregation", November 849 2008. 851 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 852 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 853 May 2008. 855 Appendix A. LAG with L2 Switch Issues 857 Several flavors of "LAG with L2 switch" provisioning models are 858 described in this section, with MPLS data plane ECMP traversal 859 validation issues with each. 861 A.1. Equal Numbers of LAG Members 863 R1 ==== S1 ==== R2 865 The issue with this LAG provisioning model is that packets traversing 866 a LAG member from R1 to S1 can get load balanced by S1 towards R2. 867 Therefore, MPLS echo request messages traversing specific LAG member 868 from R1 to S1 can actually reach R2 via any LAG members, and sender 869 of MPLS echo request messages have no knowledge of this nor no way to 870 control this traversal. In the worst case, MPLS echo request 871 messages with specific entropies to exercise every LAG members from 872 R1 to S1 can all reach R2 via same LAG member. Thus it is impossible 873 for MPLS echo request sender to verify that packets intended to 874 traverse specific LAG member from R1 to S1 did actually traverse that 875 LAG member, and to deterministically exercise "receive" processing of 876 every LAG member on R2. 878 A.2. Deviating Numbers of LAG Members 880 ____ 881 R1 ==== S1 ==== R2 883 There are deviating number of LAG members on the two sides of the L2 884 switch. The issue with this LAG provisioning model is the same as 885 previous model, sender of MPLS echo request messages have no 886 knowledge of L2 load balance algorithm nor entropy values to control 887 the traversal. 889 A.3. LAG Only on Right 891 R1 ---- S1 ==== R2 893 The issue with this LAG provisioning model is that there is no way 894 for MPLS echo request sender to deterministically exercise both LAG 895 members from S1 to R2. And without such, "receive" processing of R2 896 on each LAG member cannot be verified. 898 A.4. LAG Only on Left 900 R1 ==== S1 ---- R2 902 MPLS echo request sender has knowledge of how to traverse both LAG 903 members from R1 to S1. However, both types of packets will terminate 904 on the non-LAG interface at R2. It becomes impossible for MPLS echo 905 request sender to know that MPLS echo request messages intended to 906 traverse a specific LAG member from R1 to S1 did indeed traverse that 907 LAG member. 909 Authors' Addresses 911 Nobo Akiya 912 Cisco Systems 914 Email: nobo@cisco.com 916 George Swallow 917 Cisco Systems 919 Email: swallow@cisco.com 920 Stephane Litkowski 921 Orange 923 Email: stephane.litkowski@orange.com 925 Bruno Decraene 926 Orange 928 Email: bruno.decraene@orange.com 930 John E. Drake 931 Juniper Networks 933 Email: jdrake@juniper.net