idnits 2.17.1 draft-ietf-isis-3way-03.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 235 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 (July 2000) is 8679 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: January 2001 Rajesh Saluja 5 Nortel Networks, Inc. 6 July 2000 8 Three-Way Handshake for IS-IS Point-to-Point Adjacencies 10 draft-ietf-isis-3way-03.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) requires reliable protocols at 34 the link layer for point-to-point links. As a result, it does not use 35 a three-way handshake when establishing adjacencies on point-to-point 36 media. This paper defines an backward-compatible extension to the 37 protocol that provides for a three-way handshake. It is fully 38 interoperable with systems that do not support the extension. 40 Additionally, the extension allows the robust operation of more than 41 256 point-to-point links on a single router. 43 This extension has been implemented by multiple router vendors; this 44 paper is provided as information to the Internet community in order 45 to allow interoperable implementations to be built by other vendors. 47 1.0 Introduction 49 The IS-IS protocol [1] assumes certain requirements stated in ISO 50 10589 (section 6.7.2) for the operation of IS-IS over point-to-point 51 links and hence provides only a two-way handshake when establishing 52 adjacencies on point-to-point links. The protocol does not operate 53 correctly if these subnetwork requirements for point-to-point links 54 are not met. The basic mechanism defined in the standard is that 55 each side declares the other side to be reachable if a Hello packet 56 is heard from it. Once this occurs, each side then sends a Complete 57 Sequence Number PDU (CSNP) to trigger database synchronization. 59 Three failure modes are known. First, if the link goes down and then 60 comes back up, or one of the systems restarts, and the CSNP packet is 61 lost, and the network has a cut set of one through the link, the link 62 state databases on either side of the link will not synchronize for a 63 full LSP refresh period (up to eighteen hours). 65 A second, more serious failure, is that if the link fails in only one 66 direction, the failure will only be detected by one of the systems. 67 Normally, this is not a serious issue; only one of the two systems 68 will announce the adjacency in its link state packets, and the SPF 69 algorithm will thus ignore the link. However, if there are two 70 parallel links between systems and one of them fails in one 71 direction, SPF will still calculate paths between the two systems, 72 and the system that does not notice the failure will attempt to pass 73 traffic down the failed link (in the direction that does not work). 75 In addition, SONET links bring a third issue, which is that when 76 SONET protection is used, a system may receive packets that are 77 actually destined for a different system (or a different link on the 78 same system). The receiving system may end up thinking that it has 79 an adjacency with the remote system when in fact the remote system is 80 adjacent with a third system. 82 The solution proposed here ensures correct operation of the protocol 83 over unreliable point-to-point links. As part of the solution to the 84 three-way handshaking issue, a method is defined for supporting more 85 than 256 point-to-point interfaces which is more robust than the ad 86 hoc methods currently in use. 88 2.0 Overview of Extensions 90 2.1 Handshaking 92 The intent is to provide a three-way handshake for point-to-point 93 adjacency establishment in an backward compatible fashion. This is 94 done by providing an optional mechanism that allows each system to 95 report its adjacency state; this allows a system to only declare an 96 adjacency to be up if it knows that the other system is receiving its 97 IS-IS Hello (IIH) packets. In addition, the neighbor's system ID and 98 (newly-defined) extended circuit ID are reported in order to detect 99 the case where the same stream is being received by multiple systems 100 (only one of which can talk back). 102 The mechanism is quite similar to the one defined in the Netware Link 103 Services Protocol (NLSP) [2], a variant of IS-IS used for routing IPX 104 traffic. The difference between this mechanism and the one used in 105 NLSP is the location where the information is carried (NLSP uses two 106 of the reserved bits in the IIH header, whereas this solution adds a 107 separate option to the IIH), and the presence of the neighbor's 108 system ID and circuit ID. In theory, using the reserved header bits 109 should be backward compatible, since systems are supposed to ignore 110 them. However, it was felt that this was risky, as the use of 111 untested mechanisms such as this have led to problems in the past in 112 other protocols. New option codes, on the other hand, have been 113 demonstrated to work properly, as the deployment of Integrated IS-IS 114 for IP [3] has done exactly this. It is also worth noting that the 115 encoding used in the NLSP solution does not lend itself to backward 116 compatibility. 118 The new mechanism only comes into play when the remote system 119 includes the new option in its IIH packet; if the option is not 120 present, it is assumed that the system does not support the new 121 mechanism, and so the old procedures are used. 123 2.2 More Than 256 Interfaces 125 The IS-IS specification has an implicit limit of 256 interfaces, as 126 constrained by the eight bit Circuit ID field carried in various 127 packets. Moderately clever implementors have realized that the only 128 true constraint is that of 256 LAN interfaces, and for that matter 129 only 256 LAN interfaces for which a system is the Designated IS. 130 This is because the only place that the circuit ID is advertised in 131 LSPs is in the pseudonode LSP ID. 133 Implementors have treated the point-to-point Circuit ID number space 134 as being independent from that of the LAN interfaces, since these 135 Circuit IDs appear only in IIH PDUs and are only used for detection 136 of a change in identity at the other end of a link. More than 256 137 point-to-point interfaces have been supported by sending the same 138 circuit ID on multiple interfaces. This reduces the robustness of 139 the ID change detection algorithm, since it would then be possible to 140 switch links between interfaces on a system without detecting the 141 change. 143 Since the Circuit ID is an integral part of the new handshaking 144 mechanism, a backward compatible mechanism for expanding the circuit 145 ID number space is included in this specification. 147 3.0 Details 149 3.1 Syntax 151 A new IS-IS Option type, "Point-to-Point Adjacency State", is 152 defined: 154 Type = 0xF0 (decimal 240) 155 Length = 5 to 17 octets 156 Value: 157 Adjacency State (one octet): 158 0 = Up 159 1 = Initializing 160 2 = Down 161 Extended Local Circuit ID (four octets) 162 Neighbor System ID if known (zero to eight octets) 163 Neighbor Extended Local Circuit ID (four octets, if Neighbor 164 System ID is present) 166 Any system that supports this mechanism shall include this option in 167 its Point-to-Point IIH packets. 169 Any system that does not understand this option will ignore it, and 170 (of course) will not include it in its own IIH packets. 172 Any system that is able to process this option shall follow the 173 procedures below. 175 3.2 Elements of Procedure 177 The new handshake procedure is added to the IS-IS point-to-point IIH 178 state machine after the PDU acceptance tests have been performed. 179 The existing procedures are only executed if the neighbor is in the 180 proper state for the adjacency to come up. 182 Although the extended circuit ID is only used in the context of the 183 three-way handshake, it is worth noting that it effectively protects 184 against the unlikely event where a link is moved to another interface 185 on a system that has the same local circuit ID, as the received PDUs 186 will be ignored (via the checks defined below) and the existing 187 adjacency will fail. 189 Add a clause e) to the end of section 8.2.3: 191 The IS shall include the Point-to-Point Adjacency State option in 192 the transmitted Point-to-Point IIH PDU. The current state of the 193 adjacency with its neighbor on the link (as defined in section 194 8.2.4.1.1) shall be reported in the Adjacency State field. If no 195 adjacency exists, the state shall be reported as Down. 197 The Extended Local Circuit ID field shall contain a value assigned 198 by this IS when the circuit is created. This value shall be unique 199 among all the circuits of this Intermediate System. The value is 200 not necessarily related to that carried in the Local Circuit ID 201 field of the IIH PDU. 203 If the system ID and Extended Local Circuit ID of the neighboring 204 system are known (in state Initializing or Up), the neighbor's 205 system ID shall be reported in the Neighbor System ID field, and 206 the neighbor's Extended Local Circuit ID shall be reported in the 207 Neighbor Extended Local Circuit ID field. 209 Add a section 8.2.4.1.1, Three-Way Handshake, immediately prior to 210 section 8.2.4.2: 212 A received Point-to-Point IIH PDU may or may not contain the 213 Point-to-Point Adjacency State option. If it does not, the link is 214 assumed to be functional in both directions, and the procedures 215 described in section 8.2.4.2 are followed. 217 If the option is present, the Neighbor System ID and Neighbor 218 Extended Local Circuit ID fields, if present, shall be examined. 219 If they are present, and the system ID contained therein does not 220 match the local system's ID, or the extended circuit ID does not 221 match the local system's extended circuit ID, the PDU shall be 222 discarded and no further action is taken. 224 If the Neighbor System ID and Neighbor Extended Local Circuit ID 225 fields match those of the local system, or are not present, the 226 procedures described in section 8.2.4.2 are followed with following 227 changes: 229 a) In section 8.2.4.2 a and b, the action "Up" from state tables 230 5, 6, 7 and 8 may create new adjacency but the state of the 231 adjacency will be Down. 233 b) If the action taken from section 8.2.4.2 a or b is "Up" or 234 "Accept", the IS shall perform the action indicated by the 235 new state table below, based on the current adjacency state 236 and the received state value from the option. (Note that the 237 procedure works properly if neither field is ever included. 238 This provides backward compatibility to an earlier version of 239 this option.) 241 Received State 242 Down Initializing Up 243 ------------------------------------------------- 244 Down | Initialize Up Down 245 | 246 Adj Initializing | Initialize Up Up 247 State | 248 Up | Initialize Accept Accept 250 If the new action is "Down", an adjacencyStateChange(Down) event is 251 generated with the reason "Neighbor restarted" and the adjacency shall 252 be deleted. 254 If the new action is "Initialize", the adjacency state shall be set to 255 "Initializing". 257 If the new action is "Up", an adjacencyStateChange(Up) event is 258 generated. 260 c) Skip section 8.2.4.2 c and d. 262 d) If the new action is "Initialize", "Up" or "Accept", follow section 263 8.2.4.2 e. 265 4.0 References 267 [1] ISO, "Intermediate system to Intermediate system routeing 268 information exchange protocol for use in conjunction with the 269 Protocol for providing the Connectionless-mode Network Service 270 (ISO 8473)," ISO/IEC 10589:1992. 272 [2] "Netware Link Services Protocol Specification, Version 1.0", 273 Novell, Inc., February 1994. 275 [3] Callon, R., "OSI IS-IS for IP and Dual Environment," RFC 1195, 276 December 1990. 278 Acknowledgements 280 The authors would like to thank Tony Li, Henk Smit, Naiming Shen, 281 Dave Ward, and Jeff Learman for their contributions to this document. 283 Author's Addresses: 285 Dave Katz 286 Juniper Networks 287 385 Ravendale Drive 288 Mountain View, CA 94043 USA 290 Phone: +1 650 526 8073 291 Email: dkatz@juniper.net 293 Rajesh Saluja 294 Nortel Networks 295 600 Technology Park Drive 296 Billerica, MA 01821 USA 298 Phone: +1 978 288 7791 299 Email: rsaluja@nortelnetworks.com