idnits 2.17.1 draft-ietf-lsr-isis-area-proxy-02.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 seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (July 25, 2020) is 1343 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: '1' on line 872 == Outdated reference: A later version (-17) exists of draft-ietf-lsr-dynamic-flooding-07 == Outdated reference: A later version (-19) exists of draft-ietf-lsr-isis-srv6-extensions-08 Summary: 0 errors (**), 0 flaws (~~), 4 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 S. Chen 4 Intended status: Experimental V. Ilangovan 5 Expires: January 26, 2021 Arista Networks 6 G. Mishra 7 Verizon Inc. 8 July 25, 2020 10 Area Proxy for IS-IS 11 draft-ietf-lsr-isis-area-proxy-02 13 Abstract 15 Link state routing protocols have hierarchical abstraction already 16 built into them. However, when lower levels are used for transit, 17 they must expose their internal topologies to each other, leading to 18 scale issues. 20 To avoid this, this document discusses extensions to the IS-IS 21 routing protocol that would allow level 1 areas to provide transit, 22 yet only inject an abstraction of the level 1 topology into level 2. 23 Each level 1 area is represented as a single level 2 node, thereby 24 enabling greater scale. 26 Status of This Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at https://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on January 26, 2021. 43 Copyright Notice 45 Copyright (c) 2020 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (https://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 61 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 62 2. Area Proxy . . . . . . . . . . . . . . . . . . . . . . . . . 4 63 2.1. Segment Routing . . . . . . . . . . . . . . . . . . . . . 6 64 3. Inside Router Functions . . . . . . . . . . . . . . . . . . . 6 65 3.1. The Area Proxy TLV . . . . . . . . . . . . . . . . . . . 6 66 3.2. Level 2 SPF Computation . . . . . . . . . . . . . . . . . 7 67 4. Area Leader Functions . . . . . . . . . . . . . . . . . . . . 8 68 4.1. Area Leader Election . . . . . . . . . . . . . . . . . . 8 69 4.2. Redundancy . . . . . . . . . . . . . . . . . . . . . . . 8 70 4.3. Distributing Area Proxy Information . . . . . . . . . . . 8 71 4.3.1. The Area Proxy System Id Sub-TLV . . . . . . . . . . 8 72 4.3.2. The Area SID Sub-TLV . . . . . . . . . . . . . . . . 9 73 4.3.2.1. Flags . . . . . . . . . . . . . . . . . . . . . . 10 74 4.4. Proxy LSP Generation . . . . . . . . . . . . . . . . . . 10 75 4.4.1. The Protocols Supported TLV . . . . . . . . . . . . . 10 76 4.4.2. The Area Address TLV . . . . . . . . . . . . . . . . 11 77 4.4.3. The Dynamic Hostname TLV . . . . . . . . . . . . . . 11 78 4.4.4. The IS Neighbors TLV . . . . . . . . . . . . . . . . 11 79 4.4.5. The Extended IS Neighbors TLV . . . . . . . . . . . . 11 80 4.4.6. The MT Intermediate Systems TLV . . . . . . . . . . . 12 81 4.4.7. Reachability TLVs . . . . . . . . . . . . . . . . . . 12 82 4.4.8. The Router Capability TLV . . . . . . . . . . . . . . 13 83 4.4.9. The Multi-Topology TLV . . . . . . . . . . . . . . . 13 84 4.4.10. The SID/Label Binding and The Multi-Topology 85 SID/Label Binding SID TLV . . . . . . . . . . . . . . 13 86 4.4.11. The SRv6 Locator TLV . . . . . . . . . . . . . . . . 13 87 4.4.12. Traffic Engineering Information . . . . . . . . . . . 14 88 4.4.13. The Area SID . . . . . . . . . . . . . . . . . . . . 14 89 5. Inside Edge Router Functions . . . . . . . . . . . . . . . . 15 90 5.1. Generating L2 IIHs to Outside Routers . . . . . . . . . . 15 91 5.2. Filtering LSP information . . . . . . . . . . . . . . . . 15 92 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16 93 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 94 8. Security Considerations . . . . . . . . . . . . . . . . . . . 17 95 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 96 9.1. Normative References . . . . . . . . . . . . . . . . . . 17 97 9.2. Informative References . . . . . . . . . . . . . . . . . 19 98 9.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 19 99 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 101 1. Introduction 103 The IS-IS routing protocol IS-IS [ISO10589] currently supports a two- 104 level hierarchy of abstraction. The fundamental unit of abstraction 105 is the 'area', which is a (hopefully) connected set of systems 106 running IS-IS at the same level. Level 1, the lowest level, is 107 abstracted by routers that participate in both Level 1 and Level 2, 108 and they inject area information into Level 2. Level 2 systems 109 seeking to access Level 1, use this abstraction to compute the 110 shortest path to the Level 1 area. The full topology database of 111 Level 1 is not injected into Level 2, only a summary of the address 112 space contained within the area, so the scalability of the Level 2 113 Link State Database (LSDB) is protected. 115 This works well if the Level 1 area is tangential to the Level 2 116 area. This also works well if there are several routers in both 117 Level 1 and Level 2 and they are adjacent, so Level 2 traffic will 118 never need to transit Level 1 only routers. Level 1 will not contain 119 any Level 2 topology, and Level 2 will only contain area abstractions 120 for Level 1. 122 Unfortunately, this scheme does not work so well if the Level 1 only 123 area needs to provide transit for Level 2 traffic. For Level 2 124 shortest path first (SPF) computations to work correctly, the transit 125 topology must also appear in the Level 2 LSDB. This implies that all 126 routers that could provide transit, plus any links that might also 127 provide Level 2 transit must also become part of the Level 2 128 topology. If this is a relatively tiny portion of the Level 1 area, 129 this is not overly painful. 131 However, with today's data center topologies, this is problematic. A 132 common application is to use a Layer 3 Leaf-Spine (L3LS) topology, 133 which is a folded 3-stage Clos [Clos] fabric. It can also be thought 134 of as a complete bipartite graph. In such a topology, the desire is 135 to use Level 1 to contain the routing dynamics of the entire L3LS 136 topology and then to use Level 2 for the remainder of the network. 137 Leaves in the L3LS topology are appropriate for connection outside of 138 the data center itself, so they would provide connectivity for Level 139 2. If there are multiple connections to Level 2 for redundancy, or 140 other areas, these too would also be made to the leaves in the 141 topology. This creates a difficulty because there are now multiple 142 Level 2 leaves in the topology, with connectivity between the leaves 143 provided by the spines. 145 Following the current rules of IS-IS, all spine routers would 146 necessarily be part of the Level 2 topology, plus all links between a 147 Level 2 leaf and the spines. In the limit, where all leaves need to 148 support Level 2, it implies that the entire L3LS topology becomes 149 part of Level 2. This is seriously problematic as it more than 150 doubles the LSDB held in the L3LS topology and eliminates any 151 benefits of the hierarchy. 153 This document discusses the handling of IP traffic. Supporting MPLS 154 based traffic is a subject for future work. 156 1.1. Requirements Language 158 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 159 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 160 document are to be interpreted as described in BCP 14 [1] [RFC2119] 161 [RFC8174] when, and only when, they appear in all capitals, as shown 162 here. 164 2. Area Proxy 166 To address this, we propose to completely abstract away the details 167 of the Level 1 area topology within Level 2, making the entire area 168 look like a single proxy system directly connected to all of the 169 area's Level 2 neighbors. By only providing an abstraction of the 170 topology, Level 2's requirement for connectivity can be satisfied 171 without the full overhead of the area's internal topology. It then 172 becomes the responsibility of the Level 1 area to ensure the 173 forwarding connectivity that's advertised. 175 For this discussion, we'll consider a single Level 1 IS-IS area to be 176 the Inside Area, and the remainder of the Level 2 area is the Outside 177 Area. All routers within the Inside Area speak Level 1 and Level 2 178 IS-IS on all of the links within the topology. We propose to 179 implement Area Proxy by having a Level 2 Proxy Link State Protocol 180 Data Unit (PDU, LSP) that represents the entire Inside Area. We will 181 refer to this as the Proxy LSP. This is the only LSP from the area 182 that will be flooded into the overall Level 2 LSDB. 184 There are four classes of routers that we need to be concerned with 185 in this discussion: 187 Inside Router A router within the Inside Area that runs Level 1 and 188 Level 2 IS-IS. A router is recognized as an Inside Router by the 189 existence of its LSP in the Level 1 LSDB. 191 Area Leader The Area Leader is an Inside Router that is elected to 192 represent the Level 1 area by injecting the Proxy LSP into the 193 Level 2 LSDB. There may be multiple candidates for Area Leader, 194 but only one is elected at a given time. 196 Inside Edge Router An Inside Edge Router is an Inside Area Router 197 that has at least one Level 2 interface outside of the Inside 198 Area. An interface on an Inside Edge Router that is connected to 199 an Outside Edge Router is an Area Proxy Boundary. 201 Outside Edge Router An Outside Edge Router is a Level 2 router that 202 is outside of the Inside Area that has an adjacency with an Inside 203 Edge Router. 205 Inside Area 207 +--------+ +--------+ 208 | Inside |-----------------| Inside | 209 | Router | | Edge | 210 +--------+ +------------| Router | 211 | / +--------+ 212 | / | 213 +--------+ / =============|====== 214 | Area |/ || | 215 | Leader | || +---------+ 216 +--------+ || | Outside | 217 || | Edge | 218 || | Router | 219 || +---------+ 221 Outside Area 223 An example of router classes 225 All Inside Edge Routers learn the Area Proxy System Identifier from 226 the Level 1 LSDB and use that as the system identifier in their Level 227 2 IS-IS Hello PDUs (IIHs) on all Outside interfaces. Outside Edge 228 Routers should then advertise an adjacency to the Area Proxy System 229 Identifier. This allows all Outside Routers to use the Proxy LSP in 230 their SPF computations without seeing the full topology of the Inside 231 Area. 233 Area Proxy functionality assumes that all circuits on Inside Routers 234 are either Level 1-2 circuits within the Inside Area, or Level 2 235 circuits between Outside Edge Routers and Inside Edge Routers. 237 Area Proxy Boundary multi-access circuits (i.e. Ethernets in LAN 238 mode) with multiple Inside Edge Routers on them are not supported. 239 The Inside Edge Router on any boundary LAN MUST NOT flood Inside 240 Router LSPs on this link. Boundary LANs SHOULD NOT be enabled for 241 Level 1. An Inside Edge Router may be elected the DIS for a Boundary 242 LAN. In this case using the Area Proxy System Id as the basis for 243 the LAN pseudonode identifier could create a collision, so the 244 Insider Edge Router SHOULD compose the pseudonode identifier using 245 its native system identifier. 247 2.1. Segment Routing 249 If the Inside Area supports Segment Routing [RFC8402], then all 250 Inside Nodes MUST advertise an SR Global Block (SRGB). The first 251 value of the SRGB advertised by all Inside Nodes MUST start at the 252 same value. The range advertised for the area will be the minimum of 253 all Inside Nodes. 255 To support Segment Routing, the Area Leader will take the global SID 256 information found in the L1 LSDB and convey that to L2 through the 257 Proxy LSP. Prefixes with SID assignments will be copied to the Proxy 258 LSP. Adjacency SIDs for Outside Edge Nodes will be copied to the 259 Proxy LSP. 261 To further extend Segment Routing, it would be helpful to have a 262 segment that refers to the entire Inside Area. This allows a path to 263 refer to an area and have any node within that area accept and 264 forward the packet. In effect, this becomes an anycast SID that is 265 accepted by all Inside Edge Nodes. The information about this SID is 266 distributed in the Area SID Sub-TLV, as part of the Area Leader's 267 Area Proxy TLV (Section 4.3.2). The Inside Edge Nodes MUST establish 268 forwarding based on this SID. The Area Leader SHALL also include the 269 Area SID in the Proxy LSP so that the remainder of L2 can use it for 270 path construction. (Section 4.4.13). 272 3. Inside Router Functions 274 All Inside Routers run Level 1-2 IS-IS and must be explicitly 275 instructed to enable the Area Proxy functionality. To signal their 276 readiness to participate in Area Proxy functionality, they will 277 advertise the Area Proxy TLV. 279 3.1. The Area Proxy TLV 281 The Area Proxy TLV serves multiple functions: 283 The presence of the Area Proxy TLV in a node's LSP indicates that 284 the node is enabled for Area Proxy. 286 An LSP containing the Area Proxy TLV is also an Inside Node. All 287 Inside Nodes, including pseudonodes, MUST advertise the Area Proxy 288 TLV. 290 It is a container for sub-TLVs with Area Proxy information. 292 A node advertises the Area Proxy TLV in its L2 LSP. The Area Proxy 293 TLV is not used in the Proxy LSP. The format of the Area Proxy TLV 294 is: 296 0 1 2 297 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 298 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 299 | TLV Type | TLV Length | Sub-TLVs ... 300 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 302 TLV Type: YYY 304 TLV Length: length of the sub-TLVs 306 3.2. Level 2 SPF Computation 308 When Outside Routers perform a Level 2 SPF computation, they will use 309 the Proxy LSP for computing a path transiting the Inside Area. 310 Because the topology has been abstracted away, the cost for 311 transiting the Inside Area will be zero. 313 When Inside Routers perform a Level 2 SPF computation, they MUST 314 ignore the Proxy LSP. Further, because these systems do see the 315 Inside Area topology, the link metrics internal to the area are 316 visible. This could lead to different and possibly inconsistent SPF 317 results, potentially leading to forwarding loops. 319 To prevent this, the Inside Routers MUST consider the metrics of 320 links outside of the Inside Area (inter-area metrics) separately from 321 the metrics of the Inside Area links (intra-area metrics). Intra- 322 area metrics MUST be treated as less than any inter-area metric. 323 Thus, if two paths have different total inter-area metrics, the path 324 with the lower inter-area metric would be preferred, regardless of 325 any intra-area metrics involved. However, if two paths have equal 326 inter-area metrics, then the intra-area metrics would be used to 327 compare the paths. 329 Point-to-Point links between two Inside Routers are considered to be 330 Inside Area links. LAN links which have a pseudonode LSP in the 331 Level 1 LSDB are considered to be Inside Area links. 333 4. Area Leader Functions 335 The Area Leader has several responsibilities. First, it MUST inject 336 the Area Proxy System Identifier into the Level 1 LSDB. Second, the 337 Area Leader MUST generate the Proxy LSP for the Inside Area. 339 4.1. Area Leader Election 341 The Area Leader is selected using the election mechanisms and TLVs 342 described in Dynamic Flooding for IS-IS 343 [I-D.ietf-lsr-dynamic-flooding]. 345 4.2. Redundancy 347 If the Area Leader fails, another candidate may become Area Leader 348 and MUST regenerate the Proxy LSP. The failure of the Area Leader is 349 not visible outside of the area and appears to simply be an update of 350 the Proxy LSP. 352 For consistency, all Area Leader candidates SHOULD be configured with 353 the same Proxy System Id, Proxy Hostname, and any other information 354 that may be inserted into the Proxy LSP. 356 4.3. Distributing Area Proxy Information 358 The Area Leader is responsible for distributing information about the 359 area to all Inside Nodes. In particular, the Area Leader distributes 360 the Proxy System Id and the Area SID. This is done using two sub- 361 TLVs of the Area Proxy TLV. 363 4.3.1. The Area Proxy System Id Sub-TLV 365 The Area Proxy System Id Sub-TLV MUST be used by the Area Leader to 366 distribute the Area Proxy System Id. This is an additional system 367 identifier that is used by Inside Nodes and an indication that Area 368 Proxy is active. The format of this sub-TLV is: 370 0 1 2 371 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 372 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 373 | Type | Length | Proxy System ID | 374 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 375 | Proxy System Identifier continued | 376 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 378 Type: AAA 380 Length: length of a system ID (6) 381 Proxy System Identifier: the Area Proxy System Identifier. 383 The Area Leader MUST advertise the Area Proxy System Identifier Sub- 384 TLV when it observes that all Inside Routers are advertising the Area 385 Proxy TLV. Their advertisements indicate that they are individually 386 ready to perform Area Proxy functionality. The Area Leader then 387 advertises the Area Proxy System Identifier TLV to indicate that the 388 Inside Area MUST enable Area Proxy functionality. 390 Other candidates for Area Leader MAY also advertise the Area Proxy 391 System Identifier when they observe that all Inside Routers are 392 advertising the Area Proxy Router Capability. All candidates 393 advertising the Area Proxy System Identifier TLV MUST be advertising 394 the same system identifier. Multiple proxy system identifiers in a 395 single area is a misconfiguration and each unique occurrence SHOULD 396 be logged. 398 The Area Leader and other candidates for Area Leader MAY withdraw the 399 Area Proxy System Identifier when one or more Inside Routers are not 400 advertising the Area Proxy Router Capability. This will disable Area 401 Proxy functionality. However, before withdrawing the Area Proxy 402 System Identifier, an implementation SHOULD protect against 403 unnecessary churn from transients by delaying the withdrawal. The 404 amount of delay is implementation-dependent. 406 4.3.2. The Area SID Sub-TLV 408 The Area SID Sub-TLV allows the Area Leader to advertise a SID that 409 represents the entirety of the Inside Area to the Outside Area. This 410 sub-TLV is learned by all of the Inside Edge Nodes who should consume 411 this SID at forwarding time. The Area SID Sub-TLV has the format: 413 0 1 2 414 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 415 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 416 | Type | Length | Flags | 417 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 418 | SID/Index/Label (variable) | 419 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 421 where: 423 Type: BBB in the Area Proxy TLV, ZZZ in TLV 149 or 150. 425 Length: variable (1 + SID length) 427 Flags: 1 octet. 429 SID/Index/Label: as defined in [RFC8667] Section 2.1.1.1 431 4.3.2.1. Flags 433 The Flags octet is defined as follows: 435 0 1 2 3 4 5 6 7 436 +-+-+-+-+-+-+-+-+ 437 |F|V|L| | 438 +-+-+-+-+-+-+-+-+ 440 where: 442 F: Address-Family Flag. If unset, then this proxy SID is used 443 when forwarding IPv4-encapsulated traffic. If set, then this 444 proxy SID is used when forwarding IPv6-encapsulated traffic. 446 V: Value Flag. If set, then the proxy SID carries a value. 448 L: Local Flag. If set, then the value/index carried by the proxy 449 SID has local significance. 451 Other bits: MUST be zero when originated and ignored when 452 received. 454 4.4. Proxy LSP Generation 456 Each Inside Router generates a Level 2 LSP, and the Level 2 LSPs for 457 the Inside Edge Routers will include adjacencies to Outside Edge 458 Routers. Unlike normal Level 2 operations, these LSPs are not 459 advertised outside of the Inside Area and MUST be filtered by all 460 Inside Edge Routers to not be flooded to Outside Routers. Only the 461 Proxy LSP is injected into the overall Level 2 LSDB. 463 The Area Leader uses the Level 2 LSPs generated by the Inside Edge 464 Routers to generate the Proxy LSP. This LSP is originated using the 465 Area Proxy System Identifier. The Area Leader MAY also insert the 466 following additional TLVs into the Proxy LSP for additional 467 information for the Outside Area. LSPs generated by unreachable 468 nodes MUST NOT be considered. 470 4.4.1. The Protocols Supported TLV 472 The Area Leader SHOULD insert a Protocols Supported TLV (129) 473 [RFC1195] into the Proxy LSP. The values included in the TLV SHOULD 474 be the protocols supported by the Inside Area. 476 4.4.2. The Area Address TLV 478 The Area Leader SHOULD insert an Area Addresses TLV (1) [ISO10589] 479 into the Proxy LSP. 481 4.4.3. The Dynamic Hostname TLV 483 It is RECOMMENDED that the Area Leader insert the Dynamic Hostname 484 TLV (137) [RFC5301] into the Proxy LSP. The contents of the hostname 485 may be specified by configuration. The presence of the hostname 486 helps to simplify debugging the network. 488 4.4.4. The IS Neighbors TLV 490 The Area Leader MAY insert the IS Neighbors TLV (2) [ISO10589] into 491 the Proxy LSP for Outside Edge Routers. The Area Leader learns of 492 the Outside Edge Routers by examining the LSPs generated by the 493 Inside Edge Routers copying any IS Neighbors TLVs referring to 494 Outside Edge Routers into the Proxy LSP. Since the Outside Edge 495 Routers advertise an adjacency to the Area Proxy System Identifier, 496 this will result in a bi-directional adjacency. 498 An entry for a neighbor in both the IS Neighbors TLV and the Extended 499 IS Neighbors would be functionally redundant, so the Area Leader 500 SHOULD NOT do this. 502 4.4.5. The Extended IS Neighbors TLV 504 The Area Leader MAY insert the Extended IS Reachability TLV (22) 505 [RFC5305] into the Proxy LSP. The Area Leader SHOULD copy each 506 Extended IS Reachability TLV advertised by an Inside Edge Router 507 about an Outside Edge Router into the Proxy LSP. 509 If the Inside Area supports Segment Routing and Segment Routing 510 selects a SID where the L-Flag is unset, then the Area Lead SHOULD 511 include an Adjacency Segment Identifier sub-TLV (31) [RFC8667] using 512 the selected SID. 514 If the inside area supports SRv6, the Area Leader SHOULD copy the 515 "SRv6 End.X SID" and "SRv6 LAN End.X SID" sub-TLVs of the extended IS 516 reachability TLVs advertised by Inside Edge Routers about Outside 517 Edge Routers. 519 If the inside area supports Traffic Engineering (TE), the Area Leader 520 SHOULD copy TE related sub-TLVs [RFC5305] Section 3 to each Extended 521 IS Reachability TLV in the Proxy LSP. 523 4.4.6. The MT Intermediate Systems TLV 525 If the Inside Area supports Multi-Topology, then the Area Leader 526 SHOULD copy each Outside Edge Router advertisement that is advertised 527 by an Inside Edge Router in a MT Intermediate Systems TLV into the 528 Proxy LSP. 530 4.4.7. Reachability TLVs 532 The Area Leader SHOULD insert additional TLVs describing any routing 533 prefixes that should be advertised on behalf of the area. These 534 prefixes may be learned from the Level 1 LSDB, Level 2 LSDB, or 535 redistributed from another routing protocol. This applies to all of 536 various types of TLVs used for prefix advertisement: 538 IP Internal Reachability Information TLV (128) [RFC1195] 540 IP External Reachability Information TLV (130) [RFC1195] 542 Extended IP Reachability TLV (135) [RFC5305] 544 IPv6 Reachability TLV (236) [RFC5308] 546 Multi-Topology Reachable IPv4 Prefixes TLV (235) [RFC5120] 548 Multi-Topology Reachable IPv6 Prefixes TLV (237) [RFC5120] 550 For TLVs in the Level 1 LSDB, for a given TLV type and prefix, the 551 Area Leader SHOULD select the TLV with the lowest metric and copy 552 that TLV into the Proxy LSP. 554 When examining the Level 2 LSDB for this function, the Area Leader 555 SHOULD only consider TLVs advertised by Inside Routers. Further, for 556 prefixes that represent Boundary links, the Area Leader SHOULD copy 557 all TLVs that have unique sub-TLV contents. 559 If the Inside Area supports Segment Routing and the selected TLV 560 includes a Prefix Segment Identifier sub-TLV (3) [RFC8667], then the 561 sub-TLV SHOULD be copied as well. The P-Flag SHOULD be set in the 562 copy of the sub-TLV to indicate that penultimate hop popping SHOULD 563 NOT be performed for this prefix. The E-Flag SHOULD be reset in the 564 copy of the sub-TLV to indicate that an explicit NULL is not 565 required. The R-Flag SHOULD simply be copied. 567 4.4.8. The Router Capability TLV 569 The Area Leader MAY insert the Router Capability TLV (242) [RFC7981] 570 into the Proxy LSP. If Segment Routing is supported by the inside 571 area, as indicated by the presence of an SRGB being advertised by all 572 Inside Nodes, then the Area Leader SHOULD advertise an SR- 573 Capabilities sub-TLV (2) [RFC8667] with an SRGB. The first value of 574 the SRGB is the same value as the first value advertised by all 575 Inside Nodes. The range advertised for the area will be the minimum 576 of all ranges advertised by Inside Nodes. The Area Leader SHOULD use 577 its own Router Id in the Router Capability TLV. 579 If SRv6 Capability sub-TLV [RFC7981] is advertised by all Inside 580 Routers, the Area Leader should insert an SRv6 Capability sub-TLV in 581 the Router Capability TLV. Each flag in the SRv6 Capability sub-TLV 582 should be set if the flag is set by all Inside Routers. 584 If the Node Maximum SID Depth (MSD) sub-TLV [RFC8491] is advertised 585 by all Inside Routers, the Area Leader should advertise common MSD 586 types and the smallest supported MSD values for each type. 588 4.4.9. The Multi-Topology TLV 590 If the Inside Area supports multi-topology, then the Area Leader 591 SHOULD insert the Multi-Topology TLV (229) [RFC5120], including the 592 topologies supported by the Inside Nodes. 594 If any Inside Node is advertising the 'O' (Overload) bit for a given 595 topology, then the Area Leader MUST advertise the 'O' bit for that 596 topology. If any Inside Node is advertising the 'A' (Attach) bit for 597 a given topology, then the Area Leader MUST advertise the 'A' bit for 598 that topology. 600 4.4.10. The SID/Label Binding and The Multi-Topology SID/Label Binding 601 SID TLV 603 If an Inside Node advertises the SID/Label Binding or Multi-Topology 604 SID/Label Binding SID TLV [RFC8667], then the Area Leader MAY copy 605 the TLV to the Proxy LSP. 607 4.4.11. The SRv6 Locator TLV 609 If the inside area supports SRv6, the Area Leader SHOULD copy all 610 SRv6 locator TLVs [I-D.ietf-lsr-isis-srv6-extensions] advertised by 611 Inside Routers to the Proxy LSP. 613 4.4.12. Traffic Engineering Information 615 If the inside area supports TE, the Area Leader SHOULD advertise a TE 616 Router ID TLV (134) [RFC5305] in the Proxy LSP. It SHOULD copy the 617 Shared Risk Link Group (SRLS) TLVs (138) [RFC5307] advertised by 618 Inside Edge Routers about links to Outside Edge Routers. 620 If the inside area supports IPv6 TE, the Area Leader SHOULD advertise 621 an IPv6 TE Router ID TLV (140) [RFC6119] in the Proxy LSP. It SHOULD 622 also copy the IPv6 SRLG TLVs (139) [RFC6119] advertised by Inside 623 Edge Routers about links to Outside Edge Routers. 625 4.4.13. The Area SID 627 When SR is enabled, it may be useful to advertise an Area SID which 628 will direct traffic to any of the Inside Edge Routers. The Binding/ 629 MT Binding TLVs described in RFC 8667 Section 2.4 are used to 630 advertise such a SID. 632 The following extensions to the Binding TLV are defined in order to 633 support Area SID: 635 A new flag is defined: 637 T-flag: The SID directs traffic to an area. (Bit 5) 639 When T-flag is set: 641 M and A flag MUST be clear 643 Range and Prefix are ignored 645 Section 2.4.4 of RFC 8667 is altered to say: 647 "The Prefix-SID sub-TLV MUST be present in the SID/Label 648 Binding TLV when the M-Flag and T-flag are both clear. The 649 Prefix-SID sub-TLV MUST NOT be present when either the M-Flag 650 or T-flag are set." 652 Regarding the SID/Label sub-TLV Section 2.4.5 of RFC 8667 is 653 altered to say: 655 "It MUST be present in the SID/Label Binding TLV when either 656 the M-Flag or T-flag is set in the Flags field of the parent 657 TLV." 659 When used in support of Area Proxy, the SID advertised MUST be 660 identical to the Area SID (Section 4.3.2). Other uses of the Area 661 SID are outside the scope of this document. Documents which define 662 other use cases for the Area SID MUST specify whether the SID value 663 should be the same or different from that used in support of Area 664 Proxy. 666 If the Area Leader is advertising an Area SID in the Area SID sub-TLV 667 of the Area Proxy TLV, then the Area Leader SHOULD advertise the Area 668 SID in the Proxy LSP. The advertisement in the Proxy LSP informs the 669 remainder of the network that packets directed to the SID will be 670 forwarded by one of the Inside Edge Nodes and the Area SID will be 671 consumed. 673 5. Inside Edge Router Functions 675 The Inside Edge Router has two additional and important functions. 676 First, it MUST generate IIHs that appear to have come from the Area 677 Proxy System Identifier. Second, it MUST filter the L2 LSPs, Partial 678 Sequence Number PDUs (PSNPs), and Complete Sequence Number PDUs 679 (CSNPs) that are being advertised to Outside Routers. 681 5.1. Generating L2 IIHs to Outside Routers 683 The Inside Edge Router has one or more Level 2 interfaces to Outside 684 Routers. These may be identified by explicit configuration or by the 685 fact that they are not also Level 1 circuits. On these Level 2 686 interfaces, the Inside Edge Router MUST NOT send an IIH until it has 687 learned the Area Proxy System Id from the Area Leader. Then, once it 688 has learned the Area Proxy System Id, it MUST generate its IIHs on 689 the circuit using the Proxy System Id as the source of the IIH. 691 Using the Proxy System Id causes the Outside Router to advertise an 692 adjacency to the Proxy System Id, not to the Inside Edge Router, 693 which supports the proxy function. The normal system id of the 694 Inside Edge Router MUST NOT be used as it will cause unnecessary 695 adjacencies to form and subsequently flap. 697 5.2. Filtering LSP information 699 For the area proxy abstraction to be effective the L2 LSPs generated 700 by the Inside Routers MUST be restricted to the Inside Area. The 701 Inside Routers know which system ids are members of the Inside Area 702 based on the advertisement of the Area Proxy TLV. To prevent 703 unwanted LSP information from escaping the Inside Area, the Inside 704 Edge Router MUST perform filtering of LSP flooding, CSNPs, and PSNPs. 705 Specifically: 707 A Level 2 LSP with a source system identifier that is found in the 708 Level 1 LSDB MUST NOT be flooded to an Outside Router. 710 A Level 2 LSP that contains the Area Proxy TLV MUST NOT be flooded 711 to an Outside Router. 713 A Level 2 CSNP sent to an Outside Router MUST NOT contain any 714 information about an LSP with a system identifier found in the 715 Level 1 LSDB. If an Inside Edge Router filters a CSNP and there 716 is no remaining content, then the CSNP MUST NOT be sent. The 717 source address of the CSNP MUST be the Area Proxy System Id. 719 A Level 2 PSNP sent to an Outside Router MUST NOT contain any 720 information about an LSP with a system identifier found in the 721 Level 1 LSDB. If an Inside Edge Router filters a PSNP and there 722 is no remaining content, then the PSNP MUST NOT be sent. The 723 source address of the PSNP MUST be the Area Proxy System Id. 725 6. Acknowledgments 727 The authors would like to thank Bruno Decraene and Gunter Van De 728 Velde for their many helpful comments. The authors would also like 729 to thank a small group that wishes to remain anonymous for their 730 valuable contributions. 732 7. IANA Considerations 734 This memo requests that IANA allocate and assign one code point from 735 the IS-IS TLV Codepoints registry for the Area Proxy TLV (YYY). The 736 registry fields should be: IIH:n, LSP:y, SNP:n, Purge:n. 738 In association with this, this memo requests that IANA create a 739 registry for code points for the sub-TLVs of the Area Proxy TLV. 741 Name of the registry: Sub-TLVs for TLV YYY (Area Proxy TLV) 743 Required information for registrations: Temporary registrations 744 may be made under the Early IANA Allocation of Standards Track 745 Code Points policy. [RFC7120] Permanent registrations require the 746 publication of an RFC describing the usage of the code point. 748 Applicable registration policy: RFC Required and Expert Review. 749 We propose the initial experts be Chris Hopps, Tony Li, and Sarah 750 Chen. 752 Size, format, and syntax of registry entries: Value (0-255), Name, 753 and Reference 755 Initial assignments and reservations: IANA is requested to assign 756 the following code points: 758 +-------+------------------------------+---------------+ 759 | Value | Name | Reference | 760 +-------+------------------------------+---------------+ 761 | AAA | Area Proxy System Identifier | This document | 762 | BBB | Area SID | This document | 763 +-------+------------------------------+---------------+ 765 This memo also requests that IANA allocate a code point (ZZZ) for the 766 Area SID subTLV in the registry for Sub-TLVs for TLVs 149 and 150. 768 8. Security Considerations 770 This document introduces no new security issues. Security of routing 771 within a domain is already addressed as part of the routing protocols 772 themselves. This document proposes no changes to those security 773 architectures. 775 9. References 777 9.1. Normative References 779 [I-D.ietf-lsr-dynamic-flooding] 780 Li, T., Psenak, P., Ginsberg, L., Chen, H., Przygienda, 781 T., Cooper, D., Jalil, L., Dontula, S., and G. Mishra, 782 "Dynamic Flooding on Dense Graphs", draft-ietf-lsr- 783 dynamic-flooding-07 (work in progress), June 2020. 785 [I-D.ietf-lsr-isis-srv6-extensions] 786 Psenak, P., Filsfils, C., Bashandy, A., Decraene, B., and 787 Z. Hu, "IS-IS Extension to Support Segment Routing over 788 IPv6 Dataplane", draft-ietf-lsr-isis-srv6-extensions-08 789 (work in progress), April 2020. 791 [ISO10589] 792 International Organization for Standardization, 793 "Intermediate System to Intermediate System Intra-Domain 794 Routing Exchange Protocol for use in Conjunction with the 795 Protocol for Providing the Connectionless-mode Network 796 Service (ISO 8473)", ISO/IEC 10589:2002, Nov. 2002. 798 [RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and 799 dual environments", RFC 1195, DOI 10.17487/RFC1195, 800 December 1990, . 802 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 803 Requirement Levels", BCP 14, RFC 2119, 804 DOI 10.17487/RFC2119, March 1997, 805 . 807 [RFC5120] Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi 808 Topology (MT) Routing in Intermediate System to 809 Intermediate Systems (IS-ISs)", RFC 5120, 810 DOI 10.17487/RFC5120, February 2008, 811 . 813 [RFC5301] McPherson, D. and N. Shen, "Dynamic Hostname Exchange 814 Mechanism for IS-IS", RFC 5301, DOI 10.17487/RFC5301, 815 October 2008, . 817 [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic 818 Engineering", RFC 5305, DOI 10.17487/RFC5305, October 819 2008, . 821 [RFC5307] Kompella, K., Ed. and Y. Rekhter, Ed., "IS-IS Extensions 822 in Support of Generalized Multi-Protocol Label Switching 823 (GMPLS)", RFC 5307, DOI 10.17487/RFC5307, October 2008, 824 . 826 [RFC5308] Hopps, C., "Routing IPv6 with IS-IS", RFC 5308, 827 DOI 10.17487/RFC5308, October 2008, 828 . 830 [RFC6119] Harrison, J., Berger, J., and M. Bartlett, "IPv6 Traffic 831 Engineering in IS-IS", RFC 6119, DOI 10.17487/RFC6119, 832 February 2011, . 834 [RFC7981] Ginsberg, L., Previdi, S., and M. Chen, "IS-IS Extensions 835 for Advertising Router Information", RFC 7981, 836 DOI 10.17487/RFC7981, October 2016, 837 . 839 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 840 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 841 May 2017, . 843 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 844 Decraene, B., Litkowski, S., and R. Shakir, "Segment 845 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 846 July 2018, . 848 [RFC8491] Tantsura, J., Chunduri, U., Aldrin, S., and L. Ginsberg, 849 "Signaling Maximum SID Depth (MSD) Using IS-IS", RFC 8491, 850 DOI 10.17487/RFC8491, November 2018, 851 . 853 [RFC8667] Previdi, S., Ed., Ginsberg, L., Ed., Filsfils, C., 854 Bashandy, A., Gredler, H., and B. Decraene, "IS-IS 855 Extensions for Segment Routing", RFC 8667, 856 DOI 10.17487/RFC8667, December 2019, 857 . 859 9.2. Informative References 861 [Clos] Clos, C., "A Study of Non-Blocking Switching Networks", 862 The Bell System Technical Journal Vol. 32(2), DOI 863 10.1002/j.1538-7305.1953.tb01433.x, March 1953, 864 . 866 [RFC7120] Cotton, M., "Early IANA Allocation of Standards Track Code 867 Points", BCP 100, RFC 7120, DOI 10.17487/RFC7120, January 868 2014, . 870 9.3. URIs 872 [1] https://tools.ietf.org/html/bcp14 874 Authors' Addresses 876 Tony Li 877 Arista Networks 878 5453 Great America Parkway 879 Santa Clara, California 95054 880 USA 882 Email: tony.li@tony.li 884 Sarah Chen 885 Arista Networks 886 5453 Great America Parkway 887 Santa Clara, California 95054 888 USA 890 Email: sarahchen@arista.com 892 Vivek Ilangovan 893 Arista Networks 894 5453 Great America Parkway 895 Santa Clara, California 95054 896 USA 898 Email: ilangovan@arista.com 899 Gyan S. Mishra 900 Verizon Inc. 902 13101 Columbia Pike 904 Silver Spring 905 , 907 MD 20904 909 United States of America 911 Phone: 912 301 502-1347 914 Email: 915 gyan.s.mishra@verizon.com