idnits 2.17.1 draft-ietf-isis-wg-255adj-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. 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 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == 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 6 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 Jun 1999) is 9096 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: 6 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 Jun 1999 5 Maintaining more than 255 circuits in IS-IS 6 8 Status of This Memo 9 This document is an Internet-Draft and is in full conformance with 10 all provisions of Section 10 of RFC2026. 12 Internet-Drafts are working documents of the Internet Engineering 13 Task Force (IETF), its areas, and its working groups. Note 14 that other groups may also distribute working documents as 15 Internet-Drafts. 16 Internet-Drafts are draft documents valid for a maximum of six months 17 and may be updated, replaced, or obsoleted by other documents at 18 any time. It is inappropriate to use Internet- Drafts as reference 19 material or to cite them other than as "work in progress." 21 The list of current Internet-Drafts can be accessed at 22 http://www.ietf.org/ietf/1id-abstracts.txt 23 The list of Internet-Draft Shadow Directories can be accessed at 24 http://www.ietf.org/shadow.html. 26 Abstract 27 This draft describes an optional implementation technique within 28 IS-IS [ISO90, Cal90a, Cal90b] used today by several ISPs for routing 29 within their clouds. IS-IS is an interior gateway routing protocol 30 developed originally by OSI and used with IP extensions as IGP. 31 This draft describes how to effectively bypass the problem of 255 32 circuits that IS-IS allows to maintain with minor violations of the 33 specification that however does not prevent interoperability with 34 existing implementations. 36 1. Introduction 37 IS-IS reserves within its packets only one byte for a circuit ID 38 and the specification requests it to be unique. This ID is used in 39 broadcast networks to identify a PNode. They don't seem to serve any 40 particular purpose on p2p networks except for some checking in hellos 41 and tie-breaking in removal of excess adjacencies. 43 2. More than 255 circuits for p2p links 44 For all p2p links within an Intermediate System, the same circuit ID 45 can be chosen safely to interact with other Intermediate Systems. 46 Even when two such systems are brought up on two ends of the link 47 and both pick the same value, IS-IS specification does not preclude 48 such a configuration. In case of multiple parallel links between the 49 systems the only obvious problem is the impact on tie-breaking in 50 case of excessive adjacencies. However, such a configuration cannot 51 generate forwarding loops. 53 3. More than 255 circuits for broadcast links 54 Trickier a case is the one in which an intermediate system has to 55 form adjacencies on a broadcast medium. The decisive insight is the 56 fact that unique circuit ID on a broadcast medium is only needed 57 in the case where the given intermediate system is assuming the 58 role of the DIS for the LAN. As long as the intermediate system has 59 not elected itself DIS, it can use a non-unique circuit ID (1). 60 Therefore, it is enough to change circuit ID in all the packets 61 transmitted to a unique one as soon as DIS election ran and the 62 system must become DIS. Such behavior is basically indistinguishable 63 from a node crashing and coming immediately back with a different 64 circuit ID than the one used before the crash. Implementation 65 experience shows that it is unwise to tear down the adjacencies by 66 sending empty hellos before changing circuit IDs since this can lead 67 to ``ripple''-down behavior in DIS in the case of all routers having 68 the same preference. However, to ensure that all involved parties 69 agree on LAN ID of the media, implementations must interpret in 70 subsection 8.4.5 within 10589 the specified condition 72 f) the set of Intermediate system adjacency states 73 as including any change in LAN ID to be an indication triggering the 74 recomputation of the according DIS. Additionally, when recycling a 75 previously used circuit ID and reusing it on another LAN special 77 ___________________________________________ 78 1. it is important to realize that circuit ID is not a part of 79 tie-breaking rules on DIS election 80 care has to be taken that the newly generated pseudonode LSPs have 81 sequence numbers high enough as to prevent unnecessary flooding. 83 3.1. Modification of the Behavior on Broadcast Media 84 The exact modification of the behavior for broadcast links is 85 given here. It is a modification of chapter 8.4.5 of the original 86 specification that states: 88 When the broadcast circuit is enabled on an Intermediate system the 89 IS shall perform the following actions. 90 a) Commence sending IIH PDUs with the LAN ID field set to the 91 concatenation of its own SystemID and its locally assigned one 92 octet Local Circuit ID. 94 b) ... 96 c) Start listening for ISO 9542 ISH PDUs and ESH PDUs and 97 acquire adjacencies as appropriate. Do not run the Designated 98 Intermediate System election process. 100 d) After waiting ISISHelloTimer * 2 seconds, run the Level 1 and/or 101 the Level 2 Designated Intermediate System election process, 102 depending on the Intermediate system type. This shall be run 103 subsequently whenever an IIH PDU is received or transmitted as 104 described in 8.4.3. (For these purposes, the transmission of the 105 system's own IIH PDU is equivalent to receiving it). If there 106 has been no change to the information on which the election is 107 performed since the last time it was run, the previous result can 108 be assumed. The relevant information is 110 1) the set of Intermediate system adjacency states, 112 2) the set of Intermediate System priorities (including this 113 system's) and 115 3) the existence (or otherwise) of at least one "Up" End system 116 (not including Manual Adjacencies) or Intermediate system 117 adjacency on the circuit. 119 An Intermediate system shall not declare itself to be a LAN 120 Designated Intermediate system of any type until it has at least one 121 "Up" End system (not including Manual Adjacencies) or Intermediate 122 system adjacency on the circuit. (This prevents an Intermediate 123 System which has a defective receiver and is incapable of receiving 124 any PDUs from erroneously electing itself LAN Designated Intermediate 125 System.) The LAN ID field in the LAN IIH PDUs transmitted by this 126 system shall be set to the value of the LAN ID reported in the LAN 127 IIH PDU (for the appropriate level) received from the system which 128 this system considers to be the Designated Intermediate System. This 129 value shall also be passed to the Update Process, as the pseudonode 130 ID, to enable Link State PDUs to be issued for this system claiming 131 connectivity to the pseudonode. If this system, as a result of the 132 Designated Intermediate System election process, considers itself to 133 be designated Intermediate System, the LAN ID field shall be set to 134 the concatenation of this system's own ID and the locally assigned 135 one octet Local Circuit ID. 137 One additional point has to be introduced: 138 a) Commence sending IIH PDUs with the LAN ID field set to the 139 concatenation of its own SystemID and a local non-zero, not 140 necessarily unique circuit ID. 142 b) ... 144 c) Start listening for ISO 9542 ISH PDUs and ESH PDUs and 145 acquire adjacencies as appropriate. Do not run the Designated 146 Intermediate System election process. 148 d) After waiting ISISHelloTimer * 2 seconds, run the Level 1 and 149 or the Level 2 Designated Intermediate System election process 150 depending on the Intermediate system type. If in any point in 151 time the decision process determines the node to be DIS for this 152 LAN: 154 1) Commence sending IIH PDUs with the LAN ID field set to the 155 concatenation of its own SystemID and a local unique circuit 156 ID. 158 2) go to step b. 160 otherwise exhibit standard behavior. 162 3.2. Multiple levels 164 Since election of DIS is performed indpendently at each level, the 165 extensions can be applied to generate local circuit IDs only for the 166 level at which the system has been elected. 168 4. Acknowledgments 170 Some smart people probably thought about most of these things before 171 and the p2p case may be documented in the best current practices for 172 IS-IS in the Internet. Mike Shand, Tony Li, Arun Satyanarayana, 173 Rajesh Varadarajan and Christian Hopps provided additional comments. 175 5. Security Consideration 177 ISIS security applies to the work presented. No specific security 178 issues with the proposed solutions are known. 180 6. Intellectual Property Considerations 182 Lucent may seek patent or other intellectual property protection 183 for some or all of the technologies disclosed in this document. If 184 any standards arising from this document are or become protected 185 by one or more patents assigned to Lucent, Lucent intends to 186 disclose those patents and license them under openly specified and 187 non-discriminatory terms. 189 References 191 [Cal90a] R. Callon. OSI ISIS Intradomain Routing Protocol. 192 INTERNET-RFC, Internet Engineering Task Force, February 193 1990. 195 [Cal90b] R. Callon. Use of OSI ISIS for Routing in TCP/IP and Dual 196 Environments. INTERNET-RFC, Internet Engineering Task 197 Force, December 1990. 199 [ISO90] ISO. Information Technology - Telecommunications and 200 Information Exchange between Systems - Intermediate System 201 to Intermediate System Routing Exchange Protocol for 202 Use in Conjunction with the Protocol for Providing the 203 Connectionless-Mode Network Service. ISO, 1990. 205 Authors' Addresses 207 Tony Przygienda 208 Bell Labs, Lucent Technologies 209 101 Crawfords Corner Road 210 Holmdel, NJ 07733-3030 211 prz@dnrc.bell-labs.com