idnits 2.17.1 draft-ietf-pce-association-policy-16.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 (January 21, 2021) is 1183 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) -- Obsolete informational reference (is this intentional?): RFC 7525 (Obsoleted by RFC 9325) == Outdated reference: A later version (-23) exists of draft-ietf-pce-pcep-yang-15 Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 PCE Working Group S. Litkowski 3 Internet-Draft Cisco Systems, Inc. 4 Intended status: Standards Track S. Sivabalan 5 Expires: July 25, 2021 Ciena 6 J. Tantsura 7 Apstra, Inc. 8 J. Hardwick 9 Metaswitch Networks 10 C. Li 11 Huawei Technologies 12 January 21, 2021 14 Path Computation Element (PCE) Communication Protocol (PCEP) extension 15 for associating Policies and Label Switched Paths (LSPs) 16 draft-ietf-pce-association-policy-16 18 Abstract 20 This document introduces a simple mechanism to associate policies to 21 a group of Label Switched Paths (LSPs) via an extension to the Path 22 Computation Element (PCE) Communication Protocol (PCEP). The 23 extension allows a PCEP speaker to advertise to a PCEP peer that a 24 particular LSP belongs to a particular Policy Association Group. 26 Status of This Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at https://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on July 25, 2021. 43 Copyright Notice 45 Copyright (c) 2021 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (https://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 61 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 62 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 63 3. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 4 64 3.1. Policy based Constraints . . . . . . . . . . . . . . . . 5 65 4. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 6 66 5. Policy Association Group . . . . . . . . . . . . . . . . . . 7 67 5.1. Policy Parameters TLV . . . . . . . . . . . . . . . . . . 7 68 6. Implementation Status . . . . . . . . . . . . . . . . . . . . 9 69 6.1. Cisco's Implementation . . . . . . . . . . . . . . . . . 9 70 7. Security Considerations . . . . . . . . . . . . . . . . . . . 9 71 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 72 8.1. Association object Type Indicators . . . . . . . . . . . 10 73 8.2. PCEP TLV Type Indicators . . . . . . . . . . . . . . . . 10 74 8.3. PCEP Errors . . . . . . . . . . . . . . . . . . . . . . . 11 75 9. Manageability Considerations . . . . . . . . . . . . . . . . 11 76 9.1. Control of Function and Policy . . . . . . . . . . . . . 11 77 9.2. Information and Data Models . . . . . . . . . . . . . . . 11 78 9.3. Liveness Detection and Monitoring . . . . . . . . . . . . 12 79 9.4. Verify Correct Operations . . . . . . . . . . . . . . . . 12 80 9.5. Requirements on Other Protocols . . . . . . . . . . . . . 12 81 9.6. Impact on Network Operations . . . . . . . . . . . . . . 12 82 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12 83 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 84 11.1. Normative References . . . . . . . . . . . . . . . . . . 13 85 11.2. Informative References . . . . . . . . . . . . . . . . . 13 86 Appendix A. Example of Policy Parameters . . . . . . . . . . . . 15 87 Appendix B. Contributor Addresses . . . . . . . . . . . . . . . 15 88 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 90 1. Introduction 92 [RFC5440] describes the Path Computation Element Communication 93 Protocol (PCEP) which enables the communication between a Path 94 Computation Client (PCC) and a Path Control Element (PCE), or between 95 two PCEs based on the PCE architecture [RFC4655]. [RFC5394] provides 96 additional details on policy within the PCE architecture and also 97 provides context for the support of PCE Policy. 99 PCEP Extensions for Stateful PCE Model [RFC8231] describes a set of 100 extensions to PCEP to enable active control of Multiprotocol Label 101 Switching Traffic Engineering (MPLS-TE) and Generalized MPLS (GMPLS) 102 tunnels. [RFC8281] describes the set-up and teardown of PCE- 103 initiated LSPs under the active stateful PCE model, without the need 104 for local configuration on the PCC, thus allowing for a dynamic 105 network. Currently, the LSPs can either be signaled via Resource 106 Reservation Protocol Traffic Engineering (RSVP-TE) or can be segment 107 routed as specified in [RFC8664]. 109 [RFC8697] introduces a generic mechanism to create a grouping of LSPs 110 which can then be used to define associations between a set of LSPs 111 and a set of attributes (such as configuration parameters or 112 behaviors) and is equally applicable to stateful PCE (active and 113 passive modes) and stateless PCE. 115 This document specifies a PCEP extension to associate one or more 116 LSPs with policies using the generic association mechanism. 118 A PCEP speaker may want to influence the PCEP peer with respect to 119 path selection and other policies. This document describes a PCEP 120 extension to associate policies by creating Policy Association Group 121 (PAG) and encoding this association in PCEP messages. The 122 specification is applicable to both stateful and stateless PCEP 123 sessions. 125 Note that the actual policy definition and the associated parameters 126 are out of scope of this document. 128 1.1. Requirements Language 130 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 131 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 132 "OPTIONAL" in this document are to be interpreted as described in BCP 133 14 [RFC2119] [RFC8174] when, and only when, they appear in all 134 capitals, as shown here. 136 2. Terminology 138 The following terminology is used in this document. 140 Association parameters: As described in [RFC8697], the combination 141 of the mandatory fields Association type, Association ID and 142 Association Source in the ASSOCIATION object uniquely identify the 143 association group. If the optional TLVs - Global Association 144 Source or Extended Association ID are included, then they are 145 included in combination with mandatory fields to uniquely identify 146 the association group. 148 Association information: As described in [RFC8697], the ASSOCIATION 149 object could include other optional TLVs based on the association 150 types, that provide 'information' related to the association. 152 LSR: Label Switch Router. 154 MPLS: Multiprotocol Label Switching. 156 PAG: Policy Association Group. 158 PAT: Policy Association Type. 160 PCC: Path Computation Client; any client application requesting a 161 path computation to be performed by a Path Computation Element. 163 PCE: Path Computation Element; an entity (component, application, or 164 network node) that is capable of computing a network path or route 165 based on a network graph and applying computational constraints. 167 PCEP: Path Computation Element Communication Protocol. 169 3. Motivation 171 Paths computed using PCE can be subjected to various policies at both 172 the PCE and the PCC. For example, in a centralized traffic 173 engineering (TE) scenario, network operators may instantiate LSPs and 174 specify policies for traffic accounting, path monitoring, telemetry, 175 etc., for some LSPs via the Stateful PCE. Similarly, a PCC could 176 request a user-specific or service-specific policy to be applied at 177 the PCE, such as constraints relaxation policy to meet optimal QoS 178 and resiliency. 180 PCEP speakers can use the generic mechanism of [RFC8697] to associate 181 a set of LSPs with a policy, without the need to know the details of 182 such a policy. This simplifies network operations and avoids 183 frequent software upgrades, as well as provides the ability to 184 introduce new policies more quickly. 186 PAG Y 187 {Service-Specific Policy 188 for constraint 189 Monitor LSP relaxation} 190 | | 191 | PAG X PCReq/PCRpt | 192 V {Monitor LSP} {PAG Y} V 193 +-----+ ----------------> +-----+ 194 _ _ _ _ _ _| PCE | | | PCE | 195 | +-----+ | ----------> +-----+ 196 | PCInitiate/PCUpd | | PCReq/PCRpt 197 |{PAG X} | | {PAG Y} 198 | | | 199 | .-----. | | .-----. 200 | ( ) | +----+ ( ) 201 | .--( )--. | |PCC1|--.--( )--. 202 V ( ) | +----+ ( ) 203 +---+ ( ) | ( ) 204 |PCC|----( (G)MPLS network ) +----+ ( (G)MPLS network ) 205 +---+ ( ) |PCC2|------( ) 206 PAG X ( ) +----+ ( ) 207 {Monitor '--( )--' '--( )--' 208 LSP} ( ) ( ) 209 '-----' '-----' 211 Case 1: Policy requested by PCE Case 2: Policy requested by 212 and enforced by PCC PCC and enforced by 213 PCE 215 Figure 1: Sample use-cases for carrying policies over PCEP 217 3.1. Policy based Constraints 219 In the context of Policy-Enabled Path Computation Framework 220 [RFC5394], path computation policies may be applied at either a PCC 221 or a PCE or both. A Label Switching Router (LSR) with a policy 222 enabled PCC can receive 224 o a service request via signaling, including over a Network-Network 225 Interface (NNI) or User-Network Interface (UNI) reference point 227 o a configuration request over a management interface to establish a 228 service 230 The PCC may apply user-specific or service-specific policies to 231 decide how the path selection process should be constrained, that is, 232 which constraints, diversities, optimization criterion, and 233 constraint relaxation strategies should be applied in order for the 234 service LSP(s) to have a likelihood to be successfully established 235 and provide necessary QoS and resilience against network failures. 236 The user-specific or service-specific policies applied to PCC and are 237 then passed to the PCE along with the Path computation request, in 238 the form of constraints [RFC5394]. 240 PCEP speaker can use the generic mechanism as per [RFC8697] to 241 associate a set of LSPs with policies and its resulting path 242 computation constraints. This would simplify the path computation 243 message exchanges in PCEP. 245 4. Overview 247 As per [RFC8697], LSPs are associated with other LSPs with which they 248 interact by adding them to a common association group. Grouping can 249 also be used to define the association between LSPs and policies 250 associated to them. As described in [RFC8697], the association group 251 is uniquely identified by the combination of the following fields in 252 the ASSOCIATION object: Association Type, Association ID, Association 253 Source, and (if present) Global Association Source or Extended 254 Association ID. This document defines a new Association type, called 255 "Policy Association", of value 3 (early-allocated by IANA), based on 256 the generic ASSOCIATION object. This new Association type is also 257 called "PAT", for "Policy Association Type". 259 [RFC8697] specifies the mechanism for the capability advertisement of 260 the Association types supported by a PCEP speaker by defining a 261 ASSOC-Type-List TLV to be carried within an OPEN object. This 262 capability exchange for the PAT MUST be done before using the policy 263 association. Thus the PCEP speaker MUST include the PAT in the 264 ASSOC-Type-List TLV and MUST receive the same from the PCEP peer 265 before using the Policy Association Group (PAG) in PCEP messages. 267 The Policy Association type (3) is operator-configured (as specified 268 in [RFC8697]), i.e. the association is created by the operator 269 manually on the PCEP peers and an LSP belonging to this association 270 is conveyed via PCEP messages to the PCEP peer. There is no need to 271 convey an explicit Operator-configured Association Range, which could 272 only serve to artificially limit the available association IDs. 273 Thus, for Policy Association type, Operator-configured Association 274 Range MUST NOT be set, and MUST be ignored if received. 276 A PAG can have one or more LSPs. The association parameters 277 including association identifier, Association type (PAT), as well as 278 the association source IP address are manually configured by the 279 operator and are used to identify the PAG as described in [RFC8697]. 281 The Global Association Source and Extended Association ID MAY also be 282 included. 284 As per the processing rules specified in section 6.4 of [RFC8697], if 285 a PCEP speaker does not support this Policy Association type, it 286 would return a PCErr message with Error-Type 26 "Association Error" 287 and Error-Value 1 "Association type is not supported". The PAG and 288 the policy MUST be configured on the PCEP peers as per the operator- 289 configured association procedures. All further processing is as per 290 section 6.4 of [RFC8697]. If a PCE speaker receives PAG in a PCEP 291 message, and the policy association information is not configured, it 292 MUST return a PCErr message with Error-Type 26 "Association Error" 293 and Error-Value 4 "Association unknown". 295 Associating a particular LSP to multiple policy groups is allowed 296 from a protocol perspective, however, there is no assurance that the 297 PCEP speaker will be able to apply multiple policies. If a PCEP 298 speaker does not support handling of multiple policies for an LSP, it 299 MUST NOT add the LSP into the association group and MUST return a 300 PCErr with Error- Type 26 (Association Error) and Error-value 7 301 (Cannot join the association group). 303 5. Policy Association Group 305 Association groups and their memberships are defined using the 306 ASSOCIATION object defined in [RFC8697]. Two object types for IPv4 307 and IPv6 are defined. The ASSOCIATION object includes "Association 308 type" indicating the type of the association group. This document 309 add a new Association type (PAT). 311 PAG may carry optional TLVs including but not limited to - 313 o POLICY-PARAMETERS-TLV: Used to communicate opaque information 314 useful to apply the policy, described in Section 5.1. 316 o VENDOR-INFORMATION-TLV: Used to communicate arbitrary vendor 317 specific behavioral information, described in [RFC7470]. 319 5.1. Policy Parameters TLV 321 The POLICY-PARAMETERS-TLV is an optional TLV that can be carried in 322 ASSOCIATION object (for PAT) to carry opaque information needed to 323 apply the policy at the PCEP peer. In some cases to apply a PCE 324 policy successfully, it is required to also associate some policy 325 parameters that need to be evaluated. This TLV is used to carry 326 those policy parameters. The TLV could include one or more policy 327 related parameters. The encoding format and the order MUST be known 328 to the PCEP peers, this could be done during the configuration of the 329 policy (and its association parameters) for the PAG. The TLV format 330 is as per the format of the PCEP TLVs, as defined in [RFC5440], and 331 shown in Figure 2. Only one POLICY-PARAMETERS-TLV can be carried and 332 only the first occurrence is processed and any others MUST be 333 ignored. 335 0 1 2 3 336 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 337 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 338 | Type=48 | Length | 339 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 340 | | 341 // Policy Parameters // 342 | | 343 +---------------------------------------------------------------+ 345 Figure 2: The POLICY-PARAMETERS-TLV format 347 The type of the POLICY-PARAMETERS-TLV is 48 (early-allocated by IANA) 348 and it has a variable length. The Value field is variable and padded 349 to a 4-byte alignment; padding is not included in the Length field. 350 The PCEP peer implementation needs to be aware of the encoding 351 format, order, and meaning of the 'Policy Parameters' well in advance 352 based on the policy. Note that from the protocol point of view this 353 data is opaque and can be used to carry parameters in any format 354 understood by the PCEP peers and associated to the policy. The exact 355 use of this TLV is beyond the scope of this document. Examples are 356 included for illustration purposes in Appendix A. 358 If the PCEP peer is unaware of the policy parameters associated with 359 the policy and it receives the POLICY-PARAMETERS-TLV, it MUST reject 360 the PCEP message and send a PCErr message with Error-Type 26 361 "Association Error" and Error-Value TBD3 "Not expecting policy 362 parameters". Further, if one or more parameters in the POLICY- 363 PARAMETERS-TLV received by the PCEP speaker are considered as 364 unacceptable in the context of the associated policy (e.g., out of 365 range value, badly encoded value...), the PCEP speaker MUST reject 366 the PCEP message and send a PCErr message with Error-Type 26 367 "Association Error" and Error-Value TBD4 "Unacceptable policy 368 parameters". 370 Note that, the vendor-specific behavioral information is encoded in 371 VENDOR-INFORMATION-TLV which can be used along with this TLV. 373 6. Implementation Status 375 [Note to the RFC Editor - remove this section before publication, as 376 well as remove the reference to RFC 7942.] 378 This section records the status of known implementations of the 379 protocol defined by this specification at the time of posting of this 380 Internet-Draft, and is based on a proposal described in [RFC7942]. 381 The description of implementations in this section is intended to 382 assist the IETF in its decision processes in progressing drafts to 383 RFCs. Please note that the listing of any individual implementation 384 here does not imply endorsement by the IETF. Furthermore, no effort 385 has been spent to verify the information presented here that was 386 supplied by IETF contributors. This is not intended as, and must not 387 be construed to be, a catalog of available implementations or their 388 features. Readers are advised to note that other implementations may 389 exist. 391 According to [RFC7942], "this will allow reviewers and working groups 392 to assign due consideration to documents that have the benefit of 393 running code, which may serve as evidence of valuable experimentation 394 and feedback that have made the implemented protocols more mature. 395 It is up to the individual working groups to use this information as 396 they see fit". 398 6.1. Cisco's Implementation 400 o Organization: Cisco Systems, Inc. 402 o Implementation: IOS-XR PCE and PCC. 404 o Description: The PCEP extension specified in this document is used 405 to convey traffic steering policies. 407 o Maturity Level: In shipping product. 409 o Coverage: Partial. 411 o Contact: mkoldych@cisco.com 413 7. Security Considerations 415 The security considerations described in [RFC8697], [RFC8231], 416 [RFC5394], and [RFC5440] apply to the extensions described in this 417 document as well. In particular, a malicious PCEP speaker could be 418 spoofed and used as an attack vector by creating spurious policy 419 associations as described in [RFC8697]. Further as described in 420 [RFC8697], a spurious LSP can have policies that are inconsistent 421 with those of the legitimate LSPs of the group and thus cause 422 problems in handling of the policy for the legitimate LSPs. It 423 should be noted that policy association could provide an adversary 424 with the opportunity to eavesdrop on the relationship between the 425 LSPs. [RFC8697] suggest that the implementations and operators to 426 use indirect values as a way to hide any sensitive business 427 relationships. Thus, securing the PCEP session using Transport Layer 428 Security (TLS) [RFC8253], as per the recommendations and best current 429 practices in BCP 195 [RFC7525], is RECOMMENDED. 431 Further, extra care needs to be taken by the implementation with 432 respect to POLICY-PARAMETERS-TLV while decoding, verifying, and 433 applying these policy variables. This TLV parsing could be exploited 434 by an attacker and thus extra care must be taken while configuring 435 policy association that uses POLICY-PARAMETERS-TLV and making sure 436 that the data is easy to parse and verify before use. Ensuring 437 agreement among all relevant PCEP peers as to the format and layout 438 of the policy parameters information is key for the correct 439 operations. Note that, the parser for POLICY-PARAMETERS-TLV is 440 particularly sensitive since it is opque to PCEP and can be used to 441 convey data with many different internal structure/formats. The 442 choice of decoder is dependent on the additional metadata associated 443 with the policy and thus incur additional risk of using a wrong 444 decoder and getting garbage results. Use standard and well-known 445 policy formats could help alleviate those risks. 447 8. IANA Considerations 449 8.1. Association object Type Indicators 451 This document defines a new Association type. The sub-registry 452 "ASSOCIATION Type Field" of the "Path Computation Element Protocol 453 (PCEP) Numbers" registry was originally defined in [RFC8697]. IANA 454 is requested to confirm the early-allocated codepoint. 456 Value Name Reference 458 3 Policy Association [This.I-D] 460 8.2. PCEP TLV Type Indicators 462 The following TLV Type Indicator value is requested within the "PCEP 463 TLV Type Indicators" subregistry of the "Path Computation Element 464 Protocol (PCEP) Numbers" registry. IANA is requested to confirm the 465 early-allocated codepoint. 467 Value Description Reference 469 48 POLICY-PARAMETERS-TLV [This.I-D] 471 8.3. PCEP Errors 473 This document defines new Error-Values for Error-type 26 "Association 474 Error" defined in [RFC8697]. IANA is requested to allocate new error 475 values within the "PCEP- ERROR Object Error Types and Values" 476 subregistry of the PCEP Numbers registry as follows: 478 Error-Type Meaning Error-value Reference 480 26 Association [RFC8697] 481 Error 482 TBD3: Not expecting [This.I-D] 483 policy parameters 485 TBD4: Unacceptable [This.I-D] 486 policy parameters 488 9. Manageability Considerations 490 9.1. Control of Function and Policy 492 An operator MUST be allowed to configure the policy associations at 493 PCEP peers and associate it with the LSPs. They MAY also allow 494 configuration to related policy parameters, and provide information 495 on the encoding format and order to parse the associated policy 496 parameters TLV. 498 9.2. Information and Data Models 500 [RFC7420] describes the PCEP MIB; there are no new MIB Objects for 501 this document. 503 The PCEP YANG module is defined in [I-D.ietf-pce-pcep-yang]. That 504 module supports associations as defined in [RFC8697] and thus 505 supports the Policy Association groups. 507 An implementation SHOULD allow the operator to view the PAG 508 configured. Further implementation SHOULD allow to view associations 509 reported by each peer, and the current set of LSPs in the PAG. 511 9.3. Liveness Detection and Monitoring 513 Mechanisms defined in this document do not imply any new liveness 514 detection and monitoring requirements in addition to those already 515 listed in [RFC5440], [RFC8231], and [RFC8281]. 517 9.4. Verify Correct Operations 519 Verifying the correct operation of a policy can be performed by 520 monitoring various parameters as described in [RFC5440] and 521 [RFC8231]. A PCEP implementation SHOULD provide information on 522 failed path computation because of appling policy and log error 523 events, e.g., parsing failure for policy parameters TLV. 525 9.5. Requirements on Other Protocols 527 Mechanisms defined in this document do not imply any new requirements 528 on other protocols. 530 9.6. Impact on Network Operations 532 Mechanisms defined in this document do not have any impact on network 533 operations in addition to those already listed in [RFC5440], 534 [RFC8231], and [RFC8281]. 536 10. Acknowledgments 538 We would like to acknowledge and thank Santiago Alvarez, Zafar Ali, 539 Luis Tomotaki, Victor Lopez, Rob Shakir, and Clarence Filsfils for 540 working on earlier drafts with similar motivation. 542 A special thanks to the authors of [RFC8697], this document borrowed 543 some of the text from it. The authors would like to thank Aijun 544 Wang, Peng Shuping, and Gyan Mishra for their useful comments. 546 Thanks to Hari for shepherding this document. Thanks to Deborah 547 Brungard for providing comments and being the responsible AD for this 548 document. 550 Thanks to Nic Leymann for RTGDIR review. 552 Thanks to Benjamin Kaduk and Murray Kucherawy for the comments during 553 IESG review. 555 11. References 557 11.1. Normative References 559 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 560 Requirement Levels", BCP 14, RFC 2119, 561 DOI 10.17487/RFC2119, March 1997, 562 . 564 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 565 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 566 DOI 10.17487/RFC5440, March 2009, 567 . 569 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 570 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 571 May 2017, . 573 [RFC8231] Crabbe, E., Minei, I., Medved, J., and R. Varga, "Path 574 Computation Element Communication Protocol (PCEP) 575 Extensions for Stateful PCE", RFC 8231, 576 DOI 10.17487/RFC8231, September 2017, 577 . 579 [RFC8253] Lopez, D., Gonzalez de Dios, O., Wu, Q., and D. Dhody, 580 "PCEPS: Usage of TLS to Provide a Secure Transport for the 581 Path Computation Element Communication Protocol (PCEP)", 582 RFC 8253, DOI 10.17487/RFC8253, October 2017, 583 . 585 [RFC8697] Minei, I., Crabbe, E., Sivabalan, S., Ananthakrishnan, H., 586 Dhody, D., and Y. Tanaka, "Path Computation Element 587 Communication Protocol (PCEP) Extensions for Establishing 588 Relationships between Sets of Label Switched Paths 589 (LSPs)", RFC 8697, DOI 10.17487/RFC8697, January 2020, 590 . 592 11.2. Informative References 594 [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation 595 Element (PCE)-Based Architecture", RFC 4655, 596 DOI 10.17487/RFC4655, August 2006, 597 . 599 [RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, 600 "Network Time Protocol Version 4: Protocol and Algorithms 601 Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010, 602 . 604 [RFC5394] Bryskin, I., Papadimitriou, D., Berger, L., and J. Ash, 605 "Policy-Enabled Path Computation Framework", RFC 5394, 606 DOI 10.17487/RFC5394, December 2008, 607 . 609 [RFC7420] Koushik, A., Stephan, E., Zhao, Q., King, D., and J. 610 Hardwick, "Path Computation Element Communication Protocol 611 (PCEP) Management Information Base (MIB) Module", 612 RFC 7420, DOI 10.17487/RFC7420, December 2014, 613 . 615 [RFC7470] Zhang, F. and A. Farrel, "Conveying Vendor-Specific 616 Constraints in the Path Computation Element Communication 617 Protocol", RFC 7470, DOI 10.17487/RFC7470, March 2015, 618 . 620 [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, 621 "Recommendations for Secure Use of Transport Layer 622 Security (TLS) and Datagram Transport Layer Security 623 (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 624 2015, . 626 [RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running 627 Code: The Implementation Status Section", BCP 205, 628 RFC 7942, DOI 10.17487/RFC7942, July 2016, 629 . 631 [RFC8281] Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "Path 632 Computation Element Communication Protocol (PCEP) 633 Extensions for PCE-Initiated LSP Setup in a Stateful PCE 634 Model", RFC 8281, DOI 10.17487/RFC8281, December 2017, 635 . 637 [RFC8664] Sivabalan, S., Filsfils, C., Tantsura, J., Henderickx, W., 638 and J. Hardwick, "Path Computation Element Communication 639 Protocol (PCEP) Extensions for Segment Routing", RFC 8664, 640 DOI 10.17487/RFC8664, December 2019, 641 . 643 [I-D.ietf-pce-pcep-yang] 644 Dhody, D., Hardwick, J., Beeram, V., and J. Tantsura, "A 645 YANG Data Model for Path Computation Element 646 Communications Protocol (PCEP)", draft-ietf-pce-pcep- 647 yang-15 (work in progress), October 2020. 649 Appendix A. Example of Policy Parameters 651 An example could be a monitoring and telemetry policy P1 that is 652 dependent on a profile (GOLD/SILVER/BRONZE) as set by the operator. 653 The PCEP peers need to be aware of the policy P1 (and its associated 654 characteristics) in advance as well the fact that the policy 655 parameter will encode the profile of type string in the POLICY- 656 PARAMETERS-TLV. As an example, LSP1 could encode the PAG with the 657 POLICY-PARAMETERS-TLV with a string "GOLD". 659 Another example where the path computation at PCE could be dependent 660 on when the LSP was configured at the PCC. For such a policy P2, the 661 time-stamp can be encoded in the POLICY-PARAMETERS-TLV and the exact 662 encoding could be the 64-bit timestamp format as defined in 663 [RFC5905]. 665 While the above example has a single field in the POLICY-PARAMETERS- 666 TLV, it is possible to include multiple fields, but the exact order, 667 encoding format and meanings need to be known in advance at the PCEP 668 peers. 670 Appendix B. Contributor Addresses 671 Following have contributed extensively: 673 Mahendra Singh Negi 674 RtBrick Inc 675 N-17L, 18th Cross Rd, HSR Layout 676 Bangalore, Karnataka 560102 677 India 679 EMail: mahend.ietf@gmail.com 681 Dhruv Dhody 682 Huawei Technologies 683 Divyashree Techno Park, Whitefield 684 Bangalore, Karnataka 560066 685 India 687 EMail: dhruv.ietf@gmail.com 689 Following have contributed text that was incorporated: 691 Qin Wu 692 Huawei Technologies 693 101 Software Avenue, Yuhua District 694 Nanjing, Jiangsu 210012 695 China 697 EMail: sunseawq@huawei.com 699 Xian Zhang 700 Huawei Technologies 701 Bantian, Longgang District 702 Shenzhen 518129 703 P.R.China 705 EMail: zhang.xian@huawei.com 707 Udayasree Palle 709 EMail: udayasreereddy@gmail.com 711 Mike Koldychev 712 Cisco Systems, Inc. 713 Canada 715 EMail: mkoldych@cisco.com 717 Authors' Addresses 719 Stephane Litkowski 720 Cisco Systems, Inc. 721 11 Rue Camille Desmoulins 722 Issy-les-Moulineaux 92130 723 France 725 EMail: slitkows@cisco.com 727 Siva Sivabalan 728 Ciena 729 385 Terry Fox Drive 730 Kanata, Ontario K2K 0L1 731 Canada 733 EMail: msiva282@gmail.com 735 Jeff Tantsura 736 Apstra, Inc. 738 EMail: jefftant.ietf@gmail.com 740 Jonathan Hardwick 741 Metaswitch Networks 742 100 Church Street 743 Enfield, Middlesex 744 UK 746 EMail: Jonathan.Hardwick@metaswitch.com 748 Cheng Li 749 Huawei Technologies 750 Huawei Campus, No. 156 Beiqing Rd. 751 Beijing 100095 752 China 754 EMail: c.l@huawei.com