idnits 2.17.1 draft-ietf-pce-association-policy-14.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 08, 2020) is 1234 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 11, 2021 Ciena 6 J. Tantsura 7 Apstra, Inc. 8 J. Hardwick 9 Metaswitch Networks 10 M. Negi 11 RtBrick Inc 12 C. Li 13 Huawei Technologies 14 December 08, 2020 16 Path Computation Element (PCE) Communication Protocol (PCEP) extension 17 for associating Policies and Label Switched Paths (LSPs) 18 draft-ietf-pce-association-policy-14 20 Abstract 22 This document introduces a simple mechanism to associate policies to 23 a group of Label Switched Paths (LSPs) via an extension to the Path 24 Computation Element (PCE) Communication Protocol (PCEP). The 25 extension allows a PCEP speaker to advertise to a PCEP peer that a 26 particular LSP belongs to a particular Policy Association Group. 28 Status of This Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at https://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on June 11, 2021. 45 Copyright Notice 47 Copyright (c) 2020 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (https://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 63 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 64 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 65 3. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 4 66 3.1. Policy based Constraints . . . . . . . . . . . . . . . . 5 67 4. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 6 68 5. Policy Association Group . . . . . . . . . . . . . . . . . . 7 69 5.1. Policy Parameters TLV . . . . . . . . . . . . . . . . . . 7 70 6. Implementation Status . . . . . . . . . . . . . . . . . . . . 9 71 6.1. Cisco's Implementation . . . . . . . . . . . . . . . . . 9 72 7. Security Considerations . . . . . . . . . . . . . . . . . . . 9 73 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 74 8.1. Association object Type Indicators . . . . . . . . . . . 10 75 8.2. PCEP TLV Type Indicators . . . . . . . . . . . . . . . . 10 76 8.3. PCEP Errors . . . . . . . . . . . . . . . . . . . . . . . 10 77 9. Manageability Considerations . . . . . . . . . . . . . . . . 11 78 9.1. Control of Function and Policy . . . . . . . . . . . . . 11 79 9.2. Information and Data Models . . . . . . . . . . . . . . . 11 80 9.3. Liveness Detection and Monitoring . . . . . . . . . . . . 11 81 9.4. Verify Correct Operations . . . . . . . . . . . . . . . . 11 82 9.5. Requirements on Other Protocols . . . . . . . . . . . . . 11 83 9.6. Impact on Network Operations . . . . . . . . . . . . . . 11 84 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12 85 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 86 11.1. Normative References . . . . . . . . . . . . . . . . . . 12 87 11.2. Informative References . . . . . . . . . . . . . . . . . 12 88 Appendix A. Example of Policy Parameters . . . . . . . . . . . . 15 89 Appendix B. Contributor Addresses . . . . . . . . . . . . . . . 15 90 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 92 1. Introduction 94 [RFC5440] describes the Path Computation Element Communication 95 Protocol (PCEP) which enables the communication between a Path 96 Computation Client (PCC) and a Path Control Element (PCE), or between 97 two PCEs based on the PCE architecture [RFC4655]. [RFC5394] provides 98 additional details on policy within the PCE architecture and also 99 provides context for the support of PCE Policy. 101 PCEP Extensions for Stateful PCE Model [RFC8231] describes a set of 102 extensions to PCEP to enable active control of Multiprotocol Label 103 Switching Traffic Engineering (MPLS-TE) and Generalized MPLS (GMPLS) 104 tunnels. [RFC8281] describes the set-up and teardown of PCE- 105 initiated LSPs under the active stateful PCE model, without the need 106 for local configuration on the PCC, thus allowing for a dynamic 107 network. Currently, the LSPs can either be signaled via Resource 108 Reservation Protocol Traffic Engineering (RSVP-TE) or can be segment 109 routed as specified in [RFC8664]. 111 [RFC8697] introduces a generic mechanism to create a grouping of LSPs 112 which can then be used to define associations between a set of LSPs 113 and a set of attributes (such as configuration parameters or 114 behaviors) and is equally applicable to stateful PCE (active and 115 passive modes) and stateless PCE. 117 This document specifies a PCEP extension to associate one or more 118 LSPs with policies using the generic association mechanism. 120 A PCEP speaker may want to influence the PCEP peer with respect to 121 path selection and other policies. This document describes a PCEP 122 extension to associate policies by creating Policy Association Group 123 (PAG) and encoding this association in PCEP messages. The 124 specification is applicable to both stateful and stateless PCEP 125 sessions. 127 Note that the actual policy definition and the associated parameters 128 are out of scope of this document. 130 1.1. Requirements Language 132 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 133 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 134 "OPTIONAL" in this document are to be interpreted as described in BCP 135 14 [RFC2119] [RFC8174] when, and only when, they appear in all 136 capitals, as shown here. 138 2. Terminology 140 The following terminology is used in this document. 142 Association parameters: As described in [RFC8697], the combination 143 of the mandatory fields Association type, Association ID and 144 Association Source in the ASSOCIATION object uniquely identify the 145 association group. If the optional TLVs - Global Association 146 Source or Extended Association ID are included, then they are 147 included in combination with mandatory fields to uniquely identify 148 the association group. 150 Association information: As described in [RFC8697], the ASSOCIATION 151 object could include other optional TLVs based on the association 152 types, that provide 'information' related to the association. 154 LSR: Label Switch Router. 156 MPLS: Multiprotocol Label Switching. 158 PAG: Policy Association Group. 160 PAT: Policy Association Type. 162 PCC: Path Computation Client; any client application requesting a 163 path computation to be performed by a Path Computation Element. 165 PCE: Path Computation Element; an entity (component, application, or 166 network node) that is capable of computing a network path or route 167 based on a network graph and applying computational constraints. 169 PCEP: Path Computation Element Communication Protocol. 171 3. Motivation 173 Paths computed using PCE can be subjected to various policies at both 174 the PCE and the PCC. For example, in a centralized traffic 175 engineering (TE) scenario, network operators may instantiate LSPs and 176 specify policies for traffic accounting, path monitoring, telemetry, 177 etc., for some LSPs via the Stateful PCE. Similarly, a PCC could 178 request a user-specific or service-specific policy to be applied at 179 the PCE, such as constraints relaxation policy to meet optimal QoS 180 and resiliency. 182 PCEP speaker can use the generic mechanism as per [RFC8697] to 183 associate a set of LSPs with a policy, without the need to know the 184 details of such a policy, which simplifies network operations, avoids 185 frequent software upgrades, as well as provides an ability to 186 introduce new policies faster. 188 PAG Y 189 {Service-Specific Policy 190 for constraint 191 Monitor LSP relaxation} 192 | | 193 | PAG X PCReq/PCRpt | 194 V {Monitor LSP} {PAG Y} V 195 +-----+ ----------------> +-----+ 196 _ _ _ _ _ _| PCE | | | PCE | 197 | +-----+ | ----------> +-----+ 198 | PCInitiate/PCUpd | | PCReq/PCRpt 199 |{PAG X} | | {PAG Y} 200 | | | 201 | .-----. | | .-----. 202 | ( ) | +----+ ( ) 203 | .--( )--. | |PCC1|--.--( )--. 204 V ( ) | +----+ ( ) 205 +---+ ( ) | ( ) 206 |PCC|----( (G)MPLS network ) +----+ ( (G)MPLS network ) 207 +---+ ( ) |PCC2|------( ) 208 PAG X ( ) +----+ ( ) 209 {Monitor '--( )--' '--( )--' 210 LSP} ( ) ( ) 211 '-----' '-----' 213 Case 1: Policy requested by PCE Case 2: Policy requested by 214 and enforced by PCC PCC and enforced by 215 PCE 217 Figure 1: Sample use-cases for carrying policies over PCEP 219 3.1. Policy based Constraints 221 In the context of Policy-Enabled Path Computation Framework 222 [RFC5394], path computation policies may be applied at either a PCC 223 or a PCE or both. Consider a Label Switch Router (LSR) with a policy 224 enabled PCC, it receives a service request via signaling, including 225 over a Network-Network Interface (NNI) or User-Network Interface 226 (UNI) reference point, or receives a configuration request over a 227 management interface to establish a service. The PCC may also apply 228 user-specific or service-specific policies to decide how the path 229 selection process should be constrained, that is, which constraints, 230 diversities, optimization criterion, and constraint relaxation 231 strategies should be applied in order for the service LSP(s) to have 232 a likelihood to be successfully established and provide necessary QoS 233 and resilience against network failures. The user-specific or 234 service-specific policies applied to PCC and are then passed to the 235 PCE along with the Path computation request, in the form of 236 constraints [RFC5394]. 238 PCEP speaker can use the generic mechanism as per [RFC8697] to 239 associate a set of LSPs with policy and its resulting path 240 computation constraints. This would simplify the path computation 241 message exchanges in PCEP. 243 4. Overview 245 As per [RFC8697], LSPs are associated with other LSPs with which they 246 interact by adding them to a common association group. Grouping can 247 also be used to define the association between LSPs and policies 248 associated to them. As described in [RFC8697], the association group 249 is uniquely identified by the combination of the following fields in 250 the ASSOCIATION object: Association Type, Association ID, Association 251 Source, and (if present) Global Association Source or Extended 252 Association ID. This document defines a new Association type, called 253 "Policy Association", of value 3 (early-allocated by IANA), based on 254 the generic ASSOCIATION object. This new Association type is also 255 called "PAT", for "Policy Association Type". 257 [RFC8697] specifies the mechanism for the capability advertisement of 258 the Association types supported by a PCEP speaker by defining a 259 ASSOC-Type-List TLV to be carried within an OPEN object. This 260 capability exchange for the PAT MUST be done before using the policy 261 association. Thus the PCEP speaker MUST include the PAT in the 262 ASSOC-Type-List TLV and MUST receive the same from the PCEP peer 263 before using the Policy Association Group (PAG) in PCEP messages. 265 This Association type is operator-configured [RFC8697] association in 266 nature and created by the operator manually on the PCEP peers. An 267 LSP belonging to this association is conveyed via PCEP messages to 268 the PCEP peer. Operator-configured Association Range MUST NOT be set 269 for this association-type, and MUST be ignored, so that the full 270 range of association identifier can be utilized. 272 A PAG can have one or more LSPs. The association parameters 273 including association identifier, Association type (PAT), as well as 274 the association source IP address is manually configured by the 275 operator and is used to identify the PAG as described in [RFC8697]. 276 The Global Association Source and Extended Association ID MAY also be 277 included. 279 As per the processing rules specified in section 6.4 of [RFC8697], if 280 a PCEP speaker does not support this Policy Association type, it 281 would return a PCErr message with Error-Type 26 "Association Error" 282 and Error-Value 1 "Association type is not supported". Since the PAG 283 is opaque in nature, the PAG and the policy MUST be configured on the 284 PCEP peers as per the operator-configured association procedures. 285 All further processing is as per section 6.4 of [RFC8697]. If a PCE 286 speaker receives PAG in a PCEP message, and the policy association 287 information is not configured, it MUST return a PCErr message with 288 Error-Type 26 "Association Error" and Error-Value 4 "Association 289 unknown". 291 Associating a particular LSP to multiple policy groups is authorized 292 from a protocol perspective, however, there is no assurance that the 293 PCEP speaker will be able to apply multiple policies. If a PCEP 294 speaker does not support handling of multiple policies for an LSP, it 295 MUST NOT add the LSP into the association group and MUST return a 296 PCErr with Error- Type 26 (Association Error) and Error-value 7 297 (Cannot join the association group). 299 5. Policy Association Group 301 Association groups and their memberships are defined using the 302 ASSOCIATION object defined in [RFC8697]. Two object types for IPv4 303 and IPv6 are defined. The ASSOCIATION object includes "Association 304 type" indicating the type of the association group. This document 305 add a new Association type (PAT). 307 PAG may carry optional TLVs including but not limited to - 309 o POLICY-PARAMETERS-TLV: Used to communicate opaque information 310 useful to apply the policy, described in Section 5.1. 312 o VENDOR-INFORMATION-TLV: Used to communicate arbitrary vendor 313 specific behavioral information, described in [RFC7470]. 315 5.1. Policy Parameters TLV 317 The POLICY-PARAMETERS-TLV is an optional TLV that can be carried in 318 ASSOCIATION object (for PAT) to carry opaque information needed to 319 apply the policy at the PCEP peer. In some cases to apply a PCE 320 policy successfully, it is required to also associate some policy 321 parameters that need to be evaluated. This TLV is used to carry 322 those policy parameters. The TLV could include one or more policy 323 related parameters. The encoding format and the order MUST be known 324 to the PCEP peers, this could be done during the configuration of the 325 policy (and its association parameters) for the PAG. The TLV format 326 is as per the format of the PCEP TLVs, as defined in [RFC5440], and 327 shown in Figure 2. Only one POLICY-PARAMETERS-TLV can be carried and 328 only the first occurrence is processed and any others MUST be 329 ignored. 331 0 1 2 3 332 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 333 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 334 | Type=48 | Length | 335 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 336 | | 337 // Policy Parameters // 338 | | 339 +---------------------------------------------------------------+ 341 Figure 2: The POLICY-PARAMETERS-TLV format 343 The type of the POLICY-PARAMETERS-TLV is 48 (early-allocated by IANA) 344 and it has a variable length. The Value field is variable and padded 345 to a 4-byte alignment; padding is not included in the Length field. 346 The PCEP peer implementation needs to be aware of the encoding 347 format, order, and meaning of the 'Policy Parameters' well in advance 348 based on the policy. Note that from the protocol point of view this 349 data is opaque and can be used to carry parameters in any format 350 understood by the PCEP peers and associated to the policy. The exact 351 use of this TLV is beyond the scope of this document. Examples are 352 included for illustration purposes in Appendix A. 354 If the PCEP peer is unaware of the policy parameters associated with 355 the policy and it receives the POLICY-PARAMETERS-TLV, it MUST reject 356 the PCEP message and send a PCErr message with Error-Type 26 357 "Association Error" and Error-Value TBD3 "Not expecting policy 358 parameters". Further, if one or more parameters in the POLICY- 359 PARAMETERS-TLV received by the PCEP speaker are considered as 360 unacceptable in the context of the associated policy (e.g. out of 361 range value, badly encoded value...), the PCEP speaker MUST reject 362 the PCEP message and send a PCErr message with Error-Type 26 363 "Association Error" and Error-Value TBD4 "Unacceptable policy 364 parameters". 366 Note that, the vendor-specific behavioral information is encoded in 367 VENDOR-INFORMATION-TLV which can be used along with this TLV. 369 6. Implementation Status 371 [Note to the RFC Editor - remove this section before publication, as 372 well as remove the reference to RFC 7942.] 374 This section records the status of known implementations of the 375 protocol defined by this specification at the time of posting of this 376 Internet-Draft, and is based on a proposal described in [RFC7942]. 377 The description of implementations in this section is intended to 378 assist the IETF in its decision processes in progressing drafts to 379 RFCs. Please note that the listing of any individual implementation 380 here does not imply endorsement by the IETF. Furthermore, no effort 381 has been spent to verify the information presented here that was 382 supplied by IETF contributors. This is not intended as, and must not 383 be construed to be, a catalog of available implementations or their 384 features. Readers are advised to note that other implementations may 385 exist. 387 According to [RFC7942], "this will allow reviewers and working groups 388 to assign due consideration to documents that have the benefit of 389 running code, which may serve as evidence of valuable experimentation 390 and feedback that have made the implemented protocols more mature. 391 It is up to the individual working groups to use this information as 392 they see fit". 394 6.1. Cisco's Implementation 396 o Organization: Cisco Systems, Inc. 398 o Implementation: IOS-XR PCE and PCC. 400 o Description: The PCEP extension specified in this document is used 401 to convey traffic steering policies. 403 o Maturity Level: In shipping product. 405 o Coverage: Partial. 407 o Contact: mkoldych@cisco.com 409 7. Security Considerations 411 This document defines one new type for association, which do not add 412 any new security concerns beyond those discussed in [RFC5440], 413 [RFC8231] and [RFC8697] in itself. 415 Extra care needs to be taken by the implementation with respect to 416 POLICY-PARAMETERS-TLV while decoding, verifying, and applying these 417 policy variables. This TLV parsing could be exploited by an 418 attacker. 420 Some deployments may find policy associations and their implications 421 as extra sensitive and thus securing the PCEP session using Transport 422 Layer Security (TLS) [RFC8253], as per the recommendations and best 423 current practices in BCP 195 [RFC7525], is RECOMMENDED. 425 8. IANA Considerations 427 8.1. Association object Type Indicators 429 This document defines a new Association type. The sub-registry 430 "ASSOCIATION Type Field" of the "Path Computation Element Protocol 431 (PCEP) Numbers" registry was originally defined in [RFC8697]. IANA 432 is requested to confirm the early-allocated codepoint. 434 Value Name Reference 436 3 Policy Association [This.I-D] 438 8.2. PCEP TLV Type Indicators 440 The following TLV Type Indicator value is requested within the "PCEP 441 TLV Type Indicators" subregistry of the "Path Computation Element 442 Protocol (PCEP) Numbers" registry. IANA is requested to confirm the 443 early-allocated codepoint. 445 Value Description Reference 447 48 POLICY-PARAMETERS-TLV [This.I-D] 449 8.3. PCEP Errors 451 This document defines new Error-Values for Error-type 26 "Association 452 Error" defined in [RFC8697]. IANA is requested to allocate new error 453 values within the "PCEP- ERROR Object Error Types and Values" 454 subregistry of the PCEP Numbers registry as follows: 456 Error-Type Meaning Error-value Reference 458 26 Association [RFC8697] 459 Error 460 TBD3: Not expecting [This.I-D] 461 policy parameters 463 TBD4: Unacceptable [This.I-D] 464 policy parameters 466 9. Manageability Considerations 468 9.1. Control of Function and Policy 470 An operator MUST be allowed to configure the policy associations at 471 PCEP peers and associate it with the LSPs. They MAY also allow 472 configuration to related policy parameters, in which case the 473 operator MUST also be allowed to set the encoding format and order to 474 parse the associated policy parameters TLV. 476 9.2. Information and Data Models 478 [RFC7420] describes the PCEP MIB, there are no new MIB Objects for 479 this document. 481 The PCEP YANG module is defined in [I-D.ietf-pce-pcep-yang]. This 482 module supports associations as defined in [RFC8697] and thus 483 supports the Policy Association groups. 485 An implementation SHOULD allow the operator to view the PAG 486 configured. Further implementation SHOULD allow to view associations 487 reported by each peer, and the current set of LSPs in the PAG. 489 9.3. Liveness Detection and Monitoring 491 Mechanisms defined in this document do not imply any new liveness 492 detection and monitoring requirements in addition to those already 493 listed in [RFC5440], [RFC8231], and [RFC8281]. 495 9.4. Verify Correct Operations 497 Mechanisms defined in this document do not imply any new operation 498 verification requirements in addition to those already listed in 499 [RFC5440], [RFC8231], and [RFC8281]. 501 9.5. Requirements on Other Protocols 503 Mechanisms defined in this document do not imply any new requirements 504 on other protocols. 506 9.6. Impact on Network Operations 508 Mechanisms defined in this document do not have any impact on network 509 operations in addition to those already listed in [RFC5440], 510 [RFC8231], and [RFC8281]. 512 10. Acknowledgments 514 A special thanks to the authors of [RFC8697], this document borrowed 515 some of the text from it. The authors would like to thank Aijun 516 Wang, Peng Shuping, and Gyan Mishra for their useful comments. 518 Thanks to Hari for shepherding this document. Thanks to Deborah 519 Brungard for being the responsible AD for this document. 521 Thanks to Nic Leymann for RTGDIR review. 523 11. References 525 11.1. Normative References 527 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 528 Requirement Levels", BCP 14, RFC 2119, 529 DOI 10.17487/RFC2119, March 1997, 530 . 532 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 533 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 534 DOI 10.17487/RFC5440, March 2009, 535 . 537 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 538 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 539 May 2017, . 541 [RFC8231] Crabbe, E., Minei, I., Medved, J., and R. Varga, "Path 542 Computation Element Communication Protocol (PCEP) 543 Extensions for Stateful PCE", RFC 8231, 544 DOI 10.17487/RFC8231, September 2017, 545 . 547 [RFC8697] Minei, I., Crabbe, E., Sivabalan, S., Ananthakrishnan, H., 548 Dhody, D., and Y. Tanaka, "Path Computation Element 549 Communication Protocol (PCEP) Extensions for Establishing 550 Relationships between Sets of Label Switched Paths 551 (LSPs)", RFC 8697, DOI 10.17487/RFC8697, January 2020, 552 . 554 11.2. Informative References 556 [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation 557 Element (PCE)-Based Architecture", RFC 4655, 558 DOI 10.17487/RFC4655, August 2006, 559 . 561 [RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, 562 "Network Time Protocol Version 4: Protocol and Algorithms 563 Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010, 564 . 566 [RFC5394] Bryskin, I., Papadimitriou, D., Berger, L., and J. Ash, 567 "Policy-Enabled Path Computation Framework", RFC 5394, 568 DOI 10.17487/RFC5394, December 2008, 569 . 571 [RFC7420] Koushik, A., Stephan, E., Zhao, Q., King, D., and J. 572 Hardwick, "Path Computation Element Communication Protocol 573 (PCEP) Management Information Base (MIB) Module", 574 RFC 7420, DOI 10.17487/RFC7420, December 2014, 575 . 577 [RFC7470] Zhang, F. and A. Farrel, "Conveying Vendor-Specific 578 Constraints in the Path Computation Element Communication 579 Protocol", RFC 7470, DOI 10.17487/RFC7470, March 2015, 580 . 582 [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, 583 "Recommendations for Secure Use of Transport Layer 584 Security (TLS) and Datagram Transport Layer Security 585 (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 586 2015, . 588 [RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running 589 Code: The Implementation Status Section", BCP 205, 590 RFC 7942, DOI 10.17487/RFC7942, July 2016, 591 . 593 [RFC8253] Lopez, D., Gonzalez de Dios, O., Wu, Q., and D. Dhody, 594 "PCEPS: Usage of TLS to Provide a Secure Transport for the 595 Path Computation Element Communication Protocol (PCEP)", 596 RFC 8253, DOI 10.17487/RFC8253, October 2017, 597 . 599 [RFC8281] Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "Path 600 Computation Element Communication Protocol (PCEP) 601 Extensions for PCE-Initiated LSP Setup in a Stateful PCE 602 Model", RFC 8281, DOI 10.17487/RFC8281, December 2017, 603 . 605 [RFC8664] Sivabalan, S., Filsfils, C., Tantsura, J., Henderickx, W., 606 and J. Hardwick, "Path Computation Element Communication 607 Protocol (PCEP) Extensions for Segment Routing", RFC 8664, 608 DOI 10.17487/RFC8664, December 2019, 609 . 611 [I-D.ietf-pce-pcep-yang] 612 Dhody, D., Hardwick, J., Beeram, V., and J. Tantsura, "A 613 YANG Data Model for Path Computation Element 614 Communications Protocol (PCEP)", draft-ietf-pce-pcep- 615 yang-15 (work in progress), October 2020. 617 Appendix A. Example of Policy Parameters 619 An example could be a monitoring and telemetry policy P1 that is 620 dependent on a profile (GOLD/SILVER/BRONZE) as set by the operator. 621 The PCEP peers need to be aware of the policy P1 (and its associated 622 characteristics) in advance as well the fact that the policy 623 parameter will encode the profile of type string in the POLICY- 624 PARAMETERS-TLV. As an example, LSP1 could encode the PAG with the 625 POLICY-PARAMETERS-TLV with a string "GOLD". 627 Another example where the path computation at PCE could be dependent 628 on when the LSP was configured at the PCC. For such a policy P2, the 629 time-stamp can be encoded in the POLICY-PARAMETERS-TLV and the exact 630 encoding could be the 64-bit timestamp format as defined in 631 [RFC5905]. 633 While the above example has a single field in the POLICY-PARAMETERS- 634 TLV, it is possible to include multiple fields, but the exact order, 635 encoding format and meanings need to be known in advance at the PCEP 636 peers. 638 Appendix B. Contributor Addresses 639 Dhruv Dhody 640 Huawei Technologies 641 Divyashree Techno Park, Whitefield 642 Bangalore, Karnataka 560066 643 India 645 EMail: dhruv.ietf@gmail.com 647 Qin Wu 648 Huawei Technologies 649 101 Software Avenue, Yuhua District 650 Nanjing, Jiangsu 210012 651 China 653 EMail: sunseawq@huawei.com 655 Xian Zhang 656 Huawei Technologies 657 Bantian, Longgang District 658 Shenzhen 518129 659 P.R.China 661 EMail: zhang.xian@huawei.com 663 Udayasree Palle 665 EMail: udayasreereddy@gmail.com 667 Mike Koldychev 668 Cisco Systems, Inc. 669 Canada 671 EMail: mkoldych@cisco.com 673 Authors' Addresses 675 Stephane Litkowski 676 Cisco Systems, Inc. 677 11 Rue Camille Desmoulins 678 Issy-les-Moulineaux 92130 679 France 681 EMail: slitkows@cisco.com 682 Siva Sivabalan 683 Ciena 684 385 Terry Fox Drive 685 Kanata, Ontario K2K 0L1 686 Canada 688 EMail: msiva282@gmail.com 690 Jeff Tantsura 691 Apstra, Inc. 693 EMail: jefftant.ietf@gmail.com 695 Jonathan Hardwick 696 Metaswitch Networks 697 100 Church Street 698 Enfield, Middlesex 699 UK 701 EMail: Jonathan.Hardwick@metaswitch.com 703 Mahendra Singh Negi 704 RtBrick Inc 705 N-17L, 18th Cross Rd, HSR Layout 706 Bangalore, Karnataka 560102 707 India 709 EMail: mahend.ietf@gmail.com 711 Cheng Li 712 Huawei Technologies 713 Huawei Campus, No. 156 Beiqing Rd. 714 Beijing 100095 715 China 717 EMail: c.l@huawei.com