idnits 2.17.1 draft-delregno-pwe3-vccv-mandatory-features-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 : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RFC5085]), 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 -- The document date (October 15, 2010) is 4942 days in the past. Is this intentional? Checking references for intended status: Best Current Practice ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) No issues found here. Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group N. Del Regno, Ed. 3 Internet-Draft Verizon 4 Intended status: BCP V. Manral, Ed. 5 Expires: April 18, 2011 IPInfusion Inc. 6 R. Kunze 7 M. Paul 8 Deutsche Telekom 9 T. Nadeau 10 Huawei 11 October 15, 2010 13 Mandatory Features of Virtual Circuit Connectivity Verification 14 Implementations 15 draft-delregno-pwe3-vccv-mandatory-features-02 17 Abstract 19 Pseudowire Virtual Circuit Connectivity Verification (VCCV) [RFC5085] 20 defines several Control Channel (CC) Types for MPLS PW's , none of 21 which are preferred or mandatory. As a result, independent 22 implementations of different subsets of the three options have 23 resulted in interoperability challenges. In RFC5085 the CV type of 24 LSP Ping is made the default for MPLS PW's and ICMP Ping is made 25 optional. This however, is a recommendation and not a requirement 26 for implementations which can also lead to interoperability 27 challenges. 29 To enable interoperability between implementations, this document 30 defines a subset of control channels that is considered mandatory for 31 VCCV implementation. This will ensure that VCCV remains the valuable 32 tool it was designed to be in multi-vendor, multi-implementation and 33 multi-carrier networks. This document also states requirements for 34 the CV type too. 36 This draft is specific to MPLS PW's and not L2TPv3 PW. For the 37 L2TPv3 PW only one CC and CV type are specified and the issues raised 38 in this draft do not arise. 40 Requirements Language 42 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 43 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 44 document are to be interpreted as described in RFC 2119 [RFC2119]. 46 Status of this Memo 48 This Internet-Draft is submitted in full conformance with the 49 provisions of BCP 78 and BCP 79. 51 Internet-Drafts are working documents of the Internet Engineering 52 Task Force (IETF). Note that other groups may also distribute 53 working documents as Internet-Drafts. The list of current Internet- 54 Drafts is at http://datatracker.ietf.org/drafts/current/. 56 Internet-Drafts are draft documents valid for a maximum of six months 57 and may be updated, replaced, or obsoleted by other documents at any 58 time. It is inappropriate to use Internet-Drafts as reference 59 material or to cite them other than as "work in progress." 61 This Internet-Draft will expire on April 18, 2011. 63 Copyright Notice 65 Copyright (c) 2010 IETF Trust and the persons identified as the 66 document authors. All rights reserved. 68 This document is subject to BCP 78 and the IETF Trust's Legal 69 Provisions Relating to IETF Documents 70 (http://trustee.ietf.org/license-info) in effect on the date of 71 publication of this document. Please review these documents 72 carefully, as they describe your rights and restrictions with respect 73 to this document. Code Components extracted from this document must 74 include Simplified BSD License text as described in Section 4.e of 75 the Trust Legal Provisions and are provided without warranty as 76 described in the Simplified BSD License. 78 Table of Contents 80 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 81 2. Comparison of Alternative Control Channel Types . . . . . . . . 4 82 2.1. Control Channel Type 1: Control Word . . . . . . . . . . . 4 83 2.2. Control Channel Type 2: MPLS Router Alert Label . . . . . 5 84 2.3. Control Channel Type 3: MPLS PW Label with TTL == 1 . . . 6 85 3. Mandatory Control Channels . . . . . . . . . . . . . . . . . . 6 86 4. Mandatory CV Types . . . . . . . . . . . . . . . . . . . . . . 7 87 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 88 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 89 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8 90 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 91 8.1. Normative References . . . . . . . . . . . . . . . . . . . 8 92 8.2. Informative References . . . . . . . . . . . . . . . . . . 8 93 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 95 1. Introduction 97 [RFC5085] defines three Control Channel types for MPLS PW's: Type 1, 98 using the Pseudowire Control Word, Type 2, using the Router Alert 99 Label, and Type 3, using TTL Expiration (e.g. MPLS PW Label with TTL 100 == 1). While Type 2 (RA Label) is indicated as being "the preferred 101 mode of VCCV operation when the Control Word is not present," RFC 102 5085 does not indicate a mandatory Control Channel to ensure 103 interoperable implementations. The closest it comes to mandating a 104 control channel is the requirement to support Type 1 (Control Word) 105 whenever the control word is present. As such, the three options 106 yield seven implementation permutations (assuming you have to support 107 at least one Control Channel type to provide VCCV). Many equipment 108 manufacturers have gravitated to two common implementation camps: 1) 109 Control Word and Router Alert Label support, or 2) TTL Expiration 110 support only. 112 As a result, service providers are often faced with diametrically 113 opposed support for VCCV Control Channel types when deploying mixed 114 vendor networks. As long as operators select vendors from within a 115 camp, VCCV can be used as the valuable fault-detection and diagnostic 116 mechanism it was created to be. However, due to myriad other 117 unrelated requirements associated with large router requirement 118 specifications and related acquisitions, practice has shown it to be 119 impractical to deploy equipment from only one camp or the other. As 120 a result, this mismatch of support between camps often leads to a 121 service provider's inability to use an important operational tool in 122 networks supporting Layer 2 VPN services. 124 This document discusses the three Control Channel options, presents 125 pros and cons of each approach and concludes with which Control 126 Channel an implementation is required to implement. 128 This document also puts an explicit reqirement on the CV type to be 129 supported for MPLS PW. 131 2. Comparison of Alternative Control Channel Types 133 The following section presents a review of each control channel type 134 and the pros and cons of implementing each. 136 2.1. Control Channel Type 1: Control Word 138 As noted in [RFC5085], an in-band control channel is ideal, since 139 this ensures that the connectivity verification messages follow the 140 same path as the PWE3 traffic. VCCV Control Channel Type 1, also 141 known as "PWE3 Control Word with 0001b as first nibble," is the only 142 "in-band" control channel specified. It uses the control word as 143 opposed to using the label to indicate the presence of the 144 Connectivity Verification message (CV). This ensures that the 145 control channel follows the forwarding path of the associated traffic 146 in all cases, including in the case of ECMP hashing. 148 The use of the control word is not mandatory on all PWE3 149 encapsulations. However based on the current hardware support the 150 draft strongly suggest that all implementations SHOULD generically 151 support the use of VCCV Control Channel Type 1 for all PWE3 152 encapsulations. 154 2.2. Control Channel Type 2: MPLS Router Alert Label 156 VCCV Control Channel Type 2 is also referred to as "MPLS Router Alert 157 Label." In this approach, the VCCV control channel is created by 158 using the MPLS router alert label [RFC3032] (e.g. Label Value = 1) 159 immediately above the pseudowire label. As this label is inserted 160 above the pseudowire label and below the PSN tunnel label, 161 intermediate label switch routers do not act on the label. However, 162 at the egress router, when the PSN tunnel label is popped and the 163 next label is examined, the label value of 1 will cause the packet to 164 be delivered to a local software module for further processing (e.g. 165 processing of the VCCV Connectivity Verification (CV) message). 166 Similarly, in the case of penultimate hop-popping, the labeled packet 167 arrives with it's top-most label having a label value = 1, causing it 168 to be delivered to a local software module for further processing. 170 As the processing behavior associated with Router Alert labels is 171 germane to all MPLS implementations, VCCV Control Channel Type 2 172 should be supported by all implementations. However, there are 173 issues with using Router Alert labels in operational networks. 174 First, there are known issues related to the use of the Router Alert 175 label and possible security risks associated with DoS attacks. While 176 this is less of a risk in closed networks, this becomes a larger 177 potential issue in inter-provider networks. Second, unlike use of 178 the Control Word, inserting a label between the PSN tunnel label and 179 the pseudowire label has ECMP implications, resulting in the very 180 real possibility of the VCCV Control Channel diverging from the path 181 of the associated traffic. While ECMP issues arise from both non- 182 control-word control channels, given the security risks of using the 183 Router Alert label, the VCCV Control Channel Type 2 cannot be 184 mandatory for VCCV implementations. 186 All implementations MAY support VCCV Control Channel Type 2 so that 187 operators who choose to use this approach can do so in mixed- 188 implementation environments. Further, Router Alert Label MUST 189 contain an appropriate TTL value, such that the TTL value does not 190 cause the CPU exception in any intermediate device in case of PHP. 192 2.3. Control Channel Type 3: MPLS PW Label with TTL == 1 194 VCCV Control Channel Type 3 is also known as "MPLS PW Label with TTL 195 == 1." Unlike VCCV Control Channel Type 2, this approach uses the 196 existing pseudowire label to indicate the need for further 197 processing. Upon receiving the labeled packet, whether accompanied 198 by a PSN tunnel label or alone (in the case of penultimate hop 199 popping), the egress router makes a forwarding decision based on the 200 Label Value, assuming the TTL is greater than or equal to 2. 201 However, as part of this process and prior to forwarding the contents 202 of the labeled packet to the attachment circuit (AC), the TTL is 203 decremented. If the TTL value of the received packet was equal to 1, 204 the TTL is decremented to 0, causing the packet to be sent to the 205 control plane for processing. 207 Unlike the Router Alert Label (Label Value == 1), there has been no 208 standardization of the pseudowire label TTL to this point. For 209 example, [RFC3985], one of the only PWE3 RFCs to address TTL at all, 210 states that "when a MPLS label is used as a PW Demultiplexer, setting 211 of the TTL value in the PW label is application specific." However, 212 no subsequent RFCs have defined the default value of the TTL field 213 within the PW demultiplexer. With the advent of VCCV, it became 214 clear that a TTL value greater than 1 was needed. Many 215 implementations have settled on a default value of 2 for single- 216 segment pseudowires, as evidenced by subsequent MIB drafts in which 217 the default value of 2 is alluded to, if not explicitly defined. 218 Consequently, implementations vary widely with regard to the default 219 value of the TTL field and the subsequent behavior when the TTL is 220 decremented to 0, if it is decremented at all. 222 Similar to VCCV CC Type 2, changing the value of the TTL in the 223 existing PW demultiplexer label to something different from the value 224 of the labels accompanying the associated traffic, can result in the 225 VCCV Control Channel messages diverging from the path of the 226 associated traffic when ECMP is employed. 228 Implementations MUST support the use of this option. 230 3. Mandatory Control Channels 232 Implementations of VCCV, at a minimum, MUST support VCCV Control 233 Channel Type 3: MPLS PW Label with TTL == 1. Implementations of VCCV 234 MUST also set the default TTL value of the PW demultiplexer label to 235 2 for single-segment pseudowires. Further, implementations of VCCV 236 MUST decrement the TTL of the PW demultiplexer label in the egress 237 PE, and upon reaching a TTL==0, MUST pass the packet to the control 238 plane for further processing of the VCCV message contained therein. 239 This provides a basic level of interoperability across all 240 implementations of VCCV without mandating the use of the control word 241 for all VCCV-enabled pseudowire applications. Further, as VCCV is 242 applied to multi-segment pseudowires, using Control Channel Type 3 243 enables PW traceroute to be implemented in a manner similar to that 244 of MPLS and IP traceroute, through the incrementing of the TTL value 245 in subsequent probes. 247 As noted previously, this baseline level of VCCV support does not 248 address the aforementioned ECMP issues. Consequently, 249 implementations of VCCV SHOULD support VCCV Control Channel Type 1 250 for pseudowire encapsulations for which a control word is not 251 mandatory. 253 Implementations of VCCV MUST support VCCV Control Channel Type 1: 254 Control Word for all implemented pseudowire encapsulations where use 255 of the Control Word is mandatory. Implementations SHOULD support 256 VCCV Control Channel Type 1 for implemented pseudowire encapsulations 257 where, although optional, use of the control word is elected, on a 258 pseudowire-by-pseudowire basis. 260 Implementations of VCCV MUST support the appropriate signaling of 261 VCCV Control Channel Type support in the pseudowire setup signaling. 262 In order to avoid interoperability issues, implementations should 263 negotiate VCCV Control Channel Type, in decreasing priority: Type 1 264 (Control Word), Type 3 (TTL Expiration) and Type 2 (Router Alert), 265 when all, or any permutation of the three CC Types are supported. 267 4. Mandatory CV Types 269 For MPLS PWs, the CV Type of LSP Ping (0x02) MUST be supported, and 270 the CV Type of ICMP Ping (0x01) MAY be supported. 272 5. IANA Considerations 274 This document makes no request of IANA. 276 Note to RFC Editor: this section may be removed on publication as an 277 RFC. 279 6. Security Considerations 281 This document describes the VCCV Control Channels which MUST be 282 implemented to ensure interoperability in a mixed-implementation 283 environment. This document does not change the basic functionality 284 associated with VCCV. As a result, no additional security issues are 285 raised by this document over those already identified in [RFC5085]. 287 7. Acknowledgements 289 8. References 291 8.1. Normative References 293 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 294 Requirement Levels", BCP 14, RFC 2119, March 1997. 296 8.2. Informative References 298 [RFC3032] Rosen, E., "MPLS Label Stack Encoding", January 2001. 300 [RFC3985] Bryant, S., "Pseudo Wire Emulation Edge-to-Edge (PWE3) 301 Architecture", March 2005. 303 [RFC5085] Nadeau, T., "Pseudowire Virtual Circuit Connectivity 304 Verification (VCCV): A Control Channel for Pseudowires", 305 December 2007. 307 Authors' Addresses 309 Nick Del Regno (editor) 310 Verizon 311 400 International Pkwy 312 Richardson, TX 75081 313 US 315 Phone: 972-729-3411 316 Fax: 317 Email: nick.delregno@verizon.com 318 URI: 320 Vishwas Manral (editor) 321 IPInfusion Inc. 322 1188 E. Arques Ave. 323 Sunnyvale, CA 94085 324 US 326 Phone: 408-400-1900 327 Fax: 328 Email: vishwas@ipinfusion.com 329 URI: 331 Ruediger Kunze 332 Deutsche Telekom 334 Phone: 335 Fax: 336 Email: Ruediger.Kunze@telekom.de 337 URI: 339 Manuel Paul 340 Deutsche Telekom 342 Phone: 343 Fax: 344 Email: Manuel.Paul@telekom.de 345 URI: 347 Thomas Nadeau 348 Huawei 350 Phone: 351 Fax: 352 Email: tnadeau@lucidvision.com 353 URI: