idnits 2.17.1 draft-ietf-mpls-ldp-typed-wildcard-05.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 (January 25, 2010) is 5177 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 January 25, 2010 11 LDP Typed Wildcard FEC 12 draft-ietf-mpls-ldp-typed-wildcard-05.txt 14 Status of this Memo 16 This Internet-Draft is submitted to IETF in full conformance with 17 the provisions of BCP 78 and BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six 25 months and may be updated, replaced, or obsoleted by other documents 26 at any time. It is inappropriate to use Internet-Drafts as 27 reference material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html 35 This Internet-Draft will expire on July 25, 2010. 37 Copyright Notice 39 Copyright (c) 2010 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 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 Label Distribution Protocol (LDP) specification for the Wildcard 55 FEC element has several limitations. This document addresses those 56 limitations by defining a Typed Wildcard FEC element and associated 57 procedures. In addition, it defines a new LDP capability to address 58 backward compatibility. 60 Table of Contents 62 1. Introduction...................................................2 63 2. Specification Language.........................................3 64 3. The Typed Wildcard FEC Element.................................4 65 4. Procedures for the Typed Wildcard FEC Element..................5 66 5. Typed Wildcard FEC Capability..................................6 67 6. Typed Wildcard FEC Element for Prefix FEC Element..............7 68 7. Typed Wildcard FEC Element for Host and Wildcard FEC Elements..8 69 8. IANA Considerations............................................8 70 9. Security Considerations........................................9 71 10. Acknowledgments...............................................9 72 11. References...................................................10 73 11.1. Normative References....................................10 74 11.2. Informative References..................................10 75 Author's Addresses...............................................11 77 1. Introduction 79 LDP [RFC5036] distributes labels for Forwarding Equivalence Classes 80 (FECs). LDP uses FEC TLVs in LDP messages to specify FECs. An LDP 81 FEC TLV includes 1 or more FEC Elements. A FEC element includes a 82 FEC type and an optional type-dependent value. 84 RFC5036 specifies two FEC types (Prefix and Wildcard), and other 85 documents specify additional FEC types; e.g., see [RFC4447] [MLDP]. 87 As specified by RFC5036, the Wildcard FEC Element refers to all FECs 88 relative to an optional constraint. The only constraint RFC5036 89 specifies is one that limits the scope of the Wildcard FEC Element 90 to "all FECs bound to a given label". 92 The RFC5036 specification of the Wildcard FEC Element has the 93 following deficiencies which limit its utility: 95 1) The Wildcard FEC Element is untyped. There are situations where 96 it would be useful to be able to refer to all FECs of a given 97 type. 99 2) Use of the Wildcard FEC Element is limited to Label Withdraw and 100 Label Release messages only. There are situations where it would 101 be useful in Label Request messages. 103 This document: 105 - Addresses the above limitations by defining a Typed Wildcard 106 FEC Element and procedures for its use. 108 - Specifies use of the LDP capability mechanism [RFC5561] at 109 session establishment time for informing a peer that an LDP 110 speaker is capable of handling the Typed Wildcast FEC. 112 - Specifies the Typed Wildcard FEC Element for the Prefix FEC 113 Element specified by RFC5036. 115 Note that this document does not change procedures specified for the 116 LDP Wildcard FEC Element by RFC5036. 118 2. Specification Language 120 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 121 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 122 document are to be interpreted as described in [RFC2119]. 124 LDP - Label Distribution Protocol 125 FEC - Forwarding Equivalence Class 127 TLV - Type Lenth Value 129 LSR - Label Switch Router 131 3. The Typed Wildcard FEC Element 133 The Typed Wildcard FEC Element refers to all FECs of a given type 134 relative to an optional constraint. The constraint, if present, is 135 determined from the context in which the Typed Wildcard FEC Element 136 appears. 138 The format of the Typed Wildcard FEC Element is: 140 0 1 2 3 141 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 142 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 143 | Typed (IANA) | FEC Element | Len FEC Type | | 144 | Wildcard | Type | Info | | 145 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 146 | | 147 ~ Additional FEC Type-specific Information ~ 148 | | 149 | +-+-+-+-+-+-+-+-+ 150 | | 151 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 153 Figure 1 Typed Wildcard FEC Element 155 where: 157 Typed Wildcard: One octet FEC Element Type (to be assigned by 158 IANA). 160 FEC Element Type: One octet FEC Element Type that specifies the 161 FEC Element Type to be wildcarded. It is defined in section 3.4.1 162 of RFC5036. 164 Len FEC Type Info: One octet that specifies the length in octets 165 of the FEC Type Specific information field. It MUST be set to 0 if 166 there is no Additional FEC Type-specific Information. 168 Additional FEC Type-specific Information: Additional information 169 specific to the FEC Element Type required to fully specify the 170 Typed Wildcard. 172 It is the responsibility of the designer of the FEC Element Type 173 to specify the length and format of any Additional FEC Type 174 Specific Information. 176 This document specifies one FEC Element Type instance for the 'Typed 177 Wildcard FEC Element' in section 6. 179 4. Procedures for the Typed Wildcard FEC Element 181 It is the responsibility of the designer of the FEC Element Type to 182 determine whether typed wildcarding makes sense for the FEC Element 183 Type. If typed wildcarding does make sense, then the specification 184 for the FEC Element Type MUST include support for it. 186 When typed wildcarding is supported for a FEC Element Type, it is 187 the responsibility of the designer to specify the length and format 188 of any Additional FEC Type Specific Information. 190 When a FEC TLV contains a Typed Wildcard FEC Element, the Typed 191 Wildcard FEC Element MUST be the only FEC Element in the TLV. If an 192 LDP speaker receives a FEC TLV containing Typed Wildcard FEC Element 193 and any other FEC Elements, then the LDP speaker should ignore the 194 other FEC Elements and continue processing as if the message had 195 contained only the Typed Wildcard FEC Element. 197 An LDP implementation that supports the Typed Wildcard FEC Element 198 MUST support its use in Label Request, Label Withdraw and Label 199 Release messages. 201 An LDP implementation that supports the Typed Wildcard FEC Element 202 MUST support it for every FEC Element Type implemented for which it 203 is defined. 205 Receipt of a Label Request message with a FEC TLV containing a Typed 206 Wildcard FEC Element is interpreted as a request to send one or more 207 Label Mappings for all FECs of the type specified by the FEC Element 208 Type field in the Typed Wildcard FEC Element encoding. 210 An LDP implementation that supports the Typed Wildcard FEC Element 211 MUST support the following constraints whenever a Typed Wildcard FEC 212 appears in a Label Withdraw or Label Release message: 214 1) If the message carries an optional Label TLV the Typed Wildcard 215 FEC Element refers to all FECs of the specified FEC type bound to 216 the specified label. 218 2) If the message has no Label TLV the Typed Wildcard FEC Element 219 refers to all FECs of the specified FEC type. 221 Backwards compatibility with a router not supporting the Typed 222 Wildcard FEC element is ensured by the FEC procedures defined in 223 RFC5036. Quoting from RFC5036: 225 "If it" [an LSR] "encounters a FEC Element type it cannot decode, 226 it SHOULD stop decoding the FEC TLV, abort processing the message 227 containing the TLV, and send an "Unknown FEC" Notification message 228 to its LDP peer signaling an error." 230 A router receiving a FEC TLV containing a Typed Wildcard FEC element 231 for a FEC Element Type that it either doesn't support or for a FEC 232 Element Type that doesn't support the use of wildcarding MUST stop 233 decoding the FEC TLV, abort processing the message containing the 234 TLV, and send an "Unknown FEC" Notification message to its LDP peer 235 signaling an error. 237 5. Typed Wildcard FEC Capability 239 As noted above, RFC5056 FEC procedures provide for backward 240 compatibility with an LSR not supporting the Typed Wildcard FEC 241 Element. However, they don't provide means for LSR wishing to use 242 the Typed Wildcard FEC Element to determine whether a peer supports 243 it other than to send a message that uses the FEC Element and to 244 wait and see how the peer responds. 246 An LDP speaker that supports the Typed Wildcard FEC Element MUST 247 inform its peers of the support by including a Typed Wildcard FEC 248 Element Capability Parameter [RFC5561] in its Initialization 249 messages. 251 The Capability Parameter for the Typed Wildcard FEC capability is a 252 TLV with the following format: 254 0 1 2 3 255 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 256 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 257 |U|F| Typed WCard FEC Cap (IANA)| Length | 258 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 259 |S| Reserved | 260 +-+-+-+-+-+-+-+-+ 262 Figure 2 Typed Wildcard FEC Capability format 264 Where: 266 U and F bits : MUST be 1 and 0 respectively as per 267 section 3 of LDP Capabilities [RFC5561]. 269 Typed WCard FEC Cap : TLV code point to be assigned by IANA. 271 S-bit : MUST be 1 (indicates that capability is 272 being advertised). 274 6. Typed Wildcard FEC Element for Prefix FEC Element 276 RFC5036 defines the Prefix FEC Element but it does not specify a 277 Typed Wildcard for it. This section specifies the Typed Wildcard 278 FEC Element for Prefix FEC Elements. 280 The format of the Prefix FEC Typed Wildcard FEC ("Prefix FEC 281 Wildcard" for short) is: 283 0 1 2 3 284 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 285 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 286 | Typed Wcard | Type = Prefix | Len = 2 | Address... | 287 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 288 | ...Family | 289 +-+-+-+-+-+-+-+-+ 291 Figure 3 Format of Prefix FEC Element using Typed Wildcard 293 Where: 295 FEC Element Type : Prefix FEC Element (value=2, per RFC5036). 297 Len FEC Type Info : Two octets. 299 Address Family : Two octet quantity containing a value from 300 ADDRESS FAMILY NUMBERS in [IANA-AF]. 302 The procedures described in Section 4 apply to the Prefix FEC 303 Wildcard processing. 305 7. Typed Wildcard FEC Element for Host and Wildcard FEC Elements 307 There is no need to specify Typed Wildcard FEC Elements for the Host 308 FEC Element specified by [RFC3036], nor for the Wildcard FEC Element 309 specified by RFC5036. The [RFC3036] Host FEC Element has been 310 removed from RFC5036, and the Wildcard FEC Element is untyped by 311 definition. 313 In other words, the 'FEC Element Type' field in 'Typed Wildcard FEC 314 Element' can not be 0x01. 316 8. IANA Considerations 318 This draft introduces a new LDP FEC Element Type and a new LDP 319 Capability both of which require IANA assignment - 321 The 'Typed Wildcard' FEC Element requires a code point from the 322 LDP FEC Type Name Space. [RFC5036] partitions the FEC Type Name 323 Space into 3 regions: IETF Consensus region, First Come First 324 Served region, and Private Use region. The authors recommend 325 that the code point 0x05 from the IETF Consensus range be 326 assigned to the 'Typed Wildcard' FEC Element. 328 The 'Typed Wildcard FEC' Capability requires a code point from 329 the TLV Type name space. [RFC5036] partitions the TLV TYPE name 330 space into 3 regions: IETF Consensus region, First Come First 331 Served region, and Private Use region. The authors recommend 332 that a code point from the IETF Consensus range be assigned to 333 the 'Typed Wildcard FEC' Capability. 335 9. Security Considerations 337 No security considerations beyond those that apply to the base LDP 338 specification [RFC5036] and further described in [MPLSsec] apply to 339 use of the Typed Wildcard FEC Elements as described in this 340 document. 342 10. Acknowledgments 344 The authors would like to thank Yakov Rekhter for suggesting that 345 the limitations of the Wildcard FEC be addressed. Also, thanks to 346 Adrian Farrel for extensive review of this document. 348 This document was prepared using 2-Word-v2.0.template.dot. 350 11. References 352 11.1. Normative References 354 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 355 Requirement Levels", BCP 14, RFC 2119, March 1997. 357 [RFC5036] Andersson, L., Minei, I., and Thomas, B., "LDP 358 Specification", RFC 5036, October 2007. 360 [RFC5561] Thomas, B., Aggarwal, S., Aggarwal, R., Le Roux, J.L., 361 "LDP Capabilities", RFC5561, May 2007. 363 11.2. Informative References 365 [RFC3036] Andersson, L., Doolan, P., Feldman, N., Fredette, A. and 366 Thomas, B., "LDP Specification", RFC 3036, January 2001. 368 [RFC4447] Martini, L., Editor, "Pseudowire Setup and Maintenance 369 Using the label Distribution Protocol (LDP)", RFC4447, 370 April 2006. 372 [MLDP] Minei, I., Wijnands, I., Editors, "Label Distribution 373 Protocol Extensions for Point-to-Multipoint and 374 Multipoint-to-Multipoint Label Switched Paths", draft- 375 ietf-mpls-ldp-p2mp-08.txt, Work in Progress, Oct 2009. 377 [MPLSsec] Fang, L., "Security Framework for MPLS and GMPLS 378 Networks", draft-ietf-mpls-mpls-and-gmpls-security- 379 framework-07, Work in Progress, Oct 2009. 381 [IANA-AF] http://www.iana.org/assignments/address-family-numbers. 383 Author's Addresses 385 Ina Minei 386 Juniper Networks 387 1194 North Mathilda Ave. 388 Sunnyvale, CA 94089 389 Email: ina@juniper.net 391 Bob Thomas 392 Email: bobthomas@alum.mit.edu 394 Rajiv Asati 395 Cisco Systems, 396 7025-6 Kit Creek Rd, RTP, NC, 27709-4987 397 Email: rajiva@cisco.com