idnits 2.17.1 draft-ietf-ospf-ttz-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 : ---------------------------------------------------------------------------- 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 (June 28, 2016) is 2852 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Missing Reference: 'T75' is mentioned on line 203, but not defined == Missing Reference: 'T71' is mentioned on line 205, but not defined == Missing Reference: 'T79' is mentioned on line 205, but not defined == Missing Reference: 'T73' is mentioned on line 206, but not defined == Unused Reference: 'RFC2119' is defined on line 1057, but no explicit reference was found in the text == Unused Reference: 'RFC3630' is defined on line 1072, but no explicit reference was found in the text == Unused Reference: 'RFC5440' is defined on line 1077, but no explicit reference was found in the text Summary: 0 errors (**), 0 flaws (~~), 8 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: December 30, 2016 A. Retana 6 Y. Yang 7 Cisco Systems, Inc. 8 V. Liu 9 China Mobile 10 M. Toy 11 Comcast 12 June 28, 2016 14 OSPF Topology-Transparent Zone 15 draft-ietf-ospf-ttz-04.txt 17 Abstract 19 This document presents a topology-transparent zone in an OSPF area. 20 A topology-transparent zone comprises a group of routers and a number 21 of links connecting these routers. Any router outside of the zone is 22 not aware of the zone. The information about the links and routers 23 such as a link down inside the zone is not advertised to any router 24 outside of the zone. 26 Status of this Memo 28 This Internet-Draft is submitted to IETF in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at http://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on December 30, 2016. 43 Copyright Notice 45 Copyright (c) 2016 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 61 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 62 3. Conventions Used in This Document . . . . . . . . . . . . . . 5 63 4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 5 64 5. Topology-Transparent Zone . . . . . . . . . . . . . . . . . . 5 65 5.1. Overview of Topology-Transparent Zone . . . . . . . . . . 5 66 5.2. TTZ Example . . . . . . . . . . . . . . . . . . . . . . . 6 67 6. Extensions to OSPF Protocols . . . . . . . . . . . . . . . . . 7 68 6.1. General Format of TTZ LSA . . . . . . . . . . . . . . . . 8 69 6.2. TTZ ID TLV . . . . . . . . . . . . . . . . . . . . . . . . 9 70 6.3. TTZ Router TLV . . . . . . . . . . . . . . . . . . . . . . 9 71 6.4. TTZ Options TLV . . . . . . . . . . . . . . . . . . . . . 10 72 6.5. Link Scope TTZ LSA . . . . . . . . . . . . . . . . . . . . 11 73 7. Constructing LSAs for TTZ . . . . . . . . . . . . . . . . . . 12 74 7.1. TTZ Migration Process . . . . . . . . . . . . . . . . . . 13 75 8. Establishing Adjacencies . . . . . . . . . . . . . . . . . . . 14 76 8.1. Discovery of TTZ Neighbors . . . . . . . . . . . . . . . . 14 77 8.2. Adjacency between TTZ Edge and TTZ External Router . . . . 16 78 9. Advertisement of LSAs . . . . . . . . . . . . . . . . . . . . 17 79 9.1. Advertisement of LSAs within TTZ . . . . . . . . . . . . . 17 80 9.2. Advertisement of LSAs through TTZ . . . . . . . . . . . . 17 81 10. Computation of Routing Table . . . . . . . . . . . . . . . . . 17 82 11. Operations . . . . . . . . . . . . . . . . . . . . . . . . . . 18 83 11.1. Configuring TTZ . . . . . . . . . . . . . . . . . . . . . 18 84 11.2. Migration to TTZ . . . . . . . . . . . . . . . . . . . . . 18 85 11.3. Adding a Router into TTZ . . . . . . . . . . . . . . . . . 20 86 12. Manageability Considerations . . . . . . . . . . . . . . . . . 20 87 13. Prototype Implementation . . . . . . . . . . . . . . . . . . . 21 88 13.1. What are Implemented and Tested . . . . . . . . . . . . . 21 89 13.2. Implementation Experience . . . . . . . . . . . . . . . . 22 90 14. Security Considerations . . . . . . . . . . . . . . . . . . . 22 91 15. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 92 16. Contributors and Other Authors . . . . . . . . . . . . . . . . 23 93 17. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 24 94 18. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24 95 18.1. Normative References . . . . . . . . . . . . . . . . . . . 24 96 18.2. Informative References . . . . . . . . . . . . . . . . . . 25 97 Appendix A. Constants for LSA Advertisement . . . . . . . . . . . 25 98 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 25 100 1. Introduction 102 Networks expand as business grows and traffic increases. For 103 scalability and manageability, a hierarchical network architecture is 104 usually deployed in OSPF networks by re-grouping routers into areas, 105 which is often challenging and causes service interruptions. 107 At first, reorganizing a network from one area into multiple areas or 108 from a number of existing areas into even more areas is a very 109 challenging and time consuming task since it involves significant 110 network architecture changes. Considering the one area case, 111 originally the network has only one area, which is the backbone. 112 This original backbone area will be reorganized into a new backbone 113 and a number of non-backbone areas. In general, each of the non- 114 backbone areas is connected to the new backbone area through the Area 115 Border Routers (ABRs) between the non-backbone and the backbone area 116 (refer to RFC 2328 section 3). It demands careful re-designing of 117 network topology in advance to guarantee backbone area continuity and 118 non-backbone area reachability, and requires significant 119 modifications of configurations on many routers to ensure consistent 120 routing. 122 Secondly, the services carried by the network may be interrupted 123 while the network is being reorganized from one area into multiple 124 areas or from a number of existing areas into even more areas since 125 every OSPF interface with an area change is going down with its old 126 area and then up with a new area. 128 This document presents a topology-transparent zone (TTZ) in an OSPF 129 area and describes extensions to OSPF for supporting the topology- 130 transparent zone, which is scalable and resolves the issues above. 132 2. Terminology 134 TTZ link or TTZ internal link: A link whose ends are within a single 135 TTZ. 137 TTZ internal router: A router whose links are TTZ internal links 138 inside a single TTZ. 140 TTZ external router: A router outside of a TTZ that has no TTZ 141 internal links. 143 TTZ external link: A link not configured to be within a TTZ. 145 TTZ edge router: A router is called TTZ edge router if some, but not 146 all, of its links are within a single TTZ. 148 TTZ router: A TTZ internal router or a TTZ edge router. 150 3. Conventions Used in This Document 152 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 153 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 154 document are to be interpreted as described in RFC 2119. 156 4. Requirements 158 A Topology-Transparent Zone may be deployed to resolve some critical 159 issues in existing networks and future networks. The requirements 160 for a TTZ are listed as follows: 162 o Routers outside a TTZ MUST NOT require any changes to operate with 163 the TTZ. 165 o A TTZ MUST be enclosed in a single area. 167 o A TTZ MUST hide the topology of the TTZ from any router outside of 168 the TTZ. 170 5. Topology-Transparent Zone 172 5.1. Overview of Topology-Transparent Zone 174 A Topology-Transparent Zone is identified by a TTZ identifier (ID), 175 and it consists of a group of routers and a number of links 176 connecting the routers. A TTZ MUST be contained within an OSPF area. 178 A TTZ ID is a 32-bit number that is unique for identifying a TTZ. 179 The TTZ ID SHOULD NOT be 0. 181 In addition to having similar functions of an OSPF area, an OSPF TTZ 182 makes some improvements on an OSPF area, which include: 184 o An OSPF TTZ represents a set of TTZ edge routers, connected by a 185 full mesh of virtual connections between them. 187 o Non-TTZ link state information is handled as normal. TTZ Routers 188 receive the link state information about the topology outside of 189 the TTZ, store the information, and flood the information through 190 the TTZ to the routers outside of the TTZ. 192 5.2. TTZ Example 194 The figure below shows an area containing a TTZ: TTZ 600. 196 TTZ 600 ---- TTZ Internal Link 197 \ ==== Normal Link 198 Area X \ ^~^~^~^~^~^~^~^~^~^~^~^~ 199 ( ) 200 ===[R15]========(==[T61]----[T81]---[T63]==)======[R29]=== 201 || ( | \ / | ) || 202 || ( | \ / | ) || 203 || ( [T75] \ / | ) || 204 || ( | ___\ / | ) || 205 || ( | / [T71] [T79] ) || 206 || ( | [T73] / \ | ) || 207 || ( | / \ | ) || 208 || ( | / \ | ) || 209 || ( | / \ | ) || 210 ===[R17]========(==[T65]---[T77]----[T67]==)======[R31]=== 211 \\ (// \\) // 212 || //v~v~v~v~v~v~v~v~v~v~v~\\ || 213 || // \\ || 214 || // \\ || 215 \\ // \\ // 216 ======[R23]==============================[R25]===== 217 // \\ 218 // \\ 220 All the routers in the figure are in area X. Routers with T (i.e., 221 T61, T63, T65, T67, T71, T73, T75, T77, T79 and T81) are also in TTZ 222 600, which contains the TTZ internal links connecting them. To 223 create a TTZ, we need configure it (refer to section 11). 225 There are two types of routers in a TTZ: TTZ internal and TTZ edge 226 routers. TTZ 600 has four TTZ edge routers T61, T63, T65 and T67. 227 Each of them has at least one adjacent router in TTZ 600 and one 228 adjacent router outside of TTZ 600. For instance, router T61 is a 229 TTZ edge router since it has an adjacent router R15 outside of TTZ 230 600 and three adjacent routers T75, T71 and T81 in TTZ 600. 232 In addition, TTZ 600 comprises six TTZ internal routers T71, T73, 233 T75, T77, T79 and T81. Each of them has all its adjacent routers in 234 TTZ 600. For instance, router T71 is a TTZ internal router since its 235 adjacent routers T61, T63, T65, T67 and T73 are all in TTZ 600. It 236 should be noted that by definition, a TTZ internal router cannot also 237 be an ABR. 239 A TTZ hides the internal topology of the TTZ from the outside. It 240 does not directly advertise any internal information about the TTZ to 241 a router outside of the TTZ. 243 For instance, TTZ 600 does not send the information about TTZ 244 internal router T71 to any router outside of TTZ 600; it does not 245 send the information about the link between TTZ router T61 and T71 to 246 any router outside of TTZ 600. 248 The figure below illustrates area X from the point of view on a 249 router outside of TTZ 600 after TTZ 600 is created. 251 Area X ==== Normal Link 253 ===[R15]===========[T61]=========[T63]=========[R29]=== 254 || || \\ // || || 255 || || \\ // || || 256 || || \\ // || || 257 || || \\// || || 258 || || //\ || || 259 || || // \\ || || 260 || || // \\ || || 261 || || // \\ || || 262 || || // \\ || || 263 ===[R17]===========[T65]=========[T67]=========[R31]=== 264 \\ // \\ // 265 || // \\ || 266 || // \\ || 267 || // \\ || 268 \\ // \\ // 269 ======[R23]============================[R25]===== 270 // \\ 271 // \\ 273 From a router outside of the TTZ, a TTZ is seen as the TTZ edge 274 routers connected each other. For instance, router R15 sees that 275 T61, T63, T65 and T67 are connected each other. 277 In addition, a router outside of the TTZ sees TTZ edge routers having 278 normal connections to the routers outside of the TTZ. For example, 279 router R15 sees that T61, T63, T65 and T67 have the normal 280 connections to R15, R29, R17 and R23, R25 and R31 respectively. 282 6. Extensions to OSPF Protocols 284 The link state information about a TTZ includes router LSAs, which 285 can be contained and advertised in opaque LSAs [RFC5250] within the 286 TTZ. Some control information regarding a TTZ can also be contained 287 and advertised in opaque LSAs within the TTZ. These opaque LSAs are 288 called TTZ opaque LSAs or TTZ LSAs for short. 290 6.1. General Format of TTZ LSA 292 The following is the general format of a TTZ LSA. It has an LS Type 293 = 10/9 and TTZ-LSA-Type, and contains a number of TLVs. 295 0 1 2 3 296 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 297 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 298 | LS age | Options | LS Type = 10/9| 299 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 300 |TTZ-LSA-Type(9)| Instance ID | 301 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 302 | Advertising Router | 303 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 304 | LS Sequence Number | 305 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 306 | LS checksum | Length | 307 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 308 | | 309 ~ TLVs ~ 310 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 312 Where TTZ-LSA-Type is 9, the exact number is to be assigned by IANA. 314 There are three TTZ LSAs of LS Type 10 defined: 316 o TTZ Router LSA: a TTZ LSA containing a TTZ ID TLV and a TTZ Router 317 TLV. 319 o TTZ Control LSA: a TTZ LSA containing a TTZ ID TLV and a TTZ 320 Options TLV. 322 o TTZ Indication LSA: a TTZ LSA containing a TTZ ID TLV with E = 0, 323 which indicates that the router originating this LSA is a TTZ 324 internal router. 326 There is one TTZ LSA of LS Type 9: 328 o TTZ Discovery LSA: a TTZ LSA containing a TTZ ID TLV and a 329 optional TTZ Options TLV. 331 6.2. TTZ ID TLV 333 A TTZ ID TLV has the following format. It contains a TTZ ID and some 334 flags. 336 0 1 2 3 337 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 338 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 339 | TTZ-ID-TLV-Type (1) | TLV-Length | 340 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 341 | TTZ ID | 342 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 343 | Reserved (MUST be zero) |E|Z| 344 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 345 E = 1: Indicating a router is a TTZ Edge router 346 Z = 1: Indicating a router has migrated to TTZ 348 When a TTZ router originates a TTZ LSA containing a TTZ ID TLV, it 349 sets flag E to 1 in the TTZ ID TLV if it is a TTZ edge router, and to 350 0 if it is a TTZ internal router. It sets flag Z to 1 after it has 351 migrated to TTZ. 353 6.3. TTZ Router TLV 355 The format of a TTZ Router TLV is as follows. It has the same 356 content as a standard OSPF Router LSA (RFC 2328) with the following 357 modifications. 359 0 1 2 3 360 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 361 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 362 | TTZ-RT-TLV-Type (2) | TLV-Length | 363 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 364 | 0 |V|E|B| 0 | # links | 365 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 366 | Link ID | 367 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 368 | Link Data | 369 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 370 | Type | # TOS | metric | 371 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 372 ~ ... ~ 374 For a router link, the existing eight bit Type field for a router 375 link is split into two fields as follows: 377 0 1 2 3 4 5 6 7 378 +---+---+---+---+---+---+---+---+ 379 | I | Type-1 | 380 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 381 I bit flag: 382 1: Router link is a TTZ internal link. 383 0: Router link is a TTZ external link. 384 Type-1: The kind of the link. The values for Type-1 are the same 385 as those for Type defined in RFC 2328 section 12.4.1. 387 6.4. TTZ Options TLV 389 The format of a TTZ Options TLV is as follows. 391 0 1 2 3 392 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 393 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 394 | TTZ-OP-TLV-Type (3) | TLV-Length | 395 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 396 | OP | Reserved (MUST be zero) | 397 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 398 OP Value Meaning (Operation) 399 0x001 (T): Advertising TTZ Topology Information for Migration 400 0x010 (M): Migrating to TTZ 401 0x011 (N): Advertising Normal Topology Information for Rollback 402 0x100 (R): Rolling back from TTZ 404 A OP field of three bits is defined. It may have a value of 0x001 405 for T, 0x010 for M, 0x011 for N, or 0x100 for R, which indicates one 406 of the four operations above. When any of the other values is 407 received, it is ignored. 409 Advertising TTZ Topology Information for Migration (T): After a user 410 configures a TTZ router to advertise TTZ topology information, 411 advertising TTZ topology information for migration is triggered. The 412 TTZ router originates a TTZ Control LSA having a TTZ Options TLV with 413 OP for T. It also originates its other TTZ LSA such as a TTZ router 414 LSA or TTZ indication LSA. When another TTZ router receives the LSA 415 with OP for T, it originates its TTZ LSA as described below. 417 Migrating to TTZ (M): After a user configures a TTZ router to migrate 418 to TTZ, migrating to TTZ is triggered. The TTZ router originates a 419 TTZ Control LSA having a TTZ Options TLV with OP for M and migrates 420 to TTZ. When another TTZ router receives the LSA with OP for M, it 421 also migrates to TTZ. When a router migrates to TTZ, it computes 422 routes using the TTZ topology and the topology outside of the TTZ. 424 For a TTZ internal router, it also updates its TTZ indication LSA 425 with Z = 1. For a TTZ edge router, it updates its TTZ router LSA 426 with Z = 1 and its router LSA for virtualizing the TTZ. 428 Advertising Normal Topology Information for Rollback (N): After a 429 user configures a TTZ router to advertise normal topology 430 information, advertising Normal topology information for rollback is 431 triggered. The TTZ router originates a TTZ Control LSA having a TTZ 432 Options TLV with OP for N. It also advertises its normal LSAs such as 433 its normal router LSA and stops advertising its other TTZ LSAs. When 434 another TTZ router receives the LSA with OP for N, it advertises its 435 normal LSAs and stops advertising its TTZ LSAs. 437 Rolling back from TTZ (R): After a user configures a TTZ router to 438 roll back from TTZ, rolling back from TTZ is triggered. The TTZ 439 router originates a TTZ Control LSA having a TTZ Options TLV with OP 440 for R and rolls back from TTZ. When another TTZ router receives the 441 LSA with OP for R, it also rolls back from TTZ. 443 After a TTZ router originates a TTZ control LSA in response to a 444 configuration described above to control TTZ, it flushes the TTZ 445 control LSA if OP in the LSA is set for the configuration and the 446 configuration is removed. 448 6.5. Link Scope TTZ LSA 450 A TTZ LSA of LS Type 9 has the following format. 452 0 1 2 3 453 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 454 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 455 | LS age | Options | LS Type = 9 | 456 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 457 |TTZ-LSA-Type(9)| Instance ID | 458 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 459 | Advertising Router | 460 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 461 | LS Sequence Number | 462 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 463 | LS checksum | Length | 464 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 465 | | 466 ~ TTZ ID TLV ~ 467 +---------------------------------------------------------------+ 468 | | 469 ~ (TTZ Options TLV) ~ 470 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 472 It contains a mandatory TTZ ID TLV, which may be followed by a 473 optional TTZ Options TLV. It is used to discover a TTZ neighbor. 475 7. Constructing LSAs for TTZ 477 For a TTZ, its topology is represented by the LSAs generated by its 478 TTZ routers for the link states in the TTZ, which include TTZ router 479 LSAs, TTZ indication LSAs, normal router LSAs and network LSAs. The 480 TTZ router LSAs and TTZ indication LSAs are generated after 481 advertising TTZ topology information for migration is triggered. 483 A TTZ router LSA generated by a TTZ edge router has a TTZ ID TLV and 484 a TTZ Router TLV. The former includes the ID of the TTZ to which the 485 router belongs and flag E set to 1, which indicates the originator of 486 the LSA is a TTZ Edge router. For a TTZ edge router, its normal 487 Router LSA content is copied into a TTZ Router TLV with the 488 modifications described in section 6, and a TTZ router LSA containing 489 this TLV is constructed and advertised. 491 A TTZ indication LSA generated by a TTZ internal router has a TTZ ID 492 TLV containing the ID of the TTZ to which the router belongs and flag 493 E set to 0, which indicates the originator of the LSA is a TTZ 494 internal router. For a TTZ internal router, its regular Router LSA 495 is still generated. If a TTZ router is a DR, it originates its 496 regular network LSA. 498 After receiving a trigger to migrate to TTZ such as a TTZ control LSA 499 with OP for M, a TTZ edge router originates its normal router LSA for 500 virtualizing a TTZ, which comprises three groups of links in general. 502 The first group are the router links connecting the TTZ external 503 routers. These router links are normal router links. There is a 504 router link for every adjacency between this TTZ edge router and a 505 TTZ external router. 507 The second group are the "virtual" router links connecting to the 508 other TTZ edge routers. For each of the other TTZ edge routers, 509 there is a corresponding point-to-point router link to it from this 510 TTZ edge router. The cost of the link is the cost of the shortest 511 path from this TTZ edge router to the other TTZ edge router within 512 the TTZ. 514 In addition, the LSA may contain a third group of links, which are 515 the stub links for the loopback addresses inside the TTZ to be 516 accessed by nodes outside of the TTZ. 518 7.1. TTZ Migration Process 520 After migration to TTZ is triggered, a TTZ router computes routes 521 using its TTZ topology (refer to section 10) and a TTZ edge router 522 originates its normal router LSA for virtualizing the TTZ in two 523 steps: 525 Step 1: The router updates its router LSA by adding a point-to-point 526 link to each of the other known edge routers in the TTZ, and also 527 by adding the stub links for the loopback addresses in the TTZ to 528 be accessed outside of the TTZ. 530 Step 2: After MaxLSAGenAdvTime (0.3 s) or sr-time + MaxLSAAdvTime 531 (0.1 s), it removes the TTZ links from its router LSA, where sr- 532 time is the time from updating its router LSA to receiving the ack 533 for its router LSA and receiving the updated router LSAs 534 originated by the other TTZ edge routers. In other words, it 535 removes the TTZ links from its router LSA after sending its 536 updated router LSA and receiving the updated router LSAs 537 originated by the other TTZ edge routers for MaxLSAAdvTime or 538 after sending its updated router LSA for MaxLSAGenAdvTime (refer 539 to Appendix A). 541 This is to avoid a possible short route down or change in a TTZ 542 external router while the TTZ is being virtualized. If each TTZ edge 543 router originates its router LSA by adding its point-to-point links 544 to the other TTZ edge routers and removing its TTZ links in one step, 545 a route taking a path through the TTZ in the TTZ external router may 546 be down or changed before all the router LSAs generated by the TTZ 547 edge routers reach the TTZ external router. When the TTZ external 548 router computes routes with some router LSAs originated by the TTZ 549 edge routers, bi-directional check for some of the point-to-point 550 links will fail. Thus the route taking the path through the shortest 551 path for the point-to-point link failing the bi-directional check 552 will be down or changed. 554 To roll back from a TTZ smoothly after receiving a trigger to roll 555 back from TTZ, a TTZ edge router originates its normal router LSA in 556 the above two steps in a reverse way. 558 Step 1: Initially, it updates its normal router LSA by adding the 559 normal links for the links configured as TTZ links into the LSA. 561 Step 2: It then removes the point-to-point links to the other edge 562 routers of the TTZ for virtualizing the TTZ and the stub links for 563 the loopback addresses from its updated router LSA after sending 564 its updated router LSA and receiving the updated router LSAs 565 originated by the other TTZ edge routers for MaxLSAAdvTime or 566 after sending its updated router LSA for MaxLSAGenAdvTime. 568 8. Establishing Adjacencies 570 This section describes the TTZ adjacencies. 572 8.1. Discovery of TTZ Neighbors 574 For two routers A and B connected by a P2P link and having a normal 575 adjacency, they TTZ discover each other through a TTZ LSA of LS Type 576 9 with a TTZ ID TLV. We call this LSA D-LSA for short. 578 If two ends of the link have different TTZ IDs or only one end is 579 configured with TTZ ID, no TTZ adjacency over the link will be 580 "formed". 582 If two ends of the link have the same TTZ ID and Z flag value, A and 583 B are TTZ neighbors. The following is a sequence of events related 584 to TTZ for this case. 586 A B 587 Configure TTZ Configure TTZ 588 D-LSA (TTZ-ID=100) 589 ----------------------> Same TTZ ID and Z 590 A is B's TTZ Neighbor 591 D-LSA (TTZ-ID=100) 592 Same TTZ ID and Z <---------------------- 593 B is A's TTZ Neighbor 595 A sends B a D-LSA with TTZ-ID after the TTZ is configured on it. B 596 sends A a D-LSA with TTZ-ID after the TTZ is configured on it. 598 When A receives the D-LSA from B and determines they have the same 599 TTZ ID and Z flag value, B is A's TTZ neighbor. A also sends B all 600 the TTZ LSAs it has and originates its TTZ LSA when one of the 601 following conditions is met. 603 o Z = 0 and there is a TTZ LSA with OP for T. 605 o Z = 1. 607 B is symmetric to A and acts similarly to A. 609 If two ends of the link have the same TTZ ID but Z flags are 610 different, a TTZ adjacency over the link is "formed" in the following 611 steps. Suppose that A has migrated to TTZ and B has not (i.e., flag 612 Z in A's D-LSA is 1 and flag Z in B's D-LSA is 0). 614 A B 615 Configure TTZ Configure TTZ 616 D-LSA(TTZ-ID=100,Z=1) 617 ----------------------> Same TTZ ID, but 618 different Z 619 A is B's TTZ Neighbor 620 D-LSA(TTZ-ID=100,Z=0) 621 Same TTZ ID, but <---------------------- 622 different Z 623 B is A's TTZ Neighbor 624 TTZ LSAs 625 -----------------------> 626 TTZ LSAs 627 <----------------------- 629 When A receives the D-LSA from B and determines they have the same 630 TTZ ID but its Z = 1 and B's Z = 0, A sends B all the TTZ LSAs it has 631 and triggers B to migrate to TTZ. A updates and sends B its D-LSA by 632 adding an TTZ Options TLV with OP for M after sending B all the TTZ 633 LSAs. 635 D-LSA(TTZ-ID=100,OP=M) 636 Add TTZ Options -----------------------> Migrate to TTZ 637 TLV with OP for M 638 D-LSA(TTZ-ID=100,Z=1) Migrated to TTZ 639 <----------------------- Set Z=1 641 D-LSA(TTZ-ID=100,Z=1) 642 Remove -----------------------> 643 TTZ Options TLV 645 When B receives the D-LSA from A and determines they have the same 646 TTZ ID but its Z = 0 and A's Z = 1, B sends A all the TTZ LSAs it 647 has. 649 When B receives the D-LSA from A with OP for M, it starts to migrate 650 to TTZ. B updates and advertises its LSAs as needed. 652 After receiving B's D-LSA with Z = 1, A updates and sends B its D-LSA 653 by removing the TTZ Options TLV. It also updates and advertises its 654 LSAs as needed. 656 For a number of routers connected through a broadcast link and having 657 normal adjacencies among them, they also TTZ discover each other 658 through D-LSAs. The DR for the link "forms" TTZ adjacencies with the 659 other routers if all the routers attached to the link have the same 660 TTZ ID configured on the connections to the link. Otherwise, the DR 661 does not "form" any TTZ adjacency with any router attached to the 662 link. 664 For a number of routers connected through a broadcast link and having 665 TTZ adjacencies among them, if a mis-configured router is introduced 666 on the broadcast link, the DR for the link will not "form" any TTZ 667 adjacency with this mis-configured router. 669 For routers connected via a link without any adjacency among them, 670 they TTZ discover each other through D-LSAs in the same way as 671 described above after they form a normal adjacency. 673 A TTZ adjacency over a link is removed when one of the following 674 events happens. 676 o TTZ ID on one end of the link is changed to a different one. 678 o TTZ ID on one end of the link is removed. 680 o D-LSA is not received for sometime such as 60 minutes or is 681 flushed. 683 o Normal adjacency over the link is down. 685 When the TTZ ID on one end of the link is removed, the corresponding 686 D-LSA is flushed. 688 8.2. Adjacency between TTZ Edge and TTZ External Router 690 A TTZ edge router forms an adjacency with any TTZ external router to 691 which it is connected. 693 When the TTZ edge router synchronizes its link state database with 694 the TTZ external router, it sends the TTZ external router the 695 information about all the LSAs except for the LSAs belonging to the 696 TTZ that are hidden from any router outside of the TTZ. 698 At the end of the link state database synchronization, the TTZ edge 699 router originates its own router LSA for virtualizing the TTZ and 700 sends this LSA to its adjacent routers including the TTZ external 701 router. 703 9. Advertisement of LSAs 705 LSAs can be divided into a couple of classes according to their 706 Advertisements. The first class of LSAs is advertised within a TTZ. 707 The second is advertised through a TTZ. 709 9.1. Advertisement of LSAs within TTZ 711 Any LSA about a link state in a TTZ is advertised only within the 712 TTZ. It is not advertised to any router outside of the TTZ. For 713 example, a router LSA generated for a TTZ internal router is 714 advertised only within the TTZ. 716 Any network LSA generated for a broadcast or NBMA network in a TTZ is 717 advertised only within the TTZ. It is not advertised outside of the 718 TTZ. 720 Any opaque LSA generated for a TTZ internal TE link is advertised 721 only within the TTZ. 723 After migrating to TTZ, every edge router of a TTZ MUST NOT advertise 724 any LSA about a link state in the TTZ to any router outside of the 725 TTZ. 727 For any TTZ LSA originated by a router within the TTZ, every edge 728 router of the TTZ MUST NOT advertise it to any router outside of the 729 TTZ. 731 9.2. Advertisement of LSAs through TTZ 733 Any LSA about a link state outside of a TTZ received by an edge 734 router of the TTZ is advertised using the TTZ as transit. For 735 example, when an edge router of a TTZ receives an LSA from a router 736 outside of the TTZ, it floods it to its neighboring routers both 737 inside the TTZ and outside of the TTZ. This LSA may be any LSA such 738 as a router LSA that is advertised within an OSPF area. 740 The routers in the TTZ continue to flood the LSA. When another edge 741 router of the TTZ receives the LSA, it floods the LSA to its 742 neighboring routers both outside of the TTZ and inside the TTZ. 744 10. Computation of Routing Table 746 After a router migrates to TTZ, the computation of the routing table 747 on the router is the same as that described in RFC 2328 section 16 748 with one exception. The router in a TTZ ignores the router LSAs 749 generated by the TTZ edge routers for virtualizing the TTZ. This can 750 be achieved by adding a flag into every link stored in LSDB and 751 setting this flag to 1 in every link in these router LSAs, which 752 indicates that the link is unusable. It computes routes using the 753 TTZ topology (i.e., using LSAs for representing the TTZ) and the 754 topology outside of the TTZ, excluding any unusable links. The LSAs 755 for representing a TTZ are described in Section 7. 757 11. Operations 759 11.1. Configuring TTZ 761 This section proposes some options for configuring a TTZ. 763 1. Configuring TTZ on Every Link in TTZ 765 If every link in a TTZ is configured with a same TTZ ID as a TTZ 766 link, the TTZ is determined. A router with some TTZ links and some 767 normal links is a TTZ edge router. A router with only TTZ links is a 768 TTZ internal router. 770 2. Configuring TTZ on Every Router in TTZ 772 A same TTZ ID is configured on every router in a TTZ, and on every 773 TTZ edge router's links connecting to the routers in the TTZ. 775 A router configured with the TTZ ID on some of its links is a TTZ 776 edge router. A router configured with the TTZ ID only is a TTZ 777 internal router. All the links on a TTZ internal router are TTZ 778 links. This option is simpler than option 1 above. 780 11.2. Migration to TTZ 782 For a group of routers and a number of links connecting the routers 783 in an area, making them transfer to work as a TTZ without any service 784 interruption takes a few of steps or stages. 786 At first, a user configures the TTZ feature on every router in the 787 TTZ. In this stage, a router does not originate or advertise its TTZ 788 topology information. It will discover its TTZ neighbors. 790 Secondly, after configuring the TTZ, a user issues a CLI command on 791 one router in the TTZ, which triggers every router in the TTZ to 792 generate and advertise TTZ information among the routers in the TTZ. 793 When the router receives the command, it originates a TTZ control LSA 794 with OP for T (indicating TTZ information generation and 795 advertisement for migration). It also originates its TTZ LSA such as 796 TTZ router LSA or TTZ indication LSA, and advertises the LSA to its 797 TTZ neighbors. When another router in the TTZ receives the LSA with 798 OP for T, it originates its TTZ LSA. In this stage, every router in 799 the TTZ has dual roles. One is to function as a normal router. The 800 other is to generate and advertise TTZ information. 802 Thirdly, a user checks whether a router in the TTZ is ready for 803 migration to TTZ. A router in the TTZ is ready after it has received 804 all the necessary information from all the routers in the TTZ. This 805 information may be displayed on a router through a CLI command. 807 And then a user activates the TTZ through using a CLI command such as 808 migrate to TTZ on one router in the TTZ. The router migrates to TTZ, 809 generates and advertises a TTZ control LSA with OP for M (indicating 810 Migrating to TTZ) after it receives the command. After another 811 router in the TTZ receives the TTZ control LSA with OP for M, it also 812 migrates to TTZ. Thus, activating the TTZ on one TTZ router 813 propagates to every router in the TTZ, which migrates to TTZ. 815 For an edge router of the TTZ, migrating to work as a TTZ router 816 comprises generating a router LSA to virtualize the TTZ and flooding 817 this LSA to all its neighboring routers in two steps as described in 818 section 7. 820 In normal operations for migration to TTZ and rollback from TTZ, a 821 user issues a series of commands according to certain procedures. In 822 an abnormal case, for example two conflicting commands are issued on 823 two TTZ routers in a TTZ at the same time, a TTZ router issues an 824 error and logs the error when it detects a conflict. 826 A conflicting command may be detected on a router on which the 827 command is issued. Thus some abnormal cases may be prevented. When 828 a command for migration/rollback is issued on a router, the router 829 checks whether it is in a correct sequence of commands for migration/ 830 rollback through using the information it has. For migrating a part 831 of an area to a TTZ, the correct sequence of commands is as follows 832 in general: 834 1) configure TTZ on every router in the part of the area to be 835 migrated to TTZ; 837 2) configure on one router in the TTZ to trigger every router in the 838 TTZ to generate and advertise TTZ information for migration; and 840 3) configure on one router in the TTZ to trigger every router in the 841 TTZ to migrate to TTZ. 843 For rolling back from TTZ, it is similar. 845 After receiving a command on a router to migrate to TTZ, which is for 846 3), the router checks whether 2) is performed through checking if it 847 has received/originated TTZ LSAs. If it has not, it issues an error 848 to an operator (generation and advertisement of TTZ information for 849 migration to TTZ is not done yet) and rejects the command at this 850 time. 852 After a router receives a TTZ LSA with OP for M for 3) from another 853 router, it checks whether 2) is performed through checking if it has 854 received/originated TTZ LSAs. If it has not, it issues an error and 855 logs the error. The operation for migration will continue. 857 After receiving a command on a router to generate and advertise TTZ 858 information, which is for 2), the router checks whether 1) is 859 performed through checking if TTZ is configured on it. If it is not, 860 it issues an error to an operator (TTZ is not configured on it yet) 861 and rejects the command at this time. 863 11.3. Adding a Router into TTZ 865 When a non TTZ router (say R1) is connected via a P2P link to a 866 migrated TTZ router (say T1), and there is a normal adjacency between 867 them over the link, a user can configure TTZ on both ends of the link 868 to add R1 into the TTZ to which T1 belongs. They TTZ discover each 869 other as described in section 8. 871 When a number of non TTZ routers are connected via a broadcast or 872 NBMA link to a migrated TTZ router (say T1), and there are normal 873 adjacencies among them, a user configures TTZ on the connection to 874 the link on every router to add the non TTZ routers into the TTZ to 875 which T1 belongs. The DR for the link "forms" TTZ adjacencies with 876 the other routers connected to the link if they all have the same TTZ 877 ID configured for the link. This is determined through the TTZ 878 discovery process described in section 8. 880 12. Manageability Considerations 882 Section 11 (Operations) outlines the configuration process and 883 deployment scenarios for a TTZ. The configurable item is enabling a 884 TTZ on a router and/or an interface on a router. The TTZ function 885 may be controlled by a policy module and assigned a suitable user 886 privilege level to enable. A suitable model may be required to 887 verify the TTZ status on routers participating in the TTZ, including 888 their role as internal or edge TTZ router. The mechanisms defined in 889 this document do not imply any new liveness detection and monitoring 890 requirements in addition to those indicated in [RFC2328]. 892 13. Prototype Implementation 894 13.1. What are Implemented and Tested 896 1. CLI Commands for TTZ 898 The CLIs implemented and tested include: 900 o the CLIs of the simpler option for configuring TTZ, and 902 o the CLIs for controlling migration to TTZ. 904 2. Extensions to OSPF Protocols for TTZ 906 All the extensions defined in section "Extensions to OSPF Protocols" 907 are implemented and tested except for rolling back from TTZ. The 908 testing results illustrate: 910 o A TTZ is virtualized to outside as its edge routers connected each 911 other. Any router outside of the TTZ sees the edge routers (as 912 normal routers) connecting each other and to some other routers. 914 o The link state information about the routers and links inside the 915 TTZ is contained within the TTZ. It is not advertised to any 916 router outside of the TTZ. 918 o TTZ is transparent. From a router inside a TTZ, it sees the 919 topology (link state) outside of the TTZ. From a router outside 920 of the TTZ, it sees the topology beyond the TTZ. The link state 921 information outside of the TTZ is advertised through the TTZ. 923 o TTZ is backward compatible. Any router outside of a TTZ does not 924 need to support or know TTZ. 926 3. Smooth Migration to TTZ 928 The procedures and related protocol extensions for smooth migration 929 to TTZ are implemented and tested. The testing results show: 931 o A part of an OSPF area is smoothly migrated to a TTZ without any 932 routing disruptions. The routes on every router are stable while 933 the part of the area is being migrated to the TTZ. 935 o Migration to TTZ is very easy to operate. 937 4. Add a Router to TTZ 939 Adding a router into TTZ is implemented and tested. The testing 940 results illustrate: 942 o A router can be easily added into a TTZ and becomes a TTZ router. 944 o The router added into the TTZ is not seen on any router outside of 945 the TTZ, but it is a part of the TTZ. 947 5. Leak TTZ Loopbacks Outside 949 Leaking loopback addresses in a TTZ to routers outside of the TTZ is 950 implemented and tested. The testing results illustrate: 952 o The loopback addresses inside the TTZ are advertised to the 953 routers outside of the TTZ. 955 o The loopback addresses are accessible from a router outside of the 956 TTZ. 958 13.2. Implementation Experience 960 The implementation of TTZ is relatively easy compared to other 961 features of OSPF. Re-using the existing OSPF code along with 962 additional simple logic does the work. A couple of engineers started 963 to work on implementing the TTZ from the middle of June, 2014 and 964 finished coding it just before the end of July, 2014. After some 965 testing and bug fixes, it works as expected. 967 In our implementation, the link state information in a TTZ opaque LSA 968 is stored in the same link state database as the link state 969 information in a normal LSA. For each TTZ link in the TTZ opaque 970 LSA, there is an additional flag, which is used to differentiate 971 between a TTZ link and a Normal link. 973 Before migration to TTZ, every router in the TTZ computes its routing 974 table using the normal links. After migration to TTZ, every router 975 in the TTZ computes its routing table using the TTZ links and normal 976 links. In the case where both the TTZ link and the normal link 977 exist, the TTZ link is used. 979 14. Security Considerations 981 The mechanism described in this document does not raise any new 982 security issues for the OSPF protocols since a TTZ is enclosed in a 983 single area. TTZ relies on the OSPF security mechanisms in place and 984 has the same security threat surface. 986 15. IANA Considerations 988 Under Registry Name: Opaque Link-State Advertisements (LSA) Option 989 Types [RFC5250], IANA is requested to assign a new Opaque type 990 registry value for Topology-Transparent Zone (TTZ) LSA as follows: 992 +====================+===============+=======================+ 993 | Registry Value | Opaque Type | reference | 994 +====================+===============+=======================+ 995 | IANA TBD | TTZ LSA | This document | 996 | (9 Suggested) | | | 997 +--------------------+---------------+-----------------------+ 999 IANA is requested to assign Types for new TLVs in the new TTZ LSA as 1000 follows: 1002 Type Name Allowed in 1003 1 TTZ ID TLV TTZ LSA of LS Type 10 and 9 1004 2 TTZ Router TLV TTZ LSA of LS Type 10 1005 3 TTZ Options TLV TTZ LSA of LS Type 10 and 9 1007 16. Contributors and Other Authors 1009 1. Other Authors 1011 Gregory Cauchie 1012 FRANCE 1013 Email: greg.cauchie@gmail.com 1015 Anil Kumar S N 1016 Huawei Technologies 1017 Banglore 1018 India 1019 Email: anil.sn@huawei.com 1021 Ning So 1022 Tata Communications 1023 2613 Fairbourne Cir. 1024 Plano, TX 75082 1025 USA 1026 Email: ningso01@gmail.com 1027 Lei Liu 1028 Fujitsu 1029 USA 1030 Email: lliu@us.fujitsu.com 1032 2. Contributors 1034 Veerendranatha Reddy Vallem 1035 Huawei Technologies 1036 Banglore 1037 India 1038 Email: veerendranatharv@huawei.com 1040 William McCall 1041 Rightside Co. 1042 Kirkland, WA 1043 USA 1044 will.mccall@rightside.co 1046 17. Acknowledgement 1048 The authors would like to thank Acee Lindem, Abhay Roy, Christian 1049 Hopps, Dean Cheng, Russ White, Tony Przygienda, Wenhu Lu, Lin Han, 1050 Kiran Makhijani, Padmadevi Pillay Esnault and Yang Yu for their 1051 valuable comments on this draft. 1053 18. References 1055 18.1. Normative References 1057 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1058 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ 1059 RFC2119, March 1997, 1060 . 1062 [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, DOI 10.17487/ 1063 RFC2328, April 1998, 1064 . 1066 [RFC5250] Berger, L., Bryskin, I., Zinin, A., and R. Coltun, "The 1067 OSPF Opaque LSA Option", RFC 5250, DOI 10.17487/RFC5250, 1068 July 2008, . 1070 18.2. Informative References 1072 [RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering 1073 (TE) Extensions to OSPF Version 2", RFC 3630, 1074 DOI 10.17487/RFC3630, September 2003, 1075 . 1077 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 1078 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 1079 DOI 10.17487/RFC5440, March 2009, 1080 . 1082 Appendix A. Constants for LSA Advertisement 1084 MaxLSAAdvTime: The maximum time for an LSA to be advertised to all 1085 the routers in an area. The value of MaxLSAAdvTime is set to 0.1 1086 second. 1088 MaxLSAGenAdvTime: The maximum time for all TTZ router LSAs to be 1089 generated by all TTZ edge routers and advertised to all the routers 1090 in an area after a first TTZ router LSA is generated. The value of 1091 MaxLSAGenAdvTime is set to 0.3 second. 1093 Authors' Addresses 1095 Huaimo Chen 1096 Huawei Technologies 1097 Boston, MA 1098 USA 1100 Email: huaimo.chen@huawei.com 1102 Renwei Li 1103 Huawei Technologies 1104 2330 Central expressway 1105 Santa Clara, CA 1106 USA 1108 Email: renwei.li@huawei.com 1109 Alvaro Retana 1110 Cisco Systems, Inc. 1111 7025 Kit Creek Rd. 1112 Raleigh, NC 27709 1113 USA 1115 Email: aretana@cisco.com 1117 Yi Yang 1118 Cisco Systems, Inc. 1119 7025 Kit Creek Rd. 1120 Raleigh, NC 27709 1121 USA 1123 Email: yiya@cisco.com 1125 Vic Liu 1126 China Mobile 1127 No.32 Xuanwumen West Street, Xicheng District 1128 Beijing, 100053 1129 China 1131 Email: liuzhiheng@chinamobile.com 1133 Mehmet Toy 1134 Comcast 1135 1800 Bishops Gate Blvd. 1136 Mount Laurel, NJ 08054 1137 USA 1139 Email: mehmet_toy@cable.comcast.com