Internet Engineering Task Force T. Przygienda
INTERNET DRAFT Siara
Oct 1999
Maintaining more than 255 circuits in IS-IS
<draft-ietf-isis-wg-255adj-02.txt>
Status of This Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups. Note that other groups may also distribute
working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at
any time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Abstract
This draft describes an optional implementation technique within
IS-IS [ISO90 , Cal90a , Cal90b ] used today by several ISPs for routing
within their clouds. IS-IS is an interior gateway routing protocol
developed originally by OSI and used with IP extensions as IGP.
This draft describes how to effectively bypass the problem of 255
circuits that IS-IS allows to maintain with minor violations of the
specification that however does not prevent interoperability with
existing implementations.
1. Introduction
IS-IS reserves within its packets only one byte for a circuit ID
and the specification requests it to be unique. This ID is used in
broadcast networks to identify a PNode. They don't seem to serve any
Przygienda et al. Expires Mar 2000 [Page 1]
Internet Draft 255+ Circuits in IS-IS Oct 1999
particular purpose on p2p networks except for some checking in hellos
and tie-breaking in removal of excess adjacencies.
2. More than 255 circuits for p2p links
For all p2p links within an Intermediate System, the same circuit ID
can be chosen safely to interact with other Intermediate Systems.
Even when two such systems are brought up on two ends of the link
and both pick the same value, IS-IS specification does not preclude
such a configuration. In case of multiple parallel links between
the systems the only obvious problem is the impact on tie-breaking
in case of excessive adjacencies. However, such a configuration
cannot generate forwarding loops. Using the same circuit ID for all
p2p circuits and general specification of p2p ISIS that originally
assumed a reliable link layer, especially between same ISes can
however lead to other subtle problems, those are however described
and best solved using the optional 3-way hello technique described
in [Kat99 ].
3. More than 255 circuits for broadcast links
More trickier a case is the one in which an intermediate system has
to form adjacencies on a broadcast medium. The decisive insight
is the fact that unique circuit ID on a broadcast medium is only
needed in the case where the given intermediate system is assuming
the role of the DIS for the LAN. As long as the intermediate system
has not elected itself DIS, it can use a non-unique circuit ID (1) .
Therefore, it is enough to change circuit ID in all the packets
transmitted to a unique one as soon as DIS election ran and the
system must become DIS. Such behavior is basically indistinguishable
from a node crashing and coming immediately back with a different
circuit ID than the one used before the crash. Implementation
experience shows that it is unwise to tear down the adjacencies
before changing circuit IDs since this can lead to ``ripple''-down
behavior in DIS property on the broadcast media in case of all
routers having the same preference. Additionally, when recycling
a previously used circuit ID and reusing it on another LAN special
___________________________________________
1. it is important to realize that circuit ID is not a part of
tie-breaking rules on DIS election
Przygienda et al. Expires Mar 2000 [Page 2]
Internet Draft 255+ Circuits in IS-IS Oct 1999
care has to be taken that the newly generated pseudonode LSPs have
sequence numbers high enough as to prevent unnecessary flooding.
When using this technique a node can use arbitrary number of circuits
only being restricted by the fact that it cannot be DIS on more
than 255 circuits since PNodes would become indistinguishable for
different LANs. To solve that problem, different techniques, such
as using multiple router IDs would be necessary, are however outside
the scope of this draft. A possible, simple treatement of this
problem is for a node to generate appropriate event or management
notification and drop all hello packets on the appropriate LAN until
a unique circuit ID becomes available or it detects a node with
higher preference to become DIS on such LAN. Before going into the
details of the procedure in the next section, it is worth to notice
that the unique circuit IDs can be separated between levels (2) .
3.1. Modification of the Behavior on Broadcast Media
The exact modification of the behavior for broadcast links is
given here. It is a modification of chapter 8.4.1 of the original
specification that states:
When the broadcast circuit is enabled on an Intermediate system the
IS shall perform the following actions.
a) Commence sending IIH PDUs with the LAN ID field set to the
concatenation of its own SystemID and its locally assigned one
octet Local Circuit ID.
b) ... <omitted for clarity>
c) Start listening for ISO 9542 ISH PDUs and ESH PDUs and
acquire adjacencies as appropriate. Do not run the Designated
Intermediate System election process.
d) After waiting ISISHelloTimer * 2 seconds, run the Level 1 and/or
the Level 2 Designated Intermediate System election process,
depending on the Intermediate system type. This shall be run
subsequently whenever an IIH PDU is received or transmitted as
described in 8.4.3. (For these purposes, the transmission of the
system's own IIH PDU is equivalent to receiving it). If there
___________________________________________
2. since a node can become DIS at either level independently
Przygienda et al. Expires Mar 2000 [Page 3]
Internet Draft 255+ Circuits in IS-IS Oct 1999
has been no change to the information on which the election is
performed since the last time it was run, the previous result can
be assumed. The relevant information is
1) the set of Intermediate system adjacency states,
2) the set of Intermediate System priorities (including this
system's) and
3) the existence (or otherwise) of at least one "Up" End system
(not including Manual Adjacencies) or Intermediate system
adjacency on the circuit.
An Intermediate system shall not declare itself to be a LAN
Designated Intermediate system of any type until it has at least one
"Up" End system (not including Manual Adjacencies) or Intermediate
system adjacency on the circuit. (This prevents an Intermediate
System which has a defective receiver and is incapable of receiving
any PDUs from erroneously electing itself LAN Designated Intermediate
System.) The LAN ID field in the LAN IIH PDUs transmitted by this
system shall be set to the value of the LAN ID reported in the LAN
IIH PDU (for the appropriate level) received from the system which
this system considers to be the Designated Intermediate System. This
value shall also be passed to the Update Process, as the pseudonode
ID, to enable Link State PDUs to be issued for this system claiming
connectivity to the pseudonode. If this system, as a result of the
Designated Intermediate System election process, considers itself to
be designated Intermediate System, the LAN ID field shall be set to
the concatenation of this system's own ID and the locally assigned
one octet Local Circuit ID.
One additional point has to be introduced:
a) Commence sending IIH PDUs with the LAN ID field set to the
concatenation of its own SystemID and a local non-zero, not
necessarily unique circuit ID.
b) ... <omitted for clarity>
Przygienda et al. Expires Mar 2000 [Page 4]
Internet Draft 255+ Circuits in IS-IS Oct 1999
c) Start listening for ISO 9542 ISH PDUs and ESH PDUs and
acquire adjacencies as appropriate. Do not run the Designated
Intermediate System election process.
d) After waiting ISISHelloTimer * 2 seconds, run the Level 1 and
or the Level 2 Designated Intermediate System election process
depending on the Intermediate system type. If in any point in
time the decision process determines the node to be DIS for this
LAN:
1) Commence sending IIH PDUs with the LAN ID field set to the
concatenation of its own SystemID and a local unique circuit
ID.
otherwise exhibit standard behavior.
4. Acknowledgments
Some smart people probably thought about most of these things before
and the p2p case may be documented in the best current practices
for IS-IS in the Internet. Mike Shand and Tony Li commented on the
proposal.
5. Security Consideration
ISIS security applies to the work presented. No specific security
issues with the proposed solutions are known.
6. Intellectual Property Considerations
Lucent may seek patent or other intellectual property protection
for some or all of the technologies disclosed in this document. If
any standards arising from this document are or become protected
by one or more patents assigned to Lucent, Lucent intends to
disclose those patents and license them under openly specified and
non-discriminatory terms.
References
[Cal90a] R. Callon. OSI ISIS Intradomain Routing Protocol.
INTERNET-RFC, Internet Engineering Task Force, February
1990.
Przygienda et al. Expires Mar 2000 [Page 5]
Internet Draft 255+ Circuits in IS-IS Oct 1999
[Cal90b] R. Callon. Use of OSI ISIS for Routing in TCP/IP and Dual
Environments. INTERNET-RFC, Internet Engineering Task
Force, December 1990.
[ISO90] ISO. Information Technology - Telecommunications and
Information Exchange between Systems - Intermediate System
to Intermediate System Routing Exchange Protocol for
Use in Conjunction with the Protocol for Providing the
Connectionless-Mode Network Service. ISO, 1990.
[Kat99] D. Katz. Three-Way Handshake for IS-IS Point-to-Point
Adjacencies. work-in-progress, Internet Engineering Task
Force, 1999.
Authors' Addresses
Tony Przygienda
Siara Systems
300 Ferguson Drive
Mountain View, CA 94043
prz@siara.com
Przygienda et al. Expires Mar 2000 [Page 6]
