idnits 2.17.1 draft-nguyen-ospf-restart-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 17. -- Found old boilerplate from RFC 3978, Section 5.5 on line 258. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 269. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 276. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 282. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RFC3623]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- 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 (October 26, 2006) is 6386 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'OSPF' is mentioned on line 81, but not defined Summary: 4 errors (**), 0 flaws (~~), 3 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group L. Nguyen 3 Internet-Draft A. Roy 4 Intended status: Informational Cisco Systems 5 Expires: April 29, 2007 A. Zinin 6 Alcatel 7 October 26, 2006 9 OSPF Restart Signaling 10 draft-nguyen-ospf-restart-06.txt 12 Status of this Memo 14 By submitting this Internet-Draft, each author represents that any 15 applicable patent or other IPR claims of which he or she is aware 16 have been or will be disclosed, and any of which he or she becomes 17 aware will be disclosed, in accordance with Section 6 of BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 This Internet-Draft will expire on April 29, 2007. 37 Copyright Notice 39 Copyright (C) The Internet Society (2006). 41 Abstract 43 Abstract OSPF is a link-state intra-domain routing protocol used in 44 IP networks. Routers find new and detect unreachable neighbors via 45 Hello subprotocol. Hello OSPF packets are also used to ensure two- 46 way connectivity within time. When a router restarts its OSPF 47 software, it may not know its neighbors. If such a router sends a 48 hello packet on an interface, its neighbors are going to reset the 49 adjacency, which may not be desirable in certain conditions. 51 This memo describes a vendor specific mechanism that allows OSPF 52 routers to inform their neighbors about the restart process. Note 53 that this mechanism requires support from neighboring routers. The 54 mechanism described in this document was proposed before Graceful 55 OSPF Restart [RFC3623] came into existence. It is implemented/ 56 supported by at least one major vendor and is currently deployed in 57 the field. The purpose of this document is to capture the details of 58 this mechanism for public use. This mechanism is not an IETF 59 standard. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 64 1.1. Requirements notation . . . . . . . . . . . . . . . . . . 4 65 2. Proposed Solution . . . . . . . . . . . . . . . . . . . . . . 5 66 2.1. Sending Hello Packets with the RS-bit set . . . . . . . . 5 67 2.2. Receiving Hello Packets with RS-bit set . . . . . . . . . 5 68 2.3. Insuring topology stability . . . . . . . . . . . . . . . 6 69 3. Backward Compatibility . . . . . . . . . . . . . . . . . . . . 7 70 4. Security Considerations . . . . . . . . . . . . . . . . . . . 8 71 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 72 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 73 6.1. Normative References . . . . . . . . . . . . . . . . . . . 10 74 6.2. Informative References . . . . . . . . . . . . . . . . . . 10 75 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 11 76 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 77 Intellectual Property and Copyright Statements . . . . . . . . . . 13 79 1. Introduction 81 While performing a graceful restart of OSPF software [OSPF], routers 82 need to prevent their neighbors from resetting their adjacencies. 83 However, after a reload, routers may not be aware of the neighbors 84 they had adjacencies with in their previous incarnations. If such a 85 router sends a Hello packet on an interface and this packet does not 86 list some neighbors, those neighbors will reset the adjacency with 87 restarting router. 89 This document describes a technique that allows restarting routers to 90 inform their neighbors that they may not know about some neighbors 91 yet and the absence of some router-IDs in the Hello packets should be 92 ignored. 94 1.1. Requirements notation 96 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 97 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 98 document are to be interpreted as described in RFC2119 [RFC2119]. 100 2. Proposed Solution 102 With this Restart Signaling Solution, A new bit, called RS (restart 103 signal), is introduced into Extended Options TLV in the LLS block 104 (see [LLS]). The value of this bit is 0x00000002; see Figure 1 105 below. 107 +---+---+---+---+---+---+---+- -+---+---+---+---+---+---+---+---+ 108 | * | * | * | * | * | * | * |...| * | * | * | * | * | * | RS| LR| 109 +---+---+---+---+---+---+---+- -+---+---+---+---+---+---+---+---+ 111 Figure 1. Bits in Extended Options TLV 113 For a definition of the LR bit, see [OOB]. 115 2.1. Sending Hello Packets with the RS-bit set 117 OSPF routers should set the RS-bit in the EO-TLV attached to a Hello 118 packet when it is not known that all neighbors are listed in this 119 packet, but the restarting router wants them to preserve their 120 adjacencies. The RS-bit must not be set in Hello packets longer than 121 RouterDeadInterval seconds. 123 2.2. Receiving Hello Packets with RS-bit set 125 When an OSPF router receives a Hello packet, containing the LLS block 126 with the EO-TLV which has the RS-bit set, the router should skip the 127 two-way connectivity check with the announcing neighbor (i.e., the 128 router should not generate a 1-WayReceived event for the neighbor if 129 it does not find its own router ID in the list of neighbors as 130 described in 10.5 of [RFC2328]), provided that the neighbor FSM for 131 this neighbor is in the Full state. 133 The router should also send a unicast Hello back to the sender in 134 reply to a Hello packet with RS bit set. This is to speed up 135 learning of previously known neighbors. When sending such a reply 136 packet, care must be taken to ensure that the RS bit is clear in it. 138 Two additional fields are introduced in the neighbor data structure: 139 RestartState flag and ResyncTimeout timer. RestartState flag 140 indicates that a Hello packet with RS-bit set has been received and 141 the local router expects its neighbor to go through the LSDB 142 resynchronization procedure using [OOB]. ResyncTimeout is a single- 143 shot timer limiting the delay between the first seen Hello packet 144 with RS-bit set and initialization of the LSDB resynchronization 145 procedure. The length of ResyncTimeout timer is RouterDeadInterval 146 seconds. 148 When a Hello packet with RS-bit set is received and RestartState flag 149 is not set for the neighbor, the router sets RestartState flag and 150 starts ResyncTimeout timer. If ResyncTimeout expires, RestartState 151 flag is cleared and a 1-WayReceived event is generated for the 152 neighbor. If, while ResyncTimeout timer is running, the neighbor 153 starts LSDB resynchronization procedure using [OOB], ResyncTimeout 154 timer is cancelled. The router also clears RestartState flag on 155 completion of the LSDB resynchronization process. 157 Two or more routers on the same segment cannot have Hello packets 158 with the RS-bit set at the same time, as can be the case when two or 159 more routers restart at about the same time. In such scenario, the 160 routers should clear the RestartState flag, cancel the ResyncTimeout 161 timer, and generate a 1-WayReceived event. 163 2.3. Insuring topology stability 165 Under certain circumstances it might be desirable to stop announcing 166 the restarting router as fully adjacent if this may lead to possible 167 routing loops. In order to provide this functionality, a 168 configurable option is provided on the neighboring routers that 169 instructs the OSPF process to follow the logics described below. 171 When an OSPF router schedules a routing table calculation due to a 172 change in the contents of its LSDB, it should also reset all 173 adjacencies with restarting routers (those with RestartState set to 174 TRUE) by clearing the RestartState neighbor flags, canceling 175 ResyncTimeout timers (if running), and generating the 1-WayReceived 176 events for the neighbor FSMs. 178 3. Backward Compatibility 180 The described technique requires cooperation from neighboring 181 routers. However, if neighbors do not support this technique, they 182 will just reset the adjacency. 184 4. Security Considerations 186 The described technique does not introduce any new security issues 187 into OSPF protocol. 189 5. IANA Considerations 191 Please refer to the "IANA Considerations" section of [LLS] for more 192 information on the Extended Options bit definitions. 194 6. References 196 6.1. Normative References 198 [RFC2119] Bradner, S., "Key words for use in RFC's to Indicate 199 Requirement Levels", RFC 2119, March 1997. 201 [RFC2328] Moy, J., "OSPF Version 2", RFC 2328, April 1998. 203 [RFC3623] Moy, J., Pillay-Esnault, P., and A. Lindem, "Graceful OSPF 204 Restart", RFC 3623, November 2003. 206 6.2. Informative References 208 [LLS] Friedman, B., Nguyen, L., Roy, A., Yeung, D., and A. Zinin, 209 "OSPF Link-local Signaling", Work in progress , October 2006. 211 [OOB] Nguyen, L., Roy, A., and A. Zinin, "OSPF Out-of-band LSDB 212 resynchronization", Work in progress , October 2006. 214 Appendix A. Acknowledgments 216 The authors would like to thank John Moy, Russ White, Don Slice, and 217 Alvaro Retana for their valuable comments. 219 Authors' Addresses 221 Liem Nguyen 222 Cisco Systems 223 225 West Tasman Drive 224 San Jose, CA 95134 225 USA 227 Email: lhnguyen@cisco.com 229 Abhay Roy 230 Cisco Systems 231 225 West Tasman Drive 232 San Jose, CA 95134 233 USA 235 Email: akr@cisco.com 237 Alex Zinin 238 Alcatel 239 Sunnyvale, CA 240 USA 242 Email: zinin@psg.com 244 Full Copyright Statement 246 Copyright (C) The Internet Society (2006). 248 This document is subject to the rights, licenses and restrictions 249 contained in BCP 78, and except as set forth therein, the authors 250 retain all their rights. 252 This document and the information contained herein are provided on an 253 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 254 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 255 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 256 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 257 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 258 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 260 Intellectual Property 262 The IETF takes no position regarding the validity or scope of any 263 Intellectual Property Rights or other rights that might be claimed to 264 pertain to the implementation or use of the technology described in 265 this document or the extent to which any license under such rights 266 might or might not be available; nor does it represent that it has 267 made any independent effort to identify any such rights. Information 268 on the procedures with respect to rights in RFC documents can be 269 found in BCP 78 and BCP 79. 271 Copies of IPR disclosures made to the IETF Secretariat and any 272 assurances of licenses to be made available, or the result of an 273 attempt made to obtain a general license or permission for the use of 274 such proprietary rights by implementers or users of this 275 specification can be obtained from the IETF on-line IPR repository at 276 http://www.ietf.org/ipr. 278 The IETF invites any interested party to bring to its attention any 279 copyrights, patents or patent applications, or other proprietary 280 rights that may cover technology that may be required to implement 281 this standard. Please address the information to the IETF at 282 ietf-ipr@ietf.org. 284 Acknowledgment 286 Funding for the RFC Editor function is provided by the IETF 287 Administrative Support Activity (IASA).