idnits 2.17.00 (12 Aug 2021) /tmp/idnits30833/draft-alvarez-pce-path-profiles-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 4, 2014) is 3000 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: 'TBA' is mentioned on line 321, but not defined == Unused Reference: 'I-D.ali-pce-remote-initiated-gmpls-lsp' is defined on line 401, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-pce-gmpls-pcep-extensions' is defined on line 408, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-pce-stateful-pce' is defined on line 419, but no explicit reference was found in the text == Unused Reference: 'I-D.sivabalan-pce-segment-routing' is defined on line 424, but no explicit reference was found in the text == Unused Reference: 'RFC4655' is defined on line 445, but no explicit reference was found in the text == Outdated reference: draft-ietf-pce-gmpls-pcep-extensions has been published as RFC 8779 == Outdated reference: draft-ietf-pce-pce-initiated-lsp has been published as RFC 8281 == Outdated reference: draft-ietf-pce-stateful-pce has been published as RFC 8231 == Outdated reference: A later version (-03) exists of draft-sivabalan-pce-segment-routing-02 ** Obsolete normative reference: RFC 6006 (Obsoleted by RFC 8306) Summary: 1 error (**), 0 flaws (~~), 11 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force S. Alvarez 3 Internet-Draft S. Sivabalan 4 Intended status: Standards Track Z. Ali 5 Expires: September 5, 2014 Cisco Systems, Inc. 6 L. Tomotaki 7 Verizon 8 V. Lopez 9 Telefonica I+D 10 March 4, 2014 12 PCE Path Profiles 13 draft-alvarez-pce-path-profiles-02 15 Abstract 17 This document describes extensions to the Path Computation Element 18 (PCE) Communication Protocol (PCEP) to signal path profile 19 identifiers. A profile represents a list of path parameters or 20 policies that a PCEP peer may invoke on a remote peer using an opaque 21 identifier. When a path computation client (PCC) initiates a path 22 computation request, the PCC can signal profile identifiers to invoke 23 path parameters or policies defined on the PCE which would influence 24 the path computation. Similarly, when a PCE initiates or updates a 25 path, the PCE can signal profile identifiers to invoke path 26 parameters or policies defined on the PCC which would influence the 27 path setup. 29 Status of This Memo 31 This Internet-Draft is submitted in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF). Note that other groups may also distribute 36 working documents as Internet-Drafts. The list of current Internet- 37 Drafts is at http://datatracker.ietf.org/drafts/current/. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 This Internet-Draft will expire on September 5, 2014. 46 Copyright Notice 48 Copyright (c) 2014 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 . . . . . . . . . . . . . . . . . . . . . . . . 2 64 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 2 65 2. Path Profiles . . . . . . . . . . . . . . . . . . . . . . . . 3 66 3. Procedures . . . . . . . . . . . . . . . . . . . . . . . . . 3 67 3.1. Capability Advertisement . . . . . . . . . . . . . . . . 3 68 3.2. PCC-Initiated Paths . . . . . . . . . . . . . . . . . . . 3 69 3.2.1. Point-to-Point Paths . . . . . . . . . . . . . . . . 4 70 3.2.2. Point-to-Multipoint Paths . . . . . . . . . . . . . . 5 71 3.3. PCE-Initiated Paths . . . . . . . . . . . . . . . . . . . 6 72 4. Object Extensions . . . . . . . . . . . . . . . . . . . . . . 7 73 4.1. OPEN Object . . . . . . . . . . . . . . . . . . . . . . . 7 74 4.2. PATH-PROFILE Object . . . . . . . . . . . . . . . . . . . 8 75 5. Error Codes for PATH-PROFILE Object . . . . . . . . . . . . . 9 76 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 77 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 78 8. Security Considerations . . . . . . . . . . . . . . . . . . . 9 79 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 80 9.1. Normative References . . . . . . . . . . . . . . . . . . 10 81 9.2. Informative References . . . . . . . . . . . . . . . . . 11 82 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 84 1. Introduction 86 1.1. Requirements Language 88 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 89 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 90 document are to be interpreted as described in RFC 2119 [RFC2119]. 92 2. Path Profiles 94 A path profile represents a list of path parameters or policies that 95 a PCEP peer may invoke on a remote peer using a profile identifier. 96 The receiving peer interprets the identifier according to a local 97 path profile definition. The PATH-PROFILE object defined in 98 Section 4.2 can signal one or more profile identifiers. PCEP carries 99 profile identifiers as opaque values. PCEP peers do not exchange the 100 details of a path profile. The PCE may be stateful or stateless. 102 3. Procedures 104 3.1. Capability Advertisement 106 PCEP peers advertise their capability to support path profile 107 identifiers during the session initialization phase. They include 108 the PATH-PROFILE-CAPABILITY TLV defined in Section 4.1 as part of the 109 OPEN object. A PCEP peer can only signal path profile identifiers if 110 both peers advertised this capability. A peer MUST send a PCErr 111 message with Error-Type=4 (Not supported object), Error-value=1 (Not 112 supported object class) and close the session if it receives a 113 message with a path profile identifier, it supports the extensions in 114 this document and both peers did not advertise this capability. 116 3.2. PCC-Initiated Paths 118 A PCC MAY include a PATH-PROFILE object when sending a PCReq message. 119 The PCE uses the path profile identifiers to select path parameters 120 or path policies to fulfill the request. The PCE MUST process the 121 identifiers in the PATH-PROFILE object in the order received. The 122 means by which the PCC learns about a particular path profile 123 identifier and decides to include it in a PCReq message are outside 124 the scope of this document. Similarly, the means by which the PCE 125 selects a set of parameters or policies based on the profile 126 identifier for a specific request are outside the scope of this 127 document. The P flag of the PATH-PROFILE object MUST be set. 129 A PCE may receive a path computation request with one or more 130 unexpected path profile identifiers. The PCE sends a PCErr message 131 with Error-Type=[TBA] (PATH-PROFILE Error), Error-value=1 (Unknown 132 path profile) if the path profile identifier is not known to the PCE. 133 The PCE sends a PCErr message with Error-Type=[TBA] (PATH-PROFILE 134 Error), Error-value=2 (Invalid path profile) if the PCE knows about 135 the path profile identifier, but considers the request invalid. As 136 an example, the profile may be invalid because of the path type, the 137 PCEP session type or the originating PCC. The PCE sends a PCErr 138 message with Error-Type=[TBA] (PATH-PROFILE Error), Error-value=3 139 (Incompatible path profiles) if two or more path profile identifiers 140 are incompatible. That is, they are known and valid, but can not 141 occur simultanously. The PCEP-ERROR object SHOULD include the path 142 profile identifiers that generated the error condition. 144 The PCE will determine whether to consider any additional optional 145 objects included in a PCReq message based on policy. As illustrated 146 in Section 3.2.1 and Section 3.2.2, the PCC MAY include other 147 optional objects along with a PATH-PROFILE object as part of a path 148 computation request. The PCC will use the processing-rule (P) flag 149 in the common object header to signal whether it considers those 150 objects mandatory or optional when the PCE performs path computation. 151 Those objects may overlap with the path parameters that the PCE 152 associates with the path profile identifier. 154 PCE policy may place different kinds of restrictions on PCReq 155 messages that include a PATH-PROFILE object and additional 156 parameters. A PCE MUST send an error message if it receives a 157 request with optional objects signaled as mandatory (P flag = 1) for 158 path computation and PCE policy does not allow such behavior from the 159 originating PCC. In that case, the PCE sends a PCErr message with 160 Error-Type=[TBA] (PATH-PROFILE Error), Error-value=3 (Unexpected 161 mandatory object). If the objects are signaled as optional (P flag = 162 0) for path computation, the PCE will decide based on policy whether 163 to consider them or not. When sending the PCRep message for the 164 request, the PCE will use the ignore (I) flag in the common object 165 header to indicate to the PCC whether an object was ignored. 167 3.2.1. Point-to-Point Paths 169 [RFC5440] defines the basic structure of a PCReq message for point- 170 to-point paths. This documents extends the message format as 171 follows: 173 ::= 174 [] 175 177 where: 179 ::=[] 180 ::=[] 182 ::= 183 184 [] 185 [] 187 where: 189 is the list of optional objects used for path 190 computation as defined initially in [RFC5440] and modified in 191 subsequent PCEP extensions. 193 If present in a PCReq message, the PATH-PROFILE object MUST be the 194 first optional object in the request portion of the message. 196 3.2.2. Point-to-Multipoint Paths 198 [RFC6006] defines the basic structure of a PCReq message for point- 199 to-multipoint paths. This documents extends the message format as 200 follows: 202 ::= 203 205 where: 207 ::= 208 209 [] 210 [] 211 [] 212 [] 213 [] 214 [] 215 [] 217 where: 219 ::= 220 [][] 221 [] 223 ::=[][] 224 ::=[] 226 If present in a PCReq message, the PATH-PROFILE object MUST be the 227 first optional object in the request portion of the message. 229 3.3. PCE-Initiated Paths 231 A PCE MAY include a PATH-PROFILE object when sending a PCInitiate 232 message as defined in [I-D.ietf-pce-pce-initiated-lsp]. The PCC uses 233 the path profile identifiers to select path parameters or path 234 policies to be applied during the instantiation of the path. The PCC 235 MUST process the identifiers in the PATH-PROFILE object in the order 236 received. The means by which the PCE learns about a particular path 237 profile identifier and decides to include it in a PCInitiate message 238 are outside the scope of this document. Similarly, the means by 239 which the PCC selects a set of parameters or policies based on the 240 profile identifier for a specific path are outside the scope of this 241 document. 243 A PCC may receive a path instantiation request with one or more 244 unexpected path profile identifiers. The PCC sends a PCErr message 245 with Error-Type=[TBA] (PATH-PROFILE Error), Error-value=1 (Unknown 246 path profiles) if the path profile identifier is not known to the 247 PCC. The PCC sends a PCErr message with Error-Type=[TBA] (PATH- 248 PROFILE Error), Error-value=2 (Invalid path profiles) if the PCC 249 knows about the path profile identifier, but considers the request 250 invalid. As an example, the profile may be invalid because of the 251 path type, the PCEP session type or the originating PCE. The PCC 252 sends a PCErr message with Error-Type=[TBA] (PATH-PROFILE Error), 253 Error-value=3 (Incompatible path profiles) if two or more path 254 profile identifiers are incompatible. That is, they are known and 255 valid, but can not occur simultanously. The PCEP-ERROR object SHOULD 256 include the path profile identifiers that generated the error 257 condition. 259 [I-D.ietf-pce-pce-initiated-lsp] defines the basic structure of a 260 PCInitiate message. This documents extends the message format as 261 follows: 263 ::= 264 265 Where: 267 ::= 268 [] 270 ::= (| 271 ) 273 ::= 274 275 276 277 [PATH-PROFILE> 278 [] 280 ::= 281 283 where: 285 is defined in [RFC5440] and extended by PCEP 286 extensions. 288 4. Object Extensions 290 4.1. OPEN Object 292 This documents defines a new optional PATH-PROFILE-CAPABILITY TLV in 293 the OPEN object. 295 0 1 2 3 296 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 297 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 298 | Type=[TBA] | Length=4 | 299 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 300 | Reserved | Flags | 301 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 303 PATH-PROFILE-CAPABILITY TLV 305 Figure 1 307 Reserved (16 bits): 309 MUST be set to zero on transmission and ignored on receipt. 311 Flags (16 bits): 312 Unassigned bits are considered reserved. They MUST be set to zero 313 on transmission and ignored on receipt. No flags are currently 314 defined. 316 4.2. PATH-PROFILE Object 318 The PATH-PROFILE object may be carried in PCReq, PCInitiate and PCUpd 319 messages. 321 PATH-PROFILE Object-Class is [TBA]. 323 PATH-PROFILE Object-Type is 1. 325 0 1 2 3 326 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 327 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 328 | | 329 // TLVs // 330 | | 331 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 333 PATH-PROFILE Object 335 Figure 2 337 The PATH-PROFILE object has a variable length and contains one or 338 more PATH-PROFILE-ID TLVs. 340 0 1 2 3 341 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 342 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 343 | Type=[TBD] | Length=6 | 344 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 345 | Reserved | Flags | Path Profile Id | 346 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 347 | Path Profile Id (cont) | 348 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 350 PATH-PROFILE-ID TLV 352 Figure 3 354 Reserved (8 bits): 356 MUST be set to zero on transmission and ignored on receipt. 358 Flags (8 bits): 359 Unassigned bits are considered reserved. They MUST be set to zero 360 on transmission and ignored on receipt. No flags are currently 361 defined. 363 Path Profile Id (32 bits): 364 (non-zero) unsigned path profile identifier. 366 If more than one PATH-PROFILE object is present, the first one MUST 367 be processed and subsequent objects ignored. 369 5. Error Codes for PATH-PROFILE Object 371 Error-Type Meaning Error-Value 372 PATH-PROFILE Error 1: Unknown path profiles 373 2: Invalid path profiles 374 3: Incompatible path profiles 375 4: Unexpected mandatory object 377 6. Acknowledgements 379 The authors would like to thank Clarence Filsfils for his valuable 380 comments. 382 7. IANA Considerations 384 IANA is requested to assign the following code points. 386 PATH-PROFILE-CAPABILITY TLV 388 PATH-PROFILE Object-Class 390 PATH-PROFILE Object-Type 392 PATH-PROFILE Error-Type 394 8. Security Considerations 396 TBD 398 9. References 399 9.1. Normative References 401 [I-D.ali-pce-remote-initiated-gmpls-lsp] 402 Ali, Z., Sivabalan, S., Filsfils, C., Varga, R., Lopez, 403 V., Dios, O., and X. Zhang, "Path Computation Element 404 Communication Protocol (PCEP) Extensions for remote- 405 initiated GMPLS LSP Setup", draft-ali-pce-remote- 406 initiated-gmpls-lsp-03 (work in progress), February 2014. 408 [I-D.ietf-pce-gmpls-pcep-extensions] 409 Margaria, C., Dios, O., and F. Zhang, "PCEP extensions for 410 GMPLS", draft-ietf-pce-gmpls-pcep-extensions-09 (work in 411 progress), February 2014. 413 [I-D.ietf-pce-pce-initiated-lsp] 414 Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "PCEP 415 Extensions for PCE-initiated LSP Setup in a Stateful PCE 416 Model", draft-ietf-pce-pce-initiated-lsp-00 (work in 417 progress), December 2013. 419 [I-D.ietf-pce-stateful-pce] 420 Crabbe, E., Medved, J., Minei, I., and R. Varga, "PCEP 421 Extensions for Stateful PCE", draft-ietf-pce-stateful- 422 pce-08 (work in progress), February 2014. 424 [I-D.sivabalan-pce-segment-routing] 425 Sivabalan, S., Medved, J., Filsfils, C., Crabbe, E., and 426 R. Raszuk, "PCEP Extensions for Segment Routing", draft- 427 sivabalan-pce-segment-routing-02 (work in progress), 428 October 2013. 430 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 431 Requirement Levels", BCP 14, RFC 2119, March 1997. 433 [RFC5440] Vasseur, JP. and JL. Le Roux, "Path Computation Element 434 (PCE) Communication Protocol (PCEP)", RFC 5440, March 435 2009. 437 [RFC6006] Zhao, Q., King, D., Verhaeghe, F., Takeda, T., Ali, Z., 438 and J. Meuric, "Extensions to the Path Computation Element 439 Communication Protocol (PCEP) for Point-to-Multipoint 440 Traffic Engineering Label Switched Paths", RFC 6006, 441 September 2010. 443 9.2. Informative References 445 [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation 446 Element (PCE)-Based Architecture", RFC 4655, August 2006. 448 Authors' Addresses 450 Santiago Alvarez 451 Cisco Systems, Inc. 452 170 West Tasman Drive 453 San Jose, CA 95134 454 USA 456 Email: saalvare@cisco.com 458 Siva Sivabalan 459 Cisco Systems, Inc. 460 2000 Innovation Drive 461 Kanata, ON K2K-3E8 462 Canada 464 Email: msiva@cisco.com 466 Zafar Ali 467 Cisco Systems, Inc. 468 2000 Innovation Drive 469 Kanata, ON K2K-3E8 470 Canada 472 Email: zali@cisco.com 474 Luis Tomotaki 475 Verizon 476 400 International 477 Richardson, TX 75081 478 US 480 Email: luis.tomotaki@verizon.com 481 Victor Lopez 482 Telefonica I+D 483 c/ Don Ramon de la Cruz 84 484 Madrid 28006 485 Spain 487 Email: vlopez@tid.es