idnits 2.17.1 draft-ietf-isis-traffic-01.txt: ** The Abstract section seems to be numbered Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == No 'Intended status' indicated for this document; assuming Proposed Standard == It seems as if not all pages are separated by form feeds - found 0 form feeds but 9 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 5 instances of too long lines in the document, the longest one being 5 characters in excess of 72. ** The abstract seems to contain references ([2], [3], [1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 83: '... Implementations MUST NOT inject a /32...' RFC 2119 keyword, line 259: '... Implementations MUST NOT inject a /32...' RFC 2119 keyword, line 274: '... Implementations MUST NOT inject a /32...' Miscellaneous warnings: ---------------------------------------------------------------------------- -- 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 1999) is 9107 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 (-01) exists of draft-ietf-mpls-traffic-eng-00 ** Downref: Normative reference to an Informational draft: draft-ietf-mpls-traffic-eng (ref. '1') ** Obsolete normative reference: RFC 1142 (ref. '2') (Obsoleted by RFC 7142) Summary: 11 errors (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Henk Smit 2 INTERNET DRAFT Cisco Systems 3 Tony Li 4 Juniper Networks 5 May 1999 7 IS-IS extensions for Traffic Engineering 9 11 Status 13 This document is an Internet-Draft and is in full conformance with 14 all provisions of Section 10 of RFC2026 except that the right to 15 produce derivative works is not granted. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six 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 1.0 Abstract 35 This document describes extensions to the IS-IS protocol to support 36 Traffic Engineering [1]. The IS-IS protocol is specified in [2], 37 with extensions for supporting IPv4 specified in [3]. 39 This document extends the IS-IS protocol by specifying new 40 information that a Intermediate System (IS) [router] can place in 41 Link State Protocol Data Units (LSPs). This information describes 42 additional information about the state of the network that is useful 43 for traffic engineering computations. 45 2.0 Introduction 47 An IS-IS LSP is composed of a fixed header and a number of tuples, 48 each consisting of a Type, a Length, and a Value. Such tuples are 49 commonly known as TLVs, and are a good way of encoding information in 50 a flexible and extensible format. 52 The changes in this document include the design of new TLVs to 53 replace the existing IS Neighbor TLV, IP Reachability TLV and add 54 additional information. Mechanisms and procedures to migrate to the 55 new TLVs are not discussed in this document. 57 The primary goal of these extensions is to add more information about 58 the characteristics of a particular link to an IS-IS's LSP. 59 Secondary goals include increasing the dynamic range of the IS-IS 60 metric and improving the encoding of IP prefixes. The router id is 61 useful for traffic engineering purposes because it describes a single 62 address that can always be used to reference a particular router. 64 This document is a publication of the IS-IS Working Group within the 65 IETF, and is a contribution to ISO IEC JTC1/SC6, for eventual 66 inclusion with ISO 10589. 68 3.0 The router ID TLV 70 The router ID TLV is TLV type 134. 72 The router ID TLV contains the 4-octet router ID of the router 73 originating the LSP. This is useful in several regards: 75 For traffic engineering, it guarantees that we have a single stable 76 address that can always be referenced in a path that will be 77 reachable from multiple hops away, regardless of the state of the 78 node's interfaces. 80 If OSPF is also active in the domain, traffic engineering can compute 81 the mapping between the OSPF and IS-IS topologies. 83 Implementations MUST NOT inject a /32 prefix for the router ID into 84 their forwarding table, because this can lead to forwarding loops 85 when interacting with systems that do not support this TLV. 87 4.0 The extended IP reachability TLV 89 The extended IP reachability TLV is TLV type 135. 91 The existing IP reachability TLV is a single TLV that carries IP 92 prefixes in a format that is analogous to the IS neighbor TLV. It 93 carries four metrics, of which only the default metric is commonly 94 used. Of this, the default metric has a possible range of 0-63. 95 This limitation is one of the restrictions that we would like to 96 lift. 98 In addition, route redistribution (a.k.a. route leaking) is a key 99 problem that is not addressed by the existing IP reachability TLV. 100 This problem occurs when an IP prefix is injected into a level one 101 area, redistributed into level 2, subsequently redistributed into a 102 second level one area, and then redistributed from the second level 103 one area back into level two. This problem occurs because the path 104 that the information can take forms a loop. The likely result is a 105 forwarding loop. 107 To address these issues, the proposed extended IP reachability TLV 108 provides for a 32 bit metric and adds one bit to indicate that a 109 prefix has been redistributed 'down' in the hierarchy. 111 The proposed extended IP reachability TLV contains a new data 112 structure, consisting of: 113 4 bytes of metric information 114 1 byte of control information, consisting of 115 1 bit of up/down information 116 1 bit indicating the existence of sub-TLVs 117 6 bits of prefix length 118 0-4 bytes of IPv4 prefix 119 0-250 optional octets of sub-TVLs, if present consisting of 120 1 octet of length of sub-TLVs 121 0-249 octets of sub-TLVs 123 This data structure can be replicated within the TLV, not to exceed 124 the maximum length of the TLV. 126 The up/down bit shall be set to 0 when a prefix is first injected 127 into IS-IS. If a prefix is redistributed from a higher level to a 128 lower level (e.g. level two to level one), the bit shall be set to 1, 129 to indicate that the prefix has travelled down the hierarchy. 130 Prefixes that have the up/down bit set to 1 must not be 131 redistributed. If a prefix is redistributed from an area to another 132 area at the same level, then the up/down bit shall be set to 1. 134 These semantics apply even if IS-IS is extended in the future to have 135 additional levels. By insuring that prefixes follow only the IS-IS 136 hierarchy, we have insured that the information does not loop, 137 thereby insuring that there are no persistent forwarding loops. 139 If there are no sub-TLVs associated with this IP prefix, the bit 140 indicating the presence of sub-TVLs shall be set to 0. If this bit 141 is set to 1, the first octet after the prefix will be interpreted as 142 the length of sub-TLVs. Please note that while the encoding allows 143 for 255 octets of sub-TLVs, the maximum value cannot fit in the 144 overall extended IP reachability TLV. The practical maximum is 255 145 octets minus the 5-9 octets described above, or 250 octets. No sub- 146 TLVs for the extended IP reachability TLV have been defined yet. 148 The 6 bits of prefix length can have the values 0-32 and indicate the 149 number of significant bits in the prefix. The prefix is encoded in 150 the minimal number of bytes for the given number of significant bits. 151 This implies: 153 Significant bits Bytes 154 0 0 155 1-8 1 156 9-16 2 157 17-24 3 158 25-32 4 160 The remaining bits of prefix are transmitted as zero and ignored upon 161 receipt. 163 If an IP prefix is advertised with a metric larger then 164 MAX_PATH_METRIC (0xFE000000, see below), this IP prefix should not be 165 considered during the normal SPF computation. This will allow 166 advertisment of an IP prefix for other purposes than building the 167 normal IP routing table. 169 5.0 The extended IS reachability TLV 171 The extended IS reachability TLV is TLV type 22. 173 The existing IS reachability TLV is a single TLV that contains 174 information about a series of IS neighbors. For each neighbor, there 175 is a structure that contains the default metric, the delay, the 176 monetary cost, the reliability, and the 7-octet ID of the adjacent 177 neighbor. Of this information, the default metric is commonly used. 178 The default metric is currently one octet, with one bit used to 179 indicate that the metric is present and one bit used to indicate 180 whether the metric is internal or external. The remaining 6 bits are 181 used to store the actual metric, resulting a possible metric range of 182 0-63. This limitation is one of the restrictions that we would like 183 to lift. 185 The remaining three metrics (delay, monetary cost, and reliability) 186 are not commonly implemented and reflect unused overhead in the TLV. 187 The neighbor is identified by its system Id (typically 6-octets), 188 plus one octet to indicate the pseudonode number if the neighbor is 189 on a LAN interface. Thus, the existing TLV consumes 11 octets per 190 neighbor, with 4 octets for metric and 7 octets for neighbor 191 identification. To indicate multiple adjacencies, this structure is 192 repeated within the IS reachability TLV. Because the TLV is limited 193 to 255 octets of content, a single TLV can describe up to 23 194 neighbors. The IS reachability TLV can be repeated within the LSP 195 fragments to describe further neighbors. 197 The proposed extended IS reachability TLV contains a new data 198 structure, consisting of 199 7 octets of system Id and pseudonode number 200 3 octets of default metric 201 1 octet of length of sub-TLVs 202 0-244 octets of sub-TLVs 204 Thus, if no sub-TLVs are used, the new encoding requires 11 octets 205 and can contain up to 23 neighbors. Please note that while the 206 encoding allows for 255 octets of sub-TLVs, the maximum value cannot 207 fit in the overall IS reachability TLV. The practical maximum is 255 208 octets minus the 11 octets described above, or 244 octets. Further, 209 there is no defined mechanism for extending the sub-TLV space for a 210 particular neighbor. Thus, wasting sub-TLV space is discouraged. 212 The metric octets are encoded as a 24-bit unsigned integer. To 213 preclude overflow within an SPF implementation, all metrics greater 214 than or equal to MAX_PATH_METRIC shall be considered to have a metric 215 of MAX_PATH_METRIC. It is easiest to select MAX_PATH_METRIC such 216 that MAX_PATH_METRIC plus a single link metric does not overflow the 217 number of bits for internal metric calculation. We assume that this 218 is 32 bits. Thus, MAX_PATH_METRIC is 4,261,412,864 (0xFE000000, 2^32 219 - 2^25). 221 If a link is advertised with the maximum link metric (2^24 - 1), this 222 link should not be considered during the normal SPF computation. 223 This will allow advertisment of a link for other purposes than 224 building the normal Shortest Path Tree. An example is a link that is 225 available for traffic engineering, but not for hop-by-hop routing. 227 Certain sub-TLVs are proposed here: 229 Sub-TLV type Length (octets) Name 230 3 4 Administrative group (color) 231 6 4 IPv4 interface address 232 8 4 IPv4 neighbor address 233 9 4 Maximum link bandwidth 234 10 4 Reservable link bandwidth 235 11 32 Unreserved bandwidth 236 18 3 TE Default metric 237 250-254 Reserved for cisco specific 238 extensions 239 255 Reserved for future expansion 241 Each of these sub-TLVs is described below. Unless stated otherwise, 242 multiple occurrences of the information are supported by multiple 243 inclusions of the sub-TLV. 245 5.1 Sub-TLV 3: Administrative group (color, resource class) 247 The administrative group sub-TLV contains a 4-octet bit mask assigned 248 by the network administrator. Each set bit corresponds to one 249 administrative group assigned to the interface. 251 By convention the least significant bit is referred to as 'group 0', 252 and the most significant bit is referred to as 'group 31'. 254 5.2 Sub-TLV 6: IPv4 interface address 256 This sub-TLV contains a 4-octet IPv4 address for the interface 257 described by the (main) TLV. This sub-TLV can occur multiple times. 259 Implementations MUST NOT inject a /32 prefix for the interface 260 address into their routing or forwarding table, because this can lead 261 to forwarding loops when interacting with systems that do not support 262 this sub-TLV. 264 If a router implements the basic TLV extensions in this document, it 265 is free to add or omit this sub-TLV to the description of an 266 adjacency. If a router implements traffic engineering, it must 267 include this sub-TLV. 269 5.3 Sub-TLV 8: IPv4 neighbor address 271 This sub-TLV contains a single IPv4 address for a neighboring router 272 on this link. This sub-TLV can occur multiple times. 274 Implementations MUST NOT inject a /32 prefix for the neighbor address 275 into their routing or forwarding table, because this can lead to 276 forwarding loops when interacting with systems that do not support 277 this sub-TLV. 279 If a router implements the basic TLV extensions in this document, it 280 is free to add or omit this sub-TLV to the description of an 281 adjacency. If a router implements traffic engineering, it must 282 include this sub-TLV on point-to-point adjacencies. 284 5.4 Sub-TLV 9: Maximum link bandwidth 286 This sub-TLV contains the maximum bandwidth that can be used on this 287 link in this direction (from the system originating the LSP to its 288 neighbors). This is useful for traffic engineering. 290 The maximum link bandwidth is encoded in 32 bits in IEEE floating 291 point format. The units are bytes (not bits!) per second. 293 5.5 Sub-TLV 10: Maximum reservable link bandwidth 295 This sub-TLV contains the maximum amount of bandwidth that can be 296 reserved in this direction on this link. Note that for 297 oversubscription purposes, this can be greater than the bandwidth of 298 the link. 300 The maximum reservable link bandwidth is encoded in 32 bits in IEEE 301 floating point format. The units are bytes (not bits!) per second. 303 5.6 Sub-TLV 11: Unreserved bandwidth 305 This sub-TLV contains the amount of bandwidth reservable on this 306 direction on this link. Note that for oversubscription purposes, 307 this can be greater than the bandwidth of the link. 309 Because of the need for priority and preemption, each head end needs 310 to know the amount of reserved bandwidth at each priority level. 311 Thus, this sub-TLV contains eight 32 bit IEEE floating point numbers. 312 The units are bytes (not bits!) per second. The values correspond to 313 the bandwidth that can be reserved with a holding of priority 0 314 through 7, arranged in increasing order with priority 0 occurring at 315 the start of the sub-TLV, and priority 7 at the end of the sub-TLV. 317 For stability reasons, rapid changes in the values in this sub-TLV 318 should not cause rapid generation of LSPs. 320 5.7 Sub-TLV 18: Traffic Engineering Default metric 322 This sub-TLV contains a 24-bit unsigned integer. This metric is 323 administratively assigned and can be used to present a differently 324 weighted topology to traffic engineering SPF calculations. 326 To preclude overflow within an SPF implementation, all metrics 327 greater than or equal to MAX_PATH_METRIC shall be considered to have 328 a metric of MAX_PATH_METRIC. It is easiest to select MAX_PATH_METRIC 329 such that MAX_PATH_METRIC plus a single link metric does not overflow 330 the number of bits for internal metric calculation. We assume that 331 this is 32 bits. Thus, MAX_PATH_METRIC is 4,261,412,864 (0xFE000000, 332 2^32 - 2^25). 334 If a link is advertised without this sub-TLV, traffic engineering SPF 335 calculations must use the normal default metric of this link, which 336 is advertised in the fixed part of TLV 22. 338 6.0 Security Considerations 340 This document raises no new security issues for IS-IS. 342 7.0 Acknowledgments 344 The authors would like to thank Yakov Rekhter and Dave Katz for their 345 comments on this work. 347 8.0 References 349 [1] draft-ietf-mpls-traffic-eng-00.txt, "Requirements for Traffic 350 Engineering Over MPLS", D. Awduche, J. Malcolm, J. Agogbua, M. 351 O'Dell, J. McManus, work in progress. 353 [2] ISO 10589, "Intermediate System to Intermediate System Intra- 354 Domain Routeing Exchange Protocol for use in Conjunction with the 355 Protocol for Providing the Connectionless-mode Network Service (ISO 356 8473)" [Also republished as RFC 1142] 358 [3] RFC 1195, "Use of OSI IS-IS for routing in TCP/IP and dual 359 environments", R.W. Callon, Dec. 1990 361 9.0 Authors' Addresses 363 Henk Smit 364 Cisco Systems, Inc. 365 210 West Tasman Drive 366 San Jose, CA 95134 367 Email: hsmit@cisco.com 368 Voice: +31 20 342 3736 370 Tony Li 371 Juniper Networks, Inc. 372 385 Ravendale Dr. 373 Mountain View, CA 94043 374 Email: tli@juniper.net 375 Fax: +1 650 526 8001 376 Voice: +1 650 526 8006