



PCE Working Group                                                 Y. Lee
Internet-Draft                                                   Samsung
Intended status: Standards Track                                H. Zheng
Expires: 27 April 2023                               Huawei Technologies
                                                           D. Ceccarelli
                                                                Ericsson
                                                         24 October 2022


 Path Computation Element Communication Protocol (PCEP) extensions for
  establishing relationships between sets of Label Switched Paths and
                            Virtual Networks
                    draft-ietf-pce-vn-association-11

Abstract

   This document describes how to extend the Path Computation Element
   (PCE) Communication Protocol (PCEP) association mechanism introduced
   by the PCEP Association Group specification, to further associate
   sets of Label Switched Paths (LSPs) with a higher-level structure
   such as a Virtual Network (VN) requested by a customer or
   application.  This extended association mechanism can be used to
   facilitate control of virtual network using the PCE architecture.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on 27 April 2023.

Copyright Notice

   Copyright (c) 2022 IETF Trust and the persons identified as the
   document authors.  All rights reserved.






Lee, et al.               Expires 27 April 2023                 [Page 1]

Internet-Draft             PCE VN Association               October 2022


   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents (https://trustee.ietf.org/
   license-info) in effect on the date of publication of this document.
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.  Code Components
   extracted from this document must include Revised BSD License text as
   described in Section 4.e of the Trust Legal Provisions and are
   provided without warranty as described in the Revised BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
     1.1.  Requirement Language  . . . . . . . . . . . . . . . . . .   3
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   4
   3.  Operation Overview  . . . . . . . . . . . . . . . . . . . . .   4
   4.  Extensions to PCEP  . . . . . . . . . . . . . . . . . . . . .   6
   5.  Implementation Status . . . . . . . . . . . . . . . . . . . .   8
     5.1.  Huawei's Proof of Concept based on ONOS . . . . . . . . .   8
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .   9
   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   9
     7.1.  Association Object Type Indicator . . . . . . . . . . . .   9
     7.2.  PCEP TLV Type Indicator . . . . . . . . . . . . . . . . .   9
     7.3.  PCEP Error  . . . . . . . . . . . . . . . . . . . . . . .   9
   8.  Manageability Considerations  . . . . . . . . . . . . . . . .  10
     8.1.  Control of Function and Policy  . . . . . . . . . . . . .  10
     8.2.  Information and Data Models . . . . . . . . . . . . . . .  10
     8.3.  Liveness Detection and Monitoring . . . . . . . . . . . .  10
     8.4.  Verify Correct Operations . . . . . . . . . . . . . . . .  10
     8.5.  Requirements On Other Protocols . . . . . . . . . . . . .  10
     8.6.  Impact On Network Operations  . . . . . . . . . . . . . .  10
   9.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  10
     9.1.  Normative References  . . . . . . . . . . . . . . . . . .  10
     9.2.  Informative References  . . . . . . . . . . . . . . . . .  11
   Appendix A.  Contributors . . . . . . . . . . . . . . . . . . . .  12
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  13

1.  Introduction

   The Path Computation Element Communication Protocol (PCEP) provides
   mechanisms for Path Computation Elements (PCEs) to perform path
   computations in response to requests from Path Computation Clients
   (PCCs) [RFC5440].

   [RFC8051] describes general considerations for a stateful PCE
   deployment and examines its applicability and benefits, as well as
   its challenges and limitations through a number of use cases.
   [RFC8231] describes a set of extensions to PCEP to provide stateful
   control.  For its computations, a stateful PCE has access to not only



Lee, et al.               Expires 27 April 2023                 [Page 2]

