GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc3719

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]

/data/webs/external/dokuwiki/data/pages/rfc/rfc3719.txt · Last modified: 2004/02/25 17:08 (external edit)