<?xml version='1.0' encoding='utf-8'?> version="1.0" encoding="UTF-8"?>

<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
  <!ENTITY RFC2119 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"> nbsp    "&#160;">
  <!ENTITY RFC4655 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4655.xml"> zwsp   "&#8203;">
  <!ENTITY RFC5440 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5440.xml"> nbhy   "&#8209;">
  <!ENTITY RFC5541 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5541.xml">
<!ENTITY RFC6805 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6805.xml">
<!ENTITY RFC7470 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7470.xml">
<!ENTITY RFC7942 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7942.xml">
<!ENTITY RFC8051 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8051.xml">
<!ENTITY RFC8174 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml">
<!ENTITY RFC8231 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8231.xml">
<!ENTITY RFC8253 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8253.xml">
<!ENTITY RFC8281 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8281.xml">
<!ENTITY RFC8453 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8453.xml">
<!ENTITY RFC8637 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8637.xml">
<!ENTITY RFC8751 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8751.xml">
<!ENTITY RFC8697 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8697.xml">
<!ENTITY RFC8253 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8253.xml">
<!ENTITY RFC0020 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.0020.xml"> wj     "&#8288;">
]>

<rfc xmlns:xi="http://www.w3.org/2001/XInclude" submissionType="IETF" docName="draft-ietf-pce-vn-association-11" category="std" ipr="trust200902"> consensus="true" docName="draft-ietf-pce-vn-association-11" number="9358" ipr="trust200902"
obsoletes="" updates="" xml:lang="en" symRefs="true" sortRefs="true" tocInclude="true" version="3">

  <!-- xml2rfc v2v3 conversion 3.15.1 -->
  <!-- Generated by id2xml 1.5.0 on 2020-01-02T21:47:46Z -->
    <?rfc strict="yes"?>
    <?rfc compact="yes"?>
    <?rfc subcompact="no"?>
    <?rfc symrefs="yes"?>
    <?rfc sortrefs="no"?>
    <?rfc text-list-symbols="o*+-"?>
    <?rfc toc="yes"?>
    <front>

    <title abbrev="PCE abbrev="PCEP VN Association"> Path Association">Path Computation Element Communication
    Protocol (PCEP) extensions Extensions for establishing relationships Establishing Relationships between sets Sets of
    Label Switched Paths and Virtual Networks</title>
    <seriesInfo name="RFC" value="9358"/>
    <author fullname="Young Lee" initials="Y." surname="Lee">
      <organization>Samsung</organization>
      <organization>Samsung Electronics</organization>
      <address>
        <postal>
          <street></street>
          <street/>
          <city>Seoul</city>
          <region></region>
          <code></code>
          <country>South
          <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>Huawei Technologies</organization>
      <address>
        <postal>
	  <street>H1, Huawei Xiliu Beipo Village, 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>Ericsson</organization>
      <organization>Cisco Systems</organization>
      <address>
        <postal>
          <street>Torshamnsgatan,48</street>
          <city>Stockholm</city>
     <region></region>
     <code></code>
          <region/>
          <code/>
          <country>Sweden</country>
        </postal>
    <email>daniele.ceccarelli@ericsson.com</email>
        <email>daniele.ietf@gmail.com</email>
      </address>
    </author>
    <date year="2022" month="October" day="24"/>
    <workgroup>PCE Working Group</workgroup> year="2023" month="February"/>
    <area>rtg</area>
    <workgroup>pce</workgroup>

    <abstract>

