idnits 2.17.1 draft-ietf-mpls-ldp-typed-wildcard-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 19. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 384. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 354. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 361. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 367. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard 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 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 (November 2007) is 5979 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) == Outdated reference: A later version (-04) exists of draft-ietf-mpls-ldp-capabilities-00 -- Possible downref: Non-RFC (?) normative reference: ref. 'IANA-AF' -- Obsolete informational reference (is this intentional?): RFC 3036 (Obsoleted by RFC 5036) -- Obsolete informational reference (is this intentional?): RFC 4447 (ref. 'PWE3') (Obsoleted by RFC 8077) == Outdated reference: A later version (-15) exists of draft-ietf-mpls-ldp-p2mp-03 Summary: 2 errors (**), 0 flaws (~~), 4 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Bob Thomas 3 Internet Draft Cisco Systems, Inc. 4 Expiration Date: May 2008 5 Ina Minei 6 Juniper Networks 8 November 2007 10 LDP Typed Wildcard FEC 12 draft-ietf-mpls-ldp-typed-wildcard-02.txt 14 Status of this Memo 16 By submitting this Internet-Draft, each author represents that any 17 applicable patent or other IPR claims of which he or she is aware 18 have been or will be disclosed, and any of which he or she becomes 19 aware will be disclosed, in accordance with Section 6 of 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 months 27 and may be updated, replaced, or obsoleted by other documents at any 28 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 Copyright Notice 39 Copyright (C) The IETF TRUST (2007). 41 Abstract 43 The LDP specification [RFC5036] for the Wildcard FEC element has 44 several deficiencies. This document corrects those deficiencies. In 45 addition, it specifies the Typed Wildcard FEC for the Prefix FEC 46 Element Type defined in RFC5036. 48 Table of Contents 50 1 Introduction ....................................... 2 51 2 Specification Language ............................. 3 52 3 The Typed Wildcard FEC Element ..................... 3 53 4 Procedures for the Typed Wildcard FEC Element ...... 4 54 5 Typed Wildcard FEC Capability ...................... 5 55 6 Typed Wildcard FEC Element for Prefix FEC Element .. 6 56 7 Host FEC and Wildcard FEC Elements ................. 7 57 8 IANA Considerations ................................ 7 58 9 Security Considerations ............................ 7 59 10 Acknowledgements ................................... 7 60 11 References ......................................... 8 61 12 Author Information ................................. 8 62 13 Intellectual Property Statement .................... 9 63 14 Full Copyright Statement ........................... 9 65 1. Introduction 67 LDP [RFC5036] distributes labels for Forwarding Equivalence Classes 68 (FECs). LDP uses FEC TLVs in LDP messages to specify FECs. An LDP 69 FEC TLV includes 1 or more FEC Elements. A FEC element includes a 70 FEC type and an optional type-dependent value. 72 RFC5036 specifies two FEC types (Prefix and Wildcard), and other 73 documents specify additional FEC types; e.g., see [PWE3] [MLDP]. 75 As specified by RFC5036 the Wildcard FEC Element refers to all FECs 76 relative to an optional constraint. The only constraint RFC5036 77 specifies is one that limits the scope of the Wildcard FEC Element to 78 "all FECs bound to a given label". 80 The RFC5036 specification of the Wildcard FEC Element has the 81 following deficiencies which limit its utility: 83 1. The Wildcard FEC Element is untyped. There are situations 84 where it would be useful to be able to refer to all FECs of a 85 given type. 87 2. Use of the Wildcard FEC Element is limited to Label Withdraw 88 and Label Release messages only. There are situations where it 89 would be useful in Label Request messages. 91 This document: 93 - Addresses the above deficiencies by defining a Typed Wildcard 94 FEC Element and procedures for its use. 96 - Specifies use of the LDP capability mechanism [LDPCap] at 97 session establishment time for informing a peer that an LDP 98 speaker is capable of handling the Typed Wildcast FEC. 100 - Specifies the Typed Wildcard FEC Element for the Prefix FEC 101 Element specified by RFC5036. 103 Note that this document does not change procedures specified for the 104 LDP Wildcard FEC Element by RFC5036. 106 2. Specification Language 108 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 109 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 110 document are to be interpreted as described in [RFC2119]. 112 3. The Typed Wildcard FEC Element 114 The Typed Wildcard FEC Element refers to all FECs of a given type 115 relative to an optional constraint. The constraint, if present, is 116 determined from the context in which the Typed Wildcard FEC Element 117 appears. 119 The format of the Typed Wildcard FEC Element is: 121 0 1 2 3 122 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 123 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 124 | Typed (IANA) | FEC Element | Len FEC Type | | 125 | Wildcard | Type | Info | | 126 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 127 | | 128 ~ Additional FEC Type-specific Information ~ 129 | | 130 | +-+-+-+-+-+-+-+-+ 131 | | 132 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 134 where: 136 Typed Wildcard: One octet FEC Element Type (to be assigned by 137 IANA). 139 FEC Element Type: One octet FEC Element Type that specifies the 140 FEC Element Type to be wildcarded. 142 Len FEC Type Info: One octet that specifies the length of the FEC 143 Type Specific information field. MUST be 0 if there is no 144 Additional FEC Type-specific Information. 146 Additional FEC Type-specific Information: Additional information 147 specific to the FEC Element Type required to fully specify the 148 Typed Wildcard. 150 Specification of the length and format of Additional FEC Type 151 Specific Information for particular FEC Element Types is outside of 152 the scope of this document. It is the responsibility of the designer 153 of the FEC Element Type to specify the length and format of any 154 Additional FEC Type Specific Information. 156 4. Procedures for the Typed Wildcard FEC Element 158 It is the responsibility of the designer of the FEC Element Type to 159 determine whether typed wildcarding makes sense the FEC Element Type. 160 If typed wildcarding does make sense the specification for the FEC 161 Element Type MUST include support for it. 163 When typed wildcarding is supported for a FEC Element Type it is the 164 responsibility of the designer to specify the length and format of 165 any Additional FEC Type Specific Information. 167 When a FEC TLV contains a Typed Wildcard FEC Element the Typed 168 Wildcard FEC Element MUST be the only FEC Element in the TLV. 170 An LDP implementation that supports the Typed Wildcard FEC Element 171 MUST support its use in Label Request, Label Withdraw and Label 172 Release messages. 174 An LDP implementation that supports the Typed Wildcard FEC Element 175 MUST support it for every FEC Element Type implemented for which it 176 is defined. 178 Receipt of a Label Request message with a FEC TLV containing a Typed 179 Wildcard FEC Element is interpreted as a request to send a Label 180 Mapping for all FECs of the type specified by the FEC Element Type 181 field in the Typed Wildcard FEC Element encoding. 183 An LDP implementation that supports the Typed Wildcard FEC Element 184 MUST support the following constraints whenever a Typed Wildcard FEC 185 appears in a Label Withdraw or Label Release message: 187 1. If the message carries an optional Label TLV the Typed Wildcard 188 FEC Element refers to all FECs of the specified FEC type bound to 189 the specified label. 191 2. If the message has no Label TLV the Typed Wildcard FEC Element 192 refers to all FECs of the specified FEC type. 194 Backwards compatibility with a router not supporting the Typed 195 Wildcard FEC element is ensured by the FEC procedures defined in 196 RFC5036. Quoting from RFC5036: 198 "If it" [an LSR] "encounters a FEC Element type it cannot decode, 199 it SHOULD stop decoding the FEC TLV, abort processing the 200 message containing the TLV, and send an "Unknown FEC" 201 Notification message to its LDP peer signaling an error." 203 A router receiving a FEC TLV containing a Typed Wildcard FEC element 204 for a FEC Element Type that it either doesn't support or for a FEC 205 Element Type that doesn't support the use of wildcarding MUST stop 206 decoding the FEC TLV, abort processing the message containing the 207 TLV, and send an "Unknown FEC" Notification message to its LDP peer 208 signaling an error. 210 5. Typed Wildcard FEC Capability 212 As noted above RFC5056 FEC procedures provide for backward 213 compatibility with a LSR not supporting the Typed Wildcard FEC 214 Element. However, they don't provide means for LSR wishing to use 215 the Typed Wildcard FEC Element to determine whether a peer supports 216 it other than to send a message that uses the FEC Element and to wait 217 and see how the peer responds. 219 An LDP speaker that supports the Typed Wildcard FEC Element MUST 220 inform its peers of the support by including a Typed Wildcard FEC 221 Element Capability Parameter [LDPCap] in its Initialization messages. 223 The Capability Parameter for the Typed Wildcard FEC capability is a 224 TLV with the following format: 226 0 1 2 3 227 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 228 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 229 |U|F|Typed WCard FEC Cap (IANA) | Length | 230 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 231 |S| Reserved | 232 +-+-+-+-+-+-+-+-+ 234 where: 236 U and F bits: As specified by RFC5036. 238 Typed WCard FEC Cap: TLV code point for the Typed Wildcard FEC 239 capability (to be assigned by IANA). 241 S-bit: Must be 1 (indicates that capability is being advertised). 243 6. Typed Wildcard FEC Element for Prefix FEC Element 245 RFC5036 defines the Prefix FEC Element but it does not specify a 246 Typed Wildcard for it. This section specifies the Typed Wildcard FEC 247 Element for Prefix FEC Elements. 249 The format of the Prefix FEC Typed Wildcard FEC ("Prefix FEC 250 Wildcard" for short) is: 251 0 1 2 3 252 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 253 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 254 | Typed WCard | Prefix (2) | 2 | Address... | 255 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 256 | ...Family | 257 +-+-+-+-+-+-+-+-+ 259 Address Family: Two octet quantity containing a value from ADDRESS 260 FAMILY NUMBERS in [IANA-AF]. 262 The procedures of Section 4 apply to the Prefix FEC Wildcard. 264 7. Host FEC and Wildcard FEC Elements 266 There is no need to specify Typed Wildcard FEC Elements for the Host 267 FEC Element specified by [RFC3036] nor for the Wildcard FEC Element 268 specified by RFC5036. The [RFC3036] Host FEC Element has been 269 removed from RFC5036, and the Wildcard FEC Element is untyped by 270 definition. 272 8. IANA Considerations 274 This draft introduces a new LDP FEC Element Type and a new LDP 275 Capability both of which require code points. 277 The Typed Wildcard FEC Element requires a code point from the LDP FEC 278 Type name space. [RFC5036] partitions the FEC TYPE name space into 3 279 regions: IETF Consensus region, First Come First Served region, and 280 Private Use region. The authors recommend that the code point 0x05 281 from the IETF Consensus range be assigned to the Typed Wildcard FEC 282 Element. 284 The Typed Wildcard FEC Capability requires a code point from the TLV 285 Type name space. [RFC5036] partitions the TLV TYPE name space into 3 286 regions: IETF Consensus region, First Come First Served region, and 287 Private Use region. The authors recommend that a code point from the 288 IETF Consensus range be assigned to the Typed Wildcard FEC 289 Capability. 291 9. Security Considerations 293 No security considerations beyond those that apply to the base LDP 294 specification and described in [RFC5036] apply to use of the Typed 295 Wildcard FEC Element defined in this document. 297 10. Acknowledgements 299 The authors wish to thank Yakov Rehkter for suggesting that the 300 deficiencies of the Wildcard FEC be addressed. 302 11. References 304 Normative References 306 [RFC5036] Andersson, L., Minei, I., Thomas, B., Editors, "LDP 307 Specification", RFC 5036, October 2007. 309 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 310 Requirement Levels", BCP 14, RFC2119, March 1997. 312 [LDPCap] Thomas, B., Aggarwal, S., Aggarwal, R., Le Roux, J.L., 313 "LDP Capabilities", draft-ietf-mpls-ldp-capabilities-00, Work in 314 Progress, May 2007. 316 [IANA-AF] http://www.iana.org/assignments/address-family-numbers 318 Informative References 320 [RFC3036] Andersson, L., Doolan, P., Feldman, N., Fredette, A. and 321 Thomas, B., "LDP Specification", RFC 3036, January 2001. 323 [PWE3] Martini, L., Editor, "Pseudowire Setup and Maintenance Using 324 the Label Distribution Protocol (LDP)", RFC 4447, April 2006. 326 [MLDP] Minei, I., Wijnands, I., Editors, "Label Distribution 327 Protocol Extensions for Point-to-Multipoint and Multipoint-to- 328 Multipoint Label Switched Paths", draft-ietf-mpls-ldp-p2mp-03.txt, 329 Work in Progress, July 2007. 331 12. Author Information 333 Bob Thomas 334 Cisco Systems, Inc. 335 1414 Massachusetts Ave. 336 Boxborough MA 01719 337 Email: rhthomas@cisco.com 339 Ina Minei 340 Juniper Networks 341 1194 North Mathilda Ave. 342 Sunnyvale, CA 94089 343 Email: ina@juniper.net 345 13. Intellectual Property Statement 347 The IETF takes no position regarding the validity or scope of any 348 Intellectual Property Rights or other rights that might be claimed to 349 pertain to the implementation or use of the technology described in 350 this document or the extent to which any license under such rights 351 might or might not be available; nor does it represent that it has 352 made any independent effort to identify any such rights. Information 353 on the procedures with respect to rights in RFC documents can be 354 found in BCP 78 and BCP 79. 356 Copies of IPR disclosures made to the IETF Secretariat and any 357 assurances of licenses to be made available, or the result of an 358 attempt made to obtain a general license or permission for the use of 359 such proprietary rights by implementers or users of this 360 specification can be obtained from the IETF on-line IPR repository at 361 http://www.ietf.org/ipr. 363 The IETF invites any interested party to bring to its attention any 364 copyrights, patents or patent applications, or other proprietary 365 rights that may cover technology that may be required to implement 366 this standard. Please address the information to the IETF at ietf- 367 ipr@ietf.org. 369 14. Full Copyright Statement 371 Copyright (C) The IETF Trust (2007). 373 This document is subject to the rights, licenses and restrictions 374 contained in BCP 78, and except as set forth therein, the authors 375 retain all their rights. 377 This document and the information contained herein are provided on an 378 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 379 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST 380 AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, 381 EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT 382 THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY 383 IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR 384 PURPOSE.