idnits 2.17.1 draft-chen-isis-ttz-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** There are 2 instances of too long lines in the document, the longest one being 4 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (May 4, 2013) is 4009 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: 'RFC5441' is mentioned on line 125, but not defined == Missing Reference: 'RFC5440' is mentioned on line 125, but not defined == Missing Reference: 'R73' is mentioned on line 242, but not defined == Unused Reference: 'RFC2119' is defined on line 785, but no explicit reference was found in the text == Unused Reference: 'RFC1142' is defined on line 788, but no explicit reference was found in the text == Unused Reference: 'RFC1195' is defined on line 791, but no explicit reference was found in the text == Unused Reference: 'RFC5305' is defined on line 794, but no explicit reference was found in the text == Unused Reference: 'RFC5029' is defined on line 797, but no explicit reference was found in the text == Unused Reference: 'RFC5307' is defined on line 802, but no explicit reference was found in the text ** Obsolete normative reference: RFC 1142 (Obsoleted by RFC 7142) Summary: 3 errors (**), 0 flaws (~~), 10 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 Huawei Technologies 5 Expires: November 5, 2013 G. Cauchie 7 N. So 8 Tata Communications 9 A. Retana 10 Cisco Systems 11 May 4, 2013 13 IS-IS Topology-Transparent Zone 14 draft-chen-isis-ttz-01.txt 16 Abstract 18 This document presents a topology-transparent zone in a domain. A 19 topology-transparent zone comprises a group of routers and a number 20 of circuits connecting these routers. Any router outside of the zone 21 is not aware of the zone. The information about the circuits and 22 routers inside the zone is not distributed to any router outside of 23 the zone. Any link state change such as a circuit down inside the 24 zone is not seen by any router 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 November 5, 2013. 43 Copyright Notice 45 Copyright (c) 2013 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 2. Conventions Used in This Document . . . . . . . . . . . . . . 4 62 3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 4 63 4. Topology-Transparent Zone . . . . . . . . . . . . . . . . . . 5 64 4.1. Overview of Topology-Transparent Zone . . . . . . . . . . 5 65 4.2. An Example of TTZ . . . . . . . . . . . . . . . . . . . . 5 66 4.2.1. Creation of a TTZ . . . . . . . . . . . . . . . . . . 5 67 4.2.2. TTZ as a Group of Edge Routers Connected . . . . . . . 8 68 4.2.3. TTZ as a Single Router . . . . . . . . . . . . . . . . 8 69 5. Changes to IS-IS Protocols in LSP . . . . . . . . . . . . . . 9 70 5.1. New Sub-TLV for TTZ ID . . . . . . . . . . . . . . . . . . 9 71 5.2. One Bit to Indicate an Internal TTZ Circuit . . . . . . . 10 72 6. Constructing LSP . . . . . . . . . . . . . . . . . . . . . . . 11 73 6.1. Constructing LSP for a Router in TTZ . . . . . . . . . . . 11 74 6.2. Constructing LSP for TTZ as a Group of Edge Routers . . . 12 75 6.3. Constructing LSP for TTZ as a Router . . . . . . . . . . . 12 76 6.3.1. Selection of TTZ-DR for TTZ . . . . . . . . . . . . . 12 77 6.3.2. Constructing LSP for TTZ as a Router . . . . . . . . . 13 78 7. Establishing Adjacencies . . . . . . . . . . . . . . . . . . . 14 79 7.1. Group of Edge Routers for TTZ . . . . . . . . . . . . . . 14 80 7.2. Single Router for TTZ . . . . . . . . . . . . . . . . . . 15 81 8. Distribution of LSPs . . . . . . . . . . . . . . . . . . . . . 16 82 8.1. Distribution of LSPs within TTZ . . . . . . . . . . . . . 16 83 8.2. Distribution of LSPs through TTZ . . . . . . . . . . . . . 16 84 9. Computation of Routing Table . . . . . . . . . . . . . . . . . 16 85 10. Security Considerations . . . . . . . . . . . . . . . . . . . 17 86 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 87 12. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 17 88 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 89 13.1. Normative References . . . . . . . . . . . . . . . . . . . 18 90 13.2. Informative References . . . . . . . . . . . . . . . . . . 18 91 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18 93 1. Introduction 95 The number of routers in an Autonomous System (AS) becomes larger and 96 larger as the Internet traffic keeps growing. Thus the Intermediate 97 System To Intermediate System (IS-IS) Link State Database (LSDB) and 98 IS-IS routing table are bigger and bigger. Any link state change in 99 an AS leads to a number of link state distributions to every router 100 in the AS. This triggers every router in the AS to re-calculate its 101 IS-IS routes, update its Routing Information Base (RIB) and 102 Forwarding Information Base (FIB). All these will consume network 103 resource including network bandwidth and Central Process Unit (CPU) 104 time. This blocks further expansions of a network. 106 RFC 1142 "OSI IS-IS Intra-domain Routing Protocol", which is a 107 republication of ISO/IEC 10589, describes IS-IS areas or levels in an 108 Autonomous System (AS). Each level 1 area has a number of level 1 109 and level 2 routers connected to the level 2 area. Each level 1 and 110 level 2 router may summarize the topology of its attached level 1 111 areas to the level 2 area or vice versa. 113 Through splitting a network into multiple areas, we can extend the 114 network further. However, there are a number of issues when a 115 network is split further into more areas. 117 At first, dividing an AS or an area into multiple areas is a very 118 challenging task since it is involved in significant network 119 architecture changes. 121 Secondly, it is complex for a Multi-Protocol Label Switching (MPLS) 122 Traffic Engineering (TE) Label Switching Path (LSP) crossing multiple 123 areas to be setup. In general, a TE path crossing multiple areas is 124 computed by using collaborating Path Computation Elements (PCEs) 125 [RFC5441] through the PCE Communication Protocol (PCEP)[RFC5440], 126 which is not easy to configure by operators since the manual 127 configuration of the sequence of domains is required. Although this 128 issue can be addressed by using the Hierarchical PCE, this solution 129 may further increase the complexity of network design. Especially, 130 the current PCE standard method may not guarantee that the path found 131 is optimal. 133 Thirdly, some policies need to be configured on level 1 and level 2 134 routers for sumarizing the routes from a level 1 area to level 2 area 135 or vice versa. 137 Furthermore, route convergence may be slower. A router in an IS-IS 138 area can see all other routers in the same area. A link-state change 139 anywhere in an IS-IS area will be populated everywhere in the same 140 area, and may even be distributed to other areas in the same AS 141 indirectly. For example, all the routers and circuits in a Point-Of- 142 Presence (POP) in an IS-IS area will be seen by all the other routers 143 in the same area. Any link state change in the POP will be 144 distributed to all the other routers in the same area and may be 145 distributed to routers in other areas indirectly. 147 A link state change in an area will lead to every router in the same 148 area to re-calculate its IS-IS routes, update its RIB and FIB. It 149 may also lead to a number of link state distributions to other areas. 150 This will trigger routers in other areas to re-calculate their IS-IS 151 routes, update their RIBs and FIBs. Thus the route convergence is 152 slower. 154 This document presents a topology-transparent zone in a domain or an 155 area and describes extensions to IS-IS for supporting the topology- 156 transparent zone, which may resolve the issues above. 158 A topology-transparent zone comprises a group of routers and a number 159 of circuits connecting these routers. Any router outside of the zone 160 is not aware of the zone. The information about the circuits and 161 routers inside the zone is not distributed to any router outside of 162 the zone. Any link state change such as a circuit down inside the 163 zone is not seen by any router outside of the zone. 165 2. Conventions Used in This Document 167 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 168 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 169 document are to be interpreted as described in RFC 2119. 171 3. Requirements 173 Topology-Transparent Zone (TTZ) may be deployed for resolving some 174 ctricial issues such as scalability in existing networks and future 175 networks. The requirements for TTZ are listed as follows: 177 o TTZ MUST be backward compitable. When a TTZ is deployed on a set 178 of routers in a network, the routers outside of the TTZ in the 179 network do not need to know or support TTZ. 181 o TTZ MUST support at least one more levels of network hierarchies, 182 in addition to the hierarchies supported by existing routing 183 protocols. 185 o Users SHOULD be able to easily set up an end to end service 186 crossing TTZs. 188 o The configuration for a TTZ in a network SHOULD be minimum. 190 o The changes on the existing protocols for supporting TTZ SHOULD be 191 minimum. 193 4. Topology-Transparent Zone 195 4.1. Overview of Topology-Transparent Zone 197 A Topology-Transparent Zone (TTZ) comprises an Identifier (ID), a 198 group of routers and a number of circuits connecting the routers. A 199 Topology-Transparent Zone is in an IS-IS sub domain (area). 201 The ID of a Topology-Transparent Zone (TTZ) or TTZ ID is a number 202 that is unique for identifying an entity such as a node in an IS-IS 203 sub domain (area). It is not zero in general. 205 In addition to having the functions of an IS-IS level or area, an 206 IS-IS TTZ makes some improvements on an IS-IS level or area, which 207 include: 209 o An IS-IS TTZ is virtualized as an object, which may be a group of 210 TTZ edge routers connected or a single router. 212 o An IS-IS TTZ receives the link state information about the 213 topology outside of the TTZ, stores the information in the TTZ and 214 floods the information through the TTZ to the routers outside of 215 TTZ. 217 o No Policy configuration is needed on any edge router of a TTZ. 219 4.2. An Example of TTZ 221 4.2.1. Creation of a TTZ 223 The figure below illustrates an example of a routing domain 224 containing a topology-transparent zone: TTZ 600. 226 TTZ 600 227 / 228 / 230 ^~^~^~^~^~^~^~^~^~^~^~^~^~^~^ 231 ( ) 232 ===[R15]========(==[R61]-----------------[R63]==)========[R29]=== 233 || ( | \ / | ) || 234 || ( | \ / | ) || 235 || ( | \ / | ) || 236 || ( | \ / | ) || 237 || ( | \ / | ) || 238 || ( | \ / | ) || 239 || ( | \ / | ) || 240 || ( | _____[R71] | ) || 241 || ( | / / \ | ) || 242 || ( | [R73] / \ | ) || 243 || ( | / \ | ) || 244 || ( | / \ | ) || 245 || ( | / \ | ) || 246 || ( | / \ | ) || 247 || ( | / \ | ) || 248 ===[R17]========(==[R65]-----------------[R67]==)========[R31]=== 249 \\ (// \\ ) // 250 || //v~v~v~v~v~v~v~v~v~v~v~v~v~\\ || 251 || // \\ || 252 || // \\ || 253 || // \\ || 254 || // \\ || 255 || // \\ || 256 \\ // \\ // 257 =====[R23]======================================[R25]===== 258 // \\ 259 // \\ 260 // \\ 262 Figure 1: An Example of TTZ 264 The routing domain comprises routers R15, R17, R23, R25, R29 and R31. 265 It also contains a topology-transparent zone TTZ 600. The TTZ 600 266 comprises routers R61, R63, R65, R67, R71 and R73, and the circuits 267 connecting them. 269 There are two types of routers in a Topology-Transparent Zone (TTZ): 270 TTZ internal routers and TTZ edge routers. A TTZ internal router is 271 a router inside the TTZ and every adjacent router of the TTZ internal 272 router is a router inside the TTZ. A TTZ edge router is a router 273 inside the TTZ and has at least one adjacent router that is outside 274 of the TTZ. 276 The TTZ in the figure above comprises four TTZ edge routers R61, R63, 277 R65 and R67. Each TTZ edge router is connected to at least one 278 router outside of the TTZ. For instance, router R61 is a TTZ edge 279 router since it is connected to router R15, which is outside of the 280 TTZ. 282 In addition, the TTZ comprises two TTZ internal routers R71 and R73. 283 A TTZ internal router is not connected to any router outside of the 284 TTZ. For instance, router R71 is a TTZ internal router since it is 285 not connected to any router outside of the TTZ. It is just connected 286 to routers R61, R63, R65, R67 and R73 inside the TTZ. 288 A TTZ MUST hide the information inside the TTZ from the outside. It 289 MUST NOT directly distribute any internal information about the TTZ 290 to a router outside of the TTZ. 292 For instance, the TTZ in the figure above MUST NOT send the 293 information about TTZ internal router R71 to any router outside of 294 the TTZ in the routing domain; it MUST NOT send the information about 295 the circuit between TTZ router R61 and R65 to any router outside of 296 the TTZ. 298 In order to create a Topology-Transparent Zone (TTZ), we MUST 299 configure the same TTZ ID on every circuit that connects routers 300 inside the TTZ and every router in the TTZ MUST support TTZ feature. 302 For example, the same TTZ ID is configured on the nine circuits 303 below: 305 o the circuit between router R61 and R65, 307 o the circuit between router R65 and R67, 309 o the circuit between router R67 and R63, 311 o the circuit between router R63 and R61, 313 o the circuit between router R71 and R61, 315 o the circuit between router R71 and R63, 317 o the circuit between router R71 and R65, 319 o the circuit between router R71 and R67 and 320 o the circuit between router R71 and R73. 322 Thus six routers R61, R63, R65, R67, R71 and R73, and nine circuits 323 among these six routers form a topology-transparent zone TTZ 600 in 324 the figure above. 326 The configuration of a TTZ can be simplified by just provisioning a 327 TTZ ID on every TTZ internal router instead of on each circuit of 328 every TTZ internal router. The configuration of the TTZ ID on a 329 router indicates that every circuit of the router is a TTZ internal 330 circuit. On every edge router of the TTZ, the TTZ ID is still 331 configured on each circuit connecting to a TTZ router. 333 4.2.2. TTZ as a Group of Edge Routers Connected 335 From a router outside of the TTZ, a TTZ is seen as a group of TTZ 336 edge routers fully connected when the TTZ is virtualized as the group 337 of TTZ edge routers connected. For instance, router R15 in the 338 figure above, which is outside of TTZ 600, sees TTZ 600 as a group of 339 TTZ edge routers: R61, R63, R65 and R67. These four TTZ edge routers 340 are fully connected. 342 In addition, a router outside of the TTZ sees TTZ edge routers having 343 normal connections to the routers outside of the TTZ. For example, 344 router R15 sees four TTZ edge routers R61, R63, R65 and R67, which 345 have the normal connections to R15, R29, R17 and R23, R25 and R31 346 respectively. 348 4.2.3. TTZ as a Single Router 350 A TTZ is seen as a single router from a router outside of the TTZ 351 when the TTZ is virtualized as a single router. For instance, router 352 R15 in the figure above, which is outside of TTZ 600 and connected to 353 TTZ 600 through TTZ edge router R61, sees TTZ 600 as a single router. 355 A router outside of a TTZ sees a number of circuits connected to the 356 TTZ as a single router, each of which is connected to a router 357 outside of the TTZ. For instance, router R15 sees TTZ 600 as a 358 single router with six circuits, connecting to router R15, R17, R23, 359 R25, R29 and R31 respectively. 361 A TTZ as a special single router considers every connection between a 362 router outside of the TTZ and an edge router of the TTZ as a circuit. 363 The Router ID of the virtualized representation of the TTZ SHOULD be 364 the largest or smallest interface IP address of the TTZ-DR (TTZ-DIS) 365 (see Section 6.3.1). 367 5. Changes to IS-IS Protocols in LSP 369 There are a number of ways to extend the existing IS-IS protocols to 370 support TTZ in a Link State Packet (LSP). This section describes a 371 few of them. 373 o One way is to use a new sub-TLV for a TTZ ID to indicate that the 374 circuit described belongs to which TTZ. 376 o Alternatively, a bit in an existing sub-TLV indicates that a 377 circuit is a TTZ circuit or an internal circuit of a TTZ. 379 5.1. New Sub-TLV for TTZ ID 381 The format of extended IS reachability TLV is illustrated in the 382 figure below. 384 Length in Byte 385 +----------------------+ 386 | Type = 22 | 1 387 +----------------------+ 388 | Length | 1 389 +----------------------+ 390 | Neighbor ID | 7 391 +----------------------+ 392 | Default Metric | 3 393 +----------------------+ 394 | Length of Sub-TLVs | 1 395 +----------------------+ 396 | Sub-TLVs | Length of Sub-TLVs 397 +----------------------+ 398 | | 399 | . . . | 400 | | 401 +----------------------+ 402 | Neighbor ID | 7 403 +----------------------+ 404 | Default Metric | 3 405 +----------------------+ 406 | Length of Sub-TLVs | 1 407 +----------------------+ 408 | Sub-TLVs | Length of Sub-TLVs 409 +----------------------+ 411 Figure 2: Extended IS Reachability TLV 413 An extended IS reachability TLV may contain information about a 414 number of neighbors. There may be a series of sub-TLVs for each 415 neighbor in the TLV. 417 A new sub-TLV may be added into the sub-TLVs for a neighbor within 418 the Extended IS Reachability TLV in the figure above. This new sub- 419 TLV has the same format as the sub-TLV for the Traffic Engineering 420 Extensions in RFC 5305, which is shown in the figure below. 422 Length in Byte 423 +----------------------+ 424 | Sub-Type = 30 | 1 425 +----------------------+ 426 | Length | 1 427 +----------------------+ 428 | TTZ ID | 4 429 +----------------------+ 431 Figure 3: Sub-TLV for TTZ ID 433 The sub-TLV for TTZ ID has 1 byte of Sub-Type, 1 byte of Length of 434 the value field of the sub-TLV, which is followed by 4 bytes of value 435 field for TTZ ID. 437 The sub-TLV for TTZ ID is OPTIONAL and MUST appear at most once for 438 an IS neighbor. If this kind of sub-TLV appears more than once under 439 the same IS neighbor in a received Link State Packet (LSP), only the 440 first one SHOULD be considered and the others should be ingored. 442 For a circuit connecting to an neighboring router outside of a TTZ 443 from a TTZ edge router, there is not any TTZ ID sub-TLV under the 444 neighbor or the value field of the sub-TLV for TTZ ID is zero, 445 indicating that this circuit is an external TTZ circuit. 447 For a circuit connecting to an neighboring router inside a TTZ, there 448 is a TTZ ID sub-TLV under the neighbor, the value field for TTZ ID in 449 the sub-TLV is not zero and is a TTZ ID, indicating that this circuit 450 is an internal TTZ circuit to the neighbor and the circuit belongs to 451 the TTZ given by the TTZ ID. 453 5.2. One Bit to Indicate an Internal TTZ Circuit 455 The existing link-attribute sub-TLV within the extended IS 456 reachability TLV has 16-bit flags of value field. One of 16-bit 457 flags may be used to indicate an Internal TTZ circuit as follows: 459 0 1 2 3 460 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 461 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 462 | sub-Type = 19 | Length | |I| | | 463 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 465 I bit flag: 467 1: This indicates that the router circuit/link is an internal circuit 468 to a router inside the TTZ. 470 0: This indicates that the router circuit/link is an external circuit. 472 Figure 4: Bit to Indicate Internal TTZ Link 474 The link attribute sub-TLV is OPTIONAL and MUST appear at most once 475 for an IS neighbor. If this kind of sub-TLV appears more than once 476 under the same IS neighbor in a received Link State Packet (LSP), 477 only the first one SHOULD be considered and the others should be 478 ingored. 480 For a circuit connecting to an neighboring router inside a TTZ, there 481 is a link attribute sub-TLV under the neighbor and the value of I bit 482 flag in the sub-TLV for the neighbor is set to one, indicating that 483 this circuit is an internal TTZ circuit to the neighbor. 485 For a circuit connecting to an neighboring router outside of a TTZ 486 from a TTZ edge router, there is not any link attribute sub-TLV for 487 the neighbor or the value of I bit flag in the sub-TLV for the 488 neighbor is zero, indicating that this circuit is an external TTZ 489 circuit. 491 6. Constructing LSP 493 Two types of Link State Packets(LSPs) are generated. One is 494 constructed by every router in a TTZ for the router to describe the 495 circuits connecting to it. The other is generated by some routers in 496 the TTZ to virtualize the TTZ as a group of edge routers connected or 497 a single router. 499 6.1. Constructing LSP for a Router in TTZ 501 Every router in a TTZ constructs a LSP for the router that comprises 502 both the circuits connecting to the routers inside the TTZ and the 503 circuits connecting to the routers outside of the TTZ. It sends this 504 LSP to its neighboring routers in the TTZ. For each of the circuits 505 in the LSP, it can be represented in one of the ways described in the 506 previous section. 508 For example, when "One Bit to Indicate an Internal TTZ circuit" is 509 used as an extension, for each of the router circuits in the LSP, the 510 value of I bit flag is set to one for an internal circuit inside the 511 TTZ; and the value of I bit flag is set to zero for an external 512 circuit connecting to a router outside of the TTZ. 514 When a router inside a TTZ receives a link state packet (LSP) from a 515 neighboring router in the TTZ, it stores the link state and floods 516 the link state to the other neighboring routers in the TTZ. 518 When a TTZ edge router receives a TTZ internal link state packet for 519 a router inside the TTZ from a neighboring router in the TTZ, it 520 stores the link state and floods the link state to the other 521 neighboring routers inside the TTZ. It does not flood the link state 522 to any of its neighboring routers outside of the TTZ. 524 6.2. Constructing LSP for TTZ as a Group of Edge Routers 526 For every edge router of a TTZ, in addition to generate a LSP 527 described above, it constructs a second LSP for the router and sends 528 this second LSP to its neighboring routers. The second LSP comprises 529 two groups of circuits. 531 The first group of circuits are the circuits connecting the routers 532 outside of the TTZ from this TTZ edge router. These circuits are 533 normal circuits. There is a circuit for every adjacency between this 534 TTZ edge router and a router outside of the TTZ. 536 The second group of circuits are the "virtual" circuits. For each of 537 the other TTZ edge routers, there is a "virtual" circuit to it from 538 this TTZ edge router. The cost of the circuit from this TTZ router 539 to one of the other TTZ edge routers may be the cost of the shortest 540 path from this TTZ edge router to it. 542 6.3. Constructing LSP for TTZ as a Router 544 6.3.1. Selection of TTZ-DR for TTZ 546 Every TTZ has a TTZ Designated Router (TTZ-DR). The TTZ-DR 547 originates LSPs for the TTZ. 549 The TTZ-DR for a TTZ is elected as follows: When a TTZ router first 550 becomes functional, it checks to see whether there is currently a 551 TTZ-DR for the TTZ. If there is, it accepts that TTZ-DR, regardless 552 of its router ID. Otherwise, the router itself becomes TTZ-DR if it 553 has the highest router ID among all the TTZ routers. 555 6.3.2. Constructing LSP for TTZ as a Router 557 For the TTZ-DR in a TTZ, in addition to generate a LSP described 558 above, it constructs a second LSP or special LSP for the TTZ as a 559 special single router and sends this second LSP to its neighboring 560 routers. 562 The second LSP comprises all the circuits connecting the routers 563 outside of the TTZ from any TTZ edge router. The LSP ID is the ID of 564 the special router for the TTZ. 566 When the TTZ-DR in the TTZ constructs and sends an IS-IS packet to 567 its neighboring routers, it sets the Source ID in the packet header 568 of the packet to the ID of the special router for the TTZ. 570 The ID of the special router can be derived from the largest 571 interface IP address of the TTZ-DR if it is not the ID of the TTZ-DR; 572 otherwise, it can be dereived the smallest interface IP address of 573 the TTZ-DR. 575 A procedure for constructing all the circuits of a Special LSP (SL) 576 on the TTZ-DR is described below in pseudo code. From the point of 577 view of the router outside of the TTZ, this Special LSP (SL) does not 578 contain any TTZ specific information, it is just a normal LSP 579 containing indormation about circuits from the router for the TTZ to 580 the routers outside of the TTZ. 582 For each router LSP in the TTZ 583 { 584 For each router circuit in the LSP 585 { 586 If the circuit is an external circuit 587 { 588 Add the circuit into router LSP SL as a normal circuit; 589 } 590 } 591 } 593 Figure 5: Procedure for Constructing LSP for TTZ 595 Each LSP in the TTZ is a LSP that is generated by a router inside the 596 TTZ and is sent to routers inside the TTZ. 598 In the case of that "One Bit to Indicate an Internal TTZ circuit" is 599 used as an extension to the link attribute sub-TLV, the condition of 600 the If statement is true if there is not any link attribute sub-TLV 601 for the neighbor or the value of I bit flag in the sub-TLV for the 602 neighbor is zero. 604 In the body of the If statement, the circuit for the external circuit 605 is added into the LSP SL as a normal circuit. 607 7. Establishing Adjacencies 609 A router in a TTZ forms an adjacency with another router in the TTZ 610 in the same way as a normal router when these two routers have a 611 common connection. 613 An alternative way for forming an adjacency between two routers in a 614 TTZ is to extend hello protocol. Hello protocol is extended to 615 include TTZ ID in hello packets. The procedure for handling hellos 616 is changed to consider TTZ ID. When two routers have the same TTZ 617 IDs in their hellos, an adjacency between these two routers is to be 618 formed. 620 For an edge router in a TTZ, in addtion to establishing adjacencies 621 with other routers in the TTZ that have connections with the edge 622 routerk, it forms an adjacency with any router outside of the TTZ 623 that has a connection with the edge router. 625 When the edge router in the TTZ forms the adjacency with the router 626 outside of the TTZ, there are a few of options. A first option is 627 that it acts as a TTZ edge router, which is one of the group of edge 628 routers for TTZ; A second option is that it acts as a special single 629 router for the TTZ. 631 7.1. Group of Edge Routers for TTZ 633 An edge router of a TTZ, acting as one of the group of edge routers 634 for the TTZ, forms an adjacency with a router outside of the TTZ in a 635 way descibed below. 637 During and after the adjacency establishment, every IS-IS protocol 638 packet such as CSNP, which is sent to the router outside of the TTZ 639 by the edge router, contains the edge router identifier (ID) as 640 Source ID. 642 When the edge router synchronizes its link state database with the 643 router outside of the TTZ, it sends the router outside of the TTZ the 644 information about all the LSPs except for the LSPs belong to the TTZ 645 that are hidden from any router outside of the TTZ. 647 At the end of the link state database synchronization, the edge 648 router originates its own LSP and sends this LSP to the router 649 outside of the TTZ. This LSP contains two groups of circuits. 651 The first group of circuits are the circuits connecting to the 652 routers outside of the TTZ from this TTZ edge router. The second 653 group of circuits are the "virtual" circuits connecting to the other 654 TTZ edge routers from this TTZ edge router. 656 From the point of view of the router outside of the TTZ, it sees the 657 other end as a normal router and forms the adjacency in the same way 658 as a normal router. It is not aware of anything about its 659 neighboring TTZ. From the LSPs related to the TTZ edge router in the 660 other end, it knows that the TTZ edge router is connected to each of 661 the other TTZ edge routers and some routers outside of the TTZ. 663 7.2. Single Router for TTZ 665 An edge router of a TTZ, acting as a special single router for the 666 TTZ, forms an adjacency with a router outside of the TTZ in a way 667 descibed below. 669 During and after the adjacency establishment, every IS-IS protocol 670 packet such as CSNP, which is sent to the router outside of the TTZ 671 by the edge router, contains the special single router ID as Source 672 ID. 674 When the edge router synchronizes its link state database with the 675 router outside of the TTZ, it sends the router outside of the TTZ the 676 information about all the LSPs except for the LSPs belong to the TTZ 677 that are hidden from any router outside of the TTZ. 679 At the end of the link state database synchronization, the LSP for 680 the TTZ is originated and sent to the router outside of the TTZ. 681 This LSP contains the router circuits from every TTZ edge router to 682 routers outside of the TTZ. 684 From the point of view of the router outside of the TTZ, it sees the 685 other end as a normal single router and forms the adjacency in the 686 same way as a normal router. It is not aware of anything about its 687 neighboring TTZ. From the LSPs related to the special router in the 688 other end, it knows that the special router for the TTZ is connected 689 to the routers outside of the TTZ having connections to edge routers 690 of the TTZ. 692 8. Distribution of LSPs 694 LSPs can be divided into two classes according to their 695 distributions. One class of LSPs is distributed within a TTZ. The 696 other is distributed through a TTZ. 698 8.1. Distribution of LSPs within TTZ 700 Any LSP generated for a router in a TTZ is distributed within the 701 TTZ. It will not be distributed to any router outside of the TTZ. 703 For example, any router LSP generated for a router in a TTZ is 704 distributed within the TTZ. It will not be distributed to any router 705 outside of the TTZ. 707 Any pseudonode LSP generated for a broadcast network inside a TTZ, is 708 distributed within the TTZ. It will not be distributed to any router 709 outside of the TTZ. 711 8.2. Distribution of LSPs through TTZ 713 Any LSP about a link state outside of a TTZ received by an edge 714 router of the TTZ is distributed through the TTZ; and any LSP about a 715 link state for the TTZ is distributed through the TTZ. 717 For example, when an edge router of a TTZ receives an LSP for a link 718 state outside of the TTZ from a router outside of the TTZ, it floods 719 it to its neighboring routers both inside the TTZ and outside of the 720 TTZ. This LSP may be any LSP such as a router LSP that is 721 distributed in a domain. 723 The routers in the TTZ continue to flood the LSP. When another edge 724 router of the TTZ receives the LSP, it floods the LSP to its 725 neighboring routers both outside of the TTZ and inside the TTZ. 727 In the case that a TTZ is virtualized as a group of edge routers of 728 the TTZ connected, every edge router of the TTZ generates a router 729 LSP for the TTZ. This LSP is distributed to the routers outside of 730 the TTZ and to the routers inside the TTZ. 732 9. Computation of Routing Table 734 The computation of the routing table on a router outside of a TTZ is 735 the same as that described in RFC 1142. On a router in a TTZ, the 736 computation of the routing table has the same procedure flow as that 737 described in RFC 1142, but extends the meaning of a circuit and an 738 association between two vertexes. In this section, we specify the 739 extensions, and describe the routing table computation on a router 740 inside the TTZ. 742 A link between two vertexes can be a TTZ circuit. It can also be a 743 normal circuit. 745 When examining the LSP associated with vertex V, for each described 746 circuit in the LSP, supposing that vertex W is the other end of the 747 link, 749 o if it is a normal circuit, then vertex W is an adjacent vertex of 750 vertex V; 752 o if it is an internal TTZ circuit and the LSP is generated by a 753 router in a TTZ, then vertex W can be considered as an adjacent 754 vertex of vertex V; 756 o if it is an external TTZ circuit and the LSP is generated by a TTZ 757 edge router, then vertex W, which is the other end of the external 758 TTZ circuit and outside of the TTZ, can be considered as an 759 adjacent vertex of vertex V. 761 When a TTZ is virtualized as a group of TTZ edge routers fully 762 connected, the routing table on a router inside the TTZ is computed 763 through using the link state database (LSDB) containing the LSPs for 764 the topology of the TTZ and the LSPs for the topology outside of the 765 TTZ. That is that the shortest path to every destination both inside 766 the TTZ and outside of the TTZ is computed over all the circuits 767 including the circuits inside the TTZ and the circuits outside of the 768 TTZ. 770 10. Security Considerations 772 The mechanism described in this document does not raise any new 773 security issues for the IS-IS protocols. 775 11. IANA Considerations 777 12. Acknowledgement 779 The author would like to thank Dean Cheng, Acee Lindem for their 780 valuable comments on this draft. 782 13. References 783 13.1. Normative References 785 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 786 Requirement Levels", BCP 14, RFC 2119, March 1997. 788 [RFC1142] Oran, D., "OSI IS-IS Intra-domain Routing Protocol", 789 RFC 1142, February 1990. 791 [RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and 792 dual environments", RFC 1195, December 1990. 794 [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic 795 Engineering", RFC 5305, October 2008. 797 [RFC5029] Vasseur, JP. and S. Previdi, "Definition of an IS-IS Link 798 Attribute Sub-TLV", RFC 5029, September 2007. 800 13.2. Informative References 802 [RFC5307] Kompella, K. and Y. Rekhter, "IS-IS Extensions in Support 803 of Generalized Multi-Protocol Label Switching (GMPLS)", 804 RFC 5307, October 2008. 806 Authors' Addresses 808 Huaimo Chen 809 Huawei Technologies 810 Boston, MA 811 US 813 Email: huaimo.chen@huawei.com 815 Renwei Li 816 Huawei Technologies 817 2330 Central expressway 818 Santa Clara, CA 819 US 821 Email: renwei.li@huawei.com 823 Gregory Cauchie 824 FRANCE 826 Email: greg.cauchie@gmail.com 827 Ning So 828 Tata Communications 829 2613 Fairbourne Cir. 830 Plano, TX 75082 831 USA 833 Email: ning.so@tatacommunications.com 835 Alvaro Retana 836 Cisco Systems 837 2610 Wycliff Road 838 Raleigh, NC 27607 839 USA 841 Email: aretana@cisco.com