idnits 2.17.1 draft-chen-isis-ttz-08.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 9, 2020) is 1480 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 226, but not defined == Missing Reference: 'R73' is mentioned on line 227, but not defined == Unused Reference: 'I-D.ietf-spring-segment-routing' is defined on line 868, but no explicit reference was found in the text == Unused Reference: 'RFC1195' is defined on line 881, but no explicit reference was found in the text == Unused Reference: 'RFC5029' is defined on line 894, but no explicit reference was found in the text == Unused Reference: 'RFC5305' is defined on line 898, but no explicit reference was found in the text == Unused Reference: 'RFC7142' is defined on line 907, but no explicit reference was found in the text == Unused Reference: 'Clos' is defined on line 918, but no explicit reference was found in the text == Unused Reference: 'RFC5307' is defined on line 923, but no explicit reference was found in the text == Outdated reference: A later version (-17) 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' ** 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 A. Retana 4 Intended status: Standards Track R. Li 5 Expires: September 10, 2020 Futurewei 6 A. Kumar S N 7 RtBrick 8 N. So 10 V. Liu 12 M. Toy 13 Verizon 14 L. Liu 15 Fijitsu 16 March 9, 2020 18 Topology-Transparent Zone 19 draft-chen-isis-ttz-08.txt 21 Abstract 23 This document presents a topology-transparent zone in an area. A 24 zone is a block/piece of an area, which comprises a group of routers 25 and a number of circuits connecting them. It is abstracted as a 26 virtual entity such as a single pseudo node or zone edges mess. Any 27 router outside of the zone is not aware of the zone. The information 28 about the circuits and routers inside the zone is not distributed to 29 any router outside of the zone. 31 Status of This Memo 33 This Internet-Draft is submitted to IETF in full conformance with the 34 provisions of BCP 78 and BCP 79. 36 Internet-Drafts are working documents of the Internet Engineering 37 Task Force (IETF). Note that other groups may also distribute 38 working documents as Internet-Drafts. The list of current Internet- 39 Drafts is at https://datatracker.ietf.org/drafts/current/. 41 Internet-Drafts are draft documents valid for a maximum of six months 42 and may be updated, replaced, or obsoleted by other documents at any 43 time. It is inappropriate to use Internet-Drafts as reference 44 material or to cite them other than as "work in progress." 46 This Internet-Draft will expire on September 10, 2020. 48 Copyright Notice 50 Copyright (c) 2020 IETF Trust and the persons identified as the 51 document authors. All rights reserved. 53 This document is subject to BCP 78 and the IETF Trust's Legal 54 Provisions Relating to IETF Documents 55 (https://trustee.ietf.org/license-info) in effect on the date of 56 publication of this document. Please review these documents 57 carefully, as they describe your rights and restrictions with respect 58 to this document. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 63 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 64 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 65 2. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 4 66 3. Zone Abstraction . . . . . . . . . . . . . . . . . . . . . . 4 67 4. Topology-Transparent Zone . . . . . . . . . . . . . . . . . . 5 68 4.1. Zone as a Single Pseudo Node . . . . . . . . . . . . . . 5 69 4.1.1. An Example of Zone as a Single Node . . . . . . . . . 5 70 4.1.2. Zone Leader Election . . . . . . . . . . . . . . . . 7 71 4.1.3. LS Generation for Zone as a Single Node . . . . . . . 8 72 4.1.4. Adjacency Establishment . . . . . . . . . . . . . . . 8 73 4.1.5. Computation of Routes . . . . . . . . . . . . . . . . 10 74 4.1.6. Extensions to Protocols . . . . . . . . . . . . . . . 10 75 4.2. Zone as Edges Full Mess . . . . . . . . . . . . . . . . . 12 76 4.2.1. Extensions to IS-IS . . . . . . . . . . . . . . . . . 13 77 4.3. Advertisement of LSs . . . . . . . . . . . . . . . . . . 15 78 4.3.1. Advertisement of LSs within Zone . . . . . . . . . . 15 79 4.3.2. Advertisement of LSs through Zone . . . . . . . . . . 16 80 5. Seamless Migration . . . . . . . . . . . . . . . . . . . . . 16 81 5.1. Transfer zone to a Single Node . . . . . . . . . . . . . 16 82 5.2. Roll Back from Zone as a Single Node . . . . . . . . . . 17 83 6. Operations . . . . . . . . . . . . . . . . . . . . . . . . . 19 84 7. Security Considerations . . . . . . . . . . . . . . . . . . 19 85 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 86 9. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 19 87 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 88 10.1. Normative References . . . . . . . . . . . . . . . . . . 19 89 10.2. Informative References . . . . . . . . . . . . . . . . . 20 90 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21 92 1. Introduction 94 [ISO10589] and [RFC2328] describe two levels of areas, which are 95 level 1 and level 2 areas in IS-IS, and backbone and non-backbone 96 areas in OSPF. There are scalability issues in using areas as the 97 number of routers in a network becomes larger and larger. 99 Through splitting the network into multiple areas, we may extend the 100 network further. However, dividing a network from one area into 101 multiple areas or from a number of existing areas to even more areas 102 is a very challenging and time consuming task since it is involved in 103 significant network architecture changes. 105 Furthermore, the services carried by the network may be interrupted 106 while the network is being split from one area into multiple areas or 107 from a few existing areas into even more areas. 109 These issues can be resolved by using topology-transparent zone 110 (TTZ), which abstracts a zone (i.e., a block/piece of an area) as a 111 single pseudo node or zone edges' mess with minimum efforts and 112 minimum service interruption. Note that a zone can be an area (i.e., 113 the entire piece of an area). 115 This document presents a topology-transparent zone and describes 116 extensions to IS-IS and OSPF for supporting the topology-transparent 117 zone. 119 1.1. Requirements Language 121 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 122 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 123 document are to be interpreted as described in RFC 2119 [RFC2119]. 125 1.2. Terminology 127 LSP: A Link State Protocol Data Unit (PDU) in IS-IS. 129 LSA: A Link State Advertisement in OSPF. 131 LS: A Link Sate, which is an LSA in OSPF or LSP in IS-IS. 133 TTZ: A Topology-Transparent Zone. 135 Zone: A block or piece of an area. In a special case, a zone is an 136 area (i.e., the entire piece of an area). 138 Zone External Node: A node outside of a zone. 140 Zone Internal Node: A node of a zone without any connection to a 141 node outside of the zone. 143 Zone Edge/Border: A node of a zone connecting to a node outside of 144 the zone. 146 Zone Node: A zone internal node or a zone edge/border node (i.e., a 147 node of a zone). 149 Zone Link: A link connecting zone nodes (i.e., a link of a zone). 151 Zone Neighbor: A node outside of a zone that is a neighbor of a 152 zone edge/border. 154 2. Requirements 156 Topology-Transparent Zone (TTZ) may be deployed for resolving some 157 critical issues such as scalability in existing networks and future 158 networks. The requirements for TTZ are listed as follows: 160 o TTZ MUST be backward compatible. When a TTZ is deployed on a set 161 of routers in a network, the routers outside of the TTZ in the 162 network do not need to know or support TTZ. 164 o TTZ MUST support at least one more levels of network hierarchies, 165 in addition to the hierarchies supported by existing routing 166 protocols. 168 o Abstracting a zone as a virtual abstracted entity, which is a 169 single pseudo node or zone edges' mess, SHOULD be smooth with 170 minimum service interruption. 172 o De-abstracting (or say rolling back) a virtual abstracted entity 173 to a zone SHOULD be smooth with minimum service interruption. 175 o Users SHOULD be able to easily set up an end to end service 176 crossing TTZs. 178 o The configuration for a TTZ in a network SHOULD be minimum. 180 o The changes on the existing protocols for supporting TTZ SHOULD be 181 minimum. 183 3. Zone Abstraction 185 A zone can be abstracted as a single pseudo node or the zone edges' 186 full mess. 188 When a zone is abstracted as a single pseudo node, this single node 189 is connected to all the neighbors of the zone, and is in the same 190 area as the neighbors. 192 When a zone is abstracted as its edges' full mess, there is a full 193 mess connections among the edges and each edge is also connected to 194 its neighbors outside of the zone. 196 4. Topology-Transparent Zone 198 A Topology-Transparent Zone (TTZ) comprises an Identifier (ID) and a 199 piece/block of an area such as a Level 2 area in IS-IS and a backbone 200 area in OSPF. It is abstracted as a single pseudo node or its edges' 201 full mess. TTZ and zone will be used exchangably below. 203 4.1. Zone as a Single Pseudo Node 205 After a zone is abstracted as a single pseudo node having a pseudo 206 node ID, every node outside of the zone sees a number of links 207 connected to this single node. Each of these links connects a zone 208 neighbor. The link states inside the zone are not advertised to any 209 node outside of the zone. The pseudo node ID may be derived from the 210 zone ID. 212 4.1.1. An Example of Zone as a Single Node 214 The figure below shows an example of an area containing a TTZ: TTZ 215 600. 217 TTZ 600 218 \ 219 \ ^~^~^~^~^~^~^~^~^~^~^~^~ 220 ( ) 221 ===[R15]========(==[R61]------------[R63]==)======[R29]=== 222 || ( | \ / | ) || 223 || ( | \ / | ) || 224 || ( | \ / | ) || 225 || ( | ___\ / | ) || 226 || ( | / [R71] | ) || 227 || ( | [R73] / \ | ) || 228 || ( | / \ | ) || 229 || ( | / \ | ) || 230 || ( | / \ | ) || 231 ===[R17]========(==[R65]------------[R67]==)======[R31]=== 232 \\ (// \\) // 233 || //v~v~v~v~v~v~v~v~v~v~v~\\ || 234 || // \\ || 235 || // \\ || 236 \\ // \\ // 237 ======[R23]==============================[R25]===== 238 // \\ 239 // \\ 241 Figure 1: An Example of TTZ 600 243 The area comprises routers R15, R17, R23, R25, R29 and R31. It also 244 contains TTZ 600, which comprises routers R61, R63, R65, R67, R71 and 245 R73, and the circuits connecting them. 247 There are two types of routers in a TTZ: TTZ internal routers and TTZ 248 edge/border routers. A TTZ internal router is a router inside the 249 TTZ and its adjacent routers are inside the TTZ. A TTZ edge/border 250 router is a router inside the TTZ and has at least one adjacent 251 router that is outside of the TTZ. 253 The TTZ in the figure above comprises four TTZ edge/border routers 254 R61, R63, R65 and R67. Each TTZ edge/border router is connected to 255 at least one router outside of the TTZ. For instance, router R61 is 256 a TTZ edge/border router since it is connected to router R15, which 257 is outside of the TTZ. 259 In addition, the TTZ comprises two TTZ internal routers R71 and R73. 260 A TTZ internal router is not connected to any router outside of the 261 TTZ. For instance, router R71 is a TTZ internal router since it is 262 not connected to any router outside of the TTZ. It is just connected 263 to routers R61, R63, R65, R67 and R73 inside the TTZ. 265 A TTZ MUST hide the information inside the TTZ from the outside. It 266 MUST NOT directly distribute any internal information about the TTZ 267 to a router outside of the TTZ. 269 For instance, the TTZ in the figure above MUST NOT send the 270 information about TTZ internal router R71 to any router outside of 271 the TTZ in the routing domain; it MUST NOT send the information about 272 the circuit between TTZ router R61 and R65 to any router outside of 273 the TTZ. 275 From a router outside of the TTZ, a TTZ is seen as a single node 276 (refer to the Figure below). For instance, router R15, which is 277 outside of TTZ 600, sees TTZ 600 as a single node Rz, which has 278 normal connections to R15, R29, R17 and R23, R25 and R31. 280 TTZ 600 281 \ 282 \ ^~^~^~^~^~^~^~^~^~^~^~^~ 283 ( ) 284 ===[R15]========( )======[R29]=== 285 || ( ) || 286 || ( ) || 287 || ( ) || 288 || ( ) || 289 || ( Rz ) || 290 || ( ) || 291 || ( ) || 292 || ( ) || 293 || ( ) || 294 ===[R17]========( )======[R31]=== 295 \\ ( ) // 296 || //v~v~v~v~v~v~v~v~v~v~v~\\ || 297 || // \\ || 298 || // \\ || 299 \\ // \\ // 300 ======[R23]==============================[R25]===== 301 // \\ 302 // \\ 304 Figure 2: TTZ 600 as Sinlge Node Rz 306 4.1.2. Zone Leader Election 308 A node in a zone is elected as a leader for the zone, which is the 309 node with the highest priority (and the highest node ID when there 310 are more than one nodes having the same highest priority) in the 311 zone. The leader election mechanism described in 313 [I-D.ietf-lsr-dynamic-flooding] may be used to elect the leader for 314 the zone. 316 4.1.3. LS Generation for Zone as a Single Node 318 The leader for the zone originates a LS (i.e., a LSP in IS-IS and a 319 LSA in OSPF) for the zone as a single Pseudo node and sends it to its 320 neighbors. This is the only LS to be flooded to the nodes outside of 321 the zone. 323 The LS comprises all the links connecting the zone neighbors. The LS 324 ID is the ID of the Pseudo node for the zone. The Source ID or 325 Advertising Node/Router ID is the ID of the Pseudo node. 327 In addition, the LS may contain the stub links for the routes such as 328 the loopback addresses inside the zone to be accessed by zone 329 external nodes (i.e., nodes outside of the zone). 331 4.1.4. Adjacency Establishment 333 A zone edge node, acting as a single Pseudo node for the zone, forms 334 an adjacency with a node outside of the zone in a way described 335 below. 337 Case 1 for a new adjacency (i.e., no adjacency exists between the 338 edge and the node outside of the zone also called zone neighbor): 340 The edge node originates and sends the zone neighbor every protocol 341 packet such as Hello, which contains the Pseudo node ID as Source ID. 343 When the edge node synchronizes its link state database (LSDB) with 344 the zone neighbor, it sends the zone neighbor the information about 345 all the link states except for the link states belonging to the zone 346 that are hidden from any node outside of the zone. 348 At the end of the LSDB synchronization, the LS for the zone as the 349 single pseudo node is originated by the zone leader and distributed 350 to the zone neighbor. This LS contains the links connecting all the 351 zone neighbors, including this newly formed zone neighbor. 353 Case 2 for an existing adjacency (i.e., an adjacency already exists 354 between the zone edge and the zone neighbor): 356 The zone edge sends Hellos to the zone neighbor with additional 357 information, including a flag T-bit set to one and a TLV with the 358 Pseudo node ID. This information requests the zone neighbor to 359 transfer the existing adjacency to the new adjacency smoothly through 360 working together with the zone edge in following steps. 362 Zone Edge Zone Neighbor 363 (Transfer Zone 364 to Pseudo Node) Hello(T=1, Pseudo ID) 365 ----------------------> OK for Transfer 366 Adjacency 367 Hello(T=1, Pseudo ID) 368 Remote Ready for <---------------------- 369 Transfer 370 Hello(Source=Pseudo ID) 371 Start Transfer -----------------------> Transfer to New 372 Adjacency 373 Hello 374 Transfer to New <----------------------- 375 Adjacency . . . 377 Step 1: When "Transfer Zone to Pseudo Node" is triggered, the zone 378 edge sends the zone neighbor a Hello containing additional 379 information T=1 and Pseudo node ID. 381 Step 2: After receiving the Hello with T=1 and Pseudo node ID from 382 the zone edge, the zone neighbor sends the zone edge a Hello with 383 T=1 and Pseudo node ID, which means ok for transfer to the new 384 adjacency. 386 Step 3: The edge sends the zone neighbor a Hello containing the 387 Pseudo node ID as Source ID after receiving the Hello with T=1 and 388 Pseudo node ID from the zone neighbor, which starts to transfer to 389 the new adjacency. 391 Step 4: The zone neighbor changes the existing adjacency to the new 392 adjacency after receiving the Hello containing the Pseudo node ID 393 as Source ID from the zone edge; and sends the zone edge a Hello 394 without the additional information, which means that it 395 transferred to the new adjacency. 397 Step 5: The zone edge changes the existing adjacency to the new 398 adjacency after receiving the Hello without the additional 399 information from the zone neighbor; and continues to send the zone 400 neighbor a Hello containing the Pseudo node ID as Source ID. At 401 this point, the old adjacency is transferred to the new one. 403 For the zone neighbor, changing the existing adjacency to the new one 404 includes: 406 o Changing the existing adjacency ID from the edge node ID to the 407 Pseudo node ID through either removing the existing adjacency and 408 adding a new adjacency with the Pseudo node ID or just changing 409 the existing adjacency ID from the edge node ID to the Pseudo node 410 ID, 412 o Removing the link to the zone edge node from its LS and adding a 413 new link to the Pseudo node (or just changing the link to the edge 414 node to the link to the Pseudo node in its LS), and 416 o Continuing sending the zone edge Hellos without additional 417 information. 419 For the zone edge, changing the existing adjacency to the new one 420 includes: 422 o Keeping the link to the zone neighbor in its LS, and 424 o Continuing sending the zone neighbor Hellos containing the Pseudo 425 node ID as Source ID. 427 4.1.5. Computation of Routes 429 After a zone edge migrates to zone as a pseudo node, it computes the 430 routes (i.e., shortest paths to the destinations) in the zone in the 431 same way as that described in RFC 2328. That is, it computes the 432 routes in the normal way using the zone topology (i.e., the topology 433 of the zone without the pseudo node). 435 For the routes outside of the zone, it computes them using the zone 436 topology, the topology outside of the zone without the pseudo node 437 and the connections between each zone edge and its zone neighbor. 439 After a zone internal node migrates to zone as a pseudo node, it 440 computes the routes using the zone topology, the topology outside of 441 the zone without the pseudo node and the connections between each 442 zone edge and its zone neighbor. 444 4.1.6. Extensions to Protocols 446 The following TLVs are defined in IS-IS and OSPF. 448 o Adjacent Node ID TLV: containing an adjacent node ID, to which an 449 adjacency is transferred or rolled back. In case of transfer, the 450 TLV contains the Pseudo node ID; in case of roll back, the TLV 451 contains the edge node ID. 453 o Zone ID TLV: containing an zone ID. 455 o Zone Options TLV: containing one of some operation options. 457 In addition, two new flag bits are defined in a TLV. In OSPF, this 458 TLV is the Extended Options and Flags (EOF) TLV of LLS Type 1, which 459 is defined in OSPF Link-Local Signaling [RFC5613]. In IS-IS, this 460 TLV may be the IS-IS Flooding Request TLV, which is defined in 461 Dynamic Flooding on Dense Graphs [I-D.ietf-lsr-dynamic-flooding]. 463 o T-bit: Short for Transfer Adjacency bit. The T-bit set to one 464 indicates a request for transferring to a new 'virtual' adjacency 465 from the existing adjacency and the new adjacency is identified by 466 the Pseudo node ID (or say abstract node ID), which is included in 467 a TLV, called Adjacent Node ID TLV. 469 o N-bit: Short for Roll Back to Normal Adjacency bit. The N-bit set 470 to one indicates a request for rolling back to a Normal adjacency 471 from the existing 'virtual' adjacency and the normal adjacency is 472 identified by the edge node ID, which is included in an Adjacent 473 Node ID TLV. 475 4.1.6.1. Extensions to IS-IS 477 The format of Adjacent Node ID TLV is illustrated below. 479 0 1 2 3 480 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 481 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 482 | Type (TBD) | Length (6) | Pseudo/Edge Node ID | 483 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 484 | Pseudo/Edge Node ID (Continue) | 485 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 487 The format of Zone ID TLV is illustrated below. 489 0 1 2 3 490 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 491 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 492 |ZoneID TLV Type| TLV-Length (8)| Zone ID | 493 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 494 | Zone ID (Continue) | 495 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 496 | Reserved (MUST be zero) |E|Z| 497 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 499 E = 1: Indicating a node is a zone edge node 500 Z = 1: Indicating a node has migrated to Zone as an abstracted entity 502 When a zone node originates a zone LS containing a zone ID TLV, it 503 MUST set flag E to 1 in the zone ID TLV if it is a zone edge node and 504 to 0 if it is a zone-internal node. It MUST set flag Z to 1 after it 505 has migrated to zone as an abstracted entity and to 0 before it 506 migrates zone to the abstracted entity or after it rolls back from 507 zone as an abstracted entity. 509 The format of Zone Options TLV is illustrated below. 511 0 1 2 3 512 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 513 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 514 |ZoneOP TLV Type| TLV-Length (2)| OP | Reserved (MUST be zero) | 515 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 517 OP Value Meaning (Operation) 518 0x001 (T): Advertising Zone Topology Information for Migration 519 0x010 (M): Migrating Zone to an Abstracted Entity 520 0x011 (N): Advertising Normal Topology Information for Rollback 521 0x100 (R): Rolling Back from the Abstracted Entity 523 An OP field of 3 bits is defined. It may have a value of 0x001 for 524 T, 0x010 for M, 0x011 for N, or 0x100 for R, which indicates one of 525 the four operations above. When any of the other values is received, 526 it is ignored. The details on these OPs are described in OSPF 527 Topology-Transparent Zone [RFC8099]. 529 4.1.6.2. Extensions to OSPF 531 The format of Adjacent Node ID TLV in OSPF is illustrated below. 533 0 1 2 3 534 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 535 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 536 | Type (TBD) | Length (4) | 537 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 538 | Pseudo/Edge Node ID (i.e., Pseudo/Edge Router ID) | 539 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 541 The Zone ID TLV and Zone Options TLV in OSPF are defined in OSPF 542 Topology-Transparent Zone [RFC8099]. 544 4.2. Zone as Edges Full Mess 546 OSPF Topology-Transparent Zone [RFC8099] describes the zone as edges' 547 full mess and the extensions to OSPF for supporting zone as edges' 548 full mess. Based on these extensions, IS-IS is extended by a few new 549 TLVs or Sub-TLVs. 551 4.2.1. Extensions to IS-IS 553 4.2.1.1. Zone TLV 555 A new TLV, which is called IS-IS Zone TLV, may be added into an LSP 556 or a Hello PDU for a zone node. It has the following format. 558 0 1 2 3 559 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 560 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 561 | Type (TBD) | Length | Flags | 562 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 563 | Zone ID | 564 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 565 | | Sub TLVs | 566 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 567 ~ ~ 568 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 570 Figure 3: IS-IS Zone TLV 572 A IS-IS Zone TLV has 1 byte of Type, 1 byte of Length of the value 573 field of the TLV, 2 bytes of Flags and 6 bytes of Zone ID. A IS-IS 574 Zone TLV in an LSP may contains a number of Sub TLVs and have Flags 575 defined as follows. 577 0 1 578 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 579 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 580 |E|T|M|N|R| 0 | 581 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 582 E = 1: Edge Node of Zone 583 T = 1: Distributing Zone Topology Information for Migration 584 M = 1: Migrating Zone to an Abstracted Entity 585 N = 1: Distributing Normal Topology Information for Rollback 586 R = 1: Rolling back from Zone as an Abstracted Entity 588 When a node in a zone receives a CLI command triggering zone 589 information distribution for migration, it updates its LSP by adding 590 a IS-IS Zone TLV with T set to 1. When a node in a zone receives a 591 CLI command activating migration zone to an abstracted entity, it 592 sets M to 1 in the Zone TLV in its LSP. 594 Two new sub-TLVs are defined, which may be added into a IS-IS Zone 595 TLV in an LSP. One is Zone IS Neighbor sub-TLV, or Zone ISN sub-TLV 596 for short. The other is Zone ES Neighbor sub-TLV, or Zone ESN sub- 597 TLV for short. A Zone ISN sub-TLV contains the information about a 598 number of Zone IS neighbors connected to a zone edge router. It has 599 the format below. 601 0 1 2 3 602 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 603 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 604 | Type (TBD) | Length |DefaultMetric(i| DelayMetric(i)| 605 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 606 |ExpenseMetric(i| ErrorMetric(i)| Neighbor ID(i) | 607 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 608 ~ ~ 609 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 611 Figure 4: Zone ISN Sub TLV 613 A Zone ISN Sub TLV has 1 byte of Type, 1 byte of Length of 614 n*(IDLength + 4), which is followed by n tuples of Default Metric, 615 Delay Metric, Expense Metric, Error Metric and Neighbor ID. 617 A Zone ESN sub-TLV contains the information about a number of Zone ES 618 neighbors connected to a zone edge node. It has the format below. 620 0 1 2 3 621 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 622 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 623 | Type (TBD) | Length |Default Metric | DelayMetric | 624 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 625 |Expense Metric | Error Metric | Neighbor ID(i) | 626 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 627 ~ ~ 628 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 630 Figure 5: Zone ESN Sub TLV 632 4.2.1.2. Updating LSPs for Zone 634 A zone internal node adds a IS-IS Zone TLV into its LSP after it 635 receives an LSP containing a IS-IS Zone TLV with T = 1 or a CLI 636 command triggering zone information distribution for migration. The 637 TLV has a zone ID set to the ID of the zone and E bit in Flags set to 638 0 indicating zone internal node. The node floods its LSP to its 639 neighbors in the zone. 641 When a node inside the zone receives an LSP containing a IS-IS Zone 642 TLV from a neighboring node in the zone, it stores the LSP and floods 643 the LSP to the other neighboring nodes in the zone. 645 For every zone edge node, it updates its LSP in three steps and 646 floods the LSP to all its neighbors. 648 At first, the zone edge node adds a IS-IS Zone TLV into its LSP after 649 it receives an LSP containing a IS-IS Zone TLV with T = 1 or a CLI 650 command triggering zone information distribution for migration. The 651 TLV has a zone ID set to the ID of the zone, E bit in Flags set to 1 652 indicating zone edge node and a Zone ISN Sub TLV. The Sub TLV 653 contains the information about the zone IS neighbors connected to the 654 zone edge node. In addition, the TLV may has a Zone ESN Sub TLV 655 comprising the information about the zone end systems connected to 656 the zone edge node. 658 Secondly, it adds each of the other zone edge nodes as an IS neighbor 659 into the Intermediate System Neighbors TLV in the LSP after it 660 receives an LSP containing a IS-IS Zone TLV with M = 1 or a CLI 661 command activating migration zone to an abstracted entity. The 662 metric to the neighbor is the metric of the shortest path to the edge 663 node within the zone. 665 In addition, it adds a Prefix Neighbors TLV into its LSP. The TLV 666 contains a number of address prefixes in the zone to be reachable 667 from outside of the zone. 669 And then it removes the IS neighbors corresponding to the IS 670 neighbors in the Zone TLV (i.e., in the Zone ISN sub TLV) from 671 Intermediate System Neighbors TLV in the LSP, and the ES neighbors 672 corresponding to the ES neighbors in the Zone TLV (i.e., in the Zone 673 ESN sub TLV) from End System Neighbors TLV in the LSP. This SHOULD 674 be done after it receives the LSPs for virtualizing zone from the 675 other zone edges for a given time. 677 4.3. Advertisement of LSs 679 LSs can be divided into a couple of classes according to their 680 Advertisements. The first class of LSs is advertised within a zone. 681 The second is advertised through a zone. 683 4.3.1. Advertisement of LSs within Zone 685 Any LS about a link state in a zone is advertised only within the 686 zone. It is not advertised to any router outside of the zone. For 687 example, a router LS generated for a zone internal router is 688 advertised only within the zone. 690 Any network LS generated for a broadcast network in a zone is 691 advertised only within the zone. It is not advertised outside of the 692 zone. 694 After migrating to zone as a single pseudo node or edges' full mess, 695 every zone edge MUST NOT advertise any LS belonging to the zone or 696 any information in a LS belonging to the zone to any node outside of 697 the zone. The zone edge determines whether an LS is about a zone 698 internal link state by checking if the advertising router of the LS 699 is a zone internal router. 701 For any zone LS originated by a node within the zone, every zone edge 702 node MUST NOT advertise it to any node outside of the zone. 704 4.3.2. Advertisement of LSs through Zone 706 Any LS about a link state outside of a zone received by a zone edge 707 is advertised using the zone as transit. For example, when a zone 708 edge node receives an LS from a node outside of the zone, it floods 709 the LS to its neighbors both inside and outside of the zone. This LS 710 may be any LS such as a router LSA that is advertised within an OSPF 711 area. 713 The nodes in the zone continue to flood the LS. When another zone 714 edge receives the LS, it floods the LS to its neighbors both inside 715 and outside of the zone. 717 5. Seamless Migration 719 This section presents the seamless migration between a zone and its 720 single pseudo node. The seamless migration between a zone and its 721 edges' full mess for IS-IS is similar to that described in OSPF 722 Topology-Transparent Zone [RFC8099] for OSPF. 724 5.1. Transfer zone to a Single Node 726 After transfer a Zone to a Node is triggered, the zone is abstracted 727 as a single Pseudo node in two steps: 729 Step 1: Every zone edge node works together with each of its zone 730 neighbor nodes to smoothly transfer the existing adjacency between 731 the zone edge and the zone neighbor to a new adjacency between the 732 Pseudo node and the neighbor node in the way described in 733 Section 4.1.4 for Adjacency Establishment procedure for case 2. 735 Step 2: The zone leader originates a LS for the Pseudo node after 736 receiving the updated LSs originated by all the zone neighbor 737 nodes, where the updated LSs contain all the zone neighbors. 738 Every zone edge does not send any LS inside the zone to any zone 739 neighbors. 741 5.2. Roll Back from Zone as a Single Node 743 After roll back from Zone as a Node is triggered, rolling back is 744 done in two steps: 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 Pseudo 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 Pseudo node. Every 752 zone edge sends Hello and other packages such as CSNP in IS-IS to 753 its zone neighbors, where the packages contain the edge node ID as 754 Source ID. 756 The procedure below smoothly rolls back the existing virtual 757 adjacency between the edge node acting as the Pseudo 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 Node" is triggered, the edge 787 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 Pseudo 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 Pseudo node ID to the edge node ID, 823 o Removing the link to the Pseudo node from its LS and adding a new 824 link to the edge node (or just changing the link to the Pseudo 825 node to the link to the edge node in its LS), and 827 o Continuing sending the edge node Hellos without additional 828 information. 830 For the edge node, changing the existing virtual adjacency to the 831 normal one includes: 833 o Sending its LS to the neighbor, and 834 o Continuing sending the neighbor node Hellos containing the edge 835 node ID as Source ID without additional information. 837 6. Operations 839 The Operations on TTZ described in OSPF Topology-Transparent Zone 840 [RFC8099] are for Zone as Edges Full Mess in OSPF. They can be used 841 for Zone as Edges Full Mess in IS-IS. They can also be used for Zone 842 as a Single Pseudo Node in OSPF and IS-IS. 844 7. Security Considerations 846 The mechanism described in this document does not raise any new 847 security issues for the IS-IS and OSPF protocols. 849 8. IANA Considerations 851 9. Acknowledgement 853 The authors would like to thank Acee Lindem, Abhay Roy, Christian 854 Hopps, Dean Cheng, Russ White, Tony Przygienda, Wenhu Lu, Lin Han, 855 Kiran Makhijani, Padmadevi Pillay Esnault, and Yang Yu for their 856 valuable comments on TTZ. 858 10. References 860 10.1. Normative References 862 [I-D.ietf-lsr-dynamic-flooding] 863 Li, T., Psenak, P., Ginsberg, L., Chen, H., Przygienda, 864 T., Cooper, D., Jalil, L., and S. Dontula, "Dynamic 865 Flooding on Dense Graphs", draft-ietf-lsr-dynamic- 866 flooding-04 (work in progress), November 2019. 868 [I-D.ietf-spring-segment-routing] 869 Filsfils, C., Previdi, S., Ginsberg, L., Decraene, B., 870 Litkowski, S., and R. Shakir, "Segment Routing 871 Architecture", draft-ietf-spring-segment-routing-15 (work 872 in progress), January 2018. 874 [ISO10589] 875 International Organization for Standardization, 876 "Intermediate System to Intermediate System Intra-Domain 877 Routing Exchange Protocol for use in Conjunction with the 878 Protocol for Providing the Connectionless-mode Network 879 Service (ISO 8473)", ISO/IEC 10589:2002, Nov. 2002. 881 [RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and 882 dual environments", RFC 1195, DOI 10.17487/RFC1195, 883 December 1990, . 885 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 886 Requirement Levels", BCP 14, RFC 2119, 887 DOI 10.17487/RFC2119, March 1997, 888 . 890 [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, 891 DOI 10.17487/RFC2328, April 1998, 892 . 894 [RFC5029] Vasseur, JP. and S. Previdi, "Definition of an IS-IS Link 895 Attribute Sub-TLV", RFC 5029, DOI 10.17487/RFC5029, 896 September 2007, . 898 [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic 899 Engineering", RFC 5305, DOI 10.17487/RFC5305, October 900 2008, . 902 [RFC5613] Zinin, A., Roy, A., Nguyen, L., Friedman, B., and D. 903 Yeung, "OSPF Link-Local Signaling", RFC 5613, 904 DOI 10.17487/RFC5613, August 2009, 905 . 907 [RFC7142] Shand, M. and L. Ginsberg, "Reclassification of RFC 1142 908 to Historic", RFC 7142, DOI 10.17487/RFC7142, February 909 2014, . 911 [RFC8099] Chen, H., Li, R., Retana, A., Yang, Y., and Z. Liu, "OSPF 912 Topology-Transparent Zone", RFC 8099, 913 DOI 10.17487/RFC8099, February 2017, 914 . 916 10.2. Informative References 918 [Clos] Clos, C., "A Study of Non-Blocking Switching Networks", 919 The Bell System Technical Journal Vol. 32(2), DOI 920 10.1002/j.1538-7305.1953.tb01433.x, March 1953, 921 . 923 [RFC5307] Kompella, K., Ed. and Y. Rekhter, Ed., "IS-IS Extensions 924 in Support of Generalized Multi-Protocol Label Switching 925 (GMPLS)", RFC 5307, DOI 10.17487/RFC5307, October 2008, 926 . 928 Authors' Addresses 930 Huaimo Chen 931 Futurewei 932 Boston, MA 933 USA 935 Email: huaimo.chen@futurewei.com 937 Alvaro Retana 938 Futurewei 939 Raleigh, NC 940 USA 942 Email: alvaro.retana@futurewei.com 944 Richard Li 945 Futurewei 946 2330 Central expressway 947 Santa Clara, CA 948 USA 950 Email: richard.li@futurewei.com 952 Anil Kumar S N 953 RtBrick 954 Bangalore 955 India 957 Email: anil.ietf@gmail.com 959 Ning So 960 Plano, TX 75082 961 USA 963 Email: ningso01@gmail.com 965 Vic Liu 966 USA 968 Email: liu.cmri@gmail.com 969 Mehmet Toy 970 Verizon 971 USA 973 Email: mehmet.toy@verizon.com 975 Lei Liu 976 Fijitsu 977 USA 979 Email: liulei.kddi@gmail.com