idnits 2.17.1 draft-chen-isis-sl-overheads-reduction-03.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 18 instances of too long lines in the document, the longest one being 1 character in excess of 72. == There are 4 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. == There are 1 instance 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 (March 5, 2018) is 2241 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) == Missing Reference: 'RFC 1195' is mentioned on line 284, but not defined == Unused Reference: 'RFC1195' is defined on line 345, but no explicit reference was found in the text == Outdated reference: A later version (-07) exists of draft-shen-isis-spine-leaf-ext-05 Summary: 1 error (**), 0 flaws (~~), 6 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Z. Chen 3 Internet-Draft Huawei 4 Intended status: Standards Track X. Xu 5 Expires: September 6, 2018 Alibaba 6 D. Cheng 7 Huawei 8 March 5, 2018 10 Overheads Reduction for IS-IS Enabled Spine-Leaf Networks 11 draft-chen-isis-sl-overheads-reduction-03 13 Abstract 15 When a Spine-Leaf topology adopts the Intermediate System to 16 Intermediate System (IS-IS) routing protocol, the Leaf node receives 17 Link State Packets (LSPs) from all the other nodes thus having the 18 entire routing information of the topology. This is usually 19 considered unnecessary and costly. This document describes a 20 solution to this problem by utilizing IS-IS's inherent multi-level 21 and area partition features, which requires that an IS-IS router 22 SHOULD check a level-1 LSP's area addresses before advertising it to 23 a neighbor. 25 Requirements Language 27 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 28 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 29 document are to be interpreted as described in RFC 2119 [RFC2119]. 31 Status of This Memo 33 This Internet-Draft is submitted in full conformance with the 34 provisions of BCP 78 and BCP 79. 36 Internet-Drafts are working documents of the Internet Engineering 37 Task Force (IETF). Note that other groups may also distribute 38 working documents as Internet-Drafts. The list of current Internet- 39 Drafts is at https://datatracker.ietf.org/drafts/current/. 41 Internet-Drafts are draft documents valid for a maximum of six months 42 and may be updated, replaced, or obsoleted by other documents at any 43 time. It is inappropriate to use Internet-Drafts as reference 44 material or to cite them other than as "work in progress." 46 This Internet-Draft will expire on September 6, 2018. 48 Copyright Notice 50 Copyright (c) 2018 IETF Trust and the persons identified as the 51 document authors. All rights reserved. 53 This document is subject to BCP 78 and the IETF Trust's Legal 54 Provisions Relating to IETF Documents 55 (https://trustee.ietf.org/license-info) in effect on the date of 56 publication of this document. Please review these documents 57 carefully, as they describe your rights and restrictions with respect 58 to this document. Code Components extracted from this document must 59 include Simplified BSD License text as described in Section 4.e of 60 the Trust Legal Provisions and are provided without warranty as 61 described in the Simplified BSD License. 63 Table of Contents 65 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 66 2. Solution Description . . . . . . . . . . . . . . . . . . . . 3 67 2.1. Area Address Assignment . . . . . . . . . . . . . . . . . 3 68 2.2. Area Address Checking . . . . . . . . . . . . . . . . . . 5 69 2.3. Default Route Advertising . . . . . . . . . . . . . . . . 7 70 3. Compatibility . . . . . . . . . . . . . . . . . . . . . . . . 7 71 3.1. Overlapping Areas Use Case . . . . . . . . . . . . . . . 7 72 3.2. Maximum Area Addresses . . . . . . . . . . . . . . . . . 7 73 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 74 5. Security Considerations . . . . . . . . . . . . . . . . . . . 8 75 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 76 7. Normative References . . . . . . . . . . . . . . . . . . . . 8 77 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 79 1. Introduction 81 Spine-Leaf topology (a.k.a., CLOS topology) is widely used in today's 82 datacenter and campus networks. When the Spine-Leaf topology runs 83 the Intermediate System to Intermediate System (IS-IS) routing 84 protocol, each Leaf node receives Link State Packets (LSPs) from all 85 the other nodes thus having the entire routing information of the 86 topology. This is usually considered unnecessary and costly because 87 the Leaf node only needs to know its default gateways (i.e., the 88 Spine nodes it connects to) and the LSPs generated by the other Leaf 89 nodes bring little benefit for it to forward traffic. 91 To avoid Leaf nodes from learning the unnecessary LSPs from one 92 another, [IS-IS-SL-Extension] proposes a new TLV attached to the IS- 93 IS Hello (IIH) PDU to carry an router's role (i.e., Spine or Leaf) in 94 the topology. The Spine nodes then prevent all LSPs from being sent 95 to the Leaf nodes, and each Leaf node sets the Spine nodes it 96 connects to as its default gateways. 98 This document proposes another solution to this problem, which 99 utilizes IS-IS's inherent multi-level and area partition features. 100 In particular, it requires that each Leaf node (configured as L1 101 router) SHOULD be assigned with a unique area address and each Spine 102 node (configured as L1/L2 router) MUST NOT advertise level-1 LSPs of 103 a given area to neighbors within another area. This prevents Leaf 104 nodes from receiving routing information from one another, without 105 introducing new message formats. 107 2. Solution Description 109 2.1. Area Address Assignment 111 +------------+ +------------+ 112 | Spine-A | 10.10.10.0/24 | Spine-B | 113 | L1/L2 +----------------------+ L1/L2 | 114 | Area10/20 | .1 .2 | Area10/20 | 115 +---+--+-----+ +---+----+---+ 116 .1 | | .1 .2 | | .1 117 | | 10.10.40.0/24 | | 118 | | +-----------------------------+ | 119 10.10.20.0/24 | | | | 10.10.30.0/24 120 | +--|-------------------------------+ | 121 | | 10.10.50.0/24 | | 122 .2 | | .1 .2 | | .2 123 +---+-----+--+ +-----+--+---+ 124 | Leaf-A | | Leaf-B | 125 | L1 | | L1 | 126 | Area10 | | Area20 | 127 +-----+------+ +-----+------+ 128 | | 129 | | 130 ------+------- ------+------- 131 192.168.10.0/24 192.168.20.0/24 133 Figure 1: Topology Example 135 This section describes how to assign area addresses in the Spine-Leaf 136 topology, and illustrates why IS-IS routers SHOULD check the area 137 addresses before advertising level-1 LSPs. As shown in Figure 1, 138 there are two Spine nodes (i.e., Spine-A and Spine-B) and two Leaf 139 nodes (i.e., Leaf-A and Leaf-B). The System IDs of Spine-A, Spine-B, 140 Leaf-A, and Leaf-B are 1111.1111.1111.00 to 4444.4444.4444.00, 141 respectively. 143 To prevent a Leaf node from learning the routing information of the 144 other ones, the following configurations are REQUIRED: 146 a. Leaf nodes SHOULD be configured as L1 routers and each of them 147 SHOULD be assigned a unique area address. 149 b. Spine nodes SHOULD be configured as L1/L2 routers and SHOULD be 150 assigned multiple area addresses with each being that of a given 151 Leaf node connected to it. 153 As a result, Leaf-A and Leaf-B in Figure 1 are configured as L1 154 routers and are assigned 10 and 20 as their area addresses, 155 respectively. Spine-A and Spine-B are configured as L1/L2 routers 156 and are assigned both 10 and 20 as their area addresses. 158 Level-1 Link State Database (Spine-A): 159 +--------------------+----------+--------+--------+------+--------+-----+ 160 |LSPID |Seq Num |Checksum|Holdtime|Length|ATT/P/OL|Area | 161 +--------------------+----------+--------+--------+------+--------+-----+ 162 |1111.1111.1111.00-00|0x0000006c|0x540b |743 |124 |0/0/0 |10/20| 163 +--------------------+----------+--------+--------+------+--------+-----+ 164 |2222.2222.2222.00-00|0x0000006d|0x933b |1068 |124 |0/0/0 |10/20| 165 +--------------------+----------+--------+--------+------+--------+-----+ 166 |3333.3333.3333.00-00|0x0000006b|0x1815 |402 |122 |0/0/0 |10 | 167 +--------------------+----------+--------+--------+------+--------+-----+ 168 |4444.4444.4444.00-00|0x0000006a|0xf543 |431 |122 |0/0/0 |20 | 169 +--------------------+----------+--------+--------+------+--------+-----+ 171 Level-2 Link State Database (Spine-A): 172 +--------------------+----------+--------+--------+------+--------+-----+ 173 |LSPID |Seq Num |Checksum|Holdtime|Length|ATT/P/OL|Area | 174 +--------------------+----------+--------+--------+------+--------+-----+ 175 |1111.1111.1111.00-00|0x0000006f|0x682f |743 |150 |0/0/0 |10/20| 176 +--------------------+----------+--------+--------+------+--------+-----+ 177 |2222.2222.2222.00-00|0x00000063|0x30eb |1068 |150 |0/0/0 |10/20| 178 +--------------------+----------+--------+--------+------+--------+-----+ 180 Figure 2: Link State Database of Spine-A 182 Under such configurations, however, Leaf-A still receives Leaf-B's 183 LSPs (and vice versa) even though they are in different areas. This 184 is because of the IS-IS definition that all routers in a specific 185 area SHOULD share the same level-1 Link State Database (LSDB). In 186 other words, IS-IS routers check area addresses during neighbor 187 establishment, but are regardless of area addresses when advertising 188 LSPs to a neighbor. 190 The example in Figure 1 and the LSDB of Spine-A (in Figure 2) further 191 illustrate this. Since Spine-A and Leaf-B are both in area 20, 192 Spine-A will receive LSP 4444.4444.4444.00-00 from Leaf-B and store 193 the LSP into its level-1 LSDB. On the other hand, since Spine-A and 194 Leaf-A are both in area 10, Spine-A will advertise LSP 195 4444.4444.4444.00-00 to Leaf-A although Leaf-A and Leaf-B (generator 196 of the LSP) are in different areas. As a result, Leaf-A installs the 197 route 192.168.20.0/24 into its routing table (Figure 3), even though 198 it is an external area route. 200 Leaf-A Routing Table: 201 +---------------+-------+---+----+-----+----------+--------------+ 202 |Destination |Proto |Pre|Cost|Flags|NextHop |Interface | 203 +---------------+-------+---+----+-----+----------+--------------+ 204 |10.10.10.0/24 |ISIS-L1|15 |20 |D |10.10.20.1|Ethernet0/0/0 | 205 | |ISIS-L1|15 |20 |D |10.10.40.2|Ethernet0/0/1 | 206 +---------------+-------+---+----+-----+----------+--------------+ 207 |10.10.20.0/24 |Direct |0 |0 |D |127.0.0.1 |Ethernet0/0/0 | 208 +---------------+-------+---+----+-----+----------+--------------+ 209 |10.10.30.0/24 |ISIS-L1|15 |20 |D |10.10.40.2|Ethernet0/0/1 | 210 +---------------+-------+---+----+-----+----------+--------------+ 211 |10.10.40.0/24 |Direct |0 |0 |D |127.0.0.1 |Ethernet0/0/1 | 212 +---------------+-------+---+----+-----+----------+--------------+ 213 |10.10.50.0/24 |ISIS-L1|15 |20 |D |10.10.20.1|Ethernet0/0/0 | 214 +---------------+-------+---+----+-----+----------+--------------+ 215 |192.168.10.0/24|Direct |0 |0 |D |127.0.0.1 |GEthernet0/0/0| 216 +---------------+-------+---+----+-----+----------+--------------+ 217 |192.168.20.0/24|ISIS-L1|15 |30 |D |10.10.20.1|Ethernet0/0/0 | 218 | |ISIS-L1|15 |30 |D |10.10.40.2|Ethernet0/0/1 | 219 +---------------+-------+---+----+-----+----------+--------------+ 220 |127.0.0.0/8 |Direct |0 |0 |D |127.0.0.1 |InLoopBack0 | 221 +---------------+-------+---+----+-----+----------+--------------+ 222 |0.0.0.0/0 |ISIS-L1|15 |10 |D |10.10.20.1|Ethernet0/0/0 | 223 | |ISIS-L1|15 |10 |D |10.10.40.2|Ethernet0/0/1 | 224 +---------------+-------+---+----+-----+----------+--------------+ 226 Figure 3: Routing Table of Leaf-A 228 Therefore, the solution proposed in this document requires that an 229 IS-IS router SHOULD check a level-1 LSP's area addresses before 230 advertising it to a neighbor (see Section 2.2). 232 2.2. Area Address Checking 234 Before advertising a level-1 LSP to a neighbor, an IS-IS router 235 SHOULD compare the area addresses associated with the LSP and the 236 ones associated with the neighbor. If they have at least one area 237 address in common, the router SHOULD advertise the LSP to the 238 neighbor. Otherwise, the router MUST NOT advertise the LSP to the 239 neighbor. 241 In the former case, the router SHOULD remove every area addresse in 242 the LSP except the ones associated with the neighbor before the 243 advertisement. This makes the solution more compatible since the 244 Leaf nodes can be unaltered (see Section 3.2). 246 For instance, before Spine-A advertises LSP 1111.1111.1111.00-00 to 247 Leaf-A, it compares the LSP's area addresses (i.e., 10 and 20) with 248 Leaf-A's area address (i.e., 10). Since they have a common area 249 address 10, Spine-A SHOULD remove area address 20 from the LSP and 250 advertise the LSP to Leaf-A. On the other hand, before Spine-A 251 advertises LSP 4444.4444.4444.00-00 to Leaf-A, it checks their area 252 addresses and finds that they have no area address in common. So 253 Spine-A MUST NOT advertise the LSP to Leaf-A. As a result, Leaf-A 254 would not learn any routing information of Leaf-B, as shown in 255 Figure 4. 257 Leaf-A Routing Table: 258 +---------------+-------+---+----+-----+----------+--------------+ 259 |Destination |Proto |Pre|Cost|Flags|NextHop |Interface | 260 +---------------+-------+---+----+-----+----------+--------------+ 261 |10.10.10.0/24 |ISIS-L1|15 |20 |D |10.10.20.1|Ethernet0/0/0 | 262 | |ISIS-L1|15 |20 |D |10.10.40.2|Ethernet0/0/1 | 263 +---------------+-------+---+----+-----+----------+--------------+ 264 |10.10.20.0/24 |Direct |0 |0 |D |127.0.0.1 |Ethernet0/0/0 | 265 +---------------+-------+---+----+-----+----------+--------------+ 266 |10.10.30.0/24 |ISIS-L1|15 |20 |D |10.10.40.2|Ethernet0/0/1 | 267 +---------------+-------+---+----+-----+----------+--------------+ 268 |10.10.40.0/24 |Direct |0 |0 |D |127.0.0.1 |Ethernet0/0/1 | 269 +---------------+-------+---+----+-----+----------+--------------+ 270 |10.10.50.0/24 |ISIS-L1|15 |20 |D |10.10.20.1|Ethernet0/0/0 | 271 +---------------+-------+---+----+-----+----------+--------------+ 272 |192.168.10.0/24|Direct |0 |0 |D |127.0.0.1 |GEthernet0/0/0| 273 +---------------+-------+---+----+-----+----------+--------------+ 274 |127.0.0.0/8 |Direct |0 |0 |D |127.0.0.1 |InLoopBack0 | 275 +---------------+-------+---+----+-----+----------+--------------+ 276 |0.0.0.0/0 |ISIS-L1|15 |10 |D |10.10.20.1|Ethernet0/0/0 | 277 | |ISIS-L1|15 |10 |D |10.10.40.2|Ethernet0/0/1 | 278 +---------------+-------+---+----+-----+----------+--------------+ 280 Figure 4: Routing Table of Leaf-A 282 2.3. Default Route Advertising 284 As defined in [RFC 1195], a L1/L2 router will indicate in its LSPs 285 that it is "attached" by setting the ATT bits. Therefore, each Leaf 286 node would set the Spine nodes as its default gateways and install a 287 default route in its routing table, as shown in Figure 4. 289 However, a specific IS-IS implementation in this case may not let the 290 L1/L2 router set the ATT bits, because it may speculate that the L1/ 291 L2 router has lost connectivity to the level-2 backbone. To solve 292 this problem, operators can manually configure the L1/L2 router to 293 advertise a default route. 295 3. Compatibility 297 3.1. Overlapping Areas Use Case 299 In most deployments, an IS-IS router is assigned only one area 300 address, which will not be influenced by the area checking mechanism 301 proposed in this document. However, an IS-IS router might be 302 assigned more than one area addresses in some practical deployments 303 for the following reasons: 1) it is desirable to change the area 304 address of an area, 2) to merge two areas into one area, or 3) to 305 partition an area into two areas. 307 For instance, to change an area's address from X to Y, one can simply 308 add area address Y to all routers in the area, and then remove X from 309 them. Note that such operations would not disrupt live traffic in 310 the network. 312 Although the solution in this document requires IS-IS router to check 313 LSP's area addresses before advertising it, the above use cases are 314 still applicable and no compatible issue rises. 316 3.2. Maximum Area Addresses 318 The maximumAreaAddresses parameter in today's IS-IS implementation is 319 set to be 3 (or 0 which indicates 3) on consensus. Therefore, the 320 solution in this document also requires that Spine node SHOULD be 321 modified for supporting more area addresses. However, as LSPs sent 322 to a given neighbor only carry the area address(es) of the neighbor 323 (see Section 2.2), the solution does not require to modify Leaf 324 nodes. 326 4. IANA Considerations 328 TBD. 330 5. Security Considerations 332 TBD. 334 6. Acknowledgements 336 TBD. 338 7. Normative References 340 [IS-IS-SL-Extension] 341 Shen, N., Ginsberg, L., and S. Thyamagundalu, "IS-IS 342 Routing for Spine-Leaf Topology", draft-shen-isis-spine- 343 leaf-ext-05 (work in progress) , January 2018. 345 [RFC1195] Callon, R., "Use of OSI IS-IS for Routing in TCP/IP and 346 Dual Environments", RFC 1195 , December 1990. 348 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 349 Requirement Levels", BCP 14, RFC 2119, 350 DOI 10.17487/RFC2119, March 1997, 351 . 353 Authors' Addresses 355 Zhe Chen 356 Huawei 357 No. 156 Beiqing Rd 358 Beijing 100095 359 China 361 Email: chenzhe17@huawei.com 363 Xiaohu Xu 364 Alibaba 366 Email: xiaohu.xxh@alibaba-inc.com 368 Dean Cheng 369 Huawei 371 Email: dean.cheng@huawei.com