idnits 2.17.1 draft-chen-ospf-ttz-app-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (October 21, 2013) is 3833 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'RFC5441' is mentioned on line 100, but not defined == Missing Reference: 'RFC5440' is mentioned on line 100, but not defined == Missing Reference: 'R71' is mentioned on line 163, but not defined == Missing Reference: 'R73' is mentioned on line 164, but not defined == Unused Reference: 'RFC2119' is defined on line 587, but no explicit reference was found in the text == Unused Reference: 'RFC2328' is defined on line 590, but no explicit reference was found in the text == Unused Reference: 'RFC2740' is defined on line 592, but no explicit reference was found in the text == Unused Reference: 'RFC2370' is defined on line 597, but no explicit reference was found in the text == Unused Reference: 'RFC3630' is defined on line 600, but no explicit reference was found in the text == Unused Reference: 'RFC5786' is defined on line 604, but no explicit reference was found in the text == Unused Reference: 'OSPF-TTZ' is defined on line 608, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2740 (Obsoleted by RFC 5340) -- Obsolete informational reference (is this intentional?): RFC 2370 (Obsoleted by RFC 5250) Summary: 2 errors (**), 0 flaws (~~), 13 warnings (==), 2 comments (--). 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: Informational Huawei Technologies 5 Expires: April 24, 2014 G. Cauchie 7 N. So 8 Tata Communications 9 V. Liu 10 China Mobile 11 L. Liu 12 UC Davis 13 October 21, 2013 15 Applicability of OSPF Topology-Transparent Zone 16 draft-chen-ospf-ttz-app-04.txt 18 Abstract 20 This document discusses the applicability of "OSPF Topology- 21 Transparent Zone". It briefs the protocol and its operations first, 22 and then illustrates the application scenarios of OSPF Topology- 23 Transparent Zone. This document is intended for accompanying "OSPF 24 Topology-Transparent Zone" to the Internet standards track. 26 Status of this Memo 28 This Internet-Draft is submitted to IETF in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at http://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on April 24, 2014. 43 Copyright Notice 45 Copyright (c) 2013 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 2. Overview of Topology-Transparent Zone . . . . . . . . . . . . 3 62 2.1. Definitions of Topology-Transparent Zone . . . . . . . . . 3 63 2.2. An Example of TTZ . . . . . . . . . . . . . . . . . . . . 4 64 3. Applicability of Topology-Transparent Zone . . . . . . . . . . 6 65 3.1. One Area Network . . . . . . . . . . . . . . . . . . . . . 6 66 3.1.1. Issues on Splitting Network into Areas . . . . . . . . 6 67 3.1.2. Use of TTZ in One Area Network . . . . . . . . . . . . 7 68 3.2. Multi-Area Network . . . . . . . . . . . . . . . . . . . . 9 69 3.2.1. Issues on Splitting Network into More Areas . . . . . 9 70 3.2.2. Use of TTZ in Multi-Area Network . . . . . . . . . . . 10 71 3.3. Use of TTZ on Routers in POP . . . . . . . . . . . . . . . 11 72 3.4. Use of TTZ on Routers in IPRAN . . . . . . . . . . . . . . 12 73 3.5. Use of TTZ on Routers from Same Vendor . . . . . . . . . . 12 74 3.6. Use of TTZ on Routers in a Power Saving Group . . . . . . 12 75 4. Limitations . . . . . . . . . . . . . . . . . . . . . . . . . 12 76 5. Security Considerations . . . . . . . . . . . . . . . . . . . 13 77 6. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 13 78 7. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 13 79 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 80 8.1. Normative References . . . . . . . . . . . . . . . . . . . 13 81 8.2. Informative References . . . . . . . . . . . . . . . . . . 13 82 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 84 1. Introduction 86 The number of routers in a network becomes larger and larger as the 87 Internet traffic keeps growing. Through splitting the network into 88 multiple areas, we can extend the network further. However, there 89 are a number of issues when a network is split further into more 90 areas. 92 At first, dividing an AS or an area into multiple areas is a very 93 challenging task since it is involved in significant network 94 architecture changes. 96 Secondly, it is complex for a Multi-Protocol Label Switching (MPLS) 97 Traffic Engineering (TE) Label Switching Path (LSP) crossing multiple 98 areas to be setup. In one option, a TE path crossing multiple areas 99 is computed by using collaborating Path Computation Elements (PCEs) 100 [RFC5441] through the PCE Communication Protocol (PCEP)[RFC5440], 101 which is not easy to configure by operators since the manual 102 configuration of the sequence of domains is required. Although this 103 issue can be addressed by using the Hierarchical PCE, this solution 104 may further increase the complexity of network design. Especially, 105 the current PCE standard method may not guarantee that the path found 106 is optimal. 108 Furthermore, some policies need to be configured on area border 109 routers for reducing the number of link states such as summary Link- 110 State Advertisements (LSAs) to be distributed to other routers in 111 other areas. 113 This document introduces a technology called Topology-Transparent 114 Zone (TTZ), presents a number of application scenarios of TTZ and 115 illustrates that TTZ can resolve the issues above. 117 2. Overview of Topology-Transparent Zone 119 This section briefs the concept of Topology-Transparent Zone (TTZ) 120 and explains the TTZ in some details through an example. 122 2.1. Definitions of Topology-Transparent Zone 124 A Topology-Transparent Zone (TTZ) comprises an Identifier (ID), a 125 group of routers and a number of links connecting the routers. A 126 Topology-Transparent Zone is in an OSPF area. 128 The ID of a Topology-Transparent Zone (TTZ) or TTZ ID for short is a 129 number that is unique for identifying a node in an OSPF domain. It 130 is not zero in general. 132 A TTZ may be virtualized as a different object in a different way. 133 Two typical ways are given below. 135 In a first way, a TTZ may be virtualized as a group of TTZ edge 136 routers fully connected. From a router outside of the TTZ, a TTZ is 137 seen as a group of TTZ edge routers, which are fully connected. 139 In a second way, a TTZ may be seen as a single router. From a router 140 outside of the TTZ, a TTZ is seen as a special single router. This 141 router has a router ID, which is the TTZ ID or the maximum ID among 142 all the router IDs of the routers in the TTZ. For every connection 143 between a TTZ edge router and a router outside of TTZ, there is a 144 connection between the special router and the router outside of TTZ. 146 The virtualization of TTZ in the first way is described and used 147 below. 149 2.2. An Example of TTZ 151 The figure below illustrates an example of a routing area containing 152 a topology-transparent zone: TTZ 600. 154 TTZ 600 155 \ 156 \ ^~^~^~^~^~^~^~^~^~^~^~^~ 157 ( ) 158 ===[R15]========(==[R61]------------[R63]==)======[R29]=== 159 || ( | \ / | ) || 160 || ( | \ / | ) || 161 || ( | \ / | ) || 162 || ( | ___\ / | ) || 163 || ( | / [R71] | ) || 164 || ( | [R73] / \ | ) || 165 || ( | / \ | ) || 166 || ( | / \ | ) || 167 || ( | / \ | ) || 168 ===[R17]========(==[R65]------------[R67]==)======[R31]=== 169 \\ (// \\) // 170 || //v~v~v~v~v~v~v~v~v~v~v~\\ || 171 || // \\ || 172 || // \\ || 173 \\ // \\ // 174 ======[R23]==============================[R25]===== 175 // \\ 176 // \\ 178 Figure 1: An Example of TTZ 180 The routing area comprises routers R15, R17, R23, R25, R29 and R31. 181 It also contains a topology-transparent zone TTZ 600, which comprises 182 routers R61, R63, R65, R67, R71 and R73, and the links connecting 183 them. 185 There are two types of routers in a Topology-Transparent Zone (TTZ): 186 TTZ internal routers and TTZ edge routers. A TTZ internal router is 187 a router inside the TTZ and every adjacent router of the TTZ internal 188 router is a router inside the TTZ. A TTZ edge router is a router 189 inside the TTZ and has at least one adjacent router that is outside 190 of the TTZ and at least one adjacent router that is inside the TTZ. 192 The TTZ in the figure above comprises four TTZ edge routers R61, R63, 193 R65 and R67. Each TTZ edge router is connected to at least one 194 router outside of the TTZ. For instance, router R61 is a TTZ edge 195 router since it is connected to router R15, which is outside of the 196 TTZ. 198 In addition, the TTZ comprises two TTZ internal routers R71 and R73. 199 A TTZ internal router is not connected to any router outside of the 200 TTZ. For instance, router R71 is a TTZ internal router since it is 201 not connected to any router outside of the TTZ. It is just connected 202 to routers R61, R63, R65, R67 and R73 inside the TTZ. 204 A TTZ may hide the information inside the TTZ from the outside. It 205 may not distribute any internal information about the TTZ to a router 206 outside of the TTZ. 208 For instance, the TTZ in the figure above does not send the 209 information about TTZ internal router R71 to any router outside of 210 the TTZ in the routing domain; it does not send the information about 211 the link between R61 and R65 to any router outside of the TTZ. 213 In order to create a TTZ, we MUST configure the same TTZ ID on the 214 edge routers and identify the TTZ internal links on them. In 215 addition, we SHOULD configure the TTZ ID on every TTZ internal router 216 which indicates that every link of the router is a TTZ internal link. 218 From a router outside of the TTZ, a TTZ is seen as a group of routers 219 fully connected. For instance, router R15 in the figure above, which 220 is outside of TTZ 600, sees TTZ 600 as a group of TTZ edge routers: 221 R61, R63, R65 and R67. These four TTZ edge routers are fully 222 connected. 224 In addition, a router outside of the TTZ sees TTZ edge routers having 225 normal connections to the routers outside of the TTZ. For example, 226 router R15 sees four TTZ edge routers R61, R63, R65 and R67, which 227 have the normal connections to R15, R29, R17 and R23, R25 and R31 228 respectively. 230 3. Applicability of Topology-Transparent Zone 232 Topology-Transparent Zone (TTZ) may be used in different cases. This 233 section presents a number of application scenarios of TTZ and 234 illustrates the benefits that TTZ brings in each scenario. 236 3.1. One Area Network 238 Many networks start with one area. A network with only one area is 239 easy to operate and maintain. As a network with one area becomes 240 bigger and bigger because the increasing traffic in the network 241 drives the expansion of the network, it needs to be split into 242 multiple areas in general. 244 3.1.1. Issues on Splitting Network into Areas 246 Splitting a network with only one area into multiple areas is a very 247 challenging task and may raise a number of issues. 249 1. Significant Changes on Network Architecture 251 There are significant changes on network architecture when splitting 252 a network with one area into multiple areas. Originally the network 253 has only one area, which is backbone area. This original backbone 254 area will be split into a new backbone area and a number of non 255 backbone areas. 257 In general, each of the non backbone areas is connected to the new 258 backbone area through the area border routers between the non 259 backbone area and the backbone area. There is not any direct 260 connection between any two non backbone areas. Each area border 261 router summarizes the topology of its attached non backbone area for 262 transmission on the backbone area, and hence to all other area border 263 routers. 265 Before splitting the network into areas, every router in the network 266 has the information about the network topology. However, after 267 splitting the network into areas, each router in an area has the 268 information of the topology of the area, and it does not have the 269 information of the topology of any other area. It has only the 270 summary information about the other areas. 272 2. Complex for MPLS TE Tunnel Setup 274 Each of the MPLS TE LSP tunnels originally in one area, which has its 275 ingress and egress in different areas after the network splitting, 276 needs to be re-configured and re-established. It is very complex for 277 a MPLS TE LSP tunnel crossing areas to be set up. 279 In order to reduce the manual configurations for a MPLS TE LSP tunnel 280 crossing multiple areas, we use PCEs to compute the path for the 281 tunnel. Thus we must configure PCEs for the network split into 282 multiple areas. 284 In addition, we need to provide a sequence of areas for the tunnel 285 through manual configurations. The tunnel will go through the 286 sequence of areas provided. 288 More critically, there are some issues on using PCEs. One of them is 289 that the path computed by PCEs for the tunnel may not be optimal. If 290 the optimal path for the tunnel is not in the sequence of areas 291 configured by users, the path found by PCEs for the tunnel will not 292 be optimal. 294 3. Policy Configurations 296 Some policies need to be applied on area border routers for reducing 297 the number of link states such as summary LSAs to be distributed to 298 other routers in other areas. 300 On an ABR between a non backbone area (say area A) and the backbone 301 area (say area B), there are four sets of policies, which may be 302 configured. One set of them is the policies that block some summary 303 LSA distributions from area B to area A. The second set of them is 304 the policies that aggregate some routes for reducing the number of 305 summary LSAs to be distributed from area B to area A. The third set 306 is the policies that block some summary LSA distributions from area A 307 to area B. The forth set of them is the policies that aggregate some 308 routes for reducing the number of summary LSAs to be distributed to 309 area A from area B. 311 In addition, OSPF need to be disabled before any of the policy 312 commands is issued. And then OSPF must be enabled after the policies 313 are configured. 315 3.1.2. Use of TTZ in One Area Network 317 The issues mentioned above on splitting network into areas disappear 318 if we do not split network into areas and use OSPF Topology 319 Transparent Zone (TTZ) instead. 321 TTZ may be applied to a group of routers and links in the network 322 directly. For a group of routers and links connecting the routers in 323 the group in the network, no matter where it resides in the network, 324 we may configure it as an OSPF TTZ as long as each router in the 325 group can reach the other routers in the group through those links. 327 1. No Significant Changes on Network Architecture 329 There is not any significant changes on network architecture when an 330 OSPF TTZ is applied to a group of routers and links in the network 331 directly. 333 At first, we do not add any new connection to the network, or remove 334 any existing connection from the network. 336 Secondly, every router outside of the TTZ is not aware of the TZZ. 337 Even the router directly connecting to the TTZ is not aware of the 338 TTZ. 340 Furthermore, every router in the network still has a topology view of 341 the network. Except for those internal TTZ routers and links, which 342 are hidden, every router outside of the TTZ has the link state 343 information about all the routers and links in the network. 345 2. Easy for MPLS TE Tunnel Setup 347 After a group of routers and links in the network is configured as an 348 OSPF TTZ, a MPLS TE LSP tunnel with an ingress router and an egress 349 router, which are anywhere in the network, can be configured in a 350 way, which is the same as or similar to the way in which a MPLS TE 351 LSP tunnel in one area network is configured. 353 For example, in the network in Figure 1 above, a MPLS TE LSP tunnel 354 from ingress router R15 to egress router R29 can be configured in the 355 same way as a MPLS TE LSP tunnel in one area network through 356 provisioning the ingress router R15's IP address, the egress router 357 R29's IP address and some constraints for the tunnel on the ingress 358 router R15. 360 We do not need any PCEs for computing the constrained path for a MPLS 361 TE LSP tunnel in the network with OSPF Topology Transparent Zones 362 (TTZs). After a MPLS TE LSP tunnel with an ingress and egress 363 anywhere in the network with OSPF TTZs is configured, the ingress 364 computes the constrained path for the tunnel from the ingress to the 365 egress in the same way as it computes the constrained path for the 366 tunnel in one area network. The constrained path computed may go 367 through some OSPF TTZs. 369 For example, in the network in Figure 1 above, the constrained path 370 computed for the tunnel from ingress router R15 to egress router R29 371 may be from ingress router R15, to edge router R61 of TTZ 600, to 372 edge router R63 of TTZ 600 and then to egress router R29. 374 As soon as the constrained path for a MPLS TE LSP tunnel is computed 375 or given through configuration, the LSP can be established along the 376 path by the signaling protocol RSVP-TE. 378 3. No Policy Configurations 380 There is not any policy configuration for the use of TTZ in one area 381 network. When we apply a TTZ to a group of routers and links 382 connecting the routers, we just configure a TTZ link attribute TTZ ID 383 on each of the links. 385 3.2. Multi-Area Network 387 For a network with multiple areas, it typically needs to be split 388 into more areas when the size of the network becomes larger and 389 larger as the traffic in the network keeps growing. 391 3.2.1. Issues on Splitting Network into More Areas 393 What would happen when we split a network with multiple areas into 394 even more areas? 396 1. Significant Changes on Network Architecture 398 The changes on network architecture are significant when a network 399 with multiple areas is split into even more areas. In the network 400 before splitting, there is one backbone area, which is surrounded by 401 a number of non backbone areas. Each of the non backbone areas is 402 connected to the backbone area. There is not any direct connection 403 between any two non backbone areas in general. 405 Splitting the network into more areas is involved in re-arranging a 406 number of routers and links to create new areas and make some of the 407 existing areas to become smaller. Some of the routers and links in a 408 new area may be from the backbone area, and the other from some of 409 the non backbone areas. 411 In the network after splitting, there is still one backbone area, 412 which must be changed and be surrounded by the new non backbone areas 413 and the existing non backbone areas some of which have been changed. 414 Each of the non backbone areas is connected to the backbone area. 416 2. More Configurations for Tunnel Setup 418 For reducing the manual configurations for a MPLS TE LSP tunnel 419 crossing multiple areas, we use PCEs to compute the path for the 420 tunnel. Thus more configurations for tunnel setup is needed. We 421 must configure PCEs for each of the new areas and peer relations 422 among the PCEs for the new areas and the PCEs for the existing areas. 424 3. More Policy Configurations 426 More policy configurations may be needed. For each of the new non 427 backbone areas and each of the existing non backbone areas that have 428 been changed, some policies may need to be configured on the area 429 border router connecting it to the backbone area to aggregate the 430 routes in the non backbone area for transmission to the backbone 431 area. 433 3.2.2. Use of TTZ in Multi-Area Network 435 The issues described above on splitting network into even more areas 436 disappear if we do not split network into more areas and use OSPF TTZ 437 instead. 439 A TTZ may be applied to a group of routers and links in any area in 440 the network directly. For a group of routers and links connecting 441 the routers in the group in an area, no matter where it resides in 442 the area, we may configure it as an OSPF TTZ as long as each router 443 in the group can reach the other routers in the group through those 444 links. 446 1. No Significant Changes on Network Architecture 448 We can see that there is not any significant change on network 449 architecture when an OSPF TTZ is applied to a group of routers and 450 links in an area in the network directly. 452 At first, we do not add any new connection to the network, or remove 453 any existing connection from the network. 455 Secondly, every router outside of the TTZ is not aware of the TZZ. 456 Even the router directly connecting to the TTZ is not aware of the 457 TTZ. 459 Furthermore, every router in the area still has a topology view of 460 the area. Except for those internal TTZ routers and links, which are 461 hidden, every router outside of the TTZ has the link state 462 information about all the routers and links in the area. 464 2. No Extra Configurations for Tunnel Setup 466 After a group of routers and links in an area in the network is 467 configured as an OSPF TTZ, there is not any extra configuration for 468 supporting setup of a MPLS TE tunnel. We do not need to configure 469 any new PCE since there is not any new area generated after applying 470 a TTZ to a group of routers and links in an area. 472 3. No More Policy Configurations 474 The architecture of areas is not changed after applying a TTZ to a 475 group of routers and links in an area. Thus there is no more policy 476 configuration on the existing area border routers connecting existing 477 non backbone areas to the existing backbone area to aggregate the 478 routes in the non backbone area for transmission to the backbone area 479 in general. 481 3.3. Use of TTZ on Routers in POP 483 A Point of Presence (POP) comprises the routers in a room, a floor, a 484 building or a group of buildings. These routers are normally in an 485 AS or OSPF area. 487 We may increase the network scalability significantly through 488 configuring a POP as an OSPF TTZ. When a POP becomes a TTZ, the link 489 state information about every link and every router inside the POP is 490 hidden from a router outside of the POP. Only very small amount of 491 link state information virtualizing the TTZ for the POP is 492 distributed to the router outside of the POP. Thus, the size of the 493 LSDB on every router in the network is reduced significantly, and the 494 speed for the router to compute the shortest path to every 495 destination is increased dramatically. 497 We may also improve the network availability when we use a TTZ for a 498 POP. In the case that a link or a router in the POP is down, the 499 traffic may be interrupted without using any TTZ for the POP. The 500 link state information about the link or router down needs to be 501 distributed to every router in the network, and every router needs to 502 compute the shortest path to every destination and download the path 503 to its FIB. The traffic is forwarded according to the latest FIB on 504 every router. During this process, there may be inconsist views on 505 the network topology on different routers. 507 The traffic interruption is minimized if we use a TTZ for the POP. 508 The link state information about the link or router down is hidden 509 from every router outside of the POP, which is not aware of the link 510 or router down in the POP. Thus every router outside of the POP has 511 the same topology view when the link or router is down. It does not 512 compute the shortest path or download the path to its FIB. 514 3.4. Use of TTZ on Routers in IPRAN 516 The IP RAN provides connectivity for IP-based mobile broadband (MBB) 517 from LTE and 4G base stations. The ratio of MBB subscribers to total 518 mobile subscribers keeps growing fast. It is expected to grow to 519 nearly 40% in 2016 from 15% in 2011. 521 At the end of 2012, China Mobile had deployed more than 500,000 nodes 522 to support MBB services according to PTN Market Research 2013 Frost & 523 Sullivan. The size of the IP RAN network must seamlessly scale from 524 tens of thousands to hundreds of thousands of nodes. 526 OSPF TTZ may be used in a big IP RAN network for reducing the 527 partition of the network into more OSPF areas. Thus, the network can 528 smoothly scale to hundreds of thousands of nodes. In addition, OSPF 529 TTZ can make the operation and maintenance of the network easier. 531 3.5. Use of TTZ on Routers from Same Vendor 533 In a network, we may separate the routers from different vendors 534 through using TTZ in order to alleviate the possible multi-vendor 535 inter-operability issue. For example, the routers from a same vendor 536 can be configured as a TTZ, and the routers outside of this TTZ are 537 developed by different vendors. 539 3.6. Use of TTZ on Routers in a Power Saving Group 541 A power saving group is a set of routers and links, wherein the 542 routers are connected through the links and there is a redundant 543 route or path from a router in the group to another router in the 544 group. The redundant path is within the group. That is that every 545 hop in the redundant path is within the group. 547 In a power saving group, when the usage of a link within the group 548 between two routers crosses a given threshold value for shutting down 549 the link to save energy, the link will be shut down. This link down 550 in the power saving group will not be distributed to any router 551 outside of the group. The traffic outside of the group will not be 552 affected by the link down inside the group. 554 From the characteristics of a power saving group, we can see that a 555 power saving group is very suitable to be configured as a TTZ. 557 4. Limitations 559 A topology transparent zone is within an OSPF area. It can not be in 560 more than one OSPF areas. 562 A router may belong to a topology transparent zone. It can not 563 belong to more than one topology transparent zones. 565 5. Security Considerations 567 This document does not introduce any new security issues. 569 6. Contributors 571 Yuanbin Yin 572 Huawei Technologies 573 Beijing, 574 China 576 Email: yinyuanbin@huawei.com 578 7. Acknowledgement 580 The authors would like to thank Alvaro Retana, Acee Lindem, and Dean 581 Cheng for their valuable comments on this draft. 583 8. References 585 8.1. Normative References 587 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 588 Requirement Levels", BCP 14, RFC 2119, March 1997. 590 [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998. 592 [RFC2740] Coltun, R., Ferguson, D., and J. Moy, "OSPF for IPv6", 593 RFC 2740, December 1999. 595 8.2. Informative References 597 [RFC2370] Coltun, R., "The OSPF Opaque LSA Option", RFC 2370, 598 July 1998. 600 [RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering 601 (TE) Extensions to OSPF Version 2", RFC 3630, 602 September 2003. 604 [RFC5786] Aggarwal, R. and K. Kompella, "Advertising a Router's 605 Local Addresses in OSPF Traffic Engineering (TE) 606 Extensions", RFC 5786, March 2010. 608 [OSPF-TTZ] 609 Chen, H., Li, R., Cauchie, G., So, N., and L. Liu, "OSPF 610 Topology-Transparent Zone", draft-chen-ospf-ttz, Work in 611 Progress, July 2012. 613 Authors' Addresses 615 Huaimo Chen 616 Huawei Technologies 617 Boston, MA 618 USA 620 Email: huaimo.chen@huawei.com 622 Renwei Li 623 Huawei Technologies 624 2330 Central expressway 625 Santa Clara, CA 626 USA 628 Email: renwei.li@huawei.com 630 Gregory Cauchie 631 FRANCE 633 Email: greg.cauchie@gmail.com 635 Ning So 636 Tata Communications 637 2613 Fairbourne Cir. 638 Plano, TX 75082 639 USA 641 Email: ning.so@tatacommunications.com 642 Vic Liu 643 China Mobile 644 No.32 Xuanwumen West Street, Xicheng District 645 Beijing, 100053 646 China 648 Email: liuzhiheng@chinamobile.com 650 Lei Liu 651 UC Davis 652 USA 654 Email: liulei.kddi@gmail.com