idnits 2.17.1 draft-ietf-pce-association-policy-15.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 (December 10, 2020) is 1227 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: June 13, 2021 Ciena 6 J. Tantsura 7 Apstra, Inc. 8 J. Hardwick 9 Metaswitch Networks 10 C. Li 11 Huawei Technologies 12 December 10, 2020 14 Path Computation Element (PCE) Communication Protocol (PCEP) extension 15 for associating Policies and Label Switched Paths (LSPs) 16 draft-ietf-pce-association-policy-15 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 June 13, 2021. 43 Copyright Notice 45 Copyright (c) 2020 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 . . . . . . . . . . . . . . . . . . . . 8 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 . . . . . . . . . . . . . . . . . . . . . . . 10 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 . . . . . . . . . . . . 11 79 9.4. Verify Correct Operations . . . . . . . . . . . . . . . . 11 80 9.5. Requirements on Other Protocols . . . . . . . . . . . . . 12 81 9.6. Impact on Network Operations . . . . . . . . . . . . . . 12 82 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12 83 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 84 11.1. Normative References . . . . . . . . . . . . . . . . . . 12 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 speaker can use the generic mechanism as per [RFC8697] to 181 associate a set of LSPs with a policy, without the need to know the 182 details of such a policy, which simplifies network operations, avoids 183 frequent software upgrades, as well as provides an ability to 184 introduce new policies faster. 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. Consider a Label Switch Router (LSR) with a policy 222 enabled PCC, it receives a service request via signaling, including 223 over a Network-Network Interface (NNI) or User-Network Interface 224 (UNI) reference point, or receives a configuration request over a 225 management interface to establish a service. The PCC may also apply 226 user-specific or service-specific policies to decide how the path 227 selection process should be constrained, that is, which constraints, 228 diversities, optimization criterion, and constraint relaxation 229 strategies should be applied in order for the service LSP(s) to have 230 a likelihood to be successfully established and provide necessary QoS 231 and resilience against network failures. The user-specific or 232 service-specific policies applied to PCC and are then passed to the 233 PCE along with the Path computation request, in the form of 234 constraints [RFC5394]. 236 PCEP speaker can use the generic mechanism as per [RFC8697] to 237 associate a set of LSPs with policy and its resulting path 238 computation constraints. This would simplify the path computation 239 message exchanges in PCEP. 241 4. Overview 243 As per [RFC8697], LSPs are associated with other LSPs with which they 244 interact by adding them to a common association group. Grouping can 245 also be used to define the association between LSPs and policies 246 associated to them. As described in [RFC8697], the association group 247 is uniquely identified by the combination of the following fields in 248 the ASSOCIATION object: Association Type, Association ID, Association 249 Source, and (if present) Global Association Source or Extended 250 Association ID. This document defines a new Association type, called 251 "Policy Association", of value 3 (early-allocated by IANA), based on 252 the generic ASSOCIATION object. This new Association type is also 253 called "PAT", for "Policy Association Type". 255 [RFC8697] specifies the mechanism for the capability advertisement of 256 the Association types supported by a PCEP speaker by defining a 257 ASSOC-Type-List TLV to be carried within an OPEN object. This 258 capability exchange for the PAT MUST be done before using the policy 259 association. Thus the PCEP speaker MUST include the PAT in the 260 ASSOC-Type-List TLV and MUST receive the same from the PCEP peer 261 before using the Policy Association Group (PAG) in PCEP messages. 263 This Association type is operator-configured [RFC8697] association in 264 nature and created by the operator manually on the PCEP peers. An 265 LSP belonging to this association is conveyed via PCEP messages to 266 the PCEP peer. Operator-configured Association Range MUST NOT be set 267 for this association-type, and MUST be ignored, so that the full 268 range of association identifier can be utilized. 270 A PAG can have one or more LSPs. The association parameters 271 including association identifier, Association type (PAT), as well as 272 the association source IP address is manually configured by the 273 operator and is used to identify the PAG as described in [RFC8697]. 274 The Global Association Source and Extended Association ID MAY also be 275 included. 277 As per the processing rules specified in section 6.4 of [RFC8697], if 278 a PCEP speaker does not support this Policy Association type, it 279 would return a PCErr message with Error-Type 26 "Association Error" 280 and Error-Value 1 "Association type is not supported". Since the PAG 281 is opaque in nature, the PAG and the policy MUST be configured on the 282 PCEP peers as per the operator-configured association procedures. 283 All further processing is as per section 6.4 of [RFC8697]. If a PCE 284 speaker receives PAG in a PCEP message, and the policy association 285 information is not configured, it MUST return a PCErr message with 286 Error-Type 26 "Association Error" and Error-Value 4 "Association 287 unknown". 289 Associating a particular LSP to multiple policy groups is authorized 290 from a protocol perspective, however, there is no assurance that the 291 PCEP speaker will be able to apply multiple policies. If a PCEP 292 speaker does not support handling of multiple policies for an LSP, it 293 MUST NOT add the LSP into the association group and MUST return a 294 PCErr with Error- Type 26 (Association Error) and Error-value 7 295 (Cannot join the association group). 297 5. Policy Association Group 299 Association groups and their memberships are defined using the 300 ASSOCIATION object defined in [RFC8697]. Two object types for IPv4 301 and IPv6 are defined. The ASSOCIATION object includes "Association 302 type" indicating the type of the association group. This document 303 add a new Association type (PAT). 305 PAG may carry optional TLVs including but not limited to - 307 o POLICY-PARAMETERS-TLV: Used to communicate opaque information 308 useful to apply the policy, described in Section 5.1. 310 o VENDOR-INFORMATION-TLV: Used to communicate arbitrary vendor 311 specific behavioral information, described in [RFC7470]. 313 5.1. Policy Parameters TLV 315 The POLICY-PARAMETERS-TLV is an optional TLV that can be carried in 316 ASSOCIATION object (for PAT) to carry opaque information needed to 317 apply the policy at the PCEP peer. In some cases to apply a PCE 318 policy successfully, it is required to also associate some policy 319 parameters that need to be evaluated. This TLV is used to carry 320 those policy parameters. The TLV could include one or more policy 321 related parameters. The encoding format and the order MUST be known 322 to the PCEP peers, this could be done during the configuration of the 323 policy (and its association parameters) for the PAG. The TLV format 324 is as per the format of the PCEP TLVs, as defined in [RFC5440], and 325 shown in Figure 2. Only one POLICY-PARAMETERS-TLV can be carried and 326 only the first occurrence is processed and any others MUST be 327 ignored. 329 0 1 2 3 330 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 331 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 332 | Type=48 | Length | 333 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 334 | | 335 // Policy Parameters // 336 | | 337 +---------------------------------------------------------------+ 339 Figure 2: The POLICY-PARAMETERS-TLV format 341 The type of the POLICY-PARAMETERS-TLV is 48 (early-allocated by IANA) 342 and it has a variable length. The Value field is variable and padded 343 to a 4-byte alignment; padding is not included in the Length field. 344 The PCEP peer implementation needs to be aware of the encoding 345 format, order, and meaning of the 'Policy Parameters' well in advance 346 based on the policy. Note that from the protocol point of view this 347 data is opaque and can be used to carry parameters in any format 348 understood by the PCEP peers and associated to the policy. The exact 349 use of this TLV is beyond the scope of this document. Examples are 350 included for illustration purposes in Appendix A. 352 If the PCEP peer is unaware of the policy parameters associated with 353 the policy and it receives the POLICY-PARAMETERS-TLV, it MUST reject 354 the PCEP message and send a PCErr message with Error-Type 26 355 "Association Error" and Error-Value TBD3 "Not expecting policy 356 parameters". Further, if one or more parameters in the POLICY- 357 PARAMETERS-TLV received by the PCEP speaker are considered as 358 unacceptable in the context of the associated policy (e.g. out of 359 range value, badly encoded value...), the PCEP speaker MUST reject 360 the PCEP message and send a PCErr message with Error-Type 26 361 "Association Error" and Error-Value TBD4 "Unacceptable policy 362 parameters". 364 Note that, the vendor-specific behavioral information is encoded in 365 VENDOR-INFORMATION-TLV which can be used along with this TLV. 367 6. Implementation Status 369 [Note to the RFC Editor - remove this section before publication, as 370 well as remove the reference to RFC 7942.] 372 This section records the status of known implementations of the 373 protocol defined by this specification at the time of posting of this 374 Internet-Draft, and is based on a proposal described in [RFC7942]. 376 The description of implementations in this section is intended to 377 assist the IETF in its decision processes in progressing drafts to 378 RFCs. Please note that the listing of any individual implementation 379 here does not imply endorsement by the IETF. Furthermore, no effort 380 has been spent to verify the information presented here that was 381 supplied by IETF contributors. This is not intended as, and must not 382 be construed to be, a catalog of available implementations or their 383 features. Readers are advised to note that other implementations may 384 exist. 386 According to [RFC7942], "this will allow reviewers and working groups 387 to assign due consideration to documents that have the benefit of 388 running code, which may serve as evidence of valuable experimentation 389 and feedback that have made the implemented protocols more mature. 390 It is up to the individual working groups to use this information as 391 they see fit". 393 6.1. Cisco's Implementation 395 o Organization: Cisco Systems, Inc. 397 o Implementation: IOS-XR PCE and PCC. 399 o Description: The PCEP extension specified in this document is used 400 to convey traffic steering policies. 402 o Maturity Level: In shipping product. 404 o Coverage: Partial. 406 o Contact: mkoldych@cisco.com 408 7. Security Considerations 410 The security considerations described in [RFC8697], [RFC8231], 411 [RFC5394], and [RFC5440] apply to the extensions described in this 412 document as well. In particular, a malicious PCEP speaker could be 413 spoofed and used as an attack vector by creating spurious policy 414 associations as described in [RFC8697]. Further as described in 415 [RFC8697], a spurious LSP can have policies that are inconsistent 416 with those of the legitimate LSPs of the group and thus cause 417 problems in handling of the policy for the legitimate LSPs. It 418 should be noted that, Policy association could provide an adversary 419 with the opportunity to eavesdrop on the relationship between the 420 LSPs. [RFC8697] suggest that the implementations and operators to 421 use indirect values as a way to hide any sensitive business 422 relationships. Thus, securing the PCEP session using Transport Layer 423 Security (TLS) [RFC8253], as per the recommendations and best current 424 practices in BCP 195 [RFC7525], is RECOMMENDED. 426 Further, extra care needs to be taken by the implementation with 427 respect to POLICY-PARAMETERS-TLV while decoding, verifying, and 428 applying these policy variables. This TLV parsing could be exploited 429 by an attacker and thus extra care must be taken while configuring 430 policy association that uses POLICY-PARAMETERS-TLV and making sure 431 that the data is easy to parse and verify before use. 433 8. IANA Considerations 435 8.1. Association object Type Indicators 437 This document defines a new Association type. The sub-registry 438 "ASSOCIATION Type Field" of the "Path Computation Element Protocol 439 (PCEP) Numbers" registry was originally defined in [RFC8697]. IANA 440 is requested to confirm the early-allocated codepoint. 442 Value Name Reference 444 3 Policy Association [This.I-D] 446 8.2. PCEP TLV Type Indicators 448 The following TLV Type Indicator value is requested within the "PCEP 449 TLV Type Indicators" subregistry of the "Path Computation Element 450 Protocol (PCEP) Numbers" registry. IANA is requested to confirm the 451 early-allocated codepoint. 453 Value Description Reference 455 48 POLICY-PARAMETERS-TLV [This.I-D] 457 8.3. PCEP Errors 459 This document defines new Error-Values for Error-type 26 "Association 460 Error" defined in [RFC8697]. IANA is requested to allocate new error 461 values within the "PCEP- ERROR Object Error Types and Values" 462 subregistry of the PCEP Numbers registry as follows: 464 Error-Type Meaning Error-value Reference 466 26 Association [RFC8697] 467 Error 468 TBD3: Not expecting [This.I-D] 469 policy parameters 471 TBD4: Unacceptable [This.I-D] 472 policy parameters 474 9. Manageability Considerations 476 9.1. Control of Function and Policy 478 An operator MUST be allowed to configure the policy associations at 479 PCEP peers and associate it with the LSPs. They MAY also allow 480 configuration to related policy parameters, in which case the 481 operator MUST also be allowed to set the encoding format and order to 482 parse the associated policy parameters TLV. 484 9.2. Information and Data Models 486 [RFC7420] describes the PCEP MIB, there are no new MIB Objects for 487 this document. 489 The PCEP YANG module is defined in [I-D.ietf-pce-pcep-yang]. This 490 module supports associations as defined in [RFC8697] and thus 491 supports the Policy Association groups. 493 An implementation SHOULD allow the operator to view the PAG 494 configured. Further implementation SHOULD allow to view associations 495 reported by each peer, and the current set of LSPs in the PAG. 497 9.3. Liveness Detection and Monitoring 499 Mechanisms defined in this document do not imply any new liveness 500 detection and monitoring requirements in addition to those already 501 listed in [RFC5440], [RFC8231], and [RFC8281]. 503 9.4. Verify Correct Operations 505 Mechanisms defined in this document do not imply any new operation 506 verification requirements in addition to those already listed in 507 [RFC5440], [RFC8231], and [RFC8281]. 509 9.5. Requirements on Other Protocols 511 Mechanisms defined in this document do not imply any new requirements 512 on other protocols. 514 9.6. Impact on Network Operations 516 Mechanisms defined in this document do not have any impact on network 517 operations in addition to those already listed in [RFC5440], 518 [RFC8231], and [RFC8281]. 520 10. Acknowledgments 522 We would like to acknowledge and thank Santiago Alvarez, Zafar Ali, 523 Luis Tomotaki, Victor Lopez, Rob Shakir, and Clarence Filsfils for 524 working on earlier drafts with similar motivation. 526 A special thanks to the authors of [RFC8697], this document borrowed 527 some of the text from it. The authors would like to thank Aijun 528 Wang, Peng Shuping, and Gyan Mishra for their useful comments. 530 Thanks to Hari for shepherding this document. Thanks to Deborah 531 Brungard for providing comments and being the responsible AD for this 532 document. 534 Thanks to Nic Leymann for RTGDIR review. 536 11. References 538 11.1. Normative References 540 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 541 Requirement Levels", BCP 14, RFC 2119, 542 DOI 10.17487/RFC2119, March 1997, 543 . 545 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 546 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 547 DOI 10.17487/RFC5440, March 2009, 548 . 550 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 551 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 552 May 2017, . 554 [RFC8231] Crabbe, E., Minei, I., Medved, J., and R. Varga, "Path 555 Computation Element Communication Protocol (PCEP) 556 Extensions for Stateful PCE", RFC 8231, 557 DOI 10.17487/RFC8231, September 2017, 558 . 560 [RFC8697] Minei, I., Crabbe, E., Sivabalan, S., Ananthakrishnan, H., 561 Dhody, D., and Y. Tanaka, "Path Computation Element 562 Communication Protocol (PCEP) Extensions for Establishing 563 Relationships between Sets of Label Switched Paths 564 (LSPs)", RFC 8697, DOI 10.17487/RFC8697, January 2020, 565 . 567 11.2. Informative References 569 [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation 570 Element (PCE)-Based Architecture", RFC 4655, 571 DOI 10.17487/RFC4655, August 2006, 572 . 574 [RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, 575 "Network Time Protocol Version 4: Protocol and Algorithms 576 Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010, 577 . 579 [RFC5394] Bryskin, I., Papadimitriou, D., Berger, L., and J. Ash, 580 "Policy-Enabled Path Computation Framework", RFC 5394, 581 DOI 10.17487/RFC5394, December 2008, 582 . 584 [RFC7420] Koushik, A., Stephan, E., Zhao, Q., King, D., and J. 585 Hardwick, "Path Computation Element Communication Protocol 586 (PCEP) Management Information Base (MIB) Module", 587 RFC 7420, DOI 10.17487/RFC7420, December 2014, 588 . 590 [RFC7470] Zhang, F. and A. Farrel, "Conveying Vendor-Specific 591 Constraints in the Path Computation Element Communication 592 Protocol", RFC 7470, DOI 10.17487/RFC7470, March 2015, 593 . 595 [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, 596 "Recommendations for Secure Use of Transport Layer 597 Security (TLS) and Datagram Transport Layer Security 598 (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 599 2015, . 601 [RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running 602 Code: The Implementation Status Section", BCP 205, 603 RFC 7942, DOI 10.17487/RFC7942, July 2016, 604 . 606 [RFC8253] Lopez, D., Gonzalez de Dios, O., Wu, Q., and D. Dhody, 607 "PCEPS: Usage of TLS to Provide a Secure Transport for the 608 Path Computation Element Communication Protocol (PCEP)", 609 RFC 8253, DOI 10.17487/RFC8253, October 2017, 610 . 612 [RFC8281] Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "Path 613 Computation Element Communication Protocol (PCEP) 614 Extensions for PCE-Initiated LSP Setup in a Stateful PCE 615 Model", RFC 8281, DOI 10.17487/RFC8281, December 2017, 616 . 618 [RFC8664] Sivabalan, S., Filsfils, C., Tantsura, J., Henderickx, W., 619 and J. Hardwick, "Path Computation Element Communication 620 Protocol (PCEP) Extensions for Segment Routing", RFC 8664, 621 DOI 10.17487/RFC8664, December 2019, 622 . 624 [I-D.ietf-pce-pcep-yang] 625 Dhody, D., Hardwick, J., Beeram, V., and J. Tantsura, "A 626 YANG Data Model for Path Computation Element 627 Communications Protocol (PCEP)", draft-ietf-pce-pcep- 628 yang-15 (work in progress), October 2020. 630 Appendix A. Example of Policy Parameters 632 An example could be a monitoring and telemetry policy P1 that is 633 dependent on a profile (GOLD/SILVER/BRONZE) as set by the operator. 634 The PCEP peers need to be aware of the policy P1 (and its associated 635 characteristics) in advance as well the fact that the policy 636 parameter will encode the profile of type string in the POLICY- 637 PARAMETERS-TLV. As an example, LSP1 could encode the PAG with the 638 POLICY-PARAMETERS-TLV with a string "GOLD". 640 Another example where the path computation at PCE could be dependent 641 on when the LSP was configured at the PCC. For such a policy P2, the 642 time-stamp can be encoded in the POLICY-PARAMETERS-TLV and the exact 643 encoding could be the 64-bit timestamp format as defined in 644 [RFC5905]. 646 While the above example has a single field in the POLICY-PARAMETERS- 647 TLV, it is possible to include multiple fields, but the exact order, 648 encoding format and meanings need to be known in advance at the PCEP 649 peers. 651 Appendix B. Contributor Addresses 652 Following have contributed extensively: 654 Mahendra Singh Negi 655 RtBrick Inc 656 N-17L, 18th Cross Rd, HSR Layout 657 Bangalore, Karnataka 560102 658 India 660 EMail: mahend.ietf@gmail.com 662 Dhruv Dhody 663 Huawei Technologies 664 Divyashree Techno Park, Whitefield 665 Bangalore, Karnataka 560066 666 India 668 EMail: dhruv.ietf@gmail.com 670 Following have contributed text that was incorporated: 672 Qin Wu 673 Huawei Technologies 674 101 Software Avenue, Yuhua District 675 Nanjing, Jiangsu 210012 676 China 678 EMail: sunseawq@huawei.com 680 Xian Zhang 681 Huawei Technologies 682 Bantian, Longgang District 683 Shenzhen 518129 684 P.R.China 686 EMail: zhang.xian@huawei.com 688 Udayasree Palle 690 EMail: udayasreereddy@gmail.com 692 Mike Koldychev 693 Cisco Systems, Inc. 694 Canada 696 EMail: mkoldych@cisco.com 698 Authors' Addresses 700 Stephane Litkowski 701 Cisco Systems, Inc. 702 11 Rue Camille Desmoulins 703 Issy-les-Moulineaux 92130 704 France 706 EMail: slitkows@cisco.com 708 Siva Sivabalan 709 Ciena 710 385 Terry Fox Drive 711 Kanata, Ontario K2K 0L1 712 Canada 714 EMail: msiva282@gmail.com 716 Jeff Tantsura 717 Apstra, Inc. 719 EMail: jefftant.ietf@gmail.com 721 Jonathan Hardwick 722 Metaswitch Networks 723 100 Church Street 724 Enfield, Middlesex 725 UK 727 EMail: Jonathan.Hardwick@metaswitch.com 729 Cheng Li 730 Huawei Technologies 731 Huawei Campus, No. 156 Beiqing Rd. 732 Beijing 100095 733 China 735 EMail: c.l@huawei.com