RIFT Z. Zhang Internet-Draft Juniper Networks Intended status: Standards Track J. Tantsura Expires: April 25, 2019 Apstra, Inc D. Fedyk HPE October 22, 2018 SRIFT: Segment Routing In Fat Trees draft-zzhang-rift-sr-00 Abstract 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", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 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 April 25, 2019. Zhang, et al. Expires April 25, 2019 [Page 1] Internet-Draft srift October 2018 Copyright Notice Copyright (c) 2018 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 . . . . . . . . . . . . . . . . . . . . . . 5 5. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 5.1. Normative References . . . . . . . . . . . . . . . . . . 5 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] [I-D.ietf-isis-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 April 25, 2019 [Page 2] Internet-Draft srift October 2018 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: 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 Node A computes its IP and label routes as following: 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, 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 April 25, 2019 [Page 3] Internet-Draft srift October 2018 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 nodes 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.. For the purpose of SR-TE, a label stack is used - each entry in the stack represents a node on the TE path towards the destination. 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 Zhang, et al. Expires April 25, 2019 [Page 4] Internet-Draft srift October 2018 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 revisions. 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. 4. Acknowledgements The authors thank Bruno Rijsman and Antoni Przygenda for their review and suggestions. 5. References 5.1. Normative References [I-D.ietf-rift-rift] Team, T., "RIFT: Routing in Fat Trees", draft-ietf-rift- rift-03 (work in progress), October 2018. Zhang, et al. Expires April 25, 2019 [Page 5] Internet-Draft srift October 2018 [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 [I-D.ietf-isis-segment-routing-extensions] Previdi, S., Ginsberg, L., Filsfils, C., Bashandy, A., Gredler, H., Litkowski, S., Decraene, B., and J. Tantsura, "IS-IS Extensions for Segment Routing", draft-ietf-isis- segment-routing-extensions-19 (work in progress), July 2018. [I-D.ietf-ospf-segment-routing-extensions] 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-25 (work in progress), April 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, . Authors' Addresses Zhaohui Zhang Juniper Networks EMail: zzhang@juniper.net Jeff Tantsura Apstra, Inc EMail: jefftant.ietf@gmail.com Don Fedyk HPE EMail: don.fedyk@hpe.com Zhang, et al. Expires April 25, 2019 [Page 6]