idnits 2.17.1 draft-ietf-mpls-ldp-typed-wildcard-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.i or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. 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 : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RFC5036]), 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 seems to contain a disclaimer for pre-RFC5378 work, and may have content which was first submitted before 10 November 2008. The disclaimer is necessary when there are original authors that you have been unable to contact, or if some do not wish to grant the BCP78 rights to the IETF Trust. If you are able to get all authors (current and original) to grant those rights, you can and should remove the disclaimer; otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (September 5, 2009) is 5341 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-07 == Outdated reference: A later version (-09) exists of draft-ietf-mpls-mpls-and-gmpls-security-framework-06 Summary: 2 errors (**), 0 flaws (~~), 3 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 MPLS Working Group Bob Thomas 2 Internet Draft 3 Intended status: Standards Track 4 Expires: Feb 2010 Ina Minei 5 Juniper Networks 7 Rajiv Asati 8 Cisco Systems 10 September 5, 2009 12 LDP Typed Wildcard FEC 13 draft-ietf-mpls-ldp-typed-wildcard-04.txt 15 Status of this Memo 17 This Internet-Draft is submitted to IETF in full conformance with the 18 provisions of BCP 78 and BCP 79. This document may contain material 19 from IETF Documents or IETF Contributions published or made publicly 20 available before November 10, 2008. The person(s) controlling the 21 copyright in some of this material may not have granted the IETF 22 Trust the right to allow modifications of such material outside the 23 IETF Standards Process. Without obtaining an adequate license from 24 the person(s) controlling the copyright in such materials, this 25 document may not be modified outside the IETF Standards Process, and 26 derivative works of it may not be created outside the IETF Standards 27 Process, except to format it for publication as an RFC or to 28 translate it into languages other than English. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF), its areas, and its working groups. Note that 32 other groups may also distribute working documents as Internet- 33 Drafts. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 The list of current Internet-Drafts can be accessed at 41 http://www.ietf.org/ietf/1id-abstracts.txt 43 The list of Internet-Draft Shadow Directories can be accessed at 44 http://www.ietf.org/shadow.html 46 This Internet-Draft will expire on Feb 5, 2010. 48 Copyright Notice 50 Copyright (c) 2009 IETF Trust and the persons identified as the 51 document authors. All rights reserved. 53 This document is subject to BCP 78 and the IETF Trust's Legal 54 Provisions Relating to IETF Documents in effect on the date of 55 publication of this document (http://trustee.ietf.org/license-info). 56 Please review these documents carefully, as they describe your rights 57 and restrictions with respect to this document. 59 Abstract 61 The LDP specification [RFC5036] for the Wildcard FEC element has 62 several deficiencies. This document corrects those deficiencies. In 63 addition, it specifies the Typed Wildcard FEC for the Prefix FEC 64 Element Type defined in RFC5036. 66 Table of Contents 68 1. Introduction...................................................3 69 2. Specification Language.........................................4 70 3. The Typed Wildcard FEC Element.................................4 71 4. Procedures for the Typed Wildcard FEC Element..................5 72 5. Typed Wildcard FEC Capability..................................6 73 6. Typed Wildcard FEC Element for Prefix FEC Element..............7 74 7. Typed Wildcard FEC Element for Host and Wildcard FEC Elements..8 75 8. IANA Considerations............................................8 76 9. Security Considerations........................................8 77 10. Acknowledgments...............................................8 78 11. References....................................................9 79 11.1. Normative References.....................................9 80 11.2. Informative References...................................9 81 Author's Addresses...............................................10 83 1. Introduction 85 LDP [RFC5036] distributes labels for Forwarding Equivalence Classes 86 (FECs). LDP uses FEC TLVs in LDP messages to specify FECs. An LDP 87 FEC TLV includes 1 or more FEC Elements. A FEC element includes a 88 FEC type and an optional type-dependent value. 90 RFC5036 specifies two FEC types (Prefix and Wildcard), and other 91 documents specify additional FEC types; e.g., see [RFC4447] [MLDP]. 93 As specified by RFC5036 the Wildcard FEC Element refers to all FECs 94 relative to an optional constraint. The only constraint RFC5036 95 specifies is one that limits the scope of the Wildcard FEC Element to 96 "all FECs bound to a given label". 98 The RFC5036 specification of the Wildcard FEC Element has the 99 following deficiencies which limit its utility: 101 1) The Wildcard FEC Element is untyped. There are situations where 102 it would be useful to be able to refer to all FECs of a given 103 type. 105 2) Use of the Wildcard FEC Element is limited to Label Withdraw and 106 Label Release messages only. There are situations where it would 107 be useful in Label Request messages. 109 This document: 111 - Addresses the above deficiencies by defining a Typed Wildcard 112 FEC Element and procedures for its use. 114 - Specifies use of the LDP capability mechanism [RFC5561] at 115 session establishment time for informing a peer that an LDP 116 speaker is capable of handling the Typed Wildcast FEC. 118 - Specifies the Typed Wildcard FEC Element for the Prefix FEC 119 Element specified by RFC5036. 121 Note that this document does not change procedures specified for the 122 LDP Wildcard FEC Element by RFC5036. 124 2. Specification Language 126 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 127 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 128 document are to be interpreted as described in [RFC2119]. 130 3. The Typed Wildcard FEC Element 132 The Typed Wildcard FEC Element refers to all FECs of a given type 133 relative to an optional constraint. The constraint, if present, is 134 determined from the context in which the Typed Wildcard FEC Element 135 appears. 137 The format of the Typed Wildcard FEC Element is: 139 0 1 2 3 140 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 141 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 142 | Typed (IANA) | FEC Element | Len FEC Type | | 143 | Wildcard | Type | Info | | 144 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 145 | | 146 ~ Additional FEC Type-specific Information ~ 147 | | 148 | +-+-+-+-+-+-+-+-+ 149 | | 150 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 152 Figure 1 Typed Wildcard FEC Element 154 where: 156 Typed Wildcard: One octet FEC Element Type (to be assigned by 157 IANA). 159 FEC Element Type: One octet FEC Element Type that specifies the 160 FEC Element Type to be wildcarded. 162 Len FEC Type Info: One octet that specifies the length of the FEC 163 Type Specific information field. MUST be 0 if there is no 164 Additional FEC Type-specific Information. 166 Additional FEC Type-specific Information: Additional information 167 specific to the FEC Element Type required to fully specify the 168 Typed Wildcard. 170 Specification of the length and format of Additional FEC Type 171 Specific Information for particular FEC Element Types is outside of 172 the scope of this document. It is the responsibility of the 173 designer of the FEC Element Type to specify the length and format 174 of any Additional FEC Type Specific Information. 176 This document discusses two instances of Typed Wildcard FEC Elements 177 in section 6 and 7. 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 the FEC Element Type. 183 If typed wildcarding does make sense the specification for the FEC 184 Element Type MUST include support for it. 186 When typed wildcarding is supported for a FEC Element Type it is the 187 responsibility of the designer to specify the length and format of 188 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. 193 An LDP implementation that supports the Typed Wildcard FEC Element 194 MUST support its use in Label Request, Label Withdraw and Label 195 Release messages. 197 An LDP implementation that supports the Typed Wildcard FEC Element 198 MUST support it for every FEC Element Type implemented for which it 199 is defined. 201 Receipt of a Label Request message with a FEC TLV containing a Typed 202 Wildcard FEC Element is interpreted as a request to send a Label 203 Mapping for all FECs of the type specified by the FEC Element Type 204 field in the Typed Wildcard FEC Element encoding. 206 An LDP implementation that supports the Typed Wildcard FEC Element 207 MUST support the following constraints whenever a Typed Wildcard FEC 208 appears in a Label Withdraw or Label Release message: 210 1) If the message carries an optional Label TLV the Typed Wildcard 211 FEC Element refers to all FECs of the specified FEC type bound to 212 the specified label. 214 2) If the message has no Label TLV the Typed Wildcard FEC Element 215 refers to all FECs of the specified FEC type. 217 Backwards compatibility with a router not supporting the Typed 218 Wildcard FEC element is ensured by the FEC procedures defined in 219 RFC5036. Quoting from RFC5036: 221 "If it" [an LSR] "encounters a FEC Element type it cannot decode, 222 it SHOULD stop decoding the FEC TLV, abort processing the message 223 containing the TLV, and send an "Unknown FEC" Notification message 224 to its LDP peer signaling an error." 226 A router receiving a FEC TLV containing a Typed Wildcard FEC element 227 for a FEC Element Type that it either doesn't support or for a FEC 228 Element Type that doesn't support the use of wildcarding MUST stop 229 decoding the FEC TLV, abort processing the message containing the 230 TLV, and send an "Unknown FEC" Notification message to its LDP peer 231 signaling an error. 233 5. Typed Wildcard FEC Capability 235 As noted above, RFC5056 FEC procedures provide for backward 236 compatibility with a LSR not supporting the Typed Wildcard FEC 237 Element. However, they don't provide means for LSR wishing to use 238 the Typed Wildcard FEC Element to determine whether a peer supports 239 it other than to send a message that uses the FEC Element and to wait 240 and see how the peer responds. 242 An LDP speaker that supports the Typed Wildcard FEC Element MUST 243 inform its peers of the support by including a Typed Wildcard FEC 244 Element Capability Parameter [RFC5561] in its Initialization 245 messages. 247 The Capability Parameter for the Typed Wildcard FEC capability is a 248 TLV with the following format: 250 0 1 2 3 251 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 252 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 253 |U|F| Typed WCard FEC Cap (IANA)| Length | 254 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 255 |S| Reserved | 256 +-+-+-+-+-+-+-+-+ 258 Figure 2 Typed Wildcard FEC Capability format 260 Where: 262 U and F bits : MUST be 1 and 0 respectively as per section 263 3 of LDP Capabilities [RFC5561]. 265 Typed WCard FEC Cap : TLV code point to be assigned by IANA. 267 S-bit : MUST be 1 (indicates that capability is 268 being advertised). 270 6. Typed Wildcard FEC Element for Prefix FEC Element 272 RFC5036 defines the Prefix FEC Element but it does not specify a 273 Typed Wildcard for it. This section specifies the Typed Wildcard FEC 274 Element for Prefix FEC Elements. 276 The format of the Prefix FEC Typed Wildcard FEC ("Prefix FEC 277 Wildcard" for short) is: 279 0 1 2 3 280 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 281 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 282 | Typed Wcard | Prefix (2) | 2 | Address... | 283 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 284 | ...Family | 285 +-+-+-+-+-+-+-+-+ 287 Figure 3 Format of Prefix FEC Element using Typed Wildcard 289 Where: 291 Address Family: Two octet quantity containing a value from ADDRESS 292 FAMILY NUMBERS in [IANA-AF]. 294 The procedures of Section 4 apply to the Prefix FEC Wildcard. 296 7. Typed Wildcard FEC Element for Host and Wildcard FEC Elements 298 There is no need to specify Typed Wildcard FEC Elements for the Host 299 FEC Element specified by [RFC3036], nor for the Wildcard FEC Element 300 specified by RFC5036. The [RFC3036] Host FEC Element has been removed 301 from RFC5036, and the Wildcard FEC Element is untyped by definition. 303 8. IANA Considerations 305 This draft introduces a new LDP FEC Element Type and a new LDP 306 Capability both of which require IANA assignment - 308 The 'Typed Wildcard' FEC Element requires a code point from the 309 LDP FEC Type Name Space. [RFC5036] partitions the FEC Type Name 310 Space into 3 regions: IETF Consensus region, First Come First 311 Served region, and Private Use region. The authors recommend that 312 the code point 0x05 from the IETF Consensus range be assigned to 313 the 'Typed Wildcard' FEC Element. 315 The 'Typed Wildcard FEC' Capability requires a code point from the 316 TLV Type name space. [RFC5036] partitions the TLV TYPE name space 317 into 3 regions: IETF Consensus region, First Come First Served 318 region, and Private Use region. The authors recommend that a code 319 point from the IETF Consensus range be assigned to the 'Typed 320 Wildcard FEC' Capability. 322 9. Security Considerations 324 No security considerations beyond those that apply to the base LDP 325 specification [RFC5036] and further described in [MPLSsec] apply to 326 use of the Typed Wildcard FEC Elements as described in this document. 328 10. Acknowledgments 330 The authors would like to thank Yakov Rekhter for suggesting that the 331 deficiencies of the Wildcard FEC be addressed. 333 This document was prepared using 2-Word-v2.0.template.dot. 335 11. References 337 11.1. Normative References 339 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 340 Requirement Levels", BCP 14, RFC 2119, March 1997. 342 [RFC5036] Andersson, L., Minei, I., and Thomas, B., "LDP 343 Specification", RFC 5036, October 2007. 345 [RFC5561] Thomas, B., Aggarwal, S., Aggarwal, R., Le Roux, J.L., "LDP 346 Capabilities", RFC5561, May 2007. 348 11.2. Informative References 350 [RFC3036] Andersson, L., Doolan, P., Feldman, N., Fredette, A. and 351 Thomas, B., "LDP Specification", RFC 3036, January 2001. 353 [RFC4447] Martini, L., Editor, "Pseudowire Setup and Maintenance 354 Using the label Distribution Protocol (LDP)", RFC4447, 355 April 2006. 357 [MLDP] Minei, I., Wijnands, I., Editors, "Label Distribution 358 Protocol Extensions for Point-to-Multipoint and Multipoint- 359 to-Multipoint Label Switched Paths", draft-ietf-mpls-ldp- 360 p2mp-07.txt, Work in Progress, July 2009. 362 [MPLSsec] Fang, L., "Security Framework for MPLS and GMPLS Networks", 363 draft-ietf-mpls-mpls-and-gmpls-security-framework-06, Work 364 in Progress, July 13 2009. 366 [IANA-AF] http://www.iana.org/assignments/address-family-numbers. 368 Author's Addresses 370 Ina Minei 371 Juniper Networks 372 1194 North Mathilda Ave. 373 Sunnyvale, CA 94089 374 Email: ina@juniper.net 376 Bob Thomas 377 Email: bobthomas@alum.mit.edu 379 Rajiv Asati 380 Cisco Systems, 381 7025-6 Kit Creek Rd, RTP, NC, 27709-4987 382 Email: rajiva@cisco.com