[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02

RIFT                                                            Z. Zhang
Internet-Draft                                          Juniper Networks
Intended status: Standards Track                             J. Tantsura
Expires: May 7, 2020                                         Apstra, Inc
                                                                D. Fedyk
                                                        November 4, 2019

                  SRIFT: Segment Routing In Fat Trees


   This document specifies signaling procedures for Segment Routing
   [RFC8402] with RIFT.  Each node's loopback address, Segment Routing
   Global Block (SRGB) and Node Segment Identifier (SID), which must be
   unique within the SR domain and are typically assigned by SR
   controllers or management, are distributed southbound from the Top Of
   Fabric (TOF) nodes via the Key-Value distribution mechanism, so that
   each node can compute how to reach a node represented by the topmost
   Node SIDs .  For an ingress node to send SR traffic to another node
   via an explicit path, an SR controller signals the corresponding
   label stack to the ingress node so that the ingress node can send
   packets accordingly.

Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   document are to be interpreted as described in 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 May 7, 2020.

Zhang, et al.              Expires May 7, 2020                  [Page 1]

Internet-Draft                    srift                    November 2019

Copyright Notice

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

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Specifications  . . . . . . . . . . . . . . . . . . . . . . .   5
   3.  Security Considerations . . . . . . . . . . . . . . . . . . .   5
   4.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   6
   5.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   6
     5.1.  Normative References  . . . . . . . . . . . . . . . . . .   6
     5.2.  Informative References  . . . . . . . . . . . . . . . . .   6
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   6

1.  Introduction

   Before we discuss the SR procedures for RIFT, let us first review how
   SR works with OSPF/ISIS [I-D.ietf-ospf-segment-routing-extensions]

   Each node is provisioned with a loopback address, an SRGB, and a Node
   SID.  The loopback address and Node SID are co-ordinated centrally -
   it is unique for each node across the SR network - and then
   communicated out of band to each node and stored as configuration
   information.  For example, the out of band communication could be via
   primitive pen and paper, or modern signaling from controllers.

   SRGB configuration can be local to each node and different node can
   have the same or different label blocks for flexible label
   allocation.  Typically, modern SR networks have identical SRGB on
   each node so that a Node SID corresponds to the same label on each
   node.  However that is not mandatory.  Either way, the SRGB is part
   of the node's local configuration.  In today's network it is very
   likely pushed down from some controllers.

Zhang, et al.              Expires May 7, 2020                  [Page 2]

Internet-Draft                    srift                    November 2019

   Each node will then signal its SRGB, and its Node SID.  The Node SID
   is just an index into the SRGB and other nodes will derive the
   corresponding label for each advertised Node SID.  Consider the
   following example:

                         *   *
                       *       *
                     *           *
                   A               D
                     *           *
                       *       *
                         *   *

      Node Name  Loopback   Node SID SRGB Label Base  SRGB Label Range
      ---------  --------   -------- ---------------  ----------------

      A      1     100              50
      B      2     100              50
      C      3     200              50
      D      4     100              50

   Node A computes its IP and label routes as following:

      Destination    Next Hop
      -----------    --------       local       if_ab       if_ac       if_ab, if_ac

      Label           Next Hop
      -----           --------

      100 (La_a)      pop and look up next header
      101 (Lb_a)      swap to 101, send out of if_ab
      102 (Lc_a)      swap to 202, send out of if_ac
      103 (Ld_a)      swap to 103, send out of if_ab
                      swap to 203, send out of if_ac

   For example, Node A computes the route to node D (represented by its
   loopback address) and the next hops are node B via interface if_ab
   and node C via if_ac.  A uses D's Node SID (advertised along with D's
   loopback address), and index it into its own SRGB to obtain label

Zhang, et al.              Expires May 7, 2020                  [Page 3]

