idnits 2.17.1 draft-ietf-isis-wg-255adj-02.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: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. == No 'Intended status' indicated for this document; assuming Proposed Standard 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. ** There are 13 instances of too long lines in the document, the longest one being 7 characters in excess of 72. 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 (Oct 1999) is 8960 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) == Unused Reference: 'Cal90a' is defined on line 201, but no explicit reference was found in the text == Unused Reference: 'Cal90b' is defined on line 205, but no explicit reference was found in the text == Unused Reference: 'ISO90' is defined on line 209, but no explicit reference was found in the text == Unused Reference: 'Kat99' is defined on line 215, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'Cal90a' -- Possible downref: Non-RFC (?) normative reference: ref. 'Cal90b' -- Possible downref: Non-RFC (?) normative reference: ref. 'ISO90' -- Possible downref: Non-RFC (?) normative reference: ref. 'Kat99' Summary: 5 errors (**), 0 flaws (~~), 5 warnings (==), 6 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 Siara 3 Oct 1999 4 Maintaining more than 255 circuits in IS-IS 5 7 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. Internet-Drafts are working 11 documents of the Internet Engineering Task Force (IETF), its areas, 12 and its working groups. Note that other groups may also distribute 13 working documents as Internet-Drafts. 15 Internet-Drafts are draft documents valid for a maximum of six months 16 and may be updated, replaced, or obsoleted by other documents at 17 any time. It is inappropriate to use Internet-Drafts as reference 18 material or to cite them other than as "work in progress." 20 The list of current Internet-Drafts can be accessed at 21 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 28 This draft describes an optional implementation technique within 29 IS-IS [ISO90 , Cal90a , Cal90b ] used today by several ISPs for routing 30 within their clouds. IS-IS is an interior gateway routing protocol 31 developed originally by OSI and used with IP extensions as IGP. 32 This draft describes how to effectively bypass the problem of 255 33 circuits that IS-IS allows to maintain with minor violations of the 34 specification that however does not prevent interoperability with 35 existing implementations. 37 1. Introduction 39 IS-IS reserves within its packets only one byte for a circuit ID 40 and the specification requests it to be unique. This ID is used in 41 broadcast networks to identify a PNode. They don't seem to serve any 42 particular purpose on p2p networks except for some checking in hellos 43 and tie-breaking in removal of excess adjacencies. 45 2. More than 255 circuits for p2p links 47 For all p2p links within an Intermediate System, the same circuit ID 48 can be chosen safely to interact with other Intermediate Systems. 49 Even when two such systems are brought up on two ends of the link 50 and both pick the same value, IS-IS specification does not preclude 51 such a configuration. In case of multiple parallel links between 52 the systems the only obvious problem is the impact on tie-breaking 53 in case of excessive adjacencies. However, such a configuration 54 cannot generate forwarding loops. Using the same circuit ID for all 55 p2p circuits and general specification of p2p ISIS that originally 56 assumed a reliable link layer, especially between same ISes can 57 however lead to other subtle problems, those are however described 58 and best solved using the optional 3-way hello technique described 59 in [Kat99 ]. 61 3. More than 255 circuits for broadcast links 63 More trickier a case is the one in which an intermediate system has 64 to form adjacencies on a broadcast medium. The decisive insight 65 is the fact that unique circuit ID on a broadcast medium is only 66 needed in the case where the given intermediate system is assuming 67 the role of the DIS for the LAN. As long as the intermediate system 68 has not elected itself DIS, it can use a non-unique circuit ID (1) . 69 Therefore, it is enough to change circuit ID in all the packets 70 transmitted to a unique one as soon as DIS election ran and the 71 system must become DIS. Such behavior is basically indistinguishable 72 from a node crashing and coming immediately back with a different 73 circuit ID than the one used before the crash. Implementation 74 experience shows that it is unwise to tear down the adjacencies 75 before changing circuit IDs since this can lead to ``ripple''-down 76 behavior in DIS property on the broadcast media in case of all 77 routers having the same preference. Additionally, when recycling 78 a previously used circuit ID and reusing it on another LAN special 80 ___________________________________________ 81 1. it is important to realize that circuit ID is not a part of 82 tie-breaking rules on DIS election 83 care has to be taken that the newly generated pseudonode LSPs have 84 sequence numbers high enough as to prevent unnecessary flooding. 86 When using this technique a node can use arbitrary number of circuits 87 only being restricted by the fact that it cannot be DIS on more 88 than 255 circuits since PNodes would become indistinguishable for 89 different LANs. To solve that problem, different techniques, such 90 as using multiple router IDs would be necessary, are however outside 91 the scope of this draft. A possible, simple treatement of this 92 problem is for a node to generate appropriate event or management 93 notification and drop all hello packets on the appropriate LAN until 94 a unique circuit ID becomes available or it detects a node with 95 higher preference to become DIS on such LAN. Before going into the 96 details of the procedure in the next section, it is worth to notice 97 that the unique circuit IDs can be separated between levels (2) . 99 3.1. Modification of the Behavior on Broadcast Media 101 The exact modification of the behavior for broadcast links is 102 given here. It is a modification of chapter 8.4.1 of the original 103 specification that states: 105 When the broadcast circuit is enabled on an Intermediate system the 106 IS shall perform the following actions. 108 a) Commence sending IIH PDUs with the LAN ID field set to the 109 concatenation of its own SystemID and its locally assigned one 110 octet Local Circuit ID. 112 b) ... 114 c) Start listening for ISO 9542 ISH PDUs and ESH PDUs and 115 acquire adjacencies as appropriate. Do not run the Designated 116 Intermediate System election process. 118 d) After waiting ISISHelloTimer * 2 seconds, run the Level 1 and/or 119 the Level 2 Designated Intermediate System election process, 120 depending on the Intermediate system type. This shall be run 121 subsequently whenever an IIH PDU is received or transmitted as 122 described in 8.4.3. (For these purposes, the transmission of the 123 system's own IIH PDU is equivalent to receiving it). If there 125 ___________________________________________ 126 2. since a node can become DIS at either level independently 127 has been no change to the information on which the election is 128 performed since the last time it was run, the previous result can 129 be assumed. The relevant information is 131 1) the set of Intermediate system adjacency states, 133 2) the set of Intermediate System priorities (including this 134 system's) and 136 3) the existence (or otherwise) of at least one "Up" End system 137 (not including Manual Adjacencies) or Intermediate system 138 adjacency on the circuit. 139 An Intermediate system shall not declare itself to be a LAN 140 Designated Intermediate system of any type until it has at least one 141 "Up" End system (not including Manual Adjacencies) or Intermediate 142 system adjacency on the circuit. (This prevents an Intermediate 143 System which has a defective receiver and is incapable of receiving 144 any PDUs from erroneously electing itself LAN Designated Intermediate 145 System.) The LAN ID field in the LAN IIH PDUs transmitted by this 146 system shall be set to the value of the LAN ID reported in the LAN 147 IIH PDU (for the appropriate level) received from the system which 148 this system considers to be the Designated Intermediate System. This 149 value shall also be passed to the Update Process, as the pseudonode 150 ID, to enable Link State PDUs to be issued for this system claiming 151 connectivity to the pseudonode. If this system, as a result of the 152 Designated Intermediate System election process, considers itself to 153 be designated Intermediate System, the LAN ID field shall be set to 154 the concatenation of this system's own ID and the locally assigned 155 one octet Local Circuit ID. 156 One additional point has to be introduced: 158 a) Commence sending IIH PDUs with the LAN ID field set to the 159 concatenation of its own SystemID and a local non-zero, not 160 necessarily unique circuit ID. 162 b) ... 163 c) Start listening for ISO 9542 ISH PDUs and ESH PDUs and 164 acquire adjacencies as appropriate. Do not run the Designated 165 Intermediate System election process. 167 d) After waiting ISISHelloTimer * 2 seconds, run the Level 1 and 168 or the Level 2 Designated Intermediate System election process 169 depending on the Intermediate system type. If in any point in 170 time the decision process determines the node to be DIS for this 171 LAN: 173 1) Commence sending IIH PDUs with the LAN ID field set to the 174 concatenation of its own SystemID and a local unique circuit 175 ID. 177 otherwise exhibit standard behavior. 179 4. Acknowledgments 181 Some smart people probably thought about most of these things before 182 and the p2p case may be documented in the best current practices 183 for IS-IS in the Internet. Mike Shand and Tony Li commented on the 184 proposal. 186 5. Security Consideration 188 ISIS security applies to the work presented. No specific security 189 issues with the proposed solutions are known. 191 6. Intellectual Property Considerations 193 Lucent may seek patent or other intellectual property protection 194 for some or all of the technologies disclosed in this document. If 195 any standards arising from this document are or become protected 196 by one or more patents assigned to Lucent, Lucent intends to 197 disclose those patents and license them under openly specified and 198 non-discriminatory terms. 199 References 201 [Cal90a] R. Callon. OSI ISIS Intradomain Routing Protocol. 202 INTERNET-RFC, Internet Engineering Task Force, February 203 1990. 205 [Cal90b] R. Callon. Use of OSI ISIS for Routing in TCP/IP and Dual 206 Environments. INTERNET-RFC, Internet Engineering Task 207 Force, December 1990. 209 [ISO90] ISO. Information Technology - Telecommunications and 210 Information Exchange between Systems - Intermediate System 211 to Intermediate System Routing Exchange Protocol for 212 Use in Conjunction with the Protocol for Providing the 213 Connectionless-Mode Network Service. ISO, 1990. 215 [Kat99] D. Katz. Three-Way Handshake for IS-IS Point-to-Point 216 Adjacencies. work-in-progress, Internet Engineering Task 217 Force, 1999. 219 Authors' Addresses 221 Tony Przygienda 222 Siara Systems 223 300 Ferguson Drive 224 Mountain View, CA 94043 225 prz@siara.com