idnits 2.17.1 draft-ietf-mpls-number-0-bw-te-lsps-12.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 20. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 354. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 365. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 372. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 378. 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 : ---------------------------------------------------------------------------- No issues found here. 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 (September 1, 2008) is 5687 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) == Outdated reference: A later version (-09) exists of draft-ietf-mpls-mpls-and-gmpls-security-framework-03 Summary: 1 error (**), 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: March 5, 2009 Global Crossing 5 K. Kumaki 6 KDDI Corporation 7 Alberto. Tempia Bonda 8 Telecom Italia 9 September 1, 2008 11 A Link-Type sub-TLV to convey the number of Traffic Engineering Label 12 Switched Paths signalled with zero reserved bandwidth across a link 13 draft-ietf-mpls-number-0-bw-te-lsps-12 15 Status of this Memo 17 By submitting this Internet-Draft, each author represents that any 18 applicable patent or other IPR claims of which he or she is aware 19 have been or will be disclosed, and any of which he or she becomes 20 aware will be disclosed, in accordance with Section 6 of BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF), its areas, and its working groups. Note that 24 other groups may also distribute working documents as Internet- 25 Drafts. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 The list of current Internet-Drafts can be accessed at 33 http://www.ietf.org/ietf/1id-abstracts.txt. 35 The list of Internet-Draft Shadow Directories can be accessed at 36 http://www.ietf.org/shadow.html. 38 This Internet-Draft will expire on March 5, 2009. 40 Abstract 42 Several Link-type sub-Type-Lenght-Values (sub-TLVs) have been defined 43 for Open Shortest Path First (OSPF) and Intermediate System to 44 Intermediate System (IS-IS) in the context of Multiprotocol Label 45 Switching (MPLS) Traffic Engineering (TE) in order to advertise some 46 link characteristics such as the available bandwidth, traffic 47 engineering metric, administrative group and so on. By making 48 statistical assumptions about the aggregated traffic carried onto a 49 set of TE Label Switched Paths (LSPs) signalled with zero bandwith 50 (referred to as unconstrained TE LSP in this document), and with the 51 knowledge of the number of unconstrained TE LSPs signalled across a 52 link, algorithms can be designed to load balance (existing or newly 53 configured) unconstrained TE LSP across a set of equal cost paths. 54 This requires knowledge of the number of unconstrained TE LSPs 55 signalled across a link. This document specifies a new Link-type 56 Traffic Engineering sub-TLV used to advertise the number of 57 unconstrained TE LSP(s) signalled across a link. 59 Requirements Language 61 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 62 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 63 document are to be interpreted as described in RFC 2119 [RFC2119]. 65 Table of Contents 67 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 68 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 69 3. Protocol extensions . . . . . . . . . . . . . . . . . . . . . 5 70 3.1. IS-IS . . . . . . . . . . . . . . . . . . . . . . . . . . 5 71 3.2. OSPF . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 72 4. Elements of procedure . . . . . . . . . . . . . . . . . . . . 6 73 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 74 6. Security Considerations . . . . . . . . . . . . . . . . . . . 7 75 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7 76 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 77 8.1. Normative References . . . . . . . . . . . . . . . . . . . 7 78 8.2. Informative References . . . . . . . . . . . . . . . . . . 8 79 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 80 Intellectual Property and Copyright Statements . . . . . . . . . . 10 82 1. Terminology 84 Terminology used in this document 86 CSPF: Constrained Shortest Path First 88 IGP : Interior Gateway Protocol 90 LSA: Link State Advertisement 92 LSP: Link State Packet 94 MPLS: Multiprotocol Label Switching 96 LSR: Label Switching Router 98 SRLG: Shared Risk Link Group 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 Traffic Engineering for the sake of 107 fast recovery relying on a local protection recovery mechanism such 108 as MPLS TE Fast Reroute (see [RFC4090]). In this case, a deployment 109 model consists of deploying a full mesh of TE LSPs signalled with 110 zero bandwidth (also referred to as unconstrained TE LSP in this 111 document) between a set of LSRs (Label Switching Routers) and 112 protecting these TE LSPs against link, SRLG (Shared Risk Link Group) 113 and/or node failures with pre-established backup tunnels. The 114 traffic routed onto such unconstrained TE LSPs simply follows the IGP 115 shortest path (since the TE LSP computed by the path computation 116 algorithm (e.g. CSPF) will be no different than the IGP (Interior 117 Gateway Protocol) shortest path should the TE metric be equal to the 118 IGP metric) but is protected with MPLS TE Fast Reroute. 120 When a reoptimization process is triggered for an existing TE LSP, 121 the decision on whether to reroute that TE LSP onto a different path 122 is governed by the discovery of a lower cost path satisfying the 123 constraints (other metrics such that the percentage of reserved 124 bandwidth or the number of hops can also be used). Unfortunately, 125 metrics such as the path cost or the number of hops may be 126 ineffective in various circumstances: for example, in the case of a 127 symmetrical network with ECMPs (Equal Cost Multi-Paths), if the 128 network operator uses unconstrained TE LSP, this may lead to a poorly 129 load balanced traffic: indeed, several paths between a source and a 130 destination of a TE LSP may exist that have the same cost and the 131 reservable amount of bandwidth along each path cannot be used as a 132 tie-breaker. 134 By making statistical assumptions about the aggregated traffic 135 carried by a set of TE LSPs signalled with no bandwidth requirement 136 (referred to as unconstrained TE LSPs in this document), algorithms 137 can be designed to load balance (existing or newly configured) 138 unconstrained TE Label Switched Paths (LSPs) across a set of equal 139 cost paths. This requires knowledge of the number of unconstrained 140 Traffic Engineering Label Switched Paths (TE LSPs) signalled across 141 each link. 143 Note that the specification of load balancing algorithms is outside 144 the scope of this document and is referred to for the sake of 145 illustration of the motivation for gathering such information. 147 Furthermore, the knowledge of the number of unconstrained TE LSPs 148 signalled across each link can be used for other purposes, for 149 example to evaluate the number of affected unconstrained TE LSPs in 150 case of a link failure. 152 A set of Link-type sub-TLVs have been defined for OSPF and IS-IS (see 153 [RFC3630] and [I-D.ietf-isis-te-bis]) in the context of MPLS Traffic 154 Engineering in order to advertise various link characteristics such 155 as the available bandwidth, traffic engineering metric, 156 administrative group and so on. As currently defined in [RFC3630] 157 and [I-D.ietf-isis-te-bis] the information related to the number of 158 unconstrained TE LSP(s) is not available. This document specifies a 159 new Link-type Traffic Engineering sub-TLV used to indicate the number 160 of unconstrained TE LSPs signalled across a link. 162 Unconstrained TE LSPs that are configured and provisioned through a 163 management system MAY be omitted from the count that is reported. 165 3. Protocol extensions 167 Two Unconstrained TE LSP count sub-TLVs are defined that specify the 168 number of TE LSPs signalled with zero bandwidth across a link. 170 3.1. IS-IS 172 The IS-IS Unconstrained TE LSP Count Sub-TLV is OPTIONAL and MUST NOT 173 appear more than once within the extended IS reachability TLV (type 174 22) specified in [I-D.ietf-isis-te-bis] or the MT Intermediate 175 Systems TLV (type 222) specified in [RFC5120]. If a second instance 176 of the Unconstrained TE LSP Count sub-TLV is present, the receiving 177 system MUST only process the first instance of the sub-TLV. 179 The IS-IS Unconstrained TE LSP Count Sub-TLV format is defined below: 181 Type (1 octet): To be assigned by IANA (suggested value = 23) 183 Length (1 octet): 2 185 Value (2 octets): number of unconstrained TE LSP(s) signalled across 186 the link. 188 3.2. OSPF 190 The OSPF Unconstrained TE LSP Count TLV is OPTIONAL and MUST NOT 191 appear more than once within the Link TLV (Type 2) that is itself 192 carried within the Traffic Engineering LSA specified in [RFC3630] or 193 the OSPFv3 Intra-Area-TE LSA (function code 10) defined in 194 [I-D.ietf-ospf-ospfv3-traffic]. If a second instance of the 195 Unconstrained TE LSP Count sub-TLV is present, the receiving system 196 MUST only process the first instance of the sub-TLV. 198 The OSPF Unconstrained TE LSP Count Sub-TLV format is defined below: 200 Type (2 octets): To be assigned by IANA (suggested value = 23) 202 Length (2 octets): 4 204 Value (4 octets): number of unconstrained TE LSP(s) signalled across 205 the link. 207 4. Elements of procedure 209 The absence of the Unconstrained TE LSP Count (sub-)TLV SHOULD be 210 interpreted as an absence of information about the link. 212 Similarly to other MPLS Traffic Engineering link characteristics, 213 LSA/LSP origination trigger mechanisms are outside the scope of this 214 document. Care must be given to not trigger the systematic flooding 215 of a new IS-IS LSP or OSPF LSA with a too high granularity in case of 216 change of the number of unconstrained TE LSPs. 218 5. IANA Considerations 220 IANA has defined a sub-registry for the sub-TLVs carried in the IS-IS 221 TLV 22. IANA is requested to assign a new TLV code-point for the 222 Unconstrained TE LSP Count sub-TLV carried within the TLV 22. 224 Suggested Value TLV Name Reference 226 23 Unconstrained TE LSP Count (sub-)TLV This document 228 IANA has defined a sub-registry for the sub-TLVs carried in an OSPF 229 TE Link TLV (type 2). IANA is requested to assign a new sub-TLV 230 code-point for the Unconstrained TE LSP Count sub-TLV carried within 231 the TE Link TLV. 233 Suggested Value TLV Name Reference 235 23 Unconstrained TE LSP Count (sub-)TLV This document 237 6. Security Considerations 239 The function described in this document does not create any new 240 security issues for the OSPF and the IS-IS protocols. Security 241 considerations are covered in [RFC2328] and [RFC5340] for the base 242 OSPF protocol and in [RFC1195] and [I-D.ietf-isis-rfc3567bis] for 243 IS-IS. 245 A security framework for MPLS and Generalized MPLS can be found in 246 [I-D.ietf-mpls-mpls-and-gmpls-security-framework]. 248 7. Acknowledgements 250 The authors would like to thank Jean-Louis Le Roux, Adrian Farrel, 251 Daniel King, Acee Lindem, Lou Berger, Attila Takacs, Pasi Eronen, 252 Russ Housley, Tim Folk and Loa Anderson for their useful inputs. 254 8. References 256 8.1. Normative References 258 [I-D.ietf-isis-rfc3567bis] 259 Li, T. and R. Atkinson, "Intermediate System to 260 Intermediate System (IS-IS) Cryptographic 261 Authentication", draft-ietf-isis-rfc3567bis-03 (work in 262 progress), July 2008. 264 [I-D.ietf-isis-te-bis] 265 Li, T. and H. Smit, "IS-IS extensions for Traffic 266 Engineering", draft-ietf-isis-te-bis-00 (work in 267 progress), April 2008. 269 [I-D.ietf-ospf-ospfv3-traffic] 270 Ishiguro, K., Manral, V., Davey, A., and A. Lindem, 271 "Traffic Engineering Extensions to OSPF version 3", 272 draft-ietf-ospf-ospfv3-traffic-13 (work in progress), 273 June 2008. 275 [RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and 276 dual environments", RFC 1195, December 1990. 278 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 279 Requirement Levels", BCP 14, RFC 2119, March 1997. 281 [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998. 283 [RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering 284 (TE) Extensions to OSPF Version 2", RFC 3630, 285 September 2003. 287 [RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF 288 for IPv6", RFC 5340, July 2008. 290 8.2. Informative References 292 [I-D.ietf-mpls-mpls-and-gmpls-security-framework] 293 Fang, L. and M. Behringer, "Security Framework for MPLS 294 and GMPLS Networks", 295 draft-ietf-mpls-mpls-and-gmpls-security-framework-03 (work 296 in progress), July 2008. 298 [RFC4090] Pan, P., Swallow, G., and A. Atlas, "Fast Reroute 299 Extensions to RSVP-TE for LSP Tunnels", RFC 4090, 300 May 2005. 302 [RFC5120] Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi 303 Topology (MT) Routing in Intermediate System to 304 Intermediate Systems (IS-ISs)", RFC 5120, February 2008. 306 Authors' Addresses 308 JP Vasseur (editor) 309 Cisco Systems, Inc 310 1414 Massachusetts Avenue 311 Boxborough, MA 01719 312 USA 314 Email: jpv@cisco.com 316 Matthew R. Meyer 317 Global Crossing 318 3133 Indian Valley Tr. 319 Howell, MI 48855 320 USA 322 Email: mrminc@gmail.com 324 Kenji Kumaki 325 KDDI Corporation 326 Garden Air Tower Iidabashi, Chiyoda-ku, 327 Tokyo, 102-8460 328 JAPAN 330 Email: ke-kumaki@kddi.com 332 Alberto Tempia Bonda 333 Telecom Italia 334 via G. Reiss Romoli 274 335 Torino, 10148 336 ITALIA 338 Email: alberto.tempiabonda@telecomitalia.it 340 Full Copyright Statement 342 Copyright (C) The IETF Trust (2008). 344 This document is subject to the rights, licenses and restrictions 345 contained in BCP 78, and except as set forth therein, the authors 346 retain all their rights. 348 This document and the information contained herein are provided on an 349 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 350 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 351 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 352 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 353 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 354 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 356 Intellectual Property 358 The IETF takes no position regarding the validity or scope of any 359 Intellectual Property Rights or other rights that might be claimed to 360 pertain to the implementation or use of the technology described in 361 this document or the extent to which any license under such rights 362 might or might not be available; nor does it represent that it has 363 made any independent effort to identify any such rights. Information 364 on the procedures with respect to rights in RFC documents can be 365 found in BCP 78 and BCP 79. 367 Copies of IPR disclosures made to the IETF Secretariat and any 368 assurances of licenses to be made available, or the result of an 369 attempt made to obtain a general license or permission for the use of 370 such proprietary rights by implementers or users of this 371 specification can be obtained from the IETF on-line IPR repository at 372 http://www.ietf.org/ipr. 374 The IETF invites any interested party to bring to its attention any 375 copyrights, patents or patent applications, or other proprietary 376 rights that may cover technology that may be required to implement 377 this standard. Please address the information to the IETF at 378 ietf-ipr@ietf.org.