idnits 2.17.1 draft-ietf-mpls-proxy-lsp-ping-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 -- The document date (January 29, 2015) is 3368 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 779 -- Looks like a reference, but probably isn't: '255' on line 779 ** Obsolete normative reference: RFC 4379 (Obsoleted by RFC 8029) ** Obsolete normative reference: RFC 6424 (Obsoleted by RFC 8029) Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 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: August 2, 2015 S. Aldrin 6 Huawei Technologies 7 January 29, 2015 9 Proxy MPLS Echo Request 10 draft-ietf-mpls-proxy-lsp-ping-03 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 to 18 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), its areas, and its working groups. Note that 29 other groups may also distribute working documents as Internet- 30 Drafts. 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 The list of current Internet-Drafts can be accessed at 38 http://www.ietf.org/1id-abstracts.html 40 The list of Internet-Draft Shadow Directories can be accessed at 41 http://www.ietf.org/shadow.html 43 This Internet-Draft will expire on August 2, 2015. 45 Copyright Notice 47 Copyright (c) 2015 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (http://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 63 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 64 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 65 2. Proxy Ping Overview . . . . . . . . . . . . . . . . . . . . . 5 66 2.1. Initiating Proxy Ping . . . . . . . . . . . . . . . . . . 5 67 2.2. Handling at Proxy LSR . . . . . . . . . . . . . . . . . . 6 68 2.1.1. Backward Compatibility . . . . . . . . . . . . . . . . 6 69 3. Proxy MPLS Echo Request / Reply Procedures . . . . . . . . . . 6 70 3.1. Procedures for the initiator . . . . . . . . . . . . . . . 7 71 3.2. Procedures for the proxy LSR . . . . . . . . . . . . . . . 8 72 3.2.1. Proxy LSR Handling when it is Egress for FEC . . . . . 10 73 3.2.2. Downstream Detailed/Downstream Maps in Proxy Reply . . 11 74 3.2.3. Sending an MPLS proxy ping reply . . . . . . . . . . . 11 75 3.2.4. Sending the MPLS Echo Requests . . . . . . . . . . . . 11 76 3.2.4.1. Forming the base MPLS Echo Request . . . . . . . . 11 77 3.2.4.2. Per interface sending procedures . . . . . . . . . 13 78 4. Proxy Ping Request / Reply Messages . . . . . . . . . . . . . 13 79 4.1. Proxy Ping Request / Reply Message formats . . . . . . . . 13 80 4.2. Proxy Ping Request Message contents . . . . . . . . . . . 14 81 4.3. Proxy Ping Reply Message Contents . . . . . . . . . . . . 14 82 5. TLV formats . . . . . . . . . . . . . . . . . . . . . . . . . 15 83 5.1. Proxy Echo Parameters TLV . . . . . . . . . . . . . . . . 15 84 5.1.1. Next Hop sub-TLV . . . . . . . . . . . . . . . . . . . 18 85 5.2. Reply-to Address TLV . . . . . . . . . . . . . . . . . . . 19 86 5.3. Upstream Neighbor Address TLV . . . . . . . . . . . . . . 19 87 5.4. Downstream Neighbor Address TLV . . . . . . . . . . . . . 20 88 6. Security Considerations . . . . . . . . . . . . . . . . . . . 21 89 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 22 90 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 91 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23 92 9.1. Normative References . . . . . . . . . . . . . . . . . . . 23 93 9.2. Informative References . . . . . . . . . . . . . . . . . . 23 94 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23 96 1. Introduction 98 This document is motivated by two broad issues in connection with 99 diagnosing Point-to-Multipoint (P2MP) Label Switched Paths (LSPs). 100 The first is scalability due to the automatic replication of 101 Multiprotocol Label Switching (MPLS) Echo Request Messages as they 102 proceed down the tree. The second, which is primarily motivated by 103 Label Distribution Protocol based Point-to-Multipoint (P2MP) and 104 Multipoint-to-Multipoint (MP2MP) Label Switched Paths [RFC6388], is 105 the ability to trace a sub-LSP from leaf node to root node. 107 It is anticipated that very large Point-to-Multipoint and Multipoint- 108 to-Multipoint (MP2MP) Label Switched Paths will exist. Further it is 109 anticipated that many of the applications for P2MP/MP2MP tunnels will 110 require OAM that is both rigorous and scalable. 112 Suppose one wishes to trace a P2MP LSP to localize a fault which is 113 affecting one egress or a set of egresses. Suppose one follows the 114 normal procedure for tracing - namely repeatedly pinging from the 115 root, incrementing the Time to Live (TTL) by one after each three or 116 so pings. Such a procedure has the potential for producing a large 117 amount of processing at the P2MP-LSP midpoints and egresses. It also 118 could produce an unwieldy number of replies back to the root. 120 One alternative would be to begin sending pings from points at or 121 near the affected egress(es) and working backwards toward the root. 122 The TTL could be held constant, say two, limiting the number of 123 responses to the number of next-next-hops of the point where a ping 124 is initiated. 126 In the case of Resource Reservation Protocol-Traffic Engineering 127 (RSVP-TE), all setup is initiated from the root of the tree. Thus, 128 the root of the tree has knowledge of both all the leaf nodes and 129 usually the topology of the entire tree. Thus the above alternative 130 can easily be initiated by the root node. 132 In [RFC6388] the situation is quite different. Leaf nodes initiate 133 connectivity to the tree which is granted by the first node toward 134 the root that is part of the tree. The root node may only be aware of 135 the immediately adjacent (downstream) nodes of the tree. Initially 136 the leaf node only has knowledge of the (upstream) node to which it 137 is immediately adjacent. However this is sufficient information to 138 initiate a trace. First the above procedure is applied by asking that 139 node to ping across the final link. That is, a message is sent from 140 the leaf to the upstream node requesting it to send an MPLS Echo 141 Request for the Forward Equivalence Class (FEC) of the tree in 142 question on said link. The leaf node also requests the identity of 143 the upstream neighbor's upstream neighbor for that FEC. With this 144 information the procedure can iteratively be applied until the fault 145 is localized or the root node is reached. In all cases the TTL for 146 the request need only be at most 2. Thus the processing load of each 147 request is small as only a limited number of nodes will receive the 148 request. 150 This document defines protocol extensions to MPLS ping [RFC4379] to 151 allow a third party to remotely cause an MPLS Echo Request message to 152 be sent down an LSP or part of an LSP. The procedure described in the 153 paragraphs above does require that the initiator know the previous- 154 hop node to the one which was pinged on the prior iteration. This 155 information is readily available in [RFC4875]. This document also 156 provides a means for obtaining this information for [RFC6388]. 158 While the motivation for this document came from multicast scaling 159 concerns, it's applicability may be wider. The procedures presented 160 in this document are applicable to all LSP ping FEC types where the 161 MPLS Echo Request/Reply are IP encapsulated and the MPLS Echo Reply 162 can sent out of band of the LSP over ip. Remote pinging of LSPs that 163 involve the use of in-band control channels is beyond the scope of 164 this document. 166 Other uses of this facility are beyond the scope of this document. In 167 particular, the procedures defined in this document only allow 168 testing of a FEC stack consisting of a single FEC. It also does not 169 allow the initiator to specify the label assigned to that FEC, nor 170 does it allow the initiator to cause any additional labels to be 171 added to the label stack of the actual MPLS Echo Request message. 173 1.1. Requirements Language 175 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 176 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 177 document are to be interpreted as described in [RFC2119]. 179 The term "Must Be Zero" (MBZ) is used in TLV descriptions for 180 reserved fields. These fields MUST be set to zero when sent and 181 ignored on receipt. 183 Based on context the terms leaf and egress are used interchangeably. 184 Egress is used where consistency with[RFC4379] was deemed 185 appropriate. Receiver is used in the context of receiving protocol 186 messages. 188 1.2. Terminology 190 Term Definition 191 ----- ------------------------------------------- 192 LSP Label Switched Paths 193 LSR Label Switching Router 194 MP2MP Multipoint to Multipoint 195 P2MP Point to Multipoint 196 TTL Time to Live 198 [Note (to be removed after assignments occur): = to be assigned 199 by IANA] 201 2. Proxy Ping Overview 203 This document defines a protocol interaction between a first node and 204 a node which is part of an LSP to allow the first node to request 205 that second node initiate an LSP ping for the LSP on behalf of the 206 first node. Since the second node sends the LSP Ping on behalf of the 207 first node, it does not maintain state to be able to handle the 208 corresponding LSP Ping response. Instead the responder to the LSP 209 ping sends the LSP Ping response to either the first node or another 210 node configured to handle it. Two new LSP Ping messages are defined 211 for remote pinging: the MPLS proxy ping request and the MPLS proxy 212 ping reply. 214 A remote ping operation on a P2MP LSP generally involves at least 215 three LSRs; in some scenarios none of these are the ingress (root) or 216 an egress (leaf) of the LSP. 218 We refer to these nodes with the following terms: 220 Initiator - the node which initiates the ping operation by sending 221 an MPLS proxy ping request message 223 Proxy LSR - the node which is the destination of the MPLS proxy 224 request message and potential initiator of the MPLS Echo Request 226 Receiver(s) - the nodes which receive the MPLS Echo Request 227 message 229 Responder - A receiver that responds to a MPLS Proxy Ping Request 230 or an MPLS Echo Request 232 We note that in some scenarios, the initiator could also be the 233 responder, in which case the response would be internal to the node. 235 2.1. Initiating Proxy Ping 236 The initiator formats an MPLS proxy ping request message and sends it 237 to the proxy LSR, a node it believes to be on the path of the LSP. 238 This message instructs the proxy LSR to either Reply with Proxy 239 information or to send a MPLS Echo Request inband of the LSP. The 240 initiator requests Proxy information so that it can learn additional 241 information it needs to use to form a subsequent MPLS Proxy Ping 242 request. For example during LSP traceroute an initiator needs the 243 downstream map information to form an MPLS Echo Request. An initiator 244 may also want to learn a Proxy LSR's FEC neighbor information so that 245 it can form proxy request to various nodes along the LSP. 247 2.2. Handling at Proxy LSR 249 The proxy LSR either replies with the requested Proxy information or 250 it validates that it has a label mapping for the specified FEC and 251 that it is authorized to send the specified MPLS Echo Request on 252 behalf of the initiator. 254 If the proxy LSR has a label mapping for the FEC and all 255 authorization checks have passed, the proxy LSR formats an MPLS Echo 256 Request. If the source address of the MPLS Echo Request is not to be 257 set to the Proxy Request source address, the initiator MUST include a 258 Reply-to Address TLV containing the source address to use in the MPLS 259 Echo Request. It then sends it inband of the LSP. 261 The receivers process the MPLS Echo Request as normal, sending their 262 MPLS Echo Replies back to the initiator. 264 If the proxy LSR failed to send a MPLS Echo Request as normal because 265 it encountered an issue while attempting to send, a MPLS proxy ping 266 reply message is sent back with a return code indicating that the 267 MPLS Echo Request could not be sent. 269 2.1.1. Backward Compatibility 271 As described in sec 4.4 of [RFC4379], If the packet is not well- 272 formed, LSR X SHOULD send an MPLS Echo Reply with the Return Code set 273 to "Malformed echo request received" and the Subcode to zero. If 274 there are any TLVs not marked as "Ignore" that Proxy LSR does not 275 understand, Proxy LSR SHOULD send an MPLS "TLV not understood" (as 276 appropriate), and the Subcode set to zero. 278 In the case the targeted proxy LSR does not understand LSP ping Echo 279 Request at all, like any other LSR which do not understand the 280 messages, they MUST be dropped and no messages is set back to the 281 initiator. 283 3. Proxy MPLS Echo Request / Reply Procedures 284 3.1. Procedures for the initiator 286 The initiator creates an MPLS proxy ping request message. 288 The message MUST contain a Target FEC Stack that describes the FEC 289 being tested. The topmost FEC in the target FEC stack is used at the 290 Proxy LSR to lookup the MPLS label stack that will be used to 291 encapsulate the MPLS Echo Request packet. 293 The MPLS Proxy Ping request message MUST contain a Proxy Echo 294 Parameters TLV. In that TLV, the address type is set to either IPv4 295 or IPv6. The Destination IP Address is set to the value to be used in 296 the MPLS Echo Request packet. If the Address Type is IPv4, an address 297 is from the range 127/8. If the Address Type is IPv6, an address is 298 from the range ::FFFF:7F00:0/104. 300 The Reply mode and Global Flags of the Proxy Echo Parameters TLV are 301 set to the values to be used in the MPLS Echo Request message header. 302 The Source UDP Port is set to the value to be used in the MPLS Echo 303 Request (the source port is supplied by the Proxy Ping initiator 304 because it or a node known to it handles the LSP ping responses). The 305 TTL is set to the value to be used in the outgoing MPLS label stack. 306 See Section 5.1 for further details. 308 If the FEC's Upstream/Downstream Neighbor address information is 309 required, the initiator sets the "Request for FEC neighbor 310 information" Proxy Flags in the Proxy Echo Parameters TLV. 312 If a Downstream Detailed or Downstream Mapping TLV is required in a 313 MPLS Proxy Ping Reply, the initiator sets the "Request for Downstream 314 Detailed Mapping" or "Request for Downstream Mapping" Proxy Flags in 315 the Proxy Echo Parameters TLV. Only one of the two flags can be set. 317 The Proxy Request reply mode is set with one of the reply modes 318 defined in [RFC4379] as appropriate. 320 A list of Next Hop IP Addresses MAY be included to limit the next 321 hops towards which the MPLS Echo Request message will be sent. These 322 are encoded as Next Hop sub-TLVs and included in the Proxy Echo 323 Parameters TLV. 325 Proxy Echo Parameter TLV MPLS payload size field may be set to 326 request that the MPLS Echo Request (including any IP and UDP header) 327 be zero padded to the specified size. When the payload size is non 328 zero, if sending the MPLS Echo Request involves using an IP header, 329 the Do not Fragment (DF) bit MUST be set to 1. 331 Any of following TLVs MAY be included; these TLVs will be copied into 332 the MPLS Echo Request messages: 334 Pad 336 Vendor Enterprise Number 338 Reply TOS Byte 340 P2MP Responder Identifier [RFC6425] 342 Echo Jitter TLV [RFC6425] 344 Vendor Private TLVs 346 Downstream Detailed Mapping (DDMAP) or Downstream Mapping (DSMAP) 347 TLVs MAY be included. These TLVs will be matched to the next hop 348 address for inclusion in those particular MPLS Echo Request messages. 350 The message is then encapsulated in a UDP packet. The source User 351 Datagram Protocol (UDP) port for the MPLS proxy ping requests message 352 is chosen by the initiator; the destination UDP port is set to 3503. 353 The IP header is set as follows: the source IP address is a routable 354 address of the initiator; the destination IP address is a routable 355 address to the Proxy LSR. The packet is then sent with the IP TTL is 356 set to 255. 358 3.2. Procedures for the proxy LSR 360 A proxy LSR that receives an MPLS proxy ping request message, parses 361 the packet to ensure that it is a well-formed packet. It checks that 362 the TLVs that are not marked "Ignore" are understood. If any part of 363 the message is malformed, it sets the Return Code set to "Malformed 364 echo request received". If all the TLVs are well formed and any TLVs 365 are not understood, the return code is set to "TLV not understood". 366 The Subcode is set to zero for both cases. 368 If the Reply Mode of the message header is not 1(Do not reply), an 369 MPLS proxy ping reply message SHOULD be sent as described below. 371 If the Return Code is "TLV not understood", no more processing of the 372 MPLS proxy ping request message is required. The Proxy LSR sends an 373 MPLS Proxy ping reply message with an Errored TLVs TLV containing all 374 the not understood TLVs (only). 376 The Proxy LSR checks that the MPLS proxy ping request message did not 377 arrive via one of its exception processing paths. Packets arriving 378 via IP TTL expiry, IP destination address set to a Martian address or 379 label ttl expiry MUST be treated as "Unauthorized" packets. An MPLS 380 proxy ping reply message MAY be sent with a Return Code of , 381 "Proxy Ping not authorized". 383 The header fields Sender's Handle and Sequence Number are not 384 examined, but included in the MPLS proxy ping reply or MPLS Echo 385 Request messages, if one is sent as a direct result of the received 386 message. 388 The proxy LSR validates that it has a label mapping for the specified 389 FEC, it then determines if it is an ingress, egress, transit or bud 390 node and sets the Return Code as appropriate. A new return code 391 (Replying router has FEC mapping for topmost FEC) has been defined 392 for the case where the Proxy LSR is an ingress (for example head of 393 the TE tunnel or a transit router) because the existing RFC4379 394 return codes don't match the situation. For example, when a Proxy LSR 395 is a transit router, it's not appropriate for the return code to 396 describe how the packet would transit because the MPLS proxy ping 397 request doesn't contain information about what input interface the an 398 MPLS Echo Request would be switched from at the Proxy LSR. 400 The proxy LSR then determines if it is authorized to send the 401 specified MPLS Echo Request on behalf of the initiator. A Proxy LSR 402 MUST be capable of filtering addresses to validate initiators. Other 403 filters on FECs or MPLS Echo Request contents MAY be applied. If a 404 filter has been invoked (i.e. configured) and an address does not 405 pass the filter, then an MPLS Echo Request message MUST NOT be sent, 406 and the event SHOULD be logged. An MPLS proxy ping reply message MAY 407 be sent with a Return Code of , "Proxy Ping not authorized". 409 The destination address specified in the Proxy Echo Parameters TLV is 410 checked to ensure that it conforms to the address allowed IPv4 or 411 IPv6 address range. If not, the Return Code set to "Malformed echo 412 request received" and the Subcode set to zero. If the Reply Mode of 413 the message header is not 1, an MPLS proxy ping reply message SHOULD 414 be sent as described below. 416 If the "Request for FEC Neighbor Address info" flag is set, a 417 Upstream Neighbor Address TLV and/or Downstream Neighbor Address 418 TLV(s) is/are formatted for inclusion in the MPLS proxy ping reply. 419 If the Upstream or Downstream address is unknown they are not 420 included in the Proxy Reply. 422 If there are Next Hop sub-TLVs in the Proxy Echo Parameters TLV, each 423 address is examined to determine if it is a valid next hop for this 424 FEC. If any are not, Proxy Echo Parameters TLV SHOULD be updated 425 removing unrecognized Next Hop sub-TLVs. The updated Proxy Echo 426 Parameters TLV MUST be included in the MPLS proxy ping reply. 428 If the "Request for Downstream Detailed Mapping" or "Request for 429 Downstream Mapping" flag is set, the LSR formats (for inclusions in 430 the MPLS proxy ping reply) a Downstream Detailed/Downstream Mapping 431 TLV for each interface over which the MPLS Echo Request will be sent. 433 If the Proxy LSR is the egress for the FEC, the behavior of the proxy 434 LSR vary depending on whether the node is an Egress of a P2P LSP, a 435 P2MP LSP or MP2MP LSP. Additional details can be found in the section 436 describing "Handling when Proxy LSR it is egress for FEC". 438 If the Reply Mode of the MPLS proxy ping request message header is "1 439 - do not reply", no MPLS proxy ping reply is sent. Otherwise an MPLS 440 proxy ping reply message or MPLS Echo Request SHOULD be sent as 441 described below. 443 3.2.1. Proxy LSR Handling when it is Egress for FEC 445 This sections describes the different behaviors for the Proxy LSR 446 when it's the Egress for the FEC. In the P2MP budnode and MP2MP 447 budnode and egress cases, different behavior is required. 449 When the Proxy LSR is the egress of a P2P FEC, a MPLS proxy ping 450 reply SHOULD be sent to the initiator with the return code set to 3 451 (Reply router is Egress for FEC) with return Subcode set to 0. 453 When the Proxy LSR is the egress of a P2MP FEC, it can be either a 454 budnode or just an Egress. If the Proxy LSR is a budnode, a MPLS 455 proxy ping reply SHOULD be sent to the initiator with the return code 456 set to 3 (Reply router is Egress for FEC) with return Subcode set to 457 0 and DS/DDMAPs only if the Proxy initiator requested information to 458 be returned in a MPLS proxy ping reply. If the Proxy LSR is a budnode 459 but not requested to return a MPLS proxy ping reply, the Proxy LSR 460 SHOULD send MPLS Echo Request packet(s) to the downstream neighbors 461 (no MPLS Echo Reply is sent to the Proxy Initiator to indicate that 462 the Proxy LSR is an egress). If the Proxy LSR is just an egress, a 463 MPLS proxy ping reply SHOULD be sent to the initiator with the return 464 code set to 3 (Reply router is Egress for FEC) with return Subcode 465 set to 0. 467 When the Proxy LSR is the egress of a MP2MP FEC, it can be either a 468 budnode or just an Egress. LSP pings sent from a leaf of a MP2MP has 469 different behavior in this case. MPLS Echo Request are sent to all 470 upstream/downstream neighbors. The Proxy LSRs need to be consistent 471 with this variation in behavior. If the Proxy LSR is a budnode or 472 just an egress, a MPLS proxy ping reply SHOULD be sent to the 473 initiator with the return code set to 3 (Reply router is Egress for 474 FEC) with return Subcode set to 0 and DS/DDMAPs included only if the 475 Proxy initiator requested information to be returned in a MPLS proxy 476 ping reply. If the Proxy LSR is not requested to return information 477 in a MPLS proxy ping reply, the Proxy LSR SHOULD send MPLS Echo 478 Request packets to all upstream/downstream neighbors as would be done 479 when sourcing an LSP ping from a MP2MP leaf (no MPLS Echo Reply is 480 sent to the Proxy initiator indicating that the Proxy LSR is an 481 egress). 483 3.2.2. Downstream Detailed/Downstream Maps in Proxy Reply 485 When the Proxy LSR is a transit or bud node, downstream maps 486 corresponding to how the packet is transited can not be supplied 487 unless an ingress interface for the MPLS Echo Request is specified. 488 Since this information is not available and all valid output paths 489 are of interest, the Proxy LSR SHOULD include DS/DDMAP(s) to describe 490 the entire set of paths that the packet can be replicated. This is 491 similar to the case where an LSP ping is initiated at the Proxy LSR. 492 For mLDP there is a DSMAP/DDMAP per upstream/downstream neighbor for 493 MP2MP LSPs, or per downstream neighbor in the P2MP LSP case. 495 When the Proxy LSR is a bud node or egress in a MP2MP LSP or a 496 budnode in a P2MP LSP, an LSP ping initiated from the Proxy LSR would 497 source packets only to the neighbors but not itself despite the fact 498 that the Proxy LSR is itself an egress for the FEC. In order to match 499 the behavior as seen from LSP Ping initiated at the Proxy LSR, the 500 Proxy Reply SHOULD contain DSMAP/DDMAPs for only the paths to the 501 upstream/downstream neighbors, but no DSMAP/DDMAP describing its own 502 egresses paths. The proxy LSR identifies that it's an egress for the 503 FEC using a different Proxy Reply return code. The Proxy reply return 504 code is either set to "Reply router has a mapping for the topmost 505 FEC" or "Reply router is Egress for the FEC". 507 3.2.3. Sending an MPLS proxy ping reply 509 The Reply mode, Sender's Handle and Sequence Number fields are copied 510 from the proxy ping request message. The TLVs specified above are 511 included. The message is encapsulated in a UDP packet. The source IP 512 address is a routable address of the proxy LSR; the source port is 513 the well-known UDP port for LSP ping. The destination IP address and 514 UDP port are copied from the source IP address and UDP port of the 515 MPLS Proxy Ping Request. The IP TTL is set to 255. 517 3.2.4. Sending the MPLS Echo Requests 519 A MPLS Echo Request is formed as described in the next section. The 520 section below that describes how the MPLS Echo Request is sent on 521 each interface. 523 3.2.4.1. Forming the base MPLS Echo Request 524 A Next_Hop_List is created as follows. If Next Hop sub-TLVs were 525 included in the received Proxy Parameters TLV, the Next_Hop_List 526 created from the address in those sub-TLVs as adjusted above. 527 Otherwise, the list is set to all the next hops to which the FEC 528 would be forwarded. 530 The proxy LSR then formats an MPLS Echo Request message. The Global 531 Flags and Reply Mode are copied from the Proxy Echo Parameters TLV. 532 The Return Code and Return Subcode are set to zero. 534 The Sender's Handle and Sequence Number are copied from the remote 535 echo request message. 537 The TimeStamp Sent is set to the time-of-day (in seconds and 538 microseconds) that the MPLS Echo Request is sent. The TimeStamp 539 Received is set to zero. 541 If the reply-to address TLV is present, it is used to set the echo 542 request source address, otherwise the echo request source address is 543 set to the proxy request source address. 545 The following TLVs are copied from the MPLS proxy ping request 546 message. Note that of these, only the Target FEC Stack is REQUIRED to 547 appear in the MPLS proxy ping request message. 549 Target FEC Stack 551 Pad 553 Vendor Enterprise Number 555 Reply TOS Byte 557 P2MP Responder Identifier [RFC6425] 559 Echo Jitter TLV [RFC6425] 561 Vendor Private TLVs 563 The message is then encapsulated in a UDP packet. The source UDP port 564 is copied from the Proxy Echo Parameters TLV. The destination port 565 copied from the proxy ping request message. 567 The source IP address is set to a routable address specified in the 568 reply-to-address TLV or the source address of the received proxy 569 request. Per usual the TTL of the IP packet is set to 1. 571 If the Explicit Differentiated Services Code Point (DSCP) flag is 572 set, the Requested DSCP byte is examined. If the setting is permitted 573 then the DSCP byte of the IP header of the MPLS Echo Request message 574 is set to that value. If the Proxy LSR does not permit explicit 575 control for the DSCP byte, the MPLS Proxy Echo Parameters with the 576 Explicit DSCP flag cleared MUST be included in any MPLS proxy ping 577 reply message to indicate why an MPLS Echo Request was not sent. The 578 return code MUST be set to , "Proxy ping parameters need to be 579 modified". If the Explicit DSCP flag is not set, the Proxy LSR SHOULD 580 set the MPLS Echo Request DSCP settings to the value normally used to 581 source LSP ping packets.. 583 3.2.4.2. Per interface sending procedures 585 The proxy LSR now iterates through the Next_Hop_List modifying the 586 base MPLS Echo Request to form the MPLS Echo Request packet which is 587 then sent on that particular interface. 589 For each next hop address, the outgoing label stack is determined. 590 The TTL for the label corresponding to the FEC specified in the FEC 591 stack is set such that the TTL on the wire will be other TTL 592 specified in the Proxy Echo Parameters. If any additional labels are 593 pushed onto the stack, their TTLs are set to 255. This will ensure 594 that the requestor will not have control over tunnels not relevant to 595 the FEC being tested. 597 If the MPLS proxy ping request message contained Downstream Mapping/ 598 Downstream Detailed Mapping TLVs, they are examined. If the 599 Downstream IP Address matches the next hop address that Downstream 600 Mapping TLV is included in the MPLS Echo Request. 602 The packet is then transmitted on this interface. 604 4. Proxy Ping Request / Reply Messages 606 This document defines two new LSP Ping messages, the MPLS proxy ping 607 request and the MPLS proxy ping reply. 609 4.1. Proxy Ping Request / Reply Message formats 611 The packet format is as defined in [RFC4379]. Two new message types, 612 Proxy Ping Request and Reply, are being added. 614 Message Type 616 Type Message 617 ---- ------- 618 TBA-1 MPLS proxy ping request 619 (Pending IANA assignment) 621 TBA-2 MPLS proxy ping reply 622 (Pending IANA assignment) 624 4.2. Proxy Ping Request Message contents 626 The MPLS proxy ping request message MAY contain the following 627 TLVs: 629 Type TLV 630 ---- ----------- 631 1 Target FEC Stack 632 2 Downstream Mapping 633 3 Pad 634 5 Vendor Enterprise Number 635 10 Reply TOS Byte 637 11 P2MP Responder Identifier [RFC6425] 638 12 Echo Jitter TLV [RFC6425] 639 20 Downstream Detailed Mapping 640 21 Reply Path [RFC7110] 641 22 Reply TC [RFC7110] 642 TBA-3 Proxy Echo Parameters (Pending IANA assignment) 643 TBA-4 Reply-to-Address TLV 644 * Vendor Private TLVs 646 * TLVs types in the Vendor Private TLV Space MUST be 647 ignored if not understood 649 4.3. Proxy Ping Reply Message Contents 651 The MPLS proxy ping reply message MAY contain the following TLVs: 653 Type TLV 654 ---- ----------- 655 1 Target FEC Stack 656 2 Downstream Mapping 657 5 Vendor Enterprise Number 658 9 Errored TLVs 659 20 Downstream Detailed Mapping 660 TBA-3 Proxy Echo Parameters (Pending IANA assignment) 661 TBA-5 Upstream Neighbor Address (Pending IANA assignment) 662 TBA-6 Downstream Neighbor Address (0 or more) 663 (Pending IANA assignment) 664 * Vendor Private TLVs 666 * TLVs types in the Vendor Private TLV Space MUST be 667 ignored if not understood 669 5. TLV formats 671 5.1. Proxy Echo Parameters TLV 673 The Proxy Echo Parameters TLV is a TLV that MUST be included in an 674 MPLS proxy ping request message. The length of the TLV is 12 + K + S, 675 where K is the length of the Destination IP Address field and S is 676 the total length of the sub-TLVs. The Proxy Echo Parameters TLV can 677 be used to either to 1) control attributes used in Composing and 678 Sending an MPLS Echo Request or 2) query the Proxy LSR for 679 information about the topmost FEC in the target FEC stack but not 680 both. In the case where the Proxy LSR is being queried (ie 681 information needs to be returned in a Proxy Reply), no MPLS Echo 682 Request will be sent from the Proxy LSR. The MPLS proxy ping request 683 echo header's Reply Mode SHOULD be set to "Reply with Proxy Info". 685 0 1 2 3 686 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 687 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 688 | Address Type | Reply mode | Proxy Flags | 689 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 690 | TTL | Rqst'd DSCP | Source UDP Port | 691 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 692 | Global Flags | MPLS Payload size | 693 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 694 | | 695 : Destination IP Address : 696 | | 697 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 698 | | 699 : : 700 : Sub-TLVs : 701 : : 702 | | 703 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 705 Address Type 707 The type and length of the address found in the in the Destination 708 IP Address and Next Hop IP Addresses fields. The values are shared 709 with the Downstream Mapping Address Type Registry. 711 The type codes applicable in this case appear in the table below: 713 Address Family Type Length 714 IPv4 1 4 715 IPv6 3 16 717 Reply mode 719 The reply mode to be sent in the MPLS Echo Request message; the 720 values are as specified in [RFC4379]. 722 Proxy Flags 724 The Proxy Request Initiator sets zero, one or more of these flags 725 to request actions at the Proxy LSR. 727 0x01 Request for FEC Neighbor Address info 729 When set this requests that the proxy LSR supply the 730 Upstream and Downstream neighbor address information in the 731 MPLS proxy ping reply message. This flag is only applicable 732 for the topmost FEC in the FEC stack if the FEC types 733 corresponds with a P2MP or MP2MP LSPs. The Proxy LSR MUST 734 respond as applicable with a Upstream Neighbor Address TLV 735 and Downstream Neighbor Address TLV(s) in the MPLS proxy 736 ping reply message. Upstream Neighbor Address TLV needs be 737 included only if there is an upstream neighbor. Similarly, 738 one Downstream Neighbor Address TLV needs to be included for 739 each Downstream Neighbor for which the LSR learned bindings 740 from. 742 Setting this flag will cause the proxy LSR to cancel sending 743 an Echo request. Information learned with such proxy reply 744 may be used by the proxy initiator to generate subsequent 745 proxy requests. 747 0x02 Request for Downstream Mapping 749 When set this requests that the proxy LSR supply a 750 Downstream Mapping TLV see [RFC4379] in the MPLS proxy ping 751 reply message. It's not valid to have Request for Downstream 752 Detailed Mapping flag set when this flag is set. 754 Setting this flag will cause the proxy LSR to cancel sending 755 an Echo request. Information learned with such proxy reply 756 may be used by the proxy initiator to generate subsequent 757 proxy requests. 759 0x04 Request for Downstream Detailed Mapping 761 When set this requests that the proxy LSR supply a 762 Downstream Detailed Mapping TLV see [RFC6424] in the MPLS 763 proxy ping reply message. It's not valid to have Request for 764 Downstream Mapping flag set when this flag is set. Setting 765 this flag will cause the proxy LSR to cancel sending an Echo 766 request. Information learned with such proxy reply may be 767 used by the proxy initiator to generate subsequent proxy 768 requests. 770 0x08 Explicit DSCP Request 772 When set this requests that the proxy LSR use the supplied 773 "Rqst'd DSCP" byte in the Echo Request message 775 TTL 777 The TTL to be used in the label stack entry corresponding to 778 the topmost FEC in the in the MPLS Echo Request packet. Valid 779 values are in the range [1,255]. A setting of 0 SHOULD be 780 ignored by the Proxy LSR. 782 Requested DSCP 784 This field is valid only if the Explicit DSCP flag is set. If 785 not set, the field MUST be zero on transmission and ignored on 786 receipt. When the flag is set this field contains the DSCP 787 value to be used in the MPLS Echo Request packet IP header. 789 Source UDP Port 791 The source UDP port to be sent in the MPLS Echo Request packet 793 Global Flags 795 The Global Flags to be sent in the MPLS Echo Request message 797 MPLS Payload Size 799 Used to request that the MPLS payload (IP header + UDP header + 800 MPLS Echo Request) be padded using a zero filled Pad TLV so 801 that the IP header, UDP header and MPLS Echo Request total the 802 specified size. Field set to zero means no size request is 803 being made. If the requested size is less than the minimum size 804 required to form the MPLS Echo Request, the request will be 805 treated as a best effort request with the Proxy LSR building 806 the smallest possible packet (i.e. not using a Pad TLV). The IP 807 header DF bit SHOULD be set when this field is non zero. 809 Destination IP Address 810 If the Address Type is IPv4, an address from the range 127/8; 811 If the Address Type is IPv6, an address from the range 812 ::FFFF:7F00:0/104 814 Sub-TLVs 816 A TLV encoded list of sub-TLVs. Currently one is defined. 818 Sub-Type Length Value Field 819 -------- ------ ----------- 820 1 8+ Next Hop 822 5.1.1. Next Hop sub-TLV 824 This sub-TLV is used to describe a particular next hop towards which 825 the Echo Request packet should be sent. If the topmost FEC in the 826 FEC-stack is a multipoint LSP, this sub-TLV may appear multiple 827 times. 829 0 1 2 3 830 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 831 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 832 | Addr Type | MUST be Zero | 833 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 834 | Next Hop IP Address (4 or 16 octets) | 835 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 836 | Next Hop Interface (0, 4 or 16 octets) | 837 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 839 Address Type 841 Type Type of Next Hop Addr Length IF Length 843 1 IPv4 Numbered 4 4 844 2 IPv4 Unnumbered 4 4 845 3 IPv6 Numbered 16 16 846 4 IPv6 Unnumbered 16 4 847 5 IPv4 Protocol Adj 4 0 848 6 IPv6 Protocol Adj 16 0 850 Note: Types 1-4 correspond to the types in the DS Mapping 851 TLV. They are expected to populated with information 852 obtained through a previously returned DS Mapping TLV. 853 Types 5 and 6 are intended to be populated from the local 854 address information obtained from a previously returned 855 Downstream Neighbor Address TLV(s)/Upstream Neighbor 856 Address TLV. 858 Next Hop IP Address 860 A next hop address that the echo request message is to 861 be sent towards 863 Next Hop Interface 865 Identifier of the interface through which the echo request 866 message is to be sent. For Addr Type 5, and 6, the Next Hop 867 interface field isn't used and MUST be of an associated byte 868 length of "0" octets. 870 5.2. Reply-to Address TLV 872 Used to specify the MPLS Echo Request IP source address. This address 873 MUST be IP reachable via the Proxy LSR otherwise it will be rejected. 875 0 1 2 3 876 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 877 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 878 | Address Type | MUST be Zero | 879 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 880 | | 881 : Reply-to Address : 882 | | 883 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 885 Address Type 887 A type code as specified in the table below: 889 Type Type of Address 891 1 IPv4 892 3 IPv6 894 5.3. Upstream Neighbor Address TLV 896 0 1 2 3 897 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 898 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 899 |Upst Addr Type |Local Addr Type| MUST be Zero | 900 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 901 | | 902 : Upstream Address : 903 | | 904 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 905 | | 906 : Local Address : 907 | | 908 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 910 Upst Addr Type; Local Addr Type 912 These two fields determine the type and length of the 913 respective addresses. The codes are specified in the table 914 below: 916 Type Type of Address Length 918 0 No Address Supplied 0 919 1 IPv4 4 920 3 IPv6 16 922 Upstream Address 924 The address of the immediate upstream neighbor for the topmost 925 FEC in the FEC stack. If protocol adjacency exists by which the 926 label for this FEC was exchanged, this address MUST be the 927 address used in that protocol exchange. 929 Local Address 931 The local address used in the protocol adjacency exists by 932 which the label for this FEC was exchanged. 934 5.4. Downstream Neighbor Address TLV 936 0 1 2 3 937 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 938 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 939 |Dnst Addr Type |Local Addr Type| MUST be Zero | 940 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 941 | | 942 : Downstream Address : 943 | | 944 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 945 | | 946 : Local Address : 947 | | 948 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 950 Dnst Addr Type; Local Addr Type 952 These two fields determine the type and length of the 953 respective addresses. The codes are specified in the table 954 below: 956 Type Type of Address Length 958 0 No Address Supplied 0 959 1 IPv4 4 960 3 IPv6 16 962 Downstream Address 964 The address of a immediate downstream neighbor for the topmost 965 FEC in the FEC stack. If protocol adjacency exists by which the 966 label for this FEC was exchanged, this address MUST be the 967 address used in that protocol exchange. 969 Local Address 971 The local address used in the protocol adjacency exists by 972 which the label for this FEC was exchanged. 974 6. Security Considerations 976 The mechanisms described in this document are intended to be used 977 within a Service Provider network and to be initiated only under the 978 authority of that administration. 980 If such a network also carries Internet traffic, or permits IP access 981 from other administrations, MPLS proxy ping message SHOULD be 982 discarded at those points. This can be accomplished by filtering on 983 source address or by filtering all MPLS ping messages on UDP port. 985 Any node which acts as a proxy node SHOULD validate requests against 986 a set of valid source addresses. An implementation MUST provide such 987 filtering capabilities. 989 MPLS proxy ping request messages are IP addressed directly to the 990 Proxy node. If a node which receives an MPLS proxy ping message via 991 IP or Label TTL expiration, it MUST NOT be acted upon. 993 MPLS proxy ping request messages are IP addressed directly to the 994 Proxy node. If a MPLS Proxy ping request IP destination address is a 995 Martian Address, it MUST NOT be acted upon. 997 if a MPLS Proxy ping request IP source address is not IP reachable by 998 the Proxy LSR, the Proxy request MUST NOT be acted upon. 1000 MPLS proxy ping requests are limited to making their request via the 1001 specification of a FEC. This ensures that only valid MPLS Echo 1002 Request messages can be created. No label spoofing attacks are 1003 possible. 1005 7. Acknowledgements 1007 The authors would like to thank Nobo Akiya for his detailed review 1008 and insightful comments. 1010 8. IANA Considerations 1012 This document makes the following assignments (pending IANA action) 1014 LSP Ping Message Types 1016 Type Value Field 1017 ---- ----------- 1018 TBA-1 MPLS proxy ping request 1019 TBA-2 MPLS proxy ping reply 1021 TLVs and Sub-TLVs 1023 Type Sub-Type Value Field 1024 ---- -------- ----------- 1025 TBA-3 Proxy Echo Parameters 1026 1 Next Hop 1027 TBA-4 Reply-to Address 1028 TBA-5 Upstream Neighbor Address 1029 TBA-6 Downstream Neighbor Address 1031 Return Code [pending IANA assignment] 1033 Value Meaning 1034 ----- ------- 1035 TBA-7 Proxy ping not authorized. 1036 TBA-8 Proxy ping parameters need to be modified. 1037 TBA-9 MPLS Echo Request Could not be sent. 1038 TBA-10 Replying router has FEC mapping for topmost FEC. 1040 Downstream Address Mapping Registry [pending IANA assignment] 1042 Value Meaning 1043 ----- ------- 1044 TBA-11 IPv4 Protocol Adj 1045 TBA-12 IPv6 Protocol Adj 1047 9. References 1049 9.1. Normative References 1051 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1052 Requirement Levels", BCP 14, RFC 2119, March 1997. 1054 [RFC4379] Kompella, K. and G. Swallow, "Detecting Multi-Protocol 1055 Label Switched (MPLS) Data Plane Failures", RFC 4379, 1056 February 2006. 1058 [RFC6424] Bahadur, N., Kompella, K., and G. Swallow, "Mechanism for 1059 Performing Label Switched Path Ping (LSP Ping) over MPLS 1060 Tunnels", RFC 6424, November 2011. 1062 [RFC6425] Saxena, S., Swallow, G., Ali, Z., Farrel, A., Yasukawa, 1063 S., and T. Nadeau, "Detecting Data-Plane Failures in 1064 Point-to-Multipoint MPLS - Extensions to LSP Ping", RFC 1065 6425, November 2011. 1067 [RFC7110] Chen, M., Cao, W., Ning, S., Jounay, F., and Delord, S., 1068 "Return Path Specified Label Switched Path (LSP) Ping", 1069 RFC 7110, January 2014. 1071 9.2. Informative References 1073 [RFC4875] Aggarwal, R., Papadimitriou, D., and S. Yasukawa, 1074 "Extensions to Resource Reservation Protocol - Traffic 1075 Engineering (RSVP-TE) for Point-to-Multipoint TE Label 1076 Switched Paths (LSPs)", RFC 4875, May 2007. 1078 [RFC6388] Wijnands, IJ., Minei, I., Kompella, K., and B. Thomas, 1079 "Label Distribution Protocol Extensions for Point-to- 1080 Multipoint and Multipoint-to-Multipoint Label Switched 1081 Paths", RFC 6388, November 2011. 1083 Authors' Addresses 1085 George Swallow 1086 Cisco Systems 1087 1414 Massachusetts Ave 1088 Boxborough, MA 01719 1089 USA 1091 Email: swallow@cisco.com 1092 Vanson Lim 1093 Cisco Systems 1094 1414 Massachusetts Avenue 1095 Boxborough, MA 01719 1096 USA 1098 Email: vlim@cisco.com 1100 Sam Aldrin 1101 Huawei Technologies 1102 2330 Central Express Way 1103 Santa Clara, CA 95951 1104 USA 1106 Email: aldrin.ietf@gmail.com