idnits 2.17.1 draft-li-lsr-isis-area-proxy-03.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). == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: If the Inside Area supports Segment Routing and the selected TLV includes a Prefix Segment Identifier sub-TLV (3) [RFC8667], then the sub-TLV SHOULD be copied as well. The P-Flag SHOULD be set in the copy of the sub-TLV to indicate that penultimate hop popping SHOULD not be performed for this prefix. The E-Flag SHOULD be reset in the copy of the sub-TLV to indicate that an explicit NULL is not required. The R-Flag SHOULD simply be copied. -- The document date (March 24, 2020) is 1493 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: '1' on line 803 == Outdated reference: A later version (-18) exists of draft-ietf-lsr-dynamic-flooding-04 ** Downref: Normative reference to an Experimental draft: draft-ietf-lsr-dynamic-flooding (ref. 'I-D.ietf-lsr-dynamic-flooding') -- Possible downref: Non-RFC (?) normative reference: ref. 'ISO10589' ** Obsolete normative reference: RFC 3784 (Obsoleted by RFC 5305) Summary: 2 errors (**), 0 flaws (~~), 4 warnings (==), 3 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: Standards Track Arista Networks 5 Expires: September 25, 2020 March 24, 2020 7 Area Proxy for IS-IS 8 draft-li-lsr-isis-area-proxy-03 10 Abstract 12 Link state routing protocols have hierarchical abstraction already 13 built into them. However, when lower levels are used for transit, 14 they must expose their internal topologies to each other, leading to 15 scale issues. 17 To avoid this, this document discusses extensions to the IS-IS 18 routing protocol that would allow level 1 areas to provide transit, 19 yet only inject an abstraction of the level 1 topology into level 2. 20 Each level 1 area is represented as a single level 2 node, thereby 21 enabling greater scale. 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at https://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on September 25, 2020. 40 Copyright Notice 42 Copyright (c) 2020 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (https://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 58 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 59 2. Area Proxy . . . . . . . . . . . . . . . . . . . . . . . . . 4 60 2.1. Segment Routing . . . . . . . . . . . . . . . . . . . . . 5 61 3. Inside Router Functions . . . . . . . . . . . . . . . . . . . 6 62 3.1. The Area Proxy Router Capability . . . . . . . . . . . . 6 63 3.2. Level 2 SPF Computation . . . . . . . . . . . . . . . . . 6 64 3.3. The Inside Node TLV . . . . . . . . . . . . . . . . . . . 7 65 4. Area Leader Functions . . . . . . . . . . . . . . . . . . . . 7 66 4.1. Area Leader Election . . . . . . . . . . . . . . . . . . 7 67 4.2. Redundancy . . . . . . . . . . . . . . . . . . . . . . . 7 68 4.3. The Area Proxy TLV . . . . . . . . . . . . . . . . . . . 8 69 4.3.1. The Area Proxy System Id Sub-TLV . . . . . . . . . . 8 70 4.3.2. The Area Segment SID Sub-TLV . . . . . . . . . . . . 9 71 4.4. Area Proxy LSP Generation . . . . . . . . . . . . . . . . 10 72 4.4.1. The Protocols Supported TLV . . . . . . . . . . . . . 10 73 4.4.2. The Area Address TLV . . . . . . . . . . . . . . . . 10 74 4.4.3. The Dynamic Hostname TLV . . . . . . . . . . . . . . 10 75 4.4.4. The IS Neighbors TLV . . . . . . . . . . . . . . . . 10 76 4.4.5. The Extended IS Neighbors TLV . . . . . . . . . . . . 11 77 4.4.6. The MT Intermediate Systems TLV . . . . . . . . . . . 11 78 4.4.7. Reachability TLVs . . . . . . . . . . . . . . . . . . 11 79 4.4.8. The Router Capability TLV . . . . . . . . . . . . . . 12 80 4.4.9. The Multi-Topology TLV . . . . . . . . . . . . . . . 12 81 4.4.10. The SID/Label Binding and The Multi-Topology 82 SID/Label Binding SID TLV . . . . . . . . . . . . . . 12 83 4.4.11. The Area Segment SID TLV . . . . . . . . . . . . . . 12 84 4.4.11.1. Flags . . . . . . . . . . . . . . . . . . . . . 13 85 5. Inside Edge Router Functions . . . . . . . . . . . . . . . . 14 86 5.1. Generating L2 IIHs to Outside Routers . . . . . . . . . . 14 87 5.2. Filtering LSP information . . . . . . . . . . . . . . . . 14 88 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15 89 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 90 8. Security Considerations . . . . . . . . . . . . . . . . . . . 16 91 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 92 9.1. Normative References . . . . . . . . . . . . . . . . . . 16 93 9.2. Informative References . . . . . . . . . . . . . . . . . 17 94 9.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 17 95 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 97 1. Introduction 99 The IS-IS routing protocol IS-IS [ISO10589] currently supports a two- 100 level hierarchy of abstraction. The fundamental unit of abstraction 101 is the 'area', which is a (hopefully) connected set of systems 102 running IS-IS at the same level. Level 1, the lowest level, is 103 abstracted by routers that participate in both Level 1 and Level 2, 104 and they inject area information into Level 2. Level 2 systems 105 seeking to access Level 1, use this abstraction to compute the 106 shortest path to the Level 1 area. The full topology database of 107 Level 1 is not injected into Level 2, only a summary of the address 108 space contained within the area, so the scalability of the Level 2 109 Link State Database (LSDB) is protected. 111 This works well if the Level 1 area is tangential to the Level 2 112 area. This also works well if there are several routers in both 113 Level 1 and Level 2 and they are adjacent, so Level 2 traffic will 114 never need to transit Level 1 only routers. Level 1 will not contain 115 any Level 2 topology, and Level 2 will only contain area abstractions 116 for Level 1. 118 Unfortunately, this scheme does not work so well if the Level 1 only 119 area needs to provide transit for Level 2 traffic. For Level 2 120 shortest path first (SPF) computations to work correctly, the transit 121 topology must also appear in the Level 2 LSDB. This implies that all 122 routers that could provide transit, plus any links that might also 123 provide Level 2 transit must also become part of the Level 2 124 topology. If this is a relatively tiny portion of the Level 1 area, 125 this is not overly painful. 127 However, with today's data center topologies, this is problematic. A 128 common application is to use a Layer 3 Leaf-Spine (L3LS) topology, 129 which is a folded 3-stage Clos [Clos] fabric. It can also be thought 130 of as a complete bipartite graph. In such a topology, the desire is 131 to use Level 1 to contain the routing dynamics of the entire L3LS 132 topology and then to use Level 2 for the remainder of the network. 133 Leaves in the L3LS topology are appropriate for connection outside of 134 the data center itself, so they would provide connectivity for Level 135 2. If there are multiple connections to Level 2 for redundancy, or 136 other areas, these too would also be made to the leaves in the 137 topology. This creates a difficulty because there are now multiple 138 Level 2 leaves in the topology, with connectivity between the leaves 139 provided by the spines. 141 Following the current rules of IS-IS, all spine routers would 142 necessarily be part of the Level 2 topology, plus all links between a 143 Level 2 leaf and the spines. In the limit, where all leaves need to 144 support Level 2, it implies that the entire L3LS topology becomes 145 part of Level 2. This is seriously problematic as it more than 146 doubles the LSDB held in the L3LS topology and eliminates any 147 benefits of the hierarchy. 149 This document discusses the handling of IP traffic. Supporting MPLS 150 based traffic is a subject for future work. 152 1.1. Requirements Language 154 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 155 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 156 document are to be interpreted as described in BCP 14 [1] [RFC2119] 157 [RFC8174] when, and only when, they appear in all capitals, as shown 158 here. 160 2. Area Proxy 162 To address this, we propose to completely abstract away the details 163 of the Level 1 area topology within Level 2, making the entire area 164 look like a single proxy system directly connected to all of the 165 area's Level 2 neighbors. By only providing an abstraction of the 166 topology, Level 2's requirement for connectivity can be satisfied 167 without the full overhead of the area's internal topology. It then 168 becomes the responsibility of the Level 1 area to ensure the 169 forwarding connectivity that's advertised. 171 For this discussion, we'll consider a single Level 1 IS-IS area to be 172 the Inside Area, and the remainder of the Level 2 area is the Outside 173 Area. All routers within the Inside Area speak Level 1 and Level 2 174 IS-IS on all of the links within the topology. We propose to 175 implement Area Proxy by having a Level 2 Proxy Link State Protocol 176 Data Unit (PDU, LSP) that represents the entire Inside Area. This is 177 the only LSP from the area that will be flooded into the overall 178 Level 2 LSDB. 180 There are four classes of routers that we need to be concerned with 181 in this discussion: 183 Inside Router A router within the Inside Area that runs Level 1 and 184 Level 2 IS-IS. A router is recognized as an Inside Router by the 185 existence of its LSP in the Level 1 LSDB. 187 Area Leader The Area Leader is an Inside Router that is elected to 188 represent the Level 1 area by injecting the Proxy LSP into the 189 Level 2 LSDB. There may be multiple candidates for Area Leader, 190 but only one is elected at a given time. 192 Inside Edge Router An Inside Edge Router is an Inside Area Router 193 that has at least one Level 2 interface outside of the Inside 194 Area. An interface on an Inside Edge Router that is connected to 195 an Outside Edge Router is an Area Proxy Boundary. 197 Outside Edge Router An Outside Edge Router is a Level 2 router that 198 is outside of the Inside Area that has an adjacency with an Inside 199 Edge Router. 201 All Inside Edge Routers learn the Area Proxy System Identifier from 202 the Level 1 LSDB and use that as the system identifier in their Level 203 2 IS-IS Hello PDUs (IIHs) on all Outside interfaces. Outside Edge 204 Routers should then advertise an adjacency to the Area Proxy System 205 Identifier. This allows all Outside Routers to use the Proxy LSP in 206 their SPF computations without seeing the full topology of the Inside 207 Area. 209 Area Proxy functionality assumes that all circuits on Inside Routers 210 are either Level 1-2 circuits within the Inside Area, or Level 2 211 circuits between Outside Edge Routers and Inside Edge Routers. 213 Area Proxy Boundary multi-access circuits (i.e. Ethernets in LAN 214 mode) with multiple Inside Edge Routers and Outside Routers are not 215 recommended. The Inside Edge Routers MUST NOT flood Inside Router 216 LSPs on this link and thus the Boundary LAN does not provide 217 connectivity within the Inside Area. Boundary LANs SHOULD NOT be 218 enabled for Level 1. An Inside Edge Router may be elected the DIS 219 for a Boundary LAN. In this case using the Area Proxy System Id as 220 the basis for the LAN pseudonode identifier could create a collision, 221 so the Insider Edge Router SHOULD compose the pseudonode identifier 222 using its native system identifier. 224 2.1. Segment Routing 226 If the Inside Area supports Segment Routing [RFC8402], then all 227 Inside Nodes MUST advertise an SR Global Block (SRGB). The values of 228 the SRGB advertised by all Inside Nodes MUST be the same. 230 To support Segment Routing, the Area Leader will take the global SID 231 information found in the L1 LSDB and convey that to L2 through the 232 Proxy LSP. Prefixes with SID assignments will be copied to the Proxy 233 LSP. Adjacency SIDs for Outside Edge Nodes will be copied to the 234 Proxy LSP. 236 To further extend Segment Routing, it would be helpful to have a SID 237 that refers to the entire Inside Area. This allows a path to refer 238 to an area and have any node within that area accept and forward the 239 packet. In effect, this becomes an anycast SID that is accepted by 240 all Inside Edge Nodes. The information about this SID is distributed 241 in the Area Segment SID Sub-TLV, as part of the Area Leader's Area 242 Proxy TLV (Section 4.3.2). The Inside Edge Nodes MUST establish 243 forwarding based on this SID. The Area Leader SHALL also include the 244 Area Segment SID TLV in the Area Proxy LSP so that the remainder of 245 L2 can use it for path construction (Section 4.4.11). These two TLVs 246 are similar in structure, so care must be taken not to confuse them. 248 3. Inside Router Functions 250 All Inside Routers run Level 1-2 IS-IS and must be explicitly 251 instructed to enable the Area Proxy functionality. To signal their 252 readiness to participate in Area Proxy functionality, they will 253 advertise the Area Proxy Router Capability as part of its Level 1 254 Router Capability TLV. 256 3.1. The Area Proxy Router Capability 258 The Area Proxy Router Capability is a sub-TLV of the Router 259 Capability TLV [RFC7981] and has the following format: 261 0 1 262 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 263 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 264 | TLV Type | TLV Length | 265 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 267 TLV Type: LLL 269 TLV Length: 0 271 A router advertising this TLV indicates that it is running Level 1-2 272 and is prepared to perform Area Proxy functions. 274 3.2. Level 2 SPF Computation 276 When Outside Routers perform a Level 2 SPF computation, they will use 277 the Area Proxy LSP for computing a path transiting the Inside Area. 278 Because the topology has been abstracted away, the cost for 279 transiting the Inside Area will be zero. 281 When Inside Routers perform a Level 2 SPF computation, they MUST 282 ignore the Area Proxy LSP. Further, because these systems do see the 283 Inside Area topology, the link metrics internal to the area are 284 visible. This could lead to different and possibly inconsistent SPF 285 results, potentially leading to forwarding loops. 287 To prevent this, the Inside Routers MUST consider the metrics of 288 links outside of the Inside Area (inter-area metrics) separately from 289 the metrics of the Inside Area links (intra-area metrics). Intra- 290 area metrics MUST be treated as less than any inter-area metric. 291 Thus, if two paths have different total inter-area metrics, the path 292 with the lower inter-area metric would be preferred, regardless of 293 any intra-area metrics involved. However, if two paths have equal 294 inter-area metrics, then the intra-area metrics would be used to 295 compare the paths. 297 Point-to-Point links between two Inside Routers are considered to be 298 Inside Area links. LAN links which have a pseudonode LSP in the 299 Level 1 LSDB are considered to be Inside Area links. 301 3.3. The Inside Node TLV 303 To simplify determining which nodes belong to the Inside Area, all 304 Inside Nodes MUST insert the Inside Node TLV into their LSP and into 305 any Inside Area pseudonode LSPs. The format of the Inside Node TLV 306 is: 308 0 1 309 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 310 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 311 | Type | Length | 312 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 314 Type: ZZZ 316 Length: Zero (0) 318 4. Area Leader Functions 320 The Area Leader has several responsibilities. First, it MUST inject 321 the Area Proxy System Identifier into the Level 1 LSDB. Second, the 322 Area Leader MUST generate the Proxy LSP for the Inside Area. 324 4.1. Area Leader Election 326 The Area Leader is selected using the election mechanisms and TLVs 327 described in Dynamic Flooding for IS-IS 328 [I-D.ietf-lsr-dynamic-flooding]. 330 4.2. Redundancy 332 If the Area Leader fails, another candidate may become Area Leader 333 and MUST regenerate the Area Proxy LSP. The failure of the Area 334 Leader is not visible outside of the area and appears to simply be an 335 update of the Area Proxy LSP. 337 For consistency, all Area Leader candidates SHOULD be configured with 338 the same Proxy System Id, Proxy Hostname, and any other information 339 that may be inserted into the Proxy LSP. 341 4.3. The Area Proxy TLV 343 The Area Proxy TLV is a container for sub-TLVs with Area Proxy 344 Information. This TLV is injected into the Area Leader's Level 1 345 LSP. 347 The format of the Area Proxy TLV is: 349 0 1 2 350 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 351 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 352 | TLV Type | TLV Length | Sub-TLVs ... 353 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 355 TLV Type: YYY 357 TLV Length: length of the sub-TLVs 359 4.3.1. The Area Proxy System Id Sub-TLV 361 The Area Proxy System Id Sub-TLV MUST be used by the Area Leader to 362 distribute the Area Proxy System Id. This is an additional system 363 identifier that is used by Inside Nodes. The format of this sub-TLV 364 is: 366 0 1 2 367 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 368 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 369 | Type | Length | Proxy System ID | 370 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 371 | Proxy System Identifier continued | 372 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 374 Type: AAA 376 Length: length of a system ID (6) 378 Proxy System Identifier: the Area Proxy System Identifier. 380 The Area Leader SHOULD advertise the Area Proxy System Identifier 381 Sub-TLV when it observes that all Inside Routers are advertising the 382 Area Proxy Router Capability. Their advertisements indicate that 383 they are individually ready to perform Area Proxy functionality. The 384 Area Leader then advertises the Area Proxy System Identifier TLV to 385 indicate that the Inside Area SHOULD enable Area Proxy functionality. 387 Other candidates for Area Leader MAY also advertise the Area Proxy 388 System Identifier when they observe that all Inside Routers are 389 advertising the Area Proxy Router Capability. All candidates 390 advertising the Area Proxy System Identifier TLV MUST be advertising 391 the same system identifier. Multiple proxy system identifiers in a 392 single area is a misconfiguration and each unique occurrence SHOULD 393 be logged. 395 The Area Leader and other candidates for Area Leader MAY withdraw the 396 Area Proxy System Identifier when one or more Inside Routers are not 397 advertising the Area Proxy Router Capability. This will disable Area 398 Proxy functionality. However, before withdrawing the Area Proxy 399 System Identifier, an implementation SHOULD protect against 400 unnecessary churn from transients by delaying the withdrawal. The 401 amount of delay is implementation-dependent. 403 4.3.2. The Area Segment SID Sub-TLV 405 The Area Segment SID Sub-TLV allows the Area Leader to advertise a 406 SID that represents the entirety of the Inside Area to the Outside 407 Area. This sub-TLV is learned by all of the Inside Edge Nodes who 408 should consume this SID at forwarding time. The Area Segment SID 409 Sub-TLV has the format: 411 0 1 2 412 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 413 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 414 | Type | Length | Flags | 415 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 416 | SID/Index/Label (variable) | 417 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 419 where: 421 Type: BBB 423 Length: variable (1 + SID length) 425 Flags: 1 octet, see Section 4.4.11.1 427 SID/Index/Label: as defined in [RFC8667] Section 2.1.1.1 429 4.4. Area Proxy LSP Generation 431 Each Inside Router generates a Level 2 LSP, and the Level 2 LSPs for 432 the Inside Edge Routers will include adjacencies to Outside Edge 433 Routers. Unlike normal Level 2 operations, these LSPs are not 434 advertised outside of the Inside Area and MUST be filtered by all 435 Inside Edge Routers to not be flooded to Outside Routers. Only the 436 Area Proxy LSP is injected into the overall Level 2 LSDB. 438 The Area Leader uses the Level 2 LSPs generated by the Inside Edge 439 Routers to generate the Area Proxy LSP. This LSP is originated using 440 the Area Proxy System Identifier. The Area Leader MAY also insert 441 the following additional TLVs into the Area Proxy LSP for additional 442 information for the Outside Area. LSPs generated by unreachable 443 nodes MUST NOT be considered. 445 4.4.1. The Protocols Supported TLV 447 The Area Leader SHOULD insert a Protocols Supported TLV (129) 448 [RFC1195] into the Area Proxy LSP. The values included in the TLV 449 SHOULD be the protocols supported by the Inside Area. 451 4.4.2. The Area Address TLV 453 The Area Leader SHOULD insert an Area Addresses TLV (1) [ISO10589] 454 into the Area Proxy LSP. 456 4.4.3. The Dynamic Hostname TLV 458 It is RECOMMENDED that the Area Leader insert the Dynamic Hostname 459 TLV (137) [RFC5301] into the Area Proxy LSP. The contents of the 460 hostname may be specified by configuration. The presence of the 461 hostname helps to simplify debugging the network. 463 4.4.4. The IS Neighbors TLV 465 The Area Leader MAY insert the IS Neighbors TLV (2) [ISO10589] into 466 the Area Proxy LSP for Outside Edge Routers. The Area Leader learns 467 of the Outside Edge Routers by examining the LSPs generated by the 468 Inside Edge Routers copying any IS Neighbors TLVs referring to 469 Outside Edge Routers into the Proxy LSP. Since the Outside Edge 470 Routers advertise an adjacency to the Area Proxy System Identifier, 471 this will result in a bi-directional adjacency. 473 An entry for a neighbor in both the IS Neighbors TLV and the Extended 474 IS Neighbors would be functionally redundant, so the Area Leader 475 SHOULD NOT do this. 477 4.4.5. The Extended IS Neighbors TLV 479 The Area Leader MAY insert the Extended IS Reachability TLV (22) 480 [RFC3784] into the Area Proxy LSP. The Area Leader SHOULD copy each 481 Extended IS Reachability TLV advertised by an Inside Edge Router 482 about an Outside Edge Router into the Proxy LSP. 484 If the Inside Area supports Segment Routing and Segment Routing 485 selects a SID where the L-Flag is unset, then the Area Lead SHOULD 486 include an Adjacency Segment Identifier sub-TLV (31) [RFC8667] using 487 the selected SID. 489 4.4.6. The MT Intermediate Systems TLV 491 If the Inside Area supports Multi-Topology, then the Area Leader 492 SHOULD copy each Outside Edge Router advertisement that is advertised 493 by an Inside Edge Router in a MT Intermediate Systems TLV into the 494 Proxy LSP. 496 4.4.7. Reachability TLVs 498 The Area Leader SHOULD insert additional TLVs describing any routing 499 prefixes that should be advertised on behalf of the area. These 500 prefixes may be learned from the Level 1 LSDB, Level 2 LSDB, or 501 redistributed from another routing protocol. This applies to all of 502 various types of TLVs used for prefix advertisement: 504 IP Internal Reachability Information TLV (128) [RFC1195] 506 IP External Reachability Information TLV (130) [RFC1195] 508 Extended IP Reachability TLV (135) [RFC5305] 510 IPv6 Reachability TLV (236) [RFC5308] 512 Multi-Topology Reachable IPv4 Prefixes TLV (235) [RFC5120] 514 Multi-Topology Reachable IPv6 Prefixes TLV (237) [RFC5120] 516 For TLVs in the Level 1 LSDB, for a given TLV type and prefix, the 517 Area Leader SHOULD select the TLV with the lowest metric and copy 518 that TLV into the Area Proxy LSP. 520 When examining the Level 2 LSDB for this function, the Area Leader 521 SHOULD only consider TLVs advertised by Inside Routers. Further, for 522 prefixes that represent Boundary links, the Area Leader SHOULD copy 523 all TLVs that have unique sub-TLV contents. 525 If the Inside Area supports Segment Routing and the selected TLV 526 includes a Prefix Segment Identifier sub-TLV (3) [RFC8667], then the 527 sub-TLV SHOULD be copied as well. The P-Flag SHOULD be set in the 528 copy of the sub-TLV to indicate that penultimate hop popping SHOULD 529 not be performed for this prefix. The E-Flag SHOULD be reset in the 530 copy of the sub-TLV to indicate that an explicit NULL is not 531 required. The R-Flag SHOULD simply be copied. 533 4.4.8. The Router Capability TLV 535 The Area Leader MAY insert the Router Capability TLV (242) [RFC7981] 536 into the Area Proxy LSP. If Segment Routing is supported by the 537 inside area, as indicated by the presence of an SRGB being advertised 538 by all Inside Nodes, then the Area Leader SHOULD advertise an SR- 539 Capabilities sub-TLV (2) [RFC8667] with an SRGB identical to that 540 advertised by all Inside Routers. The Area Leader SHOULD use its own 541 Router Id in the Router Capability TLV. 543 4.4.9. The Multi-Topology TLV 545 If the Inside Area supports multi-topology, then the Area Leader 546 SHOULD insert the Multi-Topology TLV (229) [RFC5120], including the 547 topologies supported by the Inside Nodes. 549 If any Inside Node is advertising the 'O' (Overload) bit for a given 550 topology, then the Area Leader MUST advertise the 'O' bit for that 551 topology. If any Inside Node is advertising the 'A' (Attach) bit for 552 a given topology, then the Area Leader MUST advertise the 'A' bit for 553 that topology. 555 4.4.10. The SID/Label Binding and The Multi-Topology SID/Label Binding 556 SID TLV 558 If an Inside Node advertises the SID/Label Binding or Multi-Topology 559 SID/Label Binding SID TLV [RFC8667], then the Area Leader MAY copy 560 the TLV to the Area Proxy LSP. 562 4.4.11. The Area Segment SID TLV 564 If the Area Leader is advertising an Area Segment SID in the Area 565 Segment SID sub-TLV of the Area Proxy TLV, then the Area Leader 566 SHOULD adverise the Area Segment SID TLV in the Proxy LSP. The 567 advertisement in the Proxy LSP informs the remainder of the network 568 that packets directed to the SID will be forwarded by one of the 569 Inside Edge Nodes and the Area Segment SID will be consumed. 571 This TLV is not specific to Area Proxy and MAY be used by Edge 572 Routers in conventional areas. The Area Segment SID TLV has the 573 format: 575 0 1 2 576 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 577 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 578 | Type | Length | Flags | 579 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 580 | SID/Index/Label (variable) | 581 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 583 where: 585 Type: XXX 587 Length: variable (1 + SID length) 589 Flags: 1 octet, see below 591 SID/Index/Label: as defined in [RFC8667] Section 2.1.1.1 593 4.4.11.1. Flags 595 The Flags octet is defined as follows: 597 0 1 2 3 4 5 6 7 598 +-+-+-+-+-+-+-+-+ 599 |F|M|S|D|A| | 600 +-+-+-+-+-+-+-+-+ 602 where: 604 F: Not used. MUST be zero when originated and ignored when 605 received. Retained for compatibility with [RFC8667]. 607 M: Not used. MUST be zero when originated and ignored when 608 received. Retained for compatibility with [RFC8667]. 610 S: Not used. MUST be zero when originated and ignored when 611 received. Retained for compatibility with [RFC8667]. 613 D: Not used. MUST be zero when originated and ignored when 614 received. Retained for compatibility with [RFC8667]. 616 A: Not used. MUST be zero when originated and ignored when 617 received. Retained for compatibility with [RFC8667]. 619 Other bits: MUST be zero when originated and ignored when 620 received. 622 5. Inside Edge Router Functions 624 The Inside Edge Router has two additional and important functions. 625 First, it MUST generate IIHs that appear to have come from the Area 626 Proxy System Identifier. Second, it MUST filter the L2 LSPs, Partial 627 Sequence Number PDUs (PSNPs), and Complete Sequence Number PDUs 628 (CSNPs) that are being advertised to Outside Routers. 630 5.1. Generating L2 IIHs to Outside Routers 632 The Inside Edge Router has one or more Level 2 interfaces to Outside 633 Routers. These may be identified by explicit configuration or by the 634 fact that they are not also Level 1 circuits. On these Level 2 635 interfaces, the Inside Edge Router MUST NOT send an IIH until it has 636 learned the Area Proxy System Id from the Area Leader. Then, once it 637 has learned the Area Proxy System Id, it MUST generate its IIHs on 638 the circuit using the Proxy System Id as the source of the IIH. 640 Using the Proxy System Id causes the Outside Router to advertise an 641 adjacency to the Proxy System Id, not to the Inside Edge Router, 642 which supports the proxy function. The normal system id of the 643 Inside Edge Router MUST NOT be used as it will cause unnecessary 644 adjacencies to form and subsequently flap. 646 5.2. Filtering LSP information 648 For the proxy abstraction to be effective the L2 LSPs generated by 649 the Inside Routers MUST be restricted to the Inside Area. The Inside 650 Routers know which system ids are members of the Inside Area based on 651 the Level 1 LSDB. To prevent unwanted LSP information from escaping 652 the Inside Area, the Inside Edge Router MUST perform filtering of LSP 653 flooding, CSNPs, and PSNPs. Specifically: 655 A Level 2 LSP with a source system identifier that is found in the 656 Level 1 LSDB MUST never be flooded to an Outside Router. 658 A Level 2 CSNP sent to an Outside Router MUST NOT contain any 659 information about an LSP with a system identifier found in the 660 Level 1 LSDB. If an Inside Edge Router filters a CSNP and there 661 is no remaining content, then the CSNP MUST NOT be sent. The 662 source address of the CSNP MUST be the Area Proxy System Id. 664 A Level 2 PSNP sent to an Outside Router MUST NOT contain any 665 information about an LSP with a system identifier found in the 666 Level 1 LSDB. If an Inside Edge Router filters a PSNP and there 667 is no remaining content, then the PSNP MUST NOT be sent. The 668 source address of the PSNP MUST be the Area Proxy System Id. 670 6. Acknowledgments 672 The authors would like to thank Bruno Decraene, Vivek Ilangovan, and 673 Gunter Van De Velde for their many helpful comments. The authors 674 would also like to thank a small group that wishes to remain 675 anonymous for their valuable contributions. 677 7. IANA Considerations 679 This memo requests that IANA allocate and assign one code point from 680 the IS-IS TLV Codepoints registry for the Area Segment SID TLV (XXX), 681 one code point for the Area Proxy TLV (YYY), and one code point for 682 the Inside Node TLV (ZZZ). In association with this, this memo 683 requests that IANA create a registry for code points for the sub-TLVs 684 of the Area Proxy TLV. 686 Name of the registry: Sub-TLVs for TLV YYY (Area Proxy TLV) 688 Required information for registrations: Temporary registrations 689 may be made under the Early IANA Allocation of Standards Track 690 Code Points policy. [RFC7120] Permanent registrations require the 691 publication of an RFC describing the usage of the code point. 693 Applicable registration policy: RFC Required and Expert Review. 694 We propose the initial experts be Chris Hopps, Tony Li, and Sarah 695 Chen. 697 Size, format, and syntax of registry entries: Value (0-255), Name, 698 and Reference 700 Initial assignments and reservations: IANA is requested to assign 701 the following code points: 703 +-------+------------------------------+---------------+ 704 | Value | Name | Reference | 705 +-------+------------------------------+---------------+ 706 | AAA | Area Proxy System Identifier | This document | 707 | BBB | Area Segment SID | This document | 708 +-------+------------------------------+---------------+ 710 IANA is also requested to allocate and assign one code point from the 711 IS-IS Router Capability TLV sub-TLV registry for the Area Proxy 712 Capability (LLL). 714 8. Security Considerations 716 This document introduces no new security issues. Security of routing 717 within a domain is already addressed as part of the routing protocols 718 themselves. This document proposes no changes to those security 719 architectures. 721 9. References 723 9.1. Normative References 725 [I-D.ietf-lsr-dynamic-flooding] 726 Li, T., Psenak, P., Ginsberg, L., Chen, H., Przygienda, 727 T., Cooper, D., Jalil, L., and S. Dontula, "Dynamic 728 Flooding on Dense Graphs", draft-ietf-lsr-dynamic- 729 flooding-04 (work in progress), November 2019. 731 [ISO10589] 732 International Organization for Standardization, 733 "Intermediate System to Intermediate System Intra-Domain 734 Routing Exchange Protocol for use in Conjunction with the 735 Protocol for Providing the Connectionless-mode Network 736 Service (ISO 8473)", ISO/IEC 10589:2002, Nov. 2002. 738 [RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and 739 dual environments", RFC 1195, DOI 10.17487/RFC1195, 740 December 1990, . 742 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 743 Requirement Levels", BCP 14, RFC 2119, 744 DOI 10.17487/RFC2119, March 1997, 745 . 747 [RFC3784] Smit, H. and T. Li, "Intermediate System to Intermediate 748 System (IS-IS) Extensions for Traffic Engineering (TE)", 749 RFC 3784, DOI 10.17487/RFC3784, June 2004, 750 . 752 [RFC5120] Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi 753 Topology (MT) Routing in Intermediate System to 754 Intermediate Systems (IS-ISs)", RFC 5120, 755 DOI 10.17487/RFC5120, February 2008, 756 . 758 [RFC5301] McPherson, D. and N. Shen, "Dynamic Hostname Exchange 759 Mechanism for IS-IS", RFC 5301, DOI 10.17487/RFC5301, 760 October 2008, . 762 [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic 763 Engineering", RFC 5305, DOI 10.17487/RFC5305, October 764 2008, . 766 [RFC5308] Hopps, C., "Routing IPv6 with IS-IS", RFC 5308, 767 DOI 10.17487/RFC5308, October 2008, 768 . 770 [RFC7981] Ginsberg, L., Previdi, S., and M. Chen, "IS-IS Extensions 771 for Advertising Router Information", RFC 7981, 772 DOI 10.17487/RFC7981, October 2016, 773 . 775 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 776 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 777 May 2017, . 779 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 780 Decraene, B., Litkowski, S., and R. Shakir, "Segment 781 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 782 July 2018, . 784 [RFC8667] Previdi, S., Ed., Ginsberg, L., Ed., Filsfils, C., 785 Bashandy, A., Gredler, H., and B. Decraene, "IS-IS 786 Extensions for Segment Routing", RFC 8667, 787 DOI 10.17487/RFC8667, December 2019, 788 . 790 9.2. Informative References 792 [Clos] Clos, C., "A Study of Non-Blocking Switching Networks", 793 The Bell System Technical Journal Vol. 32(2), DOI 794 10.1002/j.1538-7305.1953.tb01433.x, March 1953, 795 . 797 [RFC7120] Cotton, M., "Early IANA Allocation of Standards Track Code 798 Points", BCP 100, RFC 7120, DOI 10.17487/RFC7120, January 799 2014, . 801 9.3. URIs 803 [1] https://tools.ietf.org/html/bcp14 805 Authors' Addresses 806 Tony Li 807 Arista Networks 808 5453 Great America Parkway 809 Santa Clara, California 95054 810 USA 812 Email: tony.li@tony.li 814 Sarah Chen 815 Arista Networks 816 5453 Great America Parkway 817 Santa Clara, California 95054 818 USA 820 Email: sarahchen@arista.com