idnits 2.17.1 draft-akiya-mpls-lsp-ping-reply-mode-simple-00.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 == Line 291 has weird spacing: '...ference this...' (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 (September 19, 2013) is 3866 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 (-15) exists of draft-ietf-mpls-return-path-specified-lsp-ping-13 Summary: 2 errors (**), 0 flaws (~~), 3 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: March 23, 2014 L. Andersson 7 M. Chen 8 Huawei 9 September 19, 2013 11 Label Switched Path (LSP) Ping/Trace Reply Mode Simplification 12 draft-akiya-mpls-lsp-ping-reply-mode-simple-00 14 Abstract 16 This document adds two reply modes to be used by Multiprotocol Label 17 Switching (MPLS) Label Switched Path (LSP) Ping and Traceroute: one 18 reply mode to indicate reverse LSP and one reply mode to allow 19 responder to choose reply mode from pre-defined set. This document 20 also adds an optional TLV which can carry ordered list of reply 21 modes. 23 This document updates [RFC4379]. 25 Requirements Language 27 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 28 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 29 document are to be interpreted as described in RFC 2119 [RFC2119]. 31 Status of This Memo 33 This Internet-Draft is submitted in full conformance with the 34 provisions of BCP 78 and BCP 79. 36 Internet-Drafts are working documents of the Internet Engineering 37 Task Force (IETF). Note that other groups may also distribute 38 working documents as Internet-Drafts. The list of current Internet- 39 Drafts is at http://datatracker.ietf.org/drafts/current/. 41 Internet-Drafts are draft documents valid for a maximum of six months 42 and may be updated, replaced, or obsoleted by other documents at any 43 time. It is inappropriate to use Internet-Drafts as reference 44 material or to cite them other than as "work in progress." 46 This Internet-Draft will expire on March 23, 2014. 48 Copyright Notice 50 Copyright (c) 2013 IETF Trust and the persons identified as the 51 document authors. All rights reserved. 53 This document is subject to BCP 78 and the IETF Trust's Legal 54 Provisions Relating to IETF Documents 55 (http://trustee.ietf.org/license-info) in effect on the date of 56 publication of this document. Please review these documents 57 carefully, as they describe your rights and restrictions with respect 58 to this document. Code Components extracted from this document must 59 include Simplified BSD License text as described in Section 4.e of 60 the Trust Legal Provisions and are provided without warranty as 61 described in the Simplified BSD License. 63 Table of Contents 65 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 66 2. Problem Statements . . . . . . . . . . . . . . . . . . . . . 3 67 3. Solution . . . . . . . . . . . . . . . . . . . . . . . . . . 4 68 3.1. Reply via reverse LSP . . . . . . . . . . . . . . . . . . 4 69 3.2. Reply via pre-defined preference . . . . . . . . . . . . 5 70 3.3. Reply Mode Order TLV . . . . . . . . . . . . . . . . . . 5 71 4. Security Considerations . . . . . . . . . . . . . . . . . . . 6 72 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 73 5.1. New Reply Mode . . . . . . . . . . . . . . . . . . . . . 6 74 5.2. New Reply Mode Order TLV . . . . . . . . . . . . . . . . 7 75 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 76 7. Contributing Authors . . . . . . . . . . . . . . . . . . . . 7 77 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 78 8.1. Normative References . . . . . . . . . . . . . . . . . . 7 79 8.2. Informative References . . . . . . . . . . . . . . . . . 8 80 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 82 1. Introduction 84 MPLS LSP Ping, described in [RFC4379], allows initiator to encode 85 instructions (Reply Mode) on how responder is to send response back 86 to the initiator. [I-D.ietf-mpls-return-path-specified-lsp-ping] 87 also allows initiator to encode a TLV (Reply Path TLV) which can 88 instruct responder to use specific LSP to send response back to the 89 initiator. Both approaches are powerful as they provide ability for 90 the initiator to control the return path. 92 It is, however, becoming increasingly difficult for an initiator to 93 select the "right" return path to encode in MPLS LSP echo request 94 packets. Consequence of initiator not selecting the "right" return 95 path encoding can result in false failure of MPLS LSP Ping and 96 Traceroute operations, due to initiator not receiving back expected 97 MPLS LSP echo reply. Resulting from an effort to minimize such false 98 failures, implementations may result in having different "default" 99 return path encoding per LSP type and per operational type. 100 Deviating "default" return path encoding, potentially, per vendor per 101 LSP type per operational type can drift this technology from 102 consistency axle. Thus it is desirable to have a single return path 103 encoding which works across wide range of LSP types and operational 104 types. 106 2. Problem Statements 108 It is becoming increasingly difficult for implementations to 109 automatically supply a workable return path encoding for all MPLS LSP 110 Ping and Traceroute operations across all LSP types. There are 111 several factors which are contributing to this complication. 113 o Some LSPs have control-channel, and some do not. Some LSPs have 114 reverse LSP, and some do not. Some LSPs have IP route in reverse 115 direction, and some do not. 117 o LSRs on some LSPs can have different available return path(s). 118 Available return path(s) can depend on whether responder is a 119 transit LSR or an egress LSR. In case of bi-directional LSP, 120 available return path(s) on transit LSRs can also depend on 121 whether LSP is completely co-routed, partially co-routed or non- 122 co-routed. 124 o MPLS LSP echo request packets may falsely terminate on an 125 unintended target which can have different available return 126 path(s) than intended target. 128 o MPLS LSP Ping operation is expected to terminate on egress LSR. 129 However, MPLS LSP Ping operation with specific TTL values and MPLS 130 LSP Traceroute operation can terminate on both transit LSR(s) and 131 egress LSR. 133 Except for the case where responder node does not have an IP route 134 back to the initiator, it is possible to use Reply Mode of value 2 135 (Reply via an IPv4/IPv6 UDP packet) in all cases. However, some 136 operators are preferring control-channel and reverse LSP as "default" 137 return path if they are available, which are not always available. 139 When specific return path encoding is being supplied by users or 140 applications, then there are no issues in choosing the return path 141 encoding. When specific return path encoding is not being supplied 142 by users or applications, then implementations require extended logic 143 to compute, and sometimes "guess", the "default" return path 144 encodings. If a responder received a MPLS LSP echo request 145 containing return path instruction which cannot be accommodated due 146 to unavailability, then responder implementations often drop such 147 packets. This results in initiator to not receive back MPLS LSP echo 148 reply packets. Consequence may be acceptable for failure cases (ex: 149 broken LSP) where MPLS LSP echo request terminated on unintended 150 target. However, initiator not receiving back MPLS LSP echo reply 151 packets, even when intended target received and verified the 152 requests, is not desirable as result will be conveyed as false 153 failures to users. 155 Some return path(s) are more preferred than others, but preferred 156 cannot be used in all cases. Thus implementations are required to 157 compute when preferred return path encoding can and cannot be used, 158 and that computation is becoming more and more difficult. 160 This document adds two Reply Modes to be used by MPLS LSP Ping and 161 Traceroute. One of which is a Reply Mode which can be used as 162 "default" for all LSP types and for all operational types. Thus 163 eliminating the need for initiator to compute, or sometimes "guess", 164 the "default" return path encoding. This will result in simplified 165 implementations across vendors, and result in consistent behaviors 166 across vendor products. 168 3. Solution 170 This document adds two Reply Modes to be used by MPLS LSP Ping and 171 Traceroute operations. Note: Reply Mode values specified in this 172 document will be requested for IANA early allocation, but values may 173 change as result of actual early allocation result. 175 Value Meaning 176 ----- ------- 177 6 Reply via reverse LSP 178 7 Reply via pre-defined preference 180 3.1. Reply via reverse LSP 182 Some LSP types are capable of having related LSP in reverse 183 direction, through signaling or other association mechanisms. This 184 document uses the term "Reverse LSP" to refer to the LSP in reverse 185 direction of such LSP types. Note that this document isolates the 186 scope of "Reverse LSP" applicability to those reverse LSPs which are 187 capable of and permitted to carry the IP encapsulated MPLS LSP echo 188 reply. 190 MPLS LSP echo request with 6 (Reply via reverse LSP) in the Reply 191 Mode field may be used to instruct responder to use reverse LSP to 192 send MPLS LSP echo reply. Reverse LSP is in relation to the last FEC 193 specified in the Target FEC Stack TLV. 195 When responder is using this Reply Mode, transmitting MPLS LSP echo 196 reply packet MUST use IP destination address of 127/8 for IPv4 and 197 0:0:0:0:0:FFFF:7F00/104 for IPv6. 199 3.2. Reply via pre-defined preference 201 MPLS LSP echo request with 7 (Reply via pre-defined preference) in 202 the Reply Mode field may be used to instruct responder to select the 203 return path based on availability. Receiver of MPLS LSP echo 204 request, upon reception of 7 (Reply via pre-defined preference) in 205 the Reply Mode field, MUST choose return path by examining 206 availability in following order. 208 1. Examine if Reply Mode 4 (Reply via application level control 209 channel) is available. 211 2. Examine if Reply Mode 6 (Reply via reverse LSP) is available. 213 3. Examine if Reply Mode 2 (Reply via an IPv4/IPv6 UDP packet) is 214 available. 216 First available return path is selected. Reply Mode value 217 corresponding to selected return path MUST be set in Reply Mode field 218 of MPLS LSP echo reply to communicate back to the initiator which 219 return path was chosen. 221 3.3. Reply Mode Order TLV 223 This document also introduces a new optional TLV to describe Reply 224 Mode preference order. The new TLV will contain one or more Reply 225 Mode value(s) in preferred order, first Reply Mode value appearing 226 being most preferred. This TLV can be used if a different preference 227 order than "Reply via pre-defined preference" Reply Mode is desired. 228 Following rules apply when using Reply Mode Order TLV. 230 1. Initiator, when supplying Reply Mode Order TLV in transmitting 231 MPLS echo request, MUST set Reply Mode field of MPLS echo request 232 header to value 7 (Reply via pre-defined preference). 234 2. Responder MUST ignore Reply Mode Order TLV if received MPLS echo 235 request header does not contain value 7 (Reply via pre-defined 236 preference). 238 3. Reply Mode Order TLV MUST contain at least one Reply Mode value, 239 and SHOULD contain at least two Reply Mode values. 241 4. Same Reply Mode value MUST NOT appear multiple times in the Reply 242 Mode Order TLV. 244 5. Reply Mode value 1 (Do not reply) SHOULD NOT be used in the Reply 245 Mode Order TLV. 247 6. Reply Mode value 7 (Reply via pre-defined preference) MUST NOT be 248 used in the Reply Mode TLV. 250 The responding node is to select the first available return path in 251 this TLV. Reply Mode value corresponding to selected return path 252 MUST be set in Reply Mode field of MPLS LSP echo reply to communicate 253 back to the initiator which return path was chosen. 255 The format of the TLV is as follows: 257 0 1 2 3 258 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 259 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 260 | Reply Mode Order TLV Type | Length | 261 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 262 | Reply mode 1 | Reply mode 2 | Reply mode 3 | Reply mode 4 | 263 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 264 Figure 1 Reply Mode Order TLV 266 This is a variable length optional TLV. Each Reply Mode field is 1 267 octet. If this TLV is present and valid, then the described 268 preference order will override pre-defined preference order described 269 in Section 3.2. 271 4. Security Considerations 273 Beyond those specified in [RFC4379], there are no further security 274 measured required. 276 5. IANA Considerations 278 5.1. New Reply Mode 280 IANA is requested to assign two new reply modes from the "Reply Mode" 281 sub-registry within the "Multiprotocol Label Switching Architecture 282 (MPLS)" registry. 284 Following values appear to be next available MPLS LSP Ping/Traceroute 285 Reply Mode values. Requesting IANA to allow specified values as 286 early allocation. 288 Value Meaning Reference 289 ----- ------- --------- 290 6 Reply via reverse LSP this document 291 7 Reply via pre-defined preference this document 293 5.2. New Reply Mode Order TLV 295 IANA is requested to assign a new TLV type value from the "TLVs" sub- 296 registry within the "Multiprotocol Label Switching Architecture 297 (MPLS)" registry, for the "Reply Mode Order TLV". 299 The new TLV Type value should be assigned from the range 300 (32768-49161) specified in RFC 4379 [RFC4379] section 3 that allows 301 the TLV type to be silently dropped if not recognized. 303 Type Meaning Reference 304 ---- ------- --------- 305 TBD Reply Mode Order TLV this document 307 6. Acknowledgements 309 Authors would like to thank Santiago Alvarez and Faisal Iqbal for 310 discussions which motivated creation of this document. 312 7. Contributing Authors 314 Shaleen Saxena 315 Cisco Systems 316 Email: ssaxena@cisco.com 318 8. References 320 8.1. Normative References 322 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 323 Requirement Levels", BCP 14, RFC 2119, March 1997. 325 [RFC4379] Kompella, K. and G. Swallow, "Detecting Multi-Protocol 326 Label Switched (MPLS) Data Plane Failures", RFC 4379, 327 February 2006. 329 8.2. Informative References 331 [I-D.ietf-mpls-return-path-specified-lsp-ping] 332 Chen, M., Cao, W., Ning, S., JOUNAY, F., and S. DeLord, 333 "Return Path Specified LSP Ping", draft-ietf-mpls-return- 334 path-specified-lsp-ping-13 (work in progress), September 335 2013. 337 Authors' Addresses 339 Nobo Akiya 340 Cisco Systems 342 Email: nobo@cisco.com 344 George Swallow 345 Cisco Systems 347 Email: swallow@cisco.com 349 Carlos Pignataro 350 Cisco Systems 352 Email: cpignata@cisco.com 354 Loa Andersson 355 Huawei 357 Email: loa@mail01.huawei.com 359 Mach(Guoyi) Chen 360 Huawei 362 Email: mach.chen@huawei.com