<t> This document describes how to extend the Path Computation Element (PCE)
Communication Protocol (PCEP) association mechanism introduced by the PCEP Association Group specification, 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 virtual network a VN using the PCE architecture.</t>
    </abstract>
  </front>
  <middle>
    <section title="Introduction" anchor="sect-1"> anchor="sect-1" numbered="true" toc="default">
      <name>Introduction</name>
      <t> 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"/>. target="RFC5440" format="default"/>. </t>
      <t> <xref target="RFC8051"/> target="RFC8051" format="default"/> describes general considerations for a stateful PCE deployment and examines its applicability and benefits, benefits as well as its challenges and limitations through a number of use cases. <xref target="RFC8231"/> target="RFC8231" format="default"/> 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), (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> <xref target="RFC8281"/> target="RFC8281" format="default"/> describes the setup, maintenance maintenance, and teardown of PCE-initiated LSPs under the stateful PCE model. </t>
      <t> <xref target="RFC8697"/> target="RFC8697" format="default"/> 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> <xref target="RFC8453"/> target="RFC8453" format="default"/> introduces a framework for Abstraction and Control of TE Networks (ACTN) and describes various Virtual Network (VN) 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> <xref target="RFC8637"/> target="RFC8637" format="default"/> examines the PCE and ACTN architectures and describes how the PCE architecture is applicable to ACTN.  <xref target="RFC6805"/> target="RFC6805" format="default"/> and <xref target="RFC8751"/> describes target="RFC8751" format="default"/> describe a hierarchy of stateful PCEs with Parent the parent PCE coordinating multi-domain path computation function functions between Child child PCEs, and thus making it the base for PCE applicability for ACTN.  As <xref target="RFC8751"/> target="RFC8751" format="default"/> explains, in the context of ACTN, the Child child PCE is identified with the Provisioning Network Controller (PNC), and the Parent parent PCE is identified with the Multi-domain Multi-Domain Service Coordinator (MDSC).</t>

      <t> 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 relaxing constraints, taking policy actions, setting default behavior, etc. </t>
      <t> This document specifies a PCEP extension to associate a set of LSPs based on their Virtual Network (VN). VN.  </t>
    </section>
    <section title="Requirement Language" anchor="sect-1.1">
    <t>The anchor="sect-2" numbered="true" toc="default">
      <name>Terminology</name>
<t>This document uses terminology from <xref target="RFC4655" format="default"/>, <xref target="RFC5440" format="default"/>, <xref target="RFC6805" format="default"/>, <xref target="RFC8231" format="default"/>, and <xref target="RFC8453" format="default"/>. </t>
        <t>
    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", "<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 "OPTIONAL" "<bcp14>OPTIONAL</bcp14>" in this document are
    to be interpreted as described in BCP 14 BCP&nbsp;14 <xref target="RFC2119"/>
    <xref target="RFC8174"/> when, and only when, they appear in all capitals,
    as shown here.</t>
    </section>

    </section>

    <section title="Terminology" anchor="sect-2">
    <t>The terminology is as per <xref target="RFC4655"/>, <xref target="RFC5440"/>, <xref target="RFC6805"/>, <xref target="RFC8231"/> and <xref target="RFC8453"/>. here.
	</t>

    </section>
    <section title="Operation Overview" anchor="sect-3"> anchor="sect-3" numbered="true" toc="default">
      <name>Operation Overview</name>
      <t>As per <xref target="RFC8697"/>, target="RFC8697" format="default"/>, LSPs are associated with other LSPs with which they interact by adding them to a common association group. </t>
      <t>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 - </t>
    <t> <list style="symbols">
        <t> Path Computation: When to, the following:</t>
      <dl newline="false" spacing="normal">
        <dt>Path Computation:</dt>
	<dd>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"/>) target="RFC5541"
	format="default"/>) could be applied for all the LSPs belonging to the
	VN identified by the VN association. </t>
        <t> Path Re-Optimization: The </dd>
        <dt>Path Reoptimization:</dt>
	<dd>The PCE would like to use advanced path computation algorithms and
	optimization techniques that consider all the LSPs belonging to a VN, VN
	and optimize them all together during the path re-optimization. </t>
        </list>
    </t> reoptimization. </dd>
      </dl>
      <t>In this document document, we define a new association group called the VN "VN Association Group (VNAG). (VNAG)".  This grouping is used to define the association between a set of LSPs and a virtual network. VN. </t>
      <t> The Association Object ASSOCIATION object contains a field to identify the type of association, and this document defines a new Association Type value of TBD1 7 to indicate that the association is a "VN Association".  The Association Identifier in the Association Object ASSOCIATION object is the VNAG Identifier and is handled in the same way as the generic association identifier Association Identifier defined in <xref target="RFC8697"/>. target="RFC8697" format="default"/>. </t>
      <t>  In this document, "VNAG object" refers to an Association Object ASSOCIATION object with the Association type Type set to "VN Association". Association" (7). </t>
      <t> Local polices policies on the PCE define the computational and optimization behavior for the LSPs in the VN. An LSP MUST NOT <bcp14>MUST NOT</bcp14> belong to more than one VNAG. If an implementation encounters more than one VNAG object in a PCEP message, it MUST <bcp14>MUST</bcp14> process the first occurrence occurrence, and it MUST <bcp14>MUST</bcp14> ignore the others.  </t>
      <t> <xref target="RFC8697"/> target="RFC8697" format="default"/> specifies the mechanism by which a PCEP speaker can advertise which association types Association Types it supports.  This is done using the ASSOC-Type-List TLV carried within an OPEN object.  A PCEP speaker MUST <bcp14>MUST</bcp14> include the VN Association Type (TBD1) (7) in the ASSOC-Type-List TLV before using the VNAG object in a PCEP message. As per <xref target="RFC8697"/>, target="RFC8697" format="default"/>, if the implementation does not support the VN Association Type, it will return a PCErr message with Error-Type 26 "Association Error" Error-Type=26 (Association Error) and Error-value 1 "Association Error-value=1 (Association Type is not supported". supported). </t>

      <t> The Association IDs Identifiers (VNAG IDs) for this Association Type are dynamic in nature (and and created by the Parent parent PCE (MDSC) based on the VN operations for the LSPs belonging to the same VN). VN.  Operator configuration of VNAG IDs is not supported, so there is no need for an Operator-Configured Operator-configured Association Range to be set.  Thus, the VN Association Type (TBD1) MUST NOT (7) <bcp14>MUST NOT</bcp14> be present in the Operator-Configured Operator-configured Association Range TLV if that TLV is present in the OPEN object.  If an implementation encounters the VN Association Type (TBD1) (7) in an Operator-Configured Operator-configured Association Range TLV, it MUST <bcp14>MUST</bcp14> ignore the associated Start-Assoc-ID and Range values.
      </t>
      <t>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 parent PCE, it receives a virtual network VN creation request by from its customer, with the VN uniquely identified by the Association association parameters (section 6.1.4 of <xref target="RFC8697"/>) (<xref target="RFC8697" sectionFormat="of" section="6.1.4"/>) in the VNAG or the Virtual Network identifier 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 parent PCE sends a PCInitiate Message message with this association information in the VNAG Object. object. This in effect binds an LSP that is to be instantiated at the child PCE with the VN.  The VN association information MUST <bcp14>MUST</bcp14> be included as a part of the first PCRpt message.  Figure 1 <xref target="vn-operations"/> 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, stitched by the border nodes in each domain who that receive the instruction from their child PCE (PNC).
      </t>

    <figure><artwork><![CDATA[

      <figure anchor="vn-operations">
	<name>Example of VN Operations in H-PCE (Hierarchical PCE) Architecture</name>
      <artwork name="" type="" align="left" alt=""><![CDATA[
                          ******
                ..........*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 parent PCE
PNC  -> Child child  PCE
MPI  -> PCEP

         Figure 1: Example of VN operations in H-PCE Architecture
]]></artwork>
      </figure>
      <t>Whenever changes occur with the instantiated LSP in a domain network, the domain child PCE reports the changes using a PCRpt Message message in which the VNAG Object object indicates the relationship between the LSP and the VN. </t>
      <t>Whenever an update occurs with VNs in the Parent parent PCE (due to the customer's request), the parent PCE sends an a PCUpd Message message to inform each affected child PCE of this change. </t>
    </section>
    <section title="Extensions anchor="sect-4" numbered="true" toc="default">
      <name>Extensions to PCEP" anchor="sect-4"> PCEP</name>

      <t>The format of VNAG is as per uses the generic ASSOCIATION object <xref target="RFC8697"/>. target="RFC8697" format="default"/>. </t>
      <t> 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" VENDOR-INFORMATION-TLV specified in <xref target="RFC7470"/> target="RFC7470" format="default"/>  as described below: </t>
    <t><list style="symbols">
       <t>VIRTUAL-NETWORK-TLV: Used
      <dl newline="false" spacing="normal">
        <dt>VIRTUAL-NETWORK-TLV:</dt>
	<dd>Used to communicate the Virtual Network Identifier.</t>
       <t>VENDOR-INFORMATION-TLV: Used Identifier.</dd>
        <dt>VENDOR-INFORMATION-TLV:</dt>
	<dd>Used to communicate arbitrary vendor specific vendor-specific behavioral
	information, as described in <xref target="RFC7470"/>.</t>
       </list>
   </t> target="RFC7470"
	format="default"/>.</dd>
      </dl>
      <t>The format of the VIRTUAL-NETWORK-TLV is as follows.   </t>
    <figure><artwork><![CDATA[

<figure anchor="vn-tlv-formats">
   <name>Format of the VIRTUAL-NETWORK-TLV</name>
      <artwork name="" type="" align="left" alt=""><![CDATA[
 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           Type=65             |            Length (variable)             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
//                   Virtual Network Identifier                //
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
              Figure 2: The VIRTUAL-NETWORK-TLV formats
]]></artwork>
</figure>
    <t>Type (16-bits): TBD2 (to be allocated by IANA) </t>
    <t>Length (16-bits):  indicates

<dl newline="false" spacing="normal">
  <dt>Type (16 bits):</dt>
  <dd>65</dd>
  <dt>Length (16 bits):</dt>
  <dd>Indicates the length of the value portion of the TLV in octets and MUST
  <bcp14>MUST</bcp14> be greater than 0. The TLV MUST <bcp14>MUST</bcp14> be
  zero-padded so that the TLV is 4-octet aligned. </t>
    <t>Virtual aligned.</dd>
  <dt>Virtual Network Identifier (variable): a (variable):</dt>
  <dd>A symbolic name for the VN that uniquely identifies the VN. It SHOULD
  <bcp14>SHOULD</bcp14> be a string of printable ASCII <xref target="RFC0020"/> target="RFC0020"
  format="default"/> characters (i.e., 0x20 to 0x7E), without a NULL
  terminator. The Virtual Network Identifier is a human-readable string that
  identifies a VN, it VN. It can be specified with the association information 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 VNAG
  and the LSPs associated with the VN. The Virtual Network Identifier MAY
  <bcp14>MAY</bcp14> be specified by the customer or customer, set via an operator policy
  policy, or auto-generated by the PCEP speaker. </t> speaker.</dd></dl>
      <t>The VIRTUAL-NETWORK-TLV MUST <bcp14>MUST</bcp14> be included in VNAG object.  If a PCEP speaker receives the VNAG object without the VIRTUAL-NETWORK-TLV, it MUST <bcp14>MUST</bcp14> send a PCErr message with Error-Type=6 (mandatory object (Mandatory Object missing) and Error-Value=TBD3 Error-value=18 (VIRTUAL-NETWORK-TLV missing) and close the session.   </t>
      <t>The format of VENDOR-INFORMATION-TLV is defined in <xref target="RFC7470"/>. target="RFC7470" format="default"/>. </t>
      <t>If a PCEP speaker receives a VN ASSOCIATION VNAG object with a TLV that violates the rules specified in this document, the PCEP speaker MUST <bcp14>MUST</bcp14> send a PCErr message with Error-Type = 10 Error-Type=10 (Reception of an invalid object) and Error-value = 11 Error-value=11 (Malformed object) and MUST <bcp14>MUST</bcp14> close the PCEP session. </t>
    </section>
    <section title="Implementation Status" anchor="sect-5">
    <t>   [Note to the RFC Editor - remove this section before publication, as well as remove the reference to RFC 7942.] </t>
       <t> 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 <xref target="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.   </t>
       <t>According to <xref target="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".   </t>

    <section title="Huawei's Proof of Concept based on ONOS" anchor="sect-6.1"> anchor="sect-6" numbered="true" toc="default">
      <name>Security Considerations</name>
      <t>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.   </t>
    <t>
    <list style="symbols">
      <t>Organization: Huawei</t>
      <t>Implementation: Huawei's PoC based on ONOS</t>
      <t>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</t>
      <t>Maturity Level: Prototype</t>
      <t>Coverage: Full</t>
      <t>Contact: satishk@huawei.com</t>
    </list>
   </t>
    </section>
    </section>

    <section title="Security Considerations" anchor="sect-6">
    <t>   The security considerations described in <xref target="RFC5440"/>, target="RFC5440"
      format="default"/>, <xref target="RFC8231"/> target="RFC8231" format="default"/>, and <xref target="RFC8281"/>
      target="RFC8281" format="default"/> apply to the extensions defined in
      this document as well.</t>

    <t>One new
      <t>This document introduces the VN Association Type (VN Association) (7) for the ASSOCIATION object is introduced in this document. object. Additional security
   considerations related to LSP associations due to a malicious PCEP speaker are described in <xref target="RFC8697"/> target="RFC8697" format="default"/> and apply to the VN Association type. Type.  Hence, securing the PCEP session using Transport Layer Security (TLS) <xref target="RFC8253"/> target="RFC8253" format="default"/> is RECOMMENDED.</t> <bcp14>RECOMMENDED</bcp14>.</t>
    </section>
    <section title="IANA Considerations" anchor="sect-7"> anchor="sect-7" numbered="true" toc="default">
      <name>IANA Considerations</name>
      <section title="Association anchor="sect-7.1" numbered="true" toc="default">
        <name>ASSOCIATION Object Type Indicator" anchor="sect-7.1"> Indicator</name>
        <t>IANA is requested to make has assigned the assignment of a following new value in the sub-registry "ASSOCIATION Type Field" subregistry within the "Path Computation Element Protocol (PCEP) Numbers" registry, as follows: registry:  </t>
       <figure><artwork><![CDATA[
      Value     Name                        Reference

      TBD1      VN Association Type         [This I.D.]
]]></artwork>
    </figure>
<table align="left">
  <name></name>
  <thead>
    <tr>
      <th>Value</th>
      <th>Name</th>
      <th>Reference</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td>7</td>
      <td>VN Association</td>
      <td>RFC 9358</td>
    </tr>
  </tbody>
</table>
      </section>
      <section title="PCEP anchor="sect-7.2" numbered="true" toc="default">
        <name>PCEP TLV Type Indicator" anchor="sect-7.2">
    <t> IANA is requested to make Indicator</name>
        <t>IANA has assigned the assignment of a following new value for in the existing "PCEP TLV Type Indicators" sub-registry subregistry within the "Path
   Computation Element Protocol (PCEP) Numbers" registry, as follows: registry:
        </t>
    <figure><artwork><![CDATA[
      Value     Name                        Reference

      TBD2      VIRTUAL-NETWORK-TLV         [This I.D.]
]]></artwork>
    </figure>
<table align="left">
  <name></name>
  <thead>
    <tr>
      <th>Value</th>
      <th>Name</th>
      <th>Reference</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td>65</td>
      <td>VIRTUAL-NETWORK-TLV</td>
      <td>RFC 9358</td>
    </tr>
  </tbody>
</table>
      </section>
      <section title="PCEP Error" anchor="sect-7.3"> anchor="sect-7.3" numbered="true" toc="default">
        <name>PCEP Error</name>
        <t> IANA is requested to allocate has allocated the following new error value within in the "PCEP-ERROR
        Object Error Types and Values" sub-registry subregistry within the "Path
        Computation Element Protocol (PCEP) Numbers" registry, as follows: registry:
        </t>
       <figure><artwork><![CDATA[
      Error-Type  Meaning

      6           Mandatory
<table align="left">
  <name></name>
  <thead>
    <tr>
      <th>Error-Type</th>
      <th>Meaning</th>
      <th>Error-value</th>
      <th>Reference</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td>6</td>
      <td>Mandatory Object missing
                  Error-value=TBD3: VIRTUAL-NETWORK TLV missing [This
      I.D.]
]]></artwork>
    </figure> missing</td>
      <td>18: VIRTUAL-NETWORK-TLV missing</td>
      <td>RFC 9358</td>
    </tr>
  </tbody>
</table>
      </section>
    </section>
    <section title="Manageability Considerations" anchor="sect-8"> anchor="sect-8" numbered="true" toc="default">
      <name>Manageability Considerations</name>
      <section title="Control anchor="sect-8.1" numbered="true" toc="default">
        <name>Control of Function and Policy" anchor="sect-8.1"> Policy</name>
        <t>An operator MUST <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 title="Information anchor="sect-8.2" numbered="true" toc="default">
        <name>Information and Data Models" anchor="sect-8.2"> Models</name>
        <t>The PCEP YANG module <xref target="I-D.ietf-pce-pcep-yang"/> target="I-D.ietf-pce-pcep-yang" format="default"/> should support the association between LSPs including VN association.
        </t>
      </section>
      <section title="Liveness anchor="sect-8.3" numbered="true" toc="default">
        <name>Liveness Detection and Monitoring" anchor="sect-8.3"> Monitoring</name>
        <t> 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"/>. target="RFC5440" format="default"/>.
        </t>
      </section>
      <section title="Verify anchor="sect-8.4" numbered="true" toc="default">
        <name>Verification of Correct Operations" anchor="sect-8.4"> Operations</name>
        <t>Mechanisms defined in this document do not imply any new operation verification requirements in addition to those already listed in <xref target="RFC5440"/>. target="RFC5440" format="default"/>.
        </t>
      </section>
      <section title="Requirements On anchor="sect-8.5" numbered="true" toc="default">
        <name>Requirements on Other Protocols" anchor="sect-8.5"> Protocols</name>
        <t>Mechanisms defined in this document do not imply any new requirements on other protocols.
        </t>
      </section>
      <section title="Impact On anchor="sect-8.6" numbered="true" toc="default">
        <name>Impact on Network Operations" anchor="sect-8.6"> Operations</name>
        <t><xref target="RFC8637"/> describe target="RFC8637" format="default"/> describes the network operations when PCE is used for VN operations. <xref target="sect-3"/> target="sect-3" format="default"/> further specifies the operations when VN associations are used.</t>
      </section>
    </section>
  </middle>
  <back>
    <references title="Normative References">
    &RFC0020;
    &RFC2119;
    &RFC5440;
    &RFC8174;
    &RFC8231;
    &RFC8253;
    &RFC8281;
    &RFC8697;

    <displayreference target="I-D.ietf-pce-pcep-yang" to="PCE-PCEP-YANG"/>

    <references>
      <name>References</name>
      <references>

        <name>Normative References</name>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.0020.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5440.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8231.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8253.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8281.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8697.xml"/>
      </references>
      <references>
        <name>Informative References</name>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4655.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6805.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8453.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8637.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5541.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7470.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8051.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8751.xml"/>

<!-- [I-D.ietf-pce-pcep-yang] IESG state I-D Exists -->

<reference anchor="I-D.ietf-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>Huawei Technologies</organization>
    </author>
    <author initials="V." surname="Beeram" fullname="Vishnu Pavan Beeram">
      <organization>Juniper Networks</organization>
    </author>
    <author initials="J." surname="Hardwick" fullname="Jonathan Hardwick">
      <organization></organization>
    </author>
    <author initials="J." surname="Tantsura" fullname="Jeff Tantsura">
      <organization>Microsoft</organization>
    </author>
    <date month="October" day="23" year="2022"/>
  </front>
  <seriesInfo name="Internet-Draft" value="draft-ietf-pce-pcep-yang-20"/>
</reference>

      </references>
    <references title="Informative References">
    &RFC4655;
    &RFC6805;
    &RFC7942;
    &RFC8453;
    &RFC8637;
    &RFC5541;
    &RFC7470;
    &RFC8051;
    &RFC8751;
    <?rfc include="reference.I-D.ietf-pce-pcep-yang"?>
    </references>
    <section title="Contributors" anchor="sect-10">
    <figure><artwork><![CDATA[
   Dhruv Dhody
   Huawei Technologies
   Divyashree anchor="sect-10" numbered="false" toc="default">
      <name>Contributors</name>
      <contact fullname="Dhruv Dhody">
	<organization>Huawei Technologies</organization>
	<address>
	  <postal>
	    <street>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 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>Huawei Technologies</organization>
        <address>
          <postal>
            <street></street>
            <city></city>
            <region></region>
            <country>China</country>
          </postal>
          <email>bill.wu@huawei.com</email>
        </address>
      </contact>

      <contact fullname="Xian Zhang">
        <organization>Huawei Technologies</organization>
        <address>
          <postal>
            <street></street>
            <city></city>
            <region></region>
            <country>China</country>
          </postal>
          <email>zhang.xian@huawei.com</email>
        </address>
      </contact>

      <contact fullname="Adrian Farrel">
	<organization>Old Dog Consulting
   Email: adrian@olddog.co.uk
]]></artwork>
    </figure> Consulting</organization>
        <address>
          <postal>
            <street></street>
            <city></city>
            <region></region>
            <country></country>
          </postal>
          <email>adrian@olddog.co.uk</email>
        </address>
      </contact>

    </section>
  </back>

</rfc>