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

Versions: 01

          ISIS Working Group                                  Chris Gunner
          Internet-draft                           Digital Equipment Corp.
          
                                                           Doug Montgomery
                                           National Institute of Standards
                                                     and Technology (NIST)
          
                                                                 July 1994
          
          
          
          
                    Experience with the Integrated ISIS Protocol
                           (draft-ietf-isis-opexp-01.txt)
          
          
          
          
          
                                  Table of Contents
          
          
           1.  Status of this Memo                                    2
           2.  Abstract                                               2
           3.  Introduction                                           2
           3.1.  General Requirements                                 3
           3.2.  Specific Requirements for Draft Standard             4
           4.  Documentation                                          5
           5.  MIB                                                    6
           6.  Security architecture                                  7
           7.  Implementations                                        7
           8.  Operational Experience                                 8
           8.1.  Case A                                               9
           8.2.  Case B                                              10
           8.3.  Case C                                              11
           8.4.  Case D                                              12
           9.  Interoperability Testing                              12
           9.1.  Interoperability Testing Methodology                12
           9.1.1.  Protocol Functions Tested                         13
           9.1.2.  Evaluation of Interoperability                    14
           9.2.  Testing Sessions                                    14
           9.2.1.  August 1991 DIS-level Implementation Testing      15
           9.2.2.  February 1992 IS-level Implementation Testing     18
           9.2.3.  Spring 1992 Interop Demonstration                 21
           9.2.4.  Fall 1992 Interop Demonstration Hot Stage         22
           10.  References                                           23
           11.  Acknowledgements                                     24
           12.  Working Group Information                            24
           13.  Author's Addresses                                   25
          
          
          
          
          
          
          
          
          Gunner    (Internet-Draft expires end December 1994)    [Page 1]


          Internet-Draft   Experience with Integrated ISIS       July 1994
          
          
          
          1. Status of this Memo
          
          This document is an Internet-Draft. 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-Drafts.
          
          Internet-Drafts are draft documents valid for a maximum of six
          months. Internet-Drafts may be updated, replaced, or obsoleted
          by other documents at any time. It is not appropriate to use
          Internet-Drafts as reference material or to cite them other
          than as a "working draft" or "work in progress."
          
          To learn the current status of any Internet-Draft, please check
          the 1id-abstracts.txt listing contained in the Internet-Drafts
          Shadow Directories on ds.internic.net, nic.nordu.net,
          ftp.nisc.sri.com, or munnari.oz.au.
          
          
          2. Abstract
          
          This document is one of two reports on the Integrated ISIS
          protocol. The other report documents an analysis of the
          protocol. These two reports are required by the IAB/IESG in
          order for an Internet routing protocol to advance to Draft
          Standard Status. Integrated ISIS is an Interior Gateway Protocol
          and is designed to carry both IP and ISO CLNP routing
          information.
          
          Integrated ISIS is currently designated as a Proposed Standard.
          The protocol was first published in RFC 1195. Internet Draft [2]
          was published subsequently to RFC 1195 and documents the current
          version of the protocol.
          
          This report documents experience with Integrated ISIS. This
          includes reports on interoperability testing, field experience
          and the current state of Integrated ISIS implementations. It
          also presents a summary of the Integrated ISIS Management
          Information Base (MIB), and a  summary of the Integrated ISIS
          authentication mechanism.
          
          Please send comments to isis@merit.edu.
          
          
          3. Introduction
          
          This document addresses, for Integrated ISIS, the requirements
          set forth  by the IAB/IESG for an Internet routing protocol to
          advance to Draft Standard state. These requirements are
          summarized below. The remaining sections of this report document
          
          
          
          Gunner                                                  [Page 2]


          Internet-Draft   Experience with Integrated ISIS       July 1994
          
          
          
          how Integrated ISIS satisfies these requirements.
          
          
          3.1. General Requirements
          
          1.  Documents specifying the Protocol and its Usage. This may
              be one or more documents. The specifications for the
              routing protocol must be well written such that
              independent, interoperable implementations can be developed
              solely based on the specification. For example, it should
              be possible to develop an interoperable implementation
              without consulting the original developers of the routing
              protocol.
          
          2.  A Management Information Base (MIB) must be written for the
              protocol.  Routing protocols, like all other Internet
              protocols, need a MIB defined so they can be remotely
              managed.
          
          3.  A security architecture of the protocol must be defined.
              The security architecture must include mechanisms for
              authenticating routing messages and may include other
              forms of protection.
          
          4.  Generally, a number of interoperable implementations must
              exist. At least two must be written independently.
          
          5.  There must be evidence that all features of the protocol
              have been tested, running between at least two
              implementations. This must include that all of the security
              features have been demonstrated to operate, and that the
              mechanisms defined in the protocol actually provide the
              intended protection.
          
          6.  There must be operational experience with the routing
              protocol. The level of operational experience required is
              dependent on which level of standardization is requested.
              All significant features of the protocol must be exercised.
              In the  case of an Interior Gateway Protocol (IGP), both
              interior and exterior routes must be carried (unless
              another mechanism is provided for the exterior routes). In
              the case of a Exterior Gateway Protocol (EGP), it must
              carry the full complement of exterior routes.
          
          7.  Two reports must be submitted to the IESG via the Routing
              Area Director. The first report must document how
              requirements 1) through 6) of this document have been
              satisfied. It must include:
          
              a.  Implementation experience.
          
          
          
          Gunner                                                  [Page 3]


          Internet-Draft   Experience with Integrated ISIS       July 1994
          
          
          
              b.  Reference to the MIB for the protocol.
          
              c.  Description of the authentication mechanisms in the
                  protocol.
          
              d.  List of implementations including origin of code.
          
              e.  Test scenarios and test results showing that all
                  features of the protocols have been tested.
          
              f.  Description of operational experience. This must
                  include topology, environment, time and duration,
                  implementations involved, and overall results and
                  conclusions gained from the operational experience.
          
              The second report must summarize the key features of the
              protocol and analyze how the protocol will perform and
              scale in the  Internet. The intent of this requirement is
              to understand the  boundary conditions of the routing
              protocol. The new routing  protocol must be compared with
              the existing routing protocols  (e.g., RIP, EGP, etc.) as
              appropriate. The report should answer several questions:
          
              g.  What are the key features and algorithms of the
                  protocol?
          
              h.  How much link bandwidth, router memory and router CPU
                  cycles does the protocol consume under normal
                  conditions?
          
              i.  For these metrics, how does the usage scale as the
                  routing environment grows? This should include
                  topologies at least an order of magnitude larger than
                  the current environment.
          
              j.  What are the limits of the protocol for these metrics?
                  (I.e., when will the routing protocol break?)
          
              k.  For what environments is the protocol well suited, and
                  for what is it not suitable?
          
          The IESG will forward to the IAB its recommendation for advancement
          of the new routing protocol based on its evaluation of protocol
          specifications and these reports.
          
          3.2. Specific Requirements for Draft Standard
          
          1.  Revisions to the Protocol and Usage documents showing
              changes and clarifications made based on experience gained
              in the time between when the protocol was made a Proposed
          
          
          
          Gunner                                                  [Page 4]


          Internet-Draft   Experience with Integrated ISIS       July 1994
          
          
          
              Standard and it being submitted for Draft Standard. The
              revised documents should include a section summarizing the
              changes made.
          
          2.  The Management Information Base (MIB) must be at the
              Proposed Standard level of standardization.
          
          3.  There must be significant operational experience. This must
              include running in a moderate number of routers configured
              in a moderately complex topology, and must be part of  the
              operational Internet. All significant features of the
              protocol must be exercised. In the case of an Interior
              Gateway Protocol (IGP), both interior and exterior routes
              must be carried (unless another mechanism is provided for
              the exterior routes). In the case of a Exterior Gateway
              Protocol (EGP), it must carry the full complement of
              exterior routes.
          
          
          4. Documentation
          
          The Integrated ISIS protocol is an extension of the ISIS
          protocol defined by ISO 10589. The first definition of
          Integrated ISIS which was documented in RFC 1195 was based on
          the DP version of the ISO standard. In developing Integrated
          ISIS some revisions to the ISO standard were suggested and
          defined in RFC 1195. These were incorporated into ISO 10589 with
          the result that the definitions in RFC 1195 were no longer
          necessary. Hence an Internet Draft exists for Integrated ISIS
          which defines the protocol as derived from the ISO 10589 version
          of ISIS.
          
          The details of what changed between RFC 1195 and the Internet
          Draft are described in [4]. The implementations and testing
          described in this document were all based on the RFC 1195
          definition of the Integrated additions to the base protocol.
          They were initially based on the DIS 10589 definition of the
          base ISIS protocol. Subsequent implementations and testing were
          based on the standard ISO 10589 definition of the base protocol
          (see section 9.1 for details).
          
          The Integrated ISIS protocol was developed by the ISIS Working
          Group of the Internet Engineering Task Force (IETF). This
          Working Group has a mailing list, isis@merit.edu, where
          discussions of protocol features and operation are held. The
          ISIS Working Group also meets during the quarterly Internet
          Engineering Task Force conferences. Reports of these meetings
          are published in the IETF's Proceedings.
          
          A Management Information Base (MIB) for the protocol has been
          
          
          
          Gunner                                                  [Page 5]


          Internet-Draft   Experience with Integrated ISIS       July 1994
          
          
          
          developed and published as an Internet Draft [3]. There have
          been 4 revisions of this MIB. For more information see section 5
          of this document.
          
          There is a public-domain implementation of Integrated ISIS
          available from the University of Wisconsin. This implementation
          has been incorporated into the public-domain gated program.
          
          
          5. MIB
          
          A Management Information Base for Integrated ISIS has been
          published as an Internet Draft [3]. The latest draft is the
          fourth version of the MIB.
          
          The MIB is based on the managed object definitions defined in
          ISO's GDMO and contained in ISO 10589 and parts of ISO 10733. A
          design goal of the MIB was that it provide equivalent
          functionality as that in the ISO standards. This results in a
          large MIB since the ISO standards provide richer functionality
          than that traditionally found in MIBs, for example, the ability
          to dynamically create and delete table rows and generally
          provide full configuration control. The MIB provides complete
          management for both the base ISIS protocol and the Integrated
          ISIS protocol
          
          A partial implementation of the MIB has been developed by Novell
          (level 1 and OSI only). A second implementation has been
          developed by Interactive Systems Corp.
          
          The MIB provides full configuration and monitoring control for
          the protocol. It supports multiple instances of the protocol
          running on the same system.
          
          The MIB consists of 17 groups and 214 objects of which:
          
          -   4 groups (106 objects ) are mandatory
          
          -   13 are optional depending on the functions supported by the
              instance of the protocol:
          
                 5 groups (29 objects) must be supported if the instance
                  supports IP
          
                 2 groups (14 objects) must be supported if the instance
                  supports OSI at level 1
          
                 1 group (8 objects) must be supported if the instance
                  supports OSI at level 2
          
          
          
          
          Gunner                                                  [Page 6]


          Internet-Draft   Experience with Integrated ISIS       July 1994
          
          
          
                 2 groups (10 objects) must be supported if the instance
                  supports the authentication functions
          
                 1 group (10 objects) must be supported if the instance
                  supports the partition repair function
          
                 2 groups (37 objects) may be supported if the instance
                  wishes to support static route configuration
          
          
          6. Security architecture
          
          Integrated ISIS provides the option of carrying authentication
          information in all the protocol's packets. The encoding is
          extensible to multiple authentication mechanisms. However,
          currently the only defined mechanism is a simple password,
          transmitted without encryption. This use of a simple password
          does not provide useful protection against intentional
          misbehaviour. Rather, this should be thought of as a weak
          protection against accidental errors such as misconfiguration.
          
          The protocol and MIB permit separate passwords for each circuit,
          each area and the domain. Also, although only a single password
          can be configured for inclusion in transmitted packets, a set of
          passwords can be configured for reception. This makes migration
          from one password to another simple. The process is to add the
          new password to the reception set on each router in turn, then
          change the transmission password on each router in turn and
          finally to remove the old password from the reception set on
          each router. During this process no change in the routing
          topology need occur.
          
          Since the encoding of the authentication option is extensible to
          other mechanisms, the protocol can be enhanced in a backwards
          compatible fashion to support stronger authentication should
          that be required.
          
          
          7. Implementations
          
          There are multiple interoperable implementations of Integrated
          ISIS currently available. This section gives a brief overview of
          the six implementations that are known to have taken part in
          interoperability testing. Other implementations also exist or
          are in development.
          
          The six implementations that are known to have undergone
          interoperability testing are (listed in alphabetical order):
          
          -   3com. This implementation was wholly developed by 3com. It
          
          
          
          Gunner                                                  [Page 7]


          Internet-Draft   Experience with Integrated ISIS       July 1994
          
          
          
              has participated in the Interop fall '92 demonstration and
              NIST interoperability testing.
          
          -   Cisco. This implementation was wholly developed by Cisco.
              It has participated in the Interop fall '92 demonstration
              and NIST interoperability testing.
          
          -   Digital. This implementation was wholly developed by
              Digital. It has participated in the Interop fall '92
              demonstration and NIST interoperability testing.
          
          -   Phase 2 Networks. This implementation was wholly developed
              by Phase 2 Networks. It has participated in the Interop
              Fall '92 demonstration and NIST interoperability testing.
          
          -   Proteon. This implementation was wholly developed by
              Proteon. It has participated in the Interop Fall '92
              demonstration and NIST interoperability testing.
          
          -   University of Wisconsin. This implementation was developed
              wholly by the University of Wisconsin. It has participated
              in the early ISIS testing conducted by NIST. This version
              is in the public domain and has been incorporated into
              gated.
          
          In addition to these there are implementations of the base ISIS
          protocol which have participated in interoperability testing at
          NIST. These are:
          
          -   Wellfleet
          
          -   Fibercom
          
          -   Retix
          
          -   Novell
          
          Note that, as required by the IAB/IESG for Draft standard
          status, there are multiple interoperable independent
          implementations of Integrated ISIS, namely those from 3com,
          Cisco, Digital, Phase 2 Networks, Proteon and the University of
          Wisconsin.
          
          
          8. Operational Experience
          
          This section describes some examples of significant operational
          experience with the protocol. Since Integrated ISIS is a
          derivation of the ISIS protocol, most of the core algorithms and
          protocol are common to both ISIS and Integrated ISIS. However,
          
          
          
          Gunner                                                  [Page 8]


          Internet-Draft   Experience with Integrated ISIS       July 1994
          
          
          
          the operational experience reported here is restricted to
          deployments using Integrated ISIS (those using ISIS are not
          considered). The interoperability testing includes both ISIS and
          Integrated ISIS testing since most aspects of the ISIS testing
          are relevant to showing that Integrated ISIS is interoperable.
          
          As can be seen from the sections below, the protocol has been in
          use in some reasonable size networks for a significant time. In
          no case has there been a significant problem with the protocol.
          
          
          8.1. Case A
          
          This deployment in a large research network has been following a
          migration plan from DECnet Phase IV and IP to DECnet Phase V and
          IP over the last few years. Currently I ISIS is in use only on
          Digital routers of which there are approximately 38 split into
          12 level 2 routers and 26 level 1 routers. These are in two
          different areas with 6 level 2 and 5 level 1 routers in one area
          and 6 level 2 and 21 level 1 routers in the other area. Note
          that all level 2 routers are also level 1 routers.
          
          A small number of the level 1 routers are currently running ISIS
          (i.e. not Integrated ISIS) even though they are in the same area
          as the I ISIS routers. This is technically in violation of the
          topology restriction defined in RFC 1195 which state that all
          routers in an area of all the level 2 routers must be either
          ISIS only or be I ISIS only. The reason for this restriction is
          that an ISIS only router that was on the path between two I ISIS
          routers would not be able to forward IP packets sent to it
          consistently with the I ISIS routers (if at all). In this
          network the ISIS only routers are only at stubs of the area
          where there is no IP traffic to be routed and this has proved to
          work correctly.
          
          There are approximately 600 endnodes in each of the two areas.
          Most of these run DECnet Phase IV and IP and some run DECnet
          Phase V and IP.
          
          The network migration is currently in the stage of migrating a
          larger number of Cisco routers to also run I ISIS so that at the
          end of this stage there will be approximately 130 routers
          running I ISIS.
          
          The current network topology for the Digital I ISIS routers is a
          partial mesh of Ethernet and point to point links (at various
          speeds: 19.2kbps, 64kbps, 128kbps, 256kbps, 512 kbps).
          
          In some cases the routers running I ISIS are configured to not
          announce reachability to any IP Addresses. This was done to
          
          
          
          Gunner                                                  [Page 9]


          Internet-Draft   Experience with Integrated ISIS       July 1994
          
          
          
          avoid the subnets to which the router attached being announced
          into the I ISIS domain. These subnets were being announced by
          other routers using other IP routing protocols already. In these
          cases these routers forwarded IP traffic as expected.
          
          The network also currently has a larger number (70 or so)
          routers (mostly Ciscos) which are doing IP routing using Cisco's
          IGRP. Exchange of IP routes between the IGRP and I ISIS routers
          is done either using RIP, since that is a protocol common to
          both, or using static routes. In the RIP case the I ISIS domain
          propagates all its routes into RIP while the IGRP domain
          propagates just a default route into the I ISIS domain. The IGRP
          domain is connected to the Internet.
          
          One problem that this network had was in managing the default
          route within an area. A restriction of the Digital routers meant
          that a default route originated on a level 2 router was always
          at level 2, while on a level 1 router it was always at level 1.
          Because of the precedence of routes in I ISIS this meant that
          for that area, the default route at level 1 was always
          preferred, regardless of metric, over the default route at level
          2. This is the opposite of what would normally be required. This
          is not really a problem with the I ISIS protocol but indicates
          the flexibility that is required in the configuration controls
          for the routers. In this case implementations should make sure
          they permit the configuration of which level routes are
          announced into on a level 2 router.
          
          The use of I ISIS in this network has been operational for
          approximately 6 months.
          
          
          8.2. Case B
          
          This commercial deployment has 21 Digital routers all running
          Integrated ISIS. All routers are configured as level 2. Note
          that all level 2 routers are also level 1 routers. A main
          Ethernet LAN has eight I ISIS routers attached together with 10
          other IP-only routers (from various vendors: Cisco, 3Com, Sun)
          which exchange RIP with most of the Digital I ISIS routers. The
          other routers are connected through a mix of 56kbps and 384kbps
          point to point links in a partial mesh such that no single link
          failure will partition the network. At each of the 13 branch
          sites there is an Ethernet LAN. All the point-to-point links use
          the DDCMP data link protocol over which I ISIS uses the same
          point-to-point subnetwork convergence functions as over an HDLC
          link. Throughout the network there are approximately 900
          endnodes of various types: 15 OSI, 200 DECnet Phase IV, 500 IP,
          200 IPX (whose traffic is tunnelled through IP).
          
          
          
          
          Gunner                                                 [Page 10]


          Internet-Draft   Experience with Integrated ISIS       July 1994
          
          
          
          The network has 14 sites, each of which has a separate OSI Area
          Address and a separate IP subnet address (using a single
          subnetted class B network address with a single network-wide
          subnet mask).
          
          The I ISIS routers that exchange RIP with the IP-only routers
          operate RIP in send and receive mode and propagate routes from I
          ISIS to RIP and from RIP to I ISIS. They are configured to
          accept the default route from RIP but not to announce it in RIP.
          
          The network has a single connection to the Internet via an
          endnode. Therefore there is no route propagation to or from the
          Internet.
          
          The average traffic load over the network (including all network
          protocols) is approximately 300Mbytes per day.
          
          The overall network uptime has been over 99%. Link failures have
          averaged one per month. These failures have not caused any
          problems with the applications.
          
          There have been a few designated router changeovers (caused by
          manual intervention rather than failure). During a changeover
          there has been no problem with the applications. The changeover
          process completes within a few seconds.
          
          This network has now been operational for two years.
          
          
          8.3. Case C
          
          This commercial deployment includes Digital routers running
          Integrated ISIS and routers from Cisco, Wellfleet and NSC
          running IP only. The network is a partial mesh of Ethernet, FDDI
          and point to point links (at 256kbps and 512kbps). There are
          over 2000 endnodes in the network mostly running IP and/or
          DECnet Phase IV with 5 OSI endsystems.
          
          All the I ISIS routers are configured as level 2. Note that all
          level 2 routers are also level 1 routers. Static IP routes are
          used between some I ISIS routers and some IP-only routers. In
          some cases the circuit metrics were changed from their default
          values to create the desired traffic patterns. Convergence of
          the protocol after link failures has not been a problem.
          
          There are approximately 28 IP subnets with varying subnet masks
          in use.
          
          This network is not connected to the Internet.
          
          
          
          
          Gunner                                                 [Page 11]


          Internet-Draft   Experience with Integrated ISIS       July 1994
          
          
          
          This network has now been operational for over 1 year
          
          
          8.4. Case D
          
          This commercial deployment has 15 Digital routers. These are
          interconnected via a mix of 64kbps and 2Mbps WAN links. All
          routers are running Integrated ISIS. The network has been
          operational for over 8 months.
          
          
          9. Interoperability Testing
          
          There have been four testing sessions of the protocol hosted by
          NIST. These are described in detail in the sections below. For
          the first three sessions, only the base ISIS protocol was
          tested. The fourth session was conducted prior to the Fall '92
          Interop demonstration and included testing I ISIS.
          
          The information in this section is derived from reference [9].
          
          The following provides a broad summary of the scope of the
          interoperability testing activities:
          
          -   NIST testing has involved 21 distinct ISs, representing 16
              distinct models/products from 11 distinct
              vendors/implementors (3Com, Cisco, Digital, Fibercom, IBM,
              Novell, Phase2 Networks, Retix, Proteon, University of
              Wisconsin, Wellfleet). The range of products tested has
              spanned the spectrum from PC-based LAN routers to FDDI
              capable backbone routers.
          
          -   IS-IS routers have been connected using LANs (802.3, 802.5,
              and FDDI), point-to-point links (PPP, LAPB, and
              proprietary) and X.25.  To date, only the various LAN
              technologies have been thoroughly tested with significant
              multi-vendor interconnections.
          
          -   The testing environment has employed ESs from 7 vendors
              (3Com, Apple, Digital, Hewlett-Packard, NCR, Novell, Sun
              Microsystems).  These ESs have been used to test the
              interaction between host protocols (ES-IS, CLNP, IP, ICMP)
              and the IS-IS routing protocol.
          
          
          9.1. Interoperability Testing Methodology
          
          NIST ISIS interoperability testing has been conducted on an
          informal basis. The primary objectives of the testing has been
          to foster mature commercial implementations of OSI-based routing
          
          
          
          Gunner                                                 [Page 12]


          Internet-Draft   Experience with Integrated ISIS       July 1994
          
          
          
          technology.  No notions of official NIST certification or
          endorsement are associated with this activity.
          
          While the primary focus of the testing has been IS-IS
          functionality, the testing also addresses aspects of the
          operation of the corresponding data (i.e., CLNP and IP) and
          supporting protocols (i.e., ES-IS, ICMP, ARP).
          
          The interoperability testing sessions consist of several test
          scenarios that focus on subsets of the protocol functionality.
          Within each scenario, individual tests are executed by manually
          altering: the physical configuration of the testbed, the logical
          configuration of ISs, and/or the flow of data traffic across the
          testbed.
          
          
          9.1.1. Protocol Functions Tested
          
          Individual interoperability tests are selected to exercise
          specific protocol functions.  The functions addressed by NIST
          testing include:
          
          -   IS Adjacencies - L1/L2 IS adjacency  acquisition. Primarily
              tested on LANs, issues tested include: area boundaries,
              area address computation, protocols supported,
              authentication. Configurations of 10, or more, ISs
              adjacencies on a single lan have been tested at L1 and L2.
          
          -   Designated IS (DIS) Election - L1/L2 LAN DIS functions.
              Issues tested include: DIS priority election, resignation,
              crash, pseudo node generation and sequence number
              processing.
          
          -   Link State Data Base Maintenance - L1/L2 update process
              functions.  Issues tested included: event driven and
              periodic LSP generation, sequence number LSP processing,
              LSP propagation, LSP lifetime control.
          
          -   ES Adjacencies - L1/ES-IS functions.  Issues tested
              include: dynamic ES adjacencies, area boundaries, manual ES
              adjacencies, ES poll. Configurations with approximately 30
              multi-vendor ES neighbors have been tested at L1.
          
          -   L1 Route Computation - L1 decision process functions.
              Issues addressed include: minimum cost paths, routing to
              dynamic and manual ES neighbors, computation of nearest L2
              IS, equal cost multipaths, path pruning, overloaded ISs,
              multiple metrics. Configurations with 10, or more, equal
              cost paths have been tested.
          
          
          
          
          Gunner                                                 [Page 13]


          Internet-Draft   Experience with Integrated ISIS       July 1994
          
          
          
          -   Reachable Address Prefix (RAP)s - L2 RAP configuration and
              processing.  Issues addressed include: internal and
              external metrics, RAP reporting in LSPs, default routes.
          
          -   L2 Route Computation - L2 decision process functions.
              Issues addressed include: area routes, prefix routes, path
              preference, attached flag, partition detection.
              Configurations with 10, or more, areas within a domain have
              been tested.
          
          -   CLNP/IP Forwarding and other protocol Interactions - Issues
              addressed include: route switching, error notifications, ES
              redirection.
          
          
          9.1.2. Evaluation of Interoperability
          
          Evaluations of the results of interoperability tests are made
          using various techniques. First order observation of the
          protocols under test are usually made using the
          console/management capabilities of individual ISs and protocol
          analyzers attached to appropriate subnets. Second order
          observations are made using data streams between ESs positioned
          throughout the testbed. Observations of the following attributes
          are typically made during testing:
          
          -   Reachability - Examination of individual IS forwarding
              tables using console/management interface.  Observations of
              duplex data streams between ESs (e.g. ECHO/PING, remote
              login, file transfer).
          
          -   Convergence Time - Maintenance of Transport level
              connections during routing convergence.  Observations of
              rate controlled ECHO/PING sessions.
          
          -   Protocol Stability - Observations of protocol analyzers
              during reconfigurations and stable periods.
          
          -   Protocol Efficiency - No serious attempt has been made to
              assess protocol efficiency.  Casual observations are made
              using statistics maintained by individual ISs and
              utilization measurements on protocol analyzers.
          
          
          9.2. Testing Sessions
          
          Participation in NIST interoperability testing has varied over
          time.  Likewise, the maturity of the implementations tested has
          varied as new participants joined later sessions.  In the
          sections that follow the results and observations of various
          
          
          
          Gunner                                                 [Page 14]


          Internet-Draft   Experience with Integrated ISIS       July 1994
          
          
          
          sessions are documented.  These results document the
          implementations and specification errors/issues that were found
          during the session.  In many instances, implementation errors
          were corrected and retested during a single session.  In
          instances in which an issue was raised in multiple sessions, it
          is typically only documented once.
          
          
          9.2.1. August 1991 DIS-level Implementation Testing
          
          The first open lab was conducted August 12-16 1991 for the
          purpose of testing early implementations of the Draft
          International Standard (DIS) for IS-IS. The participants in this
          session were: 3Com, Digital, Proteon, Wellfleet, and University
          of Wisconsin (WISIS in GATED, running on a BSD 4.4 microvax).
          For most of the participants the implementations under test were
          relatively immature.
          
          Testing primarily focused upon 802.3 LAN tests.  Hardware
          interface problems prevented successful testing on the FDDI LAN.
          The testing covered the basic LAN capabilities, level 1 and
          level 2 routing test scenarios.
          
          The following implementation issues/errors were found during
          testing:
          
          -   Multiple LSPs - Some implementations did not process
              multiple LSPs from the same system correctly.  Once systems
              began generating non-zero numbered LSPs these systems
              displayed various problems in LSDB synchronization.
          
          -   Unexpected PDU Encodings - Several simple PDU parsing
              errors were found.  Implementations that made novel use of
              the PDU encoding rules (e.g., that place IS neighbors one
              per TLV option, use non contiguous LSP numbers) revealed
              some less than general parsing assumptions in
              implementations.
          
          -   DIS/Pseudo Node Operation - Several implementation issues
              were discovered with DIS/pseudo Node procedures, including:
          
                 Non DIS systems generating CSNs and responding to PSNs.
          
                 Systems not generating Pseudo Node PDUs correctly.
          
                 Systems not adjusting IIH Hello timers when DIS.
          
                 Few systems implement the ES poll function.
          
          -   Area Address Computation - Errors were found in the
          
          
          
          Gunner                                                 [Page 15]


          Internet-Draft   Experience with Integrated ISIS       July 1994
          
          
          
              computation of area addresses.  Some implementations only
              reported the set of manual area addresses.
          
          -   LSDB Synchronization - Several implementations had errors
              in synchronizing LSP sequence numbers after a restart
              (e.g., either ignored previous sequence number in old LSPs,
              or counted by 1 up to the correct number).
          
          -   L1 Routing L2 IS - Several implementation errors were noted
              related to the use of L2 attached bit and computation of
              the nearest L2 IS.  Some implementations did not correctly
              set the attached bit, some set the attached bit when
              configured L1-only, others did not recognize changes in
              attached status of remote ISs during L1 SPF. Some systems
              did not perform background SPF computations.
          
          -   L2 Routing - Some errors were found in implementation of
              path precedence rules and Reachable Address Prefix (RAP)
              processing of interesting prefixes (e.g., use of odd RAP
              lengths, use of RAPs with IDI padding rules).
          
          -   ES-IS Redirection - Some errors were found in the ES-IS
              redirect function (e.g., redirecting ISs, improper RD PDU
              encodings).
          
          The following specification issues/errors were found during
          testing:
          
          -   Precedence of Routing Protocols - Questions arose relating
              to the relative precedence of IS-IS and ES-IS derived
              routing information.  Some implementations assign routes
              derived from ES-IS a higher precedence than those computed
              by IS-IS. That is, CLNP PDUs are delivered to ESs over the
              subnets to which they are directly attached while other
              IS-IS paths with lesser cost exist.
          
              The intention of the ISIS protocol specification is that
              only routes computed by the protocol are used for
              forwarding to end systems. Adjacencies to end systems
              derived from ESIS are reported in the router's LSPs. Since
              a router includes its own LSPs in its forwarding database
              computation, routes to its adjacent end systems will be
              computed. The shortest path from a router to an end system
              will depend only on the metrics assigned to the circuits.
              The relative preference of circuits can be controlled by
              adjusting their metric through management parameters. This
              has been clarified in the Integrated ISIS specification [2].
              This clarification is intended for submission as a defect
              report to the base ISIS standard [5].
          
          
          
          
          Gunner                                                 [Page 16]


          Internet-Draft   Experience with Integrated ISIS       July 1994
          
          
          
          -   Redirection Based Upon RAPs - It was noted that issuing a
              redirect as the result of forwarding based upon a RAP may
              require the Network Entity Title (NET) of the next hop.
              This information is not specified as part of the RAP
              configuration information. It was also noted that if an NET
              was specified, the SNPA and the "liveness" of the RAP next
              hop could be determined using the ES-IS protocol.
          
              The next hop's NET must be included in a Redirect if the
              next hop is a router. This requires that the base ISIS
              standard have an additional attribute in the Reachable
              Address managed object which is set to the NET of the next
              hop. A new attribute (nextHopNET) for the Reachable Address
              managed object which can be set to the next hop NET is
              defined in the Integrated ISIS specification [2]. An
              equivalent object (isisRANextHopNET) has been added to the
              Integrated ISIS MIB [3]. The default value of both of these
              is an octetstring of length 1 with octet value zero. This
              default means that Redirect PDUs will be encoded with a NET
              field even though the NET value is not that of any system.
              Some End systems use the presence or absence of the NET
              field in the Redirect PDU to determine how to originate
              packets for that destination, for example, the maximum PDU
              size to use. This addition is intended for submission as a
              defect report to the base ISIS standard [5].
          
          -   ES Poll - Some implementors that did not implement the ES
              poll function did so intentionally noting that few ESs
              support the ESCT option upon which the function is based.
              It was noted that for the ES poll function to be effective
              ESCT processing must be supported by ESs.
          
              The problem with ESs not supporting the option is that
              during a poll the router will adjust the timer for ES
              adjacencies on the assumption that ESs will respond to the
              poll. If they do not process the ESCT option then their
              adjacencies will be timed out by the router and then
              reformed later when the ESs send out their normal frequency
              ES Hellos. Before being reformed those end systems will be
              unreachable. The polling process is triggered when there
              has been a routing topology change, since this may have
              occurred when an extended LAN becomes partitioned on
              failure of a bridge. In this case the router wants to
              determine as quickly as possible the circuits through which
              the end systems are reachable. To avoid the problem of end
              systems that do not implement the option, a management
              attribute has been added to each circuit which controls
              whether existing end system adjacencies are timed out more
              quickly (as defined by the poll function) or left to time
              out with their current holding time. The new attribute is
          
          
          
          Gunner                                                 [Page 17]


          Internet-Draft   Experience with Integrated ISIS       July 1994
          
          
          
              useESConfigurationPolling in the base ISIS standard [5] and
              is isisCircESPolling in the MIB [3]. The default value for
              these is to not do polling. This addition is intended for
              submission as a defect report to the base ISIS standard [5].
          
          
          9.2.2. February 1992 IS-level Implementation Testing
          
          The second open lab was conducted February 24-28 1992 for the
          purpose of testing implementations of the  recently finalized
          International Standard (IS) version IS-IS.  The participants in
          this session were:  3Com, Digital, Fibercom, Proteon, Wellfleet,
          Cisco, Retix, Novell.
          
          Testing primarily focused upon 802.3, and FDDI LAN tests.  The
          testing covered the basic LAN capabilities, level 1 and level 2
          routing test scenarios.  The maturity level of the
          implementations, including those participating for the first
          time, was significantly higher than in the previous open lab.
          This allowed more time for testing additional, secondary
          features of the protocol, including:
          
          -   Authentication features.
          
          -   Overloaded ISs.
          
          -   Partition Repair.
          
          During this open-lab session, the NIST IS-IS Multiparty
          Conformance Test Systems was demonstrated operating upon vendor
          implementations.  Experimental conformance test suites for the
          subnetwork and update processes were executed.
          
          The following implementation issues/errors were found during
          testing:
          
          -   Circuit State Changes - Some implementations were unable to
              determine the status of circuits in some situations (e.g.,
              serial circuits marked external).   Some implementations
              failed to reflect changes in circuit states in their LSPs
              (e.g., failure of event driven LSP to drop IS neighbors or
              RAPs lost due to circuit state changes).
          
          -   Multi-pathing - Configurations with up to 10 equal cost
              multipaths revealed some SPF implementation/scaling errors.
          
          -   Overloaded ISs - Some implementations completely ignore
              LSDB overload state in ISs.  In those that recognized the
              state, there were differences in implementation of this
              feature (see specification issues below).
          
          
          
          Gunner                                                 [Page 18]


          Internet-Draft   Experience with Integrated ISIS       July 1994
          
          
          
          The following specification issues/errors were found during
          testing:
          
          -   IIH Padding - Discrepancies in configured data link block
              sizes on FDDI initially prevented IS adjacency acquisition.
              The IS with the smaller configured data link block size was
              capable of receiving larger IIHs, but the other IS would
              reject IIHs that were padded to a smaller block size than
              its own. Questions arose regarding whether PAD length
              checks are required upon receipt of IIHs.
          
              The Integrated ISIS specification [2] has been clarified to
              state that no check is made on the padded length of
              received IIHs. The purpose of the padding is to ensure that
              ISIS protocol packets of maximum size can traverse the
              transmission path between the neighbors (which may be an
              extended LAN made up of different media). It is not
              necessary that neighbors have the same data link block
              size. This clarification is intended for submission as a
              defect report to the base ISIS standard [5].
          
              In addition a new management attribute has been defined in
              the Integrated ISIS specification [2] and the GDMO in ISO
              10589 and to the I ISIS MIB which controls whether ISIS
              Hellos transmitted on a broadcast circuit are padded. The
              use of padding can cause significant overhead, for example,
              over remote bridging using low bandwidth WAN links.
          
          -   Area Addresses - Questions arose as to the use of computed
              area addresses in uses other than IS-IS PDUs.  In
              particular questions arose as to:
          
                 If dynamic ES adjacencies should be rejected if they
                  match a manual area address that has been dropped.
          
                  If a manual area address is dropped from the area this
                  indicates a configuration error since the result will
                  be that reachability to some systems may be lost, since
                  that area address will not be announced at level 2. The
                  Integrated ISIS specification [2] has been clarified to
                  describe what is the effect of dropping a manual area
                  address on the parameter manualAreaAddresses (there is
                  no effect).
          
                 For the purposes of forwarding and lowest NET
                  computation some interpretations varied, with different
                  implementations using: the manual area addresses, the
                  computed area addresses, the union of both.
          
                  The Integrated ISIS specification [2] has been
          
          
          
          Gunner                                                 [Page 19]


          Internet-Draft   Experience with Integrated ISIS       July 1994
          
          
          
                  clarified to make it clearer in the forwarding
                  description which area addresses are used (the set
                  defined by the areaAddresses parameter).
          
          -   Routing Through an Overloaded IS - There were some
              questions regarding the description of SPF computation in
              the presence of an overloaded IS.   While the text implies
              that one should consider ES adjacencies on the other side
              of an overloaded IS, some implementations will not compute
              the SPF through the overloaded IS to the pseudo node (which
              contains the LSP for the dynamic ES adjacencies). Such
              implementations will only compute routes to the the manual
              ES adjacencies of an overloaded IS.
          
              The purpose of including ES adjacencies of an overloaded
              router in the SPF computation is really just to maintain a
              path to the overloaded router itself, since a router
              announces its own ID as reachable in its level 1 LSP ES
              neighbor options. This path is needed so that management
              traffic can reach the overloaded router. During overload,
              reachability to other systems in the area or domain is
              affected and it doesn't seem worthwhile adding extra
              complexity to the SPF computation to try and keep
              reachability to end systems through an overloaded router.
              The SPF algorithm in the base standard is not very clear
              about this and so some clarifying text has been added to
              explain the behaviour. What happens is that the LAN end
              systems will be reachable through non-overloaded routers on
              the LAN, but will not be reachable through any overloaded
              routers including the designated router itself (if it is
              overloaded). If the designated router is overloaded it sets
              the "infinite hippity cost" bit in its pseudonode LSPs and
              its own LSPs. Therefore a path through the designated
              router is not computed because its reachability to the
              pseudonode is blocked.
          
          -   Partition Repair - In attempting to test the partition
              repair function it became obvious that the description of
              partition repair forwarding had the real potential for
              routing loops. In the two sets of modifications to the
              standard to add descriptions of precedence of routes and
              make partition repair optional the standard created a
              potential looping condition in areas in which only some ISs
              implement partition repair.
          
              This problem has been clarified in the base ISIS standard
              through the submission of defect reports which have been
              agreed as part of Technical Corrigenda 1 and 2 [6 and 7].
          
          -   Attached Bit in Single Area Domains - In testing inter-area
          
          
          
          Gunner                                                 [Page 20]


          Internet-Draft   Experience with Integrated ISIS       July 1994
          
          
          
              routing and computation of the nearest L2 IS discussion
              arose as to the inability to support single area domains
              with external RAPs.  In particular, an L2 IS with RAPs
              (e.g., default prefix) but no area routes will not identify
              itself as attached. It was felt that this was a deficiency
              in the protocol.
          
              This has been clarified in the base ISIS standard through
              the submission of a Defect Report which has been agreed as
              part of Technical Corrigendum 1 [6]. The presence of any
              Reachable Address Prefix causes the level 2 router to
              consider itself as "attached".
          
          
          9.2.3. Spring 1992 Interop Demonstration
          
          The participants in NIST interoperability testing activities
          demonstrated multi-vendor IS-IS interoperability at the spring
          1992 Interop conference. The demonstration was conducted within
          the NIST booth, with periodic (i.e., after hours)
          interoperability testing with the shownet routers. The
          participants in this demonstration were:  3Com, Digital, Cisco,
          Proteon, and Phase 2 Networks.
          
          The demonstration consisted primarily of L1/L2 route switching
          demonstrations across 802.3, and FDDI LAN tests.
          
          During the course of this demonstration one specification issue
          was raised:
          
          -   DIS TOS Support - Questions arose as to whether the DIS
              should report support for all metrics in its pseudo node
              LSPs.  Failure to do so causes some SPF implementations to
              abandon TOS paths that actually are contiguous.
          
              The problem here is that the designated router announces
              reachability to systems on the LAN on behalf of other
              routers on the same LAN, but the TOS supported by the
              routers may be different. Since all routers must support
              the default TOS, there will always be a default TOS path.
              However, if there were a path at a non-default TOS that
              were contiguous except for the pseudonode hop then that
              non-default TOS path could not be used - the default TOS
              path would be used.
          
              The solution is to have the designated router announce
              reachability at all TOS to LAN systems in its pseudonode
              LSPs even if that router is not configured to support one
              or more of those TOS. Since the announced cost in these
              LSPs is always zero, there is no problem of choosing the
          
          
          
          Gunner                                                 [Page 21]


          Internet-Draft   Experience with Integrated ISIS       July 1994
          
          
          
              cost to use when doing this. This permits fully contiguous
              TOS paths to be computed through the pseudonode. This
              change has been added to the Integrated ISIS specification
              [2].
          
          
          9.2.4. Fall 1992 Interop Demonstration Hot Stage
          
          An open lab was conducted in October 1992 for the purpose of hot
          staging the fall 1992 Interop integrated IS-IS multi-vendor
          demonstration.  The direct participants in this session were:
          3Com, Digital, Cisco, Proteon, and Phase 2 Networks.  Most of
          the participants in this session had recently added Integrated
          support to their existing IS-IS implementations.
          
          Testing primarily focused upon 802.3, and FDDI LAN tests.
          
          The testing scenarios covered the basic LAN capabilities, level
          1 level 2 routing test scenarios.  Given maturity level of the
          OSI capabilities of the implementations under test, most effort
          was directed at testing those IP capabilities required for the
          upcoming Interop demonstration.
          
          The following implementation issues/errors were found during
          testing:
          
          -   L2 Reachability Summarization - Some implementations
              reported configured address summaries when there was no
              corresponding internal reachability.
          
          -   Nearest L2 IS and L1 Default Routes -  Some implementations
              did not correctly establish a default route to the nearest
              L2 IS. Also, some implementations did not replace the route
              to the nearest L2 IS with announced L1 default routes.
          
          The following specification issues/errors were found during
          testing:
          
          -   Precedence of Routes - There were some questions regarding
              the relative precedence of I-IS-IS derived routes and
              directly attached interfaces.  In particular,  some
              implementations chose to treat local direct interfaces at a
              higher priority than I-IS-IS derived routes. Thus,
              longer-match or lesser cost I-IS-IS derived routes are
              ignored when the destination appears to be on the locally
              attached subnet.
          
              As with end system adjacencies, routes derived from the
              router's local interfaces are reported in the router's LSPs
              and will be included in the shortest paths computation.
          
          
          
          Gunner                                                 [Page 22]


          Internet-Draft   Experience with Integrated ISIS       July 1994
          
          
          
              There is no need to have preference controls for local
              routes versus Integrated ISIS derived routes. Text has been
              added to the Integrated ISIS specification [2] to make this
              clear.
          
          -   Reporting Interfaces on Which I-IS-IS is disabled -
              Questions arose as to whether an interface over which
              I-IS-IS is not operating should be reported as reachable?
          
              There are two ways that the IP reachability information
              attached to an interface get announced in LSPs. First, some
              or all of the addresses of the router on its interfaces are
              announced in the "IP Interface Address" options in LSPs so
              that other routers learn one or more addresses for the
              router. Second, the subnet addresses (IP address and mask)
              associated with each interface are announced in the
              router's "IP internal Reachability Information" options. In
              both cases, IP reachability information can be included
              even if the interface it is attached to does not have I
              ISIS enabled. A router may provide configuration controls
              to determine which information is announced in LSPs. For
              interface addresses, this must default to announcing at
              least one address from any of the router's interface
              regardless of the state of I ISIS on that interface. For
              subnet addresses this must default to announcing all subnet
              addresses from all the router's interfaces regardless of
              the state of I ISIS on that interface. Clarifying text has
              been added to the Integrated ISIS specification [2].
          
          
          10. References
          
          [1]Callon, R.W., "Use of OSI IS-IS for Routing in TCP/IP and
              dual environments", RFC 1195, December 1990.
          
          [2]Callon, R.W., "Use of OSI IS-IS for Routing in TCP/IP and
              dual environments", Internet-draft
              draft-ietf-isis-tcpip-01.txt, July, 1994 (obsoletes RFC
              1195)
          
          [3]Gunner, C.W., "Integrated IS-IS Management Information Base",
              Internet-draft draft-ietf-isis-mib-04.txt, July, 1994.
          
          [4]Gunner, C.W., "Integrated IS-IS Protocol Analysis",
              Internet-draft draft-ietf-isis-prot-anal-00.txt, March,
              1994.
          
          [5]"Information Technology - Telecommunications and information
              exchange between systems - Intermediate system to
              Intermediate system Intra-Domain routeing exchange protocol
          
          
          
          Gunner                                                 [Page 23]


          Internet-Draft   Experience with Integrated ISIS       July 1994
          
          
          
              for use in Conjunction with the Protocol for providing the
              Connectionless-mode Network Service (ISO 8473)",
              International Standard 10589 (ISO submission copy), October
              1991.
          
          [6]International Standard 10589 - Technical Corrigendum 1
          
          [7]International Standard 10589 - Technical Corrigendum 2
          
          [8]"Information Technology - Telocommunications and information
              exchange between systems - Elements of Management
              Information Related to OSI Network Layer Standards",
              International Standard 10733 (ISO submission copy),
              September 1992.
          
          [9]Montgomery, D. "IS-IS Interoperability Testing at NIST",
              Draft, October 1993.
          
          
          11. Acknowledgements
          
          Thanks are due to members of the ISIS working group of the
          Internet Engineering Task Force (IETF) for their input to this
          document. Thanks are due especially to Ross Callon and Mike
          Shand for technical review. Doug Montgomery acknowledges support
          for the NIST interoperability testing work from the National
          Science Foundation (Contract No. NCR-9120054).
          
          
          12. Working Group Information
          
          The current co-chairs of the ISIS working group are:
          
             Ross Callon
             Wellfleet Communications Inc.
             2 Federal Street
             Billerica
             MA 01821
             USA
          
             Phone:   (508) 436 3936
             Email:   rcallon@wellfleet.com
          
             Chris Gunner
             Digital Equipment Corp.
             550 King Street
             Littleton
             MA 01460-1289
             USA
          
          
          
          
          Gunner                                                 [Page 24]


          Internet-Draft   Experience with Integrated ISIS       July 1994
          
          
          
             Phone:   (508) 486 7792
             Fax:     (508) 486 5279
             Email:   gunner@dsmail.enet.dec.com
          
          
          
          The working group mailing list is:
          
             isis@merit.edu
          
          
          
          Subscription requests should be sent to:
          
             isis-request@merit.edu
          
          
          
          
          13. Author's Addresses
          
             Chris Gunner
             (see co-chair information above for mail, etc.)
          
             Doug Montgomery
             National Institute of Standards and Technology (NIST)
          
             Phone:   (301) 975 3630
             Fax:     (301) 590 0932
             Email:   dougm@osi.ncsl.nist.gov
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          Gunner                                                 [Page 25]
          

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