From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc3719.txt | 843 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 843 insertions(+) create mode 100644 doc/rfc/rfc3719.txt (limited to 'doc/rfc/rfc3719.txt') diff --git a/doc/rfc/rfc3719.txt b/doc/rfc/rfc3719.txt new file mode 100644 index 0000000..920e347 --- /dev/null +++ b/doc/rfc/rfc3719.txt @@ -0,0 +1,843 @@ + + + + + + +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. + +Abstract + + This 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. + +Table of Contents + + 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 + + + + +Parker Informational [Page 1] + +RFC 3719 Interoperable Networks using IS-IS February 2004 + + +1. Introduction + + In theory, there is no difference between theory and practice. + But in practice, there is. + Jan L.A. van de Snepscheut + + Interior Gateway Protocols such as IS-IS are designed to provide + timely information about the best routes in a routing domain. The + original design of IS-IS, as described in ISO 10589 [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 [2] 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 [3]. + +2. Constants That Are Variable + + Some parameters that were defined as constant in ISO 10589 are + modified in practice. These include the following + + (1) MaxAge - the lifetime of a Link State PDU (LSP) + + (2) ISISHoldingMultiplier - a parameter used to describe the + generation of hello packets + + (3) ReceiveLSPBufferSize - discussed in a later section + +2.1. MaxAge + + Each LSP contains a RemainingLifetime field which is initially set to + the MaxAge value on the generating IS. The value stored in this + field is decremented to mark the passage of time and the number of + times it has been forwarded. When the value of a foreign LSP becomes + 0, an IS initiates a purging process which will flush the LSP from + the network. This ensures that corrupted or otherwise invalid LSPs + do not remain in the network indefinitely. The rate at which LSPs + are regenerated by the originating IS is determined by the value of + maximumLSPGenerationInterval. + + + + + + + + + +Parker Informational [Page 2] + +RFC 3719 Interoperable Networks using IS-IS February 2004 + + + 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 7.3.16.3. 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." + +2.2. ISISHoldingMultiplier + + An IS sends IS to IS Hello Protocol Data Units (IIHs) on a periodic + basis over active circuits, allowing other attached routers to + monitor their aliveness. The IIH includes a two byte field called + the Holding Time which defines the time to live of an adjacency. If + an IS does not receive a hello from an adjacent IS within this + holding time, the adjacent IS is assumed to be no longer operational, + and the adjacency is removed. + + + + + +Parker Informational [Page 3] + +RFC 3719 Interoperable Networks using IS-IS February 2004 + + + 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. + +3. Variables That Are Constant + + Some values that were defined as variables in ISO 10589 do not vary + in practice. These include + + (1) ID Length - the length of the SystemID + + (2) maximumAreaAddresses + + (3) Protocol Version + +3.1. ID Length + + The ID Length is a field carried in all PDUs. The ID Length defines + the length of the System ID, and is allowed to take values from 0 to + 8. A value of 0 is interpreted to define a length of 6 bytes. As + suggested in B.1.1.3 of [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 + + + +Parker Informational [Page 4] + +RFC 3719 Interoperable Networks using IS-IS February 2004 + + + dictates that it MUST discard the PDU, and SHOULD generate an + appropriate notification. ISO 10589 defines the notification + iDFieldLengthMismatch, while the IS-IS MIB [7] defines the + notification isisIDLenMismatch. + +3.2. maximumAreaAddresses + + The value of maximumAreaAddresses is defined to be an integer between + 1 and 254, and defines the number of synonymous Area Addresses that + can be in use in an L1 area. This value is advertised in the header + of each IS-IS PDU. + + Most deployed networks use one Area Address for an L1 area. When + merging or splitting areas, a second address is required for seamless + transition. The third area address was originally required to + support DECnet PhaseIV addresses as well as OSI addresses during a + transition. + + ISO 10589 requires that all Intermediate Systems in an area or domain + use a consistent value for maximumAreaAddresses. Common practice is + for an implementation to use the value 3. Therefore an + implementation that only supports 3 can expect to interoperate + successfully with other conformant systems. + + ISO 10589 specifies that an advertised value of 0 is treated as + equivalent to 3, and that checking the value for consistency may be + omitted if an implementation only supports the value 3. + + An implementation SHOULD use the value 3, and it SHOULD check the + value advertised in IS-IS PDUs it receives. If a router receives a + PDU with maximumAreaAddresses that is not 0 or 3, it MUST discard the + PDU, as described in section 7.3.15.a.3, and it SHOULD generate an + appropriate notification. ISO 10589 defines the notification + maximumAreaAddressMismatch, while the IS-IS MIB [7] defines the + notification isisMaxAreaAddressesMismatch. + +3.3. Protocol Version + + IS-IS PDUs include two one-byte fields in the headers: + "Version/Protocol ID Extension" and "Version". + + An implementation SHOULD set both fields to 1, and it SHOULD check + the values of these fields in IS-IS PDUs it receives. If a router + receives a PDU with a value other than 1 for either field, it MUST + drop the packet, and SHOULD generate the isisVersionSkew + notification. + + + + + +Parker Informational [Page 5] + +RFC 3719 Interoperable Networks using IS-IS February 2004 + + +4. Alternative Metrics + + Section 7.2.2, ISO 10589 describes four metrics: Default Metric, + Delay Metric, Expense Metric, and Error Metric. None but the Default + Metric are used in deployed networks, and most implementations only + consider the Default Metric. In ISO 10589, the most significant bit + of the 8 bit metrics was the field S (Supported), used to define if + the metric was meaningful. + + If this IS does not support this metric it shall set bit S to 1 + to indicate that the metric is unsupported. + + The Supported bit was always 0 for the Default Metric, which must + always be supported. However, RFC 2966 [5] 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. + +5. ReceiveLSPBufferSize + + Since IS-IS does not allow segmentation of protocol PDUs, Link State + PDUs (LSPs) must be propagated without modification on all IS-IS + enabled links throughout the area/domain. Thus it is essential to + configure a maximum size that all routers can forward, receive, and + store. + + This affects three aspects, which we discuss in turn: + + (1) The largest LSP we can receive (ReceiveLSPBufferSize) + + (2) The size of the largest LSP we can generate + (originatingL1LSPBufferSize and + originatingL2LSPBufferSize) + + (3) Available Link MTU for supported Circuits (MTU). Note + this often differs from the MTU available to IP clients. + + ISO 10589 defines the architectural constant ReceiveLSPBufferSize + with value 1492 bytes, and two private management parameters, + originatingL1LSPBufferSize for level 1 PDUs and + originatingL2LSPBufferSize for level 2 PDUs. The originating buffer + + + + + +Parker Informational [Page 6] + +RFC 3719 Interoperable Networks using IS-IS February 2004 + + + 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 [1]. + + (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. + + + +Parker Informational [Page 7] + +RFC 3719 Interoperable Networks using IS-IS February 2004 + + + (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. + +6. Padding Hello PDUs + + To prevent the establishment of adjacencies between systems which may + not be able to successfully receive and propagate IS-IS PDUs due to + inconsistent settings for originatingLSPBufferSize and + ReceiveLSPBufferSize, section 8.2.3 of [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. + + + + + +Parker Informational [Page 8] + +RFC 3719 Interoperable Networks using IS-IS February 2004 + + + 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 [4], "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. + +7. Zero Checksum + + A checksum of 0 is impossible if the checksum is computed according + to the rules of ISO 8473 [8]. + + ISO 10589, section 7.3.14.2(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. + + + + + + + + + +Parker Informational [Page 9] + +RFC 3719 Interoperable Networks using IS-IS February 2004 + + +8. Purging Corrupted PDUs + + While ISO 10589 requires in section 7.3.14.2 e) that any LSP received + with an invalid PDU checksum should be purged, this has been found to + be disruptive. Most implementations today follow the revised + specification, and simply drop the LSP. + + In ISO 10589:2002 [1], Section 7.3.14.2, 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. + +9. Checking System ID in Received point-to-point IIH PDUs + + In section 8.2.4.2, ISO 10589 does not explicitly require comparison + of the source ID of a received IIH with the neighbourSystemID + associated with an existing adjacency on a point-to-point link. + + To address this omission, implementations receiving an IIH PDU on a + point to point circuit with an established adjacency SHOULD check the + Source ID field and compare that with the neighbourSystemID of the + adjacency. If these differ, an implementation SHOULD delete the + adjacency. + + Given that IIH PDUs as specified in ISO 10589 do not include a + check-sum, it is possible that a corrupted IIH may falsely indicate a + change in the neighbor's System ID. The required subnetwork + guarantees for point-to-point links, as described in 6.7.2 g) 1) + assume that undetected corrupted PDUs are very rare (one event per + four years). A link with frequent errors that produce corrupted data + could lead to flapping an adjacency. Inclusion of an optional + checksum TLV as specified in "Optional Checksums in IS-IS" [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 + + + + + +Parker Informational [Page 10] + +RFC 3719 Interoperable Networks using IS-IS February 2004 + + + 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. + +10. Doppelganger LSPs + + When an Intermediate System shuts down, it may leave old LSPs in the + network. In the normal course of events, a rebooting system flushes + out these old LSPs by reissuing those fragments with a higher + sequence number, or by purging fragments that it is not currently + generating. + + In the case where a received LSP or SNP entry and an LSP in the local + database have the same LSP ID, same sequence number, non-zero + remaining lifetimes, but different non-zero checksums, the rules + defined in [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. + +11. Generating a Complete Set of CSNPs + + There are a number of cases in which a complete set of CSNPs must be + generated. The DIS on a LAN, two IS's peering over a P2P link, and + an IS helping another IS perform graceful restart must generate a + complete set of CSNPs to assure consistent LSP Databases throughout. + Section 7.3.15.3 of [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. + + + +Parker Informational [Page 11] + +RFC 3719 Interoperable Networks using IS-IS February 2004 + + + 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. + +12. Overload Bit + + To deal with transient problems that prevent an IS from storing all + the LSPs it receives, ISO 10589 defines an LSP Database Overload + condition in section 7.3.19. When an IS is in Database Overload + condition, it sets a flag called the Overload Bit in the non- + pseudonode LSP number Zero that it generates. Section 7.2.8.1 of ISO + 10589 instructs other systems not to use the overloaded IS as a + transit router. Since the overloaded IS does not have complete + information, it may not be able to compute the right routes, and + routing loops could develop. + + + + + + +Parker Informational [Page 12] + +RFC 3719 Interoperable Networks using IS-IS February 2004 + + + 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. + +13. Security Considerations + + The clarifications in this document do not raise any new security + concerns, as there is no change in the underlying protocol described + in ISO 10589 [1]. + +14. References + +14.1. Normative References + + [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. + + [2] Callon, R., "OSI IS-IS for IP and Dual Environment", RFC 1195, + December 1990. + + [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement + Levels", BCP 14, RFC 2119, March 1997. + + [4] Katz, D. and Saluja, R., " Three-Way Handshake for Intermediate + System to Intermediate System (IS-IS) Point-to-Point + Adjacencies", RFC 3373, September 2002. + + [5] Li, T., Przygienda, T. and H. Smit, "Domain-wide Prefix + Distribution with Two-Level IS-IS", RFC 2966, October 2000. + + [6] Koodli, R. and R. Ravikanth, "Optional Checksums in Intermediate + System to Intermediate System (ISIS)", RFC 3358, August 2002. + +14.2. Informative References + + [7] Parker, J., "Management Information Base for IS-IS", Work in + Progress, January 2004. + + [8] ITU, "Information technology - Protocol for providing the + connectionless-mode network service", ISO/IEC 8473-1, 1998. + + + + + + + + + +Parker Informational [Page 13] + +RFC 3719 Interoperable Networks using IS-IS February 2004 + + +15. Acknowledgments + + This document is the work of many people, and is the distillation of + over a thousand mail messages. Thanks to Vishwas Manral, who pushed + to create such a document. Thanks to Danny McPherson, the original + editor, for kicking things off. Thanks to Mike Shand, for his work + in creating the protocol, and his uncanny ability to remember what + everything is for. Thanks to Micah Bartell and Philip Christian, who + showed us how to document difference without displaying discord. + Thanks to Les Ginsberg, Neal Castagnoli, Jeff Learman, and Dave Katz, + who spent many hours educating the editor. Thanks to Radia Perlman, + who is always ready to explain anything. Thanks to Satish Dattatri, + who was tenacious in seeing things written up correctly. Thanks to + Russ White, whose writing improved the treatment of every topic he + touched. Thanks to Shankar Vemulapalli, who read several drafts with + close attention. Thanks to Don Goodspeed, for his close reading of + the text. Thanks to Aravind Ravikumar, who pointed out that we + should check Source ID on point-to-point IIH packets. Thanks to + Michael Coyle for identifying the quotation from Jan L.A. van de + Snepscheut. Thanks for Alex Zinin's ministrations behind the scenes. + Thanks to Tony Li and Tony Przygienda, who kept us on track as the + discussions veered into the weeds. And thanks to all those who have + contributed, but whose names I have carelessly left from this list. + +16. Author's Address + + Jeff Parker + Axiowave Networks + 200 Nickerson Road + Marlborough, Mass 01752 + USA + + EMail: jparker@axiowave.com + + + + + + + + + + + + + + + + + + +Parker Informational [Page 14] + +RFC 3719 Interoperable Networks using IS-IS February 2004 + + +17. Full Copyright Statement + + Copyright (C) The Internet Society (2004). This document is subject + to the rights, licenses and restrictions contained in 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 ietf-ipr@ietf.org. + +Acknowledgement + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + + + + + + +Parker Informational [Page 15] + -- cgit v1.2.3