idnits 2.17.1 draft-xu-lsr-ospf-flooding-reduction-in-msdc-04.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 1 character 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 (December 21, 2020) is 1222 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) No issues found here. Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group X. Xu 3 Internet-Draft Alibaba, Inc 4 Intended status: Standards Track L. Fang 5 Expires: June 24, 2021 Expedia, Inc 6 J. Tantsura 7 Apstra, Inc. 8 S. Ma 9 Juniper 10 December 21, 2020 12 OSPF Flooding Reduction in Massively Scalable Data Centers (MSDCs) 13 draft-xu-lsr-ospf-flooding-reduction-in-msdc-04 15 Abstract 17 OSPF is one of the used underlay routing protocol for MSDC (Massively 18 Scalable Data Center) networks. For a given OSPF router within the 19 CLOS topology, it would receive multiple copies of exactly the same 20 LSA from multiple OSPF neighbors. In addition, two OSPF neighbors 21 may send each other the same LSA simultaneously. The unnecessary 22 link-state information flooding wastes the precious process resource 23 of OSPF routers greatly due to the presence of too many OSPF 24 neighbors for each OSPF router within the CLOS topology. This 25 document proposes extensions to OSPF so as to reduce the OSPF 26 flooding within such MSDC networks. The reduction of the OSPF 27 flooding is much beneficial to improve the scalability of MSDC 28 networks. These modifications are applicable to both OSPFv2 and 29 OSPFv3. 31 Requirements Language 33 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 34 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 35 document are to be interpreted as described in RFC 2119 [RFC2119]. 37 Status of This Memo 39 This Internet-Draft is submitted in full conformance with the 40 provisions of BCP 78 and BCP 79. 42 Internet-Drafts are working documents of the Internet Engineering 43 Task Force (IETF). Note that other groups may also distribute 44 working documents as Internet-Drafts. The list of current Internet- 45 Drafts is at https://datatracker.ietf.org/drafts/current/. 47 Internet-Drafts are draft documents valid for a maximum of six months 48 and may be updated, replaced, or obsoleted by other documents at any 49 time. It is inappropriate to use Internet-Drafts as reference 50 material or to cite them other than as "work in progress." 52 This Internet-Draft will expire on June 24, 2021. 54 Copyright Notice 56 Copyright (c) 2020 IETF Trust and the persons identified as the 57 document authors. All rights reserved. 59 This document is subject to BCP 78 and the IETF Trust's Legal 60 Provisions Relating to IETF Documents 61 (https://trustee.ietf.org/license-info) in effect on the date of 62 publication of this document. Please review these documents 63 carefully, as they describe your rights and restrictions with respect 64 to this document. Code Components extracted from this document must 65 include Simplified BSD License text as described in Section 4.e of 66 the Trust Legal Provisions and are provided without warranty as 67 described in the Simplified BSD License. 69 Table of Contents 71 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 72 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 73 3. Modifications to Legacy OSPF Behaviors . . . . . . . . . . . 4 74 3.1. OSPF Routers as Non-DRs . . . . . . . . . . . . . . . . . 4 75 3.2. Controllers as DR/BDR . . . . . . . . . . . . . . . . . . 5 76 4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 5 77 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 78 6. Security Considerations . . . . . . . . . . . . . . . . . . . 6 79 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 80 7.1. Normative References . . . . . . . . . . . . . . . . . . 6 81 7.2. Informative References . . . . . . . . . . . . . . . . . 6 82 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6 84 1. Introduction 86 OSPF is commonly used as an underlay routing protocol for Massively 87 Scalable Data Center (MSDC) networks where CLOS is the most popular 88 topology. MSDCs are also called Large-Scale Data Centers. 90 For a given OSPF router within the CLOS topology, it would receive 91 multiple copies of exactly the same LSA from multiple OSPF neighbors. 92 In addition, two OSPF neighbors may send each other the same LSA 93 simultaneously. The unnecessary link-state information flooding 94 significantly wastes the precious process resource of OSPF routers 95 and therefore OSPF could not scale very well in MSDC networks. 97 To simplify the network management task, centralized controllers are 98 becoming fundamental network elements in most MSDCs. One or more 99 controllers are usually connected to all routers within an MSDC 100 network via a Local Area Network (LAN) which is dedicated for network 101 management purpose (called management LAN), as shown in Figure 1. 103 +----------+ +----------+ 104 |Controller| |Controller| 105 +----+-----+ +-----+----+ 106 |DR |BDR 107 | | 108 | | 109 ---+---------+---+----------+-----------+---+---------+-Management LAN 110 | | | | | 111 |Non-DR |Non-DR |Non-DR |Non-DR |Non-DR 112 | | | | | 113 | +---+--+ | +---+--+ | 114 | |Router| | |Router| | 115 | *------*- | /*---/--* | 116 | / \ -- | // / \ | 117 | / \ -- | // / \ | 118 | / \ --|// / \ | 119 | / \ /*- / \ | 120 | / \ // | -- / \ | 121 | / \ // | -- / \ | 122 | / /X | -- \ | 123 | / // \ | / -- \ | 124 | / // \ | / -- \ | 125 | / // \ | / -- \ | 126 | / // \ | / -- \ | 127 | / // \ | / -- \ | 128 | / // \ | / -- \ | 129 +-+- //* +\\+-/-+ +---\-++ 130 |Router| |Router| |Router| 131 +------+ +------+ +------+ 133 Figure 1 135 With the assistance of these controllers which are acting as OSPF 136 Designated Router (DR)/Backup Designated Router (BDR) for the 137 management LAN, OSPF routers within the MSDC network don't need to 138 exchange any other types of OSPF packet than the OSPF Hello packet 139 among them. As specified in [RFC2328], these Hello packets are used 140 for the purpose of establishing and maintaining neighbor 141 relationships and ensuring bidirectional communication between OSPF 142 neighbors, and even the DR/BDR election purpose in the case where 143 those OSPF routers are connected to a broadcast network. In order to 144 obtain the full topology information (i.e., the fully synchronized 145 link-state database) of the MSDC's network, these OSPF routers only 146 need to exchange the link-state information with the controllers 147 being elected as OSPF DR/BDR for the management LAN instead. 149 To further suppress the flooding of multicast OSPF packets originated 150 from OSPF routers over the management LAN, OSPF routers would not 151 send multicast OSPF Hello packets over the management LAN. Instead, 152 they just wait for OSPF Hello packets originated from the controllers 153 being elected as OSPF DR/BDR initially. Once OSPF DR/BDR for the 154 management LAN have been discovered, they start to send OSPF Hello 155 packets directly (as unicasts) to OSPF DR/BDR periodically. In 156 addition, OSPF routers would send other types of OSPF packets (e.g., 157 Database Descriptor packet, Link State Request packet, Link State 158 Update packet, Link State Acknowledgment packet) to OSPF DR/BDR for 159 the management LAN as unicasts as well. In contrast, the controllers 160 being elected as OSPF DR/BDR would send OSPF packets as specified in 161 [RFC2328]. As a result, OSPF routers within the MSDC would not 162 receive OSPF packets from one another unless these OSPF packets are 163 forwarded as unknown unicasts over the management LAN. Through these 164 modifications to the legacy OSPF router behaviors, the OSPF flooding 165 is greatly reduced, which is much beneficial to improve the overall 166 scalability of MSDC networks. These modifications specified in this 167 document are applicable to both OSPFv2 [RFC2328] and OSPFv3 168 [RFC5340]. 170 The mechanism for OSPF refresh and flooding reduction in stable 171 topologies as described in [RFC4136] may be considered as well. 173 2. Terminology 175 This memo makes use of the terms defined in [RFC2328]. 177 3. Modifications to Legacy OSPF Behaviors 179 3.1. OSPF Routers as Non-DRs 181 After the exchange of OSPF Hello packets among OSPF routers, the OSPF 182 neighbor relationship among them would transition to and remain in 183 the 2-WAY state. OSPF routers would originate Router-LSAs and/or 184 Network-LSAs accordingly depending upon the link-types. Note that 185 the neighbors in the 2-WAY state would be advertised in the Router- 186 LSAs and/or Network-LSA. This is slightly different from the legacy 187 OSPF router behavior as specified in [RFC2328] where the neighbors in 188 the TWO-WAY state would not be advertised. However, these self- 189 originated LSAs need not to be exchanged directly among them anymore. 190 Instead, these LSAs only need to be sent solely to the controllers 191 being elected as OSPF DR/BDR for the management LAN. 193 To further reduce the flood of multicast OSPF packets over the 194 management LAN, OSPF routers SHOULD send OSPF packets as unicasts. 195 More specifically, OSPF routers SHOULD send unicast OSPF Hello 196 packets periodically to the controllers being elected as OSPF DR/BDR. 197 In other words, OSPF routers SHOULD NOT send any OSPF Hello packet 198 over the management LAN until they have found an OSPF DR/BDR for the 199 management LAN. Note that OSPF routers, within the MSDC, SHOULD NOT 200 be elected as OSPF DR/BDR for the management LAN (This is done by 201 setting the Router Priority of those OSPF routers to zero). As a 202 result, OSPF routers would not see each other over the management 203 LAN. Furthermore, OSPF routers SHOULD send all other types of OSPF 204 packets than OSPF Hello packets to the controllers being elected as 205 OSPF DR/BDR as unicasts as well. 207 To avoid the data traffic from being forwarded across the management 208 LAN, the cost of all OSPF routers' interfaces to the management LAN 209 SHOULD be set to the maximum value. 211 When a given OSPF router lost its connection to the management LAN, 212 it SHOULD actively establish FULL adjacency with all of its OSPF 213 neighbors within the MSDC network. As such, it could obtain the full 214 LSDB of the MSDC network while flooding its self-originated LSAs to 215 the remaining part of the whole network. That's to say, for a given 216 OSPF router within the MSDC network, it would not actively establish 217 FULL adjacency with its OSPF neighbor in the 2-WAY state by default. 218 However, it SHOULD NOT refuse to establish FULL adjacency with a 219 given OSPF neighbors when receiving Database Description Packets from 220 that OSPF neighbor. 222 3.2. Controllers as DR/BDR 224 The controllers being elected as OSPF DR/BDR would send OSPF packets 225 as multicasts or unicasts as per [RFC2328]. In addition, Link State 226 Acknowledgment packets are RECOMMENDED to be sent as unicasts rather 227 than multicasts. 229 4. Acknowledgements 231 The authors would like to thank Acee Lindem and Mohamed Boucadair for 232 their valuable comments and suggestions on this document. 234 5. IANA Considerations 236 TBD. 238 6. Security Considerations 240 TBD. 242 7. References 244 7.1. Normative References 246 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 247 Requirement Levels", BCP 14, RFC 2119, 248 DOI 10.17487/RFC2119, March 1997, 249 . 251 [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, 252 DOI 10.17487/RFC2328, April 1998, 253 . 255 [RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF 256 for IPv6", RFC 5340, DOI 10.17487/RFC5340, July 2008, 257 . 259 7.2. Informative References 261 [RFC4136] Pillay-Esnault, P., "OSPF Refresh and Flooding Reduction 262 in Stable Topologies", RFC 4136, DOI 10.17487/RFC4136, 263 July 2005, . 265 Authors' Addresses 267 Xiaohu Xu 268 Alibaba, Inc 270 Email: 13910161692@qq.com 272 Luyuan Fang 273 Expedia, Inc 275 Email: luyuanf@gmail.com 277 Jeff Tantsura 278 Apstra, Inc. 280 Email: jefftant.ietf@gmail.com 281 Shaowen Ma 282 Juniper 284 Email: mashao@juniper.net