idnits 2.17.1 draft-ietf-isis-iso-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 ** 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 15 longer pages, the longest (page 13) being 76 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 15 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.) == There are 2 instances of lines with non-RFC2606-compliant FQDNs in the document. == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 187 has weird spacing: '...ng Time shoul...' == 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 'MUST not' in this paragraph: (2) The implementation MUST not enable IS-IS on circuits which do not support an MTU at least as large as the originating Buf-ferSize at the appropriate level. -- 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 7441 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 3373 (ref. '4') (Obsoleted by RFC 5303) ** Obsolete normative reference: RFC 2966 (ref. '5') (Obsoleted by RFC 5302) ** Downref: Normative reference to an Informational RFC: RFC 3358 (ref. '6') == Outdated reference: A later version (-26) exists of draft-ietf-isis-wg-mib-12 Summary: 8 errors (**), 0 flaws (~~), 10 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Engineering Task Force J. Parker, Editor 2 Axiowave Networks 4 December 9, 2003 6 Recommendations for Interoperable Networks using IS-IS 7 9 Status of this Memo 11 This document is an Internet-Draft and is in full conformance with 12 all provisions of Section 10 of RFC2026. 14 Internet-Drafts are working documents of the Internet Engineering 15 Task Force (IETF), its areas, and its working groups. Note that 16 other groups may also distribute working documents as Internet- 17 Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six months 20 and may be updated, replaced, or obsoleted by other documents at any 21 time. It is inappropriate to use Internet- Drafts as reference 22 material or to cite them other than as "work in progress." 24 The list of current Internet-Drafts can be accessed at 25 http://www.ietf.org/ietf/1id-abstracts.txt 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html. 30 Copyright Notice Copyright (C) The Internet Society (2003). All 31 Rights Reserved. 33 Internet Draft - 35 Abstract 37 This document discusses a number of differences between the IS-IS 38 protocol as described in ISO 10589 and the protocol as it is deployed 39 today. These differences are discussed as a service to those 40 implementing, testing, and deploying the IS-IS Protocol. A companion 41 document discusses differences between the protocol described in RFC 42 1195 and the protocol as it is deployed today for routing IP traffic. 44 3. Table of Contents 46 1. Introduction......................................... 2 47 2. Acknowledgments...................................... 3 48 3. Constants That Are Variable.......................... 3 49 4. Variables That Are Constant.......................... 5 50 5. Alternative Metrics.................................. 7 51 6. ReceiveLSPBufferSize................................. 7 52 7. Padding Hello PDUs................................... 9 53 8. Zero Checksum........................................ 10 54 9. Purging Corrupted LSPs............................... 11 55 10. Checking System ID in Received point-to-point IIH PDUs 11 56 11. Doppelganger LSPs.................................... 12 57 12. Generating a Complete Set of CSNPs................... 12 58 13. Overload Bit......................................... 13 59 14. Security Considerations.............................. 14 60 15. Normative References................................. 14 61 16. Informative References............................... 14 62 17. Author's Address.................................... 14 63 18. Full Copyright Statement............................. 15 65 1. Introduction 67 In theory, there is no difference between theory and practice. 68 But in practice, there is. 70 Jan L.A. van de Snepscheut 71 Interior Gateway Protocols such as IS-IS are designed to provide 72 timely information about the best routes in a routing domain. The 73 original design of IS-IS, as described in ISO 10589 [1] has proved to 74 be quite durable. However, a number of original design choices have 75 been modified. This document addresses differences between the 76 protocol described in ISO 10589 and the protocol that can be observed 77 on the wire today. A companion document discusses differences between 78 the protocol described in RFC 1195 [2] for routing IP traffic and 79 current practice. 81 Internet Draft - 83 The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT" and "MAY" in 84 this document are to be interpreted as described in RFC 2119 [3]. 86 2. Acknowledgments 88 This document is the work of many people, and is the distillation of 89 over a thousand mail messages. Thanks to Vishwas Manral, who pushed 90 to create such a document. Thanks to Danny McPherson, the original 91 editor, for kicking things off. Thanks to Mike Shand, for his work 92 in creating the protocol, and his uncanny ability to remember what 93 everything is for. Thanks to Micah Bartell and Philip Christian, who 94 showed us how to document difference without displaying discord. 95 Thanks to Les Ginsberg, Neal Castagnoli, Jeff Learman, and Dave Katz, 96 who spent many hours educating the editor. Thanks to Radia Perlman, 97 who is always ready to explain anything. Thanks to Satish Dattatri, 98 who was tenacious in seeing things written up correctly. Thanks to 99 Russ White, whose writing improved the treatment of every topic he 100 touched. Thanks to Shankar Vemulapalli, who read several drafts with 101 close attention. Thanks to Don Goodspeed, for his close reading of 102 the text. Thanks to Aravind Ravikumar, who pointed out that we should 103 check Source ID on point-to-point IIH packets. Thanks to Michael 104 Coyle for identifying the quotation from Jan L.A. van de Snepscheut. 105 Thanks for Alex Zinin's ministrations behind the scenes. Thanks to 106 Tony Li and Tony Przygienda, who kept us on track as the discussions 107 veered into the weeds. And thanks to all those who have contributed, 108 but whose names I have carelessly left from this list. 110 3. Constants That Are Variable 112 Some parameters that were defined as constant in ISO 10589 are 113 modified in practice. These include the following 115 (1) MaxAge - the lifetime of a Link State PDU (LSP) 117 (2) ISISHoldingMultiplier - a parameter used to describe the 118 generation of hello packets 120 (3) ReceiveLSPBufferSize - discussed in a later section 122 3.1 MaxAge 124 Each LSP contains a RemainingLifetime field which is initially set to 125 the MaxAge value on the generating IS. The value stored in this field 126 is decremented to mark the passage of time and the number of times it 127 has been forwarded. When the value of a foreign LSP becomes 0, an IS 129 Internet Draft - 131 initiates a purging process which will flush the LSP from the net- 132 work. This ensures that that corrupted or otherwise invalid LSPs do 133 not remain in the network indefinitely. The rate at which LSPs are 134 regenerated by the originating IS is determined by the value of max- 135 imumLSPGenerationInterval. 137 MaxAge is defined in ISO 10589 as an Architectural constant of 20 138 minutes, and it is recommended that maximumLSPGenerationInterval be 139 set to 15 minutes. These times have proven to be too short in some 140 networks, as they result in a steady flow of LSP updates even when 141 nothing is changing. To reduce the rate of generation, some implemen- 142 tations allow these times to be set by the network operator. 144 The relation between MaxAge and maximumLSPGenerationInterval is dis- 145 cussed in section 7.3.21 of ISO 10589. If MaxAge is smaller than max- 146 imumLSPGenerationInterval, then an LSP will expire before it is 147 replaced. Further, as RemainingLifetime is decremented each time it 148 is forwarded, an LSP far from it's origin appears older and is 149 removed sooner. To make sure that an LSP survives long enough to be 150 replaced, MaxAge should exceed maximumLSPGenerationInterval by at 151 least ZeroAgeLifetime + minimumLSPTransmissionInterval. The first 152 term, ZeroAgeLifetime, is an estimate of how long it takes to flood 153 an LSP through the network. The second term, minimumLSPTransmis- 154 sionInterval, takes into account how long a router might delay before 155 sending an LSP. The original recommendation was that MaxAge be at 156 least 5 minutes larger than maximumLSPGenerationInterval, and that 157 recommendation is still valid today. 159 An implementation MAY use a value of MaxAge that is greater than 1200 160 seconds. MaxAge SHOULD exceed maximumLSPGenerationInterval by at 161 least 300 seconds. An implementation SHOULD NOT use it's value of 162 MaxAge to discard LSPs from peers, as discussed below. 164 An implementation is not required to coordinate the RemainingLifetime 165 it assigns to LSPs to the RemainingLifetime values it accepts, and 166 MUST ignore the following sentence from section 7.3.16.3. of ISO 167 10589. 169 "If the value of Remaining Lifetime [of the received LSP] is 170 greater than MaxAge, the LSP shall be processed as if there 171 were a checksum error." 173 3.2 ISISHoldingMultiplier 175 An IS sends IS to IS Hello Protocol Data Units (IIHs) on a periodic 176 basis over active circuits, allowing other attached routers to moni- 177 tor their aliveness. The IIH includes a two byte field called the 178 Holding Time which defines the time to live of an adjacency. If an IS 180 Internet Draft - 182 does not receive a hello from an adjacent IS within this holding 183 time, the adjacent IS is assumed to be no longer operational, and the 184 adjacency is removed. 186 ISO 10589 defines ISISHoldingMultiplier to be 10, and states that the 187 value of Holding Time should be ISISHoldingMultiplier multiplied by 188 iSISHelloTimer for ordinary systems, and dRISISHelloTimer for a DIS. 189 This implies that the neighbor must lose 10 IIHs before an adjacency 190 times out. 192 In practice, a value of 10 for the ISISHoldingMultiplier has proven 193 to be too large. DECnet PhaseV defined two related values. The vari- 194 able holdingMultiplier, with a default value of 3, was used for 195 point-to-point IIHs, while the variable ISISHoldingMultiplier, with a 196 default value of 10, was used for LAN IIHs. Most implementations 197 today set the default ISISHoldingMultiplier to 3 for both circuit 198 types. 200 Note that adjacent systems may use different values for Holding Time 201 and will form an adjacency with non-symmetric hold times. 203 An implementation MAY allow ISISHoldingMultiplier to be configurable. 204 Values lower than 3 are unstable, and may cause adjacencies to flap. 206 4. Variables That Are Constant 208 Some values that were defined as variables in ISO 10589 do not vary 209 in practice. These include 211 (1) ID Length - the length of the SystemID 213 (2) maximumAreaAddresses 215 (3) Protocol Version 217 4.1 ID Length 219 The ID Length is a field carried in all PDUs. The ID Length defines 220 the length of the System ID, and is allowed to take values from 0 to 221 8. A value of 0 is interpreted to define a length of 6 bytes. As 222 suggested in B.1.1.3 of [1], it is easy to use an Ethernet MAC 223 address to generate a unique 6 byte System ID. Since the SystemID 224 only has significance within the IGP Domain, 6 bytes has proved to be 225 easy to use and ample in practice. There are also new IS-IS Traffic 226 Engineering TLVs which assume a 6 byte System ID. Choices for the ID 227 length other than 6 are difficult to support today. Implementations 228 may interoperate without being able to deal with System IDs of any 230 Internet Draft - 232 length other than 6. 234 An implementation MUST use an ID Length of 6, and MUST check the ID 235 Length defined in the IS-IS PDUs it receives. If a router encounters 236 a PDU with an ID Length different from 0 or 6, section 7.3.15.a.2 237 dictates that it MUST discard the PDU, and SHOULD generate an 238 appropriate notification. ISO 10589 defines the notification 239 iDFieldLengthMismatch, while the IS-IS MIB [7] defines the notifica- 240 tion isisIDLenMismatch. 242 4.2 maximumAreaAddresses 244 The value of maximumAreaAddresses is defined to be an integer between 245 1 and 254, and defines the number of synonymous Area Addresses that 246 can be in use in an L1 area. This value is advertised in the header 247 of each IS-IS PDU. 249 Most deployed networks use one Area Address for an L1 area. When 250 merging or splitting areas, a second address is required for seamless 251 transition. The third area address was originally required to sup- 252 port DECnet PhaseIV addresses as well as OSI addresses during a tran- 253 sition. 255 ISO 10589 requires that all Intermediate Systems in an area or domain 256 use a consistent value for maximumAreaAddresses. Common practice is 257 for an implementation to use the value 3. Therefore an implementation 258 that only supports 3 can expect to interoperate successfully with 259 other conformant systems. 261 ISO 10589 specifies that an advertised value of 0 is treated as 262 equivalent to 3, and that checking the value for consistency may be 263 omitted if an implementation only supports the value 3. 265 An implementation SHOULD use the value 3, and it SHOULD check the 266 value advertised in IS-IS PDUs it receives. If a router receives a 267 PDU with maximumAreaAddresses that is not 0 or 3, it MUST discard the 268 PDU, as described in section 7.3.15.a.3, and it SHOULD generate an 269 appropriate notification. ISO 10589 defines the notification maximu- 270 mAreaAddressMismatch, while the IS-IS MIB [7] defines the notifica- 271 tion isisMaxAreaAddressesMismatch. 273 4.3 Protocol Version 275 IS-IS PDUs include two one-byte fields in the headers: 276 "Version/Protocol ID Extension" and "Version". 278 An implementation SHOULD set both fields to 1, and it SHOULD check 279 the values of these fields in IS-IS PDUs it receives. If a router 281 Internet Draft - 283 receives a PDU with a value other than 1 for either field, it MUST 284 drop the packet, and SHOULD generate the isisVersionSkew notifica- 285 tion. 287 5. Alternative Metrics 289 Section 7.2.2, ISO 10589 describes four metrics: Default Metric, 290 Delay Metric, Expense Metric, and Error Metric. None but the Default 291 Metric are used in deployed networks, and most implementations only 292 consider the Default Metric. In ISO 10589, the most significant bit 293 of the 8 bit metrics was the field S (Supported), used to define if 294 the metric was meaningful. 296 If this IS does not support this metric it shall set bit S to 297 1 to indicate that the metric is unsupported. 299 The Supported bit was always 0 for the Default Metric, which must 300 always be supported. However, RFC 2966 [5] uses this bit in the 301 Default Metric to mark L1 routes that have been leaked from L1 to L2 302 and back down into L1 again. 304 Implementations MUST generate the Default Metric when using narrow 305 metrics, and SHOULD ignore the other three metrics when using narrow 306 metrics. Implementations MUST assume that the Default Metric is sup- 307 ported, even if the S bit is set. RFC 2966 describes restrictions on 308 leaking such routes learned from L1 into L2. 310 6. ReceiveLSPBufferSize 312 Since IS-IS does not allow segmentation of protocol PDUs, Link State 313 PDUs (LSPs) must be propagated without modification on all IS-IS 314 enabled links throughout the area/domain. Thus it is essential to 315 configure a maximum size that all routers can forward, receive, and 316 store. 318 This affects three aspects, which we discuss in turn: 320 (1) The largest LSP we can receive (ReceiveLSPBufferSize) 322 (2) The size of the largest LSP we can generate 323 (originatingL1LSPBufferSize and originatingL2LSPBufferSize) 325 (3) Available Link MTU for supported Circuits (MTU). Note this 326 often differs from the MTU available to IP clients. 328 ISO 10589 defines the architectural constant ReceiveLSPBufferSize 330 Internet Draft - 332 with value 1492 bytes, and two private management parameters, 333 originatingL1LSPBufferSize for level 1 PDUs and 334 originatingL2LSPBufferSize for level 2 PDUs. The originating buffer 335 size parameters define the maximum size of an LSP that a router can 336 generate. ISO 10589 directs the implementor to treat a PDU larger 337 than ReceiveLSPBufferSize as an error. 339 It is crucial that 340 originatingL1LSPBufferSize <= ReceiveLSPBufferSize 341 originatingL2LSPBufferSize <= ReceiveLSPBufferSize 342 and that for all L1 links in the area 343 originatingL1LSPBufferSize <= MTU 344 and for all L2 links in the domain 345 originatingL2LSPBufferSize <= MTU 347 The original thought was that operators could decrease the originat- 348 ing Buffer size when dealing with smaller MTUs, but would not need to 349 increase ReceiveLSPBufferSize beyond 1492. 351 With the definition of new information to be advertised in LSPs, such 352 as the Traffic Engineering TLVs, the limited space of the LSP data- 353 base which may be generated by each router (256 * 1492 bytes at each 354 level) has become an issue. Given that modern networks with MTUs 355 larger than 1492 on all links are not uncommon, one method which can 356 be used to expand the LSP database size is to allow values of 357 ReceiveLSPBufferSize greater than 1492. 359 Allowing ReceiveLSPBUfferSize to become a configurable parameter 360 rather than an architectural constant must be done with care: if any 361 system in the network does not support values larger than 1492 or one 362 or more link MTUs used by IS-IS anywhere in the area/domain is 363 smaller than the largest LSP which may be generated by any router, 364 then full propagation of all LSPs may not be possible, resulting in 365 routing loops and black holes. 367 The steps below are recommended when changing ReceiveLSPBufferSize. 369 (1) Set the ReceiveLSPBufferSize to a consistent value throughout 370 the network. 372 (2) The implementation MUST not enable IS-IS on circuits which do 373 not support an MTU at least as large as the originating Buf- 374 ferSize at the appropriate level. 376 (3) Include an originatingLSPBufferSize TLV when generating LSPs, 377 introduced in section 9.8 of ISO 10589:2002 [1]. 379 (4) When receiving LSPs, check for an originatingLSPBufferSize 381 Internet Draft - 383 TLV, and report the receipt of values larger than the local 384 value of ReceiveLSPBufferSize through the defined Notifica- 385 tions and Alarms. 387 (5) Report the receipt of a PDU larger than the local ReceiveL- 388 SPBufferSize through the defined Notifications and Alarms. 390 (6) Do not discard large PDUs by default. Storing and processing 391 them as normal PDUs may help maintain coherence in a miscon- 392 figured network. 394 Steps 1 and 2 are enough by themselves, but the consequences of 395 mismatch are serious enough and difficult enough to detect, that 396 steps 3-6 are recommended to help track down and correct problems. 398 7. Padding Hello PDUs 400 To prevent the establishment of adjacencies between systems which may 401 not be able to successfully receive and propagate IS-IS PDUs due to 402 inconsistent settings for originatingLSPBufferSize and ReceiveLSPBuf- 403 ferSize, section 8.2.3 of [1] requires padding on point-to-point 404 links. 406 On point-to-point links, the initial IIH is to be padded to the max- 407 imum of 409 (1) Link MTU 411 (2) originatingL1LSPBufferSize if the link is to be used for L1 412 traffic 414 (3) originatingL2LSPBufferSize if the link is to be used for L2 415 traffic 417 In section 6.7.2 e) ISO 10589 assumes 419 Provision that failure to deliver a specific subnetwork SDU 420 will result in the timely disconnection of the subnetwork con- 421 nection in both directions and that this failure will be 422 reported to both systems 424 With this service provided by the link layer, the requirement that 425 only the initial IIH be padded was sufficient to check the con- 426 sistency of the MTU on the two sides. If the PDU was too big to be 427 received, the link would be reset. However, link layer protocols in 428 use on point-to-point circuits today often lack this service, and the 429 initial padded PDU might be silently dropped without resetting the 431 Internet Draft - 433 circuit. Therefore, the requirement that only the initial IIH be 434 padded does not provide the guarantees anticipated in ISO 10589. 436 If an implementation is using padding to detect problems, point-to- 437 point IIH PDUs SHOULD be padded until the sender declares an adja- 438 cency on the link to be in state Up. If the implementation implements 439 RFC 3373 [4], "Three-Way Handshake for IS-IS Point-to-Point Adjacen- 440 cies" then this is when the three-way state is Up: if the implementa- 441 tion use the "classic" algorithm described in ISO 10589, this is when 442 adjacencyState is Up. Transmission of padded IIH PDUs SHOULD be 443 resumed whenever the adjacency is torn down, and SHOULD continue 444 until the sender declares the adjacency to be in state Up again. 446 If an implementation is using padding, and originatingL1LSPBUfferSize 447 or originatingL2LSPBUfferSize is modified, adjacencies SHOULD be 448 brought down and reestablished so the protection provided by padding 449 IIH PDUs is performed consistent with the modified values. 451 Some implementations choose not to pad. Padding does not solve all 452 problems of misconfigured systems. In particular, it does not pro- 453 vide a transitive relation. Assume that A, B, and C all pad IIH 454 PDUs, that A and B can establish an adjacency, and that B and C can 455 establish an adjacency. We still cannot conclude that A and C could 456 establish an adjacency, if they were neighbors. 458 The presence or absence of padding TLVs MUST NOT be one of the accep- 459 tance tests applied to a received IIH regardless of the state of the 460 adjacency. 462 8. Zero Checksum 464 A checksum of 0 is impossible if the checksum is computed according 465 to the rules of ISO 8473 [8]. 467 ISO 10589, section 7.3.14.2(i), states: 469 A Link State PDU received with a zero checksum shall be 470 treated as if the Remaining Lifetime were zero. The age, if 471 not zero, shall be overwritten with zero. 473 That is, ISO 10589 directs the receiver to purge the LSP. This has 474 proved to be disruptive in practice. An implementation SHOULD treat 475 all LSPs with a zero checksum and a non-zero remaining lifetime as if 476 they had as checksum error. Such packets SHOULD be discarded. 478 Internet Draft - 480 9. Purging Corrupted PDUs 482 While ISO 10589 requires in section 7.3.14.2 e) that any LSP received 483 with an invalid PDU checksum should be purged, this has been found to 484 be disruptive. Most implementations today follow the revised specif- 485 ication, and simply drop the LSP. 487 In ISO 10589:2002 [1], Section 7.3.14.2, it states: 489 (e) An Intermediate system receiving a Link State PDU with an 490 incorrect LSP Checksum or with an invalid PDU syntax SHOULD 492 1) generate a corruptedLSPReceived circuit event, 494 2) discard the PDU. 496 10. Checking System ID in Received point-to-point IIH PDUs 498 In section 8.2.4.2, ISO 10589 does not explicitly require comparison 499 of the source ID of a received IIH with the neighbourSystemID associ- 500 ated with an existing adjacency on a point-to-point link. 502 To address this omission, implementations receiving an IIH PDU on a 503 point to point circuit with an established adjacency SHOULD check the 504 Source ID field and compare that with the neighbourSystemID of the 505 adjacency. If these differ, an implementation SHOULD delete the adja- 506 cency. 508 Given that IIH PDUs as specified in ISO 10589 do not include a check- 509 sum, it is possible that a corrupted IIH may falsely indicate a 510 change in the neighbor's System ID. The required subnetwork guaran- 511 tees for point-to-point links, as described in 6.7.2 g) 1) assume 512 that undetected corrupted PDUs are very rare (one event per four 513 years). A link with frequent errors that produce corrupted data could 514 lead to flapping an adjacency. Inclusion of an optional checksum TLV 515 as specified in "Optional Checksums in IS-IS" [6], may be used to 516 detect such corruption. Hello packets carrying this TLV that are 517 corrupted PDUs SHOULD be silently dropped, rather than dropping the 518 adjacency. 520 Some implementations have chosen to discard received IIHs where the 521 source ID differs from the neighbourSystemID. This may prevent need- 522 less flapping caused by undetected PDU corruption. If an actual 523 administrative change to the neighbor's system ID has occurred, using 524 this strategy may require the existing adjacency to timeout before an 525 adjacency with the new neighbor can be established. This is 526 expedited if the neighbor resets the circuit as anticipated in 10589 528 Internet Draft - 530 after a System ID change, or resets the 3-way adjacency state, as 531 anticipated in RFC 3373. 533 11. Doppelganger LSPs 535 When an Intermediate System shuts down, it may leave old LSPs in the 536 network. In the normal course of events, a rebooting system flushes 537 out these old LSPs by reissuing those fragments with a higher 538 sequence number, or by purging fragments that it is not currently 539 generating. 541 In the case where a received LSP or SNP entry and an LSP in the local 542 database have the same LSP ID, same sequence number, non-zero remain- 543 ing lifetimes, but different non-zero checksums, the rules defined in 544 [1] cannot determine which of the two is "newer". In this case, an 545 implementation may opt to perform an additional test as a tie breaker 546 by comparing the checksums. Implementations that elect to use this 547 method MUST consider the LSP/SNP entry with the higher checksum as 548 newer. When comparing the checksums the checksum field is treated as 549 a 16 bit unsigned integer in network byte order (i.e., most signifi- 550 cant byte first). 552 The choice of higher checksum, rather than lower, while arbitrary, 553 aligns with existing implementations and ensures compatibility. 555 Note that a purged LSP (i.e. an LSP with remaining lifetime set to 0) 556 is always considered newer than a non-purged copy of the same LSP. 558 12. Generating a Complete Set of CSNPs 560 There are a number of cases in which a complete set of CSNPs must be 561 generated. The DIS on a LAN, two IS's peering over a P2P link, and 562 an IS helping another IS perform graceful restart must generate a 563 complete set of CSNPs to assure consistent LSP Databases throughout. 564 Section 7.3.15.3 of [1] defines a complete set of CSNPs to be: 566 "A complete set of CSNPs is a set whose Start LSPID and End 567 LSPID ranges cover the complete possible range of LSPIDs. 568 (i.e. there is no possible LSPID value which does not appear 569 within the range of one of the CSNPs in the set). " 571 Strict adherence to this definition is required to ensure the relia- 572 bility of the update process. Deviation can lead to subtle and hard 573 to detect defects. It is not sufficient to send a set of CSNPs which 574 merely cover the range of LSPIDs which are in the local database. The 575 set of CSNPs must cover the complete possible range of LSPIDs. 577 Internet Draft - 579 Consider the following example: 581 If the current Level 1 LSP database on a router consists of the fol- 582 lowing non pseudo-node LSPs: 584 From system 1111.1111.1111 LSPs numbered 0-89(59H) 585 From system 2222.2222.2222 LSPs numbered 0-89(59H) 587 If the maximum size of a CSNP is 1492 bytes, then 90 CSNP entries can 588 fit into a single CSNP PDU. The following set of CSNP start/end 589 LSPIDs constitute a correctly formatted complete set: 591 Start LSPID End LSPID 592 0000.0000.0000.00-00 1111.1111.1111.00-59 593 1111.1111.1111.00-5A FFFF.FFFF.FFFF.FF-FF 595 The following are examples of incomplete sets of CSNPS: 597 Start LSPID End LSPID 598 0000.0000.0000.00-00 1111.1111.1111.00-59 599 1111.1111.1111.00-5A 2222.2222.2222.00-59 601 The sequence above has a gap after the second entry. 603 Start LSPID End LSPID 604 0000.0000.0000.00-00 1111.1111.1111.00-59 605 2222.2222.2222.00-00 FFFF.FFFF.FFFF.FF-FF 607 The sequence above has a gap between the first and second entry. 609 Although it is legal to send a CSNP which contains no actual LSP 610 entry TLVs, it should never be necessary to do so in order to conform 611 to the specification. 613 13. Overload Bit 615 To deal with transient problems that prevent an IS from storing all 616 the LSPs it receives, ISO 10589 defines an LSP Database Overload con- 617 dition in section 7.3.19. When an IS is in Database Overload condi- 618 tion, it sets a flag called the Overload Bit in the non-pseudonode 619 LSP number Zero that it generates. Section 7.2.8.1 of ISO 10589 620 instructs other systems not to use the overloaded IS as a transit 621 router. Since the overloaded IS does not have complete information, 622 it may not be able to compute the right routes, and routing loops 623 could develop. 625 An overloaded router might become the DIS. An implementation SHOULD 627 Internet Draft - 629 not set the Overload bit in PseudoNode LSPs that it generates, and 630 Overload bits seen in PseudoNode LSPs SHOULD be ignored. 632 14. Security Considerations 634 The clarifications in this document do not raise any new security 635 concerns, as there is no change in the underlying protocol described 636 in ISO 10589 [1]. 638 15. Normative References 640 [1] ISO, "Intermediate system to Intermediate system routeing informa- 641 tion exchange protocol for use in conjunction with the Protocol for 642 providing the Connectionless-mode Network Service (ISO 8473)," 643 ISO/IEC 10589:2002. 645 [2] Callon, R., "OSI IS-IS for IP and Dual Environment," RFC 1195, 646 December 1990. 648 [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement 649 Levels", BCP 14, RFC 2119, March 1997. 651 [4] Katz, D. and Saluja, R., " Three-Way Handshake for Intermediate 652 System to Intermediate System (IS-IS) Point-to-Point Adjacencies" 653 RFC 3373, September 2002. 655 [5] Li, T., Przygienda, T., "Domain-wide Prefix Distribution with Two- 656 Level IS-IS", RFC 2966, October 2000. 658 [6] Przygienda, T., "Optional Checksums in Intermediate System to 659 Intermediate System (ISIS)", RFC 3358, August 2002. 661 16. Informative References 663 [7] Parker, J., "Management Information Base for IS-IS", draft-ietf- 664 isis-wg-mib-12.txt, April 2003. 666 [8] ITU, "Information technology - Protocol for providing the 667 connectionless-mode network service", ISO/IEC 8473-1, 1998 669 Internet Draft - 671 17. Author's Address 673 Jeff Parker 674 Axiowave Networks 675 200 Nickerson Road 676 Marlborough, Mass 01752 677 USA 678 e-mail: jparker@axiowave.com 680 18. Full Copyright Statement 682 Copyright (C) The Internet Society (2003). All Rights Reserved. 684 This document and translations of it may be copied and furnished to 685 others, and derivative works that comment on or otherwise explain it 686 or assist in its implementation may be prepared, copied, published 687 and distributed, in whole or in part, without restriction of any 688 kind, provided that the above copyright notice and this paragraph are 689 included on all such copies and derivative works. However, this 690 document itself may not be modified in any way, such as by removing 691 the copyright notice or references to the Internet Society or other 692 Internet organizations, except as needed for the purpose of develop- 693 ing Internet standards in which case the procedures for copyrights 694 defined in the Internet Standards process must be followed, or as 695 required to translate it into languages other than English. 697 The limited permissions granted above are perpetual and will not be 698 revoked by the Internet Society or its successors or assigns. 700 This document and the information contained herein is provided on an 701 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 702 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 703 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 704 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MER- 705 CHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE."