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

<!-- draft submitted in xml v3 -->

<!DOCTYPE rfc [
 <!ENTITY nbsp    "&#160;">
 <!ENTITY zwsp   "&#8203;">
 <!ENTITY nbhy   "&#8209;">
 <!ENTITY wj     "&#8288;">
]>

<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>

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

  <front>

    <title abbrev="Stateful PCEP for GMPLS">Path Computation Element Communication Protocol (PCEP) Extensions for Stateful PCE Usage in GMPLS-controlled GMPLS-Controlled Networks</title>
    <seriesInfo name="Internet-Draft" value="draft-ietf-pce-pcep-stateful-pce-gmpls-23"/> name="RFC" value="9504"/>
    <author fullname="Young Lee" initials="Y." surname="Lee">
      <organization>Samsung</organization>
      <address>
        <email>younglee.tx@gmail.com</email>
      </address>
    </author>

    <author fullname="Haomian Zheng" initials="H." surname="Zheng">
      <organization>Huawei Technologies</organization>
      <address>
        <email>zhenghaomian@huawei.com</email>
      </address>
    </author>

    <author fullname="Oscar Gonzalez de Dios" initials="O." surname="Gonzalez de Dios">
      <organization>Telefonica</organization>
      <address>
        <email>oscar.gonzalezdedios@telefonica.com</email>
      </address>
    </author>

    <author fullname="Victor Lopez" initials="V." surname="Lopez">
      <organization>Nokia</organization>
      <address>
        <email>victor.lopez@nokia.com</email>
      </address>
    </author>

    <author fullname="Zafar Ali" initials="Z." surname="Ali">
      <organization>Cisco</organization>
      <address>
        <email>zali@cisco.com</email>
      </address>
    </author>
    <date month="" year="2023"/>

    <area>Routing Area</area>

    <workgroup>PCE Working Group</workgroup> year="2023" month="December"/>
    <area>rtg</area>
    <workgroup>pce</workgroup>
    <keyword>Stateful PCE</keyword>
    <keyword>GMPLS</keyword>
    <keyword>PCE-initiated LSP</keyword>

    <abstract>
      <t>The PCE communication Path Computation Element Communication Protocol (PCEP) has been extended to support stateful PCE
         functions where the Stateful stateful PCE maintains information about paths and resource
         usage within a network, but network; however, these extensions do not cover all requirements for
         GMPLS networks.</t>

      <t>This document provides the extensions required for PCEP so as to enable the usage
         of a stateful PCE capability in GMPLS-controlled networks.</t>

    </abstract>

  </front>

  <middle>

    <section anchor="intro">
      <name>Introduction</name>

      <t><xref target="RFC4655" /> presents the architecture of a Path Computation Element
      (PCE)-based PCE-based model for computing Multiprotocol Label Switching (MPLS) and Generalized
      MPLS (GMPLS) Traffic Engineering Label Switched Paths (TE LSPs).  To perform such a
      constrained computation, a PCE stores the network topology (i.e., TE links and nodes)
      and resource information (i.e., TE attributes) in its TE Database (TED).  A PCE that
      only maintains a TED is referred to as a stateless PCE. "stateless PCE".  <xref target="RFC5440" />
      describes the Path Computation Element Communication Protocol (PCEP) for interaction
      between a Path Computation Client (PCC) and a PCE, PCE or between two PCEs, enabling
      computation of TE LSPs.  PCEP is further extended to support GMPLS-controlled networks
      as per <xref target="RFC8779" />.</t>

      <t>Stateful PCEs are shown to be helpful in many application scenarios, in both MPLS
      and GMPLS networks, as illustrated in <xref target="RFC8051" />.  Further discussion
      of the concept of a stateful PCE can be found in <xref target="RFC7399" />.  In order for
      these applications to be able to exploit the capability of stateful PCEs, extensions to
      stateful PCEP for GMPLS are required.</t>

      <t><xref target="RFC8051" /> describes how a stateful PCE can be applicable applied to solve
      various problems for MPLS-TE and GMPLS networks and the benefits it brings to such
      deployments.</t>

      <t><xref target="RFC8231" /> specifies a set of extensions to PCEP to enable stateful
      control of TE LSPs where they are configured on the PCC, PCC and control over them could
      be delegated to the PCE. Furthermore, <xref target="RFC8281" /> describes the setup
      and teardown of PCE-initiated LSPs under the active stateful PCE model, without the
      need for local configuration on the PCC. However, both documents omit the specification
      for technology-specific objects/TLVs, objects and TLVs, and they do not cover GMPLS-controlled networks (e.g.,
      Wavelength Switched Optical Network (WSON), Optical Transport Network (OTN), Synchronous
      Optical Network (SONET)/Synchronous (SONET) / Synchronous Digital Hierarchy (SDH), etc. technologies).</t> (SDH)).</t>

      <t>This document focuses on the extensions that are necessary in order for the deployment
      of stateful PCEs and the requirements for PCE-initiated LSPs in GMPLS-controlled networks.
      <xref target="context" /> provides a general context of the usage of Stateful PCE stateful PCEs and PCEP for GMPLS.
      The various requirements for stateful GMPLS, including PCE-initiation PCE initiation for GMPLS LSPs,
      are provided in <xref target="reqs" />. An overview of the PCEP extensions is specified in <xref target="overview" />,
      and a />.
      A solution to address such requirements with PCEP object extensions is specified in <xref target="objs" />.</t>

      <section anchor="conventions">
         <name>Conventions Used in this This Document</name>

         <t>The
        <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" /> target="RFC2119"/> <xref target="RFC8174" /> target="RFC8174"/>
    when, and only when, they appear in all capitals, as shown here.</t> here.
        </t>

      </section>

    </section>

    <section anchor="terms">
      <name>Terminology</name>

      <t>Terminology used in this document is the same as terminology used in <xref target="RFC5440" />,
      <xref target="RFC8231" />, <xref target="RFC8281" />, and <xref target="RFC8779" />.</t>

    </section>

    <section anchor="context">
      <name>General Context of Stateful PCE and PCEP for GMPLS</name>

      <t>This section is built on the basis of Stateful PCE stateful PCEs specified in <xref target="RFC8231" /> and PCEP
      for GMPLS specified in <xref target="RFC8779" />.</t>

      <t>The operation for Stateful of a stateful PCE on LSPs can be divided into two types, types: active stateful PCE and
      passive stateful PCE as (as described in <xref target="RFC8051" />.</t>

      <t>For />).</t>
<ul>
      <li>For active stateful PCE, PCEs, a Path Computation Update Request (PCUpd)  message is sent from the PCE to
      the PCC to update the LSP state for the LSPs delegated to the PCE. Any changes to the delegated LSPs
      generate a Path Computation State Report (PCRpt) message from the PCC to the PCE to convey the changes
      of the LSPs. Any modifications to the Objects/TLVs objects and TLVs that are identified in this document to support
      GMPLS technology-specific
      GMPLS-specific attributes will be carried in the PCRpt and PCUpd messages.</t>

      <t>For messages.</li>

      <li>For passive stateful PCEs, Path Computation Request (PCReq)/ (PCReq) and Path Computation Reply (PCRep)
      messages are used to request for path computation. GMPLS-technology specific Objects GMPLS-specific objects and TLVs are
      defined in <xref target="RFC8779" />, which this document builds on it and adds the stateful PCE aspects
      where applicable. Passive Stateful A passive stateful PCE makes use of PCRpt messages when reporting LSP State state changes
      sent by PCCs to PCEs.  Any modifications to the Objects/TLVs objects and TLVs that are identified in this document
      to support GMPLS technology-specific GMPLS-specific attributes will be carried in the PCRpt message.</t> message.</li></ul>

      <t>Furthermore, the LSP Initiation function of PCEP is defined in <xref target="RFC8281" /> to allow
      the PCE to initiate LSP establishment after the path is computed. An LSP Initiate Request (PCInitiate)
      message is used to trigger the end node to set up the LSP. Any modifications to the Objects/TLVs objects and TLVs that
      are identified in this document to support GMPLS technology-specific GMPLS-specific attributes will be carried in the
      PCInitiate messages.</t>

      <t><xref target="RFC8779" /> defines GMPLS-technology specific Objects/TLVs GMPLS-specific objects and TLVs in stateless PCEP, and PCEP; this
      document makes use of these Objects/TLVs objects and TLVs without modifications where applicable. Where these Objects/TLVs objects and TLVs
      require modifications to incorporate stateful PCE, PCEs, they are described in this document. PCE-Initiated PCE-initiated
      LSPs follow the principle specified in <xref target="RFC8281" />, and the GMPLS-specific extensions are
      also included in this document.</t>

    </section>

    <section anchor="reqs">
      <name>Main Requirements</name>

      <t>This section notes the main functional requirements for PCEP extensions to support stateful PCE PCEs for
      use in GMPLS-controlled networks, based on the description in <xref target="RFC8051" />.  Many
      requirements are common across a variety of network types (e.g., MPLS-TE networks and GMPLS networks)
      and the protocol extensions to meet the requirements are already described in <xref target="RFC8231" />,
      such />
      (such as LSP update, delegation delegation, and state synchronization/report. synchronization/report).  Protection context information that
      describes the GMPLS requirement can also follow the description in <xref target="RFC8745" />.  This
      document does not repeat the description of those protocol extensions.  This document presents protocol
      extensions for a set of requirements which that are specific to the use of a stateful PCE in a GMPLS-controlled
      network.</t>

      <t>The requirements for GMPLS-specific stateful PCE PCEs are as follows:</t>

         <ul>

         <ul spacing="normal">
           <li>Advertisement of the stateful PCE capability.  This generic
           requirement is covered in
           Section 5.4 of <xref target="RFC8231" />. sectionFormat="of"
           section="5.4"/>. The GMPLS-CAPABILITY TLV specified in section 2.1 of <xref
           target="RFC8779" /> sectionFormat="of" section="2.1"/> and its
           extension in this document needs need to be advertised as well. </li>

           <li>All the PCEP messages need to be capable of indicating
           GMPLS-specific switching capabilities.  GMPLS LSP creation/modification/deletion requires
           creation, modification, and deletion require knowledge of LSP switching capability
           capabilities (e.g., Time-Division Multiplex Capable (TDM), Layer 2
           Switch Capable (L2SC), OTN-TDM, Lambda Switch Capable (LSC), etc.)
           and the generalized payload Generalized Payload Identifier (G-PID) to be used according to <xref
           target="RFC3471" />, /> and <xref target="RFC3473" />.  It also requires the specification of that traffic parameters that are both data flow and technology specific be defined. These traffic parameters (also are also known as Traffic Specification (Tspec)), which
           are technology specific. "Traffic Specification" or "Tspec".  Such information would need to be included in various
           PCEP messages.</li>

           <li>In some technologies, path calculation is tightly coupled with
           label selection along the route.  For example, path calculation in
           a Wavelength Division Multiplexing (WDM) network may include lambda
           continuity and/or lambda feasibility constraints and hence constraints; hence, a path
           computed by the PCE is associated with a specific lambda (label).  Hence,
           Thus, in such networks, the label information needs to be provided
           to a PCC in order for a PCE to initiate GMPLS LSPs under the active
           stateful PCE model, i.e.,
           explicit label control Explicit Label Control (ELC) may be
           required.</li>

           <li>Stateful PCEP messages also need to indicate the protection
           context information for the LSP specified by GMPLS, as defined in
           <xref target="RFC4872" />, /> and <xref target="RFC4873" />.</li>

         </ul>

    </section>

    <section anchor="overview">
      <name>Overview of Stateful PCEP Extensions for GMPLS Networks</name>

      <section anchor="capadv">
        <name>Capability Advertisement for Stateful PCEP in GMPLS</name>

        <t>Capability Advertisement has been advertisement is specified in <xref target="RFC8231" />, and />; it can be achieved by using
        the "STATEFUL-PCE-CAPABILITY TLV" STATEFUL-PCE-CAPABILITY TLV in the Open message. Another GMPLS-CAPABILITY TLV has been is defined in
        <xref target="RFC8779" />.  A subregistry to manage the Flag field of the GMPLS-CAPABILITY TLV is has been created by the IANA as requested by <xref target="RFC8779" />.  The following bits are introduced by this document
        in the GMPLS-CAPABILITY TLV as flags to indicate the capability for LSP report, update update, and initiation in
        GMPLS networks: LSP-REPORT-CAPABILITY(TBDa), LSP-REPORT-CAPABILITY (31), LSP-UPDATE-CAPABILITY (TBD1), (30), and LSP-INSTANTIATION-CAPABILITY
        (TBD2). (29). </t>

      </section>

      <section anchor="lspsync">
        <name>LSP Synchronization</name>

        <t>After the session between the PCC and a stateful PCE is initialized, the PCE must learn the state of a
        PCC's LSPs (including its attributes) before it can perform path computations or update LSP attributes in
        a PCC. This process is known as LSP "LSP state synchronization. synchronization".  The LSP attributes attributes, including bandwidth,
        associated route, and protection information etc., are stored by the PCE in the LSP database (LSP-DB).
        Note that, as described in <xref target="RFC8231" />, the LSP state synchronization covers both the bulk
        reporting of LSPs at initialization as well as the reporting of new or modified LSPs during normal operation.
        Incremental LSP-DB synchronization may be desired in a GMPLS-controlled network and network; it is specified in
        <xref target="RFC8232" />.</t>

        <t>The format of the PCRpt message is specified in <xref target="RFC8231" /> and extended in
        <xref target="RFC8623" /> to include the END-POINTS object. The END-POINTS object is extended for
        GMPLS in <xref target="RFC8779" />. The END-POINTS object can be carried in the PCRpt message as
        specified in <xref target="RFC8623" />. The END-POINTS object type for GMPLS is included in the PCRpt
        message as per the same. </t>

        <t>The BANDWIDTH, LSP Attributes (LSPA), Include Route Object (IRO) and Exclude Route Object (XRO) following objects are extended for GMPLS in <xref
        target="RFC8779" /> and are also used in the PCRpt in the same
        manner.
        manner: BANDWIDTH, LSP Attributes (LSPA), Include Route Object (IRO), and Exclude Route Object (XRO). These objects are carried in the PCRpt message as specified in
        <xref target="RFC8231" /> (as the attribute-list defined in Section 6.5 of <xref
        target="RFC5440" /> sectionFormat="of" section="6.5"/> and extended by
        many other documents that define PCEP extensions for specific
        scenarios). </t>

        <t>The SWITCH-LAYER object is defined in <xref target="RFC8282"
        />. This object is carried in the PCRpt message as specified in section 3.2 of <xref
        target="RFC8282" />.</t> sectionFormat="of" section="3.2"/>.</t>

      </section>

      <section anchor="delnclean">
        <name>LSP Delegation and Cleanup</name>

        <t>LSP

        <t>The LSP delegation and cleanup procedure specified in <xref target="RFC8231" target="RFC8281" /> are equally applicable
        to GMPLS LSPs and this document does not modify the associated usage.</t>

      </section>

      <section anchor="lspops">
        <name>LSP Operations</name>

        <t>Both passive and active stateful PCE mechanisms in <xref target="RFC8231" /> are applicable in
        GMPLS-controlled networks. Remote LSP Initiation in <xref target="RFC8281" /> is also applicable in
        GMPLS-controlled networks.</t>

      </section>

    </section>

    <section anchor="objs">
      <name>PCEP Object Extensions</name>

      <section anchor="exist">
        <name>Existing Extensions used Used for Stateful GMPLS</name>

        <t>Existing extensions defined in <xref target="RFC8779" /> can be used in Stateful stateful PCEP with no
        or slight changes for GMPLS network control, including the following: </t>

        <ul>

          <li>END-POINTS: Generalized

        <dl spacing="normal" newline="false">
          <dt>END-POINTS:</dt>
	  <dd><t>The END-POINTS object was specified in <xref target="RFC8779"
	  /> to include GMPLS capabilities. All Stateful stateful PCEP messages MUST
	  <bcp14>MUST</bcp14> include the END-POINTS object with Generalized Endpoint
	  object type, containing the LABEL-REQUEST TLV.  Further note that:</li>

          <li><ul>
	  that:</t>
	  <ul spacing="normal">
            <li>As per <xref target="RFC8779" /> />, for stateless GMPLS path
            computation, the Generalized END-POINTS object may contain a
            LABEL-REQUEST and/or LABEL-SET TLV. In this document, only the
            LABEL-REQUEST TLV is used to specify the switching type, encoding type
            type, and G-PID of the LSP. </li>
            <li>If unnumbered endpoint addresses are used for the LSP, the
            UNNUMBERED-ENDPOINT TLV <xref target="RFC8779" /> MUST
            <bcp14>MUST</bcp14> be used to specify the unnumbered endpoint
            addresses.</li>
            <li>The Generalized END-POINTS MAY object <bcp14>MAY</bcp14> contain other
            TLVs defined in <xref target="RFC8779" />.</li>

          </ul></li>

          <li>RP: RP
          </ul></dd>
	  <dt>RP:</dt>
  <dd>The Request Parameter (RP) object extension, together extension (together with the Routing Granularity (RG)
	  flag defined in <xref target="RFC8779" />, are />) is applicable in the Stateful
	  stateful PCEP for GMPLS networks. </li>

          <li>BANDWIDTH: Generalized </dd>
          <dt>BANDWIDTH:</dt>
	  <dd>Generalized BANDWIDTH was is specified in <xref target="RFC8779" />
	  to represent GMPLS features, including asymmetric bandwidth and
	  G-PID information. </li>

          <li>LSPA: LSPA </dd>
          <dt>LSPA:</dt>
	  <dd>LSPA Extensions in Section 2.8 of <xref target="RFC8779" /> is sectionFormat="of"
	  section="2.8"/> are applicable in Stateful stateful PCEP for GMPLS
	  networks. </li>

          <li>IRO: IRO </dd>
          <dt>IRO:</dt>
	  <dd>IRO Extensions in Section 2.6 of <xref target="RFC8779" /> is sectionFormat="of"
	  section="2.6"/> are applicable in Stateful stateful PCEP for GMPLS networks.</li>

          <li>XRO: XRO
	  networks.</dd>
          <dt>XRO:</dt>
	  <dd>XRO Extensions in Section 2.7 of <xref target="RFC8779" /> is sectionFormat="of"
	  section="2.7"/> are applicable in Stateful stateful PCEP for GMPLS networks. A
	  new flag is defined in <xref target="flags" /> of this document. </li>

          <li>ERO: The
	  document.</dd>
          <dt>ERO:</dt>
	  <dd>The Explicit Route Object (ERO) was is not extended in <xref
	  target="RFC8779" />, nor is it in this document. </li>

          <li>SWITCH-LAYER: SWITCHING-LAYER document.</dd>
          <dt>SWITCH-LAYER:</dt>
	  <dd>The SWITCH-LAYER definition in Section 3.2 of <xref target="RFC8282" />
	  sectionFormat="of" section="3.2"/> is applicable in Stateful stateful PCEP
	  messages for GMPLS networks.</li>

        </ul> networks.</dd>
        </dl>

      </section>

      <section anchor="new">
        <name>New Extensions</name>

        <section anchor="captlv">
          <name>GMPLS-CAPABILITY TLV in OPEN Object</name>

          <t>In <xref target="RFC8779" />, IANA has allocated allocates value 45
          (GMPLS-CAPABILITY) from the "PCEP TLV Type Indicators" sub-registry.  The specifcation add subregistry.
          This specification adds three flags to the flag Flag field of this TLV to
          indicate the Report, Update, and Initiation capabilities.</t>

          <t>R (LSP-REPORT-CAPABILITY(TBDa)
	  <dl newline="true" spacing="normal">
            <dt>R (LSP-REPORT-CAPABILITY (31) -- 1 bit): if bit):</dt>
	    <dd>If set to 1 by a PCC, the R flag indicates that the PCC is
	    capable of reporting the current state of a GMPLS LSP, LSP whenever
	    there's a change to the parameters or operational status of the
	    GMPLS LSP; if LSP.  If set to 1 by a PCE, the R Flag flag indicates that the PCE
	    is interested in receiving GMPLS LSP State Reports whenever there
	    is a parameter or operational status change to the LSP.  The
	    LSP-REPORT-CAPABILITY flag must be advertised by both a PCC and a
	    PCE for PCRpt messages to be allowed on a PCEP session for GMPLS LSP.</t>

          <t>U (LSP-UPDATE-CAPABILITY(TBD1)
	    LSP.</dd>
            <dt>U (LSP-UPDATE-CAPABILITY (30) -- 1 bit): if bit):</dt>
	    <dd>If set to 1 by a PCC, the U flag indicates that the PCC allows
	    modification of GMPLS LSP parameters; if parameters.  If set to 1 by a PCE, the U
	    flag indicates that the PCE is capable of updating GMPLS LSP
	    parameters.  The LSP-UPDATE-CAPABILITY flag must be advertised by
	    both a PCC and a PCE for PCUpd messages to be allowed on a PCEP
	    session for GMPLS LSP.</t>

          <t>I (LSP-INSTANTIATION-CAPABILITY(TBD2) LSP.</dd>
            <dt>I (LSP-INSTANTIATION-CAPABILITY (29) -- 1 bit): If bit):</dt>
	    <dd>If set to 1 by a PCC, the I flag indicates that the PCC allows
	    instantiation of a GMPLS LSP by a PCE.  If set to 1 by a PCE, the
	    I flag indicates that the PCE supports instantiating GMPLS LSPs.
	    The LSP-INSTANTIATION-CAPABILITY flag must be set by both the PCC
	    and PCE in order to enable PCE-initiated LSP instantiation.</t>
	    instantiation.</dd></dl>

        </section>

        <section anchor="exclusion">
          <name>New LSP Exclusion Sub-object Subobject in the XRO</name>

          <t><xref target="RFC5521" /> defines a mechanism for a PCC to request or demand that
          specific nodes, links, or other network resources are be excluded from paths computed by
          a PCE.  A PCC may wish to request the computation of a path that avoids all links and
          nodes traversed by some other LSP.</t>

          <t>To this end end, this document defines a new sub-object subobject for use with route exclusion defined
          in <xref target="RFC5521" />.  The LSP exclusion sub-object Exclusion subobject is as follows:</t>

     <figure anchor="lspexcl-fig" title="New LSP Exclusion Sub-object Subobject Format">
            <artwork>
              <![CDATA[
            <artwork><![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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|X|Type (TBD3) (11)    |     Length    |   Reserved    |    Flags      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
//                    Symbolic Path Name                       //
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
              ]]>
            </artwork>
]]></artwork>
    </figure>

          <t>X: Same

    <dl newline="false" spacing="normal">
        <dt>X:</dt>
	<dd><t>This field is the same as the X-bit defined in the XRO sub-objects subobjects in Section 2.1.1 of <xref
	target="RFC5521" /> sectionFormat="of" section="2.1.1"/> where it says: "The says:</t>

