OSPF Flooding Reduction in MSDC
draft-xu-ospf-flooding-reduction-in-msdc-00

Abstract

OSPF is commonly used as a underlay routing protocol for MSDC (Massively Scalable Data Center) networks. This document proposes some extensions to OSPF so as to reduce the OSPF flooding within MSDC networks greatly. The reduction of the OSPF flooding is much beneficial to improve the scalability of MSDC networks. These modifications are applicable to both OSPFv2 and OSPFv3.

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at http://datatracker.ietf.org/drafts/current/.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."

This Internet-Draft will expire on July 8, 2017.

Copyright Notice

Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

Table of Contents

• 1. Introduction
• 1.1. Requirements Language
• 2. Terminology
• 3. Modifications to Current OSPF Behaviors
• 3.1. OSPF Routers as Non-DRs
• 3.2. Controllers as DR/BDR
• 4. Acknowledgements
• 5. IANA Considerations
• 6. Security Considerations
• 7. References
• 7.1. Normative References
• 7.2. Informative References
• Author's Address

1. Introduction

OSPF is commonly used as a underlay routing protocol for Massively Scalable Data Center (MSDC) networks. In addition, centrolized controllers are becoming fundemental network elements in most MSDCs. One or more controllers are usually connected to all routers within the MSDC network via a Local Area Network (LAN) which is dedicated for network management purpose (called management LAN), as shown in Figure 1.

           +----------+                  +----------+                     
           |Controller|                  |Controller|                     
           +----+-----+                  +-----+----+                     
                |DR                            |BDR                       
                |                              |                          
                |                              |                          
   ---+---------+---+----------+-----------+---+---------+-Management LAN       
      |             |          |           |             |                
      |Non-DR       |Non-DR    |Non-DR     |Non-DR       |Non-DR          
      |             |          |           |             |                
      |         +---+--+       |       +---+--+          |                
      |         |Router|       |       |Router|          |                
      |         *------*-      |      /*---/--*          |                
      |        /     \   --    |    //    /    \         |                
      |        /     \     --  |  //      /    \         |                
      |       /       \      --|//       /      \        |                
      |       /        \      /*-       /        \       |                
      |      /          \   // | --    /         \       |                
      |      /          \ //   |   --  /          \      |                
      |     /           /X     |     --           \      |                
      |     /         //  \    |     / --          \     |                
      |    /        //    \    |     /   --         \    |                
      |    /      //       \   |    /      --       \    |                
      |   /     //          \  |   /         --      \   |                
      |   /   //             \ |  /            --     \  |                
      |  /  //               \ |  /              --   \  |                
    +-+- //*                +\\+-/-+               +---\-++               
    |Router|                |Router|               |Router|               
    +------+                +------+               +------+               

                              Figure 1

With the assistance of controllers acting as OSPF DR/BDR for the management LAN, OSPF routers within the MSDC network don't need to exchange any other type of OSPF packet than the OSPF Hello packet among them. As specified in [RFC2328], these Hello packets are used for the purpose of establishing and maintaining neighbor relationships and ensuring bidirectional communication between OSPF neighbors, and even the Designated Router (DR)/Backup Designated Router (BDR) election purpose in the case where those OSPF routers are connected to a broadcast network. In order to obtain the full topology information (i.e., the fully synchronized link-state database) of the MSDC's network, these OSPF routers would exchange the link-state information with the controllers being elected as OSPF DR/BDR for the management LAN instead.

To further suppress the flooding of multicast OSPF packets originated from OSPF routers over the management LAN, OSPF routers would not send multicast OSPF Hello packets over the management LAN. Insteads, they just wait for OSPF Hello packets originated from the controllers being elected as OSPF DR/BDR initially. Once OSPF DR/BDR for the management LAN have been discovered, they start to send OSPF Hello packets directly (as unicasts) to OSPF DR/BDR periodically. In addition, OSPF routers would send other types of OSPF packets (e.g., Database Descriptor packet, Link State Request packet, Link State Update packet, Link State Acknowledgment packet) to OSPF DR/BDR for the management LAN as unicasts as well. In contrast, the controllers being elected as OSPF DR/BDR would send OSPF packets as specified in [RFC2328]. As a result, OSPF routers would not receive OSPF packets from one another unless these OSPF packets are forwarded as unknown unicasts over the management LAN. Through the above modifications to the current OSPF router behaviors, the OSPF flooding is greatly reduced which is much beneficial to improve the scalability of MSDC networks. These modifications are applicable to both OSPFv2 [RFC2328] and OSPFv3 [RFC5340].

Furthermore, the mechanism for OSPF refresh and flooding reduction in stable topologies as described in [RFC2328] could be considered as well.

1.1. Requirements Language

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].

2. Terminology

This memo makes use of the terms defined in [RFC2328].

3. Modifications to Current OSPF Behaviors

3.1. OSPF Routers as Non-DRs

After the exchange of OSPF Hello packets among OSPF routers, the OSPF neighbor relationship among them would transitions to and remains in the TWO-WAY state. OSPF routers would originate Router-LSAs and Network-LSAs as per [RFC2328]. However, these self-originated LSAs need not to be exchanged directly among them anymore. Instead, these LSAs just need to be sent solely to the controllers being elected as OSPF DR/BDR for the management LAN.

To further reduce the flood of multicast OSPF packets over the management LAN, OSPF routers SHOULD send OSPF packets as unicasts. More specifically, OSPF routers SHOULD send unicast OSPF Hello packets periodically to the controllers being elected as OSPF DR/BDR. In other words, OSPF routers would not send any OSPF Hello packet over the management LAN until they have found OSPF DR/BDR for the management LAN. Note that OSPF routers SHOULD NOT be elected as OSPF DR/BDR for the management LAN (This is done by setting the Router Priority of those OSPF routers to zero). As a result, OSPF routers would not see each other over the management LAN. Furthermore, OSPF routers SHOULD send all other types of OSPF packets than OSPF Hello packets (i.e., Database Descriptor packet, Link State Request packet, Link State Update packet, Link State Acknowledgment packet) to the controllers being elected as OSPF DR/BDR as unicasts as well.

To advoid the data traffic from being forwarded across the management LAN, the cost of all OSPF routers' interfaces to the management LAN SHOULD be set to the maximum value.

3.2. Controllers as DR/BDR

The controllers being elected as OSPF DR/BDR would send OSPF packets as multicasts or unicasts as per [RFC2328]. In addition, Link State Acknowledgment packets are RECOMMENDED to be sent as unicasts if possible.

4. Acknowledgements

TBD.

5. IANA Considerations

TBD.

6. Security Considerations

TBD.

7. References

7.1. Normative References

7.2. Informative References

Author's Address