Network Working Group J. Parker, Ed. Request for Comments: 3719 Axiowave Networks Category: Informational February 2004 Recommendations for Interoperable Networks using Intermediate System to Intermediate System (IS-IS) Status of this Memo This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. Copyright Notice Copyright (C) The Internet Society (2004). All Rights Reserved.
AbstractThis document discusses a number of differences between the Intermediate System to Intermediate System (IS-IS) protocol as described in ISO 10589 and the protocol as it is deployed today. These differences are discussed as a service to those implementing, testing, and deploying the IS-IS Protocol. A companion document discusses differences between the protocol described in RFC 1195 and the protocol as it is deployed today for routing IP traffic. 1. Introduction. . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Constants That Are Variable . . . . . . . . . . . . . . . . . 2 3. Variables That Are Constant . . . . . . . . . . . . . . . . . 4 4. Alternative Metrics . . . . . . . . . . . . . . . . . . . . . 6 5. ReceiveLSPBufferSize. . . . . . . . . . . . . . . . . . . . . 6 6. Padding Hello PDUs. . . . . . . . . . . . . . . . . . . . . . 8 7. Zero Checksum . . . . . . . . . . . . . . . . . . . . . . . . 9 8. Purging Corrupted LSPs. . . . . . . . . . . . . . . . . . . . 10 9. Checking System ID in Received point-to-point IIH PDUs. . . . 10 10. Doppelganger LSPs . . . . . . . . . . . . . . . . . . . . . . 11 11. Generating a Complete Set of CSNPs. . . . . . . . . . . . . . 11 12. Overload Bit. . . . . . . . . . . . . . . . . . . . . . . . . 12 13. Security Considerations . . . . . . . . . . . . . . . . . . . 13 14. References. . . . . . . . . . . . . . . . . . . . . . . . . . 13 15. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14 16. Author's Address . . . . . . . . . . . . . . . . . . . . . . 14 17. Full Copyright Statement. . . . . . . . . . . . . . . . . . . 15
1] has proved to be quite durable. However, a number of original design choices have been modified. This document addresses differences between the protocol described in ISO 10589 and the protocol that can be observed on the wire today. A companion document discusses differences between the protocol described in RFC 1195  for routing IP traffic and current practice. The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT" and "MAY" in this document are to be interpreted as described in RFC 2119 .
MaxAge is defined in ISO 10589 as an Architectural constant of 20 minutes, and it is recommended that maximumLSPGenerationInterval be set to 15 minutes. These times have proven to be too short in some networks, as they result in a steady flow of LSP updates even when nothing is changing. To reduce the rate of generation, some implementations allow these times to be set by the network operator. The relation between MaxAge and maximumLSPGenerationInterval is discussed in section 7.3.21 of ISO 10589. If MaxAge is smaller than maximumLSPGenerationInterval, then an LSP will expire before it is replaced. Further, as RemainingLifetime is decremented each time it is forwarded, an LSP far from its origin appears older and is removed sooner. To make sure that an LSP survives long enough to be replaced, MaxAge should exceed maximumLSPGenerationInterval by at least ZeroAgeLifetime + minimumLSPTransmissionInterval. The first term, ZeroAgeLifetime, is an estimate of how long it takes to flood an LSP through the network. The second term, minimumLSPTransmissionInterval, takes into account how long a router might delay before sending an LSP. The original recommendation was that MaxAge be at least 5 minutes larger than maximumLSPGenerationInterval, and that recommendation is still valid today. An implementation MAY use a value of MaxAge that is greater than 1200 seconds. MaxAge SHOULD exceed maximumLSPGenerationInterval by at least 300 seconds. An implementation SHOULD NOT use its value of MaxAge to discard LSPs from peers, as discussed below. An implementation is not required to coordinate the RemainingLifetime it assigns to LSPs to the RemainingLifetime values it accepts, and MUST ignore the following sentence from section 18.104.22.168. of ISO 10589. "If the value of Remaining Lifetime [of the received LSP] is greater than MaxAge, the LSP shall be processed as if there were a checksum error."
ISO 10589 defines ISISHoldingMultiplier to be 10, and states that the value of Holding Time should be ISISHoldingMultiplier multiplied by iSISHelloTimer for ordinary systems, and dRISISHelloTimer for a DIS. This implies that the neighbor must lose 10 IIHs before an adjacency times out. In practice, a value of 10 for the ISISHoldingMultiplier has proven to be too large. DECnet PhaseV defined two related values. The variable holdingMultiplier, with a default value of 3, was used for point-to-point IIHs, while the variable ISISHoldingMultiplier, with a default value of 10, was used for LAN IIHs. Most implementations today set the default ISISHoldingMultiplier to 3 for both circuit types. Note that adjacent systems may use different values for Holding Time and will form an adjacency with non-symmetric hold times. An implementation MAY allow ISISHoldingMultiplier to be configurable. Values lower than 3 are unstable, and may cause adjacencies to flap. 1], it is easy to use an Ethernet MAC address to generate a unique 6 byte System ID. Since the SystemID only has significance within the IGP Domain, 6 bytes has proved to be easy to use and ample in practice. There are also new IS-IS Traffic Engineering TLVs which assume a 6 byte System ID. Choices for the ID length other than 6 are difficult to support today. Implementations may interoperate without being able to deal with System IDs of any length other than 6. An implementation MUST use an ID Length of 6, and MUST check the ID Length defined in the IS-IS PDUs it receives. If a router encounters a PDU with an ID Length different from 0 or 6, section 7.3.15.a.2
RFC 2966  uses this bit in the Default Metric to mark L1 routes that have been leaked from L1 to L2 and back down into L1 again. Implementations MUST generate the Default Metric when using narrow metrics, and SHOULD ignore the other three metrics when using narrow metrics. Implementations MUST assume that the Default Metric is supported, even if the S bit is set. RFC 2966 describes restrictions on leaking such routes learned from L1 into L2.
size parameters define the maximum size of an LSP that a router can generate. ISO 10589 directs the implementor to treat a PDU larger than ReceiveLSPBufferSize as an error. It is crucial that originatingL1LSPBufferSize <= ReceiveLSPBufferSize originatingL2LSPBufferSize <= ReceiveLSPBufferSize and that for all L1 links in the area originatingL1LSPBufferSize <= MTU and for all L2 links in the domain originatingL2LSPBufferSize <= MTU The original thought was that operators could decrease the originating Buffer size when dealing with smaller MTUs, but would not need to increase ReceiveLSPBufferSize beyond 1492. With the definition of new information to be advertised in LSPs, such as the Traffic Engineering TLVs, the limited space of the LSP database which may be generated by each router (256 * 1492 bytes at each level) has become an issue. Given that modern networks with MTUs larger than 1492 on all links are not uncommon, one method which can be used to expand the LSP database size is to allow values of ReceiveLSPBufferSize greater than 1492. Allowing ReceiveLSPBUfferSize to become a configurable parameter rather than an architectural constant must be done with care: if any system in the network does not support values larger than 1492 or one or more link MTUs used by IS-IS anywhere in the area/domain is smaller than the largest LSP which may be generated by any router, then full propagation of all LSPs may not be possible, resulting in routing loops and black holes. The steps below are recommended when changing ReceiveLSPBufferSize. (1) Set the ReceiveLSPBufferSize to a consistent value throughout the network. (2) The implementation MUST not enable IS-IS on circuits which do not support an MTU at least as large as the originating BufferSize at the appropriate level. (3) Include an originatingLSPBufferSize TLV when generating LSPs, introduced in section 9.8 of ISO 10589:2002 . (4) When receiving LSPs, check for an originatingLSPBufferSize TLV, and report the receipt of values larger than the local value of ReceiveLSPBufferSize through the defined Notifications and Alarms.
(5) Report the receipt of a PDU larger than the local ReceiveLSPBufferSize through the defined Notifications and Alarms. (6) Do not discard large PDUs by default. Storing and processing them as normal PDUs may help maintain coherence in a misconfigured network. Steps 1 and 2 are enough by themselves, but the consequences of mismatch are serious enough and difficult enough to detect, that steps 3-6 are recommended to help track down and correct problems. 1] requires padding on point-to-point links. On point-to-point links, the initial IIH is to be padded to the maximum of (1) Link MTU (2) originatingL1LSPBufferSize if the link is to be used for L1 traffic (3) originatingL2LSPBufferSize if the link is to be used for L2 traffic In section 6.7.2 e) ISO 10589 assumes Provision that failure to deliver a specific subnetwork SDU will result in the timely disconnection of the subnetwork connection in both directions and that this failure will be reported to both systems With this service provided by the link layer, the requirement that only the initial IIH be padded was sufficient to check the consistency of the MTU on the two sides. If the PDU was too big to be received, the link would be reset. However, link layer protocols in use on point-to-point circuits today often lack this service, and the initial padded PDU might be silently dropped without resetting the circuit. Therefore, the requirement that only the initial IIH be padded does not provide the guarantees anticipated in ISO 10589.
If an implementation is using padding to detect problems, point-to- point IIH PDUs SHOULD be padded until the sender declares an adjacency on the link to be in state Up. If the implementation implements RFC 3373 , "Three-Way Handshake for IS-IS Point-to- Point Adjacencies" then this is when the three-way state is Up: if the implementation use the "classic" algorithm described in ISO 10589, this is when adjacencyState is Up. Transmission of padded IIH PDUs SHOULD be resumed whenever the adjacency is torn down, and SHOULD continue until the sender declares the adjacency to be in state Up again. If an implementation is using padding, and originatingL1LSPBUfferSize or originatingL2LSPBUfferSize is modified, adjacencies SHOULD be brought down and reestablished so the protection provided by padding IIH PDUs is performed consistent with the modified values. Some implementations choose not to pad. Padding does not solve all problems of misconfigured systems. In particular, it does not provide a transitive relation. Assume that A, B, and C all pad IIH PDUs, that A and B can establish an adjacency, and that B and C can establish an adjacency. We still cannot conclude that A and C could establish an adjacency, if they were neighbors. The presence or absence of padding TLVs MUST NOT be one of the acceptance tests applied to a received IIH regardless of the state of the adjacency. 8]. ISO 10589, section 22.214.171.124(i), states: A Link State PDU received with a zero checksum shall be treated as if the Remaining Lifetime were zero. The age, if not zero, shall be overwritten with zero. That is, ISO 10589 directs the receiver to purge the LSP. This has proved to be disruptive in practice. An implementation SHOULD treat all LSPs with a zero checksum and a non-zero remaining lifetime as if they had as checksum error. Such packets SHOULD be discarded.
1], Section 126.96.36.199, it states: (e) An Intermediate system receiving a Link State PDU with an incorrect LSP Checksum or with an invalid PDU syntax SHOULD 1) generate a corruptedLSPReceived circuit event, 2) discard the PDU. 6], may be used to detect such corruption. Hello packets carrying this TLV that are corrupted PDUs SHOULD be silently dropped, rather than dropping the adjacency. Some implementations have chosen to discard received IIHs where the source ID differs from the neighbourSystemID. This may prevent needless flapping caused by undetected PDU corruption. If an actual administrative change to the neighbor's system ID has occurred, using this strategy may require the existing adjacency to timeout before an adjacency with the new neighbor can be established. This is
expedited if the neighbor resets the circuit as anticipated in 10589 after a System ID change, or resets the 3-way adjacency state, as anticipated in RFC 3373. 1] cannot determine which of the two is "newer". In this case, an implementation may opt to perform an additional test as a tie breaker by comparing the checksums. Implementations that elect to use this method MUST consider the LSP/SNP entry with the higher checksum as newer. When comparing the checksums the checksum field is treated as a 16 bit unsigned integer in network byte order (i.e., most significant byte first). The choice of higher checksum, rather than lower, while arbitrary, aligns with existing implementations and ensures compatibility. Note that a purged LSP (i.e., an LSP with remaining lifetime set to 0) is always considered newer than a non-purged copy of the same LSP. 1] defines a complete set of CSNPs to be: "A complete set of CSNPs is a set whose Start LSPID and End LSPID ranges cover the complete possible range of LSPIDs. (i.e., there is no possible LSPID value which does not appear within the range of one of the CSNPs in the set). " Strict adherence to this definition is required to ensure the reliability of the update process. Deviation can lead to subtle and hard to detect defects. It is not sufficient to send a set of CSNPs which merely cover the range of LSPIDs which are in the local database. The set of CSNPs must cover the complete possible range of LSPIDs.
Consider the following example: If the current Level 1 LSP database on a router consists of the following non pseudo-node LSPs: From system 1111.1111.1111 LSPs numbered 0-89(59H) From system 2222.2222.2222 LSPs numbered 0-89(59H) If the maximum size of a CSNP is 1492 bytes, then 90 CSNP entries can fit into a single CSNP PDU. The following set of CSNP start/end LSPIDs constitute a correctly formatted complete set: Start LSPID End LSPID 0000.0000.0000.00-00 1111.1111.1111.00-59 1111.1111.1111.00-5A FFFF.FFFF.FFFF.FF-FF The following are examples of incomplete sets of CSNPS: Start LSPID End LSPID 0000.0000.0000.00-00 1111.1111.1111.00-59 1111.1111.1111.00-5A 2222.2222.2222.00-59 The sequence above has a gap after the second entry. Start LSPID End LSPID 0000.0000.0000.00-00 1111.1111.1111.00-59 2222.2222.2222.00-00 FFFF.FFFF.FFFF.FF-FF The sequence above has a gap between the first and second entry. Although it is legal to send a CSNP which contains no actual LSP entry TLVs, it should never be necessary to do so in order to conform to the specification.
An overloaded router might become the DIS. An implementation SHOULD not set the Overload bit in PseudoNode LSPs that it generates, and Overload bits seen in PseudoNode LSPs SHOULD be ignored. 1].  ISO, "Intermediate system to Intermediate system routeing information exchange protocol for use in conjunction with the Protocol for providing the Connectionless-mode Network Service (ISO 8473)," ISO/IEC 10589:2002.  Callon, R., "OSI IS-IS for IP and Dual Environment", RFC 1195, December 1990.  Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.  Katz, D. and Saluja, R., " Three-Way Handshake for Intermediate System to Intermediate System (IS-IS) Point-to-Point Adjacencies", RFC 3373, September 2002.  Li, T., Przygienda, T. and H. Smit, "Domain-wide Prefix Distribution with Two-Level IS-IS", RFC 2966, October 2000.  Koodli, R. and R. Ravikanth, "Optional Checksums in Intermediate System to Intermediate System (ISIS)", RFC 3358, August 2002.  Parker, J., "Management Information Base for IS-IS", Work in Progress, January 2004.  ITU, "Information technology - Protocol for providing the connectionless-mode network service", ISO/IEC 8473-1, 1998.
BCP 78 and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at email@example.com. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society.