idnits 2.17.1 draft-zwx-rift-leaf-ring-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 : ---------------------------------------------------------------------------- == There are 2 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 148 has weird spacing: '...+--xxxx xxxx...' == Line 152 has weird spacing: '...Network x...' == Line 156 has weird spacing: '...+--xxxx xxxx...' -- The document date (7 July 2021) is 1025 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: 'RFC7991' is defined on line 310, but no explicit reference was found in the text Summary: 0 errors (**), 0 flaws (~~), 6 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force Z. Zhang 3 Internet-Draft Y. Wei 4 Intended status: Standards Track B. Xu 5 Expires: 8 January 2022 ZTE Corporation 6 7 July 2021 8 Supporting leaves without northbound neighbors connecting to a fat-tree 9 network using RIFT 10 draft-zwx-rift-leaf-ring-00 12 Abstract 14 This document discusses the usage and solution for leaf nodes without 15 northbound neighbors connecting to a fat-tree network by leaf nodes 16 having direct northbound neighbors in RIFT. 18 Status of This Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at https://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on 8 January 2022. 35 Copyright Notice 37 Copyright (c) 2021 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 42 license-info) in effect on the date of publication of this document. 43 Please review these documents carefully, as they describe your rights 44 and restrictions with respect to this document. Code Components 45 extracted from this document must include Simplified BSD License text 46 as described in Section 4.e of the Trust Legal Provisions and are 47 provided without warranty as described in the Simplified BSD License. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 52 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 2 53 2. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 2 54 3. Solution . . . . . . . . . . . . . . . . . . . . . . . . . . 6 55 3.1. Capability advertisement . . . . . . . . . . . . . . . . 6 56 3.2. Prefix transferring . . . . . . . . . . . . . . . . . . . 6 57 3.3. Example . . . . . . . . . . . . . . . . . . . . . . . . . 7 58 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 59 5. Security Considerations . . . . . . . . . . . . . . . . . . . 7 60 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 61 6.1. Normative References . . . . . . . . . . . . . . . . . . 7 62 6.2. Informative References . . . . . . . . . . . . . . . . . 7 63 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 65 1. Introduction 67 [I-D.ietf-rift-rift] specifies a dynamic routing protocol for Clos 68 and fat-tree network topology. It suits most of the deployments. In 69 some situations, the leaves are connected by ring or chain topology, 70 and some of them may have no northbound link, so these nodes may not 71 be able to connecting the network. This document discusses the usage 72 and proposes a solution. 74 1.1. Requirements Language 76 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 77 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 78 document are to be interpreted as described in RFC 2119 [RFC2119]. 80 2. Problem Statement 82 [I-D.ietf-rift-rift] specifies a dynamic routing protocol for Clos 83 and fat-tree network topology. The leaf part of a traditional Clos 84 and fat-tree network topology is shown as: 86 + + + 87 | N1 | N2 | N3 88 | | | 89 +--+----+ +--+----+ +--+-----+ 90 | | | | | | 91 | S01 +----------+ S02 +----------+ S03 | Level 1 92 ++-+-+--+ ++--+--++ +---+-+-++ 93 | | | | | | | | | 94 | | +----------------------------------+ | | | 95 | | | | | | | | | 96 | +-------------+ | | | +--------------+ | 97 | | | | | | | | | 98 | +----------------+ | +-----------------+ | 99 | | | | | | | | | 100 | | +------------------------------------+ | | 101 | | | | | | | | | 102 ++-+-+--+ | +---+---+ | +-+---+-++ 103 | | +-+ +-+ | | 104 | L01 |----------| L02 |----------| L03 | Level 0 105 +-------+ +-------+ +--------+ 107 Figure 1 109 In most of the cases, each leaf node has north connections with at 110 least one spine, and there may be east-west links between leaf nodes. 111 In case a leaf node lost all the north connections, it can still 112 access the network through the east-west link between leaves. For 113 example in Figure 1, there is an east-west link between L01 and L02, 114 and there is an east-west link between L02 and L03. When the 115 northbound connections for the leaves are all work well, L01, L02 and 116 L03 may generate a Prefix South TIE with default route and advertise 117 it through the east-west links according to the definition in section 118 4.2.3.4 in [I-D.ietf-rift-rift]. In case L01 lost all the northbound 119 links with S01, S02 and S03, according to Northbound SPF algorithm 120 defined in section 4.2.4.1 in [I-D.ietf-rift-rift], L01 can compute 121 the next hop L02 for the default route. On the other hand, the 122 prefix of L01 can be flood northbound by L02. Then L01 can still 123 access the network through the east-west link between L01 and L02. 125 But in some deployments, the leaves may connect with each other by 126 ring topology (sometimes, a chain topology), and not all of them have 127 northbound connection with spine nodes. 129 For example, in the IP Radio Access Network (IP RAN, mobile backhaul 130 network), the 4G eNB or the 5G gNB connect to an IP access network of 131 a ring topology. The access network attaches to an aggregation 132 network through two aggregation nodes. In 5G era, the aggregation 133 network and the metro network is envolving to Spine-and-Leaf 134 architecture to take the advantage of Spine-and-Leaf. Figure 2 135 depicts an digram of an IPRAN network with Spine-and-Leaf 136 architecture. If the aggregation network runs RIFT, using the 137 proposal of this draft, the access network ring does not need to 138 deploy other IGP protocol to enable the routing. 140 +----+ 141 |gNB | 142 +--+-+ 143 | 144 +--+-+ 145 +-----+CSG4+---- --+ 146 | +----+ | Aggregation 147 +---+ +--+-+ +-+--+ Network +-----+ xxxxx 148 |eNB+---+CSG1| | +-----------+Spine+--xxxx xxxx 149 +---+ +--+-+ |Leaf| +----++ xxx 150 | | | | xx 151 | +----+------------+ | x 152 | Access Network | | Metro Network x 153 | +----+------------+---+ x 154 | | | | xx 155 +---+ +--+-+ |Leaf| ++----+ xxx 156 |gNB+---+CSG2| | +-----------+Spine+--xxxx xxxx 157 +---+ +--+-+ +-+--+ +-----+ xxxxx 158 | +----+ | 159 +-----+CSG3+---- --+ 160 +--+-+ 161 | 162 +--+-+ 163 |eBN | 164 +----+ 166 Figure 2: IPRAN network with Spine-and-Leaf architecture 167 + + + 168 | N1 | N2 | N3 169 | | | 170 +--+----+ +--+----+ +--+-----+ 171 | | | | | | 172 | S01 +----------+ S02 +----------+ S03 | Level 1 173 ++-+-+--+ ++--+--++ +---+-+-++ 174 | | | | | | | | | 175 | | +----------------------------------+ | | | 176 | | | | | | | | | 177 | +-------------+ | | | +--------------+ | 178 | | | | | | | | | 179 | +----------------+ | +-----------------+ | 180 | | | | | | | | | 181 | | +------------------------------------+ | | 182 | | | | | | | | | 183 ++-+-+--+ | +---+---+ | +-+---+-++ 184 | | +-+ +-+ | | 185 +--| L01 |--------- | L02 |----------| L03 |--+ 186 | +-------+ +-------+ +--------+ | 187 | | 188 | | Level 0 189 | ++-+-+--+ ++-+-+--+ ++-+-+--+ | 190 | | | | | | | | 191 +--| L04 |---------| L05 |-----------| L06 |---+ 192 +-------+ +-------+ +-------+ 194 Figure 3 196 Figure 3 is an abstract of Figure 2, several leaves connect to the 197 fat-tree network by ring topology, each leaf has two east-west 198 connections with other leaves, but only L01, L02 and L03 have 199 northbound connection with spine nodes. L01, L02 and L03 advertise a 200 Prefix South TIE with default route through the east-west links. L04 201 and L06 can access the network through L01 and L03. But L04 and L06 202 do not generate or flood the Prefix South TIE with default route 203 because they have no northbound link. So L05 cannot receive the 204 Prefix South TIE with default route through the link between L04 and 205 L05, or the link between L05 and L06. On the other hand, the prefix 206 of L05 cannot be flooded east-west by L04 and L05. So L05 cannot 207 send flow to other leaf, and other leaf cannot send flow to L05 also. 208 L05 cannot access the network. 210 This document discuss the extension that can be used to solve the 211 problem when some leaves without northbound neighbors connecting to a 212 fat-tree network. 214 3. Solution 216 3.1. Capability advertisement 218 A new link capability which is named leaf-transport is set in LIE and 219 node TIE. The new capability indicates that the leaf node can 220 transfer the Prefix TIE received from the east-west link to the other 221 leaf node. 223 The LIE FSM will not be affected if only one leaf supports the 224 capability and the neighbor does not support. 226 The capability can be used for diagnosis in case there is something 227 wrong when computing route. 229 3.2. Prefix transferring 231 When a leaf node which has no northbound connection receives Prefix 232 TIE from a neighbor by an east-west link, it can transfer the Prefix 233 TIE to the other neighbor by the other east-west link, with increased 234 metric. The increased metric should be the sum of the received 235 metric and the metric of the east-west link. 237 The Prefix TIE can be the default route and the prefix of the leaf 238 node, other prefixes can also be transferred. The network 239 administrator can control the prefix transferring by policy. 241 Prefix South TIE transferring 242 The leaf node without northbound neighbors which supports the 243 leaf transfer capability, MUST transfer the Prefix South TIE 244 received from an east-west neighbor to the other east-west 245 neighbor which also has no northbound connection. 247 Prefix North TIE transferring 248 The leaf node without northbound neighbors which supports the 249 leaf transfer capability, MUST transfer the Prefix North TIE 250 received from an east-west neighbor which has no northbound 251 connection to the other east-west neighbor. 253 The leaf node without northbound neighbors which supports the leaf 254 transfer capability, MAY transfer the Prefix TIE from an east-west 255 neighbor to the other east-west neighbor which has northbound 256 connection. According to Northbound SPF algorithm defined in section 257 4.2.4.1 in [I-D.ietf-rift-rift], the transferring does not affect the 258 routing calculating result of the neighbors which has northbound 259 connection. 261 3.3. Example 263 In figure 2, either L04 or L06, or both of them advertise the leaf- 264 transport capability in LIE to L05 when they are forming an 265 adjacency. And the leaf-transport capability is also set in node TIE 266 when L04 or L06 advertise the TIE. 268 L04/L06 receives Prefix South TIE with default route from L01/L03, 269 L04/L06 transfers the route through Prefix South TIE with increased 270 metric to L05. 272 L04/L06 receives Prefix North TIE of L05 and transfers the route 273 through Prefix North TIE with increased metric to L01/L03. 275 L05 receives the Prefix South TIE from L04/L06, after N-SPF 276 calculation, L05 calculates the default route with next hop L04/L06. 277 L01/L03 receives prefix of L05 from L04/L06, and L01/03 floods the 278 Prefix North TIE northbound. Then L05 can send flow to other leaf 279 through L04/L06. The flow sent by other leaf with destination set to 280 the prefix of L05 can also be routed to L05. Then L05 can access the 281 network. 283 4. IANA Considerations 285 A new type for 'leaf-transfer' is requested in link capability. 287 5. Security Considerations 289 When the node without northbound neighbors supports the function 290 defined in this document, there may be unnecessary Prefix TIE 291 advertisement, and unnecessary prefix may be leaked. 293 6. References 295 6.1. Normative References 297 [I-D.ietf-rift-rift] 298 Przygienda, T., Sharma, A., Thubert, P., Rijsman, B., and 299 D. Afanasiev, "RIFT: Routing in Fat Trees", 2021, 300 . 303 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 304 Requirement Levels", BCP 14, RFC 2119, 305 DOI 10.17487/RFC2119, March 1997, 306 . 308 6.2. Informative References 310 [RFC7991] Hoffman, P., "The "xml2rfc" Version 3 Vocabulary", 311 RFC 7991, DOI 10.17487/RFC7991, December 2016, 312 . 314 Authors' Addresses 316 Zheng Zhang 317 ZTE Corporation 318 China 320 Email: zhang.zheng@zte.com.cn 322 Yuehua Wei 323 ZTE Corporation 324 China 326 Email: wei.yuehua@zte.com.cn 328 Benchong Xu 329 ZTE Corporation 330 China 332 Email: xu.benchong@zte.com.cn