idnits 2.17.1 draft-ietf-mpls-lsp-ping-ttl-tlv-10.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 -- The document date (August 19, 2014) is 3537 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) -- Looks like a reference, but probably isn't: 'RFC2119' on line 123 -- Looks like a reference, but probably isn't: 'RFC4379' on line 262 == Unused Reference: '1' is defined on line 291, but no explicit reference was found in the text == Unused Reference: '2' is defined on line 294, but no explicit reference was found in the text == Unused Reference: '3' is defined on line 298, but no explicit reference was found in the text ** Obsolete normative reference: RFC 4379 (ref. '1') (Obsoleted by RFC 8029) Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Sami Boutros 3 INTERNET-DRAFT Siva Sivabalan 4 Intended Status: Standards Track George Swallow 5 Shaleen Saxena 6 Cisco Systems 8 Vishwas Manral 9 Hewlett Packard Co. 11 Sam Aldrin 12 Huawei Technologies, Inc. 14 Expires: February 20, 2015 August 19, 2014 16 Definition of Time-to-Live TLV for LSP-Ping Mechanisms 17 draft-ietf-mpls-lsp-ping-ttl-tlv-10.txt 19 Abstract 21 LSP-Ping is a widely deployed Operation, Administration, and 22 Maintenance (OAM) mechanism in MPLS networks. However, in the present 23 form, this mechanism is inadequate to verify connectivity of a 24 segment of a Multi-Segment PseudoWire (MS-PW) and/or bidirectional 25 co-routed LSP from any node on the path of the MS-PW and/or 26 bidirectional co-routed LSP. This document defines a TLV to address 27 this shortcoming. 29 Status of this Memo 31 This Internet-Draft is submitted to IETF 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), its areas, and its working groups. Note that 36 other groups may also distribute working documents as 37 Internet-Drafts. 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 The list of current Internet-Drafts can be accessed at 45 http://www.ietf.org/1id-abstracts.html 47 The list of Internet-Draft Shadow Directories can be accessed at 48 http://www.ietf.org/shadow.html 50 Copyright and License Notice 52 Copyright (c) 2014 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (http://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the Simplified BSD License. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 68 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 69 3. Time To Live TLV . . . . . . . . . . . . . . . . . . . . . . . 4 70 3.1. TTL TLV Format . . . . . . . . . . . . . . . . . . . . . . 4 71 3.2. Usage . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 72 4. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 73 4.1. Traceroute mode . . . . . . . . . . . . . . . . . . . . . . 6 74 4.2. Error scenario . . . . . . . . . . . . . . . . . . . . . . 6 75 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 76 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 77 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7 78 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 79 8.1 Normative References . . . . . . . . . . . . . . . . . . . 7 80 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7 82 1. Introduction 84 A MS-PW may span across multiple service provider networks. In order 85 to allow Service Providers (SP) to verify segments of such MS-PW from 86 any node on the path of the MS-PW, any node along the path of the MS- 87 PW, should be able to originate an MPLS Echo Request packet to any 88 other node along the path of the MS-PW and receive the corresponding 89 MPLS Echo Reply. If the originator of the MPLS Echo Request is at the 90 end of a MS-PW, the receiver of the request can send the reply back 91 to the sender without knowing the hop-count distance of the 92 originator. The reply will be intercepted by the originator 93 regardless of the TTL value on the reply packet. But, if the 94 originator is not at the end of the MS-PW, the receiver of the MPLS 95 Echo Request may need to know how many hops away the originator of 96 the MPLS Echo Request is so that it can set the TTL value on the MPLS 97 header for the MPLS Echo Reply to be intercepted at the originator 98 node. 100 In MPLS networks, for bidirectional co-routed LSPs, if it is desired 101 to verify connectivity from any intermediate node (LSR) on the LSP to 102 the any other LSR on the LSP the receiver may need to know the TTL to 103 send the MPLS Echo Reply with, so as the packet is intercepted by the 104 originator node. 106 A new optional TTL TLV is defined in this document. This TLV will be 107 added by the originator of the MPLS Echo Request to inform the 108 receiver how many hops away the originator is on the path of the MS- 109 PW or Bidirectional LSP. 111 This mechanism only works if the MPLS Echo Reply is sent down the co- 112 routed LSP, hence the scope of this TTL TLV is currently limited to 113 MS-PW or Bidirectional co-routed MPLS LSPs. The presence of the TLV 114 implies the use of the return path of the co-routed LSP, if the 115 return path is any other mechanism then the TLV in the MPLS Echo 116 Request MUST be ignored. 118 2. Terminology 120 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 121 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 122 document are to be interpreted as described in RFC 2119 [RFC2119]. 124 LSR: Label Switching Router 126 MPLS-TP: MPLS Transport Profile 128 MS-PW: Multi-Segment Pseudowire 129 PW: Pseudowire 131 TLV: Type Length Value 133 TTL: Time To Live 135 3. Time To Live TLV 137 3.1. TTL TLV Format 139 0 1 2 3 140 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 141 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 142 | Type = TBD | Length = 8 | 143 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 144 | Value | Reserved | Flags | 145 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 146 Figure 1: Time To Live TLV format 148 The TTL TLV has the format shown in Figure 1. 150 Value 152 The value of the TTL as specified by this TLV 154 Flags 156 The Flags field is a bit vector with the following format: 158 0 1 159 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 160 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 161 | MBZ |R| 162 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 164 One flag is defined for now, the R flag. The rest of the 165 flags are Reserved - MUST be zero (MBZ) when sending and 166 ignored on receipt. 168 The R flag (Reply TTL) is set signify that the value is 169 meant to be used as the TTL for the reply packet. Other bits 170 may be defined later to enhance the scope of this TLV. 172 3.2. Usage 174 The TTL TLV MAY be included in the MPLS Echo Request by the 175 originator of the request. 177 If the TTL TLV is present and the receiver does not understand TTL 178 TLVs, it will simply ignore the TLV, as is the case for all optional 179 TLVs. If the TTL TLV is not present or is not processed by the 180 receiver, any determination of the TTL value used in the MPLS label 181 on the LSP-Ping echo reply is beyond the scope of this document. 183 If the TTL TLV is present and the receiver understands TTL TLVs, one 184 of the following two conditions apply: 186 o If the TTL TLV value field is zero, the LSP-Ping echo request 187 packet SHOULD be dropped. 189 o Otherwise, the receiver MUST use the TTL value specified in the 190 TTL TLV when it creates the MPLS header of the MPLS Echo Reply. 191 The TTL value in the TTL TLV takes precedence over any TTL value 192 determined by other means, such as from the Switching Point TLV in 193 the MS-PW. This precedence will aid the originator of the LSP- 194 Ping echo request in analyzing the return path. 196 4. Operation 198 In this section, we explain a use case for the TTL TLV with an MPLS 199 MS-PW. 200 <------------------MS-PW ---------------------> 202 A B C D E 203 o -------- o -------- o --------- o --------- o 204 ---MPLS Echo Request---> 205 <--MPLS Echo Reply------ 207 Figure 2: Use-case with MS-PWs 209 Let us assume a MS-PW going through LSRs A, B, C, D, and E. 210 Furthermore, assume that an operator wants to perform a connectivity 211 check between B and D from B. Thus, an MPLS Echo Request with the TTL 212 TLV is originated from B and sent towards D. The MPLS Echo Request 213 packet contains the FEC of the PW Segment between C and D. The value 214 field of the TTL TLV and the TTL field of the MPLS label are set to 215 2, the choice of the value 2 will be based on the operator input 216 requesting the MPLS Echo Request or from the optional LDP switching 217 point TLV. The MPLS Echo Request is intercepted at D because of TTL 218 expiry. D detects the TTL TLV in the request, and use the TTL value 219 (i.e., 2) specified in the TLV on the MPLS label of the MPLS Echo 220 Reply. The MPLS Echo Reply will be intercepted by B because of TTL 221 expiry. 223 The same operation will apply when we have a co-routed bidirectional 224 LSP, and we want to check connectivity from an intermediate LSR "B" 225 to another LSR "D". 227 4.1. Traceroute mode 229 In traceroute mode, the TTL value in the TLV is set to 1 for the 230 first Echo Request, then to 2 for the next, and so on. This is 231 similar to the TTL values used for the label set on the packet. 233 4.2. Error scenario 235 It is possible that the MPLS Echo Request packet was intercepted 236 before the intended destination for reason other than label TTL 237 expiry. This could be due network faults, misconfiguration or other 238 reasons. In such cases, if the return TTL is set to the value 239 specified in the TTL TLV then the echo response packet will continue 240 beyond the originating node. This becomes a security issue. 242 To prevent this, the label TTL value used in the MPLS Echo Reply 243 packet MUST be modified by deducting the incoming label TTL on the 244 received packet from TTL TLV value. If the MPLS Echo Request packet 245 is punted to the CPU before the incoming label TTL is deducted, then 246 another 1 MUST be added. In other words: 248 Return TTL Value on the MPLS Echo Reply packet = (TTL TLV Value)- 249 (Incoming Label TTL) + 1 251 5. Security Considerations 253 This draft allows the setting of the TTL value in the MPLS Label of 254 an MPLS Echo Reply, so that it can be intercepted by an intermediate 255 device. This can cause a device to get a lot of LSP Ping packets 256 which get redirected to the CPU. 258 However the same is possible even without the changes mentioned in 259 this document. A device should rate limit the LSP ping packets 260 redirected to the CPU so that the CPU is not overwhelmed. 262 The recommendation in [RFC4379] security section applies, to check 263 the source address of the MPLS Echo Request, however the source 264 address can now be any node along the LSP path. 266 A faulty transit node changing the TTL TLV value could make the wrong 267 node reply to the MPLS Echo Request, and/or the wrong node to receive 268 the MPLS Echo Reply. An LSP trace may help identify the faulty 269 transit node. 271 6. IANA Considerations 273 IANA is requested to assign TLV type value to the following TLV from 274 the "Multiprotocol Label Switching Architecture (MPLS) Label Switched 275 Paths (LSPs) Parameters - TLVs" registry, "TLVs and sub-TLVs" sub- 276 registry. 278 Time To Live TLV (See Section 3). The value MUST be assigned from the 279 range (32768-49161) of optional TLVs. 281 IANA is requested to allocate the value 32769. 283 7. Acknowledgements 285 The authors would like to thank Greg Mirsky for his comments. 287 8. References 289 8.1 Normative References 291 [1] K. Kompella, G. Swallow, "Detecting Multi-Protocol Label Switched 292 (MPLS) Data Plane Failures", RFC 4379, February 2006. 294 [2] T. Nadeau, et. al, "Pseudowire Virtual Circuit Connectivity 295 Verification (VCCV): A Control Channel for Pseudowires ", RFC 5085, 296 December 2007. 298 [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement 299 Levels", BCP 14, RFC 2119, March 1997. 301 Authors' Addresses 303 Sami Boutros 304 Cisco Systems, Inc. 305 3750 Cisco Way 306 San Jose, California 95134 307 USA 308 Email: sboutros@cisco.com 309 Siva Sivabalan 310 Cisco Systems, Inc. 311 2000 Innovation Drive 312 Kanata, Ontario, K2K 3E8 313 Canada 314 Email: msiva@cisco.com 316 George Swallow 317 Cisco Systems, Inc. 318 300 Beaver Brook Road 319 Boxborough , MASSACHUSETTS 01719 320 United States 321 Email: swallow@cisco.com 323 Shaleen Saxena 324 Cisco Systems, Inc. 325 1414 Massachusetts Avenue 326 Boxborough , MASSACHUSETTS 01719 327 United States 328 Email: ssaxena@cisco.com 330 Vishwas Manral 331 Hewlett Packard Co. 332 19111 Pruneridge Ave, 333 Cupertino, CA 95014 USA 334 United States 335 EMail: vishwas.manral@hp.com 337 Michael Wildt 338 Cisco Systems, Inc. 339 1414 Massachusetts Avenue 340 Boxborough , MASSACHUSETTS 01719 341 United States 342 Email: mwildt@cisco.com 344 Sam Aldrin 345 Huawei Technologies, Inc. 346 1188 Central Express Way, 347 Santa Clara, CA 95051 348 United States 349 Email: aldrin.ietf@gmail.com