idnits 2.17.1 draft-ietf-isis-3way-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 == The page length should not exceed 58 lines per page, but there was 6 longer pages, the longest (page 2) being 60 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 7 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** 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 6 instances of too long lines in the document, the longest one being 6 characters in excess of 72. == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 229 has weird spacing: '...ased on the c...' -- 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 (May 2000) is 8746 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. '1' -- Possible downref: Non-RFC (?) normative reference: ref. '2' Summary: 6 errors (**), 0 flaws (~~), 5 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Dave Katz 3 INTERNET DRAFT Juniper Networks, Inc. 4 Expiration Date: November 2000 Rajesh Saluja 5 Nortel Networks, Inc. 6 May 2000 8 Three-Way Handshake for IS-IS Point-to-Point Adjacencies 10 draft-ietf-isis-3way-02.txt 12 Status of this Memo 14 This document is an Internet-Draft and is in full conformance with 15 all provisions of Section 10 of RFC2026. Internet-Drafts are working 16 documents of the Internet Engineering Task Force (IETF), its areas, 17 and its working groups. Note that other groups may also distribute 18 working documents as Internet-Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 Abstract 33 The IS-IS routing protocol (ISO 10589) does not use a three-way 34 handshake when establishing adjacencies on point-to-point media. 35 This paper defines an backward-compatible extension to the protocol 36 that provides for a three-way handshake. It is fully interoperable 37 with systems that do not support the extension. 39 Additionally, the extension allows the robust operation of more than 40 256 point-to-point links on a single router. 42 This extension has been implemented by multiple router vendors; this 43 paper is provided as information to the Internet community in order 44 to allow interoperable implementations to be built by other vendors. 46 1.0 Introduction 48 The IS-IS protocol [1] provides only a two-way handshake when 49 establishing adjacencies on point-to-point links. The basic 50 mechanism defined in the standard is that each side declares the 51 other side to be reachable if a Hello packet is heard from it. Once 52 this occurs, each side then sends a Complete Sequence Number PDU 53 (CSNP) to trigger database synchronization. 55 Three failure modes are known. First, if the link goes down and then 56 comes back up, or one of the systems restarts, and the CSNP packet is 57 lost, and the network has a cut set of one through the link, the link 58 state databases on either side of the link will not synchronize for a 59 full LSP refresh period (up to eighteen hours). 61 A second, more serious failure, is that if the link fails in only one 62 direction, the failure will only be detected by one of the systems. 63 Normally, this is not a serious issue; only one of the two systems 64 will announce the adjacency in its link state packets, and the SPF 65 algorithm will thus ignore the link. However, if there are two 66 parallel links between systems and one of them fails in one 67 direction, SPF will still calculate paths between the two systems, 68 and the system that does not notice the failure will attempt to pass 69 traffic down the failed link (in the direction that does not work). 71 In addition, SONET links bring a third issue, which is that when 72 SONET protection is used, a system may receive packets that are 73 actually destined for a different system (or a different link on the 74 same system). The receiving system may end up thinking that it has 75 an adjacency with the remote system when in fact the remote system is 76 adjacent with a third system. 78 As part of the solution to the three-way handshaking issue, a method 79 is defined for supporting more than 256 point-to-point interfaces 80 which is more robust than the ad hoc methods currently in use. 82 2.0 Overview of Extensions 84 2.1 Handshaking 86 The intent is to provide a three-way handshake for point-to-point 87 adjacency establishment in an backward compatible fashion. This is 88 done by providing an optional mechanism that allows each system to 89 report its adjacency state; this allows a system to only declare an 90 adjacency to be up if it knows that the other system is receiving its 91 IS-IS Hello (IIH) packets. In addition, the neighbor's system ID and 92 (newly-defined) extended circuit ID are reported in order to detect 93 the case where the same stream is being received by multiple systems 94 (only one of which can talk back). 96 The mechanism is quite similar to the one defined in the Netware Link 97 Services Protocol (NLSP) [2], a variant of IS-IS used for routing IPX 98 traffic. The difference between this mechanism and the one used in 99 NLSP is the location where the information is carried (NLSP uses two 100 of the reserved bits in the IIH header, whereas this solution adds a 101 separate option to the IIH), and the presence of the neighbor's 102 system ID and circuit ID. In theory, using the reserved header bits 103 should be backward compatible, since systems are supposed to ignore 104 them. However, it was felt that this was risky, as the use of 105 untested mechanisms such as this have led to problems in the past in 106 other protocols. New option codes, on the other hand, have been 107 demonstrated to work properly, as the deployment of Integrated IS-IS 108 for IP [3] has done exactly this. It is also worth noting that the 109 encoding used in the NLSP solution does not lend itself to backward 110 compatibility. 112 The new mechanism only comes into play when the remote system 113 includes the new option in its IIH packet; if the option is not 114 present, it is assumed that the system does not support the new 115 mechanism, and so the old procedures are used. 117 2.2 More Than 256 Interfaces 119 The IS-IS specification has an implicit limit of 256 interfaces, as 120 constrained by the eight bit Circuit ID field carried in various 121 packets. Moderately clever implementors have realized that the only 122 true constraint is that of 256 LAN interfaces, and for that matter 123 only 256 LAN interfaces for which a system is the Designated IS. 124 This is because the only place that the circuit ID is advertised in 125 LSPs is in the pseudonode LSP ID. 127 Implementors have treated the point-to-point Circuit ID number space 128 as being independent from that of the LAN interfaces, since these 129 Circuit IDs appear only in IIH PDUs and are only used for detection 130 of a change in identity at the other end of a link. More than 256 131 point-to-point interfaces have been supported by sending the same 132 circuit ID on multiple interfaces. This reduces the robustness of 133 the ID change detection algorithm, since it would then be possible to 134 switch links between interfaces on a system without detecting the 135 change. 137 Since the Circuit ID is an integral part of the new handshaking 138 mechanism, a backward compatible mechanism for expanding the circuit 139 ID number space is included in this specification. 141 3.0 Details 143 3.1 Syntax 145 A new IS-IS Option type, "Point-to-Point Adjacency State", is 146 defined: 148 Type = 0xF0 (decimal 240) 149 Length = 5 to 17 octets 150 Value: 151 Adjacency State (one octet): 152 0 = Up 153 1 = Initializing 154 2 = Down 155 Extended Local Circuit ID (four octets) 156 Neighbor System ID if known (zero to eight octets) 157 Neighbor Extended Local Circuit ID (four octets, if Neighbor 158 System ID is present) 160 Any system that supports this mechanism shall include this option in 161 its Point-to-Point IIH packets. 163 Any system that does not understand this option will ignore it, and 164 (of course) will not include it in its own IIH packets. 166 Any system that is able to process this option shall follow the 167 procedures below. 169 3.2 Elements of Procedure 171 The new handshake procedure is added to the IS-IS point-to-point IIH 172 state machine after the PDU acceptance tests have been performed. 173 The existing procedures are only executed if the neighbor is in the 174 proper state for the adjacency to come up. 176 Although the extended circuit ID is only used in the context of the 177 three-way handshake, it is worth noting that it effectively protects 178 against the unlikely event where a link is moved to another interface 179 on a system that has the same local circuit ID, as the received PDUs 180 will be ignored (via the checks defined below) and the existing 181 adjacency will fail. 183 Add a clause e) to the end of section 8.2.3: 185 The IS shall include the Point-to-Point Adjacency State option in 186 the transmitted Point-to-Point IIH PDU. The current state of the 187 adjacency with its neighbor on the link (as defined in section 188 8.2.4.1.1) shall be reported in the Adjacency State field. If no 189 adjacency exists, the state shall be reported as Down. 191 The Extended Local Circuit ID field shall contain a value assigned 192 by this IS when the circuit is created. This value shall be unique 193 among all the circuits of this Intermediate System. The value is 194 not necessarily related to that carried in the Local Circuit ID 195 field of the IIH PDU. 197 If the system ID and Extended Local Circuit ID of the neighboring 198 system are known (in state Initializing or Up), the neighbor's 199 system ID shall be reported in the Neighbor System ID field, and 200 the neighbor's Extended Local Circuit ID shall be reported in the 201 Neighbor Extended Local Circuit ID field. 203 Add a section 8.2.4.1.1, Three-Way Handshake, immediately prior to 204 section 8.2.4.2: 206 A received Point-to-Point IIH PDU may or may not contain the 207 Point-to-Point Adjacency State option. If it does not, the link is 208 assumed to be functional in both directions, and the procedures 209 described in section 8.2.4.2 are followed. 211 If the option is present, the Neighbor System ID and Neighbor 212 Extended Local Circuit ID fields, if present, shall be examined. 213 If they are present, and the system ID contained therein does not 214 match the local system's ID, or the extended circuit ID does not 215 match the local system's extended circuit ID, the PDU shall be 216 discarded and no further action is taken. 218 If the Neighbor System ID and Neighbor Extended Local Circuit ID 219 fields match those of the local system, or are not present, the 220 procedures described in section 8.2.4.2 are followed with following 221 changes: 223 a) In section 8.2.4.2 a and b, the action "Up" from state tables 224 5, 6, 7 and 8 may create new adjacency but the state of the 225 adjacency will be Down. 227 b) If the action taken from section 8.2.4.2 a or b is "Up" or 228 "Accept", the IS shall perform the action indicated by the 229 new state table below, based on the current adjacency state 230 and the received state value from the option. (Note that the 231 procedure works properly if neither field is ever included. 232 This provides backward compatibility to an earlier version of 233 this option.) 234 Received State 235 Down Initializing Up 236 ------------------------------------------------- 237 Down | Initialize Up Down 238 | 239 Adj Initializing | Initialize Up Up 240 State | 241 Up | Initialize Accept Accept 243 If the new action is "Down", an adjacencyStateChange(Down) event is 244 generated with the reason "Neighbor restarted" and the adjacency shall 245 be deleted. 247 If the new action is "Initialize", the adjacency state shall be set to 248 "Initializing". 250 If the new action is "Up", an adjacencyStateChange(Up) event is 251 generated. 253 c) Skip section 8.2.4.2 c and d. 255 d) If the new action is "Initialize", "Up" or "Accept", follow section 256 8.2.4.2 e. 258 4.0 References 260 [1] ISO, "Intermediate system to Intermediate system routeing 261 information exchange protocol for use in conjunction with the 262 Protocol for providing the Connectionless-mode Network Service 263 (ISO 8473)," ISO/IEC 10589:1992. 265 [2] "Netware Link Services Protocol Specification, Version 1.0", 266 Novell, Inc., February 1994. 268 [3] Callon, R., "OSI IS-IS for IP and Dual Environment," RFC 1195, 269 December 1990. 271 Acknowledgements 273 The authors would like to thank Tony Li, Henk Smit, Naiming Shen, and 274 Dave Ward for their contributions to this document. 276 Author's Addresses: 278 Dave Katz 279 Juniper Networks 280 385 Ravendale Drive 281 Mountain View, CA 94043 USA 283 Phone: +1 650 526 8073 284 Email: dkatz@juniper.net 286 Rajesh Saluja 287 Nortel Networks 288 600 Technology Park Drive 289 Billerica, MA 01821 USA 291 Phone: +1 978 288 7791 292 Email: rsaluja@nortelnetworks.com