idnits 2.17.1 draft-mirsky-mpls-tp-cv-adv-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: ---------------------------------------------------------------------------- == It seems as if not all pages are separated by form feeds - found 0 form feeds but 8 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RFC5085], [RFC6428], [RFC5885]), 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 doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (January 10, 2013) is 4123 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) == Unused Reference: 'RFC5882' is defined on line 281, but no explicit reference was found in the text == Outdated reference: A later version (-02) exists of draft-ietf-pwe3-vccv-for-gal-00 ** Obsolete normative reference: RFC 4447 (Obsoleted by RFC 8077) -- Obsolete informational reference (is this intentional?): RFC 2434 (Obsoleted by RFC 5226) Summary: 2 errors (**), 0 flaws (~~), 5 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group G. Mirsky 3 Internet-Draft Ericsson 4 Intended status: Standards Track January 10, 2013 5 Expires: July 14, 2013 7 VCCV MPLS-TP Connectivity Verification (CV) Capability Advertisement 8 draft-mirsky-mpls-tp-cv-adv-02 10 Abstract 12 This document specifies how use of proactive Connectivity 13 Verification, Continuity Check, and Remote Defect Indication for the 14 MPLS Transport Profile [RFC6428] affects operation and management 15 function election for PW VCCV [RFC5085], [RFC5885]. 17 Status of this Memo 19 This Internet-Draft is submitted in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF). Note that other groups may also distribute 24 working documents as Internet-Drafts. The list of current Internet- 25 Drafts is at http://datatracker.ietf.org/drafts/current/. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 This Internet-Draft will expire on July 14, 2013. 34 Copyright Notice 36 Copyright (c) 2013 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents 41 (http://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with respect 44 to this document. Code Components extracted from this document must 45 include Simplified BSD License text as described in Section 4.e of 46 the Trust Legal Provisions and are provided without warranty as 47 described in the Simplified BSD License. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 52 1.1. Conventions used in this document . . . . . . . . . . . . . 3 53 1.1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . 3 54 1.1.2. Requirements Language . . . . . . . . . . . . . . . . . 3 55 2. MPLS-TP CC-CV on Pseudowires . . . . . . . . . . . . . . . . . 3 56 2.1. VCCV Extended CV Advertisement sub-TLV . . . . . . . . . . 4 57 2.2. MPLS-TP CC-CV Types . . . . . . . . . . . . . . . . . . . . 4 58 2.3. MPLS-TP CC-CV Type Operation . . . . . . . . . . . . . . . 5 59 2.4. CV Type Selection . . . . . . . . . . . . . . . . . . . . . 5 60 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5 61 3.1. VCCV Extended CV Types . . . . . . . . . . . . . . . . . . 6 62 4. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 63 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6 64 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 65 6.1. Normative References . . . . . . . . . . . . . . . . . . . 7 66 6.2. Informative References . . . . . . . . . . . . . . . . . . 8 67 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 8 69 1. Introduction 71 Proactive Connectivity Verification (CV), Continuity Check (CC), and 72 Remote Defect Indication (RDI) for the MPLS Transport Profile 73 [RFC6428] is applicable to all constructs of the MPLS-TP, including 74 pseudowires (PWs). If Control Plane is used to operate and manage PW 75 then procedure defined in [RFC5085] and [RFC5885] should be used to 76 select proper type of Control Channel and corresponding type of 77 Connectivity Verification. This document specifies how signaling and 78 selection process modified to ensure backward compatibility and allow 79 use of proactive CV-CC-RDI over MPLS-TP PWs. 81 1.1. Conventions used in this document 83 1.1.1. Terminology 85 BFD: Bidirectional Forwarding Detection 87 CC: Continuity Check 89 CV: Connectivity Verification 91 PE: Provider Edge 93 VCCV: Virtual Circuit Connectivity Verification 95 VCCV CC: VCCV Control Channel 97 1.1.2. Requirements Language 99 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 100 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 101 "OPTIONAL" in this document are to be interpreted as described in 102 [RFC2119]. 104 2. MPLS-TP CC-CV on Pseudowires 106 PW VCCV can support several CV Types. Ability to support arbitrary 107 combination of CV modes advertised in CV Types field of VCCV 108 Interface Parameter sub-TLV [RFC4446], [RFC4447]. Currently six 109 types of CV been defined for PW VCCV out of eight bit long field. 110 This document introduces four new CV types and to accommodate them a 111 new VCCV Extended CV parameter for PW Interface Parameters Sub-TLV is 112 defined. 114 2.1. VCCV Extended CV Advertisement sub-TLV 116 The format of VCCV Extended CV Advertisement is a TLV where: 118 0 1 2 3 119 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 120 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 121 | Type = 0x19 | Length | CV Type | Reserved | 122 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 124 Figure 1: VCCV Extended CV parameter format 126 Length - the length of the sub-TLV, including type and the Length 127 field itself. Minimum length is 4. It it isrecommended that 128 extensions to the sub-TLV be done in 4 bytes increments with Reserved 129 field being set to zero on transmit and ignored on receipt. 131 Reserved field must be set to zeroes on transmit and ignored on 132 receive. 134 CV Type field is a bitmask that lists types of CV monitoring that a 135 PE is capable to support. VCCV Extended CV parameter sub-TLV must 136 appear in combination with VCCV parameter sub-TLV. If VCCV parameter 137 sub-TLV is missing then VCCV Extended CV parameter sub-TLV should be 138 ignored. 140 2.2. MPLS-TP CC-CV Types 142 The [RFC6428] defines coordinated and independent modes of monitoring 143 point-to-point bi-directional connection that can be applied to 144 monitoring PWs. At the same time [RFC6310] defines how BFD-based OAM 145 can map and be mapped to status of an Attachment Circuit. Thus there 146 could be four MPLS-TP CV types as combination of modes and 147 functionality: 149 +---------------+-------------------+-------------------------------+ 150 | Modes | Fault Detection | Fault Detection and Status | 151 | | Only | Signalling | 152 +---------------+-------------------+-------------------------------+ 153 | Independent | 0x01 | 0x02 | 154 | Mode | | | 155 | Coordinated | 0x04 | 0x08 | 156 | Mode | | | 157 +---------------+-------------------+-------------------------------+ 159 Table 1: Bitmask Values for MPLS-TP CV Types 161 2.3. MPLS-TP CC-CV Type Operation 163 Connectivity verification according to [RFC6428] is part of MPLS-TP 164 CC/CV operation that can be used with VCCV Control Channel Types 1 165 [RFC5085] or Type 4 [I-D.ietf-pwe3-vccv-for-gal]. If VCCV CC Type 1 166 or Type 4 selected, then PEs might select one of MPLS-TP CC-CV types 167 as VCCV CV mechanism to be used for this PW. 169 2.4. CV Type Selection 171 CV selection rules that have been defined in Section 7 of [RFC5085] 172 and updated Section 4 of [RFC5885] are augmented in this document. 174 If VCCV Control Channel Type 1 or Type 4 is chosen according to 175 Section 7 [RFC5085] or Section 4 [I-D.ietf-pwe3-vccv-for-gal] and 176 common set of proactive CV types advertized by both PEs includes 177 MPLS-TP CC-CV types and some BFD CV types, then MPLS-TP CC-CV takes 178 precedence over any type of BFD CV. If multiple MPLS-TP CV types 179 advertised by both PEs, then following list sorted in descending 180 priority order is used: 182 1. 0x08 - coordinated mode for PW Fault Detection and AC/PW Fault 183 Status Signaling 185 2. 0x04 - coordinated mode for PW Fault Detection only 187 3. 0x02 - independent mode for PW Fault Detection and AC/PW Fault 188 Status Signaling 190 4. 0x01 - independent mode for PW Fault Detection only 192 3. IANA Considerations 194 The PW Interface Parameters Sub-TLV registry defined in [RFC4446]. 196 IANA is requested to reserve a new PW Interface Parameters Sub-TLV 197 type as follows: 199 +-------------+--------+----------------------------+---------------+ 200 | Parameter | Length | Description | Reference | 201 | ID | | | | 202 +-------------+--------+----------------------------+---------------+ 203 | 0x19 | 4 | VCCV Extended CV Parameter | This document | 204 +-------------+--------+----------------------------+---------------+ 206 Table 2: New PW Interface Parameters Sub-TLV 208 Parameter ID Length Description Reference 210 0x19 4 VCCV Extended CV parameter This document 212 3.1. VCCV Extended CV Types 214 IANA is requested to set up a registry of ?VCCV Extended CV Types?. 215 These are 8 bitfield values. Extended CV Type values 0x01, 0x02, 216 0x04 and 0x08 are specified in Section 2.2 of this document. The 217 remaining bitfield values (0x10 through 0x80) are to be assigned by 218 IANA using the "IETF Consensus" policy defined in [RFC2434]. A VCCV 219 Extended Control Verification Type description and a reference to an 220 RFC approved by the IESG are required for any assignment from this 221 registry. 223 +--------------+----------------------------------------------------+ 224 | Bit(Value) | Description | 225 +--------------+----------------------------------------------------+ 226 | Bit 0 (0x01) | Independent mode for PW Fault Detection only | 227 | Bit 1 (0x02) | Independent mode for PW Fault Detection and AC/PW | 228 | | Fault Status Signaling | 229 | Bit 2 (0x04) | Coordinated mode for PW Fault Detection only | 230 | Bit 3 (0x08) | Coordinated mode for PW Fault Detection and AC/PW | 231 | | Fault Status Signaling | 232 | Bit 4 (0x10) | Reserved | 233 | Bit 5 (0x20) | Reserved | 234 | Bit 6 (0x40) | Reserved | 235 | Bit 7 (0x80) | Reserved | 236 +--------------+----------------------------------------------------+ 238 Table 3: MPLS Connectivity Verification (CV) Types 240 4. Security Considerations 242 Routers that implement the additional CV Type defined herein are 243 subject to the same security considerations as defined in [RFC5085], 244 [RFC5880], [RFC5881], and [RFC6428]. This specification does not 245 raise any additional security issues beyond these. 247 5. Acknowledgements 249 The author gratefully acknowledges the thoughtful review, comments, 250 and explanations provided by Dave Allan, and by Carlos Pignataro. 252 6. References 253 6.1. Normative References 255 [I-D.ietf-pwe3-vccv-for-gal] 256 Martini, L. and T. Nadeau, "A Unified Control Channel for 257 Pseudowires", draft-ietf-pwe3-vccv-for-gal-00 (work in 258 progress), January 2012. 260 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 261 Requirement Levels", BCP 14, RFC 2119, March 1997. 263 [RFC4446] Martini, L., "IANA Allocations for Pseudowire Edge to Edge 264 Emulation (PWE3)", BCP 116, RFC 4446, April 2006. 266 [RFC4447] Martini, L., Rosen, E., El-Aawar, N., Smith, T., and G. 267 Heron, "Pseudowire Setup and Maintenance Using the Label 268 Distribution Protocol (LDP)", RFC 4447, April 2006. 270 [RFC5085] Nadeau, T. and C. Pignataro, "Pseudowire Virtual Circuit 271 Connectivity Verification (VCCV): A Control Channel for 272 Pseudowires", RFC 5085, December 2007. 274 [RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection 275 (BFD)", RFC 5880, June 2010. 277 [RFC5881] Katz, D. and D. Ward, "Bidirectional Forwarding Detection 278 (BFD) for IPv4 and IPv6 (Single Hop)", RFC 5881, 279 June 2010. 281 [RFC5882] Katz, D. and D. Ward, "Generic Application of 282 Bidirectional Forwarding Detection (BFD)", RFC 5882, 283 June 2010. 285 [RFC5885] Nadeau, T. and C. Pignataro, "Bidirectional Forwarding 286 Detection (BFD) for the Pseudowire Virtual Circuit 287 Connectivity Verification (VCCV)", RFC 5885, June 2010. 289 [RFC6310] Aissaoui, M., Busschbach, P., Martini, L., Morrow, M., 290 Nadeau, T., and Y(J). Stein, "Pseudowire (PW) Operations, 291 Administration, and Maintenance (OAM) Message Mapping", 292 RFC 6310, July 2011. 294 [RFC6428] Allan, D., Swallow Ed. , G., and J. Drake Ed. , "Proactive 295 Connectivity Verification, Continuity Check, and Remote 296 Defect Indication for the MPLS Transport Profile", 297 RFC 6428, November 2011. 299 6.2. Informative References 301 [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an 302 IANA Considerations Section in RFCs", BCP 26, RFC 2434, 303 October 1998. 305 Author's Address 307 Greg Mirsky 308 Ericsson 310 Email: gregory.mirsky@ericsson.com