idnits 2.17.1 draft-ietf-isis-3way-05.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 7 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 8 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 3 instances of too long lines in the document, the longest one being 3 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. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 184: '...s this mechanism MUST include Adjacenc...' 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 (February 2002) is 8104 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' -- Possible downref: Non-RFC (?) normative reference: ref. '4' Summary: 7 errors (**), 0 flaws (~~), 4 warnings (==), 5 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: August 2002 Rajesh Saluja 5 Nortel Networks, Inc. 6 February 2002 8 Three-Way Handshake for IS-IS Point-to-Point Adjacencies 10 draft-ietf-isis-3way-05.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 a 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 each 55 side declares the other side to be reachable if a Hello packet is 56 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 The third issue is that on some physical layers, the 76 interconnectivity between endpoints can change without causing a 77 link-layer-down condition. In this case, a system may receive packets 78 that are actually destined for a different system (or a different 79 link on the same system). The receiving system may end up thinking 80 that it has an adjacency with the remote system when in fact the 81 remote system is adjacent with a third system. 83 The solution proposed here ensures correct operation of the protocol 84 over unreliable point-to-point links. As part of the solution to the 85 three-way handshaking issue, a method is defined for supporting more 86 than 256 point-to-point interfaces which is more robust than the ad 87 hoc methods currently in use. 89 2.0 Overview of Extensions 91 2.1 Handshaking 93 The intent is to provide a three-way handshake for point-to-point 94 adjacency establishment in a backward compatible fashion. This is 95 done by providing an optional mechanism that allows each system to 96 report its adjacency three-way state; this allows a system to only 97 declare an adjacency to be up if it knows that the other system is 98 receiving its IS-IS Hello (IIH) packets. 100 The adjacency three-way state that is reported by this mechanism is 101 not equal or equivalent to the adjacency state that is described in 102 ISO 10589 [1]. If this mechanism is supported then an adjacency may 103 have two states, its state as defined in ISO 10589[1], and its 104 three-way state. For example according to ISO 10589 [1] receipt of an 105 ISH will cause an adjacency to go to Initializing state; however 106 receipt of an ISH will have no effect on the three-way state of an 107 adjacency, which remains firmly Down until it receives an IIH from a 108 neighbor that contains the three-way handshaking option. 110 In addition, the neighbor's system ID and (newly-defined) extended 111 circuit ID are reported in order to detect the case where the same 112 stream is being received by multiple systems (only one of which can 113 talk back). 115 The mechanism is quite similar to the one defined in the Netware Link 116 Services Protocol (NLSP) [2], a variant of IS-IS used for routing IPX 117 traffic. The difference between this mechanism and the one used in 118 NLSP is the location where the information is carried (NLSP uses two 119 of the reserved bits in the IIH header, whereas this solution adds a 120 separate option to the IIH), and the presence of the neighbor's 121 system ID and circuit ID. In theory, using the reserved header bits 122 should be backward compatible, since systems are supposed to ignore 123 them. However, it was felt that this was risky, as the use of 124 untested mechanisms such as this have led to problems in the past in 125 other protocols. New option codes, on the other hand, have been 126 demonstrated to work properly, as the deployment of Integrated IS-IS 127 for IP [3] has done exactly this. It is also worth noting that the 128 encoding used in the NLSP solution does not lend itself to backward 129 compatibility. 131 The new mechanism only comes into play when the remote system 132 includes the new option in its IIH packet; if the option is not 133 present, it is assumed that the system does not support the new 134 mechanism, and so the old procedures are used. 136 2.2 More Than 256 Interfaces 138 The IS-IS specification has an implicit limit of 256 interfaces, as 139 constrained by the eight bit Circuit ID field carried in various 140 packets. Moderately clever implementors have realized that the only 141 true constraint is that of 256 LAN interfaces, and for that matter 142 only 256 LAN interfaces for which a system is the Designated IS. This 143 is because the only place that the circuit ID is advertised in LSPs 144 is in the pseudonode LSP ID. 146 Implementors have treated the point-to-point Circuit ID number space 147 as being independent from that of the LAN interfaces, since these 148 Circuit IDs appear only in IIH PDUs and are only used for detection 149 of a change in identity at the other end of a link. More than 256 150 point-to-point interfaces have been supported by sending the same 151 circuit ID on multiple interfaces. This reduces the robustness of the 152 ID change detection algorithm, since it would then be possible to 153 switch links between interfaces on a system without detecting the 154 change. 156 Since the Circuit ID is an integral part of the new handshaking 157 mechanism, a backward compatible mechanism for expanding the circuit 158 ID number space is included in this specification. 160 3.0 Details 162 3.1 Syntax 164 A new IS-IS Option type, "Point-to-Point Three-Way Adjacency", is 165 defined [4]: 167 Type = 0xF0 (decimal 240) 168 Length = 1 to 17 octets 169 Value: 170 Adjacency Three-Way State (one octet): 171 0 = Up 172 1 = Initializing 173 2 = Down 174 Extended Local Circuit ID (four octets) 175 Neighbor System ID if known (zero to eight octets) 176 Neighbor Extended Local Circuit ID if known (four octets) 178 Any system that supports this mechanism shall include this option in 179 its Point-to-Point IIH packets. 181 Any system that does not understand this option will ignore it, and 182 (of course) will not include it in its own IIH packets. 184 Any system that supports this mechanism MUST include Adjacency 185 Three-Way State field in this option. The other fields in this option 186 should be included as explained below in section 3.2. 188 Any system that is able to process this option shall follow the 189 procedures below. 191 3.2 Elements of Procedure 193 The new handshake procedure is added to the IS-IS point-to-point IIH 194 state machine after the PDU acceptance tests have been performed. 195 The existing procedures are only executed if the neighbor is in the 196 proper state for the adjacency to come up. 198 Although the extended circuit ID is only used in the context of the 199 three-way handshake, it is worth noting that it effectively protects 200 against the unlikely event where a link is moved to another interface 201 on a system that has the same local circuit ID, as the received PDUs 202 will be ignored (via the checks defined below) and the existing 203 adjacency will fail. 205 Add a clause e) to the end of section 8.2.2 of [1]: 207 Set the state to be reported in the Adjacency Three-Way State field 208 of the Point-to-Point Three-Way Adjacency option to Down. 210 Add a clause e) to the end of section 8.2.3 of [1]: 212 The IS shall include the Point-to-Point Three-Way Adjacency option 213 in the transmitted Point-to-Point IIH PDU. The current three-way 214 state of the adjacency with its neighbor on the link (as defined in 215 new section 8.2.4.1.1) shall be reported in the Adjacency Three-Way 216 State field. If no adjacency exists, the state shall be reported as 217 Down. 219 The Extended Local Circuit ID field shall contain a value assigned 220 by this IS when the circuit is created. This value shall be unique 221 among all the circuits of this Intermediate System. The value is 222 not necessarily related to that carried in the Local Circuit ID 223 field of the IIH PDU. 225 If the system ID and Extended Local Circuit ID of the neighboring 226 system are known (in adjacency three-way state Initializing or Up), 227 the neighbor's system ID shall be reported in the Neighbor System 228 ID field, and the neighbor's Extended Local Circuit ID shall be 229 reported in the Neighbor Extended Local Circuit ID field. 231 Add a section 8.2.4.1.1, Three-Way Handshake, immediately prior to 232 section 8.2.4.2: 234 A received Point-to-Point IIH PDU may or may not contain the 235 Point-to-Point Three-Way Adjacency option. If it does not, the link 236 is assumed to be functional in both directions, and the procedures 237 described in section 8.2.4.2 are followed. 239 If the option is present, the Neighbor System ID and Neighbor 240 Extended Local Circuit ID fields, if present, shall be examined. If 241 they are present, and the Neighbor System ID contained therein does 242 not match the local system's ID, or the Neighbor Extended Local 243 Circuit ID does not match the local system's extended circuit ID, 244 the PDU shall be discarded and no further action is taken. 246 If the Neighbor System ID and Neighbor Extended Local Circuit ID 247 fields match those of the local system, or are not present, the 248 procedures described in section 8.2.4.2 are followed with following 249 changes: 251 a) In section 8.2.4.2 a and b, the action "Up" from state tables 252 5, 6, 7 and 8 may create a new adjacency but the three-way 253 state of the adjacency will be Down. 255 b) If the action taken from section 8.2.4.2 a or b is "Up" or 256 "Accept", the IS shall perform the action indicated by the 257 new adjacency three-way state table below, based on the 258 current adjacency three-way state and the received Adjacency 259 Three-Way State value from the option. (Note that the 260 procedure works properly if neither field is ever included. 261 This provides backward compatibility to an earlier version of 262 this option.) 263 Received Adjacency Three-Way State 264 Down Initializing Up 265 ------------------------------------------------- 266 Down | Initialize Up Down 267 | 268 adj Initializing | Initialize Up Up 269 three | 270 -way Up | Initialize Accept Accept 271 state | 272 | 274 If the new action is "Down", an adjacencyStateChange(Down) 275 event is generated with the reason "Neighbor restarted" and the 276 adjacency shall be deleted. 278 If the new action is "Initialize", the adjacency three-way state 279 shall be set to "Initializing". 281 If the new action is "Up", an adjacencyStateChange(Up) 282 event is generated. 284 c) Skip section 8.2.4.2 c and d. 286 d) If the new action is "Initialize", "Up" or "Accept", follow section 287 8.2.4.2 e. 289 4.0 References 291 [1] ISO, "Intermediate system to Intermediate system routeing 292 information exchange protocol for use in conjunction with the 293 Protocol for providing the Connectionless-mode Network Service 294 (ISO 8473)", ISO/IEC 10589:1992. 296 [2] "Netware Link Services Protocol Specification, Version 1.0", 297 Novell, Inc., February 1994. 299 [3] Callon, R., "OSI IS-IS for IP and Dual Environment", RFC 1195, 300 December 1990. 302 [4] Tony Przygienda, "Reserved TLV Codepoints in ISIS", Work in 303 Progress, January 2002 305 Acknowledgements 307 The authors would like to thank Tony Li, Henk Smit, Naiming Shen, 308 Dave Ward, Jeff Learman, Les Ginsberg and Philip Christian for their 309 contributions to this document. 311 Author's Addresses: 313 Dave Katz 314 Juniper Networks 315 385 Ravendale Drive 316 Mountain View, CA 94043 USA 318 Phone: +1 650 526 8073 319 Email: dkatz@juniper.net 321 Rajesh Saluja 322 Nortel Networks 323 600 Technology Park Drive 324 Billerica, MA 01821 USA 326 Phone: +1 978 288 7791 327 Email: rsaluja@nortelnetworks.com