idnits 2.17.1 draft-zjns-mpls-lsp-ping-relay-reply-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- -- The draft header indicates that this document updates RFC4379, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: If the K bit is set to 1, then this sub-TLV SHOULD be kept in Relay Node Address Stack, SHOULD not be deleted in compress process of section 4.2. The K bit may be set by ASBRs which address would be kept in the stack if necessary. (Using the creation date from RFC4379, updated by this document, for RFC5378 checks: 2002-03-27) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 1, 2013) is 4094 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) == Unused Reference: 'RFC4377' is defined on line 576, but no explicit reference was found in the text == Unused Reference: 'RFC4378' is defined on line 581, but no explicit reference was found in the text == Unused Reference: 'RFC6424' is defined on line 589, but no explicit reference was found in the text == Unused Reference: 'RFC6425' is defined on line 593, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 4377 ** Downref: Normative reference to an Informational RFC: RFC 4378 ** Obsolete normative reference: RFC 4379 (Obsoleted by RFC 8029) ** Obsolete normative reference: RFC 6424 (Obsoleted by RFC 8029) Summary: 4 errors (**), 0 flaws (~~), 6 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group R. Zheng, Ed. 3 Internet-Draft L. Jin, Ed. 4 Updates: 4379 (if approved) ZTE 5 Intended status: Standards Track T. Nadeau, Ed. 6 Expires: August 5, 2013 Juniper Networks 7 G. Swallow, Ed. 8 Cisco 9 February 1, 2013 11 Relayed Echo Reply mechanism for LSP Ping 12 draft-zjns-mpls-lsp-ping-relay-reply-01 14 Abstract 16 In some inter-AS and inter-area deployment scenarios for LSP Ping and 17 Traceroute, a replying LSR may not have the available route to the 18 initiator, and the Echo Reply message sent to the initiator would be 19 discarded resulting in false negatives or complete failure of 20 operation of LSP Ping and Traceroute. This document describes 21 extensions to LSP Ping mechanism to enable the replying LSR to have 22 the capability to relay the echo response by a set of routable 23 intermediate nodes to the initiator during the traceroute process in 24 inter-AS and inter-area scenarios. 26 Status of this Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at http://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on August 5, 2013. 43 Copyright Notice 45 Copyright (c) 2013 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 1.1. Conventions Used in This Document . . . . . . . . . . . . 3 62 2. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . 3 63 3. Extensions . . . . . . . . . . . . . . . . . . . . . . . . . . 5 64 3.1. Relayed Echo Reply message . . . . . . . . . . . . . . . . 5 65 3.2. Relay Node Address Stack . . . . . . . . . . . . . . . . . 6 66 3.3. New Return Code . . . . . . . . . . . . . . . . . . . . . 7 67 4. Procedures . . . . . . . . . . . . . . . . . . . . . . . . . . 8 68 4.1. Sending an Echo Request . . . . . . . . . . . . . . . . . 8 69 4.2. Receiving an Echo Request . . . . . . . . . . . . . . . . 8 70 4.3. Sending an Relayed Echo Reply . . . . . . . . . . . . . . 9 71 4.4. Receiving an Relayed Echo Reply . . . . . . . . . . . . . 9 72 4.5. Sending an Echo Reply . . . . . . . . . . . . . . . . . . 10 73 4.6. Receiving an Echo Reply . . . . . . . . . . . . . . . . . 10 74 5. LSP Ping Relayed Echo Reply Example . . . . . . . . . . . . . 10 75 6. Security Considerations . . . . . . . . . . . . . . . . . . . 12 76 7. Backward Compatibility . . . . . . . . . . . . . . . . . . . . 12 77 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 78 8.1. New Message Type . . . . . . . . . . . . . . . . . . . . . 13 79 8.2. New TLV . . . . . . . . . . . . . . . . . . . . . . . . . 13 80 8.3. New Return Code . . . . . . . . . . . . . . . . . . . . . 13 81 9. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 13 82 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 83 10.1. Normative References . . . . . . . . . . . . . . . . . . . 13 84 10.2. Informative References . . . . . . . . . . . . . . . . . . 14 85 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 87 1. Introduction 89 This document describes extensions to the LSP Ping and Traceroute as 90 specified in [RFC4379] that add as a Relayed Echo Reply mechanism 91 that can be used to detect data plane failures in inter-AS and inter- 92 area MPLS LSPs. Prior to this extension, inter-AS functionality of 93 [RFC4379] would fail in most deployment scenarios. A new message 94 referred to as "Relayed Echo Reply message" and a new TLV referred to 95 as "Relay Node Address Stack TLV" are defined in this draft to 96 overcome these deficiencies. 98 1.1. Conventions Used in This Document 100 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 101 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 102 document are to be interpreted as described in [RFC2119]. 104 2. Motivation 106 LSP Ping [RFC4379] defines a mechanism to detect data plane failures 107 and localize faults. In the traceroute mode of LSP Ping procedure, 108 the Echo Request message is send along the data plane between the 109 originating LSR and one of the LSRs along the LSP, but is directed to 110 be punted to the the control plane of each transit LSR. The control 111 plane of the receiving LSR then responds directly to the originator 112 using an Echo Reply massage with proper information are required to 113 send to the initiator at each transit LSR. Each hop along the LSP is 114 progressively probed by increasing the TTL of the Echo Request 115 Message until the terminus of the LSP is reached. Using this 116 mechanism, the LSP data plane is tested, and any resulting faults can 117 be localized. Furthermore, this mechanism allows a network operator 118 to create an accurate view of deployed LSP topology. 120 The original mechanism specifies that The Echo Reply be sent back to 121 the initiator usig a UDP packet containing directed back to the IPv4/ 122 IPv6 address of the originating LSR. This works in adminitrative 123 domains allowing IP address reachability and routing back to the 124 originating LSR. However, in practice, this is often not the case 125 due to intra-provider routing policy, route hiding, network address 126 translation at boundary autonomous system border routers (i.e.: 127 ASBR), etc... In fact, it is almost uniformly the case that in 128 inter-AS scenarios to not allow the distribution or direct routing to 129 the IP addresses of any of the nodes other than the ASBR. 131 Figure 1 demonstrates how initiating a traceroute procedure on an 132 ingress LSR (i.e.: PE1) of an LSP from PE1 to PE2, can be constructed 133 between P nodes within an AS, which are then connected to ASBRs 134 interconnect both ASs. In this case, if private addresses were in 135 use within AS2, a traceroute from PE1 directed to PE2 could fail if 136 the fault exists somewhere between AS2 and PE2 because P2 cannot 137 forward packets back to PE1 given that it is a private address within 138 AS1. In this case, PE1 would detect a path break, as the Echo 139 Request messages would not be responded to; however, localization of 140 the actual fault would not be possible. 142 +-------+ +-------+ +------+ +------+ +------+ +------+ 143 | | | | | | | | | | | | 144 | PE1 +---+ P1 +---+ ASBR1+---+ ASBR2+---+ P2 +---+ PE2 | 145 | | | | | | | | | | | | 146 +-------+ +-------+ +------+ +------+ +------+ +------+ 147 <---------------AS1-------------><---------------AS2------------> 148 <---------------------------- LSP ------------------------------> 150 Figure 1: Simple Inter-AS LSP Configuration 152 A second example that illustrates how [RFC4379] would be insufficient 153 would be the inter-area situation in a Seamless MPLS architecture 154 [ietf-mpls-seamless] as shown below in Figure 2. In the example P 155 nodes the in core network would not have IP reachable route to any of 156 the ANs. When tracing an LSP from AN to remote AN, the LSR1/LSR2 157 node could not make a response to the Echo Request either, like P2 158 node in the inter-AS scenario. 160 +-------+ +-------+ +------+ +------+ 161 | | | | | | | | 162 +--+ AGN11 +---+ AGN21 +---+ ABR1 +---+ LSR1 +--> to AGN 163 / | | /| | | | | | 164 +----+/ +-------+\/ +-------+ +------+ /+------+ 165 | AN | /\ \/ 166 +----+\ +-------+ \+-------+ +------+/\ +------+ 167 \ | | | | | | \| | 168 +--+ AGN12 +---+ AGN22 +---+ ABR2 +---+ LSR2 +--> to AGN 169 | | | | | | | | 170 +-------+ +-------+ +------+ +------+ 171 static route ISIS L1 LDP ISIS L2 LDP 172 <-Access-><--Aggregation Domain--><---------Core---------> 174 Figure 2: Seamless MPLS Architecture 176 This remainder of this document describes extensions to the LSP Ping 177 mechanism to facillitate a response from the replying LSR using a 178 simple mechanism that uses the ASBRs to relay the message back to the 179 initiator. This approach will work because every subsequent AS can 180 and must have a route back to a connected AS. Using a recursive 181 approach, intermediate ASs can relay the message toward each other 182 until the final AS is reached. At this point, the ASBR must have a 183 route to the initiating LSR because it is directly attached to it. 184 This is achieved by augmenting the replying LSR's LSP Ping algorithm 185 to send a response to a relay node (as indicated by the Relay Node 186 Address Stack TLV), and the response would be relayed to the next 187 relay node (i.e.: ASBR), until it reaches the ultimate ASBR. At that 188 point the ASBR should be able to resolve a local route to the 189 initiator. 191 3. Extensions 193 RFC4379 describes the basic MPLS LSP Ping mechanism, which defines 194 two message types. This draft defines a new message, Relayed Echo 195 Reply message. This new message is used to replace Echo Reply 196 message which is sent from the replying LSR to a relay node or from a 197 relay node to another relay node. 199 A new TLV named Relay Node Address Stack TLV is defined in this 200 draft, to carry the IP addresses of the possible relay nodes for the 201 replying LSR. 203 In addition, a new Return Code is defined to notify the initiator 204 that the packet length was exceeded by the Relay Node Address Stack 205 TLV unexpected. 207 It should be noted that this document focuses only on detecting the 208 LSP which is setup using a uniform type of IP address. That is, all 209 hops between the originator and terminus use one address type of 210 address) to address their control planes. This does not preclude 211 nodes that support both IPv6 and IPv4 addresses simultaneously, but 212 the entire path MUST be addressible using only one address family 213 type. Support for mixed IPv4-only and IPv6-only is beyond the scope 214 of this document. 216 3.1. Relayed Echo Reply message 218 The Relayed Echo Reply message is a UDP packet, and the UDP payload 219 has the same format with Echo Request/Reply message. A new message 220 type is requested from IANA. 222 New Message Type: 223 Value Meaning 224 ----- ------- 225 TBD MPLS Relayed Echo Reply 227 The TCP and UDP port number 3503 has been allocated in [RFC4379] by 228 IANA for LSP Ping messages. The Relayed Echo Reply message will use 229 the same port number. 231 3.2. Relay Node Address Stack 233 The Relay Node Address Stack TLV is an optional TLV. It MUST be 234 carried in the Echo Request, Echo Reply and Relayed Echo Reply 235 messages if the echo reply relayed mechanism described in this draft 236 is required. Figure 3 illustrates the TLV format. 238 0 1 2 3 239 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 240 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 241 | Type | Length | 242 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 243 | Initiator Source Port | Number of Relayed Addresses | 244 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 245 | | 246 ~ Stack of Relayed Addresses ~ 247 | | 248 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 250 Figure 3: Relay Node Address Stack TLV 252 - Type: to be assigned by IANA. A suggested value is assigned from 253 32768-49161 as suggested by RFC4379 Section 3. 255 - Length: The Length of the Value field in octets. 257 - Initiator Source Port: The port that the initiator sends the Echo 258 Request message, and also the port that expected to receive the 259 Echo Reply message. 261 - Number of Relayed Addresses: An integer indicating the number of 262 relayed addresses in the stack. 264 - Stack of Relayed Addresses: A list of relay node addresses. 266 The format of each relay node address is as below: 268 0 1 2 3 269 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 270 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 271 | Address Type | Address Length| Reserved |K| 272 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 273 ~ Relayed Address (0, 4, or 16 octects) ~ 274 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 276 Type# Address Type Address Length 277 ---- ------------ ------------ 278 0 Unspecified 0 279 1 IPv4 4 280 2 IPv6 16 282 Reserved: This field is reserved for future use and MUST be set to 283 zero. 285 K bit: 287 If the K bit is set to 1, then this sub-TLV SHOULD be kept in Relay 288 Node Address Stack, SHOULD not be deleted in compress process of 289 section 4.2. The K bit may be set by ASBRs which address would be 290 kept in the stack if necessary. 292 If the K bit is set to 0, then this sub-TLV SHOULD be processed 293 normally according to section 4.2. 295 Relayed Address: This field specifies the node address, either IPv4 296 or IPv6. 298 3.3. New Return Code 300 A new Return Code is used by the replying LSR to notify the initiator 301 that the packet length was exceeded by the Relay Node Address Stack 302 TLV unexpected. 304 New Return Code: 305 Value Meaning 306 ----- ------- 307 TBD Response Packet length was exceeded by the Relay Node 308 Address Stack TLV unexpected 310 4. Procedures 312 4.1. Sending an Echo Request 314 In addition to the procedures described in Section 4.3 of [RFC4379], 315 a Relay Node Address Stack TLV MUST be carried in the Echo Request 316 message for facillitate the relay functionality. 318 When the Echo Request is first sent by initiator supporting these 319 extensions, a Relay Node Address Stack TLV with the initiator address 320 in the stack and its source port MUST be included. 322 For the subsequent Echo Request messages, the initiator would copy 323 the Relay Node Address Stack TLV from the received Echo Reply 324 message. 326 4.2. Receiving an Echo Request 328 In addition to the processes in Section 4.4 of [RFC4379], the 329 procedures of the Relay Node Address Stack TLV are defined here. 331 Upon receiving a Relay Node Address Stack TLV of the Echo Request 332 message, the receiver would check the addresses of the stack in 333 sequence from top to bottom, i.e., the first address in the stack 334 would be first one to be checked, to find out the first public 335 routable IP address. Those address entries behind of the first 336 routable IP address in the address list with K bit set to 0 would be 337 deleted, and the address entry of the replying LSR would be added at 338 the bottom of the stack. Those address entries with K bit set to 1 339 would be kept in the stack. The updated Relay Node Address Stack TLV 340 would be carried in the response message. 342 If the replying LSR wishes to hide its routable address information, 343 the address entry added in the stack would be a blank entry with 344 Address Type set to Unspecified. The blank address entry in the 345 receiving Echo Request would be treated as an unroutable address 346 entry. 348 If the packet length was exceeded by the Relay Node Address Stack TLV 349 unexpectedly, the TLV SHOULD be returned back unchanged in the echo 350 response message. And the new return code would help to notify the 351 initiator of the situation. 353 If the first routable IP address is the first address in the stack, 354 the replying LSR would respond an Echo Reply message to the 355 initiator. 357 If the first routable IP address is of an intermediate node, other 358 than the first address in the stack, the replying LSR would send an 359 Relayed Echo Reply instead of an Echo Reply in response. 361 An LSR not recognize the Relay Node Address Stack TLV, SHOULD ignore 362 it according to section 3 of RFC4379. 364 4.3. Sending an Relayed Echo Reply 366 The Relayed Echo Reply is sent in two cases: 368 1. When the replying LSR received an Echo Request with the initiator 369 IP address in the Relay Node Address Stack TLV is IP unroutable, the 370 replying LSR would send an Relayed Echo Reply message to the first 371 routable intermediate node. The processing of Relayed Echo Reply is 372 the same with the procedure of the Echo Reply described in Section 373 4.5 of RFC4379, except the destination IP address and the destination 374 UDP port of the message part. The destination IP address of the 375 Relayed Echo Reply is set to the first routable IP address from the 376 Relay Node Address Stack TLV, and the destination UDP port is set to 377 3503. 379 2. When the intermediate relay node received an Relayed Echo Reply 380 with the initiator IP address in the Relay Node Address Stack TLV is 381 IP unroutable, the intermediate relay node would send the Relayed 382 Echo Reply to the next relay node with the content of the UDP packet 383 unchanged. The destination IP address of the Relayed Echo Reply is 384 set to the first routable IP address from the Relay Node Address 385 Stack TLV. Both the source and destination UDP port should be 3503. 387 4.4. Receiving an Relayed Echo Reply 389 Upon receiving an Relayed Echo Reply message with its address as the 390 destination address in the IP header, the relay node should check the 391 address items in Relay Node Address Stack TLV in sequence and find 392 the first routable node address. 394 If the first routable address is the top one of the address list, 395 i.e., the initiator address, the relay node should send an Echo Reply 396 message to the initiator containing the same payload with the Relayed 397 Echo Reply message received. 399 If the first routable address is not the top one of the address list, 400 i.e., another intermediate relay node, the relay node should send an 401 Relayed Echo Reply message to this relay node with the payload 402 unchanged. 404 4.5. Sending an Echo Reply 406 The Echo Reply is sent in two cases: 408 1. When the replying LSR received an Echo Request with the initiator 409 IP address in the Relay Node Address Stack TLV is IP routable, the 410 replying LSR would send an Echo Reply to the initiator. In addition 411 to the procedure of the Echo Reply described in Section 4.5 of 412 RFC4379, the Relay Node Address Stack TLV would be carried in the 413 Echo Reply. 415 2. When the intermediate relay node LSR received an Relayed Echo 416 Reply with the initiator IP address in the Relay Node Address Stack 417 TLV is IP routable, the intermediate relay node would send the Echo 418 Reply to the initiator with the payload no changes other than the 419 Message Type field. The destination IP address of the Echo Reply is 420 set to the initiator IP address, and the destination UDP port would 421 be copied from the Initiator Source Port field of the Relay Node 422 Address Stack TLV. The source UDP port should be 3503. 424 4.6. Receiving an Echo Reply 426 In addition to the processes in Section 4.6 of RFC4379, the initiator 427 would copy the Relay Node Address Stack TLV received in the Echo 428 Reply to the next Echo Request. 430 5. LSP Ping Relayed Echo Reply Example 432 Considering the inter-AS scenario in Figure 4 below. 434 +-------+ +-------+ +------+ +------+ +------+ +------+ 435 | | | | | | | | | | | | 436 | PE1 +---+ P1 +---+ ASBR1+---+ ASBR2+---+ P2 +---+ PE2 | 437 | | | | | | | | | | | | 438 +-------+ +-------+ +------+ +------+ +------+ +------+ 439 <---------------AS1-------------><---------------AS2------------> 440 <--------------------------- LSP -------------------------------> 442 Figure 4: Example Inter-AS LSP 444 In the example, an LSP has been created between PE1 to PE2. When 445 performing LSP traceroute on the LSP the first Echo Request sent by 446 PE1 with outter-most label TTL=1, contains the Relay Node Address 447 Stack TLV with the only address of PE1. 449 After processed by P1, P1's address will be added in the Relay Node 450 Address Stack TLV address list following PE1's address in the Echo 451 Reply. 453 PE1 copies the Relay Node Address Stack TLV into the next Echo 454 Request when receiving the Echo Reply. 456 Upon receiving the Echo Request, ASBR1 checks the address list in the 457 Relay Node Address Stack TLV in sequence, and finds out that PE1 458 address is routable. Then deletes P1 address, and adds its own 459 address following PE1 address. As a result, there would be PE1 460 address followed by ASBR1 address in the Relay Node Address Stack TLV 461 of the Echo Reply sent by ASBR1. 463 PE1 then sends an Echo Request with outter-most label TTL=3, 464 containing the Relay Node Address Stack TLV copied from the received 465 Echo Reply message. Upon receiving the Echo Request message, ASBR2 466 checks the address list in the Relay Node Address Stack TLV in 467 sequence, and finds out that PE1 address is IP route unreachable, and 468 ASBR1 address is the first routable one in the Relay Node Address 469 Stack TLV. ASBR2 adds its address as the last address item following 470 ASBR1 address in Relay Node Address Stack TLV, sets ASBR1 address as 471 the destination address of the Relayed Echo Reply, and sends the 472 Relayed Echo Reply to ASBR1. 474 Upon receiving the Relayed Echo Reply from ASBR2, ASBR1 checks the 475 address list in the Relay Node Address Stack TLV in sequence, and 476 finds out that PE1 address is first routable one in the address list. 477 Then ASBR1 send an Echo Reply to PE1 with the payload of received 478 Relayed Echo Reply no changes other than the Message Type field. 480 For the Echo Request with outter-most label TTL=4, P2 checks the 481 address list in the Relay Node Address Stack TLV in sequence, and 482 finds out that both PE1 and ASBR1 addresses are not IP routable, and 483 ASBR2 address is the first routable address. And P2 would send an 484 Relayed Echo Reply to ASBR2 with the Relay Node Address Stack TLV of 485 four addresses, PE1, ASBR1, ASBR2 and P2 address in sequence. 487 Then according to the process described in section 4.4, ASBR2 would 488 send the Relayed Echo Reply to ASBR1. Upon receiving the Relayed 489 Echo Reply, ASBR1 would send an Echo Reply to PE1 as PE1 address is 490 routable. And as relayed by ASBR2 and ASBR1, the echo response would 491 finally be sent to the initiator PE1. 493 For the Echo Request with outter-most label TTL=5, the echo response 494 would relayed to PE1 by ASBR2 and ASBR1, similar to the case of 495 TTL=4. 497 The Echo Reply from the replying node which has no reachable route to 498 the initiator is finally transmitted to the initiator by multiple 499 relay nodes. 501 6. Security Considerations 503 The Relayed Echo Reply mechanism for LSP Ping creates an increased 504 risk of DoS by putting the IP address of a target router in the Relay 505 Node Address Stack. These messages then could be used to attack the 506 control plane of an LSR by overwhelming it with these packets. A 507 rate limiter SHOULD be applied to the well-known UDP port on the 508 relay node as suggested in RFC4379. The node which acts as a relay 509 node SHOULD validate the relay reply against a set of valid source 510 addresses and discard packets from untrusted border router addresses. 511 An implementation SHOULD provide such filtering capabilities. 513 If an operator wants to obscure their nodes, it is RECOMMENDED that 514 they they may replace the failed node that originated the Echo Reply 515 with their own address. 517 Other security considerations discussed in [RFC4379], are also 518 applicable to this document. 520 7. Backward Compatibility 522 When one of the nodes along the LSP does not support the mechanism 523 specified in this draft, the node will ignore the Relay Node Address 524 Stack TLV as described in section 4.2. Then the initiator may not 525 receive the Relay Node Address Stack TLV in Echo Reply message from 526 that node. In this case, an indication should be reported to the 527 operator, and the Relay Node Address Stack TLV in the next Echo 528 Request message should be copied from the previous Echo Request, and 529 continue the ping process. If the node described above is located 530 between the initiator and the first relay node, the ping process 531 could continue without interruption. 533 8. IANA Considerations 535 IANA is requested to assign one new Message Type, one new TLV and one 536 new Return Code. 538 8.1. New Message Type 540 New Message Type: 541 Value Meaning 542 ----- ------- 543 TBD MPLS Relayed Echo Reply 545 8.2. New TLV 547 New TLV: Routable Relay Node Address TLV 548 Type Meaning 549 ---- -------- 550 TBD Relay Node Address Stack TLV 552 A suggested value is assigned from 32768-49161 as suggested by 553 RFC4379 Section 3. 555 8.3. New Return Code 557 New Return Code: 558 Value Meaning 559 ----- ------- 560 TBD Response Packet length was exceeded by the Relay Node 561 Address Stack TLV unexpected 563 9. Acknowledgement 565 The authors would like to thank Carlos Pignataro, Xinwen Jiao, Manuel 566 Paul, Loa Andersson, Wim Henderickx, Mach Chen and Thomas Morin for 567 their valuable comments and suggestions. 569 10. References 571 10.1. Normative References 573 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 574 Requirement Levels", BCP 14, RFC 2119, March 1997. 576 [RFC4377] Nadeau, T., Morrow, M., Swallow, G., Allan, D., and S. 577 Matsushima, "Operations and Management (OAM) Requirements 578 for Multi-Protocol Label Switched (MPLS) Networks", 579 RFC 4377, February 2006. 581 [RFC4378] Allan, D. and T. Nadeau, "A Framework for Multi-Protocol 582 Label Switching (MPLS) Operations and Management (OAM)", 583 RFC 4378, February 2006. 585 [RFC4379] Kompella, K. and G. Swallow, "Detecting Multi-Protocol 586 Label Switched (MPLS) Data Plane Failures", RFC 4379, 587 February 2006. 589 [RFC6424] Bahadur, N., Kompella, K., and G. Swallow, "Mechanism for 590 Performing Label Switched Path Ping (LSP Ping) over MPLS 591 Tunnels", RFC 6424, November 2011. 593 [RFC6425] Saxena, S., Swallow, G., Ali, Z., Farrel, A., Yasukawa, 594 S., and T. Nadeau, "Detecting Data-Plane Failures in 595 Point-to-Multipoint MPLS - Extensions to LSP Ping", 596 RFC 6425, November 2011. 598 10.2. Informative References 600 [ietf-mpls-seamless] 601 Leymann, N., Decraene, B., Filsfils, C., Konstantynowicz, 602 M. and D. Steinberg, "Seamless MPLS Architecture", 603 draft-ietf-mpls-seamless-mpls-02 , October 2012. 605 Authors' Addresses 607 Ryan Zheng (editor) 608 ZTE 609 50, Ruanjian Avenue 610 Nanjing, 210012, China 612 Email: zheng.zhi@zte.com.cn 614 Lizhong Jin (editor) 615 ZTE 616 889, Bibo Road 617 Shanghai, 201203, China 619 Email: lizho.jin@gmail.com 621 Thomas Nadeau (editor) 622 Juniper Networks 623 Westford, MA 625 Email: tnadeau@juniper.net 626 George Swallow (editor) 627 Cisco 628 300 Beaver Brook Road 629 Boxborough , MASSACHUSETTS 01719, USA 631 Email: swallow@cisco.com