<?xml version='1.0' encoding='utf-8'?>
<!-- This template is for creating an Internet Draft using xml2rfc,
    which is available here: http://xml.resource.org. -->
<?xml-model href="rfc7991bis.rnc"?>  <!-- Required for schema validation and schema-aware editing -->
<!-- <?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?> -->
<!-- This third-party XSLT can be enabled for direct transformations in XML processors, including most browsers -->

<rfc
      xmlns:xi="http://www.w3.org/2001/XInclude"
      category="std"
      docName="draft-zwx-rift-leaf-ring-01"
      ipr="trust200902"
      obsoletes=""
      updates=""
      submissionType="IETF"
      xml:lang="en"
      tocInclude="true"
      tocDepth="4"
      symRefs="true"
      sortRefs="true"
      version="3">
  <!-- xml2rfc v2v3 conversion 2.38.1 -->
  <!-- category values: std, bcp, info, exp, and historic
    ipr values: trust200902, noModificationTrust200902, noDerivativesTrust200902,
       or pre5378Trust200902
    you can add the attributes updates="NNNN" and obsoletes="NNNN" 
    they will automatically be output with "(if approved)" -->

 <!-- ***** FRONT MATTER ***** -->

 <front>
    <!-- The abbreviated title is used in the page header - it is only necessary if the 
        full title is longer than 39 characters -->

   <title abbrev="Abbreviated Title">Supporting leaves without northbound neighbors connecting to a fat-tree network using RIFT</title>
    <seriesInfo name="Internet-Draft" value="draft-zwx-rift-leaf-ring-01"/>
    <!-- add 'role="editor"' below for the editors if appropriate -->

   <!-- Another author who claims to be an editor -->

   <author fullname="Zheng Zhang" initials="Z" surname="Zhang">
      <organization>ZTE Corporation</organization>
      <address>
        <postal>
          <street/>
          <!-- Reorder these if your country does things differently -->

         <city></city>
          <region/>
          <code/>
          <country>China</country>
        </postal>
        <phone></phone>
        <email>zhang.zheng@zte.com.cn</email>
        <!-- uri and facsimile elements may also be added -->
     </address>
    </author>
    
    <author fullname="Yuehua Wei" initials="Y" surname="Wei">
      <organization>ZTE Corporation</organization>
      <address>
        <postal>
          <street/>
          <!-- Reorder these if your country does things differently -->

         <city></city>
          <region/>
          <code/>
          <country>China</country>
        </postal>
        <phone></phone>
        <email>wei.yuehua@zte.com.cn</email>
        <!-- uri and facsimile elements may also be added -->
     </address>
    </author>
    
    <author fullname="Benchong Xu" initials="B" surname="Xu">
      <organization>ZTE Corporation</organization>
      <address>
        <postal>
          <street/>
          <!-- Reorder these if your country does things differently -->

         <city></city>
          <region/>
          <code/>
          <country>China</country>
        </postal>
        <phone></phone>
        <email>xu.benchong@zte.com.cn</email>
        <!-- uri and facsimile elements may also be added -->
     </address>
    </author>
    <date year="2022"/>
    <!-- If the month and year are both specified and are the current ones, xml2rfc will fill 
        in the current day for you. If only the current year is specified, xml2rfc will fill 
	 in the current day and month for you. If the year is not the current one, it is 
	 necessary to specify at least a month (xml2rfc assumes day="1" if not specified for the 
	 purpose of calculating the expiry date).  With drafts it is normally sufficient to 
	 specify just the year. -->

   <!-- Meta-data Declarations -->

   <area>General</area>
    <workgroup>Internet Engineering Task Force</workgroup>
    <!-- WG name at the upperleft corner of the doc,
        IETF is fine for individual submissions.  
	 If this element is not present, the default is "Network Working Group",
        which is used by the RFC Editor as a nod to the history of the IETF. -->

   <keyword>template</keyword>
    <!-- Keywords will be incorporated into HTML output
        files in a meta tag but they have no effect on text or nroff
        output. If you submit your draft to the RFC Editor, the
        keywords will be used for the search engine. -->

   <abstract>
      <t>This document discusses the usage and solution for leaf nodes without northbound neighbors connecting to a fat-tree network by leaf nodes having direct northbound neighbors in RIFT.</t>
    </abstract>
  </front>
  <middle>
    <section numbered="true" toc="default">
      <name>Introduction</name>
      <t><xref target="I-D.ietf-rift-rift" format="default"/> specifies a dynamic routing protocol for Clos and fat-tree network topology. It suits most of the deployments. In some situations, the leaves are connected by ring or chain topology, and some of them may have no northbound link, so these nodes may not be able to connecting the network. This document discusses the usage and proposes a solution.</t>
      <section numbered="true" toc="default">
        <name>Requirements Language</name>
        <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" format="default">RFC 2119</xref>.</t>
      </section>
    </section>
    <section numbered="true" toc="default">
      <name>Problem Statement</name>
      <t><xref target="I-D.ietf-rift-rift" format="default"/> specifies a dynamic routing protocol for Clos and fat-tree network topology. The leaf part of a traditional Clos and fat-tree network topology is shown as:</t>
      
      <figure anchor="Fig1">
        <artwork align="left" name="Figure 1" type="" alt=""><![CDATA[
      +                  +                  +
      | N1               | N2               | N3
      |                  |                  |
   +--+----+          +--+----+          +--+-----+
   |       |          |       |          |        |
   |  S01  +----------+  S02  +----------+  S03   | Level 1
   ++-+-+--+          ++--+--++          +---+-+-++
    | | |              |  |  |               | | |
    | | +----------------------------------+ | | |
    | |                |  |  |             | | | |
    | +-------------+  |  |  |  +--------------+ |
    |               |  |  |  |  |          | |   |
    | +----------------+  |  +-----------------+ |
    | |             |     |     |          | | | |
    | | +------------------------------------+ | |
    | | |           |     |     |          |   | |
   ++-+-+--+        | +---+---+ |        +-+---+-++
   |       |        +-+       +-+        |        |
   |  L01  |----------|  L02  |----------|  L03   | Level 0
   +-------+          +-------+          +--------+
           ]]></artwork>
      </figure>
      
      <t>In most of the cases, each leaf node has north connections with at least one spine, and there may be east-west links between leaf nodes. In case a leaf node lost all the north connections, it can still access the network through the east-west link between leaves. For example in <xref target="Fig1"/>, there is an east-west link between L01 and L02, and there is an east-west link between L02 and L03. When the northbound connections for the leaves are all work well, L01, L02 and L03 may generate a Prefix South TIE with default route and advertise it through the east-west links according to the definition in section 4.2.3.4 in <xref target="I-D.ietf-rift-rift" format="default"/>. In case L01 lost all the northbound links with S01, S02 and S03, according to Northbound SPF algorithm defined in section 4.2.4.1 in <xref target="I-D.ietf-rift-rift" format="default"/>, L01 can compute the next hop L02 for the default route. On the other hand, the prefix of L01 can be flood northbound by L02. Then L01 can still access the network through the east-west link between L01 and L02.</t>
      
      <t>But in some deployments, the leaves may connect with each other by ring topology (sometimes, a chain topology), and not all of them have northbound connection with spine nodes.</t>
	  
	  <t>For example, in the IP Radio Access Network (IP RAN, mobile backhaul network), the 4G eNB or the 5G gNB connect to an IP access network of a ring topology. The access network attaches to an aggregation network through two aggregation nodes. In 5G era, the aggregation network and the metro network is envolving to Spine-and-Leaf architecture to take the advantage of Spine-and-Leaf. <xref target="fig-ipran"/> depicts an digram of an IPRAN network with Spine-and-Leaf architecture. If the aggregation network runs RIFT, using the proposal of this draft, the access network ring does not need to deploy other IGP protocol to enable the routing.</t>


     <figure align='center' anchor='fig-ipran'><name>IPRAN network with Spine-and-Leaf architecture</name>
        <artwork align='center'><![CDATA[
                 +----+
                 |gNB |
                 +--+-+
                    |
                 +--+-+
           +-----+CSG4+---- --+
           |     +----+       |    Aggregation
+---+   +--+-+              +-+--+   Network +-----+     xxxxx
|eNB+---+CSG1|              |    +-----------+Spine+--xxxx   xxxx
+---+   +--+-+              |Leaf|           +----++            xxx
           |                |    |                |               xx
           |                +----+------------+   |                x
           | Access Network                   |   | Metro Network  x
           |                +----+------------+---+                x
           |                |    |            |                   xx
+---+   +--+-+              |Leaf|           ++----+            xxx
|gNB+---+CSG2|              |    +-----------+Spine+--xxxx   xxxx
+---+   +--+-+              +-+--+           +-----+     xxxxx
           |     +----+       |
           +-----+CSG3+---- --+
                 +--+-+
                    |
                 +--+-+
                 |eBN |
                 +----+
         ]]></artwork>
     </figure>

	  
	  
	  
      <figure anchor="Fig2">
        <artwork align="left" name="Figure 2" type="" alt=""><![CDATA[
        +                  +                  +
        | N1               | N2               | N3
        |                  |                  |
     +--+----+          +--+----+          +--+-----+
     |       |          |       |          |        |
     |  S01  +----------+  S02  +----------+  S03   | Level 1
     ++-+-+--+          ++--+--++          +---+-+-++
      | | |              |  |  |               | | |
      | | +----------------------------------+ | | |
      | |                |  |  |             | | | |
      | +-------------+  |  |  |  +--------------+ |
      |               |  |  |  |  |          | |   |
      | +----------------+  |  +-----------------+ |
      | |             |     |     |          | | | |
      | | +------------------------------------+ | |
      | | |           |     |     |          |   | |
     ++-+-+--+        | +---+---+ |        +-+---+-++
     |       |        +-+       +-+        |        |
  +--|  L01  |--------- |  L02  |----------|  L03   |--+
  |  +-------+          +-------+          +--------+  |
  |                                                    |
  |                                                    | Level 0
  |  ++-+-+--+         ++-+-+--+           ++-+-+--+   |
  |  |       |         |       |           |       |   |
  +--|  L04  |---------|  L05  |-----------|  L06  |---+
     +-------+         +-------+           +-------+
           ]]></artwork>
      </figure>
      <t><xref target="Fig2"/> is an abstract of <xref target="fig-ipran"/>, several leaves connect to the fat-tree network by ring topology, each leaf has two east-west connections with other leaves, but only L01, L02 and L03 have northbound connection with spine nodes. L01, L02 and L03 advertise a Prefix South TIE with default route through the east-west links. L04 and L06 can access the network through L01 and L03. But L04 and L06 do not generate or flood the Prefix South TIE with default route because they have no northbound link. So L05 cannot receive the Prefix South TIE with default route through the link between L04 and L05, or the link between L05 and L06. On the other hand, the prefix of L05 cannot be flooded east-west by L04 and L05. So L05 cannot send flow to other leaf, and other leaf cannot send flow to L05 also. L05 cannot access the network.</t> 
      <t>This document discuss the extension that can be used to solve the problem when some leaves without northbound neighbors connecting to a fat-tree network.</t>    
    </section>
    
    <section numbered="true" toc="default">
      <name>Solution</name>
      <section numbered="true" toc="default">
        <name>Capability advertisement</name>
        <t>A new link capability which is named leaf-transport is set in LIE and node TIE. The new capability indicates that the leaf node can transfer the Prefix TIE received from the east-west link to the other leaf node.</t>
        <t>The LIE FSM will not be affected if only one leaf supports the capability and the neighbor does not support.</t>
        <t>The capability can be used for diagnosis in case there is something wrong when computing route.</t>        
      </section>
      
      <section numbered="true" toc="default">
        <name>Prefix transferring</name>
        <t>When a leaf node which has no northbound connection receives Prefix TIE from a neighbor by an east-west link, it can transfer the Prefix TIE to the other neighbor by the other east-west link, with increased metric. The increased metric should be the sum of the received metric and the metric of the east-west link.</t>
        <t>The Prefix TIE can be the default route and the prefix of the leaf node, other prefixes can also be transferred. The network administrator can control the prefix transferring by policy.</t>
        
        <dl newline="true" spacing="normal" indent="8">
        <dt>Prefix South TIE transferring</dt>
        <dd>The leaf node without northbound neighbors which supports the leaf transfer capability, MUST transfer the Prefix South TIE received from an east-west neighbor to the other east-west neighbor which also has no northbound connection.</dd>
        <dt>Prefix North TIE transferring</dt>
        <dd>The leaf node without northbound neighbors which supports the leaf transfer capability, MUST transfer the Prefix North TIE received from an east-west neighbor which has no northbound connection to the other east-west neighbor.</dd>
         <dt>External Prefix North TIE transferring</dt>
        <dd>The leaf node without northbound neighbors which supports the leaf transfer capability, MUST transfer the External Prefix North TIE received from an east-west neighbor which has no northbound connection to the other east-west neighbor.</dd>
        </dl>
        
        <t>The leaf node without northbound neighbors which supports the leaf transfer capability, MAY transfer the Prefix TIE from an east-west neighbor to the other east-west neighbor which has northbound connection. According to Northbound SPF algorithm defined in section 4.2.4.1 in <xref target="I-D.ietf-rift-rift" format="default"/>, the transferring does not affect the routing calculating result of the neighbors which has northbound connection.</t>
      </section>
      
      <section numbered="true" toc="default">
        <name>Example</name>
        <t>In figure 2, either L04 or L06, or both of them advertise the leaf-transport capability in LIE to L05 when they are forming an adjacency. And the leaf-transport capability is also set in node TIE when L04 or L06 advertise the TIE.</t>
        <t>L04/L06 receives Prefix South TIE with default route from L01/L03, L04/L06 transfers the route through Prefix South TIE with increased metric to L05.</t>
        <t>L04/L06 receives Prefix North TIE of L05 and transfers the route through Prefix North TIE with increased metric to L01/L03.</t>
        <t>L05 receives the Prefix South TIE from L04/L06, after N-SPF calculation, L05 calculates the default route with next hop L04/L06. L01/L03 receives prefix of L05 from L04/L06, and L01/03 floods the Prefix North TIE northbound. Then L05 can send flow to other leaf through L04/L06. The flow sent by other leaf with destination set to the prefix of L05 can also be routed to L05. Then L05 can access the network.</t>
      </section>
    </section>
    
    <section anchor="IANA" numbered="true" toc="default">
      <name>IANA Considerations</name>
      <t>A new type for 'leaf-transfer' is requested in link capability.</t>
    </section>
    <section anchor="Security" numbered="true" toc="default">
      <name>Security Considerations</name>
      <t>When the node without northbound neighbors supports the function defined in this document, there may be unnecessary Prefix TIE advertisement, and unnecessary prefix may be leaked.</t>
    </section>
  </middle>
  <!--  *****BACK MATTER ***** -->

 <back>

   <references>
      <name>References</name>
      <references>
        <name>Normative References</name>
        <?rfc include="reference.RFC.2119.xml"?>	
        <?rfc include="reference.I-D.ietf-rift-rift.xml"?>
      </references>
    </references>
 </back>
</rfc>
