idnits 2.17.1 draft-li-lsr-isis-area-abstraction-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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (August 28, 2019) is 1696 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) == Outdated reference: A later version (-18) exists of draft-ietf-lsr-dynamic-flooding-03 ** Downref: Normative reference to an Experimental draft: draft-ietf-lsr-dynamic-flooding (ref. 'I-D.ietf-lsr-dynamic-flooding') -- Possible downref: Non-RFC (?) normative reference: ref. 'ISO10589' Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force T. Li 3 Internet-Draft Arista Networks 4 Intended status: Standards Track August 28, 2019 5 Expires: February 29, 2020 7 Area Abstraction for IS-IS 8 draft-li-lsr-isis-area-abstraction-01 10 Abstract 12 Link state routing protocols have hierarchical abstraction already 13 built into them. However, when lower levels are used for transit, 14 they must expose their internal topologies, leading to scale issues. 16 To avoid this, this document discusses extensions to the IS-IS 17 routing protocol that would allow level 1 areas to provide transit, 18 yet only inject an abstraction of the level 1 topology into level 2. 20 Status of This Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at https://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on February 29, 2020. 37 Copyright Notice 39 Copyright (c) 2019 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (https://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 55 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 56 2. Area Abstraction . . . . . . . . . . . . . . . . . . . . . . 3 57 2.1. Area Leader Election . . . . . . . . . . . . . . . . . . 4 58 2.2. LSP Generation . . . . . . . . . . . . . . . . . . . . . 5 59 2.3. Redundancy . . . . . . . . . . . . . . . . . . . . . . . 5 60 2.4. Level 2 SPF Considerations . . . . . . . . . . . . . . . 5 61 3. Area Proxy System Identifier TLV . . . . . . . . . . . . . . 6 62 4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 63 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 64 6. Security Considerations . . . . . . . . . . . . . . . . . . . 6 65 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 66 7.1. Normative References . . . . . . . . . . . . . . . . . . 7 67 7.2. Informative References . . . . . . . . . . . . . . . . . 7 68 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 7 70 1. Introduction 72 The IS-IS routing protocol IS-IS [ISO10589] currently supports a two 73 level hierarchy of abstraction. The fundamental unit of abstraction 74 is the 'area', which is a (hopefully) connected set of systems 75 running IS-IS at the same level. Level 1, the lowest level, is 76 abstracted by routers that participate in both Level 1 and Level 2, 77 and they inject area information into Level 2. Level 2 systems 78 seeking to access Level 1, use this abstraction to compute the 79 shortest path to the Level 1 area. The full topology database of 80 Level 1 is not injected into Level 2, only a summary of the address 81 space contained within the area, so the scalability of the Level 2 82 link state database is protected. 84 This works well if the Level 1 area is tangential to the Level 2 85 area. This also works well if there are a number of routers in both 86 Level 1 and Level 2 and they are adjacent, so Level 2 traffic will 87 never need to transit Level 1 only routers. Level 1 will not contain 88 any Level 2 topology, and Level 2 will only contain area abstractions 89 for Level 1. 91 Unfortunately, this scheme does not work so well if the Level 1 area 92 needs to provide transit for Level 2 traffic. For Level 2 shortest 93 path first (SPF) computations to work correctly, the transit topology 94 must also appear in the Level 2 link state database. This implies 95 that all routers that could possibly provide transit, plus any links 96 that might also provide Level 2 transit must also become part of the 97 Level 2 topology. If this is a relatively tiny portion of the Level 98 1 area, this is not onerous. 100 However, with today's data center topologies, this is problematic. A 101 common application is to use a Layer 3 Leaf-Spine (L3LS) topology, 102 which is a folded 3-stage Clos [Clos] fabric. It can also be thought 103 of as a complete bipartite graph. In such a topology, the desire is 104 to use Level 1 to contain the routing of the entire L3LS topology and 105 then to use Level 2 for the remainder of the network. Leaves in the 106 L3LS topology are appropriate for connection outside of the data 107 center itself, so they would provide connectivity for Level 2. If 108 there are multiple connections to Level 2 for redundancy, or to other 109 areas, these too would also be made to the leaves in the topology. 110 This creates a difficulty because there are now multiple Level 2 111 leaves in the topology, with connectivity between the leaves provide 112 by the spines. 114 Following the current rules of IS-IS, all spine routers would 115 necessarily be part of the Level 2 topology, plus all links between a 116 Level 2 leaf and the spines. In the limit, where all leaves need to 117 support Level 2, it implies that the entire L3LS topology becomes 118 part of Level 2. This is seriously problematic as it more than 119 doubles the link state database held in the L3LS topology and 120 eliminates any benefits of the hierarchy. 122 1.1. Requirements Language 124 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 125 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 126 document are to be interpreted as described in RFC 2119 [RFC2119]. 128 2. Area Abstraction 130 To address this, we propose to completely abstract away the details 131 of the Level 1 area topology within Level 2, making the entire area 132 look like a single system directly connected to all of the area's 133 Level 2 neighbors. By only providing an abstraction of the topology, 134 Level 2's requirement for connectivity can be satisfied without the 135 full overhead of the area's internal topology. It then becomes the 136 responsibility of the Level 1 area to ensure the forwarding 137 connectivity that's advertised. 139 For the purposes of this discussion, we'll consider a single Level 1 140 IS-IS area as the Target Area. All routers within this area speak 141 Level 1 IS-IS on all of the links within this topology. We assume 142 that the Target Area is always connected. We propose to implement 143 Area Abstraction by having a Level 2 Proxy LSP that represents the 144 entire Target Area. This is the only LSP from the area that will be 145 injected into the overall Level 2 link state database. 147 There are four classes of routers that we need to be concerned with 148 in this discussion: 150 Target Area Router A router within the Target Area that runs Level 1 151 IS-IS. Some Target Area Routers may also run Level 2. 153 Area Leader The Area Leader is a Target Area Router that is elected 154 to represent the Level 1 area by injecting the Proxy LSP into the 155 Level 2 link state database. The Area Leader runs Level 2 as well 156 as Level 1. There may be multiple candidates for Area Leader, but 157 only one is elected at a given time. 159 Area Edge Router An Area Edge Router is a Target Area Router that 160 also runs Level 2 and has at least one Level 2 interface outside 161 of the Target Area. 163 Area Neighbor An Area Neighbor is a Level 2 router that is outside 164 of the Target Area that has an adjacency with an Area Edge Router. 166 The Area Leader has several responsibilities. First, it must inject 167 Area Proxy System Identifier into the Level 1 link state database. 168 Second, the Area Leader must generate the Proxy LSP for the Target 169 Area. 171 All Area Edge Routers learn the Area Proxy System Identifier from the 172 Level 1 link state database and use that as the system identifier in 173 their Level 2 IS-IS Hello PDUs on interfaces outside the Target Area. 174 Area Neighbors should then advertise an adjacency to the Area Proxy 175 System Identifier. The Area Edge Routers MUST also maintain a Level 176 2 adjacency with the Area Leader, either via a direct link or via a 177 tunnel. 179 Area Edge Routers MUST be able to provide transit to Level 2 traffic. 180 We propose that the Area Edge Routers use Segment Routing (SR) 181 [I-D.ietf-spring-segment-routing] and, during Level 2 SPF 182 computation, use the SR forwarding path to reach the exit Area Edge 183 Routers. To support SR, Area Edge Routers SHOULD advertise Adjacency 184 Segment Identifiers for their adjacency to the Area Leader. Other 185 mechanisms are possible and are a local decision. 187 2.1. Area Leader Election 189 The Area Leader is selected using the election mechanisms described 190 in Dynamic Flooding for IS-IS [I-D.ietf-lsr-dynamic-flooding]. 192 2.2. LSP Generation 194 Each Area Edge Routers generates a Level 2 LSP that includes 195 adjacencies to any Area Neighbors and the Area Leader. Unlike normal 196 Level 2 operations, this LSP is not advertised outside of the Target 197 Area and must be filtered by all Area Edge Routers to not be flooded 198 outside of the Target Area. 200 The Area Leader uses the Level 2 LSPs generated by the Area Edge 201 Routers to generate the Area Proxy LSP. This LSP is originated using 202 the Area Proxy System Identifier and includes adjacencies for all of 203 the Area Neighbors that have been advertised by the Area Edge 204 Routers. Since the Area Neighbors also advertise an adjacency to the 205 system identifier, this will result in a bi-directional adjacency. 206 The Area Proxy LSP is the only LSP that is injected into the overall 207 Level 2 link state database, with all other Level 2 LSPs from the 208 Target Area being filtered out at the Target Area boundary. 210 2.3. Redundancy 212 If the Area Leader fails, another candidate may become Area Leader 213 and MUST regenerate the Area Proxy LSP. The failure of the Area 214 Leader is not visible outside of the area and appears to simply be an 215 update of the Area Proxy LSP. 217 2.4. Level 2 SPF Considerations 219 When Level 2 systems outside of the Target Area perform an Level 2 220 SPF computation, they will use the Area Proxy LSP for computing a 221 path transiting the Target Area. Because the Level 1 topology has 222 been abstracted away, the cost for transiting the Target Area will be 223 zero. 225 When Level 2 sytems inside of the Target Area perform a Level 2 226 computation, they must ignore the Area Proxy LSP. Further, because 227 these systems do see the topology inside of the Target Area, the 228 costs internal to the area are visible. This could lead to different 229 and possibly inconsistent SPF results, potentially leading to 230 forwarding loops. 232 To prevent this, the Level 2 systems within the Target Area must 233 consider the metrics of links outside of the Target Area (inter-area 234 metrics) separately from the metrics of links inside of the Target 235 Area (intra-area metrics). Intra-area metrics as being less than any 236 inter-area metric. Thus, if two paths have different total inter- 237 area metrics, the path with the lower inter-area metric would be 238 preferred, regardless of any intra-area metrics involved. However, 239 if two paths have equal inter-area metrics, then the intra-area 240 metrics would be used to compare the paths. 242 3. Area Proxy System Identifier TLV 244 The Area Proxy System Identifier TLV allows the Area Leader to 245 advertise the existence of an Area Proxy System Identifier. This TLV 246 is injected into the Area Leader's Level 1 LSP. 248 The format of the Area Proxy System Identifier TLV is: 250 0 1 2 251 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 252 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 253 | TLV Type | TLV Length | Proxy SysID | 254 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 255 | Proxy System Identifier continued ... 256 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 258 TLV Type: XXX 260 TLV Length: 2 + (length of a system ID) 262 Proxy System Identier: The area's Proty System Identifier, which 263 is the length of a system identifier. field. 265 4. Acknowledgements 267 The author would like to thank Bruno Decraene for his many helpful 268 comments. The author would also like to thank a small group that 269 wishes to remain anonymous for their valuable contributions. 271 5. IANA Considerations 273 This memo requests that IANA allocate and assign one code point from 274 the IS-IS TLV Codepoints registry for the Area Pseudonode TLV. 276 6. Security Considerations 278 This document introduces no new security issues. Security of routing 279 within a domain is already addressed as part of the routing protocols 280 themselves. This document proposes no changes to those security 281 architectures. 283 7. References 285 7.1. Normative References 287 [I-D.ietf-lsr-dynamic-flooding] 288 Li, T., Psenak, P., Ginsberg, L., Chen, H., Przygienda, 289 T., Cooper, D., Jalil, L., and S. Dontula, "Dynamic 290 Flooding on Dense Graphs", draft-ietf-lsr-dynamic- 291 flooding-03 (work in progress), June 2019. 293 [I-D.ietf-spring-segment-routing] 294 Filsfils, C., Previdi, S., Ginsberg, L., Decraene, B., 295 Litkowski, S., and R. Shakir, "Segment Routing 296 Architecture", draft-ietf-spring-segment-routing-15 (work 297 in progress), January 2018. 299 [ISO10589] 300 International Organization for Standardization, 301 "Intermediate System to Intermediate System Intra-Domain 302 Routing Exchange Protocol for use in Conjunction with the 303 Protocol for Providing the Connectionless-mode Network 304 Service (ISO 8473)", ISO/IEC 10589:2002, Nov. 2002. 306 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 307 Requirement Levels", BCP 14, RFC 2119, 308 DOI 10.17487/RFC2119, March 1997, 309 . 311 7.2. Informative References 313 [Clos] Clos, C., "A Study of Non-Blocking Switching Networks", 314 The Bell System Technical Journal Vol. 32(2), DOI 315 10.1002/j.1538-7305.1953.tb01433.x, March 1953, 316 . 318 Author's Address 320 Tony Li 321 Arista Networks 322 5453 Great America Parkway 323 Santa Clara, California 95054 324 USA 326 Email: tony.li@tony.li