<!--Begin DNE - direct quote blockquote not available in dd tags yet (see https://github.com/ietf-tools/xml2rfc/issues/570. -->
	<t indent="3">The X-bit indicates whether the exclusion is mandatory or desired.  0
	indicates that the resource specified MUST <bcp14>MUST</bcp14> be excluded
	from the path computed by the PCE.  1 indicates that the resource
	specified SHOULD <bcp14>SHOULD</bcp14> be excluded from the path computed by
	the PCE, but MAY <bcp14>MAY</bcp14> be included subject to PCE policy and
	the absence of a viable path that meets the other constraints and
	excludes the resource.". </t>

          <t>Type: Sub-object Type resource.</t></dd>

<!--End DNE-->

        <dt>Type:</dt>
	<dd>The subobject type for an LSP exclusion sub-object. Exclusion subobject. Value of TBD3. To be assigned by IANA. </t>

          <t>Length: The 11.</dd>
        <dt>Length:</dt>
	<dd>The Length contains the total length of the sub-object subobject in bytes,
	including the Type and Length fields. </t>

          <t>Reserved: MUST fields.</dd>
        <dt>Reserved:</dt>
	<dd>Reserved <bcp14>MUST</bcp14> be set to zero on transmission and ignored on receipt.</t>

          <t>Flags: This
	receipt.</dd>
        <dt>Flags:</dt>
	<dd>This field may be used to further specify the exclusion constraint
	with regard to the LSP. Currently, no flags are defined.</t>

          <t>Symbolic defined.</dd>
        <dt>Symbolic Path Name: This Name:</dt>
	<dd><t>This is the identifier given to an LSP. Its syntax and
	semantics are identical to those of the Symbolic Path Name field
	defined in Section 7.3.2 of <xref target="RFC8231" /> sectionFormat="of" section="7.3.2"/>
	where it says: "symbolic name for the LSP, unique in the PCC.  It SHOULD
	<bcp14>SHOULD</bcp14> be a string of printable ASCII characters,
	without a NULL terminator."  The
          Symbolic Path Name symbolic path name in the LSP
	Exclusion Sub-object MUST subobject <bcp14>MUST</bcp14> only vary from being a string
	of printable ASCII characters without a NULL terminator when it is
	matching the value contained in another subobject.  It is worth noting
	that given that the Symbolic Path Name symbolic path name is unique in the context of the
	headnode, only LSPs that share the same headnode/PCC headnode or PCC could be
	excluded.</t>
        <t>This sub-object MAY subobject <bcp14>MAY</bcp14> be present multiple times in the exclude route object (XRO)
        XRO to exclude resources from multiple LSPs.
        When a stateful PCE receives a PCReq message carrying this
          sub-object, subobject,
        it MUST <bcp14>MUST</bcp14> search for the identified LSP in its LSP-DB and
        then exclude from the new path computation all resources used by the
        identified LSP.</t>

        <t>Note that this XRO Sub-object subobject could also be used by non-GMPLS LSPs.
        The description by usage of the XRO subobject for any non-GMPLS LSPs is not in the scope of this document. </t>
	</dd>
	</dl>

        </section>

        <section anchor="flags">
          <name>New flags Flags in the LSP-EXTENDED-FLAG TLV in LSP Object</name>

          <t>The LSP Object object is defined in Section 7.3 of <xref target="RFC8231" />,
          sectionFormat="of" section="7.3"/>, and the new extended flags TLV
          is defined in <xref target="RFC9357" />.  This TLV is used in PCUpd,
          PCRpt and PCInitiate messages for GMPLS, with the following flags
          defined in this document.</t>

          <ul>

            <li>G document:</t>

          <dl spacing="normal" newline="true">
            <dt>G (GMPLS LSP(TBDb) LSP (0) -- 1 bit) :  If bit):</dt>
	    <dd>If set to 1, it indicates the LSP is a GMPLS LSP.</li>

            <li>B LSP.</dd>
            <dt>B (Bidirectional LSP(TBD4) LSP (1) -- 1 bit):  If bit):</dt>
	    <dd>If set to 0, it indicates a request to create a
            uni-directional
	    unidirectional LSP.  If set to 1, it indicates a request to
	    create a bidirectional co-routed LSP.</li>

            <li>RG LSP.</dd>

            <dt>RG (Routing Granularity(TBDc) Granularity (2-3) -- 2 bits) : bits):</dt>
	    <dd><t>The RG flag for GMPLS is also defined in the LSP-EXTENDED-FLAG
	    TLV. The value values are defined as per <xref target="RFC8779" />:</li>

          </ul>

          <t>00: reserved</t>
          <t>01: node</t>
          <t>10: link</t>
          <t>11: label</t> />:</t>
            <dl spacing="compact">
	      <dt>00:</dt>
	      <dd>reserved</dd>
              <dt>01:</dt>
	      <dd>node</dd>
              <dt>10:</dt>
	      <dd>link</dd>
              <dt>11:</dt>
	      <dd>label</dd>
	    </dl>
	    </dd>
	  </dl>

        </section>

      </section>

    </section>

    <section anchor="errors">
      <name>Update to Error Handling</name>

      <t>A PCEP-ERROR object is used to report a PCEP error and is
      characterized by an Error-Type that specifies the type of error and an
      Error-value that provides additional information about the error.  This
      section adds additional error handling procedures to those specified in Section 3 of
      <xref target="RFC8779" />. sectionFormat="of" section="3"/>.  Please note
      that all error handling specified in
      Section 3 of <xref target="RFC8779" />
      sectionFormat="of" section="3"/> is applicable and MUST <bcp14>MUST</bcp14>
      be supported for a stateful PCE in GMPLS networks.</t>

      <section anchor="errcap">
        <name>Error Handling in PCEP Capabilities Advertisement</name>

        <t>The PCEP extensions described in this document for stateful PCEs with GMPLS capability
        MUST NOT capabilities
        <bcp14>MUST NOT</bcp14> be used if the PCE has not advertised its capabilities with GMPLS as per <xref target="captlv" />.</t>

        <t>If the PCC understands the U flag that indicates the stateful LSP-UPDATE-CAPABILITY, but did
        not advertise this capability, then upon receipt of a PCUpd message for GMPLS LSP from the PCE,
        it SHOULD <bcp14>SHOULD</bcp14>
	generate a PCErr with error-type Error-Type 19 ("Invalid Operation"), error-value TBDx Operation") Error-value 25 ("Attempted LSP Update Request update request for GMPLS if stateful PCE capability for GMPLS was not advertised"), advertised") and terminate
        the PCEP session. Such a PCC MAY <bcp14>MAY</bcp14> decide to utilize the capability even though it did not advertise
        support for it. </t>

        <t>If the PCE understands the R flag that indicates the stateful LSP-REPORT-CAPABILITY, but did not
        advertise this capability, then upon receipt of a PCRpt message for GMPLS LSP from the PCC, it SHOULD <bcp14>SHOULD</bcp14>
        generate a PCErr with error-type Error-Type 19 ("Invalid Operation"), error-value TBDy Operation") Error-value 26 ("Attempted LSP State Report
        Request for GMPLS if stateful PCE capability for GMPLS was not advertised"), advertised") and terminate the PCEP
        session. Such a PCE MAY <bcp14>MAY</bcp14> decide to utilize the capability even though it did not advertise support
        for it.</t>

        <t>If the PCC  understands the I flag that indicates LSP-INSTANTIATION-CAPABILITY, but did not
        advertise this capability, then upon receipt of a PCInitiate message for GMPLS LSP from the PCE,
        it SHOULD <bcp14>SHOULD</bcp14> generate a PCErr with error-type Error-Type 19 ("Invalid Operation"), error-value TBDz Operation") Error-value 27 ("Attempted
        LSP Instantiation Request instantiation request for GMPLS if stateful PCE instantiation capability for GMPLS was not
        advertised"),
        advertised") and terminate the PCEP session. Such a PCC MAY <bcp14>MAY</bcp14> decide to utilize the capability
        even though it did not advertise support for it.</t>

      </section>

      <section anchor="erropt">
        <name>Error Handling in LSP Re-optimization</name> Reoptimization</name>

        <t>A stateful PCE is expected to perform an LSP re-optimization reoptimization when receiving a message with the
        R bit set in the RP object.

	If no LSP state information is available to carry out re-optimization, reoptimization,
        the stateful PCE SHOULD <bcp14>SHOULD</bcp14> report the error "LSP Error-Type 19 ("Invalid Operation") Error-value 23 ("LSP state information info unavailable for the LSP
        re-optimization" (Error Type = 19, Error value= TBD6), reoptimization"), although such a PCE MAY <bcp14>MAY</bcp14> consider the
        re-optimization
        reoptimization to have successfully completed.  Note that this error message could also be
        used by non-GMPLS LSPs.</t>

      </section>

      <section anchor="errex">
        <name>Error Handling in Route Exclusion</name>

        <t>The LSP exclusion sub-object Exclusion subobject in XRO is XRO, as defined in <xref target="exclusion" /> of this document MAY document, <bcp14>MAY</bcp14> be present
        multiple times.  When a stateful PCE receives a PCEP message carrying this sub-object, subobject, it searches
        for the identified LSP in its LSP-DB and LSP-DB.  It then excludes from the new path computation all the
        resources used by the identified LSP.  If the stateful PCE cannot recognize the symbolic path
        name of the identified LSP, it SHOULD <bcp14>SHOULD</bcp14> send an error message PCErr reporting Error-type = Error-Type 19 ("Invalid Operation"), Operation") Error-value = TBD7 ("The LSP 24 ("LSP state information info for route exclusion purpose
        cannot be not found").  Optionally, it MAY also provide  Along with the unrecognized symbolic path name name, it <bcp14>MAY</bcp14> also provide information to the requesting PCC using the error reporting error-reporting techniques described in <xref
        target="RFC5440" />.

	An implementation MAY <bcp14>MAY</bcp14> choose to ignore the requested exclusion when the
        LSP cannot be found because it could claim it that it has avoided using all resources associated
        with an LSP that doesn't exist. </t>

      </section>

      <section anchor="errgen">
        <name>Error Handling for generalized END-POINTS</name> the Generalized END-POINTS Object</name>

        <t>Note that the END-POINTS object in the Stateful stateful PCEP messages was introduced for P2MP Point-to-Multipoint (P2MP)
        <xref target="RFC8623" />. Similarly, the END-POINTS object MUST <bcp14>MUST</bcp14> be carried for the GMPLS
        LSP.  If the END-POINTS object is missing and the GMPLS flag in LSP-EXTENDED-FLAG is set,
        the receiving PCE or PCC MUST <bcp14>MUST</bcp14> send a PCErr message with Error-type=6 Error-Type 6 ("Mandatory Object missing") and Error-value=3 Error-value 3 ("END-POINTS object missing") (defined in <xref target="RFC5440" />).
        Similarly, if the END-POINTS object with the Generalized Endpoint object type is received but if
        the LSP-EXTENDED-FLAG TLV is missing in the LSP object or if the G flag in the LSP-EXTENDED-FLAG
        TLV is not set, the receiving PCE or PCC MUST <bcp14>MUST</bcp14> send a PCErr message with Error-type = Error-Type 19 ("Invalid
        Operation"), Operation") Error-value = TBD9 28 ("Use of the Generalized Endpoint object type for non-GMPLS LSP").</t> LSPs").</t>

        <t>If the END-POINTS object with Generalized Endpoint Object Type object type is missing the LABEL-REQUEST
        TLV, the receiving PCE or PCC MUST <bcp14>MUST</bcp14> send a PCErr message with Error-type=6 Error-Type 6 ("Mandatory Object missing") and Error-value=TBD8 Error-value 20 ("LABEL-REQUEST TLV missing"). </t>

      </section>

    </section>

    <section anchor="imp">
      <name>Implementation</name>

      <t>[NOTE TO RFC EDITOR : This whole section and the reference to RFC 7942 is to be removed
      before publication as an RFC]</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 anchor="huawei">
        <name>Huawei Technologies</name>

        <ul>
          <li>Organization: Huawei Technologies, Co. LTD</li>
          <li>Implementation: Huawei NCE-T </li>
          <li>Description: PCRpt, PCUpd and PCInitiate messages for GMPLS Network</li>
          <li>Maturity Level: Production</li>
          <li>Coverage: Full</li>
          <li>Contact: zhenghaomian@huawei.com</li>
        </ul>

      </section>

    </section>

    <section anchor="iana">
      <name>IANA Considerations</name>

      <section anchor="iana-flag">
        <name>title=New
        <name>New Flags in the GMPLS-CAPABILITY TLV</name>

        <t><xref target="RFC8779" /> defines the GMPLS-CAPABILITY TLV; per that RFC, IANA created a the "GMPLS-CAPABILITY TLV Flag Field" registry to manage the value values of the GMPLS-CAPABILITY TLV's Flag field.  This document requests
        IANA to allocate registers new bits in the GMPLS-CAPABILITY TLV Flag Field registry, this registry as follows. IANA is
        requested to make allocations starting from the least significant bit (31).</t>

        <artwork>
          <![CDATA[
    Bit  | Description                      | Reference
    -----+----------------------------------+------------
    TBDa | LSP-REPORT-CAPABILITY (R)        | [This.I-D]
    TBD1 | LSP-UPDATE-CAPABILITY (U)        | [This.I-D]
    TBD2 | LSP-INSTANTIATION-CAPABILITY (I) | [This.I-D]
          ]]>
        </artwork> follows:</t>

<table anchor="iana-1" align="center">
  <name></name>
  <thead>
    <tr>
      <th>Bit</th>
      <th>Capability Description</th>
      <th>Reference</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td>31</td>
      <td>LSP-REPORT-CAPABILITY (R)</td>
      <td>RFC 9504</td>
    </tr>
    <tr>
      <td>30</td>
      <td>LSP-UPDATE-CAPABILITY (U)</td>
      <td>RFC 9504</td>
      </tr>
      <tr>
	<td>29</td>
	<td>LSP-INSTANTIATION-CAPABILITY (I)</td>
	<td>RFC 9504</td>
      </tr>
  </tbody>
</table>

      </section>

      <section anchor="iana-xro">
        <name>New Sub-object Subobject for the Exclude Route Object</name>

        <t>IANA maintains the various XRO Subobjects subobject types within the "XRO Subobjects" subregistry
        of the PCEP Numbers "Path Computation Element Protocol (PCEP) Numbers" registry.  IANA is requested to allocate has allocated a codepoint for another XRO
        subobject as follows:</t>

        <artwork>
          <![CDATA[
   Value  | Description                  | Reference
  --------+------------------------------+-------------
   TBD3   | LSP                          | [This.I-D]
          ]]>
        </artwork>

<table anchor="iana-2" align="center">
  <name></name>
  <thead>
    <tr>
      <th>Value</th>
      <th>Description</th>
      <th>Reference</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td>11</td>
      <td>LSP</td>
      <td>RFC 9504</td>
    </tr>
  </tbody>
</table>

      </section>

      <section anchor="iana-excl">
        <name>Flags Field for the LSP exclusion Sub-object</name> Exclusion Subobject</name>

        <t>IANA is requested to create has created a registry named "LSP Exclusion  Sub-Object Subobject Flag Field",
        within the "Path Computation Element Protocol (PCEP) Numbers" group, to manage the Flag
        field of the LSP Exclusion sub-object subobject in the XRO. No Flag flag is currently defined for this
        flag
        Flag field in this document.</t>

        <t>Codespace of the Flag field (LSP Exclusion sub-object)</t>

        <artwork>
          <![CDATA[
     Bit  | Description       | Reference
    ------+-------------------+-------------
     0-7  | Unassigned        | [This.I-D]
          ]]>
        </artwork> Subobject)</t>

