<?xml version='1.0' encoding='utf-8'?>
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" version="3" category="std" consensus="true" docName="draft-ietf-pce-vn-association-11" indexInclude="true" ipr="trust200902" number="9358" prepTime="2023-02-14T14:09:45" scripts="Common,Latin" sortRefs="true" submissionType="IETF" symRefs="true" tocDepth="3" tocInclude="true" xml:lang="en">
  <link href="https://datatracker.ietf.org/doc/draft-ietf-pce-vn-association-11" rel="prev"/>
  <link href="https://dx.doi.org/10.17487/rfc9358" rel="alternate"/>
  <link href="urn:issn:2070-1721" rel="alternate"/>
  <front>
    <title abbrev="PCEP VN Association">Path Computation Element Communication Protocol (PCEP) Extensions for Establishing Relationships between Sets of Label Switched Paths and Virtual Networks</title>
    <seriesInfo name="RFC" value="9358" stream="IETF"/>
    <author fullname="Young Lee" initials="Y." surname="Lee">
      <organization showOnFrontPage="true">Samsung Electronics</organization>
      <address>
        <postal>
          <street/>
          <city>Seoul</city>
          <region/>
          <code/>
          <country>Republic of Korea</country>
        </postal>
        <email>younglee.tx@gmail.com</email>
      </address>
    </author>
    <author initials="H." surname="Zheng" fullname="Haomian Zheng">
      <organization showOnFrontPage="true">Huawei Technologies</organization>
      <address>
        <postal>
          <street>H1, Huawei Xiliu Beipo Village Songshan Lake</street>
          <city>Dongguan</city>
          <region>Guangdong</region>
          <code>523808</code>
          <country>China</country>
        </postal>
        <email>zhenghaomian@huawei.com</email>
      </address>
    </author>
    <author initials="D." surname="Ceccarelli" fullname="Daniele Ceccarelli">
      <organization showOnFrontPage="true">Cisco Systems</organization>
      <address>
        <postal>
          <street>Torshamnsgatan,48</street>
          <city>Stockholm</city>
          <region/>
          <code/>
          <country>Sweden</country>
        </postal>
        <email>daniele.ietf@gmail.com</email>
      </address>
    </author>
    <date month="02" year="2023"/>
    <area>rtg</area>
    <workgroup>pce</workgroup>
    <abstract pn="section-abstract">
      <t indent="0" pn="section-abstract-1"> This document describes how to extend the Path Computation Element
