idnits 2.17.1 draft-ietf-pals-vccv-for-gal-01.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 (January 30, 2015) is 3372 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: August 3, 2015 S. Bryant 6 Cisco Systems 7 January 30, 2015 9 Using GAL as a VCCV Channel Indicator 10 draft-ietf-pals-vccv-for-gal-01 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 August 3, 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 . . . . . . . . . . . . . . . . . . 4 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 . . . . . . . . . . . . . . . . . . . . . . . 7 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-TP 88 [RFC5921] which does not otherwise require the availability of IP. 89 VCCV CC Type 2 is not applicable to multi-segment PWs (MS-PWs) 90 [RFC6073]. A MS-PW operating without the CW therefore has to use 91 VCCV CC Type 3 which identifies VCCV packets on the basis of TTL 92 expiry. Whilst less of an issue with a single segment PW (SS-PW), on 93 an MS-PW this need to be accurately set to cause TTL expiry at the 94 egress Terminating Provider Edge (T-PE) [RFC6073]. In the event of a 95 error in the setting of the PW LSE TTL this can result in VCCV 96 packets leaking into the attachment circuit which may disrupt the 97 operation of the PW, or the user service, and is a security risk. 98 The new VCCV CC type defined in this specification addresses these 99 problems for PWs that do not use the CW. 101 Note that VCCV CC Type 3 remains mandatory for multi-segment PW (MS- 102 PW) OAM and it is currently combined with VCCV CC Type 1 for MS-PWs 103 that use the CW [RFC6073]. This specification enables the 104 combination of VCCV CC Type 3 with VCCV Type 4 for PWs that do not 105 support the CWSection 5. 107 For reasons of network efficiency and due to hardware constraints it 108 is not possible to address these issue by mandating that all PWs use 109 the PW CW, hence the introduction of this new VCCV CC type. PWs 110 without the CW are widely deployed, and hence mandating that all PWs 111 use the CW is not a viable way to address this issue. 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 128 2 3 129 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 131 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 132 | PW LSE | 133 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 134 | GAL LSE | 135 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 136 |0 0 0 1|Version| Reserved | Channel Type | 137 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 138 | | 139 ~ VCCV Message Body ~ 140 | | 141 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 143 Figure 1 145 The VCCV message body is preceded by a Generic Associated Channel 146 Header as defined in [RFC5586], in which the Channel Type identifies 147 the type and format of the OAM message carried in the VCCV message 148 body. 150 The GAL LSE MUST contain the GAL reserved label as defined in 151 [RFC5586]. 153 The PW LSE is constructed according to the existing procedures that 154 apply to the type of pseudowire that is in use. 156 Note that the inclusion of a GAL following the PW LSE over a label 157 switched path subject to Equal-Cost Multi-path (ECMP) load balancing 158 can cause the OAM packet to take a different path through the network 159 from the corresponding PW data packets. If that is not acceptable, 160 then an alternative VCCV type MUST be used. 162 4. FAT PWs 164 [RFC6391] specifies that when the flow-aware transport (FAT) of 165 pseudowires over an MPLS packet switched network has been signalled 166 or configured, the Flow LSE MUST be present. It further specifies 167 that "the flow label MUST NOT be an MPLS reserved label (values in 168 the range 0..15) [RFC3032]", and that "If a flow LSE is present, it 169 MUST be checked to determine whether it carries a reserved label. If 170 it is a reserved label, the packet is processed according to the 171 rules associated with that reserved label; otherwise, the LSE is 172 discarded." 174 This document specifies that if the flow-aware transport of 175 pseudowires over an MPLS packet switched network has been signalled 176 or configured then the presence of VCCV message is indicated by the 177 use of a GAL in place of the flow LSE. 179 This is consistent with [RFC6391], and the packet structure is 180 identical to that shown in Figure 1. 182 Note that the use of a GAL in place of the flow label over a label 183 switched path subject to ECMP can cause the OAM packet to take a 184 different path through the network from the corresponding PW data 185 packets. If that is not acceptable, then an alternative VCCV type 186 MUST 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 the following capability advertisement precedence rules 223 supersede those defined in Section 7 of [RFC5085] : 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 recommended 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 review 287 comments and for his proposal to make the GAL and Flow labels 288 mutually exclusive. This proposal let to a significant 289 simplification of this design. 291 11. References 293 11.1. Normative References 295 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 296 Requirement Levels", BCP 14, RFC 2119, March 1997. 298 [RFC4385] Bryant, S., Swallow, G., Martini, L., and D. McPherson, 299 "Pseudowire Emulation Edge-to-Edge (PWE3) Control Word for 300 Use over an MPLS PSN", RFC 4385, February 2006. 302 [RFC4447] Martini, L., Rosen, E., El-Aawar, N., Smith, T., and G. 303 Heron, "Pseudowire Setup and Maintenance Using the Label 304 Distribution Protocol (LDP)", RFC 4447, April 2006. 306 [RFC5085] Nadeau, T. and C. Pignataro, "Pseudowire Virtual Circuit 307 Connectivity Verification (VCCV): A Control Channel for 308 Pseudowires", RFC 5085, December 2007. 310 [RFC5586] Bocci, M., Vigoureux, M., and S. Bryant, "MPLS Generic 311 Associated Channel", RFC 5586, June 2009. 313 [RFC6073] Martini, L., Metz, C., Nadeau, T., Bocci, M., and M. 314 Aissaoui, "Segmented Pseudowire", RFC 6073, January 2011. 316 [RFC6391] Bryant, S., Filsfils, C., Drafz, U., Kompella, V., Regan, 317 J., and S. Amante, "Flow-Aware Transport of Pseudowires 318 over an MPLS Packet Switched Network", RFC 6391, November 319 2011. 321 11.2. Informative References 323 [RFC5921] Bocci, M., Bryant, S., Frost, D., Levrau, L., and L. 324 Berger, "A Framework for MPLS in Transport Networks", RFC 325 5921, July 2010. 327 Authors' Addresses 328 Thomas D. Nadeau 329 lucidvision 331 Email: tnadeau@lucidvision.com 333 Luca Martini 334 Cisco Systems 336 Email: lmartini@cisco.com 338 Stewart Bryant 339 Cisco Systems 341 Email: stbryant@cisco.com