idnits 2.17.1 draft-chen-isis-ttz-05.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 : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 5, 2018) is 2236 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Missing Reference: 'RFC5441' is mentioned on line 121, but not defined == Missing Reference: 'RFC5440' is mentioned on line 122, but not defined == Missing Reference: 'R71' is mentioned on line 205, but not defined == Missing Reference: 'R73' is mentioned on line 206, but not defined == Unused Reference: 'RFC2119' is defined on line 684, but no explicit reference was found in the text == Unused Reference: 'RFC7142' is defined on line 689, but no explicit reference was found in the text == Unused Reference: 'RFC1195' is defined on line 693, but no explicit reference was found in the text == Unused Reference: 'RFC5305' is defined on line 697, but no explicit reference was found in the text == Unused Reference: 'RFC5029' is defined on line 701, but no explicit reference was found in the text Summary: 1 error (**), 0 flaws (~~), 10 warnings (==), 1 comment (--). 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: Experimental A. Kumar S N 5 Expires: September 6, 2018 Huawei 6 A. Retana 7 Cisco Systems, Inc. 8 N. So 9 Tata Communications 10 V. Liu 11 China Mobile 12 M. Toy 13 Verizon 14 L. Liu 15 Fijitsu 16 March 5, 2018 18 IS-IS Topology-Transparent Zone 19 draft-chen-isis-ttz-05.txt 21 Abstract 23 This document presents a topology-transparent zone in a domain. A 24 zone comprises a group of routers and a number of circuits connecting 25 them. Any router outside of the zone is not aware of the zone. The 26 information about the circuits and routers inside the zone is not 27 distributed to any router outside of the zone. Any link state change 28 such as a circuit down inside the zone is not seen by any router 29 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 http://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 6, 2018. 48 Copyright Notice 49 Copyright (c) 2018 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents 54 (http://trustee.ietf.org/license-info) in effect on the date of 55 publication of this document. Please review these documents 56 carefully, as they describe your rights and restrictions with respect 57 to this document. Code Components extracted from this document must 58 include Simplified BSD License text as described in Section 4.e of 59 the Trust Legal Provisions and are provided without warranty as 60 described in the Simplified BSD License. 62 Table of Contents 64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 65 2. Conventions Used in This Document . . . . . . . . . . . . . . 4 66 3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 4 67 4. Topology-Transparent Zone . . . . . . . . . . . . . . . . . . 4 68 4.1. Overview of Topology-Transparent Zone . . . . . . . . . . 4 69 4.2. An Example of TTZ . . . . . . . . . . . . . . . . . . . . 5 70 5. Extensions to IS-IS Protocols . . . . . . . . . . . . . . . . 6 71 5.1. TTZ TLV . . . . . . . . . . . . . . . . . . . . . . . . . 6 72 6. Updating LSPs for TTZ . . . . . . . . . . . . . . . . . . . . 9 73 6.1. Updating LSP for a TTZ Internal Router . . . . . . . . . . 9 74 6.2. Updating LSP for a TTZ Edge Router . . . . . . . . . . . . 9 75 7. Establishing Adjacencies . . . . . . . . . . . . . . . . . . . 10 76 7.1. Discover TTZ Neighbor over Normal Adjacency . . . . . . . 10 77 7.2. Establishing TTZ Adjacencies . . . . . . . . . . . . . . . 10 78 7.3. Adjacency between TTZ Edge and Router outside . . . . . . 10 79 8. Distribution of LSPs . . . . . . . . . . . . . . . . . . . . . 11 80 8.1. Distribution of LSPs within TTZ . . . . . . . . . . . . . 11 81 8.2. Distribution of LSPs through TTZ . . . . . . . . . . . . . 11 82 9. Computation of Routing Table . . . . . . . . . . . . . . . . . 12 83 10. Operations . . . . . . . . . . . . . . . . . . . . . . . . . . 12 84 10.1. Configuring TTZ . . . . . . . . . . . . . . . . . . . . . 12 85 10.2. Smooth Migration to TTZ . . . . . . . . . . . . . . . . . 13 86 10.3. Adding a Router into TTZ . . . . . . . . . . . . . . . . . 14 87 11. Security Considerations . . . . . . . . . . . . . . . . . . . 14 88 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 89 13. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 15 90 14. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 15 91 15. Normative References . . . . . . . . . . . . . . . . . . . . . 15 92 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16 94 1. Introduction 96 ISO/IEC 10589 describes IS-IS areas or levels in an Autonomous System 97 (AS). Each level 1 area has a number of level 1 and level 2 routers 98 connected to the level 2 area. Each level 1 and level 2 router may 99 summarize the topology of its attached level 1 areas to the level 2 100 area or vice versa. 102 The number of routers in a network becomes larger and larger as the 103 Internet traffic keeps growing. Through splitting the network into 104 multiple areas, we can extend the network further. However, there 105 are a number of issues when a network is split further into more 106 areas. 108 At first, dividing a network from one area into multiple areas or 109 from a number of existing areas to even more areas is a very 110 challenging and time consuming task since it is involved in 111 significant network architecture changes. 113 Secondly, the services carried by the network may be interrupted 114 while the network is being split from one area into multiple areas or 115 from a number of existing areas into even more areas. 117 Furthermore, it is complex for a Multi-Protocol Label Switching 118 (MPLS) Traffic Engineering (TE) Label Switching Path (LSP) crossing 119 multiple areas to be setup. In one option, a TE path crossing 120 multiple areas is computed by using collaborating Path Computation 121 Elements (PCEs) [RFC5441] through the PCE Communication Protocol 122 (PCEP)[RFC5440], which is not easy to configure by operators since 123 the manual configuration of the sequence of domains is required. 124 Although this issue can be addressed by using the Hierarchical PCE, 125 this solution may further increase the complexity of network design. 126 Especially, the current PCE standard method may not guarantee that 127 the path found is optimal. 129 This document presents a topology-transparent zone in a domain or an 130 area and describes extensions to IS-IS for supporting the topology- 131 transparent zone, which is scalable and resolves the issues above. 133 A topology-transparent zone comprises a group of routers and a number 134 of circuits connecting these routers. Any router outside of the zone 135 is not aware of the zone. The information about the circuits and 136 routers inside the zone is not distributed to any router outside of 137 the zone. Any link state change such as a circuit down inside the 138 zone is not seen by any router outside of the zone. 140 2. Conventions Used in This Document 142 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 143 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 144 document are to be interpreted as described in RFC 2119. 146 3. Requirements 148 Topology-Transparent Zone (TTZ) may be deployed for resolving some 149 critical issues such as scalability in existing networks and future 150 networks. The requirements for TTZ are listed as follows: 152 o TTZ MUST be backward compatible. When a TTZ is deployed on a set 153 of routers in a network, the routers outside of the TTZ in the 154 network do not need to know or support TTZ. 156 o TTZ MUST support at least one more levels of network hierarchies, 157 in addition to the hierarchies supported by existing routing 158 protocols. 160 o Users SHOULD be able to easily set up an end to end service 161 crossing TTZs. 163 o The configuration for a TTZ in a network SHOULD be minimum. 165 o The changes on the existing protocols for supporting TTZ SHOULD be 166 minimum. 168 4. Topology-Transparent Zone 170 4.1. Overview of Topology-Transparent Zone 172 A Topology-Transparent Zone (TTZ) is identified by an Identifier 173 (ID), and it includes a group of routers and a number of circuits 174 connecting the routers. A TTZ is in an IS-IS domain (area). 176 The ID of a TTZ or TTZ ID is a number that is unique for identifying 177 an entity such as a node in an IS-IS domain (area). It is not zero 178 in general. 180 In addition to having the functions of an IS-IS level or area, an 181 IS-IS TTZ makes some improvements on an IS-IS level or area, which 182 include: 184 o An IS-IS TTZ is virtualized as the TTZ edge routers connected. 186 o An IS-IS TTZ receives the link state information about the 187 topology outside of the TTZ, stores the information in the TTZ and 188 floods the information through the TTZ to the routers outside of 189 TTZ. 191 4.2. An Example of TTZ 193 The figure below illustrates an example of a routing domain 194 containing a TTZ: TTZ 600. 196 TTZ 600 197 \ 198 \ ^~^~^~^~^~^~^~^~^~^~^~^~ 199 ( ) 200 ===[R15]========(==[R61]------------[R63]==)======[R29]=== 201 || ( | \ / | ) || 202 || ( | \ / | ) || 203 || ( | \ / | ) || 204 || ( | ___\ / | ) || 205 || ( | / [R71] | ) || 206 || ( | [R73] / \ | ) || 207 || ( | / \ | ) || 208 || ( | / \ | ) || 209 || ( | / \ | ) || 210 ===[R17]========(==[R65]------------[R67]==)======[R31]=== 211 \\ (// \\) // 212 || //v~v~v~v~v~v~v~v~v~v~v~\\ || 213 || // \\ || 214 || // \\ || 215 \\ // \\ // 216 ======[R23]==============================[R25]===== 217 // \\ 218 // \\ 220 Figure 1: An Example of TTZ 222 The routing domain comprises routers R15, R17, R23, R25, R29 and R31. 223 It also contains TTZ 600, which comprises routers R61, R63, R65, R67, 224 R71 and R73, and the circuits connecting them. 226 There are two types of routers in a TTZ: TTZ internal routers and TTZ 227 edge routers. A TTZ internal router is a router inside the TTZ and 228 its adjacent routers are inside the TTZ. A TTZ edge router is a 229 router inside the TTZ and has at least one adjacent router that is 230 outside of the TTZ. 232 The TTZ in the figure above comprises four TTZ edge routers R61, R63, 233 R65 and R67. Each TTZ edge router is connected to at least one 234 router outside of the TTZ. For instance, router R61 is a TTZ edge 235 router since it is connected to router R15, which is outside of the 236 TTZ. 238 In addition, the TTZ comprises two TTZ internal routers R71 and R73. 239 A TTZ internal router is not connected to any router outside of the 240 TTZ. For instance, router R71 is a TTZ internal router since it is 241 not connected to any router outside of the TTZ. It is just connected 242 to routers R61, R63, R65, R67 and R73 inside the TTZ. 244 A TTZ MUST hide the information inside the TTZ from the outside. It 245 MUST NOT directly distribute any internal information about the TTZ 246 to a router outside of the TTZ. 248 For instance, the TTZ in the figure above MUST NOT send the 249 information about TTZ internal router R71 to any router outside of 250 the TTZ in the routing domain; it MUST NOT send the information about 251 the circuit between TTZ router R61 and R65 to any router outside of 252 the TTZ. 254 In order to create a TTZ, we MUST configure the same TTZ ID on the 255 edge routers and identify the TTZ internal circuits on them. In 256 addition, we SHOULD configure the TTZ ID on every TTZ internal router 257 which indicates that every circuit of the router is a TTZ internal 258 circuit. 260 From a router outside of the TTZ, a TTZ is seen as a group of routers 261 fully connected. For instance, router R15 in the figure above, which 262 is outside of TTZ 600, sees TTZ 600 as a group of TTZ edge routers: 263 R61, R63, R65 and R67. These four TTZ edge routers are fully 264 connected. 266 In addition, a router outside of the TTZ sees TTZ edge routers having 267 normal connections to the routers outside of the TTZ. For example, 268 router R15 sees four TTZ edge routers R61, R63, R65 and R67, which 269 have the normal connections to R15, R29, R17 and R23, R25 and R31 270 respectively. 272 5. Extensions to IS-IS Protocols 274 5.1. TTZ TLV 276 A new TLV, which is called TTZ TLV, may be added into a link state 277 PDU(LSP) or a Hello PDU for a TTZ node. It has the following format. 279 TTZ TLV Length in Byte 280 +----------------------+ 281 | Type = TBD | 1 282 +----------------------+ 283 | Length | 1 284 +----------------------+ 285 | Flags | 2 286 +----------------------+ 287 | TTZ ID | 4 288 +----------------------+ 289 | Sub-TLVs | Length of Sub-TLVs 290 +----------------------+ 292 Figure 2: TTZ TLV 294 A TTZ TLV has 1 byte of Type, 1 byte of Length of the value field of 295 the TLV, which is followed by 2 bytes of Flags and 4 bytes of TTZ ID. 296 A TTZ TLV in an LSP may contains a number of sub TLVs and have Flags 297 defined as follows. 299 0 1 300 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 301 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 302 |E|T|M|N|R| 0 | 303 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 304 E = 1: Edge router of TTZ 305 T = 1: Distributing TTZ Topology Information for Migration 306 M = 1: Migrating to TTZ 307 N = 1: Distributing Normal Topology Information for Rollback 308 R = 1: Rolling back from TTZ 310 When a router in a TTZ receives a CLI command triggering TTZ 311 information distribution for migration, it updates its LSP by adding 312 a TTZ TLV with T set to 1. When a router in a TTZ receives a CLI 313 command activating migration to TTZ, it sets M to 1 in the TTZ TLV in 314 its LSP. 316 Two new sub-TLVs are defined, which may be added into a TTZ TLV in an 317 LSP. One is TTZ IS Neighbor sub-TLV, or TTZ ISN sub-TLV for short. 318 The other is TTZ ES Neighbor sub-TLV, or TTZ ESN sub-TLV for short. 319 A TTZ ISN sub-TLV contains the information about a number of TTZ IS 320 neighbors connected to a TTZ edge router. It has the format below. 322 TTZ ISN sub-TLV Length in Byte 323 +----------------------+ 324 | Sub-Type = 1 | 1 325 +----------------------+ 326 | Length | n*(IDLength + 5) 327 +----------------------+ 328 | Default Metric(i) | 1 329 +----------------------+ 330 | Delay Metric(i) | 1 331 +----------------------+ 332 | Expense Metric(i) | 1 333 +----------------------+ 334 | Error Metric(i) | 1 335 +----------------------+ 336 | Neighbor ID(i) | IDLength + 1 337 +----------------------+ 339 Figure 3: TTZ ISN sub TLV 341 A TTZ ESN sub-TLV contains the information about a number of TTZ ES 342 neighbors connected to a TTZ edge router. It has the format below. 344 TTZ ESN sub-TLV Length in Byte 345 +----------------------+ 346 | Sub-Type = 2 | 1 347 +----------------------+ 348 | Length | 4 + n*IDLength 349 +----------------------+ 350 | Default Metric | 1 351 +----------------------+ 352 | Delay Metric | 1 353 +----------------------+ 354 | Expense Metric | 1 355 +----------------------+ 356 | Error Metric | 1 357 +----------------------+ 358 | Neighbor ID | IDLength 359 +----------------------+ 360 | . . . . . . | 361 +----------------------+ 362 | Neighbor ID | IDLength 363 +----------------------+ 365 Figure 4: TTZ ESN sub TLV 367 6. Updating LSPs for TTZ 369 6.1. Updating LSP for a TTZ Internal Router 371 A TTZ internal router adds a TTZ TLV into its LSP after it receives 372 an LSP containing a TTZ TLV with T = 1 or a CLI command triggering 373 TTZ information distribution for migration. The TLV has a TTZ ID set 374 to the ID of the TTZ and E bit in Flags set to 0 indicating TTZ 375 internal router. The router floods its LSP to its neighbors in the 376 TTZ. 378 When a router inside the TTZ receives a link state packet (LSP) 379 containing a TTZ TLV from a neighboring router in the TTZ, it stores 380 the link state and floods the link state to the other neighboring 381 routers in the TTZ. 383 6.2. Updating LSP for a TTZ Edge Router 385 For every edge router of a TTZ, it updates its LSP in three steps and 386 floods the LSP to all its neighbors. 388 At first, a TTZ edge router adds a TTZ TLV into its LSP after it 389 receives an LSP containing a TTZ TLV with T = 1 or a CLI command 390 triggering TTZ information distribution for migration. The TLV has a 391 TTZ ID set to the ID of the TTZ, E bit in Flags set to 1 indicating 392 TTZ edge router and a TTZ ISN sub TLV. The sub TLV contains the 393 information about the TTZ IS neighbors connected to the TTZ edge 394 router. In addition, the TLV may has a TTZ ESN sub TLV comprising 395 the information about the TTZ end systems connected to the TTZ edge 396 router. 398 Secondly, it adds each of the other TTZ edge routers as an IS 399 neighbor into the Intermediate System Neighbors TLV in the LSP after 400 it receives an LSP containing a TTZ TLV with M = 1 or a CLI command 401 activating migration to TTZ. The metric to the neighbor is the 402 metric of the shortest path to the edge router within the TTZ. 404 In addition, it adds a Prefix Neighbors TLV into its LSP. The TLV 405 contains a number of address prefixes in the TTZ to be reachable from 406 outside of the TTZ. 408 And then it removes the IS neighbors corresponding to the IS 409 neighbors in the TTZ TLV (i.e., in the TTZ ISN sub TLV) from 410 Intermediate System Neighbors TLV in the LSP, and the ES neighbors 411 corresponding to the ES neighbors in the TTZ TLV (i.e., in the TTZ 412 ESN sub TLV) from End System Neighbors TLV in the LSP. This SHOULD 413 be done after it receives the LSPs for virtualizing TTZ from the 414 other TTZ edges for a given time. 416 7. Establishing Adjacencies 418 7.1. Discover TTZ Neighbor over Normal Adjacency 420 For two routers A and B connected by a P2P circuit and having a 421 normal adjacency, they discover TTZ each other through including a 422 TTZ TLV containing a TTZ ID in their hello packets. If two ends of 423 the circuit have the same TTZ ID, A and B are TTZ neighbors; 424 otherwise, they are not TTZ neighbors, but normal neighbors. 426 For a number of routers connected through a broadcast circuit and 427 having normal adjacencies among them, they also discover TTZ each 428 other through including a TTZ TLV containing a TTZ ID in their hello 429 packets. The DIS for the circuit "forms" TTZ adjacency with each of 430 the other routers if all the routers attached to the circuit have the 431 same TTZ ID configured on the connections to the circuit and included 432 in their hello packets; otherwise, they are not TTZ neighbors, but 433 still normal neighbors. 435 7.2. Establishing TTZ Adjacencies 437 When a router (say A) is connected via a P2P circuit to another 438 router (say B) and there is not any adjacency between them over the 439 circuit, a user configures TTZ on two ends of the circuit to form a 440 TTZ adjacency. 442 Routers A and B include a TTZ TLV containing a TTZ ID in their hello 443 packets. If two routers have the same TTZ IDs in their hellos, an 444 adjacency between these two routers is to be formed; otherwise, no 445 adjacency is formed. 447 For a number of routers connected through a broadcast circuit and 448 having no adjacency among them, they start to form TTZ adjacencies 449 after TTZ is configured on the circuit and a TTZ TLV with a TTZ ID is 450 included in their hello packets. The DIS for the circuit forms TTZ 451 adjacency with each of the other routers if all the routers attached 452 to the circuit have the same TTZ ID configured on the connections to 453 the circuit and included in the hello packets; otherwise, the DIS 454 does not form any adjacency with any router attached to the circuit. 456 7.3. Adjacency between TTZ Edge and Router outside 458 For an edge router in a TTZ, in addition to establishing adjacencies 459 with other routers in the TTZ that have connections with the edge 460 router, it forms an adjacency with any router outside of the TTZ that 461 has a connection with the edge router. 463 When the edge router synchronizes its link state database with the 464 router outside of the TTZ, it sends the router outside of the TTZ the 465 information about all the LSPs except for the LSPs belong to the TTZ 466 that are hidden from any router outside of the TTZ. 468 At the end of the link state database synchronization, the edge 469 router originates its own LSP and sends this LSP to the router 470 outside of the TTZ. This LSP contains two groups of circuits. 472 The first group of circuits are the circuits connecting to the 473 routers outside of the TTZ from this TTZ edge router. The second 474 group of circuits are the "virtual" circuits connecting to the other 475 TTZ edge routers from this TTZ edge router. 477 From the point of view of the router outside of the TTZ, it sees the 478 other end as a normal router and forms the adjacency in the same way 479 as a normal router. It is not aware of anything about its 480 neighboring TTZ. From the LSPs related to the TTZ edge router in the 481 other end, it knows that the TTZ edge router is connected to each of 482 the other TTZ edge routers and some routers outside of the TTZ. 484 8. Distribution of LSPs 486 LSPs can be divided into two classes according to their 487 distributions. One class of LSPs is distributed within a TTZ. The 488 other is distributed through a TTZ. 490 8.1. Distribution of LSPs within TTZ 492 Any LSP generated for a TTZ internal router in a TTZ is distributed 493 within the TTZ. It will not be distributed to any router outside of 494 the TTZ. 496 Any pseudo node LSP generated for a broadcast network inside a TTZ, 497 is distributed within the TTZ. It will not be distributed to any 498 router outside of the TTZ. 500 8.2. Distribution of LSPs through TTZ 502 Any LSP about a link state outside of a TTZ received by an edge 503 router of the TTZ is distributed through the TTZ; and any LSP about a 504 link state for the TTZ generated by a TTZ edge router is distributed 505 through the TTZ. 507 For example, when an edge router of a TTZ receives an LSP for a link 508 state outside of the TTZ from a router outside of the TTZ, it floods 509 it to its neighboring routers both inside the TTZ and outside of the 510 TTZ. This LSP may be any LSP such as a router LSP that is 511 distributed in a domain. 513 The routers in the TTZ continue to flood the LSP. When another edge 514 router of the TTZ receives the LSP, it floods the LSP to its 515 neighboring routers both outside of the TTZ and inside the TTZ. 517 9. Computation of Routing Table 519 The computation of the routing table on a router outside of a TTZ is 520 the same as that described in ISO/SEC 10589. On a router in a TTZ, 521 the computation of the routing table has the same procedure flow as 522 that described in ISO/SEC 10589, with one exception. A router in a 523 TTZ MUST ignore the circuits in the router LSPs generated by the edge 524 routers of the TTZ for virtualizing the TTZ. 526 The routing table on a router inside the TTZ is computed through 527 using the link state database (LSDB) containing the LSPs for the 528 topology of the TTZ and the LSPs for the topology outside of the TTZ. 529 That is that the shortest path to every destination both inside the 530 TTZ and outside of the TTZ is computed over all the circuits 531 including the circuits inside the TTZ and the circuits outside of the 532 TTZ. 534 10. Operations 536 10.1. Configuring TTZ 538 This section proposes some options for configuring a TTZ. 540 1. Configuring TTZ on Every Circuit in TTZ 542 If every circuit in a TTZ is configured with a same TTZ ID as a TTZ 543 circuit, the TTZ is determined. A router with some TTZ circuits and 544 some normal circuits is a TTZ edge router. A router with only TTZ 545 circuits is a TTZ internal router. 547 2. Configuring TTZ on Every Router in TTZ 549 We may configure a same TTZ ID on every router in the TTZ, and on 550 every edge router's circuits connecting to the routers in the TTZ. 552 A router configured with the TTZ ID on some of its circuits is a TTZ 553 edge router. A router configured with the TTZ ID only is a TTZ 554 internal router. All the circuits on a TTZ internal router are TTZ 555 circuits. This option is simpler than the above one. 557 10.2. Smooth Migration to TTZ 559 For a group of routers and a number of circuits connecting the 560 routers in an area, making them transfer to work as a TTZ without any 561 service interruption may take a few of steps. 563 At first, users configure the TTZ feature on every router in the TTZ. 564 In this stage, a router does not update its LSPs. It will discover 565 its TTZ neighbors. 567 Secondly, after configuring the TTZ, users issue a CLI command on one 568 router in the TTZ, which triggers every router in the TTZ to 569 distribute TTZ information among the routers in the TTZ. When the 570 router receives the command, it updates its LSP by adding a TTZ TLV, 571 and distributes the LSP to its TTZ neighbors. The LSP has T = 1 in 572 Flags in the TTZ TLV (indicating TTZ information generation and 573 distribution for migration). When a router in the TTZ receives the 574 LSP with T = 1, it updates its LSP by adding a TTZ TLV. In this 575 stage, every router in the TTZ has dual roles. One is to function as 576 a normal router. The other is to generate and distribute TTZ 577 information. 579 Thirdly, users may check whether every router in the TTZ is ready for 580 transferring to work as a TTZ router. A router in the TTZ is ready 581 after it has received all the necessary information from all the 582 routers in the TTZ. This information may be displayed on a router 583 through a CLI command. 585 And then users activate the TTZ through using a CLI command such as 586 migrate to TTZ on one router in the TTZ. The router transfers to 587 work as a TTZ router, updates its LSP with M = 1 in the TTZ TLV 588 (indicating Migrating to TTZ) after it receives the command. 590 After a router in the TTZ receives the LSP with M = 1, it also 591 transfers to work as a TTZ router. Thus, activating the TTZ on one 592 TTZ router makes every router in the TTZ transfer to work as a TTZ 593 router, which computes routes through using the TTZ topology and the 594 topology outside of the TTZ. 596 For an edge router of the TTZ, transferring to work as a TTZ router 597 comprises updating its LSP to virtualize the TTZ by adding each of 598 the other TTZ edge routers as an IS neighbor and flooding this LSP to 599 all its direct neighboring routers. And then, the TTZ edge router 600 removes the IS neighbors corresponding to the IS neighbors in the TTZ 601 TLV (i.e., in the TTZ ISN sub TLV) from Intermediate System Neighbors 602 TLV in the LSP 604 10.3. Adding a Router into TTZ 606 When a non TTZ router (say R1) is connected via a P2P circuit to a 607 TTZ router (say T1) working as TTZ and there is a normal adjacency 608 between them over the circuit, a user can configure TTZ on two ends 609 of the circuit to add R1 into the TTZ to which T1 belongs. They 610 discover TTZ each other in the same way as described in section 7.1. 612 When a number of non TTZ routers are connected via a broadcast 613 circuit to a TTZ router (say T1) working as TTZ and there are normal 614 adjacencies among them, a user configures TTZ on the connection to 615 the circuit on every router to add the non TTZ routers into the TTZ 616 to which T1 belongs. The DIS for the circuit "forms" TTZ adjacency 617 with each of the other routers if all the routers have the same TTZ 618 ID configured on the connections to the circuit. 620 When a router (say R1) is connected via a P2P circuit to a TTZ router 621 (say T1) and there is not any adjacency between them over the 622 circuit, a user can configure TTZ on two ends of the circuit to add 623 R1 into the TTZ to which T1 belongs. R1 and T1 will form an 624 adjacency in the same way as described in section 7.2. 626 When a router (say R1) is connected via a broadcast circuit to a 627 group of TTZ routers on the circuit and there is not any adjacency 628 between R1 and any over the circuit, a user can configure TTZ on the 629 connection to the circuit on R1 to add R1 into the TTZ to which the 630 TTZ routers belong. R1 starts to form an adjacency with the DIS for 631 the circuit after the configuration. 633 11. Security Considerations 635 The mechanism described in this document does not raise any new 636 security issues for the IS-IS protocols. 638 12. IANA Considerations 640 This document requires the allocation for a new TLV and a couple of 641 new sub TLVs in the new TLV. IANA is requested to assign a new Type 642 (value 150 is suggested) for new TLV TTZ as follows: 644 +========+========+=======+=======+=======+=======+ 645 | Type | Name | IIH | LSP | SNP | Purge | 646 +========+========+=======+=======+=======+=======+ 647 | 150 | TTZ | Y | Y | N | N | 648 +========+========+=======+=======+=======+=======+ 650 This document defines two new Sub-TLVs in TLV 150. The values below 651 are suggested for them subject to assignment by IANA or Expert 652 review. 654 +========+==================================+ 655 | Type | Name and Description | 656 +========+==================================+ 657 | 1 | TTZ ISN, TTZ IS Neighbors | 658 +--------+----------------------------------+ 659 | 2 | TTZ ESN, TTZ ES Neighbors | 660 +========+==================================+ 662 13. Contributors 664 Veerendranatha Reddy Vallem 665 Huawei Technologies 666 Bangalore 667 India 668 Email: veerendranatharv@huawei.com 670 William McCall 671 cisco Systems, Inc. 672 Bellevue, WA 673 USA 674 wimccall@cisco.com 676 14. Acknowledgement 678 The author would like to thank Acee Lindem, Abhay Roy, Dean Cheng, 679 Wenhu Lu, Russ White, Tony Przygienda, Bingzhang Zhao, and Lin Han 680 for their valuable comments. 682 15. Normative References 684 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 685 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ 686 RFC2119, March 1997, 687 . 689 [RFC7142] Shand, M. and L. Ginsberg, "Reclassification of RFC 1142 690 to Historic", RFC 7142, DOI 10.17487/RFC7142, 691 February 2014, . 693 [RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and 694 dual environments", RFC 1195, DOI 10.17487/RFC1195, 695 December 1990, . 697 [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic 698 Engineering", RFC 5305, DOI 10.17487/RFC5305, 699 October 2008, . 701 [RFC5029] Vasseur, JP. and S. Previdi, "Definition of an IS-IS Link 702 Attribute Sub-TLV", RFC 5029, DOI 10.17487/RFC5029, 703 September 2007, . 705 Authors' Addresses 707 Huaimo Chen 708 Huawei 709 Boston, MA 710 USA 712 Email: huaimo.chen@huawei.com 714 Renwei Li 715 Huawei 716 2330 Central expressway 717 Santa Clara, CA 718 USA 720 Email: renwei.li@huawei.com 722 Anil Kumar S N 723 Huawei 724 Bangalore 725 India 727 Email: anil.sn@huawei.com 729 Alvaro Retana 730 Cisco Systems, Inc. 731 7025 Kit Creek Rd. 732 Raleigh, NC 27709 733 USA 735 Email: aretana@cisco.com 736 Ning So 737 Tata Communications 738 2613 Fairbourne Cir. 739 Plano, TX 75082 740 USA 742 Email: ningso01@gmail.com 744 Vic Liu 745 China Mobile 746 No.32 Xuanwumen West Street, Xicheng District 747 Beijing, 100053 748 China 750 Email: liu.cmri@gmail.com 752 Mehmet Toy 753 Verizon 754 USA 756 Email: mehmet.toy@verizon.com 758 Lei Liu 759 Fijitsu 760 USA 762 Email: lliu@us.fujitsu.com