idnits 2.17.1 draft-ietf-mpls-ldp-typed-wildcard-01.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 18. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 324. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 294. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 301. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 307. 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 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 (May 2007) is 6163 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-02 Summary: 3 errors (**), 0 flaws (~~), 3 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Bob Thomas 2 Internet Draft Cisco Systems, Inc. 3 Expiration Date: November 2007 4 Ina Minei 5 Juniper Networks 7 May 2007 9 LDP Typed Wildcard FEC 11 draft-ietf-mpls-ldp-typed-wildcard-01.txt 13 Status of this Memo 15 By submitting this Internet-Draft, each author represents that any 16 applicable patent or other IPR claims of which he or she is aware 17 have been or will be disclosed, and any of which he or she becomes 18 aware will be disclosed, in accordance with Section 6 of 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 months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 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 Copyright Notice 38 Copyright (C) The IETF TRUST (2007). 40 Abstract 42 The LDP specification [RFC3036] for the Wildcard FEC element has 43 several deficiencies. This document corrects those deficiencies. In 44 addition, it specifies the Typed Wildcard FEC for the Prefix FEC 45 Element Type defined in RFC3036. 47 Table of Contents 49 1 Introduction .......................................... 2 50 2 Specification Language ................................ 3 51 3 The Typed Wildcard FEC Element ........................ 3 52 4 Procedures for the Typed Wildcard FEC Element ......... 4 53 5 Typed Wildcard FEC Element for RFC3036 Prefix FEC Element 5 54 6 RFC3036 Host and Wildcard FEC Elements ................ 5 55 7 IANA Considerations ................................... 5 56 8 Security Considerations ............................... 6 57 9 Acknowledgements ...................................... 6 58 10 References ............................................ 6 59 11 Author Information .................................... 7 60 12 Intellectual Property Statement ....................... 7 61 13 Full Copyright Statement .............................. 8 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. Note that this 91 document does not change procedures specified for the LDP Wildcard 92 FEC Element by RFC3036. 94 2. Specification Language 96 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 97 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 98 document are to be interpreted as described in [RFC2119]. 100 3. The Typed Wildcard FEC Element 102 The Typed Wildcard FEC Element refers to all FECs of a given type 103 relative to an optional constraint. The constraint, if present, is 104 determined from the context in which the Typed Wildcard FEC Element 105 appears. 107 The format of the Typed Wildcard FEC Element is: 109 0 1 2 110 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 111 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 112 | Typed (IANA) | FEC Element | Len FEC Type | | 113 | Wildcard | Type | Info | | 114 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 115 | | 116 | Additional FEC Type-specific Information | 117 | +-+-+-+-+-+-+-+-+ 118 | | 119 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 121 where: 123 Typed Wildcard: One octet FEC Element type to be assigned by IANA. 125 FEC Element Type: One octet FEC Element Type that specifies the 126 FEC Element Type to be wildcarded. 128 Len FEC Type Info: One octet that specifies the length of the FEC 129 Type Specific information field. MUST be 0 if there is no 130 Additional FEC Type-specific Information. 132 Additional FEC Type-specific Information: Additional information 133 specific to the FEC Element Type required to fully specify the 134 Typed Wildcard. 136 Specification of the length and format of Additional FEC Type 137 Specific Information for particular FEC Element Types is outside of 138 the scope of this document. 140 4. Procedures for the Typed Wildcard FEC Element 142 It is the responsibility of the designer of the FEC Element Type to 143 specify whether typed wildcarding is required for the FEC Element 144 Type. When typed wildcarding is supported for a FEC Element Type it 145 is the responsibility of the designer to specify the length and 146 format of any Additional FEC Type Specific Information. 148 When a FEC TLV contains a Typed Wildcard FEC Element the Typed 149 Wildcard FEC Element MUST be the only FEC Element in the TLV. 151 An LDP implementation that supports the Typed Wildcard FEC Element 152 MUST support its use in Label Request, Label Withdraw and Label 153 Release messages. 155 Receipt of a Label Request message with a FEC TLV containing a Typed 156 Wildcard FEC Element is interpreted as a request to send a Label 157 Mapping for all FECs of the type specified by the FEC Element type 158 field in the Typed Wildcard FEC Element encoding. 160 An LDP implementation that supports the Typed Wildcard FEC Element 161 MUST support the following constraints whenever a Typed Wildcard FEC 162 appears in a Label Withdraw or Label Release message: 164 1. If the message carries an optional Label TLV the Typed Wildcard 165 FEC Element refers to all FECs of the specified FEC type bound to 166 the specified label. 168 2. If the message has no Label TLV the Typed Wildcard FEC Element 169 refers to all FECs of the specified FEC type. 171 Backwards compatibility with a router not supporting the Typed 172 Wildcard FEC element is ensured by the FEC procedures defined in 173 RFC3036. Quoting from RFC3036: 175 "If it" [an LSR] "encounters a FEC Element type it cannot decode, 176 it SHOULD stop decoding the FEC TLV, abort processing the 177 message containing the TLV, and send an "Unknown FEC" 178 Notification message to its LDP peer signaling an error." 180 A router receiving a FEC TLV containing a Typed Wildcard FEC element 181 for a FEC Element Type that it either doesn't support or for a FEC 182 Element Type that doesn't support the use of wildcarding MUST stop 183 decoding the FEC TLV, abort processing the message containing the 184 TLV, and send an "Unknown FEC" Notification message to its LDP peer 185 signaling an error. 187 5. Typed Wildcard FEC Element for RFC3036 Prefix FEC Element 189 RFC3036 defines the Prefix FEC Element but it does not specify a 190 Typed Wildcard for it. This section specifies the Typed Wildcard FEC 191 Element for RFC3036 Prefix Elements. 193 The format of the Prefix FEC Typed Wildcard FEC ("Prefix FEC 194 Wildcard" for short) is: 195 0 1 2 3 196 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 197 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 198 | Typed WCard | Prefix (2) | 2 | Address... | 199 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 200 | ...Family | 201 +-+-+-+-+-+-+-+-+ 203 Address Family: Two octet quantity containing a value from ADDRESS 204 FAMILY NUMBERS in [IANA-AF]. 206 The procedures of Section 4 apply to the Prefix FEC Wildcard. 208 6. RFC3036 Host and Wildcard FEC Elements 210 There is no need to specify Typed Wildcard FEC Elements for the Host 211 and Wildcard FEC Elements specified by RFC3036. The RFC3036 Host FEC 212 Element has been removed from rfc3036bis [RFC3036bis], and the 213 Wildcard FEC Element is untyped by definition. 215 7. IANA Considerations 217 The Typed Wildcard FEC Element requires a code point from the LDP FEC 218 Type Name Space. IANA manages the FEC TYPE name space as recommended 219 by the following from [RFC3036]: 221 "FEC Type Name Space 223 The range for FEC types is 0 - 255. 225 Following the policies outlined in [RFC3036], FEC types in the 226 range 0 - 127 are allocated through an IETF Consensus action, 227 types in the range 128 - 191 are allocated as First Come First 228 Served, and types in the range 192 - 255 are reserved for Private 229 Use." 231 The authors recommend that the code point 0x05 from the IETF 232 Consensus range be assigned to the Typed Wildcard FEC Element. 234 8. Security Considerations 236 No security considerations beyond those that apply to the base LDP 237 specification and described in [RFC3036] apply to use of the Typed 238 Wildcard FEC Element defined in this document. 240 9. Acknowledgements 242 The authors wish to thank Yakov Rehkter for suggesting that the 243 deficiencies of the Wildcard FEC be addressed. 245 10. References 247 Normative References 249 [RFC3036] Andersson, L., Doolan, P., Feldman, N., Fredette, A. and 250 Thomas, B., "LDP Specification", RFC 3036, January 2001. 252 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 253 Requirement Levels", BCP 14, RFC2119, March 1997. 255 [IANA-AF] http://www.iana.org/assignments/address-family-numbers 257 Informative References 259 [PWE3] Martini, L., Editor, "Pseudowire Setup and Maintenance Using 260 the Label Distribution Protocol (LDP)", RFC 4447, April 2006. 262 [MLDP] Minei, I., Wijnamds, I., Editors, "Label Distribution 263 Protocol Extensions for Point-to-Multipoint and Multipoint-to- 264 Multipoint Label Switched Paths", draft-ietf-mpls-ldp-p2mp-02.txt, 265 Work in Progress, October 2006. 267 [RFC3036bis] Andersson, L., Minei, I., Thomas, B., Editors, "LDP 268 Specification", draft-ietf-mpls-rfc3036bis-04.txt, Work in 269 Progress, September 2006. 271 11. Author Information 273 Bob Thomas 274 Cisco Systems, Inc. 275 1414 Massachusetts Ave. 276 Boxborough MA 01719 277 Email: rhthomas@cisco.com 279 Ina Minei 280 Juniper Networks 281 1194 North Mathilda Ave. 282 Sunnyvale, CA 94089 283 Email: ina@juniper.net 285 12. Intellectual Property Statement 287 The IETF takes no position regarding the validity or scope of any 288 Intellectual Property Rights or other rights that might be claimed to 289 pertain to the implementation or use of the technology described in 290 this document or the extent to which any license under such rights 291 might or might not be available; nor does it represent that it has 292 made any independent effort to identify any such rights. Information 293 on the procedures with respect to rights in RFC documents can be 294 found in BCP 78 and BCP 79. 296 Copies of IPR disclosures made to the IETF Secretariat and any 297 assurances of licenses to be made available, or the result of an 298 attempt made to obtain a general license or permission for the use of 299 such proprietary rights by implementers or users of this 300 specification can be obtained from the IETF on-line IPR repository at 301 http://www.ietf.org/ipr. 303 The IETF invites any interested party to bring to its attention any 304 copyrights, patents or patent applications, or other proprietary 305 rights that may cover technology that may be required to implement 306 this standard. Please address the information to the IETF at ietf- 307 ipr@ietf.org. 309 13. Full Copyright Statement 311 Copyright (C) The IETF Trust (2007). 313 This document is subject to the rights, licenses and restrictions 314 contained in BCP 78, and except as set forth therein, the authors 315 retain all their rights. 317 This document and the information contained herein are provided on an 318 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 319 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST 320 AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, 321 EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT 322 THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY 323 IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR 324 PURPOSE.