idnits 2.17.1 draft-raza-pwe3-pw-typed-wc-fec-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: ---------------------------------------------------------------------------- == 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 : ---------------------------------------------------------------------------- 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 seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (June 2, 2011) is 4712 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) == Outdated reference: A later version (-04) exists of draft-ietf-pwe3-p2mp-pw-02 Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Kamran Raza 2 Internet Draft Cisco Systems 3 Intended Status: Standards Track 4 Expiration Date: December 1, 2011 Sami Boutros 5 Cisco Systems 7 Carlos Pignataro 8 Cisco Systems 10 June 2, 2011 12 LDP Typed Wildcard FEC for the PW FEC Elements 14 draft-raza-pwe3-pw-typed-wc-fec-01.txt 16 Status of this Memo 18 This Internet-Draft is submitted to IETF in full conformance with 19 the provisions of BCP 78 and BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note that 23 other groups may also distribute working documents as Internet- 24 Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six 27 months and may be updated, replaced, or obsoleted by other documents 28 at any time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/ietf/1id-abstracts.txt 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html 37 This Internet-Draft will expire on December 1, 2011. 39 Copyright Notice 41 Copyright (c) 2011 IETF Trust and the persons identified as the 42 document authors. All rights reserved. This document is subject to 43 BCP 78 and the IETF Trust's Legal Provisions Relating to IETF 44 Documents (http://trustee.ietf.org/license-info) in effect on the 45 date of publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with 47 respect to this document. Code Components extracted from this 48 document must include Simplified BSD License text as described in 49 Section 4.e of the Trust Legal Provisions and are provided without 50 warranty as described in the BSD License. 52 Abstract 54 The "Typed Wildcard Forwarding Equivalence Class (FEC) Element" 55 defines an extension to the Label Distribution Protocol (LDP) that 56 can be used when it is desired to request or withdraw or release all 57 label bindings for a given FEC Element type. However, a typed 58 wildcard FEC element must be individually defined for each FEC 59 element type. This specification defines the typed wildcard FEC 60 elements for the PWid (0x80), Generalized PWid (0x81), and P2MP PW 61 (0x82) FEC element types. 63 Conventions used in this document 65 The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 66 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 67 document are to be interpreted as described in [RFC2119]. 69 Table of Contents 71 1. Introduction 3 72 2. Typed Wildcard for PW FEC Elements 3 73 3. Applicability Statement 4 74 4. Operation 5 75 4.1. PW Consistency Check 5 76 4.2. PW Graceful Shutdown 5 77 4.3. Wildcard PW Status 6 78 5. Security Considerations 6 79 6. IANA Considerations 6 80 7. Acknowledgments 6 81 8. References 6 82 8.1. Normative References 6 83 8.2. Informative References 7 84 Author's Address 7 86 1. Introduction 88 An extension [RFC5918] to the Label Distribution Protocol (LDP) 89 [RFC5036] defines the general notion of a "Typed Wildcard Forwarding 90 Equivalence Class (FEC) Element". This can be used when it is 91 desired to request all label bindings for a given type of FEC 92 Element, or to release or withdraw all label bindings for a given 93 type of FEC element. However, a typed wildcard FEC element must be 94 individually defined for each type of FEC element. 96 [RFC4447] defines the "PWid FEC Element" and "Generalized PWid FEC 97 Element", and [P2MP-PW] defines the "P2MP PW FEC Element". These 98 specifications, however, do not specify the Typed Wildcard format 99 for these elements. This document specifies the format of the Typed 100 Wildcard FEC Element for the "PWid FEC Element", "Generalized PWid 101 FEC Element", and "P2MP FEC Element". The procedures for Typed 102 Wildcard processing for PWid, Generalized PWid, and P2MP FEC 103 Elements are same as described in [RFC5918] for any typed wildcard 104 FEC Element type. 106 2. Typed Wildcard for PW FEC Elements 108 The format of the Typed Wildcard FEC Element for PWid, Generalized 109 PWid, and P2MP PW FEC Elements is specified as: 111 0 1 2 3 112 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 113 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 114 |Typed Wcard=0x5| Type=PW FEC | Len = 2 |R| PW type | 115 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 116 | . . . | 117 +-+-+-+-+-+-+-+-+ 119 Figure 1: Format of Typed Wildcard FEC Element for PW FEC Elements 121 Where: 123 Typed Wcard (one octet): Typed Wildcard FEC element type (0x05) 124 as specified in [RFC5918] 126 [FEC Element] Type (one octet): PW FEC Element type: 128 PWid: (type 0x80 [RFC4447]) 129 Generalized PWid: (type 0x81 [RFC4447]) 130 P2MP PW: (type 0x82, [P2MP-PW] 132 Len [FEC Type Info] (one octet): Two. (i.e. there is additional 133 FEC info to scope the Typed Wildcard) 135 Reserved bit: Must be set to ZERO on transmit and ignored on 136 receipt. 138 PW type (15-bits): PW type as specified in [RFC4447]. This field 139 is used to scope the PWid wildcard FEC operation to limit to 140 all PWs of a given type. This MUST be set to 0x7FFF 141 (Wildcard PW [IANA-PWE3]) when referring PWs of all types 142 (see Section 7). 144 [RFC4447] defines "PW Grouping ID TLV" that can be used for wildcard 145 withdrawal or status messages related to Generalized PWid and P2MP PW 146 FECs. When Typed Wildcard FEC for Generalized PWid or P2MP PW FEC 147 element is in use, "PW Grouping ID TLV" MUST NOT be present in the 148 same message. If found present, receiving LSR MUST silently ignore 149 Grouping ID TLV and process rest of the message. 151 3. Applicability Statement 153 The Typed wildcard FEC Elements defined in this document for the 154 PWid, Generalized PWid, and P2MP PW FEC Elements provide a finer 155 degree of granularity when compared to the Wildcard FEC mechanics 156 defined in [RFC5036]. 158 The PWid FEC Element as defined in [RFC4447] contains a Group ID 159 field. This field is defined as an arbitrary 32-bit value that 160 represents a group of PWs, and is used to create groups in the PW 161 space, including potentially a single group of all PWs for a given 162 FEC Element. This grouping enables an LSR to send wildcard label 163 withdrawals and/or status notification messages corresponding to a 164 PW group upon physical port failures. Similarly, [RFC4447] defines 165 the "PW Grouping ID TLV" used in the same fashion for the 166 Generalized PWid and P2MP PW FEC Elements. 168 The PW Typed Wildcard FEC elements defined in this document help us 169 achieve the similar functionality as "Group ID" field or "PW Grouping 170 ID TLV" for label withdrawal and status notification messages; 171 Additionally, the Typed Wildcard procedures [RFC5918] also provide 172 more generalized and comprehensive solution by allowing: 173 1. Typed-Wildcard Label Request message 174 2. Label TLV to further constraint the wildcard to all FECs of the 175 specified FEC type [and its specific filter] that are also bound 176 to the specified label. 178 4. Operation 180 The use of Typed Wildcard FEC elements for PW can be useful under 181 several scenarios. This section describes two use cases to 182 illustrate their usage. The following use cases consider two LSR 183 nodes, A and B, with LDP session between them to exchange L2VPN PW 184 bindings. 186 4.1. PW Consistency Check 188 A user may request a control plane consistency check at LSR A for 189 the PWid FEC and Generalized PWid FEC bindings that it had learnt 190 from LSR B over LDP session. To perform this consistency check, LSR 191 A marks all its learnt PW bindings from LSR B as stale, and then 192 send a Label Request message towards LSR B with Typed Wildcard FEC 193 element for PWid FEC element (PW type = 0x7FFF) and Generalized PWid 194 FEC element (PW type = 0x7FFF). Upon receipt of such request, LSR B 195 replays its database related to PWid FEC elements and Generalized 196 PWid FEC element in Label Mapping message. As a PW binding is 197 received at LSR A, the associated binding state is marked as 198 refreshed (no stale). When replay completes for a given type of 199 FEC, LSR B sends End-of-LIB Notification [RFC5919] to mark the end 200 of update for the given FEC type. Upon receipt of this Notification 201 at LSR A, any remaining stale PW binding of given FEC type learnt 202 from the peer LSR B, is cleaned up and removed from the database. 203 This completes consistency check with LSR B at LSR A for given FEC 204 type. 206 4.2. PW Graceful Shutdown 208 It may be desirable to perform shutdown/removal of existing PW 209 bindings advertised towards a peer in a graceful manner -- i.e. all 210 advertised PW bindings to be removed from a peer without session 211 flap. For example, to request a graceful delete of the PWid FEC and 212 Generalized PWid FEC bindings at LSR A learnt from LSR B, LSR A 213 would send a Label Withdraw message towards LSR B with Typed 214 Wildcard FEC elements pertaining to PWid FEC element (PW type = 215 0x7FFF) and Generalized PWid FEC element (PW type = 0x7FFF). Upon 216 receipt of such message, LSR B will delete all PWid and Generalized 217 PWid bindings learnt from LSR A. Afterwards, LSR B would send Label 218 Release message corresponding to received Label Withdraw with Typed 219 FEC element. 221 4.3. Wildcard PW Status 223 The Typed Wildcard FEC Elements for PW FECs can be very useful when 224 used to convey PW status amongst LSRs. The PE devices can send "PW 225 Status TLV" in an LDP Notification message to indicate status (i.e., 226 a Pseudowire Status Code denoting for example a particular fault) to 227 their remote peers [RFC4447]. In case of a global failure affecting 228 all PWs, an LSR typically sends one PW Status Notification message 229 per PW. Using Typed Wildcard FEC Element for given type of PW FEC 230 Element, the LSR will need to send only one PW Status Notification 231 message with Typed Wildcard PW FEC specified to notify about the 232 common status applicable to all PWs as scoped by the PW Typed 233 Wildcard FEC. 235 5. Security Considerations 237 No new security considerations beyond that apply to the base LDP 238 specification [RFC5036], [RFC4447] and [MPLS_SEC] apply to the use of 239 the PW Typed Wildcard FEC Element types described in this document. 241 6. IANA Considerations 243 None. 245 7. Acknowledgments 247 The authors would like to thank Eric Rosen, Siva Sivabalan, and Zafar 248 Ali for their valuable comments. 250 This document was prepared using 2-Word-v2.0 template.dot. 252 8. References 254 8.1. Normative References 256 [RFC5036] Andersson, L., Menei, I., and Thomas, B., Editors, "LDP 257 Specification", RFC 5036, September 2007. 259 [RFC5918] Asati, R., Minei, I., and Thomas, B., "LDP Typed Wildcard 260 Forwarding Equivalence Class", RFC 5918, August 2010. 262 [RFC5919] Asati, R., Mohapatra, P., Chen, E., and Thomas, B., 263 "Signaling LDP Label Advertisement Completion", RFC 5919, 264 August 2009. 266 [RFC4447] L. Martini, Editor, E. Rosen, El-Aawar, T. Smith, G. Heron, 267 "Pseudowire Setup and Maintenance using the Label 268 Distribution Protocol", RFC 4447, April 2006. 270 [P2MP-PW] Boutros, S., Martini, L., Sivabalan, S., Del Vecchio, G., 271 Kamite, Jin, L., "Signaling Root-Initiated P2MP PWs using 272 LDP", draft-ietf-pwe3-p2mp-pw-02.txt, Work in Progress, March 273 2011. 275 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 276 Requirement Levels", BCP 14, RFC2119, March 1997. 278 8.2. Informative References 280 [MPLS_SEC] Fang, L. et al., "Security Framework for MPLS and GMPLS 281 Networks", draft-ietf-mpls-mpls-and-gmpls-security-framework- 282 05.txt, Work in Progress, March 2009. 284 [IANA-PWE3] Internet Assigned Numbers Authority, "Pseudo Wires Name 285 Spaces (PWE3)", http://www.iana.org/assignments/pwe3- 286 parameters, May 2011. 288 Author's Address 290 Kamran Raza 291 Cisco Systems, Inc., 292 2000 Innovation Drive, 293 Kanata, ON K2K-3E8, Canada. 294 E-mail: skraza@cisco.com 296 Sami Boutros 297 Cisco Systems, Inc., 298 3750 Cisco Way, 299 San Jose, CA 95134, USA. 300 E-mail: sboutros@cisco.com 302 Carlos Pignataro 303 Cisco Systems, Inc., 304 7200 Kit Creek Road, 305 Research Triangle Park, NC 27709-4987, USA. 306 Email: cpignata@cisco.com