idnits 2.17.1 draft-ietf-pce-association-policy-11.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 (June 22, 2020) is 1405 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-13 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: December 24, 2020 Ciena 6 J. Tantsura 7 Apstra, Inc. 8 J. Hardwick 9 Metaswitch Networks 10 M. Negi 11 RtBrick India 12 C. Li 13 Huawei Technologies 14 June 22, 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-11 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). 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 December 24, 2020. 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 9. Manageability Considerations . . . . . . . . . . . . . . . . 10 75 9.1. Control of Function and Policy . . . . . . . . . . . . . 10 76 9.2. Information and Data Models . . . . . . . . . . . . . . . 10 77 9.3. Liveness Detection and Monitoring . . . . . . . . . . . . 11 78 9.4. Verify Correct Operations . . . . . . . . . . . . . . . . 11 79 9.5. Requirements on Other Protocols . . . . . . . . . . . . . 11 80 9.6. Impact on Network Operations . . . . . . . . . . . . . . 11 81 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11 82 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 83 11.1. Normative References . . . . . . . . . . . . . . . . . . 11 84 11.2. Informative References . . . . . . . . . . . . . . . . . 12 85 Appendix A. Contributor Addresses . . . . . . . . . . . . . . . 14 86 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 88 1. Introduction 90 [RFC5440] describes the Path Computation Element communication 91 Protocol (PCEP) which enables the communication between a Path 92 Computation Client (PCC) and a Path Control Element (PCE), or between 93 two PCEs based on the PCE architecture [RFC4655]. [RFC5394] provides 94 additional details on policy within the PCE architecture and also 95 provides context for the support of PCE Policy. 97 PCEP Extensions for Stateful PCE Model [RFC8231] describes a set of 98 extensions to PCEP to enable active control of Multiprotocol Label 99 Switching Traffic Engineering (MPLS-TE) and Generalized MPLS (GMPLS) 100 tunnels. [RFC8281] describes the set-up and teardown of PCE- 101 initiated LSPs under the active stateful PCE model, without the need 102 for local configuration on the PCC, thus allowing for a dynamic 103 network. Currently, the LSPs can either be signaled via Resource 104 Reservation Protocol Traffic Engineering (RSVP-TE) or can be segment 105 routed as specified in [RFC8664]. 107 [RFC8697] introduces a generic mechanism to create a grouping of LSPs 108 which can then be used to define associations between a set of LSPs 109 and a set of attributes (such as configuration parameters or 110 behaviors) and is equally applicable to stateful PCE (active and 111 passive modes) and stateless PCE. 113 This document specifies a PCEP extension to associate one or more 114 LSPs with policies using the generic association mechanism. 116 A PCEP speaker may want to influence the PCEP peer with respect to 117 path selection and other policies. This document describes a PCEP 118 extension to associate policies by creating Policy Association Group 119 (PAG) and encoding this association in PCEP messages. The 120 specification is applicable to both stateful and stateless PCEP 121 sessions. 123 1.1. Requirements Language 125 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 126 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 127 "OPTIONAL" in this document are to be interpreted as described in BCP 128 14 [RFC2119] [RFC8174] when, and only when, they appear in all 129 capitals, as shown here. 131 2. Terminology 133 The following terminology is used in this document. 135 Association parameters: As described in [RFC8697], the combination 136 of the mandatory fields Association type, Association ID and 137 Association Source in the ASSOCIATION object uniquely identify the 138 association group. If the optional TLVs - Global Association 139 Source or Extended Association ID are included, then they are 140 included in combination with mandatory fields to uniquely identify 141 the association group. 143 Association information: As described in [RFC8697], the ASSOCIATION 144 object could include other optional TLVs based on the association 145 types, that provides 'information' related to the association. 147 LSR: Label Switch Router. 149 MPLS: Multiprotocol Label Switching. 151 PAG: Policy Association Group. 153 PAT: Policy Association Type. 155 PCC: Path Computation Client. Any client application requesting a 156 path computation to be performed by a Path Computation Element. 158 PCE: Path Computation Element. An entity (component, application, 159 or network node) that is capable of computing a network path or 160 route based on a network graph and applying computational 161 constraints. 163 PCEP: Path Computation Element Communication Protocol. 165 3. Motivation 167 Paths computed using PCE can be subjected to various policies on both 168 PCE and PCC. For example, in a centralized traffic engineering 169 scenario, network operators may instantiate LSPs and specifies 170 policies for traffic steering, path monitoring, etc., for some LSPs 171 via the Stateful PCE. Similarly, a PCC could request a user- or 172 service-specific policy to be applied at the PCE, such as constraints 173 relaxation to meet optimal QoS and resiliency. 175 PCEP speaker can use the generic mechanism as per [RFC8697] to 176 associate a set of LSPs with a policy, without the need to know the 177 details of such a policy, which simplifies network operations, avoids 178 frequent software upgrades, as well as provides an ability to 179 introduce new policy faster. 181 PAG Y 182 {Service-Specific Policy 183 for constraint 184 Initiate & Monitor LSP relaxation} 185 | | 186 | PAG X PCReq/PCRpt | 187 V {Monitor LSP} {PAG Y} V 188 +-----+ ----------------> +-----+ 189 _ _ _ _ _ _| PCE | | | PCE | 190 | +-----+ | ----------> +-----+ 191 | PCInitiate | | PCReq/PCRpt 192 |{PAG X} | | {PAG Y} 193 | | | 194 | .-----. | | .-----. 195 | ( ) | +----+ ( ) 196 | .--( )--. | |PCC1|--.--( )--. 197 V ( ) | +----+ ( ) 198 +---+ ( ) | ( ) 199 |PCC|----( (G)MPLS network ) +----+ ( (G)MPLS network ) 200 +---+ ( ) |PCC2|------( ) 201 PAG X ( ) +----+ ( ) 202 {Monitor '--( )--' '--( )--' 203 LSP} ( ) ( ) 204 '-----' '-----' 206 Case 1: Policy requested by PCE Case 2: Policy requested by 207 and enforced by PCC PCC and enforced by 208 PCE 210 Figure 1: Sample use-cases for carrying policies over PCEP session 212 3.1. Policy based Constraints 214 In the context of policy-enabled path computation [RFC5394], path 215 computation policies may be applied at both a PCC and a PCE. 216 Consider an Label Switch Router (LSR) with a policy enabled PCC, it 217 receives a service request via signaling, including over a Network- 218 Network Interface (NNI) or User Network Interface (UNI) reference 219 point, or receives a configuration request over a management 220 interface to establish a service. The PCC may also apply user- or 221 service-specific policies to decide how the path selection process 222 should be constrained, that is, which constraints, diversities, 223 optimization criterion, and constraint relaxation strategies should 224 be applied in order for the service LSP(s) to have a likelihood to be 225 successfully established and provide necessary QoS and resilience 226 against network failures. The user- or service-specific policies 227 applied to PCC and are then passed to the PCE along with the Path 228 computation request, in the form of constraints [RFC5394]. 230 PCEP speaker can use the generic mechanism as per [RFC8697] to 231 associate a set of LSPs with policy and its resulting path 232 computation constraints. This would simplify the path computation 233 message exchanges in PCEP. 235 4. Overview 237 As per [RFC8697], LSPs are associated with other LSPs with which they 238 interact by adding them to a common association group. Grouping can 239 also be used to define association between LSPs and policies 240 associated to them. One new Association type is defined in this 241 document, based on the generic Association object - 243 o Association type = TBD1 ("Policy Association Type (PAT)" ) for 244 Policy Association Group (PAG). 246 [RFC8697] specify the mechanism for the capability advertisement of 247 the Association types supported by a PCEP speaker by defining a 248 ASSOC-Type-List TLV to be carried within an OPEN object. This 249 capability exchange for the association type described in this 250 document (i.e. PAT) MUST be done before using the policy 251 association. Thus the PCEP speaker MUST include the PAT (TBD1) in 252 the ASSOC-Type-List TLV before using the PAG in the PCEP messages. 254 This Association type is operator-configured association in nature 255 and created by the operator manually on the PCEP peers. An LSP 256 belonging to this association is conveyed via PCEP messages to the 257 PCEP peer. Operator-configured Association Range need not be set for 258 this association-type, and MUST be ignored, so that the full range of 259 association identifier can be utilized. 261 A PAG can have one or more LSPs and its associated policy. The 262 association parameters including association identifier, Association 263 type (Policy), as well as the association source IP address is 264 manually configured by the operator and is used to identify the PAG 265 as described in [RFC8697]. The Global Association Source and 266 Extended Association ID MAY also be included. 268 As per the processing rules specified in section 6.4 of [RFC8697], if 269 a PCEP speaker does not support this Policy Association type, it 270 would return a PCErr message with Error-Type 26 "Association Error" 271 and Error-Value 1 "Association type is not supported". Since the PAG 272 is opaque in nature, the PAG and the policy MUST be configured on the 273 PCEP peers as per the operator-configured association procedures. 274 All further processing is as per section 6.4 of [RFC8697]. If a PCE 275 speaker receives PAG in a PCEP message, and the policy association 276 information is not configured, it MUST return a PCErr message with 277 Error-Type 26 "Association Error" and Error- Value 4 "Association 278 unknown". If some of the association information [RFC8697] (the TLVs 279 defined in this document) received from the peer does not match the 280 local configured values, the PCEP speaker MUST reject the PCEP 281 message and send a PCErr message with Error-Type 26 "Association 282 Error" and Error-Value 5 "Operator-configured association information 283 mismatch". 285 Associating a particular LSP to multiple policy groups is authorized 286 from a protocol perspective, however there is no assurance that the 287 PCE will be able to apply multiple policies. 289 5. Policy Association Group 291 Association groups and their memberships are defined using the 292 ASSOCIATION object defined in [RFC8697]. Two object types for IPv4 293 and IPv6 are defined. The ASSOCIATION object includes "Association 294 type" indicating the type of the association group. This document 295 add a new Association type - 297 Association type = TBD1 ("Policy Association type") for PAG. 299 PAG may carry optional TLVs including but not limited to - 301 o POLICY-PARAMETERS-TLV: Used to communicate opaque information 302 useful to apply the policy, described in Section 5.1. 304 o VENDOR-INFORMATION-TLV: Used to communicate arbitrary vendor 305 specific behavioural information, described in [RFC7470]. 307 5.1. Policy Parameters TLV 309 The POLICY-PARAMETERS-TLV is an optional TLV that can be carried in 310 ASSOCIATION object (for PAT) to carry opaque information needed to 311 apply the policy at the PCEP peer. In some cases to apply a PCE 312 policy successfully, it is required to also associate some policy 313 parameters that needs to be evaluated, to successfully apply the said 314 policy. This TLV is used to carry those policy parameters. The TLV 315 could include one or more policy related parameter. The encoding 316 format and the order MUST be known to the PCEP peers, this could be 317 done during the configuration of the policy (and its association 318 parameters) for the PAG. The TLV format is as per the format of the 319 PCEP TLVs, as defined in [RFC5440], and shown in Figure 2. Only one 320 POLICY-PARAMETERS-TLV can be carried and only the first occurrence is 321 processed and any others MUST be ignored. 323 0 1 2 3 324 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 325 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 326 | Type=TBD2 | Length | 327 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 328 | | 329 // Policy Parameters // 330 | | 331 +---------------------------------------------------------------+ 333 Figure 2: The POLICY-PARAMETERS-TLV format 335 The type of the POLICY-PARAMETERS-TLV is TBD2 and it has a variable 336 length. The Value field is variable field padded to a 4-bytes 337 alignment; padding is not included in the Length field. The PCEP 338 peer implementation need to be aware of the encoding format, order, 339 and meaning of the 'Policy Parameters' well in advance based on the 340 policy. Note that from the protocol point of view this data is 341 opaque and can be used to carry parameters in any format understood 342 by the PCEP peers and associated to the policy. The exact use of 343 this TLV is beyond the scope of this document. 345 If the PCEP peer is unaware of the policy parameters associated with 346 the policy and it receives the POLICY-PARAMETERS-TLV, it MUST ignore 347 the TLV and SHOULD log this event. Further, if one or more 348 parameters received in the POLICY-PARAMETERS-TLV received by the PCEP 349 speaker are considered as unacceptable in the context of the 350 associated policy (e.g. out of range value, badly encoded value...), 351 the PCEP speaker MUST NOT apply the received policy and SHOULD log 352 this event. 354 Note that, the vendor specific behavioral information is encoded in 355 VENDOR-INFORMATION-TLV which can be used along with this TLV. 357 6. Implementation Status 359 [Note to the RFC Editor - remove this section before publication, as 360 well as remove the reference to RFC 7942.] 362 This section records the status of known implementations of the 363 protocol defined by this specification at the time of posting of this 364 Internet-Draft, and is based on a proposal described in [RFC7942]. 365 The description of implementations in this section is intended to 366 assist the IETF in its decision processes in progressing drafts to 367 RFCs. Please note that the listing of any individual implementation 368 here does not imply endorsement by the IETF. Furthermore, no effort 369 has been spent to verify the information presented here that was 370 supplied by IETF contributors. This is not intended as, and must not 371 be construed to be, a catalogue of available implementations or their 372 features. Readers are advised to note that other implementations may 373 exist. 375 According to [RFC7942], "this will allow reviewers and working groups 376 to assign due consideration to documents that have the benefit of 377 running code, which may serve as evidence of valuable experimentation 378 and feedback that have made the implemented protocols more mature. 379 It is up to the individual working groups to use this information as 380 they see fit". 382 6.1. Cisco's Implementation 384 o Organization: Cisco Systems, Inc. 386 o Implementation: IOS-XR PCE and PCC. 388 o Description: The PCEP extension specified in this document is used 389 to convey traffic steering policies. 391 o Maturity Level: In shipping product. 393 o Coverage: Partial. 395 o Contact: mkoldych@cisco.com 397 7. Security Considerations 399 This document defines one new type for association, which do not add 400 any new security concerns beyond those discussed in [RFC5440], 401 [RFC8231] and [RFC8697] in itself. 403 Extra care needs to be taken by the implementation with respect to 404 POLICY-PARAMETERS-TLV while decoding, verifying and applying these 405 policy variables. This TLV parsing could be exploited by an 406 attacker. 408 Some deployments may find policy associations and their implications 409 as extra sensitive and thus securing the PCEP session using Transport 410 Layer Security (TLS) [RFC8253], as per the recommendations and best 411 current practices in BCP 195 [RFC7525], is RECOMMENDED. 413 8. IANA Considerations 415 8.1. Association object Type Indicators 417 This document defines a new Association type. The sub-registry 418 "ASSOCIATION Type Field" of the "Path Computation Element Protocol 419 (PCEP) Numbers" registry was originally defined in [RFC8697]. IANA 420 is requested to confirm the early-allocated codepoints. 422 Value Name Reference 424 3 Policy Association [This.I-D] 426 8.2. PCEP TLV Type Indicators 428 The following TLV Type Indicator value is requested within the "PCEP 429 TLV Type Indicators" subregistry of the "Path Computation Element 430 Protocol (PCEP) Numbers" registry. IANA is requested to confirm the 431 early-allocated codepoints. 433 Value Description Reference 435 48 POLICY-PARAMETERS-TLV [This.I-D] 437 9. Manageability Considerations 439 9.1. Control of Function and Policy 441 An operator MUST be allowed to configure the policy associations at 442 PCEP peers and associate it with the LSPs. They MAY also allow 443 configuration to related policy parameters, in which case the an 444 operator MUST also be allowed to set the encoding format and order to 445 parse the associated policy parameters TLV. 447 9.2. Information and Data Models 449 [RFC7420] describes the PCEP MIB, there are no new MIB Objects for 450 this document. 452 The PCEP YANG module is defined in [I-D.ietf-pce-pcep-yang]. This 453 module supports associations as defined in [RFC8697] and thus support 454 the Policy Association groups. 456 An implementation SHOULD allow the operator to view the PAG 457 configured. Further implementation SHOULD allow to view associations 458 reported by each peer, and the current set of LSPs in the PAG. 460 9.3. Liveness Detection and Monitoring 462 Mechanisms defined in this document do not imply any new liveness 463 detection and monitoring requirements in addition to those already 464 listed in [RFC5440], [RFC8231], and [RFC8281]. 466 9.4. Verify Correct Operations 468 Mechanisms defined in this document do not imply any new operation 469 verification requirements in addition to those already listed in 470 [RFC5440], [RFC8231], and [RFC8281]. 472 9.5. Requirements on Other Protocols 474 Mechanisms defined in this document do not imply any new requirements 475 on other protocols. 477 9.6. Impact on Network Operations 479 Mechanisms defined in this document do not have any impact on network 480 operations in addition to those already listed in [RFC5440], 481 [RFC8231], and [RFC8281]. 483 10. Acknowledgments 485 A special thanks to author of [RFC8697], this document borrow some of 486 the text from it. 488 11. References 490 11.1. Normative References 492 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 493 Requirement Levels", BCP 14, RFC 2119, 494 DOI 10.17487/RFC2119, March 1997, 495 . 497 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 498 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 499 DOI 10.17487/RFC5440, March 2009, 500 . 502 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 503 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 504 May 2017, . 506 [RFC8231] Crabbe, E., Minei, I., Medved, J., and R. Varga, "Path 507 Computation Element Communication Protocol (PCEP) 508 Extensions for Stateful PCE", RFC 8231, 509 DOI 10.17487/RFC8231, September 2017, 510 . 512 [RFC8697] Minei, I., Crabbe, E., Sivabalan, S., Ananthakrishnan, H., 513 Dhody, D., and Y. Tanaka, "Path Computation Element 514 Communication Protocol (PCEP) Extensions for Establishing 515 Relationships between Sets of Label Switched Paths 516 (LSPs)", RFC 8697, DOI 10.17487/RFC8697, January 2020, 517 . 519 11.2. Informative References 521 [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation 522 Element (PCE)-Based Architecture", RFC 4655, 523 DOI 10.17487/RFC4655, August 2006, 524 . 526 [RFC5394] Bryskin, I., Papadimitriou, D., Berger, L., and J. Ash, 527 "Policy-Enabled Path Computation Framework", RFC 5394, 528 DOI 10.17487/RFC5394, December 2008, 529 . 531 [RFC7420] Koushik, A., Stephan, E., Zhao, Q., King, D., and J. 532 Hardwick, "Path Computation Element Communication Protocol 533 (PCEP) Management Information Base (MIB) Module", 534 RFC 7420, DOI 10.17487/RFC7420, December 2014, 535 . 537 [RFC7470] Zhang, F. and A. Farrel, "Conveying Vendor-Specific 538 Constraints in the Path Computation Element Communication 539 Protocol", RFC 7470, DOI 10.17487/RFC7470, March 2015, 540 . 542 [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, 543 "Recommendations for Secure Use of Transport Layer 544 Security (TLS) and Datagram Transport Layer Security 545 (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 546 2015, . 548 [RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running 549 Code: The Implementation Status Section", BCP 205, 550 RFC 7942, DOI 10.17487/RFC7942, July 2016, 551 . 553 [RFC8253] Lopez, D., Gonzalez de Dios, O., Wu, Q., and D. Dhody, 554 "PCEPS: Usage of TLS to Provide a Secure Transport for the 555 Path Computation Element Communication Protocol (PCEP)", 556 RFC 8253, DOI 10.17487/RFC8253, October 2017, 557 . 559 [RFC8281] Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "Path 560 Computation Element Communication Protocol (PCEP) 561 Extensions for PCE-Initiated LSP Setup in a Stateful PCE 562 Model", RFC 8281, DOI 10.17487/RFC8281, December 2017, 563 . 565 [RFC8664] Sivabalan, S., Filsfils, C., Tantsura, J., Henderickx, W., 566 and J. Hardwick, "Path Computation Element Communication 567 Protocol (PCEP) Extensions for Segment Routing", RFC 8664, 568 DOI 10.17487/RFC8664, December 2019, 569 . 571 [I-D.ietf-pce-pcep-yang] 572 Dhody, D., Hardwick, J., Beeram, V., and J. Tantsura, "A 573 YANG Data Model for Path Computation Element 574 Communications Protocol (PCEP)", draft-ietf-pce-pcep- 575 yang-13 (work in progress), October 2019. 577 Appendix A. Contributor Addresses 579 Dhruv Dhody 580 Huawei Technologies 581 Divyashree Techno Park, Whitefield 582 Bangalore, Karnataka 560066 583 India 585 EMail: dhruv.ietf@gmail.com 587 Qin Wu 588 Huawei Technologies 589 101 Software Avenue, Yuhua District 590 Nanjing, Jiangsu 210012 591 China 593 EMail: sunseawq@huawei.com 595 Xian Zhang 596 Huawei Technologies 597 Bantian, Longgang District 598 Shenzhen 518129 599 P.R.China 601 EMail: zhang.xian@huawei.com 603 Udayasree Palle 605 EMail: udayasreereddy@gmail.com 607 Mike Koldychev 608 Cisco Systems, Inc. 609 Canada 611 EMail: mkoldych@cisco.com 613 Authors' Addresses 615 Stephane Litkowski 616 Cisco Systems, Inc. 617 11 Rue Camille Desmoulins 618 Issy-les-Moulineaux 92130 619 France 621 EMail: slitkows@cisco.com 622 Siva Sivabalan 623 Ciena 624 385 Terry Fox Drive 625 Kanata, Ontario K2K 0L1 626 Canada 628 EMail: msiva282@gmail.com 630 Jeff Tantsura 631 Apstra, Inc. 633 EMail: jefftant.ietf@gmail.com 635 Jonathan Hardwick 636 Metaswitch Networks 637 100 Church Street 638 Enfield, Middlesex 639 UK 641 EMail: Jonathan.Hardwick@metaswitch.com 643 Mahendra Singh Negi 644 RtBrick India 645 N-17L, Floor-1, 18th Cross Rd, HSR Layout Sector-3 646 Bangalore, Karnataka 560102 647 India 649 EMail: mahend.ietf@gmail.com 651 Cheng Li 652 Huawei Technologies 653 Huawei Campus, No. 156 Beiqing Rd. 654 Beijing 100095 655 China 657 EMail: c.l@huawei.com