[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01

Internet Engineering Task Force                        J. Parker, Editor
INTERNET DRAFT                                         Axiowave Networks
Expiration Date: December 2002

                                                           June 19, 2002

       Recommendations for Interoperable IP Networks using IS-IS

1. Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet- Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at

   The list of Internet-Draft Shadow Directories can be accessed at

   Copyright Notice Copyright (C) The Internet Society (2000).  All
   Rights Reserved.

Parker                  Expires December 2002                   [Page 1]

Internet Draft - draft-ietf-isis-interoperable                 June 2002

2. Abstract

          In theory, there is no difference between theory and practice.
          But in practice, there is.

          Jan L.A. van de Snepscheut

   This document discusses a number of differences between the IS-IS
   protocol as described in ISO 10589 [1] and RFC 1195 [3] 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 to route IP traffic.

3. Table of Contents

    1.  Status of this Memo..................................    1
    2.  Abstract.............................................    2
    3.  Table of Contents....................................    2
    4.  Overview.............................................    2
    5.  Acknowledgments......................................    3
    6.  Constants Which Are Variable.........................    3
    7.  Variables Which Are Constant.........................    5
    8.  Unused Features......................................    6
    9.  Overload Bit.........................................    7
   10.  ReceiveLSPBufferSize.................................    8
   11.  Padding Hello PDUs...................................   10
   12.  Migration from Narrow Metrics to Wide................   11
   13.  Intermediate System Hello (ISH) PDU..................   14
   14.  Attached Bit.........................................   15
   15.  Default Route........................................   15
   16.  Zero Checksum........................................   15
   17.  Purging Corrupted LSPs...............................   15
   18.  Non-homogeneous Protocol Networks....................   16
   19.  Interface Address and Adjacency Creation.............   17
   20.  Checking System ID in Received point-to-point IIH PDUs  17
   21.  Security Implications...............................    18
   22.  References...........................................   18
   23.  Author's  Address....................................   19
   24.  Full Copyright Statement.............................   19

4. Overview

   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

Parker                  Expires December 2002                   [Page 2]

Internet Draft - draft-ietf-isis-interoperable                 June 2002

   been modified. This document describes some of the differences
   between the protocol as described in ISO 10589 and RFC 1195 [3] and
   the protocol that can be observed on the wire today.

5. Acknowledgments

   This document is the work of many people, and is the distilation 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, and to Bryan
   Boulton for his work on the IP adjacency issue.  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.

6. Constants Which Are Variable

   Some parameters that were defined as constant in ISO 10589 [1] 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 genera-
        tion of hello packets

6.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 aging and purging process which will flush the LSP from

Parker                  Expires December 2002                   [Page 3]

Internet Draft - draft-ietf-isis-interoperable                 June 2002

   the network. This ensures that 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.

   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 implemen-
   tations allow these times to be set by the network operator.

   The relation between MaxAge and maximumLSPGenerationInterval is dis-
   cussed in section 7.3.21 of ISO 10589. If MaxAge is smaller than max-
   imumLSPGenerationInterval, then an LSP will expire before it is
   replaced. Further, as RemainingLifetime is decremented each time it
   is forwarded, an LSP far from it's 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, minimumLSPTransmis-
   sionInterval, 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 it's value of
   MaxAge to discard LSPs from peers.

   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 of 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."

6.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 moni-
   tor 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

Parker                  Expires December 2002                   [Page 4]

Internet Draft - draft-ietf-isis-interoperable                 June 2002

   adjacency is removed.

   ISO 10589 [1] 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 vari-
   able 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.

   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 less stable, and may cause adjacencies to

7. Variables Which Are Constant

   Some that were defined as variables in ISO 10589 [1] do not vary in
   practice.  These include

     (1)  ID Length - the length of the SystemID

     (2)  maximumAreaAddresses

7.1 ID Length

   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.  Moreover, new IS-IS
   TLVs such as the Traffic Engineering TLVs, assume a 6 byte System ID,
   so choices other than 6 are difficult to support. Implementations may
   interoperate without being able to deal with System IDs of any length
   other than 6.

   An implementation SHOULD use an ID Length of 6, and SHOULD 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, it SHOULD

Parker                  Expires December 2002                   [Page 5]

Internet Draft - draft-ietf-isis-interoperable                 June 2002

   discard the PDU, and MAY generate an appropriate notification.  ISO
   10589 [1] defines the notification iDFieldLengthMismatch, while the
   ISIS MIB [9] defines the notification isisIDLenMismatch.

7.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 sup-
   port DECnet PhaseIV addresses as well as OSI addresses during a tran-

   ISO 10589 [1] requires that all Intermediate Systems in an area or
   domain use a consistent value for maximumAreaAddresses.  Common prac-
   tice is for an implementation to always use the value 3. Therefore an
   implementation that only supports 3 can expect to interoperate suc-
   cessfully 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, and it SHOULD generate an appropriate match.  ISO 10589 defines
   the notification maximumAreaAddressMismatch, while the ISIS MIB [8]
   defines the notification isisMaxAreaAddressesMismatch.

8. Unused Features

   Some features defined in ISO 10589 [1] and RFC 1195 [3] are not in
   current use.

8.1 Inter-Domain Routing Protocol Information TLV, Code 131

   RFC 1195 defines an Inter-Domain Routing Protocol Information TLV,
   with code 131, designed to convey information transparently between
   boundary routers. TLV 131 is not used, and SHOULD be ignored.

Parker                  Expires December 2002                   [Page 6]

Internet Draft - draft-ietf-isis-interoperable                 June 2002

8.2 Authentication TLV, Code 133

   RFC 1195 defines an authentication TLV, code 133, which contains
   information used to authenticate the PDU. This TLV has been replaced
   by TLV 10, described in "IS-IS Cryptographic Authentication" [5].
   TLV 133 is not used, and SHOULD be ignored.

8.3 Alternative Metrics

   Section 7.2.2, ISO 10589 [1] 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.

   This bit was always 0 for the default metric, which was always sup-
   ported.  RFC 2966 [6] uses this bit in the default metric to mark L1
   routes that have been leaked from L1 to L2 and back down into L1

   Implementations MUST generate the default metric when using narrow
   metrics, and SHOULD ignore the other three metrics when using narrow

9. Overload Bit

   To deal with transient problems that prevent an IS from storing all
   the LSPs it receives, [1] 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 of [1] instructs other sys-
   tems 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.  How-
   ever, an overloaded router may be used to reach End Systems directly
   attached to the router, as it may provide the only path to an End

   The ability to signal reduced knowledge is so useful that the meaning
   of this flag has been overloaded. In a Service Provider's network,
   when a router running BGP and IS-IS reboots, BGP might take more time
   to converge than IS-IS. Thus the router may drop traffic for

Parker                  Expires December 2002                   [Page 7]

Internet Draft - draft-ietf-isis-interoperable                 June 2002

   destinations not learned via BGP. It is convenient to set the Over-
   load Bit until BGP has converged, as described in "Intermediate Sys-
   tem to Intermediate System (IS-IS) Transient Blackhole Avoidance"

   An implementation MAY use the Overload Bit to signal that it is not
   ready to accept transit traffic.

   RFC 1195 [3] makes clear when describing the SPF algorithm for IP
   routers in section C.1.4 that directly connected IP subnetworks are
   reachable when an IS is overloaded.

          Note that the End Systems neighbors of the system P includes
          IP reachable address entries included in the LSPs from system

   When processing LSPs received from a router which has the Overload
   bit set in LSP number Zero, the receiving router SHOULD treat all IP
   reachability advertisements as directly connected and use them in its
   SPF computation.

   Since the IP prefixes that an overloaded router announces will be
   treated as directly attached, an overloaded router SHOULD take care
   in selecting which routes to advertise in the LSPs it generates.

10. 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

   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
          may differ from the MTU available to IP clients.

   ISO 10589 [1] 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                  Expires December 2002                   [Page 8]

Internet Draft - draft-ietf-isis-interoperable                 June 2002

   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 originat-
   ing 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 data-
   base 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.

   The steps below are recommended when changing ReceiveLSPBufferSize.

     (1)  Set the ReceiveLSPBufferSize to a consistent value throughout
          the network.

     (2)  The implementation SHOULD 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,
          as described in section 9.8 of [2].

     (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 Notifica-
          tions and Alarms.

Parker                  Expires December 2002                   [Page 9]

Internet Draft - draft-ietf-isis-interoperable                 June 2002

     (5)  Report the receipt of a PDU larger than the local ReceiveL-
          SPBufferSize 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 miscon-
          figured 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.

11. 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 ReceiveLSPBuf-
   ferSize, section 8.2.3 of [1] requires padding on point-to-point

   On point-to-point links, the initial IIH is to be padded to the max-
   imum of

     (1)  Link MTU

     (2)  originatingL1LSPBufferSize if the link is to be used for L1

     (3)  originatingL2LSPBufferSize if the link is to be used for L2

   In section 6.7.2 e) ISO 10589 [1] assumes

          Provision that failure to deliver a specific subnetwork SDU
          will result in the timely disconnexion of the subnetwork con-
          nection 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.  If the PDU was too
   big to be received, the link would be reset. However, link layer pro-
   tocols in use on point-to-point circuits today often lack this ser-
   vice.  Therefore, the requirement that only the initial IIH be padded
   is inadequate.

   If an implementation is using padding to detect problems, point-to-

Parker                  Expires December 2002                  [Page 10]

Internet Draft - draft-ietf-isis-interoperable                 June 2002

   point IIH PDUs SHOULD be padded until the sender declares an adja-
   cency on the link to be in state Up. If the implementation implements
   [4] then this is when three-way state is Up: if the implementation
   use the "classic" algorithm described in [1], this is when adjacency-
   State is Up.  Transmission of padded IIH PDUs SHOULD be resumed when-
   ever 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 pro-
   vide 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, were they neighbors.

   The presence or absence of padding TLVs MUST NOT be one of the accep-
   tance tests applied to a received IIH regardless of the state of the

12. Migration from Narrow Metrics to Wide

   The IS-Neighbors TLV (TLV 2) as defined in ISO 10589 and the IP
   Reachability TLV (TLV 128/TLV 130) as defined in RFC 1195 provide a 6
   bit metric for the default link metric to the listed neighbor.  This
   metric has proved too limited.  The Extended IS-Neighbors TLV (TLV
   22) and the Extended IP Reachability TLV (TLV 135) are defined in
   [7].  The Extended IS-Neighbors TLV (TLV 22) defines a 24 bit metric,
   and the Extended IP Reachability TLV (TLV 135) defines a 32 bit

   If not all devices in the IS-IS domain support wide metrics, narrow
   metrics MUST continue to be used. Once all devices in the network are
   able to support the new TLVs containing wide metrics, the network can
   be migrated to the new metric style, though care must be taken to
   avoid routing loops.

   We make the following assumptions about the implementation:

     (1)  Each system can generate and understand both narrow and wide

     (2)  The implementation can run the SPF algorithm on an LSP DB with

Parker                  Expires December 2002                  [Page 11]

Internet Draft - draft-ietf-isis-interoperable                 June 2002

          instances of both metric styles.

     (3)  If there are two metric styles for a link or IP prefix, it
          will pick one of them as the true cost for the link.

   To compare the different variants of the narrow metric, we need an
   algorithm that translates different types of narrow metric into a
   common integer range. Since we have different computations for the L1
   and L2 routes, we only need to map metrics from a single level.

   In RFC 1195 [3] section 3.10.2, item 2c) states that The IP prefixes
   located in "IP External Reachability" with internal-metric and IP
   prefixes located in "IP Internal Reachability" with internal-metric
   have the same preference.  As defined in "Domain-wide Prefix Distri-
   bution with Two-Level IS-IS" [6], the Most Significant Bit on an L1
   metric tells us if the route has been leaked down, but does not
   change the distance. Thus we will ignore the MSBit.

   We interpret the default metric as an 7 bit quantity.  Thus metrics
   with the external bit set are treated as metrics in the range

