<?xml version="1.0" encoding="US-ASCII"?>
<!-- This template is for creating an Internet Draft using xml2rfc,
    which is available here: http://xml.resource.org. -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!-- One method to get references from the online citation libraries.
    There has to be one entity for each item to be referenced. 
    An alternate method (rfc include) is described in the references. -->
<!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC2629 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2629.xml">
<!ENTITY RFC3552 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3552.xml">
<!ENTITY I-D.narten-iana-considerations-rfc2434bis SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.narten-iana-considerations-rfc2434bis.xml">
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!-- used by XSLT processors -->
<!-- For a complete list and description of processing instructions (PIs), 
    please see http://xml.resource.org/authoring/README.html. -->
<!-- Below are generally applicable Processing Instructions (PIs) that most I-Ds might want to use.
    (Here they are set differently than their defaults in xml2rfc v1.32) -->
<?rfc strict="yes" ?>
<!-- give errors regarding ID-nits and DTD validation -->
<!-- control the table of contents (ToC) -->
<?rfc toc="yes"?>
<!-- generate a ToC -->
<?rfc tocdepth="4"?>
<!-- the number of levels of subsections in ToC. default: 3 -->
<!-- control references -->
<?rfc symrefs="yes"?>
<!-- use symbolic references tags, i.e, [RFC2119] instead of [1] -->
<?rfc sortrefs="yes" ?>
<!-- sort the reference entries alphabetically -->
<!-- control vertical white space 
    (using these PIs as follows is recommended by the RFC Editor) -->
<?rfc compact="yes" ?>
<!-- do not start each main section on a new page -->
<?rfc subcompact="no" ?>
<!-- keep one blank line between list items -->
<!-- end of list of popular I-D processing instructions -->
<rfc category="std" docName="draft-xu-lsr-flooding-reduction-in-clos-00"
     ipr="trust200902">
  <front>
    <title abbrev="">Flooding Reduction in CLOS Networks</title>

    <author fullname="Xiaohu Xu" initials="X." surname="Xu">
      <organization>China Mobile</organization>

      <address>
        <email>xuxiaohu_ietf@hotmail.com</email>
      </address>
    </author>

    <!--

