idnits 2.17.1 draft-ietf-pce-association-policy-07.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 (October 30, 2019) is 1630 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 S. Sivabalan 4 Intended status: Standards Track Cisco Systems, Inc. 5 Expires: May 2, 2020 J. Tantsura 6 Apstra, Inc. 7 J. Hardwick 8 Metaswitch Networks 9 M. Negi 10 Huawei Technologies 11 October 30, 2019 13 Path Computation Element communication Protocol (PCEP) extension for 14 associating Policies and Label Switched Paths (LSPs) 15 draft-ietf-pce-association-policy-07 17 Abstract 19 This document introduces a simple mechanism to associate policies to 20 a group of Label Switched Paths (LSPs) via an extension to the Path 21 Computation Element (PCE) Communication Protocol (PCEP). 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at https://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on May 2, 2020. 40 Copyright Notice 42 Copyright (c) 2019 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (https://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 58 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 59 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 3. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 4 61 3.1. Policy based Constraints . . . . . . . . . . . . . . . . 5 62 4. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 6 63 5. Policy Association Group . . . . . . . . . . . . . . . . . . 7 64 5.1. Policy Parameters TLV . . . . . . . . . . . . . . . . . . 7 65 6. Implementation Status . . . . . . . . . . . . . . . . . . . . 8 66 7. Security Considerations . . . . . . . . . . . . . . . . . . . 9 67 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 68 8.1. Association object Type Indicators . . . . . . . . . . . 9 69 8.2. PCEP TLV Type Indicators . . . . . . . . . . . . . . . . 10 70 9. Manageability Considerations . . . . . . . . . . . . . . . . 10 71 9.1. Control of Function and Policy . . . . . . . . . . . . . 10 72 9.2. Information and Data Models . . . . . . . . . . . . . . . 10 73 9.3. Liveness Detection and Monitoring . . . . . . . . . . . . 10 74 9.4. Verify Correct Operations . . . . . . . . . . . . . . . . 11 75 9.5. Requirements on Other Protocols . . . . . . . . . . . . . 11 76 9.6. Impact on Network Operations . . . . . . . . . . . . . . 11 77 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11 78 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 79 11.1. Normative References . . . . . . . . . . . . . . . . . . 11 80 11.2. Informative References . . . . . . . . . . . . . . . . . 12 81 Appendix A. Contributor Addresses . . . . . . . . . . . . . . . 14 82 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 84 1. Introduction 86 [RFC5440] describes the Path Computation Element communication 87 Protocol (PCEP) which enables the communication between a Path 88 Computation Client (PCC) and a Path Control Element (PCE), or between 89 two PCEs based on the PCE architecture [RFC4655]. [RFC5394] provides 90 additional details on policy within the PCE architecture and also 91 provides context for the support of PCE Policy. 93 PCEP Extensions for Stateful PCE Model [RFC8231] describes a set of 94 extensions to PCEP to enable active control of Multiprotocol Label 95 Switching Traffic Engineering (MPLS-TE) and Generalzied MPLS (GMPLS) 96 tunnels. [RFC8281] describes the set-up and teardown of PCE- 97 initiated LSPs under the active stateful PCE model, without the need 98 for local configuration on the PCC, thus allowing for a dynamic 99 network. Currently, the LSPs can either be signalled via Resource 100 Reservation Protocol Traffic Engineering (RSVP-TE) or can be segment 101 routed as specified in [I-D.ietf-pce-segment-routing]. 103 [I-D.ietf-pce-association-group] introduces a generic mechanism to 104 create a grouping of LSPs which can then be used to define 105 associations between a set of LSPs and a set of attributes (such as 106 configuration parameters or behaviours) and is equally applicable to 107 stateful PCE (active and passive modes) and stateless PCE. 109 This document specifies a PCEP extension to associate one or more 110 LSPs with policies using the generic association mechanism. 112 A PCEP speaker may want to influence the PCEP peer with respect to 113 path selection and other policies. This document describes a PCEP 114 extension to associate policies by creating Policy Association Group 115 (PAG) and encoding this association in PCEP messages. The 116 specification is applicable to both stateful and stateless PCEP 117 sessions. 119 1.1. Requirements Language 121 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 122 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 123 "OPTIONAL" in this document are to be interpreted as described in BCP 124 14 [RFC2119] [RFC8174] when, and only when, they appear in all 125 capitals, as shown here. 127 2. Terminology 129 The following terminology is used in this document. 131 Association parameters: As described in 132 [I-D.ietf-pce-association-group], the combination of the mandatory 133 fields Association type, Association ID and Association Source in 134 the ASSOCIATION object uniquely identify the association group. 135 If the optional TLVs - Global Association Source or Extended 136 Association ID are included, then they are included in combination 137 with mandatory fields to uniquely identify the association group. 139 Association information: As described in 140 [I-D.ietf-pce-association-group], the ASSOCIATION object could 141 include other optional TLVs based on the association types, that 142 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 173 [I-D.ietf-pce-association-group] to associate a set of LSPs with a 174 policy, without the need to know the details of such a policy, which 175 simplifies network operations, avoids frequent software upgrades, as 176 well as provides an ability to 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 228 [I-D.ietf-pce-association-group] to associate a set of LSPs with 229 policy and its resulting path computation constraints. This would 230 simplify the path computation message exchanges in PCEP. 232 4. Overview 234 As per [I-D.ietf-pce-association-group], LSPs are associated with 235 other LSPs with which they interact by adding them to a common 236 association group. Grouping can also be used to define association 237 between LSPs and policies associated to them. One new Association 238 type is defined in this document, based on the generic Association 239 object - 241 o Association type = TBD1 ("Policy Association Type (PAT)" ) for 242 Policy Association Group (PAG). 244 [I-D.ietf-pce-association-group] specify the mechanism for the 245 capability advertisement of the Association types supported by a PCEP 246 speaker by defining a ASSOC-Type-List TLV to be carried within an 247 OPEN object. This capability exchange for the association type 248 described in this document (i.e. PAT) MUST be done before using the 249 policy association. Thus the PCEP speaker MUST include the PAT 250 (TBD1) in the ASSOC-Type-List TLV before using the PAG in the PCEP 251 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 [I-D.ietf-pce-association-group]. The Global 265 Association Source and Extended Association ID MAY also be included. 267 As per the processing rules specified in section 6.4 of 268 [I-D.ietf-pce-association-group], if a PCEP speaker does not support 269 this Policy Association type, it would return a PCErr message with 270 Error-Type 26 "Association Error" and Error-Value 1 "Association type 271 is not supported". Since the PAG is opaque in nature, the PAG and 272 the policy MUST be configured on the PCEP peers as per the operator- 273 configured association procedures. All further processing is as per 274 section 6.4 of [I-D.ietf-pce-association-group]. If a PCE speaker 275 receives PAG in a PCEP message, and the policy association 276 information is not configured, it MUST return a PCErr message with 277 Error-Type 26 "Association Error" and Error- Value 4 "Association 278 unknown". If some of the association information 279 [I-D.ietf-pce-association-group] (the TLVs defined in this document) 280 received from the peer does not match the local configured values, 281 the PCEP speaker MUST reject the PCEP message and send a PCErr 282 message with Error-Type 26 "Association Error" and Error-Value 5 283 "Operator-configured association information mismatch". 285 Associating a particular LSP to multiple policy groups is authorized 286 from a protocol perspective, however there is no assurance that the 287 PCE will be able to apply multiple policies. 289 5. Policy Association Group 291 Association groups and their memberships are defined using the 292 ASSOCIATION object defined in [I-D.ietf-pce-association-group]. Two 293 object types for IPv4 and IPv6 are defined. The ASSOCIATION object 294 includes "Association type" indicating the type of the association 295 group. This document add a new Association type - 297 Association type = TBD1 ("Policy Association type") for PAG. 299 PAG may carry optional TLVs including but not limited to - 301 o POLICY-PARAMETERS-TLV: Used to communicate opaque information 302 useful to apply the policy, described in Section 5.1. 304 o VENDOR-INFORMATION-TLV: Used to communicate arbitrary vendor 305 specific behavioural information, described in [RFC7470]. 307 5.1. Policy Parameters TLV 309 The POLICY-PARAMETERS-TLV is an optional TLV that can be carried in 310 ASSOCIATION object (for PAT) to carry opaque information needed to 311 apply the policy at the PCEP peer. In some cases to apply a PCE 312 policy successfully, it is required to also associate some policy 313 parameters that needs to be evaluated, to successfully apply the said 314 policy. This TLV is used to carry those policy parameters. The TLV 315 could include one or more policy related parameter. The encoding 316 format and the order MUST be known to the PCEP peers, this could be 317 done during the configuration of the policy (and its association 318 parameters) for the PAG. The TLV format is as per the format of the 319 PCEP TLVs, as defined in [RFC5440], and shown in Figure 2. Only one 320 POLICY-PARAMETERS-TLV can be carried and only the first occurrence is 321 processed and any others MUST be ignored. 323 0 1 2 3 324 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 325 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 326 | Type=TBD2 | Length | 327 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 328 | | 329 // Policy Parameters // 330 | | 331 +---------------------------------------------------------------+ 333 Figure 2: The POLICY-PARAMETERS-TLV format 335 The type of the POLICY-PARAMETERS-TLV is TBD2 and it has a variable 336 length. The Value field is variable field padded to a 4-bytes 337 alignment; padding is not included in the Length field. The PCEP 338 peer implementation need to be aware of the encoding format, order, 339 and meaning of the 'Policy Parameters' well in advance based on the 340 policy. Note that from the protocol point of view this data is 341 opaque and can be used to carry parameters in any format understood 342 by the PCEP peers and associated to the policy. The exact use of 343 this TLV is beyond the scope of this document. 345 If the PCEP peer is unaware of the policy parameters associated with 346 the policy and it receives the POLICY-PARAMETERS-TLV, it MUST ignore 347 the TLV and SHOULD log this event. Further, if one or more 348 parameters received in the POLICY-PARAMETERS-TLV received by the PCEP 349 speaker are considered as unacceptable in the context of the 350 associated policy (e.g. out of range value, badly encoded value...), 351 the PCEP speaker MUST NOT apply the received policy and SHOULD log 352 this event. 354 Note that, the vendor specific behavioural information is encoded in 355 VENDOR-INFORMATION-TLV which can be used along with this TLV. 357 6. Implementation Status 359 [Note to the RFC Editor - remove this section before publication, as 360 well as remove the reference to RFC 7942.] 362 This section records the status of known implementations of the 363 protocol defined by this specification at the time of posting of this 364 Internet-Draft, and is based on a proposal described in [RFC7942]. 365 The description of implementations in this section is intended to 366 assist the IETF in its decision processes in progressing drafts to 367 RFCs. Please note that the listing of any individual implementation 368 here does not imply endorsement by the IETF. Furthermore, no effort 369 has been spent to verify the information presented here that was 370 supplied by IETF contributors. This is not intended as, and must not 371 be construed to be, a catalogue of available implementations or their 372 features. Readers are advised to note that other implementations may 373 exist. 375 According to [RFC7942], "this will allow reviewers and working groups 376 to assign due consideration to documents that have the benefit of 377 running code, which may serve as evidence of valuable experimentation 378 and feedback that have made the implemented protocols more mature. 379 It is up to the individual working groups to use this information as 380 they see fit". 382 Currently there are no confirmed implementations, though vendors have 383 shown interest in making this as part of their roadmap. More details 384 to be added in a later revision. 386 7. Security Considerations 388 This document defines one new type for association, which do not add 389 any new security concerns beyond those discussed in [RFC5440], 390 [RFC8231] and [I-D.ietf-pce-association-group] in itself. 392 Extra care needs to be taken by the implementation with respect to 393 POLICY-PARAMETERS-TLV while decoding, verifying and applying these 394 policy variables. This TLV parsing could be exploited by an 395 attacker. 397 Some deployments may find policy associations and their implications 398 as extra sensitive and thus securing the PCEP session using Transport 399 Layer Security (TLS) [RFC8253], as per the recommendations and best 400 current practices in BCP 195 [RFC7525], is RECOMMENDED. 402 8. IANA Considerations 404 8.1. Association object Type Indicators 406 This document defines a new Association type. The sub-registry 407 "ASSOCIATION Type Field" of the "Path Computation Element Protocol 408 (PCEP) Numbers" registry was originally defined in 409 [I-D.ietf-pce-association-group]. IANA is requested to make the 410 following allocation. 412 Value Name Reference 414 TBD1 Policy Association [This.I-D] 416 8.2. PCEP TLV Type Indicators 418 The following TLV Type Indicator value is requested within the "PCEP 419 TLV Type Indicators" subregistry of the "Path Computation Element 420 Protocol (PCEP) Numbers" registry. IANA is requested to make the 421 following allocation. 423 Value Description Reference 425 TBD2 POLICY-PARAMETERS-TLV [This.I-D] 427 9. Manageability Considerations 429 9.1. Control of Function and Policy 431 An operator MUST be allowed to configure the policy associations at 432 PCEP peers and associate it with the LSPs. They MAY also allow 433 configuration to related policy parameters, in which case the an 434 operator MUST also be allowed to set the encoding format and order to 435 parse the associated policy parameters TLV. 437 9.2. Information and Data Models 439 [RFC7420] describes the PCEP MIB, there are no new MIB Objects for 440 this document. 442 The PCEP YANG module is defined in [I-D.ietf-pce-pcep-yang]. This 443 module supports associations as defined in 444 [I-D.ietf-pce-association-group] and thus support the Policy 445 Association groups. 447 An implementation SHOULD allow the operator to view the PAG 448 configured. Further implementation SHOULD allow to view associations 449 reported by each peer, and the current set of LSPs in the PAG. 451 9.3. Liveness Detection and Monitoring 453 Mechanisms defined in this document do not imply any new liveness 454 detection and monitoring requirements in addition to those already 455 listed in [RFC5440], [RFC8231], and [RFC8281]. 457 9.4. Verify Correct Operations 459 Mechanisms defined in this document do not imply any new operation 460 verification requirements in addition to those already listed in 461 [RFC5440], [RFC8231], and [RFC8281]. 463 9.5. Requirements on Other Protocols 465 Mechanisms defined in this document do not imply any new requirements 466 on other protocols. 468 9.6. Impact on Network Operations 470 Mechanisms defined in this document do not have any impact on network 471 operations in addition to those already listed in [RFC5440], 472 [RFC8231], and [RFC8281]. 474 10. Acknowledgments 476 A special thanks to author of [I-D.ietf-pce-association-group], this 477 document borrow some of the text from it. 479 11. References 481 11.1. Normative References 483 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 484 Requirement Levels", BCP 14, RFC 2119, 485 DOI 10.17487/RFC2119, March 1997, 486 . 488 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 489 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 490 DOI 10.17487/RFC5440, March 2009, 491 . 493 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 494 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 495 May 2017, . 497 [RFC8231] Crabbe, E., Minei, I., Medved, J., and R. Varga, "Path 498 Computation Element Communication Protocol (PCEP) 499 Extensions for Stateful PCE", RFC 8231, 500 DOI 10.17487/RFC8231, September 2017, 501 . 503 [I-D.ietf-pce-association-group] 504 Minei, I., Crabbe, E., Sivabalan, S., Ananthakrishnan, H., 505 Dhody, D., and Y. Tanaka, "Path Computation Element 506 Communication Protocol (PCEP) Extensions for Establishing 507 Relationships Between Sets of Label Switched Paths 508 (LSPs)", draft-ietf-pce-association-group-10 (work in 509 progress), August 2019. 511 11.2. Informative References 513 [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation 514 Element (PCE)-Based Architecture", RFC 4655, 515 DOI 10.17487/RFC4655, August 2006, 516 . 518 [RFC5394] Bryskin, I., Papadimitriou, D., Berger, L., and J. Ash, 519 "Policy-Enabled Path Computation Framework", RFC 5394, 520 DOI 10.17487/RFC5394, December 2008, 521 . 523 [RFC7420] Koushik, A., Stephan, E., Zhao, Q., King, D., and J. 524 Hardwick, "Path Computation Element Communication Protocol 525 (PCEP) Management Information Base (MIB) Module", 526 RFC 7420, DOI 10.17487/RFC7420, December 2014, 527 . 529 [RFC7470] Zhang, F. and A. Farrel, "Conveying Vendor-Specific 530 Constraints in the Path Computation Element Communication 531 Protocol", RFC 7470, DOI 10.17487/RFC7470, March 2015, 532 . 534 [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, 535 "Recommendations for Secure Use of Transport Layer 536 Security (TLS) and Datagram Transport Layer Security 537 (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 538 2015, . 540 [RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running 541 Code: The Implementation Status Section", BCP 205, 542 RFC 7942, DOI 10.17487/RFC7942, July 2016, 543 . 545 [RFC8253] Lopez, D., Gonzalez de Dios, O., Wu, Q., and D. Dhody, 546 "PCEPS: Usage of TLS to Provide a Secure Transport for the 547 Path Computation Element Communication Protocol (PCEP)", 548 RFC 8253, DOI 10.17487/RFC8253, October 2017, 549 . 551 [RFC8281] Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "Path 552 Computation Element Communication Protocol (PCEP) 553 Extensions for PCE-Initiated LSP Setup in a Stateful PCE 554 Model", RFC 8281, DOI 10.17487/RFC8281, December 2017, 555 . 557 [I-D.ietf-pce-segment-routing] 558 Sivabalan, S., Filsfils, C., Tantsura, J., Henderickx, W., 559 and J. Hardwick, "PCEP Extensions for Segment Routing", 560 draft-ietf-pce-segment-routing-16 (work in progress), 561 March 2019. 563 [I-D.ietf-pce-pcep-yang] 564 Dhody, D., Hardwick, J., Beeram, V., and J. Tantsura, "A 565 YANG Data Model for Path Computation Element 566 Communications Protocol (PCEP)", draft-ietf-pce-pcep- 567 yang-12 (work in progress), July 2019. 569 Appendix A. Contributor Addresses 571 Dhruv Dhody 572 Huawei Technologies 573 Divyashree Techno Park, Whitefield 574 Bangalore, Karnataka 560066 575 India 577 EMail: dhruv.ietf@gmail.com 579 Qin Wu 580 Huawei Technologies 581 101 Software Avenue, Yuhua District 582 Nanjing, Jiangsu 210012 583 China 585 EMail: sunseawq@huawei.com 587 Clarence Filsfils 588 Cisco Systems, Inc. 589 Pegasus Parc 590 De kleetlaan 6a, DIEGEM BRABANT 1831 591 BELGIUM 593 Email: cfilsfil@cisco.com 595 Xian Zhang 596 Huawei Technologies 597 Bantian, Longgang District 598 Shenzhen 518129 599 P.R.China 601 EMail: zhang.xian@huawei.com 603 Udayasree Palle 605 EMail: udayasreereddy@gmail.com 607 Authors' Addresses 609 Stephane Litkowski 610 Cisco Systems, Inc. 612 EMail: slitkows.ietf@gmail.com 613 Siva Sivabalan 614 Cisco Systems, Inc. 615 2000 Innovation Drive 616 Kanata, Ontario K2K 3E8 617 Canada 619 EMail: msiva@cisco.com 621 Jeff Tantsura 622 Apstra, Inc. 624 EMail: jefftant.ietf@gmail.com 626 Jonathan Hardwick 627 Metaswitch Networks 628 100 Church Street 629 Enfield, Middlesex 630 UK 632 EMail: Jonathan.Hardwick@metaswitch.com 634 Mahendra Singh Negi 635 Huawei Technologies 636 Divyashree Techno Park, Whitefield 637 Bangalore, Karnataka 560066 638 India 640 EMail: mahend.ietf@gmail.com