Internet DRAFT - draft-ietf-isis-255adj
draft-ietf-isis-255adj
HTTP/1.1 200 OK
Date: Tue, 09 Apr 2002 04:30:40 GMT
Server: Apache/1.3.20 (Unix)
Last-Modified: Mon, 23 Nov 1998 16:33:00 GMT
ETag: "2f5510-268c-36598e3c"
Accept-Ranges: bytes
Content-Length: 9868
Connection: close
Content-Type: text/plain
Internet Engineering Task Force T. Przygienda
INTERNET DRAFT Bell Labs
1 Nov 1998
Maintaining more than 255 adjacencies in IS-IS
<draft-ietf-isis-255adj-00.txt>
Status of This Memo
This document is an Internet Draft, and can be found as
draft-ietf-isis-255adj-00.txt in any standard internet drafts
repository. 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.''
Please check the I-D abstract listing contained in each Internet
Draft directory to learn the current status of this or any other
Internet Draft.
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 1 May 1999 [Page 1]
Internet Draft 255+ Adjacencies in IS-IS 1 Nov 1998
particular purpose on p2p networks except for some checking in hellos
and tie-breaking in removal of excess adjacencies.
2. More than 255 adjacencies on 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.
3. More than 255 adjacencies on 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.
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.5 of the original
specification that states:
___________________________________________
1. it is important to realize that circuit ID is not a part of
tie-breaking rules on DIS election
Przygienda et al. Expires 1 May 1999 [Page 2]
Internet Draft 255+ Adjacencies in IS-IS 1 Nov 1998
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
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
Przygienda et al. Expires 1 May 1999 [Page 3]
Internet Draft 255+ Adjacencies in IS-IS 1 Nov 1998
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>
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.
2) go to step b.
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.
5. Security Consideration
ISIS security applies to the work presented. No specific security
issues with the proposed solutions are known.
Przygienda et al. Expires 1 May 1999 [Page 4]
Internet Draft 255+ Adjacencies in IS-IS 1 Nov 1998
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.
[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.
Authors' Addresses
Tony Przygienda
Bell Labs, Lucent Technologies
101 Crawfords Corner Road
Holmdel, NJ 07733-3030
prz@dnrc.bell-labs.com
Przygienda et al. Expires 1 May 1999 [Page 5]
