idnits 2.17.1 draft-ietf-isis-te-bis-00.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 16. -- Found old boilerplate from RFC 3978, Section 5.5 on line 700. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 677. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 684. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 690. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- -- The draft header indicates that this document obsoletes RFC3784, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: If a router does not implement traffic engineering, it MAY add or omit the Traffic Engineering router ID TLV. If a router implements traffic engineering, it MUST include this TLV in its LSP. This TLV SHOULD not be included more than once in an LSP. -- 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 (August 2005) is 6826 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) -- Possible downref: Non-RFC (?) normative reference: ref. 'ISO-10589' ** Obsolete normative reference: RFC 2966 (Obsoleted by RFC 5302) -- Obsolete informational reference (is this intentional?): RFC 2434 (Obsoleted by RFC 5226) -- Obsolete informational reference (is this intentional?): RFC 3784 (Obsoleted by RFC 5305) Summary: 4 errors (**), 0 flaws (~~), 3 warnings (==), 11 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IS-IS for IP Internets Working T. Li 3 Group H. Smit 4 Internet-Draft Cisco Systems 5 Obsoletes: 3784 (if approved) August 2005 6 Expires: February 2, 2006 8 IS-IS extensions for Traffic Engineering 9 draft-ietf-isis-te-bis-00.txt 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on February 2, 2006. 36 Copyright Notice 38 Copyright (C) The Internet Society (2005). 40 Abstract 42 This document describes extensions to the Intermediate System to 43 Intermediate System (IS-IS) protocol to support Traffic Engineering 44 (TE). This document extends the IS-IS protocol by specifying new 45 information that an Intermediate System (router) can place in Link 46 State Protocol (LSP) Data Units. This information describes 47 additional details regarding the state of the network that are useful 48 for traffic engineering computations. 50 Requirements Language 52 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 53 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 54 document are to be interpreted as described in RFC 2119 [RFC2119]. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 2. Introducing Sub-TLVs . . . . . . . . . . . . . . . . . . . . . 4 62 3. The Extended IS Reachability TLV . . . . . . . . . . . . . . . 5 63 3.1. Sub-TLV 3: Administrative group (color, resource class) . 7 64 3.2. Sub-TLV 6: IPv4 interface address . . . . . . . . . . . . 7 65 3.3. Sub-TLV 8: IPv4 neighbor address . . . . . . . . . . . . . 8 66 3.4. Sub-TLV 9: Maximum link bandwidth . . . . . . . . . . . . 8 67 3.5. Sub-TLV 10: Maximum reservable link bandwidth . . . . . . 8 68 3.6. Sub-TLV 11: Unreserved bandwidth . . . . . . . . . . . . . 9 69 3.7. Sub-TLV 18: Traffic Engineering Default Metric . . . . . . 9 71 4. The Extended IP Reachability TLV . . . . . . . . . . . . . . . 10 72 4.1. The up/down Bit . . . . . . . . . . . . . . . . . . . . . 11 73 4.2. Expandability of the Extended IP Reachability TLV with 74 Sub-TLVs . . . . . . . . . . . . . . . . . . . . . . . . . 12 75 4.3. The Traffic Engineering Router ID TLV . . . . . . . . . . 12 77 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 78 5.1. TLV Codepoint Allocations . . . . . . . . . . . . . . . . 14 79 5.2. New Registries . . . . . . . . . . . . . . . . . . . . . . 14 80 5.2.1. Sub-TLVs for the Extended IS Reachability TLV . . . . 14 81 5.2.2. Sub-TLVs for the Extended IP Reachability TLV . . . . 15 83 6. Security Considerations . . . . . . . . . . . . . . . . . . . 16 85 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17 87 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 88 8.1. Normative References . . . . . . . . . . . . . . . . . . . 18 89 8.2. Informative References . . . . . . . . . . . . . . . . . . 18 91 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20 92 Intellectual Property and Copyright Statements . . . . . . . . . . 21 94 1. Introduction 96 The IS-IS protocol is specified in ISO 10589 [ISO-10589], with 97 extensions for supporting IPv4 specified in [RFC1195]. Each 98 Intermediate System (IS) (router) advertises one or more IS-IS Link 99 State Protocol Data Units (LSPs) with routing information. Each LSP 100 is composed of a fixed header and a number of tuples, each consisting 101 of a Type, a Length, and a Value. Such tuples are commonly known as 102 TLVs, and are a good way of encoding information in a flexible and 103 extensible format. 105 This document contains the design of new TLVs to replace the existing 106 IS Neighbor TLV, IP Reachability TLV, and to include additional 107 information about the characteristics of a particular link to an IS- 108 IS LSP. The characteristics described in this document are needed 109 for Traffic Engineering [RFC2702]. Secondary goals include 110 increasing the dynamic range of the IS-IS metric and improving the 111 encoding of IP prefixes. 113 The router id is useful for traffic engineering purposes because it 114 describes a single address that can always be used to reference a 115 particular router. 117 Mechanisms and procedures to migrate to the new TLVs are not 118 discussed in this document. 120 A prior version of this document was published as [RFC3784] with 121 Informational status. This version is on the standards track. 123 2. Introducing Sub-TLVs 125 This document introduces a new way to encode routing information in 126 IS-IS. The new object is called a sub-TLV. Sub-TLVs are similar to 127 regular TLVs. They use the same concepts as regular TLVs. The 128 difference is that TLVs exist inside IS-IS packets, while sub-TLVs 129 exist inside TLVs. TLVs are used to add extra information to IS-IS 130 packets. Sub-TLVs are used to add extra information to particular 131 TLVs. Each sub-TLV consists of three fields, a one-octet Type field, 132 a one-octet Length field, and zero or more octets of Value. The Type 133 field indicates the type of items in the Value field. The Length 134 field indicates the length of the Value field in octets. Each sub- 135 TLV can potentially hold multiple items. The number of items in a 136 sub-TLV can be computed from the length of the whole sub-TLV, when 137 the length of each item is known. Unknown sub-TLVs are to be ignored 138 and skipped upon receipt. 140 The Sub-TLV type space is managed by the IETF IS-IS WG [1]. New type 141 values are allocated following review on the IETF IS-IS mailing list. 142 This will normally require publication of additional documentation 143 describing how the new type is used. In the event that the IS-IS 144 working group has disbanded the review shall be performed by a 145 Designated Expert assigned by the responsible Area Director. 147 3. The Extended IS Reachability TLV 149 The extended IS reachability TLV is TLV type 22. 151 The existing IS reachability (TLV type 2, defined in ISO 10589 [ISO- 152 10589]) contains information about a series of IS neighbors. For 153 each neighbor, there is a structure that contains the default metric, 154 the delay, the monetary cost, the reliability, and the 7-octet ID of 155 the adjacent neighbor. Of this information, the default metric is 156 commonly used. The default metric is currently one octet, with one 157 bit used to indicate whether the metric is internal or external, and 158 one bit that was originally unused, but which was later defined by 159 [RFC2966] to be the up/down bit. The remaining 6 bits are used to 160 store the actual metric, resulting in a possible metric range of 0- 161 63. This limitation is one of the restrictions that we would like to 162 lift. 164 The remaining three metrics (delay, monetary cost, and reliability) 165 are not commonly implemented and reflect unused overhead in the TLV. 166 The neighbor is identified by its system ID, typically 6-octets, plus 167 one octet indicating the pseudonode number. Thus, the existing TLV 168 consumes 11 octets per neighbor, with 4 octets for metric and 7 169 octets for neighbor identification. To indicate multiple 170 adjacencies, this structure is repeated within the IS reachability 171 TLV. Because the TLV is limited to 255 octets of content, a single 172 TLV can describe up to 23 neighbors. The IS reachability TLV can be 173 repeated within the LSP fragments to describe further neighbors. 175 The proposed extended IS reachability TLV contains a new data 176 structure, consisting of: 178 7 octets of system Id and pseudonode number 180 3 octets of default metric 182 1 octet of length of sub-TLVs 184 0-244 octets of sub-TLVs, where each sub-TLV consists of a 185 sequence of 187 1 octet of sub-type 189 1 octet of length of the value field of the sub-TLV 191 0-242 octets of value 193 Thus, if no sub-TLVs are used, the new encoding requires 11 octets 194 and can contain up to 23 neighbors. Please note that while the 195 encoding allows for 255 octets of sub-TLVs, the maximum value cannot 196 fit in the overall IS reachability TLV. The practical maximum is 255 197 octets minus the 11 octets described above, or 244 octets. Further, 198 there is no defined mechanism for extending the sub-TLV space for a 199 particular neighbor. Thus, wasting sub-TLV space is discouraged. 201 The metric octets are encoded as a 24-bit unsigned integer. Note 202 that the metric field in the new extended IP reachability TLV is 203 encoded as a 32-bit unsigned integer. These different sizes were 204 chosen so that it is very unlikely that the cost of an intra-area 205 route has to be chopped off to fit in the metric field of an inter- 206 area route. 208 To preclude overflow within a traffic engineering SPF implementation, 209 all metrics greater than or equal to MAX_PATH_METRIC SHALL be 210 considered to have a metric of MAX_PATH_METRIC. It is easiest to 211 select MAX_PATH_METRIC such that MAX_PATH_METRIC plus a single link 212 metric does not overflow the number of bits for internal metric 213 calculation. We assume that this is 32 bits. Therefore, we have 214 chosen MAX_PATH_METRIC to be 4,261,412,864 (0xFE000000, 2^32 - 2^25). 216 If a link is advertised with the maximum link metric (2^24 - 1), this 217 link MUST NOT be considered during the normal SPF computation. This 218 will allow advertisement of a link for purposes other than building 219 the normal Shortest Path Tree. An example is a link that is 220 available for traffic engineering, but not for hop-by-hop routing. 222 Certain sub-TLVs are proposed here: 224 +------------+----------------+-------------------------------------+ 225 | Sub-TLV | Length | Name | 226 | type | (octets) | | 227 +------------+----------------+-------------------------------------+ 228 | 3 | 4 | Administrative group (color) | 229 | | | | 230 | 6 | 4 | IPv4 interface address | 231 | | | | 232 | 8 | 4 | IPv4 neighbor address | 233 | | | | 234 | 9 | 4 | Maximum link bandwidth | 235 | | | | 236 | 10 | 4 | Reservable link bandwidth | 237 | | | | 238 | 11 | 32 | Unreserved bandwidth | 239 | | | | 240 | 18 | 3 | TE Default metric | 241 | | | | 242 | 250-254 | | Reserved for cisco specific | 243 | | | extensions | 244 | | | | 245 | 255 | | Reserved for future expansion | 246 +------------+----------------+-------------------------------------+ 248 Each of these sub-TLVs is described below. Unless stated otherwise, 249 multiple occurrences of the information are supported by multiple 250 inclusions of the sub-TLV. 252 3.1. Sub-TLV 3: Administrative group (color, resource class) 254 The administrative group sub-TLV contains a 4-octet bit mask assigned 255 by the network administrator. Each set bit corresponds to one 256 administrative group assigned to the interface. 258 By convention, the least significant bit is referred to as 'group 0', 259 and the most significant bit is referred to as 'group 31'. 261 This sub-TLV is OPTIONAL. This sub-TLV SHOULD appear once at most in 262 each extended IS reachability TLV. 264 3.2. Sub-TLV 6: IPv4 interface address 266 This sub-TLV contains a 4-octet IPv4 address for the interface 267 described by the (main) TLV. This sub-TLV can occur multiple times. 269 Implementations MUST NOT inject a /32 prefix for the interface 270 address into their routing or forwarding table because this can lead 271 to forwarding loops when interacting with systems that do not support 272 this sub-TLV. 274 If a router implements the basic TLV extensions in this document, it 275 MAY add or omit this sub-TLV from the description of an adjacency. 276 If a router implements traffic engineering, it MUST include this sub- 277 TLV. 279 3.3. Sub-TLV 8: IPv4 neighbor address 281 This sub-TLV contains a single IPv4 address for a neighboring router 282 on this link. This sub-TLV can occur multiple times. 284 Implementations MUST NOT inject a /32 prefix for the neighbor address 285 into their routing or forwarding table because this can lead to 286 forwarding loops when interacting with systems that do not support 287 this sub-TLV. 289 If a router implements the basic TLV extensions in this document, it 290 MAY add or omit this sub-TLV from the description of an adjacency. 291 If a router implements traffic engineering, it MUST include this sub- 292 TLV on point-to-point adjacencies. 294 3.4. Sub-TLV 9: Maximum link bandwidth 296 This sub-TLV contains the maximum bandwidth that can be used on this 297 link in this direction (from the system originating the LSP to its 298 neighbors). This is useful for traffic engineering. 300 The maximum link bandwidth is encoded in 32 bits in IEEE floating 301 point format. The units are bytes (not bits!) per second. 303 This sub-TLV is optional. This sub-TLV SHOULD appear once at most in 304 each extended IS reachability TLV. 306 3.5. Sub-TLV 10: Maximum reservable link bandwidth 308 This sub-TLV contains the maximum amount of bandwidth that can be 309 reserved in this direction on this link. Note that for 310 oversubscription purposes, this can be greater than the bandwidth of 311 the link. 313 The maximum reservable link bandwidth is encoded in 32 bits in IEEE 314 floating point format. The units are bytes (not bits!) per second. 316 This sub-TLV is optional. This sub-TLV SHOULD appear once at most in 317 each extended IS reachability TLV. 319 3.6. Sub-TLV 11: Unreserved bandwidth 321 This sub-TLV contains the amount of bandwidth reservable in this 322 direction on this link. Note that for oversubscription purposes, 323 this can be greater than the bandwidth of the link. 325 Because of the need for priority and preemption, each head end needs 326 to know the amount of reserved bandwidth at each priority level. 327 Thus, this sub-TLV contains eight 32 bit IEEE floating point numbers. 328 The units are bytes (not bits!) per second. The values correspond to 329 the bandwidth that can be reserved with a setup priority of 0 through 330 7, arranged in increasing order with priority 0 occurring at the 331 start of the sub-TLV, and priority 7 at the end of the sub-TLV. 333 For stability reasons, rapid changes in the values in this sub-TLV 334 SHOULD NOT cause rapid generation of LSPs. 336 This sub-TLV is optional. This sub-TLV SHOULD appear once at most in 337 each extended IS reachability TLV. 339 3.7. Sub-TLV 18: Traffic Engineering Default Metric 341 This sub-TLV contains a 24-bit unsigned integer. This metric is 342 administratively assigned and can be used to present a differently 343 weighted topology to traffic engineering SPF calculations. 345 To preclude overflow within a traffic engineering SPF implementation, 346 all metrics greater than or equal to MAX_PATH_METRIC SHALL be 347 considered to have a metric of MAX_PATH_METRIC. It is easiest to 348 select MAX_PATH_METRIC such that MAX_PATH_METRIC plus a single link 349 metric does not overflow the number of bits for internal metric 350 calculation. We assume that this is 32 bits. Therefore, we have 351 chosen MAX_PATH_METRIC to be 4,261,412,864 (0xFE000000, 2^32 - 2^25). 353 This sub-TLV is optional. This sub-TLV SHOULD appear once at most in 354 each extended IS reachability TLV. If a link is advertised without 355 this sub-TLV, traffic engineering SPF calculations MUST use the 356 normal default metric of this link, which is advertised in the fixed 357 part of the extended IS reachability TLV. 359 4. The Extended IP Reachability TLV 361 The extended IP reachability TLV is TLV type 135. 363 The existing IP reachability TLVs (TLV type 128 and TLV type 130, 364 defined in [RFC1195]) carry IP prefixes in a format that is analogous 365 to the IS neighbor TLV from ISO 10589 [ISO-10589]. They carry four 366 metrics, of which only the default metric is commonly used. The 367 default metric has a possible range of 0-63. We would like to remove 368 this restriction. 370 In addition, route redistribution (a.k.a. route leaking) has a key 371 problem that was not fully addressed by the existing IP reachability 372 TLVs. [RFC1195] allows a router to advertise prefixes upwards in the 373 level hierarchy. Unfortunately there were no mechanisms defined to 374 advertise prefixes downwards in the level hierarchy. 376 To address these two issues, the proposed extended IP reachability 377 TLV provides for a 32 bit metric and adds one bit to indicate that a 378 prefix has been redistributed 'down' in the hierarchy. 380 The proposed extended IP reachability TLV contains a new data 381 structure, consisting of: 383 4 octets of metric information 385 1 octet of control information, consisting of 387 1 bit of up/down information 389 1 bit indicating the presence of sub-TLVs 391 6 bits of prefix length 393 0-4 octet of IPv4 prefix 395 0-250 optional octets of sub-TLVs, if present consisting of 397 1 octet of length of sub-TLVs 399 0-249 octets of sub-TLVs, where each sub-TLV consists of a 400 sequence of 402 1 octet of sub-type 403 1 octet of length of the value field of the sub-TLV 405 0-247 octets of value 407 This data structure can be replicated within the TLV, without 408 exceeding the maximum length of the TLV. 410 The 6 bits of prefix length can have the values 0-32 and indicate the 411 number of significant bits in the prefix. The prefix is encoded in 412 the minimal number of octets for the given number of significant 413 bits. This implies: 415 +------------------+--------+ 416 | Significant bits | Octets | 417 +------------------+--------+ 418 | 0 | 0 | 419 | | | 420 | 1-8 | 1 | 421 | | | 422 | 9-16 | 2 | 423 | | | 424 | 17-24 | 3 | 425 | | | 426 | 25-32 | 4 | 427 +------------------+--------+ 429 The remaining bits of prefix are transmitted as zero and ignored upon 430 receipt. 432 If a prefix is advertised with a metric larger then MAX_PATH_METRIC 433 (0xFE000000, see paragraph 3.0), this prefix MUST NOT be considered 434 during the normal SPF computation. This allows advertisement of a 435 prefix for purposes other than building the normal IP routing table. 437 4.1. The up/down Bit 439 If routers were allowed to redistribute IP prefixes freely in both 440 directions between level 1 and level 2 without any additional 441 mechanisms, those routers would not be able to determine looping of 442 routing information. A problem occurs when a router learns a prefix 443 via level 2 routing and advertises that prefix down into a level 1 444 area, where another router might pick up the route and advertise the 445 prefix back up into the level 2 backbone. If the original source 446 withdraws the prefix, those two routers might end up having a routing 447 loop between them, where part of the looped path is via level 1 448 routing and the other part of the looped path is via level 2 routing. 449 The solution that [RFC1195] poses is to allow only advertising 450 prefixes upward in the level hierarchy, and to disallow the 451 advertising of prefixes downward in the hierarchy. 453 To prevent this looping of prefixes between levels, a new bit of 454 information is defined in the new extended IP reachability TLV. This 455 bit is called the up/down bit. The up/down bit SHALL be set to 0 456 when a prefix is first injected into IS-IS. If a prefix is 457 advertised from a higher level to a lower level (e.g. level 2 to 458 level 1), the bit MUST be set to 1, indicating that the prefix has 459 traveled down the hierarchy. Prefixes that have the up/down bit set 460 to 1 may only be advertised down the hierarchy, i.e. to lower levels. 462 These semantics apply even if IS-IS is extended in the future to have 463 additional levels. By insuring that prefixes follow only the IS-IS 464 hierarchy, we have insured that the information does not loop, 465 thereby insuring that there are no persistent forwarding loops. 467 If a prefix is advertised from one area to another at the same level, 468 then the up/down bit SHALL be set to 1. This situation can arise 469 when a router implements multiple virtual routers at the same level, 470 but in different areas. 472 The semantics of the up/down bit in the new extended IP reachability 473 TLV are identical to the semantics of the up/down bit defined in 474 [RFC2966]. 476 4.2. Expandability of the Extended IP Reachability TLV with Sub-TLVs 478 The extended IP reachability TLV can hold sub-TLVs that apply to a 479 particular prefix. This allows for easy future extensions. If there 480 are no sub-TLVs associated with a prefix, the bit indicating the 481 presence of sub-TLVs SHALL be set to 0. If this bit is set to 1, the 482 first octet after the prefix will be interpreted as the length of all 483 sub-TLVs associated with this IPv4 prefix. Please note that while 484 the encoding allows for 255 octets of sub-TLVs, the maximum value 485 cannot fit in the overall extended IP reachability TLV. The 486 practical maximum is 255 octets minus the 5-9 octets described above, 487 or 250 octets. 489 This document does not define any sub-TLVs for the extended IP 490 reachability TLV. 492 4.3. The Traffic Engineering Router ID TLV 494 The Traffic Engineering router ID TLV is TLV type 134. 496 The router ID TLV contains the 4-octet router ID of the router 497 originating the LSP. This is useful in several regards: 499 For traffic engineering, it guarantees that we have a single 500 stable address that can always be referenced in a path that will 501 be reachable from multiple hops away, regardless of the state of 502 the node's interfaces. 504 If OSPF is also active in the domain, traffic engineering can 505 compute the mapping between the OSPF and IS-IS topologies. 507 If a router does not implement traffic engineering, it MAY add or 508 omit the Traffic Engineering router ID TLV. If a router implements 509 traffic engineering, it MUST include this TLV in its LSP. This TLV 510 SHOULD not be included more than once in an LSP. 512 If a router advertises the Traffic Engineering router ID TLV in its 513 LSP, and if it advertises prefixes via the Border Gateway Protocol 514 (BGP) with the BGP next hop attribute set to the BGP router ID, the 515 Traffic Engineering router ID SHOULD be the same as the BGP router 516 ID. 518 Implementations MUST NOT inject a /32 prefix for the router ID into 519 their forwarding table because this can lead to forwarding loops when 520 interacting with systems that do not support this TLV. 522 5. IANA Considerations 524 This document makes no new request of IANA. Prior IANA requests for 525 this purpose were coverered as part of [RFC3784]. The text of those 526 requests is reproduced here for completeness and consistency. 528 Note to RFC Editor: this paragraph and the above paragraph may be 529 removed or edited on publication as an RFC. 531 5.1. TLV Codepoint Allocations 533 This document defines the following new IS-IS TLV types, which have 534 been reflected in the ISIS TLV code-point registry: 536 +------+---------------------------------------+-----+-----+-----+ 537 | Type | Description | IIH | LSP | SNP | 538 +------+---------------------------------------+-----+-----+-----+ 539 | 22 | The extended IS reachability TLV | n | y | n | 540 | | | | | | 541 | 134 | The Traffic Engineering router ID TLV | n | y | n | 542 | | | | | | 543 | 135 | The extended IP reachability TLV | n | y | n | 544 +------+---------------------------------------+-----+-----+-----+ 546 5.2. New Registries 548 IANA has created the following new registries. 550 5.2.1. Sub-TLVs for the Extended IS Reachability TLV 552 This registry contains codepoints for Sub-TLVs of TLV 22. The range 553 of values is 0-255. Allocations within the registry require 554 documentation of the proposed use of the allocated value and approval 555 by the Designated Expert assigned by the IESG (see [RFC2434]). 557 Taking into consideration allocations specified in this document, the 558 registry has been initialized as follows: 560 +--------+-------------------------------+ 561 | Type | Description | 562 +--------+-------------------------------+ 563 | 0-2 | unassigned | 564 | | | 565 | 3 | Administrative group (color) | 566 | | | 567 | 4-5 | unassigned | 568 | | | 569 | 6 | IPv4 interface address | 570 | | | 571 | 7 | unassigned | 572 | | | 573 | 8 | IPv4 neighbor address | 574 | | | 575 | 9 | Maximum link bandwidth | 576 | | | 577 | 10 | Reservable link bandwidth | 578 | | | 579 | 11 | Unreserved bandwidth | 580 | | | 581 | 12-17 | unassigned | 582 | | | 583 | 18 | TE Default metric | 584 | | | 585 | 19-254 | unassigned | 586 | | | 587 | 255 | Reserved for future expansion | 588 +--------+-------------------------------+ 590 5.2.2. Sub-TLVs for the Extended IP Reachability TLV 592 This registry contains codepoints for Sub-TLVs of TLV 135. The range 593 of values is 0-255. Allocations within the registry require 594 documentation of the use of the allocated value and approval by the 595 Designated Expert assigned by the IESG (see [RFC2434]). No 596 codepoints are defined in this document. 598 6. Security Considerations 600 This document raises no new security issues for IS-IS. 602 7. Acknowledgements 604 The authors would like to thank Yakov Rekhter and Dave Katz for their 605 comments on this work. This work was funded in part by Procket 606 Networks and Juniper Networks. 608 8. References 610 8.1. Normative References 612 [ISO-10589] 613 ISO, "Intermediate System to Intermediate System Intra- 614 Domain Routeing Exchange Protocol for use in Conjunction 615 with the Protocol for Providing the Connectionless-mode 616 Network Service (ISO 8473)", International Standard 10589: 617 2002, Second Edition, 2002. 619 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 620 Requirement Levels", BCP 14, RFC 2119, March 1997. 622 [RFC2966] Li, T., Przygienda, T., and H. Smit, "Domain-wide Prefix 623 Distribution with Two-Level IS-IS", RFC 2966, 624 October 2000. 626 8.2. Informative References 628 [RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and 629 dual environments", RFC 1195, December 1990. 631 [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an 632 IANA Considerations Section in RFCs", BCP 26, RFC 2434, 633 October 1998. 635 [RFC2702] Awduche, D., Malcolm, J., Agogbua, J., O'Dell, M., and J. 636 McManus, "Requirements for Traffic Engineering Over MPLS", 637 RFC 2702, September 1999. 639 [RFC3784] Smit, H. and T. Li, "Intermediate System to Intermediate 640 System (IS-IS) Extensions for Traffic Engineering (TE)", 641 RFC 3784, June 2004. 643 URIs 645 [1] 647 Authors' Addresses 649 Tony Li 650 Cisco Systems 651 170 W. Tasman Dr. 652 San Jose, California 95134 653 USA 655 Phone: +1 408 525-0931 656 Fax: +1 408 526-4219 657 Email: tli@cisco.com 659 Henk Smit 660 Cisco Systems 661 170 W. Tasman Dr. 662 San Jose, California 95134 663 USA 665 Phone: +31 20 342 3736 666 Email: hsmit@cisco.com 668 Intellectual Property Statement 670 The IETF takes no position regarding the validity or scope of any 671 Intellectual Property Rights or other rights that might be claimed to 672 pertain to the implementation or use of the technology described in 673 this document or the extent to which any license under such rights 674 might or might not be available; nor does it represent that it has 675 made any independent effort to identify any such rights. Information 676 on the procedures with respect to rights in RFC documents can be 677 found in BCP 78 and BCP 79. 679 Copies of IPR disclosures made to the IETF Secretariat and any 680 assurances of licenses to be made available, or the result of an 681 attempt made to obtain a general license or permission for the use of 682 such proprietary rights by implementers or users of this 683 specification can be obtained from the IETF on-line IPR repository at 684 http://www.ietf.org/ipr. 686 The IETF invites any interested party to bring to its attention any 687 copyrights, patents or patent applications, or other proprietary 688 rights that may cover technology that may be required to implement 689 this standard. Please address the information to the IETF at 690 ietf-ipr@ietf.org. 692 Disclaimer of Validity 694 This document and the information contained herein are provided on an 695 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 696 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 697 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 698 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 699 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 700 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 702 Copyright Statement 704 Copyright (C) The Internet Society (2005). This document is subject 705 to the rights, licenses and restrictions contained in BCP 78, and 706 except as set forth therein, the authors retain all their rights. 708 Acknowledgment 710 Funding for the RFC Editor function is currently provided by the 711 Internet Society.