idnits 2.17.1 draft-vasseur-mpls-nb-te-lsp-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 261. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 234. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 243. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 249. ** 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 == The page length should not exceed 58 lines per page, but there was 3 longer pages, the longest (page 2) being 69 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 7 pages 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 6658 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 (~~), 4 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-nb-te-lsp-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 22 months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on August 5, 2006. 35 Copyright Notice 37 Copyright (C) The Internet Society (2006). 39 Abstract 41 Several Link-type sub-TLVs have been defined for OSPF and ISIS in 42 the 43 context of MPLS Traffic Engineering in order to convery some link 44 characteristics such as the available bandwidth, traffic enginering 45 metric, adminstrative group and so on. There are various 46 circumstances where it would be useful to also know the number of 47 unconstrained Traffic Engineering Label Switched Path(s) (TE LSP). 48 This document specifies a new Link-type Traffic Engineering sub-TLV 49 used to advertise the number of unconstrained TE LSP(s) signalled 50 across a specific link. 52 Requirements Language 54 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 55 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 56 document are to be interpreted as described in RFC 2119 [RFC2119]. 58 Table of Contents 60 1. 61 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 2. 63 Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3 64 3. Protocol 65 extensions . . . . . . . . . . . . . . . . . . . . . . 4 66 3.1. 67 ISIS . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 68 3.2. 69 OSPF . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 70 4. Elements of 71 procedure . . . . . . . . . . . . . . . . . . . . . 4 72 5. IANA 73 Considerations . . . . . . . . . . . . . . . . . . . . . . 4 74 6. Security 75 Considerations . . . . . . . . . . . . . . . . . . . . 5 76 7. 77 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 5 78 8. 79 References . . . . . . . . . . . . . . . . . . . . . . . . . . 5 80 8.1. Normative 81 References . . . . . . . . . . . . . . . . . . . 5 82 8.2. Informative 83 References . . . . . . . . . . . . . . . . . . 5 84 Author's 85 Address . . . . . . . . . . . . . . . . . . . . . . . . . 6 86 Intellectual Property and Copyright 87 Statements . . . . . . . . . . 7 88 1. Introduction 90 Several Link-type sub-TLVs have been defined for OSPF and ISIS (see 91 [ISIS-TE] and [OSPF-TE]) in the context of MPLS Traffic Engineering 92 in order to advertise various link characteristics such as the 93 available bandwidth, traffic enginering metric, adminstrative group 94 and so on. There are various circumstances where it would be useful 95 to also know the number of unconstrained Traffic Engineering Label 96 Switch Path(s) (TE LSP). 98 It is not uncommon to deploy MPLS Traffic Engineering for the 99 sake of 100 fast recovery with MPLS TE Fast Reroute (see [FAST-REROUTE]). In 101 this case, a common deployment model consists of deploying a full 102 mesh of unconstrained TE LSPs between a set of LSRs and protect 103 these 104 TE LSPs thanks to pre-established backup tunnels against link, SRLG 105 and/or node failures. 107 When a set of unconstrained TE LSPs is deployed, various algorithms 108 can be designed so as efficiently load balance the traffic 109 carried by 110 such unconstrained TE LSPs provided that the number of unconstrained 111 TE LSPs traversing each link in the network is known. As currently 112 defined in [OSPF-TE] and [ISIS-TE] the information related to the 113 number of unconstrained TE LSP(s) is not available. Note that the 114 specification of load balancing algorithms is outside of the 115 scope of 116 this document and merely listed for the sake of illustration of the 117 motivation for gathering such information. Furthermore, the 118 knowledge of the number of unconstrained TE LSPs signalled across 119 each link can be used for other purposes (e.g. management, ...). 121 This document specifies a new Link-type Traffic Engineering sub-TLV 122 used to indicate the number of unconstrained TE LSP signalled across 123 a specific link. 125 2. Terminology 127 Terminology used in this document LSR: Label Switch Router. 129 TE LSP: MPLS Traffic Engineering Label Switched Path. 131 Backup tunnel: the TE LSP that is used to backup up one of the many 132 TE LSPs in many-to-one backup (as defined in [FAST-REROUTE]). 134 Unconstrained TE LSP: A TE LSP signalled with a bandwidth 135 requirement 136 equal to 0. 138 3. Protocol extensions 140 A new Sub-TLV named NB-O-BW-LSP is defined that specifies the number 141 of unconstrained TE LSPs signalled across a link. 143 3.1. ISIS 145 The NB-0-BW-LSP TLV is OPTIONAL and MUST appear at most once within 146 the extended IS reachability TLV (type 22) specified in [ISIS-TE]. 147 The NB-0-BW-LSP consists of: 149 Type (1 octet): To be assigned by IANA (Recommended value = 19) 151 Length (1 octet): 4 153 Value (4 octets): field value that comprises the number of 154 unconstrained TE LSP(s) signalled across the link. 156 3.2. OSPF 158 The NB-0-BW-LSP is OPTIONAL and MUST appear at most once within the 159 Link TLV (Type 2) that is itself carried within the Traffic 160 Engineering LSA specified in [OSPF-TE]. The NB-0-BW-LSP consists 161 of: 163 Type (2 octets): To be assigned by IANA (Recommended value = 19) 165 Length (2 octets): 4 167 Value (4 octets): field value that comprises the number of 168 unconstrained TE LSP(s) signalled across the link. 170 4. Elements of procedure 172 An implementation may decide to implement a dual-thresholds 173 mechanism 174 so as to trigger the origination of an updated OSPF LSA or ISIS LSP. 175 Similalry to other MPLS Traffic Engineering link characteristics, 176 LSA/LSP origination trigger mechanisms are outside of the scope of 177 this document. 179 5. IANA Considerations 181 IANA will assign a new code point for the newly defined ISIS sub-TLV 182 (NB-0-BW-LSP) carried within the TLV 22 (suggested value =19) 184 IANA will assign a new code point for the newly defined OSPF sub-TLV 185 (NB-0-BW-LSP) carried within the Link TLV (Type 2) of the Traffic 186 Engineering LSA (suggested value=19). 188 6. Security Considerations 190 This document raises no new security issues for IS-IS and OSPF. 192 7. Acknowledgements 194 8. References 196 8.1. Normative References 198 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 199 Requirement Levels", BCP 14, RFC 2119, March 1997. 201 8.2. Informative References 203 [FAST-REROUTE] 204 P. Pan, G. Swallow, A. Atlas et al., RFC 4090, "Fast 205 Reroute Extensions to RSVP-TE for LSP Tunnels", May 2005. 207 [ISIS-TE] T. Li, H. Smit, draft-ietf-isis-te-bis-00.txt, "IS-IS 208 extensions for Traffic Engineering", August 2005. 210 [OSPF-TE] Katz, et al., RFC 3630, "Traffic Engineering (TE) 211 Extensions to OSPF Version 2", September 2003. 213 Author's Address 215 JP Vasseur 216 Cisco Systems, Inc 217 1414 Massachusetts Avenue 218 Boxborough, MA 01719 219 USA 221 Email: jpv@cisco.com 223 Intellectual Property Statement 225 The IETF takes no position regarding the validity or scope of any 226 Intellectual Property Rights or other rights that might be 227 claimed to 228 pertain to the implementation or use of the technology described in 229 this document or the extent to which any license under such rights 230 might or might not be available; nor does it represent that it has 231 made any independent effort to identify any such rights. 232 Information 233 on the procedures with respect to rights in RFC documents can be 234 found in BCP 78 and BCP 79. 236 Copies of IPR disclosures made to the IETF Secretariat and any 237 assurances of licenses to be made available, or the result of an 238 attempt made to obtain a general license or permission for the 239 use of 240 such proprietary rights by implementers or users of this 241 specification can be obtained from the IETF on-line IPR 242 repository at 243 http://www.ietf.org/ipr. 245 The IETF invites any interested party to bring to its attention any 246 copyrights, patents or patent applications, or other proprietary 247 rights that may cover technology that may be required to implement 248 this standard. Please address the information to the IETF at 249 ietf-ipr@ietf.org. 251 Disclaimer of Validity 253 This document and the information contained herein are provided 254 on an 255 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 256 REPRESENTS 257 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 258 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 259 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 260 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 261 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 263 Copyright Statement 265 Copyright (C) The Internet Society (2006). This document is subject 266 to the rights, licenses and restrictions contained in BCP 78, and 267 except as set forth therein, the authors retain all their rights. 269 Acknowledgment 271 Funding for the RFC Editor function is currently provided by the 272 Internet Society.