Internet-Draft             PCE VN Association               October 2022


   the information carried by the network's Interior Gateway Protocol
   (IGP), but also the set of active paths and their reserved resources.
   The additional state allows the PCE to compute constrained paths
   while considering individual Label Switched Paths (LSPs) and their
   interactions.

   [RFC8281] describes the setup, maintenance and teardown of PCE-
   initiated LSPs under the stateful PCE model.

   [RFC8697] introduces a generic mechanism to create a grouping of
   LSPs.  This grouping can then be used to define associations between
   sets of LSPs or between a set of LSPs and a set of attributes.

   [RFC8453] introduces a framework for Abstraction and Control of TE
   Networks (ACTN) and describes various Virtual Network (VN) operations
   initiated by a customer or application.  A VN is a customer view of
   the TE network.  Depending on the agreement between client and
   provider, various VN operations and VN views are possible.

   [RFC8637] examines the PCE and ACTN architectures and describes how
   the PCE architecture is applicable to ACTN.  [RFC6805] and [RFC8751]
   describes a hierarchy of stateful PCEs with Parent PCE coordinating
   multi-domain path computation function between Child PCEs, and thus
   making it the base for PCE applicability for ACTN.  As [RFC8751]
   explains, in the context of ACTN, the Child PCE is identified with
   the Provisioning Network Controller (PNC), and the Parent PCE is
   identified with the Multi-domain Service Coordinator (MDSC).

   In this context, there is a need to associate a set of LSPs with a VN
   "construct" to facilitate VN operations in the PCE architecture.
   This association allows a PCE to identify which LSPs belong to a
   certain VN.  The PCE could then use this association to optimize all
   LSPs belonging to the VN at once.  The PCE could further take VN-
   specific actions on the LSPs, such as relaxation of constraints,
   policy actions, setting default behavior, etc.

   This document specifies a PCEP extension to associate a set of LSPs
   based on their Virtual Network (VN).

1.1.  Requirement Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
   "OPTIONAL" in this document are to be interpreted as described in BCP
   14 [RFC2119] [RFC8174] when, and only when, they appear in all
   capitals, as shown here.





Lee, et al.               Expires 27 April 2023                 [Page 3]

Internet-Draft             PCE VN Association               October 2022


2.  Terminology

   The terminology is as per [RFC4655], [RFC5440], [RFC6805], [RFC8231]
   and [RFC8453].

3.  Operation Overview

   As per [RFC8697], LSPs are associated with other LSPs with which they
   interact by adding them to a common association group.

   An association group based on VN is useful for various optimizations
   that should be applied by considering all the LSPs in the
   association.  This includes, but is not limited to -

   *  Path Computation: When computing a path for an LSP, it is useful
      to analyze the impact of this LSP on the other LSPs belonging to
      the same VN.  The aim would be to optimize all LSPs belonging to
      the VN rather than a single LSP.  Also, the optimization criteria
      (such as minimizing the load of the most loaded link (MLL)
      [RFC5541]) could be applied for all the LSPs belonging to the VN
      identified by the VN association.

   *  Path Re-Optimization: The PCE would like to use advanced path
      computation algorithms and optimization techniques that consider
      all the LSPs belonging to a VN, and optimize them all together
      during the path re-optimization.

   In this document we define a new association group called the VN
   Association Group (VNAG).  This grouping is used to define the
   association between a set of LSPs and a virtual network.

   The Association Object contains a field to identify the type of
   association, and this document defines a new Association Type value
   of TBD1 to indicate that the association is a "VN Association".  The
   Association Identifier in the Association Object is the VNAG
   Identifier and is handled in the same way as the generic association
   identifier defined in [RFC8697].

   In this document, "VNAG object" refers to an Association Object with
   the Association type set to "VN Association".

   Local polices on the PCE define the computational and optimization
   behavior for the LSPs in the VN.  An LSP MUST NOT belong to more than
   one VNAG.  If an implementation encounters more than one VNAG object
   in a PCEP message, it MUST process the first occurrence and it MUST
   ignore the others.





Lee, et al.               Expires 27 April 2023                 [Page 4]

