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