idnits 2.17.1 draft-zzhang-rift-sr-04.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.) == 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 date (26 May 2022) is 672 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: 'RFC2119' is defined on line 298, but no explicit reference was found in the text == Unused Reference: 'RFC8402' is defined on line 303, but no explicit reference was found in the text == Unused Reference: 'RIFT' is defined on line 308, but no explicit reference was found in the text == Outdated reference: A later version (-20) exists of draft-ietf-rift-rift-12 Summary: 1 error (**), 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 J. Tantsura 4 Intended status: Standards Track J. Head 5 Expires: 27 November 2022 Juniper Networks 6 D. Fedyk 7 Individual 8 26 May 2022 10 SRIFT: Segment Routing in Fat Trees 11 draft-zzhang-rift-sr-04 13 Abstract 15 This document specifies signaling procedures for Segment Routing in 16 RIFT. Each node's loopback address, Segment Routing Global Block 17 (SRGB) and Node Segment Identifier (Node-SID), which are typically 18 assigned by a configuration management system and distibuted by 19 routing protocols, are distributed southbound from the Top Of Fabric 20 (TOF) nodes via RIFT's Key-Value distribution mechanism, so that each 21 node can compute how to reach a segment represented by the active SID 22 in a packet. An SR controller signals SR policies to ingress nodes 23 so that they can send packets with a desired segment list to steer 24 traffic. 26 Requirements Language 28 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 29 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 30 document are to be interpreted as described in RFC2119. 32 Status of This Memo 34 This Internet-Draft is submitted in full conformance with the 35 provisions of BCP 78 and BCP 79. 37 Internet-Drafts are working documents of the Internet Engineering 38 Task Force (IETF). Note that other groups may also distribute 39 working documents as Internet-Drafts. The list of current Internet- 40 Drafts is at https://datatracker.ietf.org/drafts/current/. 42 Internet-Drafts are draft documents valid for a maximum of six months 43 and may be updated, replaced, or obsoleted by other documents at any 44 time. It is inappropriate to use Internet-Drafts as reference 45 material or to cite them other than as "work in progress." 47 This Internet-Draft will expire on 27 November 2022. 49 Copyright Notice 51 Copyright (c) 2022 IETF Trust and the persons identified as the 52 document authors. All rights reserved. 54 This document is subject to BCP 78 and the IETF Trust's Legal 55 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 56 license-info) in effect on the date of publication of this document. 57 Please review these documents carefully, as they describe your rights 58 and restrictions with respect to this document. Code Components 59 extracted from this document must include Revised BSD License text as 60 described in Section 4.e of the Trust Legal Provisions and are 61 provided without warranty as described in the Revised BSD License. 63 Table of Contents 65 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 66 2. SR in RIFT (SRIFT) . . . . . . . . . . . . . . . . . . . . . 4 67 3. Well-Known KV Registry Values . . . . . . . . . . . . . . . . 6 68 3.1. SRIFT Node Key-Type . . . . . . . . . . . . . . . . . . . 6 69 4. Security Considerations . . . . . . . . . . . . . . . . . . . 7 70 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 71 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 72 6.1. Normative References . . . . . . . . . . . . . . . . . . 7 73 6.2. Informative References . . . . . . . . . . . . . . . . . 8 74 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 76 1. Introduction 78 Before we discuss the SR procedures for RIFT, let us first review how 79 SR works with OSPF [RFC8665] and IS-IS [RFC8667]. 81 Each node is provisioned with a loopback address as well as SRGB and 82 Node-SID values. The loopback address and Node-SID are centrally 83 coordinated and are unique per-node within the SR network. These 84 values are then communicated to each node out-of-band and stored as 85 configuration information. Communication could be done via primitive 86 pen and paper or via modern signaling (Netconf/YANG) from a 87 configuration management system. 89 SRGB information represents the label range of the "global" labels 90 that can be allocated on a particular node for SR. SRGB could have 91 more than one contiguous range of labeks allocated to it. It is 92 comprised of the first available label value and the total number of 93 available labels per range. While in modern networks it is common 94 for each node to have identical SRGB values so that a Node-SID will 95 correspond to the same label on each node, this is not required as to 96 allow for flexible label allocation. In either scenario, SRGB is 97 part of each node's configuration. In today's networks, it is likely 98 pushed to nodes by a configuration management system. 100 Each node then signals its SRGB and Node-SID to the other nodes. A 101 Node-SID is an index value assigned to a node (say node X), and 102 another node (say node Y) uses the Node-SID to derive (from Y's SRGB) 103 the label to use when sending traffic to node X. 105 Consider the following example illustrating Node A's computed IP 106 route and label values. 108 B 109 * * 110 * * 111 * * 112 A D 113 * * 114 * * 115 * * 116 C 118 Node Name Loopback Node SID SRGB Label Base SRGB Label Range 119 --------- -------- -------- --------------- ---------------- 121 A 10.1.1.1 1 100 50 122 B 10.1.1.2 2 100 50 123 C 10.1.1.3 3 200 50 124 D 10.1.1.4 4 100 50 125 Destination Next Hop 126 ----------- -------- 127 10.1.1.1 local 128 10.1.1.2 if_ab 129 10.1.1.3 if_ac 130 10.1.1.4 if_ab, if_ac 132 Label Next Hop 133 ----- -------- 134 100 (La_a) pop and look up next header 135 101 (Lb_a) swap to 101 (Lb_b), via if_ab 136 102 (Lc_a) swap to 202 (Lc_c), via if_ac 137 103 (Ld_a) swap to 103 (Ld_b), via if_ab 138 swap to 203 (Ld_c), via if_ac 140 The specific notation Lb_a refers to the label derived for node B, 141 using B's Node-SID as index into A's SRGB. Similarly, Ld_c refers to 142 the label derived for Node D, using D's Node-SID as index into C's 143 SRGB. 145 Node A computes the route to Node D's loopback address. The next 146 hops are Node B (via if_ab) and Node C (via if_ac). Node A uses Node 147 D's Node-SID (which was advertised along with the loopback address) 148 to index into its local SRGB to obtain a label value of 103 (Ld_a). 149 Furthermore, Node A also uses Node D's Node-SID to derive label 150 values for Node B and Node C, 103 (Ld_b) and 203 (Ld_c) respectively, 151 using D's Node-SIDs as index into B and C' SRGBs respectively. 152 Notice that Node C's SRGB is different from the other nodes. Node A 153 can now program its label forwarding state with (Ld_a --> (via if_ab 154 swap to Ld_b, via if_ac swap to Ld_c)). 156 Similarly, Node B computes the route to Node D's loopback address, 157 but this time finds that the next hop is Node D itself (via if_bd). 158 Node B will also use Node D's Node-SID (again, advertised with the 159 loopback address) to index into its local SRGB and obtain a label 160 value of 103 (Ld_b) and index into Node D's SRGB and obtain a label 161 value of 103 (Ld_d). The label forwarding state can be programmed 162 with (Ld_b --> via if_bd swap to Ld_d). Finally, Node D programs its 163 label forwarding state with (Ld_d -> pop and lookup next header). 165 2. SR in RIFT (SRIFT) 167 In referring to the previous section, it is clear that each RIFT node 168 participating in a SR domain requires the following information: 170 * SRGB values of all adjacent nodes 171 * Node-SID values of all nodes participating in the routing domain 173 * Loopback addresses or System IDs of all other nodes 175 In OSPF and IS-IS, each node's SR information is simply flooded. 176 With RIFT, Node TIEs could be used to flood SR information, but each 177 node would have to learn its own SR information first. With RIFT's 178 Key-Value mechanism, KV-TIEs can be used for TOF nodes to flood all 179 nodes' SR information that it learns from an SR controller, therefore 180 accommodating both provisioning and signalling of SR. The non-TOF 181 nodes do not need any SR related provisioning, which goes very well 182 with RIFT's ZTP concept. 184 ToF nodes in an SR domain MUST populate KV South TIEs with the 185 minimum required SR information for each node. Specifically SRGB 186 Label Base, SRGB Label Range, Node-SID, RIFT System ID, and Loopback 187 Address. While the Loopback Address must be included, it MAY be set 188 to an empty value in cases if loopbacks are not configured for nodes. 190 Traffic forwarding in an SR network is typically done in two ways. 192 The first option is to use Prefix-SIDs and allow traffic to follow 193 the shortest paths for the prefixes. Prefix-SIDs for node prefixes, 194 i.e. Node-SIDs (for loopback addresses), can be used both for 195 encapsulating service traffic to service nodes (e.g. VPN PEs) and 196 for SR-TE traffic steering purposes (see below), but the benefits of 197 other Prefix-SIDs are not clear, so currently only Node-SIDs are 198 supported with RIFT. 200 The second option is to use SR-TE and follow a specific segment list 201 in the packet header. Each node in the path steers the packet to the 202 currently active segment in the list, following the natural path for 203 that segment (see above). Since a node only has the full topology 204 south of it, and a leaf node does not have any south topology, the 205 traffic steering information (i.e. the segment list) must be 206 programmed by controllers into ingress nodes via SR policies. 208 Support for Adjacency SIDs will be considered in future revisions. 210 Consider the following 4-level topology: 212 ToF1 ToF2 214 Spine1_11 Spine1_21 | Spine1_21 Spine1_22 215 | 216 Spine2_11 Spine2_21 | Spine2_21 Spine2_22 217 | 218 Leaf11 Leaf12 | Leaf21 Leaf22 220 Suppose the TE controller instructs Leaf11 to send a packet to 221 Spine2_11 with label stack (Label_TOF2, Label_Spine2_21, 222 Label_Leaf21). Spine2_11 recognizes that Label_TOF2 maps to node 223 TOF2 and it should not simply follow the default route (because the 224 default route could lead to an unintended path via TOF1). In other 225 words, each node needs to have a specific route to every node (that 226 may appear in the segment list). That means for RIFT the southbound 227 distance vector routing needs to additionally advertise routes for 228 the nodes in the north, and they must be propagated all the way down. 229 Each node originates a route for its own loopback address and 230 advertises it southbound, with a special marking that allows a south 231 node to re-advertise it further south. 233 If loopback addresses are not used, similar "routes" for System IDs 234 must be used. It is RECOMMENDED to use loopback addresses to reuse 235 existing mechanisms. 237 3. Well-Known KV Registry Values 239 This section requests an entry from the RIFT Well-Known Key-Type 240 Registry for networks that use SR along with suggested values in 241 accordance with RIFT-KV-REGISTRY [RIFT-KV-REGISTRY]. 243 +============+=======+==================================+ 244 | Name | Value | Description | 245 +============+=======+==================================+ 246 | SRIFT Node | TBD | Key-Type describing a SRIFT node | 247 +------------+-------+----------------------------------+ 249 Table 1: Requested Entries 251 3.1. SRIFT Node Key-Type 252 0 1 2 3 253 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 254 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 255 | TBD2 | SRIFT Node | 256 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 257 | (System ID, | 258 | Loopback Address, | 259 | SRGB Label Base, | 260 | SRGB Label Range, | 261 | Node-SID,) | 262 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 264 where: 266 System ID: 267 A node's 64-bit RIFT System ID. 269 Loopback Address: 270 A node's loopback address. This MAY be set to 0 if loopback 271 addresses are not used. 273 SRGB Label Base: 274 The first valid label within the corresponding node's SRGB. 276 SRGB Label Range: 277 The total number of valid labels in the corresponding node's 278 SRGB. 280 Node-SID: 281 The corresponding node's Node-SID value. 283 4. Security Considerations 285 This document does not introduce any new security concerns with RIFT 286 or any other referenced protocols. RIFT KV TIEs are already 287 extensively secured via RIFT's specification. 289 5. Acknowledgements 291 The authors thank Bruno Rijsman and Antoni Przygenda for their review 292 and suggestions. 294 6. References 296 6.1. Normative References 298 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 299 Requirement Levels", BCP 14, RFC 2119, 300 DOI 10.17487/RFC2119, March 1997, 301 . 303 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 304 Decraene, B., Litkowski, S., and R. Shakir, "Segment 305 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 306 July 2018, . 308 [RIFT] Przygienda, T., Sharma, A., Thubert, P., Rijsman, B., and 309 D. Afanasiev, "RIFT: Routing in Fat Trees", Work in 310 Progress, draft-ietf-rift-rift-12, May 2020. 312 [RIFT-KV-REGISTRY] 313 Przygienda, T., "RIFT Keys Structure and Well-Known 314 Registry in Key Value TIE", Work in Progress, draft- 315 przygienda-rift-kv-registry-00, December 2020. 317 6.2. Informative References 319 [RFC8665] Psenak, P., Ed., Previdi, S., Ed., Filsfils, C., Gredler, 320 H., Shakir, R., Henderickx, W., and J. Tantsura, "OSPF 321 Extensions for Segment Routing", RFC 8665, 322 DOI 10.17487/RFC8665, December 2019, 323 . 325 [RFC8667] Previdi, S., Ed., Ginsberg, L., Ed., Filsfils, C., 326 Bashandy, A., Gredler, H., and B. Decraene, "IS-IS 327 Extensions for Segment Routing", RFC 8667, 328 DOI 10.17487/RFC8667, December 2019, 329 . 331 Authors' Addresses 333 Zhaohui Zhang 334 Juniper Networks 336 Email: zzhang@juniper.net 338 Jeff Tantsura 339 Juniper Networks 341 Email: jefftant.ietf@gmail.com 342 Jordan Head 343 Juniper Networks 345 Email: jhead@juniper.net 347 Don Fedyk 348 Individual 350 Email: don.fedyk@gmail.com