<table anchor="iana-3" align="center">
  <name></name>
  <thead>
    <tr>
      <th>Bit</th>
      <th>Capability Description</th>
      <th>Reference</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td>0-7</td>
      <td>Unassigned</td>
      <td>RFC 9504</td>
    </tr>
  </tbody>
</table>

        <t>New values are to be assigned by Standards Action <xref target="RFC8126" />.
        Each bit should be tracked registered with the following qualities:</t> entries:</t>

        <ul>
           <li>Bit number (counting from bit 0 as the most significant bit)</li>
           <li>Capability description</li>
           <li>Defining
           <li>Reference to defining RFC</li>
        </ul>

      </section>

      <section anchor="iana-extend">
        <name>New Flags in the LSP-EXTENDED-FLAGS TLV</name>

        <t><xref target="I-D.ietf-pce-lsp-extended-flags" target="RFC9357" /> requested IANA to create a
        subregistry, named the "LSP-EXTENDED-FLAG TLV Flag Field", within the "Path Computation
        Element Protocol (PCEP) Numbers" registry, to manage the Flag field of the
        LSP-EXTENDED-FLAG TLV.</t>

        <t>IANA is requested to make has made assignments from this registry as follows:</t>

         <artwork>
           <![CDATA[
    Bit   | Description                      | Reference
    ------+----------------------------------+------------
    TBDb  | GMPLS LSP (G)                    | [This.I-D]
    TBD4  | Bi-directional co-routed LSP (B) | [This.I-D]
    TBDc* | Routing

<table anchor="iana-4" align="center">
  <name></name>
  <thead>
    <tr>
      <th>Bit</th>
      <th>Capability Description</th>
      <th>Reference</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td>0</td>
      <td>GMPLS LSP (G)</td>
      <td>RFC 9504</td>
    </tr>
    <tr>
      <td>1</td>
      <td>Bidirectional Co-routed LSP (B)</td>
      <td>RFC 9504</td>
    </tr>
    <tr>
      <td>2-3</td>
      <td>Routing Granularity Flag (RG)    | [This.I-D]
          ]]>
        </artwork>

        <t>* - 2 bits need to be allocated</t> (RG)</td>
      <td>RFC 9504</td>
    </tr>
  </tbody>
