idnits 2.17.1 draft-ietf-ospf-oob-resync-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: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 6 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 7 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** 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 29 instances of too long lines in the document, the longest one being 3 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 (February 2001) is 8471 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) == Outdated reference: A later version (-08) exists of draft-ietf-ospf-lls-00 Summary: 6 errors (**), 0 flaws (~~), 4 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Alex Zinin 3 Internet Draft Abhay Roy 4 Expiration Date: September 2001 Liem Nguyen 5 File name: draft-ietf-ospf-oob-resync-01.txt Cisco Systems 6 February 2001 8 OSPF Out-of-band LSDB resynchronization 9 draft-ietf-ospf-oob-resync-01.txt 11 Status of this Memo 13 This document is an Internet-Draft and is in full conformance with 14 all provisions of Section 10 of RFC2026. 16 Internet Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its Areas, and its Working Groups. Note that other 18 groups may also distribute working documents as Internet Drafts. 20 Internet Drafts are draft documents valid for a maximum of six 21 months. Internet Drafts may be updated, replaced, or obsoleted by 22 other documents at any time. It is not appropriate to use Internet 23 Drafts as reference material or to cite them other than as a "working 24 draft" or "work in progress". 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 Abstract 33 OSPF is a link-state intra-domain routing protocol used in IP 34 networks. LSDB synchronization in OSPF is achieved via two methods-- 35 initial LSDB synchronization when an OSPF router has just been 36 connected to the network and asynchronous flooding that ensures 37 continuous LSDB synchronization in the presence of topology changes 38 after the initial procedure was completed. It may sometime be 39 necessary for OSPF routers to resynchronize their LSDBs. OSPF 40 standard, however, does not allow routers to do so without actually 41 changing the topology view of the network. This memo describes a 42 mechanism to perform such form of out-of-band LSDB synchronization. 44 1 Motivation 45 According to the OSPF standard [RFC2328], after two OSPF routers have 46 established an adjacency (the neighbor FSMs have reached Full state), 47 routers announce the adjacency states in their router-LSAs. 48 Asynchronous flooding algorithm ensures routers' LSDBs stay in sync 49 in the presence of topology changes. However, if routers need (for 50 some reason) to resynchronize their LSDBs, they cannot do that 51 without actually putting the neighbor FSMs into the ExStart state. 52 This effectively causes the adjacencies to be removed from the 53 router-LSAs, which may not be acceptable in some cases. In this 54 document, we provide the means for so-called out-of-band (OOB) LSDB 55 resynchronization. 57 The described mechanism can be used in a number of situations 58 including those where the routers are picking the adjacencies up 59 after a reload. The process of adjacency preemption is outside the 60 scope of this document. Only the details related to LSDB 61 resynchronization are mentioned herein. 63 2 Proposed solution 65 The format of the OSPF Database Description packet is changed to 66 include a new R-bit indicating OOB LSDB resynchronization. All DBD 67 packets sent during the OOB resynchronization procedure are sent with 68 the R-bit set. 70 Also, two new fields are added to the neighbor data structure. The 71 first field indicates neighbor's OOB resynchronization capability. 72 The second indicates that OOB LSDB resynchronization is in process. 73 The latter field allows OSPF implementations to utilize the existing 74 neighbor FSM code. 76 A bit is occupied in the Extended Options TLV (see [LLS]). Routers 77 set this bit to indicate their capability to support the described 78 technique. 80 2.1 The LR bit 82 A new bit, called LR (LR stands for LSDB Resynchronization) is 83 introduced to the LLS Extended Options TLV (see [LLS]). The value of 84 the bit is TBD (0x00000001 is the temporarily used value, see Figure 85 1). Routers set LR bit to announce OOB LSDB resynchronization 86 capability. 88 +---+---+---+---+---+---+---+- -+---+---+---+---+---+---+---+---+ 89 | * | * | * | * | * | * | * |...| * | * | * | * | * | * | * | LR| 90 +---+---+---+---+---+---+---+- -+---+---+---+---+---+---+---+---+ 92 Figure 1. The Options field 94 Routers supporting the OOB LSDB resynchronization technique set the 95 LR bit in the EO-TLV in the LLS block attached to both Hello and DBD 96 packets. Note that no bit is set in the standard OSPF Options field, 97 neither in OSPF packets, nor in LSAs. 99 2.2 OSPF Neighbor Data Structure 101 A field is introduced into OSPF neighbor data structure, as described 102 below. The name of the field is OOBResync and it is a flag indicating 103 that the router is currently performing OOB LSDB resynchronization 104 with the neighbor. 106 OOBResync flag is set when the router is initiating the OOB LSDB 107 resynchronization (see Section 2.7 for more details). 109 Routers clear OOBResync flag on the following conditions. 111 o The neighbor data structure is first created 113 o The neighbor FSM transitions to any state lower than 114 ExStart 116 o The neighbor FSM transitions to ExStart state because a DBD 117 packet with R-bit clear has been received. 119 o The neighbor FSM reaches state Full 121 Note that OOBResync flag may have TRUE value only if the neighbor FSM 122 is in states ExStart, Exchange, or Loading. As indicated above, if 123 the FSM transitions to any other state, the OOBResync flag should be 124 cleared. 126 It is important to mention that operation of OSPF neighbor FSM is not 127 changed by this document. However, depending on the state of the 128 OOBResync flag, the router sends either normal DBD packets or DBD 129 packets with the R-bit set. 131 2.3 Hello Packets 133 Routers capable of performing OOB LSDB resynchronization should 134 always set the LR bit in their Hello packets. 136 2.4 DBD Packets 138 Routers supporting the described technique should always set the LR 139 bit in the DBD packets. Since the Options field of the initial DBD 140 packet is stored in corresponding neighbor data structure, the LR bit 141 may be used later to check if a neighbor is capable of performing OOB 142 LSB resynchronization. 144 The format of type-2 (DBD) OSPF packets is changed to include a flag 145 indicating OOB LSDB resynchronization procedure. Figure 2 illustrates 146 the new packet format. 148 0 1 2 3 149 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 150 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 151 | Version # | 2 | Packet length | 152 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 153 | Router ID | 154 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 155 | Area ID | 156 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 157 | Checksum | AuType | 158 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 159 | Authentication | 160 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 161 | Authentication | 162 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 163 | Interface MTU | Options |0|0|0|0|R|I|M|MS 164 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 165 | DD sequence number | 166 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 167 | | 168 +- -+ 169 | | 170 +- An LSA Header -+ 171 | | 172 +- -+ 173 | | 174 +- -+ 175 | | 176 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 177 | ... | 179 The R-bit in OSPF type-2 packets is set when the OOBResync flag for 180 the specific neighbor is set to TRUE. If a DBD packets with R-bit 181 clear is received for a neighbor with active OOBResync flag, the OOB 182 LSDB resynchronization process is cancelled and normal LSDB synchron- 183 ization procedure is initiated. 185 When a DBD packet is received with R-bit set and the sender is known 186 to be OOB-incapable, the packet should be dropped and a SeqNumber- 187 Mismatch event should be generated for the neighbor. 189 Processing of DBD packets is modified as follows. 191 1) If the R-bit is set, do the following 193 o If bits I, M, and MS are set and the state of the neighbor 194 FSM is Full and OOBResync flag is not set, the packet is 195 accepted, the OOBResync flag is set and the FSM is put into 196 ExStart state. 198 o Otherwise, if OOBResync flag is set and the state of the 199 neighbor FSM is ExStart, Exchange, or Loading, the packet is 200 processed just as described in [RFC2328]. 202 o Otherwise, if neighbor state is Full and the receiving 203 router was the Slave in the LSDB exchange process, it must 204 be ready to identify duplicate DBDs with R-bit set from the 205 master and resend the acknowledging packet. 207 o Otherwise (the OOBResync flag is off, or the state is not 208 Full, or the packet is not a duplicate), a SeqNumberMismatch 209 is generated for the neighbor FSM that causes transition to 210 state ExStart. 212 2) Otherwise (the R-bit is not set) do the following 214 o If OOBResync flag for the neighbor is set, OOBResync flag is 215 cleared and a SeqNumberMismatch event is generated for the 216 neighbor FSM. 218 o Otherwise, process the DBD packet as described in [RFC2328]. 220 It is also necessary to limit the time an adjacency can spend in 221 ExStart, Exchange, and Loading states with OOBResync flag set to a 222 finite period of time (e.g., by limitting the number of times DBD and 223 link state request packets can be retransmitted). If the adjacency 224 does not proceed to Full state before the timeout, the neighboring 225 routers experience problems in LSDB resynchronization. The request- 226 ing router may decide to stop trying to resynchronize the LSDB over 227 this adjacency (if, for example, it can be resynchronized via another 228 neighbor on the same segment) or to resynchronize using the legacy 229 method by clearing the OOBResync flag and leaving the FSM in ExStart 230 state. The neighboring router may decide to cancel the OOB procedure 231 for the neighbor. 233 2.5 Neighbor State Treatment 235 OSPF implementation supporting the described technique should modify 236 the logic consulting the state of a neighbor FSM as described below. 238 o FSM state transitioning from and to the Full state with 239 OOBResync flag set should not cause origination of a new version 240 of router-LSA or network-LSA. 242 o Any explicit checks for the Full state of a neighbor FSM for the 243 purposes other than LSDB synchronization and flooding should 244 treat states ExStart, Exchange, and Loading as state Full, pro- 245 vided that OOBResync flag is set for the neighbor. (Flooding and 246 MaxAge-LSA-specific procedures should not check the state of 247 OOBResync flag, but should continue consulting only the FSM 248 state.) 250 2.6 Initiating OOB LSDB Resynchronization 252 To initiate out-of-band LSDB resynchronization, the router must first 253 make sure that the corresponding neighbor supports this technology 254 (by checking the LR bit in Options field of the neighbor data struc- 255 ture). If the neighboring router is capable, the OOBResync flag for 256 the neighbor should be set to TRUE and the FSM state should be forced 257 to ExStart. 259 3 Compatibility Issues 261 Because OOB-capable routers explicitly indicate their capability by 262 setting the corresponding bit in the Options field, no DBD packets 263 with R-bit set are sent to OOB-incapable routers. 265 The LR bit itself is transparent for OSPF routers and does not affect 266 communication between routers. 268 4 Security Considerations 270 The described technique does not introduce any new security issues 271 into OSPF protocol. 273 5 Acknowledgements 275 The authors would like to thank Acee Lindem, Russ White, Don Slice, 276 and Alvaro Retana for their valuable comments. 278 6 References 280 [RFC2328] 281 J. Moy. OSPF version 2. Technical Report RFC 2328, Internet 282 Engineering Task Force, 1998. ftp://ftp.isi.edu/in- 283 notes/rfc2328.txt. 285 [LLS] Zinin, Friedman, Roy, Nguyen, Yeung, "OSPF Link-local Signaling", 286 draft-ietf-ospf-lls-00.txt, Work in progress. 288 7 Authors' addresses 290 Alex Zinin Abhay Roy 291 Cisco Systems Cisco Systems 292 150 W. Tasman Dr. 170 W. Tasman Dr. 293 San Jose,CA 95134 San Jose,CA 95134 294 USA USA 295 E-mail: azinin@cisco.com E-mail: akr@cisco.com 297 Liem Nguyen 298 7025 Kit Creek Rd. 299 Research Triangle Park, NC 27709 300 USA 301 e-mail: lhnguyen@cisco.com