idnits 2.17.1 draft-akiya-mpls-lsp-ping-reply-mode-simple-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (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 (May 20, 2014) is 3628 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 4379 (Obsoleted by RFC 8029) == Outdated reference: A later version (-05) exists of draft-ietf-mpls-proxy-lsp-ping-01 Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force N. Akiya 3 Internet-Draft G. Swallow 4 Updates: 4379 (if approved) C. Pignataro 5 Intended status: Standards Track Cisco Systems 6 Expires: November 21, 2014 L. Andersson 7 M. Chen 8 Huawei 9 May 20, 2014 11 Label Switched Path (LSP) Ping/Traceroute Reply Mode Simplification 12 draft-akiya-mpls-lsp-ping-reply-mode-simple-02 14 Abstract 16 The Multiprotocol Label Switching (MPLS) Label Switched Path (LSP) 17 Ping and Traceroute use the Reply Mode field to signal the method to 18 be used in the MPLS echo reply. This document adds one value to the 19 Reply Mode field to indicate reverse LSP. This document also adds an 20 optional TLV which can carry ordered list of Reply Mode values. 22 This document updates RFC4379. 24 Requirements Language 26 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 27 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 28 document are to be interpreted as described in RFC 2119 [RFC2119]. 30 Status of This Memo 32 This Internet-Draft is submitted in full conformance with the 33 provisions of BCP 78 and BCP 79. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF). Note that other groups may also distribute 37 working documents as Internet-Drafts. The list of current Internet- 38 Drafts is at http://datatracker.ietf.org/drafts/current/. 40 Internet-Drafts are draft documents valid for a maximum of six months 41 and may be updated, replaced, or obsoleted by other documents at any 42 time. It is inappropriate to use Internet-Drafts as reference 43 material or to cite them other than as "work in progress." 45 This Internet-Draft will expire on November 21, 2014. 47 Copyright Notice 49 Copyright (c) 2014 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents 54 (http://trustee.ietf.org/license-info) in effect on the date of 55 publication of this document. Please review these documents 56 carefully, as they describe your rights and restrictions with respect 57 to this document. Code Components extracted from this document must 58 include Simplified BSD License text as described in Section 4.e of 59 the Trust Legal Provisions and are provided without warranty as 60 described in the Simplified BSD License. 62 Table of Contents 64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 65 2. Problem Statements . . . . . . . . . . . . . . . . . . . . . 3 66 3. Solution . . . . . . . . . . . . . . . . . . . . . . . . . . 4 67 3.1. Reply via reverse LSP . . . . . . . . . . . . . . . . . . 4 68 3.2. Reply Mode Order TLV . . . . . . . . . . . . . . . . . . 5 69 4. Relations to Other LSP Ping/Trace Features . . . . . . . . . 6 70 4.1. Reply Path TLV . . . . . . . . . . . . . . . . . . . . . 6 71 4.2. Proxy LSP Ping . . . . . . . . . . . . . . . . . . . . . 6 72 5. Security Considerations . . . . . . . . . . . . . . . . . . . 7 73 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 74 6.1. New Reply Mode . . . . . . . . . . . . . . . . . . . . . 7 75 6.2. New Reply Mode Order TLV . . . . . . . . . . . . . . . . 7 76 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 77 8. Contributing Authors . . . . . . . . . . . . . . . . . . . . 8 78 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 79 9.1. Normative References . . . . . . . . . . . . . . . . . . 8 80 9.2. Informative References . . . . . . . . . . . . . . . . . 8 81 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 83 1. Introduction 85 The MPLS LSP Ping, described in [RFC4379], allows an initiator to 86 encode instructions (Reply Mode) on how a responder should send the 87 response back to the initiator. [RFC7110] also allows the initiator 88 to encode a TLV (Reply Path TLV) which can instruct the responder to 89 use specific LSP to send the response back to the initiator. Both 90 approaches are powerful as they provide the ability for the initiator 91 to control the return path. 93 However, it is becoming increasingly difficult for an initiator to 94 select a valid return path to encode in the MPLS LSP echo request 95 packets. If the initiator does not select a valid return path, the 96 MPLS LSP echo reply will not get back to the initiator. This results 97 in a false failure of MPLS LSP Ping and Traceroute operation. In an 98 effort to minimize such false failures, different implementations 99 have chosen different default return path encoding for different LSP 100 types and LSP operations. The problem with implementations having 101 different default return path encoding is that the MPLS echo reply 102 will not work in many cases, and the default value may not be the 103 preferred choice by the operators. 105 This document further describes the problem in Section 2, and 106 proposes a solution in Section 3 to minimizes false failure scenarios 107 while accommodating operator preferences. 109 2. Problem Statements 111 It is becoming increasingly difficult for implementations to 112 automatically supply a workable return path encoding for all MPLS LSP 113 Ping and Traceroute operations across all LSP types. There are 114 several factors which are contributing to this complication. 116 o Some LSPs have a control-channel, and some do not. Some LSPs have 117 a reverse LSP, and some do not. Some LSPs have IP reachability in 118 the reverse direction, and some do not. 120 o LSRs on some LSPs can have different available return path(s). 121 Available return path(s) can depend on whether the responder is a 122 transit LSR or an egress LSR. In case of a bi-directional LSP, 123 available return path(s) on transit LSRs can also depend on 124 whether LSP is completely co-routed, partially co-routed or 125 associated (i.e., LSPs in the two directions are not co-routed). 127 o MPLS echo request packets may incorrectly terminate on an 128 unintended target, which can have different available return 129 path(s) than the intended target. 131 o The MPLS LSP Ping operation is expected to terminate on egress 132 LSR. However, the MPLS LSP Ping operation with specific TTL 133 values and MPLS LSP Traceroute operation can terminate on both 134 transit LSR(s) and the egress LSR. 136 Except for the case where the responder node does not have an IP 137 route back to the initiator, it is possible to use Reply Mode of 138 value 2 (Reply via an IPv4/IPv6 UDP packet) in all cases. However, 139 some operators are preferring control-channel and reverse LSP as 140 default return path if they are available, which is not always the 141 case. 143 When specific return path encoding is supplied by users or 144 applications, then there are no issues in choosing the return path 145 encoding. When specific return path encoding is not supplied by 146 users or applications, then implementations use extra logic to 147 compute, and sometimes guess, the default return path encodings. If 148 a responder node receives an MPLS echo request containing return path 149 instructions which cannot be accommodated due to unavailability, then 150 the responder often drops such packets. This results in the 151 initiator not receiving the MPLS LSP echo reply packets back. This 152 consequence may be acceptable for failure cases (e.g., broken LSPs) 153 where the MPLS echo request terminated on unintended target. 154 However, the initiator not receiving back MPLS echo reply packets, 155 even when the intended target received and verified the requests, is 156 not desirable as false failures will be conveyed to users. 158 Many operators prefer some return path(s) over others for specific 159 LSP types. To accommodate this, implementations may default to 160 operator preferred return path (or allow default return path to be 161 configured) for a specific operation. However, if the sender of MPLS 162 echo request knew that preferred return path will not be available at 163 the intended target node, then it is not very beneficial to use a 164 Reply Mode corresponding to preferred return path (i.e., the sender 165 of the MPLS echo request will not receive the MPLS echo reply in the 166 successful case). What would be beneficial, for a given operation, 167 is for the sender of the MPLS echo request to determine which return 168 path(s) can and cannot be used ahead of time. 170 This document adds one Reply Mode value to describe the reverse LSP, 171 and one optional TLV to describe an ordered list of reply modes. 172 Based on operational needs, the TLV can describe multiple Reply Mode 173 values in a preferred order to allow the responder to use the first 174 available Reply Mode from the list. This eliminates the need for the 175 initiator to compute, or sometimes guess, the default return path 176 encoding. And that will result in simplified implementations across 177 vendors, and result in improved usability to fit operational needs. 179 3. Solution 181 This document adds one reply mode to indicate reverse LSP, to be used 182 by the MPLS LSP Ping and Traceroute. This document also adds an 183 optional TLV which can carry ordered list of reply modes. 185 3.1. Reply via reverse LSP 187 Some LSP types are capable of having related LSP in reverse 188 direction, through signaling or other association mechanisms. This 189 document uses the term "Reverse LSP" to refer to the LSP in reverse 190 direction of such LSP types. Note that this document restricts the 191 scope of "Reverse LSP" applicability to those reverse LSPs which are 192 capable and allowed to carry the IP encapsulated MPLS echo reply. 194 This document adds one Reply Mode to be used by MPLS LSP Ping and 195 Traceroute operations. 197 Value Meaning 198 ----- ------- 199 TBD1 Reply via reverse LSP 201 MPLS echo request with TBD1 (Reply via reverse LSP) in the Reply Mode 202 field may be used to instruct responder to use reverse LSP to send 203 MPLS echo reply. Reverse LSP is in relation to the last FEC 204 specified in the Target FEC Stack TLV. 206 When a responder is using this Reply Mode, transmitting MPLS echo 207 reply packet MUST use IP destination address of 127/8 for IPv4 and 208 0:0:0:0:0:FFFF:7F00/104 for IPv6. 210 3.2. Reply Mode Order TLV 212 This document also introduces a new optional TLV to describe list of 213 Reply Mode values. The new TLV will contain one or more Reply Mode 214 value(s) in preferred order. The first Reply Mode value is the most 215 preferred and the last Reply Mode value is the least preferred. 216 Following rules apply when using Reply Mode Order TLV. 218 1. Reply Mode Order TLV MAY be included in MPLS echo request. 220 2. Reply Mode Order TLV MUST NOT be included in MPLS echo reply. 222 3. Reply Mode field of MPLS echo request MUST be set to a valid 223 value when supplying Reply Mode Order TLV in transmitting MPLS 224 echo request. The initiator SHOULD set Reply Mode field of MPLS 225 echo request to a value that corresponds to a return path which 226 most likely to be available, in case responder does not 227 understand the Reply Mode Order TLV. 229 4. If a responder node understands the Reply Mode Order TLV and the 230 TLV is valid, then the responder MUST consider Reply Mode values 231 described in the TLV and MUST NOT use the value described in the 232 Reply Mode field of received MPLS echo request. 234 5. If a responder node understands the Reply Mode Order TLV but the 235 TLV is not valid (due to conditions listed below), then the 236 responder MUST only use the value described in the Reply Mode 237 field of received MPLS echo request. 239 6. Reply Mode Order TLV MUST contain at least one Reply Mode value, 240 and SHOULD contain at least two Reply Mode values. 242 7. A Reply Mode value MUST NOT be repeated (i.e. MUST NOT appear 243 multiple times) in the Reply Mode Order TLV. 245 8. Reply Mode value 1 (Do not reply) SHOULD NOT be used in the Reply 246 Mode Order TLV. 248 The responding node is to select the first available return path in 249 this TLV. Reply Mode value corresponding to selected return path 250 MUST be set in Reply Mode field of MPLS echo reply to communicate 251 back to the initiator which return path was chosen. 253 The format of the TLV is as follows: 255 0 1 2 3 256 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 257 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 258 | Reply Mode Order TLV Type | Length | 259 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 260 | Reply mode 1 | Reply mode 2 | Reply mode 3 | Reply mode 4 | 261 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 262 Figure 1 Reply Mode Order TLV 264 This is a variable length optional TLV. Each Reply Mode field is 1 265 octet. 267 4. Relations to Other LSP Ping/Trace Features 269 4.1. Reply Path TLV 271 [RFC7110] defines a new Reply Mode (5 - Reply via Specified Path). 272 This Reply Mode specified in MPLS echo request indicates that MPLS 273 echo reply be sent on one specific path described by the Reply Path 274 TLV. The Flags field of the Reply Path TLV can indicate B 275 (Bidirectional) bit to describe reverse direction of the tested 276 bidirectional LSP. However, it is desired to have a new Reply Mode 277 (TBD1 - Reply via reverse LSP) to indicate reverse direction of the 278 tested bidirectional LSP without requiring to include additional TLV 279 (i.e. Reply Path TLV). Therefore, a new Reply Mode (TBD1 - Reply via 280 reverse LSP) has been added. 282 4.2. Proxy LSP Ping 284 The mechanism defined in this document will work with Proxy LSP Ping 285 defined by [I-D.ietf-mpls-proxy-lsp-ping]. MPLS proxy ping request 286 can carry a Reply Mode value and the Reply Mode Order TLV with list 287 of Reply Mode values. Proxy LSR MUST copy both Reply Mode value and 288 the Reply Mode Order TLV into MPLS echo request. Proxy LSR, upon 289 receiving MPLS echo reply, MUST copy Reply Mode value into MPLS proxy 290 ping reply. With these procedures, Reply Mode used by the MPLS echo 291 reply sender is propagated in the Reply Mode field to the sender of 292 MPLS proxy ping request. 294 5. Security Considerations 296 Beyond those specified in [RFC4379], there are no further security 297 measures required. 299 6. IANA Considerations 301 6.1. New Reply Mode 303 IANA is requested to assign one reply modes from the "Reply Mode" 304 sub-registry within the "Multiprotocol Label Switching Architecture 305 (MPLS)" registry. 307 Value Meaning Reference 308 ----- ------- --------- 309 TBD1 Reply via reverse LSP this document 311 6.2. New Reply Mode Order TLV 313 IANA is requested to assign a new TLV type value from the "TLVs" sub- 314 registry within the "Multiprotocol Label Switching Architecture 315 (MPLS)" registry, for the "Reply Mode Order TLV". 317 The new TLV Type value should be assigned from the range 318 (32768-49161) specified in [RFC4379] section 3 that allows the TLV 319 type to be silently dropped if not recognized. 321 Type Meaning Reference 322 ---- ------- --------- 323 TBD2 Reply Mode Order TLV this document 325 7. Acknowledgements 327 Authors would like to thank Santiago Alvarez and Faisal Iqbal for 328 discussions which motivated creation of this document. Authors would 329 also like to thank Sam Aldrin, Curtis Villamizar and Ross Callon for 330 providing valuable comments to influence the contents of the draft. 332 8. Contributing Authors 334 Shaleen Saxena 335 Cisco Systems 336 Email: ssaxena@cisco.com 338 9. References 340 9.1. Normative References 342 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 343 Requirement Levels", BCP 14, RFC 2119, March 1997. 345 [RFC4379] Kompella, K. and G. Swallow, "Detecting Multi-Protocol 346 Label Switched (MPLS) Data Plane Failures", RFC 4379, 347 February 2006. 349 9.2. Informative References 351 [I-D.ietf-mpls-proxy-lsp-ping] 352 Swallow, G., Lim, V., and S. Aldrin, "Proxy MPLS Echo 353 Request", draft-ietf-mpls-proxy-lsp-ping-01 (work in 354 progress), January 2014. 356 [RFC7110] Chen, M., Cao, W., Ning, S., Jounay, F., and S. Delord, 357 "Return Path Specified Label Switched Path (LSP) Ping", 358 RFC 7110, January 2014. 360 Authors' Addresses 362 Nobo Akiya 363 Cisco Systems 365 Email: nobo@cisco.com 367 George Swallow 368 Cisco Systems 370 Email: swallow@cisco.com 372 Carlos Pignataro 373 Cisco Systems 375 Email: cpignata@cisco.com 376 Loa Andersson 377 Huawei 379 Email: loa@mail01.huawei.com 381 Mach(Guoyi) Chen 382 Huawei 384 Email: mach.chen@huawei.com