idnits 2.17.1 draft-zzhang-rift-sr-00.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 (October 22, 2018) is 1985 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 230, but no explicit reference was found in the text == Unused Reference: 'RFC2119' is defined on line 234, but no explicit reference was found in the text == Outdated reference: A later version (-20) exists of draft-ietf-rift-rift-03 == Outdated reference: A later version (-25) exists of draft-ietf-isis-segment-routing-extensions-19 == Outdated reference: A later version (-27) exists of draft-ietf-ospf-segment-routing-extensions-25 Summary: 2 errors (**), 0 flaws (~~), 8 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: April 25, 2019 Apstra, Inc 6 D. Fedyk 7 HPE 8 October 22, 2018 10 SRIFT: Segment Routing In Fat Trees 11 draft-zzhang-rift-sr-00 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 April 25, 2019. 50 Copyright Notice 52 Copyright (c) 2018 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 . . . . . . . . . . . . . . . . . . . . . . 5 71 5. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 72 5.1. Normative References . . . . . . . . . . . . . . . . . . 5 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 For the purpose of SR-TE, a label stack is used - each entry in the 177 stack represents a node on the TE path towards the destination. 178 Consider the following 4-level topology: 180 TOF1 TOF2 182 Spine1_11 Spine1_21 Spine1_21 Spine1_22 184 Spine2_11 Spine2_21 Spine2_21 Spine2_22 186 Leaf11 Leaf12 Leaf21 Leaf22 188 Say the TE controller instructs Leaf11 to send a packet to Spine2_11 189 with label stack (Label_TOF2, Label_Spine2_21, Label_Leaf21). 190 Spine2_11 needs to recognize that Label_TOF2 maps to node TOF2 and it 191 should not simply follow the default route (because the default route 192 could lead to an unintended path via TOF1). In other words, each 193 node needs to have a specific route to every node in the north. That 194 means for RIFT that the southbound distance vector routing needs to 195 additionally advertise routes for loopback address of the nodes in 196 the north. Each node originates a route for its own loopback address 197 and advertises it southbound, with a special marking that allows a 198 south node to re-advertise it further south. 200 As an alternative, routes for loopback addresses may be replaced by 201 "routes" for SystemIDs. This is for further study in future 202 revisions. 204 Considerations for Prefix SIDs will be provided in future revisions. 206 2. Specifications 208 This document defines the following Key-Value for SR purpose, in the 209 form of (key type, key value, value). The key type is SR, The key 210 value is the loopback address, and the value is a (SRGB label base, 211 SRGB label range, Node SID) tuple. This also assumes that each node 212 learns its own loopback address somehow, probably through another KV 213 (given the ZTP consideration). 215 More details will be specified in future revisions. 217 3. Security Considerations 219 To be provided. 221 4. Acknowledgements 223 The authors thank Bruno Rijsman and Antoni Przygenda for their review 224 and suggestions. 226 5. References 228 5.1. Normative References 230 [I-D.ietf-rift-rift] 231 Team, T., "RIFT: Routing in Fat Trees", draft-ietf-rift- 232 rift-03 (work in progress), October 2018. 234 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 235 Requirement Levels", BCP 14, RFC 2119, 236 DOI 10.17487/RFC2119, March 1997, 237 . 239 5.2. Informative References 241 [I-D.ietf-isis-segment-routing-extensions] 242 Previdi, S., Ginsberg, L., Filsfils, C., Bashandy, A., 243 Gredler, H., Litkowski, S., Decraene, B., and J. Tantsura, 244 "IS-IS Extensions for Segment Routing", draft-ietf-isis- 245 segment-routing-extensions-19 (work in progress), July 246 2018. 248 [I-D.ietf-ospf-segment-routing-extensions] 249 Psenak, P., Previdi, S., Filsfils, C., Gredler, H., 250 Shakir, R., Henderickx, W., and J. Tantsura, "OSPF 251 Extensions for Segment Routing", draft-ietf-ospf-segment- 252 routing-extensions-25 (work in progress), April 2018. 254 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 255 Decraene, B., Litkowski, S., and R. Shakir, "Segment 256 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 257 July 2018, . 259 Authors' Addresses 261 Zhaohui Zhang 262 Juniper Networks 264 EMail: zzhang@juniper.net 266 Jeff Tantsura 267 Apstra, Inc 269 EMail: jefftant.ietf@gmail.com 271 Don Fedyk 272 HPE 274 EMail: don.fedyk@hpe.com