</table>

      </section>

      <section anchor="iana-er">
<name>New PCEP Error Codes</name>

        <t>IANA is requested to make has made the following allocation allocations in the "PCEP-ERROR Object
        Error Types and Values" registry.</t>

        <artwork>
          <![CDATA[
+===========+================+=========================+===========+
| Error-Type| Meaning        | Error-value             | Reference |
+===========+================+=========================+===========+
| 6         | Mandatory      |TBD8:

<table anchor="iana-5" align="center">
  <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</td>
	<td>20: LABEL-REQUEST TLV  | This I-D  |
|           | Object missing |missing                  |           |
|-----------|----------------+-------------------------+-----------+
|19         | Invalid        |TBD6: missing</td>
	<td>RFC 9504</td>
      </tr>
      <tr>
	<td rowspan="6">19</td>
	<td rowspan="6">Invalid Operation</td>
	<td>23: LSP state info     | This I-D  |
|           | Operation      |unavailable unavailable for the      |           |
|           |                |Re-optimization          |           |
|           |                +-------------------------+-----------+
|           |                |TBD7: reoptimization</td>
	<td>RFC 9504</td>
      </tr>
      <tr>
	<td>24: LSP state info for | This I-D  |
|           |                |route route exclusion not found|           |
|           |                +-------------------------+-----------+
|           |                |TBDx: found</td>
	<td>RFC 9504</td>
      </tr>
      <tr>
	<td>25: Attempted LSP      | This I-D  |
|           |                |Update Request update request for GMPLS |           |
|           |                |if if stateful PCE          |           |
|           |                |capability capability not advertised|           |
|           |                +-------------------------+-----------+
|           |                |TBDy: advertised</td>
	<td>RFC 9504</td>
      </tr>
      <tr>
	<td>26: Attempted LSP State| This I-D  |
|           |                |Report State Report for GMPLS if      |           |
|           |                |stateful stateful PCE capability  |           |
|           |                |not advertised           |           |
|           |                +-------------------------+-----------+
|           |                |TBDz: not advertised</td>
	<td>RFC 9504</td>
      </tr>
      <tr>
	<td>27: Attempted LSP      | This I-D  |
|           |                |Instantiation Request for|           |
|           |                |GMPLS instantiation request for GMPLS if stateful PCE    |           |
|           |                |instantiation instantiation capability |           |
|           |                |not advertised           |           |
|           |                +-------------------------+-----------+
|           |                |TBD9: use not advertised</td>
	<td>RFC 9504</td>
      </tr>
      <tr>
	<td>28: Use of the Generalized | This I-D  |
|           |                |Endpoint Endpoint object type for |           |
|           |                |non-GMPLS LSP            |           |
+-----------+----------------+-------------------------+-----------+
          ]]>
        </artwork> non-GMPLS LSPs</td>
	<td>RFC 9504</td>
      </tr>
    </tbody>
  </table>

      </section>

    </section>

    <section anchor="mgmt">
      <name>Manageability Considerations</name>

      <t>General PCE management considerations are discussed in <xref target="RFC4655" />
      and <xref target="RFC5440" />, and GMPLS specific GMPLS-specific PCEP management considerations are
      described in <xref target="RFC8779" />.  In this document document, the management considerations
      for stateful PCEP extension in GMPLS are described. </t>

      <t>This section follows the guidance of <xref target="RFC6123" />.</t>

      <section>
        <name>Control of Function through Configuration and Policy</name>

        <t>In addition to the parameters already listed in Section 8.1 of <xref
        target="RFC5440" />, sectionFormat="of" section="8.1"/>, a PCEP
        implementation SHOULD <bcp14>SHOULD</bcp14> allow configuration of the
        following PCEP session parameters on a PCC, however, PCC.  However, an implementation MAY
        <bcp14>MAY</bcp14> choose to make these features available on all PCEP
        sessions:</t>

        <ul>
          <li>The ability to send stateful PCEP messages for GMPLS LSPs.</li>
          <li>The ability to use path computation constraints (e.g., XRO).</li>
        </ul>

        <t>In addition to the parameters already listed in Section 8.1 of <xref
        target="RFC5440" />, sectionFormat="of" section="8.1"/>, a PCEP
        implementation SHOULD <bcp14>SHOULD</bcp14> allow configuration of the
        following PCEP session parameters on a PCE:</t>

        <ul>
          <li>The ability to compute paths in a stateful manner in GMPLS networks.</li>
          <li>A set of GMPLS-specific constraints.</li>
        </ul>

        <t>These parameters may be configured as default parameters for any PCEP session the PCEP
        speaker participates in, in or they may apply to a specific session with a given PCEP peer
        or a specific group of sessions with a specific group of PCEP peers.</t>

      </section>

      <section>
        <name>Information and Data Models</name>

        <t>The YANG model module in <xref target="I-D.ietf-pce-pcep-yang" /> can be used to configure and
        monitor PCEP states and messages. To make sure that the YANG model module is useful for the
        extensions as described in this document, it would need to include advertised GMPLS stateful
        capabilities etc. A future version of <xref target="I-D.ietf-pce-pcep-yang" /> will include
        this.</t>

        <t>As described in <xref target="I-D.ietf-teas-yang-path-computation" />, a YANG-based
        interface can be used in some cases to request GMPLS path computations, instead of PCEP.
        Refer to <xref target="I-D.ietf-teas-yang-path-computation" /> for details.  </t>

      </section>

      <section>
        <name>Liveness Detection and Monitoring</name>

        <t>This document makes no change to the basic operation of PCEP, so
        there are no changes to the requirements for liveness detection and
        monitoring in <xref target="RFC4657" /> and Section 8.3 of <xref target="RFC5440" />.</t>
        sectionFormat="of" section="8.3"/>.</t>

      </section>

      <section>
        <name>Verifying Correct Operation</name>

        <t>This document makes no change to the basic operations of PCEP and
        the considerations described in Section 8.4 of <xref target="RFC5440" />.
        sectionFormat="of" section="8.4"/>.  New errors defined by this
        document should satisfy the requirement to log error events.</t>

      </section>

      <section>
        <name>Requirements on Other Protocols and Functional Components</name>

        <t>When the detailed route information is included for LSP state synchronization (either
        at the initial stage or during the LSP state report State Report process), this requires the ingress node
        of an LSP to carry the RRO Record Route Object (RRO) object in order to enable the collection of such information. </t>

      </section>

      <section>
        <name>Impact on Network Operation</name>

        <t>The management considerations concerning the impact on network
        operations described in Section 4.6 of <xref target="RFC8779" /> sectionFormat="of"
        section="4.6"/> apply here.</t>

      </section>

    </section>

    <section>
      <name>Security Considerations</name>

      <t>The security considerations elaborated in <xref target="RFC5440" /> apply to this
      document.  The PCEP extensions to support GMPLS-controlled networks should be considered
      under the same security as for MPLS networks, as noted in <xref target="RFC7025" />.  So  Therefore,
      the PCEP extension to support GMPLS specified in <xref target="RFC8779" /> is used as the
      foundation of this document and document; the security considerations in <xref target="RFC8779" />
      should also be applicable to this document.  The secure transport of PCEP specified in
      <xref target="RFC8253" /> allows the usage of Transport Layer Security (TLS).  The same
      can also be used by the PCEP extension defined in this document. </t>

      <t>This document provides additional extensions to PCEP so as to facilitate stateful
      PCE usage in GMPLS-controlled networks, on top of <xref target="RFC8231" /> and
      <xref target="RFC8281" />.  Security issues caused by the extension in
      <xref target="RFC8231" /> and <xref target="RFC8281" /> are not altered by the additions
      in this document.  The security considerations in <xref target="RFC8231" /> and
      <xref target="RFC8281" />, including both issues and solutions, apply to this document
      as well.</t>

    </section>

    <section>
      <name>Acknowledgement</name>

      <t>We would like to thank Adrian Farrel, Cyril Margaria, George Swallow,  Jan Medved,
      Sue Hares, and John Scudder for the useful comments and discussions. </t>

      <t>Thanks to Dhruv Dhody for Shepherding this document and providing useful comments.</t>

    </section>
  </middle>
  <back>

