idnits 2.17.1 draft-ietf-pals-vccv-for-gal-03.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 (March 6, 2015) is 3338 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 PWE3 T. Nadeau 3 Internet-Draft lucidvision 4 Intended status: Standards Track L. Martini 5 Expires: September 7, 2015 S. Bryant 6 Cisco Systems 7 March 6, 2015 9 Using GAL as a VCCV Channel Indicator 10 draft-ietf-pals-vccv-for-gal-03 12 Abstract 14 This document specifies a new Virtual Circuit Connectivity 15 Verification (VCCV) (RFC5085) control channel type for use with 16 pseudowires (PW) carried over an MPLS network. This new channel type 17 uses the Generic Associated Channel Label (GAL) (RFC5586) to 18 distinguish VCCV packets from packets carrying user data. 20 Status of This Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at http://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on September 7, 2015. 37 Copyright Notice 39 Copyright (c) 2015 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 55 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 56 3. GAL VCCV Control Channel Type . . . . . . . . . . . . . . . . 3 57 4. FAT PWs . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 58 5. Multi-Segment Pseudowires . . . . . . . . . . . . . . . . . . 5 59 6. VCCV Capability Advertisement . . . . . . . . . . . . . . . . 5 60 7. Manageability Considerations . . . . . . . . . . . . . . . . 6 61 8. Security Considerations . . . . . . . . . . . . . . . . . . . 6 62 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 63 9.1. MPLS VCCV Control Channel (CC) Type 4 . . . . . . . . . . 6 64 9.2. LDP Status Code . . . . . . . . . . . . . . . . . . . . . 6 65 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 7 66 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 67 11.1. Normative References . . . . . . . . . . . . . . . . . . 7 68 11.2. Informative References . . . . . . . . . . . . . . . . . 7 69 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 71 1. Introduction 73 This document specifies a new Virtual Circuit Connectivity 74 Verification (VCCV) [RFC5085] control channel (CC) type for use with 75 pseudowires (PW) carried over an MPLS network that do not use the PW 76 Control Word (CW) [RFC4385]. This new VCCV CC type uses the Generic 77 Associated Channel Label (GAL) [RFC5586] to distinguish VCCV packets 78 from packets carrying user data. This new VCCV CC type introduces 79 compatibility with the method of MPLS Label Switched Path (LSP) 80 Operations, Administration, and Maintenance (OAM) identification, 81 particularly in MPLS-TP networks [RFC5921]. 83 VCCV currently specifies three CC types. VCCV CC Type 1 uses the PW 84 Control Word (CW) to distinguish VCCV packets from packets carrying 85 user data. VCCV CC Types 2 and 3 require IP encapsulation for OAM 86 packets they carry. This was not an issue when [RFC5085] was 87 designed, but is in conflict with the design goals of MPLS Transport 88 Profile (MPLS-TP) [RFC5921] which does not otherwise require the 89 availability of IP. VCCV CC Type 2 is not applicable to multi- 90 segment PWs (MS-PWs) [RFC6073]. A MS-PW operating without the CW 91 therefore has to use VCCV CC Type 3 which identifies VCCV packets on 92 the basis of Time to Live (TTL) expiry. Whilst less of an issue with 93 a single segment PW (SS-PW), on an MS-PW this need to be accurately 94 set to cause TTL expiry at the egress Terminating Provider Edge 95 (T-PE) [RFC6073]. In the event of a error in the setting of the PW 96 Label Stack Entry (LSE) TTL this can result in VCCV packets leaking 97 into the attachment circuit which may disrupt the operation of the 98 PW, or the native service, and is a security risk. The new VCCV CC 99 type defined in this specification addresses these problems for PWs 100 that do not use the CW. 102 Note that mandating that all PWs to use the PW CW is not a viable way 103 to address this issue. This is because: 105 o PWs without the CW are already widely deployed. 107 o There is a significant deployment of existing hardware that does 108 not support usage of the PW CW for some PW types. 110 o Some operators are concerned that the inclusion of the PW CW will 111 increase the PW packet size. 113 2. Requirements Language 115 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 116 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 117 "OPTIONAL" in this document are to be interpreted as described in 118 [RFC2119]. 120 3. GAL VCCV Control Channel Type 122 When the PW CW is not used, the GAL VCCV Control Channel (CC) type 123 defined in this section MAY be used. This is referred to as VCCV CC 124 Type4 throughout the rest of this of this document. VCCV Type 4 uses 125 the encapsulation shown in Figure 1. 127 0 1 2 3 128 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 130 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 131 | PW LSE | 132 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 133 | GAL LSE | 134 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 135 |0 0 0 1|Version| Reserved | Channel Type | 136 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 137 | | 138 ~ VCCV Message Body ~ 139 | | 140 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 142 Figure 1 144 The VCCV message body is preceded by a Generic Associated Channel 145 Header as defined in [RFC5586], in which the Channel Type identifies 146 the type and format of the OAM message carried in the VCCV message 147 body. 149 The GAL LSE MUST contain the GAL reserved label as defined in 150 [RFC5586]. 152 The PW LSE is constructed according to the existing procedures that 153 apply to the type of pseudowire that is in use. 155 Note that the inclusion of a GAL following the PW LSE over a label 156 switched path subject to Equal-Cost Multi-path (ECMP) load balancing 157 can cause the OAM packet to take a different path through the network 158 from the corresponding PW data packets. If that is not acceptable, 159 then an alternative VCCV type needs to be used. 161 4. FAT PWs 163 [RFC6391] specifies that when the flow-aware transport (FAT) of 164 pseudowires over an MPLS packet switched network has been signalled 165 or configured, the Flow LSE MUST be present. It further specifies 166 that "the flow label MUST NOT be an MPLS reserved label (values in 167 the range 0..15) [RFC3032]", and that "If a flow LSE is present, it 168 MUST be checked to determine whether it carries a reserved label. If 169 it is a reserved label, the packet is processed according to the 170 rules associated with that reserved label; otherwise, the LSE is 171 discarded." 173 This document specifies that if the flow-aware transport of 174 pseudowires over an MPLS packet switched network has been signalled 175 or configured then the presence of VCCV message is indicated by the 176 use of a GAL in place of the flow LSE. 178 This is consistent with [RFC6391], and the packet structure is 179 identical to that shown in Figure 1. 181 Flow LSEs are inserted into a PW label stack in order to enable the 182 distribution of the PW traffic among multiple equal cost MPLS paths. 183 The use of GAL in place of the flow label will cause all OAM packets 184 to take exactly one of these paths, and this path may be different 185 from the paths taken by any of traffic flows. If this is not 186 acceptable, then an alternative VCCV type needs be used. 188 5. Multi-Segment Pseudowires 190 When using VCCV CC Type 4 for MS-PWs, a PE transmitting the VCCV 191 packet to a Switching PE (S-PE) MUST set the TTL to the appropriate 192 value to expire at that S-PE. An S-PE that supports this 193 specification MUST inspect packets PW packet that are received as a 194 result of TTL expiry, determine whether a GAL follows the PW LSE. If 195 a GAL is present the S-PE then processes the VCCV packet. 197 An S-PE that does not support this specification would be expected to 198 reject as malformed a VCCV CC Type 4 packet that was received. This 199 is because the S-PE would expect the PW LSE to be bottom of stack 200 (the non FAT case) and for the LSE at bottom of stack not to be a 201 reserved label (both the FAT and the non-FAT cases). An S-PE that 202 did not make this reserved label check would then find that the first 203 nibble following the label stack was 0x1 and not the expected start 204 of an IP packet. It would hence be expected to also reject the 205 packet. This update to the behaviour of S-PEs is therefore backwards 206 compatible. 208 6. VCCV Capability Advertisement 210 The VCCV capability advertisement MUST match the c-bit setting that 211 is advertised in the PW FEC element [RFC4447]. If the c-bit is set, 212 indicating the use of the PW CW, then VCCV CC Type 4 MUST NOT be 213 advertised. If the c-bit is not set, indicating that the PW CW is 214 not in use, then an equipment supporting this specification MUST 215 advertise VCCV CC Type 4. Advertisement of VCCV CC Types 1 and 4 are 216 therefore mutually exclusive. 218 A PE supporting VCCV CC Type 4 MAY advertise other VCCV CC types as 219 defined in [RFC5085] . 221 If the remote PE supports VCCV CC Type 4, and the PW CW is not in 222 use, then for cases where multiple CC Types are advertised, the 223 following precedence rules apply when choosing which CC Type to use: 225 1. Type 4: GAL VCCV Control Channel. 227 2. Type 2: MPLS Router Alert Label. 229 3. Type 3: MPLS PW Label with TTL == 1. 231 If the remote PE finds that VCCV CC Types 1 and 4 are both 232 advertised, or that c-bit is set and VCCV CC Type 4 is advertised, 233 then it should report the error to the operator through the 234 management interface in use, and send a Label Release Message with a 235 status code "VCCV Type Error". 237 7. Manageability Considerations 239 Whilst the introduction of this additional VCCV CC type increases the 240 number of VCCV CC types that the operator needs to manage, it 241 addresses the issues with VCCV CC Types 2 and 3 described in 242 Section 1. 244 In the event of a misconfiguration of this VCCV CC type, the PW is 245 taken out of service and the operator advised as described in 246 Section 6. 248 Attention is drawn to the possible absence of fate sharing between PW 249 data packets and VCCV CC Type 4 packets described in Section 3 and 250 Section 4. 252 8. Security Considerations 254 This document does not by itself raise any new security 255 considerations beyond those described in [RFC5085]. It addresses the 256 possibility of packet leaking that can occur with VCCV CC Type 3. 258 9. IANA Considerations 260 9.1. MPLS VCCV Control Channel (CC) Type 4 262 IANA is requested to assign a new bit from the MPLS VCCV Control 263 Channel (CC) Types registry in the PWE3-parameters name space in 264 order to identify VCCV type 4. It is requested that Bit 3 be 265 assigned to this purpose which would have a value of 0x08. 267 MPLS VCCV Control Channel (CC) Types 269 Bit (Value) Description Reference 270 ============ =========== ================== 271 Bit X (0x0Y) Type 4 This Specification 273 9.2. LDP Status Code 275 IANA is requested to assign a new Status Code from the Label 276 Distribution Protocol (LDP) Parameters name space: 278 Status Code Name Space 280 Range/Value E Description Reference 281 =========== = =============== ========= 282 0x000000xx 0 VCCV Type Error This Specification 284 10. Acknowledgments 286 The authors wish to thank Alexander (Sasha) Vainshtein for his 287 proposal to make the GAL and Flow labels mutually exclusive. This 288 proposal led to a significant simplification of this design. The 289 authors also thank both Sasha and Matthew Bocci for their review 290 comments. 292 11. References 294 11.1. Normative References 296 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 297 Requirement Levels", BCP 14, RFC 2119, March 1997. 299 [RFC4385] Bryant, S., Swallow, G., Martini, L., and D. McPherson, 300 "Pseudowire Emulation Edge-to-Edge (PWE3) Control Word for 301 Use over an MPLS PSN", RFC 4385, February 2006. 303 [RFC4447] Martini, L., Rosen, E., El-Aawar, N., Smith, T., and G. 304 Heron, "Pseudowire Setup and Maintenance Using the Label 305 Distribution Protocol (LDP)", RFC 4447, April 2006. 307 [RFC5085] Nadeau, T. and C. Pignataro, "Pseudowire Virtual Circuit 308 Connectivity Verification (VCCV): A Control Channel for 309 Pseudowires", RFC 5085, December 2007. 311 [RFC5586] Bocci, M., Vigoureux, M., and S. Bryant, "MPLS Generic 312 Associated Channel", RFC 5586, June 2009. 314 [RFC6073] Martini, L., Metz, C., Nadeau, T., Bocci, M., and M. 315 Aissaoui, "Segmented Pseudowire", RFC 6073, January 2011. 317 [RFC6391] Bryant, S., Filsfils, C., Drafz, U., Kompella, V., Regan, 318 J., and S. Amante, "Flow-Aware Transport of Pseudowires 319 over an MPLS Packet Switched Network", RFC 6391, November 320 2011. 322 11.2. Informative References 324 [RFC5921] Bocci, M., Bryant, S., Frost, D., Levrau, L., and L. 325 Berger, "A Framework for MPLS in Transport Networks", RFC 326 5921, July 2010. 328 Authors' Addresses 330 Thomas D. Nadeau 331 lucidvision 333 Email: tnadeau@lucidvision.com 335 Luca Martini 336 Cisco Systems 338 Email: lmartini@cisco.com 340 Stewart Bryant 341 Cisco Systems 343 Email: stbryant@cisco.com