Internet-Draft                    srift                    November 2019

   Ld_a (103).  It also uses D's Node SID to index into B's and C's
   SRGBs to obtain label Ld_b (103) and Ld_c (203) respectively.  Now it
   programs its label forwarding state with (Ld_a --> (outgoing if_ab
   swap to Ld_b, outgoing if_ac swap to Ld_c)).  Notice that Ld_a, Ld_b
   and Ld_c are most likely the same though not necessarily so.

   Node B computes the route to D and finds that the next hop is node D
   itself via interface if_bd.  It use D's Node SID (advertised along
   with D's loopback address) and index it into its own SRGB and obtain
   label Ld_b (103).  It also uses the SID and index it into D's SRGB to
   obtain label Ld_d (103).  Now it programs its label forwarding state
   with (Ld_b->outgoing if_bd swap to label Ld_d).

   Similarly, D programs a label forwarding state (Ld_d->pop and lookup
   next header).

   It is clear that the following needs to happen:

   o  Each node's SRGB needs to be signalled to all other adjacent nodes

   o  Each node's Node SID needs to be signalled to all other nodes

   o  Each node's loopback address needs to be signalled to all other

   With ISIS/OSPF, each node's SRGB is actually flooded everywhere for
   simplicity.  With RIFT, North TIEs are flooded all the way north but
   South TIEs are only flooded one hop south (and then reflected one hop
   north).  While the Node TIEs could be used to flood SRGBs, each node
   would need to learn its own SRGB first.  With RIFT ZTP, the TOF nodes
   learn the SRGB and Node SID provisioning for every node (from SR
   controllers) and flood them southbound via K-V distribution - there
   is no need to flood SRGB via Node TIEs any more..

   With ISIS/OSPF, a node steer packets in two ways.  One is using
   Prefix SIDs - following shortest paths calculated by local SPFs.
   Because RIFT's principal is not to keep specific routes on a node to
   all destinations that are not south of the node, using Prefix SIDs is
   not applicable to RIFT, as it does not provide any SR benefit.

   The other is using SR-TE - following explicit paths specified in a
   segment list in the packet header.  In case of SR-TE with MPLS, a
   label stack is used - each entry in the stack represents a node on
   the TE path towards the destination.  This can be used for RIFT, as
   long as controllers provide SR policies to leaf nodes to steer
   traffic.  Leaf nodes themselves won't be able to calculate explicit
   paths as they don't have the full topology. .

Zhang, et al.              Expires May 7, 2020                  [Page 4]

Internet-Draft                    srift                    November 2019

   Consider the following 4-level topology:

                         TOF1                      TOF2

                Spine1_11    Spine1_21    Spine1_21    Spine1_22

                Spine2_11    Spine2_21    Spine2_21    Spine2_22

                  Leaf11       Leaf12       Leaf21       Leaf22

   Say the TE controller instructs Leaf11 to send a packet to Spine2_11
   with label stack (Label_TOF2, Label_Spine2_21, Label_Leaf21).
   Spine2_11 needs to recognize that Label_TOF2 maps to node TOF2 and it
   should not simply follow the default route (because the default route
   could lead to an unintended path via TOF1).  In other words, each
   node needs to have a specific route to every node in the north.  That
   means for RIFT that the southbound distance vector routing needs to
   additionally advertise routes for loopback address of the nodes in
   the north.  Each node originates a route for its own loopback address
   and advertises it southbound, with a special marking that allows a
   south node to re-advertise it further south.

   As an alternative, routes for loopback addresses may be replaced by
   "routes" for SystemIDs.  This is for further study in future

   Considerations for Prefix SIDs will be provided in future revisions.

2.  Specifications

   This document defines the following Key-Value for SR purpose, in the
   form of (key type, key value, value).  The key type is SR, The key
   value is the loopback address, and the value is a (SRGB label base,
   SRGB label range, Node SID) tuple.  This also assumes that each node
   learns its own loopback address somehow, probably through another KV
   (given the ZTP consideration).

   More details will be specified in future revisions.

3.  Security Considerations

   To be provided.

Zhang, et al.              Expires May 7, 2020                  [Page 5]

Internet-Draft                    srift                    November 2019

4.  Acknowledgements

   The authors thank Bruno Rijsman and Antoni Przygenda for their review
   and suggestions.

5.  References

5.1.  Normative References

              Przygienda, T., Sharma, A., Thubert, P., and D. Afanasiev,
              "RIFT: Routing in Fat Trees", draft-ietf-rift-rift-08
              (work in progress), September 2019.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,

5.2.  Informative References

              Previdi, S., Ginsberg, L., Filsfils, C., Bashandy, A.,
              Gredler, H., and B. Decraene, "IS-IS Extensions for
              Segment Routing", draft-ietf-isis-segment-routing-
              extensions-25 (work in progress), May 2019.

              Psenak, P., Previdi, S., Filsfils, C., Gredler, H.,
              Shakir, R., Henderickx, W., and J. Tantsura, "OSPF
              Extensions for Segment Routing", draft-ietf-ospf-segment-
              routing-extensions-27 (work in progress), December 2018.

   [RFC8402]  Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L.,
              Decraene, B., Litkowski, S., and R. Shakir, "Segment
              Routing Architecture", RFC 8402, DOI 10.17487/RFC8402,
              July 2018, <https://www.rfc-editor.org/info/rfc8402>.

Authors' Addresses

   Zhaohui Zhang
   Juniper Networks

   EMail: zzhang@juniper.net

Zhang, et al.              Expires May 7, 2020                  [Page 6]

Internet-Draft                    srift                    November 2019

   Jeff Tantsura
   Apstra, Inc

   EMail: jefftant.ietf@gmail.com

   Don Fedyk

   EMail: don.fedyk@gmail.com

Zhang, et al.              Expires May 7, 2020                  [Page 7]

Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/