idnits 2.17.1 draft-kondreddy-pce-frr-boundary-node-app-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 : ---------------------------------------------------------------------------- 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 (September 5, 2012) is 4249 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'R3' is mentioned on line 280, but not defined == Unused Reference: 'RFC2119' is defined on line 430, but no explicit reference was found in the text -- Obsolete informational reference (is this intentional?): RFC 5316 (Obsoleted by RFC 9346) Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 PCE Working Group V. Kondreddy 3 Internet-Draft D. Dhody 4 Intended status: Informational Huawei Technologies India Pvt 5 Expires: March 9, 2013 Ltd 6 September 5, 2012 8 Applicability of Path Computation Element (PCE) for Fast Reroute (FRR) 9 Boundary Node protection. 10 draft-kondreddy-pce-frr-boundary-node-app-01 12 Abstract 14 Path computation element (PCE) can be used to compute a label 15 switched path that spans across multiple domains. This document 16 explain the mechanism of Fast Re-Route (FRR) where a point of local 17 repair (PLR) needs to find the appropriate merge point (MP) to do 18 bypass path computation using PCE. 20 Status of This Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at http://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on March 9, 2013. 37 Copyright Notice 39 Copyright (c) 2012 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 56 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 3. Methods to find MP and calculate the optimal backup path . . . 5 58 3.1. Intra-domain node protection . . . . . . . . . . . . . . . 5 59 3.2. Boundary node protection . . . . . . . . . . . . . . . . . 6 60 3.2.1. Area Boundary Router (ABR) node protection . . . . . . 6 61 3.2.2. Autonomous System Border Router (ASBR) node 62 protection . . . . . . . . . . . . . . . . . . . . . . 7 63 3.2.3. Boundary node protection with Path-Key 64 Confidentiality . . . . . . . . . . . . . . . . . . . 8 65 3.2.3.1. Area Boundary Router (ABR) node protection . . . . 8 66 3.2.3.2. Autonomous System Border Router (ASBR) node 67 protection . . . . . . . . . . . . . . . . . . . . 9 68 4. Manageability Considerations . . . . . . . . . . . . . . . . . 9 69 4.1. Control of Function and Policy . . . . . . . . . . . . . . 9 70 4.2. Information and Data Models . . . . . . . . . . . . . . . 9 71 4.3. Liveness Detection and Monitoring . . . . . . . . . . . . 9 72 4.4. Verify Correct Operations . . . . . . . . . . . . . . . . 9 73 4.5. Requirements On Other Protocols . . . . . . . . . . . . . 9 74 4.6. Impact On Network Operations . . . . . . . . . . . . . . . 9 75 5. Security Considerations . . . . . . . . . . . . . . . . . . . 10 76 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 77 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10 78 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 79 8.1. Normative References . . . . . . . . . . . . . . . . . . . 10 80 8.2. Informative References . . . . . . . . . . . . . . . . . . 10 82 1. Introduction 84 The Path Computation Element (PCE) [RFC4655] can be used to perform 85 complex path computation in large single domain, multi-domain and 86 multi-layered networks. The PCE can also be used to compute a 87 variety of restoration and protection paths and services. 89 As stated in [RFC4090], there are two independent methods (one-to-one 90 backup and facility backup) of doing fast reroute (FRR). PCE can be 91 used to compute backup path for both the methods. Cooperating PCEs 92 may be used to compute inter-domain backup path. 94 In case of one to one backup method, the destination MUST be the 95 tail-end of the protected LSP. Whereas for facility backup, 96 destination MUST be the address of the merge point (MP) from the 97 corresponding point of local repair (PLR). The problem of finding 98 the MP using the interface addresses or node-ids present in Record 99 Route Object (RRO) of protected path can be easily solved in the case 100 of a single Interior Gateway Protocol (IGP) area because the PLR has 101 the complete Traffic Engineering Database (TED). Thus, the PLR can 102 unambiguously determine - 104 o The MP address regardless of RRO IPv4 or IPv6 sub-objects 105 (interface address or LSR ID). 107 o Is a backup tunnel intersecting a protected TE LSP on MP node 108 exists? This is the case where facility backup tunnel already 109 exist either due to another protected TE LSP or it is pre- 110 configured. 112 It is complex for a PLR to find the MP in case of boundary node 113 protection for computing a bypass path because the PLR doesn't have 114 the full TED visibility. When confidentiality (via path key) 115 [RFC5520] is enabled, finding MP is very complex. 117 This document describes the mechanism to find MP and to setup bypass 118 tunnel to protect a boundary node. 120 1.1. Requirements Language 122 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 123 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 124 document are to be interpreted as described in RFC2119. 126 2. Terminology 128 The following terminology is used in this document. 130 ABR: Area Border Router. Router used to connect two IGP areas 131 (Areas in OSPF or levels in IS-IS). 133 ASBR: Autonomous System Border Router. Router used to connect 134 together ASes of the same or different service providers via one 135 or more inter-AS links. 137 BN: Boundary Node (BN) a boundary node is either an ABR in the 138 context of inter-area Traffic Engineering or an ASBR in the 139 context of inter-AS Traffic Engineering. 141 CPS: Confidential Path Segment. A segment of a path that contains 142 nodes and links that the AS policy requires not to be disclosed 143 outside the AS. 145 CSPF: Constrained Shorted Path First Algorithm. 147 ERO: Explicit Route Object 149 FRR: Fast Re-Route 151 IGP: Interior Gateway Protocol. Either of the two routing 152 protocols, Open Shortest Path First (OSPF) or Intermediate System 153 to Intermediate System (IS-IS). 155 IS-IS: Intermediate System to Intermediate System. 157 LSP: Label Switched Path 159 LSR: Label Switching Router 161 MP: Merge Point. The LSR where one or more backup tunnels rejoin 162 the path of the protected LSP downstream of the potential failure. 164 OSPF: Open Shortest Path First. 166 PCC: Path Computation Client: any client application requesting a 167 path computation to be performed by a Path Computation Element. 169 PCE: Path Computation Element. An entity (component, application, 170 or network node) that is capable of computing a network path or 171 route based on a network graph and applying computational 172 constraints. 174 PKS: Path Key Subobject. A subobject of an Explicit Route Object or 175 Record Route Object that encodes a CPS so as to preserve 176 confidentiality. 178 PLR: Point of Local Repair. The head-end LSR of a backup tunnel or 179 a detour LSP. 181 RRO: Record Route Object 183 RSVP: Resource Reservation Protocol 185 TE: Traffic Engineering. 187 TED: Traffic Engineering Database. 189 3. Methods to find MP and calculate the optimal backup path 191 The Merge Point (MP) address is required at the PLR in order to 192 select a bypass tunnel intersecting a protected Traffic Engineering 193 Label Switched Path (TE LSP) on a downstream LSR. 195 Some implementations may choose to pre-configure a bypass tunnel on 196 PLR with destination address as MP. MP's Domain to be traversed by 197 bypass path can be administratively configured or learned via some 198 other means (ex Hierarchical PCE (HPCE) [PCE-HIERARCHY-FWK]). Path 199 Computation Client (PCC) on PLR can request its local PCE to compute 200 bypass path from PLR to MP, excluding links and node between PLR and 201 MP. At PLR once primary tunnel is up, a pre-configured bypass tunnel 202 is bound to the primary tunnel, note that multiple bypass tunnel can 203 also exist. 205 Most implementations may choose to create a bypass tunnel on PLR 206 after primary tunnel is signaled with Record Route Object (RRO) being 207 present in primary path's Resource Reservation Protocol (RSVP) Path 208 Reserve message. MP address has to be determined (described below) 209 to create a bypass tunnel. PCC on PLR can request its local PCE to 210 compute bypass path from PLR to MP, excluding links and node between 211 PLR and MP. 213 3.1. Intra-domain node protection 215 [R1]----[R2]----[R3]----[R4]---[R5] 216 \ / 217 [R6]--[R7]--[R8] 219 Protected LSP Path: [R1->R2->R3->R4->R5] 220 Bypass LSP Path: [R2->R6->R7->R8->R4] 222 Figure 1: Node Protection for R3 224 In Figure 1, R2 has to build a bypass tunnel that protects against 225 the failure of link [R2->R3] and node [R3]. R2 is PLR and R4 is MP 226 in this case. Since, both PLR and MP belong to the same area. The 227 problem of finding the MP using the interface addresses or node-ids 228 can be easily solved. Thus, the PLR can unambiguously find the MP 229 address regardless of RRO IPv4 or IPv6 sub-objects (interface address 230 or LSR ID) and also determine whether a backup tunnel intersecting a 231 protected TE LSP on a downstream node (MP) already exists. 233 TED on PLR will have the information of both R2 and R4, which can be 234 used to find MP's TE router IP address and compute optimal backup 235 path from R2 to R4, excluding link [R2->R3] and node [R3]. 237 Thus, RSVP-TE can signal bypass tunnel along the computed path. 239 3.2. Boundary node protection 241 3.2.1. Area Boundary Router (ABR) node protection 243 | 244 PCE-1 | PCE-2 245 | 246 IGP area 0 | IGP area 1 247 | 248 | 249 [R1]----[R2]----[R3]----[R4]---[R5] 250 \ | / 251 [R6]--[R7]--[R8] 252 | 253 | 254 | 256 Protected LSP Path: [R1->R2->R3->R4->R5] 257 Bypass LSP Path: [R2->R6->R7->R8->R4] 259 Figure 2: Node Protection for R3 (ABR) 261 In Figure 2, cooperating PCE(s) (PCE-1 and PCE-2) have computed the 262 primary LSP Path [R1->R2->R3->R4->R5] and provided to R1 (PCC). 264 R2 has to build a bypass tunnel that protects against the failure of 265 link [R2->R3] and node [R3]. R2 is PLR and R4 is MP. Both PLR and 266 MP are in different area. TED on PLR doesn't have the information of 267 R4. 269 The problem of finding the MP address in a network with inter-domain 270 TE LSP is solved by inserting a node-id sub-object [RFC4561] in the 271 RRO object carried in the RSVP Path Reserve message. PLR can find 272 out the MP from the RRO it has received in Path Reserve message from 273 its downstream LSR. 275 But the computation of optimal backup path from R2 to R4, excluding 276 link [R2->R3] and node [R3] is not possible with running of 277 Constrained Shortest Path First (CSPF) algorithm locally at R2. PCE 278 can be used to compute backup path in this case. R2 acting as PCC on 279 PLR can request PCE-1 to compute bypass path from PLR(R2) to MP(R4), 280 excluding link [R2->R3] and node [R3]. PCE MAY use inter-domain path 281 computation mechanism (like HPCE ([PCE-HIERARCHY-FWK]) etc) when the 282 domain information of MP is unknown at PLR. Further, RSVP-TE can 283 signal bypass tunnel along the computed path. 285 3.2.2. Autonomous System Border Router (ASBR) node protection 287 | | 288 PCE-1 | | PCE-2 289 | | 290 AS 100 | | AS 200 291 | | 292 | | 293 [R1]----[R2]-------[R3]---------[R4]---[R5] 294 |\ | / 295 | +-----[R6]--[R7]--[R8] 296 | | 297 | | 299 Protected LSP Path: [R1->R2->R3->R4->R5] 300 Bypass LSP Path: [R2->R6->R7->R8->R4] 302 Figure 3: Node Protection for R3 (ASBR) 304 In Figure 3, Links [R2->R3] and [R2->R6] are inter-AS links. IGP 305 extensions ([RFC5316] and [RFC5392]) describe the flooding of 306 inter-AS TE information for inter-AS path computation. Cooperating 307 PCE(s) (PCE-1 and PCE-2) have computed the primary LSP Path 308 [R1->R2->R3->R4->R5] and provided to R1 (PCC). 310 R2 is PLR and R4 is MP. Both PLR and MP are in different AS. TED on 311 PLR doesn't have the information of R4. 313 The address of MP can be found using node-id sub-object [RFC4561] in 314 the RRO object carried in the RSVP Path Reserve message. And 315 Cooperating PCEs could be used to compute the inter-AS bypass path. 316 Thus ASBR boundary node protection is similar to ABR protection. 318 3.2.3. Boundary node protection with Path-Key Confidentiality 320 [RFC5520] defines a mechanism to hide the contents of a segment of a 321 path, called the Confidential Path Segment (CPS). The CPS may be 322 replaced by a path-key that can be conveyed in the PCE Communication 323 Protocol (PCEP) and signaled within in a Resource Reservation 324 Protocol TE (RSVP-TE) explicit route object. 326 [RFC5553] states that, when the signaling message crosses a domain 327 boundary, the path segment that needs to be hidden (that is, a CPS) 328 MAY be replaced in the RRO with a PKS. Note that RRO in Path Reserve 329 message carries the same PKS as originally signaled in the ERO of the 330 Path message. 332 3.2.3.1. Area Boundary Router (ABR) node protection 334 | 335 PCE-1 | PCE-2 336 | 337 IGP area 0 | IGP area 1 338 | 339 | 340 [R1]----[R2]----[R3]----[R4]---[R5]---[R9] 341 \ | / 342 [R6]--[R7]--[R8] 343 | 344 | 345 | 347 Figure 4: Node Protection for R3 (ABR) and Path-Key 349 In Figure 4, when path-key is enabled, cooperating PCE(s) (PCE-1 and 350 PCE-2) have computed the primary LSP Path [R1->R2->R3->PKS->R9] and 351 provided to R1 (PCC). 353 When the ABR node (R3) replaces the CPS with PKS (as originally 354 signaled) during the Path Reserve message handling, it MAY also add 355 the immediate downstream node-id (R4) (so that the PLR (R2) can 356 identify the MP (R4)). Further the PLR (R2) SHOULD remove the MP 357 node-id (R4) before sending the path reserve message upstream to head 358 end router. 360 Once MP is identified, the backup path computation using PCE is as 361 described earlier. (Section 3.2.1) 363 3.2.3.2. Autonomous System Border Router (ASBR) node protection 365 | | 366 PCE-1 | | PCE-2 367 | | 368 AS 100 | | AS 200 369 | | 370 | | 371 [R1]----[R2]-------[R3]---------[R4]---[R5] 372 |\ | / 373 | +-----[R6]--[R7]--[R8] 374 | | 375 | | 377 Figure 5: Node Protection for R3 (ASBR) 379 The address of MP can be found using the same mechanism as explained 380 above. Thus ASBR boundary node protection is similar to ABR 381 protection. 383 4. Manageability Considerations 385 4.1. Control of Function and Policy 387 TBD 389 4.2. Information and Data Models 391 TBD 393 4.3. Liveness Detection and Monitoring 395 TBD 397 4.4. Verify Correct Operations 399 TBD 401 4.5. Requirements On Other Protocols 403 TBD 405 4.6. Impact On Network Operations 407 TBD 409 5. Security Considerations 411 This document does not introduce new security issues. However, MP's 412 node-id is carried as subobject in RRO across domain. This 413 relaxation is required to find MP in case of BN protection. The 414 security considerations pertaining to the [RFC3209], [RFC4090] and 415 [RFC5440] protocols remain relevant. 417 6. IANA Considerations 419 TBD 421 7. Acknowledgments 423 We would like to thank Sandeep Boina & Reeja Paul for their useful 424 comments and suggestions. 426 8. References 428 8.1. Normative References 430 [RFC2119] Bradner, S., "Key words for use in RFCs to 431 Indicate Requirement Levels", BCP 14, RFC 2119, 432 March 1997. 434 [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path 435 Computation Element (PCE)-Based Architecture", 436 RFC 4655, August 2006. 438 8.2. Informative References 440 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., 441 Srinivasan, V., and G. Swallow, "RSVP-TE: 442 Extensions to RSVP for LSP Tunnels", RFC 3209, 443 December 2001. 445 [RFC4090] Pan, P., Swallow, G., and A. Atlas, "Fast 446 Reroute Extensions to RSVP-TE for LSP Tunnels", 447 RFC 4090, May 2005. 449 [RFC4561] Vasseur, J., Ali, Z., and S. Sivabalan, 450 "Definition of a Record Route Object (RRO) 451 Node-Id Sub-Object", RFC 4561, June 2006. 453 [RFC5316] Chen, M., Zhang, R., and X. Duan, "ISIS 454 Extensions in Support of Inter-Autonomous System 455 (AS) MPLS and GMPLS Traffic Engineering", 456 RFC 5316, December 2008. 458 [RFC5392] Chen, M., Zhang, R., and X. Duan, "OSPF 459 Extensions in Support of Inter-Autonomous System 460 (AS) MPLS and GMPLS Traffic Engineering", 461 RFC 5392, January 2009. 463 [RFC5440] Vasseur, JP. and JL. Le Roux, "Path Computation 464 Element (PCE) Communication Protocol (PCEP)", 465 RFC 5440, March 2009. 467 [RFC5520] Bradford, R., Vasseur, JP., and A. Farrel, 468 "Preserving Topology Confidentiality in Inter- 469 Domain Path Computation Using a Path-Key-Based 470 Mechanism", RFC 5520, April 2009. 472 [RFC5553] Farrel, A., Bradford, R., and JP. Vasseur, 473 "Resource Reservation Protocol (RSVP) Extensions 474 for Path Key Support", RFC 5553, May 2009. 476 [PCE-HIERARCHY-FWK] King, D. and A. Farrel, "The Application of the 477 Path Computation Element Architecture to the 478 Determination of a Sequence of Domains in MPLS 479 and GMPLS. (draft-ietf-pce-hierarchy-fwk-05)", 480 August 2012. 482 Authors' Addresses 484 Venugopal Reddy Kondreddy 485 Huawei Technologies India Pvt Ltd 486 Leela Palace 487 Bangalore, Karnataka 560008 488 INDIA 490 EMail: venugopalreddyk@huawei.com 492 Dhruv Dhody 493 Huawei Technologies India Pvt Ltd 494 Leela Palace 495 Bangalore, Karnataka 560008 496 INDIA 498 EMail: dhruv.dhody@huawei.com