12.1 Transition Algorithm

   The following steps are taken, in order:

     (1)  All routers advertise Narrow Metrics as defined in [1], and
          consider narrow metrics only in their SPF computation.

     (2)  Each system is configured in turn to send wide metrics as well
          as narrow metrics.  The two metrics for the same link or IP
          prefix SHOULD agree.

     (3)  When all systems are advertising wide metrics, make any
          changes necessary on each system to consider Wide Metrics dur-
          ing the SPF, and change MaxPathMetric to 0xfe000000.

     (4)  Each system is configured in turn to stop advertising narrow

     (5)  When the network is only using wide metrics, metrics on indi-
          vidual links may be rescaled to take advantage of the larger

Parker                  Expires December 2002                  [Page 12]

Internet Draft - draft-ietf-isis-interoperable                 June 2002

12.2 Dealing with Non-Equal Metrics

   The algorithm above assumes that the metrics are equal, and thus
   needs to make no assumption about which metric the SPF algorithm
   uses.  This section describes the changes that should be made to the
   SPF algorithm when both Narrow and Wide metric styles should be con-
   sidered. Using a common algorithm allows different implementations to
   compute the same distances independently, even if the wide and narrow
   metrics do not agree.

   The standard SPF algorithm proceeds by comparing sums of link costs
   to obtain a minimal cost path. During transition, there will be more
   than one description of the some links.  We resolve this by selecting
   the minimum metric for each link. This may give us a path with some
   links chosen due to a wide metric and some links chosen due to a nar-
   row metric.

   The description below is more complex than the implementation needs
   to be: the implementation may simply select the minimal cost neighbor
   in TENT, discarding paths to destinations we have already reached, as
   described in [1]

   The variables MaxPathMetric and MaxLinkMetric SHOULD retain the
   values defined in Table 2 of section 8 of [1].

   In C.2.5 Step 0 of the description of the SPF algorithm, section b)

          d(N) = cost of the parent circuit of the adjacency N

          If multiple styles of metric for the link are defined, the
          cost will be the minimum available cost for the circuit.

   In C.2.5 Step 0 of the description of the SPF algorithm, section i)

          d(N) = metric of the circuit

          If multiple styles of metric for the link are defined, the
          cost will be the minimum available cost for the circuit.

   In C.2.6 Step 1 of the description of the SPF algorithm, section a)

          dist(P,N) = d(P) + metric(P,N)

          If multiple styles of metric for the neighbor are defined, the
          cost will be the minimum available cost for the circuit.

