idnits 2.17.1 draft-ietf-isis-iso-interoperable-00.txt: ** The Abstract section seems to be numbered Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** 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 13 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 14 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The abstract seems to contain references ([3], [1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 152: '...n implementation MAY use a value of Ma...' RFC 2119 keyword, line 153: '...seconds. MaxAge SHOULD exceed maximum...' RFC 2119 keyword, line 154: '...n implementation SHOULD NOT use it's v...' RFC 2119 keyword, line 159: '... MUST ignore the following sentence ...' RFC 2119 keyword, line 193: '...n implementation MAY allow ISISHolding...' (24 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 177 has weird spacing: '...ng Time shoul...' == 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.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Missing reference section? '1' on line 538 looks like a reference -- Missing reference section? '3' on line 548 looks like a reference -- Missing reference section? '5' on line 555 looks like a reference -- Missing reference section? '6' on line 558 looks like a reference -- Missing reference section? '2' on line 543 looks like a reference -- Missing reference section? '4' on line 551 looks like a reference -- Missing reference section? '8' on line 564 looks like a reference -- Missing reference section? '7' on line 561 looks like a reference Summary: 8 errors (**), 0 flaws (~~), 6 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force J. Parker, Editor 3 INTERNET DRAFT Axiowave Networks 4 Expiration Date: April 2003 6 Nov. 1, 2002 8 Recommendations for Interoperable Networks using IS-IS 9 11 1. Status of this Memo 13 This document is an Internet-Draft and is in full conformance with 14 all provisions of Section 10 of RFC2026. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet- Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 Copyright Notice Copyright (C) The Internet Society (2000). All 33 Rights Reserved. 35 2. Abstract 37 In theory, there is no difference between theory and practice. 38 But in practice, there is. 40 Jan L.A. van de Snepscheut 42 This document discusses a number of differences between the IS-IS 43 protocol as described in ISO 10589 [1] the protocol as it is deployed 44 today. These differences are discussed as a service to those 45 implementing, testing, and deploying the IS-IS Protocol. A companion 46 document discusses differences between the protocol described in RFC 47 1195 [3] for routing IP traffic. 49 3. Table of Contents 51 1. Status of this Memo.................................. 1 52 2. Abstract............................................. 2 53 3. Table of Contents.................................... 2 54 4. Overview............................................. 2 55 5. Acknowledgments...................................... 3 56 6. Constants That Are Variable.......................... 3 57 7. Variables That Are Constant.......................... 5 58 8. Alternative Metrics.................................. 6 59 9. ReceiveLSPBufferSize................................. 7 60 10. Padding Hello PDUs................................... 9 61 11. Zero Checksum........................................ 10 62 12. Purging Corrupted LSPs............................... 10 63 13. Checking System ID in Received point-to-point IIH PDUs 11 64 14. Doppelganger LSPs.................................... 12 65 15. Security Implications................................ 12 66 16. References........................................... 12 67 17. Author's Address.................................... 13 68 18. Full Copyright Statement............................. 13 70 4. Overview 72 Interior Gateway Protocols such as IS-IS are designed to provide 73 timely information about the best routes in a routing domain. The 74 original design of IS-IS, as described in ISO 10589 [1] has proved to 75 be quite durable. However, a number of original design choices have 76 been modified. This document addresses differences between the 77 protocol described in ISO 10589 and the protocol that can be observed 78 on the wire today. A companion document discusses differences between 79 the protocol described in RFC 1195 [3] for routing IP traffic and 80 current practice. 82 5. Acknowledgments 84 This document is the work of many people, and is the distilation of 85 over a thousand mail messages. Thanks to Vishwas Manral, who pushed 86 to create such a document. Thanks to Danny McPherson, the original 87 editor, for kicking things off. Thanks to Mike Shand, for his work 88 in creating the protocol, and his uncanny ability to remember what 89 everything is for. Thanks to Micah Bartell and Philip Christian, who 90 showed us how to document difference without displaying discord. 91 Thanks to Les Ginsberg, Neal Castagnoli, Jeff Learman, and Dave Katz, 92 who spent many hours educating the editor. Thanks to Radia Perlman, 93 who is always ready to explain anything. Thanks to Satish Dattatri, 94 who was tenacious in seeing things written up correctly. Thanks to 95 Russ White, whose writing improved the treatment of every topic he 96 touched. Thanks to Shankar Vemulapalli, who read several drafts with 97 close attention. Thanks to Don Goodspeed, for his close reading of 98 the text. Thanks to Aravind Ravikumar, who pointed out that we should 99 check Source ID on point-to-point IIH packets. Thanks to Michael 100 Coyle for identifying the quotation from Jan L.A. van de Snepscheut. 101 Thanks for Alex Zinin's ministrations behind the scenes. Thanks to 102 Tony Li and Tony Przygienda, who kept us on track as the discussions 103 veered into the weeds. And thanks to all those who have contributed, 104 but whose names I have carelessly left from this list. 106 6. Constants That Are Variable 108 Some parameters that were defined as constant in ISO 10589 are 109 modified in practice. These include the following 111 (1) MaxAge - the lifetime of a Link State PDU (LSP) 113 (2) ISISHoldingMultiplier - a parameter used to describe the 114 generation of hello packets 116 (3) ReceiveLSPBufferSize - discussed in a later section 118 6.1 MaxAge 120 Each LSP contains a RemainingLifetime field which is initially set to 121 the MaxAge value on the generating IS. The value stored in this field 122 is decremented to mark the passage of time and the number of times it 123 has been forwarded. When the value of a foreign LSP becomes 0, an IS 124 initiates a aging and purging process which will flush the LSP from 125 the network. This ensures that that corrupted or otherwise invalid 126 LSPs do not remain in the network indefinitely. The rate at which 127 LSPs are regenerated by the originating IS is determined by the value 128 of maximumLSPGenerationInterval. 130 MaxAge is defined in ISO 10589 as an Architectural constant of 20 131 minutes, and it is recommended that maximumLSPGenerationInterval be 132 set to 15 minutes. These times have proven to be too short in some 133 networks, as they result in a steady flow of LSP updates even when 134 nothing is changing. To reduce the rate of generation, some implemen- 135 tations allow these times to be set by the network operator. 137 The relation between MaxAge and maximumLSPGenerationInterval is dis- 138 cussed in section 7.3.21 of ISO 10589. If MaxAge is smaller than max- 139 imumLSPGenerationInterval, then an LSP will expire before it is 140 replaced. Further, as RemainingLifetime is decremented each time it 141 is forwarded, an LSP far from it's origin appears older and is 142 removed sooner. To make sure that an LSP survives long enough to be 143 replaced, MaxAge should exceed maximumLSPGenerationInterval by at 144 least ZeroAgeLifetime + minimumLSPTransmissionInterval. The first 145 term, ZeroAgeLifetime, is an estimate of how long it takes to flood 146 an LSP through the network. The second term, minimumLSPTransmis- 147 sionInterval, takes into account how long a router might delay before 148 sending an LSP. The original recommendation was that MaxAge be at 149 least 5 minutes larger than maximumLSPGenerationInterval, and that 150 recommendation is still valid today. 152 An implementation MAY use a value of MaxAge that is greater than 1200 153 seconds. MaxAge SHOULD exceed maximumLSPGenerationInterval by at 154 least 300 seconds. An implementation SHOULD NOT use it's value of 155 MaxAge to discard LSPs from peers, as discussed below. 157 An implementation is not required to coordinate the RemainingLifetime 158 it assigns to LSPs to the RemainingLifetime values it accepts, and 159 MUST ignore the following sentence from section 7.3.16.3. of ISO 160 10589. 162 "If the value of Remaining Lifetime [of the received LSP] is 163 greater than MaxAge, the LSP shall be processed as if there 164 were a checksum error." 166 6.2 ISISHoldingMultiplier 168 An IS sends IS to IS Hello Protocol Data Units (IIHs) on a periodic 169 basis over active circuits, allowing other attached routers to moni- 170 tor their aliveness. The IIH includes a two byte field called the 171 Holding Time which defines the time to live of an adjacency. If an IS 172 does not receive a hello from an adjacent IS within this holding 173 time, the adjacent IS is assumed to be no longer operational, and the 174 adjacency is removed. 176 ISO 10589 defines ISISHoldingMultiplier to be 10, and states that the 177 value of Holding Time should be ISISHoldingMultiplier multiplied by 178 iSISHelloTimer for ordinary systems, and dRISISHelloTimer for a DIS. 179 This implies that the neighbor must lose 10 IIHs before an adjacency 180 times out. 182 In practice, a value of 10 for the ISISHoldingMultiplier has proven 183 to be too large. DECnet PhaseV defined two related values. The vari- 184 able holdingMultiplier, with a default value of 3, was used for 185 point-to-point IIHs, while the variable ISISHoldingMultiplier, with a 186 default value of 10, was used for LAN IIHs. Most implementations 187 today set the default ISISHoldingMultiplier to 3 for both circuit 188 types. 190 Note that adjacent systems may use different values for Holding Time 191 and will form an adjacency with non-symmetric hold times. 193 An implementation MAY allow ISISHoldingMultiplier to be configurable. 194 Values lower than 3 are unstable, and may cause adjacencies to flap. 196 7. Variables That Are Constant 198 Some values that were defined as variables in ISO 10589 do not vary 199 in practice. These include 201 (1) ID Length - the length of the SystemID 203 (2) maximumAreaAddresses 205 (3) Protocol Version 207 7.1 ID Length 209 The ID Length is a field carried in all PDUs. The ID Length defines 210 the length of the System ID, and is allowed to take values from 0 to 211 8. A value of 0 is interpreted to define a length of 6 bytes. As 212 suggested in B.1.1.3 of [1], it is easy to use an Ethernet MAC 213 address to generate a unique 6 byte System ID. Since the SystemID 214 only has significance within the IGP Domain, 6 bytes has proved to be 215 easy to use and ample in practice. Moreover, new IS-IS TLVs such as 216 the Traffic Engineering TLVs, assume a 6 byte System ID, so choices 217 other than 6 are difficult to support today. Implementations may 218 interoperate without being able to deal with System IDs of any length 219 other than 6. 221 An implementation MUST use an ID Length of 6, and MUST check the ID 222 Length defined in the IS-IS PDUs it receives. If a router encounters 223 a PDU with an ID Length different from 0 or 6, section 7.3.15.a.2 224 dictates that it MUST discard the PDU, and SHOULD generate an 225 appropriate notification. ISO 10589 defines the notification 226 iDFieldLengthMismatch, while the IS-IS MIB [5] defines the notifica- 227 tion isisIDLenMismatch. 229 7.2 maximumAreaAddresses 231 The value of maximumAreaAddresses is defined to be an integer between 232 1 and 254, and defines the number of synonymous Area Addresses that 233 can be in use in an L1 area. This value is advertised in the header 234 of each IS-IS PDU. 236 Most deployed networks use one Area Address for an L1 area. When 237 merging or splitting areas, a second address is required for seamless 238 transition. The third area address was originally required to sup- 239 port DECnet PhaseIV addresses as well as OSI addresses during a tran- 240 sition. 242 ISO 10589 requires that all Intermediate Systems in an area or domain 243 use a consistent value for maximumAreaAddresses. Common practice is 244 for an implementation to use the value 3. Therefore an implementation 245 that only supports 3 can expect to interoperate successfully with 246 other conformant systems. 248 ISO 10589 specifies that an advertised value of 0 is treated as 249 equivalent to 3, and that checking the value for consistency may be 250 omitted if an implementation only supports the value 3. 252 An implementation SHOULD use the value 3, and it SHOULD check the 253 value advertised in IS-IS PDUs it receives. If a router receives a 254 PDU with maximumAreaAddresses that is not 0 or 3, it MUST discard the 255 PDU, as described in section 7.3.15.a.3, and it SHOULD generate an 256 appropriate match. ISO 10589 defines the notification maximumAreaAd- 257 dressMismatch, while the IS-IS MIB [5] defines the notification 258 isisMaxAreaAddressesMismatch. 260 7.3 Protocol Version 262 IS-IS PDUs include two one-byte fields in the headers: 263 "Version/Protocol ID Extension" and "Version". 265 An implementation SHOULD set both fields to 1, and it SHOULD check 266 the values of these fields in IS-IS PDUs it receives. If a router 267 receives a PDU with a value other than 1 for either field, it MUST 268 drop the packet, and SHOULD generate a the isisVersionSkew notifica- 269 tion. 271 8. Alternative Metrics 273 Section 7.2.2, ISO 10589 describes four metrics: Default Metric, 274 Delay Metric, Expense Metric, and Error Metric. None but the Default 275 Metric are used in deployed networks, and most implementations only 276 consider the Default Metric. In ISO 10589, the most significant bit 277 of the 8 bit metrics was the field S (Supported), used to define if 278 the metric was meaningful. 280 If this IS does not support this metric it shall set bit S to 281 1 to indicate that the metric is unsupported. 283 The Supported bit was always 0 for the Default Metric, which must 284 always be supported. However, RFC 2966 [6] uses this bit in the 285 Default Metric to mark L1 routes that have been leaked from L1 to L2 286 and back down into L1 again. 288 Implementations MUST generate the Default Metric when using narrow 289 metrics, and SHOULD ignore the other three metrics when using narrow 290 metrics. Implementations MUST assume that the Default Metric is sup- 291 ported, even if the S bit is set. RFC 2966 describes restrictions on 292 leaking such routes learned from L1 into L2. 294 9. ReceiveLSPBufferSize 296 Since IS-IS does not allow segmentation of protocol PDUs, Link State 297 PDUs (LSPs) must be propagated without modification on all IS-IS 298 enabled links throughout the area/domain. Thus it is essential to 299 configure a maximum size that all routers can forward, receive, and 300 store. 302 This affects three aspects, which we discuss in turn: 304 (1) The largest LSP we can receive (ReceiveLSPBufferSize) 306 (2) The size of the largest LSP we can generate 307 (originatingL1LSPBufferSize and originatingL2LSPBufferSize) 309 (3) Available Link MTU for supported Circuits (MTU). Note this 310 often differs from the MTU available to IP clients. 312 ISO 10589 defines the architectural constant ReceiveLSPBufferSize 313 with value 1492 bytes, and two private management parameters, 314 originatingL1LSPBufferSize for level 1 PDUs and 315 originatingL2LSPBufferSize for level 2 PDUs. The originating buffer 316 size parameters define the maximum size of an LSP that a router can 317 generate. ISO 10589 directs the implementor to treat a PDU larger 318 than ReceiveLSPBufferSize as an error. 320 It is crucial that 321 originatingL1LSPBufferSize <= ReceiveLSPBufferSize 322 originatingL2LSPBufferSize <= ReceiveLSPBufferSize 323 and that for all L1 links in the area 324 originatingL1LSPBufferSize <= MTU 325 and for all L2 links in the domain 326 originatingL2LSPBufferSize <= MTU 328 The original thought was that operators could decrease the originat- 329 ing Buffer size when dealing with smaller MTUs, but would not need to 330 increase ReceiveLSPBufferSize beyond 1492. 332 With the definition of new information to be advertised in LSPs, such 333 as the Traffic Engineering TLVs, the limited space of the LSP data- 334 base which may be generated by each router (256 * 1492 bytes at each 335 level) has become an issue. Given that modern networks with MTUs 336 larger than 1492 on all links are not uncommon, one method which can 337 be used to expand the LSP database size is to allow values of 338 ReceiveLSPBufferSize greater than 1492. 340 Allowing ReceiveLSPBUfferSize to become a configurable parameter 341 rather than an architectural constant must be done with care: if any 342 system in the network does not support values larger than 1492 or one 343 or more link MTUs used by IS-IS anywhere in the area/domain is 344 smaller than the largest LSP which may be generated by any router, 345 then full propagation of all LSPs may not be possible, resulting in 346 routing loops and black holes. 348 The steps below are recommended when changing ReceiveLSPBufferSize. 350 (1) Set the ReceiveLSPBufferSize to a consistent value throughout 351 the network. 353 (2) The implementation MUST not enable IS-IS on circuits which do 354 not support an MTU at least as large as the originating Buf- 355 ferSize at the appropriate level. 357 (3) Include an originatingLSPBufferSize TLV when generating LSPs, 358 as described in section 9.8 of the 2001 revision of ISO 10589 359 [2]. 361 (4) When receiving LSPs, check for an originatingLSPBufferSize 362 TLV, and report the receipt of values larger than the local 363 value of ReceiveLSPBufferSize through the defined Notifica- 364 tions and Alarms. 366 (5) Report the receipt of a PDU larger than the local ReceiveL- 367 SPBufferSize through the defined Notifications and Alarms. 369 (6) Do not discard large PDUs by default. Storing and processing 370 them as normal PDUs may help maintain coherence in a miscon- 371 figured network. 373 Steps 1 and 2 are enough by themselves, but the consequences of 374 mismatch are serious enough and difficult enough to detect, that 375 steps 3-6 are recommended to help track down and correct problems. 377 10. Padding Hello PDUs 379 To prevent the establishment of adjacencies between systems which may 380 not be able to successfully receive and propagate IS-IS PDUs due to 381 inconsistent settings for originatingLSPBufferSize and ReceiveLSPBuf- 382 ferSize, section 8.2.3 of [1] requires padding on point-to-point 383 links. 385 On point-to-point links, the initial IIH is to be padded to the max- 386 imum of 388 (1) Link MTU 390 (2) originatingL1LSPBufferSize if the link is to be used for L1 391 traffic 393 (3) originatingL2LSPBufferSize if the link is to be used for L2 394 traffic 396 In section 6.7.2 e) ISO 10589 assumes 398 Provision that failure to deliver a specific subnetwork SDU 399 will result in the timely disconnexion of the subnetwork con- 400 nection in both directions and that this failure will be 401 reported to both systems 403 With this service provided by the link layer, the requirement that 404 only the initial IIH be padded was sufficient to check the con- 405 sistency of the MTU on the two sides. If the PDU was too big to be 406 received, the link would be reset. However, link layer protocols in 407 use on point-to-point circuits today often lack this service, and the 408 initial padded PDU might be silently dropped without resetting the 409 circuit. Therefore, the requirement that only the initial IIH be 410 padded does not provide the guarantees anticipated in ISO 10589. 412 If an implementation is using padding to detect problems, point-to- 413 point IIH PDUs SHOULD be padded until the sender declares an adja- 414 cency on the link to be in state Up. If the implementation implements 415 RFC 3373 [4], "Three-Way Handshake for IS-IS Point-to-Point Adjacen- 416 cies" then this is when the three-way state is Up: if the implementa- 417 tion use the "classic" algorithm described in ISO 10589, this is when 418 adjacencyState is Up. Transmission of padded IIH PDUs SHOULD be 419 resumed whenever the adjacency is torn down, and SHOULD continue 420 until the sender declares the adjacency to be in state Up again. 422 If an implementation is using padding, and originatingL1LSPBUfferSize 423 or originatingL2LSPBUfferSize is modified, adjacencies SHOULD be 424 brought down and reestablished so the protection provided by padding 425 IIH PDUs is performed consistent with the modified values. 427 Some implementations choose not to pad. Padding does not solve all 428 problems of misconfigured systems. In particular, it does not pro- 429 vide a transitive relation. Assume that A, B, and C all pad IIH 430 PDUs, that A and B can establish an adjacency, and that B and C can 431 establish an adjacency. We still cannot conclude that A and C could 432 establish an adjacency, if they were neighbors. 434 The presence or absence of padding TLVs MUST NOT be one of the accep- 435 tance tests applied to a received IIH regardless of the state of the 436 adjacency. 438 11. Zero Checksum 440 A checksum of 0 is impossible if the checksum is computed according 441 to the rules of ISO 8473 [8]. 443 ISO 10589, section 7.3.14.2(i), states: 445 A Link State PDU received with a zero checksum shall be 446 treated as if the Remaining Lifetime were zero. The age, if 447 not zero, shall be overwritten with zero. 449 That is, ISO 10589 directs the receiver to purge the LSP. This has 450 proved to be disruptive in practice. An implementation SHOULD treat 451 all LSPs with a zero checksum and a non-zero remaining lifetime as if 452 they had as checksum error. Such packets SHOULD be discarded. 454 12. Purging Corrupted PDUs 456 While ISO 10589 requires in section 7.3.14.2 e) that any LSP received 457 with an invalid PDU checksum should be purged, this has been found to 458 be disruptive. Most implementations today follow the revised specif- 459 ication, and simply drop the LSP. 461 In ISO 10589:2001 [2], Section 7.3.14.2, it states: 463 (e) An Intermediate system receiving a Link State PDU with an 464 incorrect LSP Checksum or with an invalid PDU syntax SHOULD 466 1) generate a corruptedLSPReceived circuit event, 468 2) discard the PDU. 470 13. Checking System ID in Received point-to-point IIH PDUs 472 In section 8.2.4.2, ISO 10589 does not explicitly require comparison 473 of the source ID of a received IIH with the neighbourSystemID associ- 474 ated with an existing adjacency on a point-to-point link. 476 To address this omission, implementations receiving an IIH PDU on a 477 point to point circuit with an established adjacency SHOULD check the 478 Source ID field and compare that with the neighbourSystemID of the 479 adjacency. If these differ, an implementation SHOULD delete the adja- 480 cency. 482 Given that IIH PDUs as specified in ISO 10589 do not include a check- 483 sum, it is possible that a corrupted IIH may falsely indicate a 484 change in the neighbor's System ID. The required subnetwork guaran- 485 tees for point-to-point links, as described in 6.7.2 g) 1) assume 486 that undetected corrupted PDUs are very rare (one event per four 487 years). A link with frequent errors that produce corrupted data could 488 lead to flapping an adjacency. Inclusion of an optional checksum TLV 489 as specified in "Optional Checksums in ISIS" [7], may be used to 490 detect such corruption. Hello packets carrying this TLV that are 491 corrupted PDUs SHOULD be silently dropped, rather than dropping the 492 adjacency. 494 Some implementations have chosen to discard received IIHs where the 495 source ID differs from the neighbourSystemID. This may prevent need- 496 less flapping caused by undetected PDU corruption. If an actual 497 administrative change to the neighbor's system ID has occurred, using 498 this strategy may require the existing adjacency to timeout before an 499 adjacency with the new neighbor can be established. This is 500 expedited if the neighbor resets the circuit as anticipated in 10589 501 after a System ID change, or resets the 3-way adjacency state, as 502 anticipated in RFC 3373. 504 14. Doppelganger LSPs 506 When an Intermediate System shuts down, it may leave old LSPs in the 507 network. In the normal course of events, a rebooting system flushes 508 out these old LSPs by reissuing those fragments with a higher 509 sequence number, or by purging fragments that it is not currently 510 generating. 512 In the case where a received LSP or SNP entry and an LSP in the local 513 database have the same LSP ID, same sequence number, non-zero remain- 514 ing lifetimes, but different non-zero checksums, the rules defined in 515 [1] cannot determine which of the two is "newer". In this case, an 516 implementation may opt to perform an additional test as a tie breaker 517 by comparing the checksums. Implementations that elect to use this 518 method MUST consider the LSP/SNP entry with the higher checksum as 519 newer. When comparing the checksums the checksum field is treated as 520 a 16 bit unsigned integer in network byte order (i.e., most signifi- 521 cant byte first). 523 The choice of higher checksum, rather than lower, while arbitrary, 524 aligns with existing implementations and ensures compatibility. 526 Note that a purged LSP (i.e. an LSP with remaining lifetime set to 0 527 and/or a zero checksum) is always considered newer than a non-purged 528 copy of the same LSP. 530 15. Security Implications 532 The clarifications in this document do not raise any new security 533 concerns, as there is no change in the underlying protocol described 534 in ISO 10589 [1]. 536 16. References 538 [1] ISO, "Intermediate system to Intermediate system routeing informa- 539 tion exchange protocol for use in conjunction with the Protocol for 540 providing the Connectionless-mode Network Service (ISO 8473)," 541 ISO/IEC 10589:1992. 543 [2] ISO, "Intermediate system to Intermediate system routeing informa- 544 tion exchange protocol for use in conjunction with the Protocol for 545 providing the Connectionless-mode Network Service (ISO 8473)," 546 ISO/IEC 10589:2001. 548 [3] Callon, R., "OSI IS-IS for IP and Dual Environment," RFC 1195, 549 December 1990. 551 [4] Katz, D. and Saluja, R., " Three-Way Handshake for Intermediate 552 System to Intermediate System (IS-IS) Point-to-Point Adjacencies" 553 RFC 3373, September 2002. 555 [5] Parker, J., "Management Information Base for IS-IS", draft-ietf- 556 isis-wg-mib-08.txt, May 2002. 558 [6] Li, T., Przygienda, T., "Domain-wide Prefix Distribution with Two- 559 Level IS-IS", RFC 2966, October 2000. 561 [7] Przygienda, T., "Optional Checksums in ISIS", draft-ietf-isis-wg- 562 snp-checksum-03.txt, April 2002. 564 [8] ITU, "Information technology - Protocol for providing the 565 connectionless-mode network service", ISO/IEC 8473-1, 1998 567 17. Author's Addresses 569 Jeff Parker 570 Axiowave Networks 571 200 Nickerson Road 572 Marlborough, Mass 01752 573 USA 574 e-mail: jparker@axiowave.com 576 18. Full Copyright Statement 578 Copyright (C) The Internet Society (1997). All Rights Reserved. 580 This document and translations of it may be copied and furnished to 581 others, and derivative works that comment on or otherwise explain it 582 or assist in its implementation may be prepared, copied, published 583 and distributed, in whole or in part, without restriction of any 584 kind, provided that the above copyright notice and this paragraph are 585 included on all such copies and derivative works. However, this 586 document itself may not be modified in any way, such as by removing 587 the copyright notice or references to the Internet Society or other 588 Internet organizations, except as needed for the purpose of develop- 589 ing Internet standards in which case the procedures for copyrights 590 defined in the Internet Standards process must be followed, or as 591 required to translate it into languages other than English. 593 The limited permissions granted above are perpetual and will not be 594 revoked by the Internet Society or its successors or assigns. 596 This document and the information contained herein is provided on an 597 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 598 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 599 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 600 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MER- 601 CHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE."