idnits 2.17.00 (12 Aug 2021) /tmp/idnits33947/draft-ietf-pals-vccv-for-gal-06.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 (September 24, 2015) is 2424 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 4447 (Obsoleted by RFC 8077) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 PALS T. Nadeau 3 Internet-Draft lucidvision 4 Intended status: Standards Track L. Martini 5 Expires: March 27, 2016 S. Bryant 6 Cisco Systems 7 September 24, 2015 9 Using A Generic Associated Channel Label as a Virtual Circuit 10 Connectivity Verification Channel Indicator 11 draft-ietf-pals-vccv-for-gal-06 13 Abstract 15 The Virtual Circuit Connectivity Verification (VCCV) protocol 16 specified in RFC 5085 provides a control channel (CC) that is 17 associated with a pseudowire (PW). This document specifies an 18 additional VCCV control channel type to be used with pseudowires (PW) 19 which do not use the PW Control Word and which are carried over an 20 MPLS network. This new VCCV CC type uses the Generic Associated 21 Channel Label defined in RFC5586 to distinguish VCCV packets from 22 packets carrying user data. This new VCCV CC type introduces 23 compatibility with the method of MPLS Label Switched Path Operations, 24 Administration, and Maintenance (OAM) identification, particularly in 25 MPLS Transport Profile (MPLS-TP) networks (RFC5921). 27 Status of This Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at http://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on March 27, 2016. 44 Copyright Notice 46 Copyright (c) 2015 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (http://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 62 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 63 3. Type 4 MPLS VCCV Control Channel Type . . . . . . . . . . . . 3 64 4. FAT PWs . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 65 5. Multi-Segment Pseudowires . . . . . . . . . . . . . . . . . . 5 66 6. VCCV Capability Advertisement . . . . . . . . . . . . . . . . 5 67 7. Manageability Considerations . . . . . . . . . . . . . . . . 6 68 8. Security Considerations . . . . . . . . . . . . . . . . . . . 6 69 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 70 9.1. MPLS VCCV Control Channel (CC) Type 4 . . . . . . . . . . 7 71 9.2. LDP Status Code . . . . . . . . . . . . . . . . . . . . . 7 72 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 7 73 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 74 11.1. Normative References . . . . . . . . . . . . . . . . . . 7 75 11.2. Informative References . . . . . . . . . . . . . . . . . 8 76 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 78 1. Introduction 80 The Virtual Circuit Connectivity Verification (VCCV) protocol is 81 specified in RFC 5085 [RFC5085]. This document specifies a new VCCV 82 control channel (VCCV CC) type to be used with pseudowires (PW) 83 carried over an MPLS network that do not use the PW Control Word (CW) 84 [RFC4385]. This new VCCV CC type uses the Generic Associated Channel 85 Label (GAL) [RFC5586] to distinguish VCCV packets from packets 86 carrying user data. This new VCCV CC type provides compatibility 87 with the method of MPLS Label Switched Path (LSP) Operations, 88 Administration, and Maintenance (OAM) message identification, as used 89 in MPLS Transport Profile (MPLS-TP) networks [RFC5921]. 91 VCCV currently specifies three CC types. VCCV CC Type 1 uses the PW 92 Control Word (CW) to distinguish VCCV packets from packets carrying 93 user data. VCCV CC Types 2 and 3 require IP encapsulation for OAM 94 packets. This was not an issue when [RFC5085] was designed, but is 95 in conflict with the design goals of MPLS-TP [RFC5921] which does not 96 otherwise require the availability of IP. VCCV CC Type 2 is not 97 applicable to Multi-Segment PWs (MS-PWs) [RFC6073]. A MS-PW 98 operating without the CW therefore has to use VCCV CC Type 3 which 99 identifies VCCV packets on the basis of Time to Live (TTL) expiry. 100 Whilst less of an issue with a single segment PW (SS-PW), on an MS-PW 101 this requires accurately setting the TTL for expiry at the egress 102 Terminating Provider Edge (T-PE) [RFC6073]. In the event of an error 103 in the setting of the PW Label Stack Entry (LSE) TTL, VCCV packets 104 will not be received by the Terminating Provider Edge (T-PE) and may 105 leak into the attachment circuit [RFC6073]. The new VCCV CC type 106 defined in this specification addresses these problems for PWs that 107 do not use the CW. 109 Note that mandating PWs use the PW CW is not a viable way to address 110 this issue. This is because: 112 o PWs without the CW are already widely deployed. 114 o There is a significant deployment of existing hardware that does 115 not support usage of the PW CW for some PW types. 117 o Some operators are concerned that the inclusion of the PW CW will 118 increase the PW packet size. 120 2. Requirements Language 122 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 123 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 124 "OPTIONAL" in this document are to be interpreted as described in 125 [RFC2119]. 127 3. Type 4 MPLS VCCV Control Channel Type 129 When the PW CW is not used, the Type 4 MPLS VCCV Control Channel (CC) 130 type defined in this section MAY be used. This is referred to as 131 VCCV CC Type 4 throughout the rest of this of this document. VCCV CC 132 Type 4 uses the encapsulation shown in Figure 1 in which the presence 133 of a GAL at the end of the MPLS label stack indicates that the packet 134 carries a VCCV message. 136 0 1 2 3 137 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 139 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 140 | PW LSE | 141 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 142 | GAL LSE | 143 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 144 |0 0 0 1|Version| Reserved | Channel Type | 145 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 146 | | 147 ~ VCCV Message Body ~ 148 | | 149 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 151 Figure 1 153 The VCCV message body is preceded by a Generic Associated Channel 154 Header as defined in [RFC5586], in which the Channel Type identifies 155 the type and format of the OAM message carried in the VCCV message 156 body. 158 The GAL LSE MUST contain the GAL reserved label as defined in 159 [RFC5586]. 161 The PW LSE is constructed according to the existing procedures that 162 apply to the type of pseudowire that is in use. 164 Where the LSP used by the PW is subject to Equal-Cost Multi-path 165 (ECMP) load balancing, a problem arises if any LSR on that LSP treats 166 special purpose labels as ordinary labels in its ECMP selection 167 method. In these circumstances the inclusion of a GAL following the 168 PW LSE can cause the OAM packet to take a different path through the 169 network from the corresponding PW data packets. If the LSP traverses 170 such equipment and this behaviour is not acceptable, then an 171 alternative VCCV type needs to be used. The requirement to not 172 include special-purpose labels in the load-balancing decision is 173 described in "MPLS Forwarding Compliance and Performance 174 Requirements" [RFC7325]. For equipment that conforms to this, the 175 VCCV type 4 traffic will follow the corresponding PW data packets. 177 4. FAT PWs 179 [RFC6391] specifies that when the flow-aware transport (FAT) of 180 pseudowires over an MPLS packet switched network has been signalled 181 or configured, the Flow LSE MUST be present. It further specifies 182 that "the flow label MUST NOT be an MPLS reserved label (values in 183 the range 0..15) [RFC3032]", and that "If a flow LSE is present, it 184 MUST be checked to determine whether it carries a reserved label. If 185 it is a reserved label, the packet is processed according to the 186 rules associated with that reserved label; otherwise, the LSE is 187 discarded." 189 This document specifies that if the flow-aware transport of 190 pseudowires over an MPLS packet switched network has been signalled 191 or configured then the presence of VCCV message is indicated by the 192 use of a GAL in place of the flow LSE. 194 This is consistent with [RFC6391], and the packet structure is 195 identical to that shown in Figure 1. 197 Flow LSEs are inserted into a PW label stack in order to enable the 198 distribution of the PW traffic among multiple equal cost MPLS paths. 199 The use of GAL in place of the flow label will cause all OAM packets 200 to take exactly one of these paths, and this path may be different 201 from the paths taken by any of traffic flows. If this is not 202 acceptable, then an alternative VCCV type needs be used. 204 5. Multi-Segment Pseudowires 206 When using VCCV CC Type 4 for MS-PWs, a PE transmitting the VCCV 207 packet to a Switching PE (S-PE) MUST set the TTL to the appropriate 208 value to expire at that S-PE. An S-PE that supports this 209 specification MUST inspect PW packets that are received as a result 210 of TTL expiry, and determine whether a GAL follows the PW LSE. If a 211 GAL is present the S-PE then processes the VCCV packet. 213 An S-PE that does not support this specification would be expected to 214 reject as malformed a VCCV CC Type 4 packet that was received. This 215 is because the S-PE would expect the PW LSE to be bottom of stack 216 (the non FAT case) and for the LSE at bottom of stack not to be a 217 reserved label (both the FAT and the non-FAT cases). An S-PE that 218 did not make this reserved label check would then find that the first 219 nibble following the label stack was 0x1 and not the expected start 220 of an IP packet. It would hence be expected to also reject the 221 packet. This update to the behaviour of S-PEs is therefore backwards 222 compatible. 224 6. VCCV Capability Advertisement 226 The VCCV capability advertisement MUST match the c-bit setting that 227 is advertised in the PW FEC element [RFC4447]. If the c-bit is set, 228 indicating the use of the PW CW, then VCCV CC Type 4 MUST NOT be 229 advertised. If the c-bit is not set, indicating that the PW CW is 230 not in use, then equipment supporting this specification MUST 231 advertise VCCV CC Type 4. Advertisement of VCCV CC Types 1 and 4 are 232 therefore mutually exclusive. 234 A PE supporting VCCV CC Type 4 MAY advertise other VCCV CC types as 235 defined in [RFC5085] . 237 If the remote PE supports VCCV CC Type 4, and the PW CW is not in 238 use, then for cases where multiple CC Types are advertised, the 239 following precedence rules apply when choosing which CC Type to use: 241 1. Type 4: GAL VCCV Control Channel. 243 2. Type 2: MPLS Router Alert Label. 245 3. Type 3: MPLS PW Label with TTL == 1. 247 If the remote PE finds that VCCV CC Types 1 and 4 are both 248 advertised, or that c-bit is set and VCCV CC Type 4 is advertised, 249 then it should report the error to the operator through the 250 management interface in use, and send a Label Release Message with a 251 status code "VCCV Type Error". 253 7. Manageability Considerations 255 Whilst the introduction of this additional VCCV CC type increases the 256 number of VCCV CC types that the operator needs to manage, it 257 addresses the issues with VCCV CC Types 2 and 3 described in 258 Section 1. 260 In the event of a misconfiguration of this VCCV CC type, the PW is 261 taken out of service and the operator advised as described in 262 Section 6. 264 Attention is drawn to the possible absence of fate sharing between PW 265 data packets and VCCV CC Type 4 packets described in Section 3 and 266 Section 4. 268 8. Security Considerations 270 This document does not by itself raise any new security 271 considerations beyond those described in [RFC5085] and [RFC6073]. 272 [RFC6073] provides detailed operational procedures which can be used 273 to verify the MS-PW connectivity. In addition, the procedure 274 specified in this document eliminates the possibility of packet 275 leaking that can occur with VCCV Type 3. 277 9. IANA Considerations 279 9.1. MPLS VCCV Control Channel (CC) Type 4 281 IANA is requested to assign a new bit from the MPLS VCCV Control 282 Channel (CC) Types registry in the PWE3-parameters name space in 283 order to identify VCCV type 4. It is requested that Bit 3 be 284 assigned to this purpose which would have a value of 0x08. 286 MPLS VCCV Control Channel (CC) Types 288 Bit (Value) Description Reference 289 ============ =========== ================== 290 Bit X (0x0Y) Type 4: GAL This Specification 292 9.2. LDP Status Code 294 IANA is requested to assign a new Status Code from the Label 295 Distribution Protocol (LDP) Parameters name space: 297 Status Code Name Space 299 Range/Value E Description Reference 300 =========== = =============== ========= 301 0x000000xx 0 VCCV Type Error This Specification 303 10. Acknowledgments 305 The authors wish to thank Alexander (Sasha) Vainshtein for his 306 proposal to make the GAL and Flow labels mutually exclusive. This 307 proposal led to a significant simplification of this design. The 308 authors also thank Sasha, Matthew Bocci, Loa Andersson and Deborah 309 Brungard for their review comments. 311 11. References 313 11.1. Normative References 315 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 316 Requirement Levels", BCP 14, RFC 2119, 317 DOI 10.17487/RFC2119, March 1997, 318 . 320 [RFC4385] Bryant, S., Swallow, G., Martini, L., and D. McPherson, 321 "Pseudowire Emulation Edge-to-Edge (PWE3) Control Word for 322 Use over an MPLS PSN", RFC 4385, DOI 10.17487/RFC4385, 323 February 2006, . 325 [RFC4447] Martini, L., Ed., Rosen, E., El-Aawar, N., Smith, T., and 326 G. Heron, "Pseudowire Setup and Maintenance Using the 327 Label Distribution Protocol (LDP)", RFC 4447, 328 DOI 10.17487/RFC4447, April 2006, 329 . 331 [RFC5085] Nadeau, T., Ed. and C. Pignataro, Ed., "Pseudowire Virtual 332 Circuit Connectivity Verification (VCCV): A Control 333 Channel for Pseudowires", RFC 5085, DOI 10.17487/RFC5085, 334 December 2007, . 336 [RFC5586] Bocci, M., Ed., Vigoureux, M., Ed., and S. Bryant, Ed., 337 "MPLS Generic Associated Channel", RFC 5586, 338 DOI 10.17487/RFC5586, June 2009, 339 . 341 [RFC6073] Martini, L., Metz, C., Nadeau, T., Bocci, M., and M. 342 Aissaoui, "Segmented Pseudowire", RFC 6073, 343 DOI 10.17487/RFC6073, January 2011, 344 . 346 [RFC6391] Bryant, S., Ed., Filsfils, C., Drafz, U., Kompella, V., 347 Regan, J., and S. Amante, "Flow-Aware Transport of 348 Pseudowires over an MPLS Packet Switched Network", 349 RFC 6391, DOI 10.17487/RFC6391, November 2011, 350 . 352 11.2. Informative References 354 [RFC5921] Bocci, M., Ed., Bryant, S., Ed., Frost, D., Ed., Levrau, 355 L., and L. Berger, "A Framework for MPLS in Transport 356 Networks", RFC 5921, DOI 10.17487/RFC5921, July 2010, 357 . 359 [RFC7325] Villamizar, C., Ed., Kompella, K., Amante, S., Malis, A., 360 and C. Pignataro, "MPLS Forwarding Compliance and 361 Performance Requirements", RFC 7325, DOI 10.17487/RFC7325, 362 August 2014, . 364 Authors' Addresses 366 Thomas D. Nadeau 367 lucidvision 369 Email: tnadeau@lucidvision.com 370 Luca Martini 371 Cisco Systems 373 Email: lmartini@cisco.com 375 Stewart Bryant 376 Cisco Systems 378 Email: stbryant@cisco.com