idnits 2.17.1 draft-akiya-mpls-lsp-ping-reply-mode-simple-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 abstract seems to contain references ([RFC4379]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. 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 (December 15, 2013) is 3782 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) Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 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: June 18, 2014 L. Andersson 7 M. Chen 8 Huawei 9 December 15, 2013 11 Label Switched Path (LSP) Ping/Trace Reply Mode Simplification 12 draft-akiya-mpls-lsp-ping-reply-mode-simple-01 14 Abstract 16 This document adds one reply mode to indicate reverse LSP, to be used 17 by Multiprotocol Label Switching (MPLS) Label Switched Path (LSP) 18 Ping and Traceroute. This document also adds an optional TLV which 19 can carry ordered list of reply modes. 21 This document updates [RFC4379]. 23 Requirements Language 25 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 26 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 27 document are to be interpreted as described in RFC 2119 [RFC2119]. 29 Status of This Memo 31 This Internet-Draft is submitted in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF). Note that other groups may also distribute 36 working documents as Internet-Drafts. The list of current Internet- 37 Drafts is at http://datatracker.ietf.org/drafts/current/. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 This Internet-Draft will expire on June 18, 2014. 46 Copyright Notice 47 Copyright (c) 2013 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 . . . . . . . . . . . . . . . . . . . . . . . . 2 63 2. Problem Statements . . . . . . . . . . . . . . . . . . . . . 3 64 3. Solution . . . . . . . . . . . . . . . . . . . . . . . . . . 4 65 3.1. Reply via reverse LSP . . . . . . . . . . . . . . . . . . 4 66 3.2. Reply Mode Order TLV . . . . . . . . . . . . . . . . . . 5 67 4. Security Considerations . . . . . . . . . . . . . . . . . . . 6 68 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 69 5.1. New Reply Mode . . . . . . . . . . . . . . . . . . . . . 6 70 5.2. New Reply Mode Order TLV . . . . . . . . . . . . . . . . 6 71 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 72 7. Contributing Authors . . . . . . . . . . . . . . . . . . . . 7 73 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 74 8.1. Normative References . . . . . . . . . . . . . . . . . . 7 75 8.2. Informative References . . . . . . . . . . . . . . . . . 7 76 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 78 1. Introduction 80 MPLS LSP Ping, described in [RFC4379], allows initiator to encode 81 instructions (Reply Mode) on how responder is to send response back 82 to the initiator. [I-D.ietf-mpls-return-path-specified-lsp-ping] 83 also allows initiator to encode a TLV (Reply Path TLV) which can 84 instruct responder to use specific LSP to send response back to the 85 initiator. Both approaches are powerful as they provide ability for 86 the initiator to control the return path. 88 It is, however, becoming increasingly difficult for an initiator to 89 select the "right" return path to encode in MPLS LSP echo request 90 packets. Consequence of initiator not selecting the "right" return 91 path encoding can result in false failure of MPLS LSP Ping and 92 Traceroute operations, due to initiator not receiving back expected 93 MPLS LSP echo reply. Resulting from an effort to minimize such false 94 failures, implementations may result in having different "default" 95 return path encoding per LSP type and per operational type. 96 Deviating "default" return path encoding, potentially, per vendor per 97 LSP type per operational type can drift this technology from 98 consistency axle. Thus it is desirable to have a return path 99 encoding mechanism which minimizes false failure scenarios while 100 reverse direction taking path preferred for operational needs. 102 2. Problem Statements 104 It is becoming increasingly difficult for implementations to 105 automatically supply a workable return path encoding for all MPLS LSP 106 Ping and Traceroute operations across all LSP types. There are 107 several factors which are contributing to this complication. 109 o Some LSPs have control-channel, and some do not. Some LSPs have 110 reverse LSP, and some do not. Some LSPs have IP route in reverse 111 direction, and some do not. 113 o LSRs on some LSPs can have different available return path(s). 114 Available return path(s) can depend on whether responder is a 115 transit LSR or an egress LSR. In case of bi-directional LSP, 116 available return path(s) on transit LSRs can also depend on 117 whether LSP is completely co-routed, partially co-routed or non- 118 co-routed. 120 o MPLS LSP echo request packets may falsely terminate on an 121 unintended target which can have different available return 122 path(s) than intended target. 124 o MPLS LSP Ping operation is expected to terminate on egress LSR. 125 However, MPLS LSP Ping operation with specific TTL values and MPLS 126 LSP Traceroute operation can terminate on both transit LSR(s) and 127 egress LSR. 129 Except for the case where responder node does not have an IP route 130 back to the initiator, it is possible to use Reply Mode of value 2 131 (Reply via an IPv4/IPv6 UDP packet) in all cases. However, some 132 operators are preferring control-channel and reverse LSP as "default" 133 return path if they are available, which are not always available. 135 When specific return path encoding is being supplied by users or 136 applications, then there are no issues in choosing the return path 137 encoding. When specific return path encoding is not being supplied 138 by users or applications, then implementations require extended logic 139 to compute, and sometimes "guess", the "default" return path 140 encodings. If a responder received a MPLS LSP echo request 141 containing return path instruction which cannot be accommodated due 142 to unavailability, then responder implementations often drop such 143 packets. This results in initiator to not receive back MPLS LSP echo 144 reply packets. Consequence may be acceptable for failure cases (ex: 145 broken LSP) where MPLS LSP echo request terminated on unintended 146 target. However, initiator not receiving back MPLS LSP echo reply 147 packets, even when intended target received and verified the 148 requests, is not desirable as result will be conveyed as false 149 failures to users. 151 Some return path(s) are more preferred than others, but preferred 152 cannot be used in all cases. Thus implementations are required to 153 compute when preferred return path encoding can and cannot be used, 154 and that computation is becoming more and more difficult. 156 This document adds one Reply Mode to describe reverse LSP, and one 157 optional TLV to describe ordered list of reply modes. Based on 158 operational needs, the TLV can describe multiple Reply Mode values in 159 preferred order to allow responder to use first available Reply Mode 160 from the list. This eliminates the need for initiator to compute, or 161 sometimes "guess", the "default" return path encoding. And that will 162 result in simplified implementations across vendors, and result in 163 improved usability to fit operational needs. 165 3. Solution 167 This document adds one reply mode to indicate reverse LSP, to be used 168 by Multiprotocol Label Switching (MPLS) Label Switched Path (LSP) 169 Ping and Traceroute. This document also adds an optional TLV which 170 can carry ordered list of reply modes. 172 3.1. Reply via reverse LSP 174 Some LSP types are capable of having related LSP in reverse 175 direction, through signaling or other association mechanisms. This 176 document uses the term "Reverse LSP" to refer to the LSP in reverse 177 direction of such LSP types. Note that this document isolates the 178 scope of "Reverse LSP" applicability to those reverse LSPs which are 179 capable of and permitted to carry the IP encapsulated MPLS LSP echo 180 reply. 182 This document adds one Reply Mode to be used by MPLS LSP Ping and 183 Traceroute operations. 185 Value Meaning 186 ----- ------- 187 TBD1 Reply via reverse LSP 189 MPLS LSP echo request with TBD1 (Reply via reverse LSP) in the Reply 190 Mode field may be used to instruct responder to use reverse LSP to 191 send MPLS LSP echo reply. Reverse LSP is in relation to the last FEC 192 specified in the Target FEC Stack TLV. 194 When responder is using this Reply Mode, transmitting MPLS LSP echo 195 reply packet MUST use IP destination address of 127/8 for IPv4 and 196 0:0:0:0:0:FFFF:7F00/104 for IPv6. 198 3.2. Reply Mode Order TLV 200 This document also introduces a new optional TLV to describe list of 201 Reply Mode values. The new TLV will contain one or more Reply Mode 202 value(s) in preferred order, first Reply Mode value appearing being 203 most preferred. Following rules apply when using Reply Mode Order 204 TLV. 206 1. Reply Mode Order TLV MAY be included in MPLS echo request. 208 2. Reply Mode Order TLV MUST NOT be included in MPLS echo reply. 210 3. Reply Mode field of MPLS echo request MUST be set to a valid 211 value when supplying Reply Mode Order TLV in transmitting MPLS 212 echo request. It is RECOMMENDED for initiator to set Reply Mode 213 field of MPLS echo request to a value that corresponds to return 214 path most likely to be available, in case responder does not 215 understand the Reply Mode Order TLV. 217 4. If responder node understands Reply Mode Order TLV and TLV is 218 valid, then responder MUST consider Reply Mode values described 219 in the TLV and MUST NOT use value described in Reply Mode field 220 of received MPLS echo request. 222 5. If responder node understands Reply Mode Order TLV but TLV is not 223 valid (due to conditions listed below), then responder MUST only 224 use value described in Reply Mode field of received MPLS echo 225 request. 227 6. Reply Mode Order TLV MUST contain at least one Reply Mode value, 228 and SHOULD contain at least two Reply Mode values. 230 7. Same Reply Mode value MUST NOT appear multiple times in the Reply 231 Mode Order TLV. 233 8. Reply Mode value 1 (Do not reply) SHOULD NOT be used in the Reply 234 Mode Order TLV. 236 The responding node is to select the first available return path in 237 this TLV. Reply Mode value corresponding to selected return path 238 MUST be set in Reply Mode field of MPLS LSP echo reply to communicate 239 back to the initiator which return path was chosen. 241 The format of the TLV is as follows: 243 0 1 2 3 244 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 245 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 246 | Reply Mode Order TLV Type | Length | 247 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 248 | Reply mode 1 | Reply mode 2 | Reply mode 3 | Reply mode 4 | 249 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 250 Figure 1 Reply Mode Order TLV 252 This is a variable length optional TLV. Each Reply Mode field is 1 253 octet. 255 4. Security Considerations 257 Beyond those specified in [RFC4379], there are no further security 258 measures required. 260 5. IANA Considerations 262 5.1. New Reply Mode 264 IANA is requested to assign one reply modes from the "Reply Mode" 265 sub-registry within the "Multiprotocol Label Switching Architecture 266 (MPLS)" registry. 268 Value Meaning Reference 269 ----- ------- --------- 270 TBD1 Reply via reverse LSP this document 272 5.2. New Reply Mode Order TLV 274 IANA is requested to assign a new TLV type value from the "TLVs" sub- 275 registry within the "Multiprotocol Label Switching Architecture 276 (MPLS)" registry, for the "Reply Mode Order TLV". 278 The new TLV Type value should be assigned from the range 279 (32768-49161) specified in RFC 4379 [RFC4379] section 3 that allows 280 the TLV type to be silently dropped if not recognized. 282 Type Meaning Reference 283 ---- ------- --------- 284 TBD2 Reply Mode Order TLV this document 286 6. Acknowledgements 288 Authors would like to thank Santiago Alvarez and Faisal Iqbal for 289 discussions which motivated creation of this document. Authors would 290 also like to thank Sam Aldrin and Curtis Villamizar for providing 291 valuable comments to influence the contents of the draft. 293 7. Contributing Authors 295 Shaleen Saxena 296 Cisco Systems 297 Email: ssaxena@cisco.com 299 8. References 301 8.1. Normative References 303 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 304 Requirement Levels", BCP 14, RFC 2119, March 1997. 306 [RFC4379] Kompella, K. and G. Swallow, "Detecting Multi-Protocol 307 Label Switched (MPLS) Data Plane Failures", RFC 4379, 308 February 2006. 310 8.2. Informative References 312 [I-D.ietf-mpls-return-path-specified-lsp-ping] 313 Chen, M., Cao, W., Ning, S., JOUNAY, F., and S. DeLord, 314 "Return Path Specified LSP Ping", draft-ietf-mpls-return- 315 path-specified-lsp-ping-15 (work in progress), October 316 2013. 318 Authors' Addresses 320 Nobo Akiya 321 Cisco Systems 323 Email: nobo@cisco.com 325 George Swallow 326 Cisco Systems 328 Email: swallow@cisco.com 329 Carlos Pignataro 330 Cisco Systems 332 Email: cpignata@cisco.com 334 Loa Andersson 335 Huawei 337 Email: loa@mail01.huawei.com 339 Mach(Guoyi) Chen 340 Huawei 342 Email: mach.chen@huawei.com