Skip to main content

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

The information below is for an old version of the document.
Document Type This is an older version of an Internet-Draft whose latest revision is Expired
Author Xiaohu Xu
Last updated 2017-01-04
Stream (None)
Formats
Stream Stream state (No stream defined)
Consensus boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date (None)
Responsible AD (None)
Send notices to (None)
draft-xu-ospf-flooding-reduction-in-msdc-00
Network Working Group                                              X. Xu
Internet-Draft                                                    Huawei
Intended status: Standards Track                         January 4, 2017
Expires: July 8, 2017

                    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

Xu                        Expires July 8, 2017                  [Page 1]
Internet-Draft          MPLS Payload Protocol ID            January 2017

   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

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

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.

Xu                        Expires July 8, 2017                  [Page 2]
Internet-Draft          MPLS Payload Protocol ID            January 2017

           +----------+                  +----------+
           |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

Xu                        Expires July 8, 2017                  [Page 3]
Internet-Draft          MPLS Payload Protocol ID            January 2017

   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.

Xu                        Expires July 8, 2017                  [Page 4]
Internet-Draft          MPLS Payload Protocol ID            January 2017

   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

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <http://www.rfc-editor.org/info/rfc2119>.

   [RFC2328]  Moy, J., "OSPF Version 2", STD 54, RFC 2328,
              DOI 10.17487/RFC2328, April 1998,
              <http://www.rfc-editor.org/info/rfc2328>.

Xu                        Expires July 8, 2017                  [Page 5]
Internet-Draft          MPLS Payload Protocol ID            January 2017

   [RFC5340]  Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF
              for IPv6", RFC 5340, DOI 10.17487/RFC5340, July 2008,
              <http://www.rfc-editor.org/info/rfc5340>.

7.2.  Informative References

   [RFC4136]  Pillay-Esnault, P., "OSPF Refresh and Flooding Reduction
              in Stable Topologies", RFC 4136, DOI 10.17487/RFC4136,
              July 2005, <http://www.rfc-editor.org/info/rfc4136>.

   [RFC5838]  Lindem, A., Ed., Mirtorabi, S., Roy, A., Barnes, M., and
              R. Aggarwal, "Support of Address Families in OSPFv3",
              RFC 5838, DOI 10.17487/RFC5838, April 2010,
              <http://www.rfc-editor.org/info/rfc5838>.

Author's Address

   Xiaohu Xu
   Huawei

   Email: xuxiaohu@huawei.com

Xu                        Expires July 8, 2017                  [Page 6]