idnits 2.17.1 draft-ietf-isis-3way-04.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 185: '...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 (January 2002) is 8131 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: July 2002 Rajesh Saluja 5 Nortel Networks, Inc. 6 January 2002 8 Three-Way Handshake for IS-IS Point-to-Point Adjacencies 10 draft-ietf-isis-3way-04.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 (four octets, if Neighbor 177 System ID is present) 179 Any system that supports this mechanism shall include this option in 180 its Point-to-Point IIH packets. 182 Any system that does not understand this option will ignore it, and 183 (of course) will not include it in its own IIH packets. 185 Any system that supports this mechanism MUST include Adjacency 186 Three-Way State field in this option. The other fields in this option 187 should be included as explained below in section 3.2. 189 Any system that is able to process this option shall follow the 190 procedures below. 192 3.2 Elements of Procedure 194 The new handshake procedure is added to the IS-IS point-to-point IIH 195 state machine after the PDU acceptance tests have been performed. 196 The existing procedures are only executed if the neighbor is in the 197 proper state for the adjacency to come up. 199 Although the extended circuit ID is only used in the context of the 200 three-way handshake, it is worth noting that it effectively protects 201 against the unlikely event where a link is moved to another interface 202 on a system that has the same local circuit ID, as the received PDUs 203 will be ignored (via the checks defined below) and the existing 204 adjacency will fail. 206 Add a clause e) to the end of section 8.2.2 of [1]: 208 Set the state to be reported in the Adjacency Three-Way State field 209 of the Point-to-Point Three-Way Adjacency option to Down." 211 Add a clause e) to the end of section 8.2.3 of [1]: 213 The IS shall include the Point-to-Point Three-Way Adjacency option 214 in the transmitted Point-to-Point IIH PDU. The current three-way 215 state of the adjacency with its neighbor on the link (as defined in 216 new section 8.2.4.1.1) shall be reported in the Adjacency Three-Way 217 State field. If no adjacency exists, the state shall be reported as 218 Down. 220 The Extended Local Circuit ID field shall contain a value assigned 221 by this IS when the circuit is created. This value shall be unique 222 among all the circuits of this Intermediate System. The value is 223 not necessarily related to that carried in the Local Circuit ID 224 field of the IIH PDU. 226 If the system ID and Extended Local Circuit ID of the neighboring 227 system are known (in adjacency three-way state Initializing or Up), 228 the neighbor's system ID shall be reported in the Neighbor System 229 ID field, and the neighbor's Extended Local Circuit ID shall be 230 reported in the Neighbor Extended Local Circuit ID field. 232 Add a section 8.2.4.1.1, Three-Way Handshake, immediately prior to 233 section 8.2.4.2: 235 A received Point-to-Point IIH PDU may or may not contain the 236 Point-to-Point Three-Way Adjacency option. If it does not, the link 237 is assumed to be functional in both directions, and the procedures 238 described in section 8.2.4.2 are followed. 240 If the option is present, the Neighbor System ID and Neighbor 241 Extended Local Circuit ID fields, if present, shall be examined. If 242 they are present, and the Neighbor System ID contained therein does 243 not match the local system's ID, or the Neighbor Extended Local 244 Circuit ID does not match the local system's extended circuit ID, 245 the PDU shall be discarded and no further action is taken. 247 If the Neighbor System ID and Neighbor Extended Local Circuit ID 248 fields match those of the local system, or are not present, the 249 procedures described in section 8.2.4.2 are followed with following 250 changes: 252 a) In section 8.2.4.2 a and b, the action "Up" from state tables 253 5, 6, 7 and 8 may create a new adjacency but the three-way 254 state of the adjacency will be Down. 256 b) If the action taken from section 8.2.4.2 a or b is "Up" or 257 "Accept", the IS shall perform the action indicated by the 258 new adjacency three-way state table below, based on the 259 current adjacency three-way state and the received Adjacency 260 Three-Way State value from the option. (Note that the 261 procedure works properly if neither field is ever included. 262 This provides backward compatibility to an earlier version of 263 this option.) 264 Received Adjacency Three-Way State 265 Down Initializing Up 266 ------------------------------------------------- 267 Down | Initialize Up Down 268 | 269 adj Initializing | Initialize Up Up 270 three | 271 -way Up | Initialize Accept Accept 272 state | 273 | 275 If the new action is "Down", an adjacencyStateChange(Down) 276 event is generated with the reason "Neighbor restarted" and the 277 adjacency shall be deleted. 279 If the new action is "Initialize", the adjacency three-way state 280 shall be set to "Initializing". 282 If the new action is "Up", an adjacencyStateChange(Up) 283 event is generated. 285 c) Skip section 8.2.4.2 c and d. 287 d) If the new action is "Initialize", "Up" or "Accept", follow section 288 8.2.4.2 e. 290 4.0 References 292 [1] ISO, "Intermediate system to Intermediate system routeing 293 information exchange protocol for use in conjunction with the 294 Protocol for providing the Connectionless-mode Network Service 295 (ISO 8473)", ISO/IEC 10589:1992. 297 [2] "Netware Link Services Protocol Specification, Version 1.0", 298 Novell, Inc., February 1994. 300 [3] Callon, R., "OSI IS-IS for IP and Dual Environment", RFC 1195, 301 December 1990. 303 [4] Tony Przygienda, "Reserved TLV Codepoints in ISIS", Work in 304 Progress, July 2001 306 Acknowledgements 308 The authors would like to thank Tony Li, Henk Smit, Naiming Shen, 309 Dave Ward, Jeff Learman, Les Ginsberg and Philip Christian for their 310 contributions to this document. 312 Author's Addresses: 314 Dave Katz 315 Juniper Networks 316 385 Ravendale Drive 317 Mountain View, CA 94043 USA 319 Phone: +1 650 526 8073 320 Email: dkatz@juniper.net 322 Rajesh Saluja 323 Nortel Networks 324 600 Technology Park Drive 325 Billerica, MA 01821 USA 327 Phone: +1 978 288 7791 328 Email: rsaluja@nortelnetworks.com