idnits 2.17.1 draft-ietf-isis-traffic-00.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 394 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 83: '... Implementations MUST NOT inject a /32...' RFC 2119 keyword, line 243: '... Implementations MUST NOT inject a /32...' RFC 2119 keyword, line 259: '... 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 (February 1999) is 9201 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 February 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 and advertise new information. 54 Mechanisms and procedures to migrate to the new TLVs are not 55 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 5.0 The extended IS reachability TLV 165 The extended IS reachability TLV is TLV type 22. 167 The existing IS reachability TLV is a single TLV that contains 168 information about a series of IS neighbors. For each neighbor, there 169 is a structure that contains the default metric, the delay, the 170 monetary cost, the reliability, and the 7-octet ID of the adjacent 171 neighbor. Of this information, the default metric is commonly used. 172 The default metric is currently one octet, with one bit used to 173 indicate that the metric is present and one bit used to indicate 174 whether the metric is internal or external. The remaining 6 bits are 175 used to store the actual metric, resulting a possible metric range of 176 0-63. This limitation is one of the restrictions that we would like 177 to lift. 179 The remaining three metrics (delay, monetary cost, and reliability) 180 are not commonly implemented and reflect unused overhead in the TLV. 181 The neighbor is identified by its 6-octet system Id, plus one octet 182 to indicate the pseudonode number if the neighbor is on a LAN 183 interface. Thus, the existing TLV consumes 11 octets per neighbor, 184 with 4 octets for metric and 7 octets for neighbor identification. 185 To indicate multiple adjacencies, this structure is repeated within 186 the IS reachability TLV. Because the TLV is limited to 255 octets of 187 content, a single TLV can describe up to 23 neighbors. The IS 188 reachability TLV can be repeated within the LSP fragments to describe 189 further neighbors. 191 The proposed extended IS reachability TLV contains a new data 192 structure, consisting of 193 7 octets of system Id and pseudonode number 194 3 octets of default metric 195 1 octet of length of sub-TLVs 196 0-244 octets of sub-TLVs 198 Thus, if no sub-TLVs are used, the new encoding requires 11 octets 199 and can contain up to 23 neighbors. Please note that while the 200 encoding allows for 255 octets of sub-TLVs, the maximum value cannot 201 fit in the overall IS reachability TLV. The practical maximum is 255 202 octets minus the 11 octets described above, or 244 octets. Further, 203 there is no defined mechanism for extending the sub-TLV space for a 204 particular neighbor. Thus, wasting sub-TLV space is discouraged. 206 The metric octets are encoded as a 24-bit unsigned integer. To 207 preclude overflow within an SPF implementation, all metrics greater 208 than or equal to MAX_PATH_METRIC shall be considered to have a metric 209 of MAX_PATH_METRIC. It is easiest to select MAX_PATH_METRIC such 210 that MAX_PATH_METRIC plus a single link metric does not overflow the 211 number of bits for internal metric calculation. We assume that this 212 is 32 bits. Thus, MAX_PATH_METRIC is 4,261,412,864 (0xFE000000, 2^32 213 - 2^25). 215 Certain sub-TLVs are proposed here: 216 Sub-TLV type Length (octets) Name 217 3 4 Administrative group (color) 218 6 4 IPv4 interface address 219 8 4 IPv4 neighbor address 220 9 4 Maximum link bandwidth 221 10 2 Maximum reservable link bandwidth 222 11 32 Current bandwidth reservation 223 18 3 TE Default metric 225 Each of these sub-TLVs is described below. Unless stated otherwise, 226 multiple occurrences of the information are supported by multiple 227 inclusions of the sub-TLV. 229 5.1 Sub-TLV 3: Administrative group (color, resource class) 231 The administrative group sub-TLV contains a 4-octet bit mask assigned 232 by the network administrator. Each set bit corresponds to one 233 administrative group assigned to the interface. 235 By convention the least significant bit is referred to as 'group 0', 236 and the most significant bit is referred to as 'group 31'. 238 5.2 Sub-TLV 6: IPv4 interface address 240 This sub-TLV contains a 4-octet IPv4 address for the interface 241 described by the (main) TLV. This sub-TLV can occur multiple times. 243 Implementations MUST NOT inject a /32 prefix for the interface 244 address into their routing or forwarding table, because this can lead 245 to forwarding loops when interacting with systems that do not support 246 this sub-TLV. 248 If a router implements the basic TLV extensions in this document, it 249 is free to add or omit this sub-TLV to the description of an 250 adjacency. If a router implements traffic engineering, it must 251 include this sub-TLV. 253 5.3 Sub-TLV 8: IPv4 neighbor address 255 This sub-TLV contains a single IPv4 address for a neighboring router 256 on this link. This sub-TLV can occur multiple times. This sub-TLV 257 is useful for diagnostic purposes. 259 Implementations MUST NOT inject a /32 prefix for the neighbor address 260 into their routing or forwarding table, because this can lead to 261 forwarding loops when interacting with systems that do not support 262 this sub-TLV. 264 5.4 Sub-TLV 9: Maximum link bandwidth 266 This sub-TLV contains the maximum bandwidth that can be used on this 267 link in this direction (from the system originating the LSP to its 268 neighbors). This is useful for traffic engineering. 270 The bandwidth is encoded in 32 bits in IEEE floating point format. 271 The units are bytes (not bits!) per second. 273 5.5 Sub-TLV 10: Maximum reservable link bandwidth 275 This sub-TLV contains the maximum percentage of bandwidth that can be 276 reserved in this direction on this link. Note that for 277 oversubscription purposes, this can be greater than one hundred 278 percent of the bandwidth of the link. 280 This maximum percentage is encoded as a 2-octet unsigned integer. 281 Thus, this field can indicate that 0% of the link bandwidth up to 282 65,535% of the link bandwidth is available for reservation. 284 5.6 Sub-TLV 11: Current bandwidth reservation 286 This sub-TLV contains the amount of bandwidth currently reserved in 287 this direction on this link. Note that for oversubscription 288 purposes, this can be greater than the bandwidth of the link. This 289 is encoded similarly to the maximum link bandwidth. 291 Because of the need for priority and preemption, each head end needs 292 to know the amount of reserved bandwidth at each priority level. 293 Thus, this sub-TLV contains eight 32 bit IEEE floating point numbers. 294 The units are bytes (not bits!) per second. The values correspond to 295 the bandwidth reserved with a holding of priority 0 through 7, 296 arranged in increasing order with priority 0 occurring at the start 297 of the sub-TLV, and priority 7 at the end of the sub-TLV. 299 For stability reasons, rapid changes in the values in this sub-TLV 300 should not cause rapid generation of LSPs. 302 5.7 Sub-TLV 18: Traffic Engineering Default metric 304 This sub-TLV contains a 24-bit unsigned integer. This metric is 305 administratively assigned and can be used to present a differently 306 weighted topology to traffic engineering SPF calculations. 308 To preclude overflow within an SPF implementation, all metrics 309 greater than or equal to MAX_PATH_METRIC shall be considered to have 310 a metric of MAX_PATH_METRIC. It is easiest to select MAX_PATH_METRIC 311 such that MAX_PATH_METRIC plus a single link metric does not overflow 312 the number of bits for internal metric calculation. We assume that 313 this is 32 bits. Thus, MAX_PATH_METRIC is 4,261,412,864 (0xFE000000, 314 2^32 - 2^25). 316 6.0 Security Considerations 318 This document raises no new security issues for IS-IS. 320 7.0 Acknowledgments 322 The authors would like to thank Yakov Rekhter and Dave Katz for their 323 comments on this work. 325 8.0 References 327 [1] draft-ietf-mpls-traffic-eng-00.txt, "Requirements for Traffic 328 Engineering Over MPLS", D. Awduche, J. Malcolm, J. Agogbua, M. 329 O'Dell, J. McManus, work in progress. 331 [2] ISO 10589, "Intermediate System to Intermediate System Intra- 332 Domain Routeing Exchange Protocol for use in Conjunction with the 333 Protocol for Providing the Connectionless-mode Network Service (ISO 334 8473)" [Also republished as RFC 1142] 336 [3] RFC 1195, "Use of OSI IS-IS for routing in TCP/IP and dual 337 environments", R.W. Callon, Dec. 1990 339 9.0 Authors' Addresses 341 Henk Smit 342 Cisco Systems, Inc. 343 210 West Tasman Drive 344 San Jose, CA 95134 345 Email: hsmit@cisco.com 346 Voice: +31 20 342 3736 348 Tony Li 349 Juniper Networks, Inc. 350 385 Ravendale Dr. 351 Mountain View, CA 94043 352 Email: tli@juniper.net 353 Fax: +1 650 526 8001 354 Voice: +1 650 526 8006