idnits 2.17.1 draft-chen-ospf-te-ttz-02.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 (March 21, 2016) is 2958 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Missing Reference: 'R71' is mentioned on line 150, but not defined == Missing Reference: 'R73' is mentioned on line 151, but not defined == Unused Reference: 'RFC2119' is defined on line 427, but no explicit reference was found in the text == Unused Reference: 'RFC2328' is defined on line 432, but no explicit reference was found in the text == Unused Reference: 'RFC2370' is defined on line 436, but no explicit reference was found in the text == Unused Reference: 'RFC3630' is defined on line 440, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2370 (Obsoleted by RFC 5250) Summary: 1 error (**), 0 flaws (~~), 7 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force H. Chen 3 Internet-Draft R. Li 4 Intended status: Experimental Huawei Technologies 5 Expires: September 22, 2016 G. Cauchie 7 A. Retana 8 Cisco Systems, Inc. 9 N. So 10 Tata Communications 11 F. Xu 12 Verizon 13 V. Liu 14 China Mobile 15 M. Toy 16 Comcast 17 L. Liu 18 Fujitsu 19 March 21, 2016 21 OSPF TE Topology-Transparent Zone 22 draft-chen-ospf-te-ttz-02.txt 24 Abstract 26 A topology-transparent zone is virtualized as the edges of the zone 27 fully connected. This document proposes extensions to OSPF protocols 28 to support Traffic Engineering (TE) topology-transparent zone. 30 Status of this Memo 32 This Internet-Draft is submitted to IETF in full conformance with the 33 provisions of BCP 78 and BCP 79. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF). Note that other groups may also distribute 37 working documents as Internet-Drafts. The list of current Internet- 38 Drafts is at http://datatracker.ietf.org/drafts/current/. 40 Internet-Drafts are draft documents valid for a maximum of six months 41 and may be updated, replaced, or obsoleted by other documents at any 42 time. It is inappropriate to use Internet-Drafts as reference 43 material or to cite them other than as "work in progress." 45 This Internet-Draft will expire on September 22, 2016. 47 Copyright Notice 48 Copyright (c) 2016 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (http://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 64 2. Conventions Used in This Document . . . . . . . . . . . . . . 3 65 3. Overview of Topology-Transparent Zone . . . . . . . . . . . . 3 66 4. Extensions to OSPF Protocols . . . . . . . . . . . . . . . . . 5 67 4.1. Add TTZ ID TLV into Existing TE LSA . . . . . . . . . . . 5 68 4.1.1. Updating TE LSAs for a TTZ Router . . . . . . . . . . 6 69 4.1.2. Originating TE LSAs for a TTZ Edge Router . . . . . . 6 70 4.2. Put an Existing TE LSA in Another LSA . . . . . . . . . . 6 71 4.2.1. Originating TTZ TE LSAs for a TTZ Router . . . . . . . 7 72 4.2.2. Originating TE LSAs for a TTZ Edge Router . . . . . . 7 73 4.2.3. Flushing Out TE LSAs for a TTZ Router . . . . . . . . 8 74 4.3. Comparison of Two Ways . . . . . . . . . . . . . . . . . . 8 75 5. Computation of TE Path . . . . . . . . . . . . . . . . . . . . 8 76 6. Summarizing TE Information in TTZ . . . . . . . . . . . . . . 8 77 7. Security Considerations . . . . . . . . . . . . . . . . . . . 9 78 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 79 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 9 80 10. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 10 81 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 82 11.1. Normative References . . . . . . . . . . . . . . . . . . . 10 83 11.2. Informative References . . . . . . . . . . . . . . . . . . 11 84 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 86 1. Introduction 88 The number of routers in a network becomes larger and larger as the 89 Internet traffic keeps growing. Through splitting the network into 90 multiple areas, we can extend the network further. However, there 91 are a number of issues when a network is split further into more 92 areas. 94 At first, dividing a network into more areas is a very challenging 95 and time consuming since it is involved in significant network 96 architecture changes. 98 Secondly, the services carried by the network may be interrupted 99 while the network is being split into more areas. 101 Furthermore, it is complex for a TE LSP crossing areas to be setup. 102 In one option, a TE path crossing areas is computed by using 103 collaborating PCEs [RFC5441] through PCEP[RFC5440], which is not easy 104 to configure by operators since the manual configuration of the 105 sequence of domains is required. Especially, the current PCE 106 standard method may not guarantee that the path found is optimal. 108 Topology-transparent zone (TTZ) resolves these issues. This document 109 proposes extensions to OSPF protocols to support Traffic Engineering 110 (TE) topology-transparent zone. 112 2. Conventions Used in This Document 114 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 115 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 116 document are to be interpreted as described in RFC 2119. 118 3. Overview of Topology-Transparent Zone 120 A Topology-Transparent Zone (TTZ) is identified by an Identifier 121 (ID), and it includes a group of routers and a number of links 122 connecting the routers. A Topology-Transparent Zone is in an OSPF 123 domain. 125 The ID of a Topology-Transparent Zone (TTZ) or TTZ ID is a number 126 that is unique for identifying an entity such as a node in an OSPF 127 domain. It is not zero in general. 129 In addition to having the functions of an OSPF area, an OSPF TTZ 130 makes some improvements on an OSPF area, which include: 132 o An OSPF TTZ is virtualized as a group of TTZ edge routers fully 133 connected. 135 o An OSPF TTZ receives the link state information about the topology 136 outside of the TTZ, stores the information in the TTZ and floods 137 the information through the TTZ to the routers outside of TTZ. 139 The figure below illustrates an area containing a TTZ: TTZ 600. 141 TTZ 600 142 \ 143 \ ^~^~^~^~^~^~^~^~^~^~^~^~ 144 ( ) 145 ===[R15]========(==[R61]------------[R63]==)======[R29]=== 146 || ( | \ / | ) || 147 || ( | \ / | ) || 148 || ( | \ / | ) || 149 || ( | ___\ / | ) || 150 || ( | / [R71] | ) || 151 || ( | [R73] / \ | ) || 152 || ( | / \ | ) || 153 || ( | / \ | ) || 154 || ( | / \ | ) || 155 ===[R17]========(==[R65]------------[R67]==)======[R31]=== 156 \\ (// \\) // 157 || //v~v~v~v~v~v~v~v~v~v~v~\\ || 158 || // \\ || 159 || // \\ || 160 \\ // \\ // 161 ======[R23]==============================[R25]===== 162 // \\ 163 // \\ 165 Figure 1: An Example of TTZ 167 The area comprises routers R15, R17, R23, R25, R29 and R31. It also 168 contains TTZ 600, which comprises routers R61, R63, R65, R67, R71 and 169 R73, and the links connecting them. 171 There are two types of routers in a TTZ: TTZ internal routers and TTZ 172 edge routers. A TTZ internal router is a router inside the TTZ and 173 its adjacent routers are in the TTZ. A TTZ edge router is a router 174 inside the TTZ and has at least one adjacent router that is outside 175 of the TTZ. 177 The TTZ in the figure above comprises four TTZ edge routers R61, R63, 178 R65 and R67. Each TTZ edge router is connected to at least one 179 router outside of the TTZ. For instance, router R61 is a TTZ edge 180 router since it is connected to router R15, which is outside of the 181 TTZ. 183 In addition, the TTZ comprises two TTZ internal routers R71 and R73. 184 A TTZ internal router is not connected to any router outside of the 185 TTZ. For instance, router R71 is a TTZ internal router since it is 186 not connected to any router outside of the TTZ. It is just connected 187 to routers R61, R63, R65, R67 and R73 inside the TTZ. 189 A TTZ hides the information inside the TTZ from the outside. It does 190 not directly distribute any internal information about the TTZ to a 191 router outside of the TTZ. 193 For instance, the TTZ in the figure above does not send the 194 information about TTZ internal router R71 to any router outside of 195 the TTZ in the routing domain; it does not send the information about 196 the link between TTZ router R61 and R65 to any router outside of the 197 TTZ. 199 From a router outside of the TTZ, a TTZ is seen as a group of routers 200 fully connected. For instance, router R15 in the figure above, which 201 is outside of TTZ 600, sees TTZ 600 as a group of TTZ edge routers: 202 R61, R63, R65 and R67. These four TTZ edge routers are fully 203 connected. The cost of the "link" from one edge router to another 204 edge router is the cost of the shortest path between these two 205 routers. The bandwidth of the "link" is the maximum bandwidth of a 206 path between the two routers. 208 In addition, a router outside of the TTZ sees TTZ edge routers having 209 normal connections to the routers outside of the TTZ. For example, 210 router R15 sees four TTZ edge routers R61, R63, R65 and R67, which 211 have the normal connections to R15, R29, R17 and R23, R25 and R31 212 respectively. 214 4. Extensions to OSPF Protocols 216 There are a couple of ways in which OSPF protocols are extened to 217 support OSPF TE TTZ. One way is to add a TTZ ID TLV into an existing 218 TE LSA. Another way is to put the contents of an existing TE LSA 219 into another opaque LSA with a TTZ ID TLV. 221 4.1. Add TTZ ID TLV into Existing TE LSA 223 A TTZ ID TLV below, which is defined in OSPF TTZ, is added into an 224 existing OSPF TE LSA. 226 0 1 2 3 227 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 228 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 229 | TTZ-ID-TLV-type | Length = 4 | 230 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 231 | TTZ ID | 232 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 234 4.1.1. Updating TE LSAs for a TTZ Router 236 When a TTZ router receives a CLI command triggering TTZ information 237 distribution for migration or an LSA containing a TTZ Options TLV 238 with T = 1, it knows that distributing TTZ information is started. 240 A TTZ router adds a TTZ ID TLV into each of its existing TE LSAs and 241 floods the LSAs to its neighbors after distributing TTZ information 242 starts. 244 When a router inside the TTZ receives a TE LSA containing a TTZ ID 245 TLV from a neighboring router in the TTZ, it stores the TE link state 246 for the TE TTZ and floods the link state to the other neighboring 247 routers. 249 4.1.2. Originating TE LSAs for a TTZ Edge Router 251 When a TTZ router receives a CLI command activating migration to TTZ 252 or an LSA containing a TTZ Options TLV with M = 1, it knows that the 253 migration to TTZ is initiated. 255 A TTZ edge router originates a TE LSA for a P2P TE "link" to each of 256 the other TTZ edge routers after the migration to TTZ starts. The 257 metric of the link is the metric of the shortest path between two 258 edge routers within the TTZ. The bandwidth of the link is the 259 maximum bandwidth of a path between the two TTZ edge routers within 260 the TTZ. 262 The edge router of a TTZ does not distribute any TE LSA with a TTZ ID 263 TLV containing the ID of the TTZ to a router outside of the TTZ after 264 the migration to TTZ starts. 266 4.2. Put an Existing TE LSA in Another LSA 268 The TE LSAs about a TTZ describes the TE TTZ topology. These LSAs 269 can be contained and distributed in opaque LSAs within the TTZ. 270 These opaque LSAs are called TTZ opaque LSAs or TTZ LSAs for short. 272 The following is a general form of a TTZ LSA, which is defined in 273 OSPF TTZ. It has an LS type = 10 and TTZ-LSA-Type, and contains a 274 number of TLVs. 276 0 1 2 3 277 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 278 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 279 | LS age | Options | LS Type = 10 | 280 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 281 | TTZ-LSA-Type | Opaque ID | 282 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 283 | Advertising Router | 284 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 285 | LS Sequence Number | 286 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 287 | LS checksum | Length | 288 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 289 | | 290 ~ TLVs ~ 291 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 293 Where a new value (TTZ-TE-LSA-Type) for TTZ TE LSA is introduced for 294 TTZ-LSA-Type. 296 4.2.1. Originating TTZ TE LSAs for a TTZ Router 298 After distributing TTZ information starts, a router in a TTZ 299 originates a TTZ TE LSA for each of its existing TE LSAs and floods 300 the TTZ TE LSA to its neighbors. For an existing TE LSA, the TTZ TE 301 LSA contains the TLVs in the existing TE LSA and a TTZ ID TLV with 302 the ID of the TTZ. 304 When a router inside the TTZ receives a TTZ TE LSA from a neighboring 305 router in the TTZ, it stores the TE link state for the TTZ and floods 306 the link state to the other neighboring routers. 308 4.2.2. Originating TE LSAs for a TTZ Edge Router 310 A TTZ edge router originates a TE LSA for a P2P TE "link" to each of 311 the other TTZ edge routers after the migration to TTZ starts. The 312 metric of the link is the metric of the shortest path between two 313 edge routers within the TTZ. The bandwidth of the link is the 314 maximum bandwidth of a path between the two TTZ edge routers within 315 the TTZ. 317 The edge router of a TTZ does not distribute any TTZ TE LSA to a 318 router outside of the TTZ after the migration to TTZ starts. 320 4.2.3. Flushing Out TE LSAs for a TTZ Router 322 A TTZ router SHOULD flush out its existing TE LSAs after their 323 corresponding TTZ TE LSAs are originated and the migration to TTZ is 324 done for a short given time such as one minute. 326 4.3. Comparison of Two Ways 328 The first way seems simple, in which the existing TE LSAs are used. 329 In addition, it may use less memory. However, it is hard to flush 330 out the TE LSAs with TTZ ID TLVs after migration to TTZ. 332 The second way uses two separated sets of LSAs. One set is for the 333 normal TE topology of a TTZ; the other set is for the TTZ TE topology 334 of the TTZ. Thus it is easy to flush out the normal TE LSAs of the 335 TTZ after migration to TTZ. Moreover, it is cleaner. 337 It seems that the second way is preferred since it is cleaner. 339 5. Computation of TE Path 341 The computation of a TE path on a router outside of a TTZ is the same 342 as before. On a router in a TTZ, the computation of a TE path has 343 the same procedure flow as before, with one exception. A router in a 344 TTZ MUST ignore the TE links in the TE LSAs generated by the edge 345 routers of the TTZ for virtualizing the TE TTZ. 347 A TE path on a router inside the TTZ is computed through using the TE 348 link state database (LSDB) containing the TE topology of the TTZ and 349 the TE topology outside of the TTZ. 351 6. Summarizing TE Information in TTZ 353 The Traffic Engineering (TE) information about a TTZ may be 354 summarized to the outside of the TTZ as the edges of the TTZ fully 355 connected. The TE link (virtual) between two edges may have the 356 maximum bandwidth of a path between them. The procedure below 357 illustrates a way to find the bandwidth for the TE link. 359 L1: candidate-list = {{root, MaxBW}}; result-tree = { }. 360 Where for edge Ei, root = Ei; MaxBW is a maximum number. 362 L2: While candidate-list != { } do 364 L3: Select node with maximum bandwidth from candidate-list 365 as working node k; 366 remove it from candidate-list; add it into result-tree. 368 L4: Suppose that BWk is the bandwidth of working node k 369 (i.e., BWk is the maximum bandwidth from root to node k). 370 For each node x connected to node k and not in result-tree, 371 find the bandwidth BWx of node x as follows: 372 BWx = min{BWk, BWk-x}, where 373 BWk-x is the bandwidth of the link from node k to node x. 374 If node x is not in candidate-list, 375 then add {x, BWx} into candidate-list; 376 otherwise (i.e., {x, BWx0} is in candidate-list), 377 if BWx > BWx0, 378 then replace {x, BWx0} in candidate-list with {x, BWx}. 380 L5: end-while 382 L6: Maximum bandwidth from Ei to every other edge node Ej is found. 384 Figure 2: Find Bandwidth of TE Link between Two Edges 386 Note that we should have solutions for summarizing SRLGs and link 387 colors for a TTZ, which are challenging. 389 7. Security Considerations 391 The mechanism described in this document does not raise any new 392 security issues for the OSPF protocols. 394 8. IANA Considerations 396 TBD 398 9. Contributors 399 Veerendranatha Reddy Vallem 400 Huawei Technologies 401 Banglore 402 India 403 Email: veerendranatharv@huawei.com 405 William McCall 406 cisco Systems, Inc. 407 Bellevue, WA 408 USA 409 wimccall@cisco.com 411 Anil Kumar S N 412 Huawei Technologies 413 Banglore 414 India 415 Email: anil.sn@huawei.com 417 10. Acknowledgement 419 The author would like to thank Hannes Gredler, Igor Bryskin, Acee 420 Lindem, Abhay Roy, Wenhu Lu, and Dean Cheng for their valuable 421 comments. 423 11. References 425 11.1. Normative References 427 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 428 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ 429 RFC2119, March 1997, 430 . 432 [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, DOI 10.17487/ 433 RFC2328, April 1998, 434 . 436 [RFC2370] Coltun, R., "The OSPF Opaque LSA Option", RFC 2370, 437 DOI 10.17487/RFC2370, July 1998, 438 . 440 [RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering 441 (TE) Extensions to OSPF Version 2", RFC 3630, 442 DOI 10.17487/RFC3630, September 2003, 443 . 445 11.2. Informative References 447 [RFC5441] Vasseur, JP., Ed., Zhang, R., Bitar, N., and JL. Le Roux, 448 "A Backward-Recursive PCE-Based Computation (BRPC) 449 Procedure to Compute Shortest Constrained Inter-Domain 450 Traffic Engineering Label Switched Paths", RFC 5441, 451 DOI 10.17487/RFC5441, April 2009, 452 . 454 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 455 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 456 DOI 10.17487/RFC5440, March 2009, 457 . 459 Authors' Addresses 461 Huaimo Chen 462 Huawei Technologies 463 Boston, MA 464 USA 466 Email: huaimo.chen@huawei.com 468 Renwei Li 469 Huawei Technologies 470 2330 Central expressway 471 Santa Clara, CA 472 USA 474 Email: renwei.li@huawei.com 476 Gregory Cauchie 477 FRANCE 479 Email: greg.cauchie@gmail.com 481 Alvaro Retana 482 Cisco Systems, Inc. 483 7025 Kit Creek Rd. 484 Raleigh, NC 27709 485 USA 487 Email: aretana@cisco.com 488 Ning So 489 Tata Communications 490 2613 Fairbourne Cir. 491 Plano, TX 75082 492 USA 494 Email: ning.so@tatacommunications.com 496 Fengman Xu 497 Verizon 498 2400 N. Glenville Dr 499 Richardson, TX 75082 500 USA 502 Email: fengman.xu@verizon.com 504 Vic Liu 505 China Mobile 506 No.32 Xuanwumen West Street, Xicheng District 507 Beijing, 100053 508 China 510 Email: liuzhiheng@chinamobile.com 512 Mehmet Toy 513 Comcast 514 1800 Bishops Gate Blvd. 515 Mount Laurel, NJ 08054 516 USA 518 Email: mehmet_toy@cable.comcast.com 520 Lei Liu 521 Fujitsu 522 USA 524 Email: lliu@us.fujitsu.com