idnits 2.17.1 draft-ietf-isis-ip-interoperable-02.txt: 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 document type: Expected "INTERNET-DRAFT" in the upper left hand corner of the first 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 10 longer pages, the longest (page 2) being 60 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 11 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.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). == 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: An implementation SHOULD not set the Overload bit in PseudoNode LSPs that it generates, and Overload bits seen in PseudoNode LSPs SHOULD be ignored. This is also discussed in the companion document on ISO interoperability. -- 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 (December 9, 2003) is 7437 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. '1' ** Obsolete normative reference: RFC 3567 (ref. '4') (Obsoleted by RFC 5304) ** Downref: Normative reference to an Informational draft: draft-ietf-isis-traffic (ref. '5') ** Downref: Normative reference to an Informational RFC: RFC 3277 (ref. '6') Summary: 7 errors (**), 0 flaws (~~), 6 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force J. Parker, Editor 3 Axiowave Networks 5 December 9, 2003 7 Recommendations for Interoperable IP Networks using IS-IS 8 10 Status of this Memo 12 This document is an Internet-Draft and is in full conformance with 13 all provisions of Section 10 of RFC2026. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet- 18 Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet- Drafts as reference 23 material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 Copyright Notice Copyright (C) The Internet Society (2003). All 32 Rights Reserved. 34 Abstract 36 This document discusses a number of differences between the 37 IS-IS protocol used to route IP traffic as described in RFC 38 1195 and the protocol as it is deployed today. These 39 differences are discussed as a service to those implementing, 40 testing, and deploying the IS-IS Protocol to route IP traffic. 41 A companion document describes the differences between the 42 protocol described in ISO 10589 and current practice. 44 Table of Contents 46 1. Introduction......................................... 2 47 2. Acknowledgments...................................... 3 48 3. Unused Features...................................... 3 49 4. Overload Bit......................................... 4 50 5. Migration from Narrow Metrics to Wide................ 5 51 6. Intermediate System Hello (ISH) PDU.................. 7 52 7. Attached Bit......................................... 8 53 8. Default Route........................................ 8 54 9. Non-homogeneous Protocol Networks.................... 9 55 10. Adjacency Creation and IP Interface Addressing....... 9 56 11. Security Considerations............................. 10 57 12. Normative References................................. 10 58 13. Informative References............................... 11 59 14. Author's Address.................................... 11 60 15. Full Copyright Statement............................. 11 62 1. Overview 64 Interior Gateway Protocols such as IS-IS are designed to provide 65 timely information about the best routes in a routing domain. The 66 original design of IS-IS, as described in ISO 10589 [1] has proved to 67 be quite durable. However, a number of original design choices have 68 been modified. This document describes some of the differences 69 between the protocol as described in RFC 1195 [2] and the protocol 70 that can be observed on the wire today. A companion document 71 describes the differences between the protocol described in ISO 10589 72 and current practice. 74 The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT" and "MAY" in 75 this document are to be interpreted as described in RFC 2119 [3]. 77 2. Acknowledgments 79 This document is the work of many people, and is the distillation of 80 over a thousand mail messages. Thanks to Vishwas Manral, who pushed 81 to create such a document. Thanks to Danny McPherson, the original 82 editor, for kicking things off. Thanks to Mike Shand, for his work 83 in creating the protocol, and his uncanny ability to remember what 84 everything is for. Thanks to Micah Bartell and Philip Christian, who 85 showed us how to document difference without displaying discord. 86 Thanks to Les Ginsberg, Neal Castagnoli, Jeff Learman, and Dave Katz, 87 who spent many hours educating the editor. Thanks to Radia Perlman, 88 who is always ready to explain anything. Thanks to Satish Dattatri, 89 who was tenacious in seeing things written up correctly, and to Bryan 90 Boulton for his work on the IP adjacency issue. Thanks to Russ 91 White, whose writing improved the treatment of every topic he 92 touched. Thanks to Shankar Vemulapalli, who read several drafts with 93 close attention. Thanks to Don Goodspeed, for his close reading of 94 the text. Thanks to Michael Coyle for identifying the quotation from 95 Jan L.A. van de Snepscheut. Thanks for Alex Zinin's ministrations 96 behind the scenes. Thanks to Tony Li and Tony Przygienda, who kept 97 us on track as the discussions veered into the weeds. And thanks to 98 all those who have contributed, but whose names I have carelessly 99 left from this list. 101 3. Unused Features 103 Some features defined in RFC 1195 are not in current use. 105 3.1 Inter-Domain Routing Protocol Information TLV, Code 131 107 RFC 1195 defines an Inter-Domain Routing Protocol Information TLV, 108 with code 131, designed to convey information transparently between 109 boundary routers. TLV 131 is not used, and MUST be ignored if 110 received. 112 3.2 Authentication TLV, Code 133 114 RFC 1195 defines an authentication TLV, code 133, which contains 115 information used to authenticate the PDU. This TLV has been replaced 116 by TLV 10, described in "IS-IS Cryptographic Authentication" [4]. 117 TLV 133 is not used, and MUST be ignored. 119 4. Overload Bit 121 To deal with transient problems that prevent an IS from storing all 122 the LSPs it receives, ISO 10589 defines an LSP Database Overload 123 condition in section 7.3.19. When an IS is in Database Overload 124 condition, it sets a flag called the Overload Bit in the non- 125 pseudonode LSP number Zero that it generates. Section 7.2.8.1 of ISO 126 10589 instructs other systems not to use the overloaded IS as a 127 transit router. Since the overloaded IS does not have complete 128 information, it may not be able to compute the right routes, and 129 routing loops could develop. However, an overloaded router may be 130 used to reach End Systems directly attached to the router, as it may 131 provide the only path to an End System. 133 The ability to signal reduced knowledge is so useful that the meaning 134 of this flag has been overloaded. In a Service Provider's network, 135 when a router running BGP and IS-IS reboots, BGP might take more time 136 to converge than IS-IS. Thus the router may drop traffic for 137 destinations not yet learned via BGP. It is convenient to set the 138 Overload Bit until BGP has converged, as described in "Intermediate 139 System to Intermediate System (IS-IS) Transient Blackhole Avoidance" 140 [6]. 142 An implementation SHOULD use the Overload Bit to signal that it is 143 not ready to accept transit traffic. 145 An implementation SHOULD not set the Overload bit in PseudoNode LSPs 146 that it generates, and Overload bits seen in PseudoNode LSPs SHOULD 147 be ignored. This is also discussed in the companion document on ISO 148 interoperability. 150 RFC 1195 makes clear when describing the SPF algorithm for IP routers 151 in section C.1.4 that directly connected IP subnetworks are reachable 152 when an IS is overloaded. 154 Note that the End Systems neighbors of the system P includes 155 IP reachable address entries included in the LSPs from system 156 P. 158 When processing LSPs received from a router which has the Overload 159 bit set in LSP number Zero, the receiving router SHOULD treat all IP 160 reachability advertisements as directly connected and use them in its 161 SPF computation. 163 Since the IP prefixes that an overloaded router announces will be 164 treated as directly attached, an overloaded router SHOULD take care 165 in selecting which routes to advertise in the LSPs it generates. 167 5. Migration from Narrow Metrics to Wide 169 The IS-Neighbors TLV (TLV 2) as defined in ISO 10589 and the IP 170 Reachability TLV (TLV 128/TLV 130) as defined in RFC 1195 provide a 6 171 bit metric for the default link metric to the listed neighbor. This 172 metric has proved too limited. The Extended IS-Neighbors TLV (TLV 173 22) and the Extended IP Reachability TLV (TLV 135) are defined in 174 "IS-IS extensions for Traffic Engineering" [5]. The Extended IS- 175 Neighbors TLV (TLV 22) defines a 24 bit metric, and the Extended IP 176 Reachability TLV (TLV 135) defines a 32 bit metric for IP Networks 177 and Hosts. 179 If not all devices in the IS-IS domain support wide metrics, narrow 180 metrics MUST continue to be used. Once all devices in the network are 181 able to support the new TLVs containing wide metrics, the network can 182 be migrated to the new metric style, though care must be taken to 183 avoid routing loops. 185 We make the following assumptions about the implementation: 187 (1) Each system can generate and understand both narrow and 188 wide metrics. 190 (2) The implementation can run the SPF algorithm on an LSP DB 191 with instances of both metric styles. 193 (3) If there are two metric styles for a link or IP prefix, 194 it will pick one of them as the true cost for the link. 196 To compare the different variants of the narrow metric with wide 197 metrics, we need an algorithm that translates External and Internal 198 narrow metrics into a common integer range. Since we have different 199 computations for the L1 and L2 routes, we only need to map metrics 200 from a single level. 202 In RFC 1195 section 3.10.2, item 2c) states that The IP prefixes 203 located in "IP External Reachability" with internal-metric and IP 204 prefixes located in "IP Internal Reachability" with internal-metric 205 have the same preference. As defined in "Domain-wide Prefix Distri- 206 bution with Two-Level IS-IS", the Most Significant Bit on an L1 207 metric tells us if the route has been leaked down, but does not 208 change the distance. Thus we will ignore the MSBit. 210 We interpret the default metric as an 7 bit quantity. Metrics with 211 the external bit set are interpreted as metrics in the range 212 [64..127]. Metrics with the external bit clear are interpreted as 213 metrics in the range [0..63]. 215 5.1 Transition Algorithm 217 To facilitate a smooth transition between the use of narrow metrics 218 exclusively to the use of wide metrics exclusively, the following 219 steps must be taken, in the order below. 221 (1) All routers advertise Narrow Metrics as defined in ISO 10589, 222 and consider narrow metrics only in their SPF computation. 224 (2) Each system is configured in turn to send wide metrics as well 225 as narrow metrics. The two metrics for the same link or IP 226 prefix SHOULD agree. 228 (3) When all systems are advertising wide metrics, make any 229 changes necessary on each system to consider Wide Metrics dur- 230 ing the SPF, and change MaxPathMetric to 0xFE000000. 232 (4) Each system is configured in turn to stop advertising narrow 233 metrics. 235 (5) When the network is only using wide metrics, metrics on indi- 236 vidual links may be rescaled to take advantage of the larger 237 metric. 239 5.2 Dealing with Non-Equal Metrics 241 The algorithm above assumes that the metrics are equal, and thus 242 needs to make no assumption about which metric the SPF algorithm 243 uses. This section describes the changes that should be made to the 244 SPF algorithm when both Narrow and Wide metric styles should be con- 245 sidered. Using a common algorithm allows different implementations to 246 compute the same distances independently, even if the wide and narrow 247 metrics do not agree. 249 The standard SPF algorithm proceeds by comparing sums of link costs 250 to obtain a minimal cost path. During transition, there will be more 251 than one description of the same links. We resolve this by selecting 252 the minimum metric for each link. This may give us a path with some 253 links chosen due to a wide metric and some links chosen due to a nar- 254 row metric. 256 The description below is more complex than the implementation needs 257 to be: the implementation may simply select the minimal cost neighbor 258 in TENT, discarding paths to destinations we have already reached, as 259 described in ISO 10589. 261 The variables MaxPathMetric and MaxLinkMetric SHOULD retain the 262 values defined in Table 2 of section 8 of ISO 10589. 264 In C.2.5 Step 0 of the description of the SPF algorithm, section b) 266 d(N) = cost of the parent circuit of the adjacency N 268 If multiple styles of metric for the link are defined, the 269 cost will be the minimum available cost for the circuit. 271 In C.2.5 Step 0 of the description of the SPF algorithm, section i) 273 d(N) = metric of the circuit 275 If multiple styles of metric for the link are defined, the 276 cost will be the minimum available cost for the circuit. 278 In C.2.6 Step 1 of the description of the SPF algorithm, section a) 280 dist(P,N) = d(P) + metric(P,N) 282 If multiple styles of metric for the neighbor are defined, the 283 cost will be the minimum available cost for the circuit. 285 6. Intermediate System Hello (ISH) PDU 287 The original intent of RFC 1195 was to provide a routing protocol 288 capable of handling both CLNS and IPv4 reachability information. To 289 allow CLNS Endstations (ES) to know that they are attached to a 290 router, Intermediate Systems are required to send Intermediate System 291 Hello PDUs (ISH) for End Stations when a point-to-point circuit comes 292 up. Furthermore, an IS is not allowed to send Intermediate System to 293 Intermediate System Hello PDUs (IIH) before receiving an ISH from a 294 peer. This reduces routing protocol traffic on links with a single 295 IS. 297 For this reason section 5.1 RFC 1195 states: 299 "On point-to-point links, the exchange of ISO 9542 ISHs 300 (intermediate system Hellos) is used to initialize the link, 301 and to allow each router to know if there is a router on the 302 other end of the link, before IS-IS Hellos are exchanged. All 303 routers implementing IS-IS (whether IP-only, OSI-only, or 304 dual), if they have any interfaces on point-to-point links, 305 must therefore be able to transmit ISO 9542 ISHs on their 306 point-to-point links." 308 Section 5.1 RFC 1195 reinforces the need to comply with section 8.2.4 309 of ISO 10589. However, in an IP Only environment, the original need 310 for the ISH PDU is not present. 312 A multi-protocol IS that supports the attachment of CLNS ESs over 313 Point to Point circuits must act in accordance with section 8.2.2 ISO 314 10589 when CLNS functionality is enabled. 316 An IP only implementation SHOULD issue an ISH PDU as described in 317 section 8.2.3 of ISO 10589. This is to inter-operate with implemen- 318 tations which require an ISH to initiate the formation of an IS-IS 319 adjacency. 321 An IP Only implementation may issue an IIH PDU when a point to point 322 circuit transitions into an "Up" state to initiate the formation of 323 an IS-IS adjacency, without sending an ISH PDU. However, this may 324 not inter-operate with implementations which require an ISH for adja- 325 cency formation. 327 An IS may issue an IIH PDU in response to the receipt of an IIH PDU 328 in accordance with section 8.2.5.2 ISO 10589, even though it has not 329 received an ISH PDU. 331 7. The Attached Bit 333 In section 7.2.9.2 of ISO 10589, an algorithm is described to deter- 334 mining when the attachedFlag should be set on an intermediate system. 335 Some implementations also allow the attachedFlag to be set on Inter- 336 mediate Systems routing IP traffic when there is a default route in 337 the local routing table, or when some other state is reached that 338 implies a connection to the rest of the network. 340 8. Default Route 342 RFC 1195 states in section 1.3: 344 Default routes are permitted only at level 2 as external 345 routes (i.e., included in the "IP External Reachability Infor- 346 mation" field, as explained in sections 3 and 5). Default 347 routes are not permitted at level 1. 349 Because of the utility of the default route when dealing with other 350 routing protocols and the ability to influence the exit point from an 351 area, an implementation MAY generate default routes in Level 1. 353 9. Non-homogeneous Protocol Networks 355 RFC 1195 assumes that every deployment of IS-IS routers will sup- 356 port a homogeneous set of protocols. It anticipates OSI only, IP 357 only, or dual OSI and IP routers. While it allows mixed areas with, 358 for example, both pure IP and Dual IP and OSI routers, it allows only 359 IP traffic in such domains, and OSI traffic only when pure OSI and 360 Dual IP and OSI routers are present. Thus it provides only lowest 361 common denominator routing. 363 RFC 1195 also requires the inclusion of the Protocol Supported TLV 364 with code 129 in IIH and ISH PDUs and in LSP number Zero. IP capable 365 routers MUST generate a Protocol Supported TLV, and MUST include the 366 IP protocol as a supported protocol. A router that does not include 367 the Protocols Supported TLV may be assumed to be a pure OSI router 368 and can be interpreted as implicitly "advertising" support for the 369 OSI protocol. 371 The requirements of RFC 1195 are ample if networks adhere to this 372 restriction. However, the behavior of mixed networks that do not fol- 373 low these guidelines is not well defined. 375 The ITU-T requires that SONET/SDH equipment running the IS-IS proto- 376 col must not form an adjacency with a neighbour unless they share at 377 least one network layer protocol in common. Unless this feature is 378 present in every IS in the SONET or SDH DCN network the network may 379 not function correctly. Implementors MAY include this feature if they 380 wish to ensure interoperability with SONET and SDH DCN networks. 382 Definition of an interoperable strategy for resolving the problems 383 that arise in non-homogeneous protocol networks remains incomplete. 384 Members of the ITU are actively working on a proposal: see "Architec- 385 ture and Specification of Data Communication Network", [7]. 387 10. Adjacency Creation and IP Interface Addressing 389 RFC 1195 states that adjacencies are formed without regard to IP 390 interface addressing. However, many current implementations refuse 391 adjacencies based on interface addresses and related issues. 393 In section 4.2, RFC 1195 requires routers with IP interface addresses 394 to advertise the addresses in an IP Interface Address TLV (132) car- 395 ried in IIH PDUs. Some implementations will not interoperate with a 396 neighbor router that does not include the IP Interface Address TLV. 397 Further, some implementations will not form an adjacency on broadcast 398 interfaces with a peer who does not share an interface address in 399 some common IP subnetwork. 401 If a LAN contains a mixture of implementations, some that form adja- 402 cencies with all neighbors and some that do not, care must be taken 403 when assigning IP addresses. If not all routers in a LAN are on the 404 same IP subnet, it is possible that DIS election may fail, leading to 405 the election of multiple DISs on a LAN, or no DIS at all. Even if DIS 406 election succeeds, black holes can result because the IS-IS LAN tran- 407 sitivity requirements of section 6.7.3 ISO 10589 are not met. 409 Unnumbered point to point links do not have IP interface addresses, 410 though they may have other IP addresses assigned to the routers. The 411 IP address assigned to two routers that are neighbors on an unnum- 412 bered point to point link do not need to be related. However, some 413 implementations will not form an adjacency on numbered point to point 414 links if the interface addresses of each endpoint are not in the same 415 IP subnetwork. This means that care must be taken in assigning IP 416 interface addresses in all networks. 418 For an implementation to interoperate in a such mixed environment, it 419 MUST include an IP Interface address (TLV 132) in its IIH PDUs. The 420 network administrator should ensure that there is a common IP subnet 421 assigned to links with numbered interfaces, and that all routers on 422 each link have a IP Interface Addresses belonging to the assigned 423 subnet. 425 11. Security Considerations 427 The clarifications in this document do not raise any new security 428 concerns, as there is no change in the underlying protocol described 429 in ISO 10589 [1] and RFC 1195 [2]. 431 The document does make clear that TLV 133 has been deprecated and 432 replaced with TLV 10. 434 12. Normative References 436 [1] ISO, "Intermediate system to Intermediate system routeing informa- 437 tion exchange protocol for use in conjunction with the Protocol for 438 providing the Connectionless-mode Network Service (ISO 8473)," 439 ISO/IEC 10589:2002. 441 [2] Callon, R., "OSI IS-IS for IP and Dual Environment," RFC 1195, 442 December 1990. 444 [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement 445 Levels", BCP 14, RFC 2119, March 1997. 447 [4] Li, T., Atkinson, R. J., "IS-IS Cryptographic Authentication", RFC 448 3567 July 2003. 450 [5] Li, T., Smit, H., "IS-IS extensions for Traffic Engineering", 451 draft-ietf-isis-traffic-05.txt, August 2003. 453 [6] August 2001. McPherson, D., "Intermediate System to Intermediate 454 System (IS-IS) Transient Blackhole Avoidance", RFC 3277, April 455 2002. 457 13. Informative References 459 [7] ITU, "Architecture and Specification of Data Communication Net- 460 work", ITU-T Recommendation G.7712/Y.1703, November 2001 462 14. Author's Address 464 Jeff Parker 465 Axiowave Networks 466 200 Nickerson Road 467 Marlborough, Mass 01752 468 USA 469 e-mail: jparker@axiowave.com 471 15. Full Copyright Statement 473 Copyright (C) The Internet Society (2003). All Rights Reserved. 475 This document and translations of it may be copied and furnished to 476 others, and derivative works that comment on or otherwise explain it 477 or assist in its implementation may be prepared, copied, published 478 and distributed, in whole or in part, without restriction of any 479 kind, provided that the above copyright notice and this paragraph are 480 included on all such copies and derivative works. However, this 481 document itself may not be modified in any way, such as by removing 482 the copyright notice or references to the Internet Society or other 483 Internet organizations, except as needed for the purpose of develop- 484 ing Internet standards in which case the procedures for copyrights 485 defined in the Internet Standards process must be followed, or as 486 required to translate it into languages other than English. 488 The limited permissions granted above are perpetual and will not be 489 revoked by the Internet Society or its successors or assigns. 491 This document and the information contained herein is provided on an 492 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 493 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 494 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 495 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MER- 496 CHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE."