idnits 2.17.1 draft-ietf-mpls-ldp-typed-wildcard-07.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (See https://trustee.ietf.org/license-info/) 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 seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (March 4, 2010) is 5167 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 informational reference (is this intentional?): RFC 3036 (Obsoleted by RFC 5036) -- Obsolete informational reference (is this intentional?): RFC 4447 (Obsoleted by RFC 8077) == Outdated reference: A later version (-15) exists of draft-ietf-mpls-ldp-p2mp-08 == Outdated reference: A later version (-09) exists of draft-ietf-mpls-mpls-and-gmpls-security-framework-07 Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 MPLS Working Group Rajiv Asati 2 Internet Draft Cisco Systems 3 Intended status: Standards Track 4 Expires: July 2010 Ina Minei 5 Juniper Networks 7 Bob Thomas 9 March 4, 2010 11 Label Distribution Protocol (LDP) 'Typed Wildcard' Forward 12 Equivalence Class (FEC) 13 draft-ietf-mpls-ldp-typed-wildcard-07.txt 15 Status of this Memo 17 This Internet-Draft is submitted to IETF in full conformance with 18 the provisions of BCP 78 and BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six 26 months and may be updated, replaced, or obsoleted by other documents 27 at any time. It is inappropriate to use Internet-Drafts as 28 reference material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html 36 This Internet-Draft will expire on July 4, 2010. 38 Copyright Notice 40 Copyright (c) 2010 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with 48 respect to this document. Code Components extracted from this 49 document must include Simplified BSD License text as described in 50 Section 4.e of the Trust Legal Provisions and are provided without 51 warranty as described in the BSD License. 53 Abstract 55 The Label Distribution Protocol (LDP) specification for the Wildcard 56 Forward Equivalence Class (FEC) element has several limitations. 57 This document addresses those limitations by defining a Typed 58 Wildcard FEC element and associated procedures. In addition, it 59 defines a new LDP capability to address backward compatibility. 61 Table of Contents 63 1. Introduction...................................................3 64 2. Specification Language.........................................4 65 3. The Typed Wildcard FEC Element.................................4 66 4. Procedures for the Typed Wildcard FEC Element..................5 67 5. Typed Wildcard FEC Capability..................................6 68 6. Typed Wildcard FEC Element for Prefix FEC Element..............7 69 7. Typed Wildcard FEC Element for Host and Wildcard FEC Elements..8 70 8. IANA Considerations............................................8 71 9. Security Considerations........................................9 72 10. Acknowledgments...............................................9 73 11. References...................................................10 74 11.1. Normative References....................................10 75 11.2. Informative References..................................10 76 Author's Addresses...............................................11 78 1. Introduction 80 LDP [RFC5036] distributes labels for Forwarding Equivalence Classes 81 (FECs). LDP uses FEC TLVs in LDP messages to specify FECs. An LDP 82 FEC TLV includes 1 or more FEC Elements. A FEC element includes a 83 FEC type and an optional type-dependent value. 85 RFC5036 specifies two FEC types (Prefix and Wildcard), and other 86 documents specify additional FEC types; e.g., see [RFC4447] [MLDP]. 88 As specified by RFC5036, the Wildcard FEC Element refers to all FECs 89 relative to an optional constraint. The only constraint RFC5036 90 specifies is one that limits the scope of the Wildcard FEC Element 91 to "all FECs bound to a given label". 93 The RFC5036 specification of the Wildcard FEC Element has the 94 following deficiencies which limit its utility: 96 1) The Wildcard FEC Element is untyped. There are situations where 97 it would be useful to be able to refer to all FECs of a given 98 type (as another constraint). 100 2) Use of the Wildcard FEC Element is limited to Label Withdraw and 101 Label Release messages only. There are situations where it would 102 be useful to have Wildcard FEC Element, with type constraint, in 103 Label Request messages. 105 This document: 107 - Addresses the above limitations by defining a Typed Wildcard 108 FEC Element and procedures for its use. 110 - Specifies use of the LDP capability mechanism [RFC5561] at 111 session establishment time for informing a peer that an LDP 112 speaker is capable of handling the Typed Wildcast FEC. 114 - Specifies use of Typed Wildcard FEC Element in Label Request 115 message. 117 - Specifies the Typed Wildcard FEC Element for the Prefix FEC 118 Element specified by RFC5036. 120 Note that this document does not change procedures specified for the 121 LDP Wildcard FEC Element by RFC5036. 123 2. Specification Language 125 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 126 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 127 document are to be interpreted as described in [RFC2119]. 129 LDP - Label Distribution Protocol 131 FEC - Forwarding Equivalence Class 133 TLV - Type Length Value 135 LSR - Label Switch Router 137 3. The Typed Wildcard FEC Element 139 The Typed Wildcard FEC Element refers to all FECs of the specified 140 type that meet the constraint. It specifies a 'FEC Element Type' and 141 an optional constraint, which is intended to provide additional 142 information. 144 The format of the Typed Wildcard FEC Element is: 146 0 1 2 3 147 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 2 148 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 149 | Typed (IANA) | FEC Element | Len FEC Type | | 150 | Wildcard | Type | Info | | 151 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 152 | | 153 ~ Additional FEC Type-specific Information ~ 154 | (Optional) | 155 | +-+-+-+-+-+-+-+-+ 156 | | 157 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 159 Figure 1 Typed Wildcard FEC Element 161 where: 163 Typed Wildcard : One octet FEC Element Type (to be assigned 164 by IANA). 166 FEC Element Type : One octet FEC Element Type that specifies 167 the FEC Element Type to be wildcarded. Please see section 3.4.1 of 168 RFC5036. 170 Any (future) document specifying new FEC Element Type (not 171 defined in RFC5630) should prescribe whether typed wildcarding 172 is needed for that FEC Element Type. 174 Len FEC Type Info : One octet that specifies the length in 175 octets of the FEC Type Specific information field. It MUST be set 176 to 0 if there is no Additional FEC Type-specific Information. 178 Additional FEC Type-specific Information: (Optional) Additional 179 information specific to the FEC Element Type required to fully 180 specify the Typed Wildcard. If this field is absent, then all FECs 181 of the specified FEC Type would be matched. 183 Any (future) document specifying Typed wildcarding for any FEC 184 Element Type should also specify the length and format of 185 Additional FEC Type Specific Information, if included. 187 This document specifies one FEC Element Type instance (e.g. Prefix 188 FEC) for the 'Typed Wildcard FEC Element' in section 6. 190 4. Procedures for the Typed Wildcard FEC Element 192 When a FEC TLV contains a Typed Wildcard FEC Element, the Typed 193 Wildcard FEC Element MUST be the only FEC Element in the TLV. If an 194 LDP speaker receives a FEC TLV containing Typed Wildcard FEC Element 195 and any other FEC Elements, then the LDP speaker should ignore the 196 other FEC Elements and continue processing as if the message had 197 contained only the Typed Wildcard FEC Element. 199 An LDP implementation that supports the Typed Wildcard FEC Element 200 MUST support its use in Label Request, Label Withdraw and Label 201 Release messages. 203 An LDP implementation that supports the Typed Wildcard FEC Element 204 MUST support it for every FEC Element Type implemented for which it 205 is defined. 207 Receipt of a Label Request message with a FEC TLV containing a Typed 208 Wildcard FEC Element is interpreted as a request to send one or more 209 Label Mappings for all FECs of the type specified by the FEC Element 210 Type field in the Typed Wildcard FEC Element encoding. 212 An LDP implementation that supports the Typed Wildcard FEC Element 213 MUST support the following constraints whenever a Typed Wildcard FEC 214 appears in a Label Withdraw or Label Release message: 216 1) If the message carries an optional Label TLV the Typed Wildcard 217 FEC Element refers to all FECs of the specified FEC type bound to 218 the specified label. 220 2) If the message has no Label TLV the Typed Wildcard FEC Element 221 refers to all FECs of the specified FEC type. 223 Backwards compatibility with a router not supporting the Typed 224 Wildcard FEC element is ensured by the FEC procedures defined in 225 RFC5036. Quoting from RFC5036: 227 "If it" [an LSR] "encounters a FEC Element type it cannot decode, 228 it SHOULD stop decoding the FEC TLV, abort processing the message 229 containing the TLV, and send an "Unknown FEC" Notification message 230 to its LDP peer signaling an error." 232 A router receiving a FEC TLV containing a Typed Wildcard FEC element 233 for a FEC Element Type that it either doesn't support or for a FEC 234 Element Type that doesn't support the use of wildcarding, MUST stop 235 decoding the FEC TLV, abort processing the message containing the 236 TLV, and send an "Unknown FEC" Notification message to its LDP peer 237 signaling an error. 239 5. Typed Wildcard FEC Capability 241 As noted above, RFC5056 FEC procedures provide for backward 242 compatibility with an LSR not supporting the Typed Wildcard FEC 243 Element. However, they don't provide means for LSR wishing to use 244 the Typed Wildcard FEC Element to determine whether a peer supports 245 it other than to send a message that uses the FEC Element and to 246 wait and see how the peer responds. 248 An LDP speaker that supports the Typed Wildcard FEC Element MUST 249 inform its peers of the support by including a Typed Wildcard FEC 250 Element Capability Parameter [RFC5561] in its Initialization 251 messages. 253 The Capability Parameter for the Typed Wildcard FEC capability is a 254 TLV with the following format: 256 0 1 2 3 257 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 258 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 259 |U|F| Typed WCard FEC Cap (IANA)| Length | 260 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 261 |S| Reserved | 262 +-+-+-+-+-+-+-+-+ 264 Figure 2 Typed Wildcard FEC Capability format 266 Where: 268 U and F bits : MUST be 1 and 0 respectively as per 269 section 3 of LDP Capabilities [RFC5561]. 271 Typed WCard FEC Cap : TLV code point to be assigned by IANA. 273 S-bit : MUST be 1 (indicates that capability is 274 being advertised). 276 6. Typed Wildcard FEC Element for Prefix FEC Element 278 RFC5036 defines the Prefix FEC Element but it does not specify a 279 Typed Wildcard for it. This section specifies the Typed Wildcard 280 FEC Element for Prefix FEC Elements. 282 The format of the Prefix FEC Typed Wildcard FEC Element ("Prefix FEC 283 Wildcard" for short), based on Figure 1, is: 285 0 1 2 3 286 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 2 287 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 288 | Typed Wcard | Type = Prefix | Len = 2 | Address... | 289 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 290 | ...Family | 291 +-+-+-+-+-+-+-+-+ 293 Figure 3 Format of Prefix FEC Element using Typed Wildcard 295 Where: 297 FEC Element Type : "Prefix" FEC Element (0x02, per RFC5036). 299 Len FEC Type Info : Two octets (=0x02). 301 Address Family : Two octet quantity containing a value from 302 ADDRESS FAMILY NUMBERS in [IANA-AF]. 304 The procedures described in Section 4 apply to the Prefix FEC 305 Wildcard processing. 307 7. Typed Wildcard FEC Element for Host and Wildcard FEC Elements 309 There is no need to specify Typed Wildcard FEC Elements for the Host 310 FEC Element specified by [RFC3036], nor for the Wildcard FEC Element 311 specified by RFC5036. The [RFC3036] Host FEC Element has been 312 removed from RFC5036, and the Wildcard FEC Element is untyped by 313 definition. 315 In other words, the 'FEC Element Type' field in 'Typed Wildcard FEC 316 Element' MUST NOT be 0x01. 318 8. IANA Considerations 320 This draft introduces a new LDP FEC Element Type and a new LDP 321 Capability both of which require IANA assignment - 323 The 'Typed Wildcard' FEC Element requires a code point from the 324 LDP FEC Type Name Space. [RFC5036] partitions the FEC Type Name 325 Space into 3 regions: IETF Consensus region, First Come First 326 Served region, and Private Use region. The authors recommend 327 that the code point 0x05 from the IETF Consensus range be 328 assigned to the 'Typed Wildcard' FEC Element. 330 The 'Typed Wildcard FEC' Capability requires a code point from 331 the TLV Type name space. [RFC5036] partitions the TLV TYPE name 332 space into 3 regions: IETF Consensus region, Vendor Private Use 333 region, and Experimental Use region. The authors recommend that 334 a code point from the IETF Consensus range be assigned to the 335 'Typed Wildcard FEC' Capability. 337 9. Security Considerations 339 No security considerations beyond those that apply to the base LDP 340 specification [RFC5036] and further described in [MPLSsec] apply to 341 use of the Typed Wildcard FEC Elements as described in this 342 document. 344 One could deduce that the security exposure is reduced by this 345 document, since an LDP speaker using Typed Wildcard FEC Element 346 could use a single message to request, withdraw or release all the 347 label mappings of a particular type (a particular AFI, for example), 348 whereas an LDP speaker using Wildcard FEC Element, as defined in 349 based LDP specification [RFC5036], could use a single message to 350 request, withdraw or release all the label mappings of all types 351 (all AFIs, for example). 353 10. Acknowledgments 355 The authors would like to thank Yakov Rekhter for suggesting that 356 the limitations of the Wildcard FEC be addressed. Also, thanks to 357 Adrian Farrel and Richard L. Barnes for extensive review of this 358 document. 360 This document was prepared using 2-Word-v2.0.template.dot. 362 11. References 364 11.1. Normative References 366 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 367 Requirement Levels", BCP 14, RFC 2119, March 1997. 369 [RFC5036] Andersson, L., Minei, I., and Thomas, B., "LDP 370 Specification", RFC 5036, October 2007. 372 [RFC5561] Thomas, B., Aggarwal, S., Aggarwal, R., Le Roux, J.L., 373 "LDP Capabilities", RFC5561, May 2007. 375 11.2. Informative References 377 [RFC3036] Andersson, L., Doolan, P., Feldman, N., Fredette, A. and 378 Thomas, B., "LDP Specification", RFC 3036, January 2001. 380 [RFC4447] Martini, L., Editor, "Pseudowire Setup and Maintenance 381 Using the label Distribution Protocol (LDP)", RFC4447, 382 April 2006. 384 [MLDP] Minei, I., Wijnands, I., Editors, "Label Distribution 385 Protocol Extensions for Point-to-Multipoint and 386 Multipoint-to-Multipoint Label Switched Paths", draft- 387 ietf-mpls-ldp-p2mp-08.txt, Work in Progress, Oct 2009. 389 [MPLSsec] Fang, L., "Security Framework for MPLS and GMPLS 390 Networks", draft-ietf-mpls-mpls-and-gmpls-security- 391 framework-07, Work in Progress, Oct 2009. 393 [IANA-AF] http://www.iana.org/assignments/address-family-numbers. 395 Author's Addresses 397 Ina Minei 398 Juniper Networks 399 1194 North Mathilda Ave. 400 Sunnyvale, CA 94089 401 Email: ina@juniper.net 403 Bob Thomas 404 Email: bobthomas@alum.mit.edu 406 Rajiv Asati 407 Cisco Systems, 408 7025-6 Kit Creek Rd, RTP, NC, 27709-4987 409 Email: rajiva@cisco.com