idnits 2.17.1 draft-chen-isis-ttz-12.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 date (August 18, 2020) is 1345 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) == Missing Reference: 'R71' is mentioned on line 225, but not defined == Missing Reference: 'R73' is mentioned on line 226, but not defined == Unused Reference: 'I-D.ietf-spring-segment-routing' is defined on line 891, but no explicit reference was found in the text == Unused Reference: 'RFC1195' is defined on line 904, but no explicit reference was found in the text == Unused Reference: 'RFC5029' is defined on line 913, but no explicit reference was found in the text == Unused Reference: 'RFC5305' is defined on line 917, but no explicit reference was found in the text == Unused Reference: 'RFC7142' is defined on line 921, but no explicit reference was found in the text == Unused Reference: 'Clos' is defined on line 932, but no explicit reference was found in the text == Unused Reference: 'RFC5307' is defined on line 937, but no explicit reference was found in the text == Outdated reference: A later version (-18) exists of draft-ietf-lsr-dynamic-flooding-07 ** 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' ** Downref: Normative reference to an Informational RFC: RFC 7142 ** Downref: Normative reference to an Experimental RFC: RFC 8099 Summary: 3 errors (**), 0 flaws (~~), 11 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force H. Chen 3 Internet-Draft R. Li 4 Intended status: Standards Track Futurewei 5 Expires: February 19, 2021 Y. Yang 6 IBM 7 A. Kumar S N 8 RtBrick 9 Y. Fan 10 Casa Systems 11 N. So 13 V. Liu 15 M. Toy 16 Verizon 17 L. Liu 18 Fujitsu 19 K. Makhijani 20 Futurewei 21 August 18, 2020 23 IS-IS Topology-Transparent Zone 24 draft-chen-isis-ttz-12.txt 26 Abstract 28 This document presents a topology-transparent zone in an area. A 29 zone is a block/piece of an area, which comprises a group of routers 30 and a number of circuits connecting them. It is abstracted as a 31 virtual entity such as a single virtual node or zone edges mesh. Any 32 router outside of the zone is not aware of the zone. The information 33 about the circuits and routers inside the zone is not distributed to 34 any router outside of the zone. 36 Status of This Memo 38 This Internet-Draft is submitted to IETF in full conformance with the 39 provisions of BCP 78 and BCP 79. 41 Internet-Drafts are working documents of the Internet Engineering 42 Task Force (IETF). Note that other groups may also distribute 43 working documents as Internet-Drafts. The list of current Internet- 44 Drafts is at https://datatracker.ietf.org/drafts/current/. 46 Internet-Drafts are draft documents valid for a maximum of six months 47 and may be updated, replaced, or obsoleted by other documents at any 48 time. It is inappropriate to use Internet-Drafts as reference 49 material or to cite them other than as "work in progress." 51 This Internet-Draft will expire on February 19, 2021. 53 Copyright Notice 55 Copyright (c) 2020 IETF Trust and the persons identified as the 56 document authors. All rights reserved. 58 This document is subject to BCP 78 and the IETF Trust's Legal 59 Provisions Relating to IETF Documents 60 (https://trustee.ietf.org/license-info) in effect on the date of 61 publication of this document. Please review these documents 62 carefully, as they describe your rights and restrictions with respect 63 to this document. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 68 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 69 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 70 2. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 4 71 3. Zone Abstraction . . . . . . . . . . . . . . . . . . . . . . 4 72 4. Topology-Transparent Zone . . . . . . . . . . . . . . . . . . 5 73 4.1. Zone as a Single Node . . . . . . . . . . . . . . . . . . 5 74 4.1.1. An Example of Zone as a Single Node . . . . . . . . . 5 75 4.1.2. Zone Leader Election . . . . . . . . . . . . . . . . 7 76 4.1.3. LS Generation for Zone as a Single Node . . . . . . . 8 77 4.1.4. Adjacency Establishment and Termination . . . . . . . 8 78 4.1.5. Computation of Routes . . . . . . . . . . . . . . . . 10 79 4.1.6. Extensions to Protocols . . . . . . . . . . . . . . . 11 80 4.2. Zone as Edges Full Mesh . . . . . . . . . . . . . . . . . 14 81 4.2.1. Extensions to IS-IS . . . . . . . . . . . . . . . . . 14 82 4.3. Advertisement of LSs . . . . . . . . . . . . . . . . . . 15 83 4.3.1. Advertisement of LSs within Zone . . . . . . . . . . 15 84 4.3.2. Advertisement of LSs through Zone . . . . . . . . . . 16 85 5. Seamless Migration . . . . . . . . . . . . . . . . . . . . . 16 86 5.1. Transfer Zone to a Single Node . . . . . . . . . . . . . 16 87 5.2. Roll Back from Zone as a Single Node . . . . . . . . . . 16 88 6. Operations . . . . . . . . . . . . . . . . . . . . . . . . . 19 89 7. Security Considerations . . . . . . . . . . . . . . . . . . 19 90 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 91 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 20 92 10. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 20 93 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 94 11.1. Normative References . . . . . . . . . . . . . . . . . . 20 95 11.2. Informative References . . . . . . . . . . . . . . . . . 21 97 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21 99 1. Introduction 101 [ISO10589] describes two levels of areas, which are level 1 and level 102 2 areas in IS-IS. There are scalability issues in using areas as the 103 number of routers in a network becomes larger and larger. 105 Through splitting the network into multiple areas, we may extend the 106 network further. However, dividing a network from one area into 107 multiple areas or from a number of existing areas to even more areas 108 is a very challenging and time consuming task since it is involved in 109 significant network architecture changes. 111 These issues can be resolved by using topology-transparent zone 112 (TTZ), which abstracts a zone (i.e., a block/piece of an area) as a 113 single virtual node or zone edges' mesh with minimum efforts and 114 minimum service interruption. Note that a zone can be an area (i.e., 115 the entire piece of an area). 117 This document presents a topology-transparent zone and describes 118 extensions to IS-IS for supporting the topology-transparent zone. 120 1.1. Requirements Language 122 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 123 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 124 document are to be interpreted as described in RFC 2119 [RFC2119]. 126 1.2. Terminology 128 LSP: A Link State Protocol Data Unit (PDU) in IS-IS. 130 LS: A Link Sate, which is short for LSP in IS-IS. 132 TTZ: A Topology-Transparent Zone. 134 Zone: A block or piece of an area. In a special case, a zone is an 135 area (i.e., the entire piece of an area). 137 Zone External Node: A node outside of a zone. 139 Zone Internal Node: A node of a zone without any connection to a 140 node outside of the zone. 142 Zone Edge/Border: A node of a zone connecting to a node outside of 143 the zone. 145 Zone Node: A zone internal node or a zone edge/border node (i.e., a 146 node of a zone). 148 Zone Link: A link connecting zone nodes (i.e., a link of a zone). 150 Zone Neighbor: A node outside of a zone that is a neighbor of a 151 zone edge/border. 153 2. Requirements 155 Topology-Transparent Zone (TTZ) may be deployed for resolving some 156 critical issues such as scalability in existing networks and future 157 networks. The requirements for TTZ are listed as follows: 159 o TTZ MUST be backward compatible. When a TTZ is deployed on a set 160 of routers in a network, the routers outside of the TTZ in the 161 network do not need to know or support TTZ. 163 o TTZ MUST support at least one more levels of network hierarchies, 164 in addition to the hierarchies supported by existing routing 165 protocols. 167 o Abstracting a zone as a virtual entity, which is a single virtual 168 node or zone edges' mesh, SHOULD be smooth with minimum service 169 interruption. 171 o De-abstracting (or say rolling back) a virtual entity to a zone 172 SHOULD be smooth with minimum service interruption. 174 o Users SHOULD be able to easily set up an end to end service 175 crossing TTZs. 177 o The configuration for a TTZ in a network SHOULD be minimum. 179 o The changes on the existing protocols for supporting TTZ SHOULD be 180 minimum. 182 3. Zone Abstraction 184 A zone can be abstracted as a single virtual node or the zone edges' 185 full mesh. 187 When a zone is abstracted as a single virtual node, this single node 188 is connected to all the neighbors of the zone, and is in the same 189 area as the neighbors. 191 When a zone is abstracted as its edges' full mesh, there is a full 192 mesh connections among the edges and each edge is also connected to 193 its neighbors outside of the zone. 195 4. Topology-Transparent Zone 197 A Topology-Transparent Zone (TTZ) comprises an Identifier (ID) and a 198 piece/block of an area such as a Level 2 area in IS-IS. It is 199 abstracted as a single virtual node or its edges' full mesh. TTZ and 200 zone will be used exchangably below. 202 4.1. Zone as a Single Node 204 After a zone is abstracted as a single virtual node having a virtual 205 node ID, every node outside of the zone sees a number of links 206 connected to this single node. Each of these links connects a zone 207 neighbor. The link states inside the zone are not advertised to any 208 node outside of the zone. The virtual node ID may be derived from 209 the zone ID. 211 4.1.1. An Example of Zone as a Single Node 213 The figure below shows an example of an area containing a TTZ: TTZ 214 600. 216 TTZ 600 217 \ 218 \ ^~^~^~^~^~^~^~^~^~^~^~^~ 219 ( ) 220 ===[R15]========(==[R61]------------[R63]==)======[R29]=== 221 || ( | \ / | ) || 222 || ( | \ / | ) || 223 || ( | \ / | ) || 224 || ( | ___\ / | ) || 225 || ( | / [R71] | ) || 226 || ( | [R73] / \ | ) || 227 || ( | / \ | ) || 228 || ( | / \ | ) || 229 || ( | / \ | ) || 230 ===[R17]========(==[R65]------------[R67]==)======[R31]=== 231 \\ (// \\) // 232 || //v~v~v~v~v~v~v~v~v~v~v~\\ || 233 || // \\ || 234 || // \\ || 235 \\ // \\ // 236 ======[R23]==============================[R25]===== 237 // \\ 238 // \\ 240 Figure 1: An Example of TTZ 600 242 The area comprises routers R15, R17, R23, R25, R29 and R31. It also 243 contains TTZ 600, which comprises routers R61, R63, R65, R67, R71 and 244 R73, and the circuits connecting them. 246 There are two types of routers in a TTZ: TTZ internal routers and TTZ 247 edge/border routers. A TTZ internal router is a router inside the 248 TTZ and its adjacent routers are inside the TTZ. A TTZ edge/border 249 router is a router inside the TTZ and has at least one adjacent 250 router that is outside of the TTZ. 252 The TTZ in the figure above comprises four TTZ edge/border routers 253 R61, R63, R65 and R67. Each TTZ edge/border router is connected to 254 at least one router outside of the TTZ. For instance, router R61 is 255 a TTZ edge/border router since it is connected to router R15, which 256 is outside of the TTZ. 258 In addition, the TTZ comprises two TTZ internal routers R71 and R73. 259 A TTZ internal router is not connected to any router outside of the 260 TTZ. For instance, router R71 is a TTZ internal router since it is 261 not connected to any router outside of the TTZ. It is just connected 262 to routers R61, R63, R65, R67 and R73 inside the TTZ. 264 A TTZ MUST hide the information inside the TTZ from the outside. It 265 MUST NOT directly distribute any internal information about the TTZ 266 to a router outside of the TTZ. 268 For instance, the TTZ in the figure above MUST NOT send the 269 information about TTZ internal router R71 to any router outside of 270 the TTZ in the routing domain; it MUST NOT send the information about 271 the circuit between TTZ router R61 and R65 to any router outside of 272 the TTZ. 274 From a router outside of the TTZ, a TTZ is seen as a single node 275 (refer to the Figure below). For instance, router R15, which is 276 outside of TTZ 600, sees TTZ 600 as a single node Rz, which has 277 normal connections to R15, R29, R17 and R23, R25 and R31. 279 TTZ 600 280 \ 281 \ ^~^~^~^~^~^~^~^~^~^~^~^~ 282 ( ) 283 ===[R15]========( )======[R29]=== 284 || ( ) || 285 || ( ) || 286 || ( ) || 287 || ( ) || 288 || ( Rz ) || 289 || ( ) || 290 || ( ) || 291 || ( ) || 292 || ( ) || 293 ===[R17]========( )======[R31]=== 294 \\ ( ) // 295 || //v~v~v~v~v~v~v~v~v~v~v~\\ || 296 || // \\ || 297 || // \\ || 298 \\ // \\ // 299 ======[R23]==============================[R25]===== 300 // \\ 301 // \\ 303 Figure 2: TTZ 600 as Single Node Rz 305 4.1.2. Zone Leader Election 307 A node in a zone is elected as a leader for the zone, which is the 308 node with the highest priority (and the highest node ID when there 309 are more than one nodes having the same highest priority) in the 310 zone. The leader election mechanism described in 312 [I-D.ietf-lsr-dynamic-flooding] may be used to elect the leader for 313 the zone. 315 4.1.3. LS Generation for Zone as a Single Node 317 The leader for the zone originates an LS (i.e., an LSP in IS-IS) for 318 the zone as a single virtual node and sends it to its neighbors. 320 The LS comprises all the links connecting the zone neighbors. The LS 321 ID is the ID of the virtual node for the zone. The Source ID or 322 Advertising Node/Router ID is the ID of the virtual node. 324 In addition, the LS may contain the stub links for the routes such as 325 the loopback addresses inside the zone to be accessed by zone 326 external nodes (i.e., nodes outside of the zone). 328 4.1.4. Adjacency Establishment and Termination 330 A zone edge node, acting as a single virtual node for the zone, forms 331 an adjacency with a node outside of the zone in a way described 332 below. 334 Case 1 for a new adjacency (i.e., no adjacency exists between the 335 edge and the node outside of the zone also called zone neighbor): 337 The edge node originates and sends the zone neighbor every protocol 338 packet such as Hello, which contains the virtual node ID as Source 339 ID. 341 When the edge node synchronizes its link state database (LSDB) with 342 the zone neighbor, it sends the zone neighbor the information about 343 all the link states except for the link states belonging to the zone 344 that are hidden from any node outside of the zone. 346 At the end of the LSDB synchronization, the LS for the zone as the 347 single virtual node is originated by the zone leader and distributed 348 to the zone neighbor. This LS contains the links connecting all the 349 zone neighbors, including this newly formed zone neighbor. 351 Case 2 for an existing adjacency (i.e., an adjacency already exists 352 between the zone edge and the zone neighbor): 354 At first, the edge acting as virtual node creates a new adjacency 355 between the virtual node for the zone and the zone external node in a 356 normal way. It sends Hellos and other packets containing the virtual 357 node ID as Source ID to the zone external node. The zone external 358 node establishes the adjacency with the virtual in the normal way. 360 And then, the edge terminates the existing adjacency between the edge 361 and the external node after the zone has been transferred to the 362 virtual node. It stops sending Hellos for the adjacency to the zone 363 external node. Without receiving Hellos from the edge node for a 364 given time such as hold-timer interval, the zone external node 365 removes the adjacency to the edge node. Even though this adjacency 366 terminates, the edge node keeps the link to the external node in its 367 LS. 369 In another option, the zone edge sends Hellos to the zone neighbor 370 with additional information, including a flag T-bit set to one and a 371 TLV with the virtual node ID. This information requests the zone 372 neighbor to transfer the existing adjacency to the new adjacency 373 smoothly through working together with the zone edge in following 374 steps. 376 Zone Edge Zone Neighbor 377 (Transfer Zone 378 to Virtual Node) Hello(T=1, Virtual ID) 379 ----------------------> OK for Transfer 380 Adjacency 381 Hello(T=1, Virtual ID) 382 Remote Ready for <---------------------- 383 Transfer 384 Hello(Source=Virtual ID) 385 Start Transfer -----------------------> Transfer to New 386 Adjacency 387 Hello 388 Transfer to New <----------------------- 389 Adjacency . . . 391 Step 1: When "Transfer Zone to Virtual Node" is triggered, the zone 392 edge sends the zone neighbor a Hello containing additional 393 information T=1 and Virtual node ID. 395 Step 2: After receiving the Hello with T=1 and virtual node ID from 396 the zone edge, the zone neighbor sends the zone edge a Hello with 397 T=1 and virtual node ID, which means ok for transfer to the new 398 adjacency. 400 Step 3: The edge sends the zone neighbor a Hello containing the 401 virtual node ID as Source ID after receiving the Hello with T=1 402 and virtual node ID from the zone neighbor, which starts to 403 transfer to the new adjacency. 405 Step 4: The zone neighbor changes the existing adjacency to the new 406 adjacency after receiving the Hello containing the virtual node ID 407 as Source ID from the zone edge; and sends the zone edge a Hello 408 without the additional information, which means that it 409 transferred to the new adjacency. 411 Step 5: The zone edge changes the existing adjacency to the new 412 adjacency after receiving the Hello without the additional 413 information from the zone neighbor; and continues to send the zone 414 neighbor a Hello containing the virtual node ID as Source ID. At 415 this point, the old adjacency is transferred to the new one. 417 For the zone neighbor, changing the existing adjacency to the new one 418 includes: 420 o Changing the existing adjacency ID from the edge node ID to the 421 virtual node ID through either removing the existing adjacency and 422 adding a new adjacency with the virtual node ID or just changing 423 the existing adjacency ID from the edge node ID to the virtual 424 node ID, 426 o Removing the link to the zone edge node from its LS and adding a 427 new link to the virtual node (or just changing the link to the 428 edge node to the link to the virtual node in its LS), and 430 o Continuing sending the zone edge Hellos without additional 431 information. 433 For the zone edge, changing the existing adjacency to the new one 434 includes: 436 o Keeping the link to the zone neighbor in its LS, and 438 o Continuing sending the zone neighbor Hellos containing the virtual 439 node ID as Source ID. 441 4.1.5. Computation of Routes 443 After a zone edge migrates to zone as a virtual node, it computes the 444 routes (i.e., shortest paths to the destinations) in the zone using 445 the zone topology (i.e., the topology of the zone without the virtual 446 node). 448 For the routes outside of the zone, it computes them using the zone 449 topology, the topology outside of the zone without the virtual node 450 and the connections between each zone edge and its zone neighbor. 452 After a zone internal node migrates to zone as a virtual node, it 453 computes the routes using the zone topology, the topology outside of 454 the zone without the virtual node and the connections between each 455 zone edge and its zone neighbor. 457 4.1.6. Extensions to Protocols 459 The following TLVs are defined in IS-IS. 461 o Adjacent Node ID TLV: containing an adjacent node ID, to which an 462 adjacency is transferred or rolled back. In case of transfer, the 463 TLV contains the virtual node ID; in case of roll back, the TLV 464 contains the edge node ID. 466 o Zone TLV: containing a zone ID, a flags field and optional sub- 467 TLVs. 469 4.1.6.1. Adjacent Node ID TLV 471 The format of Adjacent Node ID TLV is illustrated below. 473 0 1 2 3 474 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 475 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 476 | Type (TBD1) | Length (8) | Virtual/Edge Node ID | 477 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 478 | Virtual/Edge Node ID (Continue) | 479 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 480 | Flags |N|T| 481 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 483 Type (1 byte): To be assigned by IANA. 485 Length (1 byte): Its value is 8. 487 Virtual/Edge Node ID (6 bytes): An adjacent node ID, to which an 488 adjacency is transferred or rolled back. 490 Flags field (16 bits): two new flag bits are defined as follows: 492 o T-bit: Short for Transfer Adjacency bit. The T-bit set to one 493 indicates a request for transferring to a new 'virtual' adjacency 494 from the existing adjacency and the new adjacency is identified by 495 the virtual node ID (or say abstract node ID). 497 o N-bit: Short for Roll Back to Normal Adjacency bit. The N-bit set 498 to one indicates a request for rolling back to a Normal adjacency 499 from the existing 'virtual' adjacency and the normal adjacency is 500 identified by the edge node ID. 502 4.1.6.2. Zone TLV 504 The format of IS-IS Zone TLV is illustrated below. It may be added 505 into an LSP or a Hello PDU for a zone node. When a node in a zone 506 receives a CLI command triggering zone information distribution for 507 migration, it updates its LSP by adding an IS-IS Zone TLV with T set 508 to 1. When a node in a zone receives a CLI command activating 509 migration zone to an abstracted entity, it sets M to 1 in the Zone 510 TLV in its LSP. 512 0 1 2 3 513 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 514 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 515 | Type (TBD2) | Length | Zone ID | 516 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 517 | Zone ID (Continue) | 518 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 519 | Flags |E|Z|S| OP | Sub TLVs | 520 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 521 ~ ~ 522 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 524 Figure 3: IS-IS Zone TLV 526 Type (1 byte): To be assigned by IANA. 528 Length (1 byte): Its value is variable. 530 Zone ID (6 bytes): It is the identifier (ID) of a zone. 532 Flags field (16 bits): Three flag bits E, Z and S, and OP of 3 bits 533 are defined. 535 E = 1: Indicating a node is a zone edge node 536 Z = 1: Indicating a node has migrated to Zone as a virtual entity 537 S = 1: Indicating the virtual entity is a Single virtual node 539 When a zone node originates an LS containing a zone TLV, it MUST set 540 flag E to 1 if it is a zone edge node and to 0 if it is a zone- 541 internal node. It MUST set flag Z to 1 after it has migrated to zone 542 as a virtual entity and to 0 before it migrates zone to the virtual 543 entity or after it rolls back from zone as a virtual entity. When 544 the entity abstracted from a zone is a Single virtual node, flag S 545 MUST be set to 1. 547 OP Value Meaning (Operation) 548 0x001 (T): Advertising Zone Topology Information for Migration 549 0x010 (M): Migrating Zone to a Virtual Entity 550 0x011 (N): Advertising Normal Topology Information for Rollback 551 0x100 (R): Rolling Back from the Virtual Entity 553 The value of OP indicates one of the four operations above. When any 554 of the other values is received, it is ignored. 556 When a node in a zone receives a CLI command triggering zone 557 information distribution for migration, it updates its LSP by adding 558 an IS-IS Zone TLV with T set to 1. When a node in a zone receives a 559 CLI command activating migration zone to a virtual entity, it sets M 560 to 1 in the Zone TLV in its LSP. 562 Two new sub-TLVs are defined, which may be added into an IS-IS Zone 563 TLV in an LSP. One is Zone IS Neighbor sub-TLV, or Zone ISN sub-TLV 564 for short. The other is Zone ES Neighbor sub-TLV, or Zone ESN sub- 565 TLV for short. A Zone ISN sub-TLV contains the information about a 566 number of IS neighbors in the zone connected to a zone edge router. 567 It has the format below. 569 0 1 2 3 570 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 571 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 572 | Type (TBD) | Length |DefaultMetric(i| DelayMetric(i)| 573 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 574 |ExpenseMetric(i| ErrorMetric(i)| Neighbor ID(i) | 575 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 576 ~ ~ 577 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 579 Figure 4: Zone ISN Sub TLV 581 A Zone ISN Sub TLV has 1 byte of Type, 1 byte of Length of 582 n*(IDLength + 4), which is followed by n tuples of Default Metric, 583 Delay Metric, Expense Metric, Error Metric and Neighbor ID. 585 A Zone ESN sub-TLV contains the information about a number of ES 586 neighbors in the zone connected to a zone edge node. It has the 587 format below. 589 0 1 2 3 590 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 591 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 592 | Type (TBD) | Length |Default Metric | DelayMetric | 593 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 594 |Expense Metric | Error Metric | Neighbor ID(i) | 595 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 596 ~ ~ 597 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 599 Figure 5: Zone ESN Sub TLV 601 4.2. Zone as Edges Full Mesh 603 OSPF Topology-Transparent Zone [RFC8099] describes the zone as edges' 604 full mesh and the extensions to OSPF for supporting zone as edges' 605 full mesh. Based on these extensions, IS-IS is extended by a few new 606 TLVs or Sub-TLVs. 608 4.2.1. Extensions to IS-IS 610 4.2.1.1. Updating LSPs for Zone 612 A zone internal node adds an IS-IS Zone TLV into its LSP after it 613 receives an LSP containing an IS-IS Zone TLV with T = 1 or a CLI 614 command triggering zone information distribution for migration. The 615 TLV has a zone ID set to the ID of the zone and E bit in Flags set to 616 0 indicating zone internal node. The node floods its LSP to its 617 neighbors in the zone. 619 When a node inside the zone receives an LSP containing an IS-IS Zone 620 TLV from a neighboring node in the zone, it stores the LSP and floods 621 the LSP to the other neighboring nodes in the zone. 623 For every zone edge node, it updates its LSP in three steps and 624 floods the LSP to all its neighbors. 626 At first, the zone edge node adds an IS-IS Zone TLV into its LSP 627 after it receives an LSP containing an IS-IS Zone TLV with T = 1 or a 628 CLI command triggering zone information distribution for migration. 629 The TLV has a zone ID set to the ID of the zone, E bit in Flags set 630 to 1 indicating zone edge node and a Zone ISN Sub TLV. The Sub TLV 631 contains the information about the zone IS neighbors connected to the 632 zone edge node. In addition, the TLV may has a Zone ESN Sub TLV 633 comprising the information about the zone end systems connected to 634 the zone edge node. 636 Secondly, it adds each of the other zone edge nodes as an IS neighbor 637 into the Intermediate System Neighbors TLV in the LSP after it 638 receives an LSP containing an IS-IS Zone TLV with M = 1 or a CLI 639 command activating migration zone to an abstracted entity. The 640 metric to the neighbor is the metric of the shortest path to the edge 641 node within the zone. 643 In addition, it adds a Prefix Neighbors TLV into its LSP. The TLV 644 contains a number of address prefixes in the zone to be reachable 645 from outside of the zone. 647 And then it removes the IS neighbors corresponding to the IS 648 neighbors in the Zone TLV (i.e., in the Zone ISN sub TLV) from 649 Intermediate System Neighbors TLV in the LSP, and the ES neighbors 650 corresponding to the ES neighbors in the Zone TLV (i.e., in the Zone 651 ESN sub TLV) from End System Neighbors TLV in the LSP. This SHOULD 652 be done after it receives the LSPs for virtualizing zone from the 653 other zone edges for a given time. 655 4.3. Advertisement of LSs 657 LSs can be divided into a couple of classes according to their 658 Advertisements. The first class of LSs is advertised within a zone. 659 The second is advertised through a zone. 661 4.3.1. Advertisement of LSs within Zone 663 Any LS about a link state in a zone is advertised only within the 664 zone. It is not advertised to any router outside of the zone. For 665 example, a router LS generated for a zone internal router is 666 advertised only within the zone. 668 Any network LS generated for a broadcast network in a zone is 669 advertised only within the zone. It is not advertised outside of the 670 zone. 672 After migrating to zone as a single virtual node or edges' full mesh, 673 every zone edge MUST NOT advertise any LS belonging to the zone or 674 any information in a LS belonging to the zone to any node outside of 675 the zone. The zone edge determines whether an LS is about a zone 676 internal link state by checking if the advertising router of the LS 677 is a zone internal router. 679 For any zone LS originated by a node within the zone, every zone edge 680 node MUST NOT advertise it to any node outside of the zone. 682 4.3.2. Advertisement of LSs through Zone 684 Any LS about a link state outside of a zone received by a zone edge 685 is advertised using the zone as transit. For example, when a zone 686 edge node receives an LS from a node outside of the zone, it floods 687 the LS to its neighbors both inside and outside of the zone. This LS 688 may be any LS such as a router LSA that is advertised within an OSPF 689 area. 691 The nodes in the zone continue to flood the LS. When another zone 692 edge receives the LS, it floods the LS to its neighbors both inside 693 and outside of the zone. 695 5. Seamless Migration 697 This section presents the seamless migration between a zone and its 698 single virtual node. The seamless migration between a zone and its 699 edges' full mesh for IS-IS is similar to that described in OSPF 700 Topology-Transparent Zone [RFC8099] for OSPF. 702 5.1. Transfer Zone to a Single Node 704 After transfer a Zone to a Single Virtual Node is triggered, the zone 705 is abstracted as a single virtual node in two steps: 707 Step 1: Every zone edge node works together with each of its zone 708 neighbor nodes to create a new adjacency between the virtual node 709 and the neighbor node in the way described in Section 4.1.4 for 710 Adjacency Establishment and Termination procedure for case 2. 711 After creating the adjacency, each of the zone neighbor nodes 712 update its LS by adding the adjacency/link into its LS. 714 Step 2: The zone leader originates an LS for the virtual node after 715 receiving the updated LSes originated by all the zone neighbor 716 nodes, where the updated LSes contain all the zone neighbors. 718 Step 3: After receiving the LS for the virtual node, every zone edge 719 does not send any LS inside the zone to any zone neighbors. It 720 advertises its LS without any links inside the zone to the nodes 721 outside of the zone and terminates its adjacency to each of its 722 zone neighbors in the way described in Section 4.1.4 for Adjacency 723 Establishment and Termination procedure for case 2. 725 5.2. Roll Back from Zone as a Single Node 727 After roll back from Zone as a Signle Virtual Node is triggered, 728 rolling back is done in following steps: 730 Step 1: Every zone edge creates an adjacency to each of its zone 731 neighbors in a normal way. 733 Step 2: After all the adjacencies between the zone edges and the 734 zone neighbors are created, the zone leader updates the LS for the 735 virtual node by changing every link metric to the maximum metric 736 in the LS. 738 Step 3: Every zone edge sends its LS with the links inside the zone 739 and all the LSes inside the zone to its zone neighbors. Every 740 zone edge acting as the virtual node terminates the adjacency 741 between the virtual node and each of its zone neighbors through 742 stopping Hellos to the neighbors. 744 In another option, rolling back is done as follows: 746 Step 1: Using the procedure described in the following, every zone 747 edge rolls back the existing virtual adjacency between the edge 748 node acting as the virtual node and the zone neighbor node to a 749 normal adjacency between the edge node and the neighbor. 751 Step 2: The zone leader may flush the LS for the virtual node. 752 Every zone edge sends Hello and other packets to its zone 753 neighbors, where the packets contain the edge node ID as Source 754 ID. 756 The procedure below smoothly rolls back the existing virtual 757 adjacency between the edge node acting as the virtual node and the 758 zone neighbor node to a normal adjacency between the edge node and 759 the neighbor node. 761 The edge node sends the neighbor node Hellos with additional 762 information, including a flag N-bit set to one and a TLV with the 763 edge node ID such as the Adjacent Node ID TLV with the edge node ID. 764 This information requests the neighbor node to roll back the existing 765 virtual adjacency to the normal adjacency smoothly through working 766 together with the edge node. 768 The following steps will roll back the existing virtual adjacency to 769 the normal one: 771 zone Edge zone Neighbor 772 (Roll Back to 773 Normal Adjacency) Hello (N=1, Edge ID) 774 ----------------------> OK to Roll Back to 775 Normal Adjacency 776 Hello (N=1, Edge ID) 777 Remote Ready for <---------------------- 778 Rolling Back 779 Hello(Source=Edge ID) 780 Start Roll Back -----------------------> Roll Back to 781 Normal Adjacency 782 Hello 783 Roll Back to <----------------------- 784 Normal Adjacency . . . 786 Step 1: When "Roll Back from Zone as a Single Node" is triggered, 787 the edge node sends the neighbor node a Hello with the additional 788 information N=1 and Edge ID as normal adjacency ID in order to 789 roll back to the normal adjacency from the virtual adjacency. 791 Step 2: After receiving the Hello with the additional information 792 from the edge node, the neighbor node sends the edge node a Hello 793 with the additional information (i.e., N=1 and Edge ID as normal 794 adjacency ID), which means ok for rolling back to the normal 795 adjacency. 797 Step 3: The edge sends the neighbor a Hello containing the edge node 798 ID as Source ID after receiving the Hello with the additional 799 information from the neighbor, which starts to roll back to the 800 normal adjacency. 802 Step 4: The neighbor node changes the existing adjacency to the 803 normal adjacency after receiving the Hello containing the edge 804 node ID as Source ID from the edge node; and sends the edge node a 805 Hello without the additional information, which means that it 806 rolled back to the normal adjacency. 808 Step 5: The edge node changes the existing adjacency to the normal 809 adjacency after receiving the Hello without the additional 810 information from the neighbor node; and continues to send the 811 neighbor Hello containing the edge node ID as Source ID. At this 812 point, the virtual adjacency is rolled back to the normal 813 adjacency. 815 For the neighbor node, changing the existing virtual adjacency to the 816 normal one includes: 818 o Changing the existing adjacency ID from the virtual node ID to the 819 edge node ID through either removing the existing adjacency and 820 adding a new adjacency with the edge node ID or just changing the 821 existing adjacency ID from the virtual node ID to the edge node 822 ID, 824 o Removing the link to the virtual node from its LS and adding a new 825 link to the edge node (or just changing the link to the virtual 826 node to the link to the edge node in its LS), and 828 o Continuing sending the edge node Hellos without additional 829 information. 831 For the edge node, changing the existing virtual adjacency to the 832 normal one includes: 834 o Sending its LS to the neighbor, and 836 o Continuing sending the neighbor node Hellos containing the edge 837 node ID as Source ID without additional information. 839 6. Operations 841 The Operations on TTZ described in OSPF Topology-Transparent Zone 842 [RFC8099] are for Zone as Edges Full Mesh in OSPF. They can be used 843 for Zone as Edges Full Mesh in IS-IS. They can also be used for Zone 844 as a Single Virtual Node in IS-IS. 846 7. Security Considerations 848 The mechanism described in this document does not raise any new 849 security issues for the IS-IS protocols. 851 8. IANA Considerations 853 Under the registry name "IS-IS TLV Codepoints", IANA is requested to 854 assign new registry types for Adjacent Node ID, Zone ID and Zone 855 Options as follows: 857 +==============+===================+=====================+ 858 | TLV Type | TLV Name | reference | 859 +==============+===================+=====================+ 860 | 26(suggested)| Adjacent Node ID | This document | 861 +--------------+-------------------+---------------------+ 862 | 27(suggested)| Zone | This document | 863 +--------------+-------------------+---------------------+ 865 9. Contributors 867 Alvaro Retana 868 Futurewei 869 Raleigh, NC 870 USA 872 Email: alvaro.retana@futurewei.com 874 10. Acknowledgement 876 The authors would like to thank Acee Lindem, Abhay Roy, Christian 877 Hopps, Dean Cheng, Russ White, Tony Przygienda, Wenhu Lu, Lin Han, 878 Kiran Makhijani, Padmadevi Pillay Esnault, and Yang Yu for their 879 valuable comments on TTZ. 881 11. References 883 11.1. Normative References 885 [I-D.ietf-lsr-dynamic-flooding] 886 Li, T., Psenak, P., Ginsberg, L., Chen, H., Przygienda, 887 T., Cooper, D., Jalil, L., Dontula, S., and G. Mishra, 888 "Dynamic Flooding on Dense Graphs", draft-ietf-lsr- 889 dynamic-flooding-07 (work in progress), June 2020. 891 [I-D.ietf-spring-segment-routing] 892 Filsfils, C., Previdi, S., Ginsberg, L., Decraene, B., 893 Litkowski, S., and R. Shakir, "Segment Routing 894 Architecture", draft-ietf-spring-segment-routing-15 (work 895 in progress), January 2018. 897 [ISO10589] 898 International Organization for Standardization, 899 "Intermediate System to Intermediate System Intra-Domain 900 Routing Exchange Protocol for use in Conjunction with the 901 Protocol for Providing the Connectionless-mode Network 902 Service (ISO 8473)", ISO/IEC 10589:2002, Nov. 2002. 904 [RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and 905 dual environments", RFC 1195, DOI 10.17487/RFC1195, 906 December 1990, . 908 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 909 Requirement Levels", BCP 14, RFC 2119, 910 DOI 10.17487/RFC2119, March 1997, 911 . 913 [RFC5029] Vasseur, JP. and S. Previdi, "Definition of an IS-IS Link 914 Attribute Sub-TLV", RFC 5029, DOI 10.17487/RFC5029, 915 September 2007, . 917 [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic 918 Engineering", RFC 5305, DOI 10.17487/RFC5305, October 919 2008, . 921 [RFC7142] Shand, M. and L. Ginsberg, "Reclassification of RFC 1142 922 to Historic", RFC 7142, DOI 10.17487/RFC7142, February 923 2014, . 925 [RFC8099] Chen, H., Li, R., Retana, A., Yang, Y., and Z. Liu, "OSPF 926 Topology-Transparent Zone", RFC 8099, 927 DOI 10.17487/RFC8099, February 2017, 928 . 930 11.2. Informative References 932 [Clos] Clos, C., "A Study of Non-Blocking Switching Networks", 933 The Bell System Technical Journal Vol. 32(2), DOI 934 10.1002/j.1538-7305.1953.tb01433.x, March 1953, 935 . 937 [RFC5307] Kompella, K., Ed. and Y. Rekhter, Ed., "IS-IS Extensions 938 in Support of Generalized Multi-Protocol Label Switching 939 (GMPLS)", RFC 5307, DOI 10.17487/RFC5307, October 2008, 940 . 942 Authors' Addresses 944 Huaimo Chen 945 Futurewei 946 Boston, MA 947 USA 949 Email: huaimo.chen@futurewei.com 951 Richard Li 952 Futurewei 953 2330 Central expressway 954 Santa Clara, CA 955 USA 957 Email: richard.li@futurewei.com 958 Yi Yang 959 IBM 960 Cary, NC 961 United States of America 963 Email: yyietf@gmail.com 965 Anil Kumar S N 966 RtBrick 967 Bangalore 968 India 970 Email: anil.ietf@gmail.com 972 Yanhe Fan 973 Casa Systems 974 USA 976 Email: yfan@casa-systems.com 978 Ning So 979 Plano, TX 75082 980 USA 982 Email: ningso01@gmail.com 984 Vic Liu 985 USA 987 Email: liu.cmri@gmail.com 989 Mehmet Toy 990 Verizon 991 USA 993 Email: mehmet.toy@verizon.com 995 Lei Liu 996 Fujitsu 997 USA 999 Email: liulei.kddi@gmail.com 1000 Kiran Makhijani 1001 Futurewei 1002 USA 1004 Email: kiranm@futurewei.com