Internet-Draft             PCE VN Association               October 2022


   [RFC8697] specifies the mechanism by which a PCEP speaker can
   advertise which association types it supports.  This is done using
   the ASSOC-Type-List TLV carried within an OPEN object.  A PCEP
   speaker MUST include the VN Association Type (TBD1) in the ASSOC-
   Type-List TLV before using the VNAG object in a PCEP message.  As per
   [RFC8697], if the implementation does not support the VN Association
   Type, it will return a PCErr message with Error-Type 26 "Association
   Error" and Error-value 1 "Association Type is not supported".

   The Association IDs (VNAG IDs) for this Association Type are dynamic
   in nature (and created by the Parent PCE (MDSC) based on the VN
   operations for the LSPs belonging to the same VN).  Operator
   configuration of VNAG IDs is not supported, so there is no need for
   an Operator-Configured Association Range to be set.  Thus, the VN
   Association Type (TBD1) MUST NOT be present in the Operator-
   Configured Association Range TLV if that TLV is present in the OPEN
   object.  If an implementation encounters the VN Association Type
   (TBD1) in an Operator-Configured Association Range TLV, it MUST
   ignore the associated Start-Assoc-ID and Range values.

   This association is useful in a PCEP session between a parent PCE
   (MDSC) and a child PCE (PNC).  When computing the path, the child PCE
   (PNC) refers to the VN association in the request from the parent PCE
   (MDSC) and maps the VN to the associated LSPs and network resources.
   From the perspective of the Parent PCE, it receives a virtual network
   creation request by its customer, with the VN uniquely identified by
   the Association parameters (section 6.1.4 of [RFC8697]) in the VNAG
   or the Virtual Network identifier encoded in the VIRTUAL-NETWORK-TLV.
   This VN may comprise multiple LSPs in the network in a single domain
   or across multiple domains.  The Parent PCE sends a PCInitiate
   Message with this association information in the VNAG Object.  This
   in effect binds an LSP that is to be instantiated at the child PCE
   with the VN.  The VN association information MUST be included as a
   part of the first PCRpt message.  Figure 1 shows an example of a
   typical VN operation using PCEP.  It is worth noting that in a multi-
   domain scenario, the different domains are controlled by different
   child PCEs.  In order to set up the cross-domain tunnel, multiple
   segments need to be stitched, by the border nodes in each domain who
   receive the instruction from their child PCE (PNC).












Lee, et al.               Expires 27 April 2023                 [Page 5]

