idnits 2.17.1 draft-chen-teas-rsvp-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 doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (June 1, 2017) is 2521 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 239, but not defined == Missing Reference: 'R73' is mentioned on line 240, but not defined == Unused Reference: 'RFC2119' is defined on line 323, but no explicit reference was found in the text == Unused Reference: 'RFC3031' is defined on line 328, but no explicit reference was found in the text == Unused Reference: 'RFC3209' is defined on line 333, but no explicit reference was found in the text == Unused Reference: 'RFC4090' is defined on line 338, but no explicit reference was found in the text Summary: 0 errors (**), 0 flaws (~~), 8 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force H. Chen 3 Internet-Draft R. Li 4 Intended status: Standards Track Huawei Technologies 5 Expires: December 3, 2017 G. Cauchie 7 A. Retana 8 Cisco Systems, Inc. 9 N. So 10 Tata Communications 11 F. Xu 12 M. Toy 13 Verizon 14 V. Liu 15 China Mobile 16 L. Liu 17 Fijitsu 18 June 1, 2017 20 TE LSP Crossing Topology-Transparent Zones 21 draft-chen-teas-rsvp-ttz-02.txt 23 Abstract 25 A topology-transparent zone is virtualized as the edges of the zone 26 fully connected. This document presents the procedures for the 27 establishment of Traffic Engineering (TE) LSPs crossing Topology- 28 Transparent Zones. 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 December 3, 2017. 47 Copyright Notice 48 Copyright (c) 2017 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 (TTZ) . . . . . . . . . . 3 66 4. Set up TE LSPs crossing TTZs . . . . . . . . . . . . . . . . . 5 67 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 8 68 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 8 69 7. Normative References . . . . . . . . . . . . . . . . . . . . . 8 70 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 72 1. Introduction 74 The number of routers in a network becomes larger and larger as the 75 Internet traffic keeps growing. Through splitting the network into 76 multiple areas, we can extend the network further. However, there 77 are a number of issues when a network is split further into more 78 areas. 80 At first, dividing a network into more areas is a very challenging 81 and time consuming since it is involved in significant network 82 architecture changes. 84 Secondly, the services carried by the network may be interrupted 85 while the network is being split into more areas. 87 Furthermore, it is complex for a TE LSP crossing areas to be setup. 88 In one option, a TE path crossing areas is computed by using 89 collaborating PCEs [RFC5441] through PCEP[RFC5440], which is not easy 90 to configure. 92 Topology-transparent zone (TTZ) resolves these issues. This document 93 briefs TTZ and presents the procedures for the establishment of TE 94 LSPs crossing TTZs. 96 2. Conventions Used in This Document 98 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 99 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 100 document are to be interpreted as described in RFC 2119. 102 3. Overview of Topology-Transparent Zone (TTZ) 104 A Topology-Transparent Zone (TTZ) is identified by an Identifier (ID) 105 called TTZ ID, and it includes a group of routers and a number of 106 links connecting the routers. A TTZ is in an IGP area. 108 In addition to having the functions of an IGP area, an IGP TTZ makes 109 some improvements on an IGP area, which include: 111 o An IGP TTZ is virtualized as the TTZ edge routers connected. 113 o An IGP TTZ receives the link state information about the topology 114 outside of the TTZ, stores the information in the TTZ and floods 115 the information through the TTZ to the routers outside of the TTZ. 117 The figure below shows an area containing a TTZ: TTZ 600. 119 TTZ 600 120 \ 121 \ ^~^~^~^~^~^~^~^~^~^~^~^~ 122 ( ) 123 ===[R15]========(==[R61]------------[R63]==)======[R29]=== 124 || ( | \ / | ) || 125 || ( | \ / | ) || 126 || ( | \ / | ) || 127 || ( | ___\ / | ) || 128 || ( | / [R71] | ) || 129 || ( | [R73] / \ | ) || 130 || ( | / \ | ) || 131 || ( | / \ | ) || 132 || ( | / \ | ) || 133 ===[R17]========(==[R65]------------[R67]==)======[R31]=== 134 \\ (// \\) // 135 || //v~v~v~v~v~v~v~v~v~v~v~\\ || 136 || // \\ || 137 || // \\ || 138 \\ // \\ // 139 ======[R23]==============================[R25]===== 140 // \\ 141 // \\ 143 Figure 1: An Example of TTZ 145 The area comprises routers R15, R17, R23, R25, R29 and R31. It also 146 contains TTZ 600, which comprises routers R61, R63, R65, R67, R71 and 147 R73, and the links connecting them. 149 There are two types of routers in a TTZ: TTZ internal routers and TTZ 150 edge routers. A TTZ internal router is a router inside the TTZ and 151 its adjacent routers are in the TTZ. A TTZ edge router is a router 152 inside the TTZ and has at least one adjacent router that is outside 153 of the TTZ. 155 The TTZ in the figure above comprises four TTZ edge routers R61, R63, 156 R65 and R67. Each TTZ edge router is connected to at least one 157 router outside of the TTZ. For instance, router R61 is a TTZ edge 158 router since it is connected to router R15, which is outside of the 159 TTZ. 161 In addition, the TTZ comprises two TTZ internal routers R71 and R73. 162 A TTZ internal router is not connected to any router outside of the 163 TTZ. For instance, router R71 is a TTZ internal router since it is 164 not connected to any router outside of the TTZ. It is just connected 165 to routers R61, R63, R65, R67 and R73 in the TTZ. 167 A TTZ hides the information inside the TTZ from the outside. It does 168 not directly distribute any internal information about the TTZ to a 169 router outside of the TTZ. 171 For instance, the TTZ in the figure above does not send the 172 information about TTZ internal router R71 to any router outside of 173 the TTZ in the routing domain; it does not send the information about 174 the link between TTZ router R61 and R65 to any router outside of the 175 TTZ. 177 From a router outside of the TTZ, a TTZ is seen as a group of routers 178 fully connected. For instance, router R15 in the figure above, which 179 is outside of TTZ 600, sees TTZ 600 as a group of TTZ edge routers: 180 R61, R63, R65 and R67. These four TTZ edge routers are fully 181 connected. 183 The cost of the "link" from one edge router to another edge router is 184 the cost of the shortest path between these two routers. The 185 bandwidth of the "link" is the maximum bandwidth of a path between 186 the two routers. 188 In addition, a router outside of the TTZ sees TTZ edge routers having 189 normal connections to the routers outside of the TTZ. For example, 190 router R15 sees four TTZ edge routers R61, R63, R65 and R67, which 191 have the normal connections to R15, R29, R17 and R23, R25 and R31 192 respectively. 194 4. Set up TE LSPs crossing TTZs 196 On a source node, we can configure a TE LSP from the source to a 197 destination crossing TTZs in the same way as we configure it without 198 any TTZs. This is because the source node is not aware of any TTZs. 200 For example, on node R15 in Figure 1, to set up a TE LSP from R15 to 201 R31, we just configure the TE LSP by giving its source R15, its 202 destination R31, and some constraints such as bandwidth as needed. 204 On the source node, it computes the path to the destination based on 205 the configuration of the TE LSP. It just sees a full mess connection 206 of edge nodes for every TTZ. Thus the computation of the path is 207 done in the same way as it is done without any TTZ. After the path 208 is computed, the source node starts to signal the LSP automatically 209 along the path. 211 For example, on node R15 in Figure 1, it computes the path to the 212 destination R31. It sees the full mess connection of four TTZ edge 213 nodes R61, R63, R65 and R67 in its topology. It computes the path in 214 the same way as before and may get the path: R15 - R61 - R67 - R31. 215 And then it signals the TE LSP along this path. It sends a RSVP-TE 216 PATH message to R61. 218 When an edge node of a TTZ receives a PATH message, it checks if the 219 next hop in the ERO in the message is another edge node of the TTZ. 220 If so, it computes the path segment to the other edge node and 221 continues to signal the TE LSP along the path segment computed. 223 For instance, when R61, which is an edge node of a TTZ, receives the 224 PATH message, it computes the path segment to the other edge node R67 225 (Supposed that the path segment is: R61 - R71 - R67) and continues to 226 signal the TE LSP to R67 along the path segment computed. It sends a 227 PATH message to R71, which sends a PATH message to R67, which sends a 228 PATH message to R31. 230 TTZ 600 231 \ 232 \ ^~^~^~^~^~^~^~^~^~^~^~^~ 233 Source 51 ( ) 234 ===[R15]========(==[R61]------------[R63]==)======[R29]=== 235 || ( | \ / | ) || 236 || ( | \ / | ) || 237 || ( | \11 / | ) || 238 || ( | ___\ / | ) || 239 || ( | / [R71] | ) || 240 || ( | [R73] / \ | ) || 241 || ( | / \ | ) || 242 || ( | / \17 | ) || 243 || ( | / \ | ) 71 || 244 ===[R17]========(==[R65]------------[R67]==)======[R31]=== 245 \\ (// \\) //Destination 246 || //v~v~v~v~v~v~v~v~v~v~v~\\ || 247 || // \\ || 248 || // \\ || 249 \\ // \\ // 250 ======[R23]==============================[R25]===== 251 // \\ 252 // \\ 254 Figure 2: LSP from R15 to R31 256 When R31 receives the PATH message from R67, it allocates a label 257 (e.g., 71), reserves the bandwidth as needed, and sends a RESV 258 message with the label (71) to R67. It sets the forwarding entry for 259 the TE LSP using label 71 as inbound label. 261 When R67 receives the RESV message from R31, it allocates a label 262 (e.g., 17), and sends a RESV message with the label (17) to R71. It 263 also sets the cross connect for the TE LSP using labels 17 and 71 as 264 inbound label and outbound label respectively. 266 When R71 receives the RESV message with the label (17) from R67, it 267 allocates a label (e.g., 11), and sends a RESV message with the label 268 (11) to R61. It sets the cross connect for the TE LSP using labels 269 11 and 17 as inbound label and outbound label respectively. 271 When R61 receives the RESV message with the label (11) from R71, it 272 allocates a label (e.g., 51), and sends a RESV message with the label 273 (51) to R15. It sets the cross connect for the TE LSP using labels 274 51 and 11 as inbound label and outbound label respectively. 276 When R15 receives the RESV message with the label (51) from R61, it 277 sets the forwarding entry for the TE LSP using label 51 as outbound 278 label. At this point, the set up of TE LSP from R15 to R31 is done. 280 The source node (i.e., head-end LSR) sets the "label recording 281 requested" flag in the SESSION_ATTRIBUTE object for LSPs requesting 282 local protection. This will cause all LSRs to record their INBOUND 283 labels. 285 For a TE LSP crossing a TTZ, we may assume that it goes into the TTZ 286 through an in edge node of the TTZ and goes out of the TTZ from a out 287 edge node of the TTZ. 289 For example, the TE LSP crossing TTZ 600 in Figure 2 is from R15 to 290 R61 to R71 to R67 to R31. The LSP goes into TTZ 600 through the edge 291 node R61, which is the in edge node. The LSP goes out of TTZ 600 292 from the edge node R67, which is the out edge node. 294 On the in edge node of the TTZ for the TE LSP, it does not record all 295 the INBOUND labels inside the TTZ in the RESV message to be sent to 296 its previous hop node. It just records the INBOUND label of the out 297 edge node. 299 For example, R61 (the in edge node of TTZ 600 for the TE LSP in 300 Figure 2) just keeps the INBOUND label 17 of R67 (the out edge node). 301 It does not record any other INBOUND labels inside TTZ 600. It will 302 remove the INBOUND label 11 of the TTZ internal node R71. Thus the 303 RESV message sent by R61 to its previous hop node R15 records two 304 INBOUND labels 17 and 71, which are the INBOUND labels of R67 and R31 305 respectively. 307 On the out edge node of the TTZ for the TE LSP, it does not record 308 all the hops inside the TTZ in the PATH message to its next hop node. 310 It just records one hop from the in edge to the out edge. 312 5. Security Considerations 314 The mechanism described in this document does not raise any new 315 security issues for the RSVP-TE protocols. 317 6. IANA Considerations 319 There is not any requirement for IANA to assign a code point. 321 7. Normative References 323 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 324 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ 325 RFC2119, March 1997, 326 . 328 [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol 329 Label Switching Architecture", RFC 3031, DOI 10.17487/ 330 RFC3031, January 2001, 331 . 333 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 334 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 335 Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001, 336 . 338 [RFC4090] Pan, P., Ed., Swallow, G., Ed., and A. Atlas, Ed., "Fast 339 Reroute Extensions to RSVP-TE for LSP Tunnels", RFC 4090, 340 DOI 10.17487/RFC4090, May 2005, 341 . 343 [RFC5441] Vasseur, JP., Ed., Zhang, R., Bitar, N., and JL. Le Roux, 344 "A Backward-Recursive PCE-Based Computation (BRPC) 345 Procedure to Compute Shortest Constrained Inter-Domain 346 Traffic Engineering Label Switched Paths", RFC 5441, 347 DOI 10.17487/RFC5441, April 2009, 348 . 350 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 351 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 352 DOI 10.17487/RFC5440, March 2009, 353 . 355 Authors' Addresses 357 Huaimo Chen 358 Huawei Technologies 359 Boston, MA 360 USA 362 Email: huaimo.chen@huawei.com 364 Renwei Li 365 Huawei Technologies 366 2330 Central Expressway 367 Santa Clara, CA 368 USA 370 Email: renwei.li@huawei.com 372 Gregory Cauchie 373 FRANCE 375 Email: greg.cauchie@gmail.com 377 Alvaro Retana 378 Cisco Systems, Inc. 379 7025 Kit Creek Rd. 380 Raleigh, NC 27709 381 USA 383 Email: aretana@cisco.com 385 Ning So 386 Tata Communications 387 USA 389 Email: ningso01@gmail.com 390 Fengman Xu 391 Verizon 392 2400 N. Glenville Dr 393 Richardson, TX 75082 394 USA 396 Email: fengman.xu@verizon.com 398 Mehmet Toy 399 Verizon 400 USA 402 Email: mehmet.toy@verizon.com 404 Vic Liu 405 China Mobile 406 No.32 Xuanwumen West Street, Xicheng District 407 Beijing, 100053 408 China 410 Email: liu.cmri@gmail.com 412 Lei Liu 413 Fijitsu 414 USA 416 Email: liulei.kddi@gmail.com