idnits 2.17.1 draft-ietf-mpls-lsp-ping-relay-reply-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Using 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: Note, the replying LSR SHOULD send a Relayed Echo Reply message to the first relay node found in Relay Node Address Stack TLV that is IP routable. The routable address MUST be located before the source IP address of the received Relayed Echo Reply which must be also in the stack, otherwise the Relayed Echo Reply SHOULD not be sent, so as to avoid potential loop. (Using the creation date from RFC4379, updated by this document, for RFC5378 checks: 2002-03-27) -- The document seems to contain a disclaimer for pre-RFC5378 work, and may have content which was first submitted before 10 November 2008. The disclaimer is necessary when there are original authors that you have been unable to contact, or if some do not wish to grant the BCP78 rights to the IETF Trust. If you are able to get all authors (current and original) to grant those rights, 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 30, 2014) is 3557 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: 'I-D.ietf-mpls-proxy-lsp-ping' is defined on line 621, but no explicit reference was found in the text == Outdated reference: A later version (-05) exists of draft-ietf-mpls-proxy-lsp-ping-02 ** Obsolete normative reference: RFC 4379 (Obsoleted by RFC 8029) Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Luo, Ed. 3 Internet-Draft ZTE 4 Updates: 4379 (if approved) L. Jin, Ed. 5 Intended status: Standards Track 6 Expires: January 31, 2015 T. Nadeau, Ed. 7 Lucidvision 8 G. Swallow, Ed. 9 Cisco 10 July 30, 2014 12 Relayed Echo Reply mechanism for LSP Ping 13 draft-ietf-mpls-lsp-ping-relay-reply-04 15 Abstract 17 In some inter autonomous system (AS) and inter-area deployment 18 scenarios for RFC 4379 "Label Switched Path (LSP) Ping and 19 Traceroute", a replying LSR may not have the available route to the 20 initiator, and the Echo Reply message sent to the initiator would be 21 discarded resulting in false negatives or complete failure of 22 operation of LSP Ping and Traceroute. This document describes 23 extensions to LSP Ping mechanism to enable the replying Label 24 Switching Router (LSR) to have the capability to relay the Echo 25 Response by a set of routable intermediate nodes to the initiator. 26 This document updates RFC 4379. 28 Status of This Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at http://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on January 31, 2015. 45 Copyright Notice 47 Copyright (c) 2014 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 This document may contain material from IETF Documents or IETF 61 Contributions published or made publicly available before November 62 10, 2008. The person(s) controlling the copyright in some of this 63 material may not have granted the IETF Trust the right to allow 64 modifications of such material outside the IETF Standards Process. 65 Without obtaining an adequate license from the person(s) controlling 66 the copyright in such materials, this document may not be modified 67 outside the IETF Standards Process, and derivative works of it may 68 not be created outside the IETF Standards Process, except to format 69 it for publication as an RFC or to translate it into languages other 70 than English. 72 Table of Contents 74 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 75 1.1. Conventions Used in This Document . . . . . . . . . . . . 3 76 2. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 3 77 3. Extensions . . . . . . . . . . . . . . . . . . . . . . . . . 5 78 3.1. Relayed Echo Reply message . . . . . . . . . . . . . . . 5 79 3.2. Relay Node Address Stack . . . . . . . . . . . . . . . . 6 80 3.3. New Return Code . . . . . . . . . . . . . . . . . . . . . 7 81 4. Procedures . . . . . . . . . . . . . . . . . . . . . . . . . 8 82 4.1. Sending an Echo Request . . . . . . . . . . . . . . . . . 8 83 4.2. Receiving an Echo Request . . . . . . . . . . . . . . . . 8 84 4.3. Originating an Relayed Echo Reply . . . . . . . . . . . . 9 85 4.4. Relaying an Relayed Echo Reply . . . . . . . . . . . . . 9 86 4.5. Sending an Echo Reply . . . . . . . . . . . . . . . . . . 10 87 4.6. Receiving an Echo Reply . . . . . . . . . . . . . . . . . 10 88 4.7. Impact to Traceroute . . . . . . . . . . . . . . . . . . 10 89 5. LSP Ping Relayed Echo Reply Example . . . . . . . . . . . . . 10 90 6. Security Considerations . . . . . . . . . . . . . . . . . . . 12 91 7. Backward Compatibility . . . . . . . . . . . . . . . . . . . 12 92 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 93 8.1. New Message Type . . . . . . . . . . . . . . . . . . . . 13 94 8.2. New TLV . . . . . . . . . . . . . . . . . . . . . . . . . 13 95 8.3. New Return Code . . . . . . . . . . . . . . . . . . . . . 13 96 9. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 14 97 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 14 98 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 99 11.1. Normative References . . . . . . . . . . . . . . . . . . 14 100 11.2. Informative References . . . . . . . . . . . . . . . . . 14 101 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 103 1. Introduction 105 This document describes the extensions to the Label Switched Path 106 (LSP) Ping as specified in [RFC4379], by adding a relayed echo reply 107 mechanism which could be used to detect data plane failures for the 108 inter autonomous system (AS) and inter-area LSPs. The extensions are 109 to update the [RFC4379]. Without these extensions, the ping 110 functionality provided by [RFC4379] would fail in many deployed 111 inter-AS scenarios, since the replying LSR in one AS may not have the 112 available route to the initiator in the other AS. The mechanism in 113 this document defines a new message type referred as "Relayed Echo 114 Reply message", and a new TLV referred as "Relay Node Address Stack 115 TLV". 117 1.1. Conventions Used in This Document 119 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 120 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 121 document are to be interpreted as described in [RFC2119]. 123 2. Motivation 125 LSP Ping [RFC4379] defines a mechanism to detect the data plane 126 failures and localize faults. The mechanism specifies that the Echo 127 Reply should be sent back to the initiator using an UDP packet with 128 the IPv4/ IPv6 address of the originating LSR. This works in 129 administrative domains where IP addresses reachability are allowed 130 among LSRs, and every LSR is able to route back to the originating 131 LSR. However, in practice, this is often not the case due to intra- 132 provider routing policy, route hiding, and network address 133 translation at autonomous system border routers (ASBR). In fact, it 134 is almost uniformly the case that in inter-AS scenarios, it is not 135 allowed the distribution or direct routing to the IP addresses of any 136 of the nodes other than the ASBR in another AS. 138 Figure 1 demonstrates a case where one LSP is set up between PE1 and 139 PE2. If private addresses were in use within AS1, a traceroute from 140 PE1 directed to PE2 could fail if the fault exists somewhere between 141 ASBR2 and PE2. Because P2 cannot forward packets back to PE1 given 142 that it is a private address within AS1. In this case, PE1 would 143 detect a path break, as the Echo Reply messages would not be 144 received. Then localization of the actual fault would not be 145 possible. 147 +-------+ +-------+ +------+ +------+ +------+ +------+ 148 | | | | | | | | | | | | 149 | PE1 +---+ P1 +---+ ASBR1+---+ ASBR2+---+ P2 +---+ PE2 | 150 | | | | | | | | | | | | 151 +-------+ +-------+ +------+ +------+ +------+ +------+ 152 <---------------AS1-------------><---------------AS2------------> 153 <---------------------------- LSP ------------------------------> 155 Figure 1: Simple Inter-AS LSP Configuration 157 A second example that illustrates how [RFC4379] would be insufficient 158 would be the inter-area situation in a seamless MPLS architecture 159 [I-D.ietf-mpls-seamless-mpls] as shown below in Figure 2. In this 160 example LSRs in the core network would not have IP reachable route to 161 any of the ANs. When tracing an LSP from one AN to the remote AN, 162 the LSR1/LSR2 node could not make a response to the Echo Request 163 either, like the P2 node in the inter-AS scenario in Figure 1. 165 +-------+ +-------+ +------+ +------+ 166 | | | | | | | | 167 +--+ AGN11 +---+ AGN21 +---+ ABR1 +---+ LSR1 +--> to AGN 168 / | | /| | | | | | 169 +----+/ +-------+\/ +-------+ +------+ /+------+ 170 | AN | /\ \/ 171 +----+\ +-------+ \+-------+ +------+/\ +------+ 172 \ | | | | | | \| | 173 +--+ AGN12 +---+ AGN22 +---+ ABR2 +---+ LSR2 +--> to AGN 174 | | | | | | | | 175 +-------+ +-------+ +------+ +------+ 176 static route ISIS L1 LDP ISIS L2 LDP 177 <-Access-><--Aggregation Domain--><---------Core---------> 179 Figure 2: Seamless MPLS Architecture 181 This document describes extensions to the LSP Ping mechanism to 182 facilitate a response from the replying LSR, by defining a simple 183 mechanism that uses a relay node (e.g, ASBR) to relay the message 184 back to the initiator. Every designated or learned relay node must 185 have an IP route to the next relay node or to the initiator. Using a 186 recursive approach, relay node could relay the message to the next 187 relay node until the initiator is reached. 189 The LSP Ping relay mechanism in this document is defined for unicast 190 case. How to apply the LSP Ping relay mechanism in multicast case is 191 out of the scope. 193 3. Extensions 195 [RFC4379] describes the basic MPLS LSP Ping mechanism, which defines 196 two message types, Echo Request and Echo Reply message. This 197 document defines a new message, Relayed Echo Reply message. This new 198 message is used to replace Echo Reply message which is sent from the 199 replying LSR to a relay node or from a relay node to another relay 200 node. 202 A new TLV named Relay Node Address Stack TLV is defined in this 203 document, to carry the IP addresses of the possible relay nodes for 204 the replying LSR. 206 In addition, a new Return Code is defined to notify the initiator 207 that the packet length is exceeded unexpected by the Relay Node 208 Address Stack TLV. 210 It should be noted that this document focuses only on detecting the 211 LSP which is set up using a uniform IP address family type. That is, 212 all hops between the source and destination node use the same address 213 family type for their LSP ping control planes. This does not 214 preclude nodes that support both IPv6 and IPv4 addresses 215 simultaneously, but the entire path must be addressable using only 216 one address family type. Supporting for mixed IPv4-only and 217 IPv6-only is beyond the scope of this document. 219 3.1. Relayed Echo Reply message 221 The Relayed Echo Reply message is a UDP packet, and the UDP payload 222 has the same format with Echo Request/Reply message. A new message 223 type is requested from IANA. 225 New Message Type: 226 Value Meaning 227 ----- ------- 228 TBD MPLS Relayed Echo Reply 230 The use of TCP and UDP port number 3503 is described in [RFC4379] and 231 has been allocated by IANA for LSP Ping messages. The Relayed Echo 232 Reply message will use the same port number. 234 3.2. Relay Node Address Stack 236 The Relay Node Address Stack TLV is an optional TLV. It MUST be 237 carried in the Echo Request, Echo Reply and Relayed Echo Reply 238 messages if the echo reply relayed mechanism described in this 239 document is required. Figure 3 illustrates the TLV format. 241 0 1 2 3 242 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 243 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 244 | Type | Length | 245 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 246 | Initiator Source Port | Number of Relayed Addresses | 247 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 248 | | 249 ~ Stack of Relayed Addresses ~ 250 | | 251 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 253 Figure 3: Relay Node Address Stack TLV 255 - Type: to be assigned by IANA. A value should be assigned from 256 32768-49161 as suggested by [RFC4379] Section 3. 258 - Length: the length of the value field in octets. 260 - Initiator Source Port: the source UDP port that the initiator 261 sends the Echo Request message, and also the port that is expected 262 to receive the Echo Reply message. 264 - Number of Relayed Addresses: an integer indicating the number of 265 relayed addresses in the stack. 267 - Stack of Relayed Addresses: a list of relay node addresses. 269 The format of each relay node address is as below: 271 0 1 2 3 272 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 273 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 274 | Address Type | Address Length| Reserved |K| 275 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 276 ~ Relayed Address (0, 4, or 16 octects) ~ 277 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 279 Type# Address Type Address Length 280 ---- ------------ ------------ 281 0 Unspecified 0 282 1 IPv4 4 283 2 IPv6 16 285 Reserved: This field is reserved and MUST be set to zero. 287 K bit: if the K bit is set to 1, then this sub-TLV MUST be kept in 288 Relay Node Address Stack during TLV compress process described in 289 section 4.2. The entry with Unspecified Address Type SHOULD NOT set 290 K bit. 292 Having the K bit set on the relay node address entry causes that 293 entry to be preserved in the Relay Node Address Stack TLV for the 294 entire traceroute operation. A responder node MAY set the K bit to 295 ensure its relay node address entry remains as one of the relay nodes 296 in the Relay Node Address Stack TLV. Some nodes could be configured 297 to always set the K bit, or the module handling MPLS echo requests 298 could discover its K bit use through topology awareness. How a node 299 determines to set the K bit is outside the scope of this document. 301 Relayed Address: this field specifies the node address, either IPv4 302 or IPv6. 304 3.3. New Return Code 306 A new Return Code is used by the replying LSR to notify the initiator 307 that the packet length is exceeded unexpected by the Relay Node 308 Address Stack TLV. 310 New Return Code: 311 Value Meaning 312 ----- ------- 313 TBD Response Packet length was exceeded by the Relay Node 314 Address Stack TLV unexpected 316 4. Procedures 318 4.1. Sending an Echo Request 320 In addition to the procedures described in section 4.3 of [RFC4379], 321 a Relay Node Address Stack TLV MUST be carried in the Echo Request 322 message to facilitate the relay functionality. 324 When the Echo Request is first sent by the initiator, a Relay Node 325 Address Stack TLV with the initiator address in the stack and its 326 source UDP port MUST be included. That will ensure that the first 327 relay node address in the stack will always be the initiator address. 329 For the subsequent Echo Request messages, the initiator would copy 330 the Relay Node Address Stack TLV from the received Echo Reply 331 message. 333 4.2. Receiving an Echo Request 335 In addition to the processes in section 4.4 of [RFC4379], the 336 procedures of the Relay Node Address Stack TLV are defined here. 338 Upon receiving a Relay Node Address Stack TLV of the Echo Request 339 message, the receiver MUST check the addresses of the stack in 340 sequence from top to bottom (the first address in the stack will be 341 the first one to be checked), to find out the first public routable 342 IP address. Those address entries behind of the first routable IP 343 address in the address list with K bit set to 0 MUST be deleted, and 344 the address entry of the replying LSR MUST be added at the bottom of 345 the stack. The address entry added by the replying LSR MUST be same 346 as the source IP address of Relay Echo Reply (section 4.3) or Echo 347 Reply message (section 4.5) being sent. Those address entries with K 348 bit set to 1 MUST be kept in the stack. The updated Relay Node 349 Address Stack TLV MUST be carried in the response message. 351 If the replying LSR is configured to hide its routable address 352 information, the address entry added in the stack SHOULD be a blank 353 entry with Address Type set to unspecified. The blank address entry 354 in the receiving Echo Request SHOULD be treated as an unroutable 355 address entry. 357 If the packet length was exceeded unexpectedly by the Relay Node 358 Address Stack TLV, the TLV SHOULD be returned back unchanged in the 359 Echo Reply message. And the new return code in section 3.3 SHOULD be 360 used to notify the initiator of the situation. 362 If the first routable IP address is the first address in the stack, 363 the replying LSR SHOULD respond an Echo Reply message to the 364 initiator. 366 If the first routable IP address is an intermediate node, other than 367 the first address in the stack, the replying LSR SHOULD send a 368 Relayed Echo Reply instead of an Echo Reply as a response. 370 An LSR not recognize the Relay Node Address Stack TLV, SHOULD ignore 371 it according to section 3 of [RFC4379]. 373 4.3. Originating an Relayed Echo Reply 375 When the replying LSR receives an Echo Request with the first IP 376 address in the Relay Node Address Stack TLV is IP unroutable, the 377 replying LSR SHOULD send a Relayed Echo Reply message to the first 378 routable intermediate node. The processing of Relayed Echo Reply is 379 the same with the procedure of the Echo Reply described in 380 Section 4.5 of [RFC4379], except the destination IP address and the 381 destination UDP port. The destination IP address of the Relayed Echo 382 Reply is set to the first routable IP address from the Relay Node 383 Address Stack TLV, and both the source and destination UDP port is 384 set to 3503. 386 4.4. Relaying an Relayed Echo Reply 388 Upon receiving an Relayed Echo Reply message with its own address as 389 the destination address in the IP header, the relay node SHOULD check 390 the address items in Relay Node Address Stack TLV in sequence from 391 top to down, and find the first routable node address. 393 If the first routable address is the top one of the address list, 394 e.g, the initiator address, the relay node SHOULD send an Echo Reply 395 message to the initiator containing the same payload with the Relayed 396 Echo Reply message received. See section 4.5 for detail. 398 If the first routable address is not the top one of the address list, 399 e.g, another intermediate relay node, the relay node SHOULD send an 400 Relayed Echo Reply message to this relay node with the payload 401 unchanged. The TTL of the Relayed Echo Reply SHOULD be copied from 402 the received Relay Echo Reply and decremented by 1. 404 Note, the replying LSR SHOULD send a Relayed Echo Reply message to 405 the first relay node found in Relay Node Address Stack TLV that is IP 406 routable. The routable address MUST be located before the source IP 407 address of the received Relayed Echo Reply which must be also in the 408 stack, otherwise the Relayed Echo Reply SHOULD not be sent, so as to 409 avoid potential loop. 411 4.5. Sending an Echo Reply 413 The Echo Reply is sent in two cases: 415 1. When the replying LSR receives an Echo Request with the first IP 416 address in the Relay Node Address Stack TLV IP routable, the replying 417 LSR would send an Echo Reply to the initiator. In addition to the 418 procedure of the Echo Reply described in Section 4.5 of [RFC4379], 419 the Relay Node Address Stack TLV would be carried in the Echo Reply. 421 2. When the intermediate relay node receives a Relayed Echo Reply 422 with the first IP address in the Relay Node Address Stack TLV IP 423 routable, the intermediate relay node would send the Echo Reply to 424 the initiator with the UDP payload unchanged other than the Message 425 Type field (change from type of Relayed Echo Reply to Echo Reply). 426 The destination IP address of the Echo Reply is set to the first IP 427 address in the stack, and the destination UDP port would be copied 428 from the Initiator Source Port field of the Relay Node Address Stack 429 TLV. The source UDP port should be 3503. The TTL of the Echo Reply 430 SHOULD be copied from the received Relay Echo Reply and decremented 431 by 1. 433 4.6. Receiving an Echo Reply 435 In addition to the processes in Section 4.6 of [RFC4379], the 436 initiator would copy the Relay Node Address Stack TLV received in the 437 Echo Reply to the next Echo Request. 439 4.7. Impact to Traceroute 441 Source IP address in Echo Reply and Relay Echo Reply are to be of the 442 address of the node sending those packets, not the original 443 responding node. Then the traceroute address output module will 444 print the source IP address as below: 446 if (Relay Node Address Stack TLV exists) { 447 Print the last address in the stack; 448 } else { 449 Print the source IP address of Echo Reply message; 450 } 452 5. LSP Ping Relayed Echo Reply Example 454 Considering the inter-AS scenario in Figure 4 below. 456 +-------+ +-------+ +------+ +------+ +------+ +------+ 457 | | | | | | | | | | | | 458 | PE1 +---+ P1 +---+ ASBR1+---+ ASBR2+---+ P2 +---+ PE2 | 459 | | | | | | | | | | | | 460 +-------+ +-------+ +------+ +------+ +------+ +------+ 461 <---------------AS1-------------><---------------AS2------------> 462 <--------------------------- LSP -------------------------------> 464 Figure 4: Example Inter-AS LSP 466 In the example, an LSP has been created between PE1 to PE2. When 467 performing LSP traceroute on the LSP, the first Echo Request sent by 468 PE1 with outer-most label TTL=1, contains the Relay Node Address 469 Stack TLV with PE1's address. 471 After processed by P1, P1's address will be added in the Relay Node 472 Address Stack TLV address list following PE1's address in the Echo 473 Reply. 475 PE1 copies the Relay Node Address Stack TLV into the next Echo 476 Request when receiving the Echo Reply. 478 Upon receiving the Echo Request, ASBR1 checks the address list in the 479 Relay Node Address Stack TLV in sequence, and finds out that PE1's 480 address is routable. Then deletes P1's address, and adds its own 481 address following PE1 address. As a result, there would be PE1's 482 address followed by ASBR1's address in the Relay Node Address Stack 483 TLV of the Echo Reply sent by ASBR1. 485 PE1 then sends an Echo Request with outer-most label TTL=3, 486 containing the Relay Node Address Stack TLV copied from the received 487 Echo Reply message. Upon receiving the Echo Request message, ASBR2 488 checks the address list in the Relay Node Address Stack TLV in 489 sequence, and finds out that PE1's address is IP route unreachable, 490 and ASBR1's address is the first routable one in the Relay Node 491 Address Stack TLV. ASBR2 adds its address as the last address item 492 following ASBR1's address in Relay Node Address Stack TLV, sets 493 ASBR1's address as the destination address of the Relayed Echo Reply, 494 and sends the Relayed Echo Reply to ASBR1. 496 Upon receiving the Relayed Echo Reply from ASBR2, ASBR1 checks the 497 address list in the Relay Node Address Stack TLV in sequence, and 498 finds out that PE1's address is first routable one in the address 499 list. Then ASBR1 sends an Echo Reply to PE1 with the payload of the 500 received Relayed Echo Reply no changes other than the Message Type 501 field. 503 For the Echo Request with outer-most label TTL=4, P2 checks the 504 address list in the Relay Node Address Stack TLV in sequence, and 505 finds out that both PE1's and ASBR1's addresses are not IP routable, 506 and ASBR2's address is the first routable address. Then P2 sends an 507 Relayed Echo Reply to ASBR2 with the Relay Node Address Stack TLV 508 containing four addresses, PE1's, ASBR1's, ASBR2's and P2's address 509 in sequence. 511 Then according to the process described in section 4.4, ASBR2 sends 512 the Relayed Echo Reply to ASBR1. Upon receiving the Relayed Echo 513 Reply, ASBR1 sends an Echo Reply to PE1 which is routable. And as 514 relayed by ASBR2 and ASBR1, the Echo Reply would finally be sent to 515 the initiator PE1. 517 For the Echo Request with outer-most label TTL=5, the Echo Reply 518 would relayed to PE1 by ASBR2 and ASBR1, similar to the case of 519 TTL=4. 521 The Echo Reply from the replying node which has no IP reachable route 522 to the initiator is finally transmitted to the initiator by multiple 523 relay nodes. 525 6. Security Considerations 527 The Relayed Echo Reply mechanism for LSP Ping creates an increased 528 risk of DoS by putting the IP address of a target router in the Relay 529 Node Address Stack. These messages then could be used to attack the 530 control plane of an LSR by overwhelming it with these packets. A 531 rate limiter SHOULD be applied to the well-known UDP port on the 532 relay node as suggested in [RFC4379]. The node which acts as a relay 533 node SHOULD validate the relay reply against a set of valid source 534 addresses and discard packets from untrusted border router addresses. 535 An implementation SHOULD provide such filtering capabilities. 537 If an operator wants to obscure their nodes, it is RECOMMENDED that 538 they may replace the replying node address that originated the Echo 539 Reply with blank address in Relay Node Address Stack TLV. 541 Other security considerations discussed in [RFC4379], are also 542 applicable to this document. 544 7. Backward Compatibility 546 When one of the nodes along the LSP does not support the mechanism 547 specified in this document, the node will ignore the Relay Node 548 Address Stack TLV as described in section 4.2. Then the initiator 549 may not receive the Relay Node Address Stack TLV in Echo Reply 550 message from that node. In this case, an indication should be 551 reported to the operator, and the Relay Node Address Stack TLV in the 552 next Echo Request message should be copied from the previous Echo 553 Request, and continue the ping process. If the node described above 554 is located between the initiator and the first relay node, the ping 555 process could continue without interruption. 557 8. IANA Considerations 559 IANA is requested to assign one new Message Type, one new TLV and one 560 new Return Code. 562 8.1. New Message Type 564 This document requires allocation of one new message type from 565 "Multi-Protocol Label Switching (MPLS) Label Switched Paths (LSPs) 566 Ping Parameters" registry, the "Message Type" registry: 568 Value Meaning 569 ----- ------- 570 TBD MPLS Relayed Echo Reply 572 The value should be assigned from the "Standards Action" range 573 (0-191), and using the lowest free value within this range. 575 8.2. New TLV 577 This document requires allocation of one new TLV from "Multi-Protocol 578 Label Switching (MPLS) Label Switched Paths (LSPs) Ping Parameters" 579 registry, the "TLVs" registry: 581 Type Meaning 582 ---- -------- 583 TBD Relay Node Address Stack TLV 585 A suggested value should be assigned from "Standards Action" range 586 (32768-49161) as suggested by [RFC4379] Section 3, using the first 587 free value within this range. 589 8.3. New Return Code 591 This document requires allocation of one new return code from "Multi- 592 Protocol Label Switching (MPLS) Label Switched Paths (LSPs) Ping 593 Parameters" registry, the "Return Codes" registry: 595 Value Meaning 596 ----- ------- 597 TBD Response Packet length was exceeded unexpected by the Relay 598 Node Address Stack TLV unexpected 600 The value should be assigned from the "Standards Action" range 601 (0-191), and using the lowest free value within this range. 603 9. Acknowledgement 605 The authors would like to thank Carlos Pignataro, Xinwen Jiao, Manuel 606 Paul, Loa Andersson, Wim Henderickx, Mach Chen, Thomas Morin, Gregory 607 Mirsky, and Nobo Akiya for their valuable comments and suggestions. 609 10. Contributors 611 Ryan Zheng 612 JSPTPD 613 371, Zhongshan South Road 614 Nanjing, 210006, China 615 Email: ryan.zhi.zheng@gmail.com 617 11. References 619 11.1. Normative References 621 [I-D.ietf-mpls-proxy-lsp-ping] 622 Swallow, G., Lim, V., and S. Aldrin, "Proxy MPLS Echo 623 Request", draft-ietf-mpls-proxy-lsp-ping-02 (work in 624 progress), July 2014. 626 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 627 Requirement Levels", BCP 14, RFC 2119, March 1997. 629 [RFC4379] Kompella, K. and G. Swallow, "Detecting Multi-Protocol 630 Label Switched (MPLS) Data Plane Failures", RFC 4379, 631 February 2006. 633 11.2. Informative References 635 [I-D.ietf-mpls-seamless-mpls] 636 Leymann, N., Decraene, B., Filsfils, C., Konstantynowicz, 637 M., and D. Steinberg, "Seamless MPLS Architecture", draft- 638 ietf-mpls-seamless-mpls-07 (work in progress), June 2014. 640 Authors' Addresses 642 Jian Luo (editor) 643 ZTE 644 50, Ruanjian Avenue 645 Nanjing, 210012, China 647 Email: luo.jian@zte.com.cn 649 Lizhong Jin (editor) 650 Shanghai, China 652 Email: lizho.jin@gmail.com 654 Thomas Nadeau (editor) 655 Lucidvision 657 Email: tnadeau@lucidvision.com 659 George Swallow (editor) 660 Cisco 661 300 Beaver Brook Road 662 Boxborough , MASSACHUSETTS 01719, USA 664 Email: swallow@cisco.com