idnits 2.17.00 (12 Aug 2021) /tmp/idnits11070/draft-chen-pce-compute-backup-ingress-19.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 document date (10 January 2022) is 124 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: 'TBD' is mentioned on line 352, but not defined == Missing Reference: 'RFC5511' is mentioned on line 399, but not defined == Unused Reference: 'RFC2119' is defined on line 484, but no explicit reference was found in the text == Unused Reference: 'RFC3209' is defined on line 489, but no explicit reference was found in the text == Unused Reference: 'RFC4090' is defined on line 499, but no explicit reference was found in the text == Unused Reference: 'RFC4875' is defined on line 504, but no explicit reference was found in the text == Unused Reference: 'RFC6006' is defined on line 511, but no explicit reference was found in the text == Unused Reference: 'RFC4655' is defined on line 520, but no explicit reference was found in the text == Unused Reference: 'RFC5862' is defined on line 525, but no explicit reference was found in the text ** Obsolete normative reference: RFC 6006 (Obsoleted by RFC 8306) Summary: 1 error (**), 0 flaws (~~), 9 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 Futurewei 4 Intended status: Standards Track 10 January 2022 5 Expires: 14 July 2022 7 Extensions to Path Computation Element Communication Protocol (PCEP) for 8 Backup Ingress of a Traffic Engineering Label Switched Path 9 draft-chen-pce-compute-backup-ingress-19 11 Abstract 13 This document presents extensions to the Path Computation Element 14 Communication Protocol (PCEP) for a PCC to send a request for 15 computing a backup ingress for an MPLS TE P2MP LSP or an MPLS TE P2P 16 LSP to a PCE and for a PCE to compute the backup ingress and reply to 17 the PCC with a computation result for the backup ingress. 19 Status of This Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at https://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on 14 July 2022. 36 Copyright Notice 38 Copyright (c) 2022 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 43 license-info) in effect on the date of publication of this document. 44 Please review these documents carefully, as they describe your rights 45 and restrictions with respect to this document. Code Components 46 extracted from this document must include Revised BSD License text as 47 described in Section 4.e of the Trust Legal Provisions and are 48 provided without warranty as described in the Revised BSD License. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 53 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 3. Conventions Used in This Document . . . . . . . . . . . . . . 3 55 4. Extensions to PCEP . . . . . . . . . . . . . . . . . . . . . 3 56 4.1. Backup Ingress Capability Advertisement . . . . . . . . . 4 57 4.1.1. Capability TLV in Existing PCE Discovery Protocol . . 4 58 4.1.2. Open Message Extension . . . . . . . . . . . . . . . 6 59 4.2. Request and Reply Message Extension . . . . . . . . . . . 6 60 4.2.1. RP Object Extension . . . . . . . . . . . . . . . . . 6 61 4.2.2. External Source Node . . . . . . . . . . . . . . . . 7 62 4.2.3. Constraints between Ingress and Backup Ingress . . . 8 63 4.2.4. Constraints for Backup Path . . . . . . . . . . . . . 8 64 4.2.5. Backup Ingress Node . . . . . . . . . . . . . . . . . 9 65 4.2.6. Backup Ingress PCEP Error Objects and Types . . . . . 9 66 4.2.7. Request Message Format . . . . . . . . . . . . . . . 9 67 4.2.8. Reply Message Format . . . . . . . . . . . . . . . . 10 68 5. Security Considerations . . . . . . . . . . . . . . . . . . . 10 69 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 70 6.1. Backup Ingress Capability Flag . . . . . . . . . . . . . 10 71 6.2. Backup Ingress Capability TLV . . . . . . . . . . . . . . 11 72 6.3. Request Parameter Bit Flags . . . . . . . . . . . . . . . 11 73 6.4. PCEP Objects . . . . . . . . . . . . . . . . . . . . . . 11 74 7. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 12 75 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 76 8.1. Normative References . . . . . . . . . . . . . . . . . . 12 77 8.2. Informative References . . . . . . . . . . . . . . . . . 12 78 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 13 80 1. Introduction 82 RFC4090 "Fast Reroute Extensions to RSVP-TE for LSP Tunnels" 83 describes two methods to protect P2P LSP tunnels or paths at local 84 repair points. The local repair points may comprise a number of 85 intermediate nodes between an ingress node and an egress node along 86 the path. The first method is a one-to-one backup method, where a 87 detour backup P2P LSP for each protected P2P LSP is created at each 88 potential point of local repair. The second method is a facility 89 bypass backup protection method, where a bypass backup P2P LSP tunnel 90 is created using MPLS label stacking to protect a potential failure 91 point for a set of P2P LSP tunnels. The bypass backup tunnel can 92 protect a set of P2P LSPs that have similar backup constraints. 94 RFC4875 "Extensions to RSVP-TE for P2MP TE LSPs" describes how to use 95 the one-to-one backup method and facility bypass backup method to 96 protect a link or intermediate node failure on the path of a P2MP 97 LSP. 99 However, there is no mention of locally protecting an ingress node 100 failure in a protected P2MP LSP or P2P LSP. 102 The methods for protecting an ingress node of a P2MP LSP or P2P LSP 103 may be classified into two categories. 105 A first category uses a backup P2MP LSP that is from a backup ingress 106 node to the number of destination nodes for the P2MP LSP, and a 107 backup P2P LSP that is from a backup ingress node to the destination 108 node for the P2P LSP. The disadvantages of this class of methods 109 include more network resource such as computer power and link 110 bandwidth consumption since the backup P2MP LSP or P2P LSP is from 111 the backup ingress node to the number of destination nodes or the 112 destination respectively. 114 A second category uses a local P2MP LSP or P2P LSP for protecting the 115 ingress of a P2MP LSP or P2P LSP locally. The local P2MP LSP is from 116 a backup ingress node to the next hop nodes of the ingress of the 117 P2MP LSP. The local P2P LSP is from a backup ingress node to the 118 next hop node of the ingress of the P2P LSP. It is desirable to let 119 PCE compute these backup ingress nodes. 121 This document defines extensions to the Path Computation Element 122 Communication Protocol (PCEP) for a PCC to send a request for 123 computing a backup ingress node for an MPLS TE P2MP LSP or an MPLS TE 124 P2P LSP to a PCE and for a PCE to compute the backup ingress node and 125 reply to the PCC with a computation result for the backup ingress 126 node. 128 2. Terminology 130 This document uses terminologies defined in RFC5440, RFC4090, and 131 RFC4875. 133 3. Conventions Used in This Document 135 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 136 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 137 document are to be interpreted as described in RFC2119. 139 4. Extensions to PCEP 141 This section describes the extensions to PCEP for computing a backup 142 ingress of an MPLS TE P2MP LSP and an MPLS TE P2P LSP. 144 4.1. Backup Ingress Capability Advertisement 146 4.1.1. Capability TLV in Existing PCE Discovery Protocol 148 There are a couple of options for advertising a PCE capability for 149 computing a backup ingress for an MPLS TE P2MP LSP or an MPLS TE P2P 150 LSP. 152 The first option is to define a new flag in the OSPF and ISIS PCE 153 Capability Flags to indicate the capability that a PCE is capable to 154 compute both a backup ingress for an MPLS TE P2MP LSP and a backup 155 ingress for an MPLS TE P2P LSP. 157 The second option is to define two new flags. One new flag in the 158 OSPF and ISIS PCE Capability Flags indicates the capability that a 159 PCE is capable to compute a backup ingress for an MPLS TE P2MP LSP; 160 and another new flag in the OSPF and ISIS PCE Capability Flags 161 indicates the capability that a PCE is capable to compute a backup 162 ingress for an MPLS TE P2P LSP. 164 This second option is preferred now. 166 The format of the PCE-CAP-FLAGS sub-TLV is as follows: 168 0 1 2 3 169 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 170 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 171 | Type = 5 | Length | 172 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 173 | | 174 ~ PCE Capability Flags ~ 175 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 177 Type: 5 178 Length: Multiple of 4 octets 179 Value: This contains an array of units of 32-bit flags 180 numbered from the most significant as bit zero, where 181 each bit represents one PCE capability. 183 The following capability bits have been assigned by IANA: 185 Bit Capabilities 186 0 Path computation with GMPLS link constraints 187 1 Bidirectional path computation 188 2 Diverse path computation 189 3 Load-balanced path computation 190 4 Synchronized path computation 191 5 Support for multiple objective functions 192 6 Support for additive path constraints 193 (max hop count, etc.) 194 7 Support for request prioritization 195 8 Support for multiple requests per message 196 9 Global Concurrent Optimization (GCO) 197 10 P2MP path computation 198 11-31 Reserved for future assignments by IANA. 200 Reserved bits SHOULD be set to zero on transmission and MUST be 201 ignored on receipt. 203 For the second option, one bit such as bit 11 may be assigned to 204 indicate that a PCE is capable to compute a backup ingress for an 205 MPLS TE P2MP LSP and another bit such as bit 12 may be assigned to 206 indicate that a PCE is capable to compute a backup ingress for an 207 MPLS TE P2P LSP. 209 Bit Capabilities 210 11 Backup ingress computation for P2MP LSP 211 12 Backup ingress computation for P2P LSP 212 13-31 Reserved for future assignments by IANA. 214 4.1.2. Open Message Extension 216 If a PCE does not advertise its backup ingress compution capability 217 during discovery, PCEP should be used to allow a PCC to discover, 218 during the Open Message Exchange, which PCEs are capable of 219 supporting backup ingress computation. 221 To achieve this, we extend the PCEP OPEN object by defining a new 222 optional TLV to indicate the PCE's capability to perform backup 223 ingress compution for an MPLS TE P2MP LSP and an MPLS TE P2P LSP. 225 We request IANA to allocate a value such as 8 from the "PCEP TLV Type 226 Indicators" subregistry, as documented in Section below ("Backup 227 Ingress Capability TLV"). The description is "backup ingress 228 capable", and the length value is 2 bytes. The value field is set to 229 indicate the capability of a PCE for backup ingress compution for an 230 MPLS TE LSP in details. 232 We can use flag bits in the value field in the same way as the PCE 233 Capability Flags described in the previous section. 235 The inclusion of this TLV in an OPEN object indicates that the sender 236 can perform backup ingress compution for an MPLS TE P2MP LSP or an 237 MPLS TE P2P LSP. 239 The capability TLV is meaningful only for a PCE, so it will typically 240 appear only in one of the two Open messages during PCE session 241 establishment. However, in case of PCE cooperation (e.g., inter- 242 domain), when a PCE behaving as a PCC initiates a PCE session it 243 SHOULD also indicate its path computation capabilities. 245 4.2. Request and Reply Message Extension 247 This section describes extensions to the existing RP (Request 248 Parameters) object to allow a PCC to request a PCE for computing a 249 backup ingress of an MPLS TE P2MP LSP or an MPLS TE P2P LSP when the 250 PCE receives the PCEP request. 252 4.2.1. RP Object Extension 254 The following flags are added into the RP Object: 256 The I bit is added in the flag bits field of the RP object to tell 257 the receiver of the message that the request/reply is for computing a 258 bcakup ingress of an MPLS TE P2MP LSP and an MPLS TE P2P LSP. 260 o I ( Backup Ingress bit - 1 bit): 261 0: This indicates that this is not PCReq/PCRep 262 for backup ingress. 263 1: This indicates that this is PCReq or PCRep message 264 for backup ingress. 266 The IANA request is referenced in Section below (Request Parameter 267 Bit Flags) of this document. 269 This I bit with the N bit defined in RFC6006 can indicate whether the 270 request/reply is for a bcakup ingress of an MPLS TE P2MP LSP or an 271 MPLS TE P2P LSP. 273 o I = 1 and N = 1: This indicates that this is a PCReq/PCRep 274 message for backup ingress of an MPLS TE 275 P2MP LSP. 276 o I = 1 and N = 0: This indicates that this is a PCReq/PCRep 277 message for backup ingress of an MPLS TE 278 P2P LSP. 280 4.2.2. External Source Node 282 In addition to the information about the path that an MPLS TE P2MP 283 LSP or an MPLS TE P2P LSP traverses, a request message may comprise 284 other information that may be used for computing the backup ingress 285 for the P2MP LSP or P2P LSP. For example, the information about an 286 external source node, from which data traffic is delivered to the 287 ingress node of the P2MP LSP or P2P LSP and transported to the egress 288 node(s) via the P2MP LSP or P2P LSP, is useful for computing a backup 289 ingress node. 291 The PCC can specify an external source node (ESN) Object. The ESN 292 Object has the same format as the IRO object defined in [RFC5440] 293 except that it only supports IPv4 and IPv6 prefix sub-objects. 295 The object can only be carried in a PCReq message. A Path Request 296 may carry at most one external source node Object. 298 The Object-Class and Object-types will need to be allocated by IANA. 299 The IANA request is documented in Section below. (PCEP Objects). 301 Alternatively, we may use END-POINTS to represent an external source 302 node in a request message for computing a backup ingress node of MPLS 303 LSP. 305 To represent an external source node efficiently, we define a new 306 type of END-POINTS objects for computing a backup ingress node of 307 MPLS LSP. The format of the new END-POINTS object body for IPv4 308 (Object-Type 3) is as follows: 310 0 1 2 3 311 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 312 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 313 | External Source Type (11) | 314 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 315 | External Source IPv4 address | 316 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 318 The new type of END-POINTS is External Source Node Type (11). The 319 final value for the type will be assigned by IANA. This new type of 320 END-POINTS object contains an external source node IPv4 address. 322 4.2.3. Constraints between Ingress and Backup Ingress 324 A request message sent to a PCE from a PCC for computing a backup 325 ingress of an MPLS TE P2MP LSP or an MPLS TE P2P LSP may comprise a 326 constraint indicating that there must be a path from the backup 327 ingress node to be computed to the ingress node of the P2MP LSP or 328 P2P LSP and that the length of the path is within a given hop limit 329 such as one hop. 331 This constraint can be considered as default by a PCE or explicitly 332 sent to the PCE by a PCC [TBD]. 334 4.2.4. Constraints for Backup Path 336 A request message sent to a PCE from a PCC for computing a backup 337 ingress of a P2MP LSP or P2P LSP may comprise a constraint indicating 338 that the backup ingress node to be computed may not be a node on the 339 P2MP LSP or P2P LSP. In addition, the request message may comprise a 340 list of nodes, each of which is a candidate for the backup ingress 341 node. 343 A request message sent to a PCE from a PCC for computing a backup 344 ingress of a P2MP LSP or P2P LSP may comprise a constraint indicating 345 that there must be a path from the backup ingress node to be computed 346 to the next-hop nodes of the ingress node of the P2MP LSP or P2P LSP 347 and that there is not an internal node of the path from the backup 348 ingress to the next-hop nodes on the P2MP LSP or P2P LSP . 350 Most of these constraints for the backup path can be considered as 351 default by a PCE. The constraints for the backup path may be 352 explicitly sent to the PCE by a PCC [TBD]. 354 4.2.5. Backup Ingress Node 356 The PCE may send a reply message to the PCC in return to the request 357 message for computing a new backup ingress node. The reply message 358 may comprise information about the computed backup ingress node, 359 which is contained in the path from the backup ingress computed to 360 the next-hop node(s) of the ingress node of the P2MP LSP or P2P LSP. 362 The backup ingress node is the root or head node of the backup path 363 computed. 365 4.2.6. Backup Ingress PCEP Error Objects and Types 367 In some cases, the PCE may not complete the backup ingress 368 computation as requested, for example based on a set of constraints. 369 As such, the PCE may send a reply message to the PCC that indicates 370 an unsuccessful backup ingress computation attempt. The reply 371 message may comprise a PCEP-error object, which may comprise an 372 error-value, error-type and some detail information. 374 4.2.7. Request Message Format 376 The PCReq message is encoded as follows using RBNF as defined in 377 [RFC5511]. 379 Below is the message format for a request message: 381 ::= 382 [] 383 384 ::= [] 385 [] [] [] 386 [] 387 [] 388 [] 389 where: 390 is an external source node object. 392 The definitions for svec-list, RP, end-point-rro-pair-list, OF, LSPA, 393 BANDWIDTH, metric-list, IRO, and LOAD-BALANCING are described in 394 RFC5440 and RFC6006. 396 4.2.8. Reply Message Format 398 The PCRep message is encoded as follows using RBNF as defined in 399 [RFC5511]. 401 Below is the message format for a reply message: 403 ::= 404 405 ::= 406 [] 407 [] 408 where: 409 ::= 410 [][] 412 ::= (|) [] 414 ::= [] [] [] 415 [] [] 417 The definitions for RP, NO-PATH, END-POINTS, OF, LSPA, BANDWIDTH, 418 metric-list, IRO, and SERO are described in RFC5440, RFC6006 and 419 RFC4875. 421 5. Security Considerations 423 The mechanism described in this document does not raise any new 424 security issues for the PCEP, OSPF and IS-IS protocols. 426 6. IANA Considerations 428 This section specifies requests for IANA allocation. 430 6.1. Backup Ingress Capability Flag 432 Two new OSPF Capability Flags are defined in this document to 433 indicate the capabilities for computing a backup ingress for an MPLS 434 TE P2MP LSP and an MPLS TE P2P LSP. IANA is requested to make the 435 assignment from the "OSPF Parameters Path Computation Element (PCE) 436 Capability Flags" registry: 438 Bit Description Reference 439 11 Backup ingress for P2MP LSP This I-D 440 12 Backup ingress for P2P LSP This I-D 442 6.2. Backup Ingress Capability TLV 444 A new backup ingress capability TLV is defined in this document to 445 allow a PCE to advertize its backup ingress computation capability. 446 IANA is requested to make the following allocation from the "PCEP TLV 447 Type Indicators" sub-registry. 449 Value Description Reference 450 8 Backup ingress capable This I-D 452 6.3. Request Parameter Bit Flags 454 A new RP Object Flag has been defined in this document. IANA is 455 requested to make the following allocation from the "PCEP RP Object 456 Flag Field" Sub-Registry: 458 Bit Description Reference 459 16 Backup ingress (I-bit) This I-D 461 6.4. PCEP Objects 463 An External Source Node Object-Type is defined in this document. 464 IANA is requested to make the following Object-Type allocation from 465 the "PCEP Objects" sub-registry: 467 Object-Class Value 33 468 Name External Source Node 469 Object-Type 1: IPv4 470 2: IPv6 471 3-15: Unassigned 472 Reference This I-D 474 7. Acknowledgement 476 The author would like to thank Cyril Margaria, Ramon Casellas, Dhruv 477 Dhody and Quintin Zhao for their valuable comments and suggestions on 478 this draft. 480 8. References 482 8.1. Normative References 484 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 485 Requirement Levels", BCP 14, RFC 2119, 486 DOI 10.17487/RFC2119, March 1997, 487 . 489 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 490 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 491 Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001, 492 . 494 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 495 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 496 DOI 10.17487/RFC5440, March 2009, 497 . 499 [RFC4090] Pan, P., Ed., Swallow, G., Ed., and A. Atlas, Ed., "Fast 500 Reroute Extensions to RSVP-TE for LSP Tunnels", RFC 4090, 501 DOI 10.17487/RFC4090, May 2005, 502 . 504 [RFC4875] Aggarwal, R., Ed., Papadimitriou, D., Ed., and S. 505 Yasukawa, Ed., "Extensions to Resource Reservation 506 Protocol - Traffic Engineering (RSVP-TE) for Point-to- 507 Multipoint TE Label Switched Paths (LSPs)", RFC 4875, 508 DOI 10.17487/RFC4875, May 2007, 509 . 511 [RFC6006] Zhao, Q., Ed., King, D., Ed., Verhaeghe, F., Takeda, T., 512 Ali, Z., and J. Meuric, "Extensions to the Path 513 Computation Element Communication Protocol (PCEP) for 514 Point-to-Multipoint Traffic Engineering Label Switched 515 Paths", RFC 6006, DOI 10.17487/RFC6006, September 2010, 516 . 518 8.2. Informative References 520 [RFC4655] Farrel, A., Vasseur, J.-P., and J. Ash, "A Path 521 Computation Element (PCE)-Based Architecture", RFC 4655, 522 DOI 10.17487/RFC4655, August 2006, 523 . 525 [RFC5862] Yasukawa, S. and A. Farrel, "Path Computation Clients 526 (PCC) - Path Computation Element (PCE) Requirements for 527 Point-to-Multipoint MPLS-TE", RFC 5862, 528 DOI 10.17487/RFC5862, June 2010, 529 . 531 Author's Address 533 Huaimo Chen 534 Futurewei 535 Boston, MA, 536 United States of America 538 Email: Huaimo.chen@futurewei.com