Internet-Draft             PCE VN Association               October 2022


                                    ******
                          ..........*MDSC*..............................
                       .            ****** ..                   MPI    .
                    .                .        .                 PCEP   .
                 .                   .          .   PCInitiate LSPx    .
               .                    .             .   with VNAG        .
              .                    .                .                  .
             .                    .                  .                 .
            .                    .                    .                .
            v                    v                    v                .
          ******               ******               ******             .
          *PNC1*               *PNC2*               *PNC4*             .
          ******               ******               ******             .
          +---------------+    +---------------+    +---------------+  .
          |               |----|               |----|              C|  .
          |               |    |               |    |               |  .
          |DOMAIN 1       |----|DOMAIN 2       |----|DOMAIN 4       |  .
          +---------------+    +---------------+    +---------------+  .
                                                   /                   .
                              ******              /                    .
                              *PNC3*<............/......................
                              ******            /
                              +---------------+/
                              |               |
                              |               |
                              |DOMAIN 3       |
                              +---------------+

          MDSC -> Parent PCE
          PNC  -> Child  PCE
          MPI  -> PCEP

          Figure 1: Example of VN operations in H-PCE Architecture

   Whenever changes occur with the instantiated LSP in a domain network,
   the domain child PCE reports the changes using a PCRpt Message in
   which the VNAG Object indicates the relationship between the LSP and
   the VN.

   Whenever an update occurs with VNs in the Parent PCE (due to the
   customer's request), the parent PCE sends an PCUpd Message to inform
   each affected child PCE of this change.

4.  Extensions to PCEP

   The format of VNAG is as per the ASSOCIATION object [RFC8697].





Lee, et al.               Expires 27 April 2023                 [Page 6]

Internet-Draft             PCE VN Association               October 2022


   This document defines one new mandatory TLV "VIRTUAL-NETWORK-TLV".
   Optionally, the new TLV can be jointly used with the existing
   "VENDOR-INFORMATION-TLV" specified in [RFC7470] as described below:

   *  VIRTUAL-NETWORK-TLV: Used to communicate the Virtual Network
      Identifier.

   *  VENDOR-INFORMATION-TLV: Used to communicate arbitrary vendor
      specific behavioral information, described in [RFC7470].

   The format of VIRTUAL-NETWORK-TLV is as follows.

       0                   1                   2                   3
       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |           Type=TBD2           |       Length (variable)       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      //                   Virtual Network Identifier                //
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                 Figure 2: The VIRTUAL-NETWORK-TLV formats

   Type (16-bits): TBD2 (to be allocated by IANA)

   Length (16-bits): indicates the length of the value portion of the
   TLV in octets and MUST be greater than 0.  The TLV MUST be zero-
   padded so that the TLV is 4-octet aligned.

   Virtual Network Identifier (variable): a symbolic name for the VN
   that uniquely identifies the VN.  It SHOULD be a string of printable
   ASCII [RFC0020] characters (i.e., 0x20 to 0x7E), without a NULL
   terminator.  The Virtual Network Identifier is a human-readable
   string that identifies a VN, it can be specified with the association
   information which may be conveyed in a VENDOR-INFORMATION-TLV.  An
   implementation uses the Virtual Network Identifier to maintain a
   mapping to the VN association group and the LSPs associated with the
   VN.  The Virtual Network Identifier MAY be specified by the customer
   or set via an operator policy or auto-generated by the PCEP speaker.

   The VIRTUAL-NETWORK-TLV MUST be included in VNAG object.  If a PCEP
   speaker receives the VNAG object without the VIRTUAL-NETWORK-TLV, it
   MUST send a PCErr message with Error-Type=6 (mandatory object
   missing) and Error-Value=TBD3 (VIRTUAL-NETWORK-TLV missing) and close
   the session.

   The format of VENDOR-INFORMATION-TLV is defined in [RFC7470].




Lee, et al.               Expires 27 April 2023                 [Page 7]

Internet-Draft             PCE VN Association               October 2022


   If a PCEP speaker receives a VN ASSOCIATION object with a TLV that
   violates the rules specified in this document, the PCEP speaker MUST
   send a PCErr message with Error-Type = 10 (Reception of an invalid
   object) and Error-value = 11 (Malformed object) and MUST close the
   PCEP session.

5.  Implementation Status

   [Note to the RFC Editor - remove this section before publication, as
   well as remove the reference to RFC 7942.]

   This section records the status of known implementations of the
   protocol defined by this specification at the time of posting of this
   Internet-Draft, and is based on a proposal described in [RFC7942].
   The description of implementations in this section is intended to
   assist the IETF in its decision processes in progressing drafts to
   RFCs.  Please note that the listing of any individual implementation
   here does not imply endorsement by the IETF.  Furthermore, no effort
   has been spent to verify the information presented here that was
   supplied by IETF contributors.  This is not intended as, and must not
   be construed to be, a catalog of available implementations or their
   features.  Readers are advised to note that other implementations may
   exist.

   According to [RFC7942], "this will allow reviewers and working groups
   to assign due consideration to documents that have the benefit of
   running code, which may serve as evidence of valuable experimentation
   and feedback that have made the implemented protocols more mature.
   It is up to the individual working groups to use this information as
   they see fit".

5.1.  Huawei's Proof of Concept based on ONOS

   The PCE function was developed in the ONOS open source platform.
   This extension was implemented on a private version as a proof of
   concept to ACTN.

   *  Organization: Huawei

   *  Implementation: Huawei's PoC based on ONOS

   *  Description: PCEP as a southbound plugin was added to ONOS.  To
      support ACTN, this extension in PCEP is used.  Refer
      https://wiki.onosproject.org/display/ONOS/PCEP+Protocol

   *  Maturity Level: Prototype

   *  Coverage: Full



Lee, et al.               Expires 27 April 2023                 [Page 8]

Internet-Draft             PCE VN Association               October 2022


   *  Contact: satishk@huawei.com

6.  Security Considerations

   The security considerations described in [RFC5440], [RFC8231] and
   [RFC8281] apply to the extensions defined in this document as well.

   One new Association Type (VN Association) for the ASSOCIATION object
   is introduced in this document.  Additional security considerations
   related to LSP associations due to a malicious PCEP speaker are
   described in [RFC8697] and apply to the VN Association type.  Hence,
   securing the PCEP session using Transport Layer Security (TLS)
   [RFC8253] is RECOMMENDED.

7.  IANA Considerations

7.1.  Association Object Type Indicator

   IANA is requested to make the assignment of a new value in the sub-
   registry "ASSOCIATION Type Field" within the "Path Computation
   Element Protocol (PCEP) Numbers" registry, as follows:

         Value     Name                        Reference

         TBD1      VN Association Type         [This I.D.]

7.2.  PCEP TLV Type Indicator

   IANA is requested to make the assignment of a new value for the
   existing "PCEP TLV Type Indicators" sub-registry within the "Path
   Computation Element Protocol (PCEP) Numbers" registry, as follows:

         Value     Name                        Reference

         TBD2      VIRTUAL-NETWORK-TLV         [This I.D.]

7.3.  PCEP Error

   IANA is requested to allocate new error value within the "PCEP-ERROR
   Object Error Types and Values" sub-registry within the "Path
   Computation Element Protocol (PCEP) Numbers" registry, as follows:

         Error-Type  Meaning

         6           Mandatory Object missing
                     Error-value=TBD3: VIRTUAL-NETWORK TLV missing [This
         I.D.]




Lee, et al.               Expires 27 April 2023                 [Page 9]

Internet-Draft             PCE VN Association               October 2022


8.  Manageability Considerations

8.1.  Control of Function and Policy

   An operator MUST be allowed to mark LSPs that belong to the same VN.
   This could also be done automatically based on the VN configuration.

8.2.  Information and Data Models

   The PCEP YANG module [I-D.ietf-pce-pcep-yang] should support the
   association between LSPs including VN association.

8.3.  Liveness Detection and Monitoring

   Mechanisms defined in this document do not imply any new liveness
   detection and monitoring requirements in addition to those already
   listed in [RFC5440].

8.4.  Verify Correct Operations

   Mechanisms defined in this document do not imply any new operation
   verification requirements in addition to those already listed in
   [RFC5440].

8.5.  Requirements On Other Protocols

   Mechanisms defined in this document do not imply any new requirements
   on other protocols.

8.6.  Impact On Network Operations

   [RFC8637] describe the network operations when PCE is used for VN
   operations.  Section 3 further specifies the operations when VN
   associations are used.

9.  References

9.1.  Normative References

   [RFC0020]  Cerf, V., "ASCII format for network interchange", STD 80,
              RFC 20, DOI 10.17487/RFC0020, October 1969,
              <https://www.rfc-editor.org/info/rfc20>.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.




Lee, et al.               Expires 27 April 2023                [Page 10]

Internet-Draft             PCE VN Association               October 2022


   [RFC5440]  Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation
              Element (PCE) Communication Protocol (PCEP)", RFC 5440,
              DOI 10.17487/RFC5440, March 2009,
              <https://www.rfc-editor.org/info/rfc5440>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/info/rfc8174>.

   [RFC8231]  Crabbe, E., Minei, I., Medved, J., and R. Varga, "Path
              Computation Element Communication Protocol (PCEP)
              Extensions for Stateful PCE", RFC 8231,
              DOI 10.17487/RFC8231, September 2017,
              <https://www.rfc-editor.org/info/rfc8231>.

   [RFC8253]  Lopez, D., Gonzalez de Dios, O., Wu, Q., and D. Dhody,
              "PCEPS: Usage of TLS to Provide a Secure Transport for the
              Path Computation Element Communication Protocol (PCEP)",
              RFC 8253, DOI 10.17487/RFC8253, October 2017,
              <https://www.rfc-editor.org/info/rfc8253>.

   [RFC8281]  Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "Path
              Computation Element Communication Protocol (PCEP)
              Extensions for PCE-Initiated LSP Setup in a Stateful PCE
              Model", RFC 8281, DOI 10.17487/RFC8281, December 2017,
              <https://www.rfc-editor.org/info/rfc8281>.

   [RFC8697]  Minei, I., Crabbe, E., Sivabalan, S., Ananthakrishnan, H.,
              Dhody, D., and Y. Tanaka, "Path Computation Element
              Communication Protocol (PCEP) Extensions for Establishing
              Relationships between Sets of Label Switched Paths
              (LSPs)", RFC 8697, DOI 10.17487/RFC8697, January 2020,
              <https://www.rfc-editor.org/info/rfc8697>.

9.2.  Informative References

   [RFC4655]  Farrel, A., Vasseur, J.-P., and J. Ash, "A Path
              Computation Element (PCE)-Based Architecture", RFC 4655,
              DOI 10.17487/RFC4655, August 2006,
              <https://www.rfc-editor.org/info/rfc4655>.

   [RFC6805]  King, D., Ed. and A. Farrel, Ed., "The Application of the
              Path Computation Element Architecture to the Determination
              of a Sequence of Domains in MPLS and GMPLS", RFC 6805,
              DOI 10.17487/RFC6805, November 2012,
              <https://www.rfc-editor.org/info/rfc6805>.





Lee, et al.               Expires 27 April 2023                [Page 11]

Internet-Draft             PCE VN Association               October 2022


   [RFC7942]  Sheffer, Y. and A. Farrel, "Improving Awareness of Running
              Code: The Implementation Status Section", BCP 205,
              RFC 7942, DOI 10.17487/RFC7942, July 2016,
              <https://www.rfc-editor.org/info/rfc7942>.

   [RFC8453]  Ceccarelli, D., Ed. and Y. Lee, Ed., "Framework for
              Abstraction and Control of TE Networks (ACTN)", RFC 8453,
              DOI 10.17487/RFC8453, August 2018,
              <https://www.rfc-editor.org/info/rfc8453>.

   [RFC8637]  Dhody, D., Lee, Y., and D. Ceccarelli, "Applicability of
              the Path Computation Element (PCE) to the Abstraction and
              Control of TE Networks (ACTN)", RFC 8637,
              DOI 10.17487/RFC8637, July 2019,
              <https://www.rfc-editor.org/info/rfc8637>.

   [RFC5541]  Le Roux, JL., Vasseur, JP., and Y. Lee, "Encoding of
              Objective Functions in the Path Computation Element
              Communication Protocol (PCEP)", RFC 5541,
              DOI 10.17487/RFC5541, June 2009,
              <https://www.rfc-editor.org/info/rfc5541>.

   [RFC7470]  Zhang, F. and A. Farrel, "Conveying Vendor-Specific
              Constraints in the Path Computation Element Communication
              Protocol", RFC 7470, DOI 10.17487/RFC7470, March 2015,
              <https://www.rfc-editor.org/info/rfc7470>.

   [RFC8051]  Zhang, X., Ed. and I. Minei, Ed., "Applicability of a
              Stateful Path Computation Element (PCE)", RFC 8051,
              DOI 10.17487/RFC8051, January 2017,
              <https://www.rfc-editor.org/info/rfc8051>.

   [RFC8751]  Dhody, D., Lee, Y., Ceccarelli, D., Shin, J., and D. King,
              "Hierarchical Stateful Path Computation Element (PCE)",
              RFC 8751, DOI 10.17487/RFC8751, March 2020,
              <https://www.rfc-editor.org/info/rfc8751>.

   [I-D.ietf-pce-pcep-yang]
              Dhody, D., Beeram, V. P., Hardwick, J., and J. Tantsura,
              "A YANG Data Model for Path Computation Element
              Communications Protocol (PCEP)", Work in Progress,
              Internet-Draft, draft-ietf-pce-pcep-yang-20, 23 October
              2022, <https://datatracker.ietf.org/api/v1/doc/document/
              draft-ietf-pce-pcep-yang/>.

Appendix A.  Contributors





Lee, et al.               Expires 27 April 2023                [Page 12]

Internet-Draft             PCE VN Association               October 2022


      Dhruv Dhody
      Huawei Technologies
      Divyashree Technopark, Whitefield
      Bangalore, Karnataka  560066
      India
      Email: dhruv.ietf@gmail.com

      Qin Wu
      Huawei Technologies
      China
      Email: bill.wu@huawei.com

      Xian Zhang
      Huawei Technologies
      China
      Email: zhang.xian@huawei.com

      Adrian Farrel
      Old Dog Consulting
      Email: adrian@olddog.co.uk

Authors' Addresses

   Young Lee
   Samsung
   Seoul
   South Korea
   Email: younglee.tx@gmail.com


   Haomian Zheng
   Huawei Technologies
   H1, Huawei Xiliu Beipo Village, Songshan Lake
   Dongguan
   Guangdong, 523808
   China
   Email: zhenghaomian@huawei.com


   Daniele Ceccarelli
   Ericsson
   Torshamnsgatan,48
   Stockholm
   Sweden
   Email: daniele.ceccarelli@ericsson.com






Lee, et al.               Expires 27 April 2023                [Page 13]
