idnits 2.17.1 draft-thomas-mpls-ldp-typed-wildcard-00.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 on line 315. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 281. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 288. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 294. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. 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 ([RFC3036]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 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 (October 2006) is 6402 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 3036 (Obsoleted by RFC 5036) -- Possible downref: Non-RFC (?) normative reference: ref. 'IANA-AF' -- 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-00 Summary: 5 errors (**), 0 flaws (~~), 3 warnings (==), 9 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: April 2007 5 Ina Minei 6 Juniper Networks 8 October 2006 10 LDP Typed Wildcard FEC 12 draft-thomas-mpls-ldp-typed-wildcard-00.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 Internet Society (2006). 41 Abstract 43 The LDP specification [RFC3036] 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 RFC3036. 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 Element for RFC3036 Prefix FEC Element 5 55 6 Security Considerations ............................... 5 56 7 IANA Considerations ................................... 5 57 8 Acknowledgements ...................................... 6 58 9 References ............................................ 6 59 10 Author Information .................................... 6 60 11 Intellectual Property Statement ....................... 7 61 12 Full Copyright Statement .............................. 7 63 1. Introduction 65 LDP [RFC3036] distributes labels for Forwarding Equivalence Classes 66 (FECs). LDP uses FEC TLVs in LDP messages to specify FECs. An LDP 67 FEC TLV includes 1 or more FEC Elements. A FEC element includes a 68 FEC type and an optional type-dependent value. 70 RFC3036 specifies two FEC types (Wildcard and Prefix), and other 71 documents specify additional FEC types; e.g., see [PWE3] [MLDP]. 73 As specified in RFC3036 the Wildcard FEC Element refers to all FECs 74 relative to an optional constraint. The only constraint RFC3036 75 specifies is one that limits the scope of the Wildcard FEC Element to 76 "all FECs bound to a given label". 78 The RFC3036 specification of the Wildcard FEC Element has the 79 following deficiencies which limit its utility: 81 1. The Wildcard FEC Element is untyped. There are situations 82 where it would be useful to be able to refer to all FECs of a 83 given type. 85 2. Use of the Wildcard FEC Element is limited to Label Withdraw 86 and Label Release messages only. There are situations where it 87 would be useful in Label Request messages. 89 This document addresses these deficiencies by defining a Typed 90 Wildcard FEC Element and procedures for its use. 92 2. Specification Language 94 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 95 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 96 document are to be interpreted as described in [RFC2119]. 98 3. The Typed Wildcard FEC Element 100 The Typed Wildcard FEC Element refers to all FECs of a given type 101 relative to an optional constraint. The constraint, if present, is 102 determined from the context in which the Typed Wildcard FEC Element 103 appears. 105 The format of the Typed Wildcard FEC Element is: 107 0 1 2 108 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 109 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 110 | Typed (IANA) | FEC Element | Len FEC Type | | 111 | Wildcard | Type | Info | | 112 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 113 | | 114 | Additional FEC Type-specific Information | 115 | +-+-+-+-+-+-+-+-+ 116 | | 117 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 119 where: 121 Typed Wildcard: One octet FEC Element type to be assigned by IANA. 123 FEC Element Type: One octet FEC Element Type that specifies the 124 FEC Element Type to be wildcarded. 126 Len FEC Type Info: One octet that specifies the length of the FEC 127 Type Specific information field. MUST be 0 if there is no 128 Additional FEC Type-specific Information. 130 Additional FEC Type-specific Information: Additional information 131 specific to the FEC Element Type required to fully specify the 132 Typed Wildcard. 134 Specification of the length and format of Additional FEC Type 135 Specific Information for particular FEC Element Types is outside of 136 the scope of this document. 138 4. Procedures for the Typed Wildcard FEC Element 140 It is the responsibility of the designer of the FEC Element Type to 141 specify whether typed wildcarding is required for the FEC Element 142 Type. When typed wildcarding is supported for a FEC Element Type it 143 is the responsibility of the designer to specify the length and 144 format of any Additional FEC Type Specific Information. 146 When a FEC TLV contains a Typed Wildcard FEC Element the Typed 147 Wildcard FEC Element MUST be the only FEC Element in the TLV. 149 An LDP implementation that supports the Typed Wildcard FEC Element 150 MUST support its use in Label Request, Label Withdraw and Label 151 Release messages. 153 Receipt of a Label Request message with a FEC TLV containing a Typed 154 Wildcard FEC Element is interpreted as a request to send a Label 155 Mapping for all FECs of the type specified by the FEC Element type in 156 the Typed Wildcard FEC Element encoding. 158 An LDP implementation that supports the Typed Wildcard FEC Element 159 MUST support the following constraints whenever a Typed Wildcard FEC 160 appears in a Label Withdraw or Label Release message: 162 1. If the message carries an optional Label TLV the Typed Wildcard 163 FEC Element refers to all FECs of the specified FEC type bound to 164 the specified label. 166 2. If the message has no Label TLV the Typed Wildcard FEC Element 167 refers to all FECs of the specified FEC type. 169 Backwards compatibility with a router not supporting the Typed 170 Wildcard FEC element is ensured by the FEC procedures defined in 171 RFC3036. Quoting from RFC3036: 173 "If it" [an LSR] "encounters a FEC Element type it cannot decode, 174 it SHOULD stop decoding the FEC TLV, abort processing the 175 message containing the TLV, and send an "Unknown FEC" 176 Notification message to its LDP peer signaling an error." 178 A router receiving a FEC TLV containing a Typed Wildcard FEC element 179 for a FEC Element Type that it either doesn't support or for a FEC 180 Element Type that doesn't support the use of wildcarding MUST stop 181 decoding the FEC TLV, abort processing the message containing the 182 TLV, and send an "Unknown FEC" Notification message to its LDP peer 183 signaling an error. 185 5. Typed Wildcard FEC Element for RFC3036 Prefix FEC Element 187 RFC3036 defines the Prefix FEC Element but it does not specify a 188 Typed Wildcard for it. This section specifies the Typed Wildcard FEC 189 Element for RFC3036 Prefix Elements. 191 The format of the Prefix FEC Typed Wildcard FEC ("Prefix FEC 192 Wildcard" for short) is: 193 0 1 2 3 194 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 195 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 196 | Typed WCard | Prefix (2) | 2 | Address... | 197 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 198 | ...Family | 199 +-+-+-+-+-+-+-+-+ 201 Address Family: Two octet quantity containing a value from ADDRESS 202 FAMILY NUMBERS in [IANA-AF]. 204 The procedures of Section 4 apply to the Prefix FEC Wildcard. 206 6. Security Considerations 208 No security considerations beyond those that apply to the base LDP 209 specification and described in [RFC3036] apply to use of the Typed 210 Wildcard FEC Element defined in this document. 212 7. IANA Considerations 214 The Typed Wildcard FEC Element requires a code point from the LDP FEC 215 Type Name Space. IANA manages the FEC TYPE name space as recommended 216 by the following from [RFC3036]: 218 "FEC Type Name Space 220 The range for FEC types is 0 - 255. 222 Following the policies outlined in [RFC3036], FEC types in the 223 range 0 - 127 are allocated through an IETF Consensus action, 224 types in the range 128 - 191 are allocated as First Come First 225 Served, and types in the range 192 - 255 are reserved for Private 226 Use." 228 The authors recommend that the code point for the Typed Wildcard FEC 229 Element be assigned from the 0-127 (IETF Consensus) range. 231 8. Acknowledgements 233 The authors wish to thank Yakov Rehkter for suggesting that the 234 deficiencies of the Wildcard FEC be addressed. 236 9. References 238 Normative References 240 [RFC3036] Andersson, L., Doolan, P., Feldman, N., Fredette, A. and 241 Thomas, B., "LDP Specification", RFC 3036, January 2001. 243 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 244 Requirement Levels", BCP 14, RFC2119, March 1997. 246 [IANA-AF] http://www.iana.org/assignments/address-family-numbers 248 Informative References 250 [PWE3] Martini, L., Editor, "Pseudowire Setup and Maintenance Using 251 the Label Distribution Protocol (LDP)", RFC 4447, April 2006. 253 [MLDP] Minei, I., Wijnamds, I., Editors, "Label Distribution 254 Protocol Extensions for Point-to-Multipoint and Multipoint-to- 255 Multipoint Label Switched Paths", draft-ietf-mpls-ldp-p2mp-00.txt, 256 Work in Progress, June 2006. 258 10. Author Information 260 Bob Thomas 261 Cisco Systems, Inc. 262 1414 Massachusetts Ave. 263 Boxborough MA 01719 264 Email: rhthomas@cisco.com 266 Ina Minei 267 Juniper Networks 268 1194 North Mathilda Ave. 269 Sunnyvale, CA 94089 270 Email: ina@juniper.net 272 11. Intellectual Property Statement 274 The IETF takes no position regarding the validity or scope of any 275 Intellectual Property Rights or other rights that might be claimed to 276 pertain to the implementation or use of the technology described in 277 this document or the extent to which any license under such rights 278 might or might not be available; nor does it represent that it has 279 made any independent effort to identify any such rights. Information 280 on the procedures with respect to rights in RFC documents can be 281 found in BCP 78 and BCP 79. 283 Copies of IPR disclosures made to the IETF Secretariat and any 284 assurances of licenses to be made available, or the result of an 285 attempt made to obtain a general license or permission for the use of 286 such proprietary rights by implementers or users of this 287 specification can be obtained from the IETF on-line IPR repository at 288 http://www.ietf.org/ipr. 290 The IETF invites any interested party to bring to its attention any 291 copyrights, patents or patent applications, or other proprietary 292 rights that may cover technology that may be required to implement 293 this standard. Please address the information to the IETF at ietf- 294 ipr@ietf.org. 296 12. Full Copyright Statement 298 Copyright (C) The Internet Society (2006). This document is subject 299 to the rights, licenses and restrictions contained in BCP 78, and 300 except as set forth therein, the authors retain all their rights. 302 Additional copyright notices are not permitted in IETF Documents 303 except in the case where such document is the product of a joint 304 development effort between the IETF and another standards development 305 organization or the document is a republication of the work of 306 another standards organization. Such exceptions must be approved on 307 an individual basis by the IAB. 309 This document and the information contained herein are provided on an 310 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 311 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 312 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 313 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 314 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 315 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.