idnits 2.17.1 draft-ietf-mpls-proxy-lsp-ping-02.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 == The document seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 3, 2014) is 3585 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) -- Looks like a reference, but probably isn't: '1' on line 774 -- Looks like a reference, but probably isn't: '255' on line 774 ** Obsolete normative reference: RFC 4379 (Obsoleted by RFC 8029) ** Obsolete normative reference: RFC 6424 (Obsoleted by RFC 8029) Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group G. Swallow 3 Internet-Draft V. Lim 4 Intended status: Standards Track Cisco Systems 5 Expires: January 4, 2015 S. Aldrin 6 Huawei Technologies 7 July 3, 2014 9 Proxy MPLS Echo Request 10 draft-ietf-mpls-proxy-lsp-ping-02 12 Abstract 14 This document defines a means of remotely initiating Multiprotocol 15 Label Switched Protocol Pings on Label Switched Paths. A MPLS proxy 16 ping request is sent to any Label Switching Routers along a Label 17 Switched Path. The primary motivations for this facility are first 18 to limit the number of messages and related processing when using LSP 19 Ping in large Point-to-Multipoint LSPs, and second to enable leaf to 20 leaf/root tracing. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on January 3, 2015. 39 Copyright Notice 41 Copyright (c) 2014 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 This document may contain material from IETF Documents or IETF 55 Contributions published or made publicly available before November 56 10, 2008. The person(s) controlling the copyright in some of this 57 material may not have granted the IETF Trust the right to allow 58 modifications of such material outside the IETF Standards Process. 59 Without obtaining an adequate license from the person(s) controlling 60 the copyright in such materials, this document may not be modified 61 outside the IETF Standards Process, and derivative works of it may 62 not be created outside the IETF Standards Process, except to format 63 it for publication as an RFC or to translate it into languages other 64 than English. 66 Table of Contents 68 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 69 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 70 2. Proxy Ping Overview . . . . . . . . . . . . . . . . . . . . . 5 71 3. Proxy MPLS Echo Request / Reply Procedures . . . . . . . . . . 6 72 3.1. Procedures for the initiator . . . . . . . . . . . . . . . 6 73 3.2. Procedures for the proxy LSR . . . . . . . . . . . . . . . 7 74 3.2.1. Proxy LSR Handling when it is Egress for FEC . . . . . 9 75 3.2.2. Downstream Detailed/Downstream Maps in Proxy Reply . . 10 76 3.2.3. Sending an MPLS proxy ping reply . . . . . . . . . . . 10 77 3.2.4. Sending the MPLS Echo Requests . . . . . . . . . . . . 10 78 3.2.4.1. Forming the base MPLS Echo Request . . . . . . . . 11 79 3.2.4.2. Per interface sending procedures . . . . . . . . . 12 80 4. Proxy Ping Request / Reply Messages . . . . . . . . . . . . . 12 81 4.1. Proxy Ping Request / Reply Message formats . . . . . . . . 13 82 4.2. Proxy Ping Request Message contents . . . . . . . . . . . 14 83 4.3. Proxy Ping Reply Message Contents . . . . . . . . . . . . 14 84 5. TLV formats . . . . . . . . . . . . . . . . . . . . . . . . . 15 85 5.1. Proxy Echo Parameters TLV . . . . . . . . . . . . . . . . 15 86 5.1.1. Next Hop sub-TLV . . . . . . . . . . . . . . . . . . . 18 87 5.2. Reply-to Address TLV . . . . . . . . . . . . . . . . . . . 19 88 5.3. Upstream Neighbor Address TLV . . . . . . . . . . . . . . 20 89 5.4. Downstream Neighbor Address TLV . . . . . . . . . . . . . 21 90 6. Security Considerations . . . . . . . . . . . . . . . . . . . 21 91 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 22 92 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 93 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23 94 9.1. Normative References . . . . . . . . . . . . . . . . . . . 23 95 9.2. Informative References . . . . . . . . . . . . . . . . . . 23 96 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24 98 1. Introduction 100 This document is motivated by two broad issues in connection with 101 diagnosing Point-to-Multipoint (P2MP) Label Switched Paths (LSPs). 102 The first is scalability due to the automatic replication of 103 Multiprotocol Label Switching (MPLS) Echo Request Messages as they 104 proceed down the tree. The second, which is primarily motivated by 105 Label Distribution Protocol based Point-to-Multipoint (P2MP) and 106 Multipoint-to-Multipoint (MP2MP) Label Switched Paths [RFC6388], is 107 the ability to trace a sub-LSP from leaf node to root node. 109 It is anticipated that very large Point-to-Multipoint and Multipoint- 110 to-Multipoint (MP2MP) Label Switched Paths will exist. Further it is 111 anticipated that many of the applications for P2MP/MP2MP tunnels will 112 require OAM that is both rigorous and scalable. 114 Suppose one wishes to trace a P2MP LSP to localize a fault which is 115 affecting one egress or a set of egresses. Suppose one follows the 116 normal procedure for tracing - namely repeatedly pinging from the 117 root, incrementing the Time to Live (TTL) by one after each three or 118 so pings. Such a procedure has the potential for producing a large 119 amount of processing at the P2MP-LSP midpoints and egresses. It also 120 could produce an unwieldy number of replies back to the root. 122 One alternative would be to begin sending pings from points at or 123 near the affected egress(es) and working backwards toward the root. 124 The TTL could be held constant, say two, limiting the number of 125 responses to the number of next-next-hops of the point where a ping 126 is initiated. 128 In the case of Resource Reservation Protocol-Traffic Engineering 129 (RSVP-TE), all setup is initiated from the root of the tree. Thus, 130 the root of the tree has knowledge of both all the leaf nodes and 131 usually the topology of the entire tree. Thus the above alternative 132 can easily be initiated by the root node. 134 In [RFC6388] the situation is quite different. Leaf nodes initiate 135 connectivity to the tree which is granted by the first node toward 136 the root that is part of the tree. The root node may only be aware 137 of the immediately adjacent (downstream) nodes of the tree. Initially 138 the leaf node only has knowledge of the (upstream) node to which it 139 is immediately adjacent. However this is sufficient information to 140 initiate a trace. First the above procedure is applied by asking 141 that node to ping across the final link. That is, a message is sent 142 from the leaf to the upstream node requesting it to send an MPLS Echo 143 Request for the Forward Equivalence Class (FEC) of the tree in 144 question on said link. The leaf node also requests the identity of 145 the upstream neighbor's upstream neighbor for that FEC. With this 146 information the procedure can iteratively be applied until the fault 147 is localized or the root node is reached. In all cases the TTL for 148 the request need only be at most 2. Thus the processing load of each 149 request is small as only a limited number of nodes will receive the 150 request. 152 This document defines protocol extensions to MPLS ping [RFC4379] to 153 allow a third party to remotely cause an MPLS Echo Request message to 154 be sent down a LSP or part of an LSP. The procedure described in the 155 paragraphs above does require that the initiator know the previous- 156 hop node to the one which was pinged on the prior iteration. This 157 information is readily available in [RFC4875]. This document also 158 provides a means for obtaining this information for [RFC6388]. 160 While the motivation for this document came from multicast scaling 161 concerns, it's applicability may be wider. The procedures presented 162 in this document are applicable to all LSP ping FEC types where the 163 MPLS Echo Request/Reply are IP encapsulated and the MPLS Echo Reply 164 can sent out of band of the LSP over ip. Remote pinging of LSPs that 165 involve the use of in-band control channels is beyond the scope of 166 this document. 168 Other uses of this facility are beyond the scope of this document. In 169 particular, the procedures defined in this document only allow 170 testing of a FEC stack consisting of a single FEC. It also does not 171 allow the initiator to specify the label assigned to that FEC, nor 172 does it allow the initiator to cause any additional labels to be 173 added to the label stack of the actual MPLS Echo Request message. 175 1.1. Requirements Language 177 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 178 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 179 document are to be interpreted as described in RFC 2119. 181 The term "Must Be Zero" (MBZ) is used in TLV descriptions for 182 reserved fields. These fields MUST be set to zero when sent and 183 ignored on receipt. 185 Based on context the terms leaf and egress are used interchangeably. 186 Egress is used where consistency with[RFC4379] was deemed 187 appropriate. Receiver is used in the context of receiving protocol 188 messages. 190 [Note (to be removed after assignments occur): = to be assigned 191 by IANA] 193 2. Proxy Ping Overview 195 This document defines a protocol interaction between a first node and 196 a node which is part of an LSP to allow the first node to request 197 that second node initiate an LSP ping for the LSP on behalf of the 198 first node. Two new LSP Ping messages are defined for remote 199 pinging: the MPLS proxy ping request and the MPLS proxy ping reply. 201 A remote ping operation on a P2MP LSP generally involves at least 202 three LSRs; in some scenarios none of these are the ingress (root) or 203 an egress (leaf) of the LSP. 205 We refer to these nodes with the following terms: 207 Initiator - the node which initiates the ping operation by sending 208 an MPLS proxy ping request message 210 Proxy LSR - the node which is the destination of the MPLS proxy 211 request message and potential initiator of the MPLS Echo Request 213 Receiver(s) - the nodes which receive the MPLS Echo Request 214 message 216 Responder - A receiver that responds to a MPLS Proxy Ping Request 217 or an MPLS Echo Request 219 We note that in some scenarios, the initiator could also be the 220 responder, in which case the response would be internal to the node. 222 The initiator formats an MPLS proxy ping request message and sends it 223 to the proxy LSR, a node it believes to be on the path of the LSP. 224 This message instructs the proxy LSR to either Reply with Proxy 225 information or to send a MPLS Echo Request inband of the LSP. The 226 initiator requests Proxy information so that it can learn additional 227 information it needs to use to form a subsequent MPLS Proxy Ping 228 request. For example during LSP traceroute an initiator needs the 229 downstream map information to form an MPLS Echo Request. An 230 initiator may also want to learn a Proxy LSR's FEC neighbor 231 information so that it can form proxy request to various nodes along 232 the LSP. 234 The proxy LSR either replies with the requested Proxy information or 235 it validates that it has a label mapping for the specified FEC and 236 that it is authorized to send the specified MPLS Echo Request on 237 behalf of the initiator. 239 If the proxy LSR has a label mapping for the FEC and all 240 authorization checks have passed, the proxy LSR formats an MPLS Echo 241 Request. If the source address of the MPLS Echo Request is not to be 242 set to the Proxy Request source address, the initiator must include a 243 Reply-to Address TLV containing the source address to use in the MPLS 244 Echo Request. It then sends it inband of the LSP. 246 The receivers process the MPLS Echo Request as normal, sending their 247 MPLS Echo Replies back to the initiator. 249 If the proxy LSR failed to send a MPLS Echo Request as normal because 250 it encountered an issue while attempting to send, a MPLS proxy ping 251 reply message is sent back with a return code indicating that the 252 MPLS Echo Request could not be sent. 254 3. Proxy MPLS Echo Request / Reply Procedures 256 3.1. Procedures for the initiator 258 The initiator creates an MPLS proxy ping request message. 260 The message MUST contain a Target FEC Stack that describes the FEC 261 being tested. The topmost FEC in the target FEC stack is used at the 262 Proxy LSR to lookup the MPLS label stack that will be used to 263 encapsulate the MPLS Echo Request packet. 265 The MPLS Proxy Ping request message MUST contain a Proxy Echo 266 Parameters TLV. In that TLV, the address type is set to either IPv4 267 or IPv6. The Destination IP Address is set to the value to be used 268 in the MPLS Echo Request packet. If the Address Type is IPv4, an 269 address is from the range 127/8. If the Address Type is IPv6, an 270 address is from the range ::FFFF:7F00:0/104. 272 The Reply mode and Global Flags of the Proxy Echo Parameters TLV are 273 set to the values to be used in the MPLS Echo Request message header. 274 The Source UDP Port is set to the value to be used in the MPLS Echo 275 Request packet. The TTL is set to the value to be used in the 276 outgoing MPLS label stack. See Section 5.1 for further details. 278 If the FEC's Upstream/Downstream Neighbor address information is 279 required, the initiator sets the "Request for FEC neighbor 280 information" Proxy Flags in the Proxy Echo Parameters TLV. 282 If a Downstream Detailed or Downstream Mapping TLV is required in a 283 MPLS Proxy Ping Reply, the initiator sets the "Request for Downstream 284 Detailed Mapping" or "Request for Downstream Mapping" Proxy Flags in 285 the Proxy Echo Parameters TLV. Only one of the two flags can be set. 287 The Proxy Request reply mode is set with one of the reply modes 288 defined in [RFC4379] as appropriate. 290 A list of Next Hop IP Addresses MAY be included to limit the next 291 hops towards which the MPLS Echo Request message will be sent. These 292 are encoded as Next Hop sub-TLVs and included in the Proxy Echo 293 Parameters TLV. 295 Proxy Echo Parameter TLV MPLS payload size field may be set to 296 request that the MPLS Echo Request (including any IP and UDP header) 297 be zero padded to the specified size. When the payload size is non 298 zero, if sending the MPLS Echo Request involves using an IP header, 299 the Do not Fragment (DF) bit MUST be set to 1. 301 Any of following TLVs MAY be included; these TLVs will be copied into 302 the MPLS Echo Request messages: 304 Pad 306 Vendor Enterprise Number 308 Reply TOS Byte 310 P2MP Responder Identifier [RFC6425] 312 Echo Jitter TLV [RFC6425] 314 Vendor Private TLVs 316 Downstream Detailed Mapping (DDMAP) or Downstream Mapping (DSMAP) 317 TLVs MAY be included. These TLVs will be matched to the next hop 318 address for inclusion in those particular MPLS Echo Request messages. 320 The message is then encapsulated in a UDP packet. The source User 321 Datagram Protocol (UDP) port is chosen by the initiator; the 322 destination UDP port is set to 3503. The IP header is set as 323 follows: the source IP address is a routable address of the 324 initiator; the destination IP address is a routable address to the 325 Proxy LSR. The packet is then sent with the IP TTL is set to 255. 327 3.2. Procedures for the proxy LSR 329 A proxy LSR that receives an MPLS proxy ping request message, parses 330 the packet to ensure that it is a well-formed packet. It checks that 331 the TLVs that are not marked "Ignore" are understood. If not, it 332 sets the Return Code set to "Malformed echo request received" or "TLV 333 not understood" (as appropriate), and the Subcode set to zero. If 334 the Reply Mode of the message header is not 1(Do not reply), an MPLS 335 proxy ping reply message SHOULD be sent as described below. In the 336 latter case, the misunderstood TLVs (only) are included in an Errored 337 TLVs TLV. 339 The Proxy LSR checks that the MPLS proxy ping request message did not 340 arrive via one of its exception processing paths. Packets arriving 341 via IP TTL expiry, IP destination address set to a Martian address or 342 label ttl expiry MUST be treated as "Unauthorized" packets. An MPLS 343 proxy ping reply message MAY be sent with a Return Code of , 344 "Proxy Ping not authorized". 346 The header fields Sender's Handle and Sequence Number are not 347 examined, but are saved to be included in the MPLS proxy ping reply 348 or MPLS Echo Request messages. 350 The proxy LSR validates that it has a label mapping for the specified 351 FEC, it then determines if it is an ingress, egress, transit or bud 352 node and sets the Return Code as appropriate. A new return code 353 (Replying router has FEC mapping for topmost FEC) has been defined 354 for the case where the Proxy LSR is an ingress (for example head of 355 the TE tunnel or a transit router) because the existing RFC4379 356 return codes don't match the situation. For example, when a Proxy 357 LSR is a transit router, it's not appropriate for the return code to 358 describe how the packet would transit because the MPLS proxy ping 359 request doesn't contain information about what input interface the an 360 MPLS Echo Request would be switched from at the Proxy LSR. 362 The proxy LSR then determines if it is authorized to send the 363 specified MPLS Echo Request on behalf of the initiator. A Proxy LSR 364 MUST be capable of filtering addresses to validate initiators. Other 365 filters on FECs or MPLS Echo Request contents MAY be applied. If a 366 filter has been invoked (i.e. configured) and an address does not 367 pass the filter, then an MPLS Echo Request message MUST NOT be sent, 368 and the event SHOULD be logged. An MPLS proxy ping reply message MAY 369 be sent with a Return Code of , "Proxy Ping not authorized". 371 The destination address specified in the Proxy Echo Parameters TLV is 372 checked to ensure that it conforms to the address allowed IPv4 or 373 IPv6 address range. If not, it sets the Return Code set to 374 "Malformed echo request received" and the Subcode set to zero. If 375 the Reply Mode of the message header is not 1, an MPLS proxy ping 376 reply message SHOULD be sent as described below. 378 If the "Request for FEC Neighbor Address info" flag is set, a 379 Upstream Neighbor Address TLV and/or Downstream Neighbor Address 380 TLV(s) is/are formatted for inclusion in the MPLS proxy ping reply. 381 If the Upstream or Downstream address is unknown they are not 382 included in the Proxy Reply. 384 If there are Next Hop sub-TLVs in the Proxy Echo Parameters TLV, each 385 address is examined to determine if it is a valid next hop for this 386 FEC. If any are not, Proxy Echo Parameters TLV should be updated 387 removing unrecognized Next Hop sub-TLVs. The updated Proxy Echo 388 Parameters TLV MUST be included in the MPLS proxy ping reply. 390 If the "Request for Downstream Detailed Mapping" or "Request for 391 Downstream Mapping" flag is set, the LSR formats (for inclusions in 392 the MPLS proxy ping reply) a Downstream Detailed/Downstream Mapping 393 TLV for each interface over which the MPLS Echo Request will be sent. 395 If the Proxy LSR is the egress for the FEC, the behavior of the proxy 396 LSR vary depending on whether the node is an Egress of a P2P LSP, a 397 P2MP LSP or MP2MP LSP. Additional details can be found in the 398 section describing "Handling when Proxy LSR it is egress for FEC". 400 If the Reply Mode of the MPLS proxy ping request message header is "1 401 - do not reply", no MPLS proxy ping reply is sent. Otherwise an MPLS 402 proxy ping reply message or MPLS Echo Request should be sent as 403 described below. 405 3.2.1. Proxy LSR Handling when it is Egress for FEC 407 This sections describes the different behaviors for the Proxy LSR 408 when it's the Egress for the FEC. In the P2MP budnode and MP2MP 409 budnode and egress cases, different behavior is required. 411 When the Proxy LSR is the egress of a P2P FEC, a MPLS proxy ping 412 reply should be sent to the initiator with the return code set to 3 413 (Reply router is Egress for FEC) with return Subcode set to 0. 415 When the Proxy LSR is the egress of a P2MP FEC, it can be either a 416 budnode or just an Egress. If the Proxy LSR is a budnode, a MPLS 417 proxy ping reply should be sent to the initiator with the return code 418 set to 3 (Reply router is Egress for FEC) with return Subcode set to 419 0 and DS/DDMAPs only if the Proxy initiator requested information to 420 be returned in a MPLS proxy ping reply. If the Proxy LSR is a 421 budnode but not requested to return a MPLS proxy ping reply, the 422 Proxy LSR should send MPLS Echo Request packet(s) to the downstream 423 neighbors (no MPLS Echo Reply is sent to the Proxy Initiator to 424 indicate that the Proxy LSR is an egress). If the Proxy LSR is just 425 an egress, a MPLS proxy ping reply should be sent to the initiator 426 with the return code set to 3 (Reply router is Egress for FEC) with 427 return Subcode set to 0. 429 When the Proxy LSR is the egress of a MP2MP FEC, it can be either a 430 budnode or just an Egress. LSP pings sent from a leaf of a MP2MP has 431 different behavior in this case. MPLS Echo Request are sent to all 432 upstream/downstream neighbors. The Proxy LSRs need to be consistent 433 with this variation in behavior. If the Proxy LSR is a budnode or 434 just an egress, a MPLS proxy ping reply should be sent to the 435 initiator with the return code set to 3 (Reply router is Egress for 436 FEC) with return Subcode set to 0 and DS/DDMAPs included only if the 437 Proxy initiator requested information to be returned in a MPLS proxy 438 ping reply. If the Proxy LSR is not requested to return information 439 in a MPLS proxy ping reply, the Proxy LSR should send MPLS Echo 440 Request packets to all upstream/downstream neighbors as would be done 441 when sourcing an LSP ping from a MP2MP leaf (no MPLS Echo Reply is 442 sent to the Proxy initiator indicating that the Proxy LSR is an 443 egress). 445 3.2.2. Downstream Detailed/Downstream Maps in Proxy Reply 447 When the Proxy LSR is a transit or bud node, downstream maps 448 corresponding to how the packet is transited can not be supplied 449 unless an ingress interface for the MPLS Echo Request is specified, 450 since this information is not available and since all valid output 451 paths are of interest, the Proxy LSR should include DS/DDMAP(s) to 452 describe the entire set of paths that the packet can be replicated, 453 like in the case where an LSP ping is initiated at the Proxy LSR. For 454 mLDP there is a DSMAP/DDMAP per upstream/downstream neighbor for 455 MP2MP LSPs, or per downstream neighbor in the P2MP LSP case. 457 When the Proxy LSR is a bud node or egress in a MP2MP LSP or a 458 budnode in a P2MP LSP, an LSP ping initiated from the Proxy LSR would 459 source packets only to the neighbors but not itself despite the fact 460 that the Proxy LSR is itself an egress for the FEC. In order to 461 match the behavior as seen from LSP Ping initiated at the Proxy LSR, 462 the Proxy Reply should contain DSMAP/DDMAPs for only the paths to the 463 upstream/downstream neighbors, but no DSMAP/DDMAP describing its own 464 egresses paths. The proxy LSR identifies that it's an egress for the 465 FEC using a different Proxy Reply return code. The Proxy reply 466 return code is either set to "Reply router has a mapping for the 467 topmost FEC" or "Reply router is Egress for the FEC". 469 3.2.3. Sending an MPLS proxy ping reply 471 The Reply mode, Sender's Handle and Sequence Number fields are copied 472 from the proxy ping request message. The TLVs specified above are 473 included. The message is encapsulated in a UDP packet. The source 474 IP address is a routable address of the proxy LSR; the source port is 475 the well-known UDP port for LSP ping. The destination IP address and 476 UDP port are copied from the source IP address and UDP port of the 477 MPLS Echo Request. The IP TTL is set to 255. 479 3.2.4. Sending the MPLS Echo Requests 481 A MPLS Echo Request is formed as described in the next section. The 482 section below that describes how the MPLS Echo Request is sent on 483 each interface. 485 3.2.4.1. Forming the base MPLS Echo Request 487 A Next_Hop_List is created as follows. If Next Hop sub-TLVs were 488 included in the received Proxy Parameters TLV, the Next_Hop_List 489 created from the address in those sub-TLVs as adjusted above. 490 Otherwise, the list is set to all the next hops to which the FEC 491 would be forwarded. 493 The proxy LSR then formats an MPLS Echo Request message. The Global 494 Flags and Reply Mode are copied from the Proxy Echo Parameters TLV. 495 The Return Code and Return Subcode are set to zero. 497 The Sender's Handle and Sequence Number are copied from the remote 498 echo request message. 500 The TimeStamp Sent is set to the time-of-day (in seconds and 501 microseconds) that the MPLS Echo Request is sent. The TimeStamp 502 Received is set to zero. 504 If the reply-to address TLV is present, it is used to set the echo 505 request source address, otherwise the echo request source address is 506 set to the proxy request source address. 508 The following TLVs are copied from the MPLS proxy ping request 509 message. Note that of these, only the Target FEC Stack is REQUIRED 510 to appear in the MPLS proxy ping request message. 512 Target FEC Stack 514 Pad 516 Vendor Enterprise Number 518 Reply TOS Byte 520 P2MP Responder Identifier [RFC6425] 522 Echo Jitter TLV [RFC6425] 524 Vendor Private TLVs 526 The message is then encapsulated in a UDP packet. The source UDP 527 port is copied from the Proxy Echo Parameters TLV. The destination 528 port copied from the proxy ping request message. 530 The source IP address is set to a routable address specified in the 531 reply-to-address TLV or the source address of the received proxy 532 request. Per usual the TTL of the IP packet is set to 1. 534 If the Explicit Differentiated Services Code Point (DSCP) flag is 535 set, the Requested DSCP byte is examined. If the setting is 536 permitted then the DSCP byte of the IP header of the MPLS Echo 537 Request message is set to that value. If the Proxy LSR does not 538 permit explicit control for the DSCP byte, the MPLS Proxy Echo 539 Parameters with the Explicit DSCP flag cleared MUST be included in 540 any MPLS proxy ping reply message to indicate why an MPLS Echo 541 Request was not sent. The return code MUST be set to , "Proxy 542 ping parameters need to be modified". If the Explicit DSCP flag is 543 not set, the Proxy LSR should set the MPLS Echo Request DSCP settings 544 to the value normally used to source LSP ping packets.. 546 3.2.4.2. Per interface sending procedures 548 The proxy LSR now iterates through the Next_Hop_List modifying the 549 base MPLS Echo Request to form the MPLS Echo Request packet which is 550 then sent on that particular interface. 552 For each next hop address, the outgoing label stack is determined. 553 The TTL for the label corresponding to the FEC specified in the FEC 554 stack is set such that the TTL on the wire will be other TTL 555 specified in the Proxy Echo Parameters. If any additional labels are 556 pushed onto the stack, their TTLs are set to 255. This will ensure 557 that the requestor will not have control over tunnels not relevant to 558 the FEC being tested. 560 If the MPLS proxy ping request message contained Downstream Mapping/ 561 Downstream Detailed Mapping TLVs, they are examined. If the 562 Downstream IP Address matches the next hop address that Downstream 563 Mapping TLV is included in the MPLS Echo Request. 565 The packet is then transmitted on this interface. 567 4. Proxy Ping Request / Reply Messages 569 This document defines two new LSP Ping messages, the MPLS proxy ping 570 request and the MPLS proxy ping reply. 572 4.1. Proxy Ping Request / Reply Message formats 574 Except where noted, the definitions of all fields in the messages are 575 identical to those found in [RFC4379]. The messages have the 576 following format: 578 0 1 2 3 579 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 580 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 581 | Version Number | MUST Be Zero | 582 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 583 | Message Type | Reply mode | Return Code | Return Subcode| 584 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 585 | Sender's Handle | 586 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 587 | Sequence Number | 588 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 589 | TLVs ... | 590 . . 591 . . 592 . . 593 | | 594 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 596 Version Number 598 The Version Number is currently 1. (Note: the Version Number 599 is to be incremented whenever a change is made that affects the 600 ability of an implementation to correctly parse or process an 601 MPLS Echo Request/Reply. These changes include any syntactic 602 or semantic changes made to any of the fixed fields, or to any 603 TLV or sub-TLV assignment or format that is defined at a 604 certain version number. The Version Number may not need to be 605 changed if an optional TLV or sub-TLV is added.) 607 Message Type 609 Type Message 610 ---- ------- 611 TBA-1 MPLS proxy ping request 612 (Pending IANA assignment) 614 TBA-2 MPLS proxy ping reply 615 (Pending IANA assignment) 617 4.2. Proxy Ping Request Message contents 619 The MPLS proxy ping request message MAY contain the following 620 TLVs: 622 Type TLV 623 ---- ----------- 624 1 Target FEC Stack 625 2 Downstream Mapping 626 3 Pad 627 5 Vendor Enterprise Number 628 10 Reply TOS Byte 630 11 P2MP Responder Identifier [RFC6425] 631 12 Echo Jitter TLV [RFC6425] 632 20 Downstream Detailed Mapping 633 21 Reply Path [RFC7110] 634 22 Reply TC [RFC7110] 635 TBA-3 Proxy Echo Parameters (Pending IANA assignment) 636 TBA-4 Reply-to-Address TLV 637 * Vendor Private TLVs 639 * TLVs types in the Vendor Private TLV Space MUST be 640 ignored if not understood 642 4.3. Proxy Ping Reply Message Contents 644 The MPLS proxy ping reply message MAY contain the following TLVs: 646 Type TLV 647 ---- ----------- 648 1 Target FEC Stack 649 2 Downstream Mapping 650 5 Vendor Enterprise Number 651 9 Errored TLVs 652 20 Downstream Detailed Mapping 653 TBA-3 Proxy Echo Parameters (Pending IANA assignment) 654 TBA-5 Upstream Neighbor Address (Pending IANA assignment) 655 TBA-6 Downstream Neighbor Address (0 or more) 656 (Pending IANA assignment) 657 * Vendor Private TLVs 659 * TLVs types in the Vendor Private TLV Space MUST be 660 ignored if not understood 662 5. TLV formats 664 5.1. Proxy Echo Parameters TLV 666 The Proxy Echo Parameters TLV is a TLV that MUST be included in an 667 MPLS proxy ping request message. The length of the TLV is 12 + K + 668 S, where K is the length of the Destination IP Address field and S is 669 the total length of the sub-TLVs. The Proxy Echo Parameters TLV can 670 be used to either to 1) control attributes used in Composing and 671 Sending an MPLS Echo Request or 2) query the Proxy LSR for 672 information about the topmost FEC in the target FEC stack but not 673 both. In the case where the Proxy LSR is being queried (ie 674 information needs to be returned in a Proxy Reply), no MPLS Echo 675 Request will be sent from the Proxy LSR. The MPLS proxy ping request 676 echo header's Reply Mode should be set to "Reply with Proxy Info". 678 0 1 2 3 679 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 680 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 681 | Address Type | Reply mode | Proxy Flags | 682 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 683 | TTL | Rqst'd DSCP | Source UDP Port | 684 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 685 | Global Flags | MPLS Payload size | 686 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 687 | | 688 : Destination IP Address : 689 | | 690 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 691 | | 692 : : 693 : Sub-TLVs : 694 : : 695 | | 696 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 698 Address Type 700 The type and length of the address found in the in the Destination 701 IP Address and Next Hop IP Addresses fields. The values are 702 shared with the Downstream Mapping Address Type Registry. 704 The type codes applicable in this case appear in the table below: 706 Address Family Type Length 708 IPv4 1 4 709 IPv6 3 16 711 Reply mode 713 The reply mode to be sent in the MPLS Echo Request message; the 714 values are as specified in [RFC4379]. 716 Proxy Flags 718 The Proxy Request Initiator sets zero, one or more of these flags 719 to request actions at the Proxy LSR. 721 0x01 Request for FEC Neighbor Address info 723 When set this requests that the proxy LSR supply the 724 Upstream and Downstream neighbor address information in the 725 MPLS proxy ping reply message. This flag is only applicable 726 for the topmost FEC in the FEC stack if the FEC types 727 corresponds with a P2MP or MP2MP LSPs. The Proxy LSR MUST 728 respond as applicable with a Upstream Neighbor Address TLV 729 and Downstream Neighbor Address TLV(s) in the MPLS proxy 730 ping reply message. Upstream Neighbor Address TLV needs be 731 included only if there is an upstream neighbor. Similarly, 732 one Downstream Neighbor Address TLV needs to be included for 733 each Downstream Neighbor for which the LSR learned bindings 734 from. 736 Setting this flag will cause the proxy LSR to cancel sending 737 an Echo request. Information learned with such proxy reply 738 may be used by the proxy initiator to generate subsequent 739 proxy requests. 741 0x02 Request for Downstream Mapping 743 When set this requests that the proxy LSR supply a 744 Downstream Mapping TLV see [RFC4379] in the MPLS proxy ping 745 reply message. It's not valid to have Request for 746 Downstream Detailed Mapping flag set when this flag is set. 748 Setting this flag will cause the proxy LSR to cancel sending 749 an Echo request. Information learned with such proxy reply 750 may be used by the proxy initiator to generate subsequent 751 proxy requests. 753 0x04 Request for Downstream Detailed Mapping 755 When set this requests that the proxy LSR supply a 756 Downstream Detailed Mapping TLV see [RFC6424] in the MPLS 757 proxy ping reply message. It's not valid to have Request 758 for Downstream Mapping flag set when this flag is set. 760 Setting this flag will cause the proxy LSR to cancel sending 761 an Echo request. Information learned with such proxy reply 762 may be used by the proxy initiator to generate subsequent 763 proxy requests. 765 0x08 Explicit DSCP Request 767 When set this requests that the proxy LSR use the supplied 768 "Rqst'd DSCP" byte in the Echo Request message 770 TTL 772 The TTL to be used in the label stack entry corresponding to 773 the topmost FEC in the in the MPLS Echo Request packet. Valid 774 values are in the range [1,255]. A setting of 0 should be 775 ignored by the Proxy LSR. 777 Requested DSCP 779 This field is valid only if the Explicit DSCP flag is set. If 780 not set, the field MUST be zero on transmission and ignored on 781 receipt. When the flag is set this field contains the DSCP 782 value to be used in the MPLS Echo Request packet IP header. 784 Source UDP Port 786 The source UDP port to be sent in the MPLS Echo Request packet 788 Global Flags 790 The Global Flags to be sent in the MPLS Echo Request message 792 MPLS Payload Size 794 Used to request that the MPLS payload (IP header + UDP header + 795 MPLS Echo Request) be padded using a zero filled Pad TLV so 796 that the IP header, UDP header and MPLS Echo Request total the 797 specified size. Field set to zero means no size request is 798 being made. If the requested size is less than the minimum 799 size required to form the MPLS Echo Request, the request will 800 be treated as a best effort request with the Proxy LSR building 801 the smallest possible packet (i.e. not using a Pad TLV). The 802 IP header DF bit should be set when this field is non zero. 804 Destination IP Address 806 If the Address Type is IPv4, an address from the range 127/8; 807 If the Address Type is IPv6, an address from the range 808 ::FFFF:7F00:0/104 810 Sub-TLVs 812 A TLV encoded list of sub-TLVs. Currently one is defined. 814 Sub-Type Length Value Field 815 -------- ------ ----------- 816 1 8+ Next Hop 818 5.1.1. Next Hop sub-TLV 820 This sub-TLV is used to describe a particular next hop towards which 821 the Echo Request packet should be sent. If the topmost FEC in the 822 FEC-stack is a multipoint LSP, this sub-TLV may appear multiple 823 times. 825 0 1 2 3 826 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 827 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 828 | Addr Type | MUST be Zero | 829 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 830 | Next Hop IP Address (4 or 16 octets) | 831 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 832 | Next Hop Interface (0, 4 or 16 octets) | 833 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 835 Address Type 837 Type Type of Next Hop Addr Length IF Length 839 1 IPv4 Numbered 4 4 840 2 IPv4 Unnumbered 4 4 841 3 IPv6 Numbered 16 16 842 4 IPv6 Unnumbered 16 4 843 5 IPv4 Protocol Adj 4 0 844 6 IPv6 Protocol Adj 16 0 846 Note: Types 1-4 correspond to the types in the DS Mapping 847 TLV. They are expected to populated with information 848 obtained through a previously returned DS Mapping TLV. 849 Types 5 and 6 are intended to be populated from the local 850 address information obtained from a previously returned 851 Downstream Neighbor Address TLV(s)/Upstream Neighbor 852 Address TLV. 854 Next Hop IP Address 855 A next hop address that the echo request message is to 856 be sent towards 858 Next Hop Interface 860 Identifier of the interface through which the echo request 861 message is to be sent. For Addr Type 5, and 6, the Next Hop 862 interface field isn't used and must of a associated byte length 863 of "0" octets. 865 5.2. Reply-to Address TLV 867 Used to specify the MPLS Echo Request IP source address. This 868 address must be IP reachable via the Proxy LSR otherwise it will be 869 rejected. 871 0 1 2 3 872 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 873 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 874 | Address Type | MUST be Zero | 875 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 876 | | 877 : Reply-to Address : 878 | | 879 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 881 Address Type 883 A type code as specified in the table below: 885 Type Type of Address 887 1 IPv4 888 3 IPv6 890 5.3. Upstream Neighbor Address TLV 892 0 1 2 3 893 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 894 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 895 |Upst Addr Type |Local Addr Type| MUST be Zero | 896 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 897 | | 898 : Upstream Address : 899 | | 900 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 901 | | 902 : Local Address : 903 | | 904 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 906 Upst Addr Type; Local Addr Type 908 These two fields determine the type and length of the 909 respective addresses. The codes are specified in the table 910 below: 912 Type Type of Address Length 914 0 No Address Supplied 0 915 1 IPv4 4 916 3 IPv6 16 918 Upstream Address 920 The address of the immediate upstream neighbor for the topmost 921 FEC in the FEC stack. If protocol adjacency exists by which 922 the label for this FEC was exchanged, this address MUST be the 923 address used in that protocol exchange. 925 Local Address 927 The local address used in the protocol adjacency exists by 928 which the label for this FEC was exchanged. 930 5.4. Downstream Neighbor Address TLV 932 0 1 2 3 933 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 934 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 935 |Dnst Addr Type |Local Addr Type| MUST be Zero | 936 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 937 | | 938 : Downstream Address : 939 | | 940 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 941 | | 942 : Local Address : 943 | | 944 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 946 Dnst Addr Type; Local Addr Type 948 These two fields determine the type and length of the 949 respective addresses. The codes are specified in the table 950 below: 952 Type Type of Address Length 954 0 No Address Supplied 0 955 1 IPv4 4 956 3 IPv6 16 958 Downstream Address 960 The address of a immediate downstream neighbor for the topmost 961 FEC in the FEC stack. If protocol adjacency exists by which 962 the label for this FEC was exchanged, this address MUST be the 963 address used in that protocol exchange. 965 Local Address 967 The local address used in the protocol adjacency exists by 968 which the label for this FEC was exchanged. 970 6. Security Considerations 972 The mechanisms described in this document are intended to be used 973 within a Service Provider network and to be initiated only under the 974 authority of that administration. 976 If such a network also carries Internet traffic, or permits IP access 977 from other administrations, MPLS proxy ping message SHOULD be 978 discarded at those points. This can be accomplished by filtering on 979 source address or by filtering all MPLS ping messages on UDP port. 981 Any node which acts as a proxy node SHOULD validate requests against 982 a set of valid source addresses. An implementation MUST provide such 983 filtering capabilities. 985 MPLS proxy ping request messages are IP addressed directly to the 986 Proxy node. If a node which receives an MPLS proxy ping message via 987 IP or Label TTL expiration, it MUST NOT be acted upon. 989 MPLS proxy ping request messages are IP addressed directly to the 990 Proxy node. If a MPLS Proxy ping request IP destination address is a 991 Martian Address, it MUST NOT be acted upon. 993 if a MPLS Proxy ping request IP source address is not IP reachable by 994 the Proxy LSR, the Proxy request MUST NOT be acted upon. 996 MPLS proxy ping requests are limited to making their request via the 997 specification of a FEC. This ensures that only valid MPLS Echo 998 Request messages can be created. No label spoofing attacks are 999 possible. 1001 7. Acknowledgements 1003 The authors would like to thank Nobo Akiya for his detailed review 1004 and insightful comments. 1006 8. IANA Considerations 1008 This document makes the following assignments (pending IANA action) 1010 LSP Ping Message Types 1012 Type Value Field 1013 ---- ----------- 1014 TBA-1 MPLS proxy ping request 1015 TBA-2 MPLS proxy ping reply 1017 TLVs and Sub-TLVs 1019 Type Sub-Type Value Field 1020 ---- -------- ----------- 1021 TBA-3 Proxy Echo Parameters 1022 1 Next Hop 1023 TBA-4 Reply-to Address 1024 TBA-5 Upstream Neighbor Address 1025 TBA-6 Downstream Neighbor Address 1027 Return Code [pending IANA assignment] 1029 Value Meaning 1030 ----- ------- 1031 TBA-7 Proxy ping not authorized. 1032 TBA-8 Proxy ping parameters need to be modified. 1033 TBA-9 MPLS Echo Request Could not be sent. 1034 TBA-10 Replying router has FEC mapping for topmost FEC. 1036 Downstream Address Mapping Registry [pending IANA assignment] 1038 Value Meaning 1039 ----- ------- 1040 TBA-11 IPv4 Protocol Adj 1041 TBA-12 IPv6 Protocol Adj 1043 9. References 1045 9.1. Normative References 1047 [RFC4379] Kompella, K. and G. Swallow, "Detecting Multi-Protocol 1048 Label Switched (MPLS) Data Plane Failures", RFC 4379, 1049 February 2006. 1051 [RFC6424] Bahadur, N., Kompella, K., and G. Swallow, "Mechanism for 1052 Performing Label Switched Path Ping (LSP Ping) over MPLS 1053 Tunnels", RFC 6424, November 2011. 1055 [RFC6425] Saxena, S., Swallow, G., Ali, Z., Farrel, A., Yasukawa, 1056 S., and T. Nadeau, "Detecting Data-Plane Failures in 1057 Point-to-Multipoint MPLS - Extensions to LSP Ping", RFC 1058 6425, November 2011. 1060 [RFC7110] Chen, M., Cao, W., Ning, S., Jounay, F., and Delord, S., 1061 "Return Path Specified Label Switched Path (LSP) Ping", 1062 RFC 7110, January 2014. 1064 9.2. Informative References 1066 [RFC4875] Aggarwal, R., Papadimitriou, D., and S. Yasukawa, 1067 "Extensions to Resource Reservation Protocol - Traffic 1068 Engineering (RSVP-TE) for Point-to-Multipoint TE Label 1069 Switched Paths (LSPs)", RFC 4875, May 2007. 1071 [RFC6388] Wijnands, IJ., Minei, I., Kompella, K., and B. Thomas, 1072 "Label Distribution Protocol Extensions for Point-to- 1073 Multipoint and Multipoint-to-Multipoint Label Switched 1074 Paths", RFC 6388, November 2011. 1076 Authors' Addresses 1078 George Swallow 1079 Cisco Systems 1080 1414 Massachusetts Ave 1081 Boxborough, MA 01719 1082 USA 1084 Email: swallow@cisco.com 1086 Vanson Lim 1087 Cisco Systems 1088 1414 Massachusetts Avenue 1089 Boxborough, MA 01719 1090 USA 1092 Email: vlim@cisco.com 1094 Sam Aldrin 1095 Huawei Technologies 1096 2330 Central Express Way 1097 Santa Clara, CA 95951 1098 USA 1100 Email: aldrin.ietf@gmail.com