idnits 2.17.1 draft-chen-isis-sl-overheads-reduction-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 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 (January 6, 2017) is 2638 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 266, but not defined == Unused Reference: 'RFC1195' is defined on line 313, but no explicit reference was found in the text == Outdated reference: A later version (-07) exists of draft-shen-isis-spine-leaf-ext-02 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: July 10, 2017 January 6, 2017 7 Overheads Reduction for IS-IS Enabled Spine-Leaf Networks 8 draft-chen-isis-sl-overheads-reduction-00 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 assigning different area identifiers 18 (AIDs) to the Leaf nodes. The solution requires that an IS-IS router 19 SHOULD check a Level-1 LSP's AIDs before it advertises the LSP to its 20 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 July 10, 2017. 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 ID Assignment . . . . . . . . . . . . . . . . . . . 3 65 2.2. Area ID Checking . . . . . . . . . . . . . . . . . . . . 5 66 2.3. Default Route Advertising . . . . . . . . . . . . . . . . 6 67 3. Discussions . . . . . . . . . . . . . . . . . . . . . . . . . 7 68 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 69 5. Security Considerations . . . . . . . . . . . . . . . . . . . 7 70 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 71 7. Normative References . . . . . . . . . . . . . . . . . . . . 7 72 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 74 1. Introduction 76 Spine-Leaf topology (a.k.a., CLOS topology) is widely used in today's 77 datacenter and campus networks. When the Spine-Leaf topology runs 78 the Intermediate System to Intermediate System (IS-IS) routing 79 protocol, each Leaf node will receive Link State Packets (LSPs) from 80 all the other nodes and have the entire routing information of the 81 topology. This is usually considered to be unnecessary and costly 82 because the Leaf node only needs to know its default gateways (i.e., 83 the Spine nodes it connects to), and the LSPs generated by the other 84 Leaf nodes benefit nothing for it to forward traffic. 86 To avoid Leaf nodes from learning the unnecessary LSPs from one 87 another, [IS-IS-SL-Extension] proposes a new TLV of the IS-IS Hello 88 (IIH) PDU to differentiate Spine/Leaf nodes and LSPs generated by 89 Leaf nodes will be blocked at Spine nodes. Additionally, each Leaf 90 node sets the Spine nodes it connects to as its default gateways. 92 This document describes another solution to this problem, which needs 93 not to extend the IS-IS messages. In particular, it requires that 94 each Leaf node SHOULD be assigned with a unique area identifier (AID) 95 and IS-IS L1/L2 routers MUST NOT advertise Level-1 LSPs of a given 96 area to Level-1 routers within another area. This prevents Leaf 97 nodes from receiving routing information from one another, and lets 98 the Leaf node set the Spine nodes as its default gateways. 100 2. Solution Description 102 2.1. Area ID Assignment 104 +------------+ +------------+ 105 | Spine-A | 10.10.10.0/24 | Spine-B | 106 | L1/L2 +----------------------+ L1/L2 | 107 | Area10/20 | .1 .2 | Area10/20 | 108 +---+--+-----+ +---+----+---+ 109 .1 | | .1 .2 | | .1 110 | | 10.10.40.0/24 | | 111 | | +-----------------------------+ | 112 10.10.20.0/24 | | | | 10.10.30.0/24 113 | +--|-------------------------------+ | 114 | | 10.10.50.0/24 | | 115 .2 | | .1 .2 | | .2 116 +---+-----+--+ +-----+--+---+ 117 | Leaf-A | | Leaf-B | 118 | L1 | | L1 | 119 | Area10 | | Area20 | 120 +-----+------+ +-----+------+ 121 | | 122 | | 123 ------+------- ------+------- 124 192.168.10.0/24 192.168.20.0/24 126 Figure 1: Topology Example 128 This section describes how to assign AIDs in the Spine-Leaf topology, 129 and illustrates why IS-IS routers SHOULD check the AIDs before 130 advertising Level-1 LSPs. As shown in Figure 1, there are two Spine 131 nodes (i.e., Spine-A and Spine-B) and two Leaf nodes (i.e., Leaf-A 132 and Leaf-B). The System IDs of Spine-A, Spine-B, Leaf-A, and Leaf-B 133 are 1111.1111.1111.1111.00 to 4444.4444.4444.00, respectively. 135 To prevent a Leaf node from learning the routing information of the 136 other Leaf nodes, the following configurations are required: 138 a. Leaf nodes SHOULD be configured as L1 routers and each of them 139 SHOULD be assigned a unique AID. 141 b. Spine nodes SHOULD be configured as L1/L2 routers and SHOULD be 142 assigned multiple AIDs with each being that of a given Leaf node 143 connected to it. 145 As a result, Leaf-A and Leaf-B in Figure 1 are configured as L1 146 routers and are assigned AID 10 and AID 20, respectively. Spine-A 147 and Spine-B are configured as L1/L2 routers and are assigned both AID 148 10 and AID 20. 150 Level-1 Link State Database (Spine-A): 151 +--------------------+----------+--------+--------+------+--------+-----+ 152 |LSPID |Seq Num |Checksum|Holdtime|Length|ATT/P/OL|Area | 153 +--------------------+----------+--------+--------+------+--------+-----+ 154 |1111.1111.1111.00-00|0x0000006c|0x540b |743 |124 |0/0/0 |10/20| 155 +--------------------+----------+--------+--------+------+--------+-----+ 156 |2222.2222.2222.00-00|0x0000006d|0x933b |1068 |124 |0/0/0 |10/20| 157 +--------------------+----------+--------+--------+------+--------+-----+ 158 |3333.3333.3333.00-00|0x0000006b|0x1815 |402 |122 |0/0/0 |10 | 159 +--------------------+----------+--------+--------+------+--------+-----+ 160 |4444.4444.4444.00-00|0x0000006a|0xf543 |431 |122 |0/0/0 |20 | 161 +--------------------+----------+--------+--------+------+--------+-----+ 163 Level-2 Link State Database (Spine-A): 164 +--------------------+----------+--------+--------+------+--------+-----+ 165 |LSPID |Seq Num |Checksum|Holdtime|Length|ATT/P/OL|Area | 166 +--------------------+----------+--------+--------+------+--------+-----+ 167 |1111.1111.1111.00-00|0x0000006f|0x682f |743 |150 |0/0/0 |10/20| 168 +--------------------+----------+--------+--------+------+--------+-----+ 169 |2222.2222.2222.00-00|0x00000063|0x30eb |1068 |150 |0/0/0 |10/20| 170 +--------------------+----------+--------+--------+------+--------+-----+ 172 Figure 2: Link State Database of Spine-A 174 Under such configurations, Leaf-A will still receives Leaf-B's LSPs 175 (and vice versa) even though they are in different areas. This is 176 because of the IS-IS definition that all routers in a specific area 177 SHOULD share the same Level-1 Link State Database (LSDB). 179 The LSDB of Spine-A is shown in Figure 2. In particular, since 180 Spine-A and Leaf-B are both in area 20, Spine-A will receive the LSP 181 4444.4444.4444.00-00 from Leaf-B and store the LSP into its Level-1 182 LSDB. On the other hand, since Spine-A and Leaf-A are both in area 183 10, Spine-A will advertise the LSP 4444.4444.4444.00-00 to Leaf-A 184 although Leaf-A and Leaf-B (generator of the LSP) are in different 185 areas. As a result, Leaf-A will install the route 192.168.20.0/24 186 into its routing table (Figure 3), even though it is an external area 187 route. 189 Leaf-A Routing Table: 190 +---------------+-------+---+----+-----+----------+--------------+ 191 |Destination |Proto |Pre|Cost|Flags|NextHop |Interface | 192 +---------------+-------+---+----+-----+----------+--------------+ 193 |10.10.10.0/24 |ISIS-L1|15 |20 |D |10.10.20.1|Ethernet0/0/0 | 194 | |ISIS-L1|15 |20 |D |10.10.40.2|Ethernet0/0/1 | 195 +---------------+-------+---+----+-----+----------+--------------+ 196 |10.10.20.0/24 |Direct |0 |0 |D |127.0.0.1 |Ethernet0/0/0 | 197 +---------------+-------+---+----+-----+----------+--------------+ 198 |10.10.30.0/24 |ISIS-L1|15 |20 |D |10.10.40.2|Ethernet0/0/1 | 199 +---------------+-------+---+----+-----+----------+--------------+ 200 |10.10.40.0/24 |Direct |0 |0 |D |127.0.0.1 |Ethernet0/0/1 | 201 +---------------+-------+---+----+-----+----------+--------------+ 202 |10.10.50.0/24 |ISIS-L1|15 |20 |D |10.10.20.1|Ethernet0/0/0 | 203 +---------------+-------+---+----+-----+----------+--------------+ 204 |192.168.10.0/24|Direct |0 |0 |D |127.0.0.1 |GEthernet0/0/0| 205 +---------------+-------+---+----+-----+----------+--------------+ 206 |192.168.20.0/24|ISIS-L1|15 |30 |D |10.10.20.1|Ethernet0/0/0 | 207 | |ISIS-L1|15 |30 |D |10.10.40.2|Ethernet0/0/1 | 208 +---------------+-------+---+----+-----+----------+--------------+ 209 |127.0.0.0/8 |Direct |0 |0 |D |127.0.0.1 |InLoopBack0 | 210 +---------------+-------+---+----+-----+----------+--------------+ 211 |0.0.0.0/0 |ISIS-L1|15 |10 |D |10.10.20.1|Ethernet0/0/0 | 212 | |ISIS-L1|15 |10 |D |10.10.40.2|Ethernet0/0/1 | 213 +---------------+-------+---+----+-----+----------+--------------+ 215 Figure 3: Routing Table of Leaf-A 217 Therefore, to avoid Level-1 LSPs of one area from being flooded into 218 another area, an AID checking mechanism (see Section 2.2) is needed. 220 2.2. Area ID Checking 222 Before an IS-IS router advertises a Level-1 LSP to a Level-1 223 neighbor, it SHOULD compare the AIDs associated with the LSP and the 224 AIDs associated with the neighbor. If they have at least one AID in 225 common, the router SHOULD advertise the LSP to the neighbor. 226 Otherwise, the router MUST NOT advertise the LSP to the neighbor. 228 For instance, as shown in Figure 1, before Spine-A advertises the LSP 229 1111.1111.1111.00-00 to Leaf-A, it compares the LSP's AIDs (i.e., 10 230 and 20) with Leaf-A's AID (i.e., 10). Since they have an AID in 231 common that is AID 10, Spine-A SHOULD advertise the LSP to Leaf-A. 233 On the other hand, before Spine-A advertises the LSP 234 4444.4444.4444.00-00 to Leaf-A, it checks their AIDs and finds that 235 they have no AID in common. So Spine-A MUST NOT advertise the LSP to 236 Leaf-A. As a result, Leaf-A would not learn the routing information 237 of Leaf-B, as shown in Figure 4. 239 Leaf-A Routing Table: 240 +---------------+-------+---+----+-----+----------+--------------+ 241 |Destination |Proto |Pre|Cost|Flags|NextHop |Interface | 242 +---------------+-------+---+----+-----+----------+--------------+ 243 |10.10.10.0/24 |ISIS-L1|15 |20 |D |10.10.20.1|Ethernet0/0/0 | 244 | |ISIS-L1|15 |20 |D |10.10.40.2|Ethernet0/0/1 | 245 +---------------+-------+---+----+-----+----------+--------------+ 246 |10.10.20.0/24 |Direct |0 |0 |D |127.0.0.1 |Ethernet0/0/0 | 247 +---------------+-------+---+----+-----+----------+--------------+ 248 |10.10.30.0/24 |ISIS-L1|15 |20 |D |10.10.40.2|Ethernet0/0/1 | 249 +---------------+-------+---+----+-----+----------+--------------+ 250 |10.10.40.0/24 |Direct |0 |0 |D |127.0.0.1 |Ethernet0/0/1 | 251 +---------------+-------+---+----+-----+----------+--------------+ 252 |10.10.50.0/24 |ISIS-L1|15 |20 |D |10.10.20.1|Ethernet0/0/0 | 253 +---------------+-------+---+----+-----+----------+--------------+ 254 |192.168.10.0/24|Direct |0 |0 |D |127.0.0.1 |GEthernet0/0/0| 255 +---------------+-------+---+----+-----+----------+--------------+ 256 |127.0.0.0/8 |Direct |0 |0 |D |127.0.0.1 |InLoopBack0 | 257 +---------------+-------+---+----+-----+----------+--------------+ 258 |0.0.0.0/0 |ISIS-L1|15 |10 |D |10.10.20.1|Ethernet0/0/0 | 259 | |ISIS-L1|15 |10 |D |10.10.40.2|Ethernet0/0/1 | 260 +---------------+-------+---+----+-----+----------+--------------+ 262 Figure 4: Routing Table of Leaf-A 264 2.3. Default Route Advertising 266 As defined in [RFC 1195], a L1/L2 router will indicate in its L1 LSPs 267 that it is "attached" by setting the ATT bits. Therefore, each Leaf 268 node in the example will set the Spine nodes as its default gateways 269 and install the corresponding default routes into its routing table, 270 as shown in Figure 4. 272 However, a specific IS-IS implementation in this case may not let the 273 L1/L2 router set the ATT bits, because it may speculate that the L1/ 274 L2 router has lost connectivity to the Level-2 backbone. To solve 275 this problem, operators can manually configure the L1/L2 router to 276 advertise a default route. 278 3. Discussions 280 The AID checking mechanism described in this document will put little 281 effect on the current usage of the IS-IS protocol because of two 282 reasons: 284 a. In usual cases, an IS-IS router is assigned no more than one AID. 285 Therefore no LSP will be blocked and the IS-IS protocol runs as 286 normal. 288 b. An IS-IS router is assigned more than one AIDs only when 1) it is 289 desirable to change the AID of an area, 2) to merge two areas 290 into one area, or 3) to partition an area into two areas. 291 Apparently, the AID checking mechanism does not impact these 292 operations. 294 4. IANA Considerations 296 TBD. 298 5. Security Considerations 300 TBD. 302 6. Acknowledgements 304 TBD. 306 7. Normative References 308 [IS-IS-SL-Extension] 309 Shen, N. and S. Thyamagundalu, "IS-IS Routing for Spine- 310 Leaf Topology", draft-shen-isis-spine-leaf-ext-02 (work in 311 progress) , October 2016. 313 [RFC1195] Callon, R., "Use of OSI IS-IS for Routing in TCP/IP and 314 Dual Environments", RFC 1195 , December 1990. 316 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 317 Requirement Levels", BCP 14, RFC 2119, 318 DOI 10.17487/RFC2119, March 1997, 319 . 321 Authors' Addresses 322 Zhe Chen 323 Huawei Technologies 324 No. 156 Beiqing Rd 325 Beijing 100095 326 China 328 Email: chenzhe17@huawei.com 330 Xiaohu Xu 331 Huawei Technologies 332 No. 156 Beiqing Rd 333 Beijing 100095 334 China 336 Email: xuxiaohu@huawei.com