idnits 2.17.1 draft-ietf-ospf-ttz-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 10, 2016) is 2970 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Missing Reference: 'T75' is mentioned on line 198, but not defined == Missing Reference: 'T71' is mentioned on line 200, but not defined == Missing Reference: 'T79' is mentioned on line 200, but not defined == Missing Reference: 'T73' is mentioned on line 201, but not defined == Unused Reference: 'RFC2119' is defined on line 937, but no explicit reference was found in the text == Unused Reference: 'RFC2328' is defined on line 942, but no explicit reference was found in the text == Unused Reference: 'RFC5441' is defined on line 952, but no explicit reference was found in the text == Unused Reference: 'RFC5440' is defined on line 959, but no explicit reference was found in the text Summary: 0 errors (**), 0 flaws (~~), 9 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 Huawei Technologies 5 Expires: September 11, 2016 A. Retana 6 Y. Yang 7 Cisco Systems, Inc. 8 V. Liu 9 China Mobile 10 M. Toy 11 Comcast 12 March 10, 2016 14 OSPF Topology-Transparent Zone 15 draft-ietf-ospf-ttz-03.txt 17 Abstract 19 This document presents a topology-transparent zone in an OSPF area. 20 A topology-transparent zone comprises a group of routers and a number 21 of links connecting these routers. Any router outside of the zone is 22 not aware of the zone. The information about the links and routers 23 such as a link down inside the zone is not advertised to any router 24 outside of the zone. 26 Status of this Memo 28 This Internet-Draft is submitted to IETF in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at http://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on September 11, 2016. 43 Copyright Notice 45 Copyright (c) 2016 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 61 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 62 3. Conventions Used in This Document . . . . . . . . . . . . . . 5 63 4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 5 64 5. Topology-Transparent Zone . . . . . . . . . . . . . . . . . . 5 65 5.1. Overview of Topology-Transparent Zone . . . . . . . . . . 5 66 5.2. Some Details on TTZ . . . . . . . . . . . . . . . . . . . 6 67 6. Extensions to OSPF Protocols . . . . . . . . . . . . . . . . . 7 68 6.1. General Format of TTZ LSA . . . . . . . . . . . . . . . . 8 69 6.2. TTZ ID TLV . . . . . . . . . . . . . . . . . . . . . . . . 8 70 6.3. TTZ Router TLV . . . . . . . . . . . . . . . . . . . . . . 9 71 6.4. TTZ Options TLV . . . . . . . . . . . . . . . . . . . . . 10 72 6.5. Link Scope TTZ LSA . . . . . . . . . . . . . . . . . . . . 11 73 7. Constructing LSAs for TTZ . . . . . . . . . . . . . . . . . . 11 74 8. Establishing Adjacencies . . . . . . . . . . . . . . . . . . . 13 75 8.1. Discover TTZ Neighbors . . . . . . . . . . . . . . . . . . 13 76 8.2. Adjacency between TTZ Edge and TTZ External Router . . . . 14 77 9. Advertisement of LSAs . . . . . . . . . . . . . . . . . . . . 14 78 9.1. Advertisement of LSAs within TTZ . . . . . . . . . . . . . 15 79 9.2. Advertisement of LSAs through TTZ . . . . . . . . . . . . 15 80 10. Computation of Routing Table . . . . . . . . . . . . . . . . . 15 81 11. Operations . . . . . . . . . . . . . . . . . . . . . . . . . . 16 82 11.1. Configuring TTZ . . . . . . . . . . . . . . . . . . . . . 16 83 11.2. Smooth Migration to TTZ . . . . . . . . . . . . . . . . . 16 84 11.3. Adding a Router into TTZ . . . . . . . . . . . . . . . . . 18 85 12. Prototype Implementation . . . . . . . . . . . . . . . . . . . 18 86 12.1. What are Implemented and Tested . . . . . . . . . . . . . 18 87 12.2. Implementation Experience . . . . . . . . . . . . . . . . 20 88 13. Security Considerations . . . . . . . . . . . . . . . . . . . 20 89 14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 90 15. Contributors and Other Authors . . . . . . . . . . . . . . . . 21 91 16. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 22 92 17. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22 93 17.1. Normative References . . . . . . . . . . . . . . . . . . . 22 94 17.2. Informative References . . . . . . . . . . . . . . . . . . 22 95 Appendix A. Constants for LSA Advertisement . . . . . . . . . . . 23 96 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23 98 1. Introduction 100 The number of routers in a network becomes larger and larger as the 101 network expands. For scalability and manageability, the network is 102 reorganized into more areas when it becomes too big. However, this 103 causes a number of issues. 105 At first, reorganizing a network from one area into multiple areas or 106 from a number of existing areas into even more areas is a very 107 challenging and time consuming task since it involves significant 108 network architecture changes. Considering the one area case, 109 originally the network has only one area, which is the backbone. 110 This original backbone area will be reorganized into a new backbone 111 and a number of non-backbone areas. In general, each of the non- 112 backbone areas is connected to the new backbone area through the Area 113 Border Routers (ABRs) between the non-backbone and the backbone area 114 (refer to RFC 2328 section 3). 116 Secondly, the services carried by the network may be interrupted 117 while the network is being reorganized from one area into multiple 118 areas or from a number of existing areas into even more areas since 119 every OSPF interface with an area change is going down with its old 120 area and then up with a new area. 122 This document presents a topology-transparent zone (TTZ) in an OSPF 123 area and describes extensions to OSPF for supporting the topology- 124 transparent zone, which is scalable and resolves the issues above. 126 2. Terminology 128 TTZ internal link: a link between two TTZ adjacent routers in the 129 same TTZ. A TTZ internal link is called a TTZ link in general. 131 TTZ internal router: a router in a TTZ whose adjacent routers are all 132 in the same TTZ. 134 TTZ external router: a router outside of a TTZ without any TTZ 135 internal link. 137 TTZ external link: a link between a TTZ edge router and a TTZ 138 external router. 140 TTZ edge router: a router in a TTZ that has one (or more) adjacent 141 routers which belong to the same TTZ, and one (or more) adjacent 142 routers which do not belong to the TTZ. 144 TTZ router: a router in a TTZ, i.e., a TTZ internal router or a TTZ 145 edge router. 147 3. Conventions Used in This Document 149 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 150 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 151 document are to be interpreted as described in RFC 2119. 153 4. Requirements 155 Topology-Transparent Zone may be deployed to resolve some critical 156 issues in existing networks and future networks. The requirements 157 for TTZ are listed as follows: 159 o Routers outside a TTZ MUST NOT require any changes to operate with 160 the TTZ. 162 o A TTZ MUST be enclosed in a single area. 164 o A TTZ MUST hide the topology of the TTZ from any router outside of 165 the TTZ. 167 5. Topology-Transparent Zone 169 5.1. Overview of Topology-Transparent Zone 171 A Topology-Transparent Zone is identified by an Identifier (ID), and 172 it consists of a group of routers and a number of links connecting 173 the routers. A TTZ MUST be contained within an OSPF area. 175 The ID of a TTZ or TTZ ID is a 32-bit number that is unique for 176 identifying a TTZ. The ID SHOULD NOT be 0. 178 In addition to having the functions of an OSPF area, an OSPF TTZ 179 makes some improvements on an OSPF area, which include: 181 o An OSPF TTZ is virtualized as the TTZ edges connected each other. 183 o An OSPF TTZ receives the link state information about the topology 184 outside of the TTZ, stores the information in the TTZ and floods 185 the information through the TTZ to the routers outside of the TTZ. 187 5.2. Some Details on TTZ 189 The figure below shows an area containing a TTZ: TTZ 600. 191 TTZ 600 ---- TTZ Internal Link 192 \ ==== Normal Link 193 Area X \ ^~^~^~^~^~^~^~^~^~^~^~^~ 194 ( ) 195 ===[R15]========(==[T61]----[T81]---[T63]==)======[R29]=== 196 || ( | \ / | ) || 197 || ( | \ / | ) || 198 || ( [T75] \ / | ) || 199 || ( | ___\ / | ) || 200 || ( | / [T71] [T79] ) || 201 || ( | [T73] / \ | ) || 202 || ( | / \ | ) || 203 || ( | / \ | ) || 204 || ( | / \ | ) || 205 ===[R17]========(==[T65]---[T77]----[T67]==)======[R31]=== 206 \\ (// \\) // 207 || //v~v~v~v~v~v~v~v~v~v~v~\\ || 208 || // \\ || 209 || // \\ || 210 \\ // \\ // 211 ======[R23]==============================[R25]===== 212 // \\ 213 // \\ 215 All the routers in the figure are in area X. Routers with T (i.e., 216 T61, T63, T65, T67, T71, T73, T75, T77, T79 and T81) are also in TTZ 217 600, which contains the TTZ internal links connecting them. To 218 create a TTZ, we need configure it (refer to section 11). 220 There are two types of routers in a TTZ: TTZ internal and TTZ edge 221 routers. TTZ 600 has four TTZ edge routers T61, T63, T65 and T67. 222 Each of them has at least one adjacent router in TTZ 600 and one 223 adjacent router outside of TTZ 600. For instance, router T61 is a 224 TTZ edge router since it has an adjacent router R15 outside of TTZ 225 600 and three adjacent routers T75, T71 and T81 in TTZ 600. 227 In addition, TTZ 600 comprises six TTZ internal routers T71, T73, 228 T75, T77, T79 and T81. Each of them has all its adjacent routers in 229 TTZ 600. For instance, router T71 is a TTZ internal router since its 230 adjacent routers T61, T63, T65, T67 and T73 are all in TTZ 600. Note 231 that none of the TTZ internal routers can be an ABR. 233 A TTZ hides the internal topology of the TTZ from the outside. It 234 does not directly advertise any internal information about the TTZ to 235 a router outside of the TTZ. 237 For instance, TTZ 600 does not send the information about TTZ 238 internal router T71 to any router outside of TTZ 600; it does not 239 send the information about the link between TTZ router T61 and T71 to 240 any router outside of TTZ 600. 242 The figure below illustrates area X from the point of view on a 243 router outside of TTZ 600 after TTZ 600 is created. 245 Area X ==== Normal Link 247 ===[R15]===========[T61]=========[T63]=========[R29]=== 248 || || \\ // || || 249 || || \\ // || || 250 || || \\ // || || 251 || || \\// || || 252 || || //\ || || 253 || || // \\ || || 254 || || // \\ || || 255 || || // \\ || || 256 || || // \\ || || 257 ===[R17]===========[T65]=========[T67]=========[R31]=== 258 \\ // \\ // 259 || // \\ || 260 || // \\ || 261 || // \\ || 262 \\ // \\ // 263 ======[R23]============================[R25]===== 264 // \\ 265 // \\ 267 From a router outside of the TTZ, a TTZ is seen as the TTZ edge 268 routers connected each other. For instance, router R15 sees that 269 T61, T63, T65 and T67 are connected each other. 271 In addition, a router outside of the TTZ sees TTZ edge routers having 272 normal connections to the routers outside of the TTZ. For example, 273 router R15 sees that T61, T63, T65 and T67 have the normal 274 connections to R15, R29, R17 and R23, R25 and R31 respectively. 276 6. Extensions to OSPF Protocols 278 The link state information about a TTZ includes router LSAs, which 279 can be contained and advertised in opaque LSAs [RFC5250] within the 280 TTZ. Some control information regarding a TTZ can also be contained 281 and advertised in opaque LSAs within the TTZ. These opaque LSAs are 282 called TTZ opaque LSAs or TTZ LSAs for short. 284 6.1. General Format of TTZ LSA 286 The following is the general format of a TTZ LSA. It has an LS Type 287 = 10/9 and TTZ-LSA-Type, and contains a number of TLVs. 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 | LS Type = 10/9| 293 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 294 |TTZ-LSA-Type(9)| Instance ID | 295 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 296 | Advertising Router | 297 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 298 | LS Sequence Number | 299 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 300 | LS checksum | Length | 301 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 302 | | 303 ~ TLVs ~ 304 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 306 Where TTZ-LSA-Type is 9, the exact number is to be assigned by IANA. 308 There are three top-level TLVs defined: TTZ ID TLV, TTZ Router TLV, 309 and TTZ Options TLV. A TTZ LSA of LS Type 10 contains a mandatory 310 TTZ ID TLV, which is followed by a number of other top-level TLVs. 312 A TTZ LSA having a optional TTZ Router TLV is called a TTZ Router 313 LSA. A TTZ LSA containing a TTZ Options TLV is called a TTZ Control 314 LSA. 316 6.2. TTZ ID TLV 318 A TTZ ID TLV has the following format. It contains a TTZ ID and some 319 flags. 321 0 1 2 3 322 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 323 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 324 | TTZ-ID-TLV-Type (1) | TLV-Length | 325 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 326 | TTZ ID | 327 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 328 | Reserved (MUST be zero) |E|Z| 329 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 330 E = 1: Indicating a router is a TTZ Edge router 331 Z = 1: Indicating a router has migrated to TTZ 333 When a TTZ router originates a TTZ LSA containing a TTZ ID TLV, it 334 sets flag E to 1 in the TTZ ID TLV if it is a TTZ edge router, and to 335 0 if it is a TTZ internal router. It sets flag Z to 1 after it has 336 migrated to TTZ. 338 6.3. TTZ Router TLV 340 The format of a TTZ Router TLV is as follows. It contains the 341 contents of a router LSA. 343 0 1 2 3 344 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 345 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 346 | TTZ-RT-TLV-Type (2) | TLV-Length | 347 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 348 | 0 |V|E|B| 0 | # links | 349 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 350 | Link ID | 351 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 352 | Link Data | 353 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 354 | Type | # TOS | metric | 355 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 356 ~ ... ~ 358 For a router link, the existing eight bit Type field for a router 359 link is split into two fields as follows: 361 0 1 2 3 4 5 6 7 362 +---+---+---+---+---+---+---+---+ 363 | I | Type-1 | 364 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 365 I bit flag: 366 1: Router link is a TTZ internal link. 367 0: Router link is a TTZ external link. 368 Type-1: The kind of the link. The values for Type-1 are the same 369 as those for Type defined in RFC 2328 section 12.4.1. 371 6.4. TTZ Options TLV 373 The format of a TTZ Options TLV is as follows. 375 0 1 2 3 376 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 377 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 378 | TTZ-OP-TLV-Type (3) | TLV-Length | 379 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 380 |T|M|N|R| Reserved (MUST be zero) | 381 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 382 T = 1: Advertising TTZ Topology Information for Migration 383 M = 1: Migrating to TTZ 384 N = 1: Advertising Normal Topology Information for Rollback 385 R = 1: Rolling back from TTZ 387 Flags T, M, N and R are exclusive. When one of them is set to 1, the 388 others MUST be set to 0. 390 After a user configures a TTZ router to advertise TTZ topology 391 information, the TTZ router originates a TTZ Control LSA having a TTZ 392 Options TLV with flag T set to 1. It also originates its TTZ router 393 LSA. When another TTZ router receives the LSA with T = 1, it 394 originates its TTZ router LSA as needed. 396 After a user configures a TTZ router to migrate to TTZ, the TTZ 397 router originates a TTZ Control LSA having a TTZ Options TLV with 398 flag M set to 1 and migrates to TTZ. When another TTZ router 399 receives the LSA with M = 1, it also migrates to TTZ. 401 After a user configures a TTZ router to advertise normal topology 402 information, the TTZ router originates a TTZ Control LSA having a TTZ 403 Options TLV with flag N set to 1. It also advertises its normal LSAs 404 such as its normal router LSA and stops advertising its other TTZ 405 LSAs. When another TTZ router receives the LSA with N = 1, it 406 advertises its normal LSAs and stops advertising its TTZ LSAs. 408 After a user configures a TTZ router to roll back from TTZ, the TTZ 409 router originates a TTZ Control LSA having a TTZ Options TLV with 410 flag R set to 1 and rolls back from TTZ. When another TTZ router 411 receives the LSA with R = 1, it also rolls back from TTZ. 413 After a TTZ router originates a TTZ control LSA in response to a 414 configuration described above to control TTZ, it updates the TTZ 415 control LSA accordingly if another configuration to control TTZ is 416 issued on it. 418 6.5. Link Scope TTZ LSA 420 A TTZ LSA of LS Type 9 has the following format. 422 0 1 2 3 423 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 424 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 425 | LS age | Options | LS Type = 9 | 426 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 427 |TTZ-LSA-Type(9)| Instance ID | 428 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 429 | Advertising Router | 430 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 431 | LS Sequence Number | 432 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 433 | LS checksum | Length | 434 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 435 | | 436 ~ TTZ ID TLV ~ 437 +---------------------------------------------------------------+ 438 | | 439 ~ (Options TLV) ~ 440 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 442 It contains a mandatory TTZ ID TLV, which may be followed by a 443 optional Options TLV. It is used to discover a TTZ neighbor. 445 7. Constructing LSAs for TTZ 447 The LSAs for representing a TTZ include TTZ router LSAs and normal 448 router LSAs for virtualizing the TTZ. 450 A TTZ router LSA generated by a TTZ edge router has a TTZ ID TLV and 451 a TTZ Router TLV. The former includes the ID of the TTZ to which the 452 router belongs and flag E set to 1, which indicates the originator of 453 the LSA is a TTZ Edge router. The latter contains the links attached 454 to the router. 456 A TTZ router LSA generated by a TTZ internal router has a TTZ ID TLV 457 containing the ID of the TTZ to which the router belongs and flag E 458 set to 0, which indicates the originator of the LSA is a TTZ internal 459 router. The TTZ internal router generates the TTZ router LSA with 460 just the TTZ ID TLV and its normal router LSA. 462 After receiving a trigger to migrate to TTZ such as a TTZ LSA with 463 flag M = 1, a TTZ edge router originates its normal router LSA for 464 virtualizing a TTZ, which comprises three groups of links in general. 466 The first group are the router links connecting the TTZ external 467 routers. These router links are normal router links. There is a 468 router link for every adjacency between this TTZ edge router and a 469 TTZ external router. 471 The second group are the "virtual" router links connecting to the 472 other TTZ edge routers. For each of the other TTZ edge routers, 473 there is a corresponding point-to-point router link to it from this 474 TTZ edge router. The cost of the link is the cost of the shortest 475 path from this TTZ edge router to the other TTZ edge router within 476 the TTZ. 478 In addition, the LSA may contain a third group of links, which are 479 the stub links for the loopback addresses inside the TTZ to be 480 accessed by nodes outside of the TTZ. 482 To migrate to a TTZ smoothly, a TTZ edge router virtualizes the TTZ 483 in two steps. At first, the router updates its normal router LSA by 484 adding a point-to-point link to each of the other edge routers of the 485 TTZ and a stub link for each of the loopback addresses in the TTZ to 486 be accessed outside of the TTZ into the LSA. And then it removes the 487 links configured as TTZ links from its updated router LSA after 488 sending its updated router LSA and receiving the updated router LSAs 489 originated by the other TTZ edge routers for MaxLSAAdvTime or after 490 sending its updated router LSA for MaxLSAGenAdvTime (refer to 491 Appendix A). 493 To roll back from a TTZ smoothly after receiving a trigger to roll 494 back from TTZ, a TTZ edge router updates its normal router LSA in the 495 above two steps in a reverse way. At first, it updates its normal 496 router LSA by adding the normal links for the links configured as TTZ 497 links into the LSA. And then it removes the point-to-point links to 498 the other edge routers of the TTZ for virtualizing the TTZ and the 499 stub links for the loopback addresses from its updated router LSA 500 after sending its updated router LSA and receiving the updated router 501 LSAs originated by the other TTZ edge routers for MaxLSAAdvTime or 502 after sending its updated router LSA for MaxLSAGenAdvTime. 504 8. Establishing Adjacencies 506 This section describes the adjacencies in different cases. 508 8.1. Discover TTZ Neighbors 510 For two routers A and B connected by a P2P link and having a normal 511 adjacency, they discover TTZ each other through a TTZ LSA of LS Type 512 9 with a TTZ ID TLV. We call this LSA D-LSA for short. 514 If two ends of the link have different TTZ IDs, no TTZ adjacency over 515 the link will be "formed". 517 If two ends of the link have the same TTZ ID and Z flag value, A and 518 B are TTZ neighbors. The following is a sequence of events related 519 to TTZ for this case. 521 A B 522 Configure TTZ Configure TTZ 523 D-LSA (TTZ-ID=100) 524 ----------------------> Same TTZ ID and Z 525 A is B's TTZ Neighbor 526 D-LSA (TTZ-ID=100) 527 Same TTZ ID and Z <---------------------- 528 B is A's TTZ Neighbor 530 A sends B a D-LSA with TTZ-ID after the TTZ is configured on it. B 531 sends A a D-LSA with TTZ-ID after the TTZ is configured on it. 533 When A receives the D-LSA from B and determines they have the same 534 TTZ ID and Z flag value, B is A's TTZ neighbor. A also sends B all 535 the TTZ LSAs it has and originates its TTZ router LSA if (Z==0 and 536 there is a TTZ LSA with T=1) OR Z==1. 538 B is symmetric to A and acts similarly to A. 540 If two ends of the link have the same TTZ ID but Z flags are 541 different, a TTZ adjacency over the link is "formed" in the following 542 steps. Suppose that A has migrated to TTZ and B has not (i.e., flag 543 Z in A's D-LSA is 1 and flag Z in B's D-LSA is 0). 545 When A receives the D-LSA from B and determines they have the same 546 TTZ ID but its Z=1 and B's Z=0, A sends B all the TTZ LSAs it has and 547 triggers B to migrate to TTZ. A updates and sends B its D-LSA by 548 adding an Options TLV with M=1 after sending B all the TTZ LSAs. 550 When B receives the D-LSA from A and determines they have the same 551 TTZ ID but its Z=0 and A's Z=1, B sends A all the TTZ LSAs it has and 552 starts to migrate to TTZ after receiving A's D-LSA with M=1. After 553 migration to TTZ, B updates and advertises its LSAs as needed. 555 After receiving B's D-LSA with Z=1, A updates and sends B its D-LSA 556 by removing the Options TLV. It also updates and advertises its LSAs 557 as needed. 559 For a number of routers connected through a broadcast link and having 560 normal adjacencies among them, they also discover TTZ each other 561 through D-LSAs. The DR for the link "forms" TTZ adjacencies with the 562 other routers if all the routers attached to the link have the same 563 TTZ ID configured on the connections to the link. Otherwise, the DR 564 does not "form" any TTZ adjacency with any router attached to the 565 link. 567 For a number of routers connected through a broadcast link and having 568 TTZ adjacencies among them, if a mis-configured router is introduced 569 on the broadcast link, the DR for the link will not "form" any TTZ 570 adjacency with this mis-configured router. 572 For routers connected via a link without any adjacency among them, 573 they discover TTZ each other through D-LSAs in the same way as 574 described above after they form a normal adjacency. 576 8.2. Adjacency between TTZ Edge and TTZ External Router 578 A TTZ edge router forms an adjacency with any TTZ external router to 579 which it is connected. 581 When the TTZ edge router synchronizes its link state database with 582 the TTZ external router, it sends the TTZ external router the 583 information about all the LSAs except for the LSAs belonging to the 584 TTZ that are hidden from any router outside of the TTZ. 586 At the end of the link state database synchronization, the TTZ edge 587 router originates its own router LSA for virtualizing the TTZ and 588 sends this LSA to its adjacent routers including the TTZ external 589 router. 591 9. Advertisement of LSAs 593 LSAs can be divided into a couple of classes according to their 594 Advertisements. The first class of LSAs is advertised within a TTZ. 596 The second is advertised through a TTZ. 598 9.1. Advertisement of LSAs within TTZ 600 Any LSA about a link state in a TTZ is advertised within the TTZ. It 601 is not advertised to any router outside of the TTZ. For example, a 602 router LSA generated for a router in a TTZ is advertised within the 603 TTZ. 605 Any network LSA generated for a broadcast or NBMA network in a TTZ is 606 advertised within the TTZ. 608 Any opaque LSA generated for a TTZ internal TE link is advertised 609 within the TTZ. 611 After migrating to TTZ, every edge router of a TTZ MUST NOT advertise 612 any LSA about a link state in the TTZ to any router outside of the 613 TTZ. 615 For any TTZ LSA originated by a router within the TTZ, every edge 616 router of the TTZ MUST NOT advertise it to any router outside of the 617 TTZ. 619 9.2. Advertisement of LSAs through TTZ 621 Any LSA about a link state outside of a TTZ received by an edge 622 router of the TTZ is advertised using the TTZ as transit. For 623 example, when an edge router of a TTZ receives an LSA from a router 624 outside of the TTZ, it floods it to its neighboring routers both 625 inside the TTZ and outside of the TTZ. This LSA may be any LSA such 626 as a router LSA that is advertised within an OSPF area. 628 The routers in the TTZ continue to flood the LSA. When another edge 629 router of the TTZ receives the LSA, it floods the LSA to its 630 neighboring routers both outside of the TTZ and inside the TTZ. 632 10. Computation of Routing Table 634 After a router migrates to TTZ, the computation of the routing table 635 on the router is the same as that described in RFC 2328 section 16 636 with one exception. The router in a TTZ ignores the router LSAs 637 generated by the TTZ edge routers for virtualizing the TTZ. This can 638 be achieved by adding a flag into every link stored in LSDB and 639 setting this flag to 1 in every link in these router LSAs, which 640 indicates that the link is unusable. It computes routes within the 641 TTZ topology and the topology outside of the TTZ without using any 642 unusable links. 644 11. Operations 646 11.1. Configuring TTZ 648 This section proposes some options for configuring a TTZ. 650 1. Configuring TTZ on Every Link in TTZ 652 If every link in a TTZ is configured with a same TTZ ID as a TTZ 653 link, the TTZ is determined. A router with some TTZ links and some 654 normal links is a TTZ edge router. A router with only TTZ links is a 655 TTZ internal router. 657 2. Configuring TTZ on Every Router in TTZ 659 A same TTZ ID is configured on every router in a TTZ, and on every 660 TTZ edge router's links connecting to the routers in the TTZ. 662 A router configured with the TTZ ID on some of its links is a TTZ 663 edge router. A router configured with the TTZ ID only is a TTZ 664 internal router. All the links on a TTZ internal router are TTZ 665 links. This option is simpler than the above one. 667 11.2. Smooth Migration to TTZ 669 For a group of routers and a number of links connecting the routers 670 in an area, making them transfer to work as a TTZ without any service 671 interruption takes a few of steps or stages. 673 At first, a user configures the TTZ feature on every router in the 674 TTZ. In this stage, a router does not originate its TTZ router LSA. 675 It will discover its TTZ neighbors. 677 Secondly, after configuring the TTZ, a user issues a CLI command on 678 one router in the TTZ, which triggers every router in the TTZ to 679 generate and advertise TTZ information among the routers in the TTZ. 680 When the router receives the command, it originates a TTZ control LSA 681 with T=1 (indicating TTZ information generation and advertisement for 682 migration). It also originates its TTZ router LSA, and advertises 683 the LSA to its TTZ neighbors. When another router in the TTZ 684 receives the LSA with T=1, it originates its TTZ router LSA. In this 685 stage, every router in the TTZ has dual roles. One is to function as 686 a normal router. The other is to generate and advertise TTZ 687 information. 689 Thirdly, a user checks whether a router in the TTZ is ready for 690 migration to TTZ. A router in the TTZ is ready after it has received 691 all the necessary information from all the routers in the TTZ. This 692 information may be displayed on a router through a CLI command. 694 And then a user activates the TTZ through using a CLI command such as 695 migrate to TTZ on one router in the TTZ. The router migrates to TTZ, 696 generates and advertises a TTZ control LSA with M = 1 (indicating 697 Migrating to TTZ) after it receives the command. After another 698 router in the TTZ receives the TTZ control LSA with M = 1, it also 699 migrates to TTZ. Thus, activating the TTZ on one TTZ router 700 propagates to every router in the TTZ, which migrates to TTZ. 702 For an edge router of the TTZ, migrating to work as a TTZ router 703 comprises generating a router LSA to virtualize the TTZ and flooding 704 this LSA to all its neighboring routers in two steps as described in 705 section 7. 707 In normal operations for migration to TTZ and rollback from TTZ, a 708 user issues a series of commands according to certain procedures. In 709 an abnormal case, for example two conflicting commands are issued on 710 two TTZ routers in a TTZ at the same time, a TTZ router issues an 711 error and logs the error when it detects a conflict. 713 A conflicting command may be detected on a router on which the 714 command is issued. Thus some abnormal cases may be prevented. When 715 a command for migration/rollback is issued on a router, the router 716 checks whether it is in a correct sequence of commands for migration/ 717 rollback through using the information it has. For migrating a part 718 of an area to a TTZ, the correct sequence of commands is as follows 719 in general: 721 1) configure TTZ on every router in the part of the area to be 722 migrated to TTZ; 724 2) configure on one router in the TTZ to trigger every router in the 725 TTZ to generate and advertise TTZ information for migration; and 727 3) configure on one router in the TTZ to trigger every router in the 728 TTZ to migrate to TTZ. 730 For rolling back from TTZ, it is similar. 732 After receiving a command on a router to migrate to TTZ, which is for 733 3), the router checks whether 2) is performed through checking if it 734 has received/originated TTZ LSAs. If it has not, it issues an error 735 to an operator (generation and advertisement of TTZ information for 736 migration to TTZ is not done yet) and rejects the command at this 737 time. 739 After a router receives a TTZ LSA with M=1 for 3) from another 740 router, it checks whether 2) is performed through checking if it has 741 received/originated TTZ LSAs. If it has not, it issues an error and 742 logs the error. The operation for migration will continue. 744 After receiving a command on a router to generate and advertise TTZ 745 information, which is for 2), the router checks whether 1) is 746 performed through checking if TTZ is configured on it. If it is not, 747 it issues an error to an operator (TTZ is not configured on it yet) 748 and rejects the command at this time. 750 11.3. Adding a Router into TTZ 752 When a non TTZ router (say R1) is connected via a P2P link to a TTZ 753 router (say T1) working as TTZ and there is a normal adjacency 754 between them over the link, a user can configure TTZ on two ends of 755 the link to add R1 into the TTZ to which T1 belongs. They discover 756 TTZ each other with the TTZ as described in section 8. 758 When a number of non TTZ routers are connected via a broadcast link 759 to a TTZ router (say T1) working as TTZ and there are normal 760 adjacencies among them, a user configures TTZ on the connection to 761 the link on every router to add the non TTZ routers into the TTZ to 762 which T1 belongs. The DR for the link "forms" TTZ adjacencies with 763 the other routers connected to the link if they all have the same TTZ 764 ID configured for the link. This is determined through the discovery 765 process described in section 8. 767 When a router (say R1) is connected via a P2P link to a TTZ router 768 (say T1) and there is not any adjacency between them over the link, a 769 user can configure TTZ on two ends of the link to add R1 into the TTZ 770 to which T1 belongs. R1 and T1 will form an adjacency in the same 771 way as described in section 8. 773 12. Prototype Implementation 775 12.1. What are Implemented and Tested 777 1. CLI Commands for TTZ 779 The CLIs implemented and tested include: 781 o the CLIs of the simpler option for configuring TTZ, and 783 o the CLIs for controlling migration to TTZ. 785 2. Extensions to OSPF Protocols for TTZ 786 All the extensions defined in section "Extensions to OSPF Protocols" 787 are implemented and tested except for rolling back from TTZ. The 788 testing results illustrate: 790 o A TTZ is virtualized to outside as its edge routers connected each 791 other. Any router outside of the TTZ sees the edge routers (as 792 normal routers) connecting each other and to some other routers. 794 o The link state information about the routers and links inside the 795 TTZ is contained within the TTZ. It is not advertised to any 796 router outside of the TTZ. 798 o TTZ is transparent. From a router inside a TTZ, it sees the 799 topology (link state) outside of the TTZ. From a router outside 800 of the TTZ, it sees the topology beyond the TTZ. The link state 801 information outside of the TTZ is advertised through the TTZ. 803 o TTZ is backward compatible. Any router outside of a TTZ does not 804 need to support or know TTZ. 806 3. Smooth Migration to TTZ 808 The procedures and related protocol extensions for smooth migration 809 to TTZ are implemented and tested. The testing results show: 811 o A part of an OSPF area is smoothly migrated to a TTZ without any 812 routing disruptions. The routes on every router are stable while 813 the part of the area is being migrated to the TTZ. 815 o Migration to TTZ is very easy to operate. 817 4. Add a Router to TTZ 819 Adding a router into TTZ is implemented and tested. The testing 820 results illustrate: 822 o A router can be easily added into a TTZ and becomes a TTZ router. 824 o The router added into the TTZ is not seen on any router outside of 825 the TTZ, but it is a part of the TTZ. 827 5. Leak TTZ Loopbacks Outside 829 Leaking loopback addresses in a TTZ to routers outside of the TTZ is 830 implemented and tested. The testing results illustrate: 832 o The loopback addresses inside the TTZ are advertised to the 833 routers outside of the TTZ. 835 o The loopback addresses are accessible from a router outside of the 836 TTZ. 838 12.2. Implementation Experience 840 The implementation of TTZ is relatively easy compared to other 841 features of OSPF. Re-using the existing OSPF code along with 842 additional simple logic does the work. A couple of engineers started 843 to work on implementing the TTZ from the middle of June, 2014 and 844 finished coding it just before IETF 90. After some testing and bug 845 fixes, it works as expected. 847 In our implementation, the link state information in a TTZ opaque LSA 848 is stored in the same link state database as the link state 849 information in a normal LSA. For each TTZ link in the TTZ opaque 850 LSA, there is an additional flag, which is used to differentiate 851 between a TTZ link and a Normal link. 853 Before migration to TTZ, every router in the TTZ computes its routing 854 table using the normal links. After migration to TTZ, every router 855 in the TTZ computes its routing table using the TTZ links and normal 856 links. In the case where both the TTZ link and the normal link 857 exist, the TTZ link is used. 859 13. Security Considerations 861 The mechanism described in this document does not raise any new 862 security issues for the OSPF protocols since a TTZ is enclosed in a 863 single area. 865 14. IANA Considerations 867 Under Registry Name: Opaque Link-State Advertisements (LSA) Option 868 Types [RFC5250], IANA is requested to assign a new Opaque type 869 registry value for Topology-Transparent Zone (TTZ) LSA as follows: 871 +====================+===============+=======================+ 872 | Registry Value | Opaque Type | reference | 873 +====================+===============+=======================+ 874 | IANA TBD | TTZ LSA | This document | 875 | (9 Suggested) | | | 876 +--------------------+---------------+-----------------------+ 878 IANA is requested to assign Types for new TLVs in the new TTZ LSA as 879 follows: 881 Type Name Allowed in 882 1 TTZ ID TLV TTZ LSA of LS Type 10 and 9 883 2 TTZ Router TLV TTZ LSA of LS Type 10 884 3 TTZ Options TLV TTZ LSA of LS Type 10 and 9 886 15. Contributors and Other Authors 888 1. Other Authors 890 Gregory Cauchie 891 FRANCE 892 Email: greg.cauchie@gmail.com 894 Anil Kumar S N 895 Huawei Technologies 896 Banglore 897 India 898 Email: anil.sn@huawei.com 900 Ning So 901 Tata Communications 902 2613 Fairbourne Cir. 903 Plano, TX 75082 904 USA 905 Email: ningso01@gmail.com 907 Lei Liu 908 Fujitsu 909 USA 910 Email: lliu@us.fujitsu.com 912 2. Contributors 914 Veerendranatha Reddy Vallem 915 Huawei Technologies 916 Banglore 917 India 918 Email: veerendranatharv@huawei.com 920 William McCall 921 Rightside Co. 922 Kirkland, WA 923 USA 924 will.mccall@rightside.co 926 16. Acknowledgement 928 The authors would like to thank Acee Lindem, Abhay Roy, Dean Cheng, 929 Russ White, Tony Przygienda, Wenhu Lu, Lin Han, Kiran Makhijani, 930 Padmadevi Pillay Esnault and Yang Yu for their valuable comments on 931 this draft. 933 17. References 935 17.1. Normative References 937 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 938 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ 939 RFC2119, March 1997, 940 . 942 [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, DOI 10.17487/ 943 RFC2328, April 1998, 944 . 946 [RFC5250] Berger, L., Bryskin, I., Zinin, A., and R. Coltun, "The 947 OSPF Opaque LSA Option", RFC 5250, DOI 10.17487/RFC5250, 948 July 2008, . 950 17.2. Informative References 952 [RFC5441] Vasseur, JP., Ed., Zhang, R., Bitar, N., and JL. Le Roux, 953 "A Backward-Recursive PCE-Based Computation (BRPC) 954 Procedure to Compute Shortest Constrained Inter-Domain 955 Traffic Engineering Label Switched Paths", RFC 5441, 956 DOI 10.17487/RFC5441, April 2009, 957 . 959 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 960 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 961 DOI 10.17487/RFC5440, March 2009, 962 . 964 Appendix A. Constants for LSA Advertisement 966 MaxLSAAdvTime: The maximum time for an LSA to be advertised to all 967 the routers in an area. The value of MaxLSAAdvTime is set to 0.1 968 second. 970 MaxLSAGenAdvTime: The maximum time for all TTZ router LSAs to be 971 generated by all TTZ edge routers and advertised to all the routers 972 in an area after a first TTZ router LSA is generated. The value of 973 MaxLSAGenAdvTime is set to 0.3 second. 975 Authors' Addresses 977 Huaimo Chen 978 Huawei Technologies 979 Boston, MA 980 USA 982 Email: huaimo.chen@huawei.com 984 Renwei Li 985 Huawei Technologies 986 2330 Central expressway 987 Santa Clara, CA 988 USA 990 Email: renwei.li@huawei.com 992 Alvaro Retana 993 Cisco Systems, Inc. 994 7025 Kit Creek Rd. 995 Raleigh, NC 27709 996 USA 998 Email: aretana@cisco.com 999 Yi Yang 1000 Cisco Systems, Inc. 1001 7025 Kit Creek Rd. 1002 Raleigh, NC 27709 1003 USA 1005 Email: yiya@cisco.com 1007 Vic Liu 1008 China Mobile 1009 No.32 Xuanwumen West Street, Xicheng District 1010 Beijing, 100053 1011 China 1013 Email: liuzhiheng@chinamobile.com 1015 Mehmet Toy 1016 Comcast 1017 1800 Bishops Gate Blvd. 1018 Mount Laurel, NJ 08054 1019 USA 1021 Email: mehmet_toy@cable.comcast.com