idnits 2.17.1 draft-ietf-mpls-number-0-bw-te-lsps-04.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 21. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 312. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 323. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 330. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 336. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There is 1 instance of too long lines in the document, the longest one being 4 characters in excess of 72. 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 (December 8, 2006) is 6350 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) == Unused Reference: 'OSPFv3-TE' is defined on line 262, but no explicit reference was found in the text ** Obsolete normative reference: RFC 1194 (Obsoleted by RFC 1196, RFC 1288) ** Obsolete normative reference: RFC 3784 (Obsoleted by RFC 5305) Summary: 4 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, Ed. 2 Internet-Draft Cisco Systems, Inc 3 Intended status: Standards Track Matthew. R. Meyer 4 Expires: June 11, 2007 Global Crossing 5 K. Kumaki 6 KDDI Corporation 7 Alberto. Tempia Bonda 8 Telecom Italia 9 December 8, 2006 11 A Link-Type sub-TLV to convey the number of Traffic Engineering Label 12 Switch Paths signalled signalled with zero reserved bandwidth across a 13 link 14 draft-ietf-mpls-number-0-bw-te-lsps-04 16 Status of this Memo 18 By submitting this Internet-Draft, each author represents that any 19 applicable patent or other IPR claims of which he or she is aware 20 have been or will be disclosed, and any of which he or she becomes 21 aware will be disclosed, in accordance with Section 6 of BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF), its areas, and its working groups. Note that 25 other groups may also distribute working documents as Internet- 26 Drafts. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 The list of current Internet-Drafts can be accessed at 34 http://www.ietf.org/ietf/1id-abstracts.txt. 36 The list of Internet-Draft Shadow Directories can be accessed at 37 http://www.ietf.org/shadow.html. 39 This Internet-Draft will expire on June 11, 2007. 41 Copyright Notice 43 Copyright (C) The IETF Trust (2006). 45 Abstract 47 Several Link-type sub-TLVs have been defined for OSPF and ISIS in the 48 context of Multiprotocol Label Switching (MPLS) Traffic Engineering 49 (TE) in order to advertise some link characteristics such as the 50 available bandwidth, traffic engineering metric, administrative group 51 and so on. By making statistical assumption on the aggregated 52 traffic carried onto a set of TE Label Switched Paths (LSPs) 53 signalled with zero bandwdith (referred to as unconstrained TE LSP in 54 this document), and with the knowledge of the number of unconstrained 55 TE LSPs signalled across a link, algorithms can be designed to load 56 balance (existing or newly configured) unconstrained TE LSP across a 57 set of equal cost paths. This requires the knowledge of the number 58 of unconstrained TE LSPs signalled across a link. This document 59 specifies a new Link-type Traffic Engineering sub-TLV used to 60 advertise the number of unconstrained TE LSP(s) signalled across a 61 link. 63 Requirements Language 65 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 66 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 67 document are to be interpreted as described in RFC 2119 [RFC2119]. 69 Table of Contents 71 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 4 72 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 73 3. Protocol extensions . . . . . . . . . . . . . . . . . . . . . . 5 74 3.1. IS-IS . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 75 3.2. OSPF . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 76 4. Elements of procedure . . . . . . . . . . . . . . . . . . . . . 6 77 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 78 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 79 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7 80 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 81 8.1. Normative References . . . . . . . . . . . . . . . . . . . 7 82 8.2. Informative References . . . . . . . . . . . . . . . . . . 7 83 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7 84 Intellectual Property and Copyright Statements . . . . . . . . . . 9 86 1. Terminology 88 Terminology used in this document 90 CSPF: Constraint Shortest Path First 92 MPLS: Multiprotocol Label Switching 94 LSA: Link State Advertisement. 96 LSP: Link State Packet. 98 LSR: Label Switching Router. 100 TE LSP: Traffic Engineering Label Switched Path. 102 Unconstrained TE LSP: A TE LSP signalled with a bandwidth equal to 0. 104 2. Introduction 106 It is not uncommon to deploy MPLS TE for the sake of fast recovery 107 relying on a local protection recovery mechanism such as MPLS TE Fast 108 Reroute (see [RFC4090]). In this case, a deployment model consists 109 of deploying a full mesh of unconstrained TE LSPs (TE LSP signalled 110 with zero bandwidth) between a set of LSRs and protecting these TE 111 LSPs against link, SRLG and/or node failures with pre-established 112 backup tunnels. The traffic routed onto such unconstrained TE LSP 113 simply follows the IGP shortest path (since the TE LSP computed by 114 the path computation algorithm (e.g. CSPF) will be no different than 115 the IGP shortest path should the TE metric be equal to the IGP 116 metric) but is protected with MPLS TE Fast Reroute. 118 When a reoptimization process is triggered for an existing TE LSP, 119 the decision on whether to reroute that TE LSP onto a different path 120 is governed by the discovery of a lower cost path satisfying the 121 constraints (other metric such that the percentage of reserved 122 bandwidth or the number of hops can also be used). Unfortunately, 123 for instance in the presence of ECMPs (Equal Cost Multi-Paths) in 124 symmetrical networks when unconstrained TE LSPs are used, such 125 metrics are usually ineffective and may lead to poorly load balanced 126 traffic. 128 By making statistical assumption on the aggregated traffic carried 129 onto a set of TE LSPs signalled with no bandwidth requirement 130 (referred to as unconstrained TE LSP in this document), algorithms 131 can be designed to load balance (existing or newly configured) 132 unconstrained TE Label Switched Path (LSP) across a set of equal cost 133 paths. This requires the knowledge of the number of unconstrained 134 Traffic Engineering Label Switched Path(s) (TE LSP) signalled across 135 a link. 137 A set of Link-type sub-TLVs have been defined for OSPF and IS-IS (see 138 [RFC3630] and [RFC3784]) in the context of MPLS Traffic Engineering 139 in order to advertise various link characteristics such as the 140 available bandwidth, traffic engineering metric, administrative group 141 and so on. As currently defined in [RFC3630] and [RFC3784] the 142 information related to the number of unconstrained TE LSP(s) is not 143 available. This document specifies a new Link-type Traffic 144 Engineering sub-TLV used to indicate the number of unconstrained TE 145 LSPs signalled across a link. 147 Note that the specification of load balancing algorithms is outside 148 of the scope of this document and merely listed for the sake of 149 illustration of the motivation for gathering such information. 151 TE LSPs signalled with zero bandwidth that are configured and 152 provisioned through a management system are not included in the count 153 that is reported. 155 Furthermore, the knowledge of the number of unconstrained TE LSPs 156 signalled across each link can be used for other purposes (for 157 example to evaluate the number of affected TE LSPs in case of a link 158 failure). 160 3. Protocol extensions 162 The Number of 0-bandwidth TE LSP(s) Sub-TLV is defined that specifies 163 the number of TE LSPs signalled with zero bandwidth across a link. 165 3.1. IS-IS 167 The Number of 0-bandwidth TE LSP(s) sub-TLV is OPTIONAL and MUST 168 appear at most once within the extended IS reachability TLV (type 22) 169 specified in [RFC3784]. 171 The IS-IS Number of 0-bandwidth TE LSP(s) sub-TLV format is defined 172 below: 174 Type (1 octet): To be assigned by IANA (suggested value = 18) 176 Length (1 octet): 2 178 Value (2 octets): number of unconstrained TE LSP(s) signalled across 179 the link. 181 3.2. OSPF 183 The Number of 0-bandwidth TE LSP(s) sub-TLV is OPTIONAL and MUST 184 appear at most once within the Link TLV (Type 2) that is itself 185 carried within the Traffic Engineering LSA specified in [RFC3630] or 186 the OSPFv3 Intra-Area-TE LSA (function code 10) defined in 187 draft-ietf-ospf-ospfv3-traffic-07.txt. If a second instance of the 188 Number of 0-bandwidth TE LSP(s) sub-TLV is present, the receiving 189 system MUST only process the first instance of the sub-TLV. 191 The OSPF Number of 0-bandwidth TE LSP(s) sub-TLV format is defined 192 below: 194 Type (2 octets): To be assigned by IANA (suggested value = 18) 196 Length (2 octets): 4 198 Value (4 octets): number of unconstrained TE LSP(s) signalled across 199 the link. 201 4. Elements of procedure 203 An implementation MAY decide to implement a dual-thresholds mechanism 204 based on the number of unconstrained TE LSPs to govern the 205 origination of updated OSPF LSA or ISIS LSP. Similarly to other MPLS 206 Traffic Engineering link characteristics, LSA/LSP origination trigger 207 mechanisms are outside of the scope of this document. 209 5. IANA Considerations 211 IANA will assign a new code point for the newly defined IS-IS Number 212 of 0-bandwidth TE LSP(s) sub-TLV carried within the TLV 22 (suggested 213 value =18). 215 IANA will assign a new code point for the newly defined OSPF Number 216 of 0-bandwidth TE LSP(s) sub-TLV carried within the Link TLV (Type 2) 217 of the Traffic Engineering LSA (suggested value=18). 219 6. Security Considerations 221 The function described in this document does not create any new 222 security issues for the OSPF and the IS-IS protocols. Security 223 considerations are covered in [RFC2328] and [RFC2470] for the base 224 OSPF protocol and in [RFC1194] for IS-IS. 226 7. Acknowledgements 228 The authors would like to thank Jean-Louis Le Roux, Adrian Farrel, 229 Daniel King, Acee Lindem, Loa Anderson and Les Ginsberg for 230 their useful inputs. 232 8. References 234 8.1. Normative References 236 [RFC1194] Zimmerman, D., "Finger User Information Protocol", 237 RFC 1194, November 1990. 239 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 240 Requirement Levels", BCP 14, RFC 2119, March 1997. 242 [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998. 244 [RFC2470] Crawford, M., Narten, T., and S. Thomas, "Transmission of 245 IPv6 Packets over Token Ring Networks", RFC 2470, 246 December 1998. 248 [RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering 249 (TE) Extensions to OSPF Version 2", RFC 3630, 250 September 2003. 252 [RFC3784] Smit, H. and T. Li, "Intermediate System to Intermediate 253 System (IS-IS) Extensions for Traffic Engineering (TE)", 254 RFC 3784, June 2004. 256 8.2. Informative References 258 [RFC4090] Pan, P., Swallow, G., and A. Atlas, "Fast Reroute 259 Extensions to RSVP-TE for LSP Tunnels", RFC 4090, 260 May 2005. 262 [OSPFv3-TE] Lindem, A. et al., "Traffic Engineering Extensions to OSPF 263 version 3", draft-ietf-ospf-ospfv3-traffic, work in progress. 265 Authors' Addresses 267 JP Vasseur (editor) 268 Cisco Systems, Inc 269 1414 Massachusetts Avenue 270 Boxborough, MA 01719 271 USA 273 Email: jpv@cisco.com 274 Matthew R. Meyer 275 Global Crossing 276 3133 Indian Valley Tr. 277 Howell, MI 48855 278 USA 280 Email: mrm@gblx.net 282 Kenji Kumaki 283 KDDI Corporation 284 Garden Air Tower Iidabashi, Chiyoda-ku, 285 Tokyo, 102-8460 286 JAPAN 288 Email: ke-kumaki@kddi.com 290 Alberto Tempia Bonda 291 Telecom Italia 292 via G. Reiss Romoli 274 293 Torino, 10148 294 ITALIA 296 Email: alberto.tempiabonda@telecomitalia.it 298 Full Copyright Statement 300 Copyright (C) The IETF Trust (2006). 302 This document is subject to the rights, licenses and restrictions 303 contained in BCP 78, and except as set forth therein, the authors 304 retain all their rights. 306 This document and the information contained herein are provided on an 307 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 308 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 309 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 310 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 311 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 312 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 314 Intellectual Property 316 The IETF takes no position regarding the validity or scope of any 317 Intellectual Property Rights or other rights that might be claimed to 318 pertain to the implementation or use of the technology described in 319 this document or the extent to which any license under such rights 320 might or might not be available; nor does it represent that it has 321 made any independent effort to identify any such rights. Information 322 on the procedures with respect to rights in RFC documents can be 323 found in BCP 78 and BCP 79. 325 Copies of IPR disclosures made to the IETF Secretariat and any 326 assurances of licenses to be made available, or the result of an 327 attempt made to obtain a general license or permission for the use of 328 such proprietary rights by implementers or users of this 329 specification can be obtained from the IETF on-line IPR repository at 330 http://www.ietf.org/ipr. 332 The IETF invites any interested party to bring to its attention any 333 copyrights, patents or patent applications, or other proprietary 334 rights that may cover technology that may be required to implement 335 this standard. Please address the information to the IETF at 336 ietf-ipr@ietf.org. 338 Acknowledgment 340 Funding for the RFC Editor function is provided by the IETF 341 Administrative Support Activity (IASA).