idnits 2.17.1 draft-ietf-pce-association-policy-06.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 (August 6, 2019) is 1717 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-12 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 Orange 4 Intended status: Standards Track S. Sivabalan 5 Expires: February 7, 2020 Cisco Systems, Inc. 6 J. Tantsura 7 Apstra, Inc. 8 J. Hardwick 9 Metaswitch Networks 10 M. Negi 11 Huawei Technologies 12 August 6, 2019 14 Path Computation Element communication Protocol (PCEP) extension for 15 associating Policies and Label Switched Paths (LSPs) 16 draft-ietf-pce-association-policy-06 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 February 7, 2020. 41 Copyright Notice 43 Copyright (c) 2019 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 [I-D.ietf-pce-segment-routing]. 104 [I-D.ietf-pce-association-group] introduces a generic mechanism to 105 create a grouping of LSPs which can then be used to define 106 associations between a set of LSPs and a set of attributes (such as 107 configuration parameters or behaviours) and is equally applicable to 108 stateful PCE (active and 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 133 [I-D.ietf-pce-association-group], the combination of the mandatory 134 fields Association type, Association ID and Association Source in 135 the ASSOCIATION object uniquely identify the association group. 136 If the optional TLVs - Global Association Source or Extended 137 Association ID are included, then they are included in combination 138 with mandatory fields to uniquely identify the association group. 140 Association information: As described in 141 [I-D.ietf-pce-association-group], the ASSOCIATION object could 142 include other optional TLVs based on the association types, that 143 provides 'information' related to the association. 145 LSR: Label Switch Router. 147 MPLS: Multiprotocol Label Switching. 149 PAG: Policy Association Group. 151 PCC: Path Computation Client. Any client application requesting a 152 path computation to be performed by a Path Computation Element. 154 PCE: Path Computation Element. An entity (component, application, 155 or network node) that is capable of computing a network path or 156 route based on a network graph and applying computational 157 constraints. 159 PCEP: Path Computation Element Communication Protocol. 161 3. Motivation 163 Paths computed using PCE can be subjected to various policies on both 164 PCE and PCC. For example, in a centralized traffic engineering 165 scenario, network operators may instantiate LSPs and specifies 166 policies for traffic steering, path monitoring, etc., for some LSPs 167 via the Stateful PCE. Similarly, a PCC could request a user- or 168 service-specific policy to be applied at the PCE, such as constraints 169 relaxation to meet optimal QoS and resiliency. 171 PCEP speaker can use the generic mechanism as per 172 [I-D.ietf-pce-association-group] to associate a set of LSPs with a 173 policy, without the need to know the details of such a policy, which 174 simplifies network operations, avoids frequent software upgrades, as 175 well as provides an ability to introduce new policy faster. 177 PAG Y 178 {Service-Specific Policy 179 for constraint 180 Initiate & Monitor LSP relaxation} 181 | | 182 | PAG X PCReq | 183 V {Monitor LSP} {PAG Y} V 184 +-----+ ----------------> +-----+ 185 _ _ _ _ _ _| PCE | | | PCE | 186 | +-----+ | ----------> +-----+ 187 | PCInitiate | | PCReq 188 |{PAG X} | | {PAG Y} 189 | | | 190 | .-----. | | .-----. 191 | ( ) | +----+ ( ) 192 | .--( )--. | |PCC1|--.--( )--. 193 V ( ) | +----+ ( ) 194 +---+ ( ) | ( ) 195 |PCC|----( (G)MPLS network ) +----+ ( (G)MPLS network ) 196 +---+ ( ) |PCC2|------( ) 197 PAG X ( ) +----+ ( ) 198 {Monitor LSP} '--( )--' '--( )--' 199 ( ) ( ) 200 '-----' '-----' 202 Case 1: Policy requested by PCE Case 2: Policy requested by 203 and enforced by PCC PCC and enforced by 204 PCE 206 Figure 1: Sample use-cases for carrying policies over PCEP session 208 3.1. Policy based Constraints 210 In the context of policy-enabled path computation [RFC5394], path 211 computation policies may be applied at both a PCC and a PCE. 212 Consider an Label Switch Router (LSR) with a policy enabled PCC, it 213 receives a service request via signalling, including over a Network- 214 Network Interface (NNI) or User Network Interface (UNI) reference 215 point, or receives a configuration request over a management 216 interface to establish a service. The PCC may also apply user- or 217 service-specific policies to decide how the path selection process 218 should be constrained, that is, which constraints, diversities, 219 optimization criterion, and constraint relaxation strategies should 220 be applied in order for the service LSP(s) to have a likelihood to be 221 successfully established and provide necessary QoS and resilience 222 against network failures. The user- or service-specific policies 223 applied to PCC and are then passed to the PCE along with the Path 224 computation request, in the form of constraints [RFC5394]. 226 PCEP speaker can use the generic mechanism as per 227 [I-D.ietf-pce-association-group] to associate a set of LSPs with 228 policy and its resulting path computation constraints. This would 229 simplify the path computation message exchanges in PCEP. 231 4. Overview 233 As per [I-D.ietf-pce-association-group], LSPs are associated with 234 other LSPs with which they interact by adding them to a common 235 association group. Grouping can also be used to define association 236 between LSPs and policies associated to them. One new Association 237 type is defined in this document, based on the generic Association 238 object - 240 o Association type = TBD1 ("Policy Association Type") for Policy 241 Association Group (PAG). 243 [I-D.ietf-pce-association-group] specify the mechanism for the 244 capability advertisement of the Association types supported by a PCEP 245 speaker by defining a ASSOC-Type-List TLV to be carried within an 246 OPEN object. This capability exchange for the association type 247 described in this document (i.e. Policy Association Type) MUST be 248 done before using the policy association. Thus the PCEP speaker MUST 249 include the Policy Association type (TBD1) in the ASSOC-Type-List TLV 250 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 [I-D.ietf-pce-association-group]. The Global 264 Association Source and Extended Association ID MAY also be included. 266 As per the processing rules specified in section 6.4 of 267 [I-D.ietf-pce-association-group], if a PCEP speaker does not support 268 this Policy Association type, it would return a PCErr message with 269 Error-Type 26 "Association Error" and Error-Value 1 "Association type 270 is not supported". Since the PAG is opaque in nature, the PAG and 271 the policy MUST be configured on the PCEP peers as per the operator- 272 configured association procedures. All further processing is as per 273 section 6.4 of [I-D.ietf-pce-association-group]. If a PCE speaker 274 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 278 [I-D.ietf-pce-association-group] (the TLVs defined in this document) 279 received from the peer does not match the local configured values, 280 the PCEP speaker MUST reject the PCEP message and send a PCErr 281 message with Error-Type 26 "Association Error" and Error-Value 5 282 "Operator-configured association information 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 [I-D.ietf-pce-association-group]. Two 292 object types for IPv4 and IPv6 are defined. The ASSOCIATION object 293 includes "Association type" indicating the type of the association 294 group. This document 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 (with "Policy Association type") to carry opaque 310 information needed to apply the policy at the PCEP peer. In some 311 cases to apply a PCE policy successfully, it is required to also 312 associate some policy parameters that needs to be evaluated, to 313 successfully apply the said policy. This TLV is used to carry those 314 policy parameters. The TLV could include one or more policy related 315 parameter. The encoding format and the order MUST be known to the 316 PCEP peers, this could be done during the configuration of the policy 317 (and its association parameters) for the PAG. The TLV format is as 318 per the format of the PCEP TLVs, as defined in [RFC5440], and shown 319 in Figure 2. Only one POLICY-PARAMETERS-TLV can be carried and only 320 the first occurrence is 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 Currently there are no confirmed implementations, though vendors have 382 shown interest in making this as part of their roadmap. More details 383 to be added in a later revision. 385 7. Security Considerations 387 This document defines one new type for association, which do not add 388 any new security concerns beyond those discussed in [RFC5440], 389 [RFC8231] and [I-D.ietf-pce-association-group] in itself. 391 Extra care needs to be taken by the implementation with respect to 392 POLICY-PARAMETERS-TLV while decoding, verifying and applying these 393 policy variables. This TLV parsing could be exploited by an 394 attacker. 396 Some deployments may find policy associations and their implications 397 as extra sensitive and thus securing the PCEP session using Transport 398 Layer Security (TLS) [RFC8253], as per the recommendations and best 399 current practices in [RFC7525], is RECOMMENDED. 401 8. IANA Considerations 403 8.1. Association object Type Indicators 405 This document defines a new Association type. The sub-registry 406 "ASSOCIATION Type Field" of the "Path Computation Element Protocol 407 (PCEP) Numbers" registry was originally defined in 408 [I-D.ietf-pce-association-group]. IANA is requested to make the 409 following allocation. 411 Value Name Reference 413 TBD1 Policy Association type [This.I-D] 415 8.2. PCEP TLV Type Indicators 417 The following TLV Type Indicator value is requested within the "PCEP 418 TLV Type Indicators" subregistry of the "Path Computation Element 419 Protocol (PCEP) Numbers" registry. IANA is requested to make the 420 following allocation. 422 Value Description Reference 424 TBD2 POLICY-PARAMETERS-TLV [This.I-D] 426 9. Manageability Considerations 428 9.1. Control of Function and Policy 430 An operator MUST be allowed to configure the policy associations at 431 PCEP peers and associate it with the LSPs. They MAY also allow 432 configuration to related policy parameters, in which case the an 433 operator MUST also be allowed to set the encoding format and order to 434 parse the associated policy parameters TLV. 436 9.2. Information and Data Models 438 The PCEP YANG module is defined in [I-D.ietf-pce-pcep-yang]. In 439 future, this YANG module should be extended or augmented to provide 440 the following additional information relating to POlicy Association 441 groups. 443 An implementation SHOULD allow the operator to view the PAG 444 configured. Further implementation SHOULD allow to view the current 445 set of LSPs in the PAG. 447 9.3. Liveness Detection and Monitoring 449 Mechanisms defined in this document do not imply any new liveness 450 detection and monitoring requirements in addition to those already 451 listed in [RFC5440]. 453 9.4. Verify Correct Operations 455 Mechanisms defined in this document do not imply any new operation 456 verification requirements in addition to those already listed in 457 [RFC5440]. 459 9.5. Requirements on Other Protocols 461 Mechanisms defined in this document do not imply any new requirements 462 on other protocols. 464 9.6. Impact on Network Operations 466 Mechanisms defined in this document do not have any impact on network 467 operations in addition to those already listed in [RFC5440]. 469 10. Acknowledgments 471 A special thanks to author of [I-D.ietf-pce-association-group], this 472 document borrow some of 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 [I-D.ietf-pce-association-group] 499 Minei, I., Crabbe, E., Sivabalan, S., Ananthakrishnan, H., 500 Dhody, D., and Y. Tanaka, "Path Computation Element 501 Communication Protocol (PCEP) Extensions for Establishing 502 Relationships Between Sets of Label Switched Paths 503 (LSPs)", draft-ietf-pce-association-group-10 (work in 504 progress), August 2019. 506 11.2. Informative References 508 [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation 509 Element (PCE)-Based Architecture", RFC 4655, 510 DOI 10.17487/RFC4655, August 2006, 511 . 513 [RFC5394] Bryskin, I., Papadimitriou, D., Berger, L., and J. Ash, 514 "Policy-Enabled Path Computation Framework", RFC 5394, 515 DOI 10.17487/RFC5394, December 2008, 516 . 518 [RFC7470] Zhang, F. and A. Farrel, "Conveying Vendor-Specific 519 Constraints in the Path Computation Element Communication 520 Protocol", RFC 7470, DOI 10.17487/RFC7470, March 2015, 521 . 523 [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, 524 "Recommendations for Secure Use of Transport Layer 525 Security (TLS) and Datagram Transport Layer Security 526 (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 527 2015, . 529 [RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running 530 Code: The Implementation Status Section", BCP 205, 531 RFC 7942, DOI 10.17487/RFC7942, July 2016, 532 . 534 [RFC8253] Lopez, D., Gonzalez de Dios, O., Wu, Q., and D. Dhody, 535 "PCEPS: Usage of TLS to Provide a Secure Transport for the 536 Path Computation Element Communication Protocol (PCEP)", 537 RFC 8253, DOI 10.17487/RFC8253, October 2017, 538 . 540 [RFC8281] Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "Path 541 Computation Element Communication Protocol (PCEP) 542 Extensions for PCE-Initiated LSP Setup in a Stateful PCE 543 Model", RFC 8281, DOI 10.17487/RFC8281, December 2017, 544 . 546 [I-D.ietf-pce-segment-routing] 547 Sivabalan, S., Filsfils, C., Tantsura, J., Henderickx, W., 548 and J. Hardwick, "PCEP Extensions for Segment Routing", 549 draft-ietf-pce-segment-routing-16 (work in progress), 550 March 2019. 552 [I-D.ietf-pce-pcep-yang] 553 Dhody, D., Hardwick, J., Beeram, V., and J. Tantsura, "A 554 YANG Data Model for Path Computation Element 555 Communications Protocol (PCEP)", draft-ietf-pce-pcep- 556 yang-12 (work in progress), July 2019. 558 Appendix A. Contributor Addresses 560 Dhruv Dhody 561 Huawei Technologies 562 Divyashree Techno Park, Whitefield 563 Bangalore, Karnataka 560066 564 India 566 EMail: dhruv.ietf@gmail.com 568 Qin Wu 569 Huawei Technologies 570 101 Software Avenue, Yuhua District 571 Nanjing, Jiangsu 210012 572 China 574 EMail: sunseawq@huawei.com 576 Clarence Filsfils 577 Cisco Systems, Inc. 578 Pegasus Parc 579 De kleetlaan 6a, DIEGEM BRABANT 1831 580 BELGIUM 582 Email: cfilsfil@cisco.com 584 Xian Zhang 585 Huawei Technologies 586 Bantian, Longgang District 587 Shenzhen 518129 588 P.R.China 590 EMail: zhang.xian@huawei.com 592 Udayasree Palle 593 Huawei Technologies 594 Divyashree Techno Park, Whitefield 595 Bangalore, Karnataka 560066 596 India 598 EMail: udayasreereddy@gmail.com 600 Authors' Addresses 601 Stephane Litkowski 602 Orange 604 EMail: stephane.litkowski@orange.com 606 Siva Sivabalan 607 Cisco Systems, Inc. 608 2000 Innovation Drive 609 Kanata, Ontario K2K 3E8 610 Canada 612 EMail: msiva@cisco.com 614 Jeff Tantsura 615 Apstra, Inc. 617 EMail: jefftant.ietf@gmail.com 619 Jonathan Hardwick 620 Metaswitch Networks 621 100 Church Street 622 Enfield, Middlesex 623 UK 625 EMail: Jonathan.Hardwick@metaswitch.com 627 Mahendra Singh Negi 628 Huawei Technologies 629 Divyashree Techno Park, Whitefield 630 Bangalore, Karnataka 560066 631 India 633 EMail: mahend.ietf@gmail.com