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