idnits 2.17.1 draft-ietf-pce-vn-association-01.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 28, 2019) is 1639 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) No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 PCE Working Group Y. Lee 3 Internet-Draft SKKU 4 Intended Status: Standards track H. Zheng 5 Expires: April 28, 2020 Huawei Technologies 6 D. Ceccarelli 7 Ericsson 8 October 28, 2019 10 Path Computation Element communication Protocol (PCEP) extensions 11 for Establishing Relationships between sets of LSPs and Virtual 12 Networks 13 draft-ietf-pce-vn-association-01 15 Abstract 17 This document describes how to extend Path Computation Element (PCE) 18 Communication Protocol (PCEP) association mechanism introduced by the 19 PCEP Association Group specification, to further associate sets of 20 LSPs with a higher-level structure such as a virtual network (VN) 21 requested by clients or applications. This extended association 22 mechanism can be used to facilitate virtual network control using PCE 23 architecture. 25 Status of this Memo 27 This Internet-Draft is submitted to IETF in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF), its areas, and its working groups. Note that 32 other groups may also distribute working documents as Internet- 33 Drafts. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 39 The list of current Internet-Drafts can be accessed at 40 https://www.ietf.org/ietf/1id-abstracts.txt 42 The list of Internet-Draft Shadow Directories can be accessed at 43 https://www.ietf.org/shadow.html 45 This Internet-Draft will expire on April 28, 2020. 47 Copyright Notice 49 Copyright (c) 2019 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents 54 (http://trustee.ietf.org/license-info) in effect on the date of 55 publication of this document. Please review these documents 56 carefully, as they describe your rights and restrictions with respect 57 to this document. Code Components extracted from this document must 58 include Simplified BSD License text as described in Section 4.e of 59 the Trust Legal Provisions and are provided without warranty as 60 described in the Simplified BSD License. 62 Table of Contents 64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 65 1.1. Requirements Language . . . . . . . . . . . . . . . . . . . 4 66 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 5 67 3. Operation Overview . . . . . . . . . . . . . . . . . . . . . . 5 68 4. Extensions to PCEP . . . . . . . . . . . . . . . . . . . . . . 7 69 5. Applicability to H-PCE architecture . . . . . . . . . . . . . . 8 70 6. Implementation Status . . . . . . . . . . . . . . . . . . . . . 9 71 6.1. Huawei's Proof of Concept based on ONOS . . . . . . . . . 10 72 7. Security Considerations . . . . . . . . . . . . . . . . . . . . 10 73 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 10 74 8.1. Association Object Type Indicator . . . . . . . . . . . . . 10 75 8.2. PCEP TLV Type Indicator . . . . . . . . . . . . . . . . . . 10 76 8.3. PCEP Error . . . . . . . . . . . . . . . . . . . . . . . . 11 77 9. Manageability Considerations . . . . . . . . . . . . . . . . . 11 78 9.1. Control of Function and Policy . . . . . . . . . . . . . . 11 79 9.2. Information and Data Models . . . . . . . . . . . . . . . 11 80 9.3. Liveness Detection and Monitoring . . . . . . . . . . . . 11 81 9.4. Verify Correct Operations . . . . . . . . . . . . . . . . 11 82 9.5. Requirements On Other Protocols . . . . . . . . . . . . . 12 83 9.6. Impact On Network Operations . . . . . . . . . . . . . . . 12 84 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 85 10.1. Normative References . . . . . . . . . . . . . . . . . . . 12 86 10.2. Informative References . . . . . . . . . . . . . . . . . . 12 88 1. Introduction 90 The Path Computation Element communication Protocol (PCEP) provides 91 mechanisms for Path Computation Elements (PCEs) to perform path 92 computations in response to Path Computation Clients' (PCCs) 93 requests. 95 [RFC8051] describes general considerations for a stateful PCE 96 deployment and examines its applicability and benefits, as well as 97 its challenges and limitations through a number of use cases. 98 [RFC8231] describes a set of extensions to PCEP to provide stateful 99 control. A stateful PCE has access to not only the information 100 carried by the network's Interior Gateway Protocol (IGP), but also 101 the set of active paths and their reserved resources for its 102 computations. The additional state allows the PCE to compute 103 constrained paths while considering individual LSPs and their 104 interactions. 106 [RFC8281] describes the setup, maintenance and teardown of PCE- 107 initiated LSPs under the stateful PCE model. 109 [I-D.ietf-pce-association-group] introduces a generic mechanism to 110 create a grouping of LSPs. This grouping can then be used to define 111 association between sets of LSPs or between a set of LSPs and a set 112 of attributes. 114 [RFC8453] describes various Virtual Network (VN) operations initiated 115 by a customer/application. In this context, there is a need for 116 associating a set of LSPs with a VN "construct" to facilitate VN 117 operations in PCE architecture. This association allows the PCEs to 118 identify which LSPs belong to a certain VN. The PCE could then use 119 this association to optimize all LSPs belonging to the VN together. 120 The PCE could further take VN specific actions on the LSPs such as 121 relaxation of constraints, policy actions, setting default behavior 122 etc. 124 [RFC8637] examines the PCE and ACTN architecture and describes how 125 the PCE architecture is applicable to ACTN. [RFC6805] and [I-D.ietf- 126 pce-stateful-hpce] describes a hierarchy of stateful PCEs with Parent 127 PCE coordinating multi-domain path computation function between Child 128 PCE(s) and thus making it the base for PCE applicability for ACTN. In 129 this text child PCE would be same as Provisioning Network Controller 130 (PNC), and the parent PCE as Multi-domain Service Coordinator (MDSC) 132 [RFC8453]. 134 This document specifies a PCEP extension to associate a set of LSPs 135 based on Virtual Network (VN) (or customer). A Virtual Network (VN) 136 is a customer view of the TE network. Depending on the agreement 137 between client and provider various VN operations and VN views are 138 possible as described in [RFC8453]. 140 1.1. Requirements Language 142 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 143 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 144 "OPTIONAL" in this document are to be interpreted as described in BCP 145 14 [RFC2119] [RFC8174] when, and only when, they appear in all 146 capitals, as shown here. 148 2. Terminology 150 The terminology is as per [RFC4655], [RFC5440], [RFC6805], [RFC8231] 151 and [RFC8453]. 153 3. Operation Overview 155 As per [I-D.ietf-pce-association-group], LSPs are associated with 156 other LSPs with which they interact by adding them to a common 157 association group. 159 An association group based on VN is useful for various optimizations 160 that should be applied by considering all the LSPs in the 161 association. This includes, but not limited to - 163 o Path Computation: When computing path for a LSP, the impact of 164 this LSP, on the other LSPs belonging to the same VN is useful to 165 analyze. The aim would be optimize overall VN and all LSPs, rather 166 than a single LSP. Also, the optimization criteria such as 167 minimize the load of the most loaded link (MLL) [RFC5541] and 168 other could be applied for all the LSP belonging to the same VN, 169 identified by the VN association. 171 o Path Re-Optimization: The child PCE or the parent PCE would like 172 to use advanced path computation algorithm and optimization 173 technique that consider all the LSPs belonging to a VN/customer 174 and optimize them all together during the re-optimization. 176 This association is useful in PCEP session between parent PCE 177 (MDSC) and child PCE (PNC). When computing the path, the child PCE 178 (PNC) refer to the VN in the request from parent PCE (MDSC) and 179 map the VN to available network resources. Based on the 180 availability of resource and various constraints, the path is 181 computed and replied to the parent PCE (MDSC). The mapping 182 relationship between the VN and the network could be included as a 183 part of response as well. The figure describes a typical VN 184 operations using PCEP for illustration purpose. It is worth noting 185 that in a multi-domain scenario, the different domain is 186 controlled by different child PCEs. In order to set up the end-to- 187 end tunnel, multiple tunnel segments need to be stitched, by the 188 border nodes in each domain who receives the instruction from 189 their child PCE (PNC). 191 ****** 192 ..........*MDSC*.............................. 193 . ****** .. MPI . 194 . . . PCEP . 195 . . . PCInitiate LSPx . 196 . . . with VNAG = 10 . 197 . . . . 198 . . . . 199 . . . . 200 v v v . 201 ****** ****** ****** . 202 *PNC1* *PNC2* *PNC4* . 203 ****** ****** ****** . 204 +---------------+ +---------------+ +---------------+ . 205 |A |----| |----| C| . 206 | | | | | | . 207 |DOMAIN 1 |----|DOMAIN 2 |----|DOMAIN 4 | . 208 +------------B13+ +---------------+ +B43------------+ . 209 / . 210 ****** / . 211 *PNC3*<............/..................... 212 ****** / 213 +---------------+/ 214 B31 B34 215 | | 216 |DOMAIN 3 B| 217 +---------------+ 219 MDSC -> Parent PCE 220 PNC -> Child PCE 221 MPI -> PCEP 223 In this draft, this grouping is used to define associations between a 224 set of LSPs and a virtual network, a new association group is defined 225 below - 227 o VN Association Group (VNAG) 229 One new Association type is defined as described in the Association 230 object - 232 o Association type = TBD1 ("VN Association") for VNAG 234 The scope and handling of VNAG identifier is similar to the generic 235 association identifier defined in [I-D.ietf-pce-association-group]. 237 In this document VNAG object refers to an Association Object with the 238 Association type set to "VNAG". 240 Local polices on the PCE MAY define the computational and 241 optimization behavior for the LSPs in the VN. An LSP MUST NOT belong 242 to more than one VNAG. If an implementation encounters more than one 243 VNAG, it MUST consider the first occurrence and ignore the others. 245 [I-D.ietf-pce-association-group] specify the mechanism for the 246 capability advertisement of the association types supported by a PCEP 247 speaker by defining a ASSOC-Type-List TLV to be carried within an 248 OPEN object. This capability exchange for the association type 249 described in this document (i.e. VN Association Type) MUST be done 250 before using the policy association. Thus the PCEP speaker MUST 251 include the VN Association Type (TBD1) in the ASSOC-Type-List TLV 252 before using the VNAG in the PCEP messages. 254 This Association-Type is dynamic in nature and created by the Parent 255 PCE (MDSC) for the LSPs belonging to the same VN or customer. These 256 associations are conveyed via PCEP messages to the PCEP peer. 257 Operator-configured Association Range MUST NOT be set for this 258 association-type and MUST be ignored. 260 4. Extensions to PCEP 262 The format of VNAG is as per the ASSOCIATION object [I-D.ietf-pce- 263 association-group]. 265 This document defines one mandatory TLV "VIRTUAL-NETWORK-TLV" and one 266 new optional TLV "VENDOR-INFORMATION-TLV"; apart from this TLV, 267 VENDOR-INFORMATION-TLV can be used to carry arbitrary vendor specific 268 information. 270 o VIRTUAL-NETWORK-TLV: Used to communicate the VN Identifier. 272 o VENDOR-INFORMATION-TLV: Used to communicate arbitrary vendor 273 specific behavioral information, described in [RFC7470]. 275 The format of VIRTUAL-NETWORK-TLV is as follows. 277 0 1 2 3 278 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 279 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 280 | Type=TBD2 | Length (variable) | 281 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 282 | | 283 // Virtual Network Name // 284 | | 285 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 286 Figure 1: The VIRTUAL-NETWORK-TLV formats 288 Type: TBD2 (to be allocated by IANA) 290 Length: Variable Length 292 Virtual Network Name (variable): an unique symbolic name for the VN. 293 It SHOULD be a string of printable ASCII characters, without a NULL 294 terminator. The VN name is a human-readable string that identifies 295 a VN and can be specified at the beginning of the PCEP session. 296 After the mapping between VN and LSPs are accomplished, the VN name 297 can be used as a reference, to identify the LSPs from VN or identify 298 the VN from LSP information in the later PCEP session. Therefore it 299 MUST remain constant throughout an LSP's lifetime, which may span 300 across multiple consecutive PCEP sessions and/or PCC restarts. The 301 VN name MAY be specified by an operator or auto-generated by the 302 PCEP speaker. 304 The VIRTUAL-NETWORK-TLV MUST be included in VNAG object.If a PCEP 305 speaker receives the VNAG object without the VIRTUAL-NETWORK-TLV, it 306 MUST send a PCErr message with Error-Type=6 (mandatory object 307 missing) and Error-Value=TBD3 (VIRTUAL-NETWORK-TLV missing) and close 308 the session. 310 The format of VENDOR-INFORMATION-TLV is defined in [RFC7470]. 312 5. Applicability to H-PCE architecture 314 The ability to compute shortest constrained TE LSPs in Multiprotocol 315 Label Switching (MPLS) and Generalized MPLS (GMPLS) networks across 316 multiple domains has been identified as a key motivation for PCE 317 development. [RFC6805] describes a Hierarchical PCE (H-PCE) 318 architecture which can be used for computing end-to-end paths for 319 inter-domain MPLS Traffic Engineering (TE) and GMPLS Label Switched 320 Paths (LSPs). Within the hierarchical PCE architecture, the parent 321 PCE is used to compute a multi-domain path based on the domain 322 connectivity information. A child PCE may be responsible for a 323 single domain or multiple domains, it is used to compute the intra- 324 domain path based on its domain topology information. 326 [I-D.ietf-pce-stateful-hpce] introduces general considerations for 327 stateful PCE(s) in hierarchical PCE architecture. In particular, the 328 behavior changes and additions to the existing stateful PCE 329 mechanisms in the context of a H-PCE architecture. 331 In Stateful H-PCE architecture, the Parent PCE receives a virtual 332 network creation request by its client over its Northbound API. This 333 VN is uniquely identified by an Association ID in VNAG as well as the 334 VIRTUAL-NETWORK name. This VN may comprise multiple LSPs in the 335 network in a single domain or across multiple domains. 337 As the Parent PCE computes the optimum E2E paths for each tunnel in 338 VN, it MUST associate each LSP with the VN to which it belongs. 339 Parent PCE sends a PCInitiate Message with this association 340 information in the VNAG Object (See Section 4 for details). This in 341 effect binds an LSP that is to be instantiated at the child PCE with 342 the VN. 344 Whenever changes occur with the instantiated LSP in a domain network, 345 the domain child PCE reports the changes using a PCRpt Message in 346 which the VNAG Object indicates the relationship between the LSP and 347 the VN. 349 Whenever an update occurs with VNs in the Parent PCE (via the 350 client's request), the parent PCE sends an PCUpd Message to inform 351 each affected child PCE of this change. 353 The Child PCE could then use this association to optimize all LSPs 354 belonging to the same VN association together. The Child PCE could 355 further take VN specific actions on the LSPs such as relaxation of 356 constraints, policy actions, setting default behavior etc. The parent 357 PCE could also maintain all E2E LSP or per-domain path segments under 358 a single VN association. 360 6. Implementation Status 362 [Note to the RFC Editor - remove this section before publication, as 363 well as remove the reference to RFC 7942.] 365 This section records the status of known implementations of the 366 protocol defined by this specification at the time of posting of this 367 Internet-Draft, and is based on a proposal described in RFC 7942 368 [RFC7942]. The description of implementations in this section is 369 intended to assist the IETF in its decision processes in progressing 370 drafts to RFCs. Please note that the listing of any individual 371 implementation here does not imply endorsement by the IETF. 372 Furthermore, no effort has been spent to verify the information 373 presented here that was supplied by IETF contributors. This is not 374 intended as, and must not be construed to be, a catalog of available 375 implementations or their features. Readers are advised to note that 376 other implementations may exist. 378 According to RFC 7942, "this will allow reviewers and working groups 379 to assign due consideration to documents that have the benefit of 380 running code, which may serve as evidence of valuable experimentation 381 and feedback that have made the implemented protocols more mature. It 382 is up to the individual working groups to use this information as 383 they see fit". 385 6.1. Huawei's Proof of Concept based on ONOS 387 The PCE function was developed in the ONOS open source platform. This 388 extension was implemented on a private version as a proof of concept 389 to ACTN. 391 o Organization: Huawei 393 o Implementation: Huawei's PoC based on ONOS 395 o Description: PCEP as a southbound plugin was added to ONOS. To 396 support ACTN, this extension in PCEP is used. Refer 397 https://wiki.onosproject.org/display/ONOS/PCEP+Protocol 399 o Maturity Level: Prototype 401 o Coverage: Full 403 o Contact: satishk@huawei.com 405 7. Security Considerations 407 This document defines one new type for association, which do not 408 add any new security concerns beyond those discussed in [RFC5440], 409 [RFC8231] and [I-D.ietf-pce-association-group] in itself. 411 Some deployments may find the Virtual Network Name and the VN 412 associations as extra sensitive; and thus should employ suitable 413 PCEP security mechanisms like TCP-AO [RFC5925] or [RFC8253]. 415 8. IANA Considerations 417 8.1. Association Object Type Indicator 419 This document defines a new association type, originally defined 420 in [I-D.ietf-pce-association-group], for path protection. IANA is 421 requested to make the assignment of a new value for the sub- 422 registry "ASSOCIATION Type Field" (request to be created in [I- 423 D.ietf-pce-association-group]), as follows: 425 Value Name Reference 427 TBD1 VN Association Type [This I.D.] 429 8.2. PCEP TLV Type Indicator 430 This document defines a new TLV for carrying additional 431 information of LSPs within a path protection association group. 432 IANA is requested to make the assignment of a new value for the 433 existing "PCEP TLV Type Indicators" registry as follows: 435 Value Name Reference 437 TBD2 VIRTUAL-NETWORK-TLV [This I.D.] 439 8.3. PCEP Error 441 This document defines new Error-Type and Error-Value related to 442 path protection association. IANA is requested to allocate new 443 error values within the "PCEP-ERROR Object Error Types and Values" 444 sub- registry of the PCEP Numbers registry, as follows: 446 Error-Type Meaning 448 6 Mandatory Object missing 449 Error-value=TBD3: VIRTUAL-NETWORK TLV missing [This 450 I.D.] 452 9. Manageability Considerations 454 9.1. Control of Function and Policy 456 An operator MUST BE allowed to mark LSPs that belong to the same 457 VN. This could also be done automatically based on the VN 458 configuration. 460 9.2. Information and Data Models 462 The PCEP YANG module [I-D.ietf-pce-pcep-yang] should support the 463 association between LSPs including VN association. 465 9.3. Liveness Detection and Monitoring 467 Mechanisms defined in this document do not imply any new liveness 468 detection and monitoring requirements in addition to those already 469 listed in [RFC5440]. 471 9.4. Verify Correct Operations 473 Mechanisms defined in this document do not imply any new operation 474 verification requirements in addition to those already listed in 475 [RFC5440]. 477 9.5. Requirements On Other Protocols 479 Mechanisms defined in this document do not imply any new 480 requirements on other protocols. 482 9.6. Impact On Network Operations 484 Mechanisms defined in this document do not have any impact on 485 network operations in addition to those already listed in 486 [RFC5440]. 488 10. References 490 10.1. Normative References 492 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 493 Requirement Levels", BCP 14, RFC 2119, DOI 494 10.17487/RFC2119, March 1997. 496 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 497 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 498 March 2009. 500 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 501 2119 Key Words", BCP 14, RFC 8174, May 2017. 503 [RFC8231] E. Crabbe, I. Minei, J. Medved, and R. Varga, "PCEP 504 Extensions for Stateful PCE", RFC 8231, September 2017. 506 [RFC8281] E. Crabbe, et. al., "PCEP Extensions for PCE-initiated LSP 507 Setup in a Stateful PCE Model", RFC 8281, December 2017. 509 [I-D.ietf-pce-association-group] I, Minei, Ed., "PCEP Extensions for 510 Establishing Relationships Between Sets of LSPs", draft- 511 ietf-pce-association-group, work in progress. 513 10.2. Informative References 515 [RFC4655] Farrel, A., Vasseur, J.-P., and J. Ash, "A Path Computation 516 Element (PCE)-Based Architecture", RFC 4655, August 2006. 518 [RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP 519 Authentication Option", RFC 5925, DOI 10.17487/RFC5925, 520 June 2010, . 522 [RFC6805] A. Farrel and D. King, "The Application of the Path 523 Computation Element Architecture to the Determination of a 524 Sequence of Domains in MPLS and GMPLS", RFC 6805, November 525 2012. 527 [RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running 528 Code: The Implementation Status Section", BCP 205, RFC 529 7942, DOI 10.17487/RFC7942, July 2016. 531 [RFC8453] Ceccarelli, D., Ed. and Y. Lee, Ed., "Framework for 532 Abstraction and Control of TE Networks (ACTN)", RFC 8453, 533 DOI 10.17487/RFC8453, August 2018, . 536 [RFC8637] Dhody D., Lee Y., and D. Ceccarelli, "Applicability of Path 537 Computation Element (PCE) for Abstraction and Control of TE 538 Networks (ACTN)", RFC 8637, July 2019, . 541 [I-D.ietf-pce-stateful-hpce] Dhody, D. and Lee, Y., "Hierarchical 542 Stateful Path Computation Element (PCE)", 543 draft-ietf-pce-stateful-hpce, work in progress. 545 [RFC5541] Le Roux, JL., Vasseur, JP., and Y. Lee, "Encoding of 546 Objective Functions in the Path Computation Element 547 Communication Protocol (PCEP)", RFC 5541, 548 DOI 10.17487/RFC5541, June 2009, 549 . 551 [RFC7470] Zhang, F. and A. Farrel, "Conveying Vendor-Specific 552 Constraints in the Path Computation Element Communication 553 Protocol", RFC 7470, DOI 10.17487/RFC7470, March 2015, 554 . 556 [RFC8051] Zhang, X., Ed. and I. Minei, Ed., "Applicability of a 557 Stateful Path Computation Element (PCE)", RFC 8051, 558 DOI 10.17487/RFC8051, January 2017, 559 . 561 [RFC8253] Lopez, D., Dios, O., Wu, W., and D. Dhody, "Secure 562 Transport for PCEP", RFC 8253, October 2017 . 564 [I-D.ietf-pce-pcep-yang] 565 Dhody, D., Hardwick, J., Beeram, V., and j. 566 jefftant@gmail.com, "A YANG Data Model for Path 567 Computation Element Communications Protocol (PCEP)", 568 draft-ietf-pce-pcep-yang (work in progress). 570 Contributor's Addresses 572 Dhruv Dhody 573 Huawei Technologies 574 Divyashree Technopark, Whitefield 575 Bangalore, Karnataka 560066 576 India 578 Email: dhruv.ietf@gmail.com 580 Qin Wu 581 Huawei Technologies 582 China 584 Email: bill.wu@huawei.com 586 Xian Zhang 587 Huawei Technologies 588 China 590 Email: zhang.xian@huawei.com 592 Author's Addresses 594 Young Lee 595 Sung Kyun Kwan University (SKKU) 596 Seoul South Korea 598 Email: younglee.tx@gmail.com 600 Haomian Zheng 601 Huawei Technologies 602 China 604 Email: zhenghaomian@huawei.com 606 Daniele Ceccarelli 607 Ericsson 608 Torshamnsgatan,48 609 Stockholm, 610 Sweden 612 Email: daniele.ceccarelli@ericsson.com