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