idnits 2.17.1 draft-ietf-mpls-lsp-ping-ttl-tlv-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: ---------------------------------------------------------------------------- == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 60 lines 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 (June 29, 2011) is 4678 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: '1' is defined on line 215, but no explicit reference was found in the text == Unused Reference: '2' is defined on line 219, 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 (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Sami Boutros (Ed.) 3 Internet Draft Siva Sivabalan (Ed.) 4 Intended status: Standards Track George Swallow 5 Expires: September 2011 Shaleen Saxena 6 Cisco Systems, Inc. 8 Vishwas Manral 9 IPInfusion, Inc. 10 June 29, 2011 12 Definition of Time-to-Live TLV for LSP-Ping Mechanisms 13 draft-ietf-mpls-lsp-ping-ttl-tlv-00.txt 15 Abstract 17 LSP-Ping is a widely deployed Operation, Administration, and 18 Maintenance (OAM) mechanism in MPLS networks. However, in the present 19 form, this mechanism is inadequate to verify connectivity of a 20 segment of a Multi-Segment PseudoWire (MS-PW) from any node on the 21 path of the MS-PW. This document defines a TLV to address this 22 shortcoming. 24 Requirements Language 26 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 27 NOT","SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 28 this document are to be interpreted as described in RFC 2119 [3]. 30 Status of this Memo 32 This Internet-Draft is submitted to IETF 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), its areas, and its working groups. Note that 37 other groups may also distribute working documents as Internet- 38 Drafts. 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 The list of current Internet-Drafts can be accessed at 46 http://www.ietf.org/ietf/1id-abstracts.txt 47 The list of Internet-Draft Shadow Directories can be accessed at 48 http://www.ietf.org/shadow.html 50 This Internet-Draft will expire on December 29, 2011. 52 Copyright Notice 54 Copyright (c) 2010 IETF Trust and the persons identified as the 55 document authors. All rights reserved. 57 This document is subject to BCP 78 and the IETF Trust's Legal 58 Provisions Relating to IETF Documents 59 (http://trustee.ietf.org/license-info) in effect on the date of 60 publication of this document. Please review these documents 61 carefully, as they describe your rights and restrictions with respect 62 to this document. Code Components extracted from this document must 63 include Simplified BSD License text as described in Section 4.e of 64 the Trust Legal Provisions and are provided without warranty as 65 described in the Simplified BSD License. 67 Table of Contents 69 1. Introduction...................................................2 70 2. Terminology....................................................3 71 3. Time To Live TLV...............................................4 72 4. Operation......................................................4 73 5. Security Considerations........................................5 74 6. IANA Considerations............................................5 75 7. References.....................................................5 76 7.1. Normative References......................................5 77 7.2. Informative References....................................6 78 Author's Addresses................................................6 80 1. Introduction 82 A MS-PW can span across multiple service provider networks. In 83 order to allow Service Providers (SP) to verify segments of such MS- 84 PW from any node on the path of the MS-PW, any node along the path of 85 the MS-PW, should be able to originate an LSP-Ping echo request 86 packet to any another node along the path of the MS-PW and receive 87 the corresponding echo reply. If the originator of the echo request 88 is at the end of a MS-PW, the receiver of the request can send the 89 reply back to the sender without knowing the hop-count distance of 90 the originator. For example, the reply will be intercepted by the 91 originator regardless of the TTL value on the reply packet. But, if 92 the originator is not at the end of the MS-PW, the receiver of the 93 echo request MAY need to know how many hops away the originator of 94 the echo request is so that it can set the TTL value on the MPLS 95 header for the echo reply to be intercepted at the originator node. 97 In MPLS networks (also applicable to MPLS-TP), for bidirectional co- 98 routed LSPs, if it is desired to verify connectivity from any 99 intermediate node (LSR) on the LSP to the any other LSR on the LSP 100 the receiver may need to know the TTL to send the Echo reply with, so 101 as the packet is intercepted by the originator node. 103 A new optional TTL TLV is being proposed in this document this TLV 104 will be added by the originator of the echo request to inform the 105 receiver how many hops away the originator is on the path of the MS- 106 PW or Bidirectional LSP. 108 Conventions used in this document 110 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 111 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 112 document are to be interpreted as described in RFC-2119Error! 113 Reference source not found. 115 2. Terminology 117 LSR: Label Switching Router 119 MPLS-OAM: MPLS Operations, Administration and Maintenance 121 MPLS-TP: MPLS Transport Profile 123 MS-PW: Multi-Segment PseudoWire 125 PW: PseudoWire 127 TLV: Type Length Value 129 TTL: Time To Live 131 3. Time To Live TLV 133 0 1 2 3 134 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 135 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 136 | type = TBD | Length = 8 | 137 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 138 | value | 139 +-+-+-+-+-+-+-+-+ 141 Figure 1: Time To Live TLV format 143 The TTL TLV has the format shown in Figure 1. This TLV shall be 144 included in the echo request by the originator of request. The use of 145 this TLV is optional. If the value field is zero, the LSP Ping Echo 146 request packet will be dropped. 148 If a receiver does not understand the TTL TLV, it will simply ignore 149 the TLV (Type value of TLV is assumed to be in the range of optional 150 TLVs which SHOULD be ignored if an implementation does not support or 151 understand them). In the absence of TTL TLV or if TTL TLV is ignored 152 by a receiver, the determination of the TTL value used in the MPLS 153 label on the echo reply is beyond the scope of this document. 155 If a receiver understands the TTL TLV, and the TTL TLV is present in 156 the echo request, the receiver MUST use the TTL value specified in 157 TLV in the MPLS header of the echo reply. 159 In the traceroute mode TTL value in the TLV is successively set to 1, 160 2, and so on. 162 4. Operation 164 In this section, we explain a use case for the TTL TLV with an MPLS 165 MS-PW. 167 <------------------MS-PW ---------------------> 169 A B C D E 170 o -------- o -------- o --------- o --------- o 171 ------Echo Request-----> 172 <-----Echo Reply-------- 174 Figure 2: Use-case with MS-PWs 176 Let us assume a MS-PW going through LSRs A, B, C, D, and E. 177 Furthermore, assume that an operator wants to perform a connectivity 178 check between B and D from B. Thus, an LSP-Ping request with the TTL 179 TLV is originated from B and sent towards D. The echo request packet 180 contains the FEC of the PW Segment between C and D. The value field 181 of the TTL TLV and the TTL field of the MPLS label are set to 2. The 182 echo request is intercepted at D because of TTL expiry. D detects the 183 TTL TLV in the request, and use the TTL value (i.e., 2) specified in 184 the TLV on the MPLS label of the echo reply. The echo reply will be 185 intercepted by B because of TTL expiry. 187 The same operation will apply in the case a co-routed bidirectional 188 LSP and we want to check connectivity from an intermediate LSR B to 189 another LSR D, from B. 191 5. Security Considerations 193 This draft allows the setting of the TTL value in the MPLS Label of 194 an echo reply, so that it can be intercepted by an intermediate 195 device. This can cause a device to get a lot of LSP Ping packets 196 which get redirected to the CPU. 198 However the same is possible even without the changes mentioned in 199 this document. A device should rate limit the LSP ping packets 200 redirected to the CPU so that the CPU is not overwhelmed. 202 6. IANA Considerations 204 IANA is requested to assign TLV type value to the following TLV from 205 the "Multiprotocol Label Switching Architecture (MPLS) Label Switched 206 Paths (LSPs) Parameters - TLVs" registry, "TLVs and sub-TLVs" sub- 207 registry. 209 Time To Live TLV (See Section 3). 211 7. References 213 7.1. Normative References 215 [1] K. Kompella, G. Swallow, "Detecting Multi-Protocol Label 216 Switched (MPLS) Data Plane Failures", RFC 4379, February 217 2006. 219 [2] T. Nadeau, et. al, "Pseudowire Virtual Circuit Connectivity 220 Verification (VCCV): A Control Channel for Pseudowires ", RFC 221 5085, December 2007. 223 [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement 224 Levels", BCP 14, RFC 2119, March 1997. 226 7.2. Informative References 228 Author's Addresses 230 Sami Boutros 231 Cisco Systems, Inc. 232 3750 Cisco Way 233 San Jose, California 95134 234 USA 235 Email: sboutros@cisco.com 237 Siva Sivabalan 238 Cisco Systems, Inc. 239 2000 Innovation Drive 240 Kanata, Ontario, K2K 3E8 241 Canada 242 Email: msiva@cisco.com 244 George Swallow 245 Cisco Systems, Inc. 246 300 Beaver Brook Road 247 Boxborough , MASSACHUSETTS 01719 248 United States 249 Email: swallow@cisco.com 251 Shaleen Saxena 252 Cisco Systems, Inc. 253 1414 Massachusetts Avenue 254 Boxborough , MASSACHUSETTS 01719 255 United States 256 Email: ssaxena@cisco.com 258 Vishwas Manral 259 IPInfusion, Inc. 260 1188 E. Arques Ave., 261 Sunnyvale, CA 94085 262 United States 263 Email: vishwas@ipinfusion.com