idnits 2.17.1 draft-ietf-lsr-isis-area-proxy-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 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 (June 29, 2020) is 1394 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: '1' on line 855 == Outdated reference: A later version (-18) 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: December 31, 2020 Arista Networks 6 G. Mishra 7 Verizon Inc. 8 June 29, 2020 10 Area Proxy for IS-IS 11 draft-ietf-lsr-isis-area-proxy-00 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 December 31, 2020. 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 . . . . . . . . . . . . . . . . . . . . . 5 64 3. Inside Router Functions . . . . . . . . . . . . . . . . . . . 6 65 3.1. The Area Proxy Router Capability . . . . . . . . . . . . 6 66 3.2. Level 2 SPF Computation . . . . . . . . . . . . . . . . . 6 67 3.3. The Inside Node TLV . . . . . . . . . . . . . . . . . . . 7 68 4. Area Leader Functions . . . . . . . . . . . . . . . . . . . . 7 69 4.1. Area Leader Election . . . . . . . . . . . . . . . . . . 7 70 4.2. Redundancy . . . . . . . . . . . . . . . . . . . . . . . 8 71 4.3. The Area Proxy TLV . . . . . . . . . . . . . . . . . . . 8 72 4.3.1. The Area Proxy System Id Sub-TLV . . . . . . . . . . 8 73 4.3.2. The Area Segment SID Sub-TLV . . . . . . . . . . . . 9 74 4.4. Area Proxy LSP Generation . . . . . . . . . . . . . . . . 10 75 4.4.1. The Protocols Supported TLV . . . . . . . . . . . . . 10 76 4.4.2. The Area Address TLV . . . . . . . . . . . . . . . . 10 77 4.4.3. The Dynamic Hostname TLV . . . . . . . . . . . . . . 10 78 4.4.4. The IS Neighbors TLV . . . . . . . . . . . . . . . . 10 79 4.4.5. The Extended IS Neighbors TLV . . . . . . . . . . . . 11 80 4.4.6. The MT Intermediate Systems TLV . . . . . . . . . . . 11 81 4.4.7. Reachability TLVs . . . . . . . . . . . . . . . . . . 11 82 4.4.8. The Router Capability TLV . . . . . . . . . . . . . . 12 83 4.4.9. The Multi-Topology TLV . . . . . . . . . . . . . . . 12 84 4.4.10. The SID/Label Binding and The Multi-Topology 85 SID/Label Binding SID TLV . . . . . . . . . . . . . . 13 86 4.4.11. The Area Segment SID TLV . . . . . . . . . . . . . . 13 87 4.4.11.1. Flags . . . . . . . . . . . . . . . . . . . . . 14 88 4.4.12. The SRv6 Locator TLV . . . . . . . . . . . . . . . . 14 89 4.4.13. Traffic Engineering Information . . . . . . . . . . . 14 90 5. Inside Edge Router Functions . . . . . . . . . . . . . . . . 14 91 5.1. Generating L2 IIHs to Outside Routers . . . . . . . . . . 15 92 5.2. Filtering LSP information . . . . . . . . . . . . . . . . 15 93 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15 94 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 95 8. Security Considerations . . . . . . . . . . . . . . . . . . . 16 96 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 97 9.1. Normative References . . . . . . . . . . . . . . . . . . 17 98 9.2. Informative References . . . . . . . . . . . . . . . . . 18 99 9.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 19 100 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 102 1. Introduction 104 The IS-IS routing protocol IS-IS [ISO10589] currently supports a two- 105 level hierarchy of abstraction. The fundamental unit of abstraction 106 is the 'area', which is a (hopefully) connected set of systems 107 running IS-IS at the same level. Level 1, the lowest level, is 108 abstracted by routers that participate in both Level 1 and Level 2, 109 and they inject area information into Level 2. Level 2 systems 110 seeking to access Level 1, use this abstraction to compute the 111 shortest path to the Level 1 area. The full topology database of 112 Level 1 is not injected into Level 2, only a summary of the address 113 space contained within the area, so the scalability of the Level 2 114 Link State Database (LSDB) is protected. 116 This works well if the Level 1 area is tangential to the Level 2 117 area. This also works well if there are several routers in both 118 Level 1 and Level 2 and they are adjacent, so Level 2 traffic will 119 never need to transit Level 1 only routers. Level 1 will not contain 120 any Level 2 topology, and Level 2 will only contain area abstractions 121 for Level 1. 123 Unfortunately, this scheme does not work so well if the Level 1 only 124 area needs to provide transit for Level 2 traffic. For Level 2 125 shortest path first (SPF) computations to work correctly, the transit 126 topology must also appear in the Level 2 LSDB. This implies that all 127 routers that could provide transit, plus any links that might also 128 provide Level 2 transit must also become part of the Level 2 129 topology. If this is a relatively tiny portion of the Level 1 area, 130 this is not overly painful. 132 However, with today's data center topologies, this is problematic. A 133 common application is to use a Layer 3 Leaf-Spine (L3LS) topology, 134 which is a folded 3-stage Clos [Clos] fabric. It can also be thought 135 of as a complete bipartite graph. In such a topology, the desire is 136 to use Level 1 to contain the routing dynamics of the entire L3LS 137 topology and then to use Level 2 for the remainder of the network. 138 Leaves in the L3LS topology are appropriate for connection outside of 139 the data center itself, so they would provide connectivity for Level 140 2. If there are multiple connections to Level 2 for redundancy, or 141 other areas, these too would also be made to the leaves in the 142 topology. This creates a difficulty because there are now multiple 143 Level 2 leaves in the topology, with connectivity between the leaves 144 provided by the spines. 146 Following the current rules of IS-IS, all spine routers would 147 necessarily be part of the Level 2 topology, plus all links between a 148 Level 2 leaf and the spines. In the limit, where all leaves need to 149 support Level 2, it implies that the entire L3LS topology becomes 150 part of Level 2. This is seriously problematic as it more than 151 doubles the LSDB held in the L3LS topology and eliminates any 152 benefits of the hierarchy. 154 This document discusses the handling of IP traffic. Supporting MPLS 155 based traffic is a subject for future work. 157 1.1. Requirements Language 159 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 160 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 161 document are to be interpreted as described in BCP 14 [1] [RFC2119] 162 [RFC8174] when, and only when, they appear in all capitals, as shown 163 here. 165 2. Area Proxy 167 To address this, we propose to completely abstract away the details 168 of the Level 1 area topology within Level 2, making the entire area 169 look like a single proxy system directly connected to all of the 170 area's Level 2 neighbors. By only providing an abstraction of the 171 topology, Level 2's requirement for connectivity can be satisfied 172 without the full overhead of the area's internal topology. It then 173 becomes the responsibility of the Level 1 area to ensure the 174 forwarding connectivity that's advertised. 176 For this discussion, we'll consider a single Level 1 IS-IS area to be 177 the Inside Area, and the remainder of the Level 2 area is the Outside 178 Area. All routers within the Inside Area speak Level 1 and Level 2 179 IS-IS on all of the links within the topology. We propose to 180 implement Area Proxy by having a Level 2 Proxy Link State Protocol 181 Data Unit (PDU, LSP) that represents the entire Inside Area. This is 182 the only LSP from the area that will be flooded into the overall 183 Level 2 LSDB. 185 There are four classes of routers that we need to be concerned with 186 in this discussion: 188 Inside Router A router within the Inside Area that runs Level 1 and 189 Level 2 IS-IS. A router is recognized as an Inside Router by the 190 existence of its LSP in the Level 1 LSDB. 192 Area Leader The Area Leader is an Inside Router that is elected to 193 represent the Level 1 area by injecting the Proxy LSP into the 194 Level 2 LSDB. There may be multiple candidates for Area Leader, 195 but only one is elected at a given time. 197 Inside Edge Router An Inside Edge Router is an Inside Area Router 198 that has at least one Level 2 interface outside of the Inside 199 Area. An interface on an Inside Edge Router that is connected to 200 an Outside Edge Router is an Area Proxy Boundary. 202 Outside Edge Router An Outside Edge Router is a Level 2 router that 203 is outside of the Inside Area that has an adjacency with an Inside 204 Edge Router. 206 All Inside Edge Routers learn the Area Proxy System Identifier from 207 the Level 1 LSDB and use that as the system identifier in their Level 208 2 IS-IS Hello PDUs (IIHs) on all Outside interfaces. Outside Edge 209 Routers should then advertise an adjacency to the Area Proxy System 210 Identifier. This allows all Outside Routers to use the Proxy LSP in 211 their SPF computations without seeing the full topology of the Inside 212 Area. 214 Area Proxy functionality assumes that all circuits on Inside Routers 215 are either Level 1-2 circuits within the Inside Area, or Level 2 216 circuits between Outside Edge Routers and Inside Edge Routers. 218 Area Proxy Boundary multi-access circuits (i.e. Ethernets in LAN 219 mode) with multiple Inside Edge Routers on them are not supported. 220 The Inside Edge Router on any boundary LAN MUST NOT flood Inside 221 Router LSPs on this link. Boundary LANs SHOULD NOT be enabled for 222 Level 1. An Inside Edge Router may be elected the DIS for a Boundary 223 LAN. In this case using the Area Proxy System Id as the basis for 224 the LAN pseudonode identifier could create a collision, so the 225 Insider Edge Router SHOULD compose the pseudonode identifier using 226 its native system identifier. 228 2.1. Segment Routing 230 If the Inside Area supports Segment Routing [RFC8402], then all 231 Inside Nodes MUST advertise an SR Global Block (SRGB). The first 232 value of the SRGB advertised by all Inside Nodes MUST start at the 233 same value. The range advertised for the area will be the minimum of 234 all Inside Nodes. 236 To support Segment Routing, the Area Leader will take the global SID 237 information found in the L1 LSDB and convey that to L2 through the 238 Proxy LSP. Prefixes with SID assignments will be copied to the Proxy 239 LSP. Adjacency SIDs for Outside Edge Nodes will be copied to the 240 Proxy LSP. 242 To further extend Segment Routing, it would be helpful to have a SID 243 that refers to the entire Inside Area. This allows a path to refer 244 to an area and have any node within that area accept and forward the 245 packet. In effect, this becomes an anycast SID that is accepted by 246 all Inside Edge Nodes. The information about this SID is distributed 247 in the Area Segment SID Sub-TLV, as part of the Area Leader's Area 248 Proxy TLV (Section 4.3.2). The Inside Edge Nodes MUST establish 249 forwarding based on this SID. The Area Leader SHALL also include the 250 Area Segment SID TLV in the Area Proxy LSP so that the remainder of 251 L2 can use it for path construction (Section 4.4.11). These two TLVs 252 are similar in structure, so care must be taken not to confuse them. 254 3. Inside Router Functions 256 All Inside Routers run Level 1-2 IS-IS and must be explicitly 257 instructed to enable the Area Proxy functionality. To signal their 258 readiness to participate in Area Proxy functionality, they will 259 advertise the Area Proxy Router Capability as part of its Level 1 260 Router Capability TLV. 262 3.1. The Area Proxy Router Capability 264 The Area Proxy Router Capability is a sub-TLV of the Router 265 Capability TLV [RFC7981] and has the following format: 267 0 1 268 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 269 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 270 | TLV Type | TLV Length | 271 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 273 TLV Type: LLL 275 TLV Length: 0 277 A router advertising this TLV indicates that it is running Level 1-2 278 and is prepared to perform Area Proxy functions. 280 3.2. Level 2 SPF Computation 282 When Outside Routers perform a Level 2 SPF computation, they will use 283 the Area Proxy LSP for computing a path transiting the Inside Area. 284 Because the topology has been abstracted away, the cost for 285 transiting the Inside Area will be zero. 287 When Inside Routers perform a Level 2 SPF computation, they MUST 288 ignore the Area Proxy LSP. Further, because these systems do see the 289 Inside Area topology, the link metrics internal to the area are 290 visible. This could lead to different and possibly inconsistent SPF 291 results, potentially leading to forwarding loops. 293 To prevent this, the Inside Routers MUST consider the metrics of 294 links outside of the Inside Area (inter-area metrics) separately from 295 the metrics of the Inside Area links (intra-area metrics). Intra- 296 area metrics MUST be treated as less than any inter-area metric. 297 Thus, if two paths have different total inter-area metrics, the path 298 with the lower inter-area metric would be preferred, regardless of 299 any intra-area metrics involved. However, if two paths have equal 300 inter-area metrics, then the intra-area metrics would be used to 301 compare the paths. 303 Point-to-Point links between two Inside Routers are considered to be 304 Inside Area links. LAN links which have a pseudonode LSP in the 305 Level 1 LSDB are considered to be Inside Area links. 307 3.3. The Inside Node TLV 309 To simplify determining which nodes belong to the Inside Area, all 310 Inside Nodes MUST insert the Inside Node TLV into their LSP and into 311 any Inside Area pseudonode LSPs. The format of the Inside Node TLV 312 is: 314 0 1 315 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 316 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 317 | Type | Length | 318 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 320 Type: ZZZ 322 Length: Zero (0) 324 4. Area Leader Functions 326 The Area Leader has several responsibilities. First, it MUST inject 327 the Area Proxy System Identifier into the Level 1 LSDB. Second, the 328 Area Leader MUST generate the Proxy LSP for the Inside Area. 330 4.1. Area Leader Election 332 The Area Leader is selected using the election mechanisms and TLVs 333 described in Dynamic Flooding for IS-IS 334 [I-D.ietf-lsr-dynamic-flooding]. 336 4.2. Redundancy 338 If the Area Leader fails, another candidate may become Area Leader 339 and MUST regenerate the Area Proxy LSP. The failure of the Area 340 Leader is not visible outside of the area and appears to simply be an 341 update of the Area Proxy LSP. 343 For consistency, all Area Leader candidates SHOULD be configured with 344 the same Proxy System Id, Proxy Hostname, and any other information 345 that may be inserted into the Proxy LSP. 347 4.3. The Area Proxy TLV 349 The Area Proxy TLV is a container for sub-TLVs with Area Proxy 350 Information. This TLV is injected into the Area Leader's Level 1 351 LSP. 353 The format of the Area Proxy TLV is: 355 0 1 2 356 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 357 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 358 | TLV Type | TLV Length | Sub-TLVs ... 359 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 361 TLV Type: YYY 363 TLV Length: length of the sub-TLVs 365 4.3.1. The Area Proxy System Id Sub-TLV 367 The Area Proxy System Id Sub-TLV MUST be used by the Area Leader to 368 distribute the Area Proxy System Id. This is an additional system 369 identifier that is used by Inside Nodes. The format of this sub-TLV 370 is: 372 0 1 2 373 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 374 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 375 | Type | Length | Proxy System ID | 376 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 377 | Proxy System Identifier continued | 378 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 380 Type: AAA 382 Length: length of a system ID (6) 383 Proxy System Identifier: the Area Proxy System Identifier. 385 The Area Leader SHOULD advertise the Area Proxy System Identifier 386 Sub-TLV when it observes that all Inside Routers are advertising the 387 Area Proxy Router Capability. Their advertisements indicate that 388 they are individually ready to perform Area Proxy functionality. The 389 Area Leader then advertises the Area Proxy System Identifier TLV to 390 indicate that the Inside Area SHOULD enable Area Proxy functionality. 392 Other candidates for Area Leader MAY also advertise the Area Proxy 393 System Identifier when they observe that all Inside Routers are 394 advertising the Area Proxy Router Capability. All candidates 395 advertising the Area Proxy System Identifier TLV MUST be advertising 396 the same system identifier. Multiple proxy system identifiers in a 397 single area is a misconfiguration and each unique occurrence SHOULD 398 be logged. 400 The Area Leader and other candidates for Area Leader MAY withdraw the 401 Area Proxy System Identifier when one or more Inside Routers are not 402 advertising the Area Proxy Router Capability. This will disable Area 403 Proxy functionality. However, before withdrawing the Area Proxy 404 System Identifier, an implementation SHOULD protect against 405 unnecessary churn from transients by delaying the withdrawal. The 406 amount of delay is implementation-dependent. 408 4.3.2. The Area Segment SID Sub-TLV 410 The Area Segment SID Sub-TLV allows the Area Leader to advertise a 411 SID that represents the entirety of the Inside Area to the Outside 412 Area. This sub-TLV is learned by all of the Inside Edge Nodes who 413 should consume this SID at forwarding time. The Area Segment SID 414 Sub-TLV has the format: 416 0 1 2 417 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 418 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 419 | Type | Length | Flags | 420 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 421 | SID/Index/Label (variable) | 422 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 424 where: 426 Type: BBB 428 Length: variable (1 + SID length) 430 Flags: 1 octet, see Section 4.4.11.1 431 SID/Index/Label: as defined in [RFC8667] Section 2.1.1.1 433 4.4. Area Proxy LSP Generation 435 Each Inside Router generates a Level 2 LSP, and the Level 2 LSPs for 436 the Inside Edge Routers will include adjacencies to Outside Edge 437 Routers. Unlike normal Level 2 operations, these LSPs are not 438 advertised outside of the Inside Area and MUST be filtered by all 439 Inside Edge Routers to not be flooded to Outside Routers. Only the 440 Area Proxy LSP is injected into the overall Level 2 LSDB. 442 The Area Leader uses the Level 2 LSPs generated by the Inside Edge 443 Routers to generate the Area Proxy LSP. This LSP is originated using 444 the Area Proxy System Identifier. The Area Leader MAY also insert 445 the following additional TLVs into the Area Proxy LSP for additional 446 information for the Outside Area. LSPs generated by unreachable 447 nodes MUST NOT be considered. 449 4.4.1. The Protocols Supported TLV 451 The Area Leader SHOULD insert a Protocols Supported TLV (129) 452 [RFC1195] into the Area Proxy LSP. The values included in the TLV 453 SHOULD be the protocols supported by the Inside Area. 455 4.4.2. The Area Address TLV 457 The Area Leader SHOULD insert an Area Addresses TLV (1) [ISO10589] 458 into the Area Proxy LSP. 460 4.4.3. The Dynamic Hostname TLV 462 It is RECOMMENDED that the Area Leader insert the Dynamic Hostname 463 TLV (137) [RFC5301] into the Area Proxy LSP. The contents of the 464 hostname may be specified by configuration. The presence of the 465 hostname helps to simplify debugging the network. 467 4.4.4. The IS Neighbors TLV 469 The Area Leader MAY insert the IS Neighbors TLV (2) [ISO10589] into 470 the Area Proxy LSP for Outside Edge Routers. The Area Leader learns 471 of the Outside Edge Routers by examining the LSPs generated by the 472 Inside Edge Routers copying any IS Neighbors TLVs referring to 473 Outside Edge Routers into the Proxy LSP. Since the Outside Edge 474 Routers advertise an adjacency to the Area Proxy System Identifier, 475 this will result in a bi-directional adjacency. 477 An entry for a neighbor in both the IS Neighbors TLV and the Extended 478 IS Neighbors would be functionally redundant, so the Area Leader 479 SHOULD NOT do this. 481 4.4.5. The Extended IS Neighbors TLV 483 The Area Leader MAY insert the Extended IS Reachability TLV (22) 484 [RFC5305] into the Area Proxy LSP. The Area Leader SHOULD copy each 485 Extended IS Reachability TLV advertised by an Inside Edge Router 486 about an Outside Edge Router into the Proxy LSP. 488 If the Inside Area supports Segment Routing and Segment Routing 489 selects a SID where the L-Flag is unset, then the Area Lead SHOULD 490 include an Adjacency Segment Identifier sub-TLV (31) [RFC8667] using 491 the selected SID. 493 If the inside area supports SRv6, the Area Leader SHOULD copy the 494 "SRv6 End.X SID" and "SRv6 LAN End.X SID" sub-TLVs of the extended IS 495 reachability TLVs advertised by Inside Edge Routers about Outside 496 Edge Routers. 498 If the inside area supports Traffic Engineering (TE), the Area Leader 499 SHOULD copy TE related sub-TLVs [RFC5305] Section 3 to each Extended 500 IS Reachability TLV in the Proxy LSP. 502 4.4.6. The MT Intermediate Systems TLV 504 If the Inside Area supports Multi-Topology, then the Area Leader 505 SHOULD copy each Outside Edge Router advertisement that is advertised 506 by an Inside Edge Router in a MT Intermediate Systems TLV into the 507 Proxy LSP. 509 4.4.7. Reachability TLVs 511 The Area Leader SHOULD insert additional TLVs describing any routing 512 prefixes that should be advertised on behalf of the area. These 513 prefixes may be learned from the Level 1 LSDB, Level 2 LSDB, or 514 redistributed from another routing protocol. This applies to all of 515 various types of TLVs used for prefix advertisement: 517 IP Internal Reachability Information TLV (128) [RFC1195] 519 IP External Reachability Information TLV (130) [RFC1195] 521 Extended IP Reachability TLV (135) [RFC5305] 523 IPv6 Reachability TLV (236) [RFC5308] 524 Multi-Topology Reachable IPv4 Prefixes TLV (235) [RFC5120] 526 Multi-Topology Reachable IPv6 Prefixes TLV (237) [RFC5120] 528 For TLVs in the Level 1 LSDB, for a given TLV type and prefix, the 529 Area Leader SHOULD select the TLV with the lowest metric and copy 530 that TLV into the Area Proxy LSP. 532 When examining the Level 2 LSDB for this function, the Area Leader 533 SHOULD only consider TLVs advertised by Inside Routers. Further, for 534 prefixes that represent Boundary links, the Area Leader SHOULD copy 535 all TLVs that have unique sub-TLV contents. 537 If the Inside Area supports Segment Routing and the selected TLV 538 includes a Prefix Segment Identifier sub-TLV (3) [RFC8667], then the 539 sub-TLV SHOULD be copied as well. The P-Flag SHOULD be set in the 540 copy of the sub-TLV to indicate that penultimate hop popping SHOULD 541 NOT be performed for this prefix. The E-Flag SHOULD be reset in the 542 copy of the sub-TLV to indicate that an explicit NULL is not 543 required. The R-Flag SHOULD simply be copied. 545 4.4.8. The Router Capability TLV 547 The Area Leader MAY insert the Router Capability TLV (242) [RFC7981] 548 into the Area Proxy LSP. If Segment Routing is supported by the 549 inside area, as indicated by the presence of an SRGB being advertised 550 by all Inside Nodes, then the Area Leader SHOULD advertise an SR- 551 Capabilities sub-TLV (2) [RFC8667] with an SRGB. The first value of 552 the SRGB is the same value as the first value advertised by all 553 Inside Nodes. The range advertised for the area will be the minimum 554 of all ranges advertised by Inside Nodes. The Area Leader SHOULD use 555 its own Router Id in the Router Capability TLV. 557 If SRv6 Capability sub-TLV [RFC7981] is advertised by all Inside 558 Routers, the Area Leader should insert an SRv6 Capability sub-TLV in 559 the Router Capability TLV. Each flag in the SRv6 Capability sub-TLV 560 should be set if the flag is set by all Inside Routers. 562 If the Node Maximum SID Depth (MSD) sub-TLV [RFC8491] is advertised 563 by all Inside Routers, the Area Leader should advertise common MSD 564 types and the smallest supported MSD values for each type. 566 4.4.9. The Multi-Topology TLV 568 If the Inside Area supports multi-topology, then the Area Leader 569 SHOULD insert the Multi-Topology TLV (229) [RFC5120], including the 570 topologies supported by the Inside Nodes. 572 If any Inside Node is advertising the 'O' (Overload) bit for a given 573 topology, then the Area Leader MUST advertise the 'O' bit for that 574 topology. If any Inside Node is advertising the 'A' (Attach) bit for 575 a given topology, then the Area Leader MUST advertise the 'A' bit for 576 that topology. 578 4.4.10. The SID/Label Binding and The Multi-Topology SID/Label Binding 579 SID TLV 581 If an Inside Node advertises the SID/Label Binding or Multi-Topology 582 SID/Label Binding SID TLV [RFC8667], then the Area Leader MAY copy 583 the TLV to the Area Proxy LSP. 585 4.4.11. The Area Segment SID TLV 587 If the Area Leader is advertising an Area Segment SID in the Area 588 Segment SID sub-TLV of the Area Proxy TLV, then the Area Leader 589 SHOULD advertise the Area Segment SID TLV in the Proxy LSP. The 590 advertisement in the Proxy LSP informs the remainder of the network 591 that packets directed to the SID will be forwarded by one of the 592 Inside Edge Nodes and the Area Segment SID will be consumed. 594 This TLV is not specific to Area Proxy and MAY be used by Edge 595 Routers in conventional areas. The Area Segment SID TLV has the 596 format: 598 0 1 2 599 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 600 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 601 | Type | Length | Flags | 602 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 603 | SID/Index/Label (variable) | 604 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 606 where: 608 Type: XXX 610 Length: variable (1 + SID length) 612 Flags: 1 octet, see below 614 SID/Index/Label: as defined in [RFC8667] Section 2.1.1.1 616 4.4.11.1. Flags 618 The Flags octet is defined as follows: 620 0 1 2 3 4 5 6 7 621 +-+-+-+-+-+-+-+-+ 622 |F|V|L| | 623 +-+-+-+-+-+-+-+-+ 625 where: 627 F: Address-Family Flag. If unset, then this proxy SID is used 628 when forwarding IPv4-encapsulated traffic. If set, then this 629 proxy SID is used when forwarding IPv6-encapsulated traffic. 631 V: Value Flag. If set, then the proxy SID carries a value. 633 L: Local Flag. If set, then the value/index carried by the proxy 634 SID has local significance. 636 Other bits: MUST be zero when originated and ignored when 637 received. 639 4.4.12. The SRv6 Locator TLV 641 If the inside area supports SRv6, the Area Leader SHOULD copy all 642 SRv6 locator TLVs [I-D.ietf-lsr-isis-srv6-extensions] advertised by 643 Inside Routers to the Proxy LSP. 645 4.4.13. Traffic Engineering Information 647 If the inside area supports TE, the Area Leader SHOULD advertise a TE 648 Router ID TLV (134) [RFC5305] in the Proxy LSP. It SHOULD copy the 649 Shared Risk Link Group (SRLS) TLVs (138) [RFC5307] advertised by 650 Inside Edge Routers about links to Outside Edge Routers. 652 If the inside area supports IPv6 TE, the Area Leader SHOULD advertise 653 an IPv6 TE Router ID TLV (140) [RFC6119] in the Proxy LSP. It SHOULD 654 also copy the IPv6 SRLG TLVs (139) [RFC6119] advertised by Inside 655 Edge Routers about links to Outside Edge Routers. 657 5. Inside Edge Router Functions 659 The Inside Edge Router has two additional and important functions. 660 First, it MUST generate IIHs that appear to have come from the Area 661 Proxy System Identifier. Second, it MUST filter the L2 LSPs, Partial 662 Sequence Number PDUs (PSNPs), and Complete Sequence Number PDUs 663 (CSNPs) that are being advertised to Outside Routers. 665 5.1. Generating L2 IIHs to Outside Routers 667 The Inside Edge Router has one or more Level 2 interfaces to Outside 668 Routers. These may be identified by explicit configuration or by the 669 fact that they are not also Level 1 circuits. On these Level 2 670 interfaces, the Inside Edge Router MUST NOT send an IIH until it has 671 learned the Area Proxy System Id from the Area Leader. Then, once it 672 has learned the Area Proxy System Id, it MUST generate its IIHs on 673 the circuit using the Proxy System Id as the source of the IIH. 675 Using the Proxy System Id causes the Outside Router to advertise an 676 adjacency to the Proxy System Id, not to the Inside Edge Router, 677 which supports the proxy function. The normal system id of the 678 Inside Edge Router MUST NOT be used as it will cause unnecessary 679 adjacencies to form and subsequently flap. 681 5.2. Filtering LSP information 683 For the proxy abstraction to be effective the L2 LSPs generated by 684 the Inside Routers MUST be restricted to the Inside Area. The Inside 685 Routers know which system ids are members of the Inside Area based on 686 the Level 1 LSDB. To prevent unwanted LSP information from escaping 687 the Inside Area, the Inside Edge Router MUST perform filtering of LSP 688 flooding, CSNPs, and PSNPs. Specifically: 690 A Level 2 LSP with a source system identifier that is found in the 691 Level 1 LSDB MUST never be flooded to an Outside Router. 693 A Level 2 CSNP sent to an Outside Router MUST NOT contain any 694 information about an LSP with a system identifier found in the 695 Level 1 LSDB. If an Inside Edge Router filters a CSNP and there 696 is no remaining content, then the CSNP MUST NOT be sent. The 697 source address of the CSNP MUST be the Area Proxy System Id. 699 A Level 2 PSNP sent to an Outside Router MUST NOT contain any 700 information about an LSP with a system identifier found in the 701 Level 1 LSDB. If an Inside Edge Router filters a PSNP and there 702 is no remaining content, then the PSNP MUST NOT be sent. The 703 source address of the PSNP MUST be the Area Proxy System Id. 705 6. Acknowledgments 707 The authors would like to thank Bruno Decraene, Vivek Ilangovan, and 708 Gunter Van De Velde for their many helpful comments. The authors 709 would also like to thank a small group that wishes to remain 710 anonymous for their valuable contributions. 712 7. IANA Considerations 714 This memo requests that IANA allocate and assign one code point from 715 the IS-IS TLV Codepoints registry for the Area Segment SID TLV (XXX), 716 one code point for the Area Proxy TLV (YYY), and one code point for 717 the Inside Node TLV (ZZZ). The registry fields for all three should 718 be: IIH:n, LSP:y, SNP:n, Purge:n. 720 In association with this, this memo requests that IANA create a 721 registry for code points for the sub-TLVs of the Area Proxy TLV. 723 Name of the registry: Sub-TLVs for TLV YYY (Area Proxy TLV) 725 Required information for registrations: Temporary registrations 726 may be made under the Early IANA Allocation of Standards Track 727 Code Points policy. [RFC7120] Permanent registrations require the 728 publication of an RFC describing the usage of the code point. 730 Applicable registration policy: RFC Required and Expert Review. 731 We propose the initial experts be Chris Hopps, Tony Li, and Sarah 732 Chen. 734 Size, format, and syntax of registry entries: Value (0-255), Name, 735 and Reference 737 Initial assignments and reservations: IANA is requested to assign 738 the following code points: 740 +-------+------------------------------+---------------+ 741 | Value | Name | Reference | 742 +-------+------------------------------+---------------+ 743 | AAA | Area Proxy System Identifier | This document | 744 | BBB | Area Segment SID | This document | 745 +-------+------------------------------+---------------+ 747 IANA is also requested to allocate and assign one code point from the 748 IS-IS Router Capability TLV sub-TLV registry for the Area Proxy 749 Capability (LLL). 751 8. Security Considerations 753 This document introduces no new security issues. Security of routing 754 within a domain is already addressed as part of the routing protocols 755 themselves. This document proposes no changes to those security 756 architectures. 758 9. References 760 9.1. Normative References 762 [I-D.ietf-lsr-dynamic-flooding] 763 Li, T., Psenak, P., Ginsberg, L., Chen, H., Przygienda, 764 T., Cooper, D., Jalil, L., Dontula, S., and G. Mishra, 765 "Dynamic Flooding on Dense Graphs", draft-ietf-lsr- 766 dynamic-flooding-07 (work in progress), June 2020. 768 [I-D.ietf-lsr-isis-srv6-extensions] 769 Psenak, P., Filsfils, C., Bashandy, A., Decraene, B., and 770 Z. Hu, "IS-IS Extension to Support Segment Routing over 771 IPv6 Dataplane", draft-ietf-lsr-isis-srv6-extensions-08 772 (work in progress), April 2020. 774 [ISO10589] 775 International Organization for Standardization, 776 "Intermediate System to Intermediate System Intra-Domain 777 Routing Exchange Protocol for use in Conjunction with the 778 Protocol for Providing the Connectionless-mode Network 779 Service (ISO 8473)", ISO/IEC 10589:2002, Nov. 2002. 781 [RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and 782 dual environments", RFC 1195, DOI 10.17487/RFC1195, 783 December 1990, . 785 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 786 Requirement Levels", BCP 14, RFC 2119, 787 DOI 10.17487/RFC2119, March 1997, 788 . 790 [RFC5120] Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi 791 Topology (MT) Routing in Intermediate System to 792 Intermediate Systems (IS-ISs)", RFC 5120, 793 DOI 10.17487/RFC5120, February 2008, 794 . 796 [RFC5301] McPherson, D. and N. Shen, "Dynamic Hostname Exchange 797 Mechanism for IS-IS", RFC 5301, DOI 10.17487/RFC5301, 798 October 2008, . 800 [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic 801 Engineering", RFC 5305, DOI 10.17487/RFC5305, October 802 2008, . 804 [RFC5307] Kompella, K., Ed. and Y. Rekhter, Ed., "IS-IS Extensions 805 in Support of Generalized Multi-Protocol Label Switching 806 (GMPLS)", RFC 5307, DOI 10.17487/RFC5307, October 2008, 807 . 809 [RFC5308] Hopps, C., "Routing IPv6 with IS-IS", RFC 5308, 810 DOI 10.17487/RFC5308, October 2008, 811 . 813 [RFC6119] Harrison, J., Berger, J., and M. Bartlett, "IPv6 Traffic 814 Engineering in IS-IS", RFC 6119, DOI 10.17487/RFC6119, 815 February 2011, . 817 [RFC7981] Ginsberg, L., Previdi, S., and M. Chen, "IS-IS Extensions 818 for Advertising Router Information", RFC 7981, 819 DOI 10.17487/RFC7981, October 2016, 820 . 822 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 823 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 824 May 2017, . 826 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 827 Decraene, B., Litkowski, S., and R. Shakir, "Segment 828 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 829 July 2018, . 831 [RFC8491] Tantsura, J., Chunduri, U., Aldrin, S., and L. Ginsberg, 832 "Signaling Maximum SID Depth (MSD) Using IS-IS", RFC 8491, 833 DOI 10.17487/RFC8491, November 2018, 834 . 836 [RFC8667] Previdi, S., Ed., Ginsberg, L., Ed., Filsfils, C., 837 Bashandy, A., Gredler, H., and B. Decraene, "IS-IS 838 Extensions for Segment Routing", RFC 8667, 839 DOI 10.17487/RFC8667, December 2019, 840 . 842 9.2. Informative References 844 [Clos] Clos, C., "A Study of Non-Blocking Switching Networks", 845 The Bell System Technical Journal Vol. 32(2), DOI 846 10.1002/j.1538-7305.1953.tb01433.x, March 1953, 847 . 849 [RFC7120] Cotton, M., "Early IANA Allocation of Standards Track Code 850 Points", BCP 100, RFC 7120, DOI 10.17487/RFC7120, January 851 2014, . 853 9.3. URIs 855 [1] https://tools.ietf.org/html/bcp14 857 Authors' Addresses 859 Tony Li 860 Arista Networks 861 5453 Great America Parkway 862 Santa Clara, California 95054 863 USA 865 Email: tony.li@tony.li 867 Sarah Chen 868 Arista Networks 869 5453 Great America Parkway 870 Santa Clara, California 95054 871 USA 873 Email: sarahchen@arista.com 875 Vivek Ilangovan 876 Arista Networks 877 5453 Great America Parkway 878 Santa Clara, California 95054 879 USA 881 Email: ilangovan@arista.com 882 Gyan S. Mishra 883 Verizon Inc. 885 13101 Columbia Pike 887 Silver Spring 888 , 890 MD 20904 892 United States of America 894 Phone: 895 301 502-1347 897 Email: 898 gyan.s.mishra@verizon.com