Skip to main content

Flooding Reduction in CLOS Networks
draft-xu-lsr-flooding-reduction-in-clos-01

Document Type Active Internet-Draft (individual)
Author Xiaohu Xu
Last updated 2023-11-21
RFC stream (None)
Intended RFC status (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-lsr-flooding-reduction-in-clos-01
Network Working Group                                              X. Xu
Internet-Draft                                              China Mobile
Intended status: Standards Track                        22 November 2023
Expires: 25 May 2024

                  Flooding Reduction in CLOS Networks
               draft-xu-lsr-flooding-reduction-in-clos-01

Abstract

   In a CLOS topology, an OSPF (or ISIS) router may receive identical
   copies of an LSA (or LSP) from multiple OSPF (or ISIS) neighbors.
   Moreover, two OSPF (or ISIS) neighbors may exchange the same LSA (or
   LSP) simultaneously.  This results in unnecessary flooding of link-
   state information, which wastes the precious resources of OSPF (or
   ISIS) routers.  Therefore, this document proposes extensions to OSPF
   (or ISIS) to reduce this flooding within CLOS networks.  The
   reduction of OSPF (or ISIS) flooding is highly beneficial for
   improving the scalability of CLOS networks.

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].

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 https://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 25 May 2024.

Copyright Notice

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

