idnits 2.17.1 draft-nguyen-ospf-oob-resync-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 384. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 395. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 402. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 408. ** 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 6392 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 4 errors (**), 0 flaws (~~), 2 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 Out-of-band LSDB resynchronization 10 draft-nguyen-ospf-oob-resync-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 OSPF is a link-state intra-domain routing protocol used in IP 44 networks. LSDB synchronization in OSPF is achieved via two methods-- 45 initial LSDB synchronization when an OSPF router has just been 46 connected to the network and asynchronous flooding that ensures 47 continuous LSDB synchronization in the presence of topology changes 48 after the initial procedure was completed. It may sometime be 49 necessary for OSPF routers to resynchronize their LSDBs. OSPF 50 standard, however, does not allow routers to do so without actually 51 changing the topology view of the network. 53 This memo describes a vendor specific mechanism to perform such form 54 of out-of-band LSDB synchronization. The mechanism described in this 55 document was proposed before Graceful OSPF Restart [RFC3623] came 56 into existence. It is implemented/supported by at least one major 57 vendor and is currently deployed in the field. The purpose of this 58 document is to capture the details of this mechanism for public use. 59 This mechanism is not an IETF standard. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 64 1.1. Requirements notation . . . . . . . . . . . . . . . . . . 4 65 2. Proposed Solution . . . . . . . . . . . . . . . . . . . . . . 5 66 2.1. The LR bit . . . . . . . . . . . . . . . . . . . . . . . . 5 67 2.2. OSPF Neighbor Data Structure . . . . . . . . . . . . . . . 5 68 2.3. Hello Packets . . . . . . . . . . . . . . . . . . . . . . 6 69 2.4. DBD Packets . . . . . . . . . . . . . . . . . . . . . . . 6 70 2.5. Neighbor State Treatment . . . . . . . . . . . . . . . . . 8 71 2.6. Initiating OOB LSDB Resynchronization . . . . . . . . . . 9 72 3. Backward Compatibility . . . . . . . . . . . . . . . . . . . . 10 73 4. Security Considerations . . . . . . . . . . . . . . . . . . . 11 74 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 75 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 76 6.1. Normative References . . . . . . . . . . . . . . . . . . . 13 77 6.2. Informative References . . . . . . . . . . . . . . . . . . 13 78 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 14 79 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 80 Intellectual Property and Copyright Statements . . . . . . . . . . 16 82 1. Introduction 84 According to the OSPF standard [RFC2328], after two OSPF routers have 85 established an adjacency (the neighbor FSMs have reached Full state), 86 routers announce the adjacency states in their router-LSAs. 87 Asynchronous flooding algorithm ensures routers' LSDBs stay in sync 88 in the presence of topology changes. However, if routers need (for 89 some reason) to resynchronize their LSDBs, they cannot do that 90 without actually putting the neighbor FSMs into the ExStart state. 91 This effectively causes the adjacencies to be removed from the 92 router-LSAs, which may not be acceptable if the desire is to prevent 93 routing table flaps during database resynchronization. In this 94 document, we provide the means for so-called out-of-band (OOB) LSDB 95 resynchronization. 97 The described mechanism can be used in a number of situations 98 including those where the routers are picking the adjacencies up 99 after a reload. The process of adjacency preemption is outside the 100 scope of this document. Only the details related to LSDB 101 resynchronization are mentioned herein. 103 1.1. Requirements notation 105 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 106 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 107 document are to be interpreted as described in RFC2119 [RFC2119]. 109 2. Proposed Solution 111 With this Out-Of-Band Resynchronization Solution, the format of the 112 OSPF Database Description packet is changed to include a new R-bit 113 indicating OOB LSDB resynchronization. All DBD packets sent during 114 the OOB resynchronization procedure are sent with the R-bit set. 116 Also, two new fields are added to the neighbor data structure. The 117 first field indicates neighbor's OOB resynchronization capability. 118 The second indicates that OOB LSDB resynchronization is in process. 119 The latter field allows OSPF implementations to utilize the existing 120 neighbor FSM code. 122 A bit is occupied in the Extended Options TLV (see [LLS]). Routers 123 set this bit to indicate their capability to support the described 124 technique. 126 2.1. The LR bit 128 A new bit, called LR (LR stands for LSDB Resynchronization) is 129 introduced to the LLS Extended Options TLV (see [LLS]). The value of 130 the bit is 0x00000001; see Figure 1. See the "IANA Considerations" 131 section of [LLS] for more information on the Extended Options bit 132 definitions. Routers set LR bit to announce OOB LSDB 133 resynchronization capability. 135 +---+---+---+---+---+---+---+- -+---+---+---+---+---+---+---+---+ 136 | * | * | * | * | * | * | * |...| * | * | * | * | * | * | * | LR| 137 +---+---+---+---+---+---+---+- -+---+---+---+---+---+---+---+---+ 139 Figure 1. The Options field 141 Routers supporting the OOB LSDB resynchronization technique set the 142 LR bit in the EO-TLV in the LLS block attached to both Hello and DBD 143 packets. Note that no bit is set in the standard OSPF Options field, 144 neither in OSPF packets, nor in LSAs. 146 2.2. OSPF Neighbor Data Structure 148 A field is introduced into OSPF neighbor data structure, as described 149 below. The name of the field is OOBResync and it is a flag 150 indicating that the router is currently performing OOB LSDB 151 resynchronization with the neighbor. 153 OOBResync flag is set when the router is initiating the OOB LSDB 154 resynchronization (see Section 2.6 for more details). 156 Routers clear OOBResync flag on the following conditions: 158 o The neighbor data structure is first created 160 o The neighbor FSM transitions to any state lower than ExStart 162 o The neighbor FSM transitions to ExStart state because a DBD packet 163 with R-bit clear has been received 165 o The neighbor FSM reaches state Full. 167 Note that OOBResync flag may have TRUE value only if the neighbor FSM 168 is in states ExStart, Exchange, or Loading. As indicated above, if 169 the FSM transitions to any other state, the OOBResync flag should be 170 cleared. 172 It is important to mention that operation of OSPF neighbor FSM is not 173 changed by this document. However, depending on the state of the 174 OOBResync flag, the router sends either normal DBD packets or DBD 175 packets with the R-bit set. 177 2.3. Hello Packets 179 Routers capable of performing OOB LSDB resynchronization should 180 always set the LR bit in their Hello packets. 182 2.4. DBD Packets 184 Routers supporting the described technique should always set the LR 185 bit in the DBD packets. Since the Options field of the initial DBD 186 packet is stored in corresponding neighbor data structure, the LR bit 187 may be used later to check if a neighbor is capable of performing OOB 188 LSDB resynchronization. 190 The format of type-2 (DBD) OSPF packets is changed to include a flag 191 indicating OOB LSDB resynchronization procedure. Figure 2 192 illustrates the new packet format. 194 0 1 2 3 195 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 196 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 197 | Version # | 2 | Packet length | 198 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 199 | Router ID | 200 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 201 | Area ID | 202 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 203 | Checksum | AuType | 204 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 205 | Authentication | 206 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 207 | Authentication | 208 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 209 | Interface MTU | Options |0|0|0|0|R|I|M|MS 210 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 211 | DD sequence number | 212 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 213 | | 214 +- -+ 215 | | 216 +- An LSA Header -+ 217 | | 218 +- -+ 219 | | 220 +- -+ 221 | | 222 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 223 | ... | 225 Figure 2. Modified DBD packet 227 The R-bit in OSPF type-2 packets is set when the OOBResync flag for 228 the specific neighbor is set to TRUE. If a DBD packets with R-bit 229 clear is received for a neighbor with active OOBResync flag, the OOB 230 LSDB resynchronization process is cancelled and normal LSDB 231 synchronization procedure is initiated. 233 When a DBD packet is received with R-bit set and the sender is known 234 to be OOB-incapable, the packet should be dropped and a SeqNumber- 235 Mismatch event should be generated for the neighbor. 237 Processing of DBD packets is modified as follows. 239 1. If the OOBResync flag for the neighbor is set (the LSDB 240 resynchronization process has been started) and received DBD 241 packet does not have the R bit set, ignore the packet and gen- 242 erate a SeqNumberMismatch event for the neighbor FSM. 244 2. Otherwise, if OOBResync flag for the neighbor is clear and 245 received DBD packet has the R bit set, perform the following 246 steps: 248 * If the neighbor FSM is in state Full and bits I, M, and MS are 249 set in the DBD packet, set the OOBResync flag for the 250 neighbor, put the FSM in ExStart state and continue process- 251 ing the DBD packet as described in [RFC2328]. 253 * Otherwise, ignore received DBD packet (no OOB DBD packets are 254 allowed with OOBResync flag clear and FSM in state other than 255 Full.) Also, if the state of the FSM is Exchange or higher, 256 generate a SeqNumberMismatch event for the neighbor FSM. 258 3. Otherwise, process the DBD packet as described in [RFC2328]. 260 During normal processing of the initial OOB DBD packet (with bits R, 261 I, M, and MS set), if the receiving router is selected to be the Mas- 262 ter, it may speed up the resynchronization process by immediately 263 replying to the received packet. 265 It is also necessary to limit the time an adjacency can spend in 266 ExStart, Exchange, and Loading states with OOBResync flag set to a 267 finite period of time (e.g., by limiting the number of times DBD and 268 link state request packets can be retransmitted). If the adjacency 269 does not proceed to Full state before the timeout, it is indicative 270 that the neighboring router cannot resynchronize its LSDB with the 271 local router. The requesting router may decide to stop trying to 272 resynchronize the LSDB over this adjacency (if, for example, it can 273 be resynchronized via another neighbor on the same segment) or to 274 resynchronize using the legacy method by clearing the OOBResync flag 275 and leaving the FSM in ExStart state. The neighboring router may 276 decide to cancel the OOB procedure for the neighbor. 278 2.5. Neighbor State Treatment 280 OSPF implementation supporting the described technique should modify 281 the logic consulting the state of a neighbor FSM as described below. 283 o FSM state transitioning from and to the Full state with OOBResync 284 flag set should not cause origination of a new version of router- 285 LSA or network-LSA. 287 o Any explicit checks for the Full state of a neighbor FSM for the 288 purposes other than LSDB synchronization and flooding should treat 289 states ExStart, Exchange, and Loading as state Full, pro- vided 290 that OOBResync flag is set for the neighbor. (Flooding and 291 MaxAge-LSA-specific procedures should not check the state of 292 OOBResync flag, but should continue consulting only the FSM 293 state.) 295 2.6. Initiating OOB LSDB Resynchronization 297 To initiate out-of-band LSDB resynchronization, the router must first 298 make sure that the corresponding neighbor supports this technology 299 (by checking the LR bit in Options field of the neighbor data struc- 300 ture). If the neighboring router is capable, the OOBResync flag for 301 the neighbor should be set to TRUE and the FSM state should be forced 302 to ExStart. 304 3. Backward Compatibility 306 Because OOB-capable routers explicitly indicate their capability by 307 setting the corresponding bit in the Options field, no DBD packets 308 with R-bit set are sent to OOB-incapable routers. 310 The LR bit itself is transparent for OSPF implementations and does 311 not affect communication between routers. 313 4. Security Considerations 315 The described technique does not introduce any new security issues 316 into OSPF protocol. 318 5. IANA Considerations 320 Please refer to the "IANA Considerations" section of [LLS] for more 321 information on the Extended Options bit definitions. 323 6. References 325 6.1. Normative References 327 [RFC2119] Bradner, S., "Key words for use in RFC's to Indicate 328 Requirement Levels", RFC 2119, March 1997. 330 [RFC2328] Moy, J., "OSPF Version 2", RFC 2328, April 1998. 332 [RFC3623] Moy, J., Pillay-Esnault, P., and A. Lindem, "Graceful OSPF 333 Restart", RFC 3623, November 2003. 335 6.2. Informative References 337 [LLS] Friedman, B., Nguyen, L., Roy, A., Yeung, D., and A. Zinin, 338 "OSPF Link-local Signaling", Work in progress , October 2006. 340 Appendix A. Acknowledgments 342 The authors would like to thank Acee Lindem, Russ White, Don Slice, 343 and Alvaro Retana for their valuable comments. 345 Authors' Addresses 347 Liem Nguyen 348 Cisco Systems 349 225 West Tasman Drive 350 San Jose, CA 95134 351 USA 353 Email: lhnguyen@cisco.com 355 Abhay Roy 356 Cisco Systems 357 225 West Tasman Drive 358 San Jose, CA 95134 359 USA 361 Email: akr@cisco.com 363 Alex Zinin 364 Alcatel 365 Sunnyvale, CA 366 USA 368 Email: zinin@psg.com 370 Full Copyright Statement 372 Copyright (C) The Internet Society (2006). 374 This document is subject to the rights, licenses and restrictions 375 contained in BCP 78, and except as set forth therein, the authors 376 retain all their rights. 378 This document and the information contained herein are provided on an 379 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 380 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 381 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 382 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 383 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 384 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 386 Intellectual Property 388 The IETF takes no position regarding the validity or scope of any 389 Intellectual Property Rights or other rights that might be claimed to 390 pertain to the implementation or use of the technology described in 391 this document or the extent to which any license under such rights 392 might or might not be available; nor does it represent that it has 393 made any independent effort to identify any such rights. Information 394 on the procedures with respect to rights in RFC documents can be 395 found in BCP 78 and BCP 79. 397 Copies of IPR disclosures made to the IETF Secretariat and any 398 assurances of licenses to be made available, or the result of an 399 attempt made to obtain a general license or permission for the use of 400 such proprietary rights by implementers or users of this 401 specification can be obtained from the IETF on-line IPR repository at 402 http://www.ietf.org/ipr. 404 The IETF invites any interested party to bring to its attention any 405 copyrights, patents or patent applications, or other proprietary 406 rights that may cover technology that may be required to implement 407 this standard. Please address the information to the IETF at 408 ietf-ipr@ietf.org. 410 Acknowledgment 412 Funding for the RFC Editor function is provided by the IETF 413 Administrative Support Activity (IASA).