[Search] [txt|html|xml|pdf|bibtex] [Tracker] [Email] [Nits]

Versions: 00                                                            
Internet Engineering Task Force                                 Z. Zhang
Internet-Draft                                                    Y. Wei
Intended status: Standards Track                                   B. Xu
Expires: 8 January 2022                                  ZTE Corporation
                                                             7 July 2021


Supporting leaves without northbound neighbors connecting to a fat-tree
                           network using RIFT
                      draft-zwx-rift-leaf-ring-00

Abstract

   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.

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 8 January 2022.

Copyright Notice

   Copyright (c) 2021 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 (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 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.




Zhang, et al.            Expires 8 January 2022                 [Page 1]


Internet-Draft              Abbreviated Title                  July 2021


Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
     1.1.  Requirements Language . . . . . . . . . . . . . . . . . .   2
   2.  Problem Statement . . . . . . . . . . . . . . . . . . . . . .   2
   3.  Solution  . . . . . . . . . . . . . . . . . . . . . . . . . .   6
     3.1.  Capability advertisement  . . . . . . . . . . . . . . . .   6
     3.2.  Prefix transferring . . . . . . . . . . . . . . . . . . .   6
     3.3.  Example . . . . . . . . . . . . . . . . . . . . . . . . .   7
   4.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   7
   5.  Security Considerations . . . . . . . . . . . . . . . . . . .   7
   6.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   7
     6.1.  Normative References  . . . . . . . . . . . . . . . . . .   7
     6.2.  Informative References  . . . . . . . . . . . . . . . . .   7
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   8

1.  Introduction

   [I-D.ietf-rift-rift] 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.

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.  Problem Statement

   [I-D.ietf-rift-rift] 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:















Zhang, et al.            Expires 8 January 2022                 [Page 2]


Internet-Draft              Abbreviated Title                  July 2021


         +                  +                  +
         | N1               | N2               | N3
         |                  |                  |
      +--+----+          +--+----+          +--+-----+
      |       |          |       |          |        |
      |  S01  +----------+  S02  +----------+  S03   | Level 1
      ++-+-+--+          ++--+--++          +---+-+-++
       | | |              |  |  |               | | |
       | | +----------------------------------+ | | |
       | |                |  |  |             | | | |
       | +-------------+  |  |  |  +--------------+ |
       |               |  |  |  |  |          | |   |
       | +----------------+  |  +-----------------+ |
       | |             |     |     |          | | | |
       | | +------------------------------------+ | |
       | | |           |     |     |          |   | |
      ++-+-+--+        | +---+---+ |        +-+---+-++
      |       |        +-+       +-+        |        |
      |  L01  |----------|  L02  |----------|  L03   | Level 0
      +-------+          +-------+          +--------+

                                  Figure 1

   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 Figure 1, 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 [I-D.ietf-rift-rift].  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 [I-D.ietf-rift-rift], 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.

   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.

   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



Zhang, et al.            Expires 8 January 2022                 [Page 3]


Internet-Draft              Abbreviated Title                  July 2021


   architecture to take the advantage of Spine-and-Leaf.  Figure 2
   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.

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

          Figure 2: IPRAN network with Spine-and-Leaf architecture


















Zhang, et al.            Expires 8 January 2022                 [Page 4]


Internet-Draft              Abbreviated Title                  July 2021


           +                  +                  +
           | N1               | N2               | N3
           |                  |                  |
        +--+----+          +--+----+          +--+-----+
        |       |          |       |          |        |
        |  S01  +----------+  S02  +----------+  S03   | Level 1
        ++-+-+--+          ++--+--++          +---+-+-++
         | | |              |  |  |               | | |
         | | +----------------------------------+ | | |
         | |                |  |  |             | | | |
         | +-------------+  |  |  |  +--------------+ |
         |               |  |  |  |  |          | |   |
         | +----------------+  |  +-----------------+ |
         | |             |     |     |          | | | |
         | | +------------------------------------+ | |
         | | |           |     |     |          |   | |
        ++-+-+--+        | +---+---+ |        +-+---+-++
        |       |        +-+       +-+        |        |
     +--|  L01  |--------- |  L02  |----------|  L03   |--+
     |  +-------+          +-------+          +--------+  |
     |                                                    |
     |                                                    | Level 0
     |  ++-+-+--+         ++-+-+--+           ++-+-+--+   |
     |  |       |         |       |           |       |   |
     +--|  L04  |---------|  L05  |-----------|  L06  |---+
        +-------+         +-------+           +-------+

                                  Figure 3

   Figure 3 is an abstract of Figure 2, 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.

   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.





Zhang, et al.            Expires 8 January 2022                 [Page 5]


Internet-Draft              Abbreviated Title                  July 2021


3.  Solution

3.1.  Capability advertisement

   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.

   The LIE FSM will not be affected if only one leaf supports the
   capability and the neighbor does not support.

   The capability can be used for diagnosis in case there is something
   wrong when computing route.

3.2.  Prefix transferring

   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.

   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.

   Prefix South TIE transferring
           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.

   Prefix North TIE transferring
           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.

   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 [I-D.ietf-rift-rift], the transferring does not affect the
   routing calculating result of the neighbors which has northbound
   connection.





Zhang, et al.            Expires 8 January 2022                 [Page 6]


Internet-Draft              Abbreviated Title                  July 2021


3.3.  Example

   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.

   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.

   L04/L06 receives Prefix North TIE of L05 and transfers the route
   through Prefix North TIE with increased metric to L01/L03.

   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.

4.  IANA Considerations

   A new type for 'leaf-transfer' is requested in link capability.

5.  Security Considerations

   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.

6.  References

6.1.  Normative References

   [I-D.ietf-rift-rift]
              Przygienda, T., Sharma, A., Thubert, P., Rijsman, B., and
              D. Afanasiev, "RIFT: Routing in Fat Trees", 2021,
              <https://www.ietf.org/internet-drafts/draft-ietf-rift-
              rift.txt>.

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

6.2.  Informative References



Zhang, et al.            Expires 8 January 2022                 [Page 7]


Internet-Draft              Abbreviated Title                  July 2021


   [RFC7991]  Hoffman, P., "The "xml2rfc" Version 3 Vocabulary",
              RFC 7991, DOI 10.17487/RFC7991, December 2016,
              <https://www.rfc-editor.org/info/rfc7991>.

Authors' Addresses

   Zheng Zhang
   ZTE Corporation
   China

   Email: zhang.zheng@zte.com.cn


   Yuehua Wei
   ZTE Corporation
   China

   Email: wei.yuehua@zte.com.cn


   Benchong Xu
   ZTE Corporation
   China

   Email: xu.benchong@zte.com.cn


























Zhang, et al.            Expires 8 January 2022                 [Page 8]