idnits 2.17.1 draft-li-lsr-isis-area-abstraction-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 : ---------------------------------------------------------------------------- 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 (December 7, 2018) is 1966 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) -- Possible downref: Non-RFC (?) normative reference: ref. 'ISO10589' Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 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 December 7, 2018 5 Expires: June 10, 2019 7 Level 1 Area Abstraction for IS-IS 8 draft-li-lsr-isis-area-abstraction-00 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 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 June 10, 2019. 37 Copyright Notice 39 Copyright (c) 2018 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 . . . . . . . . . . . . . . . . . . . . . 4 59 2.3. Redundancy . . . . . . . . . . . . . . . . . . . . . . . 5 60 3. Area Pseudonode TLV . . . . . . . . . . . . . . . . . . . . . 5 61 4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 5 62 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 63 6. Security Considerations . . . . . . . . . . . . . . . . . . . 6 64 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 65 7.1. Normative References . . . . . . . . . . . . . . . . . . 6 66 7.2. Informative References . . . . . . . . . . . . . . . . . 6 67 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 6 69 1. Introduction 71 The IS-IS routing protocol IS-IS [ISO10589] currently supports a two 72 level hierarchy of abstraction. The fundamental unit of abstraction 73 is the 'area', which is a (hopefully) connected set of systems 74 running IS-IS at the same level. Level 1, the lowest level, is 75 abstracted by routers that participate in both Level 1 and Level 2, 76 and they inject area information into Level 2. Level 2 systems 77 seeking to access Level 1, use this abstraction to compute the 78 shortest path to the Level 1 area. The full topology database of 79 Level 1 is not injected into Level 2, only a summary of the address 80 space contained within the area, so the scalability of the Level 2 81 link state database is protected. 83 This works well if the Level 1 area is tangential to the Level 2 84 area. This also works well if there are a number of routers in both 85 Level 1 and Level 2 and they are adjacent, so Level 2 traffic will 86 never need to transit Level 1 only routers. Level 1 will not contain 87 any Level 2 topology, and Level 2 will only contain area abstractions 88 for Level 1. 90 Unfortunately, this scheme does not work so well if the Level 1 area 91 needs to provide transit for Level 2 traffic. For Level 2 shortest 92 path first (SPF) computations to work correctly, the transit topology 93 must also appear in the Level 2 link state database. This implies 94 that all routers that could possibly provide transit, plus any links 95 that might also provide Level 2 transit must also become part of the 96 Level 2 topology. If this is a relatively tiny portion of the Level 97 1 area, this is not onerous. 99 However, with today's data center topologies, this is problematic. A 100 common application is to use a Layer 3 Leaf-Spine (L3LS) topology, 101 which is a folded 3-stage Clos [Clos] fabric. It can also be thought 102 of as a complete bipartite graph. In such a topology, the desire is 103 to use Level 1 to contain the routing of the entire L3LS topology and 104 then to use Level 2 for the remainder of the network. Leaves in the 105 L3LS topology are appropriate for connection outside of the data 106 center itself, so they would provide connectivity for Level 2. If 107 there are multiple connections to Level 2 for redundancy, or to other 108 areas, these too would also be made to the leaves in the topology. 109 This creates a difficulty because there are now multiple Level 2 110 leaves in the topology, with connectivity between the leaves provide 111 by the spines. 113 Following the rules of IS-IS, all spine routers would necessarily be 114 part of the Level 2 topology, plus all links between a Level 2 leaf 115 and the spines. In the limit, where all leaves need to support Level 116 2, it implies that the entire L3LS topology becomes part of Level 2. 117 This is seriously problematic as it more than doubles the link state 118 database held in the L3LS topology and eliminates any benefits of the 119 hierarchy. 121 1.1. Requirements Language 123 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 124 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 125 document are to be interpreted as described in RFC 2119 [RFC2119]. 127 2. Area Abstraction 129 We propose to completely abstract away the Level 2 topology of the 130 Level 1 area, making the entire area look like a single system 131 directly connected to all of the area's Level 2 neighbors. By only 132 providing an abstraction of the topology, Level 2's requirement for 133 connectivity can be satisfied without the full overhead of the area's 134 internal topology. It then becomes the responsibility of the Level 1 135 area to ensure the forwarding connectivity that's advertised. 137 We propose to implement Area Abstraction by having a Level 2 138 pseudonode that represents the entire Level 1 area. This is the only 139 LSP from the area that will be injected into the overall Level 2 link 140 state database. 142 There are three classes of routers that we need to be concerned with 143 in this discussion: 145 Area Leader The Area Leader is a router in the Level 1 area that is 146 elected to represent the Level 1 area by injecting an LSP into the 147 Level 2 link state database. 149 Area Edge Router An Area Edge Router is a router that is part of the 150 Level 1 area as well as Level 2 and has at least one Level 2 151 interface outside of the Area. 153 Area Neighbor An Area Neighbor is a Level 2 router that is outside 154 of the Level 1 Area. 156 The Area Leader has several responsibilities. First, it must inject 157 a pseudonode identifier into the Level 1 link state database. This 158 is the Area Pseudonode Identifier. Second, the Area Leader must 159 generate the pseudonode LSP for the Area. 161 All Area Edge Routers learn the Area Pseudonode Identifier from the 162 Level 1 link state database and use that as the identifier in their 163 Level 2 IS-IS Hello PDUs on interfaces outside the Level 1 area. 164 Area Neighbors should then advertise an adjacency to the pseudonode. 165 The Area Edge Routers MUST also maintain an Level 2 adjacency with 166 the Area Leader, either via a direct link or via a tunnel. 168 Area Edge Routers MUST be able to provide transit to Level 2 traffic. 169 We propose that the Area Edge Routers use Segment Routing (SR) 170 [I-D.ietf-spring-segment-routing] and, during Level 2 SPF 171 computation, use the SR forwarding path to reach the exit Area Edge 172 Routers. To support SR, Area Edge Routers SHOULD advertise Adjacency 173 Segment Identifiers for their adjacency to the Area Leader. 175 2.1. Area Leader Election 177 The Area Leader is selected using the election mechanisms described 178 in Dynamic Flooding for IS-IS [I-D.li-lsr-dynamic-flooding]. 180 2.2. LSP Generation 182 For each of its Level 1 areas, Area Edge Routers generate a Level 2 183 LSP that includes adjacencies to any Area Neighbors and the Area 184 Leader. Unlike normal Level 2 operations, this LSP is not advertised 185 outside of the area and must be filtered by all Area Edge Routers to 186 not be flooded outside of the Level 1 Area. 188 The Area Leader uses the Level 2 LSPs generated by the Area Edge 189 Routers to generate the Area Pseudonode LSP. This LSP is originated 190 using the Area Pseudonode Identifier and includes adjacencies for all 191 of the Area Neighbors that have been advertised by the Area Edge 192 Routers. Since the Area Neighbors also advertise an adjacency to the 193 pseudonode, this will result in a bi-directional adjacency. The Area 194 Pseudonode LSP is the only LSP that is injected into the overall 195 Level 2 link state database, with all other Level 2 LSPs from the 196 area being filtered out at the area boundary. 198 2.3. Redundancy 200 If the Area Leader fails, another candidate may become Area Leader 201 and MUST regenerate the Area Pseudonode LSP. The failure of the Area 202 Leader is not visible outside of the area and appears to simply be an 203 update of the Area Pseudonode LSP. 205 3. Area Pseudonode TLV 207 The Area Pseudonode TLV allows the Area Leader to advertise the 208 existence of an Area Pseudonode Identifier. This TLV is injected 209 into one of the Area Leader's Level 1 LSPs. 211 The format of the Area Pseudonode TLV is: 213 0 1 2 214 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 215 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 216 | TLV Type | TLV Length | Pseudonode ID | 217 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 218 | Pseudonode ID continued ... 219 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 221 TLV Type: XXX 223 TLV Length: 2 + (length of a system ID + 1) 225 Pseudonode ID: A pseudonode ID, which is the length of a system ID 226 plus one octet. field. 228 4. Acknowledgements 230 The author would like to thank Bruno Decraene for his many helpful 231 comments. 233 5. IANA Considerations 235 This memo requests that IANA allocate and assign one code point from 236 the IS-IS TLV Codepoints registry for the Area Pseudonode TLV. 238 6. Security Considerations 240 This document introduces no new security issues. Security of routing 241 within a domain is already addressed as part of the routing protocols 242 themselves. This document proposes no changes to those security 243 architectures. 245 7. References 247 7.1. Normative References 249 [I-D.ietf-spring-segment-routing] 250 Filsfils, C., Previdi, S., Ginsberg, L., Decraene, B., 251 Litkowski, S., and R. Shakir, "Segment Routing 252 Architecture", draft-ietf-spring-segment-routing-15 (work 253 in progress), January 2018. 255 [I-D.li-lsr-dynamic-flooding] 256 Li, T., Psenak, P., Ginsberg, L., Przygienda, T., Cooper, 257 D., Jalil, L., and S. Dontula, "Dynamic Flooding on Dense 258 Graphs", draft-li-lsr-dynamic-flooding-02 (work in 259 progress), December 2018. 261 [ISO10589] 262 International Organization for Standardization, 263 "Intermediate System to Intermediate System Intra-Domain 264 Routing Exchange Protocol for use in Conjunction with the 265 Protocol for Providing the Connectionless-mode Network 266 Service (ISO 8473)", ISO/IEC 10589:2002, Nov. 2002. 268 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 269 Requirement Levels", BCP 14, RFC 2119, 270 DOI 10.17487/RFC2119, March 1997, 271 . 273 7.2. Informative References 275 [Clos] Clos, C., "A Study of Non-Blocking Switching Networks", 276 The Bell System Technical Journal Vol. 32(2), DOI 277 10.1002/j.1538-7305.1953.tb01433.x, March 1953, 278 . 280 Author's Address 281 Tony Li 282 Arista Networks 283 5453 Great America Parkway 284 Santa Clara, California 95054 285 USA 287 Email: tony.li@tony.li