idnits 2.17.1 draft-ietf-lsr-isis-area-proxy-08.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 (16 May 2022) is 704 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Outdated reference: A later version (-18) exists of draft-ietf-lsr-dynamic-flooding-10 == Outdated reference: A later version (-19) exists of draft-ietf-lsr-isis-srv6-extensions-18 Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force T. Li 3 Internet-Draft Juniper Networks 4 Intended status: Experimental S. Chen 5 Expires: 17 November 2022 V. Ilangovan 6 Arista Networks 7 G. Mishra 8 Verizon Inc. 9 16 May 2022 11 Area Proxy for IS-IS 12 draft-ietf-lsr-isis-area-proxy-08 14 Abstract 16 Link state routing protocols have hierarchical abstraction already 17 built into them. However, when lower levels are used for transit, 18 they must expose their internal topologies to each other, leading to 19 scale issues. 21 To avoid this, this document discusses extensions to the IS-IS 22 routing protocol that would allow level 1 areas to provide transit, 23 yet only inject an abstraction of the level 1 topology into level 2. 24 Each level 1 area is represented as a single level 2 node, thereby 25 enabling greater scale. 27 Status of This Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at https://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on 17 November 2022. 44 Copyright Notice 46 Copyright (c) 2022 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 51 license-info) in effect on the date of publication of this document. 52 Please review these documents carefully, as they describe your rights 53 and restrictions with respect to this document. Code Components 54 extracted from this document must include Revised BSD License text as 55 described in Section 4.e of the Trust Legal Provisions and are 56 provided without warranty as described in the Revised 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 . . . . . . . . . . . . . . . . . . . 7 66 3.2. Level 2 SPF Computation . . . . . . . . . . . . . . . . . 7 67 3.3. Responsibilities with respect to the Proxy LSP . . . . . 8 68 4. Area Leader Functions . . . . . . . . . . . . . . . . . . . . 8 69 4.1. Area Leader Election . . . . . . . . . . . . . . . . . . 8 70 4.2. Redundancy . . . . . . . . . . . . . . . . . . . . . . . 8 71 4.3. Distributing Area Proxy Information . . . . . . . . . . . 8 72 4.3.1. The Area Proxy System Id Sub-TLV . . . . . . . . . . 9 73 4.3.2. The Area SID Sub-TLV . . . . . . . . . . . . . . . . 10 74 4.4. Proxy LSP Generation . . . . . . . . . . . . . . . . . . 11 75 4.4.1. The Protocols Supported TLV . . . . . . . . . . . . . 11 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 . . . . . . . . . . . . 12 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 . . . . . . . . . . . . . . . 14 84 4.4.10. The SID/Label Binding and The Multi-Topology SID/Label 85 Binding SID TLV . . . . . . . . . . . . . . . . . . . 14 86 4.4.11. The SRv6 Locator TLV . . . . . . . . . . . . . . . . 14 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 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 100 1. Introduction 102 The IS-IS routing protocol IS-IS [ISO10589] currently supports a two- 103 level hierarchy of abstraction. The fundamental unit of abstraction 104 is the 'area', which is a (hopefully) connected set of systems 105 running IS-IS at the same level. Level 1, the lowest level, is 106 abstracted by routers that participate in both Level 1 and Level 2, 107 and they inject area information into Level 2. Level 2 systems 108 seeking to access Level 1, use this abstraction to compute the 109 shortest path to the Level 1 area. The full topology database of 110 Level 1 is not injected into Level 2, only a summary of the address 111 space contained within the area, so the scalability of the Level 2 112 Link State Database (LSDB) is protected. 114 This works well if the Level 1 area is tangential to the Level 2 115 area. This also works well if there are several routers in both 116 Level 1 and Level 2 and they are adjacent, so Level 2 traffic will 117 never need to transit Level 1 only routers. Level 1 will not contain 118 any Level 2 topology, and Level 2 will only contain area abstractions 119 for Level 1. 121 Unfortunately, this scheme does not work so well if the Level 1 only 122 area needs to provide transit for Level 2 traffic. For Level 2 123 shortest path first (SPF) computations to work correctly, the transit 124 topology must also appear in the Level 2 LSDB. This implies that all 125 routers that could provide transit, plus any links that might also 126 provide Level 2 transit must also become part of the Level 2 127 topology. If this is a relatively tiny portion of the Level 1 area, 128 this is not overly painful. 130 However, with today's data center topologies, this is problematic. A 131 common application is to use a Layer 3 Leaf-Spine (L3LS) topology, 132 which is a folded 3-stage Clos [Clos] fabric. It can also be thought 133 of as a complete bipartite graph. In such a topology, the desire is 134 to use Level 1 to contain the routing dynamics of the entire L3LS 135 topology and then to use Level 2 for the remainder of the network. 136 Leaves in the L3LS topology are appropriate for connection outside of 137 the data center itself, so they would provide connectivity for Level 138 2. If there are multiple connections to Level 2 for redundancy, or 139 other areas, these too would also be made to the leaves in the 140 topology. This creates a difficulty because there are now multiple 141 Level 2 leaves in the topology, with connectivity between the leaves 142 provided by the spines. 144 Following the current rules of IS-IS, all spine routers would 145 necessarily be part of the Level 2 topology, plus all links between a 146 Level 2 leaf and the spines. In the limit, where all leaves need to 147 support Level 2, it implies that the entire L3LS topology becomes 148 part of Level 2. This is seriously problematic as it more than 149 doubles the LSDB held in the L3LS topology and eliminates any 150 benefits of the hierarchy. 152 This document discusses the handling of IP traffic. Supporting MPLS 153 based traffic is a subject for future work. 155 1.1. Requirements Language 157 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 158 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 159 document are to be interpreted as described in BCP 14 160 (https://tools.ietf.org/html/bcp14) [RFC2119] [RFC8174] when, and 161 only when, they appear in all capitals, as shown here. 163 2. Area Proxy 165 To address this, we propose to completely abstract away the details 166 of the Level 1 area topology within Level 2, making the entire area 167 look like a single proxy system directly connected to all of the 168 area's Level 2 neighbors. By only providing an abstraction of the 169 topology, Level 2's requirement for connectivity can be satisfied 170 without the full overhead of the area's internal topology. It then 171 becomes the responsibility of the Level 1 area to ensure the 172 forwarding connectivity that's advertised. 174 For this discussion, we'll consider a single Level 1 IS-IS area to be 175 the Inside Area, and the remainder of the Level 2 area is the Outside 176 Area. All routers within the Inside Area speak Level 1 and Level 2 177 IS-IS on all of the links within the topology. We propose to 178 implement Area Proxy by having a Level 2 Proxy Link State Protocol 179 Data Unit (PDU, LSP) that represents the entire Inside Area. We will 180 refer to this as the Proxy LSP. This is the only LSP from the area 181 that will be flooded into the overall Level 2 LSDB. 183 There are four classes of routers that we need to be concerned with 184 in this discussion: 186 Inside Router A router within the Inside Area that runs Level 1 and 187 Level 2 IS-IS. A router is recognized as an Inside Router by the 188 existence of its LSP in the Level 1 LSDB. 190 Area Leader The Area Leader is an Inside Router that is elected to 191 represent the Level 1 area by injecting the Proxy LSP into the 192 Level 2 LSDB. There may be multiple candidates for Area Leader, 193 but only one is elected at a given time. Any Inside Router can be 194 Area Leader. 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 Figure 1: An example of router classes 225 All Inside Edge Routers learn the Area Proxy System Identifier from 226 the Area Proxy TLV advertised by the Area Leader and use that as the 227 system identifier in their Level 2 IS-IS Hello PDUs (IIHs) on all 228 Outside interfaces. Outside Edge Routers should then advertise an 229 adjacency to the Area Proxy System Identifier. This allows all 230 Outside Routers to use the Proxy LSP in their SPF computations 231 without seeing the full topology of the Inside 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. This choice of pseudonode identifier 246 may confuse neighbors with an extremely strict implementation, in 247 which case the Inside Edge Router may be configured with priority 0, 248 causing an Outside Router to be elected DIS. 250 2.1. Segment Routing 252 If the Inside Area supports Segment Routing [RFC8402], then all 253 Inside Nodes MUST advertise an SR Global Block (SRGB). The first 254 value of the SRGB advertised by all Inside Nodes MUST start at the 255 same value. The range advertised for the area will be the minimum of 256 all Inside Nodes. 258 To support Segment Routing, the Area Leader will take the global SID 259 information found in the L1 LSDB and convey that to L2 through the 260 Proxy LSP. Prefixes with SID assignments will be copied to the Proxy 261 LSP. Adjacency SIDs for Outside Edge Nodes will be copied to the 262 Proxy LSP. 264 To further extend Segment Routing, it would be helpful to have a 265 segment that refers to the entire Inside Area. This allows a path to 266 refer to an area and have any node within that area accept and 267 forward the packet. In effect, this becomes an anycast SID that is 268 accepted by all Inside Edge Nodes. The information about this SID is 269 distributed in the Area SID Sub-TLV, as part of the Area Leader's 270 Area Proxy TLV (Section 4.3.2). The Inside Edge Nodes MUST establish 271 forwarding based on this SID. The Area Leader SHALL also include the 272 Area SID in the Proxy LSP so that the remainder of L2 can use it for 273 path construction. (Section 4.4.13). 275 3. Inside Router Functions 277 All Inside Routers run Level 1-2 IS-IS and must be explicitly 278 instructed to enable the Area Proxy functionality. To signal their 279 readiness to participate in Area Proxy functionality, they will 280 advertise the Area Proxy TLV in their L2 LSP. 282 3.1. The Area Proxy TLV 284 The Area Proxy TLV serves multiple functions: 286 The presence of the Area Proxy TLV in a node's LSP indicates that 287 the node is enabled for Area Proxy. 289 An LSP containing the Area Proxy TLV is also an Inside Node. All 290 Inside Nodes, including pseudonodes, MUST advertise the Area Proxy 291 TLV. 293 It is a container for sub-TLVs with Area Proxy information. 295 A node advertises the Area Proxy TLV in fragment 0 of its L2 LSP. 296 Nodes MUST NOT advertise the Area Proxy TLV in a L1 LSP. Nodes MUST 297 ignore the Area Proxy TLV if it is found in a L1 LSP. The Area Proxy 298 TLV is not used in the Proxy LSP. The format of the Area Proxy TLV 299 is: 301 0 1 2 302 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 303 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 304 | TLV Type | TLV Length | Sub-TLVs ... 305 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 307 TLV Type: 20 309 TLV Length: length of the sub-TLVs 311 3.2. Level 2 SPF Computation 313 When Outside Routers perform a Level 2 SPF computation, they will use 314 the Proxy LSP for computing a path transiting the Inside Area. 315 Because the topology has been abstracted away, the cost for 316 transiting the Inside Area will be zero. 318 When Inside Routers perform a Level 2 SPF computation, they MUST 319 ignore the Proxy LSP. Further, because these systems do see the 320 Inside Area topology, the link metrics internal to the area are 321 visible. This could lead to different and possibly inconsistent SPF 322 results, potentially leading to forwarding loops. 324 To prevent this, the Inside Routers MUST consider the metrics of 325 links outside of the Inside Area (inter-area metrics) separately from 326 the metrics of the Inside Area links (intra-area metrics). Intra- 327 area metrics MUST be treated as less than any inter-area metric. 328 Thus, if two paths have different total inter-area metrics, the path 329 with the lower inter-area metric would be preferred, regardless of 330 any intra-area metrics involved. However, if two paths have equal 331 inter-area metrics, then the intra-area metrics would be used to 332 compare the paths. 334 Point-to-Point links between two Inside Routers are considered to be 335 Inside Area links. LAN links which have a pseudonode LSP in the 336 Level 1 LSDB are considered to be Inside Area links. 338 3.3. Responsibilities with respect to the Proxy LSP 340 The Area Leader will generate a Proxy LSP that will be flooded across 341 the Inside Area. Inside Routers MUST ignore the contents of the 342 Proxy LSP other than for flooding. The Proxy LSP uses the Area Proxy 343 System Identifier as its Source ID. 345 4. Area Leader Functions 347 The Area Leader has several responsibilities. First, it MUST inject 348 the Area Proxy System Identifier into the Level 2 LSDB. Second, the 349 Area Leader MUST generate the Proxy LSP for the Inside Area. 351 4.1. Area Leader Election 353 The Area Leader is selected using the election mechanisms and TLVs 354 described in Dynamic Flooding for IS-IS 355 [I-D.ietf-lsr-dynamic-flooding]. 357 4.2. Redundancy 359 If the Area Leader fails, another candidate may become Area Leader 360 and MUST regenerate the Proxy LSP. The failure of the Area Leader is 361 not visible outside of the area and appears to simply be an update of 362 the Proxy LSP. 364 For consistency, all Area Leader candidates SHOULD be configured with 365 the same Proxy System Id, Proxy Hostname, and any other information 366 that may be inserted into the Proxy LSP. 368 4.3. Distributing Area Proxy Information 370 The Area Leader is responsible for distributing information about the 371 area to all Inside Nodes. In particular, the Area Leader distributes 372 the Proxy System Id and the Area SID. This is done using two sub- 373 TLVs of the Area Proxy TLV. 375 4.3.1. The Area Proxy System Id Sub-TLV 377 The Area Proxy System Id Sub-TLV MUST be used by the Area Leader to 378 distribute the Area Proxy System Id. This is an additional system 379 identifier that is used by Inside Nodes and an indication that Area 380 Proxy is active. The format of this sub-TLV is: 382 0 1 2 383 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 384 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 385 | Type | Length | Proxy System ID | 386 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 387 | Proxy System Identifier continued | 388 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 390 Type: 1 392 Length: length of a system ID (6) 394 Proxy System Identifier: the Area Proxy System Identifier. 396 The Area Leader MUST advertise the Area Proxy System Identifier Sub- 397 TLV when it observes that all Inside Routers are advertising the Area 398 Proxy TLV. Their advertisements indicate that they are individually 399 ready to perform Area Proxy functionality. The Area Leader then 400 advertises the Area Proxy System Identifier TLV to indicate that the 401 Inside Area MUST enable Area Proxy functionality. 403 Other candidates for Area Leader MAY also advertise the Area Proxy 404 System Identifier when they observe that all Inside Routers are 405 advertising the Area Proxy Router Capability. All candidates 406 advertising the Area Proxy System Identifier TLV MUST be advertising 407 the same system identifier. Multiple proxy system identifiers in a 408 single area is a misconfiguration and each unique occurrence SHOULD 409 be logged. 411 The Area Leader and other candidates for Area Leader MAY withdraw the 412 Area Proxy System Identifier when one or more Inside Routers are not 413 advertising the Area Proxy Router Capability. This will disable Area 414 Proxy functionality. However, before withdrawing the Area Proxy 415 System Identifier, an implementation SHOULD protect against 416 unnecessary churn from transients by delaying the withdrawal. The 417 amount of delay is implementation-dependent. 419 4.3.2. The Area SID Sub-TLV 421 The Area SID Sub-TLV allows the Area Leader to advertise a prefix and 422 SID that represents the entirety of the Inside Area to the Outside 423 Area. This sub-TLV is learned by all of the Inside Edge Nodes who 424 should consume this SID at forwarding time. The Area SID Sub-TLV has 425 the format: 427 0 1 2 428 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 429 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 430 | Type | Length | Flags | 431 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 432 | SID/Index/Label (variable) | 433 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 434 | Prefix Length | Prefix (variable) | 435 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 437 where: 439 Type: 2 441 Length: variable (1 + SID length) 443 Flags: 1 octet. 445 SID/Index/Label: as defined in [RFC8667] Section 2.1.1.1 447 Prefix Length: 1 octet 449 Prefix: 0-16 octets 451 The Flags octet is defined as follows: 453 0 1 2 3 4 5 6 7 454 +-+-+-+-+-+-+-+-+ 455 |F|V|L| | 456 +-+-+-+-+-+-+-+-+ 458 where: 460 F: Address-Family Flag. If unset, then this proxy SID is used 461 when forwarding IPv4-encapsulated traffic. If set, then this 462 proxy SID is used when forwarding IPv6-encapsulated traffic. 464 V: Value Flag. If set, then the proxy SID carries a value. 466 L: Local Flag. If set, then the value/index carried by the proxy 467 SID has local significance. 469 Other bits: MUST be zero when originated and ignored when 470 received. 472 4.4. Proxy LSP Generation 474 Each Inside Router generates a Level 2 LSP, and the Level 2 LSPs for 475 the Inside Edge Routers will include adjacencies to Outside Edge 476 Routers. Unlike normal Level 2 operations, these LSPs are not 477 advertised outside of the Inside Area and MUST be filtered by all 478 Inside Edge Routers to not be flooded to Outside Routers. Only the 479 Proxy LSP is injected into the overall Level 2 LSDB. 481 The Area Leader uses the Level 2 LSPs generated by the Inside Edge 482 Routers to generate the Proxy LSP. This LSP is originated using the 483 Area Proxy System Identifier. The Area Leader MAY also insert the 484 following additional TLVs into the Proxy LSP for additional 485 information for the Outside Area. LSPs generated by unreachable 486 nodes MUST NOT be considered. 488 4.4.1. The Protocols Supported TLV 490 The Area Leader SHOULD insert a Protocols Supported TLV (129) 491 [RFC1195] into the Proxy LSP. The values included in the TLV SHOULD 492 be the protocols supported by the Inside Area. 494 4.4.2. The Area Address TLV 496 The Area Leader SHOULD insert an Area Addresses TLV (1) [ISO10589] 497 into the Proxy LSP. 499 4.4.3. The Dynamic Hostname TLV 501 It is RECOMMENDED that the Area Leader insert the Dynamic Hostname 502 TLV (137) [RFC5301] into the Proxy LSP. The contents of the hostname 503 may be specified by configuration. The presence of the hostname 504 helps to simplify debugging the network. 506 4.4.4. The IS Neighbors TLV 508 The Area Leader MAY insert the IS Neighbors TLV (2) [ISO10589] into 509 the Proxy LSP for Outside Edge Routers. The Area Leader learns of 510 the Outside Edge Routers by examining the LSPs generated by the 511 Inside Edge Routers copying any IS Neighbors TLVs referring to 512 Outside Edge Routers into the Proxy LSP. Since the Outside Edge 513 Routers advertise an adjacency to the Area Proxy System Identifier, 514 this will result in a bi-directional adjacency. 516 An entry for a neighbor in both the IS Neighbors TLV and the Extended 517 IS Neighbors would be functionally redundant, so the Area Leader 518 SHOULD NOT do this. 520 4.4.5. The Extended IS Neighbors TLV 522 The Area Leader MAY insert the Extended IS Reachability TLV (22) 523 [RFC5305] into the Proxy LSP. The Area Leader SHOULD copy each 524 Extended IS Reachability TLV advertised by an Inside Edge Router 525 about an Outside Edge Router into the Proxy LSP. 527 If the Inside Area supports Segment Routing and Segment Routing 528 selects a SID where the L-Flag is unset, then the Area Lead SHOULD 529 include an Adjacency Segment Identifier sub-TLV (31) [RFC8667] using 530 the selected SID. 532 If the inside area supports SRv6, the Area Leader SHOULD copy the 533 "SRv6 End.X SID" and "SRv6 LAN End.X SID" sub-TLVs of the extended IS 534 reachability TLVs advertised by Inside Edge Routers about Outside 535 Edge Routers. 537 If the inside area supports Traffic Engineering (TE), the Area Leader 538 SHOULD copy TE related sub-TLVs [RFC5305] Section 3 to each Extended 539 IS Reachability TLV in the Proxy LSP. 541 4.4.6. The MT Intermediate Systems TLV 543 If the Inside Area supports Multi-Topology, then the Area Leader 544 SHOULD copy each Outside Edge Router advertisement that is advertised 545 by an Inside Edge Router in a MT Intermediate Systems TLV into the 546 Proxy LSP. 548 4.4.7. Reachability TLVs 550 The Area Leader SHOULD insert additional TLVs describing any routing 551 prefixes that should be advertised on behalf of the area. These 552 prefixes may be learned from the Level 1 LSDB, Level 2 LSDB, or 553 redistributed from another routing protocol. This applies to all of 554 various types of TLVs used for prefix advertisement: 556 IP Internal Reachability Information TLV (128) [RFC1195] 558 IP External Reachability Information TLV (130) [RFC1195] 560 Extended IP Reachability TLV (135) [RFC5305] 561 IPv6 Reachability TLV (236) [RFC5308] 563 Multi-Topology Reachable IPv4 Prefixes TLV (235) [RFC5120] 565 Multi-Topology Reachable IPv6 Prefixes TLV (237) [RFC5120] 567 For TLVs in the Level 1 LSDB, for a given TLV type and prefix, the 568 Area Leader SHOULD select the TLV with the lowest metric and copy 569 that TLV into the Proxy LSP. 571 When examining the Level 2 LSDB for this function, the Area Leader 572 SHOULD only consider TLVs advertised by Inside Routers. Further, for 573 prefixes that represent Boundary links, the Area Leader SHOULD copy 574 all TLVs that have unique sub-TLV contents. 576 If the Inside Area supports Segment Routing and the selected TLV 577 includes a Prefix Segment Identifier sub-TLV (3) [RFC8667], then the 578 sub-TLV SHOULD be copied as well. The P-Flag SHOULD be set in the 579 copy of the sub-TLV to indicate that penultimate hop popping SHOULD 580 NOT be performed for this prefix. The E-Flag SHOULD be reset in the 581 copy of the sub-TLV to indicate that an explicit NULL is not 582 required. The R-Flag SHOULD simply be copied. 584 4.4.8. The Router Capability TLV 586 The Area Leader MAY insert the Router Capability TLV (242) [RFC7981] 587 into the Proxy LSP. If Segment Routing is supported by the inside 588 area, as indicated by the presence of an SRGB being advertised by all 589 Inside Nodes, then the Area Leader SHOULD advertise an SR- 590 Capabilities sub-TLV (2) [RFC8667] with an SRGB. The first value of 591 the SRGB is the same value as the first value advertised by all 592 Inside Nodes. The range advertised for the area will be the minimum 593 of all ranges advertised by Inside Nodes. The Area Leader SHOULD use 594 its own Router Id in the Router Capability TLV. 596 If SRv6 Capability sub-TLV [RFC7981] is advertised by all Inside 597 Routers, the Area Leader should insert an SRv6 Capability sub-TLV in 598 the Router Capability TLV. Each flag in the SRv6 Capability sub-TLV 599 should be set if the flag is set by all Inside Routers. 601 If the Node Maximum SID Depth (MSD) sub-TLV [RFC8491] is advertised 602 by all Inside Routers, the Area Leader should advertise common MSD 603 types and the smallest supported MSD values for each type. 605 4.4.9. The Multi-Topology TLV 607 If the Inside Area supports multi-topology, then the Area Leader 608 SHOULD insert the Multi-Topology TLV (229) [RFC5120], including the 609 topologies supported by the Inside Nodes. 611 If any Inside Node is advertising the 'O' (Overload) bit for a given 612 topology, then the Area Leader MUST advertise the 'O' bit for that 613 topology. If any Inside Node is advertising the 'A' (Attach) bit for 614 a given topology, then the Area Leader MUST advertise the 'A' bit for 615 that topology. 617 4.4.10. The SID/Label Binding and The Multi-Topology SID/Label Binding 618 SID TLV 620 If an Inside Node advertises the SID/Label Binding or Multi-Topology 621 SID/Label Binding SID TLV [RFC8667], then the Area Leader MAY copy 622 the TLV to the Proxy LSP. 624 4.4.11. The SRv6 Locator TLV 626 If the inside area supports SRv6, the Area Leader SHOULD copy all 627 SRv6 locator TLVs [I-D.ietf-lsr-isis-srv6-extensions] advertised by 628 Inside Routers to the Proxy LSP. 630 4.4.12. Traffic Engineering Information 632 If the inside area supports TE, the Area Leader SHOULD advertise a TE 633 Router ID TLV (134) [RFC5305] in the Proxy LSP. It SHOULD copy the 634 Shared Risk Link Group (SRLS) TLVs (138) [RFC5307] advertised by 635 Inside Edge Routers about links to Outside Edge Routers. 637 If the inside area supports IPv6 TE, the Area Leader SHOULD advertise 638 an IPv6 TE Router ID TLV (140) [RFC6119] in the Proxy LSP. It SHOULD 639 also copy the IPv6 SRLG TLVs (139) [RFC6119] advertised by Inside 640 Edge Routers about links to Outside Edge Routers. 642 4.4.13. The Area SID 644 When SR is enabled, it may be useful to advertise an Area SID which 645 will direct traffic to any of the Inside Edge Routers. The 646 information for the Area SID is distributed to all Inside Edge 647 Routers using the Area SID sub-TLV (Section 4.3.2) by the Area 648 Leader. 650 The Area Leader SHOULD advertise the Area SID information in the 651 Proxy LSP as a Node SID as defined in [RFC8667] Section 2.1. The 652 advertisement in the Proxy LSP informs the Outside Area that packets 653 directed to the SID will be forwarded to one of the Inside Edge Nodes 654 and the Area SID will be consumed. 656 Other uses of the Area SID and area SID prefix are outside the scope 657 of this document. Documents which define other use cases for the 658 Area SID MUST specify whether the SID value should be the same or 659 different from that used in support of Area Proxy. 661 5. Inside Edge Router Functions 663 The Inside Edge Router has two additional and important functions. 664 First, it MUST generate IIHs that appear to have come from the Area 665 Proxy System Identifier. Second, it MUST filter the L2 LSPs, Partial 666 Sequence Number PDUs (PSNPs), and Complete Sequence Number PDUs 667 (CSNPs) that are being advertised to Outside Routers. 669 5.1. Generating L2 IIHs to Outside Routers 671 The Inside Edge Router has one or more Level 2 interfaces to Outside 672 Routers. These may be identified by explicit configuration or by the 673 fact that they are not also Level 1 circuits. On these Level 2 674 interfaces, the Inside Edge Router MUST NOT send an IIH until it has 675 learned the Area Proxy System Id from the Area Leader. Then, once it 676 has learned the Area Proxy System Id, it MUST generate its IIHs on 677 the circuit using the Proxy System Id as the source of the IIH. 679 Using the Proxy System Id causes the Outside Router to advertise an 680 adjacency to the Proxy System Id, not to the Inside Edge Router, 681 which supports the proxy function. The normal system id of the 682 Inside Edge Router MUST NOT be used as it will cause unnecessary 683 adjacencies to form and subsequently flap. 685 5.2. Filtering LSP information 687 For the area proxy abstraction to be effective the L2 LSPs generated 688 by the Inside Routers MUST be restricted to the Inside Area. The 689 Inside Routers know which system ids are members of the Inside Area 690 based on the advertisement of the Area Proxy TLV. To prevent 691 unwanted LSP information from escaping the Inside Area, the Inside 692 Edge Router MUST perform filtering of LSP flooding, CSNPs, and PSNPs. 693 Specifically: 695 A Level 2 LSP with a source system identifier that is found in the 696 Level 1 LSDB MUST NOT be flooded to an Outside Router. 698 A Level 2 LSP that contains the Area Proxy TLV MUST NOT be flooded 699 to an Outside Router. 701 A Level 2 CSNP sent to an Outside Router MUST NOT contain any 702 information about an LSP with a system identifier found in the 703 Level 1 LSDB. If an Inside Edge Router filters a CSNP and there 704 is no remaining content, then the CSNP MUST NOT be sent. The 705 source address of the CSNP MUST be the Area Proxy System Id. 707 A Level 2 PSNP sent to an Outside Router MUST NOT contain any 708 information about an LSP with a system identifier found in the 709 Level 1 LSDB. If an Inside Edge Router filters a PSNP and there 710 is no remaining content, then the PSNP MUST NOT be sent. The 711 source address of the PSNP MUST be the Area Proxy System Id. 713 6. Acknowledgments 715 The authors would like to thank Bruno Decraene and Gunter Van De 716 Velde for their many helpful comments. The authors would also like 717 to thank a small group that wishes to remain anonymous for their 718 valuable contributions. 720 7. IANA Considerations 722 This memo requests that IANA allocate and assign code point 20 from 723 the IS-IS TLV Codepoints registry for the Area Proxy TLV. The 724 registry fields should be: IIH:n, LSP:y, SNP:n, Purge:n. 726 In association with this, this memo requests that IANA create a 727 registry for code points for the sub-TLVs of the Area Proxy TLV. 729 Name of the registry: Sub-TLVs for TLV 20 (Area Proxy TLV) 731 Required information for registrations: Temporary registrations 732 may be made under the Early IANA Allocation of Standards Track 733 Code Points policy. [RFC7120] Permanent registrations require the 734 publication of an RFC describing the usage of the code point. 736 Applicable registration policy: RFC Required and Expert Review. 737 We propose the initial experts be Chris Hopps, Tony Li, and Sarah 738 Chen. 740 Size, format, and syntax of registry entries: Value (0-255), Name, 741 and Reference 743 Initial assignments and reservations: IANA is requested to assign 744 the following code points: 746 +=======+==============================+===============+ 747 | Value | Name | Reference | 748 +=======+==============================+===============+ 749 | 1 | Area Proxy System Identifier | This document | 750 +-------+------------------------------+---------------+ 751 | 2 | Area SID | This document | 752 +-------+------------------------------+---------------+ 754 Table 1 756 8. Security Considerations 758 This document introduces no new security issues. Security of routing 759 within a domain is already addressed as part of the routing protocols 760 themselves. This document proposes no changes to those security 761 architectures. 763 9. References 765 9.1. Normative References 767 [I-D.ietf-lsr-dynamic-flooding] 768 Li, T., Przygienda, T., Psenak, P., Ginsberg, L., Chen, 769 H., Cooper, D., Jalil, L., Dontula, S., and G. S. Mishra, 770 "Dynamic Flooding on Dense Graphs", Work in Progress, 771 Internet-Draft, draft-ietf-lsr-dynamic-flooding-10, 7 772 December 2021, . 775 [I-D.ietf-lsr-isis-srv6-extensions] 776 Psenak, P., Filsfils, C., Bashandy, A., Decraene, B., and 777 Z. Hu, "IS-IS Extensions to Support Segment Routing over 778 IPv6 Dataplane", Work in Progress, Internet-Draft, draft- 779 ietf-lsr-isis-srv6-extensions-18, 20 October 2021, 780 . 783 [ISO10589] ISO, "Intermediate System to Intermediate System Intra- 784 Domain Routing Exchange Protocol for use in Conjunction 785 with the Protocol for Providing the Connectionless-mode 786 Network Service (ISO 8473)", ISO/IEC 10589:2002, October 787 2002. 789 [RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and 790 dual environments", RFC 1195, DOI 10.17487/RFC1195, 791 December 1990, . 793 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 794 Requirement Levels", BCP 14, RFC 2119, 795 DOI 10.17487/RFC2119, March 1997, 796 . 798 [RFC5120] Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi 799 Topology (MT) Routing in Intermediate System to 800 Intermediate Systems (IS-ISs)", RFC 5120, 801 DOI 10.17487/RFC5120, February 2008, 802 . 804 [RFC5301] McPherson, D. and N. Shen, "Dynamic Hostname Exchange 805 Mechanism for IS-IS", RFC 5301, DOI 10.17487/RFC5301, 806 October 2008, . 808 [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic 809 Engineering", RFC 5305, DOI 10.17487/RFC5305, October 810 2008, . 812 [RFC5307] Kompella, K., Ed. and Y. Rekhter, Ed., "IS-IS Extensions 813 in Support of Generalized Multi-Protocol Label Switching 814 (GMPLS)", RFC 5307, DOI 10.17487/RFC5307, October 2008, 815 . 817 [RFC5308] Hopps, C., "Routing IPv6 with IS-IS", RFC 5308, 818 DOI 10.17487/RFC5308, October 2008, 819 . 821 [RFC6119] Harrison, J., Berger, J., and M. Bartlett, "IPv6 Traffic 822 Engineering in IS-IS", RFC 6119, DOI 10.17487/RFC6119, 823 February 2011, . 825 [RFC7981] Ginsberg, L., Previdi, S., and M. Chen, "IS-IS Extensions 826 for Advertising Router Information", RFC 7981, 827 DOI 10.17487/RFC7981, October 2016, 828 . 830 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 831 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 832 May 2017, . 834 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 835 Decraene, B., Litkowski, S., and R. Shakir, "Segment 836 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 837 July 2018, . 839 [RFC8491] Tantsura, J., Chunduri, U., Aldrin, S., and L. Ginsberg, 840 "Signaling Maximum SID Depth (MSD) Using IS-IS", RFC 8491, 841 DOI 10.17487/RFC8491, November 2018, 842 . 844 [RFC8667] Previdi, S., Ed., Ginsberg, L., Ed., Filsfils, C., 845 Bashandy, A., Gredler, H., and B. Decraene, "IS-IS 846 Extensions for Segment Routing", RFC 8667, 847 DOI 10.17487/RFC8667, December 2019, 848 . 850 9.2. Informative References 852 [Clos] Clos, C., "A Study of Non-Blocking Switching Networks", 853 The Bell System Technical Journal Vol. 32(2), DOI 854 10.1002/j.1538-7305.1953.tb01433.x, March 1953, 855 . 857 [RFC7120] Cotton, M., "Early IANA Allocation of Standards Track Code 858 Points", BCP 100, RFC 7120, DOI 10.17487/RFC7120, January 859 2014, . 861 Authors' Addresses 863 Tony Li 864 Juniper Networks 865 1133 Innovation Way 866 Sunnyvale, California 94089 867 United States of America 868 Email: tony.li@tony.li 870 Sarah Chen 871 Arista Networks 872 5453 Great America Parkway 873 Santa Clara, California 95054 874 United States of America 875 Email: sarahchen@arista.com 877 Vivek Ilangovan 878 Arista Networks 879 5453 Great America Parkway 880 Santa Clara, California 95054 881 United States of America 882 Email: ilangovan@arista.com 883 Gyan S. Mishra 884 Verizon Inc. 885 13101 Columbia Pike 886 Silver Spring, MD 20904 887 United States of America 888 Phone: 301 502-1347 889 Email: gyan.s.mishra@verizon.com