idnits 2.17.1 draft-li-lsr-isis-area-proxy-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). == 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 document date (March 5, 2020) is 1513 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 781 == 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 6, 2020 March 5, 2020 7 Area Proxy for IS-IS 8 draft-li-lsr-isis-area-proxy-02 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 6, 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 4. Area Leader Functions . . . . . . . . . . . . . . . . . . . . 7 65 4.1. Area Leader Election . . . . . . . . . . . . . . . . . . 7 66 4.2. Redundancy . . . . . . . . . . . . . . . . . . . . . . . 7 67 4.3. The Area Proxy TLV . . . . . . . . . . . . . . . . . . . 7 68 4.3.1. The Area Proxy System Id Sub-TLV . . . . . . . . . . 8 69 4.3.2. The Area Segment SID Sub-TLV . . . . . . . . . . . . 9 70 4.4. Area Proxy LSP Generation . . . . . . . . . . . . . . . . 9 71 4.4.1. The Protocols Supported TLV . . . . . . . . . . . . . 10 72 4.4.2. The Area Address TLV . . . . . . . . . . . . . . . . 10 73 4.4.3. The Dynamic Hostname TLV . . . . . . . . . . . . . . 10 74 4.4.4. The IS Neighbors TLV . . . . . . . . . . . . . . . . 10 75 4.4.5. The Extended IS Neighbors TLV . . . . . . . . . . . . 10 76 4.4.6. The MT Intermediate Systems TLV . . . . . . . . . . . 11 77 4.4.7. Reachability TLVs . . . . . . . . . . . . . . . . . . 11 78 4.4.8. The Router Capability TLV . . . . . . . . . . . . . . 11 79 4.4.9. The Multi-Topology TLV . . . . . . . . . . . . . . . 12 80 4.4.10. The SID/Label Binding and The Multi-Topology 81 SID/Label Binding SID TLV . . . . . . . . . . . . . . 12 82 4.4.11. The Area Segment SID TLV . . . . . . . . . . . . . . 12 83 4.4.11.1. Flags . . . . . . . . . . . . . . . . . . . . . 13 84 5. Inside Edge Router Functions . . . . . . . . . . . . . . . . 13 85 5.1. Generating L2 IIHs to Outside Routers . . . . . . . . . . 13 86 5.2. Filtering LSP information . . . . . . . . . . . . . . . . 14 87 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14 88 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 89 8. Security Considerations . . . . . . . . . . . . . . . . . . . 15 90 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 91 9.1. Normative References . . . . . . . . . . . . . . . . . . 15 92 9.2. Informative References . . . . . . . . . . . . . . . . . 17 93 9.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 17 94 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 96 1. Introduction 98 The IS-IS routing protocol IS-IS [ISO10589] currently supports a two- 99 level hierarchy of abstraction. The fundamental unit of abstraction 100 is the 'area', which is a (hopefully) connected set of systems 101 running IS-IS at the same level. Level 1, the lowest level, is 102 abstracted by routers that participate in both Level 1 and Level 2, 103 and they inject area information into Level 2. Level 2 systems 104 seeking to access Level 1, use this abstraction to compute the 105 shortest path to the Level 1 area. The full topology database of 106 Level 1 is not injected into Level 2, only a summary of the address 107 space contained within the area, so the scalability of the Level 2 108 Link State Database (LSDB) is protected. 110 This works well if the Level 1 area is tangential to the Level 2 111 area. This also works well if there are several routers in both 112 Level 1 and Level 2 and they are adjacent, so Level 2 traffic will 113 never need to transit Level 1 only routers. Level 1 will not contain 114 any Level 2 topology, and Level 2 will only contain area abstractions 115 for Level 1. 117 Unfortunately, this scheme does not work so well if the Level 1 only 118 area needs to provide transit for Level 2 traffic. For Level 2 119 shortest path first (SPF) computations to work correctly, the transit 120 topology must also appear in the Level 2 LSDB. This implies that all 121 routers that could provide transit, plus any links that might also 122 provide Level 2 transit must also become part of the Level 2 123 topology. If this is a relatively tiny portion of the Level 1 area, 124 this is not overly painful. 126 However, with today's data center topologies, this is problematic. A 127 common application is to use a Layer 3 Leaf-Spine (L3LS) topology, 128 which is a folded 3-stage Clos [Clos] fabric. It can also be thought 129 of as a complete bipartite graph. In such a topology, the desire is 130 to use Level 1 to contain the routing dynamics of the entire L3LS 131 topology and then to use Level 2 for the remainder of the network. 132 Leaves in the L3LS topology are appropriate for connection outside of 133 the data center itself, so they would provide connectivity for Level 134 2. If there are multiple connections to Level 2 for redundancy, or 135 other areas, these too would also be made to the leaves in the 136 topology. This creates a difficulty because there are now multiple 137 Level 2 leaves in the topology, with connectivity between the leaves 138 provided by the spines. 140 Following the current rules of IS-IS, all spine routers would 141 necessarily be part of the Level 2 topology, plus all links between a 142 Level 2 leaf and the spines. In the limit, where all leaves need to 143 support Level 2, it implies that the entire L3LS topology becomes 144 part of Level 2. This is seriously problematic as it more than 145 doubles the LSDB held in the L3LS topology and eliminates any 146 benefits of the hierarchy. 148 This document discusses the handling of IP traffic. Supporting MPLS 149 based traffic is a subject for future work. 151 1.1. Requirements Language 153 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 154 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 155 document are to be interpreted as described in BCP 14 [1] [RFC2119] 156 [RFC8174] when, and only when, they appear in all capitals, as shown 157 here. 159 2. Area Proxy 161 To address this, we propose to completely abstract away the details 162 of the Level 1 area topology within Level 2, making the entire area 163 look like a single proxy system directly connected to all of the 164 area's Level 2 neighbors. By only providing an abstraction of the 165 topology, Level 2's requirement for connectivity can be satisfied 166 without the full overhead of the area's internal topology. It then 167 becomes the responsibility of the Level 1 area to ensure the 168 forwarding connectivity that's advertised. 170 For this discussion, we'll consider a single Level 1 IS-IS area to be 171 the Inside Area, and the remainder of the Level 2 area is the Outside 172 Area. All routers within the Inside Area speak Level 1 and Level 2 173 IS-IS on all of the links within the topology. We propose to 174 implement Area Proxy by having a Level 2 Proxy Link State Protocol 175 Data Unit (PDU, LSP) that represents the entire Inside Area. This is 176 the only LSP from the area that will be flooded into the overall 177 Level 2 LSDB. 179 There are four classes of routers that we need to be concerned with 180 in this discussion: 182 Inside Router A router within the Inside Area that runs Level 1 and 183 Level 2 IS-IS. A router is recognized as an Inside Router by the 184 existence of its LSP in the Level 1 LSDB. 186 Area Leader The Area Leader is an Inside Router that is elected to 187 represent the Level 1 area by injecting the Proxy LSP into the 188 Level 2 LSDB. There may be multiple candidates for Area Leader, 189 but only one is elected at a given time. 191 Inside Edge Router An Inside Edge Router is an Inside Area Router 192 that has at least one Level 2 interface outside of the Inside 193 Area. An interface on an Inside Edge Router that is connected to 194 an Outside Edge Router is an Area Proxy Boundary. 196 Outside Edge Router An Outside Edge Router is a Level 2 router that 197 is outside of the Inside Area that has an adjacency with an Inside 198 Edge Router. 200 All Inside Edge Routers learn the Area Proxy System Identifier from 201 the Level 1 LSDB and use that as the system identifier in their Level 202 2 IS-IS Hello PDUs (IIHs) on all Outside interfaces. Outside Edge 203 Routers should then advertise an adjacency to the Area Proxy System 204 Identifier. This allows all Outside Routers to use the Proxy LSP in 205 their SPF computations without seeing the full topology of the Inside 206 Area. 208 Area Proxy functionality assumes that all circuits on Inside Routers 209 are either Level 1-2 circuits within the Inside Area, or Level 2 210 circuits between Outside Edge Routers and Inside Edge Routers. 212 Area Proxy Boundary multi-access circuits (i.e. Ethernets in LAN 213 mode) with multiple Inside Edge Routers and Outside Routers are not 214 recommended. The Inside Edge Routers MUST NOT flood Inside Router 215 LSPs on this link and thus the Boundary LAN does not provide 216 connectivity within the Inside Area. Boundary LANs SHOULD NOT be 217 enabled for Level 1. An Inside Edge Router may be elected the DIS 218 for a Boundary LAN. In this case using the Area Proxy System Id as 219 the basis for the LAN pseudonode identifier could create a collision, 220 so the Insider Edge Router SHOULD compose the pseudonode identifier 221 using its native system identifier. 223 2.1. Segment Routing 225 If the Inside Area supports Segment Routing [RFC8402], then all 226 Inside Nodes MUST advertise an SR Global Block (SRGB). The values of 227 the SRGB advertised by all Inside Nodes MUST be the same. 229 To support Segment Routing, the Area Leader will take the global SID 230 information found in the L1 LSDB and convey that to L2 through the 231 Proxy LSP. Prefixes with SID assignments will be copied to the Proxy 232 LSP. Adjacency SIDs for Outside Edge Nodes will be copied to the 233 Proxy LSP. 235 To further extend Segment Routing, it would be helpful to have a SID 236 that refers to the entire Inside Area. This allows a path to refer 237 to an area and have any node within that area accept and forward the 238 packet. In effect, this becomes an anycast SID that is accepted by 239 all Inside Edge Nodes. The information about this SID is distributed 240 in the Area Segment SID Sub-TLV, as part of the Area Leader's Area 241 Proxy TLV (Section 4.3.2). The Inside Edge Nodes MUST establish 242 forwarding based on this SID. The Area Leader SHALL also include the 243 Area Segment SID TLV in the Area Proxy LSP so that the remainder of 244 L2 can use it for path construction (Section 4.4.11). These two TLVs 245 are similar in structure, so care must be taken not to confuse them. 247 3. Inside Router Functions 249 All Inside Routers run Level 1-2 IS-IS and must be explicitly 250 instructed to enable the Area Proxy functionality. To signal their 251 readiness to participate in Area Proxy functionality, they will 252 advertise the Area Proxy Router Capability as part of its Level 1 253 Router Capability TLV. 255 3.1. The Area Proxy Router Capability 257 The Area Proxy Router Capability is a sub-TLV of the Router 258 Capability TLV [RFC7981] and has the following format: 260 0 1 261 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 262 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 263 | TLV Type | TLV Length | 264 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 266 TLV Type: LLL 268 TLV Length: 0 270 A router advertising this TLV indicates that it is running Level 1-2 271 and is prepared to perform Area Proxy functions. 273 3.2. Level 2 SPF Computation 275 When Outside Routers perform a Level 2 SPF computation, they will use 276 the Area Proxy LSP for computing a path transiting the Inside Area. 277 Because the topology has been abstracted away, the cost for 278 transiting the Inside Area will be zero. 280 When Inside Routers perform a Level 2 SPF computation, they MUST 281 ignore the Area Proxy LSP. Further, because these systems do see the 282 Inside Area topology, the link metrics internal to the area are 283 visible. This could lead to different and possibly inconsistent SPF 284 results, potentially leading to forwarding loops. 286 To prevent this, the Inside Routers MUST consider the metrics of 287 links outside of the Inside Area (inter-area metrics) separately from 288 the metrics of the Inside Area links (intra-area metrics). Intra- 289 area metrics MUST be treated as less than any inter-area metric. 290 Thus, if two paths have different total inter-area metrics, the path 291 with the lower inter-area metric would be preferred, regardless of 292 any intra-area metrics involved. However, if two paths have equal 293 inter-area metrics, then the intra-area metrics would be used to 294 compare the paths. 296 Point-to-Point links between two Inside Routers are considered to be 297 Inside Area links. LAN links which have a pseudonode LSP in the 298 Level 1 LSDB are considered to be Inside Area links. 300 4. Area Leader Functions 302 The Area Leader has several responsibilities. First, it MUST inject 303 the Area Proxy System Identifier into the Level 1 LSDB. Second, the 304 Area Leader MUST generate the Proxy LSP for the Inside Area. 306 4.1. Area Leader Election 308 The Area Leader is selected using the election mechanisms and TLVs 309 described in Dynamic Flooding for IS-IS 310 [I-D.ietf-lsr-dynamic-flooding]. 312 4.2. Redundancy 314 If the Area Leader fails, another candidate may become Area Leader 315 and MUST regenerate the Area Proxy LSP. The failure of the Area 316 Leader is not visible outside of the area and appears to simply be an 317 update of the Area Proxy LSP. 319 For consistency, all Area Leader candidates SHOULD be configured with 320 the same Proxy System Id, Proxy Hostname, and any other information 321 that may be inserted into the Proxy LSP. 323 4.3. The Area Proxy TLV 325 The Area Proxy TLV is a container for sub-TLVs with Area Proxy 326 Information. This TLV is injected into the Area Leader's Level 1 327 LSP. 329 The format of the Area Proxy TLV is: 331 0 1 2 332 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 333 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 334 | TLV Type | TLV Length | Sub-TLVs ... 335 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 337 TLV Type: YYY 339 TLV Length: length of the sub-TLVs 341 4.3.1. The Area Proxy System Id Sub-TLV 343 The Area Proxy System Id Sub-TLV MUST be used by the Area Leader to 344 distribute the Area Proxy System Id. This is an additional system 345 identifier that is used by Inside Nodes. The format of this sub-TLV 346 is: 348 0 1 2 349 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 350 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 351 | Type | Length | Proxy System ID | 352 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 353 | Proxy System Identifier continued | 354 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 356 Type: AAA 358 Length: length of a system ID (6) 360 Proxy System Identifier: the Area Proxy System Identifier. 362 The Area Leader SHOULD advertise the Area Proxy System Identifier 363 Sub-TLV when it observes that all Inside Routers are advertising the 364 Area Proxy Router Capability. Their advertisements indicate that 365 they are individually ready to perform Area Proxy functionality. The 366 Area Leader then advertises the Area Proxy System Identifier TLV to 367 indicate that the Inside Area SHOULD enable Area Proxy functionality. 369 Other candidates for Area Leader MAY also advertise the Area Proxy 370 System Identifier when they observe that all Inside Routers are 371 advertising the Area Proxy Router Capability. All candidates 372 advertising the Area Proxy System Identifier TLV MUST be advertising 373 the same system identifier. Multiple proxy system identifiers in a 374 single area is a misconfiguration and each unique occurrence SHOULD 375 be logged. 377 The Area Leader and other candidates for Area Leader MAY withdraw the 378 Area Proxy System Identifier when one or more Inside Routers are not 379 advertising the Area Proxy Router Capability. This will disable Area 380 Proxy functionality. However, before withdrawing the Area Proxy 381 System Identifier, an implementation SHOULD protect against 382 unnecessary churn from transients by delaying the withdrawal. The 383 amount of delay is implementation-dependent. 385 4.3.2. The Area Segment SID Sub-TLV 387 The Area Segment SID Sub-TLV allows the Area Leader to advertise a 388 SID that represents the entirety of the Inside Area to the Outside 389 Area. This sub-TLV is learned by all of the Inside Edge Nodes who 390 should consume this SID at forwarding time. The Area Segment SID 391 Sub-TLV has the format: 393 0 1 2 394 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 395 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 396 | Type | Length | Flags | 397 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 398 | SID/Index/Label (variable) | 399 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 401 where: 403 Type: BBB 405 Length: variable (1 + SID length) 407 Flags: 1 octet, see Section 4.4.11.1 409 SID/Index/Label: as defined in [RFC8667] Section 2.1.1.1 411 4.4. Area Proxy LSP Generation 413 Each Inside Router generates a Level 2 LSP, and the Level 2 LSPs for 414 the Inside Edge Routers will include adjacencies to Outside Edge 415 Routers. Unlike normal Level 2 operations, these LSPs are not 416 advertised outside of the Inside Area and MUST be filtered by all 417 Inside Edge Routers to not be flooded to Outside Routers. Only the 418 Area Proxy LSP is injected into the overall Level 2 LSDB. 420 The Area Leader uses the Level 2 LSPs generated by the Inside Edge 421 Routers to generate the Area Proxy LSP. This LSP is originated using 422 the Area Proxy System Identifier. The Area Leader MAY also insert 423 the following additional TLVs into the Area Proxy LSP for additional 424 information for the Outside Area. LSPs generated by unreachable 425 nodes MUST NOT be considered. 427 4.4.1. The Protocols Supported TLV 429 The Area Leader SHOULD insert a Protocols Supported TLV (129) 430 [RFC1195] into the Area Proxy LSP. The values included in the TLV 431 SHOULD be the protocols supported by the Inside Area. 433 4.4.2. The Area Address TLV 435 The Area Leader SHOULD insert an Area Addresses TLV (1) [ISO10589] 436 into the Area Proxy LSP. 438 4.4.3. The Dynamic Hostname TLV 440 It is RECOMMENDED that the Area Leader insert the Dynamic Hostname 441 TLV (137) [RFC5301] into the Area Proxy LSP. The contents of the 442 hostname may be specified by configuration. The presence of the 443 hostname helps to simplify debugging the network. 445 4.4.4. The IS Neighbors TLV 447 The Area Leader MAY insert the IS Neighbors TLV (2) [ISO10589] into 448 the Area Proxy LSP for Outside Edge Routers. The Area Leader learns 449 of the Outside Edge Routers by examining the LSPs generated by the 450 Inside Edge Routers copying any IS Neighbors TLVs referring to 451 Outside Edge Routers into the Proxy LSP. Since the Outside Edge 452 Routers advertise an adjacency to the Area Proxy System Identifier, 453 this will result in a bi-directional adjacency. 455 An entry for a neighbor in both the IS Neighbors TLV and the Extended 456 IS Neighbors would be functionally redundant, so the Area Leader 457 SHOULD NOT do this. 459 4.4.5. The Extended IS Neighbors TLV 461 The Area Leader MAY insert the Extended IS Reachability TLV (22) 462 [RFC3784] into the Area Proxy LSP. The Area Leader SHOULD copy each 463 Extended IS Reachability TLV advertised by an Inside Edge Router 464 about an Outside Edge Router into the Proxy LSP. 466 If the Inside Area supports Segment Routing and Segment Routing 467 selects a SID where the L-Flag is unset, then the Area Lead SHOULD 468 include an Adjacency Segment Identifier sub-TLV (31) [RFC8667] using 469 the selected SID. 471 4.4.6. The MT Intermediate Systems TLV 473 If the Inside Area supports Multi-Topology, then the Area Leader 474 SHOULD copy each Outside Edge Router advertisement that is advertised 475 by an Inside Edge Router in a MT Intermediate Systems TLV into the 476 Proxy LSP. 478 4.4.7. Reachability TLVs 480 The Area Leader SHOULD insert additional TLVs describing any routing 481 prefixes that should be advertised on behalf of the area. These 482 prefixes may be learned from the Level 1 LSDB, Level 2 LSDB, or 483 redistributed from another routing protocol. This applies to all of 484 various types of TLVs used for prefix advertisement: 486 IP Internal Reachability Information TLV (128) [RFC1195] 488 IP External Reachability Information TLV (130) [RFC1195] 490 Extended IP Reachability TLV (135) [RFC5305] 492 IPv6 Reachability TLV (236) [RFC5308] 494 Multi-Topology Reachable IPv4 Prefixes TLV (235) [RFC5120] 496 Multi-Topology Reachable IPv6 Prefixes TLV (237) [RFC5120] 498 For TLVs in the Level 1 LSDB, for a given TLV type and prefix, the 499 Area Leader SHOULD select the TLV with the lowest metric and copy 500 that TLV into the Area Proxy LSP. 502 When examining the Level 2 LSDB for this function, the Area Leader 503 SHOULD only consider TLVs advertised by Inside Routers. Further, for 504 prefixes that represent Boundary links, the Area Leader SHOULD copy 505 all TLVs that have unique sub-TLV contents. 507 If the Inside Area supports Segment Routing and the selected TLV 508 includes a Prefix Segment Identifier sub-TLV (3) [RFC8667], then the 509 sub-TLV SHOULD be copied as well. The P-Flag SHOULD be set in the 510 copy of the sub-TLV to indicate that penultimate hop popping SHOULD 511 not be performed for this prefix. 513 4.4.8. The Router Capability TLV 515 The Area Leader MAY insert the Router Capability TLV (242) [RFC7981] 516 into the Area Proxy LSP. If Segment Routing is supported by the 517 inside area, as indicated by the presence of an SRGB being advertised 518 by all Inside Nodes, then the Area Leader SHOULD advertise an SR- 519 Capabilities sub-TLV (2) [RFC8667] with an SRGB identical to that 520 advertised by all Inside Routers. The Area Leader SHOULD use its own 521 Router Id in the Router Capability TLV. 523 4.4.9. The Multi-Topology TLV 525 If the Inside Area supports multi-topology, then the Area Leader 526 SHOULD insert the Multi-Topology TLV (229) [RFC5120], including the 527 topologies supported by the Inside Nodes. 529 If any Inside Node is advertising the 'O' (Overload) bit for a given 530 topology, then the Area Leader MUST advertise the 'O' bit for that 531 topology. If any Inside Node is advertising the 'A' (Attach) bit for 532 a given topology, then the Area Leader MUST advertise the 'A' bit for 533 that topology. 535 4.4.10. The SID/Label Binding and The Multi-Topology SID/Label Binding 536 SID TLV 538 If an Inside Node advertises the SID/Label Binding or Multi-Topology 539 SID/Label Binding SID TLV [RFC8667], then the Area Leader MAY copy 540 the TLV to the Area Proxy LSP. 542 4.4.11. The Area Segment SID TLV 544 If the Area Leader is advertising an Area Segment SID in the Area 545 Segment SID sub-TLV of the Area Proxy TLV, then the Area Leader 546 SHOULD adverise the Area Segment SID TLV in the Proxy LSP. The 547 advertisement in the Proxy LSP informs the remainder of the network 548 that packets directed to the SID will be forwarded by one of the 549 Inside Edge Nodes and the Area Segment SID will be consumed. 551 This TLV is not specific to Area Proxy and MAY be used by Edge 552 Routers in conventional areas. The Area Segment SID TLV has the 553 format: 555 0 1 2 556 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 557 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 558 | Type | Length | Flags | 559 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 560 | SID/Index/Label (variable) | 561 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 563 where: 565 Type: XXX 566 Length: variable (1 + SID length) 568 Flags: 1 octet, see below 570 SID/Index/Label: as defined in [RFC8667] Section 2.1.1.1 572 4.4.11.1. Flags 574 The Flags octet is defined as follows: 576 0 1 2 3 4 5 6 7 577 +-+-+-+-+-+-+-+-+ 578 |F|M|S|D|A| | 579 +-+-+-+-+-+-+-+-+ 581 where: 583 F: Not used. MUST be zero when originated and ignored when 584 received. Retained for compatibility with [RFC8667]. 586 M: Not used. MUST be zero when originated and ignored when 587 received. Retained for compatibility with [RFC8667]. 589 S: Not used. MUST be zero when originated and ignored when 590 received. Retained for compatibility with [RFC8667]. 592 D: Not used. MUST be zero when originated and ignored when 593 received. Retained for compatibility with [RFC8667]. 595 A: Not used. MUST be zero when originated and ignored when 596 received. Retained for compatibility with [RFC8667]. 598 Other bits: MUST be zero when originated and ignored when 599 received. 601 5. Inside Edge Router Functions 603 The Inside Edge Router has two additional and important functions. 604 First, it MUST generate IIHs that appear to have come from the Area 605 Proxy System Identifier. Second, it MUST filter the L2 LSPs, Partial 606 Sequence Number PDUs (PSNPs), and Complete Sequence Number PDUs 607 (CSNPs) that are being advertised to Outside Routers. 609 5.1. Generating L2 IIHs to Outside Routers 611 The Inside Edge Router has one or more Level 2 interfaces to Outside 612 Routers. These may be identified by explicit configuration or by the 613 fact that they are not also Level 1 circuits. On these Level 2 614 interfaces, the Inside Edge Router MUST NOT send an IIH until it has 615 learned the Area Proxy System Id from the Area Leader. Then, once it 616 has learned the Area Proxy System Id, it MUST generate its IIHs on 617 the circuit using the Proxy System Id as the source of the IIH. 619 Using the Proxy System Id causes the Outside Router to advertise an 620 adjacency to the Proxy System Id, not to the Inside Edge Router, 621 which supports the proxy function. The normal system id of the 622 Inside Edge Router MUST NOT be used as it will cause unnecessary 623 adjacencies to form and subsequently flap. 625 5.2. Filtering LSP information 627 For the proxy abstraction to be effective the L2 LSPs generated by 628 the Inside Routers MUST be restricted to the Inside Area. The Inside 629 Routers know which system ids are members of the Inside Area based on 630 the Level 1 LSDB. To prevent unwanted LSP information from escaping 631 the Inside Area, the Inside Edge Router MUST perform filtering of LSP 632 flooding, CSNPs, and PSNPs. Specifically: 634 A Level 2 LSP with a source system identifier that is found in the 635 Level 1 LSDB MUST never be flooded to an Outside Router. 637 A Level 2 CSNP sent to an Outside Router MUST NOT contain any 638 information about an LSP with a system identifier found in the 639 Level 1 LSDB. If an Inside Edge Router filters a CSNP and there 640 is no remaining content, then the CSNP MUST NOT be sent. The 641 source address of the CSNP MUST be the Area Proxy System Id. 643 A Level 2 PSNP sent to an Outside Router MUST NOT contain any 644 information about an LSP with a system identifier found in the 645 Level 1 LSDB. If an Inside Edge Router filters a PSNP and there 646 is no remaining content, then the PSNP MUST NOT be sent. The 647 source address of the PSNP MUST be the Area Proxy System Id. 649 6. Acknowledgments 651 The authors would like to thank Bruno Decraene, Vivek Ilangovan, and 652 Gunter Van De Velde for their many helpful comments. The authors 653 would also like to thank a small group that wishes to remain 654 anonymous for their valuable contributions. 656 7. IANA Considerations 658 This memo requests that IANA allocate and assign one code point from 659 the IS-IS TLV Codepoints registry for the Area Segment SID TLV (XXX) 660 and one code point for the Area Proxy TLV (YYY). In association with 661 this, this memo requests that IANA create a registry for code points 662 for the sub-TLVs of the Area Proxy TLV. 664 Name of the registry: Sub-TLVs for TLV YYY (Area Proxy TLV) 666 Required information for registrations: Temporary registrations 667 may be made under the Early IANA Allocation of Standards Track 668 Code Points policy. [RFC7120] Permanent registrations require the 669 publication of an RFC describing the usage of the code point. 671 Applicable registration policy: RFC Required and Expert Review. 672 We propose the initial experts be Chris Hopps, Tony Li, and Sarah 673 Chen. 675 Size, format, and syntax of registry entries: Value (0-255), Name, 676 and Reference 678 Initial assignments and reservations: IANA is requested to assign 679 the following code points: 681 +-------+------------------------------+---------------+ 682 | Value | Name | Reference | 683 +-------+------------------------------+---------------+ 684 | AAA | Area Proxy System Identifier | This document | 685 | BBB | Area Segment SID | This document | 686 +-------+------------------------------+---------------+ 688 IANA is also requested to allocate and assign one code point from the 689 IS-IS Router Capability TLV sub-TLV registry for the Area Proxy 690 Capability (LLL). 692 8. Security Considerations 694 This document introduces no new security issues. Security of routing 695 within a domain is already addressed as part of the routing protocols 696 themselves. This document proposes no changes to those security 697 architectures. 699 9. References 701 9.1. Normative References 703 [I-D.ietf-lsr-dynamic-flooding] 704 Li, T., Psenak, P., Ginsberg, L., Chen, H., Przygienda, 705 T., Cooper, D., Jalil, L., and S. Dontula, "Dynamic 706 Flooding on Dense Graphs", draft-ietf-lsr-dynamic- 707 flooding-04 (work in progress), November 2019. 709 [ISO10589] 710 International Organization for Standardization, 711 "Intermediate System to Intermediate System Intra-Domain 712 Routing Exchange Protocol for use in Conjunction with the 713 Protocol for Providing the Connectionless-mode Network 714 Service (ISO 8473)", ISO/IEC 10589:2002, Nov. 2002. 716 [RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and 717 dual environments", RFC 1195, DOI 10.17487/RFC1195, 718 December 1990, . 720 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 721 Requirement Levels", BCP 14, RFC 2119, 722 DOI 10.17487/RFC2119, March 1997, 723 . 725 [RFC3784] Smit, H. and T. Li, "Intermediate System to Intermediate 726 System (IS-IS) Extensions for Traffic Engineering (TE)", 727 RFC 3784, DOI 10.17487/RFC3784, June 2004, 728 . 730 [RFC5120] Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi 731 Topology (MT) Routing in Intermediate System to 732 Intermediate Systems (IS-ISs)", RFC 5120, 733 DOI 10.17487/RFC5120, February 2008, 734 . 736 [RFC5301] McPherson, D. and N. Shen, "Dynamic Hostname Exchange 737 Mechanism for IS-IS", RFC 5301, DOI 10.17487/RFC5301, 738 October 2008, . 740 [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic 741 Engineering", RFC 5305, DOI 10.17487/RFC5305, October 742 2008, . 744 [RFC5308] Hopps, C., "Routing IPv6 with IS-IS", RFC 5308, 745 DOI 10.17487/RFC5308, October 2008, 746 . 748 [RFC7981] Ginsberg, L., Previdi, S., and M. Chen, "IS-IS Extensions 749 for Advertising Router Information", RFC 7981, 750 DOI 10.17487/RFC7981, October 2016, 751 . 753 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 754 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 755 May 2017, . 757 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 758 Decraene, B., Litkowski, S., and R. Shakir, "Segment 759 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 760 July 2018, . 762 [RFC8667] Previdi, S., Ed., Ginsberg, L., Ed., Filsfils, C., 763 Bashandy, A., Gredler, H., and B. Decraene, "IS-IS 764 Extensions for Segment Routing", RFC 8667, 765 DOI 10.17487/RFC8667, December 2019, 766 . 768 9.2. Informative References 770 [Clos] Clos, C., "A Study of Non-Blocking Switching Networks", 771 The Bell System Technical Journal Vol. 32(2), DOI 772 10.1002/j.1538-7305.1953.tb01433.x, March 1953, 773 . 775 [RFC7120] Cotton, M., "Early IANA Allocation of Standards Track Code 776 Points", BCP 100, RFC 7120, DOI 10.17487/RFC7120, January 777 2014, . 779 9.3. URIs 781 [1] https://tools.ietf.org/html/bcp14 783 Authors' Addresses 785 Tony Li 786 Arista Networks 787 5453 Great America Parkway 788 Santa Clara, California 95054 789 USA 791 Email: tony.li@tony.li 793 Sarah Chen 794 Arista Networks 795 5453 Great America Parkway 796 Santa Clara, California 95054 797 USA 799 Email: sarahchen@arista.com