idnits 2.17.1 draft-xu-ospf-flooding-reduction-in-msdc-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 : ---------------------------------------------------------------------------- ** 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 4, 2017) is 2640 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: 'RFC4136' is defined on line 227, but no explicit reference was found in the text == Unused Reference: 'RFC5838' is defined on line 231, but no explicit reference was found in the text 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 X. Xu 3 Internet-Draft Huawei 4 Intended status: Standards Track January 4, 2017 5 Expires: July 8, 2017 7 OSPF Flooding Reduction in MSDC 8 draft-xu-ospf-flooding-reduction-in-msdc-00 10 Abstract 12 OSPF is commonly used as a underlay routing protocol for MSDC 13 (Massively Scalable Data Center) networks. This document proposes 14 some extensions to OSPF so as to reduce the OSPF flooding within MSDC 15 networks greatly. The reduction of the OSPF flooding is much 16 beneficial to improve the scalability of MSDC networks. These 17 modifications are applicable to both OSPFv2 and OSPFv3. 19 Status of This Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at http://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on July 8, 2017. 36 Copyright Notice 38 Copyright (c) 2017 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 54 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 55 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 56 3. Modifications to Current OSPF Behaviors . . . . . . . . . . . 4 57 3.1. OSPF Routers as Non-DRs . . . . . . . . . . . . . . . . . 4 58 3.2. Controllers as DR/BDR . . . . . . . . . . . . . . . . . . 5 59 4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 5 60 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 61 6. Security Considerations . . . . . . . . . . . . . . . . . . . 5 62 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 63 7.1. Normative References . . . . . . . . . . . . . . . . . . 5 64 7.2. Informative References . . . . . . . . . . . . . . . . . 6 65 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 6 67 1. Introduction 69 OSPF is commonly used as a underlay routing protocol for Massively 70 Scalable Data Center (MSDC) networks. In addition, centrolized 71 controllers are becoming fundemental network elements in most MSDCs. 72 One or more controllers are usually connected to all routers within 73 the MSDC network via a Local Area Network (LAN) which is dedicated 74 for network management purpose (called management LAN), as shown in 75 Figure 1. 77 +----------+ +----------+ 78 |Controller| |Controller| 79 +----+-----+ +-----+----+ 80 |DR |BDR 81 | | 82 | | 83 ---+---------+---+----------+-----------+---+---------+-Management LAN 84 | | | | | 85 |Non-DR |Non-DR |Non-DR |Non-DR |Non-DR 86 | | | | | 87 | +---+--+ | +---+--+ | 88 | |Router| | |Router| | 89 | *------*- | /*---/--* | 90 | / \ -- | // / \ | 91 | / \ -- | // / \ | 92 | / \ --|// / \ | 93 | / \ /*- / \ | 94 | / \ // | -- / \ | 95 | / \ // | -- / \ | 96 | / /X | -- \ | 97 | / // \ | / -- \ | 98 | / // \ | / -- \ | 99 | / // \ | / -- \ | 100 | / // \ | / -- \ | 101 | / // \ | / -- \ | 102 | / // \ | / -- \ | 103 +-+- //* +\\+-/-+ +---\-++ 104 |Router| |Router| |Router| 105 +------+ +------+ +------+ 107 Figure 1 109 With the assistance of controllers acting as OSPF DR/BDR for the 110 management LAN, OSPF routers within the MSDC network don't need to 111 exchange any other type of OSPF packet than the OSPF Hello packet 112 among them. As specified in [RFC2328], these Hello packets are used 113 for the purpose of establishing and maintaining neighbor 114 relationships and ensuring bidirectional communication between OSPF 115 neighbors, and even the Designated Router (DR)/Backup Designated 116 Router (BDR) election purpose in the case where those OSPF routers 117 are connected to a broadcast network. In order to obtain the full 118 topology information (i.e., the fully synchronized link-state 119 database) of the MSDC's network, these OSPF routers would exchange 120 the link-state information with the controllers being elected as OSPF 121 DR/BDR for the management LAN instead. 123 To further suppress the flooding of multicast OSPF packets originated 124 from OSPF routers over the management LAN, OSPF routers would not 125 send multicast OSPF Hello packets over the management LAN. Insteads, 126 they just wait for OSPF Hello packets originated from the controllers 127 being elected as OSPF DR/BDR initially. Once OSPF DR/BDR for the 128 management LAN have been discovered, they start to send OSPF Hello 129 packets directly (as unicasts) to OSPF DR/BDR periodically. In 130 addition, OSPF routers would send other types of OSPF packets (e.g., 131 Database Descriptor packet, Link State Request packet, Link State 132 Update packet, Link State Acknowledgment packet) to OSPF DR/BDR for 133 the management LAN as unicasts as well. In contrast, the controllers 134 being elected as OSPF DR/BDR would send OSPF packets as specified in 135 [RFC2328]. As a result, OSPF routers would not receive OSPF packets 136 from one another unless these OSPF packets are forwarded as unknown 137 unicasts over the management LAN. Through the above modifications to 138 the current OSPF router behaviors, the OSPF flooding is greatly 139 reduced which is much beneficial to improve the scalability of MSDC 140 networks. These modifications are applicable to both OSPFv2 141 [RFC2328] and OSPFv3 [RFC5340]. 143 Furthermore, the mechanism for OSPF refresh and flooding reduction in 144 stable topologies as described in [RFC2328] could be considered as 145 well. 147 1.1. Requirements Language 149 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 150 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 151 document are to be interpreted as described in RFC 2119 [RFC2119]. 153 2. Terminology 155 This memo makes use of the terms defined in [RFC2328]. 157 3. Modifications to Current OSPF Behaviors 159 3.1. OSPF Routers as Non-DRs 161 After the exchange of OSPF Hello packets among OSPF routers, the OSPF 162 neighbor relationship among them would transitions to and remains in 163 the TWO-WAY state. OSPF routers would originate Router-LSAs and 164 Network-LSAs as per [RFC2328]. However, these self-originated LSAs 165 need not to be exchanged directly among them anymore. Instead, these 166 LSAs just need to be sent solely to the controllers being elected as 167 OSPF DR/BDR for the management LAN. 169 To further reduce the flood of multicast OSPF packets over the 170 management LAN, OSPF routers SHOULD send OSPF packets as unicasts. 171 More specifically, OSPF routers SHOULD send unicast OSPF Hello 172 packets periodically to the controllers being elected as OSPF DR/BDR. 174 In other words, OSPF routers would not send any OSPF Hello packet 175 over the management LAN until they have found OSPF DR/BDR for the 176 management LAN. Note that OSPF routers SHOULD NOT be elected as OSPF 177 DR/BDR for the management LAN (This is done by setting the Router 178 Priority of those OSPF routers to zero). As a result, OSPF routers 179 would not see each other over the management LAN. Furthermore, OSPF 180 routers SHOULD send all other types of OSPF packets than OSPF Hello 181 packets (i.e., Database Descriptor packet, Link State Request packet, 182 Link State Update packet, Link State Acknowledgment packet) to the 183 controllers being elected as OSPF DR/BDR as unicasts as well. 185 To advoid the data traffic from being forwarded across the management 186 LAN, the cost of all OSPF routers' interfaces to the management LAN 187 SHOULD be set to the maximum value. 189 3.2. Controllers as DR/BDR 191 The controllers being elected as OSPF DR/BDR would send OSPF packets 192 as multicasts or unicasts as per [RFC2328]. In addition, Link State 193 Acknowledgment packets are RECOMMENDED to be sent as unicasts if 194 possible. 196 4. Acknowledgements 198 TBD. 200 5. IANA Considerations 202 TBD. 204 6. Security Considerations 206 TBD. 208 7. References 210 7.1. Normative References 212 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 213 Requirement Levels", BCP 14, RFC 2119, 214 DOI 10.17487/RFC2119, March 1997, 215 . 217 [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, 218 DOI 10.17487/RFC2328, April 1998, 219 . 221 [RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF 222 for IPv6", RFC 5340, DOI 10.17487/RFC5340, July 2008, 223 . 225 7.2. Informative References 227 [RFC4136] Pillay-Esnault, P., "OSPF Refresh and Flooding Reduction 228 in Stable Topologies", RFC 4136, DOI 10.17487/RFC4136, 229 July 2005, . 231 [RFC5838] Lindem, A., Ed., Mirtorabi, S., Roy, A., Barnes, M., and 232 R. Aggarwal, "Support of Address Families in OSPFv3", 233 RFC 5838, DOI 10.17487/RFC5838, April 2010, 234 . 236 Author's Address 238 Xiaohu Xu 239 Huawei 241 Email: xuxiaohu@huawei.com