idnits 2.17.1 draft-ietf-ospf-ttz-06.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 8, 2017) is 2665 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Missing Reference: 'T75' is mentioned on line 209, but not defined == Missing Reference: 'T71' is mentioned on line 211, but not defined == Missing Reference: 'T79' is mentioned on line 211, but not defined == Missing Reference: 'T73' is mentioned on line 212, but not defined == Unused Reference: 'RFC2119' is defined on line 1040, but no explicit reference was found in the text == Unused Reference: 'RFC4940' is defined on line 1058, but no explicit reference was found in the text == Unused Reference: 'RFC3630' is defined on line 1064, but no explicit reference was found in the text == Unused Reference: 'RFC5440' is defined on line 1069, 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: July 12, 2017 A. Retana 6 Cisco Systems, Inc. 7 Y. Yang 8 Sockrate 9 Z. Liu 10 China Mobile 11 January 8, 2017 13 OSPF Topology-Transparent Zone 14 draft-ietf-ospf-ttz-06.txt 16 Abstract 18 This document presents a topology-transparent zone (TTZ) in an OSPF 19 area. A topology-transparent zone comprises a group of routers and a 20 number of links connecting these routers. Any router outside of the 21 zone is not aware of the zone. A TTZ hides the internal topology of 22 the TTZ from the outside. It does not directly advertise any 23 internal information about the TTZ to a router outside of the TTZ. 24 The information about the links and routers such as a link down 25 inside the TTZ is not advertised to any router outside of the TTZ. 27 Status of this Memo 29 This Internet-Draft is submitted to IETF in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at http://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on July 12, 2017. 44 Copyright Notice 46 Copyright (c) 2017 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (http://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 62 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 63 3. Conventions Used in This Document . . . . . . . . . . . . . . 5 64 4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 5 65 5. Topology-Transparent Zone . . . . . . . . . . . . . . . . . . 5 66 5.1. Overview of Topology-Transparent Zone . . . . . . . . . . 5 67 5.2. TTZ Example . . . . . . . . . . . . . . . . . . . . . . . 6 68 6. Extensions to OSPF Protocols . . . . . . . . . . . . . . . . . 8 69 6.1. General Format of TTZ LSA . . . . . . . . . . . . . . . . 8 70 6.2. TTZ ID TLV . . . . . . . . . . . . . . . . . . . . . . . . 9 71 6.3. TTZ Router TLV . . . . . . . . . . . . . . . . . . . . . . 9 72 6.4. TTZ Options TLV . . . . . . . . . . . . . . . . . . . . . 10 73 6.5. Link Scope TTZ LSA . . . . . . . . . . . . . . . . . . . . 11 74 7. Constructing LSAs for TTZ . . . . . . . . . . . . . . . . . . 12 75 7.1. TTZ Migration Process . . . . . . . . . . . . . . . . . . 13 76 8. Establishing Adjacencies . . . . . . . . . . . . . . . . . . . 14 77 8.1. Discovery of TTZ Neighbors . . . . . . . . . . . . . . . . 14 78 8.2. Adjacency between TTZ Edge and TTZ External Router . . . . 17 79 9. Advertisement of LSAs . . . . . . . . . . . . . . . . . . . . 17 80 9.1. Advertisement of LSAs within TTZ . . . . . . . . . . . . . 17 81 9.2. Advertisement of LSAs through TTZ . . . . . . . . . . . . 18 82 10. Computation of Routing Table . . . . . . . . . . . . . . . . . 18 83 11. Operations . . . . . . . . . . . . . . . . . . . . . . . . . . 18 84 11.1. Configuring TTZ . . . . . . . . . . . . . . . . . . . . . 18 85 11.2. Migration to TTZ . . . . . . . . . . . . . . . . . . . . . 19 86 11.3. Adding a Router into TTZ . . . . . . . . . . . . . . . . . 21 87 12. Manageability Considerations . . . . . . . . . . . . . . . . . 22 88 13. Security Considerations . . . . . . . . . . . . . . . . . . . 22 89 14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 90 15. Contributors and Other Authors . . . . . . . . . . . . . . . . 23 91 16. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 24 92 17. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24 93 17.1. Normative References . . . . . . . . . . . . . . . . . . . 24 94 17.2. Informative References . . . . . . . . . . . . . . . . . . 25 95 Appendix A. Prototype Implementation . . . . . . . . . . . . . . 25 96 A.1. What are Implemented and Tested . . . . . . . . . . . . . 25 97 A.2. Implementation Experience . . . . . . . . . . . . . . . . 26 98 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 27 100 1. Introduction 102 Networks expand as business grows and traffic increases. For 103 scalability and manageability, a hierarchical network architecture is 104 usually deployed in OSPF networks by re-grouping routers into areas, 105 which is often challenging and causes service interruptions. 107 At first, reorganizing a network from one area into multiple areas or 108 from a number of existing areas into even more areas is a very 109 challenging and time consuming task since it involves significant 110 network architecture changes. Considering the one area case, 111 originally the network has only one area, which is the backbone. 112 This original backbone area will be reorganized into a new backbone 113 and a number of non-backbone areas. In general, each of the non- 114 backbone areas is connected to the new backbone area through the Area 115 Border Routers (ABRs) between the non-backbone and the backbone area 116 (refer to RFC 2328 section 3). It demands careful re-designing of 117 network topology in advance to guarantee backbone area continuity and 118 non-backbone area reachability, and requires significant 119 modifications of configurations on many routers to ensure consistent 120 routing. 122 Secondly, the services carried by the network may be interrupted 123 while the network is being reorganized from one area into multiple 124 areas or from a number of existing areas into even more areas since 125 every OSPF interface with an area change is going down with its old 126 area and then up with a new area. 128 This document presents a topology-transparent zone (TTZ) in an OSPF 129 area and describes extensions to OSPFv2 for supporting the topology- 130 transparent zone, which is scalable and resolves the issues above. A 131 TTZ hides the internal topology of the TTZ from the outside. It does 132 not directly advertise any internal information about the TTZ to a 133 router outside of the TTZ. 135 2. Terminology 137 TTZ link or TTZ internal link: A link whose ends are within a single 138 TTZ. 140 TTZ internal router: A router whose links are TTZ internal links 141 inside a single TTZ. 143 TTZ external router: A router outside of a TTZ that has no TTZ 144 internal links. 146 TTZ external link: A link not configured to be within a TTZ. 148 TTZ edge router: A router is called TTZ edge router if some, but not 149 all, of its links are within a single TTZ. 151 TTZ router: A TTZ internal router or a TTZ edge router. 153 3. Conventions Used in This Document 155 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 156 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 157 document are to be interpreted as described in RFC 2119. 159 4. Requirements 161 A Topology-Transparent Zone may be deployed to resolve some critical 162 issues in existing networks and future networks. The requirements 163 for a TTZ are listed as follows: 165 o Routers outside a TTZ MUST NOT require any changes to operate with 166 the TTZ. 168 o A TTZ MUST be enclosed in a single area. 170 o A TTZ MUST hide the topology of the TTZ from any router outside of 171 the TTZ. 173 5. Topology-Transparent Zone 175 5.1. Overview of Topology-Transparent Zone 177 A Topology-Transparent Zone is identified by a TTZ identifier (ID), 178 and it consists of a group of routers and a number of links 179 connecting the routers. A TTZ MUST be contained within an OSPF area. 181 A TTZ ID is a 32-bit number that is unique for identifying a TTZ. 182 The TTZ ID SHOULD NOT be 0, to avoid confusion with Area 0. The same 183 TTZ ID MUST be configured on the routers and/or links that make up a 184 specific instance of a TTZ. All TTZ instances in an OSPF area MUST 185 be unique. 187 In addition to having similar functions of an OSPF area, an OSPF TTZ 188 makes some improvements on an OSPF area, which include: 190 o An OSPF TTZ represents a set of TTZ edge routers, connected by a 191 full mesh of virtual connections between them. 193 o Non-TTZ link state information is handled as normal. TTZ Routers 194 receive the link state information about the topology outside of 195 the TTZ, store the information, and flood the information through 196 the TTZ to the routers outside of the TTZ. 198 5.2. TTZ Example 200 The figure below shows an area containing a TTZ: TTZ 600. 202 TTZ 600 ---- TTZ Internal Link 203 \ ==== Normal Link 204 Area X \ ^~^~^~^~^~^~^~^~^~^~^~^~ 205 ( ) 206 ===[R15]========(==[T61]----[T81]---[T63]==)======[R29]=== 207 || ( | \ / | ) || 208 || ( | \ / | ) || 209 || ( [T75] \ / | ) || 210 || ( | ___\ / | ) || 211 || ( | / [T71] [T79] ) || 212 || ( | [T73] / \ | ) || 213 || ( | / \ | ) || 214 || ( | / \ | ) || 215 || ( | / \ | ) || 216 ===[R17]========(==[T65]---[T77]----[T67]==)======[R31]=== 217 \\ (// \\) // 218 || //v~v~v~v~v~v~v~v~v~v~v~\\ || 219 || // \\ || 220 || // \\ || 221 \\ // \\ // 222 ======[R23]==============================[R25]===== 223 // \\ 224 // \\ 226 All the routers in the figure are in area X. Routers with T (i.e., 227 T61, T63, T65, T67, T71, T73, T75, T77, T79 and T81) are also in TTZ 228 600, which contains the TTZ internal links connecting them. To 229 create a TTZ, we need configure it (refer to section 11). 231 There are two types of routers in a TTZ: TTZ internal and TTZ edge 232 routers. TTZ 600 has four TTZ edge routers T61, T63, T65 and T67. 233 Each of them has at least one adjacent router in TTZ 600 and one 234 adjacent router outside of TTZ 600. For instance, router T61 is a 235 TTZ edge router since it has an adjacent router R15 outside of TTZ 236 600 and three adjacent routers T75, T71 and T81 in TTZ 600. 238 In addition, TTZ 600 comprises six TTZ internal routers T71, T73, 239 T75, T77, T79 and T81. Each of them has all its adjacent routers in 240 TTZ 600. For instance, router T71 is a TTZ internal router since its 241 adjacent routers T61, T63, T65, T67 and T73 are all in TTZ 600. It 242 should be noted that by definition, a TTZ internal router cannot also 243 be an ABR. 245 A TTZ hides the internal topology of the TTZ from the outside. It 246 does not directly advertise any internal information about the TTZ to 247 a router outside of the TTZ. 249 For instance, TTZ 600 does not send the information about TTZ 250 internal router T71 to any router outside of TTZ 600; it does not 251 send the information about the link between TTZ router T61 and T71 to 252 any router outside of TTZ 600. 254 The figure below illustrates area X from the point of view on a 255 router outside of TTZ 600 after TTZ 600 is created. 257 Area X ==== Normal Link 259 ===[R15]===========[T61]=========[T63]=========[R29]=== 260 || || \\ // || || 261 || || \\ // || || 262 || || \\ // || || 263 || || \\// || || 264 || || //\ || || 265 || || // \\ || || 266 || || // \\ || || 267 || || // \\ || || 268 || || // \\ || || 269 ===[R17]===========[T65]=========[T67]=========[R31]=== 270 \\ // \\ // 271 || // \\ || 272 || // \\ || 273 || // \\ || 274 \\ // \\ // 275 ======[R23]============================[R25]===== 276 // \\ 277 // \\ 279 From a router outside of the TTZ, a TTZ is seen as the TTZ edge 280 routers connected each other. For instance, router R15 sees that 281 T61, T63, T65 and T67 are connected each other. 283 In addition, a router outside of the TTZ sees TTZ edge routers having 284 normal connections to the routers outside of the TTZ. For example, 285 router R15 sees that T61, T63, T65 and T67 have the normal 286 connections to R15, R29, R17 and R23, R25 and R31 respectively. 288 6. Extensions to OSPF Protocols 290 The link state information about a TTZ includes router LSAs, which 291 can be contained and advertised in opaque LSAs [RFC5250] within the 292 TTZ. Some control information regarding a TTZ can also be contained 293 and advertised in opaque LSAs within the TTZ. These opaque LSAs are 294 called TTZ opaque LSAs or TTZ LSAs for short. 296 6.1. General Format of TTZ LSA 298 The following is the general format of a TTZ LSA. It has an LS Type 299 = 10/9 and TTZ-LSA-Type, and contains a number of TLVs. 301 0 1 2 3 302 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 303 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 304 | LS age | Options | LS Type = 10/9| 305 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 306 |TTZ-LSA-Type(9)| Instance ID | 307 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 308 | Advertising Router | 309 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 310 | LS Sequence Number | 311 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 312 | LS checksum | Length | 313 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 314 | | 315 ~ TLVs ~ 316 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 318 There are three TTZ LSAs of LS Type 10 defined: 320 o TTZ Router LSA: a TTZ LSA containing a TTZ ID TLV and a TTZ Router 321 TLV. 323 o TTZ Control LSA: a TTZ LSA containing a TTZ ID TLV and a TTZ 324 Options TLV. 326 o TTZ Indication LSA: a TTZ LSA containing a TTZ ID TLV with E = 0, 327 which indicates that the router originating this LSA is a TTZ 328 internal router. 330 There is one TTZ LSA of LS Type 9: 332 o TTZ Discovery LSA: a TTZ LSA containing a TTZ ID TLV and a 333 optional TTZ Options TLV. 335 6.2. TTZ ID TLV 337 A TTZ ID TLV has the following format. It contains a TTZ ID (refer 338 to section 5.1) and some flags. It has the TLV-Length of 8 octets. 340 0 1 2 3 341 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 342 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 343 | TTZ-ID-TLV-Type (1) | TLV-Length (8) | 344 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 345 | TTZ ID | 346 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 347 | Reserved (MUST be zero) |E|Z| 348 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 349 E = 1: Indicating a router is a TTZ Edge router 350 Z = 1: Indicating a router has migrated to TTZ 352 When a TTZ router originates a TTZ LSA containing a TTZ ID TLV, it 353 MUST set flag E to 1 in the TTZ ID TLV if it is a TTZ edge router, 354 and to 0 if it is a TTZ internal router. It MUST set flag Z to 1 355 after it has migrated to TTZ, and to 0 before it migrates to TTZ or 356 after it rolls back from TTZ (refer to section 6.4). 358 6.3. TTZ Router TLV 360 The format of a TTZ Router TLV is as follows. It has the same 361 content as a standard OSPF Router LSA (RFC 2328) with the following 362 modifications. 364 0 1 2 3 365 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 366 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 367 | TTZ-RT-TLV-Type (2) | TLV-Length | 368 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 369 | 0 |V|E|B| 0 | # links | 370 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 371 | Link ID | 372 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 373 | Link Data | 374 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 375 | Type | # TOS | metric | 376 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 377 ~ ... ~ 379 For a router link, the existing eight bit Link Type field for a 380 router link is split into two fields as follows: 382 0 1 2 3 4 5 6 7 383 +---+---+---+---+---+---+---+---+ 384 | I | Type-1 | 385 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 386 I bit flag: 387 1: Router link is a TTZ internal link. 388 0: Router link is a TTZ external link. 389 Type-1: The kind of the link. The values for Type-1 are the same 390 as those for Type defined in RFC 2328 section 12.4.1. 392 The Link Type field is 8 bits, the values 128-255 of the field are 393 reserved (refer to RFC 4940), which allows the reuse of the bottom 7 394 bits to indicate the type of a TTZ internal or external link. 396 6.4. TTZ Options TLV 398 The format of a TTZ Options TLV is as follows. 400 0 1 2 3 401 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 402 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 403 | TTZ-OP-TLV-Type (3) | TLV-Length | 404 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 405 | OP | Reserved (MUST be zero) | 406 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 407 OP Value Meaning (Operation) 408 0x001 (T): Advertising TTZ Topology Information for Migration 409 0x010 (M): Migrating to TTZ 410 0x011 (N): Advertising Normal Topology Information for Rollback 411 0x100 (R): Rolling back from TTZ 413 A OP field of three bits is defined. It may have a value of 0x001 414 for T, 0x010 for M, 0x011 for N, or 0x100 for R, which indicates one 415 of the four operations above. When any of the other values is 416 received, it is ignored. 418 Advertising TTZ Topology Information for Migration (T): After a user 419 configures a TTZ router to advertise TTZ topology information, 420 advertising TTZ topology information for migration is triggered. The 421 TTZ router originates a TTZ Control LSA having a TTZ Options TLV with 422 OP for T. It also originates its other TTZ LSA such as a TTZ router 423 LSA or TTZ indication LSA. When another TTZ router receives the LSA 424 with OP for T, it originates its TTZ LSA as described in section 7. 426 Migrating to TTZ (M): After a user configures a TTZ router to migrate 427 to TTZ, migrating to TTZ is triggered. The TTZ router originates a 428 TTZ Control LSA having a TTZ Options TLV with OP for M and migrates 429 to TTZ. When another TTZ router receives the LSA with OP for M, it 430 also migrates to TTZ. When a router migrates to TTZ, it computes 431 routes using the TTZ topology and the topology outside of the TTZ. 432 For a TTZ internal router, it also updates its TTZ indication LSA 433 with Z = 1. For a TTZ edge router, it updates its TTZ router LSA 434 with Z = 1 and its router LSA for virtualizing the TTZ. A TTZ router 435 determines whether it is internal or edge based on configurations 436 (refer to section 11.1). 438 Advertising Normal Topology Information for Rollback (N): After a 439 user configures a TTZ router to advertise normal topology 440 information, advertising Normal topology information for rollback is 441 triggered. The TTZ router originates a TTZ Control LSA having a TTZ 442 Options TLV with OP for N. It also advertises its normal LSAs such as 443 its normal router LSA and stops advertising its other TTZ LSAs. When 444 another TTZ router receives the LSA with OP for N, it forwards the 445 LSA, advertises its normal LSAs, and stops advertising its TTZ LSAs. 447 Rolling back from TTZ (R): After a user configures a TTZ router to 448 roll back from TTZ, rolling back from TTZ is triggered. The TTZ 449 router originates a TTZ Control LSA having a TTZ Options TLV with OP 450 for R and rolls back from TTZ. When another TTZ router receives the 451 LSA with OP for R, it also rolls back from TTZ. 453 After a TTZ router originates a TTZ control LSA in response to a 454 configuration described above to control TTZ, it flushes the TTZ 455 control LSA if OP in the LSA is set for the configuration and the 456 configuration is removed. 458 6.5. Link Scope TTZ LSA 460 A TTZ LSA of LS Type 9 has the following format. 462 0 1 2 3 463 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 464 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 465 | LS age | Options | LS Type = 9 | 466 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 467 |TTZ-LSA-Type(9)| Instance ID | 468 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 469 | Advertising Router | 470 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 471 | LS Sequence Number | 472 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 473 | LS checksum | Length | 474 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 475 | | 476 ~ TTZ ID TLV ~ 477 +---------------------------------------------------------------+ 478 | | 479 ~ (TTZ Options TLV) ~ 480 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 482 It contains a mandatory TTZ ID TLV, which may be followed by a 483 optional TTZ Options TLV. It is used to discover a TTZ neighbor. 485 7. Constructing LSAs for TTZ 487 For a TTZ, its topology is represented by the LSAs generated by its 488 TTZ routers for the link states in the TTZ, which include TTZ router 489 LSAs by TTZ edge routers, TTZ indication LSAs by TTZ internal 490 routers, normal router LSAs and network LSAs. The TTZ router LSAs 491 and TTZ indication LSAs MUST be generated after advertising TTZ 492 topology information for migration is triggered. 494 A TTZ edge router generates a TTZ router LSA that has a TTZ ID TLV 495 and a TTZ Router TLV. The former includes the ID of the TTZ to which 496 the router belongs and flag E set to 1, which indicates the 497 originator of the LSA is a TTZ Edge router. The TTZ router TLV 498 contains the TTZ external links to the routers outside of the TTZ and 499 the TTZ internal links to the routers inside the TTZ as described in 500 section 6. The TTZ router LSA containing this TLV is constructed and 501 advertised within the TTZ. 503 A TTZ internal router generates a TTZ indication LSA that has a TTZ 504 ID TLV containing the ID of the TTZ to which the router belongs and 505 flag E set to 0, which indicates the originator of the LSA is a TTZ 506 internal router. For a TTZ internal router, its regular Router LSA 507 is still generated. If a TTZ router is a Designated Router (DR), it 508 originates its regular network LSA. 510 After receiving a trigger to migrate to TTZ such as a TTZ control LSA 511 with OP for M, a TTZ edge router MUST originate its normal router LSA 512 for virtualizing a TTZ, which comprises three groups of links in 513 general. 515 The first group are the router links connecting the TTZ external 516 routers. These router links are normal router links. There is a 517 router link for every adjacency between this TTZ edge router and a 518 TTZ external router. 520 The second group are the "virtual" router links connecting to the 521 other TTZ edge routers. For each of the other TTZ edge routers, 522 there is a corresponding point-to-point router link to it from this 523 TTZ edge router. The cost of the link is the cost of the shortest 524 path from this TTZ edge router to the other TTZ edge router within 525 the TTZ. 527 In addition, the LSA may contain a third group of links, which are 528 the stub links for the loopback addresses inside the TTZ to be 529 accessed by nodes outside of the TTZ. 531 7.1. TTZ Migration Process 533 After migration to TTZ is triggered, a TTZ router computes routes 534 using its TTZ topology (refer to section 10) and a TTZ edge router 535 originates its normal router LSA for virtualizing the TTZ in two 536 steps: 538 Step 1: The router updates its router LSA by adding a point-to-point 539 link to each of the other known edge routers in the TTZ, and also 540 by adding the stub links for the loopback addresses in the TTZ to 541 be accessed outside of the TTZ according to configuration policies 542 of operators. 544 Step 2: After MaxLSAGenAdvTime (0.3 s) or sr-time + MaxLSAAdvTime 545 (0.1 s), it removes the TTZ links from its router LSA, where sr- 546 time is the time from updating its router LSA to receiving the ack 547 for its router LSA and receiving the updated router LSAs 548 originated by the other TTZ edge routers. In other words, it 549 removes the TTZ links from its router LSA after sending its 550 updated router LSA and receiving the updated router LSAs 551 originated by the other TTZ edge routers for MaxLSAAdvTime or 552 after sending its updated router LSA for MaxLSAGenAdvTime. 553 MaxLSAAdvTime and MaxLSAGenAdvTime SHOULD be set to 100ms and 554 300ms respectively, but MAY be configurable. The former is the 555 maximum time for an LSA to be advertised to all the routers in an 556 area. The latter is the maximum time for all TTZ router LSAs to 557 be generated by all TTZ edge routers and advertised to all the 558 routers in an area after a first TTZ router LSA is generated. 560 This is to avoid a possible short route down or change in a TTZ 561 external router while the TTZ is being virtualized. If each TTZ edge 562 router originates its router LSA by adding its point-to-point links 563 to the other TTZ edge routers and removing its TTZ links in one step, 564 a route taking a path through the TTZ in the TTZ external router may 565 be down or changed before all the router LSAs generated by the TTZ 566 edge routers reach the TTZ external router. When the TTZ external 567 router computes routes with some router LSAs originated by the TTZ 568 edge routers, bi-directional check for some of the point-to-point 569 links will fail. Thus the route taking the path through the shortest 570 path for the point-to-point link failing the bi-directional check 571 will be down or changed. 573 To roll back from a TTZ smoothly after receiving a trigger to roll 574 back from TTZ, a TTZ edge router MUST originate its normal router LSA 575 in the above two steps in a reverse way. 577 Step 1: Initially, it updates its normal router LSA by adding the 578 normal links for the links configured as TTZ links into the LSA. 580 Step 2: It then removes the point-to-point links to the other edge 581 routers of the TTZ for virtualizing the TTZ and the stub links for 582 the loopback addresses from its updated router LSA after sending 583 its updated router LSA and receiving the updated router LSAs 584 originated by the other TTZ edge routers for MaxLSAAdvTime or 585 after sending its updated router LSA for MaxLSAGenAdvTime. 587 8. Establishing Adjacencies 589 This section describes the TTZ adjacencies. 591 8.1. Discovery of TTZ Neighbors 593 For two routers A and B connected by a P2P link and having a normal 594 adjacency, they TTZ discover each other through a TTZ LSA of LS Type 595 9 with a TTZ ID TLV. We call this LSA D-LSA for short. 597 If two ends of the link have different TTZ IDs or only one end is 598 configured with TTZ ID, TTZ adjacency over the link MUST NOT be 599 "formed". 601 If two ends of the link have the same TTZ ID and Z flag value, A and 602 B are TTZ neighbors. The following is a sequence of events related 603 to TTZ for this case. 605 A B 606 Configure TTZ Configure TTZ 607 D-LSA (TTZ-ID=100) 608 ----------------------> Same TTZ ID and Z 609 A is B's TTZ Neighbor 610 D-LSA (TTZ-ID=100) 611 Same TTZ ID and Z <---------------------- 612 B is A's TTZ Neighbor 614 A sends B a D-LSA with TTZ-ID after the TTZ is configured on it. B 615 sends A a D-LSA with TTZ-ID after the TTZ is configured on it. 617 When A receives the D-LSA from B and determines they have the same 618 TTZ ID and Z flag value, B is A's TTZ neighbor. A also sends B all 619 the TTZ LSAs it has and originates its TTZ LSA when one of the 620 following conditions is met. 622 o Z = 0 and there is a TTZ LSA with OP for T. 624 o Z = 1. 626 B is symmetric to A and acts similarly to A. 628 If two ends of the link have the same TTZ ID but Z flags are 629 different, a TTZ adjacency over the link MUST be "formed" in the 630 following steps. Suppose that A has migrated to TTZ and B has not 631 (i.e., flag Z in A's D-LSA is 1 and flag Z in B's D-LSA is 0). 633 A B 634 Configure TTZ Configure TTZ 635 D-LSA(TTZ-ID=100,Z=1) 636 ----------------------> Same TTZ ID, but 637 different Z 638 A is B's TTZ Neighbor 639 D-LSA(TTZ-ID=100,Z=0) 640 Same TTZ ID, but <---------------------- 641 different Z 642 B is A's TTZ Neighbor 643 TTZ LSAs 644 -----------------------> 645 TTZ LSAs 646 <----------------------- 648 When A receives the D-LSA from B and determines they have the same 649 TTZ ID but its Z = 1 and B's Z = 0, A sends B all the TTZ LSAs it has 650 and triggers B to migrate to TTZ. A updates and sends B its D-LSA by 651 adding an TTZ Options TLV with OP for M after sending B all the TTZ 652 LSAs. 654 D-LSA(TTZ-ID=100,OP=M) 655 Add TTZ Options -----------------------> Migrate to TTZ 656 TLV with OP for M 657 D-LSA(TTZ-ID=100,Z=1) Migrated to TTZ 658 <----------------------- Set Z=1 660 D-LSA(TTZ-ID=100,Z=1) 661 Remove -----------------------> 662 TTZ Options TLV 664 When B receives the D-LSA from A and determines they have the same 665 TTZ ID but its Z = 0 and A's Z = 1, B sends A all the TTZ LSAs it 666 has. 668 When B receives the D-LSA from A with OP for M, it starts to migrate 669 to TTZ. B updates and advertises its LSAs as needed. 671 After receiving B's D-LSA with Z = 1, A updates and sends B its D-LSA 672 by removing the TTZ Options TLV. It also updates and advertises its 673 LSAs as needed. 675 For a number of routers connected through a broadcast link and having 676 normal adjacencies among them, they also TTZ discover each other 677 through D-LSAs. The DR (Designated Router) for the link MUST "form" 678 TTZ adjacencies with the other routers if all the routers attached to 679 the link have the same TTZ ID configured on the connections to the 680 link. Otherwise, the DR MUST NOT "form" any TTZ adjacency with any 681 router attached to the link. 683 For a number of routers connected through a broadcast link and having 684 TTZ adjacencies among them, if a mis-configured router is introduced 685 on the broadcast link, the DR for the link MUST NOT "form" any TTZ 686 adjacency with this mis-configured router. 688 For routers connected via a link without any adjacency among them, 689 they TTZ discover each other through D-LSAs in the same way as 690 described above after they form a normal adjacency. 692 A TTZ adjacency over a link MUST be removed when one of the following 693 events happens. 695 o TTZ ID on one end of the link is changed to a different one. 697 o TTZ ID on one end of the link is removed. 699 o The D-LSA is not received after the D-LSA-MAX-RETRANSMIT-TIME or 700 is explicitly flushed. The D-LSA-MAX-RETRANSMIT-TIME SHOULD be 701 set to 60 minutes, but MAY be configurable. 703 o Normal adjacency over the link is down. 705 When the TTZ ID on one end of the link is removed, the corresponding 706 D-LSA is flushed. 708 8.2. Adjacency between TTZ Edge and TTZ External Router 710 A TTZ edge router forms an adjacency with any TTZ external router to 711 which it is connected. 713 When the TTZ edge router synchronizes its link state database with 714 the TTZ external router, it sends the TTZ external router the 715 information about all the LSAs except for the LSAs belonging to the 716 TTZ that are hidden from any router outside of the TTZ. 718 At the end of the link state database synchronization, the TTZ edge 719 router originates its own router LSA for virtualizing the TTZ and 720 sends this LSA to its adjacent routers including the TTZ external 721 router. 723 9. Advertisement of LSAs 725 LSAs can be divided into a couple of classes according to their 726 Advertisements. The first class of LSAs is advertised within a TTZ. 727 The second is advertised through a TTZ. 729 9.1. Advertisement of LSAs within TTZ 731 Any LSA about a link state in a TTZ is advertised only within the 732 TTZ. It is not advertised to any router outside of the TTZ. For 733 example, a router LSA generated for a TTZ internal router is 734 advertised only within the TTZ. 736 Any network LSA generated for a broadcast or NBMA network in a TTZ is 737 advertised only within the TTZ. It is not advertised outside of the 738 TTZ. 740 Any opaque LSA generated for a TTZ internal TE link is advertised 741 only within the TTZ. 743 After migrating to TTZ, every edge router of a TTZ MUST NOT advertise 744 any LSA about a link state in the TTZ to any router outside of the 745 TTZ. The TTZ edge router determines whether an LSA is about a TTZ 746 internal link state by checking if the advertising router of the LSA 747 is a TTZ internal router (i.e., there is a TTZ indication LSA 748 generated by the TTZ internal router and having the same advertising 749 router). 751 For any TTZ LSA originated by a router within the TTZ, every edge 752 router of the TTZ MUST NOT advertise it to any router outside of the 753 TTZ. 755 9.2. Advertisement of LSAs through TTZ 757 Any LSA about a link state outside of a TTZ received by an edge 758 router of the TTZ is advertised using the TTZ as transit. For 759 example, when an edge router of a TTZ receives an LSA from a router 760 outside of the TTZ, it floods it to its neighboring routers both 761 inside the TTZ and outside of the TTZ. This LSA may be any LSA such 762 as a router LSA that is advertised within an OSPF area. 764 The routers in the TTZ continue to flood the LSA. When another edge 765 router of the TTZ receives the LSA, it floods the LSA to its 766 neighboring routers both outside of the TTZ and inside the TTZ. 768 10. Computation of Routing Table 770 After a router migrates to TTZ, the computation of the routing table 771 on the router is the same as that described in RFC 2328 section 16 772 with one exception. The router in a TTZ ignores the router LSAs 773 generated by the TTZ edge routers for virtualizing the TTZ. It 774 computes routes using the TTZ router LSAs and the regular LSAs, 775 excluding the router LSAs for virtualizing the TTZ. That is that it 776 computes routes using the TTZ topology and the topology outside of 777 the TTZ, excluding the links for virtualizing the TTZ. 779 11. Operations 781 11.1. Configuring TTZ 783 This section proposes some options for configuring a TTZ. 785 1. Configuring TTZ on Every Link in TTZ 787 If every link in a TTZ is configured with a same TTZ ID as a TTZ 788 link, the TTZ is determined. A router with some links in a TTZ and 789 some links not in this TTZ is a TTZ edge router. A router with all 790 its links in a TTZ is a TTZ internal router. 792 2. Configuring TTZ on Routers in TTZ 794 A same TTZ ID is configured on every TTZ internal router in a TTZ, 795 and on every TTZ edge router's links connecting to the routers in the 796 TTZ. 798 A router configured with the TTZ ID on some of its links is a TTZ 799 edge router. A router configured with the TTZ ID only is a TTZ 800 internal router. All the links on a TTZ internal router are TTZ 801 links. This option is simpler than option 1 above. 803 For a TTZ edge router X with different TTZ IDs on its different 804 links, router X connects two or more different TTZs. In this case, 805 router X originates its router LSA for virtualizing the TTZs. This 806 LSA includes the normal links connecting to routers outside of these 807 TTZs and the virtual links to the other edge routers of each of these 808 TTZs. Router X also originates its TTZ router LSA for each of TTZs. 809 The TTZ router LSA for TTZ N includes the links to routers outside of 810 these TTZs, the virtual links to the other edge routers of the other 811 TTZs, and the TTZ links to the routers in TTZ N. 813 11.2. Migration to TTZ 815 For a group of routers and a number of links connecting the routers 816 in an area, making them transfer to work as a TTZ without any service 817 interruption takes a few of steps or stages. 819 At first, a user configures the TTZ feature on every router in the 820 TTZ. In this stage, a router does not originate or advertise its TTZ 821 topology information. It will discover its TTZ neighbors. 823 Secondly, after configuring the TTZ, a user issues a configuration on 824 one router in the TTZ, which triggers every router in the TTZ to 825 generate and advertise TTZ information among the routers in the TTZ. 826 When the router receives the configuration, it originates a TTZ 827 control LSA with OP for T (indicating TTZ information generation and 828 advertisement for migration). It also originates its TTZ LSA such as 829 TTZ router LSA or TTZ indication LSA, and advertises the LSA to its 830 TTZ neighbors. When another router in the TTZ receives the LSA with 831 OP for T, it originates its TTZ LSA. In this stage, every router in 832 the TTZ has dual roles. One is to function as a normal router. The 833 other is to generate and advertise TTZ information. 835 Thirdly, a user checks whether a router in the TTZ is ready for 836 migration to TTZ. A router in the TTZ is ready after it has received 837 all the TTZ LSAs including TTZ router LSAs from TTZ edge routers and 838 TTZ indication LSAs from TTZ internal routers. This information may 839 be displayed on a router through a configuration. 841 And then a user activates the TTZ through using a configuration such 842 as migrate to TTZ on one router in the TTZ. The router migrates to 843 TTZ, generates and advertises a TTZ control LSA with OP for M 844 (indicating Migrating to TTZ) after it receives the configuration. 845 After another router in the TTZ receives the TTZ control LSA with OP 846 for M, it also migrates to TTZ. Thus, activating the TTZ on one TTZ 847 router propagates to every router in the TTZ, which migrates to TTZ. 849 For an edge router of the TTZ, migrating to work as a TTZ router 850 comprises generating a router LSA to virtualize the TTZ and flooding 851 this LSA to all its neighboring routers in two steps as described in 852 section 7. 854 In normal operations for migration to TTZ and rollback from TTZ, a 855 user issues a series of configurations according to certain 856 procedures. In an abnormal case, for example two conflicting 857 configurations are issued on two TTZ routers in a TTZ at the same 858 time, a TTZ router issues an error and logs the error when it detects 859 a conflict. 861 A conflicting configuration may be detected on a router on which the 862 configuration is issued. Thus some abnormal cases may be prevented. 863 When a configuration for migration/rollback is issued on a router, 864 the router checks whether it is in a correct sequence of 865 configurations for migration/rollback through using the information 866 it has. For migrating a part of an area to a TTZ, the correct 867 sequence of configurations is as follows in general: 869 1) configure TTZ on every router in the part of the area to be 870 migrated to TTZ; 872 2) configure on one router in the TTZ to trigger every router in the 873 TTZ to generate and advertise TTZ information for migration; and 875 3) configure on one router in the TTZ to trigger every router in the 876 TTZ to migrate to TTZ. 878 After receiving a configuration on a router to migrate to TTZ, which 879 is for 3), the router checks whether 2) is performed through checking 880 if it has received/originated TTZ LSAs. If it has not, it issues an 881 error to an operator (generation and advertisement of TTZ information 882 for migration to TTZ is not done yet) and rejects the configuration 883 at this time. 885 After a router receives a TTZ LSA with OP for M for 3) from another 886 router, it checks whether 2) is performed through checking if it has 887 received/originated TTZ LSAs. If it has not, it issues an error and 888 logs the error, and does not migrate to TTZ. In this case, it does 889 not originate its router LSA for virtualizing the TTZ if it is a TTZ 890 edge router. 892 After receiving a configuration on a router to generate and advertise 893 TTZ information, which is for 2), the router checks whether 1) is 894 performed through checking if TTZ is configured on it. If it is not, 895 it issues an error to an operator (TTZ is not configured on it yet) 896 and rejects the configuration at this time. 898 For rolling back from TTZ, the correct sequence of configurations is 899 below. 901 1) configure on one router in the TTZ to trigger every router in the 902 TTZ to advertise normal LSAs and stop advertising TTZ LSAs; 904 2) configure on one router in the TTZ to trigger every router in the 905 TTZ to roll back from TTZ. 907 After receiving a configuration on a router to roll back from TTZ, 908 which is for 2), the router checks whether 1) is performed through 909 checking if it has received TTZ LSA with OP for N. If it has not, it 910 issues an error to an operator (advertise normal LSAs and stop 911 advertising TTZ LSAs for rolling back from TTZ is not done yet) and 912 rejects the configuration at this time. 914 After a router receives a TTZ LSA with OP for R for 2) from another 915 router, it checks whether 1) is performed through checking if it has 916 received TTZ LSA with OP for N. If it has not, it issues an error and 917 logs the error, and does not roll back from TTZ. 919 After receiving a configuration on a router to advertise normal LSAs 920 and stop advertising TTZ LSAs for rolling back from TTZ, which is for 921 1), the router checks whether it has any TTZ LSAs. If it does not, 922 it issues an error to an operator (no TTZ to be rolled back) and 923 rejects the configuration at this time. 925 11.3. Adding a Router into TTZ 927 When a non TTZ router (say R1) is connected via a P2P link to a 928 migrated TTZ router (say T1), and there is a normal adjacency between 929 them over the link, a user can configure TTZ on both ends of the link 930 to add R1 into the TTZ to which T1 belongs. They TTZ discover each 931 other as described in section 8. 933 When a number of non TTZ routers are connected via a broadcast or 934 NBMA link to a migrated TTZ router (say T1), and there are normal 935 adjacencies among them, a user configures TTZ on the connection to 936 the link on every router to add the non TTZ routers into the TTZ to 937 which T1 belongs. The DR for the link "forms" TTZ adjacencies with 938 the other routers connected to the link if they all have the same TTZ 939 ID configured for the link. This is determined through the TTZ 940 discovery process described in section 8. 942 12. Manageability Considerations 944 Section 11 (Operations) outlines the configuration process and 945 deployment scenarios for a TTZ. The configurable item is enabling a 946 TTZ on a router and/or an interface on a router. The TTZ function 947 may be controlled by a policy module and assigned a suitable user 948 privilege level to enable. A suitable model may be required to 949 verify the TTZ status on routers participating in the TTZ, including 950 their role as internal or edge TTZ router. The mechanisms defined in 951 this document do not imply any new liveness detection and monitoring 952 requirements in addition to those indicated in [RFC2328]. 954 13. Security Considerations 956 A notable beneficial security aspect of TTZ is that the TTZ is 957 enclosed in a single area, and TTZ could be used to mask the internal 958 topology. External routers that are not participating in the TTZ 959 will not be aware of the internal TTZ topology. It should be noted 960 that a malicious node could inject TTZ LSAs with the OP Field set to 961 M or R, which could trigger the migration into/from a TTZ and may 962 result in the isolation of some routers in the network. Good 963 security practice might reuse the OSPF authentication and other 964 security mechanisms described in [RFC2328] and [RFC7474], to mitigate 965 this type of risk. 967 14. IANA Considerations 969 Under Registry Name: Opaque Link-State Advertisements (LSA) Option 970 Types [RFC5250], IANA is requested to assign a new Opaque type 971 registry value for Topology-Transparent Zone (TTZ) LSA as follows: 973 +====================+===============+=======================+ 974 | Registry Value | Opaque Type | reference | 975 +====================+===============+=======================+ 976 | IANA TBD | TTZ LSA | This document | 977 | (9 Suggested) | | | 978 +--------------------+---------------+-----------------------+ 980 IANA is to create and maintain a new registry: 982 o OSPFv2 TTZ LSA TLVs 984 Initial values for the registry are given below. The future 985 assignments are to be made through IETF Review. 987 Value OSPFv2 TTZ LSA TLV Name Definition 988 ----- ----------------------- ---------- 989 0 Reserved 990 1 TTZ ID TLV see section 6.2 991 2 TTZ Router TLV see section 6.3 992 3 TTZ Options TLV see section 6.4 993 4-32767 Unassigned 994 32768-65535 Reserved 996 15. Contributors and Other Authors 998 1. Other Authors 1000 Mehmet Toy 1001 USA 1002 Email: mehmet.toy@verizon.com 1004 Gregory Cauchie 1005 FRANCE 1006 Email: greg.cauchie@gmail.com 1008 Anil Kumar S N 1009 India 1010 Email: anil.sn@huawei.com 1012 Ning So 1013 USA 1014 Email: ningso01@gmail.com 1015 Lei Liu 1016 USA 1017 Email: lliu@us.fujitsu.com 1019 2. Contributors 1021 Veerendranatha Reddy Vallem 1022 India 1023 Email: veerendranatharv@huawei.com 1025 William McCall 1026 USA 1027 will.mccall@rightside.co 1029 16. Acknowledgement 1031 The authors would like to thank Acee Lindem, Abhay Roy, Christian 1032 Hopps, Dean Cheng, Russ White, Tony Przygienda, Wenhu Lu, Lin Han, 1033 Kiran Makhijani, Padmadevi Pillay Esnault and Yang Yu for their 1034 valuable comments on this draft. 1036 17. References 1038 17.1. Normative References 1040 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1041 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ 1042 RFC2119, March 1997, 1043 . 1045 [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, DOI 10.17487/ 1046 RFC2328, April 1998, 1047 . 1049 [RFC5250] Berger, L., Bryskin, I., Zinin, A., and R. Coltun, "The 1050 OSPF Opaque LSA Option", RFC 5250, DOI 10.17487/RFC5250, 1051 July 2008, . 1053 [RFC7474] Bhatia, M., Hartman, S., Zhang, D., and A. Lindem, Ed., 1054 "Security Extension for OSPFv2 When Using Manual Key 1055 Management", RFC 7474, DOI 10.17487/RFC7474, April 2015, 1056 . 1058 [RFC4940] Kompella, K. and B. Fenner, "IANA Considerations for 1059 OSPF", BCP 130, RFC 4940, DOI 10.17487/RFC4940, July 2007, 1060 . 1062 17.2. Informative References 1064 [RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering 1065 (TE) Extensions to OSPF Version 2", RFC 3630, 1066 DOI 10.17487/RFC3630, September 2003, 1067 . 1069 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 1070 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 1071 DOI 10.17487/RFC5440, March 2009, 1072 . 1074 Appendix A. Prototype Implementation 1076 A.1. What are Implemented and Tested 1078 1. CLI Commands for TTZ 1080 The CLIs implemented and tested include: 1082 o the CLIs of the simpler option for configuring TTZ, and 1084 o the CLIs for controlling migration to TTZ. 1086 2. Extensions to OSPF Protocols for TTZ 1088 All the extensions defined in section "Extensions to OSPF Protocols" 1089 are implemented and tested except for rolling back from TTZ. The 1090 testing results illustrate: 1092 o A TTZ is virtualized to outside as its edge routers connected each 1093 other. Any router outside of the TTZ sees the edge routers (as 1094 normal routers) connecting each other and to some other routers. 1096 o The link state information about the routers and links inside the 1097 TTZ is contained within the TTZ. It is not advertised to any 1098 router outside of the TTZ. 1100 o TTZ is transparent. From a router inside a TTZ, it sees the 1101 topology (link state) outside of the TTZ. From a router outside 1102 of the TTZ, it sees the topology beyond the TTZ. The link state 1103 information outside of the TTZ is advertised through the TTZ. 1105 o TTZ is backward compatible. Any router outside of a TTZ does not 1106 need to support or know TTZ. 1108 3. Smooth Migration to TTZ 1110 The procedures and related protocol extensions for smooth migration 1111 to TTZ are implemented and tested. The testing results show: 1113 o A part of an OSPF area is smoothly migrated to a TTZ without any 1114 routing disruptions. The routes on every router are stable while 1115 the part of the area is being migrated to the TTZ. 1117 o Migration to TTZ is very easy to operate. 1119 4. Add a Router to TTZ 1121 Adding a router into TTZ is implemented and tested. The testing 1122 results illustrate: 1124 o A router can be easily added into a TTZ and becomes a TTZ router. 1126 o The router added into the TTZ is not seen on any router outside of 1127 the TTZ, but it is a part of the TTZ. 1129 5. Leak TTZ Loopbacks Outside 1131 Leaking loopback addresses in a TTZ to routers outside of the TTZ is 1132 implemented and tested. The testing results illustrate: 1134 o The loopback addresses inside the TTZ are advertised to the 1135 routers outside of the TTZ. 1137 o The loopback addresses are accessible from a router outside of the 1138 TTZ. 1140 A.2. Implementation Experience 1142 The implementation of TTZ re-uses the existing OSPF code along with 1143 additional simple logic. A couple of engineers started to work on 1144 implementing the TTZ from the middle of June, 2014 and finished 1145 coding it just before the end of July, 2014. After some testing and 1146 bug fixes, it works as expected. 1148 In our implementation, the link state information in a TTZ opaque LSA 1149 is stored in the same link state database as the link state 1150 information in a normal LSA. For each TTZ link in the TTZ opaque 1151 LSA, there is an additional flag, which is used to differentiate 1152 between a TTZ link and a Normal link. 1154 Before migration to TTZ, every router in the TTZ computes its routing 1155 table using the normal links. After migration to TTZ, every router 1156 in the TTZ computes its routing table using the TTZ links and normal 1157 links. In the case where both the TTZ link and the normal link 1158 exist, the TTZ link is used. 1160 Authors' Addresses 1162 Huaimo Chen 1163 Huawei Technologies 1164 Boston, MA 1165 USA 1167 Email: huaimo.chen@huawei.com 1169 Renwei Li 1170 Huawei Technologies 1171 2330 Central expressway 1172 Santa Clara, CA 1173 USA 1175 Email: renwei.li@huawei.com 1177 Alvaro Retana 1178 Cisco Systems, Inc. 1179 7025 Kit Creek Rd. 1180 Raleigh, NC 27709 1181 USA 1183 Email: aretana@cisco.com 1185 Yi Yang 1186 Sockrate 1187 USA 1189 Email: yyang1998@gmail.com 1190 Zhiheng Liu 1191 China Mobile 1192 No.32 Xuanwumen West Street, Xicheng District 1193 Beijing, 100053 1194 China 1196 Email: liu.cmri@gmail.com