idnits 2.17.1 draft-ietf-pce-association-policy-10.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 21, 2020) is 1404 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 S. Sivabalan 4 Intended status: Standards Track Cisco Systems, Inc. 5 Expires: December 23, 2020 J. Tantsura 6 Apstra, Inc. 7 J. Hardwick 8 Metaswitch Networks 9 M. Negi 10 RtBrick India 11 C. Li 12 Huawei Technologies 13 June 21, 2020 15 Path Computation Element communication Protocol (PCEP) extension for 16 associating Policies and Label Switched Paths (LSPs) 17 draft-ietf-pce-association-policy-10 19 Abstract 21 This document introduces a simple mechanism to associate policies to 22 a group of Label Switched Paths (LSPs) via an extension to the Path 23 Computation Element (PCE) Communication Protocol (PCEP). 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at https://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on December 23, 2020. 42 Copyright Notice 44 Copyright (c) 2020 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (https://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 60 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 61 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 3. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 4 63 3.1. Policy based Constraints . . . . . . . . . . . . . . . . 5 64 4. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 6 65 5. Policy Association Group . . . . . . . . . . . . . . . . . . 7 66 5.1. Policy Parameters TLV . . . . . . . . . . . . . . . . . . 7 67 6. Implementation Status . . . . . . . . . . . . . . . . . . . . 8 68 6.1. Cisco's Implementation . . . . . . . . . . . . . . . . . 9 69 7. Security Considerations . . . . . . . . . . . . . . . . . . . 9 70 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 71 8.1. Association object Type Indicators . . . . . . . . . . . 10 72 8.2. PCEP TLV Type Indicators . . . . . . . . . . . . . . . . 10 73 9. Manageability Considerations . . . . . . . . . . . . . . . . 10 74 9.1. Control of Function and Policy . . . . . . . . . . . . . 10 75 9.2. Information and Data Models . . . . . . . . . . . . . . . 10 76 9.3. Liveness Detection and Monitoring . . . . . . . . . . . . 11 77 9.4. Verify Correct Operations . . . . . . . . . . . . . . . . 11 78 9.5. Requirements on Other Protocols . . . . . . . . . . . . . 11 79 9.6. Impact on Network Operations . . . . . . . . . . . . . . 11 80 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11 81 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 82 11.1. Normative References . . . . . . . . . . . . . . . . . . 11 83 11.2. Informative References . . . . . . . . . . . . . . . . . 12 84 Appendix A. Contributor Addresses . . . . . . . . . . . . . . . 14 85 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 87 1. Introduction 89 [RFC5440] describes the Path Computation Element communication 90 Protocol (PCEP) which enables the communication between a Path 91 Computation Client (PCC) and a Path Control Element (PCE), or between 92 two PCEs based on the PCE architecture [RFC4655]. [RFC5394] provides 93 additional details on policy within the PCE architecture and also 94 provides context for the support of PCE Policy. 96 PCEP Extensions for Stateful PCE Model [RFC8231] describes a set of 97 extensions to PCEP to enable active control of Multiprotocol Label 98 Switching Traffic Engineering (MPLS-TE) and Generalzied MPLS (GMPLS) 99 tunnels. [RFC8281] describes the set-up and teardown of PCE- 100 initiated LSPs under the active stateful PCE model, without the need 101 for local configuration on the PCC, thus allowing for a dynamic 102 network. Currently, the LSPs can either be signalled via Resource 103 Reservation Protocol Traffic Engineering (RSVP-TE) or can be segment 104 routed as specified in [RFC8664]. 106 [RFC8697] introduces a generic mechanism to create a grouping of LSPs 107 which can then be used to define associations between a set of LSPs 108 and a set of attributes (such as configuration parameters or 109 behaviours) and is equally applicable to stateful PCE (active and 110 passive modes) and stateless PCE. 112 This document specifies a PCEP extension to associate one or more 113 LSPs with policies using the generic association mechanism. 115 A PCEP speaker may want to influence the PCEP peer with respect to 116 path selection and other policies. This document describes a PCEP 117 extension to associate policies by creating Policy Association Group 118 (PAG) and encoding this association in PCEP messages. The 119 specification is applicable to both stateful and stateless PCEP 120 sessions. 122 1.1. Requirements Language 124 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 125 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 126 "OPTIONAL" in this document are to be interpreted as described in BCP 127 14 [RFC2119] [RFC8174] when, and only when, they appear in all 128 capitals, as shown here. 130 2. Terminology 132 The following terminology is used in this document. 134 Association parameters: As described in [RFC8697], the combination 135 of the mandatory fields Association type, Association ID and 136 Association Source in the ASSOCIATION object uniquely identify the 137 association group. If the optional TLVs - Global Association 138 Source or Extended Association ID are included, then they are 139 included in combination with mandatory fields to uniquely identify 140 the association group. 142 Association information: As described in [RFC8697], the ASSOCIATION 143 object could include other optional TLVs based on the association 144 types, that provides 'information' related to the association. 146 LSR: Label Switch Router. 148 MPLS: Multiprotocol Label Switching. 150 PAG: Policy Association Group. 152 PAT: Policy Association Type. 154 PCC: Path Computation Client. Any client application requesting a 155 path computation to be performed by a Path Computation Element. 157 PCE: Path Computation Element. An entity (component, application, 158 or network node) that is capable of computing a network path or 159 route based on a network graph and applying computational 160 constraints. 162 PCEP: Path Computation Element Communication Protocol. 164 3. Motivation 166 Paths computed using PCE can be subjected to various policies on both 167 PCE and PCC. For example, in a centralized traffic engineering 168 scenario, network operators may instantiate LSPs and specifies 169 policies for traffic steering, path monitoring, etc., for some LSPs 170 via the Stateful PCE. Similarly, a PCC could request a user- or 171 service-specific policy to be applied at the PCE, such as constraints 172 relaxation to meet optimal QoS and resiliency. 174 PCEP speaker can use the generic mechanism as per [RFC8697] to 175 associate a set of LSPs with a policy, without the need to know the 176 details of such a policy, which simplifies network operations, avoids 177 frequent software upgrades, as well as provides an ability to 178 introduce new policy faster. 180 PAG Y 181 {Service-Specific Policy 182 for constraint 183 Initiate & Monitor LSP relaxation} 184 | | 185 | PAG X PCReq/PCRpt | 186 V {Monitor LSP} {PAG Y} V 187 +-----+ ----------------> +-----+ 188 _ _ _ _ _ _| PCE | | | PCE | 189 | +-----+ | ----------> +-----+ 190 | PCInitiate | | PCReq/PCRpt 191 |{PAG X} | | {PAG Y} 192 | | | 193 | .-----. | | .-----. 194 | ( ) | +----+ ( ) 195 | .--( )--. | |PCC1|--.--( )--. 196 V ( ) | +----+ ( ) 197 +---+ ( ) | ( ) 198 |PCC|----( (G)MPLS network ) +----+ ( (G)MPLS network ) 199 +---+ ( ) |PCC2|------( ) 200 PAG X ( ) +----+ ( ) 201 {Monitor '--( )--' '--( )--' 202 LSP} ( ) ( ) 203 '-----' '-----' 205 Case 1: Policy requested by PCE Case 2: Policy requested by 206 and enforced by PCC PCC and enforced by 207 PCE 209 Figure 1: Sample use-cases for carrying policies over PCEP session 211 3.1. Policy based Constraints 213 In the context of policy-enabled path computation [RFC5394], path 214 computation policies may be applied at both a PCC and a PCE. 215 Consider an Label Switch Router (LSR) with a policy enabled PCC, it 216 receives a service request via signalling, including over a Network- 217 Network Interface (NNI) or User Network Interface (UNI) reference 218 point, or receives a configuration request over a management 219 interface to establish a service. The PCC may also apply user- or 220 service-specific policies to decide how the path selection process 221 should be constrained, that is, which constraints, diversities, 222 optimization criterion, and constraint relaxation strategies should 223 be applied in order for the service LSP(s) to have a likelihood to be 224 successfully established and provide necessary QoS and resilience 225 against network failures. The user- or service-specific policies 226 applied to PCC and are then passed to the PCE along with the Path 227 computation request, in the form of constraints [RFC5394]. 229 PCEP speaker can use the generic mechanism as per [RFC8697] to 230 associate a set of LSPs with policy and its resulting path 231 computation constraints. This would simplify the path computation 232 message exchanges in PCEP. 234 4. Overview 236 As per [RFC8697], LSPs are associated with other LSPs with which they 237 interact by adding them to a common association group. Grouping can 238 also be used to define association between LSPs and policies 239 associated to them. One new Association type is defined in this 240 document, based on the generic Association object - 242 o Association type = TBD1 ("Policy Association Type (PAT)" ) for 243 Policy Association Group (PAG). 245 [RFC8697] specify the mechanism for the capability advertisement of 246 the Association types supported by a PCEP speaker by defining a 247 ASSOC-Type-List TLV to be carried within an OPEN object. This 248 capability exchange for the association type described in this 249 document (i.e. PAT) MUST be done before using the policy 250 association. Thus the PCEP speaker MUST include the PAT (TBD1) in 251 the ASSOC-Type-List TLV before using the PAG in the PCEP messages. 253 This Association type is operator-configured association in nature 254 and created by the operator manually on the PCEP peers. An LSP 255 belonging to this association is conveyed via PCEP messages to the 256 PCEP peer. Operator-configured Association Range need not be set for 257 this association-type, and MUST be ignored, so that the full range of 258 association identifier can be utilized. 260 A PAG can have one or more LSPs and its associated policy. The 261 association parameters including association identifier, Association 262 type (Policy), as well as the association source IP address is 263 manually configured by the operator and is used to identify the PAG 264 as described in [RFC8697]. The Global Association Source and 265 Extended Association ID MAY also be included. 267 As per the processing rules specified in section 6.4 of [RFC8697], if 268 a PCEP speaker does not support this Policy Association type, it 269 would return a PCErr message with Error-Type 26 "Association Error" 270 and Error-Value 1 "Association type is not supported". Since the PAG 271 is opaque in nature, the PAG and the policy MUST be configured on the 272 PCEP peers as per the operator-configured association procedures. 273 All further processing is as per section 6.4 of [RFC8697]. If a PCE 274 speaker receives PAG in a PCEP message, and the policy association 275 information is not configured, it MUST return a PCErr message with 276 Error-Type 26 "Association Error" and Error- Value 4 "Association 277 unknown". If some of the association information [RFC8697] (the TLVs 278 defined in this document) received from the peer does not match the 279 local configured values, the PCEP speaker MUST reject the PCEP 280 message and send a PCErr message with Error-Type 26 "Association 281 Error" and Error-Value 5 "Operator-configured association information 282 mismatch". 284 Associating a particular LSP to multiple policy groups is authorized 285 from a protocol perspective, however there is no assurance that the 286 PCE will be able to apply multiple policies. 288 5. Policy Association Group 290 Association groups and their memberships are defined using the 291 ASSOCIATION object defined in [RFC8697]. Two object types for IPv4 292 and IPv6 are defined. The ASSOCIATION object includes "Association 293 type" indicating the type of the association group. This document 294 add a new Association type - 296 Association type = TBD1 ("Policy Association type") for PAG. 298 PAG may carry optional TLVs including but not limited to - 300 o POLICY-PARAMETERS-TLV: Used to communicate opaque information 301 useful to apply the policy, described in Section 5.1. 303 o VENDOR-INFORMATION-TLV: Used to communicate arbitrary vendor 304 specific behavioural information, described in [RFC7470]. 306 5.1. Policy Parameters TLV 308 The POLICY-PARAMETERS-TLV is an optional TLV that can be carried in 309 ASSOCIATION object (for PAT) to carry opaque information needed to 310 apply the policy at the PCEP peer. In some cases to apply a PCE 311 policy successfully, it is required to also associate some policy 312 parameters that needs to be evaluated, to successfully apply the said 313 policy. This TLV is used to carry those policy parameters. The TLV 314 could include one or more policy related parameter. The encoding 315 format and the order MUST be known to the PCEP peers, this could be 316 done during the configuration of the policy (and its association 317 parameters) for the PAG. The TLV format is as per the format of the 318 PCEP TLVs, as defined in [RFC5440], and shown in Figure 2. Only one 319 POLICY-PARAMETERS-TLV can be carried and only the first occurrence is 320 processed and any others MUST be ignored. 322 0 1 2 3 323 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 324 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 325 | Type=TBD2 | Length | 326 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 327 | | 328 // Policy Parameters // 329 | | 330 +---------------------------------------------------------------+ 332 Figure 2: The POLICY-PARAMETERS-TLV format 334 The type of the POLICY-PARAMETERS-TLV is TBD2 and it has a variable 335 length. The Value field is variable field padded to a 4-bytes 336 alignment; padding is not included in the Length field. The PCEP 337 peer implementation need to be aware of the encoding format, order, 338 and meaning of the 'Policy Parameters' well in advance based on the 339 policy. Note that from the protocol point of view this data is 340 opaque and can be used to carry parameters in any format understood 341 by the PCEP peers and associated to the policy. The exact use of 342 this TLV is beyond the scope of this document. 344 If the PCEP peer is unaware of the policy parameters associated with 345 the policy and it receives the POLICY-PARAMETERS-TLV, it MUST ignore 346 the TLV and SHOULD log this event. Further, if one or more 347 parameters received in the POLICY-PARAMETERS-TLV received by the PCEP 348 speaker are considered as unacceptable in the context of the 349 associated policy (e.g. out of range value, badly encoded value...), 350 the PCEP speaker MUST NOT apply the received policy and SHOULD log 351 this event. 353 Note that, the vendor specific behavioural information is encoded in 354 VENDOR-INFORMATION-TLV which can be used along with this TLV. 356 6. Implementation Status 358 [Note to the RFC Editor - remove this section before publication, as 359 well as remove the reference to RFC 7942.] 361 This section records the status of known implementations of the 362 protocol defined by this specification at the time of posting of this 363 Internet-Draft, and is based on a proposal described in [RFC7942]. 364 The description of implementations in this section is intended to 365 assist the IETF in its decision processes in progressing drafts to 366 RFCs. Please note that the listing of any individual implementation 367 here does not imply endorsement by the IETF. Furthermore, no effort 368 has been spent to verify the information presented here that was 369 supplied by IETF contributors. This is not intended as, and must not 370 be construed to be, a catalogue of available implementations or their 371 features. Readers are advised to note that other implementations may 372 exist. 374 According to [RFC7942], "this will allow reviewers and working groups 375 to assign due consideration to documents that have the benefit of 376 running code, which may serve as evidence of valuable experimentation 377 and feedback that have made the implemented protocols more mature. 378 It is up to the individual working groups to use this information as 379 they see fit". 381 6.1. Cisco's Implementation 383 o Organization: Cisco Systems, Inc. 385 o Implementation: IOS-XR PCE and PCC. 387 o Description: The PCEP extension specified in this document is used 388 to convey traffic steering policies. 390 o Maturity Level: In shipping product. 392 o Coverage: Partial. 394 o Contact: msiva@cisco.com. 396 7. Security Considerations 398 This document defines one new type for association, which do not add 399 any new security concerns beyond those discussed in [RFC5440], 400 [RFC8231] and [RFC8697] in itself. 402 Extra care needs to be taken by the implementation with respect to 403 POLICY-PARAMETERS-TLV while decoding, verifying and applying these 404 policy variables. This TLV parsing could be exploited by an 405 attacker. 407 Some deployments may find policy associations and their implications 408 as extra sensitive and thus securing the PCEP session using Transport 409 Layer Security (TLS) [RFC8253], as per the recommendations and best 410 current practices in BCP 195 [RFC7525], is RECOMMENDED. 412 8. IANA Considerations 414 8.1. Association object Type Indicators 416 This document defines a new Association type. The sub-registry 417 "ASSOCIATION Type Field" of the "Path Computation Element Protocol 418 (PCEP) Numbers" registry was originally defined in [RFC8697]. IANA 419 is requested to make the following allocation. 421 Value Name Reference 423 TBD1 Policy Association [This.I-D] 425 8.2. PCEP TLV Type Indicators 427 The following TLV Type Indicator value is requested within the "PCEP 428 TLV Type Indicators" subregistry of the "Path Computation Element 429 Protocol (PCEP) Numbers" registry. IANA is requested to make the 430 following allocation. 432 Value Description Reference 434 TBD2 POLICY-PARAMETERS-TLV [This.I-D] 436 9. Manageability Considerations 438 9.1. Control of Function and Policy 440 An operator MUST be allowed to configure the policy associations at 441 PCEP peers and associate it with the LSPs. They MAY also allow 442 configuration to related policy parameters, in which case the an 443 operator MUST also be allowed to set the encoding format and order to 444 parse the associated policy parameters TLV. 446 9.2. Information and Data Models 448 [RFC7420] describes the PCEP MIB, there are no new MIB Objects for 449 this document. 451 The PCEP YANG module is defined in [I-D.ietf-pce-pcep-yang]. This 452 module supports associations as defined in [RFC8697] and thus support 453 the Policy Association groups. 455 An implementation SHOULD allow the operator to view the PAG 456 configured. Further implementation SHOULD allow to view associations 457 reported by each peer, and the current set of LSPs in the PAG. 459 9.3. Liveness Detection and Monitoring 461 Mechanisms defined in this document do not imply any new liveness 462 detection and monitoring requirements in addition to those already 463 listed in [RFC5440], [RFC8231], and [RFC8281]. 465 9.4. Verify Correct Operations 467 Mechanisms defined in this document do not imply any new operation 468 verification requirements in addition to those already listed in 469 [RFC5440], [RFC8231], and [RFC8281]. 471 9.5. Requirements on Other Protocols 473 Mechanisms defined in this document do not imply any new requirements 474 on other protocols. 476 9.6. Impact on Network Operations 478 Mechanisms defined in this document do not have any impact on network 479 operations in addition to those already listed in [RFC5440], 480 [RFC8231], and [RFC8281]. 482 10. Acknowledgments 484 A special thanks to author of [RFC8697], this document borrow some of 485 the text from it. 487 11. References 489 11.1. Normative References 491 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 492 Requirement Levels", BCP 14, RFC 2119, 493 DOI 10.17487/RFC2119, March 1997, 494 . 496 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 497 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 498 DOI 10.17487/RFC5440, March 2009, 499 . 501 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 502 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 503 May 2017, . 505 [RFC8231] Crabbe, E., Minei, I., Medved, J., and R. Varga, "Path 506 Computation Element Communication Protocol (PCEP) 507 Extensions for Stateful PCE", RFC 8231, 508 DOI 10.17487/RFC8231, September 2017, 509 . 511 [RFC8697] Minei, I., Crabbe, E., Sivabalan, S., Ananthakrishnan, H., 512 Dhody, D., and Y. Tanaka, "Path Computation Element 513 Communication Protocol (PCEP) Extensions for Establishing 514 Relationships between Sets of Label Switched Paths 515 (LSPs)", RFC 8697, DOI 10.17487/RFC8697, January 2020, 516 . 518 11.2. Informative References 520 [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation 521 Element (PCE)-Based Architecture", RFC 4655, 522 DOI 10.17487/RFC4655, August 2006, 523 . 525 [RFC5394] Bryskin, I., Papadimitriou, D., Berger, L., and J. Ash, 526 "Policy-Enabled Path Computation Framework", RFC 5394, 527 DOI 10.17487/RFC5394, December 2008, 528 . 530 [RFC7420] Koushik, A., Stephan, E., Zhao, Q., King, D., and J. 531 Hardwick, "Path Computation Element Communication Protocol 532 (PCEP) Management Information Base (MIB) Module", 533 RFC 7420, DOI 10.17487/RFC7420, December 2014, 534 . 536 [RFC7470] Zhang, F. and A. Farrel, "Conveying Vendor-Specific 537 Constraints in the Path Computation Element Communication 538 Protocol", RFC 7470, DOI 10.17487/RFC7470, March 2015, 539 . 541 [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, 542 "Recommendations for Secure Use of Transport Layer 543 Security (TLS) and Datagram Transport Layer Security 544 (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 545 2015, . 547 [RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running 548 Code: The Implementation Status Section", BCP 205, 549 RFC 7942, DOI 10.17487/RFC7942, July 2016, 550 . 552 [RFC8253] Lopez, D., Gonzalez de Dios, O., Wu, Q., and D. Dhody, 553 "PCEPS: Usage of TLS to Provide a Secure Transport for the 554 Path Computation Element Communication Protocol (PCEP)", 555 RFC 8253, DOI 10.17487/RFC8253, October 2017, 556 . 558 [RFC8281] Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "Path 559 Computation Element Communication Protocol (PCEP) 560 Extensions for PCE-Initiated LSP Setup in a Stateful PCE 561 Model", RFC 8281, DOI 10.17487/RFC8281, December 2017, 562 . 564 [RFC8664] Sivabalan, S., Filsfils, C., Tantsura, J., Henderickx, W., 565 and J. Hardwick, "Path Computation Element Communication 566 Protocol (PCEP) Extensions for Segment Routing", RFC 8664, 567 DOI 10.17487/RFC8664, December 2019, 568 . 570 [I-D.ietf-pce-pcep-yang] 571 Dhody, D., Hardwick, J., Beeram, V., and J. Tantsura, "A 572 YANG Data Model for Path Computation Element 573 Communications Protocol (PCEP)", draft-ietf-pce-pcep- 574 yang-13 (work in progress), October 2019. 576 Appendix A. Contributor Addresses 578 Dhruv Dhody 579 Huawei Technologies 580 Divyashree Techno Park, Whitefield 581 Bangalore, Karnataka 560066 582 India 584 EMail: dhruv.ietf@gmail.com 586 Qin Wu 587 Huawei Technologies 588 101 Software Avenue, Yuhua District 589 Nanjing, Jiangsu 210012 590 China 592 EMail: sunseawq@huawei.com 594 Xian Zhang 595 Huawei Technologies 596 Bantian, Longgang District 597 Shenzhen 518129 598 P.R.China 600 EMail: zhang.xian@huawei.com 602 Udayasree Palle 604 EMail: udayasreereddy@gmail.com 606 Authors' Addresses 608 Stephane Litkowski 609 Cisco Systems, Inc. 610 11 Rue Camille Desmoulins 611 Issy-les-Moulineaux 92130 612 France 614 EMail: slitkows@cisco.com 615 Siva Sivabalan 616 Cisco Systems, Inc. 617 2000 Innovation Drive 618 Kanata, Ontario K2K 3E8 619 Canada 621 EMail: msiva@cisco.com 623 Jeff Tantsura 624 Apstra, Inc. 626 EMail: jefftant.ietf@gmail.com 628 Jonathan Hardwick 629 Metaswitch Networks 630 100 Church Street 631 Enfield, Middlesex 632 UK 634 EMail: Jonathan.Hardwick@metaswitch.com 636 Mahendra Singh Negi 637 RtBrick India 638 N-17L, Floor-1, 18th Cross Rd, HSR Layout Sector-3 639 Bangalore, Karnataka 560102 640 India 642 EMail: mahend.ietf@gmail.com 644 Cheng Li 645 Huawei Technologies 646 Huawei Campus, No. 156 Beiqing Rd. 647 Beijing 100095 648 China 650 EMail: chengli13@huawei.com