idnits 2.17.1 draft-chen-ospf-ttz-app-05.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 (July 4, 2014) is 3581 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'RFC5441' is mentioned on line 103, but not defined == Missing Reference: 'RFC5440' is mentioned on line 103, but not defined == Missing Reference: 'R71' is mentioned on line 161, but not defined == Missing Reference: 'R73' is mentioned on line 162, but not defined == Unused Reference: 'RFC2119' is defined on line 567, but no explicit reference was found in the text == Unused Reference: 'RFC2328' is defined on line 570, but no explicit reference was found in the text == Unused Reference: 'RFC2740' is defined on line 572, but no explicit reference was found in the text == Unused Reference: 'RFC2370' is defined on line 577, but no explicit reference was found in the text == Unused Reference: 'RFC3630' is defined on line 580, but no explicit reference was found in the text == Unused Reference: 'RFC5786' is defined on line 584, but no explicit reference was found in the text == Unused Reference: 'OSPF-TTZ' is defined on line 588, 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: January 5, 2015 G. Cauchie 7 N. So 8 Tata Communications 9 V. Liu 10 China Mobile 11 L. Liu 12 UC Davis 13 July 4, 2014 15 Applicability of OSPF Topology-Transparent Zone 16 draft-chen-ospf-ttz-app-05.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 January 5, 2015. 43 Copyright Notice 45 Copyright (c) 2014 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 . . . . . . . . . . . . . . 11 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. Security Considerations . . . . . . . . . . . . . . . . . . . 12 76 5. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 12 77 6. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 13 78 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 79 7.1. Normative References . . . . . . . . . . . . . . . . . . . 13 80 7.2. Informative References . . . . . . . . . . . . . . . . . . 13 81 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 83 1. Introduction 85 The number of routers in a network becomes larger and larger as the 86 Internet traffic keeps growing. Through splitting the network into 87 multiple areas, we can extend the network further. However, there 88 are a number of issues when a network is split further into more 89 areas. 91 At first, dividing an AS or an area into multiple areas is a very 92 challenging task since it is involved in significant network 93 architecture changes. 95 Secondly, the services carried by the network may be interrupted 96 while the network is being split from one area into multiple areas or 97 from a number of existing areas into even more areas. 99 Moreover, it is complex for a Multi-Protocol Label Switching (MPLS) 100 Traffic Engineering (TE) Label Switching Path (LSP) crossing multiple 101 areas to be setup. In one option, a TE path crossing multiple areas 102 is computed by using collaborating Path Computation Elements (PCEs) 103 [RFC5441] through the PCE Communication Protocol (PCEP)[RFC5440], 104 which is not easy to configure by operators since the manual 105 configuration of the sequence of domains is required. Although this 106 issue can be addressed by using the Hierarchical PCE, this solution 107 may further increase the complexity of network design. Especially, 108 the current PCE standard method may not guarantee that the path found 109 is optimal. 111 This document introduces a technology called Topology-Transparent 112 Zone (TTZ), presents a number of application scenarios of TTZ and 113 illustrates that TTZ can resolve the issues above. 115 2. Overview of Topology-Transparent Zone 117 This section briefs the concept of Topology-Transparent Zone (TTZ) 118 and explains the TTZ in some details through an example. 120 2.1. Definitions of Topology-Transparent Zone 122 A Topology-Transparent Zone (TTZ) comprises an Identifier (ID), a 123 group of routers and a number of links connecting the routers. A 124 Topology-Transparent Zone is in an OSPF area. 126 The ID of a Topology-Transparent Zone (TTZ) or TTZ ID for short is a 127 number that is unique for identifying a node in an OSPF domain. It 128 is not zero in general. 130 A TTZ may be virtualized as a different object in a different way. 131 Two typical ways are given below. 133 In a first way, a TTZ may be virtualized as a group of TTZ edge 134 routers fully connected. From a router outside of the TTZ, a TTZ is 135 seen as a group of TTZ edge routers, which are fully connected. 137 In a second way, a TTZ may be seen as a single router. From a router 138 outside of the TTZ, a TTZ is seen as a special single router. This 139 router has a router ID, which is the TTZ ID or the maximum ID among 140 all the router IDs of the routers in the TTZ. For every connection 141 between a TTZ edge router and a router outside of TTZ, there is a 142 connection between the special router and the router outside of TTZ. 144 The virtualization of TTZ in the first way is described and used 145 below. 147 2.2. An Example of TTZ 149 The figure below illustrates an example of a routing area containing 150 a topology-transparent zone: TTZ 600. 152 TTZ 600 153 \ 154 \ ^~^~^~^~^~^~^~^~^~^~^~^~ 155 ( ) 156 ===[R15]========(==[R61]------------[R63]==)======[R29]=== 157 || ( | \ / | ) || 158 || ( | \ / | ) || 159 || ( | \ / | ) || 160 || ( | ___\ / | ) || 161 || ( | / [R71] | ) || 162 || ( | [R73] / \ | ) || 163 || ( | / \ | ) || 164 || ( | / \ | ) || 165 || ( | / \ | ) || 166 ===[R17]========(==[R65]------------[R67]==)======[R31]=== 167 \\ (// \\) // 168 || //v~v~v~v~v~v~v~v~v~v~v~\\ || 169 || // \\ || 170 || // \\ || 171 \\ // \\ // 172 ======[R23]==============================[R25]===== 173 // \\ 174 // \\ 176 Figure 1: An Example of TTZ 178 The routing area comprises routers R15, R17, R23, R25, R29 and R31. 179 It also contains a topology-transparent zone TTZ 600, which comprises 180 routers R61, R63, R65, R67, R71 and R73, and the links connecting 181 them. 183 There are two types of routers in a Topology-Transparent Zone (TTZ): 184 TTZ internal routers and TTZ edge routers. A TTZ internal router is 185 a router inside the TTZ and every adjacent router of the TTZ internal 186 router is a router inside the TTZ. A TTZ edge router is a router 187 inside the TTZ and has at least one adjacent router that is outside 188 of the TTZ and at least one adjacent router that is inside the TTZ. 190 The TTZ in the figure above comprises four TTZ edge routers R61, R63, 191 R65 and R67. Each TTZ edge router is connected to at least one 192 router outside of the TTZ. For instance, router R61 is a TTZ edge 193 router since it is connected to router R15, which is outside of the 194 TTZ. 196 In addition, the TTZ comprises two TTZ internal routers R71 and R73. 197 A TTZ internal router is not connected to any router outside of the 198 TTZ. For instance, router R71 is a TTZ internal router since it is 199 not connected to any router outside of the TTZ. It is just connected 200 to routers R61, R63, R65, R67 and R73 inside the TTZ. 202 A TTZ may hide the information inside the TTZ from the outside. It 203 may not distribute any internal information about the TTZ to a router 204 outside of the TTZ. 206 For instance, the TTZ in the figure above does not send the 207 information about TTZ internal router R71 to any router outside of 208 the TTZ in the routing domain; it does not send the information about 209 the link between R61 and R65 to any router outside of the TTZ. 211 In order to create a TTZ, we MUST configure the same TTZ ID on the 212 edge routers and identify the TTZ internal links on them. In 213 addition, we SHOULD configure the TTZ ID on every TTZ internal router 214 which indicates that every link of the router is a TTZ internal link. 216 From a router outside of the TTZ, a TTZ is seen as a group of routers 217 fully connected. For instance, router R15 in the figure above, which 218 is outside of TTZ 600, sees TTZ 600 as a group of TTZ edge routers: 219 R61, R63, R65 and R67. These four TTZ edge routers are fully 220 connected. 222 In addition, a router outside of the TTZ sees TTZ edge routers having 223 normal connections to the routers outside of the TTZ. For example, 224 router R15 sees four TTZ edge routers R61, R63, R65 and R67, which 225 have the normal connections to R15, R29, R17 and R23, R25 and R31 226 respectively. 228 3. Applicability of Topology-Transparent Zone 230 Topology-Transparent Zone (TTZ) may be used in different cases. This 231 section presents a number of application scenarios of TTZ and 232 illustrates the benefits that TTZ brings in each scenario. 234 3.1. One Area Network 236 Many networks start with one area. A network with only one area is 237 easy to operate and maintain. As a network with one area becomes 238 bigger and bigger because the increasing traffic in the network 239 drives the expansion of the network, it needs to be split into 240 multiple areas in general. 242 3.1.1. Issues on Splitting Network into Areas 244 Splitting a network with only one area into multiple areas is a very 245 challenging task and may raise a number of issues. 247 1. Significant Changes on Network Architecture 249 There are significant changes on network architecture when splitting 250 a network with one area into multiple areas. Originally the network 251 has only one area, which is backbone area. This original backbone 252 area will be split into a new backbone area and a number of non 253 backbone areas. 255 In general, each of the non backbone areas is connected to the new 256 backbone area through the area border routers between the non 257 backbone area and the backbone area. There is not any direct 258 connection between any two non backbone areas. Each area border 259 router summarizes the topology of its attached non backbone area for 260 transmission on the backbone area, and hence to all other area border 261 routers. 263 Before splitting the network into areas, every router in the network 264 has the information about the network topology. However, after 265 splitting the network into areas, each router in an area has the 266 information of the topology of the area, and it does not have the 267 information of the topology of any other area. It has only the 268 summary information about the other areas. 270 2. Service Interruptions 272 The services carried by the network may be interrupted while the 273 network is being split from one area into multiple areas. 275 3. Complex for MPLS TE Tunnel Setup 277 Each of the MPLS TE LSP tunnels originally in one area, which has its 278 ingress and egress in different areas after the network splitting, 279 needs to be re-configured and re-established. It is very complex for 280 a MPLS TE LSP tunnel crossing areas to be set up. 282 In order to reduce the manual configurations for a MPLS TE LSP tunnel 283 crossing multiple areas, we use PCEs to compute the path for the 284 tunnel. Thus we must configure PCEs for the network split into 285 multiple areas. 287 In addition, we need to provide a sequence of areas for the tunnel 288 through manual configurations. The tunnel will go through the 289 sequence of areas provided. 291 More critically, there are some issues on using PCEs. One of them is 292 that the path computed by PCEs for the tunnel may not be optimal. If 293 the optimal path for the tunnel is not in the sequence of areas 294 configured by users, the path found by PCEs for the tunnel will not 295 be optimal. 297 3.1.2. Use of TTZ in One Area Network 299 The issues mentioned above on splitting network into areas disappear 300 if we do not split network into areas and use OSPF Topology 301 Transparent Zone (TTZ) instead. 303 TTZ may be applied to a group of routers and links in the network 304 directly. For a group of routers and links connecting the routers in 305 the group in the network, no matter where it resides in the network, 306 we may configure it as an OSPF TTZ as long as each router in the 307 group can reach the other routers in the group through those links. 309 1. No Significant Changes on Network Architecture 311 There is not any significant changes on network architecture when an 312 OSPF TTZ is applied to a group of routers and links in the network 313 directly. 315 At first, we do not add any new connection to the network, or remove 316 any existing connection from the network. 318 Secondly, every router outside of the TTZ is not aware of the TZZ. 319 Even the router directly connecting to the TTZ is not aware of the 320 TTZ. 322 Furthermore, every router in the network still has a topology view of 323 the network. Except for those internal TTZ routers and links, which 324 are hidden, every router outside of the TTZ has the link state 325 information about all the routers and links in the network. 327 2. No Service Interruption 329 For a group of routers and a number of links connecting the routers 330 in an area, they can transfer to work as a TTZ without any service 331 interruptions. 333 There is not any route change while these routers are migrating to 334 work as a TTZ. Every router in the TTZ "sees" the same network 335 topology (the TTZ topology and the topology outside of the TTZ) and 336 uses it to compute the routes. Thus the routing table on the router 337 will not change. 339 For every router outside of the TTZ, its routing table will not 340 change either while those routers are migrating to work as a TTZ. 341 Even though there are some new router LSAs for virtualizing TTZ, 342 these LSAs will not change any routes. Each link in any of these 343 LSAs represents a shortest path between two TTZ edge routers within 344 the TTZ. 346 3. Easy for MPLS TE Tunnel Setup 348 After a group of routers and links in the network is configured as an 349 OSPF TTZ, a MPLS TE LSP tunnel with an ingress router and an egress 350 router, which are anywhere in the network, can be configured in a 351 way, which is the same as or similar to the way in which a MPLS TE 352 LSP tunnel in one area network is configured. 354 For example, in the network in Figure 1 above, a MPLS TE LSP tunnel 355 from ingress router R15 to egress router R29 can be configured in the 356 same way as a MPLS TE LSP tunnel in one area network through 357 provisioning the ingress router R15's IP address, the egress router 358 R29's IP address and some constraints for the tunnel on the ingress 359 router R15. 361 We do not need any PCEs for computing the constrained path for a MPLS 362 TE LSP tunnel in the network with OSPF Topology Transparent Zones 363 (TTZs). After a MPLS TE LSP tunnel with an ingress and egress 364 anywhere in the network with OSPF TTZs is configured, the ingress 365 computes the constrained path for the tunnel from the ingress to the 366 egress in the same way as it computes the constrained path for the 367 tunnel in one area network. The constrained path computed may go 368 through some OSPF TTZs. 370 For example, in the network in Figure 1 above, the constrained path 371 computed for the tunnel from ingress router R15 to egress router R29 372 may be from ingress router R15, to edge router R61 of TTZ 600, to 373 edge router R63 of TTZ 600 and then to egress router R29. 375 As soon as the constrained path for a MPLS TE LSP tunnel is computed 376 or given through configuration, the LSP can be established along the 377 path by the signaling protocol RSVP-TE. 379 3.2. Multi-Area Network 381 For a network with multiple areas, it typically needs to be split 382 into more areas when the size of the network becomes larger and 383 larger as the traffic in the network keeps growing. 385 3.2.1. Issues on Splitting Network into More Areas 387 What would happen when we split a network with multiple areas into 388 even more areas? 390 1. Significant Changes on Network Architecture 392 The changes on network architecture are significant when a network 393 with multiple areas is split into even more areas. In the network 394 before splitting, there is one backbone area, which is surrounded by 395 a number of non backbone areas. Each of the non backbone areas is 396 connected to the backbone area. There is not any direct connection 397 between any two non backbone areas in general. 399 Splitting the network into more areas is involved in re-arranging a 400 number of routers and links to create new areas and make some of the 401 existing areas to become smaller. Some of the routers and links in a 402 new area may be from the backbone area, and the other from some of 403 the non backbone areas. 405 In the network after splitting, there is still one backbone area, 406 which must be changed and be surrounded by the new non backbone areas 407 and the existing non backbone areas some of which have been changed. 408 Each of the non backbone areas is connected to the backbone area. 410 2. Service Interruptions 412 The services carried by the network may be interrupted while the 413 network is being split from a number of existing areas into even more 414 areas. 416 3. More Configurations for Tunnel Setup 417 For reducing the manual configurations for a MPLS TE LSP tunnel 418 crossing multiple areas, we use PCEs to compute the path for the 419 tunnel. Thus more configurations for tunnel setup is needed. We 420 must configure PCEs for each of the new areas and peer relations 421 among the PCEs for the new areas and the PCEs for the existing areas. 423 3.2.2. Use of TTZ in Multi-Area Network 425 The issues described above on splitting network into even more areas 426 disappear if we do not split network into more areas and use OSPF TTZ 427 instead. 429 A TTZ may be applied to a group of routers and links in any area in 430 the network directly. For a group of routers and links connecting 431 the routers in the group in an area, no matter where it resides in 432 the area, we may configure it as an OSPF TTZ as long as each router 433 in the group can reach the other routers in the group through those 434 links. 436 1. No Significant Changes on Network Architecture 438 We can see that there is not any significant change on network 439 architecture when an OSPF TTZ is applied to a group of routers and 440 links in an area in the network directly. 442 At first, we do not add any new connection to the network, or remove 443 any existing connection from the network. 445 Secondly, every router outside of the TTZ is not aware of the TZZ. 446 Even the router directly connecting to the TTZ is not aware of the 447 TTZ. 449 Furthermore, every router in the area still has a topology view of 450 the area. Except for those internal TTZ routers and links, which are 451 hidden, every router outside of the TTZ has the link state 452 information about all the routers and links in the area. 454 2. No Service Interruption 456 For a group of routers and a number of links connecting the routers 457 in an area, they can transfer to work as a TTZ without any service 458 interruptions. 460 There is not any route change in the network while those routers are 461 transferring to work as a TTZ. 463 3. No Extra Configurations for Tunnel Setup 464 After a group of routers and links in an area in the network is 465 configured as an OSPF TTZ, there is not any extra configuration for 466 supporting setup of a MPLS TE tunnel. We do not need to configure 467 any new PCE since there is not any new area generated after applying 468 a TTZ to a group of routers and links in an area. 470 3.3. Use of TTZ on Routers in POP 472 A Point of Presence (POP) comprises the routers in a room, a floor, a 473 building or a group of buildings. These routers are normally in an 474 AS or OSPF area. 476 We may increase the network scalability significantly through 477 configuring a POP as an OSPF TTZ. When a POP becomes a TTZ, the link 478 state information about every link and every router inside the POP is 479 hidden from a router outside of the POP. Only very small amount of 480 link state information virtualizing the TTZ for the POP is 481 distributed to the router outside of the POP. Thus, the size of the 482 LSDB on every router in the network is reduced significantly, and the 483 speed for the router to compute the shortest path to every 484 destination is increased dramatically. 486 We may also improve the network availability when we use a TTZ for a 487 POP. In the case that a link or a router in the POP is down, the 488 traffic may be interrupted without using any TTZ for the POP. The 489 link state information about the link or router down needs to be 490 distributed to every router in the network, and every router needs to 491 compute the shortest path to every destination and download the path 492 to its FIB. The traffic is forwarded according to the latest FIB on 493 every router. During this process, there may be inconsist views on 494 the network topology on different routers. 496 The traffic interruption is minimized if we use a TTZ for the POP. 497 The link state information about the link or router down is hidden 498 from every router outside of the POP, which is not aware of the link 499 or router down in the POP. Thus every router outside of the POP has 500 the same topology view when the link or router is down. It does not 501 compute the shortest path or download the path to its FIB. 503 3.4. Use of TTZ on Routers in IPRAN 505 The IP RAN provides connectivity for IP-based mobile broadband (MBB) 506 from LTE and 4G base stations. The ratio of MBB subscribers to total 507 mobile subscribers keeps growing fast. It is expected to grow to 508 nearly 40% in 2016 from 15% in 2011. 510 At the end of 2012, China Mobile had deployed more than 500,000 nodes 511 to support MBB services according to PTN Market Research 2013 Frost & 512 Sullivan. The size of the IP RAN network must seamlessly scale from 513 tens of thousands to hundreds of thousands of nodes. 515 OSPF TTZ may be used in a big IP RAN network for reducing the 516 partition of the network into more OSPF areas. Thus, the network can 517 smoothly scale to hundreds of thousands of nodes. In addition, OSPF 518 TTZ can make the operation and maintenance of the network easier. 520 3.5. Use of TTZ on Routers from Same Vendor 522 In a network, we may separate the routers from different vendors 523 through using TTZ in order to alleviate the possible multi-vendor 524 inter-operability issue. For example, the routers from a same vendor 525 can be configured as a TTZ, and the routers outside of this TTZ are 526 developed by different vendors. 528 3.6. Use of TTZ on Routers in a Power Saving Group 530 A power saving group is a set of routers and links, wherein the 531 routers are connected through the links and there is a redundant 532 route or path from a router in the group to another router in the 533 group. The redundant path is within the group. That is that every 534 hop in the redundant path is within the group. 536 In a power saving group, when the usage of a link within the group 537 between two routers crosses a given threshold value for shutting down 538 the link to save energy, the link will be shut down. This link down 539 in the power saving group will not be distributed to any router 540 outside of the group. The traffic outside of the group will not be 541 affected by the link down inside the group. 543 From the characteristics of a power saving group, we can see that a 544 power saving group is very suitable to be configured as a TTZ. 546 4. Security Considerations 548 This document does not introduce any new security issues. 550 5. Contributors 552 Yuanbin Yin 553 Huawei Technologies 554 Beijing, 555 China 556 Email: yinyuanbin@huawei.com 558 6. Acknowledgement 560 The authors would like to thank Alvaro Retana, Acee Lindem, and Dean 561 Cheng for their valuable comments on this draft. 563 7. References 565 7.1. Normative References 567 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 568 Requirement Levels", BCP 14, RFC 2119, March 1997. 570 [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998. 572 [RFC2740] Coltun, R., Ferguson, D., and J. Moy, "OSPF for IPv6", 573 RFC 2740, December 1999. 575 7.2. Informative References 577 [RFC2370] Coltun, R., "The OSPF Opaque LSA Option", RFC 2370, 578 July 1998. 580 [RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering 581 (TE) Extensions to OSPF Version 2", RFC 3630, 582 September 2003. 584 [RFC5786] Aggarwal, R. and K. Kompella, "Advertising a Router's 585 Local Addresses in OSPF Traffic Engineering (TE) 586 Extensions", RFC 5786, March 2010. 588 [OSPF-TTZ] 589 Chen, H., Li, R., Cauchie, G., So, N., and L. Liu, "OSPF 590 Topology-Transparent Zone", draft-chen-ospf-ttz, Work in 591 Progress, July 2012. 593 Authors' Addresses 595 Huaimo Chen 596 Huawei Technologies 597 Boston, MA 598 USA 600 Email: huaimo.chen@huawei.com 601 Renwei Li 602 Huawei Technologies 603 2330 Central expressway 604 Santa Clara, CA 605 USA 607 Email: renwei.li@huawei.com 609 Gregory Cauchie 610 FRANCE 612 Email: greg.cauchie@gmail.com 614 Ning So 615 Tata Communications 616 2613 Fairbourne Cir. 617 Plano, TX 75082 618 USA 620 Email: ningso01@gmail.com 622 Vic Liu 623 China Mobile 624 No.32 Xuanwumen West Street, Xicheng District 625 Beijing, 100053 626 China 628 Email: liuzhiheng@chinamobile.com 630 Lei Liu 631 UC Davis 632 USA 634 Email: liulei.kddi@gmail.com