idnits 2.17.00 (12 Aug 2021) /tmp/idnits49357/draft-yan-ospf-sync-group-01.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 : ---------------------------------------------------------------------------- ** There is 1 instance of too long lines in the document, the longest one being 17 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (November 9, 2014) is 2749 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) == Unused Reference: 'RFC5613' is defined on line 444, but no explicit reference was found in the text == Outdated reference: draft-ietf-ospf-prefix-link-attr has been published as RFC 7684 -- Obsolete informational reference (is this intentional?): RFC 4970 (Obsoleted by RFC 7770) Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group G. Yan 3 Internet-Draft Y. Liu 4 Intended status: Standards Track X. Zhang 5 Expires: May 15, 2015 Huawei 6 November 9, 2014 8 OSPF Synchronization Group 9 draft-yan-ospf-sync-group-01 11 Abstract 13 OSPF is a fundamental component for a routing system. It depends on 14 the flooding mechanism to advertise and synchronize link-state 15 database among distributed nodes in a network. As modern networks 16 become larger and more complex, more and more nodes and adjacencies 17 are involved. As a result, massive link-state information are 18 generated and synchronized which are becoming an overhead of networks 19 nowadays. 21 This document proposes a new design of OSPF database synchronization 22 that is slightly different from the one stated in OSPF. This new 23 design can help to alleviate the overhead by dividing OSPF routers 24 into independent synchronization groups and limiting synchronization 25 across the group border. Since less burden from synchronization, it 26 is possible to accommodate more OSPF routers and adjacencies in a 27 network. 29 Requirements Language 31 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 32 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 33 document are to be interpreted as described in RFC 2119 [RFC2119]. 35 Status of This Memo 37 This Internet-Draft is submitted in full conformance with the 38 provisions of BCP 78 and BCP 79. 40 Internet-Drafts are working documents of the Internet Engineering 41 Task Force (IETF). Note that other groups may also distribute 42 working documents as Internet-Drafts. The list of current Internet- 43 Drafts is at http://datatracker.ietf.org/drafts/current/. 45 Internet-Drafts are draft documents valid for a maximum of six months 46 and may be updated, replaced, or obsoleted by other documents at any 47 time. It is inappropriate to use Internet-Drafts as reference 48 material or to cite them other than as "work in progress." 49 This Internet-Draft will expire on May 14, 2015. 51 Copyright Notice 53 Copyright (c) 2014 IETF Trust and the persons identified as the 54 document authors. All rights reserved. 56 This document is subject to BCP 78 and the IETF Trust's Legal 57 Provisions Relating to IETF Documents 58 (http://trustee.ietf.org/license-info) in effect on the date of 59 publication of this document. Please review these documents 60 carefully, as they describe your rights and restrictions with respect 61 to this document. Code Components extracted from this document must 62 include Simplified BSD License text as described in Section 4.e of 63 the Trust Legal Provisions and are provided without warranty as 64 described in the Simplified BSD License. 66 Table of Contents 68 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 69 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 70 3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 3 71 4. Proposed Solution . . . . . . . . . . . . . . . . . . . . . . 4 72 4.1. Overview of a Synchronization Group . . . . . . . . . . . 4 73 4.2. LSA Synchronization in a Group . . . . . . . . . . . . . 5 74 5. Changes to the protocol . . . . . . . . . . . . . . . . . . . 5 75 5.1. Changes to the Flooding mechanism . . . . . . . . . . . . 5 76 5.2. Route Calculation . . . . . . . . . . . . . . . . . . . . 6 77 5.3. Protocol Extension . . . . . . . . . . . . . . . . . . . 6 78 5.4. Protocol Process . . . . . . . . . . . . . . . . . . . . 8 79 6. Multi-homed SG consideration . . . . . . . . . . . . . . . . 8 80 6.1. Problem Statement . . . . . . . . . . . . . . . . . . . . 8 81 6.2. Proposed Solution . . . . . . . . . . . . . . . . . . . . 9 82 7. Backward Compatibility . . . . . . . . . . . . . . . . . . . 10 83 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 84 9. Security Considerations . . . . . . . . . . . . . . . . . . . 10 85 10. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 10 86 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 87 11.1. Normative References . . . . . . . . . . . . . . . . . . 10 88 11.2. Informative References . . . . . . . . . . . . . . . . . 11 89 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 91 1. Introduction 93 OSPF is a fundamental component for a routing system. It depends on 94 the flooding mechanism to advertise and synchronize link-state 95 database among distributed nodes in a network. As modern networks 96 become larger and more complex, more and more nodes and adjacencies 97 are involved. As a result, massive link-state information are 98 generated and synchronized which are becoming an overhead of networks 99 nowadays. 101 This document proposes a new design of OSPF database synchronization 102 that is slightly different from the one stated in [RFC2328]. This 103 new design can help to alleviate the overhead by dividing OSPF 104 routers into independent synchronization groups and limiting 105 synchronization across the group border. Since less burden from 106 synchronization, it is possible to accommodate more OSPF routers and 107 adjacencies in a network. 109 In some scenarios, the routers in those networks suffer from limited 110 CPU or storage resource which make them unqualified for large 111 networks. With the help from this new design the situation can be 112 improved. 114 2. Terminology 116 Synchronization Group (SG) : A sub-domain of one OSPF area in which 117 the link-state database synchronization only happened among those 118 routers in the same group. 120 Synchronization Group ID (SGID) : The identity of a Synchronization 121 Group which MUST be unique in one OSPF network. 123 Synchronization Group Member (SGM) : One role of OSPF router which 124 belongs to an unique Synchronization Group by carrying the SGID in 125 its Hello packet. Adjacencies MUST NOT be established among SGMs 126 from different SGs. 128 Synchronization Group Member Interface (SGMI) : The interface of a 129 Synchronization Group Member. 131 Synchronization Group Director (SGD) : One role of OSPF router whose 132 adjacencies MUST follow the standard procedure instead of affected by 133 SGIDs. 135 Synchronization Group Director Interface (SGDI) : The interface of a 136 Synchronization Group Director. 138 3. Problem Statement 140 As stated in [RFC2328], the flooding procedure supplied a reliable 141 advertisement mechanism through which the link-state database is 142 synchronized in an OSPF network. Forwarding loops or routing black- 143 hole can be introduced if synchronization status is not achieved. 144 There are some devices for which it is difficult to host the whole 145 link-state database since they may possess limited CPU or storage 146 resource. Even for those devices which have enough resource, it is 147 still an unneglectable overhead in a periodical manner. 149 +----+ +----+ 150 | S1 | *** *** *** | Si | 151 +----+--- ---+----+ 152 * ---- ---- * 153 * ---- ---- * 154 * --+----+-- * 155 |Hub | 156 * --+----+-- * 157 * ---- ---- * 158 * ---- ---- * 159 +----+--- ---+----+ 160 | Sj | *** *** *** | Sn | 161 +----+ +----+ 163 Figure 1 Hub and Spoke scenario 165 As showed in Figure 1, the hub sub-network established OSPF 166 adjacencies with many spoke sub-networks indexed from S1 to Sn 167 separately. Every LSAs generated by a single spoke have to be 168 flooded to the rest of spokes through hub and vice versa. Let's 169 assume there are m LSAs originated by each spoke then the total 170 number of LSAs advertised among hub and spokes can be roughly counted 171 as m * n, excluding the number of retransmission. What is worse, 172 these LSA copies have to be refreshed every LSRefreshTime. This 173 advertisement is indeed an unnecessary burden for devices with 174 limited resources and even those devices with enough resources since 175 all routes in one spoke share the same next hop which is the hub. 177 4. Proposed Solution 179 This document introduces a new mechanism which can solve the issue 180 stated above through limiting synchronization scope inside a 181 Synchronization Group instead of an area. The solution metioned here 182 should be effective primarily in the hub-and-spoke scenario. 184 4.1. Overview of a Synchronization Group 186 A Synchronization Group (SG) is a sub-domain of one OSPF area in 187 which the link-state database synchronization only happened among 188 those routers in the same group. Each SG is identified uniquely by 189 an identification number which is called SGID. 191 There are two roles involved into one Synchronization Group: 192 Synchronization Group Member (SGM) and Synchronization Group Director 193 (SGD). The same SGD may be involved into several SGs simultaneously. 194 Different SGDs are REQUIRED to interconnect with each other without 195 passing through SGMs. The interfaces SGM and SGD used to form 196 adjacencies are inherently called SGMI and SGDI. A SGMI or SGDI MUST 197 belong to a single SG. 199 4.2. LSA Synchronization in a Group 201 Link-state database synchronization among SGDs follows the same 202 procedure stated in [RFC2328]. They maintain the complete database 203 of the area they belong to. This database is used to advertise among 204 SGDs and consumed in the SPF calculation. 206 On the other side, SGMs only possess those LSAs that are learned from 207 other SDMs and several LSAs leaked by their corresponding SGDs. SGMs 208 advertise and use their LSDB in the manner as the standard document 209 specified. 211 When OSPF adjacencies built between a SGD and a SGM, the 212 synchronization between them SHOULD follow the specification defined 213 in this document. In order to decrease the size of SGM's LSDB, a SGD 214 only advertise necessary LSAs to its adjacent SGMs. Those LSAs in 215 necessity include the Router-LSAs of SGDs in the same SG, the 216 Network-LSAs if some of SGDs are DR for their corresponding networks 217 and some Extended Prefix Opaque LSAs[I-D.ietf-ospf-prefix-link-attr] 218 originated by SGDs to serve for limited reachability for SGMs. 220 5. Changes to the protocol 222 This document introduced some changes to OSPF[RFC2328] which is 223 necessary to support SG. 225 5.1. Changes to the Flooding mechanism 227 SGDI and SGMI SHOULD be used to send and receive the LSAs updating in 228 one SG. The LSA's SG belonging is identified by its originator's 229 SGID. If MaxAge LSA is received, it SHOULD be processed as described 230 in section 13 of OSPF[RFC2328]. If a LSA is received from a neighbor 231 that does not support SG, it SHOULD be processed as standardized 232 since SG feature is ineffective between them. 234 When LSDB synchronization happened between SGDs and SGMs, only 235 limited LSDB SHOULD be flooded from SGDs to SGMs. As stated above, 236 instead of flooding all LSAs to SGMs, only Router-LSAs and Network- 237 LSAs in the same Group SHOULD be flooded to SGMs. On the contrary, 238 SGMs SHOULD synchronize their whole LSDB to SGDs as standandized. 240 5.2. Route Calculation 242 No change introduced for route calculation in this document. 244 5.3. Protocol Extension 246 One new bit is introduced into Router Informational Capabilities TLV 247 to indicate its originator supporting SG capability or not. 249 0 1 2 3 250 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 251 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 252 | Type | Length | 253 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 254 | Informational Capabilities | 255 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 257 Bit TBD: OSPF Synchronization Group capable 259 Figure 2 SG-bit in Informational Capabilities TLV 261 A new TLV called Synchronization Group TLV is defined to be included 262 in Router Information Opaque LSA[RFC4970]. Every router that support 263 SG feature MUST contain this TLV in its RI Opaque-LSA. SGID and role 264 of SGM or SGD can be learnt by parsing this TLV and act accordingly. 266 0 1 2 3 267 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 268 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 269 | Type | Length | 270 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 271 | Flags | Reserved | Synchronization Group ID | 272 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 273 | ... ... ... | 274 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 275 | Flags | Reserved | Synchronization Group ID | 276 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 277 Type: TBD 278 Length: 2 octets 279 Synchronization Group ID: ID of this SG. 281 Flags: 282 0 1 2 3 4 5 6 7 283 +-+-+-+-+-+-+-+-+ 284 | Reserved |E|D| 285 +-+-+-+-+-+-+-+-+ 286 Bit-D: Set if Synchronization Group Director. 287 Bit-E: Set if Synchronization Group Director is elected as Designated SGD for this SG. 289 Figure 3 Synchronization Group TLV 291 Extended Prefix TLV SHOULD be used by SGDs to advertise default route 292 or necessary aggregated prefixes to SGMs. New sub-TLV is introduced 293 to identify metrics for corresponding prefixes. The metric used in 294 the sub-TLV SHOULD be the actual number from SGDs to the destination 295 of the prefix. 297 0 1 2 3 298 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 299 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 300 | Type | Length | 301 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 302 | Route Type | Prefix Length | AF | Reserved | 303 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 304 | Address Prefix (variable) | 305 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 306 | Sub-TLVs (variable) | 307 +- -+ 308 | | 309 OSPFv2 Extended Prefix TLV 311 0 1 2 3 312 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 313 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 314 | Type | Length | 315 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 316 | Metric of the prefix | 317 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 318 Type: TBD 319 Length: 2 octets 320 Metric of the prefix: The actual metric for corresponding prefix. 322 Figure 4 Sub-TLV used to express prefix metric 324 5.4. Protocol Process 326 Synchronization Group TLV MUST be carried in the RI Opaque-LSA with 327 SG-bit set if the originator support SG feature. It SHOULD be 328 regarded as not supporting SG feature If this TLV is not carried or 329 SG-bit is clear. SGDs and SGMs MUST send this TLV with corresponding 330 SGIDs set and with correct Bit-D status. If there are more than one 331 Synchronization Group TLVs carried in RI Opaque-LSAs then the 332 originator SHOULD be regarded as supporing all those carried SGs. 334 6. Multi-homed SG consideration 336 6.1. Problem Statement 338 In certain scenario, one SG may multi-homed to two or more SGDs. 339 Forwarding loops may be observed when topology changed since the 340 link-state database of SGD and SGM can be different. In order to 341 solve this issue, one tunnel is REQUIRED to be established among SGDs 342 with the metric lower than the path through SG. 344 As shown below, when link between SGD2 and SG1A failed, the best path 345 to reach SG1A is SGD2->SGD4->SG2A->SGD3->SGD1->SG1A. Since SG2A only 346 have default route originated by its SGDs, saying SGD3 and SGD4, 347 forwarding loops can be observed. Even special handling was taken on 348 SGD4, such as avoiding traveling through SDMs, traffic black hole 349 could happen on SGD4 since SGD2 will insist on its choice. What is 350 worse, assuming SGD2 generated the same prefix as SG1A did but with 351 shorter prefix length, since SGD4 should ignore the link between SGD4 352 and SG2A that will cause transversal traffic, this shorter prefix 353 will be the best match for the original destination, so forwarding 354 loop can be observed between SGD2 and SGD4. 356 +----+ +----+ 357 |SGD1| |SGD2| 358 +----+\\ ---+----+\ 359 100 -- \\---- \\ 10 360 -- 100 ----\\ 10 \ 361 -- ---- **\\*************\********* 362 +----+-- * \ +----+ +----+ * 363 |SG1A| * |SGD3| |SGD4| * 364 +----+ * +----+ +----+ * 365 | * \\ // * 366 |10 * 10 \ / 10 * 367 +----+ * +----+ * 368 |SG1B| * |SG2A| * 369 +----+ * +----+ * 370 *************************** 372 Figure 5 Multi-homed SG scenario 374 6.2. Proposed Solution 376 The root cause for the issue above is the inconsistent status of LSDB 377 between SGDs and SGMs. In order to solve this flaw, we may simply 378 add one restriction to SGDs that SG sub-networks can't be passed 379 through to reach another SGD. With this restriction, inconsistent 380 routing-table can be observed between SGDs and the rest of networks 381 in the same area, like SGD2 and SGD4 did above. Two solutions 382 proposed here. 384 Solution I: SGDs in the same SG are REQUIRED to automatically 385 interconnect with each other using certain tunnels. The tunnel can 386 be created when the SGD Router-LSA in the same SG is received. The 387 traffic SHOULD be redirected into tunnels when the SGD finds the next 388 hop points to one SGM. The exact tunnel type used here is out of the 389 scope of this document. 391 Solution II: When a SG is multi-homed to multiple SGDs, SGDs and SGMs 392 in the same SG SHOULD elect one Designated SGD (DSGD) from those 393 candidate SGDs. Adjacencies SHOULD NOT be built between the non- 394 designated SGDs and SDMs. A new DSGD SHOULD be elected among left 395 candidates when the current DSGD failed. 397 With one of the solutions above, forwarding loops and traffic black 398 hole are believed to be prevented. 400 7. Backward Compatibility 402 It is RECOMMENDED that SG feature is deployed all over the network at 403 the same time. Otherwise It will work in the standardized manner 404 without harm introduced into current network if partial deployment is 405 used. 407 8. IANA Considerations 409 This document requests that IANA allocate from the OSPF TLV 410 Codepoints Registry for a new TLV, referred to as the 411 "Synchronization Group TLV". 413 9. Security Considerations 415 This document does not introduce any new security concerns to OSPF or 416 any other specifications referenced in this document. 418 10. Acknowledgement 420 The authors would like to thank Eric Wu for his valuable suggestion 421 on this draft. 423 11. References 425 11.1. Normative References 427 [I-D.ietf-ospf-prefix-link-attr] 428 Psenak, P., Gredler, H., Shakir, R., Henderickx, W., 429 Tantsura, J., and A. Lindem, "OSPFv2 Prefix/Link Attribute 430 Advertisement", draft-ietf-ospf-prefix-link-attr-01 (work 431 in progress), September 2014. 433 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 434 Requirement Levels", BCP 14, RFC 2119, March 1997. 436 [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998. 438 11.2. Informative References 440 [RFC4970] Lindem, A., Shen, N., Vasseur, JP., Aggarwal, R., and S. 441 Shaffer, "Extensions to OSPF for Advertising Optional 442 Router Capabilities", RFC 4970, July 2007. 444 [RFC5613] Zinin, A., Roy, A., Nguyen, L., Friedman, B., and D. 445 Yeung, "OSPF Link-Local Signaling", RFC 5613, August 2009. 447 Authors' Addresses 449 Gang Yan 450 Huawei 451 Huawei Bld., No.156 Beiqing Rd. 452 Beijing 100095 453 China 455 Email: yangang@huawei.com 457 Yuanjiao Liu 458 Huawei 459 Huawei Bld., No.156 Beiqing Rd. 460 Beijing 100095 461 China 463 Email: liuyuanjiao@huawei.com 465 Xudong Zhang 466 Huawei 467 Huawei Bld., No.156 Beiqing Rd. 468 Beijing 100095 469 China 471 Email: zhangxudong@huawei.com