idnits 2.17.1 draft-chen-ospf-ttz-08.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 (July 4, 2014) is 3584 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'R71' is mentioned on line 211, but not defined == Missing Reference: 'R73' is mentioned on line 212, but not defined == Missing Reference: 'GRACE' is mentioned on line 409, but not defined == Missing Reference: 'EXP-TE' is mentioned on line 411, but not defined == Missing Reference: 'OSPF-TTZ' is mentioned on line 412, but not defined == Unused Reference: 'RFC2119' is defined on line 752, but no explicit reference was found in the text == Unused Reference: 'RFC2328' is defined on line 755, but no explicit reference was found in the text == Unused Reference: 'RFC4970' is defined on line 757, but no explicit reference was found in the text == Unused Reference: 'RFC2370' is defined on line 761, but no explicit reference was found in the text == Unused Reference: 'RFC5613' is defined on line 764, but no explicit reference was found in the text ** Obsolete normative reference: RFC 4970 (Obsoleted by RFC 7770) ** Obsolete normative reference: RFC 2370 (Obsoleted by RFC 5250) Summary: 2 errors (**), 0 flaws (~~), 11 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: Standards Track A. Kummar S N 5 Expires: January 5, 2015 Huawei Technologies 6 G. Cauchie 8 A. Retana 9 Cisco Systems, Inc. 10 N. So 11 Tata Communications 12 V. Liu 13 China Mobile 14 M. Toy 15 Comcast 16 L. Liu 17 UC Davis 18 July 4, 2014 20 OSPF Topology-Transparent Zone 21 draft-chen-ospf-ttz-08.txt 23 Abstract 25 This document presents a topology-transparent zone in a domain. A 26 topology-transparent zone comprises a group of routers and a number 27 of links connecting these routers. Any router outside of the zone is 28 not aware of the zone. The information about the links and routers 29 inside the zone is not distributed to any router outside of the zone. 30 Any link state change such as a link down inside the zone is not seen 31 by any router outside of the zone. 33 Status of this Memo 35 This Internet-Draft is submitted to IETF in full conformance with the 36 provisions of BCP 78 and BCP 79. 38 Internet-Drafts are working documents of the Internet Engineering 39 Task Force (IETF). Note that other groups may also distribute 40 working documents as Internet-Drafts. The list of current Internet- 41 Drafts is at http://datatracker.ietf.org/drafts/current/. 43 Internet-Drafts are draft documents valid for a maximum of six months 44 and may be updated, replaced, or obsoleted by other documents at any 45 time. It is inappropriate to use Internet-Drafts as reference 46 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on January 5, 2015. 50 Copyright Notice 52 Copyright (c) 2014 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (http://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the Simplified BSD License. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 68 2. Conventions Used in This Document . . . . . . . . . . . . . . 4 69 3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 4 70 4. Topology-Transparent Zone . . . . . . . . . . . . . . . . . . 4 71 4.1. Overview of Topology-Transparent Zone . . . . . . . . . . 4 72 4.2. An Example of TTZ . . . . . . . . . . . . . . . . . . . . 5 73 5. Changes to OSPF Protocols . . . . . . . . . . . . . . . . . . 6 74 5.1. Opaque LSAs for TTZ . . . . . . . . . . . . . . . . . . . 6 75 5.2. A TTZ Capability TLV in Router Information LSA . . . . . . 9 76 6. Constructing LSAs for TTZ . . . . . . . . . . . . . . . . . . 10 77 7. Establishing Adjacencies . . . . . . . . . . . . . . . . . . . 11 78 7.1. Discover TTZ Neighbor over Normal Adjacency . . . . . . . 11 79 7.2. Establishing TTZ Adjacencies . . . . . . . . . . . . . . . 11 80 7.3. Adjacency between TTZ Edge and Router outside . . . . . . 12 81 8. Distribution of LSAs . . . . . . . . . . . . . . . . . . . . . 12 82 8.1. Distribution of LSAs within TTZ . . . . . . . . . . . . . 13 83 8.2. Distribution of LSAs through TTZ . . . . . . . . . . . . . 13 84 9. Computation of Routing Table . . . . . . . . . . . . . . . . . 13 85 10. Operations . . . . . . . . . . . . . . . . . . . . . . . . . . 13 86 10.1. Configuring TTZ . . . . . . . . . . . . . . . . . . . . . 13 87 10.2. Smooth Migration to TTZ . . . . . . . . . . . . . . . . . 14 88 10.3. Adding a Router into TTZ . . . . . . . . . . . . . . . . . 15 89 11. Security Considerations . . . . . . . . . . . . . . . . . . . 16 90 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 91 13. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 16 92 14. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 17 93 15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 94 15.1. Normative References . . . . . . . . . . . . . . . . . . . 17 95 15.2. Informative References . . . . . . . . . . . . . . . . . . 17 96 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17 98 1. Introduction 100 The number of routers in a network becomes larger and larger as the 101 Internet traffic keeps growing. Through splitting the network into 102 multiple areas, we can extend the network further. However, there 103 are a number of issues when a network is split further into more 104 areas. 106 At first, dividing a network from one area into multiple areas or 107 from a number of existing areas to even more areas is a very 108 challenging and time consuming task since it is involved in 109 significant network architecture changes. Considering the one area 110 case, originally the network has only one area, which is the 111 backbone. This original backbone area will be split into a new 112 backbone and a number of non backbone areas. In general, each of the 113 non backbone areas is connected to the new backbone area through the 114 area border routers between the non backbone and the backbone area. 115 There is not any direct connection between any two non backbone 116 areas. Each area border router summarizes the topology of its 117 attached non backbone area for transmission on the backbone area, and 118 hence to all other area border routers. 120 Secondly, the services carried by the network may be interrupted 121 while the network is being split from one area into multiple areas or 122 from a number of existing areas into even more areas. 124 Furthermore, it is complex for a Multi-Protocol Label Switching 125 (MPLS) Traffic Engineering (TE) Label Switching Path (LSP) crossing 126 multiple areas to be setup. In one option, a TE path crossing 127 multiple areas is computed by using collaborating Path Computation 128 Elements (PCEs) [RFC5441] through the PCE Communication Protocol 129 (PCEP)[RFC5440], which is not easy to configure by operators since 130 the manual configuration of the sequence of domains is required. 131 Although this issue can be addressed by using the Hierarchical PCE, 132 this solution may further increase the complexity of network design. 133 Especially, the current PCE standard method may not guarantee that 134 the path found is optimal. 136 This document presents a topology-transparent zone in an area and 137 describes extensions to OSPF for supporting the topology-transparent 138 zone, which is scalable and resolves the issues above. 140 A topology-transparent zone comprises a group of routers and a number 141 of links connecting these routers. Any router outside of the zone is 142 not aware of the zone. The information about the links and routers 143 inside the zone is not distributed to any router outside of the zone. 144 Any link state change such as a link down inside the zone is not seen 145 by any router outside of the zone. 147 2. Conventions Used in This Document 149 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 150 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 151 document are to be interpreted as described in RFC 2119. 153 3. Requirements 155 Topology-Transparent Zone (TTZ) may be deployed for resolving some 156 critical issues in existing networks and future networks. The 157 requirements for TTZ are listed as follows: 159 o TTZ MUST be backward compatible. When a TTZ is deployed on a set 160 of routers in a network, the routers outside of the TTZ in the 161 network do not need to know or support TTZ. 163 o TTZ MUST support at least one more levels of network hierarchies, 164 in addition to the hierarchies supported by existing routing 165 protocols. 167 o Users SHOULD be able to easily set up an end to end service 168 crossing TTZs. 170 o The configuration for a TTZ in a network SHOULD be minimum. 172 o The changes on the existing protocols for supporting TTZ SHOULD be 173 minimum. 175 4. Topology-Transparent Zone 177 4.1. Overview of Topology-Transparent Zone 179 A Topology-Transparent Zone (TTZ) is identified by an Identifier 180 (ID), and it includes a group of routers and a number of links 181 connecting the routers. A TTZ is in an OSPF area. 183 The ID of a Topology-Transparent Zone (TTZ) or TTZ ID is a number 184 that is unique for identifying an entity such as a node in an OSPF 185 domain. It is not zero in general. 187 In addition to having the functions of an OSPF area, an OSPF TTZ 188 makes some improvements on an OSPF area, which include: 190 o An OSPF TTZ is virtualized as a group of TTZ edge routers 191 connected. 193 o An OSPF TTZ receives the link state information about the topology 194 outside of the TTZ, stores the information in the TTZ and floods 195 the information through the TTZ to the routers outside of TTZ. 197 4.2. An Example of TTZ 199 The figure below illustrates an example of a routing area containing 200 a topology-transparent zone: TTZ 600. 202 TTZ 600 203 \ 204 \ ^~^~^~^~^~^~^~^~^~^~^~^~ 205 ( ) 206 ===[R15]========(==[R61]------------[R63]==)======[R29]=== 207 || ( | \ / | ) || 208 || ( | \ / | ) || 209 || ( | \ / | ) || 210 || ( | ___\ / | ) || 211 || ( | / [R71] | ) || 212 || ( | [R73] / \ | ) || 213 || ( | / \ | ) || 214 || ( | / \ | ) || 215 || ( | / \ | ) || 216 ===[R17]========(==[R65]------------[R67]==)======[R31]=== 217 \\ (// \\) // 218 || //v~v~v~v~v~v~v~v~v~v~v~\\ || 219 || // \\ || 220 || // \\ || 221 \\ // \\ // 222 ======[R23]==============================[R25]===== 223 // \\ 224 // \\ 226 Figure 1: An Example of TTZ 228 The routing area comprises routers R15, R17, R23, R25, R29 and R31. 229 It also contains a topology-transparent zone TTZ 600. The TTZ 600 230 comprises routers R61, R63, R65, R67, R71 and R73, and the links 231 connecting them. 233 There are two types of routers in a TTZ: TTZ internal routers and TTZ 234 edge routers. A TTZ internal router is a router inside the TTZ and 235 every adjacent router of the TTZ internal router is a router inside 236 the TTZ. A TTZ edge router is a router inside the TTZ and has at 237 least one adjacent router that is outside of the TTZ. 239 The TTZ in the figure above comprises four TTZ edge routers R61, R63, 240 R65 and R67. Each TTZ edge router is connected to at least one 241 router outside of the TTZ. For instance, router R61 is a TTZ edge 242 router since it is connected to router R15, which is outside of the 243 TTZ. 245 In addition, the TTZ comprises two TTZ internal routers R71 and R73. 246 A TTZ internal router is not connected to any router outside of the 247 TTZ. For instance, router R71 is a TTZ internal router since it is 248 not connected to any router outside of the TTZ. It is just connected 249 to routers R61, R63, R65, R67 and R73 inside the TTZ. 251 A TTZ MUST hide the information inside the TTZ from the outside. It 252 MUST NOT directly distribute any internal information about the TTZ 253 to a router outside of the TTZ. 255 For instance, the TTZ in the figure above MUST NOT send the 256 information about TTZ internal router R71 to any router outside of 257 the TTZ in the routing domain; it MUST NOT send the information about 258 the link between TTZ router R61 and R65 to any router outside of the 259 TTZ. 261 In order to create a TTZ, we MUST configure the same TTZ ID on the 262 edge routers and identify the TTZ internal links on them. In 263 addition, we SHOULD configure the TTZ ID on every TTZ internal router 264 which indicates that every link of the router is a TTZ internal link. 266 From a router outside of the TTZ, a TTZ is seen as a group of routers 267 fully connected. For instance, router R15 in the figure above, which 268 is outside of TTZ 600, sees TTZ 600 as a group of TTZ edge routers: 269 R61, R63, R65 and R67. These four TTZ edge routers are fully 270 connected. 272 In addition, a router outside of the TTZ sees TTZ edge routers having 273 normal connections to the routers outside of the TTZ. For example, 274 router R15 sees four TTZ edge routers R61, R63, R65 and R67, which 275 have the normal connections to R15, R29, R17 and R23, R25 and R31 276 respectively. 278 5. Changes to OSPF Protocols 280 5.1. Opaque LSAs for TTZ 282 The link state information about a TTZ includes router LSAs and 283 network LSAs describing the TTZ topology. These LSAs can be 284 contained and distributed in opaque LSAs within the TTZ. Some 285 control information on a TTZ can also be contained and distributed in 286 opaque LSAs within the TTZ. These opaque LSAs are called TTZ opaque 287 LSAs or TTZ LSAs for short. 289 The following is a general form of a TTZ LSA. It has an LS type = 10 290 and TTZ-LSA-Type, and contains a number of TLVs. 292 0 1 2 3 293 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 294 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 295 | LS age | Options | LS Type = 10 | 296 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 297 | TTZ-LSA-type | Opaque ID | 298 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 299 | Advertising Router | 300 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 301 | LS Sequence Number | 302 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 303 | LS checksum | Length | 304 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 305 | | 306 ~ TLVs ~ 307 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 309 Where TTZ-LSA-type may be TBD1 (TTZ-RT-LSA-type) for TTZ Router LSA, 310 TBD2 (TTZ-NW-LSA-type) for TTZ Network LSA, and TBD3 (TTZ-CT-LSA- 311 type) for TTZ Control LSA. 313 There are four types of TLVs: TTZ ID TLV, TTZ Router TLV, TTZ network 314 TLV and TTZ Options TLV. A TTZ ID TLV has the following format. It 315 contains a TTZ ID. 317 0 1 2 3 318 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 319 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 320 | TTZ-ID-TLV-type | Length = 4 | 321 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 322 | TTZ ID | 323 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 325 The format of a TTZ Router TLV is as follows. It contains the 326 contents of a normal router LSA. A TTZ router LSA includes a TTZ ID 327 TLV and a TTZ Router TLV. 329 0 1 2 3 330 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 331 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 332 | TTZ-RT-TLV-type | TLV-Length | 333 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 334 |G| 0 |V|E|B| 0 | # links | 335 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 336 | Link ID | 337 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 338 | Link Data | 339 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 340 | Type | # TOS | metric | 341 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 342 ~ ... ~ 344 Where G = 1/0 indicates that the router is an edge/internal router of 345 TTZ. For a router link, the existing eight bit Type field for a 346 router link may be split into two fields as follows: 348 0 1 2 3 4 5 6 7 349 +---+---+---+---+---+---+---+---+ 350 | I | Type-1 | 351 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 352 I bit flag: 353 1: Router link is an internal link to a router inside TTZ. 354 0: This indicates that the router link is an external link. 355 Type-1: The kind of the link. 357 For a link inside a TTZ, I bit flag is set to one, indicating that 358 this link is an internal TTZ link. For a link connecting to a router 359 outside of a TTZ from a TTZ edge router, I bit flag is set to zero, 360 indicating that this link is an external TTZ link. 362 The value of Type-1 may be 1, 2, 3, or 4, which indicates that the 363 kind of a link being described is a point-to-point connection to 364 another router, a connection to a transit network, a connection to a 365 stub network, or a virtual link respectively. 367 A TTZ Network TLV has the following format. It contains the contents 368 of a normal network LSA. A TTZ network LSA includes a TTZ ID TLV and 369 a TTZ network TLV. 371 0 1 2 3 372 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 373 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 374 | TTZ-NW-TLV-type | TLV-Length | 375 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 376 | Network Id | 377 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 378 | Network Mask | 379 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 380 | Attached Router | 381 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 382 ~ ... ~ 384 Where Network ID is the interface address of the DR, which is 385 followed by the contents of a network LSA. 387 The format of TTZ Options TLV is as follows. A TTZ control LSA 388 contains a TTZ ID TLV and a TTZ Options TLV. 390 0 1 2 3 391 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 392 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 393 | TTZ-OP-TLV-type | Length = 4 | 394 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 395 |T|M|N|R| 0 | 396 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 398 T = 1: Distributing TTZ Topology Information for Migration 399 M = 1: Migrating to TTZ 400 N = 1: Distributing Normal Topology Information for Rollback 401 R = 1: Rolling back from TTZ 403 5.2. A TTZ Capability TLV in Router Information LSA 405 A new bit such as bit 6 for TTZ capability may be defined in the 406 Router Informational Capabilities TLV as follows: 408 Bit Capabilities 409 0 OSPF graceful restart capable [GRACE] 410 : ... 411 5 OSPF Experimental TE [EXP-TE] 412 6 OSPF TTZ capable [OSPF-TTZ] 413 7-31 Unassigned (Standards Action) 415 When the OSPF TTZ capable bit is set to one, a TTZ capability TLV 416 must follow the Router Informational Capabilities TLV to indicate a 417 link/router's TTZ capability and the TTZ to which the link/router 418 belongs. It has the following format. 420 0 1 2 3 421 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 422 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 423 | TTZ-CAP-TLV-Type = 2 | Length = 8 | 424 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 425 | TTZ ID | 426 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 427 |M| 0 | 428 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 430 It contains a TTZ ID and a number of TTZ bits. The following bits in 431 the TLV are assigned: 433 Bit Meaning 434 M Have Migrated to TTZ (i.e., works as TTZ) 435 1-31 Unassigned (Standards Action) 437 A link scope RI LSA with a OSPF TTZ capable bit set to one and a TTZ 438 Capability TLV will be used to discover a TTZ neighbor. 440 6. Constructing LSAs for TTZ 442 There are three types of LSAs for representing a TTZ: TTZ router LSA, 443 TTZ network LSA and Router LSA for virtualizing TTZ. The first two 444 is generated by any TTZ router, and the third by a TTZ edge router. 446 A TTZ router LSA generated by a TTZ router has a TTZ ID TLV and a TTZ 447 Router TLV. The former includes the ID of the TTZ to which the 448 router belongs. The latter contains the links to the router. 450 A TTZ network LSA for a broadcast link is generated by the DR for the 451 link. It contains a TTZ ID TLV and a TTZ network TLV. The former 452 has the ID of the TTZ to which the link belongs. The latter includes 453 the DR's address, the network mask, and the routers attached. 455 A router LSA for virtualizing a TTZ generated by an edge router of 456 the TTZ comprises two groups of links in general. 458 The first group are the router links connecting the routers outside 459 of the TTZ. These router links are normal router links. There is a 460 router link for every adjacency between this TTZ edge router and a 461 router outside of the TTZ. 463 The second group are the "virtual" router links. For each of the 464 other TTZ edge routers, there is a "virtual" router link to it. The 465 cost of the router link may be the cost of the shortest path from 466 this TTZ edge router to it within the TTZ. 468 In addition, the LSA may contain a third group of links, which are 469 stub links for other destinations inside the TTZ. They may be the 470 loopback addresses to be accessed by a node outside of the TTZ. 472 7. Establishing Adjacencies 474 This section describes the adjacencies in some different cases. 476 7.1. Discover TTZ Neighbor over Normal Adjacency 478 For two routers A and B connected by a P2P link and having a normal 479 adjacency, they discover TTZ each other through a link scope RI LSA 480 with an OSPF TTZ capable bit and a TTZ ID. We call this LSA D-LSA 481 for short. If two ends of the link have the same TTZ ID, A and B are 482 TTZ neighbors. The following is a sequence of events related to TTZ. 484 A B 485 Configure TTZ Configure TTZ 486 D-LSA (TTZ-ID=100) 487 ---------------------------> Same TTZ ID 488 A is B's TTZ Neighbor 489 D-LSA (TTZ-ID=100) 490 Same TTZ ID <--------------------------- 491 B is A's TTZ Neighbor 493 A sends B a D-LSA with TTZ-ID after the TTZ is configured on it. B 494 sends A a D-LSA with TTZ-ID after the TTZ is configured on it. When 495 A receives the D-LSA from B and determines they have the same TTZ ID, 496 B is A's TTZ neighbor. When B receives the D-LSA from A and 497 determines they have the same TTZ ID, A is B's TTZ neighbor. 499 For a number of routers connected through a broadcast link and having 500 normal adjacencies among them, they also discover TTZ each other 501 through D-LSAs. The DR for the link "forms" TTZ adjacency with each 502 of the other routers if all the routers attached to the link have the 503 same TTZ ID configured on the connections to the link. 505 7.2. Establishing TTZ Adjacencies 507 When a router (say A) is connected via a P2P link to another router 508 (say B) and there is not any adjacency between them over the link, a 509 user configures TTZ on two ends of the link to form a TTZ adjacency. 511 While A and B are forming an adjacency, they start to discover TTZ 512 each other through D-LSAs in the same way as described above after 513 the normal adjacency is greater than ExStart. When the normal 514 adjacency is full and B becomes A's TTZ neighbor, A forms a TTZ 515 adjacency with B. Similarly, B forms a TTZ adjacency with A. 517 For a number of routers connected through a broadcast link and having 518 no adjacency among them, they start to form TTZ adjacencies after TTZ 519 is configured on the link. While forming adjacencies, they discover 520 TTZ each other through D-LSAs in the same way as described above 521 after the normal adjacency is greater than ExStart. The DR for the 522 link forms TTZ adjacency with each of the other routers if all the 523 routers attached to the link have the same TTZ ID configured on the 524 connections to the link. Otherwise, the DR does not form any 525 adjacency with any router attached to the link. 527 An alternative way for forming an adjacency between two routers in a 528 TTZ is to extend hello protocol. Hello protocol is extended to 529 include TTZ ID in LLS of a hello packet. The procedure for handling 530 hellos is changed to consider TTZ ID. If two routers have the same 531 TTZ IDs in their hellos, an adjacency between these two routers is to 532 be formed; otherwise, no adjacency is formed. 534 7.3. Adjacency between TTZ Edge and Router outside 536 For an edge router in a TTZ, it forms an adjacency with any router 537 outside of the TTZ that has a connection with it. 539 When the edge router synchronizes its link state database with the 540 router outside of the TTZ, it sends the router outside of the TTZ the 541 information about all the LSAs except for the LSAs belonging to the 542 TTZ that are hidden from any router outside of the TTZ. 544 At the end of the link state database synchronization, the edge 545 router originates its own router LSA for virtualizing the TTZ and 546 sends this LSA to the router outside of the TTZ. 548 From the point of view of the router outside of the TTZ, it sees the 549 other end as a normal router and forms the adjacency in the same way 550 as a normal router. It is not aware of anything about its 551 neighboring TTZ. From the LSAs related to the TTZ edge router in the 552 other end, it knows that the TTZ edge router is connected to each of 553 the other TTZ edge routers and some routers outside of the TTZ. 555 8. Distribution of LSAs 557 LSAs can be divided into a couple of classes according to their 558 distributions. The first class of LSAs is distributed within a TTZ. 559 The second is distributed through a TTZ. 561 8.1. Distribution of LSAs within TTZ 563 Any LSA about a link state in a TTZ is distributed within the TTZ. 564 It is not distributed to any router outside of the TTZ. For example, 565 a router LSA generated for a router in a TTZ is distributed within 566 the TTZ and not distributed to any router outside of the TTZ. 568 Any network LSA generated for a broadcast or NBMA network in a TTZ is 569 distributed in the TTZ and not sent to a router outside of the TTZ. 571 Any opaque LSA generated for a TTZ internal TE link is distributed 572 within the TTZ and not distributed to any router outside of the TTZ. 574 8.2. Distribution of LSAs through TTZ 576 Any LSA about a link state outside of a TTZ received by an edge 577 router of the TTZ is distributed through the TTZ. For example, when 578 an edge router of a TTZ receives an LSA from a router outside of the 579 TTZ, it floods it to its neighboring routers both inside the TTZ and 580 outside of the TTZ. This LSA may be any LSA such as a router LSA 581 that is distributed in a domain. 583 The routers in the TTZ continue to flood the LSA. When another edge 584 router of the TTZ receives the LSA, it floods the LSA to its 585 neighboring routers both outside of the TTZ and inside the TTZ. 587 9. Computation of Routing Table 589 The computation of the routing table on a router is the same as that 590 described in RFC 2328, with one exception. A router in a TTZ MUST 591 ignore the router LSAs generated by the edge routers of the TTZ for 592 virtualizing the TTZ. It computes routes through using the TTZ 593 topology represented by TTZ LSAs and the topology outside of the TTZ. 595 10. Operations 597 10.1. Configuring TTZ 599 This section proposes some options for configuring a TTZ. 601 1. Configuring TTZ on Every Link in TTZ 603 If every link in a TTZ is configured with a same TTZ ID as a TTZ 604 link, the TTZ is determined. A router with some TTZ links and some 605 normal links is a TTZ edge router. A router with only TTZ links is a 606 TTZ internal router. 608 2. Configuring TTZ on Every Router in TTZ 610 We may configure a same TTZ ID on every router in the TTZ, and on 611 every edge router's links connecting to the routers in the TTZ. 613 A router configured with the TTZ ID on some of its links is a TTZ 614 edge router. A router configured with the TTZ ID only is a TTZ 615 internal router. All the links on a TTZ internal router are TTZ 616 links. This option is simpler than the above one. 618 10.2. Smooth Migration to TTZ 620 For a group of routers and a number of links connecting the routers 621 in an area, making them transfer to work as a TTZ without any service 622 interruption may take a few of steps or stages. 624 At first, users configure the TTZ feature on every router in the TTZ. 625 In this stage, a router does not originate its TTZ router LSA or TTZ 626 network LSAs. It will discover its TTZ neighbors. 628 Secondly, after configuring the TTZ, users may issue a CLI command on 629 one router in the TTZ, which triggers every router in the TTZ to 630 generate and distribute TTZ information among the routers in the TTZ. 631 When the router receives the command, it originates its TTZ router 632 LSA and TTZ network LSAs as needed, and distributes them to its TTZ 633 neighbors. It also originates a TTZ control LSA with T=1 (indicating 634 TTZ information generation and distribution for migration). When a 635 router in the TTZ receives the LSA with T=1, it originates its TTZ 636 router LSA and TTZ network LSAs as needed. In this stage, every 637 router in the TTZ has dual roles. One is to function as a normal 638 router. The other is to generate and distribute TTZ information. 640 Thirdly, users SHOULD check whether every router in the TTZ is ready 641 for transferring to work as a TTZ router. A router in the TTZ is 642 ready after it has received all the necessary information from all 643 the routers in the TTZ. This information may be displayed on a 644 router through a CLI command. 646 And then users may activate the TTZ through using a CLI command such 647 as migrate to TTZ on one router in the TTZ. The router transfers to 648 work as a TTZ router, generates and distributes a TTZ control LSA 649 with M=1 (indicating Migrating to TTZ) after it receives the command. 651 After a router in the TTZ receives the TTZ control LSA with M=1, it 652 also transfers to work as a TTZ router. Thus, activating the TTZ on 653 one TTZ router makes every router in the TTZ transfer to work as a 654 TTZ router, which flushes its normal router LSA and network LSAs, 655 computes routes through using the TTZ topology represented by TTZ 656 LSAs and the topology outside of the TTZ. 658 For an edge router of the TTZ, transferring to work as a TTZ router 659 comprises generating a router LSA to virtualize the TTZ and flooding 660 this LSA to all its neighboring routers. 662 10.3. Adding a Router into TTZ 664 When a non TTZ router (say R1) is connected via a P2P link to a TTZ 665 router (say T1) working as TTZ and there is a normal adjacency 666 between them over the link, a user can configure TTZ on two ends of 667 the link to add R1 into the TTZ to which T1 belongs. They discover 668 TTZ each other through D-LSAs in the same way as described above with 669 a bit addition. When T1 sends R1 a D-LSA, the D-LSA has a bit M=1 670 indicating that T1 works as TTZ. When R1 receives D-LSA with M=1, it 671 transfers to work as TTZ if it determines that T1 is its TTZ 672 neighbor. The following is a sequence of events related to TTZ. 674 T1 R1 675 Configure TTZ Configure TTZ 676 D-LSA(TTZ-ID=100,M=1) 677 ---------------------------> Same TTZ ID 678 TTZ Neighbor, work as TTZ 679 D-LSA(TTZ-ID=100) 680 Same TTZ ID <--------------------------- 681 TTZ Neighbor 683 After R1 receives the D-LSA with M=1 from T1, T1 becomes R1's TTZ 684 neighbor and R1 starts to work as TTZ. It originates its TTZ LSAs, 685 flushes old normal LSAs and computes routes using the TTZ topology 686 and the topology outside of the TTZ. 688 When T1 receives the D-LSA from R1, R1 is T1's TTZ neighbor, T1 re- 689 originates its TTZ LSAs and sends R1 all the TTZ LSAs. 691 When a number of non TTZ routers are connected via a broadcast link 692 to a TTZ router (say T1) working as TTZ and there are normal 693 adjacencies among them, a user configures TTZ on the connection to 694 the link on every router to add the non TTZ routers into the TTZ to 695 which T1 belongs. The DR for the link "forms" TTZ adjacency with 696 each of the other routers if all the routers have the same TTZ ID 697 configured on the connections to the link. 699 When a router (say R1) is connected via a P2P link to a TTZ router 700 (say T1) and there is not any adjacency between them over the link, a 701 user can configure TTZ on two ends of the link to add R1 into the TTZ 702 to which T1 belongs. 704 While R1 and T1 are forming an adjacency, they start to discover TTZ 705 each other through D-LSAs in the same way as described above after 706 the adjacency is greater than ExStart. When the adjacency is full 707 and T1 becomes R1's TTZ neighbor, R1 works as TTZ if T1 works as TTZ. 709 When a router (say R1) is connected via a broadcast link to a group 710 of TTZ routers on the link and there is not any adjacency between R1 711 and any over the link, a user can configure TTZ on the connection to 712 the link on R1 to add R1 into the TTZ to which the TTZ routers 713 belong. R1 starts to form an adjacency with the DR for the link 714 after the configuration. 716 While R1 and the DR are forming an adjacency, they start to discover 717 TTZ each other through D-LSAs in the same way as described above 718 after the adjacency is greater than ExStart. When the adjacency is 719 full and the DR becomes R1's TTZ neighbor, R1 works as TTZ if the DR 720 works as TTZ. If R1 and the DR can not "form" any TTZ adjacency 721 because TTZ is not configured or is mis-configured on R1, DR will not 722 bring the normal adjacency between DR and R1 to Full, but bring the 723 adjacency to ExStart until TTZ is correctly configured on R1. 725 11. Security Considerations 727 The mechanism described in this document does not raise any new 728 security issues for the OSPF protocols. 730 12. IANA Considerations 732 TBD 734 13. Contributors 736 Veerendranatha Reddy Vallem 737 Huawei Technologies 738 Banglore 739 India 740 Email: veerendranatharv@huawei.com 742 14. Acknowledgement 744 The author would like to thank Acee Lindem, Abhay Roy, Dean Cheng, 745 Russ White, William McCall, Tony Przygienda, Lin Han and Yang Yu for 746 their valuable comments on this draft. 748 15. References 750 15.1. Normative References 752 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 753 Requirement Levels", BCP 14, RFC 2119, March 1997. 755 [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998. 757 [RFC4970] Lindem, A., Shen, N., Vasseur, JP., Aggarwal, R., and S. 758 Shaffer, "Extensions to OSPF for Advertising Optional 759 Router Capabilities", RFC 4970, July 2007. 761 [RFC2370] Coltun, R., "The OSPF Opaque LSA Option", RFC 2370, 762 July 1998. 764 [RFC5613] Zinin, A., Roy, A., Nguyen, L., Friedman, B., and D. 765 Yeung, "OSPF Link-Local Signaling", RFC 5613, August 2009. 767 15.2. Informative References 769 [RFC5441] Vasseur, JP., Zhang, R., Bitar, N., and JL. Le Roux, "A 770 Backward-Recursive PCE-Based Computation (BRPC) Procedure 771 to Compute Shortest Constrained Inter-Domain Traffic 772 Engineering Label Switched Paths", RFC 5441, April 2009. 774 [RFC5440] Vasseur, JP. and JL. Le Roux, "Path Computation Element 775 (PCE) Communication Protocol (PCEP)", RFC 5440, 776 March 2009. 778 Authors' Addresses 780 Huaimo Chen 781 Huawei Technologies 782 Boston, MA 783 USA 785 Email: huaimo.chen@huawei.com 786 Renwei Li 787 Huawei Technologies 788 2330 Central expressway 789 Santa Clara, CA 790 USA 792 Email: renwei.li@huawei.com 794 Anil Kumar S N 795 Huawei Technologies 796 Banglore 797 India 799 Email: anil.sn@huawei.com 801 Gregory Cauchie 802 FRANCE 804 Email: greg.cauchie@gmail.com 806 Alvaro Retana 807 Cisco Systems, Inc. 808 7025 Kit Creek Rd. 809 Raleigh, NC 27709 810 USA 812 Email: aretana@cisco.com 814 Ning So 815 Tata Communications 816 2613 Fairbourne Cir. 817 Plano, TX 75082 818 USA 820 Email: ningso01@gmail.com 821 Vic Liu 822 China Mobile 823 No.32 Xuanwumen West Street, Xicheng District 824 Beijing, 100053 825 China 827 Email: liuzhiheng@chinamobile.com 829 Mehmet Toy 830 Comcast 831 1800 Bishops Gate Blvd. 832 Mount Laurel, NJ 08054 833 USA 835 Email: mehmet_toy@cable.comcast.com 837 Lei Liu 838 UC Davis 839 CA 840 USA 842 Email: liulei.kddi@gmail.com