Xu                         Expires 25 May 2024                  [Page 1]
Internet-Draft     Flooding Reduction in CLOS Networks     November 2023

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents (https://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 Revised BSD License text as
   described in Section 4.e of the Trust Legal Provisions and are
   provided without warranty as described in the Revised BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Solution Description  . . . . . . . . . . . . . . . . . . . .   3
   3.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   5
   4.  Modifications to OSPF and ISIS Behavior . . . . . . . . . . .   5
   5.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   5
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   5
   7.  Security Considerations . . . . . . . . . . . . . . . . . . .   5
   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   5
     8.1.  Normative References  . . . . . . . . . . . . . . . . . .   5
     8.2.  Informative References  . . . . . . . . . . . . . . . . .   5
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .   6

1.  Introduction

   In a CLOS topology, OSPF or ISIS routers might receive multiple
   identical copies of an LSA or LSP from different neighbors, two
   neighbors may even exchange the same LSA or LSP simultaneously.  The
   unnecessary flooding of link-state information waste valuable
   resources of OSPF or ISIS routers.  To tackle this issue, this
   document proposes some extensions to OSPF or ISIS so as to reduce the
   unnecessary flooding within CLOS networks and therefore improve the
   scalability of CLOS networks.

   Due to the flooding issue as mentioned above, some data center
   network operators have opted for BGP [RFC7938] as the underlay
   routing protocol for their CLOS networks.

   However, with the advent of high-performance Ethernet networks for AI
   and HPC, it has become necessary to have visibility of the whole
   network topology, including link capacity and load information, to
   enable end-to-end path load-balancing, also known as global load-
   balancing or adaptive routing.  This implies that link-state routing
   protocols like OSPF or ISIS may need to be reviewed as the routing
   protocol for large-scale AI and HPC Ethernet networks, provided the
   scaling issue associated with link-state routing protocols is well
   addressed.

Xu                         Expires 25 May 2024                  [Page 2]
Internet-Draft     Flooding Reduction in CLOS Networks     November 2023

   To address the scaling issue, this document proposes a pragmatic
   approach.  The idea is to configure partial routers as non-reflectors
   for a given OSPF area or a given ISIS level.  These routers cannot
   reflect the LSAs or LSPs they receive from neighbors in that OSPF
   area or ISIS level to their other neighbors in the same OSPF area or
   ISIS level.

2.  Solution Description

       +----+ +----+ +----+ +----+
       | S1 | | S2 | | S3 | | S4 |  (Spine)
       +----+ +----+ +----+ +----+

       +----+ +----+ +----+ +----+ +----+ +----+ +----+ +----+
       | L1 | | L2 | | L3 | | L4 | | L5 | | L6 | | L7 | | L8 |  (Leaf)
       +----+ +----+ +----+ +----+ +----+ +----+ +----+ +----+

                                  Figure 1

   (Note that the diagram above does not include the connections between
   nodes.  However, it can be assumed that leaf nodes are connected to
   every spine node in their CLOS topology.)

   In a three-stage CLOS network as shown in Figure 1, also known as a
   leaf-spine network, all nodes should be in OSPF area zero or ISIS
   Level-2.  All leaf nodes SHOULD be configured as non-reflectors.  To
   further reduce the flooding of link-state, all spine nodes, except
   for two, COULD also be configured as non-reflectors.

Xu                         Expires 25 May 2024                  [Page 3]
Internet-Draft     Flooding Reduction in CLOS Networks     November 2023

     =========================================
     # +----+ +----+ +----+ +----+           #
     # | L1 | | L2 | | L3 | | L4 | (Leaf)    #
     # +----+ +----+ +----+ +----+           #
     #                                PoD-1  #
     # +----+ +----+ +----+ +----+           #
     # | S1 | | S2 | | S3 | | S4 | (Spine)   #
     # +----+ +----+ +----+ +----+           #
     =========================================

     ===============================     ===============================
     # +----+ +----+ +----+ +----+ #     # +----+ +----+ +----+ +----+ #
     # |SS1 | |SS2 | |SS3 | |SS4 | #     # |SS1 | |SS2 | |SS3 | |SS4 | #
     # +----+ +----+ +----+ +----+ #     # +----+ +----+ +----+ +----+ #
     #   (Super-Spine@Plane-1)     #     #   (Super-Spine@Plane-4)     #
     #============================== ... ===============================

     =========================================
     # +----+ +----+ +----+ +----+           #
     # | S1 | | S2 | | S3 | | S4 | (Spine)   #
     # +----+ +----+ +----+ +----+           #
     #                                PoD-8  #
     # +----+ +----+ +----+ +----+           #
     # | L1 | | L2 | | L3 | | L4 | (Leaf)    #
     # +----+ +----+ +----+ +----+           #
     =========================================

                                Figure 2

   (Note that the diagram above does not include the connections between
   nodes.  However, it can be assumed that the leaf nodes in a given PoD
   are connected to every spine node in that PoD.  Similarly, each spine
   node (e.g., S1) is connected to all super-spine nodes in the
   corresponding PoD-interconnect plane (e.g., Plane-1).)

   For a five-stage CLOS network as illustrated in Figure 2, each Pod
   consisting of leaf and spine nodes is configured as an OSPF non-zero
   area or an ISIS Level-1 area.  The Pod-interconnect plane consisting
   of spine and super-spine nodes is configured as an OSPF area zero or
   an ISIS Level-2 area.  Therefore, spine nodes play the role of OSPF
   area border routers or ISIS Level-1-2 routers.  All leaf nodes SHOULD
   be configured as non-reflectors, and all spine nodes SHOULD be
   configured as non-reflectors for OSPF area zero or ISIS Level-2.  To
   reduce the link-state flooding further, all spine nodes in each Pod,
   except for at least two of them, COULD be configured as non-
   reflectors for the associated non-zero OSPF area or ISIS Level-1
   area.  Similarly, all super-spine nodes in each Pod-interconnect
   plane, except for two of them, COULD be configured as non-reflectors.

Xu                         Expires 25 May 2024                  [Page 4]
Internet-Draft     Flooding Reduction in CLOS Networks     November 2023

3.  Terminology

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

4.  Modifications to OSPF and ISIS Behavior

   Routers that are configured as non-reflectors for a given OSPF area
   or ISIS level SHOULD NOT reflect the LSAs or LSPs they receive from
   neighbors in that OSPF area or ISIS level to their other neighbors in
   the same OSPF area or ISIS level.

5.  Acknowledgements

   TBD.

6.  IANA Considerations

   TBD.

7.  Security Considerations

   TBD.

8.  References

8.1.  Normative References

   [RFC1195]  Callon, R., "Use of OSI IS-IS for routing in TCP/IP and
              dual environments", RFC 1195, DOI 10.17487/RFC1195,
              December 1990, <https://www.rfc-editor.org/info/rfc1195>.

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

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

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

8.2.  Informative References

Xu                         Expires 25 May 2024                  [Page 5]
Internet-Draft     Flooding Reduction in CLOS Networks     November 2023

   [RFC7938]  Lapukhov, P., Premji, A., and J. Mitchell, Ed., "Use of
              BGP for Routing in Large-Scale Data Centers", RFC 7938,
              DOI 10.17487/RFC7938, August 2016,
              <https://www.rfc-editor.org/info/rfc7938>.

Author's Address

   Xiaohu Xu
   China Mobile
   Email: xuxiaohu_ietf@hotmail.com

Xu                         Expires 25 May 2024                  [Page 6]