SRIFT: Segment Routing in Fat Trees
Internet-Draft draft-ietf-rift-sr-01
Zhaohui Zhang
Juniper Networks
zzhang@juniper.net
Jeff Tantsura
Nvidia
jefftant.ietf@gmail.com
Jordan Head
Juniper Networks
jhead@juniper.net
RIFT
This document specifies signaling procedures for Segment Routing in RIFT. Each node's loopback address, Segment Routing Global Block (SRGB) and Node Segment Identifier (Node-SID), which are typically assigned by a configuration management system and distibuted by routing protocols, are distributed southbound from the Top Of Fabric (TOF) nodes via RIFT's Key-Value distribution mechanism, so that each node can compute how to reach a segment represented by the active SID in a packet. An SR controller signals SR policies to ingress nodes so that they can send packets with a desired segment list to steer traffic.
Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
Introduction
Before we discuss the SR procedures for RIFT, let us first review how SR works with OSPF [RFC8665] and IS-IS [RFC8667].
Each node is provisioned with a loopback address as well as SRGB and Node-SID values. The loopback address and Node-SID are centrally coordinated and are unique per-node within the SR network. These values are then communicated to each node out-of-band and stored as configuration information. Communication could be done via primitive pen and paper or via modern signaling (Netconf/YANG) from a configuration management system.
SRGB information represents the label range of the "global" labels that can be allocated on a particular node for SR. SRGB could have more than one contiguous range of labeks allocated to it. It is comprised of the first available label value and the total number of available labels per range. While in modern networks it is common for each node to have identical SRGB values so that a Node-SID will correspond to the same label on each node, this is not required as to allow for flexible label allocation. In either scenario, SRGB is part of each node's configuration. In today's networks, it is likely pushed to nodes by a configuration management system.
Each node then signals its SRGB and Node-SID to the other nodes. A Node-SID is an index value assigned to a node (say node X), and another node (say node Y) uses the Node-SID to derive (from Y's SRGB) the label to use when sending traffic to node X.
Consider the following example illustrating Node A's computed IP route and label values.

                    B
                  *   *
                *       *
              *           *
            A               D
              *           *
                *       *
                  *   *
                    C

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

A           10.1.1.1   1          100               50
B           10.1.1.2   2          100               50
C           10.1.1.3   3          200               50
D           10.1.1.4   4          100               50

   Destination    Next Hop
   -----------    --------
   10.1.1.1       local
   10.1.1.2       if_ab
   10.1.1.3       if_ac
   10.1.1.4       if_ab, if_ac

   Label           Next Hop
   -----           --------
   100 (La_a)      pop and look up next header
   101 (Lb_a)      swap to 101 (Lb_b), via if_ab
   102 (Lc_a)      swap to 202 (Lc_c), via if_ac
   103 (Ld_a)      swap to 103 (Ld_b), via if_ab
                   swap to 203 (Ld_c), via if_ac

The specific notation Lb_a refers to the label derived for node B, using B's Node-SID as index into A's SRGB. Similarly, Ld_c refers to the label derived for Node D, using D's Node-SID as index into C's SRGB.
Node A computes the route to Node D's loopback address. The next hops are Node B (via if_ab) and Node C (via if_ac). Node A uses Node D's Node-SID (which was advertised along with the loopback address) to index into its local SRGB to obtain a label value of 103 (Ld_a). Furthermore, Node A also uses Node D's Node-SID to derive label values for Node B and Node C, 103 (Ld_b) and 203 (Ld_c) respectively, using D's Node-SIDs as index into B and C' SRGBs respectively. Notice that Node C's SRGB is different from the other nodes. Node A can now program its label forwarding state with (Ld_a --> (via if_ab swap to Ld_b, via if_ac swap to Ld_c)).
Similarly, Node B computes the route to Node D's loopback address, but this time finds that the next hop is Node D itself (via if_bd). Node B will also use Node D's Node-SID (again, advertised with the loopback address) to index into its local SRGB and obtain a label value of 103 (Ld_b) and index into Node D's SRGB and obtain a label value of 103 (Ld_d). The label forwarding state can be programmed with (Ld_b --> via if_bd swap to Ld_d). Finally, Node D programs its label forwarding state with (Ld_d -> pop and lookup next header).
SR in RIFT (SRIFT)
In referring to the previous section, it is clear that each RIFT node participating in a SR domain requires the following information:
- SRGB values of all adjacent nodes
- Node-SID values of all nodes participating in the routing domain
- Loopback addresses or System IDs of all other nodes
In OSPF and IS-IS, each node's SR information is simply flooded. With RIFT, Node TIEs could be used to flood SR information, but each node would have to learn its own SR information first. With RIFT's Key-Value mechanism, KV-TIEs can be used for TOF nodes to flood all nodes' SR information that it learns from an SR controller, therefore accommodating both provisioning and signalling of SR. The non-TOF nodes do not need any SR related provisioning, which goes very well with RIFT's ZTP concept.
ToF nodes in an SR domain MUST populate KV South TIEs with the minimum required SR information for each node. Specifically SRGB Label Base, SRGB Label Range, Node-SID, RIFT System ID, and Loopback Address. While the Loopback Address must be included, it MAY be set to an empty value in cases if loopbacks are not configured for nodes.
Traffic forwarding in an SR network is typically done in two ways.
The first option is to use Prefix-SIDs and allow traffic to follow the shortest paths for the prefixes. Prefix-SIDs for node prefixes, i.e. Node-SIDs (for loopback addresses), can be used both for encapsulating service traffic to service nodes (e.g. VPN PEs) and for SR-TE traffic steering purposes (see below), but the benefits of other Prefix-SIDs are not clear, so currently only Node-SIDs are supported with RIFT.
The second option is to use SR-TE and follow a specific segment list in the packet header. Each node in the path steers the packet to the currently active segment in the list, following the natural path for that segment (see above). Since a node only has the full topology south of it, and a leaf node does not have any south topology, the traffic steering information (i.e. the segment list) must be programmed by controllers into ingress nodes via SR policies.
Support for Adjacency SIDs will be considered in future revisions.
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

Suppose the TE controller instructs Leaf11 to send a packet to Spine2_11 with label stack (Label_TOF2, Label_Spine2_21, Label_Leaf21). Spine2_11 recognizes 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 (that may appear in the segment list). That means for RIFT the southbound distance vector routing needs to additionally advertise routes for the nodes in the north, and they must be propagated all the way down. 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.
If loopback addresses are not used, similar "routes" for System IDs must be used. It is RECOMMENDED to use loopback addresses to reuse existing mechanisms.
SRIFT-Node Key-Type
This section requests an entry from the RIFT Key-Types Registry for RIFT networks that use SR along with suggested values in accordance with [I-D.ietf-rift-kv-tie-structure-and-processing].
Requested Entries
Name | Value | Description
SRIFT-Node | TBD | Key-Type describing a SRIFT node
SRIFT Node Key-Type

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      TBD      |      Key Identifier for a SRIFT Node          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     (System ID,                                               |
   |      Loopback Address,                                        |
   |      SRGB Label Base,                                         |
   |      SRGB Label Range,                                        |
   |      Node-SID)                                                |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

where:
- System ID:
A node's 64-bit RIFT System ID.
Loopback Address:
A node's loopback address. This MAY be set to 0 if loopback addresses are not used.
SRGB Label Base:
The first valid label within the corresponding node's SRGB.
SRGB Label Range:
The total number of valid labels in the corresponding node's SRGB.
Node-SID:
The corresponding node's Node-SID value.
The Key Identifier for a RIFT node is assigned by an orchestrator, which distributes the KVs to all ToF nodes. In the simplest scenario, the Key Identifier could be the SID index into the SRGB. The ToF nodes all have the same KVs learned from the orchestrator and distribute them southbound. A node may learn the same KV from multiple north nodes and the tie-breaking will lead to the same information to be selected and distributed further south.
Security Considerations
This document does not introduce any new security concerns with RIFT or any other referenced protocols. RIFT KV TIEs are already extensively secured via RIFT's specification.
Acknowledgements
The authors thank Bruno Rijsman and Antoni Przygenda for their review and suggestions.

Normative References

Informative References
[RFC2119]
[RFC8174]
[RFC8665]
[RFC8667]
[I-D.ietf-rift-kv-tie-structure-and-processing]