Parker                  Expires December 2002                  [Page 13]

Internet Draft - draft-ietf-isis-interoperable                 June 2002

13. ISH

   The original intent of RFC 1195 [3] was to provide a routing protocol
   capable of handling both CLNS and IPv4 reachability information.  To
   allow CLNS Endstations (ES) to know that they are attached to a
   router, Intermediate Systems are required to send Intermediate System
   Hello PDUs (ISH) for End Stations when a point-to-point circuit comes
   up.  Furthermore, an IS is not allowed to send Intermediate System to
   Intermediate System Hello PDUs (IIH) before receiving an ISH from a
   peer.  This reduces routing protocol traffic on links with a single

   For this reason section 5.1 [3] states:

          "On point-to-point links, the exchange of ISO 9542 ISHs
          (intermediate system Hellos) is used to initialize the link,
          and to allow each router to know if there is a router on the
          other end of the link, before IS-IS Hellos are exchanged.  All
          routers implementing IS-IS (whether IP-only, OSI-only, or
          dual), if they have any interfaces on point-to-point links,
          must therefore be able to transmit ISO 9542 ISHs on their
          point-to-point links."

   Section 5.1 [3] reinforces the need to comply with section 8.2.4 of
   ISO 10589 [1]. However, in an IP Only environment, the original need
   for the ISH PDU is not present.

   A multi-protocol IS that supports the attachment of CLNS ESs over
   Point to Point circuits must act in accordance with section 8.2.2 [1]
   when CLNS functionality is enabled.

   An IP Only implementation should issue an ISH PDU as described in
   section 8.2.3 of [1].  This is to inter-operate with implementations
   which require an ISH to initiate the formation of an IS-IS adjacency.

   An IP Only implementation may issue an IIH PDU when a point to point
   circuit transitions into an "Up" state to initiate the formation of
   an IS-IS adjacency, without sending an ISH PDU.  However, this may
   not inter-operate with implementations which require an ISH for adja-
   cency formation.

   An IS may issue an IIH PDU in response to the receipt of an IIH PDU
   in accordance with section [1], even though it has not
   received an ISH PDU.

