Internet Engineering Task Force T. Przygienda INTERNET DRAFT Bell Labs 1 Nov 1998 Maintaining more than 255 adjacencies in IS-IS 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) ... 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) ... 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]