Communication Protocol (PCEP) association mechanism introduced by RFC 8697 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 a VN using the PCE architecture.</t>
    </abstract>
    <boilerplate>
      <section anchor="status-of-memo" numbered="false" removeInRFC="false" toc="exclude" pn="section-boilerplate.1">
        <name slugifiedName="name-status-of-this-memo">Status of This Memo</name>
        <t indent="0" pn="section-boilerplate.1-1">
            This is an Internet Standards Track document.
        </t>
        <t indent="0" pn="section-boilerplate.1-2">
            This document is a product of the Internet Engineering Task Force
            (IETF).  It represents the consensus of the IETF community.  It has
            received public review and has been approved for publication by
            the Internet Engineering Steering Group (IESG).  Further
            information on Internet Standards is available in Section 2 of 
            RFC 7841.
        </t>
        <t indent="0" pn="section-boilerplate.1-3">
            Information about the current status of this document, any
            errata, and how to provide feedback on it may be obtained at
            <eref target="https://www.rfc-editor.org/info/rfc9358" brackets="none"/>.
        </t>
      </section>
      <section anchor="copyright" numbered="false" removeInRFC="false" toc="exclude" pn="section-boilerplate.2">
        <name slugifiedName="name-copyright-notice">Copyright Notice</name>
        <t indent="0" pn="section-boilerplate.2-1">
            Copyright (c) 2023 IETF Trust and the persons identified as the
            document authors. All rights reserved.
        </t>
        <t indent="0" pn="section-boilerplate.2-2">
            This document is subject to BCP 78 and the IETF Trust's Legal
            Provisions Relating to IETF Documents
            (<eref target="https://trustee.ietf.org/license-info" brackets="none"/>) 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.
        </t>
      </section>
    </boilerplate>
    <toc>
      <section anchor="toc" numbered="false" removeInRFC="false" toc="exclude" pn="section-toc.1">
        <name slugifiedName="name-table-of-contents">Table of Contents</name>
        <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1">
          <li pn="section-toc.1-1.1">
            <t indent="0" keepWithNext="true" pn="section-toc.1-1.1.1"><xref derivedContent="1" format="counter" sectionFormat="of" target="section-1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-introduction">Introduction</xref></t>
          </li>
          <li pn="section-toc.1-1.2">
            <t indent="0" keepWithNext="true" pn="section-toc.1-1.2.1"><xref derivedContent="2" format="counter" sectionFormat="of" target="section-2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-terminology">Terminology</xref></t>
          </li>
          <li pn="section-toc.1-1.3">
            <t indent="0" keepWithNext="true" pn="section-toc.1-1.3.1"><xref derivedContent="3" format="counter" sectionFormat="of" target="section-3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-operation-overview">Operation Overview</xref></t>
          </li>
          <li pn="section-toc.1-1.4">
            <t indent="0" pn="section-toc.1-1.4.1"><xref derivedContent="4" format="counter" sectionFormat="of" target="section-4"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-extensions-to-pcep">Extensions to PCEP</xref></t>
          </li>
          <li pn="section-toc.1-1.5">
            <t indent="0" pn="section-toc.1-1.5.1"><xref derivedContent="5" format="counter" sectionFormat="of" target="section-5"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-security-considerations">Security Considerations</xref></t>
          </li>
          <li pn="section-toc.1-1.6">
            <t indent="0" pn="section-toc.1-1.6.1"><xref derivedContent="6" format="counter" sectionFormat="of" target="section-6"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-iana-considerations">IANA Considerations</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.6.2">
              <li pn="section-toc.1-1.6.2.1">
                <t indent="0" pn="section-toc.1-1.6.2.1.1"><xref derivedContent="6.1" format="counter" sectionFormat="of" target="section-6.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-association-object-type-ind">ASSOCIATION Object Type Indicator</xref></t>
              </li>
              <li pn="section-toc.1-1.6.2.2">
                <t indent="0" pn="section-toc.1-1.6.2.2.1"><xref derivedContent="6.2" format="counter" sectionFormat="of" target="section-6.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-pcep-tlv-type-indicator">PCEP TLV Type Indicator</xref></t>
              </li>
              <li pn="section-toc.1-1.6.2.3">
                <t indent="0" pn="section-toc.1-1.6.2.3.1"><xref derivedContent="6.3" format="counter" sectionFormat="of" target="section-6.3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-pcep-error">PCEP Error</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.7">
            <t indent="0" pn="section-toc.1-1.7.1"><xref derivedContent="7" format="counter" sectionFormat="of" target="section-7"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-manageability-consideration">Manageability Considerations</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.7.2">
              <li pn="section-toc.1-1.7.2.1">
                <t indent="0" pn="section-toc.1-1.7.2.1.1"><xref derivedContent="7.1" format="counter" sectionFormat="of" target="section-7.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-control-of-function-and-pol">Control of Function and Policy</xref></t>
              </li>
              <li pn="section-toc.1-1.7.2.2">
                <t indent="0" pn="section-toc.1-1.7.2.2.1"><xref derivedContent="7.2" format="counter" sectionFormat="of" target="section-7.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-information-and-data-models">Information and Data Models</xref></t>
              </li>
              <li pn="section-toc.1-1.7.2.3">
                <t indent="0" pn="section-toc.1-1.7.2.3.1"><xref derivedContent="7.3" format="counter" sectionFormat="of" target="section-7.3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-liveness-detection-and-moni">Liveness Detection and Monitoring</xref></t>
              </li>
              <li pn="section-toc.1-1.7.2.4">
                <t indent="0" pn="section-toc.1-1.7.2.4.1"><xref derivedContent="7.4" format="counter" sectionFormat="of" target="section-7.4"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-verification-of-correct-ope">Verification of Correct Operations</xref></t>
              </li>
              <li pn="section-toc.1-1.7.2.5">
                <t indent="0" pn="section-toc.1-1.7.2.5.1"><xref derivedContent="7.5" format="counter" sectionFormat="of" target="section-7.5"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-requirements-on-other-proto">Requirements on Other Protocols</xref></t>
              </li>
              <li pn="section-toc.1-1.7.2.6">
                <t indent="0" pn="section-toc.1-1.7.2.6.1"><xref derivedContent="7.6" format="counter" sectionFormat="of" target="section-7.6"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-impact-on-network-operation">Impact on Network Operations</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.8">
            <t indent="0" pn="section-toc.1-1.8.1"><xref derivedContent="8" format="counter" sectionFormat="of" target="section-8"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-references">References</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.8.2">
              <li pn="section-toc.1-1.8.2.1">
                <t indent="0" pn="section-toc.1-1.8.2.1.1"><xref derivedContent="8.1" format="counter" sectionFormat="of" target="section-8.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-normative-references">Normative References</xref></t>
              </li>
              <li pn="section-toc.1-1.8.2.2">
                <t indent="0" pn="section-toc.1-1.8.2.2.1"><xref derivedContent="8.2" format="counter" sectionFormat="of" target="section-8.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-informative-references">Informative References</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.9">
            <t indent="0" pn="section-toc.1-1.9.1"><xref derivedContent="" format="none" sectionFormat="of" target="section-appendix.a"/><xref derivedContent="" format="title" sectionFormat="of" target="name-contributors">Contributors</xref></t>
          </li>
          <li pn="section-toc.1-1.10">
            <t indent="0" pn="section-toc.1-1.10.1"><xref derivedContent="" format="none" sectionFormat="of" target="section-appendix.b"/><xref derivedContent="" format="title" sectionFormat="of" target="name-authors-addresses">Authors' Addresses</xref></t>
          </li>
        </ul>
      </section>
    </toc>
  </front>
  <middle>
    <section anchor="sect-1" numbered="true" toc="include" removeInRFC="false" pn="section-1">
      <name slugifiedName="name-introduction">Introduction</name>
      <t indent="0" pn="section-1-1"> 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) <xref target="RFC5440" format="default" sectionFormat="of" derivedContent="RFC5440"/>. </t>
      <t indent="0" pn="section-1-2"> <xref target="RFC8051" format="default" sectionFormat="of" derivedContent="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. <xref target="RFC8231" format="default" sectionFormat="of" derivedContent="RFC8231"/> describes a set of extensions to PCEP to provide stateful control. For its computations, a stateful PCE has access to not only 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. </t>
      <t indent="0" pn="section-1-3"> <xref target="RFC8281" format="default" sectionFormat="of" derivedContent="RFC8281"/> describes the setup, maintenance, and teardown of PCE-initiated LSPs under the stateful PCE model. </t>
      <t indent="0" pn="section-1-4"> <xref target="RFC8697" format="default" sectionFormat="of" derivedContent="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. </t>
      <t indent="0" pn="section-1-5"> <xref target="RFC8453" format="default" sectionFormat="of" derivedContent="RFC8453"/> introduces a framework for Abstraction and Control of TE Networks (ACTN) and describes various 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. </t>
      <t indent="0" pn="section-1-6"> <xref target="RFC8637" format="default" sectionFormat="of" derivedContent="RFC8637"/> examines the PCE and ACTN architectures and describes how the PCE architecture is applicable to ACTN.  <xref target="RFC6805" format="default" sectionFormat="of" derivedContent="RFC6805"/> and <xref target="RFC8751" format="default" sectionFormat="of" derivedContent="RFC8751"/> describe a hierarchy of stateful PCEs with the parent PCE coordinating multi-domain path computation functions between child PCEs, thus making it the base for PCE applicability for ACTN.  As <xref target="RFC8751" format="default" sectionFormat="of" derivedContent="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).</t>
      <t indent="0" pn="section-1-7"> 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 relaxing constraints, taking policy actions, setting default behavior, etc. </t>
      <t indent="0" pn="section-1-8"> This document specifies a PCEP extension to associate a set of LSPs based on their VN.  </t>
    </section>
    <section anchor="sect-2" numbered="true" toc="include" removeInRFC="false" pn="section-2">
      <name slugifiedName="name-terminology">Terminology</name>
      <t indent="0" pn="section-2-1">This document uses terminology from <xref target="RFC4655" format="default" sectionFormat="of" derivedContent="RFC4655"/>, <xref target="RFC5440" format="default" sectionFormat="of" derivedContent="RFC5440"/>, <xref target="RFC6805" format="default" sectionFormat="of" derivedContent="RFC6805"/>, <xref target="RFC8231" format="default" sectionFormat="of" derivedContent="RFC8231"/>, and <xref target="RFC8453" format="default" sectionFormat="of" derivedContent="RFC8453"/>. </t>
      <t indent="0" pn="section-2-2">
    The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
    "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>",
    "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
    "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are
    to be interpreted as described in BCP 14 <xref target="RFC2119" format="default" sectionFormat="of" derivedContent="RFC2119"/>
        <xref target="RFC8174" format="default" sectionFormat="of" derivedContent="RFC8174"/> when, and only when, they appear in all capitals,
    as shown here.
      </t>
    </section>
    <section anchor="sect-3" numbered="true" toc="include" removeInRFC="false" pn="section-3">
      <name slugifiedName="name-operation-overview">Operation Overview</name>
      <t indent="0" pn="section-3-1">As per <xref target="RFC8697" format="default" sectionFormat="of" derivedContent="RFC8697"/>, LSPs are associated with other LSPs with which they interact by adding them to a common association group. </t>
      <t indent="0" pn="section-3-2">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, the following:</t>
      <dl newline="false" spacing="normal" indent="3" pn="section-3-3">
        <dt pn="section-3-3.1">Path Computation:</dt>
        <dd pn="section-3-3.2">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) <xref target="RFC5541" format="default" sectionFormat="of" derivedContent="RFC5541"/>) could be applied for all the LSPs belonging to the
	VN identified by the VN association. </dd>
        <dt pn="section-3-3.3">Path Reoptimization:</dt>
        <dd pn="section-3-3.4">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 reoptimization. </dd>
      </dl>
      <t indent="0" pn="section-3-4">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 VN. </t>
      <t indent="0" pn="section-3-5"> The ASSOCIATION object contains a field to identify the type of association, and this document defines a new Association Type value of 7 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 <xref target="RFC8697" format="default" sectionFormat="of" derivedContent="RFC8697"/>. </t>
      <t indent="0" pn="section-3-6">  In this document, "VNAG object" refers to an ASSOCIATION object with the Association Type set to "VN Association" (7). </t>
      <t indent="0" pn="section-3-7"> Local policies on the PCE define the computational and optimization behavior for the LSPs in the VN. An LSP <bcp14>MUST NOT</bcp14> belong to more than one VNAG. If an implementation encounters more than one VNAG object in a PCEP message, it <bcp14>MUST</bcp14> process the first occurrence, and it <bcp14>MUST</bcp14> ignore the others.  </t>
      <t indent="0" pn="section-3-8"> <xref target="RFC8697" format="default" sectionFormat="of" derivedContent="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 <bcp14>MUST</bcp14> include the VN Association Type (7) in the ASSOC-Type-List TLV before using the VNAG object in a PCEP message. As per <xref target="RFC8697" format="default" sectionFormat="of" derivedContent="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). </t>
      <t indent="0" pn="section-3-9"> The Association Identifiers (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 (7) <bcp14>MUST NOT</bcp14> 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 (7) in an Operator-configured Association Range TLV, it <bcp14>MUST</bcp14> ignore the associated Start-Assoc-ID and Range values.
      </t>
      <t indent="0" pn="section-3-10">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 VN creation request from its customer, with the VN uniquely identified by the association parameters (<xref target="RFC8697" sectionFormat="of" section="6.1.4" format="default" derivedLink="https://rfc-editor.org/rfc/rfc8697#section-6.1.4" derivedContent="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 <bcp14>MUST</bcp14> be included as a part of the first PCRpt message. <xref target="vn-operations" format="default" sectionFormat="of" derivedContent="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 that receive the instruction from their child PCE (PNC).
      </t>
      <figure anchor="vn-operations" align="left" suppress-title="false" pn="figure-1">
        <name slugifiedName="name-example-of-vn-operations-in">Example of VN Operations in H-PCE (Hierarchical PCE) Architecture</name>
        <artwork name="" type="" align="left" alt="" pn="section-3-11.1">
                          ******
                ..........*MDSC*..............................
             .            ****** ..                   MPI    .
          .                .        .                        .
       .                   .          .   PCInitiate LSPx    .
     .                    .             .   with VNAG        .
    .                    .                .                  .
   .                    .                  .                 .
  .                    .                    .                .
  v                    v                    v                .
******               ******               ******             .
*PNC1*               *PNC2*               *PNC4*             .
******               ******               ******             .
+---------------+    +---------------+    +---------------+  .
|               |----|               |----|              C|  .
|               |    |               |    |               |  .
|DOMAIN 1       |----|DOMAIN 2       |----|DOMAIN 4       |  .
+---------------+    +---------------+    +---------------+  .
                                         /                   .
                    ******              /                    .
                    *PNC3*&lt;............/......................
                    ******            /
                    +---------------+/
                    |               |
                    |               |
                    |DOMAIN 3       |
                    +---------------+

MDSC -&gt; parent PCE
PNC  -&gt; child  PCE
MPI  -&gt; PCEP		    
</artwork>
      </figure>
      <t indent="0" pn="section-3-12">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. </t>
      <t indent="0" pn="section-3-13">Whenever an update occurs with VNs in the parent PCE (due to the customer's request), the parent PCE sends a PCUpd message to inform each affected child PCE of this change. </t>
    </section>
    <section anchor="sect-4" numbered="true" toc="include" removeInRFC="false" pn="section-4">
      <name slugifiedName="name-extensions-to-pcep">Extensions to PCEP</name>
      <t indent="0" pn="section-4-1">The VNAG uses the generic ASSOCIATION object <xref target="RFC8697" format="default" sectionFormat="of" derivedContent="RFC8697"/>. </t>
      <t indent="0" pn="section-4-2"> This document defines one new mandatory TLV called the "VIRTUAL-NETWORK-TLV". Optionally, the new TLV can be jointly used with the existing VENDOR-INFORMATION-TLV specified in <xref target="RFC7470" format="default" sectionFormat="of" derivedContent="RFC7470"/>  as described below: </t>
      <dl newline="false" spacing="normal" indent="3" pn="section-4-3">
        <dt pn="section-4-3.1">VIRTUAL-NETWORK-TLV:</dt>
        <dd pn="section-4-3.2">Used to communicate the Virtual Network Identifier.</dd>
        <dt pn="section-4-3.3">VENDOR-INFORMATION-TLV:</dt>
        <dd pn="section-4-3.4">Used to communicate arbitrary vendor-specific behavioral
	information, as described in <xref target="RFC7470" format="default" sectionFormat="of" derivedContent="RFC7470"/>.</dd>
      </dl>
      <t indent="0" pn="section-4-4">The format of the VIRTUAL-NETWORK-TLV is as follows.   </t>
      <figure anchor="vn-tlv-formats" align="left" suppress-title="false" pn="figure-2">
        <name slugifiedName="name-format-of-the-virtual-netwo">Format of the VIRTUAL-NETWORK-TLV</name>
        <artwork name="" type="" align="left" alt="" pn="section-4-5.1">
 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=65             |            Length             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
//                   Virtual Network Identifier                //
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork>
      </figure>
      <dl newline="false" spacing="normal" indent="3" pn="section-4-6">
        <dt pn="section-4-6.1">Type (16 bits):</dt>
        <dd pn="section-4-6.2">65</dd>
        <dt pn="section-4-6.3">Length (16 bits):</dt>
        <dd pn="section-4-6.4">Indicates the length of the value portion of the TLV in octets and
  <bcp14>MUST</bcp14> be greater than 0. The TLV <bcp14>MUST</bcp14> be
  zero-padded so that the TLV is 4-octet aligned.</dd>
        <dt pn="section-4-6.5">Virtual Network Identifier (variable):</dt>
        <dd pn="section-4-6.6">A symbolic name for the VN that uniquely identifies the VN. It
  <bcp14>SHOULD</bcp14> be a string of printable ASCII <xref target="RFC0020" format="default" sectionFormat="of" derivedContent="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 VNAG
  and the LSPs associated with the VN. The Virtual Network Identifier
  <bcp14>MAY</bcp14> be specified by the customer, set via an operator
  policy, or auto-generated by the PCEP speaker.</dd>
      </dl>
      <t indent="0" pn="section-4-7">The VIRTUAL-NETWORK-TLV <bcp14>MUST</bcp14> be included in VNAG object.  If a PCEP speaker receives the VNAG object without the VIRTUAL-NETWORK-TLV, it <bcp14>MUST</bcp14> send a PCErr message with Error-Type=6 (Mandatory Object missing) and Error-value=18 (VIRTUAL-NETWORK-TLV missing) and close the session.   </t>
      <t indent="0" pn="section-4-8">The format of VENDOR-INFORMATION-TLV is defined in <xref target="RFC7470" format="default" sectionFormat="of" derivedContent="RFC7470"/>. </t>
      <t indent="0" pn="section-4-9">If a PCEP speaker receives a VNAG object with a TLV that violates the rules specified in this document, the PCEP speaker <bcp14>MUST</bcp14> send a PCErr message with Error-Type=10 (Reception of an invalid object) and Error-value=11 (Malformed object) and <bcp14>MUST</bcp14> close the PCEP session. </t>
    </section>
    <section anchor="sect-6" numbered="true" toc="include" removeInRFC="false" pn="section-5">
      <name slugifiedName="name-security-considerations">Security Considerations</name>
      <t indent="0" pn="section-5-1">The security considerations described in <xref target="RFC5440" format="default" sectionFormat="of" derivedContent="RFC5440"/>, <xref target="RFC8231" format="default" sectionFormat="of" derivedContent="RFC8231"/>, and <xref target="RFC8281" format="default" sectionFormat="of" derivedContent="RFC8281"/> apply to the extensions defined in
      this document as well.</t>
      <t indent="0" pn="section-5-2">This document introduces the VN Association Type (7) for the ASSOCIATION object. Additional security
   considerations related to LSP associations due to a malicious PCEP speaker are described in <xref target="RFC8697" format="default" sectionFormat="of" derivedContent="RFC8697"/> and apply to the VN Association Type.  Hence, securing the PCEP session using Transport Layer Security (TLS) <xref target="RFC8253" format="default" sectionFormat="of" derivedContent="RFC8253"/> is <bcp14>RECOMMENDED</bcp14>.</t>
    </section>
    <section anchor="sect-7" numbered="true" toc="include" removeInRFC="false" pn="section-6">
      <name slugifiedName="name-iana-considerations">IANA Considerations</name>
      <section anchor="sect-7.1" numbered="true" toc="include" removeInRFC="false" pn="section-6.1">
        <name slugifiedName="name-association-object-type-ind">ASSOCIATION Object Type Indicator</name>
        <t indent="0" pn="section-6.1-1">IANA has assigned the following new value in the "ASSOCIATION Type Field" subregistry within the "Path Computation Element Protocol (PCEP) Numbers" registry:  </t>
        <table align="left" pn="table-1">
          <name/>
          <thead>
            <tr>
              <th align="left" colspan="1" rowspan="1">Value</th>
              <th align="left" colspan="1" rowspan="1">Name</th>
              <th align="left" colspan="1" rowspan="1">Reference</th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td align="left" colspan="1" rowspan="1">7</td>
              <td align="left" colspan="1" rowspan="1">VN Association</td>
              <td align="left" colspan="1" rowspan="1">RFC 9358</td>
            </tr>
          </tbody>
        </table>
      </section>
      <section anchor="sect-7.2" numbered="true" toc="include" removeInRFC="false" pn="section-6.2">
        <name slugifiedName="name-pcep-tlv-type-indicator">PCEP TLV Type Indicator</name>
        <t indent="0" pn="section-6.2-1">IANA has assigned the following new value in the "PCEP TLV Type Indicators" subregistry within the "Path
   Computation Element Protocol (PCEP) Numbers" registry:
        </t>
        <table align="left" pn="table-2">
          <name/>
          <thead>
            <tr>
              <th align="left" colspan="1" rowspan="1">Value</th>
              <th align="left" colspan="1" rowspan="1">Name</th>
              <th align="left" colspan="1" rowspan="1">Reference</th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td align="left" colspan="1" rowspan="1">65</td>
              <td align="left" colspan="1" rowspan="1">VIRTUAL-NETWORK-TLV</td>
              <td align="left" colspan="1" rowspan="1">RFC 9358</td>
            </tr>
          </tbody>
        </table>
      </section>
      <section anchor="sect-7.3" numbered="true" toc="include" removeInRFC="false" pn="section-6.3">
        <name slugifiedName="name-pcep-error">PCEP Error</name>
        <t indent="0" pn="section-6.3-1"> IANA has allocated the following new error value in the "PCEP-ERROR
        Object Error Types and Values" subregistry within the "Path
        Computation Element Protocol (PCEP) Numbers" registry:
        </t>
        <table align="left" pn="table-3">
          <name/>
          <thead>
            <tr>
              <th align="left" colspan="1" rowspan="1">Error-Type</th>
              <th align="left" colspan="1" rowspan="1">Meaning</th>
              <th align="left" colspan="1" rowspan="1">Error-value</th>
              <th align="left" colspan="1" rowspan="1">Reference</th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td align="left" colspan="1" rowspan="1">6</td>
              <td align="left" colspan="1" rowspan="1">Mandatory Object missing</td>
              <td align="left" colspan="1" rowspan="1">18: VIRTUAL-NETWORK-TLV missing</td>
              <td align="left" colspan="1" rowspan="1">RFC 9358</td>
            </tr>
          </tbody>
        </table>
      </section>
    </section>
    <section anchor="sect-8" numbered="true" toc="include" removeInRFC="false" pn="section-7">
      <name slugifiedName="name-manageability-consideration">Manageability Considerations</name>
      <section anchor="sect-8.1" numbered="true" toc="include" removeInRFC="false" pn="section-7.1">
        <name slugifiedName="name-control-of-function-and-pol">Control of Function and Policy</name>
        <t indent="0" pn="section-7.1-1">An operator <bcp14>MUST</bcp14> be allowed to mark LSPs that belong to the same VN. This could also be done automatically based on the VN configuration.
        </t>
      </section>
      <section anchor="sect-8.2" numbered="true" toc="include" removeInRFC="false" pn="section-7.2">
        <name slugifiedName="name-information-and-data-models">Information and Data Models</name>
        <t indent="0" pn="section-7.2-1">The PCEP YANG module <xref target="I-D.ietf-pce-pcep-yang" format="default" sectionFormat="of" derivedContent="PCE-PCEP-YANG"/> should support the association between LSPs including VN association.
        </t>
      </section>
      <section anchor="sect-8.3" numbered="true" toc="include" removeInRFC="false" pn="section-7.3">
        <name slugifiedName="name-liveness-detection-and-moni">Liveness Detection and Monitoring</name>
        <t indent="0" pn="section-7.3-1"> Mechanisms defined in this document do not imply any new liveness detection and monitoring requirements in addition to those already listed in <xref target="RFC5440" format="default" sectionFormat="of" derivedContent="RFC5440"/>.
        </t>
      </section>
      <section anchor="sect-8.4" numbered="true" toc="include" removeInRFC="false" pn="section-7.4">
        <name slugifiedName="name-verification-of-correct-ope">Verification of Correct Operations</name>
        <t indent="0" pn="section-7.4-1">Mechanisms defined in this document do not imply any new operation verification requirements in addition to those already listed in <xref target="RFC5440" format="default" sectionFormat="of" derivedContent="RFC5440"/>.
        </t>
      </section>
      <section anchor="sect-8.5" numbered="true" toc="include" removeInRFC="false" pn="section-7.5">
        <name slugifiedName="name-requirements-on-other-proto">Requirements on Other Protocols</name>
        <t indent="0" pn="section-7.5-1">Mechanisms defined in this document do not imply any new requirements on other protocols.
        </t>
      </section>
      <section anchor="sect-8.6" numbered="true" toc="include" removeInRFC="false" pn="section-7.6">
        <name slugifiedName="name-impact-on-network-operation">Impact on Network Operations</name>
        <t indent="0" pn="section-7.6-1"><xref target="RFC8637" format="default" sectionFormat="of" derivedContent="RFC8637"/> describes the network operations when PCE is used for VN operations. <xref target="sect-3" format="default" sectionFormat="of" derivedContent="Section 3"/> further specifies the operations when VN associations are used.</t>
      </section>
    </section>
  </middle>
  <back>
    <displayreference target="I-D.ietf-pce-pcep-yang" to="PCE-PCEP-YANG"/>
    <references pn="section-8">
      <name slugifiedName="name-references">References</name>
      <references pn="section-8.1">
        <name slugifiedName="name-normative-references">Normative References</name>
        <reference anchor="RFC0020" target="https://www.rfc-editor.org/info/rfc20" quoteTitle="true" derivedAnchor="RFC0020">
          <front>
            <title>ASCII format for network interchange</title>
            <author fullname="V.G. Cerf" initials="V.G." surname="Cerf"/>
            <date month="October" year="1969"/>
          </front>
          <seriesInfo name="STD" value="80"/>
          <seriesInfo name="RFC" value="20"/>
          <seriesInfo name="DOI" value="10.17487/RFC0020"/>
        </reference>
        <reference anchor="RFC2119" target="https://www.rfc-editor.org/info/rfc2119" quoteTitle="true" derivedAnchor="RFC2119">
          <front>
            <title>Key words for use in RFCs to Indicate Requirement Levels</title>
            <author fullname="S. Bradner" initials="S." surname="Bradner"/>
            <date month="March" year="1997"/>
            <abstract>
              <t indent="0">In many standards track documents several words are used to signify the requirements in the specification.  These words are often capitalized.  This document defines these words as they should be interpreted in IETF documents.  This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="14"/>
          <seriesInfo name="RFC" value="2119"/>
          <seriesInfo name="DOI" value="10.17487/RFC2119"/>
        </reference>
        <reference anchor="RFC5440" target="https://www.rfc-editor.org/info/rfc5440" quoteTitle="true" derivedAnchor="RFC5440">
          <front>
            <title>Path Computation Element (PCE) Communication Protocol (PCEP)</title>
            <author fullname="JP. Vasseur" initials="JP." role="editor" surname="Vasseur"/>
            <author fullname="JL. Le Roux" initials="JL." role="editor" surname="Le Roux"/>
            <date month="March" year="2009"/>
            <abstract>
              <t indent="0">This document specifies the Path Computation Element (PCE) Communication Protocol (PCEP) for communications between a Path Computation Client (PCC) and a PCE, or between two PCEs.  Such interactions include path computation requests and path computation replies as well as notifications of specific states related to the use of a PCE in the context of Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Traffic Engineering.  PCEP is designed to be flexible and extensible so as to easily allow for the addition of further messages and objects, should further requirements be expressed in the future. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="5440"/>
          <seriesInfo name="DOI" value="10.17487/RFC5440"/>
        </reference>
        <reference anchor="RFC8174" target="https://www.rfc-editor.org/info/rfc8174" quoteTitle="true" derivedAnchor="RFC8174">
          <front>
            <title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title>
            <author fullname="B. Leiba" initials="B." surname="Leiba"/>
            <date month="May" year="2017"/>
            <abstract>
              <t indent="0">RFC 2119 specifies common key words that may be used in protocol specifications.  This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="14"/>
          <seriesInfo name="RFC" value="8174"/>
          <seriesInfo name="DOI" value="10.17487/RFC8174"/>
        </reference>
        <reference anchor="RFC8231" target="https://www.rfc-editor.org/info/rfc8231" quoteTitle="true" derivedAnchor="RFC8231">
          <front>
            <title>Path Computation Element Communication Protocol (PCEP) Extensions for Stateful PCE</title>
            <author fullname="E. Crabbe" initials="E." surname="Crabbe"/>
            <author fullname="I. Minei" initials="I." surname="Minei"/>
            <author fullname="J. Medved" initials="J." surname="Medved"/>
            <author fullname="R. Varga" initials="R." surname="Varga"/>
            <date month="September" year="2017"/>
            <abstract>
              <t indent="0">The Path Computation Element Communication Protocol (PCEP) provides mechanisms for Path Computation Elements (PCEs) to perform path computations in response to Path Computation Client (PCC) requests.</t>
              <t indent="0">Although PCEP explicitly makes no assumptions regarding the information available to the PCE, it also makes no provisions for PCE control of timing and sequence of path computations within and across PCEP sessions. This document describes a set of extensions to PCEP to enable stateful control of MPLS-TE and GMPLS Label Switched Paths (LSPs) via PCEP.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8231"/>
          <seriesInfo name="DOI" value="10.17487/RFC8231"/>
        </reference>
        <reference anchor="RFC8253" target="https://www.rfc-editor.org/info/rfc8253" quoteTitle="true" derivedAnchor="RFC8253">
          <front>
            <title>PCEPS: Usage of TLS to Provide a Secure Transport for the Path Computation Element Communication Protocol (PCEP)</title>
            <author fullname="D. Lopez" initials="D." surname="Lopez"/>
            <author fullname="O. Gonzalez de Dios" initials="O." surname="Gonzalez de Dios"/>
            <author fullname="Q. Wu" initials="Q." surname="Wu"/>
            <author fullname="D. Dhody" initials="D." surname="Dhody"/>
            <date month="October" year="2017"/>
            <abstract>
              <t indent="0">The Path Computation Element Communication Protocol (PCEP) defines the mechanisms for the communication between a Path Computation Client (PCC) and a Path Computation Element (PCE), or among PCEs. This document describes PCEPS -- the usage of Transport Layer Security (TLS) to provide a secure transport for PCEP. The additional security mechanisms are provided by the transport protocol supporting PCEP; therefore, they do not affect the flexibility and extensibility of PCEP.</t>
              <t indent="0">This document updates RFC 5440 in regards to the PCEP initialization phase procedures.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8253"/>
          <seriesInfo name="DOI" value="10.17487/RFC8253"/>
        </reference>
        <reference anchor="RFC8281" target="https://www.rfc-editor.org/info/rfc8281" quoteTitle="true" derivedAnchor="RFC8281">
          <front>
            <title>Path Computation Element Communication Protocol (PCEP) Extensions for PCE-Initiated LSP Setup in a Stateful PCE Model</title>
            <author fullname="E. Crabbe" initials="E." surname="Crabbe"/>
            <author fullname="I. Minei" initials="I." surname="Minei"/>
            <author fullname="S. Sivabalan" initials="S." surname="Sivabalan"/>
            <author fullname="R. Varga" initials="R." surname="Varga"/>
            <date month="December" year="2017"/>
            <abstract>
              <t indent="0">The Path Computation Element Communication Protocol (PCEP) provides mechanisms for Path Computation Elements (PCEs) to perform path computations in response to Path Computation Client (PCC) requests.</t>
              <t indent="0">The extensions for stateful PCE provide active control of Multiprotocol Label Switching (MPLS) Traffic Engineering Label Switched Paths (TE LSPs) via PCEP, for a model where the PCC delegates control over one or more locally configured LSPs to the PCE. This document describes the creation and deletion of PCE-initiated LSPs under the stateful PCE model.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8281"/>
          <seriesInfo name="DOI" value="10.17487/RFC8281"/>
        </reference>
        <reference anchor="RFC8697" target="https://www.rfc-editor.org/info/rfc8697" quoteTitle="true" derivedAnchor="RFC8697">
          <front>
            <title>Path Computation Element Communication Protocol (PCEP) Extensions for Establishing Relationships between Sets of Label Switched Paths (LSPs)</title>
            <author fullname="I. Minei" initials="I." surname="Minei"/>
            <author fullname="E. Crabbe" initials="E." surname="Crabbe"/>
            <author fullname="S. Sivabalan" initials="S." surname="Sivabalan"/>
            <author fullname="H. Ananthakrishnan" initials="H." surname="Ananthakrishnan"/>
            <author fullname="D. Dhody" initials="D." surname="Dhody"/>
            <author fullname="Y. Tanaka" initials="Y." surname="Tanaka"/>
            <date month="January" year="2020"/>
            <abstract>
              <t indent="0">This document introduces a generic mechanism to create a grouping of Label Switched Paths (LSPs) in the context of a Path Computation Element (PCE).  This grouping can then be used to define associations between sets of LSPs or between a set of LSPs and a set of attributes (such as configuration parameters or behaviors), and it is equally applicable to the stateful PCE (active and passive modes) and the stateless PCE.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8697"/>
          <seriesInfo name="DOI" value="10.17487/RFC8697"/>
        </reference>
      </references>
      <references pn="section-8.2">
        <name slugifiedName="name-informative-references">Informative References</name>
        <reference anchor="I-D.ietf-pce-pcep-yang" quoteTitle="true" target="https://datatracker.ietf.org/doc/html/draft-ietf-pce-pcep-yang-20" derivedAnchor="PCE-PCEP-YANG">
          <front>
            <title>A YANG Data Model for Path Computation Element Communications Protocol (PCEP)</title>
            <author initials="D." surname="Dhody" fullname="Dhruv Dhody" role="editor">
              <organization showOnFrontPage="true">Huawei Technologies</organization>
            </author>
            <author initials="V." surname="Beeram" fullname="Vishnu Pavan Beeram">
              <organization showOnFrontPage="true">Juniper Networks</organization>
            </author>
            <author initials="J." surname="Hardwick" fullname="Jonathan Hardwick">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="J." surname="Tantsura" fullname="Jeff Tantsura">
              <organization showOnFrontPage="true">Microsoft</organization>
            </author>
            <date month="October" day="23" year="2022"/>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-ietf-pce-pcep-yang-20"/>
          <refcontent>Work in Progress</refcontent>
        </reference>
        <reference anchor="RFC4655" target="https://www.rfc-editor.org/info/rfc4655" quoteTitle="true" derivedAnchor="RFC4655">
          <front>
            <title>A Path Computation Element (PCE)-Based Architecture</title>
            <author fullname="A. Farrel" initials="A." surname="Farrel"/>
            <author fullname="J.-P. Vasseur" initials="J.-P." surname="Vasseur"/>
            <author fullname="J. Ash" initials="J." surname="Ash"/>
            <date month="August" year="2006"/>
            <abstract>
              <t indent="0">Constraint-based path computation is a fundamental building block for traffic engineering systems such as Multiprotocol Label Switching (MPLS) and Generalized Multiprotocol Label Switching (GMPLS) networks. Path computation in large, multi-domain, multi-region, or multi-layer networks is complex and may require special computational components and cooperation between the different network domains.</t>
              <t indent="0">This document specifies the architecture for a Path Computation Element (PCE)-based model to address this problem space. This document does not attempt to provide a detailed description of all the architectural components, but rather it describes a set of building blocks for the PCE architecture from which solutions may be constructed. This memo provides information for the Internet community.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="4655"/>
          <seriesInfo name="DOI" value="10.17487/RFC4655"/>
        </reference>
        <reference anchor="RFC5541" target="https://www.rfc-editor.org/info/rfc5541" quoteTitle="true" derivedAnchor="RFC5541">
          <front>
            <title>Encoding of Objective Functions in the Path Computation Element Communication Protocol (PCEP)</title>
            <author fullname="JL. Le Roux" initials="JL." surname="Le Roux"/>
            <author fullname="JP. Vasseur" initials="JP." surname="Vasseur"/>
            <author fullname="Y. Lee" initials="Y." surname="Lee"/>
            <date month="June" year="2009"/>
            <abstract>
              <t indent="0">The computation of one or a set of Traffic Engineering Label Switched Paths (TE LSPs) in MultiProtocol Label Switching (MPLS) and Generalized MPLS (GMPLS) networks is subject to a set of one or more specific optimization criteria, referred to as objective functions (e.g., minimum cost path, widest path, etc.).</t>
              <t indent="0">In the Path Computation Element (PCE) architecture, a Path Computation Client (PCC) may want a path to be computed for one or more TE LSPs according to a specific objective function. Thus, the PCC needs to instruct the PCE to use the correct objective function. Furthermore, it is possible that not all PCEs support the same set of objective functions; therefore, it is useful for the PCC to be able to automatically discover the set of objective functions supported by each PCE.</t>
              <t indent="0">This document defines extensions to the PCE communication Protocol (PCEP) to allow a PCE to indicate the set of objective functions it supports. Extensions are also defined so that a PCC can indicate in a path computation request the required objective function, and a PCE can report in a path computation reply the objective function that was used for path computation.</t>
              <t indent="0">This document defines objective function code types for six objective functions previously listed in the PCE requirements work, and provides the definition of four new metric types that apply to a set of synchronized requests. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="5541"/>
          <seriesInfo name="DOI" value="10.17487/RFC5541"/>
        </reference>
        <reference anchor="RFC6805" target="https://www.rfc-editor.org/info/rfc6805" quoteTitle="true" derivedAnchor="RFC6805">
          <front>
            <title>The Application of the Path Computation Element Architecture to the Determination of a Sequence of Domains in MPLS and GMPLS</title>
            <author fullname="D. King" initials="D." role="editor" surname="King"/>
            <author fullname="A. Farrel" initials="A." role="editor" surname="Farrel"/>
            <date month="November" year="2012"/>
            <abstract>
              <t indent="0">Computing optimum routes for Label Switched Paths (LSPs) across multiple domains in MPLS Traffic Engineering (MPLS-TE) and GMPLS networks presents a problem because no single point of path computation is aware of all of the links and resources in each domain. A solution may be achieved using the Path Computation Element (PCE) architecture.</t>
              <t indent="0">Where the sequence of domains is known a priori, various techniques can be employed to derive an optimum path. If the domains are simply connected, or if the preferred points of interconnection are also known, the Per-Domain Path Computation technique can be used. Where there are multiple connections between domains and there is no preference for the choice of points of interconnection, the Backward-Recursive PCE-based Computation (BRPC) procedure can be used to derive an optimal path.</t>
              <t indent="0">This document examines techniques to establish the optimum path when the sequence of domains is not known in advance. The document shows how the PCE architecture can be extended to allow the optimum sequence of domains to be selected, and the optimum end-to-end path to be derived through the use of a hierarchical relationship between domains. This document is not an Internet Standards Track specification; it is published for informational purposes.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="6805"/>
          <seriesInfo name="DOI" value="10.17487/RFC6805"/>
        </reference>
        <reference anchor="RFC7470" target="https://www.rfc-editor.org/info/rfc7470" quoteTitle="true" derivedAnchor="RFC7470">
          <front>
            <title>Conveying Vendor-Specific Constraints in the Path Computation Element Communication Protocol</title>
            <author fullname="F. Zhang" initials="F." surname="Zhang"/>
            <author fullname="A. Farrel" initials="A." surname="Farrel"/>
            <date month="March" year="2015"/>
            <abstract>
              <t indent="0">The Path Computation Element Communication Protocol (PCEP) is used to convey path computation requests and responses both between Path Computation Clients (PCCs) and Path Computation Elements (PCEs) and between cooperating PCEs. In PCEP, the path computation requests carry details of the constraints and objective functions that the PCC wishes the PCE to apply in its computation.</t>
              <t indent="0">This document defines a facility to carry vendor-specific information in PCEP using a dedicated object and a new Type-Length-Value (TLV) that can be carried in any PCEP object that supports TLVs.</t>
              <t indent="0">This document obsoletes RFC 7150. The only changes from that document are a clarification of the use of the new Type-Length-Value and the allocation of a different code point for the VENDOR-INFORMATION object.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="7470"/>
          <seriesInfo name="DOI" value="10.17487/RFC7470"/>
        </reference>
        <reference anchor="RFC8051" target="https://www.rfc-editor.org/info/rfc8051" quoteTitle="true" derivedAnchor="RFC8051">
          <front>
            <title>Applicability of a Stateful Path Computation Element (PCE)</title>
            <author fullname="X. Zhang" initials="X." role="editor" surname="Zhang"/>
            <author fullname="I. Minei" initials="I." role="editor" surname="Minei"/>
            <date month="January" year="2017"/>
            <abstract>
              <t indent="0">A stateful Path Computation Element (PCE) maintains information about Label Switched Path (LSP) characteristics and resource usage within a network in order to provide traffic-engineering calculations for its associated Path Computation Clients (PCCs).  This document 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.  PCE Communication Protocol (PCEP) extensions required for stateful PCE usage are covered in separate documents.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8051"/>
          <seriesInfo name="DOI" value="10.17487/RFC8051"/>
        </reference>
        <reference anchor="RFC8453" target="https://www.rfc-editor.org/info/rfc8453" quoteTitle="true" derivedAnchor="RFC8453">
          <front>
            <title>Framework for Abstraction and Control of TE Networks (ACTN)</title>
            <author fullname="D. Ceccarelli" initials="D." role="editor" surname="Ceccarelli"/>
            <author fullname="Y. Lee" initials="Y." role="editor" surname="Lee"/>
            <date month="August" year="2018"/>
            <abstract>
              <t indent="0">Traffic Engineered (TE) networks have a variety of mechanisms to facilitate the separation of the data plane and control plane. They also have a range of management and provisioning protocols to configure and activate network resources. These mechanisms represent key technologies for enabling flexible and dynamic networking. The term "Traffic Engineered network" refers to a network that uses any connection-oriented technology under the control of a distributed or centralized control plane to support dynamic provisioning of end-to- end connectivity.</t>
              <t indent="0">Abstraction of network resources is a technique that can be applied to a single network domain or across multiple domains to create a single virtualized network that is under the control of a network operator or the customer of the operator that actually owns the network resources.</t>
              <t indent="0">This document provides a framework for Abstraction and Control of TE Networks (ACTN) to support virtual network services and connectivity services.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8453"/>
          <seriesInfo name="DOI" value="10.17487/RFC8453"/>
        </reference>
        <reference anchor="RFC8637" target="https://www.rfc-editor.org/info/rfc8637" quoteTitle="true" derivedAnchor="RFC8637">
          <front>
            <title>Applicability of the Path Computation Element (PCE) to the Abstraction and Control of TE Networks (ACTN)</title>
            <author fullname="D. Dhody" initials="D." surname="Dhody"/>
            <author fullname="Y. Lee" initials="Y." surname="Lee"/>
            <author fullname="D. Ceccarelli" initials="D." surname="Ceccarelli"/>
            <date month="July" year="2019"/>
            <abstract>
              <t indent="0">Abstraction and Control of TE Networks (ACTN) refers to the set of virtual network (VN) operations needed to orchestrate, control, and manage large-scale multidomain TE networks so as to facilitate network programmability, automation, efficient resource sharing, and end-to-end virtual service-aware connectivity and network function virtualization services.</t>
              <t indent="0">The Path Computation Element (PCE) is a component, application, or network node that is capable of computing a network path or route based on a network graph and applying computational constraints. The PCE serves requests from Path Computation Clients (PCCs) that communicate with it over a local API or using the Path Computation Element Communication Protocol (PCEP).</t>
              <t indent="0">This document examines the applicability of PCE to the ACTN framework.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8637"/>
          <seriesInfo name="DOI" value="10.17487/RFC8637"/>
        </reference>
        <reference anchor="RFC8751" target="https://www.rfc-editor.org/info/rfc8751" quoteTitle="true" derivedAnchor="RFC8751">
          <front>
            <title>Hierarchical Stateful Path Computation Element (PCE)</title>
            <author fullname="D. Dhody" initials="D." surname="Dhody"/>
            <author fullname="Y. Lee" initials="Y." surname="Lee"/>
            <author fullname="D. Ceccarelli" initials="D." surname="Ceccarelli"/>
            <author fullname="J. Shin" initials="J." surname="Shin"/>
            <author fullname="D. King" initials="D." surname="King"/>
            <date month="March" year="2020"/>
            <abstract>
              <t indent="0">A stateful Path Computation Element (PCE) maintains information on the current network state received from the Path Computation Clients (PCCs), including computed Label Switched Paths (LSPs), reserved resources within the network, and pending path computation requests. This information may then be considered when computing the path for a new traffic-engineered LSP or for any associated/dependent LSPs. The path-computation response from a PCE helps the PCC to gracefully establish the computed LSP.</t>
              <t indent="0">The Hierarchical Path Computation Element (H-PCE) architecture allows the optimum sequence of interconnected domains to be selected and network policy to be applied if applicable, via the use of a hierarchical relationship between PCEs.</t>
              <t indent="0">Combining the capabilities of stateful PCE and the hierarchical PCE would be advantageous. This document describes general considerations and use cases for the deployment of stateful, but not stateless, PCEs using the hierarchical PCE architecture.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8751"/>
          <seriesInfo name="DOI" value="10.17487/RFC8751"/>
        </reference>
      </references>
    </references>
    <section anchor="sect-10" numbered="false" toc="include" removeInRFC="false" pn="section-appendix.a">
      <name slugifiedName="name-contributors">Contributors</name>
      <contact fullname="Dhruv Dhody">
        <organization showOnFrontPage="true">Huawei Technologies</organization>
        <address>
          <postal>
            <street>Divyashree Technopark, Whitefield</street>
            <city>Bangalore</city>
            <region>Karnataka</region>
            <code>560066</code>
            <country>India</country>
          </postal>
          <email>dhruv.ietf@gmail.com</email>
        </address>
      </contact>
      <contact fullname="Qin Wu">
        <organization showOnFrontPage="true">Huawei Technologies</organization>
        <address>
          <postal>
            <street/>
            <city/>
            <region/>
            <country>China</country>
          </postal>
          <email>bill.wu@huawei.com</email>
        </address>
      </contact>
      <contact fullname="Xian Zhang">
        <organization showOnFrontPage="true">Huawei Technologies</organization>
        <address>
          <postal>
            <street/>
            <city/>
            <region/>
            <country>China</country>
          </postal>
          <email>zhang.xian@huawei.com</email>
        </address>
      </contact>
      <contact fullname="Adrian Farrel">
        <organization showOnFrontPage="true">Old Dog Consulting</organization>
        <address>
          <postal>
            <street/>
            <city/>
            <region/>
            <country/>
          </postal>
          <email>adrian@olddog.co.uk</email>
        </address>
      </contact>
    </section>
    <section anchor="authors-addresses" numbered="false" removeInRFC="false" toc="include" pn="section-appendix.b">
      <name slugifiedName="name-authors-addresses">Authors' Addresses</name>
      <author fullname="Young Lee" initials="Y." surname="Lee">
        <organization showOnFrontPage="true">Samsung Electronics</organization>
        <address>
          <postal>
            <street/>
            <city>Seoul</city>
            <region/>
            <code/>
            <country>Republic of Korea</country>
          </postal>
          <email>younglee.tx@gmail.com</email>
        </address>
      </author>
      <author initials="H." surname="Zheng" fullname="Haomian Zheng">
        <organization showOnFrontPage="true">Huawei Technologies</organization>
        <address>
          <postal>
            <street>H1, Huawei Xiliu Beipo Village Songshan Lake</street>
            <city>Dongguan</city>
            <region>Guangdong</region>
            <code>523808</code>
            <country>China</country>
          </postal>
          <email>zhenghaomian@huawei.com</email>
        </address>
      </author>
      <author initials="D." surname="Ceccarelli" fullname="Daniele Ceccarelli">
        <organization showOnFrontPage="true">Cisco Systems</organization>
        <address>
          <postal>
            <street>Torshamnsgatan,48</street>
            <city>Stockholm</city>
            <region/>
            <code/>
            <country>Sweden</country>
          </postal>
          <email>daniele.ietf@gmail.com</email>
        </address>
      </author>
    </section>
  </back>
</rfc>
