idnits 2.17.1 draft-chen-ospf-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 (January 16, 2014) is 3746 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 205, but not defined == Missing Reference: 'R73' is mentioned on line 206, but not defined == Unused Reference: 'RFC2119' is defined on line 596, but no explicit reference was found in the text == Unused Reference: 'RFC2328' is defined on line 599, but no explicit reference was found in the text == Unused Reference: 'RFC4970' is defined on line 601, but no explicit reference was found in the text == Unused Reference: 'RFC2740' is defined on line 605, but no explicit reference was found in the text ** Obsolete normative reference: RFC 4970 (Obsoleted by RFC 7770) ** Obsolete normative reference: RFC 2740 (Obsoleted by RFC 5340) Summary: 2 errors (**), 0 flaws (~~), 7 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: Standards Track Huawei Technologies 5 Expires: July 20, 2014 G. Cauchie 7 A. Retana 8 Cisco Systems, Inc. 9 N. So 10 Tata Communications 11 M. Toy 12 Comcast 13 L. Liu 14 UC Davis 15 January 16, 2014 17 OSPF Topology-Transparent Zone 18 draft-chen-ospf-ttz-07.txt 20 Abstract 22 This document presents a topology-transparent zone in a domain. A 23 topology-transparent zone comprises a group of routers and a number 24 of links connecting these routers. Any router outside of the zone is 25 not aware of the zone. The information about the links and routers 26 inside the zone is not distributed to any router outside of the zone. 27 Any link state change such as a link down inside the zone is not seen 28 by any router outside of the zone. 30 Status of this Memo 32 This Internet-Draft is submitted to IETF in full conformance with the 33 provisions of BCP 78 and BCP 79. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF). Note that other groups may also distribute 37 working documents as Internet-Drafts. The list of current Internet- 38 Drafts is at http://datatracker.ietf.org/drafts/current/. 40 Internet-Drafts are draft documents valid for a maximum of six months 41 and may be updated, replaced, or obsoleted by other documents at any 42 time. It is inappropriate to use Internet-Drafts as reference 43 material or to cite them other than as "work in progress." 45 This Internet-Draft will expire on July 20, 2014. 47 Copyright Notice 48 Copyright (c) 2014 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (http://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 64 2. Conventions Used in This Document . . . . . . . . . . . . . . 4 65 3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 4 66 4. Topology-Transparent Zone . . . . . . . . . . . . . . . . . . 4 67 4.1. Overview of Topology-Transparent Zone . . . . . . . . . . 4 68 4.2. An Example of TTZ . . . . . . . . . . . . . . . . . . . . 5 69 4.2.1. Creation of a TTZ . . . . . . . . . . . . . . . . . . 5 70 5. Changes to OSPF Protocols . . . . . . . . . . . . . . . . . . 6 71 5.1. One Bit to Indicate an Internal TTZ Link . . . . . . . . . 7 72 5.2. A TTZ TLV in Router Information LSA . . . . . . . . . . . 8 73 6. Constructing Router LSA . . . . . . . . . . . . . . . . . . . 9 74 7. Establishing Adjacencies . . . . . . . . . . . . . . . . . . . 10 75 8. Distribution of LSAs . . . . . . . . . . . . . . . . . . . . . 11 76 8.1. Distribution of LSAs within TTZ . . . . . . . . . . . . . 11 77 8.2. Distribution of LSAs through TTZ . . . . . . . . . . . . . 11 78 9. Computation of Routing Table . . . . . . . . . . . . . . . . . 11 79 10. Operations . . . . . . . . . . . . . . . . . . . . . . . . . . 12 80 10.1. Configuring TTZ . . . . . . . . . . . . . . . . . . . . . 12 81 10.2. Smooth Migration to TTZ . . . . . . . . . . . . . . . . . 12 82 11. Security Considerations . . . . . . . . . . . . . . . . . . . 13 83 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 84 13. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 13 85 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 86 14.1. Normative References . . . . . . . . . . . . . . . . . . . 14 87 14.2. Informative References . . . . . . . . . . . . . . . . . . 14 88 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 90 1. Introduction 92 The number of routers in a network becomes larger and larger as the 93 Internet traffic keeps growing. Through splitting the network into 94 multiple areas, we can extend the network further. However, there 95 are a number of issues when a network is split further into more 96 areas. 98 At first, dividing a network from one area into multiple areas or 99 from a number of existing areas to even more areas is a very 100 challenging and time consuming task since it is involved in 101 significant network architecture changes. Considering the one area 102 case, originally the network has only one area, which is the 103 backbone. This original backbone area will be split into a new 104 backbone and a number of non backbone areas. In general, each of the 105 non backbone areas is connected to the new backbone area through the 106 area border routers between the non backbone and the backbone area. 107 There is not any direct connection between any two non backbone 108 areas. Each area border router summarizes the topology of its 109 attached non backbone area for transmission on the backbone area, and 110 hence to all other area border routers. 112 Secondly, the services carried by the network may be interrupted 113 while the network is being split from one area into multiple areas or 114 from a number of existing areas into even more areas. 116 Furthermore, it is complex for a Multi-Protocol Label Switching 117 (MPLS) Traffic Engineering (TE) Label Switching Path (LSP) crossing 118 multiple areas to be setup. In one option, a TE path crossing 119 multiple areas is computed by using collaborating Path Computation 120 Elements (PCEs) [RFC5441] through the PCE Communication Protocol 121 (PCEP)[RFC5440], which is not easy to configure by operators since 122 the manual configuration of the sequence of domains is required. 123 Although this issue can be addressed by using the Hierarchical PCE, 124 this solution may further increase the complexity of network design. 125 Especially, the current PCE standard method may not guarantee that 126 the path found is optimal. 128 This document presents a topology-transparent zone in an area and 129 describes extensions to OSPF for supporting the topology-transparent 130 zone, which is scalable and resolves the issues above. 132 A topology-transparent zone comprises a group of routers and a number 133 of links connecting these routers. Any router outside of the zone is 134 not aware of the zone. The information about the links and routers 135 inside the zone is not distributed to any router outside of the zone. 136 Any link state change such as a link down inside the zone is not seen 137 by any router outside of the zone. 139 2. Conventions Used in This Document 141 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 142 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 143 document are to be interpreted as described in RFC 2119. 145 3. Requirements 147 Topology-Transparent Zone (TTZ) may be deployed for resolving some 148 critical issues in existing networks and future networks. The 149 requirements for TTZ are listed as follows: 151 o TTZ MUST be backward compatible. When a TTZ is deployed on a set 152 of routers in a network, the routers outside of the TTZ in the 153 network do not need to know or support TTZ. 155 o TTZ MUST support at least one more levels of network hierarchies, 156 in addition to the hierarchies supported by existing routing 157 protocols. 159 o Users SHOULD be able to easily set up an end to end service 160 crossing TTZs. 162 o The configuration for a TTZ in a network SHOULD be minimum. 164 o The changes on the existing protocols for supporting TTZ SHOULD be 165 minimum. 167 4. Topology-Transparent Zone 169 4.1. Overview of Topology-Transparent Zone 171 A Topology-Transparent Zone (TTZ) is identified by an Identifier 172 (ID), and it includes a group of routers and a number of links 173 connecting the routers. A TTZ is in an OSPF area. 175 The ID of a Topology-Transparent Zone (TTZ) or TTZ ID is a number 176 that is unique for identifying an entity such as a node in an OSPF 177 domain. It is not zero in general. 179 In addition to having the functions of an OSPF area, an OSPF TTZ 180 makes some improvements on an OSPF area, which include: 182 o An OSPF TTZ is virtualized as a group of TTZ edge routers 183 connected. 185 o An OSPF TTZ receives the link state information about the topology 186 outside of the TTZ, stores the information in the TTZ and floods 187 the information through the TTZ to the routers outside of TTZ. 189 4.2. An Example of TTZ 191 4.2.1. Creation of a TTZ 193 The figure below illustrates an example of a routing area containing 194 a topology-transparent zone: 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 area comprises routers R15, R17, R23, R25, R29 and R31. 223 It also contains a topology-transparent zone TTZ 600. The TTZ 600 224 comprises routers R61, R63, R65, R67, R71 and R73, and the links 225 connecting them. 227 There are two types of routers in a TTZ: TTZ internal routers and TTZ 228 edge routers. A TTZ internal router is a router inside the TTZ and 229 every adjacent router of the TTZ internal router is a router inside 230 the TTZ. A TTZ edge router is a router inside the TTZ and has at 231 least one adjacent router that is outside of the TTZ. 233 The TTZ in the figure above comprises four TTZ edge routers R61, R63, 234 R65 and R67. Each TTZ edge router is connected to at least one 235 router outside of the TTZ. For instance, router R61 is a TTZ edge 236 router since it is connected to router R15, which is outside of the 237 TTZ. 239 In addition, the TTZ comprises two TTZ internal routers R71 and R73. 240 A TTZ internal router is not connected to any router outside of the 241 TTZ. For instance, router R71 is a TTZ internal router since it is 242 not connected to any router outside of the TTZ. It is just connected 243 to routers R61, R63, R65, R67 and R73 inside the TTZ. 245 A TTZ MUST hide the information inside the TTZ from the outside. It 246 MUST NOT directly distribute any internal information about the TTZ 247 to a router outside of the TTZ. 249 For instance, the TTZ in the figure above MUST NOT send the 250 information about TTZ internal router R71 to any router outside of 251 the TTZ in the routing domain; it MUST NOT send the information about 252 the link between TTZ router R61 and R65 to any router outside of the 253 TTZ. 255 In order to create a TTZ, we MUST configure the same TTZ ID on the 256 edge routers and identify the TTZ internal links on them. In 257 addition, we SHOULD configure the TTZ ID on every TTZ internal router 258 which indicates that every link of the router is a TTZ internal link. 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. Changes to OSPF Protocols 274 There are a number of ways to extend the existing OSPF protocol to 275 support TTZ. This section describes a couple of them. 277 o One way is to use one bit to indicate that a link is a TTZ link in 278 a router LSA. 280 o Another option is to have a TLV in a Router Information LSA 281 containing TTZ ID and flags to indicate that the router is a TTZ 282 edge router or a TTZ internal router. 284 5.1. One Bit to Indicate an Internal TTZ Link 286 A router LSA contains the description of a number of router links. 287 The existing format of a router LSA is illustrated as follows: 289 0 1 2 3 290 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 291 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 292 | LS age | Options | 1 | 293 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 294 | Link State ID | 295 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 296 | Advertising Router | 297 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 298 | LS sequence number | 299 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 300 | LS checksum | length | 301 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 302 | 0 |V|E|B| 0 | # links | 303 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 304 | Link ID | 305 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 306 | Link Data | 307 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 308 | Type | # TOS | metric | 309 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 310 | ... | 311 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 312 | TOS | 0 | TOS metric | 313 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 314 | Link ID | 315 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 316 | Link Data | 317 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 318 | ... | 320 Figure 2: Format of Router LSA 322 For a router link, the value of an eight bit Type field indicates the 323 kind of the link. The value of the Type field may be 1, 2, 3 or 4, 324 which indicates that the kind of the link is a point-to-point 325 connection to another router, a connection to a transit network, a 326 connection to a stub network, or a virtual link respectively. 328 The existing eight bit Type field for a router link may be split into 329 two fields as follows: 331 0 1 2 3 4 5 6 7 332 +---+---+---+---+---+---+---+---+ 333 | I | Type-1 | 334 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 336 I bit flag: 338 1: This indicates that the router link is an internal link 339 to a router inside the TTZ. 341 0: This indicates that the router link is an external link. 343 Type-1: 345 The kind of the link. 347 Figure 3: Bit to Indicate Internal TTZ Link 349 For a link inside a TTZ, the value of I bit flag is set to one, 350 indicating that this link is an internal TTZ link. For a link 351 connecting to a router outside of a TTZ from a TTZ edge router, the 352 value of I bit flag is set to zero, indicating that this link is an 353 external TTZ link. 355 The value of Type-1 field may have value 1, 2, 3, or 4, which 356 indicates that the kind of a link being described is a point-to-point 357 connection to another router, a connection to a transit network, a 358 connection to a stub network, or a virtual link respectively. 360 5.2. A TTZ TLV in Router Information LSA 362 A new TLV is proposed in Router Information LSA for TTZ in the figure 363 below to indicate a router's TTZ capability and the TTZ to which the 364 router belongs. 366 0 1 2 3 367 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 368 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 369 | Type | Length | 370 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 371 |E| | 372 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 373 | TTZ ID | 374 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 376 Type A 16-bit field set to a number to be determined by IANA. 378 Length A 16-bit field indicating the length of the value, which 379 is 8. 381 Value E bit set to 1 indicating a TTZ edge router 382 0 indicating a TTZ internal router 384 TTZ ID gives the TTZ to which the router belongs 386 Figure 4: TTZ TLV in Router Information LSA 388 The TTZ TLV follows the Router Informational Capabilities TLV in a 389 Router Information LSA. Every edge router of a TTZ generates a 390 Router Information LSA containing a TTZ TLV with E bit set to 1 and 391 the ID of the TTZ. Each internal router of the TTZ originates a 392 Router Information LSA containing a TTZ TLV with E bit set to 0 and 393 the ID of the TTZ. 395 A TTZ is defined by all the routers with the same TTZ ID and all the 396 TTZ links. For a TTZ edge router, its links connected to other TTZ 397 routers belong to the TTZ. For a TTZ internal router, all its links 398 belong to the TTZ. 400 6. Constructing Router LSA 402 Two types of router LSAs are generated by an edge router of a TTZ. 403 The first type describes the links connecting to it; in fact, this 404 LSA is the "normal" LSA that would be constructed if the TTZ feature 405 is not used. This LSA is also generated by a router inside the TTZ. 406 The second is generated to virtualize the TTZ as a group of edge 407 routers connected. 409 The first type of LSA comprises both the router links connecting the 410 routers inside the TTZ and the router links connecting to the routers 411 outside of the TTZ. For each of the router links in the LSA, it can 412 be represented in one of the ways described in the previous section. 414 The second router LSA generated by an edge router of the TTZ 415 comprises two groups of links in general. 417 The first group of links are the router links connecting the routers 418 outside of the TTZ from this TTZ edge router. These router links are 419 normal router links. There is a router link for every adjacency 420 between this TTZ edge router and a router outside of the TTZ. 422 The second group of links are the "virtual" router links. For each 423 of the other TTZ edge routers, there is a "virtual" router link to it 424 from this TTZ edge router. The cost of the router link from this TTZ 425 router to one of the other TTZ edge routers may be the cost of the 426 shortest path from this TTZ edge router to it. 428 In addition, the LSA may contain a third group of links, which are 429 stub links for other destinations inside the TTZ. They may be the 430 loopback addresses to be accessed by a node outside of the TTZ. 432 7. Establishing Adjacencies 434 A router in a TTZ forms an adjacency with another router in the TTZ 435 in the same way as a normal router when these two routers have a 436 connection. 438 For an edge router in a TTZ, it also forms an adjacency with any 439 router outside of the TTZ that has a connection with the edge router. 441 When the edge router synchronizes its link state database with the 442 router outside of the TTZ, it sends the router outside of the TTZ the 443 information about all the LSAs except for the LSAs belonging to the 444 TTZ that are hidden from any router outside of the TTZ. 446 At the end of the link state database synchronization, the edge 447 router originates its own router LSA for virtualizing the TTZ and 448 sends this LSA to the router outside of the TTZ. 450 From the point of view of the router outside of the TTZ, it sees the 451 other end as a normal router and forms the adjacency in the same way 452 as a normal router. It is not aware of anything about its 453 neighboring TTZ. From the LSAs related to the TTZ edge router in the 454 other end, it knows that the TTZ edge router is connected to each of 455 the other TTZ edge routers and some routers outside of the TTZ. 457 8. Distribution of LSAs 459 LSAs can be divided into a couple of classes according to their 460 distributions. The first class of LSAs is distributed within a TTZ. 461 The second is distributed through a TTZ. 463 8.1. Distribution of LSAs within TTZ 465 Any LSA about a link state in a TTZ is distributed within the TTZ. 466 It will not be distributed to any router outside of the TTZ. 468 For example, any router LSA generated for a router in a TTZ is 469 distributed within the TTZ. It will not be distributed to any router 470 outside of the TTZ. 472 Any network LSA generated for a broadcast or NBMA network inside a 473 TTZ is distributed within the TTZ. It will not be distributed to any 474 router outside of the TTZ. 476 Any opaque LSA generated for a TTZ internal TE link is distributed 477 within the TTZ. It will not be distributed to any router outside of 478 the TTZ. 480 8.2. Distribution of LSAs through TTZ 482 Any LSA about a link state outside of a TTZ received by an edge 483 router of the TTZ is distributed through the TTZ. 485 For example, when an edge router of a TTZ receives an LSA for a link 486 state outside of the TTZ from a router outside of the TTZ, it floods 487 it to its neighboring routers both inside the TTZ and outside of the 488 TTZ. This LSA may be any LSA such as a router LSA and an opaque LSA 489 that is distributed in a domain. 491 The routers in the TTZ continue to flood the LSA. When another edge 492 router of the TTZ receives the LSA, it floods the LSA to its 493 neighboring routers both outside of the TTZ and inside the TTZ. 495 9. Computation of Routing Table 497 The computation of the routing table on a router is the same as that 498 described in RFC 2328, with one exception. An edge router of a TTZ 499 MUST ignore the router LSAs generated by the edge routers of the TTZ 500 for virtualizing the TTZ. 502 10. Operations 504 As described above, only the edge routers of the TTZ are aware of any 505 changes in the operation of the domain. 507 10.1. Configuring TTZ 509 This section proposes a few of options for configuring a TTZ. 511 1. Configuring TTZ on Every Link in TTZ 513 If every link in a TTZ is configured with a same TTZ ID as a TTZ 514 link, the TTZ is determined. A router with some TTZ links and some 515 normal links is a TTZ edge router. A router with only TTZ links is a 516 TTZ internal router. 518 2. Configuring TTZ on Every Router in TTZ 520 We may configure a same TTZ ID on every router in the TTZ, and on 521 every edge router's links connecting to the routers in the TTZ. 523 A router configured with the TTZ ID on some of its links is a TTZ 524 edge router. A router configured with the TTZ ID only is a TTZ 525 internal router. All the links on a TTZ internal router are TTZ 526 links. 528 This option is simpler than the above one. 530 3. Configuring TTZ on Edge Routers 532 We may configure a same TTZ ID on every edge router of the TTZ and on 533 every edge router's links connectting the routers in the TTZ. 535 A router is a TTZ router if it is connected to another TTZ router. 536 For a TTZ internal router, all its links are TTZ links. A TTZ 537 comprises all the TTZ edge routers configured, the TTZ internal 538 routers, and the TTZ links. 540 This option is simpler than the above two options. 542 10.2. Smooth Migration to TTZ 544 This section describes the mechanisms which allow users to make a 545 smooth migration to the TTZ with minimum interruption to the network. 547 For a group of routers and a number of links connecting the routers 548 in an area, making them to work as a TTZ eventually with minimum 549 interruption to the network may take a few of steps or stages. 551 At first, users configure the TTZ feature on the edge routers of the 552 TTZ. In this stage, the router has dual roles. One role is to 553 function as a normal router. The other is to generate and distribute 554 some TTZ information among the routers in the TTZ. 556 Secondly, users SHOULD check whether every router in the TTZ is ready 557 for transferring to work as a TTZ router. A router in the TTZ is 558 ready after it has received all the necessary information from all 559 the routers in the TTZ. This information may be displayed on a 560 router through a CLI command. 562 And then users may activate the TTZ. There are a few of ways to 563 activate the TTZ. One way is to activate it on a TTZ router through 564 a CLI command such as activate TTZ directly. Another is through a 565 TTZ activate timer, which activates the TTZ once the timer expires. 567 After a TTZ router is requested to activate the TTZ, it transfers to 568 work as a TTZ router. When a TTZ router receives a LSA for 569 virtualizing the TTZ, it also transfers to work as a TTZ router. 570 Thus, activating the TTZ on one TTZ router will make every router in 571 the TTZ transfer to work as a TTZ router. 573 For an edge router of the TTZ, transferring to work as a TTZ router 574 comprises generating a router LSA to virtualize the TTZ and flooding 575 this LSA to all its neighboring routers. 577 11. Security Considerations 579 The mechanism described in this document does not raise any new 580 security issues for the OSPF protocols. 582 12. IANA Considerations 584 IANA is asked to assign a TLV in the OSPF Router Informational LSA, 585 as described in Section 5. 587 13. Acknowledgement 589 The author would like to thank Acee Lindem, Dean Cheng, Russ White, 590 William McCall, Tony Przygienda, Lin Han and Yang Yu for their 591 valuable comments on this draft. 593 14. References 594 14.1. Normative References 596 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 597 Requirement Levels", BCP 14, RFC 2119, March 1997. 599 [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998. 601 [RFC4970] Lindem, A., Shen, N., Vasseur, JP., Aggarwal, R., and S. 602 Shaffer, "Extensions to OSPF for Advertising Optional 603 Router Capabilities", RFC 4970, July 2007. 605 [RFC2740] Coltun, R., Ferguson, D., and J. Moy, "OSPF for IPv6", 606 RFC 2740, December 1999. 608 14.2. Informative References 610 [RFC5441] Vasseur, JP., Zhang, R., Bitar, N., and JL. Le Roux, "A 611 Backward-Recursive PCE-Based Computation (BRPC) Procedure 612 to Compute Shortest Constrained Inter-Domain Traffic 613 Engineering Label Switched Paths", RFC 5441, April 2009. 615 [RFC5440] Vasseur, JP. and JL. Le Roux, "Path Computation Element 616 (PCE) Communication Protocol (PCEP)", RFC 5440, 617 March 2009. 619 Authors' Addresses 621 Huaimo Chen 622 Huawei Technologies 623 Boston, MA 624 USA 626 Email: huaimo.chen@huawei.com 628 Renwei Li 629 Huawei Technologies 630 2330 Central expressway 631 Santa Clara, CA 632 USA 634 Email: renwei.li@huawei.com 635 Gregory Cauchie 636 FRANCE 638 Email: greg.cauchie@gmail.com 640 Alvaro Retana 641 Cisco Systems, Inc. 642 7025 Kit Creek Rd. 643 Raleigh, NC 27709 644 USA 646 Email: aretana@cisco.com 648 Ning So 649 Tata Communications 650 2613 Fairbourne Cir. 651 Plano, TX 75082 652 USA 654 Email: ning.so@tatacommunications.com 656 Mehmet Toy 657 Comcast 658 1800 Bishops Gate Blvd. 659 Mount Laurel, NJ 08054 660 USA 662 Email: mehmet_toy@cable.comcast.com 664 Lei Liu 665 UC Davis 666 CA 667 USA 669 Email: liulei.kddi@gmail.com