Parker                  Expires December 2002                  [Page 14]

Internet Draft - draft-ietf-isis-interoperable                 June 2002

14. The Attached Bit

   In section of ISO 10589 [1], an algorithm is described to
   determining when the attachedFlag should be set on an intermediate
   system. Some implementations also allow the attachedFlag to be set on
   Intermediate Systems routing IP traffic when there is a default route
   in the local routing table, when some other state is reached that
   implies a connection to the rest of the network.

15. Default Route

   RFC1195 [3] states in section 1.3:

          Default routes are permitted only at level 2 as external
          routes (i.e., included in the "IP External Reachability Infor-
          mation" field, as explained in sections 3 and 5).  Default
          routes are not permitted at level 1.

   Because of the utility of the default route when dealing with other
   routing protocols and the ability to influence the exit point from an
   area, default routes can be generated into level 1 in most implemen-

16. Zero Checksum

   A checksum of 0 is impossible if the checksum is computed according
   to the rules of ISO 8473.

   ISO 10589 [1], section, 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.

   However, 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.

17. Purging Corrupted PDUs

   While ISO 10589 [1] requires in section 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.

Parker                  Expires December 2002                  [Page 15]

Internet Draft - draft-ietf-isis-interoperable                 June 2002

   In [2], Section, 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.

18. Non-homogeneous Protocol Networks

   RFC 1195 [3] assumes that every deployment of IS-IS routers will sup-
   port a homogeneous set of protocols. It anticipates OSI only, IP
   only, or dual OSI and IP routers. While it allows mixed areas with,
   for example, both pure IP and Dual IP and OSI routers, it allows only
   IP traffic in such domains, and OSI traffic only when pure OSI and
   Dual IP and OSI routers are present. Thus it provides only lowest
   common denominator routing.

   Also required in [3] is the inclusion of the Protocol Supported TLV
   with code 129 in IIH and ISH PDUs and LSP number Zero. IP capable
   routers MUST generate a Protocol Supported TLV, and include the IP
   protocol as a supported protocol. A router that does not include the
   Protocols Supported TLV may be assumed to be a pure OSI router and
   can be interpreted as implicitly "advertising" support for the OSI

   The requirements of [3] are ample if networks adhere to this restric-
   tion. However, the behavior of mixed networks that do not follow
   these guidelines is not well defined.

   The ITU-T requires that SONET/SDH equipment running the IS-IS proto-
   col must not form an adjacency with a neighbour unless they share at
   least one network layer protocol in common. Unless this feature is
   present in every IS in the SONET or SDH DCN network the network may
   not function correctly. Implementors MAY include this feature if they
   wish to ensure interoperability with SONET and SDH DCN networks.

   Definition of an interoperable strategy for resolving the problems
   that arise in non-homogeneous protocol remains incomplete. Members of
   the ITU are actively working on a proposal: see "Architecture and
   Specification of Data Communication Network", [10].

Parker                  Expires December 2002                  [Page 16]

Internet Draft - draft-ietf-isis-interoperable                 June 2002

19. Adjacency Creation and IP Interface Addressing

   RFC 1195 [3] states that adjacencies are formed without regard to IP
   interface addressing. However, many current implementations refuse
   adjacencies based on interface addresses and related issues.

   In section 4.2 [3] requires routers with IP interface addresses to
   advertise the addresses in an IP Interface Address TLV (132) carried
   in IIH PDUs. Some implementations will not interoperate with a neigh-
   bor router that does not include the IP Interface Address TLV.
   Further, some implementations will not form an adjacency on broadcast
   interfaces with a peer who does not share an interface address in
   some common IP subnetwork.

   If a LAN contains a mixture of implementations, some that form adja-
   cencies with all neighbors and some that do not, care must be taken
   when assigning IP addresses.  If not all routers in a LAN are on the
   same IP subnet, it is possible that DIS election may fail, leading to
   the election of multiple DISs on a LAN, or no DIS at all. Even if DIS
   election succeeds, black holes can result because the IS-IS LAN tran-
   sitivity requirements of section 6.7.3 [1] are not met.

   Unnumbered point to point links do not have IP interface addresses,
   though they may have other IP addresses assigned to the routers.  The
   IP address assigned to two routers that are neighbors on an unnum-
   bered point to point link do not need to be related.  However, some
   implementations will not form an adjacency on numbered point to point
   links if the interface addresses of each endpoint are not in the same
   IP subnetwork.  This means that care must be taken in assigning IP
   interface addresses in all networks.

   For an implementation to interoperate in a such mixed environment, it
   SHOULD include TLV 132 in its IIH PDUs. The network administrator
   should ensure that there is a common IP subnet assigned to links with
   numbered interfaces, and that all routers on each link have a IP
   Interface Addresses belonging to the assigned subnet.

20. Checking System ID in Received point-to-point IIH PDUs

   In section, ISO 10589 [1] does not explicitly require com-
   parison 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

Parker                  Expires December 2002                  [Page 17]

Internet Draft - draft-ietf-isis-interoperable                 June 2002


   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 guaran-
   tees 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 [draft-ietf-isis-wg-snp-checksum-03 11] may be used
   to detect such corruption: corrupted PDUs SHOULD be dropped.

   Some implementations have chosen to discard received IIHs where the
   source ID differs from the neighbourSystemID. This may prevent need-
   less 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
   [1] after a System ID change, or resets the 3-way adjacency state, as
   anticipated in "Three-Way Handshake for IS-IS Point-to-Point Adjacen-
   cies" [4].

21. Security Implications

   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] and RFC 1195 [3].

