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]
