idnits 2.17.00 (12 Aug 2021) /tmp/idnits48788/draft-ylz-ospf-lsdb-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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: 2) if x is not maxage LSA and A does not receive the Synchronization Group sub-TLV of Router Information Opaque LSA of B before, LSA x cannot make sure which group it belongs to, so LSA x SHOULD not be sent to adjacencies of Group Member. -- The document date (October 14, 2013) is 3140 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: 'RFC4970' is defined on line 381, but no explicit reference was found in the text ** Obsolete normative reference: RFC 4813 (Obsoleted by RFC 5613) ** Obsolete normative reference: RFC 4970 (Obsoleted by RFC 7770) Summary: 2 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). 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: April 17, 2014 Huawei Technologies 6 October 14, 2013 8 OSPF Extensions for Link State Database Synchronization Group 9 draft-ylz-ospf-lsdb-sync-group-01 11 Abstract 13 This document describes a special scheme of OSPF Database 14 synchronization by dividing OSPF Routers into different groups and 15 preventing OSPF Routers from different groups to synchronize, this 16 scheme can help to enhance the number of OSPF adjacencies and the 17 capability of deploying OSPF on large network. 19 Requirements Language 21 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 22 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 23 document are to be interpreted as described in RFC 2119 [RFC2119]. 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at http://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on April 17, 2014. 42 Copyright Notice 44 Copyright (c) 2013 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 60 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2 61 3. Requirement . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 3.1. Hub and Spoke Scenario . . . . . . . . . . . . . . . . . 3 63 4. Solution . . . . . . . . . . . . . . . . . . . . . . . . . . 4 64 4.1. Synchronization Group . . . . . . . . . . . . . . . . . . 4 65 4.2. Synchronization Group Adjacency . . . . . . . . . . . . . 4 66 4.3. LSA Synchronization by Group . . . . . . . . . . . . . . 5 67 4.4. Route Calculation . . . . . . . . . . . . . . . . . . . . 6 68 4.5. Change of Group Member's Group ID . . . . . . . . . . . . 6 69 5. Protocol Extension . . . . . . . . . . . . . . . . . . . . . 6 70 6. Protocol Process . . . . . . . . . . . . . . . . . . . . . . 8 71 6.1. Sending . . . . . . . . . . . . . . . . . . . . . . . . . 8 72 6.2. Receiving . . . . . . . . . . . . . . . . . . . . . . . . 8 73 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 74 8. Security Considerations . . . . . . . . . . . . . . . . . . . 8 75 9. Normative References . . . . . . . . . . . . . . . . . . . . 8 76 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 78 1. Introduction 80 The OSPF routing protocol has been used more and more widely in IP 81 radio access networks and enterprise networks. The routers in these 82 networks are usually small devices which have limited memory and CPU, 83 and can not be deployed on large network or large number of 84 adjacencies. This document describes a new mechanism for improving 85 this issue. 87 2. Terminology 89 Synchronization Group: Subset of one area in which the OSPF Routers 90 can exchange LSAs with each other. The OSPF Routers from different 91 Synchronization Groups MUST NOT exchange LSAs with each other. 93 Synchronization Group ID: Identity of Synchronization Group. 95 Group Member: One role of OSPF in Synchronization Group which has a 96 unique Synchronization Group ID carried in its LSA. Only those 97 members who are carrying the same Synchronization Group ID SHOULD 98 establish adjacency. Otherwise no adjacency SHOULD be established. 99 The interface of Group Member is called Group Member interface. 101 Group Master: One role of OSPF in Synchronization Group which should 102 establish adjacencies with any other OSPF Routers ignoring Group IDs. 103 The interface of Group Master is called Group Master interface. 105 3. Requirement 107 The OSPF routing protocol [RFC2328]has an mechanism to make sure the 108 LSA database to synchronize. If the LSA database is not 109 synchronized, There may be loop of routes or black hole of routes. 110 One OSPF in network must exchange link status information with its 111 adjacencies. In some scenarios that there are thousands of LSAs and 112 more than one thousand adjacencies in the network, lots of LSAs need 113 to be transferred on all adjacencies for synchronization. The 114 physical device resources including memory/CPU/ line card are the 115 critical factor to extend the size of network. 117 3.1. Hub and Spoke Scenario 119 Hub A 120 / | : | \ 121 / | : | \ 122 / | : | \ 123 p1 ... pn 125 Figure 1 Hub and Spoke Network 127 Suppose Hub A establish n adjacencies and there are m LSAs in the 128 network. Hub A will transfer (including receiving and sending) these 129 LSAs on its n interfaces. The total LSAs to transfer is O(n*m) 130 without considering the number of LSAs which need to be 131 retransmitted. The time to synchronize LSAs to n adjacencies for Hub 132 A is critical for route convergence. Hub A need support high 133 performance of transferring packets. In some scenarios, hub and 134 spoke devices are poor hardware condition with limited memory and 135 CPU, especially the spoke devices can not store all LSAs in the 136 network because of less memory. In such case, there are some special 137 requirements: 139 1) The spoke devices are not necessary to learn routes with each 140 other. 142 2) The spoke devices learn default route or gate way route from hub 143 device. 145 4. Solution 147 This document introduces a new mechanism which supports LSAs to 148 synchronize in part of one area. 150 4.1. Synchronization Group 152 One area is divided into several parts called Synchronization Groups 153 which are identified by unique ID (Synchronization Group ID). 155 Two roles of OSPF Routers are defined here: Group Member OSPF Router 156 and Group Master OSPF Router. 158 Group Member OSPF Routers from the same Synchronization Group SHOULD 159 establish adjacencies and exchange LSAs; 161 Group Member OSPF Routers from different Synchronization Group MUST 162 NOT establish adjacencies and MUST NOT exchange LSAs with each other. 164 The interface of Group Member OSPF Router is defined as Group Member 165 Interface; The interface of Group Master OSPF Router is defined as 166 Group Master Interface. 168 4.2. Synchronization Group Adjacency 170 The procedure of establishing Synchronization Group Adjacency: 172 1) A new TLV called Synchronization Group sub-TLV (see section 5) can 173 be carried in Router Information Opaque LSA [RFC4970]and Link-Local 174 Signaling (LLS for short) [RFC4813]. Group Member Interface sends 175 Router Information Opaque LSA including Synchronization Group TLV 176 with its related Synchronization Group ID and M bit set to 0; Group 177 Master Interface sends Router Information Opaque LSA including 178 Synchronization Group TLV with its Synchronization Group ID set to 0 179 and M bit set to 1. (Note: Group Member Routers/Interface SHOULD set 180 Synchronization Group ID as configured value which is not 0. Group 181 Master Routers/Interface SHOULD set Synchronization Group ID as 0.) 183 2) For Group Member whose Synchronization Group ID is not 0, 185 a) If Group Member OSPF Router has one or more neighbors of Group 186 Member, none of them don't support Synchronization Group feature, 187 they MUST NOT form normal adjacency/adjacencies. 189 b) If Group Member OSPF Router has one or more neighbors of Group 190 Member which have the same Synchronization Group ID, they SHOULD form 191 Synchronization Group adjacency/adjacencies; otherwise, they MUST NOT 192 form normal adjacency/adjacencies. 194 3) For Group Master OSPF Router whose Synchronization Group ID is 0, 196 a) If Group Master OSPF Router has one or more neighbors of OSPF 197 Routers, but none of them supports Synchronization Group feature, 198 then they can form normal adjacency/adjacencies. 200 b) If Group Master OSPF Router has one or more neighbors of Group 201 Member OSPF Routers which have the same Synchronization Group ID, 202 they can form Synchronization Group adjacency/adjacencies. If some 203 neighbors have different Synchronization Group IDs, they MUST NOT 204 form normal adjacency/adjacencies. 206 c) If Group Master OSPF Router has more than one neighbor of OSPF 207 Routers and some of them support Synchronization Group feature while 208 others don't, then they MUST NOT form normal adjacency/adjacencies. 210 d) Group Master OSPF Routers SHOULD form normal adjacencies with each 211 other on the LAN where no Group Member OSPF exists. 213 e) If a common LAN is shared by two or more Group Master OSPF Routers 214 and some Group Member OSPF Routers whose Synchronization Group ID are 215 the same, they can form Synchronization Group adjacency/adjacencies. 217 f) If a common LAN is shared by two or more Group Master OSPF Routers 218 and some Group Member OSPF Routers whose Synchronization Group ID are 219 not the same, they MUST NOT form adjacency/adjacencies. 221 Synchronization Group Adjacency SHOULD be advertised as normal 222 adjacency. 224 4.3. LSA Synchronization by Group 226 Group Member OSPF MUST carry Synchronization Group TLV (see section 227 5) in Router Information Opaque LSA and LLS. Group Member OSPF 228 Router just holds the LSAs which are generated by OSPF Routers which 229 in the same Synchronization Group, or by Group Master OSPF Routers, 230 or by OSPF Routers which don't support Synchronization Group feature. 232 The procedure of packets: 234 1) Group Member Interface and Group Master Interface which has 235 Synchronization Group Adjacency SHOULD send/receive special LSA 236 packets which just contain the entries of the same group and non- 237 group LSAs. 239 2) When Group Member Interface receives some LSAs from packet which 240 is not belong the same group, 241 a) If the LSA entry with non-maxage, the LSA entry SHOULD be discard. 243 b) If the LSA entry with maxage, the LSA entry SHOULD be processed as 244 described in OSPF [RFC2328]. 246 The procedure of LSA, When Group Member OSPF A receives OSPF B's LSA 247 x: 249 1) if x is maxage LSA, A SHOULD synchronize LSA x to adjacencies of 250 Group Member. maxage LSA SHOULD be synchronized as described in OSPF 251 [RFC2328]. 253 2) if x is not maxage LSA and A does not receive the Synchronization 254 Group sub-TLV of Router Information Opaque LSA of B before, LSA x 255 cannot make sure which group it belongs to, so LSA x SHOULD not be 256 sent to adjacencies of Group Member. 258 3) if x is not maxage LSA and A has received the Router Information 259 Opaque LSA of B, 261 a) If B does not support Synchronization Group feature, LSA x SHOULD 262 be synchronized to all adjacencies of A. 264 b) If B supports Synchronization Group feature and has the same 265 Synchronization Group ID, LSA x SHOULD be synchronized to all 266 adjacencies of A; otherwise, LSA x SHOULD NOT be sent to adjacencies 267 of Group Member. 269 4.4. Route Calculation 271 OSPF calculates routes based on its LSA database. No change in this 272 document. 274 4.5. Change of Group Member's Group ID 276 When a Group Member OSPF wants to change its group ID to another one, 277 it is RECOMMENDED to change system ID of OSPF for a new one at the 278 same time. Group member will generate new LSAs and be synchronized 279 in a new group. The old LSAs will remain in the old group, but it 280 will not be used in route calculation. The remain life of the old 281 LSAs will be reduced until LSAs reach Maxage to flush. 283 5. Protocol Extension 285 A new TLV called Synchronization Group TLV is defined to be included 286 in Router Information Opaque LSA and LLS. The Opaque LSA transmitted 287 by a interface that belongs to one Synchronization Group MUST include 288 this TLV. 290 Type TBD 292 Length # of octets in the value field (2 octets) 294 Value 296 0 1 2 3 297 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 298 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 299 | Type | Length | 300 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 301 | Flags | Reserved | Synchronization Group ID | 302 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 303 | Sub-TLV Type(*) | Sub-TLV Length(*) | 304 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 305 | Sub-TLV values(*) | 306 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 307 * - if present 309 Flags (1 octet): 311 0 1 2 3 4 5 6 7 312 +-+-+-+-+-+-+-+-+ 313 | Reserved |S|M| 314 +-+-+-+-+-+-+-+-+ 316 M - Group Master/Member Role bit 317 S - subtlv present bit 319 (Note: Group Master sets M bit to 1 and Group Member sets M bit to 0) 321 Synchronization Group ID (2 octets): The range of value of 322 Synchronization Group ID is from 0 to 65535. The value of 0 SHALL be 323 used by Group Master only. Synchronization Group ID of Group Member 324 MUST NOT be 0. 326 Sub-TLV is not defined in this document which could be extended in 327 future. 329 6. Protocol Process 331 Synchronization Group TLV is introduced to indicate whether support 332 Synchronization Group feature or not. 334 6.1. Sending 336 Synchronization Group TLV MUST be carried in the Router Information 337 Opaque LSA and LLS, and MUST encode just one time in LSA; This TLV is 338 optional to carry for Group Master OSPF Router. 340 Group Member Interface MUST carry this TLV in its Router Information 341 Opaque LSA and LLS with its related Synchronization Group ID and M 342 bit set to 0; 344 Group Master Interface sends Router Information Opaque LSA and LLS 345 including synchronization Group TLV with its Synchronization Group ID 346 set to 0 and M bit set to 1. 348 6.2. Receiving 350 If there are more than one Synchronization Group TLVs in Router 351 Information Opaque LSA, the first one is selected, others are 352 ignored. 354 if Synchronization Group ID and M bit are both set to 0 in TLV, the 355 TLV is illegal and SHOULD be ignored. 357 if Synchronization Group ID is not 0 and M bit is set to 1 in TLV, 358 the TLV is illegal and SHOULD be ignored. 360 7. IANA Considerations 362 This document requests that IANA allocate from the OSPF TLV 363 Codepoints Registry a new TLV, referred to as the "Synchronization 364 Group" TLV 366 8. Security Considerations 368 This document does not introduce any new security concerns to OSPF or 369 any other specifications referenced in this document. 371 9. Normative References 373 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 374 Requirement Levels", BCP 14, RFC 2119, March 1997. 376 [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998. 378 [RFC4813] Friedman, B., Nguyen, L., Roy, A., Yeung, D., and A. 379 Zinin, "OSPF Link-Local Signaling", RFC 4813, March 2007. 381 [RFC4970] Lindem, A., Shen, N., Vasseur, JP., Aggarwal, R., and S. 382 Shaffer, "Extensions to OSPF for Advertising Optional 383 Router Capabilities", RFC 4970, July 2007. 385 Authors' Addresses 387 Gang Yan 388 Huawei Technologies 389 Huawei Bld., No.156 Beiqing Rd. 390 Beijing 100095 391 China 393 Email: yangang@huawei.com 395 Yuanjiao Liu 396 Huawei Technologies 397 Huawei Bld., No.156 Beiqing Rd. 398 Beijing 100095 399 China 401 Email: liuyuanjiao@huawei.com 403 Xudong Zhang 404 Huawei Technologies 405 Huawei Bld., No.156 Beiqing Rd. 406 Beijing 100095 407 China 409 Email: zhangxudong@huawei.com