-->

    <date day="22" month="November" year="2023"/>

    <abstract>
      <t>For a given OSPF (or ISIS) router within the CLOS topology, it would
      receive multiple copies of exactly the same LSA (or LSP) from multiple
      OSPF (or ISIS) neighbors. In addition, two OSPF (or ISIS) neighbors may
      send each other the same LSA (or LSP) simultaneously. The unnecessary
      link-state information flooding wastes the precious process resource of
      OSPF (or ISIS) routers. This document proposes extensions to OSPF (or
      ISIS) so as to reduce the OSPF (or ISIS) flooding within such CLOS
      networks. The reduction of the OSPF (or ISIS) flooding is much
      beneficial to improve the scalability of CLOS networks. </t>
    </abstract>

    <note title="Requirements Language">
      <t>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 <xref
      target="RFC2119">RFC 2119</xref>.</t>
    </note>
  </front>

  <middle>
    <section title="Introduction">
      <t>For a given OSPF (or ISIS) router within the CLOS topology, it would
      receive multiple copies of exactly the same LSA (or LSP) from multiple
      OSPF (or ISIS) neighbors. In addition, two OSPF (or ISIS) neighbors may
      send each other the same LSA (or LSP) simultaneously. The unnecessary
      link-state information flooding wastes the precious process resource of
      OSPF (or ISIS) routers. This document proposes extensions to OSPF (or
      ISIS) so as to reduce the OSPF (or ISIS) flooding within such CLOS
      networks. The reduction of the OSPF (or ISIS) flooding is much
      beneficial to improve the scalability of CLOS networks. </t>

      <t>As a result, some CLOS network operators had to choose BGP as the
      underlay routing protocol in their data centers <xref
      target="RFC7938"/>. However, with the emergence of high-performance
      Ethernet networks for AI and high performance computing (HPC), the
      visibility of the whole network topology, and even the link load
      information, is crucial for performing the end-to-end path
      load-balancing, also known as global load-balancing or adaptive routing.
      As a result, link-state routing protocols, such as OSPF (or ISIS), would
      have to be reconsidered as the routing protocol for large-scale AI and
      HPC Ethernet networks. Of course, the prerequisite is the scaling issue
      associated with link-state routing protocols as mentioned above could be
      well addressed.</t>

      <t>This document describes a pragmatic approach to the above scaling
      issue. The basic idea is to configure partial routers as non-reflectors
      for a given OSPF area (or a given ISIS level) which are not allowed to
      reflect the LSAs (or LSPs) received from neighbors in that OSPF area (or
      that ISIS level) to neighbors in the same OSPF area (or the same ISIS
      level).</t>

      <t>For a three-stage CLOS network (i.e., a leaf-spine network) as shown
      in Figure 1, all nodes are in OSPF area zero (or ISIS Level-2). All leaf
      nodes SHOULD be configured as non-reflectors. To further reduce the
      link-state flooding, all spine nodes except two of them COULD be
      configured as non-refletors as well. </t>

      <t>For a five-stage CLOS network (i.e., a leaf-spine-superspine network)
      as shown in Figure 2, each PoD consist of leaf nodes and spine nodes is
      configured as an OSPF non-zero area (or an ISIS Level-1 area), each
      PoD-interconnect plane consist of spine nodes and super-spine nodes is
      configured as an OSPF area zero (or an ISIS Level-2 area) . As such,
      spine nodes act as OSPF area border routers (or ISIS Level-1-2 routers).
      All leaf nodes SHOULD be configured as non-reflectors. All spine nodes
      SHOULD be configured as non-reflectors for OSPF area zero (or ISIS
      Level-2). To further reduce the link-state flooding, all spine nodes of
      each pod except at least two of them are recommended to be configured as
      non-reflectors for the associated non-zero OSPF area (or ISIS Level-1
      area), and all super-spine nodes of each PoD-interconnect plane except
      two of them COULD be configured as non-reflectors.</t>

      <t><figure>
          <artwork align="center"><![CDATA[      
   +----+ +----+ +----+ +----+  
   | S1 | | S2 | | S3 | | S4 |  (Spine)
   +----+ +----+ +----+ +----+             
             
   +----+ +----+ +----+ +----+ +----+ +----+ +----+ +----+
   | L1 | | L2 | | L3 | | L4 | | L5 | | L6 | | L7 | | L8 |  (Leaf)
   +----+ +----+ +----+ +----+ +----+ +----+ +----+ +----+ 


                              Figure 1]]></artwork>
        </figure></t>

      <t><figure>
          <artwork align="center"><![CDATA[      
   =========================================         
   # +----+ +----+ +----+ +----+           #
   # | 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]]></artwork>
        </figure></t>

      <t>The above diagram does not contain the connections between nodes. The
      reader should assume that leaf nodes in a given PoD is connected to
      every spine node in that PoD while each spine node (e.g., S1) is
      connected to all super-spine nodes in the corresponding PoD-interconnect
      plane (e.g., Plane-1).</t>
    </section>

    <section anchor="Abbreviations_Terminology" title="Terminology">
      <t>This memo makes use of the terms defined in <xref
      target="RFC2328"/>.</t>
    </section>

    <section title="Modifications to Legacy OSPF and ISIS Behaviors ">
      <t>Those OSPF (or ISIS) routers which are configured as non-reflectors
      for a given OSPF area (or a given ISIS level) SHOULD NOT reflect the
      LSAs (or LSPs) received from neighbors in that OSPF area (or that ISIS
      level) to neighbors in the same OSPF area (or the same ISIS level).</t>
    </section>

    <section anchor="Acknowledgements" title="Acknowledgements">
      <t>TBD.</t>

      <!---->
    </section>

    <section anchor="IANA" title="IANA Considerations">
      <t>TBD.</t>
    </section>

    <section anchor="Security" title="Security Considerations">
      <t>TBD.</t>

      <!---->
    </section>
  </middle>

  <back>
    <references title="Normative References">
      <?rfc include='reference.RFC.2119'?>

      <?rfc include='reference.RFC.2328'?>

      <?rfc include='reference.RFC.5340'?>

      <!---->
    </references>

    <references title="Informative References">
      <?rfc include='reference.RFC.4136'?>

      <?rfc include='reference.RFC.7938'?>

      <!---->
    </references>
  </back>
</rfc>
