idnits 2.17.1 draft-chen-ospf-ttz-09.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 (October 26, 2014) is 3463 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 212, but not defined == Missing Reference: 'R73' is mentioned on line 213, 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 811, but no explicit reference was found in the text == Unused Reference: 'RFC2328' is defined on line 814, but no explicit reference was found in the text == Unused Reference: 'RFC4970' is defined on line 816, but no explicit reference was found in the text == Unused Reference: 'RFC2370' is defined on line 820, but no explicit reference was found in the text == Unused Reference: 'RFC5613' is defined on line 823, 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. Kumar S N 5 Expires: April 29, 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 October 26, 2014 20 OSPF Topology-Transparent Zone 21 draft-chen-ospf-ttz-09.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 April 29, 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 . . . . . . . . . . . . . . . . . . . . . . . . . 4 68 2. Conventions Used in This Document . . . . . . . . . . . . . . 5 69 3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 5 70 4. Topology-Transparent Zone . . . . . . . . . . . . . . . . . . 5 71 4.1. Overview of Topology-Transparent Zone . . . . . . . . . . 5 72 4.2. An Example of TTZ . . . . . . . . . . . . . . . . . . . . 6 73 5. Extensions to OSPF Protocols . . . . . . . . . . . . . . . . . 7 74 5.1. Opaque LSAs for TTZ . . . . . . . . . . . . . . . . . . . 7 75 5.2. A TTZ Capability TLV in Router Information LSA . . . . . . 10 76 6. Constructing LSAs for TTZ . . . . . . . . . . . . . . . . . . 11 77 7. Establishing Adjacencies . . . . . . . . . . . . . . . . . . . 12 78 7.1. Discover TTZ Neighbor over Normal Adjacency . . . . . . . 12 79 7.2. Establishing TTZ Adjacencies . . . . . . . . . . . . . . . 12 80 7.3. Adjacency between TTZ Edge and Router outside . . . . . . 13 81 8. Distribution of LSAs . . . . . . . . . . . . . . . . . . . . . 13 82 8.1. Distribution of LSAs within TTZ . . . . . . . . . . . . . 14 83 8.2. Distribution of LSAs through TTZ . . . . . . . . . . . . . 14 84 9. Computation of Routing Table . . . . . . . . . . . . . . . . . 14 85 10. Operations . . . . . . . . . . . . . . . . . . . . . . . . . . 14 86 10.1. Configuring TTZ . . . . . . . . . . . . . . . . . . . . . 14 87 10.2. Smooth Migration to TTZ . . . . . . . . . . . . . . . . . 15 88 10.3. Adding a Router into TTZ . . . . . . . . . . . . . . . . . 16 89 11. Prototype Implementation . . . . . . . . . . . . . . . . . . . 16 90 11.1. What are Implemented and Tested . . . . . . . . . . . . . 16 91 11.2. Implementation Experience . . . . . . . . . . . . . . . . 18 92 12. Security Considerations . . . . . . . . . . . . . . . . . . . 18 93 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 94 14. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 19 95 15. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 19 96 16. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19 97 16.1. Normative References . . . . . . . . . . . . . . . . . . . 19 98 16.2. Informative References . . . . . . . . . . . . . . . . . . 19 99 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20 101 1. Introduction 103 The number of routers in a network becomes larger and larger as the 104 Internet traffic keeps growing. Through splitting the network into 105 multiple areas, we can extend the network further. However, there 106 are a number of issues when a network is split further into more 107 areas. 109 At first, dividing a network from one area into multiple areas or 110 from a number of existing areas to even more areas is a very 111 challenging and time consuming task since it is involved in 112 significant network architecture changes. Considering the one area 113 case, originally the network has only one area, which is the 114 backbone. This original backbone area will be split into a new 115 backbone and a number of non backbone areas. In general, each of the 116 non backbone areas is connected to the new backbone area through the 117 area border routers between the non backbone and the backbone area. 118 There is not any direct connection between any two non backbone 119 areas. Each area border router summarizes the topology of its 120 attached non backbone area for transmission on the backbone area, and 121 hence to all other area border routers. 123 Secondly, the services carried by the network may be interrupted 124 while the network is being split from one area into multiple areas or 125 from a number of existing areas into even more areas. 127 Furthermore, it is complex for a Multi-Protocol Label Switching 128 (MPLS) Traffic Engineering (TE) Label Switching Path (LSP) crossing 129 multiple areas to be setup. In one option, a TE path crossing 130 multiple areas is computed by using collaborating Path Computation 131 Elements (PCEs) [RFC5441] through the PCE Communication Protocol 132 (PCEP)[RFC5440], which is not easy to configure by operators since 133 the manual configuration of the sequence of domains is required. 134 Although this issue can be addressed by using the Hierarchical PCE, 135 this solution may further increase the complexity of network design. 136 Especially, the current PCE standard method may not guarantee that 137 the path found is optimal. 139 This document presents a topology-transparent zone in an area and 140 describes extensions to OSPF for supporting the topology-transparent 141 zone, which is scalable and resolves the issues above. 143 A topology-transparent zone comprises a group of routers and a number 144 of links connecting these routers. Any router outside of the zone is 145 not aware of the zone. The information about the links and routers 146 inside the zone is not distributed to any router outside of the zone. 147 Any link state change such as a link down inside the zone is not seen 148 by any router outside of the zone. 150 2. 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 3. Requirements 158 Topology-Transparent Zone (TTZ) may be deployed for resolving some 159 critical issues in existing networks and future networks. The 160 requirements for TTZ are listed as follows: 162 o TTZ MUST be backward compatible. When a TTZ is deployed on a set 163 of routers in a network, the routers outside of the TTZ in the 164 network do not need to know or support TTZ. 166 o TTZ MUST support at least one more levels of network hierarchies, 167 in addition to the hierarchies supported by existing routing 168 protocols. 170 o Users SHOULD be able to easily set up an end to end service 171 crossing TTZs. 173 o The configuration for a TTZ in a network SHOULD be minimum. 175 o The changes on the existing protocols for supporting TTZ SHOULD be 176 minimum. 178 4. Topology-Transparent Zone 180 4.1. Overview of Topology-Transparent Zone 182 A Topology-Transparent Zone (TTZ) is identified by an Identifier 183 (ID), and it includes a group of routers and a number of links 184 connecting the routers. A TTZ is in an OSPF area. 186 The ID of a TTZ or TTZ ID is a number that is unique for identifying 187 an entity such as a node in an OSPF domain. It is not zero in 188 general. 190 In addition to having the functions of an OSPF area, an OSPF TTZ 191 makes some improvements on an OSPF area, which include: 193 o An OSPF TTZ is virtualized as the TTZ edge routers connected. 195 o An OSPF TTZ receives the link state information about the topology 196 outside of the TTZ, stores the information in the TTZ and floods 197 the information through the TTZ to the routers outside of the TTZ. 199 4.2. An Example of TTZ 201 The figure below shows an area containing a TTZ: TTZ 600. 203 TTZ 600 204 \ 205 \ ^~^~^~^~^~^~^~^~^~^~^~^~ 206 ( ) 207 ===[R15]========(==[R61]------------[R63]==)======[R29]=== 208 || ( | \ / | ) || 209 || ( | \ / | ) || 210 || ( | \ / | ) || 211 || ( | ___\ / | ) || 212 || ( | / [R71] | ) || 213 || ( | [R73] / \ | ) || 214 || ( | / \ | ) || 215 || ( | / \ | ) || 216 || ( | / \ | ) || 217 ===[R17]========(==[R65]------------[R67]==)======[R31]=== 218 \\ (// \\) // 219 || //v~v~v~v~v~v~v~v~v~v~v~\\ || 220 || // \\ || 221 || // \\ || 222 \\ // \\ // 223 ======[R23]==============================[R25]===== 224 // \\ 225 // \\ 227 Figure 1: An Example of TTZ 229 The area comprises routers R15, R17, R23, R25, R29 and R31. It also 230 contains TTZ 600, which comprises routers R61, R63, R65, R67, R71 and 231 R73, and the links 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 its adjacent routers are in the TTZ. A TTZ edge router is a router 236 inside the TTZ and has at least one adjacent router that is outside 237 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 in 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. Extensions 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 may be generated by a 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 three 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 point-to-point router link to it. 466 The cost of the link may be the cost of the shortest path from this 467 TTZ edge router to it within the TTZ. 469 In addition, the LSA may contain a third group of links, which are 470 stub links for other destinations inside the TTZ. They may be the 471 loopback addresses to be accessed by a node outside of the TTZ. 473 7. Establishing Adjacencies 475 This section describes the adjacencies in some different cases. 477 7.1. Discover TTZ Neighbor over Normal Adjacency 479 For two routers A and B connected by a P2P link and having a normal 480 adjacency, they discover TTZ each other through a link scope RI LSA 481 with an OSPF TTZ capable bit and a TTZ ID. We call this LSA D-LSA 482 for short. If two ends of the link have the same TTZ ID, A and B are 483 TTZ neighbors. The following is a sequence of events related to TTZ. 485 A B 486 Configure TTZ Configure TTZ 487 D-LSA (TTZ-ID=100) 488 ---------------------------> Same TTZ ID 489 A is B's TTZ Neighbor 490 D-LSA (TTZ-ID=100) 491 Same TTZ ID <--------------------------- 492 B is A's TTZ Neighbor 494 A sends B a D-LSA with TTZ-ID after the TTZ is configured on it. B 495 sends A a D-LSA with TTZ-ID after the TTZ is configured on it. When 496 A receives the D-LSA from B and determines they have the same TTZ ID, 497 B is A's TTZ neighbor. When B receives the D-LSA from A and 498 determines they have the same TTZ ID, A is B's TTZ neighbor. 500 For a number of routers connected through a broadcast link and having 501 normal adjacencies among them, they also discover TTZ each other 502 through D-LSAs. The DR for the link "forms" TTZ adjacency with each 503 of the other routers if all the routers attached to the link have the 504 same TTZ ID configured on the connections to the link. 506 7.2. Establishing TTZ Adjacencies 508 When a router (say A) is connected via a P2P link to another router 509 (say B) and there is not any adjacency between them over the link, a 510 user configures TTZ on two ends of the link to form a TTZ adjacency. 512 While A and B are forming an adjacency, they start to discover TTZ 513 each other through D-LSAs in the same way as described above after 514 the normal adjacency is greater than ExStart. When the normal 515 adjacency is full and B becomes A's TTZ neighbor, A forms a TTZ 516 adjacency with B. Similarly, B forms a TTZ adjacency with A. 518 For a number of routers connected through a broadcast link and having 519 no adjacency among them, they start to form TTZ adjacencies after TTZ 520 is configured on the link. While forming adjacencies, they discover 521 TTZ each other through D-LSAs in the same way as described above 522 after the normal adjacency is greater than ExStart. The DR for the 523 link forms TTZ adjacency with each of the other routers if all the 524 routers attached to the link have the same TTZ ID configured on the 525 connections to the link. Otherwise, the DR does not form any 526 adjacency with any router attached to the link. 528 An alternative way for forming an adjacency between two routers in a 529 TTZ is to extend hello protocol. Hello protocol is extended to 530 include TTZ ID in LLS of a hello packet. The procedure for handling 531 hellos is changed to consider TTZ ID. If two routers have the same 532 TTZ IDs in their hellos, an adjacency between these two routers is to 533 be formed; otherwise, no adjacency is formed. 535 7.3. Adjacency between TTZ Edge and Router outside 537 For an edge router in a TTZ, it forms an adjacency with any router 538 outside of the TTZ that has a connection with it. 540 When the edge router synchronizes its link state database with the 541 router outside of the TTZ, it sends the router outside of the TTZ the 542 information about all the LSAs except for the LSAs belonging to the 543 TTZ that are hidden from any router outside of the TTZ. 545 At the end of the link state database synchronization, the edge 546 router originates its own router LSA for virtualizing the TTZ and 547 sends this LSA to the router outside of the TTZ. 549 From the point of view of the router outside of the TTZ, it sees the 550 other end as a normal router and forms the adjacency in the same way 551 as a normal router. It is not aware of anything about its 552 neighboring TTZ. From the LSAs related to the TTZ edge router in the 553 other end, it knows that the TTZ edge router is connected to each of 554 the other TTZ edge routers and some routers outside of the TTZ. 556 8. Distribution of LSAs 558 LSAs can be divided into a couple of classes according to their 559 distributions. The first class of LSAs is distributed within a TTZ. 560 The second is distributed through a TTZ. 562 8.1. Distribution of LSAs within TTZ 564 Any LSA about a link state in a TTZ is distributed within the TTZ. 565 It is not distributed to any router outside of the TTZ. For example, 566 a router LSA generated for a router in a TTZ is distributed within 567 the TTZ and not distributed to any router outside of the TTZ. 569 Any network LSA generated for a broadcast or NBMA network in a TTZ is 570 distributed in the TTZ and not sent to a router outside of the TTZ. 572 Any opaque LSA generated for a TTZ internal TE link is distributed 573 within the TTZ and not distributed to any router outside of the TTZ. 575 8.2. Distribution of LSAs through TTZ 577 Any LSA about a link state outside of a TTZ received by an edge 578 router of the TTZ is distributed through the TTZ. For example, when 579 an edge router of a TTZ receives an LSA from a router outside of the 580 TTZ, it floods it to its neighboring routers both inside the TTZ and 581 outside of the TTZ. This LSA may be any LSA such as a router LSA 582 that is distributed in a domain. 584 The routers in the TTZ continue to flood the LSA. When another edge 585 router of the TTZ receives the LSA, it floods the LSA to its 586 neighboring routers both outside of the TTZ and inside the TTZ. 588 9. Computation of Routing Table 590 The computation of the routing table on a router is the same as that 591 described in RFC 2328, with one exception. A router in a TTZ MUST 592 ignore the router LSAs generated by the edge routers of the TTZ for 593 virtualizing the TTZ. It computes routes through using the TTZ 594 topology represented by TTZ LSAs and the topology outside of the TTZ. 596 10. Operations 598 10.1. Configuring TTZ 600 This section proposes some options for configuring a TTZ. 602 1. Configuring TTZ on Every Link in TTZ 604 If every link in a TTZ is configured with a same TTZ ID as a TTZ 605 link, the TTZ is determined. A router with some TTZ links and some 606 normal links is a TTZ edge router. A router with only TTZ links is a 607 TTZ internal router. 609 2. Configuring TTZ on Every Router in TTZ 611 We may configure a same TTZ ID on every router in the TTZ, and on 612 every edge router's links connecting to the routers in the TTZ. 614 A router configured with the TTZ ID on some of its links is a TTZ 615 edge router. A router configured with the TTZ ID only is a TTZ 616 internal router. All the links on a TTZ internal router are TTZ 617 links. This option is simpler than the above one. 619 10.2. Smooth Migration to TTZ 621 For a group of routers and a number of links connecting the routers 622 in an area, making them transfer to work as a TTZ without any service 623 interruption may take a few of steps or stages. 625 At first, users configure the TTZ feature on every router in the TTZ. 626 In this stage, a router does not originate its TTZ router LSA or TTZ 627 network LSAs. It will discover its TTZ neighbors. 629 Secondly, after configuring the TTZ, users may issue a CLI command on 630 one router in the TTZ, which triggers every router in the TTZ to 631 generate and distribute TTZ information among the routers in the TTZ. 632 When the router receives the command, it originates its TTZ router 633 LSA and TTZ network LSAs as needed, and distributes them to its TTZ 634 neighbors. It also originates a TTZ control LSA with T=1 (indicating 635 TTZ information generation and distribution for migration). When a 636 router in the TTZ receives the LSA with T=1, it originates its TTZ 637 router LSA and TTZ network LSAs as needed. In this stage, every 638 router in the TTZ has dual roles. One is to function as a normal 639 router. The other is to generate and distribute TTZ information. 641 Thirdly, users SHOULD check whether every router in the TTZ is ready 642 for transferring to work as a TTZ router. A router in the TTZ is 643 ready after it has received all the necessary information from all 644 the routers in the TTZ. This information may be displayed on a 645 router through a CLI command. 647 And then users may activate the TTZ through using a CLI command such 648 as migrate to TTZ on one router in the TTZ. The router transfers to 649 work as a TTZ router, generates and distributes a TTZ control LSA 650 with M=1 (indicating Migrating to TTZ) after it receives the command. 652 After a router in the TTZ receives the TTZ control LSA with M=1, it 653 also transfers to work as a TTZ router. Thus, activating the TTZ on 654 one TTZ router makes every router in the TTZ transfer to work as a 655 TTZ router, which flushes its normal router LSA and network LSAs, 656 computes routes through using the TTZ topology represented by TTZ 657 LSAs and the topology outside of the TTZ. 659 For an edge router of the TTZ, transferring to work as a TTZ router 660 comprises generating a router LSA to virtualize the TTZ and flooding 661 this LSA to all its neighboring routers. 663 10.3. Adding a Router into TTZ 665 When a non TTZ router (say R1) is connected via a P2P link to a TTZ 666 router (say T1) working as TTZ and there is a normal adjacency 667 between them over the link, a user can configure TTZ on two ends of 668 the link to add R1 into the TTZ to which T1 belongs. They discover 669 TTZ each other in the same way as described in section 7.1. 671 When a number of non TTZ routers are connected via a broadcast link 672 to a TTZ router (say T1) working as TTZ and there are normal 673 adjacencies among them, a user configures TTZ on the connection to 674 the link on every router to add the non TTZ routers into the TTZ to 675 which T1 belongs. The DR for the link "forms" TTZ adjacency with 676 each of the other routers if all the routers have the same TTZ ID 677 configured on the connections to the link. 679 When a router (say R1) is connected via a P2P link to a TTZ router 680 (say T1) and there is not any adjacency between them over the link, a 681 user can configure TTZ on two ends of the link to add R1 into the TTZ 682 to which T1 belongs. R1 and T1 will form an adjacency in the same 683 way as described in section 7.2. 685 When a router (say R1) is connected via a broadcast link to a group 686 of TTZ routers on the link and there is not any adjacency between R1 687 and any over the link, a user can configure TTZ on the connection to 688 the link on R1 to add R1 into the TTZ to which the TTZ routers 689 belong. R1 starts to form an adjacency with the DR for the link 690 after the configuration. 692 11. Prototype Implementation 694 11.1. What are Implemented and Tested 696 1. CLI Commands for TTZ 698 The CLIs implemented and tested include: 700 o the CLIs of the simpler option for configuring TTZ, and 702 o the CLIs for controlling migration to TTZ. 704 2. Extensions to OSPF Protocols for TTZ 706 All the extensions defined in section "Extensions to OSPF Protocols" 707 are implemented and tested except for rolling back from TTZ. The 708 testing results illustrate: 710 o A TTZ is virtualized to outside as its edge routers fully 711 connected. Any router outside of the TTZ sees the edge routers 712 (as normal routers) connecting each other and to some other 713 routers. 715 o The link state information about the routers and links inside the 716 TTZ is contained within the TTZ. It is not distributed to any 717 router outside of the TTZ. 719 o TTZ is transparent. From a router inside a TTZ, it sees the 720 topology (link state) outside of the TTZ. From a router outside 721 of the TTZ, it sees the topology beyond the TTZ. The link state 722 information outside of the TTZ is distributed through the TTZ. 724 o TTZ is backward compatible. Any router outside of a TTZ does not 725 need to support or know TTZ. 727 3. Smooth Migration to TTZ 729 The procedures and related protocol extensions for smooth migration 730 to TTZ are implemented and tested. The testing results show: 732 o A part of an area is smoothly migrated to a TTZ without any 733 routing disruptions. The routes on every router are stable while 734 the part of the area is being migrated to the TTZ. 736 o Migration to TTZ is very easy to operate. 738 4. Add a Router to TTZ 740 Adding a router into TTZ is implemented and tested. The testing 741 results illustrate: 743 o A router can be easily added into a TTZ and becomes a TTZ router. 745 o The router added into the TTZ is not seen on any router outside of 746 the TTZ, but it is a part of the TTZ. 748 5. Leak TTZ Loopbacks Outside 750 Leaking loopback addresses in a TTZ to routers outside of the TTZ is 751 implemented and tested. The testing results illustrate: 753 o The loopback addresses inside the TTZ are distributed to the 754 routers outside of the TTZ. 756 o The loopback addresses are accessable from a router outside of the 757 TTZ. 759 11.2. Implementation Experience 761 The implementation of TTZ is relatively easy compared to other 762 features of OSPF. Re-using the existing OSPF code along with 763 additional simple logic does the work. A couple of engineers started 764 to work on implementing the TTZ from the middle of June, 2014 and 765 finished coding it just before IETF 90. After some testing and bug 766 fixes, it works as expected. 768 In our implementation, the link state information in a TTZ opaque LSA 769 is stored in the same link state database as the link state 770 information in a normal LSA. For each TTZ link in the TTZ opaque LSA 771 stored, there is an additional flag, which is used to differentiate 772 between a TTZ link and a Normal link. 774 Before migration to TTZ, every router in the TTZ computes its routing 775 table using the normal links. After migration to TTZ, every router 776 in the TTZ computes its routing table using the TTZ links and normal 777 links. In the case that there are one TTZ link and one normal link 778 to select, the TTZ link is used. In SPF calculation, the back-link 779 check passes if and only if the corresponding new additional bit 780 matches. If link type bit is TTZ link, then the lookup is for 781 corresponding TTZ LSA. In case of normal link, the lookup is based 782 on normal link. 784 12. Security Considerations 786 The mechanism described in this document does not raise any new 787 security issues for the OSPF protocols. 789 13. IANA Considerations 791 TBD 793 14. Contributors 795 Veerendranatha Reddy Vallem 796 Huawei Technologies 797 Banglore 798 India 799 Email: veerendranatharv@huawei.com 801 15. Acknowledgement 803 The author would like to thank Acee Lindem, Abhay Roy, Dean Cheng, 804 Russ White, William McCall, Tony Przygienda, Lin Han and Yang Yu for 805 their valuable comments on this draft. 807 16. References 809 16.1. Normative References 811 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 812 Requirement Levels", BCP 14, RFC 2119, March 1997. 814 [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998. 816 [RFC4970] Lindem, A., Shen, N., Vasseur, JP., Aggarwal, R., and S. 817 Shaffer, "Extensions to OSPF for Advertising Optional 818 Router Capabilities", RFC 4970, July 2007. 820 [RFC2370] Coltun, R., "The OSPF Opaque LSA Option", RFC 2370, 821 July 1998. 823 [RFC5613] Zinin, A., Roy, A., Nguyen, L., Friedman, B., and D. 824 Yeung, "OSPF Link-Local Signaling", RFC 5613, August 2009. 826 16.2. Informative References 828 [RFC5441] Vasseur, JP., Zhang, R., Bitar, N., and JL. Le Roux, "A 829 Backward-Recursive PCE-Based Computation (BRPC) Procedure 830 to Compute Shortest Constrained Inter-Domain Traffic 831 Engineering Label Switched Paths", RFC 5441, April 2009. 833 [RFC5440] Vasseur, JP. and JL. Le Roux, "Path Computation Element 834 (PCE) Communication Protocol (PCEP)", RFC 5440, 835 March 2009. 837 Authors' Addresses 839 Huaimo Chen 840 Huawei Technologies 841 Boston, MA 842 USA 844 Email: huaimo.chen@huawei.com 846 Renwei Li 847 Huawei Technologies 848 2330 Central expressway 849 Santa Clara, CA 850 USA 852 Email: renwei.li@huawei.com 854 Anil Kumar S N 855 Huawei Technologies 856 Banglore 857 India 859 Email: anil.sn@huawei.com 861 Gregory Cauchie 862 FRANCE 864 Email: greg.cauchie@gmail.com 866 Alvaro Retana 867 Cisco Systems, Inc. 868 7025 Kit Creek Rd. 869 Raleigh, NC 27709 870 USA 872 Email: aretana@cisco.com 873 Ning So 874 Tata Communications 875 2613 Fairbourne Cir. 876 Plano, TX 75082 877 USA 879 Email: ningso01@gmail.com 881 Vic Liu 882 China Mobile 883 No.32 Xuanwumen West Street, Xicheng District 884 Beijing, 100053 885 China 887 Email: liuzhiheng@chinamobile.com 889 Mehmet Toy 890 Comcast 891 1800 Bishops Gate Blvd. 892 Mount Laurel, NJ 08054 893 USA 895 Email: mehmet_toy@cable.comcast.com 897 Lei Liu 898 UC Davis 899 CA 900 USA 902 Email: liulei.kddi@gmail.com