idnits 2.17.00 (12 Aug 2021) /tmp/idnits6632/draft-ietf-isis-traffic-02.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 == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 482 lines 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 6 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 88: '... Implementations MUST NOT inject a /32...' RFC 2119 keyword, line 273: '... Implementations MUST NOT inject a /32...' RFC 2119 keyword, line 295: '... 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 (September 2000) is 7917 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) ** Downref: Normative reference to an Informational RFC: RFC 2702 (ref. '1') ** Obsolete normative reference: RFC 1142 (ref. '2') (Obsoleted by RFC 7142) Summary: 11 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Tony Li 2 INTERNET DRAFT Procket Networks 3 Henk Smit 4 Procket Networks 5 September 2000 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 Traffic Engineering router ID TLV 70 The Traffic Engineering 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 If a router advertises the Traffic Engineering router ID TLV in its 84 LSP, and if it advertises BGP routes with the BGP next hop attribute 85 set to the BGP router ID, in that case the Traffic Engineering router 86 ID should be the same as the BGP router ID. 88 Implementations MUST NOT inject a /32 prefix for the router ID into 89 their forwarding table, because this can lead to forwarding loops 90 when interacting with systems that do not support this TLV. 92 4.0 The extended IP reachability TLV 94 The extended IP reachability TLV is TLV type 135. 96 The existing IP reachability TLV is a single TLV that carries IP 97 prefixes in a format that is analogous to the IS neighbor TLV. It 98 carries four metrics, of which only the default metric is commonly 99 used. Of this, the default metric has a possible range of 0-63. 100 This limitation is one of the restrictions that we would like to 101 lift. 103 In addition, route redistribution (a.k.a. route leaking) is a key 104 problem that is not addressed by the existing IP reachability TLV. 105 This problem occurs when an IP prefix is injected into a level one 106 area, redistributed into level 2, subsequently redistributed into a 107 second level one area, and then redistributed from the second level 108 one area back into level two. This problem occurs because the path 109 that the information can take forms a loop. The likely result is a 110 forwarding loop. 112 To address these issues, the proposed extended IP reachability TLV 113 provides for a 32 bit metric and adds one bit to indicate that a 114 prefix has been redistributed 'down' in the hierarchy. 116 The proposed extended IP reachability TLV contains a new data 117 structure, consisting of: 118 4 bytes of metric information 119 1 byte of control information, consisting of 120 1 bit of up/down information 121 1 bit indicating the existence of sub-TLVs 122 6 bits of prefix length 123 0-4 bytes of IPv4 prefix 124 0-250 optional octets of sub-TVLs, if present consisting of 125 1 octet of length of sub-TLVs 126 0-249 octets of sub-TLVs 128 This data structure can be replicated within the TLV, not to exceed 129 the maximum length of the TLV. 131 The up/down bit shall be set to 0 when a prefix is first injected 132 into IS-IS. If a prefix is redistributed from a higher level to a 133 lower level (e.g. level two to level one), the bit shall be set to 1, 134 to indicate that the prefix has travelled down the hierarchy. 135 Prefixes that have the up/down bit set to 1 must not be 136 redistributed. If a prefix is redistributed from an area to another 137 area at the same level, then the up/down bit shall be set to 1. 139 These semantics apply even if IS-IS is extended in the future to have 140 additional levels. By insuring that prefixes follow only the IS-IS 141 hierarchy, we have insured that the information does not loop, 142 thereby insuring that there are no persistent forwarding loops. 144 If there are no sub-TLVs associated with this IP prefix, the bit 145 indicating the presence of sub-TVLs shall be set to 0. If this bit 146 is set to 1, the first octet after the prefix will be interpreted as 147 the length of sub-TLVs. Please note that while the encoding allows 148 for 255 octets of sub-TLVs, the maximum value cannot fit in the 149 overall extended IP reachability TLV. The practical maximum is 255 150 octets minus the 5-9 octets described above, or 250 octets. No sub- 151 TLVs for the extended IP reachability TLV have been defined yet. 153 The 6 bits of prefix length can have the values 0-32 and indicate the 154 number of significant bits in the prefix. The prefix is encoded in 155 the minimal number of bytes for the given number of significant bits. 156 This implies: 158 Significant bits Bytes 159 0 0 160 1-8 1 161 9-16 2 162 17-24 3 163 25-32 4 165 The remaining bits of prefix are transmitted as zero and ignored upon 166 receipt. 168 If an IP prefix is advertised with a metric larger then 169 MAX_PATH_METRIC (0xFE000000, see below), this IP prefix should not be 170 considered during the normal SPF computation. This will allow 171 advertisment of an IP prefix for other purposes than building the 172 normal IP routing table. 174 5.0 The extended IS reachability TLV 176 The extended IS reachability TLV is TLV type 22. 178 The existing IS reachability TLV is a single TLV that contains 179 information about a series of IS neighbors. For each neighbor, there 180 is a structure that contains the default metric, the delay, the 181 monetary cost, the reliability, and the 7-octet ID of the adjacent 182 neighbor. Of this information, the default metric is commonly used. 183 The default metric is currently one octet, with one bit used to 184 indicate that the metric is present and one bit used to indicate 185 whether the metric is internal or external. The remaining 6 bits are 186 used to store the actual metric, resulting a possible metric range of 187 0-63. This limitation is one of the restrictions that we would like 188 to lift. 190 The remaining three metrics (delay, monetary cost, and reliability) 191 are not commonly implemented and reflect unused overhead in the TLV. 192 The neighbor is identified by its system Id (typically 6-octets), 193 plus one octet to indicate the pseudonode number if the neighbor is 194 on a LAN interface. Thus, the existing TLV consumes 11 octets per 195 neighbor, with 4 octets for metric and 7 octets for neighbor 196 identification. To indicate multiple adjacencies, this structure is 197 repeated within the IS reachability TLV. Because the TLV is limited 198 to 255 octets of content, a single TLV can describe up to 23 199 neighbors. The IS reachability TLV can be repeated within the LSP 200 fragments to describe further neighbors. 202 The proposed extended IS reachability TLV contains a new data 203 structure, consisting of 204 7 octets of system Id and pseudonode number 205 3 octets of default metric 206 1 octet of length of sub-TLVs 207 0-244 octets of sub-TLVs 209 Thus, if no sub-TLVs are used, the new encoding requires 11 octets 210 and can contain up to 23 neighbors. Please note that while the 211 encoding allows for 255 octets of sub-TLVs, the maximum value cannot 212 fit in the overall IS reachability TLV. The practical maximum is 255 213 octets minus the 11 octets described above, or 244 octets. Further, 214 there is no defined mechanism for extending the sub-TLV space for a 215 particular neighbor. Thus, wasting sub-TLV space is discouraged. 217 The metric octets are encoded as a 24-bit unsigned integer. Note that 218 the metric field in the new extended IP reachability TLV is encoded 219 as a 32-bit unsigned integer. These different sizes were chosen so 220 that it is very unlikely that the cost of an intra-area route has to 221 be chopped off to fit in the metric field of an inter-area route. 223 To preclude overflow within an SPF implementation, all metrics 224 greater than or equal to MAX_PATH_METRIC shall be considered to have 225 a metric of MAX_PATH_METRIC. It is easiest to select MAX_PATH_METRIC 226 such that MAX_PATH_METRIC plus a single link metric does not overflow 227 the number of bits for internal metric calculation. We assume that 228 this is 32 bits. Thus, MAX_PATH_METRIC is 4,261,412,864 (0xFE000000, 229 2^32 - 2^25). 231 If a link is advertised with the maximum link metric (2^24 - 1), this 232 link should not be considered during the normal SPF computation. 233 This will allow advertisment of a link for other purposes than 234 building the normal Shortest Path Tree. An example is a link that is 235 available for traffic engineering, but not for hop-by-hop routing. 237 Certain sub-TLVs are proposed here: 238 Sub-TLV type Length (octets) Name 239 3 4 Administrative group (color) 240 6 4 IPv4 interface address 241 8 4 IPv4 neighbor address 242 9 4 Maximum link bandwidth 243 10 4 Reservable link bandwidth 244 11 32 Unreserved bandwidth 245 18 3 TE Default metric 246 250-254 Reserved for cisco specific extensions 247 255 Reserved for future expansion 249 Each of these sub-TLVs is described below. Unless stated otherwise, 250 multiple occurrences of the information are supported by multiple 251 inclusions of the sub-TLV. 253 5.1 Sub-TLV 3: Administrative group (color, resource class) 255 The administrative group sub-TLV contains a 4-octet bit mask assigned 256 by the network administrator. Each set bit corresponds to one 257 administrative group assigned to the interface. 259 By convention the least significant bit is referred to as 'group 0', 260 and the most significant bit is referred to as 'group 31'. 262 5.2 Sub-TLV 6: IPv4 interface address 264 This sub-TLV contains a 4-octet IPv4 address for the interface 265 described by the (main) TLV. This sub-TLV can occur multiple times. 267 If the interface being advertised for Traffic Engineering purposes is 268 unnumbered, the IPv4 interface address sub-TLV is set to the router 269 ID of the advertising router. In combination with the IPv4 neighbor 270 address sub-TLV this identifies the unnumbered link over which the 271 advertised adjacency has been established. 273 Implementations MUST NOT inject a /32 prefix for the interface 274 address into their routing or forwarding table, because this can lead 275 to forwarding loops when interacting with systems that do not support 276 this sub-TLV. 278 If a router implements the basic TLV extensions in this document, it 279 is free to add or omit this sub-TLV to the description of an 280 adjacency. If a router implements traffic engineering, it must 281 include this sub-TLV. 283 5.3 Sub-TLV 8: IPv4 neighbor address 285 This sub-TLV contains a single IPv4 address for a neighboring router 286 on this link. This sub-TLV can occur multiple times. 288 If the interface being advertised for Traffic Engineering purposes is 289 unnumbered, the first two octets of the IPv4 neighbor address sub-TLV 290 are set to zero and the next two octets are set to the interface ID 291 of the unnumbered interface. In combination with the IPv4 interface 292 address sub-TLV this identifies the unnumbered link over which the 293 advertised adjacency has been established. 295 Implementations MUST NOT inject a /32 prefix for the neighbor address 296 into their routing or forwarding table, because this can lead to 297 forwarding loops when interacting with systems that do not support 298 this sub-TLV. 300 If a router implements the basic TLV extensions in this document, it 301 is free to add or omit this sub-TLV to the description of an 302 adjacency. If a router implements traffic engineering, it must 303 include this sub-TLV on point-to-point adjacencies. 305 5.4 Sub-TLV 9: Maximum link bandwidth 307 This sub-TLV contains the maximum bandwidth that can be used on this 308 link in this direction (from the system originating the LSP to its 309 neighbors). This is useful for traffic engineering. 311 The maximum link bandwidth is encoded in 32 bits in IEEE floating 312 point format. The units are bytes (not bits!) per second. 314 5.5 Sub-TLV 10: Maximum reservable link bandwidth 316 This sub-TLV contains the maximum amount of bandwidth that can be 317 reserved in this direction on this link. Note that for 318 oversubscription purposes, this can be greater than the bandwidth of 319 the link. 321 The maximum reservable link bandwidth is encoded in 32 bits in IEEE 322 floating point format. The units are bytes (not bits!) per second. 324 5.6 Sub-TLV 11: Unreserved bandwidth 326 This sub-TLV contains the amount of bandwidth reservable on this 327 direction on this link. Note that for oversubscription purposes, 328 this can be greater than the bandwidth of the link. 330 Because of the need for priority and preemption, each head end needs 331 to know the amount of reserved bandwidth at each priority level. 332 Thus, this sub-TLV contains eight 32 bit IEEE floating point numbers. 333 The units are bytes (not bits!) per second. The values correspond to 334 the bandwidth that can be reserved with a holding of priority 0 335 through 7, arranged in increasing order with priority 0 occurring at 336 the start of the sub-TLV, and priority 7 at the end of the sub-TLV. 338 For stability reasons, rapid changes in the values in this sub-TLV 339 should not cause rapid generation of LSPs. 341 5.7 Sub-TLV 18: Traffic Engineering Default metric 343 This sub-TLV contains a 24-bit unsigned integer. This metric is 344 administratively assigned and can be used to present a differently 345 weighted topology to traffic engineering SPF calculations. 347 To preclude overflow within an SPF implementation, all metrics 348 greater than or equal to MAX_PATH_METRIC shall be considered to have 349 a metric of MAX_PATH_METRIC. It is easiest to select MAX_PATH_METRIC 350 such that MAX_PATH_METRIC plus a single link metric does not overflow 351 the number of bits for internal metric calculation. We assume that 352 this is 32 bits. Thus, MAX_PATH_METRIC is 4,261,412,864 (0xFE000000, 353 2^32 - 2^25). 355 If a link is advertised without this sub-TLV, traffic engineering SPF 356 calculations must use the normal default metric of this link, which 357 is advertised in the fixed part of the extended IS reachability TLV. 359 6.0 Security Considerations 361 This document raises no new security issues for IS-IS. 363 7.0 Acknowledgments 365 The authors would like to thank Yakov Rekhter and Dave Katz for their 366 comments on this work. 368 8.0 References 370 [1] RFC 2702, "Requirements for Traffic Engineering Over MPLS," D. 371 Awduche, J. Malcolm, J. Agogbua, M. O'Dell, and J. McManus, September 372 1999. 374 [2] ISO 10589, "Intermediate System to Intermediate System Intra- 375 Domain Routeing Exchange Protocol for use in Conjunction with the 376 Protocol for Providing the Connectionless-mode Network Service (ISO 377 8473)" [Also republished as RFC 1142] 379 [3] RFC 1195, "Use of OSI IS-IS for routing in TCP/IP and dual 380 environments", R.W. Callon, Dec. 1990 382 9.0 Authors' Addresses 384 Tony Li 385 Procket Networks, Inc. 386 3850 North First Street 387 San Jose, CA 95134 388 Email: tli@procket.com 389 Voice: +1 408 9547900 390 Fax: +1 408 9876166 392 Henk Smit 393 Procket Networks, Inc. 394 3850 North First Street 395 San Jose, CA 95134 396 Email: henk@procket.com 397 Voice: +1 408 9547900 398 Fax: +1 408 9876166