idnits 2.17.00 (12 Aug 2021) /tmp/idnits35644/draft-dimitri-ospf-phased-db-sync-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. 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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors 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 contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (May 23, 2010) is 4381 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) == Missing Reference: 'RFC1765' is mentioned on line 124, but not defined == Unused Reference: 'RFC2119' is defined on line 429, but no explicit reference was found in the text == Unused Reference: 'RFC2234' is defined on line 432, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2234 (Obsoleted by RFC 4234) ** Obsolete normative reference: RFC 2370 (Obsoleted by RFC 5250) == Outdated reference: A later version (-11) exists of draft-ietf-ospf-transport-instance-04 Summary: 2 errors (**), 0 flaws (~~), 7 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 OSPF Working Group Dimitri Papadimitriou 3 Internet Draft Alcatel-Lucent 4 Intended status: Standard Track May 23, 2010 5 Expires: November 22, 2010 7 Phased OSPF Link-State Database Synchronization 8 draft-dimitri-ospf-phased-db-sync-00.txt 10 Status of this Memo 12 This Internet-Draft is submitted in full conformance with the 13 provisions of BCP 78 and BCP 79. 15 This document may contain material from IETF Documents or IETF 16 Contributions published or made publicly available before 17 November 10, 2008. The person(s) controlling the copyright in 18 some of this material may not have granted the IETF Trust the 19 right to allow modifications of such material outside the IETF 20 Standards Process. Without obtaining an adequate license from 21 the person(s) controlling the copyright in such materials, this 22 document may not be modified outside the IETF Standards Process, 23 and derivative works of it may not be created outside the IETF 24 Standards Process, except to format it for publication as an RFC 25 or to translate it into languages other than English. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF), its areas, and its working groups. Note that 29 other groups may also distribute working documents as Internet- 30 Drafts. 32 Internet-Drafts are draft documents valid for a maximum of six 33 months and may be updated, replaced, or obsoleted by other 34 documents at any time. It is inappropriate to use Internet- 35 Drafts as reference material or to cite them other than as "work 36 in progress." 38 The list of current Internet-Drafts can be accessed at 39 http://www.ietf.org/ietf/1id-abstracts.txt 41 The list of Internet-Draft Shadow Directories can be accessed at 42 http://www.ietf.org/shadow.html 44 This Internet-Draft will expire on November 22, 2010. 46 Copyright Notice 48 Copyright (c) 2010 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (http://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with 56 respect to this document. Code Components extracted from this 57 document must include Simplified BSD License text as described 58 in Section 4.e of the Trust Legal Provisions and are provided 59 without warranty as described in the Simplified BSD License. 61 Abstract 63 Opaque Link-State Advertisements (LSA) extend the topological 64 link state of Open Shortest Path First (OSPF). The information 65 contained in Opaque LSA may be used directly by OSPF or 66 indirectly by some application wishing to distribute information 67 throughout the OSPF domain. However the Link-State Database 68 (LSDB) synchronization process is kept unified, i.e., there is 69 no messaging or processing allowing to order the exchanges in 70 the link state database synchronization process. We call this 71 ordering, phasing of logically segmented LSDB into Opaque and 72 non-Opaque. The motivation is to prevent delaying reaching Full 73 state whereas synchronizing over the entire LSDB would delay 74 full adjacency establishment. 76 Table of Contents 78 1. Introduction................................................3 79 2. Conventions used in this document...........................4 80 3. Link-State Database (LSDB) Synchronization..................4 81 3.1. LSDB Synchronization: General Description..............4 82 3.2. Application of LSDB Synchronization to Opaque LSA......5 83 4. Phased Link-State Database (LSDB) Synchronization...........6 84 4.1. Phased Link-State Database (LSDB) Synchronization 85 Process................................................6 86 4.2. Transition from LSDB to Opaque LSDB Synchronization....8 87 4.3. Capability Negotiation.................................8 88 4.3.1. Option field in Hello Packets.....................9 89 4.3.2. Link Local Signaling (LLS)........................9 90 5. Backward Compatibility......................................9 91 6. Security Considerations....................................10 92 7. IANA Considerations........................................10 93 8. References.................................................10 94 8.1. Normative References..................................10 95 8.2. Informative References................................10 96 9. Acknowledgments............................................10 98 1. Introduction 100 Open Shortest Path First (OSPF) link-state routing protocol 101 supports a class of Link-State Advertisements (LSA) called Opaque 102 LSAs that provide a generalized mechanism to allow extensibility 103 of OSPF [RFC2328]. The information field contained in Opaque LSAs 104 is often indirectly used by some application wishing to 105 distribute information throughout the OSPF domain. Standard OSPF 106 Link-State Database (LSDB) flooding mechanisms are used to 107 distribute Opaque LSAs to all or some limited portion of the OSPF 108 topology [RFC2370]. Nevertheless, OSPF mandates full 109 synchronization of the LSDB before a routing adjacency is 110 declared in state Full (when LSDB synchronization is completed, 111 the neighbor is in state Full and the two routers are fully 112 adjacent). 114 The reliable and effective LSDB synchronization but also link- 115 state flooding mechanism provided by OSPF has thus been re-used 116 by many distributed network applications that rely on OSPF to 117 exchange non IP routing information. By non-IP routing 118 information, we mean any information that is not directly or 119 indirectly related to the forwarding of IP datagrams. Another 120 case that often leads to a delayed synchronization process is 121 when the number of entries is not bound by the number of links. 122 This observation also leads us to think that AS-external LSAs in 123 particular are good candidate for the approach proposed here and 124 the mechanism can thus be seen as a complement to [RFC1765]. 126 The proposed mechanism phases the LSDB synchronization process by 127 first exchanging IP routing LSAs (Router, Network, Summary, AS- 128 external, and Not-so-stubby area LSAs) and then, the Opaque LSAs 129 as defined in [RFC2370]. The purpose is to prevent delaying the 130 establishment of fully adjacent routers - at this point the 131 adjacency is listed in LSAs - even if the "Opaque part" of the 132 LSDB is not synchronized. We note here that in most cases the 133 application itself makes use of the IP adjacencies for 134 application specific message exchanges and thus the applications 135 would not be slow down by this process. In this sense, the 136 present document reverts back to [RFC2328] the LSDB 137 synchronization process as extended by [RFC2370] (that covers 138 LSDB including both non-Opaque and Opaque LSAs). Phasing is 139 achieved by logically segmenting the LSDB synchronization 140 process: add "on top of" the LSDB synchronization process 141 described in [RFC2328], a synchronization process dedicated to 142 Opaque LSAs. This phasing prevents delaying establishment of full 143 adjacency between two routers (Full state) resulting from the 144 time needed to synchronize Opaque LSAs. This condition occurs in 145 particular when the number of Opaque LSAs >> non-Opaque LSAs. The 146 fundamental aspect of the proposed approach consists thus of 147 considering the state Full as the invariant state for reaching 148 full adjacency. 150 The purpose of the proposed Opaque LSDB Synchronization process 151 is to devise a less drastic alternative to the current approach 152 developed at OSPF WG that mandates complete separation of OSPF 153 instances when Opaque LSA are decoupled from IP Routing [OSPF- 154 TP]. The latter does not actually solve the so-called "Opaque 155 overload" problem because it separates IP-related from non-IP 156 related routing information instead of Opaque from non-Opaque 157 LSAs. The proposed approach here is to avoid duplicating OSPF 158 instances while keeping Opaque LSA messaging and processing as 159 part of a single OSPF instance. 161 2. Conventions used in this document 163 In examples, "C:" and "S:" indicate lines sent by the client and 164 server respectively. 166 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 167 NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and 168 "OPTIONAL" in this document are to be interpreted as described 169 in RFC-2119. 171 3. Link-State Database (LSDB) Synchronization 173 3.1. LSDB Synchronization: General Description 175 In link-state routing, it is very important for all routers' 176 Link-State Databases (LSDB) to stay synchronized. OSPF simplifies 177 this by requiring only adjacent routers to remain synchronized. 178 The synchronization process begins as soon as the routers attempt 179 to bring up the routing adjacency. 181 Each router describes its database by sending a sequence of 182 Database Description (DD) packets to its neighbor. Each Database 183 Description packet describes a set of LSAs belonging to the 184 router's database. When the neighbor sees an LSA that is more 185 recent than its own database copy, it makes a note that this 186 newer LSA should be requested. This sending and receiving of 187 Database Description packets is called the "Database Exchange 188 Process". During this process, the two routers form a 189 master/slave relationship. Each Database Description packet has a 190 sequence number. Database Description packets sent by the master 191 (polls) are acknowledged by the slave through echoing of the 192 sequence number. Both polls and their responses contain summaries 193 of link state data. The master is the only one allowed to 194 retransmit Database Description packets. It does so only at fixed 195 intervals, the length of which is the configured per-interface 196 constant RxmtInterval. 198 3.2. Application of LSDB Synchronization to Opaque LSA 200 Per [RFC2370]: an opaque-capable router learns of its neighbor's 201 opaque capability at the beginning of the "Database Exchange 202 Process" (see Section 10.6 of [RFC2328], receiving Database 203 Description packets from a neighbor in state ExStart). A neighbor 204 is opaque-capable if and only if it sets the O-bit in the Options 205 field of its Database Description packets; the O-bit is not set 206 in packets other than Database Description packets. Then, in the 207 next step of the Database Exchange process, Opaque LSAs are 208 included in the Database summary list that is sent to the 209 neighbor if and only if the neighbor is opaque capable. When 210 flooding Opaque LSAs to adjacent neighbors, an opaque-capable 211 router looks at the neighbor's opaque capability. Opaque LSAs are 212 only flooded to opaque-capable neighbors, i.e., Opaque LSAs are 213 only placed on the link-state retransmission lists of opaque- 214 capable neighbors. In case non-opaque-capable neighbor 215 inadvertently receives Opaque LSAs, the non-opaque- capable 216 router will then simply discard the LSA receiving LSAs having 217 unknown LS types). 219 Hence, [RFC2370] does not modify the state machine as defined in 220 Section 10.3 of [RFC2328] except for the action associated with 221 State: ExStart, Event: NegotiationDone which is where the 222 Database summary list is built in order to incorporate the Opaque 223 LSA in OSPF (see Figure 1). 225 4. Phased Link-State Database (LSDB) Synchronization 227 Compared to the [RFC2370] processing, the Phase Link-State 228 Database (LSDB) synchronization modifies the LSDB exchange 229 process as follows: Opaque LSAs are included in the LSDB summary 230 list that is sent to the neighbor, if and only if 232 i) The neighbor is Opaque capable (see Section 4 and Appendix A 233 of [RFC2370]) 234 +-------+ 235 |ExStart| 236 +-------+ 237 | 238 NegotiationDone| 239 | 240 v 241 +--------+ 242 |Exchange| 243 +--------+ 244 | 245 Exchange| 246 Done | 247 +----+ | +-------+ 248 |Full|<---------+----->|Loading| 249 +----+<- +-------+ 250 | LoadingDone | 251 ------------------ 253 Fig.1 Neighbor state changes (Database Exchange) 255 ii) The neighbor has fully exchanged the area LSDB that consists 256 of the router-LSAs (Type 1), network-LSAs (Type 2), and summary- 257 LSAs (Type 3, 4) contained in the area structure, along with the 258 AS-external-LSAs (Type 5) contained in the global structure, and 259 Not-So-Stubby Area (NSSA) LSAs (Type 7) [RFC3101], i.e., the 260 "Full" state has been reached. 262 iii) Both local and neighbor router supports the phased LSDB 263 synchronization (see Section 4.3). 265 4.1. Phased Link-State Database (LSDB) Synchronization Process 267 The process is depicted in Fig.2, the ExStart, Exchange, Loading 268 and Full states are defined per [RFC2328]. Note that in Full 269 State, the router can perform all subsequent operations per [RFC 270 2328] including, the computation of the shortest-path tree for an 271 area, and the computation of the AS external routes, as described 272 in Section 16 of [RFC2328]. Events NegotiationDone, ExchangeDone 273 and LoadingDone are used as defined per [RFC2328]. 275 +---------+ 276 | ExStart | 277 +---------+ 278 | 279 |NegotiationDone 280 | 281 v 282 +---------+ 283 |Exchange | 284 +---------+ 285 | 286 |Exchange 287 |Done 288 | 289 +---------+ | +---------+ 290 --------->| Full |<---------+--------->| Loading | 291 | +---------+<- +---------+ 292 | | | | 293 | | | LoadingDone | 294 | | ----------------------- 295 | | 296 | |Start_O 297 | | RFC 2328 298 ------|---------------|------------------------------------------ 299 | | 300 | | New 301 | v 302 | +-----------+ 303 | |NExchange_O| 304 | +-----------+ 305 | | 306 | |NExchange 307 | |Done_O 308 | | 309 +---------+ | +---------+ 310 | Full_O |<---------+--------->|Loading_O| 311 +---------+<- +---------+ 312 | | 313 | LoadingDone_O | 314 ----------------------- 316 Fig.2 Modified Neighbor state changes (Database Exchange) 318 4.2. Transition from LSDB to Opaque LSDB Synchronization 320 In case Full state is not reached due to e.g. corruption or 321 Fletcher checksum error, the exchange process restarts (go back 322 to ExStart). 324 In case Full state is reached, the process continues as follows 325 (note that the master remains the master as negotiated during 326 the ExStart step): 328 - Start_O (Event): LSDB contain Opaque_LSA's AND capability 329 as described in Section 4.3 successfully negotiated. This 330 ensures backward compatibility with [RFC2370]. 332 - NExchange_O (State): the router lists the contents of its 333 Opaque area LSDB in the neighbor Database summary list. The 334 Opaque area LSDB consists of Type 9 and Type 10 Opaque LSAs 335 along with Type 11 Opaque LSAs contained in the global 336 structure. The router sends the Database Description (DD) 337 packets for these Opaque LSAs to the neighbor. Each DD 338 Packet has a DD sequence number, and is explicitly 339 acknowledged. Only one DD Packet is allowed outstanding at 340 any one time. In this state, LS Request Packets may also be 341 sent asking for the neighbor's more recent Opaque LSAs. 343 - NExchangeDone_O (Event): both routers have successfully 344 transmitted a full sequence of DD packets. Each router now 345 knows what parts of its Opaque LSDB are out of date. 347 - Loading_O (State): LS Request packets are sent to the 348 neighbor asking for the more recent Opaque LSAs that have 349 been discovered (but not yet received) in the NExchange_O 350 state. 352 - LoadingDone_O (Event): LS Updates have been received for 353 all out-of-date portions of the Opaque LSDB. This is 354 indicated by the Link state request list becoming empty 355 after the Database Exchange process has completed. 357 - Full_O (State): neighboring nodes have completed Opaque 358 LSA exchange. 360 4.3. Capability Negotiation 362 Negotiating Phased LSDB synchronization can be performed by 363 inserting a Phased LSDB Flag in: 365 i) Option field of Hello Packets and DD Packets 367 ii) Data block of Link Local Signaling (LLS) and DD Packets 369 4.3.1. Option field in Hello Packets 371 The Options field (8-bits) enables OSPF routers to support (or 372 not support) optional capabilities, and to communicate their 373 capability level to other OSPF routers. Through this mechanism 374 routers of differing capabilities can be mixed within an OSPF 375 routing domain. When used in Hello packets, the Options field 376 allows a router to accept a neighbor at the condition of 377 adaptation to neighbors's capability (due to the initial 378 mismatch): if either of the neighbors does not support or does 379 not recognize the capability the synchronization is not phased. 380 In this case, routers encountering the unrecognized Option bits 381 in received Hello Packets ignore the capability and process the 382 packet normally. 384 Then, by exchanging this capability in Database Description (DD) 385 packets a router can sequence its exchange of LSAs (starting by 386 non-Opaque LSAs and then Opaque LSAs): if both neighbors are 387 capable of phased synchronization, they may still decide to use 388 or not. 390 This alternative is perfectly valid but requires usage of one bit 391 of the Option field that is a very sparse resource. 393 4.3.2. Link Local Signaling (LLS) 395 To Link-local signaling (LLS), OSPF routers add a special data 396 block to the end of OSPF packets (or right after the 397 authentication data block when cryptographic authentication is 398 used). The LLS block is attached to OSPF Hello packets. The 399 drawback of this alternative is that the delivery of LLS data in 400 Hello packets is not guaranteed. 402 To circumvent this problem, the solution consists in piggy 403 bagging the Phased DB Flag in the Database Description packets. 405 5. Backward Compatibility 407 The proposed synchronization process is backward compatible since 408 the mechanism extends the current process if and only if the 409 mechanism is locally (see Section 4.2) and remotely supported 410 (see Section 4.3). If either of these conditions is not met LSDB 411 synchronization falls back to the linear process currently 412 specific per [RFC2370]. Note also that the proposed mechanism 413 does not modify the LSDB process as specified in [RFC2328]. 414 However, it does not prevent that routers may be required to 415 support both methods. This could be the case typically for ABR's. 417 6. Security Considerations 419 TBD 421 7. IANA Considerations 423 TBD 425 8. References 427 8.1. Normative References 429 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 430 Requirement Levels", BCP 14, RFC 2119, March 1997. 432 [RFC2234] Crocker, D. and Overell, P.(Editors), "Augmented BNF 433 for Syntax Specifications: ABNF", RFC 2234, Internet 434 Mail Consortium and Demon Internet Ltd., November 1997. 436 [RFC2328] J. Moy, "OSPF version 2", RFC 2328, Internet 437 Engineering Task Force, April 1998. 439 [RFC2370] R. Coltun, "The OSPF Opaque LSA Option", RFC 2370, July 440 1998. 442 8.2. Informative References 444 [OSPF-TP] A.Lindem, et al. "OSPF Transport Instance Extensions", 445 IETF Draft, Work in Progress, draft-ietf-ospf- 446 transport-instance-04.txt, April 2010. 448 [RFC3101] P. Murphy, "The OSPF Not-So-Stubby Area (NSSA) Option", 449 RFC 3101, Internet Engineering Task Force, January 450 2003. 452 9. Acknowledgments 454 Authors would like to thank Marc Lasserre, Devendra Raut, Andrew 455 Lange, and Manav Bhatia for their comments. 457 This document was prepared using 2-Word-v2.0.template.dot. 459 Authors' Addresses 461 Dimitri Papadimitriou 462 Alcatel-Lucent Bell 463 Copernicuslaan 50 464 2018 Antwerpen 465 Belgium 466 Phone: +32 3 2408491 467 Email: dimitri.papadimitriou@alcatel-lucent.com