draft-ietf-isis-wg-255adj-01.txt   draft-ietf-isis-wg-255adj-02.txt 
Internet Engineering Task Force T. Przygienda Internet Engineering Task Force T. Przygienda
INTERNET DRAFT Bell Labs INTERNET DRAFT Siara
1 Jun 1999 Oct 1999
Maintaining more than 255 circuits in IS-IS Maintaining more than 255 circuits in IS-IS
<draft-ietf-isis-wg-255adj-01.txt> <draft-ietf-isis-wg-255adj-02.txt>
Status of This Memo Status of This Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. 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 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 are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at and may be updated, replaced, or obsoleted by other documents at
any time. It is inappropriate to use Internet- Drafts as reference any time. It is inappropriate to use Internet- Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
Abstract Abstract
This draft describes an optional implementation technique within This draft describes an optional implementation technique within
IS-IS [ISO90, Cal90a, Cal90b] used today by several ISPs for routing IS-IS [ISO90, Cal90a, Cal90b] used today by several ISPs for routing
within their clouds. IS-IS is an interior gateway routing protocol within their clouds. IS-IS is an interior gateway routing protocol
developed originally by OSI and used with IP extensions as IGP. developed originally by OSI and used with IP extensions as IGP.
This draft describes how to effectively bypass the problem of 255 This draft describes how to effectively bypass the problem of 255
circuits that IS-IS allows to maintain with minor violations of the circuits that IS-IS allows to maintain with minor violations of the
specification that however does not prevent interoperability with specification that however does not prevent interoperability with
existing implementations. existing implementations.
1. Introduction 1. Introduction
skipping to change at page 1, line 38 skipping to change at page 1, line 39
This draft describes an optional implementation technique within This draft describes an optional implementation technique within
IS-IS [ISO90, Cal90a, Cal90b] used today by several ISPs for routing IS-IS [ISO90, Cal90a, Cal90b] used today by several ISPs for routing
within their clouds. IS-IS is an interior gateway routing protocol within their clouds. IS-IS is an interior gateway routing protocol
developed originally by OSI and used with IP extensions as IGP. developed originally by OSI and used with IP extensions as IGP.
This draft describes how to effectively bypass the problem of 255 This draft describes how to effectively bypass the problem of 255
circuits that IS-IS allows to maintain with minor violations of the circuits that IS-IS allows to maintain with minor violations of the
specification that however does not prevent interoperability with specification that however does not prevent interoperability with
existing implementations. existing implementations.
1. Introduction 1. Introduction
IS-IS reserves within its packets only one byte for a circuit ID 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 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 broadcast networks to identify a PNode. They don't seem to serve any
particular purpose on p2p networks except for some checking in hellos particular purpose on p2p networks except for some checking in hellos
and tie-breaking in removal of excess adjacencies. and tie-breaking in removal of excess adjacencies.
2. More than 255 circuits for p2p links 2. More than 255 circuits for p2p links
For all p2p links within an Intermediate System, the same circuit ID For all p2p links within an Intermediate System, the same circuit ID
can be chosen safely to interact with other Intermediate Systems. can be chosen safely to interact with other Intermediate Systems.
Even when two such systems are brought up on two ends of the link 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 and both pick the same value, IS-IS specification does not preclude
such a configuration. In case of multiple parallel links between the such a configuration. In case of multiple parallel links between
systems the only obvious problem is the impact on tie-breaking in the systems the only obvious problem is the impact on tie-breaking
case of excessive adjacencies. However, such a configuration cannot in case of excessive adjacencies. However, such a configuration
generate forwarding loops. 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 3. More than 255 circuits for broadcast links
Trickier a case is the one in which an intermediate system has to
form adjacencies on a broadcast medium. The decisive insight is the More trickier a case is the one in which an intermediate system has
fact that unique circuit ID on a broadcast medium is only needed to form adjacencies on a broadcast medium. The decisive insight
in the case where the given intermediate system is assuming the is the fact that unique circuit ID on a broadcast medium is only
role of the DIS for the LAN. As long as the intermediate system has needed in the case where the given intermediate system is assuming
not elected itself DIS, it can use a non-unique circuit ID (1). 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 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 transmitted to a unique one as soon as DIS election ran and the
system must become DIS. Such behavior is basically indistinguishable system must become DIS. Such behavior is basically indistinguishable
from a node crashing and coming immediately back with a different from a node crashing and coming immediately back with a different
circuit ID than the one used before the crash. Implementation circuit ID than the one used before the crash. Implementation
experience shows that it is unwise to tear down the adjacencies by experience shows that it is unwise to tear down the adjacencies
sending empty hellos before changing circuit IDs since this can lead before changing circuit IDs since this can lead to ``ripple''-down
to ``ripple''-down behavior in DIS in the case of all routers having behavior in DIS property on the broadcast media in case of all
the same preference. However, to ensure that all involved parties routers having the same preference. Additionally, when recycling
agree on LAN ID of the media, implementations must interpret in a previously used circuit ID and reusing it on another LAN special
subsection 8.4.5 within 10589 the specified condition
f) the set of Intermediate system adjacency states
as including any change in LAN ID to be an indication triggering the
recomputation of the according DIS. 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 1. it is important to realize that circuit ID is not a part of
tie-breaking rules on DIS election tie-breaking rules on DIS election
care has to be taken that the newly generated pseudonode LSPs have care has to be taken that the newly generated pseudonode LSPs have
sequence numbers high enough as to prevent unnecessary flooding. 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 3.1. Modification of the Behavior on Broadcast Media
The exact modification of the behavior for broadcast links is The exact modification of the behavior for broadcast links is
given here. It is a modification of chapter 8.4.5 of the original given here. It is a modification of chapter 8.4.1 of the original
specification that states: specification that states:
When the broadcast circuit is enabled on an Intermediate system the When the broadcast circuit is enabled on an Intermediate system the
IS shall perform the following actions. IS shall perform the following actions.
a) Commence sending IIH PDUs with the LAN ID field set to the a) Commence sending IIH PDUs with the LAN ID field set to the
concatenation of its own SystemID and its locally assigned one concatenation of its own SystemID and its locally assigned one
octet Local Circuit ID. octet Local Circuit ID.
b) ... <omitted for clarity> b) ... <omitted for clarity>
c) Start listening for ISO 9542 ISH PDUs and ESH PDUs and c) Start listening for ISO 9542 ISH PDUs and ESH PDUs and
acquire adjacencies as appropriate. Do not run the Designated acquire adjacencies as appropriate. Do not run the Designated
Intermediate System election process. Intermediate System election process.
skipping to change at page 3, line 30 skipping to change at page 3, line 45
c) Start listening for ISO 9542 ISH PDUs and ESH PDUs and c) Start listening for ISO 9542 ISH PDUs and ESH PDUs and
acquire adjacencies as appropriate. Do not run the Designated acquire adjacencies as appropriate. Do not run the Designated
Intermediate System election process. Intermediate System election process.
d) After waiting ISISHelloTimer * 2 seconds, run the Level 1 and/or d) After waiting ISISHelloTimer * 2 seconds, run the Level 1 and/or
the Level 2 Designated Intermediate System election process, the Level 2 Designated Intermediate System election process,
depending on the Intermediate system type. This shall be run depending on the Intermediate system type. This shall be run
subsequently whenever an IIH PDU is received or transmitted as subsequently whenever an IIH PDU is received or transmitted as
described in 8.4.3. (For these purposes, the transmission of the described in 8.4.3. (For these purposes, the transmission of the
system's own IIH PDU is equivalent to receiving it). If there system's own IIH PDU is equivalent to receiving it). If there
___________________________________________
2. since a node can become DIS at either level independently
has been no change to the information on which the election is has been no change to the information on which the election is
performed since the last time it was run, the previous result can performed since the last time it was run, the previous result can
be assumed. The relevant information is be assumed. The relevant information is
1) the set of Intermediate system adjacency states, 1) the set of Intermediate system adjacency states,
2) the set of Intermediate System priorities (including this 2) the set of Intermediate System priorities (including this
system's) and system's) and
3) the existence (or otherwise) of at least one "Up" End system 3) the existence (or otherwise) of at least one "Up" End system
skipping to change at page 4, line 41 skipping to change at page 5, line 18
d) After waiting ISISHelloTimer * 2 seconds, run the Level 1 and d) After waiting ISISHelloTimer * 2 seconds, run the Level 1 and
or the Level 2 Designated Intermediate System election process or the Level 2 Designated Intermediate System election process
depending on the Intermediate system type. If in any point in depending on the Intermediate system type. If in any point in
time the decision process determines the node to be DIS for this time the decision process determines the node to be DIS for this
LAN: LAN:
1) Commence sending IIH PDUs with the LAN ID field set to the 1) Commence sending IIH PDUs with the LAN ID field set to the
concatenation of its own SystemID and a local unique circuit concatenation of its own SystemID and a local unique circuit
ID. ID.
2) go to step b.
otherwise exhibit standard behavior. otherwise exhibit standard behavior.
3.2. Multiple levels
Since election of DIS is performed indpendently at each level, the
extensions can be applied to generate local circuit IDs only for the
level at which the system has been elected.
4. Acknowledgments 4. Acknowledgments
Some smart people probably thought about most of these things before Some smart people probably thought about most of these things before
and the p2p case may be documented in the best current practices for and the p2p case may be documented in the best current practices
IS-IS in the Internet. Mike Shand, Tony Li, Arun Satyanarayana, for IS-IS in the Internet. Mike Shand and Tony Li commented on the
Rajesh Varadarajan and Christian Hopps provided additional comments. proposal.
5. Security Consideration 5. Security Consideration
ISIS security applies to the work presented. No specific security ISIS security applies to the work presented. No specific security
issues with the proposed solutions are known. issues with the proposed solutions are known.
6. Intellectual Property Considerations 6. Intellectual Property Considerations
Lucent may seek patent or other intellectual property protection Lucent may seek patent or other intellectual property protection
for some or all of the technologies disclosed in this document. If for some or all of the technologies disclosed in this document. If
skipping to change at page 6, line 5 skipping to change at page 6, line 15
[Cal90b] R. Callon. Use of OSI ISIS for Routing in TCP/IP and Dual [Cal90b] R. Callon. Use of OSI ISIS for Routing in TCP/IP and Dual
Environments. INTERNET-RFC, Internet Engineering Task Environments. INTERNET-RFC, Internet Engineering Task
Force, December 1990. Force, December 1990.
[ISO90] ISO. Information Technology - Telecommunications and [ISO90] ISO. Information Technology - Telecommunications and
Information Exchange between Systems - Intermediate System Information Exchange between Systems - Intermediate System
to Intermediate System Routing Exchange Protocol for to Intermediate System Routing Exchange Protocol for
Use in Conjunction with the Protocol for Providing the Use in Conjunction with the Protocol for Providing the
Connectionless-Mode Network Service. ISO, 1990. 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 Authors' Addresses
Tony Przygienda Tony Przygienda
Bell Labs, Lucent Technologies Siara Systems
101 Crawfords Corner Road 300 Ferguson Drive
Holmdel, NJ 07733-3030 Mountain View, CA 94043
prz@dnrc.bell-labs.com prz@siara.com
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/