idnits 2.17.1 draft-chen-isis-ttz-07.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 (October 9, 2019) is 1661 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 219, but not defined == Missing Reference: 'R73' is mentioned on line 220, but not defined == Unused Reference: 'I-D.ietf-spring-segment-routing' is defined on line 859, but no explicit reference was found in the text == Unused Reference: 'RFC1195' is defined on line 872, but no explicit reference was found in the text == Unused Reference: 'RFC5029' is defined on line 885, but no explicit reference was found in the text == Unused Reference: 'RFC5305' is defined on line 889, but no explicit reference was found in the text == Unused Reference: 'RFC7142' is defined on line 898, but no explicit reference was found in the text == Unused Reference: 'Clos' is defined on line 909, but no explicit reference was found in the text == Unused Reference: 'RFC5307' is defined on line 914, but no explicit reference was found in the text == Outdated reference: A later version (-18) exists of draft-ietf-lsr-dynamic-flooding-03 ** 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: April 11, 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 October 9, 2019 18 Topology-Transparent Zone 19 draft-chen-isis-ttz-07.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 April 11, 2020. 48 Copyright Notice 50 Copyright (c) 2019 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 . . . . . . . 7 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 service interruption. Note that a zone can be an area (i.e., the 113 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 Users SHOULD be able to easily set up an end to end service 169 crossing TTZs. 171 o The configuration for a TTZ in a network SHOULD be minimum. 173 o The changes on the existing protocols for supporting TTZ SHOULD be 174 minimum. 176 3. Zone Abstraction 178 A zone can be abstracted as a single pseudo node or the zone edges' 179 full mess. 181 When a zone is abstracted as a single pseudo node, this single node 182 is connected to all the neighbors of the zone, and is in the same 183 area as the neighbors. 185 When a zone is abstracted as its edges' full mess, there is a full 186 mess connections among the edges and each edge is also connected to 187 its neighbors outside of the zone. 189 4. Topology-Transparent Zone 191 A Topology-Transparent Zone (TTZ) comprises an Identifier (ID) and a 192 piece/block of an area such as a Level 2 area in IS-IS and a backbone 193 area in OSPF. It is abstracted as a single pseudo node or its edges' 194 full mess. TTZ and zone will be used exchangably below. 196 4.1. Zone as a Single Pseudo Node 198 After a zone is abstracted as a single pseudo node having a pseudo 199 node ID, every node outside of the zone sees a number of links 200 connected to this single node. Each of these links connects a zone 201 neighbor. The link states inside the zone are not advertised to any 202 node outside of the zone. The pseudo node ID may be derived from the 203 zone ID. 205 4.1.1. An Example of Zone as a Single Node 207 The figure below shows an example of an area containing a TTZ: TTZ 208 600. 210 TTZ 600 211 \ 212 \ ^~^~^~^~^~^~^~^~^~^~^~^~ 213 ( ) 214 ===[R15]========(==[R61]------------[R63]==)======[R29]=== 215 || ( | \ / | ) || 216 || ( | \ / | ) || 217 || ( | \ / | ) || 218 || ( | ___\ / | ) || 219 || ( | / [R71] | ) || 220 || ( | [R73] / \ | ) || 221 || ( | / \ | ) || 222 || ( | / \ | ) || 223 || ( | / \ | ) || 224 ===[R17]========(==[R65]------------[R67]==)======[R31]=== 225 \\ (// \\) // 226 || //v~v~v~v~v~v~v~v~v~v~v~\\ || 227 || // \\ || 228 || // \\ || 229 \\ // \\ // 230 ======[R23]==============================[R25]===== 231 // \\ 232 // \\ 234 Figure 1: An Example of TTZ 600 236 The area comprises routers R15, R17, R23, R25, R29 and R31. It also 237 contains TTZ 600, which comprises routers R61, R63, R65, R67, R71 and 238 R73, and the circuits connecting them. 240 There are two types of routers in a TTZ: TTZ internal routers and TTZ 241 edge/border routers. A TTZ internal router is a router inside the 242 TTZ and its adjacent routers are inside the TTZ. A TTZ edge/border 243 router is a router inside the TTZ and has at least one adjacent 244 router that is outside of the TTZ. 246 The TTZ in the figure above comprises four TTZ edge/border routers 247 R61, R63, R65 and R67. Each TTZ edge/border router is connected to 248 at least one router outside of the TTZ. For instance, router R61 is 249 a TTZ edge/border router since it is connected to router R15, which 250 is outside of the TTZ. 252 In addition, the TTZ comprises two TTZ internal routers R71 and R73. 253 A TTZ internal router is not connected to any router outside of the 254 TTZ. For instance, router R71 is a TTZ internal router since it is 255 not connected to any router outside of the TTZ. It is just connected 256 to routers R61, R63, R65, R67 and R73 inside the TTZ. 258 A TTZ MUST hide the information inside the TTZ from the outside. It 259 MUST NOT directly distribute any internal information about the TTZ 260 to a router outside of the TTZ. 262 For instance, the TTZ in the figure above MUST NOT send the 263 information about TTZ internal router R71 to any router outside of 264 the TTZ in the routing domain; it MUST NOT send the information about 265 the circuit between TTZ router R61 and R65 to any router outside of 266 the TTZ. 268 From a router outside of the TTZ, a TTZ is seen as a single node 269 (refer to the Figure below). For instance, router R15, which is 270 outside of TTZ 600, sees TTZ 600 as a single node Rz, which has 271 normal connections to R15, R29, R17 and R23, R25 and R31. 273 TTZ 600 274 \ 275 \ ^~^~^~^~^~^~^~^~^~^~^~^~ 276 ( ) 277 ===[R15]========( )======[R29]=== 278 || ( ) || 279 || ( ) || 280 || ( ) || 281 || ( ) || 282 || ( Rz ) || 283 || ( ) || 284 || ( ) || 285 || ( ) || 286 || ( ) || 287 ===[R17]========( )======[R31]=== 288 \\ ( ) // 289 || //v~v~v~v~v~v~v~v~v~v~v~\\ || 290 || // \\ || 291 || // \\ || 292 \\ // \\ // 293 ======[R23]==============================[R25]===== 294 // \\ 295 // \\ 297 Figure 2: TTZ 600 as Sinlge Node Rz 299 4.1.2. Zone Leader Election 301 A node in a zone is elected as a leader for the zone, which is the 302 node with the highest priority (and the highest node ID when there 303 are more than one nodes having the same highest priority) in the 304 zone. The leader election mechanism described in 305 [I-D.ietf-lsr-dynamic-flooding] may be used to elect the leader for 306 the zone. 308 4.1.3. LS Generation for Zone as a Single Node 310 The leader for the zone originates a LS (i.e., a LSP in IS-IS and a 311 LSA in OSPF) for the zone as a single Pseudo node and sends it to its 312 neighbors. This is the only LS to be flooded to the nodes outside of 313 the zone. 315 The LS comprises all the links connecting the zone neighbors. The LS 316 ID is the ID of the Pseudo node for the zone. The Source ID or 317 Advertising Node/Router ID is the ID of the Pseudo node. 319 In addition, the LS may contain the stub links for the routes such as 320 the loopback addresses inside the zone to be accessed by zone 321 external nodes (i.e., nodes outside of the zone). 323 4.1.4. Adjacency Establishment 325 A zone edge node, acting as a single Pseudo node for the zone, forms 326 an adjacency with a node outside of the zone in a way described 327 below. 329 Case 1 for a new adjacency (i.e., no adjacency exists between the 330 edge and the node outside of the zone also called zone neighbor): 332 The edge node originates and sends the zone neighbor every protocol 333 packet such as Hello, which contains the Pseudo node ID as Source ID. 335 When the edge node synchronizes its link state database (LSDB) with 336 the zone neighbor, it sends the zone neighbor the information about 337 all the link states except for the link states belonging to the zone 338 that are hidden from any node outside of the zone. 340 At the end of the LSDB synchronization, the LS for the zone as the 341 single pseudo node is originated by the zone leader and distributed 342 to the zone neighbor. This LS contains the links connecting all the 343 zone neighbors, including this newly formed zone neighbor. 345 Case 2 for an existing adjacency (i.e., an adjacency already exists 346 between the zone edge and the zone neighbor): 348 The zone edge sends Hellos to the zone neighbor with additional 349 information, including a flag T-bit set to one and a TLV with the 350 Pseudo node ID. This information requests the zone neighbor to 351 transfer the existing adjacency to the new adjacency smoothly through 352 working together with the zone edge in following steps. 354 Zone Edge Zone Neighbor 355 (Transfer Zone 356 to Pseudo Node) Hello(T=1, Pseudo ID) 357 ----------------------> OK for Transfer 358 Adjacency 359 Hello(T=1, Pseudo ID) 360 Remote Ready for <---------------------- 361 Transfer 362 Hello(Source=Pseudo ID) 363 Start Transfer -----------------------> Transfer to New 364 Adjacency 365 Hello 366 Transfer to New <----------------------- 367 Adjacency . . . 369 Step 1: When "Transfer Zone to Pseudo Node" is triggered, the zone 370 edge sends the zone neighbor a Hello containing additional 371 information T=1 and Pseudo node ID. 373 Step 2: After receiving the Hello with T=1 and Pseudo node ID from 374 the zone edge, the zone neighbor sends the zone edge a Hello with 375 T=1 and Pseudo node ID, which means ok for transfer to the new 376 adjacency. 378 Step 3: The edge sends the zone neighbor a Hello containing the 379 Pseudo node ID as Source ID after receiving the Hello with T=1 and 380 Pseudo node ID from the zone neighbor, which starts to transfer to 381 the new adjacency. 383 Step 4: The zone neighbor changes the existing adjacency to the new 384 adjacency after receiving the Hello containing the Pseudo node ID 385 as Source ID from the zone edge; and sends the zone edge a Hello 386 without the additional information, which means that it 387 transferred to the new adjacency. 389 Step 5: The zone edge changes the existing adjacency to the new 390 adjacency after receiving the Hello without the additional 391 information from the zone neighbor; and continues to send the zone 392 neighbor a Hello containing the Pseudo node ID as Source ID. At 393 this point, the old adjacency is transferred to the new one. 395 For the zone neighbor, changing the existing adjacency to the new one 396 includes: 398 o Changing the existing adjacency ID from the edge node ID to the 399 Pseudo node ID through either removing the existing adjacency and 400 adding a new adjacency with the Pseudo node ID or just changing 401 the existing adjacency ID from the edge node ID to the Pseudo node 402 ID, 404 o Removing the link to the zone edge node from its LS and adding a 405 new link to the Pseudo node (or just changing the link to the edge 406 node to the link to the Pseudo node in its LS), and 408 o Continuing sending the zone edge Hellos without additional 409 information. 411 For the zone edge, changing the existing adjacency to the new one 412 includes: 414 o Keeping the link to the zone neighbor in its LS, and 416 o Continuing sending the zone neighbor Hellos containing the Pseudo 417 node ID as Source ID. 419 4.1.5. Computation of Routes 421 After a zone edge migrates to zone as a pseudo node, it computes the 422 routes (i.e., shortest paths to the destinations) in the zone in the 423 same way as that described in RFC 2328. That is, it computes the 424 routes in the normal way using the zone topology (i.e., the topology 425 of the zone without the pseudo node). 427 For the routes outside of the zone, it computes them using the zone 428 topology, the topology outside of the zone without the pseudo node 429 and the connections between each zone edge and its zone neighbor. 431 After a zone internal node migrates to zone as a pseudo node, it 432 computes the routes using the zone topology, the topology outside of 433 the zone without the pseudo node and the connections between each 434 zone edge and its zone neighbor. 436 4.1.6. Extensions to Protocols 438 The following TLVs are defined in IS-IS and OSPF. 440 o Adjacent Node ID TLV: containing an adjacent node ID, to which an 441 adjacency is transferred or rolled back. In case of transfer, the 442 TLV contains the Pseudo node ID; in case of roll back, the TLV 443 contains the edge node ID. 445 o Zone ID TLV: containing an zone ID. 447 o Zone Options TLV: containing one of some operation options. 449 In addition, two new flag bits are defined in a TLV. In OSPF, this 450 TLV is the Extended Options and Flags (EOF) TLV of LLS Type 1, which 451 is defined in OSPF Link-Local Signaling [RFC5613]. In IS-IS, this 452 TLV may be the IS-IS Flooding Request TLV, which is defined in 453 Dynamic Flooding on Dense Graphs [I-D.ietf-lsr-dynamic-flooding]. 455 o T-bit: Short for Transfer Adjacency bit. The T-bit set to one 456 indicates a request for transferring to a new 'virtual' adjacency 457 from the existing adjacency and the new adjacency is identified by 458 the Pseudo node ID (or say abstract node ID), which is included in 459 a TLV, called Adjacent Node ID TLV. 461 o N-bit: Short for Roll Back to Normal Adjacency bit. The N-bit set 462 to one indicates a request for rolling back to a Normal adjacency 463 from the existing 'virtual' adjacency and the normal adjacency is 464 identified by the edge node ID, which is included in an Adjacent 465 Node ID TLV. 467 4.1.6.1. Extensions to IS-IS 469 The format of Adjacent Node ID TLV is illustrated below. 471 0 1 2 3 472 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 473 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 474 | Type (TBD) | Length (6) | Pseudo/Edge Node ID | 475 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 476 | Pseudo/Edge Node ID (Continue) | 477 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 479 The format of Zone ID TLV is illustrated below. 481 0 1 2 3 482 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 483 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 484 |ZoneID TLV Type| TLV-Length (8)| Zone ID | 485 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 486 | Zone ID (Continue) | 487 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 488 | Reserved (MUST be zero) |E|Z| 489 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 491 E = 1: Indicating a node is a zone edge node 492 Z = 1: Indicating a node has migrated to Zone as an abstracted entity 494 When a zone node originates a zone LS containing a zone ID TLV, it 495 MUST set flag E to 1 in the zone ID TLV if it is a zone edge node and 496 to 0 if it is a zone-internal node. It MUST set flag Z to 1 after it 497 has migrated to zone as an abstracted entity and to 0 before it 498 migrates zone to the abstracted entity or after it rolls back from 499 zone as an abstracted entity. 501 The format of Zone Options TLV is illustrated below. 503 0 1 2 3 504 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 505 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 506 |ZoneOP TLV Type| TLV-Length (2)| OP | Reserved (MUST be zero) | 507 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 509 OP Value Meaning (Operation) 510 0x001 (T): Advertising Zone Topology Information for Migration 511 0x010 (M): Migrating Zone to an Abstracted Entity 512 0x011 (N): Advertising Normal Topology Information for Rollback 513 0x100 (R): Rolling Back from the Abstracted Entity 515 An OP field of 3 bits is defined. It may have a value of 0x001 for 516 T, 0x010 for M, 0x011 for N, or 0x100 for R, which indicates one of 517 the four operations above. When any of the other values is received, 518 it is ignored. The details on these OPs are described in OSPF 519 Topology-Transparent Zone [RFC8099]. 521 4.1.6.2. Extensions to OSPF 523 The format of Adjacent Node ID TLV in OSPF is illustrated below. 525 0 1 2 3 526 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 527 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 528 | Type (TBD) | Length (4) | 529 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 530 | Pseudo/Edge Node ID (i.e., Pseudo/Edge Router ID) | 531 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 533 The Zone ID TLV and Zone Options TLV in OSPF are defined in OSPF 534 Topology-Transparent Zone [RFC8099]. 536 4.2. Zone as Edges Full Mess 538 OSPF Topology-Transparent Zone [RFC8099] describes the zone as edges 539 full mess and the extensions to OSPF for supporting zone as edges 540 full mess. Based on these extensions, IS-IS is extended by a few new 541 TLVs or Sub-TLVs. 543 4.2.1. Extensions to IS-IS 545 4.2.1.1. Zone TLV 547 A new TLV, which is called Zone TLV, may be added into an LSP or a 548 Hello PDU for a zone node. It has the following format. 550 0 1 2 3 551 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 552 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 553 | Type (TBD) | Length | Flags | 554 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 555 | Zone ID | 556 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 557 | | Sub TLVs | 558 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 559 ~ ~ 560 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 562 Figure 3: Zone TLV 564 A Zone TLV has 1 byte of Type, 1 byte of Length of the value field of 565 the TLV, 2 bytes of Flags and 6 bytes of Zone ID. A Zone TLV in an 566 LSP may contains a number of Sub TLVs and have Flags defined as 567 follows. 569 0 1 570 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 571 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 572 |E|T|M|N|R| 0 | 573 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 574 E = 1: Edge Node of Zone 575 T = 1: Distributing Zone Topology Information for Migration 576 M = 1: Migrating Zone to an Abstracted Entity 577 N = 1: Distributing Normal Topology Information for Rollback 578 R = 1: Rolling back from Zone as an Abstracted Entity 580 When a node in a zone receives a CLI command triggering zone 581 information distribution for migration, it updates its LSP by adding 582 a Zone TLV with T set to 1. When a node in a zone receives a CLI 583 command activating migration zone to an abstracted entity, it sets M 584 to 1 in the Zone TLV in its LSP. 586 Two new sub-TLVs are defined, which may be added into a Zone TLV in 587 an LSP. One is Zone IS Neighbor sub-TLV, or Zone ISN sub-TLV for 588 short. The other is Zone ES Neighbor sub-TLV, or Zone ESN sub-TLV 589 for short. A Zone ISN sub-TLV contains the information about a 590 number of Zone IS neighbors connected to a zone edge router. It has 591 the format below. 593 0 1 2 3 594 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 595 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 596 | Type (TBD) | Length |DefaultMetric(i| DelayMetric(i)| 597 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 598 |ExpenseMetric(i| ErrorMetric(i)| Neighbor ID(i) | 599 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 600 ~ ~ 601 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 603 Figure 4: Zone ISN Sub TLV 605 A Zone ISN Sub TLV has 1 byte of Type, 1 byte of Length of 606 n*(IDLength + 4), which is followed by n tuples of Default Metric, 607 Delay Metric, Expense Metric, Error Metric and Neighbor ID. 609 A Zone ESN sub-TLV contains the information about a number of Zone ES 610 neighbors connected to a zone edge node. It has the format below. 612 0 1 2 3 613 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 614 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 615 | Type (TBD) | Length |Default Metric | DelayMetric | 616 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 617 |Expense Metric | Error Metric | Neighbor ID(i) | 618 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 619 ~ ~ 620 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 622 Figure 5: Zone ESN Sub TLV 624 4.2.1.2. Updating LSPs for Zone 626 A zone internal node adds a Zone TLV into its LSP after it receives 627 an LSP containing a Zone TLV with T = 1 or a CLI command triggering 628 zone information distribution for migration. The TLV has a zone ID 629 set to the ID of the zone and E bit in Flags set to 0 indicating zone 630 internal node. The node floods its LSP to its neighbors in the zone. 632 When a node inside the zone receives an LSP containing a Zone TLV 633 from a neighboring node in the zone, it stores the LSP and floods the 634 LSP to the other neighboring nodes in the zone. 636 For every zone edge node, it updates its LSP in three steps and 637 floods the LSP to all its neighbors. 639 At first, the zone edge node adds a Zone TLV into its LSP after it 640 receives an LSP containing a Zone TLV with T = 1 or a CLI command 641 triggering zone information distribution for migration. The TLV has 642 a zone ID set to the ID of the zone, E bit in Flags set to 1 643 indicating zone edge node and a Zone ISN Sub TLV. The Sub TLV 644 contains the information about the zone IS neighbors connected to the 645 zone edge node. In addition, the TLV may has a Zone ESN Sub TLV 646 comprising the information about the zone end systems connected to 647 the zone edge node. 649 Secondly, it adds each of the other zone edge nodes as an IS neighbor 650 into the Intermediate System Neighbors TLV in the LSP after it 651 receives an LSP containing a Zone TLV with M = 1 or a CLI command 652 activating migration zone to an abstracted entity. The metric to the 653 neighbor is the metric of the shortest path to the edge node within 654 the zone. 656 In addition, it adds a Prefix Neighbors TLV into its LSP. The TLV 657 contains a number of address prefixes in the zone to be reachable 658 from outside of the zone. 660 And then it removes the IS neighbors corresponding to the IS 661 neighbors in the Zone TLV (i.e., in the Zone ISN sub TLV) from 662 Intermediate System Neighbors TLV in the LSP, and the ES neighbors 663 corresponding to the ES neighbors in the Zone TLV (i.e., in the Zone 664 ESN sub TLV) from End System Neighbors TLV in the LSP. This SHOULD 665 be done after it receives the LSPs for virtualizing zone from the 666 other zone edges for a given time. 668 4.3. Advertisement of LSs 670 LSs can be divided into a couple of classes according to their 671 Advertisements. The first class of LSs is advertised within a zone. 672 The second is advertised through a zone. 674 4.3.1. Advertisement of LSs within Zone 676 Any LS about a link state in a zone is advertised only within the 677 zone. It is not advertised to any router outside of the zone. For 678 example, a router LS generated for a zone internal router is 679 advertised only within the zone. 681 Any network LS generated for a broadcast network in a zone is 682 advertised only within the zone. It is not advertised outside of the 683 zone. 685 After migrating to zone as a single pseudo node or edges full mess, 686 every zone edge MUST NOT advertise any LS belonging to the zone or 687 any information in a LS belonging to the zone to any node outside of 688 the zone. The zone edge determines whether an LS is about a zone 689 internal link state by checking if the advertising router of the LS 690 is a zone internal router. 692 For any zone LS originated by a node within the zone, every zone edge 693 node MUST NOT advertise it to any node outside of the zone. 695 4.3.2. Advertisement of LSs through Zone 697 Any LS about a link state outside of a zone received by a zone edge 698 is advertised using the zone as transit. For example, when a zone 699 edge node receives an LS from a node outside of the zone, it floods 700 the LS to its neighbors both inside and outside of the zone. This LS 701 may be any LS such as a router LSA that is advertised within an OSPF 702 area. 704 The nodes in the zone continue to flood the LS. When another zone 705 edge receives the LS, it floods the LS to its neighbors both inside 706 and outside of the zone. 708 5. Seamless Migration 710 This section presents the seamless migration between a zone and its 711 single pseudo node. The seamless migration between a zone and its 712 edges full mess for IS-IS is similar to that described in OSPF 713 Topology-Transparent Zone [RFC8099] for OSPF. 715 5.1. Transfer zone to a Single Node 717 After transfer a Zone to a Node is triggered, the zone is abstracted 718 as a single Pseudo node in two steps: 720 Step 1: Every zone edge node works together with each of its zone 721 neighbor nodes to smoothly transfer the existing adjacency between 722 the zone edge and the zone neighbor to a new adjacency between the 723 Pseudo node and the neighbor node in the way described in 724 Section 4.1.4 for Adjacency Establishment procedure for case 2. 726 Step 2: The zone leader originates a LS for the Pseudo node after 727 receiving the updated LSs originated by all the zone neighbor 728 nodes, where the updated LSs contain all the zone neighbors. 729 Every zone edge does not send any LS inside the zone to any zone 730 neighbors. 732 5.2. Roll Back from Zone as a Single Node 734 After roll back from Zone as a Node is triggered, rolling back is 735 done in two steps: 737 Step 1: Using the procedure described in the following, every zone 738 edge rolls back the existing virtual adjacency between the edge 739 node acting as the Pseudo node and the zone neighbor node to a 740 normal adjacency between the edge node and the neighbor. 742 Step 2: The zone leader may flush the LS for the Pseudo node. Every 743 zone edge sends Hello and other packages such as CSNP in IS-IS to 744 its zone neighbors, where the packages contain the edge node ID as 745 Source ID. 747 The procedure below smoothly rolls back the existing virtual 748 adjacency between the edge node acting as the Pseudo node and the 749 zone neighbor node to a normal adjacency between the edge node and 750 the neighbor node. 752 The edge node sends the neighbor node Hellos with additional 753 information, including a flag N-bit set to one and a TLV with the 754 edge node ID such as the Adjacent Node ID TLV with the edge node ID. 755 This information requests the neighbor node to roll back the existing 756 virtual adjacency to the normal adjacency smoothly through working 757 together with the edge node. 759 The following steps will roll back the existing virtual adjacency to 760 the normal one: 762 zone Edge zone Neighbor 763 (Roll Back to 764 Normal Adjacency) Hello (N=1, Edge ID) 765 ----------------------> OK to Roll Back to 766 Normal Adjacency 767 Hello (N=1, Edge ID) 768 Remote Ready for <---------------------- 769 Rolling Back 770 Hello(Source=Edge ID) 771 Start Roll Back -----------------------> Roll Back to 772 Normal Adjacency 773 Hello 774 Roll Back to <----------------------- 775 Normal Adjacency . . . 777 Step 1: When "Roll Back from Zone as a Node" is triggered, the edge 778 node sends the neighbor node a Hello with the additional 779 information N=1 and Edge ID as normal adjacency ID in order to 780 roll back to the normal adjacency from the virtual adjacency. 782 Step 2: After receiving the Hello with the additional information 783 from the edge node, the neighbor node sends the edge node a Hello 784 with the additional information (i.e., N=1 and Edge ID as normal 785 adjacency ID), which means ok for rolling back to the normal 786 adjacency. 788 Step 3: The edge sends the neighbor a Hello containing the edge node 789 ID as Source ID after receiving the Hello with the additional 790 information from the neighbor, which starts to roll back to the 791 normal adjacency. 793 Step 4: The neighbor node changes the existing adjacency to the 794 normal adjacency after receiving the Hello containing the edge 795 node ID as Source ID from the edge node; and sends the edge node a 796 Hello without the additional information, which means that it 797 rolled back to the normal adjacency. 799 Step 5: The edge node changes the existing adjacency to the normal 800 adjacency after receiving the Hello without the additional 801 information from the neighbor node; and continues to send the 802 neighbor Hello containing the edge node ID as Source ID. At this 803 point, the virtual adjacency is rolled back to the normal 804 adjacency. 806 For the neighbor node, changing the existing virtual adjacency to the 807 normal one includes: 809 o Changing the existing adjacency ID from the Pseudo node ID to the 810 edge node ID through either removing the existing adjacency and 811 adding a new adjacency with the edge node ID or just changing the 812 existing adjacency ID from the Pseudo node ID to the edge node ID, 814 o Removing the link to the Pseudo node from its LS and adding a new 815 link to the edge node (or just changing the link to the Pseudo 816 node to the link to the edge node in its LS), and 818 o Continuing sending the edge node Hellos without additional 819 information. 821 For the edge node, changing the existing virtual adjacency to the 822 normal one includes: 824 o Sending its LS to the neighbor, and 825 o Continuing sending the neighbor node Hellos containing the edge 826 node ID as Source ID without additional information. 828 6. Operations 830 The Operations on TTZ described in OSPF Topology-Transparent Zone 831 [RFC8099] are for Zone as Edges Full Mess in OSPF. They can be used 832 for Zone as Edges Full Mess in IS-IS. They can also be used for Zone 833 as a Single Pseudo Node in OSPF and IS-IS. 835 7. Security Considerations 837 The mechanism described in this document does not raise any new 838 security issues for the IS-IS and OSPF protocols. 840 8. IANA Considerations 842 9. Acknowledgement 844 The authors would like to thank Acee Lindem, Abhay Roy, Christian 845 Hopps, Dean Cheng, Russ White, Tony Przygienda, Wenhu Lu, Lin Han, 846 Kiran Makhijani, Padmadevi Pillay Esnault, and Yang Yu for their 847 valuable comments on TTZ. 849 10. References 851 10.1. Normative References 853 [I-D.ietf-lsr-dynamic-flooding] 854 Li, T., Psenak, P., Ginsberg, L., Chen, H., Przygienda, 855 T., Cooper, D., Jalil, L., and S. Dontula, "Dynamic 856 Flooding on Dense Graphs", draft-ietf-lsr-dynamic- 857 flooding-03 (work in progress), June 2019. 859 [I-D.ietf-spring-segment-routing] 860 Filsfils, C., Previdi, S., Ginsberg, L., Decraene, B., 861 Litkowski, S., and R. Shakir, "Segment Routing 862 Architecture", draft-ietf-spring-segment-routing-15 (work 863 in progress), January 2018. 865 [ISO10589] 866 International Organization for Standardization, 867 "Intermediate System to Intermediate System Intra-Domain 868 Routing Exchange Protocol for use in Conjunction with the 869 Protocol for Providing the Connectionless-mode Network 870 Service (ISO 8473)", ISO/IEC 10589:2002, Nov. 2002. 872 [RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and 873 dual environments", RFC 1195, DOI 10.17487/RFC1195, 874 December 1990, . 876 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 877 Requirement Levels", BCP 14, RFC 2119, 878 DOI 10.17487/RFC2119, March 1997, 879 . 881 [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, 882 DOI 10.17487/RFC2328, April 1998, 883 . 885 [RFC5029] Vasseur, JP. and S. Previdi, "Definition of an IS-IS Link 886 Attribute Sub-TLV", RFC 5029, DOI 10.17487/RFC5029, 887 September 2007, . 889 [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic 890 Engineering", RFC 5305, DOI 10.17487/RFC5305, October 891 2008, . 893 [RFC5613] Zinin, A., Roy, A., Nguyen, L., Friedman, B., and D. 894 Yeung, "OSPF Link-Local Signaling", RFC 5613, 895 DOI 10.17487/RFC5613, August 2009, 896 . 898 [RFC7142] Shand, M. and L. Ginsberg, "Reclassification of RFC 1142 899 to Historic", RFC 7142, DOI 10.17487/RFC7142, February 900 2014, . 902 [RFC8099] Chen, H., Li, R., Retana, A., Yang, Y., and Z. Liu, "OSPF 903 Topology-Transparent Zone", RFC 8099, 904 DOI 10.17487/RFC8099, February 2017, 905 . 907 10.2. Informative References 909 [Clos] Clos, C., "A Study of Non-Blocking Switching Networks", 910 The Bell System Technical Journal Vol. 32(2), DOI 911 10.1002/j.1538-7305.1953.tb01433.x, March 1953, 912 . 914 [RFC5307] Kompella, K., Ed. and Y. Rekhter, Ed., "IS-IS Extensions 915 in Support of Generalized Multi-Protocol Label Switching 916 (GMPLS)", RFC 5307, DOI 10.17487/RFC5307, October 2008, 917 . 919 Authors' Addresses 921 Huaimo Chen 922 Futurewei 923 Boston, MA 924 USA 926 Email: huaimo.chen@futurewei.com 928 Alvaro Retana 929 Futurewei 930 Raleigh, NC 931 USA 933 Email: alvaro.retana@futurewei.com 935 Richard Li 936 Futurewei 937 2330 Central expressway 938 Santa Clara, CA 939 USA 941 Email: richard.li@futurewei.com 943 Anil Kumar S N 944 RtBrick 945 Bangalore 946 India 948 Email: anil.ietf@gmail.com 950 Ning So 951 Plano, TX 75082 952 USA 954 Email: ningso01@gmail.com 956 Vic Liu 957 USA 959 Email: liu.cmri@gmail.com 960 Mehmet Toy 961 Verizon 962 USA 964 Email: mehmet.toy@verizon.com 966 Lei Liu 967 Fijitsu 968 USA 970 Email: liulei.kddi@gmail.com