<displayreference target="I-D.ietf-pce-pcep-yang" to="PCE-PCEP-YANG"/>
<displayreference target="I-D.ietf-teas-yang-path-computation" to="YANG-PATH-COMPUTATION"/>

<references><name>References</name>
<references>
    <name>Nomative
    <name>Normative References</name>

      <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/> href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/>
      <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5440.xml"/> href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5440.xml"/>
            <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5521.xml"/> href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5511.xml"/>
      <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/> href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5521.xml"/>
      <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8231.xml"/> href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/>
      <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8253.xml"/> href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8231.xml"/>
      <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8281.xml"/> href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8253.xml"/>
      <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8779.xml"/> href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8281.xml"/>
      <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.9357.xml"/> href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8779.xml"/>
      <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9357.xml"/>
</references>
    <references>
      <name>Informative References</name>

      <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7942.xml"/>
      <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8051.xml"/> href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8051.xml"/>
      <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8232.xml"/> href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8232.xml"/>
      <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8282.xml"/> href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8282.xml"/>
      <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3471.xml"/> href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3471.xml"/>
      <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3473.xml"/> href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3473.xml"/>
      <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4655.xml"/> href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4655.xml"/>
      <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4657.xml"/> href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4657.xml"/>
      <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4872.xml"/> href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4872.xml"/>
      <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4873.xml"/> href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4873.xml"/>
      <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5511.xml"/> href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6123.xml"/>
      <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6123.xml"/> href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7025.xml"/>
      <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7025.xml"/> href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7399.xml"/>
      <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7399.xml"/> href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8126.xml"/>
      <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8126.xml"/> href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8623.xml"/>
      <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8623.xml"/>
      <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8745.xml"/>

      <xi:include href="https://datatracker.ietf.org/doc/bibxml3/draft-ietf-pce-pcep-yang.xml"/>
      <xi:include href="https://datatracker.ietf.org/doc/bibxml3/draft-ietf-teas-yang-path-computation.xml"/>
      <xi:include href="https://datatracker.ietf.org/doc/bibxml3/draft-ietf-pce-lsp-extended-flags.xml"/> href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8745.xml"/>

