idnits 2.17.1 draft-ietf-isis-wg-255adj-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-16) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard == It seems as if not all pages are separated by form feeds - found 0 form feeds but 5 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The abstract seems to contain references (Cal90b], [ISO90,Cal90a,), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (1 Nov 1998) is 9298 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Possible downref: Non-RFC (?) normative reference: ref. 'Cal90a' -- Possible downref: Non-RFC (?) normative reference: ref. 'Cal90b' -- Possible downref: Non-RFC (?) normative reference: ref. 'ISO90' Summary: 9 errors (**), 0 flaws (~~), 2 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Engineering Task Force T. Przygienda 2 INTERNET DRAFT Bell Labs 3 1 Nov 1998 5 Maintaining more than 255 adjacencies in IS-IS 6 8 Status of This Memo 9 This document is an Internet Draft, and can be found as 10 draft-ietf-isis-255adj-00.txt in any standard internet drafts 11 repository. Internet Drafts are working documents of the Internet 12 Engineering Task Force (IETF), its Areas, and its Working Groups. 13 Note that other groups may also distribute working documents as 14 Internet Drafts. 16 Internet Drafts are draft documents valid for a maximum of six 17 months. Internet Drafts may be updated, replaced, or obsoleted by 18 other documents at any time. It is not appropriate to use Internet 19 Drafts as reference material, or to cite them other than as a 20 ``working draft'' or ``work in progress.'' 21 Please check the I-D abstract listing contained in each Internet 22 Draft directory to learn the current status of this or any other 23 Internet Draft. 25 Abstract 26 This draft describes an optional implementation technique within 27 IS-IS [ISO90, Cal90a, Cal90b] used today by several ISPs for routing 28 within their clouds. IS-IS is an interior gateway routing protocol 29 developed originally by OSI and used with IP extensions as IGP. 30 This draft describes how to effectively bypass the problem of 255 31 circuits that IS-IS allows to maintain with minor violations of the 32 specification that however does not prevent interoperability with 33 existing implementations. 35 1. Introduction 36 IS-IS reserves within its packets only one byte for a circuit ID 37 and the specification requests it to be unique. This ID is used in 38 broadcast networks to identify a PNode. They don't seem to serve any 39 particular purpose on p2p networks except for some checking in hellos 40 and tie-breaking in removal of excess adjacencies. 42 2. More than 255 adjacencies on p2p links 43 For all p2p links within an Intermediate System, the same circuit ID 44 can be chosen safely to interact with other Intermediate Systems. 45 Even when two such systems are brought up on two ends of the link 46 and both pick the same value, IS-IS specification does not preclude 47 such a configuration. In case of multiple parallel links between the 48 systems the only obvious problem is the impact on tie-breaking in 49 case of excessive adjacencies. However, such a configuration cannot 50 generate forwarding loops. 52 3. More than 255 adjacencies on broadcast links 53 More trickier a case is the one in which an intermediate system has 54 to form adjacencies on a broadcast medium. The decisive insight 55 is the fact that unique circuit ID on a broadcast medium is only 56 needed in the case where the given intermediate system is assuming 57 the role of the DIS for the LAN. As long as the intermediate system 58 has not elected itself DIS, it can use a non-unique circuit ID (1). 59 Therefore, it is enough to change circuit ID in all the packets 60 transmitted to a unique one as soon as DIS election ran and the 61 system must become DIS. Such behavior is basically indistinguishable 62 from a node crashing and coming immediately back with a different 63 circuit ID than the one used before the crash. Implementation 64 experience shows that it is unwise to tear down the adjacencies 65 before changing circuit IDs since this can lead to ``ripple''-down 66 behavior in DIS property on the broadcast media in case of all 67 routers having the same preference. 69 3.1. Modification of the Behavior on Broadcast Media 70 The exact modification of the behavior for broadcast links is 71 given here. It is a modification of chapter 8.4.5 of the original 72 specification that states: 74 ___________________________________________ 75 1. it is important to realize that circuit ID is not a part of 76 tie-breaking rules on DIS election 77 When the broadcast circuit is enabled on an Intermediate system the 78 IS shall perform the following actions. 80 a) Commence sending IIH PDUs with the LAN ID field set to the 81 concatenation of its own SystemID and its locally assigned one 82 octet Local Circuit ID. 84 b) ... 86 c) Start listening for ISO 9542 ISH PDUs and ESH PDUs and 87 acquire adjacencies as appropriate. Do not run the Designated 88 Intermediate System election process. 90 d) After waiting ISISHelloTimer * 2 seconds, run the Level 1 and/or 91 the Level 2 Designated Intermediate System election process, 92 depending on the Intermediate system type. This shall be run 93 subsequently whenever an IIH PDU is received or transmitted as 94 described in 8.4.3. (For these purposes, the transmission of the 95 system's own IIH PDU is equivalent to receiving it). If there 96 has been no change to the information on which the election is 97 performed since the last time it was run, the previous result can 98 be assumed. The relevant information is 100 1) the set of Intermediate system adjacency states, 102 2) the set of Intermediate System priorities (including this 103 system's) and 105 3) the existence (or otherwise) of at least one "Up" End system 106 (not including Manual Adjacencies) or Intermediate system 107 adjacency on the circuit. 109 An Intermediate system shall not declare itself to be a LAN 110 Designated Intermediate system of any type until it has at least one 111 "Up" End system (not including Manual Adjacencies) or Intermediate 112 system adjacency on the circuit. (This prevents an Intermediate 113 System which has a defective receiver and is incapable of receiving 114 any PDUs from erroneously electing itself LAN Designated Intermediate 115 System.) The LAN ID field in the LAN IIH PDUs transmitted by this 116 system shall be set to the value of the LAN ID reported in the LAN 117 IIH PDU (for the appropriate level) received from the system which 118 this system considers to be the Designated Intermediate System. This 119 value shall also be passed to the Update Process, as the pseudonode 120 ID, to enable Link State PDUs to be issued for this system claiming 121 connectivity to the pseudonode. If this system, as a result of the 122 Designated Intermediate System election process, considers itself to 123 be designated Intermediate System, the LAN ID field shall be set to 124 the concatenation of this system's own ID and the locally assigned 125 one octet Local Circuit ID. 127 One additional point has to be introduced: 129 a) Commence sending IIH PDUs with the LAN ID field set to the 130 concatenation of its own SystemID and a local non-zero, not 131 necessarily unique circuit ID. 133 b) ... 135 c) Start listening for ISO 9542 ISH PDUs and ESH PDUs and 136 acquire adjacencies as appropriate. Do not run the Designated 137 Intermediate System election process. 139 d) After waiting ISISHelloTimer * 2 seconds, run the Level 1 and 140 or the Level 2 Designated Intermediate System election process 141 depending on the Intermediate system type. If in any point in 142 time the decision process determines the node to be DIS for this 143 LAN: 145 1) Commence sending IIH PDUs with the LAN ID field set to the 146 concatenation of its own SystemID and a local unique circuit 147 ID. 149 2) go to step b. 151 otherwise exhibit standard behavior. 153 4. Acknowledgments 154 Some smart people probably thought about most of these things before 155 and the p2p case may be documented in the best current practices for 156 IS-IS in the Internet. 158 5. Security Consideration 159 ISIS security applies to the work presented. No specific security 160 issues with the proposed solutions are known. 162 6. Intellectual Property Considerations 164 Lucent may seek patent or other intellectual property protection 165 for some or all of the technologies disclosed in this document. If 166 any standards arising from this document are or become protected 167 by one or more patents assigned to Lucent, Lucent intends to 168 disclose those patents and license them under openly specified and 169 non-discriminatory terms. 171 References 173 [Cal90a] R. Callon. OSI ISIS Intradomain Routing Protocol. 174 INTERNET-RFC, Internet Engineering Task Force, February 175 1990. 177 [Cal90b] R. Callon. Use of OSI ISIS for Routing in TCP/IP and Dual 178 Environments. INTERNET-RFC, Internet Engineering Task 179 Force, December 1990. 181 [ISO90] ISO. Information Technology - Telecommunications and 182 Information Exchange between Systems - Intermediate System 183 to Intermediate System Routing Exchange Protocol for 184 Use in Conjunction with the Protocol for Providing the 185 Connectionless-Mode Network Service. ISO, 1990. 187 Authors' Addresses 189 Tony Przygienda 190 Bell Labs, Lucent Technologies 191 101 Crawfords Corner Road 192 Holmdel, NJ 07733-3030 193 prz@dnrc.bell-labs.com