idnits 2.17.1 draft-ietf-ospf-ttz-02.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 (December 23, 2015) is 3046 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Missing Reference: 'R71' is mentioned on line 224, but not defined == Missing Reference: 'R73' is mentioned on line 225, but not defined == Unused Reference: 'RFC2119' is defined on line 868, but no explicit reference was found in the text == Unused Reference: 'RFC2328' is defined on line 873, but no explicit reference was found in the text == Unused Reference: 'RFC5613' is defined on line 881, but no explicit reference was found in the text Summary: 0 errors (**), 0 flaws (~~), 6 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: June 25, 2016 A. Retana 6 Y. Yang 7 Cisco Systems, Inc. 8 V. Liu 9 China Mobile 10 M. Toy 11 Comcast 12 December 23, 2015 14 OSPF Topology-Transparent Zone 15 draft-ietf-ospf-ttz-02.txt 17 Abstract 19 This document presents a topology-transparent zone in a domain. A 20 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 inside the zone is not distributed to any router outside of the zone. 24 Any link state change such as a link down inside the zone is not seen 25 by any router outside of the zone. 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 June 25, 2016. 44 Copyright Notice 46 Copyright (c) 2015 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 . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 63 3. Conventions Used in This Document . . . . . . . . . . . . . . 4 64 4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 4 65 5. Topology-Transparent Zone . . . . . . . . . . . . . . . . . . 5 66 5.1. Overview of Topology-Transparent Zone . . . . . . . . . . 5 67 5.2. Some Details on TTZ . . . . . . . . . . . . . . . . . . . 5 68 6. Extensions to OSPF Protocols . . . . . . . . . . . . . . . . . 6 69 7. Constructing LSAs for TTZ . . . . . . . . . . . . . . . . . . 10 70 8. Establishing Adjacencies . . . . . . . . . . . . . . . . . . . 11 71 8.1. Discover TTZ Neighbor over Normal Adjacency . . . . . . . 11 72 8.2. Establishing TTZ Adjacencies . . . . . . . . . . . . . . . 12 73 8.3. Adjacency between TTZ Edge and TTZ External Router . . . . 12 74 9. Distribution of LSAs . . . . . . . . . . . . . . . . . . . . . 13 75 9.1. Distribution of LSAs within TTZ . . . . . . . . . . . . . 13 76 9.2. Distribution of LSAs through TTZ . . . . . . . . . . . . . 13 77 10. Computation of Routing Table . . . . . . . . . . . . . . . . . 13 78 11. Operations . . . . . . . . . . . . . . . . . . . . . . . . . . 14 79 11.1. Configuring TTZ . . . . . . . . . . . . . . . . . . . . . 14 80 11.2. Smooth Migration to TTZ . . . . . . . . . . . . . . . . . 14 81 11.3. Adding a Router into TTZ . . . . . . . . . . . . . . . . . 15 82 12. Prototype Implementation . . . . . . . . . . . . . . . . . . . 15 83 12.1. What are Implemented and Tested . . . . . . . . . . . . . 16 84 12.2. Implementation Experience . . . . . . . . . . . . . . . . 17 85 13. Security Considerations . . . . . . . . . . . . . . . . . . . 17 86 14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 87 15. Contributors and Other Authors . . . . . . . . . . . . . . . . 18 88 16. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 19 89 17. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19 90 17.1. Normative References . . . . . . . . . . . . . . . . . . . 19 91 17.2. Informative References . . . . . . . . . . . . . . . . . . 20 92 Appendix A. Constants for LSA Distribution . . . . . . . . . . . 20 93 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20 95 1. Introduction 97 The number of routers in a network becomes larger and larger as the 98 Internet traffic keeps growing. Through splitting the network into 99 multiple areas, we can extend the network further. However, there 100 are a number of issues when a network is split further into more 101 areas. 103 At first, dividing a network from one area into multiple areas or 104 from a number of existing areas to even more areas is a very 105 challenging and time consuming task since it is involved in 106 significant network architecture changes. Considering the one area 107 case, originally the network has only one area, which is the 108 backbone. This original backbone area will be split into a new 109 backbone and a number of non backbone areas. In general, each of the 110 non backbone areas is connected to the new backbone area through the 111 area border routers between the non backbone and the backbone area. 112 There is not any direct connection between any two non backbone 113 areas. Each area border router summarizes the topology of its 114 attached non backbone area for transmission on the backbone area, and 115 hence to all other area border routers. 117 Secondly, the services carried by the network may be interrupted 118 while the network is being split from one area into multiple areas or 119 from a number of existing areas into even more areas. 121 Furthermore, it is complex for a Multi-Protocol Label Switching 122 (MPLS) Traffic Engineering (TE) Label Switching Path (LSP) crossing 123 multiple areas to be setup. In one option, a TE path crossing 124 multiple areas is computed by using collaborating Path Computation 125 Elements (PCEs) [RFC5441] through the PCE Communication Protocol 126 (PCEP)[RFC5440], which is not easy to configure by operators since 127 the manual configuration of the sequence of domains is required. 128 Although this issue can be addressed by using the Hierarchical PCE, 129 this solution may further increase the complexity of network design. 130 Especially, the current PCE standard method may not guarantee that 131 the path found is optimal. 133 This document presents a topology-transparent zone in an area and 134 describes extensions to OSPF for supporting the topology-transparent 135 zone, which is scalable and resolves the issues above. 137 A topology-transparent zone comprises a group of routers and a number 138 of links connecting these routers. Any router outside of the zone is 139 not aware of the zone. The information about the links and routers 140 inside the zone is not distributed to any router outside of the zone. 141 Any link state change such as a link down inside the zone is not seen 142 by any router outside of the zone. 144 2. Terminology 146 TTZ internal link: a link between two TTZ adjacent routers in a same 147 TTZ. 149 TTZ external link: a link between a TTZ edge router and a router 150 outside of the TTZ. 152 TTZ internal router: a router in a TTZ whose adjacent routers are in 153 the same TTZ. 155 TTZ external router: a router outside of a TTZ without any TTZ 156 internal link. 158 TTZ edge router: a router in a TTZ that has one (or more) adjacent 159 routers which belong to the same TTZ, and one (or more) adjacent 160 routers which do not belong to the TTZ. 162 3. Conventions Used in This Document 164 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 165 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 166 document are to be interpreted as described in RFC 2119. 168 4. Requirements 170 Topology-Transparent Zone (TTZ) may be deployed for resolving some 171 critical issues in existing networks and future networks. The 172 requirements for TTZ are listed as follows: 174 o Routers outside a TTZ MUST NOT require any changes to operate with 175 the TTZ. 177 o A TTZ MUST be in an area. 179 o A TTZ MUST hide the topology of the TTZ from any router outside of 180 the TTZ. 182 o Users SHOULD be able to easily set up an end to end service 183 crossing TTZs. 185 o The configuration for a TTZ in a network SHOULD be minimum. 187 o The changes on the existing protocols for supporting TTZ SHOULD be 188 minimum. 190 5. Topology-Transparent Zone 192 5.1. Overview of Topology-Transparent Zone 194 A Topology-Transparent Zone (TTZ) is identified by an Identifier 195 (ID), and it includes a group of routers and a number of links 196 connecting the routers. A TTZ is in an OSPF area. 198 The ID of a TTZ or TTZ ID is a 32-bit number that is unique for 199 identifying an entity such as a node in an OSPF domain. It is not 200 zero in general. 202 In addition to having the functions of an OSPF area, an OSPF TTZ 203 makes some improvements on an OSPF area, which include: 205 o An OSPF TTZ is virtualized as the TTZ edges fully connected. 207 o An OSPF TTZ receives the link state information about the topology 208 outside of the TTZ, stores the information in the TTZ and floods 209 the information through the TTZ to the routers outside of the TTZ. 211 5.2. Some Details on TTZ 213 The figure below shows an area containing a TTZ: TTZ 600. 215 TTZ 600 216 \ 217 \ ^~^~^~^~^~^~^~^~^~^~^~^~ 218 ( ) 219 ===[R15]========(==[R61]------------[R63]==)======[R29]=== 220 || ( | \ / | ) || 221 || ( | \ / | ) || 222 || ( | \ / | ) || 223 || ( | ___\ / | ) || 224 || ( | / [R71] | ) || 225 || ( | [R73] / \ | ) || 226 || ( | / \ | ) || 227 || ( | / \ | ) || 228 || ( | / \ | ) || 229 ===[R17]========(==[R65]------------[R67]==)======[R31]=== 230 \\ (// \\) // 231 || //v~v~v~v~v~v~v~v~v~v~v~\\ || 232 || // \\ || 233 || // \\ || 234 \\ // \\ // 235 ======[R23]==============================[R25]===== 236 // \\ 237 // \\ 239 The area comprises routers R15, R17, R23, R25, R29 and R31. It also 240 contains TTZ 600, which comprises routers R61, R63, R65, R67, R71 and 241 R73, and the links connecting them. 243 There are two types of routers in a TTZ: TTZ internal and TTZ edge 244 routers. TTZ 600 has four TTZ edge routers R61, R63, R65 and R67. 245 Each TTZ edge router is connected to at least one router outside of 246 TTZ 600. For instance, router R61 is a TTZ edge router since it is 247 connected to router R15, which is outside of TTZ 600. 249 In addition, TTZ 600 comprises two TTZ internal routers R71 and R73. 250 A TTZ internal router is not connected to any router outside of the 251 TTZ. For instance, router R71 is a TTZ internal router since it is 252 not connected to any router outside of TTZ 600. It is just connected 253 to routers R61, R63, R65, R67 and R73 in the TTZ. 255 A TTZ hides the internal topology of the TTZ from the outside. It 256 does not directly distribute any internal information about the TTZ 257 to a router outside of the TTZ. 259 For instance, TTZ 600 does not send the information about TTZ 260 internal router R71 to any router outside of TTZ 600; it does not 261 send the information about the link between TTZ router R61 and R65 to 262 any router outside of TTZ 600. 264 In order to create a TTZ, we may assign the same TTZ ID to the TTZ 265 edge routers and identify the TTZ internal links on them through CLI. 266 In addition, we assign the TTZ ID to every TTZ internal router which 267 indicates that every link of the router is a TTZ internal link. 269 From a router outside of the TTZ, a TTZ is seen as a group of routers 270 fully connected. For instance, router R15 in the figure above, which 271 is outside of TTZ 600, sees TTZ 600 as a group of TTZ edge routers: 272 R61, R63, R65 and R67, which are fully connected. 274 In addition, a router outside of the TTZ sees TTZ edge routers having 275 normal connections to the routers outside of the TTZ. For example, 276 router R15 sees four TTZ edge routers R61, R63, R65 and R67, which 277 have the normal connections to R15, R29, R17 and R23, R25 and R31 278 respectively. 280 6. Extensions to OSPF Protocols 282 The link state information about a TTZ includes router LSAs and 283 network LSAs. Router LSAs can be contained and distributed in opaque 284 LSAs [RFC5250] within the TTZ. Some control information on a TTZ can 285 also be contained and distributed in opaque LSAs within the TTZ. 287 These opaque LSAs are called TTZ opaque LSAs or TTZ LSAs for short. 289 The following is a general form of a TTZ LSA. It has an LS type = 290 10/9 and TTZ-LSA-Type, and contains a number of TLVs. 292 0 1 2 3 293 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 294 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 295 | LS age | Options | LS Type = 10/9| 296 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 297 |TTZ-LSA-type(5)| Instance ID | 298 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 299 | Advertising Router | 300 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 301 | LS Sequence Number | 302 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 303 | LS checksum | Length | 304 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 305 | | 306 ~ TLVs ~ 307 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 309 Where TTZ-LSA-type is 5, the exact number for it is to be assigned by 310 IANA. 312 There are three top-level TLVs defined: TTZ ID TLV, TTZ Router TLV, 313 and TTZ Options TLV. A TTZ LSA of LS Type 10 contains a mandatory 314 TTZ ID TLV, which is followed by one of the other top-level TLVs. 316 A TTZ LSA containing a TTZ Router TLV is called TTZ Router LSA. A 317 TTZ LSA containing a TTZ Options TLV is called TTZ Control LSA. 319 A TTZ ID TLV has the following format. It contains a TTZ ID and some 320 flags. 322 0 1 2 3 323 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 324 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 325 | TTZ-ID-TLV-type (1) | Length = 8 | 326 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 327 | TTZ ID | 328 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 329 | 0 |E|Z| 330 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 331 E = 1: Indicating a router is a TTZ Edge router 332 Z = 1: Indicating a router has migrated to TTZ 334 When a TTZ router originates a TTZ LSA containing a TTZ ID TLV, it 335 sets flag E to 1 in the TTZ ID TLV if it is a TTZ edge router, and to 336 0 if it is a TTZ internal router. It sets flag Z to 1 after it has 337 migrated to TTZ. 339 The format of a TTZ Router TLV is as follows. It contains the 340 contents of a router LSA. 342 0 1 2 3 343 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 344 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 345 | TTZ-RT-TLV-type (2) | TLV-Length | 346 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 347 | 0 |V|E|B| 0 | # links | 348 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 349 | Link ID | 350 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 351 | Link Data | 352 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 353 | Type | # TOS | metric | 354 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 355 ~ ... ~ 357 For a router link, the existing eight bit Type field for a router 358 link is split into two fields as follows: 360 0 1 2 3 4 5 6 7 361 +---+---+---+---+---+---+---+---+ 362 | I | Type-1 | 363 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 364 I bit flag: 365 1: Router link is a TTZ internal link. 366 0: Router link is a TTZ external link. 367 Type-1: The kind of the link. 369 For a link inside a TTZ, I bit flag is set to one, indicating that 370 this link is a TTZ internal link. For a link connecting to a router 371 outside of a TTZ from a TTZ edge router, I bit flag is set to zero, 372 indicating that this link is a TTZ external link. 374 The value of Type-1 is 1, 2, 3, or 4, which indicates that the kind 375 of a link being described is a point-to-point connection to another 376 router, a connection to a transit network, a connection to a stub 377 network, or a virtual link respectively. 379 The format of TTZ Options TLV is as follows. 381 0 1 2 3 382 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 383 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 384 | TTZ-OP-TLV-type (3) | Length = 4 | 385 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 386 |T|M|N|R| 0 | 387 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 388 T = 1: Distributing TTZ Topology Information for Migration 389 M = 1: Migrating to TTZ 390 N = 1: Distributing Normal Topology Information for Rollback 391 R = 1: Rolling back from TTZ 393 Flags T, M, N and R are exclusive. When one of them is set to 1, the 394 others MUST be set to 0. 396 After a user triggers a TTZ router in a way such as issuing a CLI 397 command to distribute TTZ topology information, the TTZ router 398 originates a TTZ Control LSA having a TTZ Options TLV with flag T set 399 to 1. It also originates its TTZ router LSA. When another TTZ 400 router receives the LSA with T = 1, it originates its TTZ router LSA 401 as needed. 403 After a user asks a TTZ router in a way such as a CLI command to 404 migrate to TTZ, the TTZ router originates a TTZ Control LSA having a 405 TTZ Options TLV with flag M set to 1 and migrates to TTZ. When 406 another TTZ router receives the LSA with M = 1, it also migrates to 407 TTZ. 409 After a user triggers a TTZ router to distribute normal topology 410 information, the TTZ router originates a TTZ Control LSA having a TTZ 411 Options TLV with flag N set to 1. It also distributes its normal 412 LSAs such as its normal router LSA and stops distributing its other 413 TTZ LSAs. When another TTZ router receives the LSA with N = 1, it 414 distributes its normal LSAs and stops distributing its TTZ LSAs. 416 After a user asks a TTZ router to roll back from TTZ, the TTZ router 417 originates a TTZ Control LSA having a TTZ Options TLV with flag R set 418 to 1 and rolls back from TTZ. When another TTZ router receives the 419 LSA with R = 1, it also rolls back from TTZ. 421 If two CLI trigger commands are issued on a TTZ router, two TTZ 422 Control LSAs having a same instance ID are originated by the TTZ 423 router. 425 A TTZ LSA of LS Type 9 with a TTZ ID TLV below is used to discover a 426 TTZ neighbor. 428 0 1 2 3 429 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 430 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 431 | LS age | Options | LS Type = 9 | 432 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 433 |TTZ-LSA-type(5)| Instance ID | 434 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 435 | Advertising Router | 436 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 437 | LS Sequence Number | 438 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 439 | LS checksum | Length | 440 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 441 | | 442 ~ TTZ ID TLV ~ 443 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 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 to the 454 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. This LSA implies that all the links connected to the router 460 are TTZ internal links. In other words, all the router links in the 461 normal router LSA generated by the TTZ internal router are TTZ 462 internal links. Thus a TTZ internal router can choose one of two 463 options: 1) generating a TTZ router LSA with a TTZ ID TLV and a TTZ 464 Router TLV and 2) generating its normal router LSA and a TTZ router 465 LSA with just a TTZ ID TLV. These two options are compatible. 467 After receiving a trigger to migrate to TTZ such as a TTZ Control LSA 468 with flag M = 1, a TTZ edge router originates a normal router LSA for 469 virtualizing a TTZ, which comprises three groups of links in general. 471 The first group are the router links connecting the TTZ external 472 routers. These router links are normal router links. There is a 473 router link for every adjacency between this TTZ edge router and a 474 TTZ external router. 476 The second group are the "virtual" router links. For each of the 477 other TTZ edge routers, there is a point-to-point router link to it. 478 The cost of the link is the cost of the shortest path from this TTZ 479 edge router to it within the TTZ. 481 In addition, the LSA may contain a third group of links, which are 482 stub links for other destinations inside the TTZ. They may be the 483 loopback addresses to be accessed by a node outside of the TTZ. 485 To migrate to TTZ smoothly, a TTZ edge router virtualizes the TTZ in 486 two steps. At first, the router updates its normal router LSA by 487 adding a point-to-point link to each of the other edge routers of the 488 TTZ and a stub link for each of the loopback addresses in the TTZ to 489 be leaked. And then it removes the links configured as TTZ links 490 from its updated router LSA after sending its updated router LSA and 491 receiving the updated router LSAs originated by the other TTZ edge 492 routers for MaxLSADistTime or after sending its updated router LSA 493 for MaxLSAGenDistTime. 495 8. Establishing Adjacencies 497 This section describes the adjacencies in some different cases. 499 8.1. Discover TTZ Neighbor over Normal Adjacency 501 For two routers A and B connected by a P2P link and having a normal 502 adjacency, they discover TTZ each other through a TTZ LSA of LS Type 503 9 with a TTZ ID TLV. We call this LSA D-LSA for short. If two ends 504 of the link have the same TTZ ID, A and B are TTZ neighbors. The 505 following is a sequence of events related to TTZ. 507 A B 508 Configure TTZ Configure TTZ 509 D-LSA (TTZ-ID=100) 510 ---------------------------> Same TTZ ID 511 A is B's TTZ Neighbor 512 D-LSA (TTZ-ID=100) 513 Same TTZ ID <--------------------------- 514 B is A's TTZ Neighbor 516 A sends B a D-LSA with TTZ-ID after the TTZ is configured on it. B 517 sends A a D-LSA with TTZ-ID after the TTZ is configured on it. When 518 A receives the D-LSA from B and determines they have the same TTZ ID, 519 B is A's TTZ neighbor. When B receives the D-LSA from A and 520 determines they have the same TTZ ID, A is B's TTZ neighbor. 522 For a number of routers connected through a broadcast link and having 523 normal adjacencies among them, they also discover TTZ each other 524 through D-LSAs. The DR for the link "forms" TTZ adjacency with each 525 of the other routers if all the routers attached to the link have the 526 same TTZ ID configured on the connections to the link. Otherwise, 527 the DR does not "form" any TTZ adjacency with any router attached to 528 the link. 530 8.2. Establishing TTZ Adjacencies 532 When a router (say A) is connected via a P2P link to another router 533 (say B) and there is not any adjacency between them over the link, a 534 user configures TTZ on two ends of the link to form a TTZ adjacency. 535 They start to discover TTZ each other through D-LSAs in the same way 536 as described above after the normal adjacency is formed. 538 For a number of routers connected through a broadcast link and having 539 no adjacency among them, they start to form TTZ adjacencies after TTZ 540 is configured on the link. While forming adjacencies, they discover 541 TTZ each other through D-LSAs in the same way as described above 542 after the normal adjacency is formed. 544 8.3. Adjacency between TTZ Edge and TTZ External Router 546 For an edge router in a TTZ, it forms an adjacency with any TTZ 547 external router that has a connection with it. 549 When the edge router synchronizes its link state database with the 550 TTZ external router, it sends the TTZ external router the information 551 about all the LSAs except for the LSAs belonging to the TTZ that are 552 hidden from any router outside of the TTZ. 554 At the end of the link state database synchronization, the edge 555 router originates its own router LSA for virtualizing the TTZ and 556 sends this LSA to the TTZ external router. 558 From the point of view of the TTZ external router, which is outside 559 of the TTZ, it sees the other end as a normal router and forms the 560 adjacency in the same way as a normal router. It is not aware of 561 anything about its neighboring TTZ. From the LSAs related to the TTZ 562 edge router in the other end, it knows that the TTZ edge router is 563 connected to each of the other TTZ edge routers and some routers 564 outside of the TTZ. 566 9. Distribution of LSAs 568 LSAs can be divided into a couple of classes according to their 569 distributions. The first class of LSAs is distributed within a TTZ. 570 The second is distributed through a TTZ. 572 9.1. Distribution of LSAs within TTZ 574 Any LSA about a link state in a TTZ is distributed within the TTZ. 575 It is not distributed to any router outside of the TTZ. For example, 576 a router LSA generated for a router in a TTZ is distributed within 577 the TTZ and not distributed to any router outside of the TTZ. 579 Any network LSA generated for a broadcast or NBMA network in a TTZ is 580 distributed in the TTZ and not sent to a router outside of the TTZ. 582 Any opaque LSA generated for a TTZ internal TE link is distributed 583 within the TTZ and not distributed to any router outside of the TTZ. 585 After migrating to TTZ, every edge router of a TTZ MUST NOT 586 distribute any LSA about a link state in the TTZ to any router 587 outside of the TTZ. 589 For any TTZ LSA originated by a router within the TTZ, every edge 590 router of the TTZ MUST NOT distribute it to any router outside of the 591 TTZ. 593 9.2. Distribution of LSAs through TTZ 595 Any LSA about a link state outside of a TTZ received by an edge 596 router of the TTZ is distributed through the TTZ. For example, when 597 an edge router of a TTZ receives an LSA from a router outside of the 598 TTZ, it floods it to its neighboring routers both inside the TTZ and 599 outside of the TTZ. This LSA may be any LSA such as a router LSA 600 that is distributed in a domain. 602 The routers in the TTZ continue to flood the LSA. When another edge 603 router of the TTZ receives the LSA, it floods the LSA to its 604 neighboring routers both outside of the TTZ and inside the TTZ. 606 10. Computation of Routing Table 608 When a router migrates to TTZ, the computation of the routing table 609 on the router is the same as that described in RFC 2328, with one 610 exception. The router in a TTZ ignores the router LSAs generated by 611 the TTZ edge routers for virtualizing the TTZ. It computes routes 612 through using the TTZ topology and the topology outside of the TTZ. 614 11. Operations 616 11.1. Configuring TTZ 618 This section proposes some options for configuring a TTZ. 620 1. Configuring TTZ on Every Link in TTZ 622 If every link in a TTZ is configured with a same TTZ ID as a TTZ 623 link, the TTZ is determined. A router with some TTZ links and some 624 normal links is a TTZ edge router. A router with only TTZ links is a 625 TTZ internal router. 627 2. Configuring TTZ on Every Router in TTZ 629 We may configure a same TTZ ID on every router in the TTZ, and on 630 every edge router's links connecting to the routers in the TTZ. 632 A router configured with the TTZ ID on some of its links is a TTZ 633 edge router. A router configured with the TTZ ID only is a TTZ 634 internal router. All the links on a TTZ internal router are TTZ 635 links. This option is simpler than the above one. 637 11.2. Smooth Migration to TTZ 639 For a group of routers and a number of links connecting the routers 640 in an area, making them transfer to work as a TTZ without any service 641 interruption takes a few of steps or stages. 643 At first, a user configures the TTZ feature on every router in the 644 TTZ. In this stage, a router does not originate its TTZ router LSA. 645 It will discover its TTZ neighbors. 647 Secondly, after configuring the TTZ, a user issues a CLI command on 648 one router in the TTZ, which triggers every router in the TTZ to 649 generate and distribute TTZ information among the routers in the TTZ. 650 When the router receives the command, it originates a TTZ control LSA 651 with T=1 (indicating TTZ information generation and distribution for 652 migration). It also originates its TTZ router LSA, and distributes 653 the LSA to its TTZ neighbors. When a router in the TTZ receives the 654 LSA with T=1, it originates its TTZ router LSA. In this stage, every 655 router in the TTZ has dual roles. One is to function as a normal 656 router. The other is to generate and distribute TTZ information. 658 Thirdly, a user checks whether every router in the TTZ is ready for 659 migration to TTZ. A router in the TTZ is ready after it has received 660 all the necessary information from all the routers in the TTZ. This 661 information may be displayed on a router through a CLI command. 663 And then a user activates the TTZ through using a CLI command such as 664 migrate to TTZ on one router in the TTZ. The router migrates to TTZ, 665 generates and distributes a TTZ control LSA with M = 1 (indicating 666 Migrating to TTZ) after it receives the command. 668 After a router in the TTZ receives the TTZ control LSA with M = 1, it 669 also migrates to TTZ. Thus, activating the TTZ on one TTZ router 670 makes every router in the TTZ migrate to TTZ, which computes routes 671 through using the TTZ topology and the topology outside of the TTZ. 673 For an edge router of the TTZ, migrating to work as a TTZ router 674 comprises generating a router LSA to virtualize the TTZ and flooding 675 this LSA to all its neighboring routers in two steps described in 676 section 7. 678 In normal operations for migration to TTZ and rollback from TTZ, a 679 user issues a series of commands according to certain procedures. In 680 an abnormal case, for example two conflict commands are issued on two 681 TTZ routers in a TTZ at the same time, a TTZ router gives a warning 682 when it detects the abnormal case. 684 11.3. Adding a Router into TTZ 686 When a non TTZ router (say R1) is connected via a P2P link to a TTZ 687 router (say T1) working as TTZ and there is a normal adjacency 688 between them over the link, a user can configure TTZ on two ends of 689 the link to add R1 into the TTZ to which T1 belongs. They discover 690 TTZ each other in the same way as described in section 8. 692 When a number of non TTZ routers are connected via a broadcast link 693 to a TTZ router (say T1) working as TTZ and there are normal 694 adjacencies among them, a user configures TTZ on the connection to 695 the link on every router to add the non TTZ routers into the TTZ to 696 which T1 belongs. The DR for the link "forms" TTZ adjacency with 697 each of the other routers if all the routers have the same TTZ ID 698 configured on the connections to the link. 700 When a router (say R1) is connected via a P2P link to a TTZ router 701 (say T1) and there is not any adjacency between them over the link, a 702 user can configure TTZ on two ends of the link to add R1 into the TTZ 703 to which T1 belongs. R1 and T1 will form an adjacency in the same 704 way as described in section 8. 706 12. Prototype Implementation 707 12.1. What are Implemented and Tested 709 1. CLI Commands for TTZ 711 The CLIs implemented and tested include: 713 o the CLIs of the simpler option for configuring TTZ, and 715 o the CLIs for controlling migration to TTZ. 717 2. Extensions to OSPF Protocols for TTZ 719 All the extensions defined in section "Extensions to OSPF Protocols" 720 are implemented and tested except for rolling back from TTZ. The 721 testing results illustrate: 723 o A TTZ is virtualized to outside as its edge routers fully 724 connected. Any router outside of the TTZ sees the edge routers 725 (as normal routers) connecting each other and to some other 726 routers. 728 o The link state information about the routers and links inside the 729 TTZ is contained within the TTZ. It is not distributed to any 730 router outside of the TTZ. 732 o TTZ is transparent. From a router inside a TTZ, it sees the 733 topology (link state) outside of the TTZ. From a router outside 734 of the TTZ, it sees the topology beyond the TTZ. The link state 735 information outside of the TTZ is distributed through the TTZ. 737 o TTZ is backward compatible. Any router outside of a TTZ does not 738 need to support or know TTZ. 740 3. Smooth Migration to TTZ 742 The procedures and related protocol extensions for smooth migration 743 to TTZ are implemented and tested. The testing results show: 745 o A part of an area is smoothly migrated to a TTZ without any 746 routing disruptions. The routes on every router are stable while 747 the part of the area is being migrated to the TTZ. 749 o Migration to TTZ is very easy to operate. 751 4. Add a Router to TTZ 753 Adding a router into TTZ is implemented and tested. The testing 754 results illustrate: 756 o A router can be easily added into a TTZ and becomes a TTZ router. 758 o The router added into the TTZ is not seen on any router outside of 759 the TTZ, but it is a part of the TTZ. 761 5. Leak TTZ Loopbacks Outside 763 Leaking loopback addresses in a TTZ to routers outside of the TTZ is 764 implemented and tested. The testing results illustrate: 766 o The loopback addresses inside the TTZ are distributed to the 767 routers outside of the TTZ. 769 o The loopback addresses are accessible from a router outside of the 770 TTZ. 772 12.2. Implementation Experience 774 The implementation of TTZ is relatively easy compared to other 775 features of OSPF. Re-using the existing OSPF code along with 776 additional simple logic does the work. A couple of engineers started 777 to work on implementing the TTZ from the middle of June, 2014 and 778 finished coding it just before IETF 90. After some testing and bug 779 fixes, it works as expected. 781 In our implementation, the link state information in a TTZ opaque LSA 782 is stored in the same link state database as the link state 783 information in a normal LSA. For each TTZ link in the TTZ opaque LSA 784 stored, there is an additional flag, which is used to differentiate 785 between a TTZ link and a Normal link. 787 Before migration to TTZ, every router in the TTZ computes its routing 788 table using the normal links. After migration to TTZ, every router 789 in the TTZ computes its routing table using the TTZ links and normal 790 links. In the case that there are one TTZ link and one normal link 791 to select, the TTZ link is used. 793 13. Security Considerations 795 The mechanism described in this document does not raise any new 796 security issues for the OSPF protocols. 798 14. IANA Considerations 800 Under Registry Name: Opaque Link-State Advertisements (LSA) Option 801 Types [RFC5250], IANA is requested to assign a new Opaque type 802 registry value for Topology-Transparent Zone (TTZ) LSA as follows: 804 +====================+===============+=======================+ 805 | Registry Value | Opaque Type | reference | 806 +====================+===============+=======================+ 807 | 5 | TTZ LSA | This document | 808 +--------------------+---------------+-----------------------+ 810 IANA is requested to assign Types for new TLVs in the new TTZ LSA as 811 follows: 813 Type Name Allowed in 814 1 TTZ ID TLV TTZ LSA of LS Type 10 and 9 815 2 TTZ Router TLV TTZ LSA of LS Type 10 816 3 TTZ Options TLV TTZ LSA of LS Type 10 818 15. Contributors and Other Authors 820 1. Other Authors 822 Gregory Cauchie 823 FRANCE 824 Email: greg.cauchie@gmail.com 826 Anil Kumar S N 827 Huawei Technologies 828 Banglore 829 India 830 Email: anil.sn@huawei.com 832 Ning So 833 Tata Communications 834 2613 Fairbourne Cir. 835 Plano, TX 75082 836 USA 837 Email: ningso01@gmail.com 839 Lei Liu 840 Fujitsu 841 USA 842 Email: lliu@us.fujitsu.com 844 2. Contributors 846 Veerendranatha Reddy Vallem 847 Huawei Technologies 848 Banglore 849 India 850 Email: veerendranatharv@huawei.com 852 William McCall 853 Cisco Systems, Inc. 854 Bellevue, WA 855 USA 856 wimccall@cisco.com 858 16. Acknowledgement 860 The author would like to thank Acee Lindem, Abhay Roy, Dean Cheng, 861 Russ White, Tony Przygienda, Wenhu Lu, Lin Han and Yang Yu for their 862 valuable comments on this draft. 864 17. References 866 17.1. Normative References 868 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 869 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ 870 RFC2119, March 1997, 871 . 873 [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, DOI 10.17487/ 874 RFC2328, April 1998, 875 . 877 [RFC5250] Berger, L., Bryskin, I., Zinin, A., and R. Coltun, "The 878 OSPF Opaque LSA Option", RFC 5250, DOI 10.17487/RFC5250, 879 July 2008, . 881 [RFC5613] Zinin, A., Roy, A., Nguyen, L., Friedman, B., and D. 882 Yeung, "OSPF Link-Local Signaling", RFC 5613, 883 DOI 10.17487/RFC5613, August 2009, 884 . 886 17.2. Informative References 888 [RFC5441] Vasseur, JP., Ed., Zhang, R., Bitar, N., and JL. Le Roux, 889 "A Backward-Recursive PCE-Based Computation (BRPC) 890 Procedure to Compute Shortest Constrained Inter-Domain 891 Traffic Engineering Label Switched Paths", RFC 5441, 892 DOI 10.17487/RFC5441, April 2009, 893 . 895 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 896 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 897 DOI 10.17487/RFC5440, March 2009, 898 . 900 Appendix A. Constants for LSA Distribution 902 MaxLSADistTime: The maximum time for an LSA to be distributed to all 903 the routers in an area. The value of MaxLSADistTime is set to 0.1 904 second. 906 MaxLSAGenDistTime: The maximum time for all TTZ router LSAs to be 907 generated by all TTZ edge routers and distributed to all the routers 908 in an area after a first TTZ router LSA is generated. The value of 909 MaxLSAGenDistTime is set to 0.3 second. 911 Authors' Addresses 913 Huaimo Chen 914 Huawei Technologies 915 Boston, MA 916 USA 918 Email: huaimo.chen@huawei.com 920 Renwei Li 921 Huawei Technologies 922 2330 Central expressway 923 Santa Clara, CA 924 USA 926 Email: renwei.li@huawei.com 927 Alvaro Retana 928 Cisco Systems, Inc. 929 7025 Kit Creek Rd. 930 Raleigh, NC 27709 931 USA 933 Email: aretana@cisco.com 935 Yi Yang 936 Cisco Systems, Inc. 937 7025 Kit Creek Rd. 938 Raleigh, NC 27709 939 USA 941 Email: yiya@cisco.com 943 Vic Liu 944 China Mobile 945 No.32 Xuanwumen West Street, Xicheng District 946 Beijing, 100053 947 China 949 Email: liuzhiheng@chinamobile.com 951 Mehmet Toy 952 Comcast 953 1800 Bishops Gate Blvd. 954 Mount Laurel, NJ 08054 955 USA 957 Email: mehmet_toy@cable.comcast.com