<!-- [I-D.ietf-pce-pcep-yang] IESG state I-D Exists. Updated to long version because missing editor role -->

<reference anchor="I-D.ietf-pce-pcep-yang" target="https://datatracker.ietf.org/doc/html/draft-ietf-pce-pcep-yang-22">
<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</organization>
</author>
<author initials="V. P." surname="Beeram" fullname="Vishnu Pavan Beeram">
<organization>Juniper Networks</organization>
</author>
<author initials="J." surname="Hardwick" fullname="Jonathan Hardwick">
<organization>Microsoft</organization>
</author>
<author initials="J." surname="Tantsura" fullname="Jeff Tantsura">
<organization>Nvidia</organization>
</author>
<date month="September" day="11" year="2023"/>
</front>
<seriesInfo name="Internet-Draft" value="draft-ietf-pce-pcep-yang-22"/>
</reference>

<!-- [I-D.ietf-teas-yang-path-computation] IESG state I-D Exists. Updated to long version because missing editor roles -->

<reference anchor="I-D.ietf-teas-yang-path-computation" target="https://datatracker.ietf.org/doc/html/draft-ietf-teas-yang-path-computation-21">
<front>
<title>A YANG Data Model for requesting path computation</title>
<author initials="I." surname="Busi" fullname="Italo Busi" role="editor">
<organization>Huawei Technologies</organization>
</author>
<author initials="S." surname="Belotti" fullname="Sergio Belotti" role="editor">
<organization>Nokia</organization>
</author>
<author initials="O. G." surname="de Dios" fullname="Oscar Gonzalez de Dios">
<organization>Telefonica</organization>
</author>
<author initials="A." surname="Sharma" fullname="Anurag Sharma">
<organization>Google</organization>
</author>
<author initials="Y." surname="Shi" fullname="Yan Shi">
<organization>China Unicom</organization>
</author>
<date month="July" day="7" year="2023"/>
</front>
<seriesInfo name="Internet-Draft" value="draft-ietf-teas-yang-path-computation-21"/>
</reference>
    </references>
  </references>

    <section title="Contributors' Address">

      <artwork>
        <![CDATA[
Xian Zhang
Huawei Technologies
Email: zhang.xian@huawei.com

Dhruv Dhody
Huawei Technology
India
Email: dhruv.ietf@gmail.com

Yi Lin
Huawei Technologies
Email: yi.lin@huawei.com

Fatai Zhang
Huawei Technologies
Email: zhangfatai@huawei.com

Ramon Casellas
CTTC
Av. Carl Friedrich Gauss n7
Castelldefels, Barcelona 08860
Spain
Email: ramon.casellas@cttc.es

Siva Sivabalan
Cisco Systems
Email: msiva@cisco.com

Clarence Filsfils
Cisco Systems
Email: cfilsfil@cisco.com

Robert Varga
Pantheon Technologies
Email: nite@hq.sk
        ]]>
      </artwork>

    </section>

    <section title="PCEP Messages">

      <t>This section uses the Routing Backus-Naur Form (RBNF) <xref target="RFC5511" /> to illustrate
      the PCEP messages. The RBNF in this section is reproduced for informative purposes. It is also
      expanded to show the GMPLS specific GMPLS-specific objects. </t>

      <section title="The PCRpt Message">

        <t>According to <xref target="RFC8231" />, the PCRpt Message message is used to report the current
        state of an LSP. This document extends the message in reporting the status of LSPs with GMPLS
        characteristics. </t>

        <t>The format of the PCRpt message is as follows:</t>

        <artwork>
          <![CDATA[

<sourcecode type="rbnf"><![CDATA[
<PCRpt Message> ::= <Common Header>
                    <state-report-list>
          ]]>
        </artwork>
]]></sourcecode>

        <t>Where:</t>

          <artwork>
            <![CDATA[

<sourcecode type="rbnf"><![CDATA[
<state-report-list> ::= <state-report>[<state-report-list>]
<state-report> ::= [<SRP>]
                   <LSP>
                   [<END-POINTS>]
                   <path>
          ]]>
        </artwork>
]]></sourcecode>

        <t>Where:</t>

        <artwork>
          <![CDATA[

<sourcecode type="rbnf"><![CDATA[
<path> ::= <intended-path>
           [<actual-attribute-list><actual-path>]
           <intended-attribute-list>
<actual-attribute-list> ::=[<BANDWIDTH>]
                           [<metric-list>]
          ]]>
        </artwork>
]]></sourcecode>

        <t>Where:</t>

        <ul>

          <li>The END-POINTS object MUST <bcp14>MUST</bcp14> be carried in a PCRpt message when the G flag is set in the
          LSP-EXTENDED-FLAG TLV in the LSP object for a GMPLS LSP.</li>

          <li>&lt;intended-path&gt; is represented by the ERO object defined
          in Section 7.9 of <xref target="RFC5440" />, sectionFormat="of" section="7.9"/> and
          augmented in <xref target="RFC8779" /> with explicit label
          control (ELC) and Path Keys.</li> ELC.</li>

          <li>&lt;actual-attribute-list&gt; consists of the actual computed and  signaled values of the
          &lt;BANDWIDTH&gt; and &lt;metric-lists&gt; objects defined in <xref target="RFC5440" />.</li>

          <li>&lt;actual-path&gt; is represented by the RRO object defined in Section 7.10 of
          <xref target="RFC5440" />.</li> sectionFormat="of" section="7.10"/>.</li>

          <li>&lt;intended-attribute-list&gt; is the attribute-list defined in Section 6.5 of
          <xref target="RFC5440" /> sectionFormat="of" section="6.5"/> and
          extended by many other documents that define PCEP extensions for
          specific scenarios as shown below:</li>

        </ul>

        <artwork>
          <![CDATA[

<sourcecode type='rbnf'><![CDATA[
<attribute-list> ::= [<of-list>]
                     [<LSPA>]
                     [<BANDWIDTH>]
                     [<metric-list>]
                     [<IRO>][<XRO>]
                     [<INTER-LAYER>]
                     [<SWITCH-LAYER>]
                     [<REQ-ADAP-CAP>]
                     [<SERVER-INDICATION>]
          ]]>
        </artwork>
]]></sourcecode>

      </section>

      <section title="The PCUpd Message">

        <t>The format of a PCUpd message is as follows:</t>

        <artwork>
          <![CDATA[

<sourcecode type='rbnf'><![CDATA[
<PCUpd Message> ::= <Common Header>
                    <update-request-list>
          ]]>
        </artwork>
]]></sourcecode>

        <t>Where:</t>

        <artwork>
          <![CDATA[

<sourcecode type='rbnf'><![CDATA[
<update-request-list> ::= <update-request>[<update-request-list>]
<update-request> ::= <SRP>
                     <LSP>
                     [<END-POINTS>]
                     <path>
          ]]>
        </artwork>
]]></sourcecode>

       <t>Where:</t>

        <artwork>
          <![CDATA[

<sourcecode type='rbnf'><![CDATA[
<path> ::= <intended-path><intended-attribute-list>
          ]]>
        </artwork>
]]></sourcecode>

        <t>Where:</t>

        <ul>

          <li>The END-POINTS object MUST <bcp14>MUST</bcp14> be carried in a PCUpd message for the GMPLS LSP.</li>

          <li>&lt;intended-path&gt; is represented by the ERO object defined
          in Section 7.9 of <xref target="RFC5440" />, sectionFormat="of" section="7.9"/>,
          augmented in <xref target="RFC8779" /> with explicit
          label control (ELC) and Path Keys.</li> ELC.</li>

          <li>&lt;intended-attribute-list&gt; is the attribute-list defined in <xref target="RFC5440" />
          and extended by many other documents that define PCEP extensions for specific scenarios
          and as shown for PCRpt above.</li>

        </ul>

      </section>

      <section title="The PCInitiate Message">

        <t>According to <xref target="RFC8281" />, the PCInitiate Message message is used allow LSP Initiation. This
        document extends the message in initiating LSPs with GMPLS characteristics.  The format of a PCInitiate
        message is as follows:</t>

        <artwork>
          <![CDATA[

<sourcecode type="rbnf"><![CDATA[
<PCInitiate Message> ::= <Common Header>
                         <PCE-initiated-lsp-list>
          ]]>
        </artwork>
]]></sourcecode>

        <t>Where:</t>

        <artwork>
          <![CDATA[

<sourcecode type="rbnf"><![CDATA[
<Common Header> is defined in <xref target="RFC5440" />.
<PCE-initiated-lsp-list> ::= <PCE-initiated-lsp-request>
                             [<PCE-initiated-lsp-list>]
<PCE-initiated-lsp-request> ::= (<PCE-initiated-lsp-instantiation>|
                                 <PCE-initiated-lsp-deletion>)
<PCE-initiated-lsp-instantiation> ::= <SRP>
                                      <LSP>
                                      [<END-POINTS>]
                                      <ERO>
                                      [<attribute-list>]
<PCE-initiated-lsp-deletion> ::= <SRP>
                                 <LSP>
          ]]>
        </artwork>
]]></sourcecode>

        <t>The format of the PCInitiate message is unchanged from Section 5.1 of <xref
        target="RFC8281" />. sectionFormat="of" section="5.1"/>. All fields are
        similar to the PCRpt and the PCUpd message. messages. </t>

      </section>

    </section>

        <section numbered="false">
      <name>Acknowledgements</name>

      <t>We would like to thank <contact fullname="Adrian Farrel"/>, <contact
      fullname="Cyril Margaria"/>, <contact fullname="George Swallow"/>,
      <contact fullname="Jan Medved"/>, <contact fullname="Sue Hares"/>, and
      <contact fullname="John Scudder"/> for the useful comments and
      discussions. </t>

      <t>Thanks to <contact fullname="Dhruv Dhody"/> for Shepherding this
      document and providing useful comments.</t>

    </section>

    <section title="Contributors" numbered="false">

      <contact fullname="Xian Zhang">
        <organization>Huawei Technologies</organization>
        <address>
          <email>zhang.xian@huawei.com</email>
        </address>
      </contact>

      <contact fullname="Dhruv Dhody">
        <organization>Huawei Technology</organization>
        <address>
          <postal>
            <country>India</country>
          </postal>
          <email>dhruv.ietf@gmail.com</email>
        </address>
      </contact>

      <contact fullname="Yi Lin">
        <organization>Huawei Technologies</organization>
        <address>
          <email>yi.lin@huawei.com</email>
        </address>
      </contact>

      <contact fullname="Fatai Zhang">
        <organization>Huawei Technologies</organization>
        <address>
          <email>zhangfatai@huawei.com</email>
        </address>
      </contact>

      <contact fullname="Ramon Casellas">
        <organization>CTTC</organization>
        <address>
          <postal>
            <street>Av. Carl Friedrich Gauss n7</street>
            <city>Barcelona</city>
            <region>Castelldefels</region><code>08860</code>
            <country>Spain</country>
          </postal>
          <email>ramon.casellas@cttc.es</email>
        </address>
      </contact>

      <contact fullname="Siva Sivabalan">
        <organization>Cisco Systems</organization>
        <address>
          <email>msiva@cisco.com</email>
        </address>
      </contact>

      <contact fullname="Clarence Filsfils">
        <organization>Cisco Systems</organization>
        <address>
          <email>cfilsfil@cisco.com</email>
        </address>
      </contact>

      <contact fullname="Robert Varga">
        <organization>Pantheon Technologies</organization>
        <address>
          <email>nite@hq.sk</email>
        </address>
      </contact>

    </section>

  </back>
</rfc>