idnits 2.17.1 draft-vasseur-mpls-number-0-bw-te-lsps-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 14. -- Found old boilerplate from RFC 3978, Section 5.5 on line 233. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 210. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 217. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 223. ** 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 : ---------------------------------------------------------------------------- No issues found here. 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 (February 1, 2006) is 6651 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) No issues found here. Summary: 3 errors (**), 0 flaws (~~), 2 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Networking Working Group JP. Vasseur 2 Internet-Draft Cisco Systems, Inc 3 Expires: August 5, 2006 February 1, 2006 5 A Link-Type sub-TLV to convey the number of unconstrained Traffic 6 Engineering Label Switch Paths signalled across a link 7 draft-vasseur-mpls-number-0-bw-te-lsps-00 9 Status of this Memo 11 By submitting this Internet-Draft, each author represents that any 12 applicable patent or other IPR claims of which he or she is aware 13 have been or will be disclosed, and any of which he or she becomes 14 aware will be disclosed, in accordance with Section 6 of BCP 79. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 This Internet-Draft will expire on August 5, 2006. 34 Copyright Notice 36 Copyright (C) The Internet Society (2006). 38 Abstract 40 Several Link-type sub-TLVs have been defined for OSPF and ISIS in the 41 context of MPLS Traffic Engineering in order to convery some link 42 characteristics such as the available bandwidth, traffic enginering 43 metric, adminstrative group and so on. There are various 44 circumstances where it would be useful to also know the number of 45 unconstrained Traffic Engineering Label Switched Path(s) (TE LSP). 46 This document specifies a new Link-type Traffic Engineering sub-TLV 47 used to advertise the number of unconstrained TE LSP(s) signalled 48 across a specific link. 50 Requirements Language 52 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 53 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 54 document are to be interpreted as described in RFC 2119 [RFC2119]. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 3. Protocol extensions . . . . . . . . . . . . . . . . . . . . . . 4 61 3.1. ISIS . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 62 3.2. OSPF . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 63 4. Elements of procedure . . . . . . . . . . . . . . . . . . . . . 4 64 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 4 65 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 5 66 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 5 67 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 5 68 8.1. Normative References . . . . . . . . . . . . . . . . . . . 5 69 8.2. Informative References . . . . . . . . . . . . . . . . . . 5 70 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 6 71 Intellectual Property and Copyright Statements . . . . . . . . . . 7 73 1. Introduction 75 Several Link-type sub-TLVs have been defined for OSPF and ISIS (see 76 [ISIS-TE] and [OSPF-TE]) in the context of MPLS Traffic Engineering 77 in order to advertise various link characteristics such as the 78 available bandwidth, traffic enginering metric, adminstrative group 79 and so on. There are various circumstances where it would be useful 80 to also know the number of unconstrained Traffic Engineering Label 81 Switch Path(s) (TE LSP). 83 It is not uncommon to deploy MPLS Traffic Engineering for the sake of 84 fast recovery with MPLS TE Fast Reroute (see [FAST-REROUTE]). In 85 this case, a common deployment model consists of deploying a full 86 mesh of unconstrained TE LSPs between a set of LSRs and protect these 87 TE LSPs thanks to pre-established backup tunnels against link, SRLG 88 and/or node failures. 90 When a set of unconstrained TE LSPs is deployed, various algorithms 91 can be designed so as efficiently load balance the traffic carried by 92 such unconstrained TE LSPs provided that the number of unconstrained 93 TE LSPs traversing each link in the network is known. As currently 94 defined in [OSPF-TE] and [ISIS-TE] the information related to the 95 number of unconstrained TE LSP(s) is not available. Note that the 96 specification of load balancing algorithms is outside of the scope of 97 this document and merely listed for the sake of illustration of the 98 motivation for gathering such information. Furthermore, the 99 knowledge of the number of unconstrained TE LSPs signalled across 100 each link can be used for other purposes (e.g. management, ...). 102 This document specifies a new Link-type Traffic Engineering sub-TLV 103 used to indicate the number of unconstrained TE LSP signalled across 104 a specific link. 106 2. Terminology 108 Terminology used in this document LSR: Label Switch Router. 110 TE LSP: MPLS Traffic Engineering Label Switched Path. 112 Backup tunnel: the TE LSP that is used to backup up one of the many 113 TE LSPs in many-to-one backup (as defined in [FAST-REROUTE]). 115 Unconstrained TE LSP: A TE LSP signalled with a bandwidth requirement 116 equal to 0. 118 3. Protocol extensions 120 A new Sub-TLV named NB-O-BW-LSP is defined that specifies the number 121 of unconstrained TE LSPs signalled across a link. 123 3.1. ISIS 125 The NB-0-BW-LSP TLV is OPTIONAL and MUST appear at most once within 126 the extended IS reachability TLV (type 22) specified in [ISIS-TE]. 127 The NB-0-BW-LSP consists of: 129 Type (1 octet): To be assigned by IANA (Recommended value = 19) 131 Length (1 octet): 4 133 Value (4 octets): field value that comprises the number of 134 unconstrained TE LSP(s) signalled across the link. 136 3.2. OSPF 138 The NB-0-BW-LSP is OPTIONAL and MUST appear at most once within the 139 Link TLV (Type 2) that is itself carried within the Traffic 140 Engineering LSA specified in [OSPF-TE]. The NB-0-BW-LSP consists of: 142 Type (2 octets): To be assigned by IANA (Recommended value = 19) 144 Length (2 octets): 4 146 Value (4 octets): field value that comprises the number of 147 unconstrained TE LSP(s) signalled across the link. 149 4. Elements of procedure 151 An implementation may decide to implement a dual-thresholds mechanism 152 so as to trigger the origination of an updated OSPF LSA or ISIS LSP. 153 Similalry to other MPLS Traffic Engineering link characteristics, 154 LSA/LSP origination trigger mechanisms are outside of the scope of 155 this document. 157 5. IANA Considerations 159 IANA will assign a new code point for the newly defined ISIS sub-TLV 160 (NB-0-BW-LSP) carried within the TLV 22 (suggested value =19) 162 IANA will assign a new code point for the newly defined OSPF sub-TLV 163 (NB-0-BW-LSP) carried within the Link TLV (Type 2) of the Traffic 164 Engineering LSA (suggested value=19). 166 6. Security Considerations 168 This document raises no new security issues for IS-IS and OSPF. 170 7. Acknowledgements 172 8. References 174 8.1. Normative References 176 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 177 Requirement Levels", BCP 14, RFC 2119, March 1997. 179 8.2. Informative References 181 [FAST-REROUTE] 182 P. Pan, G. Swallow, A. Atlas et al., RFC 4090, "Fast 183 Reroute Extensions to RSVP-TE for LSP Tunnels", May 2005. 185 [ISIS-TE] T. Li, H. Smit, draft-ietf-isis-te-bis-00.txt, "IS-IS 186 extensions for Traffic Engineering", August 2005. 188 [OSPF-TE] Katz, et al., RFC 3630, "Traffic Engineering (TE) 189 Extensions to OSPF Version 2", September 2003. 191 Author's Address 193 JP Vasseur 194 Cisco Systems, Inc 195 1414 Massachusetts Avenue 196 Boxborough, MA 01719 197 USA 199 Email: jpv@cisco.com 201 Intellectual Property Statement 203 The IETF takes no position regarding the validity or scope of any 204 Intellectual Property Rights or other rights that might be claimed to 205 pertain to the implementation or use of the technology described in 206 this document or the extent to which any license under such rights 207 might or might not be available; nor does it represent that it has 208 made any independent effort to identify any such rights. Information 209 on the procedures with respect to rights in RFC documents can be 210 found in BCP 78 and BCP 79. 212 Copies of IPR disclosures made to the IETF Secretariat and any 213 assurances of licenses to be made available, or the result of an 214 attempt made to obtain a general license or permission for the use of 215 such proprietary rights by implementers or users of this 216 specification can be obtained from the IETF on-line IPR repository at 217 http://www.ietf.org/ipr. 219 The IETF invites any interested party to bring to its attention any 220 copyrights, patents or patent applications, or other proprietary 221 rights that may cover technology that may be required to implement 222 this standard. Please address the information to the IETF at 223 ietf-ipr@ietf.org. 225 Disclaimer of Validity 227 This document and the information contained herein are provided on an 228 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 229 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 230 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 231 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 232 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 233 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 235 Copyright Statement 237 Copyright (C) The Internet Society (2006). This document is subject 238 to the rights, licenses and restrictions contained in BCP 78, and 239 except as set forth therein, the authors retain all their rights. 241 Acknowledgment 243 Funding for the RFC Editor function is currently provided by the 244 Internet Society.