22. References

[1]  ISO, "Intermediate system to Intermediate system routeing informa-
     tion exchange protocol for use in conjunction with the Protocol for
     providing the Connectionless-mode Network Service (ISO 8473),"
     ISO/IEC 10589:1992.

[2]  ISO, "Intermediate system to Intermediate system routeing informa-
     tion exchange protocol for use in conjunction with the Protocol for
     providing the Connectionless-mode Network Service (ISO 8473),"
     ISO/IEC 10589:2001.

[3]  Callon, R., "OSI IS-IS for IP and Dual Environment," RFC 1195,
     December 1990.

[4]  Katz, D. and Saluja, R., "Three-Way Handshake for IS-IS Point-to-

Parker                  Expires December 2002                  [Page 18]

Internet Draft - draft-ietf-isis-interoperable                 June 2002

     Point Adjacencies", draft-ietf-isis-3way-06.txt, April 2002.

[5]  Li, T., Atkinson, R. J., "IS-IS Cryptographic Authentication",
     draft-ietf-isis-hmac-03.txt, July 2001.

[6]  Li, T., Przygienda, T., "Domain-wide Prefix Distribution with Two-
     Level IS-IS", RFC 2966, October 2000.

[7]  Li, T. and Smit, H., "IS-IS extensions for Traffic Engineering",
     draft-ietf-isis-traffic-04.txt, August 2001.

[8]  McPherson, D., "Intermediate System to Intermediate System (IS-IS)
     Transient Blackhole Avoidance", RFC 3277, April 2002.

[9]  Parker, J., "Management Information Base for IS-IS", draft-ietf-
     isis-wg-mib-08.txt, May 2002.

[10] ITU, "Architecture and Specification of Data Communication Net-
     work", ITU-T Recommendation G.7712/Y.1703, November 2001

[11] Przygienda, T., "Optional Checksums in ISIS", draft-ietf-isis-wg-
     snp-checksum-03.txt, April 2002.

23. Author's Addresses

   Jeff Parker
   Axiowave Networks
   200 Nickerson Road
   Marlborough, Mass 01752
   e-mail: jparker@axiowave.com

24. Full Copyright Statement

   Copyright (C) The Internet Society (1997).  All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of

Parker                  Expires December 2002                  [Page 19]

Internet Draft - draft-ietf-isis-interoperable                 June 2002

   developing Internet standards in which case the procedures for copy-
   rights defined in the Internet Standards process must be followed, or
   as required to translate it into languages other than English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an

Parker                  Expires December 2002                  [Page 20]

Html markup produced by rfcmarkup 1.124, available from https://tools.ietf.org/tools/rfcmarkup/