idnits 2.17.1 draft-zzhang-rift-sr-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The abstract seems to contain references ([RFC8402]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == There are 8 instances of lines with private range IPv4 addresses in the document. If these are generic example addresses, they should be changed to use any of the ranges defined in RFC 6890 (or successor): 192.0.2.x, 198.51.100.x or 203.0.113.x. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (November 4, 2019) is 1628 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'I-D.ietf-rift-rift' is defined on line 242, but no explicit reference was found in the text == Unused Reference: 'RFC2119' is defined on line 247, but no explicit reference was found in the text == Outdated reference: A later version (-21) exists of draft-ietf-rift-rift-08 Summary: 2 errors (**), 0 flaws (~~), 6 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 RIFT Z. Zhang 3 Internet-Draft Juniper Networks 4 Intended status: Standards Track J. Tantsura 5 Expires: May 7, 2020 Apstra, Inc 6 D. Fedyk 7 Individual 8 November 4, 2019 10 SRIFT: Segment Routing In Fat Trees 11 draft-zzhang-rift-sr-02 13 Abstract 15 This document specifies signaling procedures for Segment Routing 16 [RFC8402] with RIFT. Each node's loopback address, Segment Routing 17 Global Block (SRGB) and Node Segment Identifier (SID), which must be 18 unique within the SR domain and are typically assigned by SR 19 controllers or management, are distributed southbound from the Top Of 20 Fabric (TOF) nodes via the Key-Value distribution mechanism, so that 21 each node can compute how to reach a node represented by the topmost 22 Node SIDs . For an ingress node to send SR traffic to another node 23 via an explicit path, an SR controller signals the corresponding 24 label stack to the ingress node so that the ingress node can send 25 packets accordingly. 27 Requirements Language 29 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 30 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 31 document are to be interpreted as described in RFC2119. 33 Status of This Memo 35 This Internet-Draft is submitted in full conformance with the 36 provisions of BCP 78 and BCP 79. 38 Internet-Drafts are working documents of the Internet Engineering 39 Task Force (IETF). Note that other groups may also distribute 40 working documents as Internet-Drafts. The list of current Internet- 41 Drafts is at https://datatracker.ietf.org/drafts/current/. 43 Internet-Drafts are draft documents valid for a maximum of six months 44 and may be updated, replaced, or obsoleted by other documents at any 45 time. It is inappropriate to use Internet-Drafts as reference 46 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on May 7, 2020. 50 Copyright Notice 52 Copyright (c) 2019 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (https://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the Simplified BSD License. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 68 2. Specifications . . . . . . . . . . . . . . . . . . . . . . . 5 69 3. Security Considerations . . . . . . . . . . . . . . . . . . . 5 70 4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 71 5. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 72 5.1. Normative References . . . . . . . . . . . . . . . . . . 6 73 5.2. Informative References . . . . . . . . . . . . . . . . . 6 74 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6 76 1. Introduction 78 Before we discuss the SR procedures for RIFT, let us first review how 79 SR works with OSPF/ISIS [I-D.ietf-ospf-segment-routing-extensions] 80 [I-D.ietf-isis-segment-routing-extensions]. 82 Each node is provisioned with a loopback address, an SRGB, and a Node 83 SID. The loopback address and Node SID are co-ordinated centrally - 84 it is unique for each node across the SR network - and then 85 communicated out of band to each node and stored as configuration 86 information. For example, the out of band communication could be via 87 primitive pen and paper, or modern signaling from controllers. 89 SRGB configuration can be local to each node and different node can 90 have the same or different label blocks for flexible label 91 allocation. Typically, modern SR networks have identical SRGB on 92 each node so that a Node SID corresponds to the same label on each 93 node. However that is not mandatory. Either way, the SRGB is part 94 of the node's local configuration. In today's network it is very 95 likely pushed down from some controllers. 97 Each node will then signal its SRGB, and its Node SID. The Node SID 98 is just an index into the SRGB and other nodes will derive the 99 corresponding label for each advertised Node SID. Consider the 100 following example: 102 B 103 * * 104 * * 105 * * 106 A D 107 * * 108 * * 109 * * 110 C 112 Node Name Loopback Node SID SRGB Label Base SRGB Label Range 113 --------- -------- -------- --------------- ---------------- 115 A 10.1.1.1 1 100 50 116 B 10.1.1.2 2 100 50 117 C 10.1.1.3 3 200 50 118 D 10.1.1.4 4 100 50 120 Node A computes its IP and label routes as following: 122 Destination Next Hop 123 ----------- -------- 124 10.1.1.1 local 125 10.1.1.2 if_ab 126 10.1.1.3 if_ac 127 10.1.1.4 if_ab, if_ac 129 Label Next Hop 130 ----- -------- 132 100 (La_a) pop and look up next header 133 101 (Lb_a) swap to 101, send out of if_ab 134 102 (Lc_a) swap to 202, send out of if_ac 135 103 (Ld_a) swap to 103, send out of if_ab 136 swap to 203, send out of if_ac 138 For example, Node A computes the route to node D (represented by its 139 loopback address) and the next hops are node B via interface if_ab 140 and node C via if_ac. A uses D's Node SID (advertised along with D's 141 loopback address), and index it into its own SRGB to obtain label 142 Ld_a (103). It also uses D's Node SID to index into B's and C's 143 SRGBs to obtain label Ld_b (103) and Ld_c (203) respectively. Now it 144 programs its label forwarding state with (Ld_a --> (outgoing if_ab 145 swap to Ld_b, outgoing if_ac swap to Ld_c)). Notice that Ld_a, Ld_b 146 and Ld_c are most likely the same though not necessarily so. 148 Node B computes the route to D and finds that the next hop is node D 149 itself via interface if_bd. It use D's Node SID (advertised along 150 with D's loopback address) and index it into its own SRGB and obtain 151 label Ld_b (103). It also uses the SID and index it into D's SRGB to 152 obtain label Ld_d (103). Now it programs its label forwarding state 153 with (Ld_b->outgoing if_bd swap to label Ld_d). 155 Similarly, D programs a label forwarding state (Ld_d->pop and lookup 156 next header). 158 It is clear that the following needs to happen: 160 o Each node's SRGB needs to be signalled to all other adjacent nodes 162 o Each node's Node SID needs to be signalled to all other nodes 164 o Each node's loopback address needs to be signalled to all other 165 nodes 167 With ISIS/OSPF, each node's SRGB is actually flooded everywhere for 168 simplicity. With RIFT, North TIEs are flooded all the way north but 169 South TIEs are only flooded one hop south (and then reflected one hop 170 north). While the Node TIEs could be used to flood SRGBs, each node 171 would need to learn its own SRGB first. With RIFT ZTP, the TOF nodes 172 learn the SRGB and Node SID provisioning for every node (from SR 173 controllers) and flood them southbound via K-V distribution - there 174 is no need to flood SRGB via Node TIEs any more.. 176 With ISIS/OSPF, a node steer packets in two ways. One is using 177 Prefix SIDs - following shortest paths calculated by local SPFs. 178 Because RIFT's principal is not to keep specific routes on a node to 179 all destinations that are not south of the node, using Prefix SIDs is 180 not applicable to RIFT, as it does not provide any SR benefit. 182 The other is using SR-TE - following explicit paths specified in a 183 segment list in the packet header. In case of SR-TE with MPLS, a 184 label stack is used - each entry in the stack represents a node on 185 the TE path towards the destination. This can be used for RIFT, as 186 long as controllers provide SR policies to leaf nodes to steer 187 traffic. Leaf nodes themselves won't be able to calculate explicit 188 paths as they don't have the full topology. . 190 Consider the following 4-level topology: 192 TOF1 TOF2 194 Spine1_11 Spine1_21 Spine1_21 Spine1_22 196 Spine2_11 Spine2_21 Spine2_21 Spine2_22 198 Leaf11 Leaf12 Leaf21 Leaf22 200 Say the TE controller instructs Leaf11 to send a packet to Spine2_11 201 with label stack (Label_TOF2, Label_Spine2_21, Label_Leaf21). 202 Spine2_11 needs to recognize that Label_TOF2 maps to node TOF2 and it 203 should not simply follow the default route (because the default route 204 could lead to an unintended path via TOF1). In other words, each 205 node needs to have a specific route to every node in the north. That 206 means for RIFT that the southbound distance vector routing needs to 207 additionally advertise routes for loopback address of the nodes in 208 the north. Each node originates a route for its own loopback address 209 and advertises it southbound, with a special marking that allows a 210 south node to re-advertise it further south. 212 As an alternative, routes for loopback addresses may be replaced by 213 "routes" for SystemIDs. This is for further study in future 214 revisions. 216 Considerations for Prefix SIDs will be provided in future revisions. 218 2. Specifications 220 This document defines the following Key-Value for SR purpose, in the 221 form of (key type, key value, value). The key type is SR, The key 222 value is the loopback address, and the value is a (SRGB label base, 223 SRGB label range, Node SID) tuple. This also assumes that each node 224 learns its own loopback address somehow, probably through another KV 225 (given the ZTP consideration). 227 More details will be specified in future revisions. 229 3. Security Considerations 231 To be provided. 233 4. Acknowledgements 235 The authors thank Bruno Rijsman and Antoni Przygenda for their review 236 and suggestions. 238 5. References 240 5.1. Normative References 242 [I-D.ietf-rift-rift] 243 Przygienda, T., Sharma, A., Thubert, P., and D. Afanasiev, 244 "RIFT: Routing in Fat Trees", draft-ietf-rift-rift-08 245 (work in progress), September 2019. 247 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 248 Requirement Levels", BCP 14, RFC 2119, 249 DOI 10.17487/RFC2119, March 1997, 250 . 252 5.2. Informative References 254 [I-D.ietf-isis-segment-routing-extensions] 255 Previdi, S., Ginsberg, L., Filsfils, C., Bashandy, A., 256 Gredler, H., and B. Decraene, "IS-IS Extensions for 257 Segment Routing", draft-ietf-isis-segment-routing- 258 extensions-25 (work in progress), May 2019. 260 [I-D.ietf-ospf-segment-routing-extensions] 261 Psenak, P., Previdi, S., Filsfils, C., Gredler, H., 262 Shakir, R., Henderickx, W., and J. Tantsura, "OSPF 263 Extensions for Segment Routing", draft-ietf-ospf-segment- 264 routing-extensions-27 (work in progress), December 2018. 266 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 267 Decraene, B., Litkowski, S., and R. Shakir, "Segment 268 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 269 July 2018, . 271 Authors' Addresses 273 Zhaohui Zhang 274 Juniper Networks 276 EMail: zzhang@juniper.net 277 Jeff Tantsura 278 Apstra, Inc 280 EMail: jefftant.ietf@gmail.com 282 Don Fedyk 283 Individual 285 EMail: don.fedyk@gmail.com