idnits 2.17.1 draft-ietf-isis-3way-01.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: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** 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 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 is 1 instance of too long lines in the document, the longest one being 2 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 (March 1999) is 9167 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: 7 errors (**), 0 flaws (~~), 1 warning (==), 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: September 1999 March 1999 6 Three-Way Handshake for IS-IS Point-to-Point Adjacencies 8 draft-ietf-isis-3way-01.txt 10 Status of this Memo 12 This document is an Internet-Draft and is in full conformance with 13 all provisions of Section 10 of RFC2026. Internet-Drafts are working 14 documents of the Internet Engineering Task Force (IETF), its areas, 15 and its working groups. Note that other groups may also distribute 16 working documents as Internet-Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six months 19 and may be updated, replaced, or obsoleted by other documents at any 20 time. It is inappropriate to use Internet-Drafts as reference 21 material or to cite them other than as "work in progress." 23 The list of current Internet-Drafts can be accessed at 24 http://www.ietf.org/ietf/1id-abstracts.txt 26 The list of Internet-Draft Shadow Directories can be accessed at 27 http://www.ietf.org/shadow.html. 29 Abstract 31 The IS-IS routing protocol (ISO 10589) does not use a three-way 32 handshake when establishing adjacencies on point-to-point media. 33 This paper defines an backward-compatible extension to the protocol 34 that provides for a three-way handshake. It is fully interoperable 35 with systems that do not support the extension. 37 Additionally, the extension allows the robust operation of more than 38 256 point-to-point links on a single router. 40 This extension has been implemented by multiple router vendors; this 41 paper is provided as information to the Internet community in order 42 to allow interoperable implementations to be built by other vendors. 44 1.0 Introduction 46 The IS-IS protocol [1] provides only a two-way handshake when 47 establishing adjacencies on point-to-point links. The basic 48 mechanism defined in the standard is that each side declares the 49 other side to be reachable if a Hello packet is heard from it. Once 50 this occurs, each side then sends a Complete Sequence Number PDU 51 (CSNP) to trigger database synchronization. 53 Three failure modes are known. First, if the link goes down and then 54 comes back up, or one of the systems restarts, and the CSNP packet is 55 lost, and the network has a cut set of one through the link, the link 56 state databases on either side of the link will not synchronize for a 57 full LSP refresh period (up to eighteen hours). 59 A second, more serious failure, is that if the link fails in only one 60 direction, the failure will only be detected by one of the systems. 61 Normally, this is not a serious issue; only one of the two systems 62 will announce the adjacency in its link state packets, and the SPF 63 algorithm will thus ignore the link. However, if there are two 64 parallel links between systems and one of them fails in one 65 direction, SPF will still calculate paths between the two systems, 66 and the system that does not notice the failure will attempt to pass 67 traffic down the failed link (in the direction that does not work). 69 In addition, SONET links bring a third issue, which is that when 70 SONET protection is used, a system may receive packets that are 71 actually destined for a different system (or a different link on the 72 same system). The receiving system may end up thinking that it has 73 an adjacency with the remote system when in fact the remote system is 74 adjacent with a third system. 76 As part of the solution to the three-way handshaking issue, a method 77 is defined for supporting more than 256 point-to-point interfaces 78 which is more robust than the ad hoc methods currently in use. 80 2.0 Overview of Extensions 82 2.1 Handshaking 84 The intent is to provide a three-way handshake for point-to-point 85 adjacency establishment in an backward compatible fashion. This is 86 done by providing an optional mechanism that allows each system to 87 report its adjacency state; this allows a system to only declare an 88 adjacency to be up if it knows that the other system is receiving its 89 IS-IS Hello (IIH) packets. In addition, the neighbor's system ID and 90 (newly-defined) extended circuit ID are reported in order to detect 91 the case where the same stream is being received by multiple systems 92 (only one of which can talk back). 94 The mechanism is quite similar to the one defined in the Netware Link 95 Services Protocol (NLSP) [2], a variant of IS-IS used for routing IPX 96 traffic. The difference between this mechanism and the one used in 97 NLSP is the location where the information is carried (NLSP uses two 98 of the reserved bits in the IIH header, whereas this solution adds a 99 separate option to the IIH), and the presence of the neighbor's 100 system ID and circuit ID. In theory, using the reserved header bits 101 should be backward compatible, since systems are supposed to ignore 102 them. However, it was felt that this was risky, as the use of 103 untested mechanisms such as this have led to problems in the past in 104 other protocols. New option codes, on the other hand, have been 105 demonstrated to work properly, as the deployment of Integrated IS-IS 106 for IP [3] has done exactly this. It is also worth noting that the 107 encoding used in the NLSP solution does not lend itself to backward 108 compatibility. 110 The new mechanism only comes into play when the remote system 111 includes the new option in its IIH packet; if the option is not 112 present, it is assumed that the system does not support the new 113 mechanism, and so the old procedures are used. 115 2.2 More Than 256 Interfaces 117 The IS-IS specification has an implicit limit of 256 interfaces, as 118 constrained by the eight bit Circuit ID field carried in various 119 packets. Moderately clever implementors have realized that the only 120 true constraint is that of 256 LAN interfaces, and for that matter 121 only 256 LAN interfaces for which a system is the Designated IS. 122 This is because the only place that the circuit ID is advertised in 123 LSPs is in the pseudonode LSP ID. 125 Implementors have treated the point-to-point Circuit ID number space 126 as being independent from that of the LAN interfaces, since these 127 Circuit IDs appear only in IIH PDUs and are only used for detection 128 of a change in identity at the other end of a link. More than 256 129 point-to-point interfaces have been supported by sending the same 130 circuit ID on multiple interfaces. This reduces the robustness of 131 the ID change detection algorithm, since it would then be possible to 132 switch links between interfaces on a system without detecting the 133 change. 135 Since the Circuit ID is an integral part of the new handshaking 136 mechanism, a backward compatible mechanism for expanding the circuit 137 ID number space is included in this specification. 139 3.0 Details 141 3.1 Syntax 143 A new IS-IS Option type, "Point-to-Point Adjacency State", is 144 defined: 146 Type = 0xF0 (decimal 240) 147 Length = 5 to 17 octets 148 Value: 149 Adjacency State (one octet): 150 0 = Up 151 1 = Initializing 152 2 = Down 153 Extended Local Circuit ID (four octets) 154 Neighbor System ID if known (zero to eight octets) 155 Neighbor Extended Local Circuit ID (four octets, if Neighbor 156 System ID is present) 158 Any system that supports this mechanism shall include this option in 159 its Point-to-Point IIH packets. 161 Any system that does not understand this option will ignore it, and 162 (of course) will not include it in its own IIH packets. 164 Any system that is able to process this option shall follow the 165 procedures below. 167 3.2 Elements of Procedure 169 The new handshake procedure is added to the IS-IS point-to-point IIH 170 state machine after the basic validity checks have been made, and 171 before the existing state table is used. The existing procedures are 172 only executed if the neighbor is in the proper state for the 173 adjacency to come up. 175 Although the extended circuit ID is only used in the context of the 176 three-way handshake, it is worth noting that it effectively protects 177 against the unlikely event where a link is moved to another interface 178 on a system that has the same local circuit ID, as the received PDUs 179 will be ignored (via the checks defined below) and the existing 180 adjacency will fail. 182 Add a clause e) to the end of section 8.2.3: 184 The IS shall include the Point-to-Point Adjacency State option in 185 the transmitted Point-to-Point IIH PDU. The current state of the 186 adjacency with its neighbor on the link (as defined in section 187 8.2.4.1.1) shall be reported in the Adjacency State field. If no 188 adjacency exists, the state shall be reported as Down. 190 The Extended Local Circuit ID field shall contain a value assigned 191 by this IS when the circuit is created. This value shall be unique 192 among all the circuits of this Intermediate System. The value is 193 not necessarily related to that carried in the Local Circuit ID 194 field of the IIH PDU. 196 If the system ID of the neighboring system is known (in state 197 Initializing or Up), it shall be reported in the Neighbor System ID 198 field, and the neighbor's Extended Local Circuit ID shall be 199 reported in the Neighbor Extended Local Circuit ID field. 201 Add a section 8.2.4.1.1, Three-Way Handshake, immediately prior to 202 section 8.2.4.2: 204 A received Point-to-Point IIH PDU may or may not contain the Point- 205 to-Point Adjacency State option. If it does not, the link is 206 assumed to be functional in both directions, and the procedures 207 described in section 8.2.4.2 are followed. 209 If the option is present, the Neighbor System ID and Neighbor 210 Extended Local Circuit ID fields, if present, shall be examined. 211 If they are present, and the system ID contained therein does not 212 match the local system's ID, or the extended circuit ID does not 213 match the local system's extended circuit ID, the PDU shall be 214 discarded and no further action is taken. 216 If the Neighbor System ID and Neighbor Extended Local Circuit ID 217 fields match those of the local system, or are not present, the 218 state table below is used to determine the next state, based on the 219 current adjacency state and the received state value from the 220 option. (Note that the procedure works properly if neither field 221 is ever included. This provides backward compatibility to an 222 earlier version of this option.) 224 If the new state is "Down", an adjacencyStateChange(Down) event is 225 generated with the reason "Neighbor restarted" and the adjacency 226 shall be deleted. 228 If the new state is "Initializing", the adjacency state shall be 229 set to "Initializing" and no further action is taken. 231 If the new state is "Up", processing continues as described in 232 section 8.2.4.2. 234 Received State 235 Down Initializing Up 236 ------------------------------------------------- 237 Down | Initializing Initializing Down 238 | 239 Adj Initializing | Initializing Up Up 240 State | 241 Up | Initializing Up Up 243 4.0 References 245 [1] ISO, "Intermediate system to Intermediate system routeing 246 information exchange protocol for use in conjunction with the 247 Protocol for providing the Connectionless-mode Network Service 248 (ISO 8473)," ISO/IEC 10589:1992. 250 [2] "Netware Link Services Protocol Specification, Version 1.0", 251 Novell, Inc., February 1994. 253 [3] Callon, R., "OSI IS-IS for IP and Dual Environment," RFC 1195, 254 December 1990. 256 Acknowledgements 258 The author would like to thank Tony Li, Henk Smit, Naiming Shen, and 259 Dave Ward for their contributions to this document. 261 Author's Address 263 Dave Katz 264 Juniper Networks 265 385 Ravendale Drive 266 Mountain View, CA 94043 USA 268 Phone: +1 650 526 8073 269 Email: dkatz@juniper.net