idnits 2.17.00 (12 Aug 2021) /tmp/idnits12280/draft-xu-ospf-flooding-reduction-in-msdc-03.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 (January 9, 2018) is 1586 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) == Unused Reference: 'RFC5838' is defined on line 265, but no explicit reference was found in the text Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 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 Huawei 4 Intended status: Standards Track L. Fang 5 Expires: July 13, 2018 Expedia, Inc 6 J. Tantsura 7 Individual 8 S. Ma 9 Juniper 10 January 9, 2018 12 OSPF Flooding Reduction in MSDC 13 draft-xu-ospf-flooding-reduction-in-msdc-03 15 Abstract 17 OSPF is commonly used as an underlay routing protocol for MSDC 18 (Massively Scalable Data Center) networks. For a given OSPF router 19 within the CLOS topology, it would receive multiple copies of exactly 20 the same LSA from multiple OSPF neighbors. In addition, two OSPF 21 neighbors may send each other the same LSA simultaneously. The 22 unneccessary link-state information flooding wastes the precious 23 process resource of OSPF routers greatly due to the fact that there 24 are too many OSPF neighbors for each OSPF router within the CLOS 25 topology. This document proposes some extensions to OSPF so as to 26 reduce the OSPF flooding within MSDC networks greatly. The reduction 27 of the OSPF flooding is much beneficial to improve the scalability of 28 MSDC networks. These modifications are applicable to both OSPFv2 and 29 OSPFv3. 31 Status of This Memo 33 This Internet-Draft is submitted in full conformance with the 34 provisions of BCP 78 and BCP 79. 36 Internet-Drafts are working documents of the Internet Engineering 37 Task Force (IETF). Note that other groups may also distribute 38 working documents as Internet-Drafts. The list of current Internet- 39 Drafts is at https://datatracker.ietf.org/drafts/current/. 41 Internet-Drafts are draft documents valid for a maximum of six months 42 and may be updated, replaced, or obsoleted by other documents at any 43 time. It is inappropriate to use Internet-Drafts as reference 44 material or to cite them other than as "work in progress." 46 This Internet-Draft will expire on July 13, 2018. 48 Copyright Notice 50 Copyright (c) 2018 IETF Trust and the persons identified as the 51 document authors. All rights reserved. 53 This document is subject to BCP 78 and the IETF Trust's Legal 54 Provisions Relating to IETF Documents 55 (https://trustee.ietf.org/license-info) in effect on the date of 56 publication of this document. Please review these documents 57 carefully, as they describe your rights and restrictions with respect 58 to this document. Code Components extracted from this document must 59 include Simplified BSD License text as described in Section 4.e of 60 the Trust Legal Provisions and are provided without warranty as 61 described in the Simplified BSD License. 63 Table of Contents 65 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 66 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 67 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 68 3. Modifications to Current OSPF Behaviors . . . . . . . . . . . 4 69 3.1. OSPF Routers as Non-DRs . . . . . . . . . . . . . . . . . 4 70 3.2. Controllers as DR/BDR . . . . . . . . . . . . . . . . . . 5 71 4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 5 72 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 73 6. Security Considerations . . . . . . . . . . . . . . . . . . . 6 74 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 75 7.1. Normative References . . . . . . . . . . . . . . . . . . 6 76 7.2. Informative References . . . . . . . . . . . . . . . . . 6 77 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6 79 1. Introduction 81 OSPF is commonly used as an underlay routing protocol for Massively 82 Scalable Data Center (MSDC) networks where CLOS is the most popular 83 toplogy. For a given OSPF router within the CLOS topology, it would 84 receive multiple copies of exactly the same LSA from multiple OSPF 85 neighbors. In addition, two OSPF neighbors may send each other the 86 same LSA simultaneously. The unnecessary link-state information 87 flooding wastes the precious process resource of OSPF routers greatly 88 and therefore OSPF could not scale very well in MSDC networks. 90 To simplify the network management task, centralized controllers are 91 becoming fundamental network elements in most MSDCs. One or more 92 controllers are usually connected to all routers within the MSDC 93 network via a Local Area Network (LAN) which is dedicated for network 94 management purpose (called management LAN), as shown in Figure 1. 96 +----------+ +----------+ 97 |Controller| |Controller| 98 +----+-----+ +-----+----+ 99 |DR |BDR 100 | | 101 | | 102 ---+---------+---+----------+-----------+---+---------+-Management LAN 103 | | | | | 104 |Non-DR |Non-DR |Non-DR |Non-DR |Non-DR 105 | | | | | 106 | +---+--+ | +---+--+ | 107 | |Router| | |Router| | 108 | *------*- | /*---/--* | 109 | / \ -- | // / \ | 110 | / \ -- | // / \ | 111 | / \ --|// / \ | 112 | / \ /*- / \ | 113 | / \ // | -- / \ | 114 | / \ // | -- / \ | 115 | / /X | -- \ | 116 | / // \ | / -- \ | 117 | / // \ | / -- \ | 118 | / // \ | / -- \ | 119 | / // \ | / -- \ | 120 | / // \ | / -- \ | 121 | / // \ | / -- \ | 122 +-+- //* +\\+-/-+ +---\-++ 123 |Router| |Router| |Router| 124 +------+ +------+ +------+ 126 Figure 1 128 With the assistance of controllers acting as OSPF Designated Router 129 (DR)/Backup Designated Router (BDR) for the management LAN, OSPF 130 routers within the MSDC network don't need to exchange any other 131 types of OSPF packet than the OSPF Hello packet among them. As 132 specified in [RFC2328], these Hello packets are used for the purpose 133 of establishing and maintaining neighbor relationships and ensuring 134 bidirectional communication between OSPF neighbors, and even the DR/ 135 BDR election purpose in the case where those OSPF routers are 136 connected to a broadcast network. In order to obtain the full 137 topology information (i.e., the fully synchronized link-state 138 database) of the MSDC's network, these OSPF routers just need to 139 exchange the link-state information with the controllers being 140 elected as OSPF DR/BDR for the management LAN instead. 142 To further suppress the flooding of multicast OSPF packets originated 143 from OSPF routers over the management LAN, OSPF routers would not 144 send multicast OSPF Hello packets over the management LAN. Insteads, 145 they just wait for OSPF Hello packets originated from the controllers 146 being elected as OSPF DR/BDR initially. Once OSPF DR/BDR for the 147 management LAN have been discovered, they start to send OSPF Hello 148 packets directly (as unicasts) to OSPF DR/BDR periodically. In 149 addition, OSPF routers would send other types of OSPF packets (e.g., 150 Database Descriptor packet, Link State Request packet, Link State 151 Update packet, Link State Acknowledgment packet) to OSPF DR/BDR for 152 the management LAN as unicasts as well. In contrast, the controllers 153 being elected as OSPF DR/BDR would send OSPF packets as specified in 154 [RFC2328]. As a result, OSPF routers would not receive OSPF packets 155 from one another unless these OSPF packets are forwarded as unknown 156 unicasts over the management LAN. Through the above modifications to 157 the current OSPF router behaviors, the OSPF flooding is greatly 158 reduced, which is much beneficial to improve the scalability of MSDC 159 networks. These modifications are applicable to both OSPFv2 160 [RFC2328] and OSPFv3 [RFC5340]. 162 Furthermore, the mechanism for OSPF refresh and flooding reduction in 163 stable topologies as described in [RFC4136] could be considered as 164 well. 166 1.1. Requirements Language 168 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 169 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 170 document are to be interpreted as described in RFC 2119 [RFC2119]. 172 2. Terminology 174 This memo makes use of the terms defined in [RFC2328]. 176 3. Modifications to Current OSPF Behaviors 178 3.1. OSPF Routers as Non-DRs 180 After the exchange of OSPF Hello packets among OSPF routers, the OSPF 181 neighbor relationship among them would transition to and remain in 182 the TWO-WAY state. OSPF routers would originate Router-LSAs and/or 183 Network-LSAs accordingly depending upon the link-types. Note that 184 the neighbors in the TWO-WAY state would be advertised in the Router- 185 LSAs and/or Network-LSA. This is a little bit different from the 186 OSPF router behavior as specified in [RFC2328] where the neighbors in 187 the TWO-WAY state would not be advertised. However, these self- 188 originated LSAs need not to be exchanged directly among them anymore. 189 Instead, these LSAs just need to be sent solely to the controllers 190 being elected as OSPF DR/BDR for the management LAN. 192 To further reduce the flood of multicast OSPF packets over the 193 management LAN, OSPF routers SHOULD send OSPF packets as unicasts. 194 More specifically, OSPF routers SHOULD send unicast OSPF Hello 195 packets periodically to the controllers being elected as OSPF DR/BDR. 196 In other words, OSPF routers would not send any OSPF Hello packet 197 over the management LAN until they have found OSPF DR/BDR for the 198 management LAN. Note that OSPF routers SHOULD NOT be elected as OSPF 199 DR/BDR for the management LAN (This is done by setting the Router 200 Priority of those OSPF routers to zero). As a result, OSPF routers 201 would not see each other over the management LAN. Furthermore, OSPF 202 routers SHOULD send all other types of OSPF packets than OSPF Hello 203 packets (i.e., Database Descriptor packet, Link State Request packet, 204 Link State Update packet, Link State Acknowledgment packet) to the 205 controllers being elected as 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 CLOS network. As such, it could obtain the full 214 LSDB of the CLOS 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 CLOS network, it would not actively establish 217 FULL adjacency with its OSPF neighbor in the TWO-WAY state by 218 default. However, it SHOULD NOT refuse to establish FULL adjacency 219 with a given OSPF neighbors when receiving Database Description 220 Packets from 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 if possible. 229 4. Acknowledgements 231 The authors would like to thank Acee Lindem for his valuable comments 232 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 [RFC5838] Lindem, A., Ed., Mirtorabi, S., Roy, A., Barnes, M., and 266 R. Aggarwal, "Support of Address Families in OSPFv3", 267 RFC 5838, DOI 10.17487/RFC5838, April 2010, 268 . 270 Authors' Addresses 272 Xiaohu Xu 273 Huawei 275 Email: xuxh.mail@gmail.com 277 Luyuan Fang 278 Expedia, Inc 280 Email: luyuanf@gmail.com 281 Jeff Tantsura 282 Individual 284 Email: jefftant@gmail.com 286 Shaowen Ma 287 Juniper 289 Email: mashao@juniper.net