idnits 2.17.1 draft-ietf-pals-vccv-for-gal-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 : ---------------------------------------------------------------------------- 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 (February 18, 2015) is 3354 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 D. Nadeau 3 Internet-Draft lucidvision 4 Intended status: Standards Track L . Martini 5 Expires: August 20, 2015 S. Bryant 6 Cisco Systems 7 February 18, 2015 9 Using GAL as a VCCV Channel Indicator 10 draft-ietf-pals-vccv-for-gal-02 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 20, 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 (http://trustee.ietf.org/ 44 license-info) in effect on the date of publication of this document. 45 Please review these documents carefully, as they describe your rights 46 and restrictions with respect to this document. Code Components 47 extracted from this document must include Simplified BSD License text 48 as described in Section 4.e of the Trust Legal Provisions and are 49 provided without warranty as described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 54 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 2 55 3. GAL VCCV Control Channel Type . . . . . . . . . . . . . . . . 3 56 4. FAT PWs . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 5. Multi-Segment Pseudowires . . . . . . . . . . . . . . . . . . 4 58 6. VCCV Capability Advertisement . . . . . . . . . . . . . . . . 4 59 7. Manageability Considerations . . . . . . . . . . . . . . . . . 5 60 8. Security Considerations . . . . . . . . . . . . . . . . . . . 5 61 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 62 9.1. MPLS VCCV Control Channel (CC) Type 4 . . . . . . . . . . 5 63 9.2. LDP Status Code . . . . . . . . . . . . . . . . . . . . . 6 64 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 6 65 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 66 11.1. Normative References . . . . . . . . . . . . . . . . . . 6 67 11.2. Informative References . . . . . . . . . . . . . . . . . 7 68 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7 70 1. Introduction 72 This document specifies a new Virtual Circuit Connectivity 73 Verification (VCCV) [RFC5085] control channel (CC) type for use with 74 pseudowires (PW) carried over an MPLS network that do not use the PW 75 Control Word (CW) [RFC4385]. This new VCCV CC type uses the Generic 76 Associated Channel Label (GAL) [RFC5586] to distinguish VCCV packets 77 from packets carrying user data. This new VCCV CC type introduces 78 compatibility with the method of MPLS Label Switched Path (LSP) 79 Operations, Administration, and Maintenance (OAM) identification, 80 particularly in MPLS-TP networks [RFC5921]. 82 VCCV currently specifies three CC types. VCCV CC Type 1 uses the PW 83 Control Word (CW) to distinguish VCCV packets from packets carrying 84 user data. VCCV CC Types 2 and 3 require IP encapsulation for OAM 85 packets they carry. This was not an issue when [RFC5085] was 86 designed, but is in conflict with the design goals of MPLS-TP 87 [RFC5921] which does not otherwise require the availability of IP. 88 VCCV CC Type 2 is not applicable to multi-segment PWs (MS-PWs) 89 [RFC6073]. A MS-PW operating without the CW therefore has to use 90 VCCV CC Type 3 which identifies VCCV packets on the basis of TTL 91 expiry. Whilst less of an issue with a single segment PW (SS-PW), on 92 an MS-PW this need to be accurately set to cause TTL expiry at the 93 egress Terminating Provider Edge (T-PE) [RFC6073]. In the event of a 94 error in the setting of the PW LSE TTL this can result in VCCV 95 packets leaking into the attachment circuit which may disrupt the 96 operation of the PW, or the native service, and is a security risk. 97 The new VCCV CC type defined in this specification addresses these 98 problems for PWs that do not use the CW. 100 For reasons of network efficiency and due to hardware constraints it 101 is not possible to address these issue by mandating that all PWs use 102 the PW CW, hence the introduction of this new VCCV CC type. PWs 103 without the CW are widely deployed, and hence mandating that all PWs 104 use the CW is not a viable way to address this issue. 106 2. Requirements Language 107 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 108 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 109 "OPTIONAL" in this document are to be interpreted as described in 110 [RFC2119]. 112 3. GAL VCCV Control Channel Type 114 When the PW CW is not used, the GAL VCCV Control Channel (CC) type 115 defined in this section MAY be used. This is referred to as VCCV CC 116 Type4 throughout the rest of this of this document. VCCV Type 4 uses 117 the encapsulation shown in Figure 1. 119 0 1 120 2 3 121 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 123 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 124 | PW LSE | 125 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 126 | GAL LSE | 127 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 128 |0 0 0 1|Version| Reserved | Channel Type | 129 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 130 | | 131 ~ VCCV Message Body ~ 132 | | 133 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 135 The VCCV message body is preceded by a Generic Associated Channel 136 Header as defined in [RFC5586], in which the Channel Type identifies 137 the type and format of the OAM message carried in the VCCV message 138 body. 140 The GAL LSE MUST contain the GAL reserved label as defined in 141 [RFC5586]. 143 The PW LSE is constructed according to the existing procedures that 144 apply to the type of pseudowire that is in use. 146 Note that the inclusion of a GAL following the PW LSE over a label 147 switched path subject to Equal-Cost Multi-path (ECMP) load balancing 148 can cause the OAM packet to take a different path through the network 149 from the corresponding PW data packets. If that is not acceptable, 150 then an alternative VCCV type MUST be used. 152 4. FAT PWs 154 [RFC6391] specifies that when the flow-aware transport (FAT) of 155 pseudowires over an MPLS packet switched network has been signalled 156 or configured, the Flow LSE MUST be present. It further specifies 157 that "the flow label MUST NOT be an MPLS reserved label (values in 158 the range 0..15) [RFC3032]", and that "If a flow LSE is present, it 159 MUST be checked to determine whether it carries a reserved label. If 160 it is a reserved label, the packet is processed according to the 161 rules associated with that reserved label; otherwise, the LSE is 162 discarded." 164 This document specifies that if the flow-aware transport of 165 pseudowires over an MPLS packet switched network has been signalled 166 or configured then the presence of VCCV message is indicated by the 167 use of a GAL in place of the flow LSE. 169 This is consistent with [RFC6391], and the packet structure is 170 identical to that shown in Figure 1. 172 Note that the use of a GAL in place of the flow label over a label 173 switched path subject to ECMP can cause the OAM packet to take a 174 different path through the network from the corresponding PW data 175 packets. If that is not acceptable, then an alternative VCCV type 176 MUST be used. 178 5. Multi-Segment Pseudowires 180 When using VCCV CC Type 4 for MS-PWs, a PE transmitting the VCCV 181 packet to a Switching PE (S-PE) MUST set the TTL to the appropriate 182 value to expire at that S-PE. An S-PE that supports this 183 specification MUST inspect packets PW packet that are received as a 184 result of TTL expiry, determine whether a GAL follows the PW LSE. If 185 a GAL is present the S-PE then processes the VCCV packet. 187 An S-PE that does not support this specification would be expected to 188 reject as malformed a VCCV CC Type 4 packet that was received. This 189 is because the S-PE would expect the PW LSE to be bottom of stack 190 (the non FAT case) and for the LSE at bottom of stack not to be a 191 reserved label (both the FAT and the non-FAT cases). An S-PE that did 192 not make this reserved label check would then find that the first 193 nibble following the label stack was 0x1 and not the expected start 194 of an IP packet. It would hence be expected to also reject the 195 packet. This update to the behaviour of S-PEs is therefore backwards 196 compatible. 198 6. VCCV Capability Advertisement 200 The VCCV capability advertisement MUST match the c-bit setting that 201 is advertised in the PW FEC element [RFC4447]. If the c-bit is set, 202 indicating the use of the PW CW, then VCCV CC Type 4 MUST NOT be 203 advertised. If the c-bit is not set, indicating that the PW CW is 204 not in use, then an equipment supporting this specification MUST 205 advertise VCCV CC Type 4. Advertisement of VCCV CC Types 1 and 4 are 206 therefore mutually exclusive. 208 A PE supporting VCCV CC Type 4 MAY advertise other VCCV CC types as 209 defined in [RFC5085] . 211 If the remote PE supports VCCV CC Type 4, and the PW CW is not in 212 use, then for cases where multiple CC Types are advertised, the 213 following precedence rules apply when choosing which CC Type to use: 215 1. Type 4: GAL VCCV Control Channel. 217 2. Type 2: MPLS Router Alert Label. 219 3. Type 3: MPLS PW Label with TTL == 1. 221 If the remote PE finds that VCCV CC Types 1 and 4 are both 222 advertised, or that c-bit is set and VCCV CC Type 4 is advertised, 223 then it should report the error to the operator through the 224 management interface in use, and send a Label Release Message with a 225 status code "VCCV Type Error". 227 7. Manageability Considerations 229 Whilst the introduction of this additional VCCV CC type increases the 230 number of VCCV CC types that the operator needs to manage, it 231 addresses the issues with VCCV CC Types 2 and 3 described in . 232 (Section 1). 234 In the event of a misconfiguration of this VCCV CC type, the PW is 235 taken out of service and the operator advised as described in Section 236 6. 238 Attention is drawn to the possible absence of fate sharing between PW 239 data packets and VCCV CC Type 4 packets described in Section 3 and 240 Section 4. 242 8. Security Considerations 244 This document does not by itself raise any new security 245 considerations beyond those described in [RFC5085]. It addresses the 246 possibility of packet leaking that can occur with VCCV CC Type 3. 248 9. IANA Considerations 250 9.1. MPLS VCCV Control Channel (CC) Type 4 252 IANA is requested to assign a new bit from the MPLS VCCV Control 253 Channel (CC) Types registry in the PWE3-parameters name space in 254 order to identify VCCV type 4. It is recommended that Bit 3 be 255 assigned to this purpose which would have a value of 0x08. 257 MPLS VCCV Control Channel (CC) Types 259 Bit (Value) Description Reference 260 ============ =========== ================== 261 Bit X (0x0Y) Type 4 This Specification 263 9.2. LDP Status Code 265 IANA is requested to assign a new Status Code from the Label 266 Distribution Protocol (LDP) Parameters name space: 268 Status Code Name Space 270 Range/Value E Description Reference 271 =========== = =============== ========= 272 0x000000xx 0 VCCV Type Error This Specification 274 10. Acknowledgments 276 The authors wish to thank Alexander (Sasha) Vainshtein for his 277 proposal to make the GAL and Flow labels mutually exclusive. This 278 proposal let to a significant simplification of this design. They 279 also thank both Sasha and and Matthew Bocci for their review 280 comments. 282 11. References 284 11.1. Normative References 286 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 287 Requirement Levels", BCP 14, RFC 2119, March 1997. 289 [RFC4385] Bryant, S., Swallow, G., Martini, L. and D. McPherson, 290 "Pseudowire Emulation Edge-to-Edge (PWE3) Control Word for 291 Use over an MPLS PSN", RFC 4385, February 2006. 293 [RFC4447] Martini, L., Rosen, E., El-Aawar, N., Smith, T. and G. 294 Heron, "Pseudowire Setup and Maintenance Using the Label 295 Distribution Protocol (LDP)", RFC 4447, April 2006. 297 [RFC5085] Nadeau, T. and C. Pignataro, "Pseudowire Virtual Circuit 298 Connectivity Verification (VCCV): A Control Channel for 299 Pseudowires", RFC 5085, December 2007. 301 [RFC5586] Bocci, M., Vigoureux, M. and S. Bryant, "MPLS Generic 302 Associated Channel", RFC 5586, June 2009. 304 [RFC6073] Martini, L., Metz, C., Nadeau, T., Bocci, M. and M. 305 Aissaoui, "Segmented Pseudowire", RFC 6073, January 2011. 307 [RFC6391] Bryant, S., Filsfils, C., Drafz, U., Kompella, V., Regan, 308 J. and S. Amante, "Flow-Aware Transport of Pseudowires 309 over an MPLS Packet Switched Network", RFC 6391, November 310 2011. 312 11.2. Informative References 314 [RFC5921] Bocci, M., Bryant, S., Frost, D., Levrau, L. and L. 315 Berger, "A Framework for MPLS in Transport Networks", RFC 316 5921, July 2010. 318 Authors' Addresses 320 Thomas D. Nadeau 321 lucidvision 323 Email: tnadeau@lucidvision.com 325 Luca Martini 326 Cisco Systems 328 Email: lmartini@cisco.com 330 Stewart Bryant 331 Cisco Systems 333 Email: stbryant@cisco.com