<?xml version='1.0' encoding='utf-8'?>
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" version="3" category="std" docName="draft-ietf-pce-stateful-pce-optional-13" number="9753" consensus="true" ipr="trust200902" obsoletes="" submissionType="IETF" updates="8231" xml:lang="en" tocInclude="true" tocDepth="4" symRefs="true" sortRefs="true" prepTime="2025-04-21T12:23:15" indexInclude="true" scripts="Common,Latin">
  <link href="https://datatracker.ietf.org/doc/draft-ietf-pce-stateful-pce-optional-13" rel="prev"/>
  <link href="https://dx.doi.org/10.17487/rfc9753" rel="alternate"/>
  <link href="urn:issn:2070-1721" rel="alternate"/>
  <front>
    <title abbrev="Optional Processing of PCEP Objects">Extension for Stateful PCE to Allow Optional Processing of Path Computation Element Communication Protocol (PCEP) Objects</title>
    <seriesInfo name="RFC" value="9753" stream="IETF"/>
    <author fullname="Cheng Li" initials="C." surname="Li">
      <organization showOnFrontPage="true">Huawei Technologies</organization>
      <address>
        <postal>
          <street>Huawei Campus, No. 156 Beiqing Rd.</street>
          <city>Beijing</city>
          <code>100095</code>
          <country>China</country>
        </postal>
        <email>c.l@huawei.com</email>
      </address>
    </author>
    <author fullname="Haomian Zheng" initials="H." surname="Zheng">
      <organization showOnFrontPage="true">Huawei Technologies</organization>
      <address>
        <postal>
          <street>H1, Huawei Xiliu Beipo Village, Songshan Lake</street>
          <city>Dongguan</city>
          <region>Guangdong</region>
          <code>523808</code>
          <country>China</country>
        </postal>
        <email>zhenghaomian@huawei.com</email>
      </address>
    </author>
    <author fullname="Stephane Litkowski" initials="S" surname="Litkowski">
      <organization showOnFrontPage="true">Cisco</organization>
      <address>
        <email>slitkows.ietf@gmail.com</email>
      </address>
    </author>
    <date month="04" year="2025"/>
    <area>RTG</area>
    <workgroup>pce</workgroup>
    <keyword>PCEP</keyword>
    <keyword>Stateful</keyword>
    <keyword>optional processing</keyword>
    <abstract pn="section-abstract">
      <t indent="0" pn="section-abstract-1">This document introduces a mechanism to mark some of the Path
      Computation Element Communication Protocol (PCEP) objects as
      optional during PCEP message exchange, so the stateful Path Computation Element (PCE) model 
      can relax some constraints during path computation and setup. This
      document introduces this relaxation to stateful PCE, and it updates RFC
      8231.</t>
    </abstract>
    <boilerplate>
      <section anchor="status-of-memo" numbered="false" removeInRFC="false" toc="exclude" pn="section-boilerplate.1">
        <name slugifiedName="name-status-of-this-memo">Status of This Memo</name>
        <t indent="0" pn="section-boilerplate.1-1">
            This is an Internet Standards Track document.
        </t>
        <t indent="0" pn="section-boilerplate.1-2">
            This document is a product of the Internet Engineering Task Force
            (IETF).  It represents the consensus of the IETF community.  It has
            received public review and has been approved for publication by
            the Internet Engineering Steering Group (IESG).  Further
            information on Internet Standards is available in Section 2 of 
            RFC 7841.
        </t>
        <t indent="0" pn="section-boilerplate.1-3">
            Information about the current status of this document, any
            errata, and how to provide feedback on it may be obtained at
            <eref target="https://www.rfc-editor.org/info/rfc9753" brackets="none"/>.
        </t>
      </section>
      <section anchor="copyright" numbered="false" removeInRFC="false" toc="exclude" pn="section-boilerplate.2">
        <name slugifiedName="name-copyright-notice">Copyright Notice</name>
        <t indent="0" pn="section-boilerplate.2-1">
            Copyright (c) 2025 IETF Trust and the persons identified as the
            document authors. All rights reserved.
        </t>
        <t indent="0" pn="section-boilerplate.2-2">
            This document is subject to BCP 78 and the IETF Trust's Legal
            Provisions Relating to IETF Documents
            (<eref target="https://trustee.ietf.org/license-info" brackets="none"/>) in effect on the date of
            publication of this document. Please review these documents
            carefully, as they describe your rights and restrictions with
            respect to this document. Code Components extracted from this
            document must include Revised BSD License text as described in
            Section 4.e of the Trust Legal Provisions and are provided without
            warranty as described in the Revised BSD License.
        </t>
      </section>
    </boilerplate>
    <toc>
      <section anchor="toc" numbered="false" removeInRFC="false" toc="exclude" pn="section-toc.1">
        <name slugifiedName="name-table-of-contents">Table of Contents</name>
        <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1">
          <li pn="section-toc.1-1.1">
            <t indent="0" keepWithNext="true" pn="section-toc.1-1.1.1"><xref derivedContent="1" format="counter" sectionFormat="of" target="section-1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-introduction">Introduction</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.1.2">
              <li pn="section-toc.1-1.1.2.1">
                <t indent="0" keepWithNext="true" pn="section-toc.1-1.1.2.1.1"><xref derivedContent="1.1" format="counter" sectionFormat="of" target="section-1.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-requirements-language">Requirements Language</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.2">
            <t indent="0" pn="section-toc.1-1.2.1"><xref derivedContent="2" format="counter" sectionFormat="of" target="section-2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-overview">Overview</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.2.2">
              <li pn="section-toc.1-1.2.2.1">
                <t indent="0" keepWithNext="true" pn="section-toc.1-1.2.2.1.1"><xref derivedContent="2.1" format="counter" sectionFormat="of" target="section-2.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-usage-example">Usage Example</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.3">
            <t indent="0" pn="section-toc.1-1.3.1"><xref derivedContent="3" format="counter" sectionFormat="of" target="section-3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-pcep-extension">PCEP Extension</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.3.2">
              <li pn="section-toc.1-1.3.2.1">
                <t indent="0" pn="section-toc.1-1.3.2.1.1"><xref derivedContent="3.1" format="counter" sectionFormat="of" target="section-3.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-stateful-pce-capability-tlv">STATEFUL-PCE-CAPABILITY TLV</xref></t>
              </li>
              <li pn="section-toc.1-1.3.2.2">
                <t indent="0" pn="section-toc.1-1.3.2.2.1"><xref derivedContent="3.2" format="counter" sectionFormat="of" target="section-3.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-handling-of-the-p-flag">Handling of the P Flag</xref></t>
                <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.3.2.2.2">
                  <li pn="section-toc.1-1.3.2.2.2.1">
                    <t indent="0" pn="section-toc.1-1.3.2.2.2.1.1"><xref derivedContent="3.2.1" format="counter" sectionFormat="of" target="section-3.2.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-the-pcrpt-message">The PCRpt Message</xref></t>
                    <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.3.2.2.2.1.2">
                      <li pn="section-toc.1-1.3.2.2.2.1.2.1">
                        <t indent="0" pn="section-toc.1-1.3.2.2.2.1.2.1.1"><xref derivedContent="3.2.1.1" format="counter" sectionFormat="of" target="section-3.2.1.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-delegation">Delegation</xref></t>
                      </li>
                    </ul>
                  </li>
                  <li pn="section-toc.1-1.3.2.2.2.2">
                    <t indent="0" pn="section-toc.1-1.3.2.2.2.2.1"><xref derivedContent="3.2.2" format="counter" sectionFormat="of" target="section-3.2.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-the-pcupd-message-and-the-p">The PCUpd Message and the PCInitiate Message</xref></t>
                  </li>
                </ul>
              </li>
              <li pn="section-toc.1-1.3.2.3">
                <t indent="0" pn="section-toc.1-1.3.2.3.1"><xref derivedContent="3.3" format="counter" sectionFormat="of" target="section-3.3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-handling-of-the-i-flag">Handling of the I Flag</xref></t>
                <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.3.2.3.2">
                  <li pn="section-toc.1-1.3.2.3.2.1">
                    <t indent="0" pn="section-toc.1-1.3.2.3.2.1.1"><xref derivedContent="3.3.1" format="counter" sectionFormat="of" target="section-3.3.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-the-pcupd-message">The PCUpd Message</xref></t>
                  </li>
                  <li pn="section-toc.1-1.3.2.3.2.2">
                    <t indent="0" pn="section-toc.1-1.3.2.3.2.2.1"><xref derivedContent="3.3.2" format="counter" sectionFormat="of" target="section-3.3.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-the-pcrpt-message-2">The PCRpt Message</xref></t>
                  </li>
                  <li pn="section-toc.1-1.3.2.3.2.3">
                    <t indent="0" pn="section-toc.1-1.3.2.3.2.3.1"><xref derivedContent="3.3.3" format="counter" sectionFormat="of" target="section-3.3.3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-the-pcinitiate-message">The PCInitiate Message</xref></t>
                  </li>
                </ul>
              </li>
              <li pn="section-toc.1-1.3.2.4">
                <t indent="0" pn="section-toc.1-1.3.2.4.1"><xref derivedContent="3.4" format="counter" sectionFormat="of" target="section-3.4"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-unknown-object-handling">Unknown Object Handling</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.4">
            <t indent="0" pn="section-toc.1-1.4.1"><xref derivedContent="4" format="counter" sectionFormat="of" target="section-4"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-security-considerations">Security Considerations</xref></t>
          </li>
          <li pn="section-toc.1-1.5">
            <t indent="0" pn="section-toc.1-1.5.1"><xref derivedContent="5" format="counter" sectionFormat="of" target="section-5"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-iana-considerations">IANA Considerations</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.5.2">
              <li pn="section-toc.1-1.5.2.1">
                <t indent="0" pn="section-toc.1-1.5.2.1.1"><xref derivedContent="5.1" format="counter" sectionFormat="of" target="section-5.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-stateful-pce-capability-tlv-2">STATEFUL-PCE-CAPABILITY TLV</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.6">
            <t indent="0" pn="section-toc.1-1.6.1"><xref derivedContent="6" format="counter" sectionFormat="of" target="section-6"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-manageability-consideration">Manageability Considerations</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.6.2">
              <li pn="section-toc.1-1.6.2.1">
                <t indent="0" pn="section-toc.1-1.6.2.1.1"><xref derivedContent="6.1" format="counter" sectionFormat="of" target="section-6.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-control-of-function-and-pol">Control of Function and Policy</xref></t>
              </li>
              <li pn="section-toc.1-1.6.2.2">
                <t indent="0" pn="section-toc.1-1.6.2.2.1"><xref derivedContent="6.2" format="counter" sectionFormat="of" target="section-6.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-information-and-data-models">Information and Data Models</xref></t>
              </li>
              <li pn="section-toc.1-1.6.2.3">
                <t indent="0" pn="section-toc.1-1.6.2.3.1"><xref derivedContent="6.3" format="counter" sectionFormat="of" target="section-6.3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-liveness-detection-and-moni">Liveness Detection and Monitoring</xref></t>
              </li>
              <li pn="section-toc.1-1.6.2.4">
                <t indent="0" pn="section-toc.1-1.6.2.4.1"><xref derivedContent="6.4" format="counter" sectionFormat="of" target="section-6.4"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-verify-correct-operations">Verify Correct Operations</xref></t>
              </li>
              <li pn="section-toc.1-1.6.2.5">
                <t indent="0" pn="section-toc.1-1.6.2.5.1"><xref derivedContent="6.5" format="counter" sectionFormat="of" target="section-6.5"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-requirements-on-other-proto">Requirements on Other Protocols</xref></t>
              </li>
              <li pn="section-toc.1-1.6.2.6">
                <t indent="0" pn="section-toc.1-1.6.2.6.1"><xref derivedContent="6.6" format="counter" sectionFormat="of" target="section-6.6"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-impact-on-network-operation">Impact on Network Operations</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.7">
            <t indent="0" pn="section-toc.1-1.7.1"><xref derivedContent="7" format="counter" sectionFormat="of" target="section-7"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-references">References</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.7.2">
              <li pn="section-toc.1-1.7.2.1">
                <t indent="0" pn="section-toc.1-1.7.2.1.1"><xref derivedContent="7.1" format="counter" sectionFormat="of" target="section-7.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-normative-references">Normative References</xref></t>
              </li>
              <li pn="section-toc.1-1.7.2.2">
                <t indent="0" pn="section-toc.1-1.7.2.2.1"><xref derivedContent="7.2" format="counter" sectionFormat="of" target="section-7.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-informative-references">Informative References</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.8">
            <t indent="0" pn="section-toc.1-1.8.1"><xref derivedContent="" format="none" sectionFormat="of" target="section-appendix.a"/><xref derivedContent="" format="title" sectionFormat="of" target="name-acknowledgments">Acknowledgments</xref></t>
          </li>
          <li pn="section-toc.1-1.9">
            <t indent="0" pn="section-toc.1-1.9.1"><xref derivedContent="" format="none" sectionFormat="of" target="section-appendix.b"/><xref derivedContent="" format="title" sectionFormat="of" target="name-contributors">Contributors</xref></t>
          </li>
          <li pn="section-toc.1-1.10">
            <t indent="0" pn="section-toc.1-1.10.1"><xref derivedContent="" format="none" sectionFormat="of" target="section-appendix.c"/><xref derivedContent="" format="title" sectionFormat="of" target="name-authors-addresses">Authors' Addresses</xref></t>
          </li>
        </ul>
      </section>
    </toc>
  </front>
  <middle>
    <section toc="include" numbered="true" removeInRFC="false" pn="section-1">
      <name slugifiedName="name-introduction">Introduction</name>
      <t indent="0" pn="section-1-1"><xref target="RFC5440" format="default" sectionFormat="of" derivedContent="RFC5440"/> describes the Path Computation Element
      Communication Protocol (PCEP), which enables communication between a Path
      Computation Client (PCC) and a Path Control Element (PCE), or between
      two PCEs based on the PCE architecture <xref target="RFC4655" format="default" sectionFormat="of" derivedContent="RFC4655"/>.</t>
      <t indent="0" pn="section-1-2">PCEP extensions for the stateful PCE model <xref target="RFC8231" format="default" sectionFormat="of" derivedContent="RFC8231"/>
      describes a set of extensions to PCEP to enable active control of
      Multiprotocol Label Switching Traffic Engineering (MPLS-TE) and
      Generalized MPLS (GMPLS) tunnels. <xref target="RFC8281" format="default" sectionFormat="of" derivedContent="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, thus
      allowing for dynamic control.</t>
      <t indent="0" pn="section-1-3"><xref target="RFC5440" format="default" sectionFormat="of" derivedContent="RFC5440"/> defined the P flag (Processing-Rule) in the
      Common Object Header to allow a PCC to specify in a Path Computation
      Request (PCReq) message (sent to a PCE) whether the object must be taken
      into account by the PCE during path computation or is optional. The I
      flag (Ignore) is used by the PCE in a Path Computation Reply (PCRep)
      message to indicate to a PCC whether or not an optional object was
      considered by the PCE during path computation. Stateful PCE <xref target="RFC8231" format="default" sectionFormat="of" derivedContent="RFC8231"/> specifies that the P and I flags of the PCEP objects
      are to be set to zero on transmission
      and ignored on receipt, since they are exclusively related to the path
      computation requests. This document defines a new flag, the R (RELAX)
      flag in STATEFUL-PCE-CAPABILITY TLV, in the PCEP common object header to
      indicate a PCE speaker supporting P and I flags processing, and it also
      specifies how the P and I flags could be used in the stateful PCE model
      to identify optional objects in the Path Computation State Report
      (PCRpt) <xref target="RFC8231" format="default" sectionFormat="of" derivedContent="RFC8231"/>, the Path Computation Update Request
      (PCUpd) <xref target="RFC8231" format="default" sectionFormat="of" derivedContent="RFC8231"/>, and the LSP Initiate Request
      (PCInitiate) <xref target="RFC8281" format="default" sectionFormat="of" derivedContent="RFC8281"/> messages.</t>
      <t indent="0" pn="section-1-4">This document updates <xref target="RFC8231" format="default" sectionFormat="of" derivedContent="RFC8231"/> concerning usage of
      the P and I flags as well as the handling of unknown objects in
      stateful PCEP message exchange.</t>
      <section toc="include" numbered="true" removeInRFC="false" pn="section-1.1">
        <name slugifiedName="name-requirements-language">Requirements Language</name>
        <t indent="0" pn="section-1.1-1">
    The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
    "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>",
    "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>",
    "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
    "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to be
    interpreted as described in BCP 14 <xref target="RFC2119" format="default" sectionFormat="of" derivedContent="RFC2119"/> <xref target="RFC8174" format="default" sectionFormat="of" derivedContent="RFC8174"/> when, and only when, they appear in all capitals, as
    shown here.
        </t>
      </section>
    </section>
    <section toc="include" numbered="true" removeInRFC="false" pn="section-2">
      <name slugifiedName="name-overview">Overview</name>
      <t indent="0" pn="section-2-1">Setting the P flag in the PCReq message to handle unknown objects 
  is as described in <xref target="RFC5440" section="7.2" sectionFormat="of" format="default" derivedLink="https://rfc-editor.org/rfc/rfc5440#section-7.2" derivedContent="RFC5440"/>.
Further, <xref target="RFC8231" format="default" sectionFormat="of" derivedContent="RFC8231"/> defined the usage of the LSP Error Code TLV in the
      PCRpt message in response to a failed LSP Update Request via the PCUpd
      message (for example, due to an unsupported object or TLV).</t>
      <t indent="0" pn="section-2-2">This document specifies the procedure of marking some objects as
      'optional to be processed' by the PCEP peer in the stateful PCEP
      messages. Furthermore, this document updates the procedure for handling
      unknown objects in stateful PCEP messages based on the P flag.</t>
      <section toc="include" numbered="true" removeInRFC="false" pn="section-2.1">
        <name slugifiedName="name-usage-example">Usage Example</name>
        <t indent="0" pn="section-2.1-1">The PCRpt message is used to report the current state of an LSP. As
        part of the message, both the &lt;intended-attribute-list&gt; and
        &lt;actual-attribute-list&gt; are encoded (see <xref target="RFC8231" format="default" sectionFormat="of" derivedContent="RFC8231"/>). For example, the &lt;intended-attribute-list&gt;
        could include the METRIC object to indicate a limiting constraint
        (Bound 'B' flag set) for the Path Delay Variation metric <xref target="RFC8233" format="default" sectionFormat="of" derivedContent="RFC8233"/>. 
In some scenarios, it would be useful to indicate
        that this constraint can be relaxed by the PCE in case it
        cannot find a path.  
In these cases, it would be useful to mark
  the objects as 'optional' so they could be ignored by the PCEP peer.
Also, it would be useful for the PCEP speaker to learn
        if the PCEP peer has relaxed the constraint and ignored the processing
        of the PCEP object.</t>
        <t indent="0" pn="section-2.1-2">Thus, this document specifies how the already existing P and I
        flags in the PCEP common object header could be used during the
        stateful PCEP message exchange. 
 The scope of how P and I flags are applied is defined in <xref target="RFC5440" format="default" sectionFormat="of" derivedContent="RFC5440"/> and is unchanged by this document. Therefore, these flags can only be applied to an entire PCEP
 object; they cannot be applied at the granularity of optional TLVs encoded in the PCEP object.
</t>
      </section>
    </section>
    <section toc="include" numbered="true" removeInRFC="false" pn="section-3">
      <name slugifiedName="name-pcep-extension">PCEP Extension</name>
      <section toc="include" numbered="true" removeInRFC="false" pn="section-3.1">
        <name slugifiedName="name-stateful-pce-capability-tlv">STATEFUL-PCE-CAPABILITY TLV</name>
        <t indent="0" pn="section-3.1-1">A PCEP speaker indicates its ability to support the handling of the
        P and I flags in the stateful PCEP message exchange during the PCEP
        initialization phase, as follows. During the PCEP initialization
        phase, a PCC sends an Open message with an OPEN object that contains
        the STATEFUL-PCE-CAPABILITY TLV, as defined in <xref target="RFC8231" format="default" sectionFormat="of" derivedContent="RFC8231"/>. A new flag, the R (RELAX) flag, is added to this
        TLV to indicate support for relaxing the processing of some
        objects via the use of the P and I flags in the PCEP common object
        header.</t>
        <t indent="0" pn="section-3.1-2">R (RELAX bit - 17): If set to 1 by a PCEP Speaker, the R flag
        indicates that the PCEP Speaker is willing to handle the P and I flags
        in the PCEP common object header for the PCEP objects in the stateful
        PCEP messages. If the bit is unset, it indicates that the PCEP Speaker
        will not handle the P and I flags in the PCEP common object header
        for stateful PCE messages.</t>
        <t indent="0" pn="section-3.1-3">The R flag <bcp14>MUST</bcp14> be set by both the PCC and PCE to indicate support for
        handling the P and I flags in the PCEP common object header to
        allow relaxing some constraints by marking objects as 'optional to
        process'. If the PCEP speaker does not set the R flag but receives PCEP
        objects with the P or I bits set, it <bcp14>MUST</bcp14> ignore the flags. <xref target="RFC8231" format="default" sectionFormat="of" derivedContent="RFC8231"/> states that P and I flags of the PCEP objects
        are set to 0 on transmission and
        ignored on receipt. It fails to mention the behaviour of objects
        defined outside of <xref target="RFC8231" format="default" sectionFormat="of" derivedContent="RFC8231"/>, leading to ambiguity.</t>
      </section>
      <section toc="include" numbered="true" removeInRFC="false" pn="section-3.2">
        <name slugifiedName="name-handling-of-the-p-flag">Handling of the P Flag</name>
        <section toc="include" numbered="true" removeInRFC="false" pn="section-3.2.1">
          <name slugifiedName="name-the-pcrpt-message">The PCRpt Message</name>
          <t indent="0" pn="section-3.2.1-1">The P flag in the PCRpt message <xref target="RFC8231" format="default" sectionFormat="of" derivedContent="RFC8231"/> allows a
          PCC to specify to a PCE whether the object must be taken into
          account by the PCE (during state maintenance, path computation, or
          re-optimisation) or is optional to process. When the P flag is set
          in the PCRpt message received on a PCEP session on which the R bit
          is set by both peers, the object <bcp14>MUST</bcp14> be taken into account by the
          PCE. Conversely, when the P flag is cleared, the object is optional
          and the PCE can ignore it. The P flag for the mandatory
          objects, such as the LSP and the ERO (Explicit Route Object) object
          (intended path), <bcp14>MUST</bcp14> be set in the PCRpt message. If a mandatory
          object is received with the P flag set incorrectly according to the
          rules stated above, the receiving peer <bcp14>MUST</bcp14> send a PCErr message
          with Error-Type=10 (Reception of an invalid object) and
          Error-value=1 (Reception of an object with P flag not set). On a
          PCEP session on which the R bit was set by both peers, the PCC
          <bcp14>SHOULD</bcp14> set the P flag by default, unless a local configuration or
          local policy indicates that some constraints (corresponding PCEP
          objects) can be marked as optional and could be ignored by the PCE
          or the object itself conveys informational parameters that can be
          safely ignored.</t>
          <section toc="include" numbered="true" removeInRFC="false" pn="section-3.2.1.1">
            <name slugifiedName="name-delegation">Delegation</name>
            <t indent="0" pn="section-3.2.1.1-1">Delegation is an operation to grant a PCE temporary rights to
            modify a subset of parameters on one or more LSPs by a PCC as
            described in <xref target="RFC8051" format="default" sectionFormat="of" derivedContent="RFC8051"/>. Note that for the delegated
            LSPs, the PCE can update and mark some objects as ignored even
            when the PCC has set the P flag during the delegation. Similarly,
            the PCE can update and mark some objects as a 'must to process'
            even when the PCC has not set the P flag during delegation.</t>
            <t indent="0" pn="section-3.2.1.1-2">The PCC <bcp14>MUST</bcp14> acknowledge this by sending the PCRpt message with
            the P flag set as per the PCE expectation for the corresponding
            object. If the PCC cannot accept the update message, it <bcp14>MUST</bcp14> react as
            per the processing rules of unacceptable update in <xref section="5.8.3" target="RFC8231" format="default" sectionFormat="of" derivedLink="https://rfc-editor.org/rfc/rfc8231#section-5.8.3" derivedContent="RFC8231"/>.</t>
          </section>
        </section>
        <section toc="include" numbered="true" removeInRFC="false" pn="section-3.2.2">
          <name slugifiedName="name-the-pcupd-message-and-the-p">The PCUpd Message and the PCInitiate Message</name>
          <t indent="0" pn="section-3.2.2-1">The P flag in the PCUpd message <xref target="RFC8231" format="default" sectionFormat="of" derivedContent="RFC8231"/> and the
          PCInitiate message <xref target="RFC8281" format="default" sectionFormat="of" derivedContent="RFC8281"/> allows a PCE to specify
          to a PCC whether the object must be taken into account by the PCC
          (during path setup) or is optional to process. When the P flag is
          set in the PCUpd/PCInitiate message received on a PCEP session on
          which the R bit was set by both peers, the object <bcp14>MUST</bcp14> be taken into
          account by the PCC. Conversely, when the P flag is cleared, the
          object is optional and the PCC can ignore it. The P flag for
          the mandatory objects -- such as the SRP (Stateful PCE Request
          Parameters), the LSP, and the ERO -- <bcp14>MUST</bcp14> be set in the
          PCUpd/PCInitiate message. If a mandatory object is received with the
          P flag set incorrectly according to the rules stated above, the
          receiving peer <bcp14>MUST</bcp14> send a PCErr message with Error-Type=10
          (Reception of an invalid object) and Error-value=1 (Reception of an
          object with P flag not set). On a PCEP session in which both peers set the R
          bit, the PCE <bcp14>SHOULD</bcp14> set the P flag by default unless a local
          configuration/policy indicates that some constraints (corresponding
          PCEP objects) can be marked as optional and can be ignored by the
          PCC or the object itself conveys informational parameters that can
          be safely ignored.</t>
        </section>
      </section>
      <section toc="include" numbered="true" removeInRFC="false" pn="section-3.3">
        <name slugifiedName="name-handling-of-the-i-flag">Handling of the I Flag</name>
        <section toc="include" numbered="true" removeInRFC="false" pn="section-3.3.1">
          <name slugifiedName="name-the-pcupd-message">The PCUpd Message</name>
          <t indent="0" pn="section-3.3.1-1">The I flag in the PCUpd message <xref target="RFC8231" format="default" sectionFormat="of" derivedContent="RFC8231"/> allows a
          PCE to indicate to a PCC whether or not an optional object was
          processed. The PCE <bcp14>MAY</bcp14> include the ignored optional object in its
          update request and set the I flag to indicate that the optional
          object was ignored. When the I flag is cleared, the PCE indicates
          that the optional object was processed.</t>
          <t indent="0" pn="section-3.3.1-2">Note that when a PCE is unable to find the path that meets all
          the constraints as per the PCEP object that cannot be ignored (i.e.
          the P flag is set), the PCUpd message <bcp14>MAY</bcp14> optionally include the
          PCEP objects that caused the path computation to fail along with the
          empty ERO.</t>
        </section>
        <section toc="include" numbered="true" removeInRFC="false" pn="section-3.3.2">
          <name slugifiedName="name-the-pcrpt-message-2">The PCRpt Message</name>
          <t indent="0" pn="section-3.3.2-1">The I flag in the PCRpt message <xref target="RFC8231" format="default" sectionFormat="of" derivedContent="RFC8231"/> allows a
          PCC to indicate to a PCE whether or not an optional object was
          processed in response to a PCUpd or PCInitiate message.
          The PCC <bcp14>MAY</bcp14> include the ignored
          optional object in its report and set the I flag to indicate that
          the optional object was ignored at PCC. When the I flag is cleared,
          the PCC indicates that the optional object was processed. The I flag
          has no meaning if the PCRpt message is not in response to a PCUpd or
          PCInitiate message (i.e., without the SRP object in the PCRpt
          message).</t>
          <t indent="0" pn="section-3.3.2-2">Note that when a PCC is unable to set up a path that meets all
          the parameters as per the PCEP object that cannot be ignored (i.e.,
          the P flag is set), the PCRpt message <bcp14>MAY</bcp14> optionally include the
          PCEP objects that caused the path setup to fail along with the
          LSP-ERROR-CODE TLV <xref target="RFC8231" format="default" sectionFormat="of" derivedContent="RFC8231"/> indicating the reason
          for the failure.</t>
        </section>
        <section toc="include" numbered="true" removeInRFC="false" pn="section-3.3.3">
          <name slugifiedName="name-the-pcinitiate-message">The PCInitiate Message</name>
          <t indent="0" pn="section-3.3.3-1">The I flag has no meaning in the PCInitiate message <xref target="RFC8281" format="default" sectionFormat="of" derivedContent="RFC8281"/>, so the I flag <bcp14>MUST</bcp14> set to 0 on transmission and
          ignored on receipt.</t>
        </section>
      </section>
      <section toc="include" numbered="true" removeInRFC="false" pn="section-3.4">
        <name slugifiedName="name-unknown-object-handling">Unknown Object Handling</name>
        <t indent="0" pn="section-3.4-1">
   This document updates the handling of unknown objects in the stateful
   PCEP messages by setting the P flag in the common object
   header in a similar way as described in <xref target="RFC5440" format="default" sectionFormat="of" derivedContent="RFC5440"/>.  That is, if a 
   PCEP speaker does not understand an object with the P flag set, or 
   if the PCEP speaker understands the object
   but decides to ignore the object, the entire stateful PCEP message
   <bcp14>MUST</bcp14> be rejected, and the PCE <bcp14>MUST</bcp14> send a PCErr message with Error-
   Type="Unknown Object" or "Not supported object" <xref target="RFC5440" format="default" sectionFormat="of" derivedContent="RFC5440"/>.
If the P flag is not set, the PCEP
        speaker can ignore the object and continue with the message
        processing as defined.</t>
        <t indent="0" pn="section-3.4-2"><xref target="RFC8231" format="default" sectionFormat="of" derivedContent="RFC8231"/> defined the LSP Error Code TLV to be carried
        in the PCRpt message in the LSP object to convey error information. This
        document does not change that procedure.</t>
      </section>
    </section>
    <section toc="include" numbered="true" removeInRFC="false" pn="section-4">
      <name slugifiedName="name-security-considerations">Security Considerations</name>
      <t indent="0" pn="section-4-1">This document specifies how the already existing P and I flags in the
      PCEP common object header could be used during stateful PCEP exchanges.
      It updates the unknown object error handling in stateful PCEP message
      exchange. On their own, these changes do not add any new security
      concerns. The security considerations identified in <xref target="RFC5440" format="default" sectionFormat="of" derivedContent="RFC5440"/>, <xref target="RFC8231" format="default" sectionFormat="of" derivedContent="RFC8231"/>, and <xref target="RFC8281" format="default" sectionFormat="of" derivedContent="RFC8281"/> continue to apply.</t>
      <t indent="0" pn="section-4-2">As per <xref target="RFC8231" format="default" sectionFormat="of" derivedContent="RFC8231"/>, it is <bcp14>RECOMMENDED</bcp14> that these PCEP
      extensions can only be activated on authenticated and encrypted sessions
      across PCEs and PCCs belonging to the same administrative authority,
      using Transport Layer Security (TLS) <xref target="RFC8253" format="default" sectionFormat="of" derivedContent="RFC8253"/> as per the
      recommendations and best current practices described in <xref target="RFC9325" format="default" sectionFormat="of" derivedContent="RFC9325"/>.</t>
    </section>
    <section toc="include" numbered="true" removeInRFC="false" pn="section-5">
      <name slugifiedName="name-iana-considerations">IANA Considerations</name>
      <section toc="include" numbered="true" removeInRFC="false" pn="section-5.1">
        <name slugifiedName="name-stateful-pce-capability-tlv-2">STATEFUL-PCE-CAPABILITY TLV</name>
        <t indent="0" pn="section-5.1-1"><xref target="RFC8231" format="default" sectionFormat="of" derivedContent="RFC8231"/> defined the STATEFUL-PCE-CAPABILITY TLV
        and IANA created the "STATEFUL-PCE-CAPABILITY TLV Flag Field"
        registry to manage the value of the STATEFUL-PCE-CAPABILITY TLV's
        Flag field. IANA has allocated a new bit in the
        registry, as follows:</t>
        <table align="center" pn="table-1">
          <thead>
            <tr>
              <th align="left" colspan="1" rowspan="1">Bit</th>
              <th align="left" colspan="1" rowspan="1">Description</th>
              <th align="left" colspan="1" rowspan="1">Reference</th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td align="left" colspan="1" rowspan="1">17</td>
              <td align="left" colspan="1" rowspan="1">RELAX</td>
              <td align="left" colspan="1" rowspan="1">RFC 9753</td>
            </tr>
          </tbody>
        </table>
      </section>
    </section>
    <section toc="include" numbered="true" removeInRFC="false" pn="section-6">
      <name slugifiedName="name-manageability-consideration">Manageability Considerations</name>
      <section toc="include" numbered="true" removeInRFC="false" pn="section-6.1">
        <name slugifiedName="name-control-of-function-and-pol">Control of Function and Policy</name>
        <t indent="0" pn="section-6.1-1">An implementation supporting this document <bcp14>SHOULD</bcp14> allow
        configuration of the capability to support relaxation of constraints
        in the stateful PCEP message exchange. They <bcp14>SHOULD</bcp14> also allow
        configuration of related LSP constraints (or parameters) that are
        optional to process.</t>
      </section>
      <section toc="include" numbered="true" removeInRFC="false" pn="section-6.2">
        <name slugifiedName="name-information-and-data-models">Information and Data Models</name>
        <t indent="0" pn="section-6.2-1">An implementation supporting this document <bcp14>SHOULD</bcp14> allow the
        operator to view the capability defined in this document. To serve
        this purpose, the PCEP YANG module <xref target="PCEP-YANG" format="default" sectionFormat="of" derivedContent="PCEP-YANG"/> could be extended in the future.</t>
      </section>
      <section toc="include" numbered="true" removeInRFC="false" pn="section-6.3">
        <name slugifiedName="name-liveness-detection-and-moni">Liveness Detection and Monitoring</name>
        <t indent="0" pn="section-6.3-1">Mechanisms defined in this document do not imply any new liveness
        detection and monitoring requirements in addition to those already
        listed in <xref target="RFC5440" format="default" sectionFormat="of" derivedContent="RFC5440"/>.</t>
      </section>
      <section toc="include" numbered="true" removeInRFC="false" pn="section-6.4">
        <name slugifiedName="name-verify-correct-operations">Verify Correct Operations</name>
        <t indent="0" pn="section-6.4-1">Mechanisms defined in this document do not imply any new operation
        verification requirements in addition to those already listed in <xref target="RFC5440" format="default" sectionFormat="of" derivedContent="RFC5440"/>.</t>
      </section>
      <section toc="include" numbered="true" removeInRFC="false" pn="section-6.5">
        <name slugifiedName="name-requirements-on-other-proto">Requirements on Other Protocols</name>
        <t indent="0" pn="section-6.5-1">Mechanisms defined in this document do not imply any new
        requirements on other protocols.</t>
      </section>
      <section toc="include" numbered="true" removeInRFC="false" pn="section-6.6">
        <name slugifiedName="name-impact-on-network-operation">Impact on Network Operations</name>
        <t indent="0" pn="section-6.6-1">Mechanisms defined in this document do not have any impact on
        network operations in addition to those already listed in <xref target="RFC5440" format="default" sectionFormat="of" derivedContent="RFC5440"/>.</t>
      </section>
    </section>
  </middle>
  <back>
    <references pn="section-7">
      <name slugifiedName="name-references">References</name>
      <references pn="section-7.1">
        <name slugifiedName="name-normative-references">Normative References</name>
        <reference anchor="RFC2119" target="https://www.rfc-editor.org/info/rfc2119" quoteTitle="true" derivedAnchor="RFC2119">
          <front>
            <title>Key words for use in RFCs to Indicate Requirement Levels</title>
            <author fullname="S. Bradner" initials="S." surname="Bradner"/>
            <date month="March" year="1997"/>
            <abstract>
              <t indent="0">In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="14"/>
          <seriesInfo name="RFC" value="2119"/>
          <seriesInfo name="DOI" value="10.17487/RFC2119"/>
        </reference>
        <reference anchor="RFC5440" target="https://www.rfc-editor.org/info/rfc5440" quoteTitle="true" derivedAnchor="RFC5440">
          <front>
            <title>Path Computation Element (PCE) Communication Protocol (PCEP)</title>
            <author fullname="JP. Vasseur" initials="JP." role="editor" surname="Vasseur"/>
            <author fullname="JL. Le Roux" initials="JL." role="editor" surname="Le Roux"/>
            <date month="March" year="2009"/>
            <abstract>
              <t indent="0">This document specifies the Path Computation Element (PCE) Communication Protocol (PCEP) for communications between a Path Computation Client (PCC) and a PCE, or between two PCEs. Such interactions include path computation requests and path computation replies as well as notifications of specific states related to the use of a PCE in the context of Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Traffic Engineering. PCEP is designed to be flexible and extensible so as to easily allow for the addition of further messages and objects, should further requirements be expressed in the future. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="5440"/>
          <seriesInfo name="DOI" value="10.17487/RFC5440"/>
        </reference>
        <reference anchor="RFC8174" target="https://www.rfc-editor.org/info/rfc8174" quoteTitle="true" derivedAnchor="RFC8174">
          <front>
            <title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title>
            <author fullname="B. Leiba" initials="B." surname="Leiba"/>
            <date month="May" year="2017"/>
            <abstract>
              <t indent="0">RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="14"/>
          <seriesInfo name="RFC" value="8174"/>
          <seriesInfo name="DOI" value="10.17487/RFC8174"/>
        </reference>
        <reference anchor="RFC8231" target="https://www.rfc-editor.org/info/rfc8231" quoteTitle="true" derivedAnchor="RFC8231">
          <front>
            <title>Path Computation Element Communication Protocol (PCEP) Extensions for Stateful PCE</title>
            <author fullname="E. Crabbe" initials="E." surname="Crabbe"/>
            <author fullname="I. Minei" initials="I." surname="Minei"/>
            <author fullname="J. Medved" initials="J." surname="Medved"/>
            <author fullname="R. Varga" initials="R." surname="Varga"/>
            <date month="September" year="2017"/>
            <abstract>
              <t indent="0">The Path Computation Element Communication Protocol (PCEP) provides mechanisms for Path Computation Elements (PCEs) to perform path computations in response to Path Computation Client (PCC) requests.</t>
              <t indent="0">Although PCEP explicitly makes no assumptions regarding the information available to the PCE, it also makes no provisions for PCE control of timing and sequence of path computations within and across PCEP sessions. This document describes a set of extensions to PCEP to enable stateful control of MPLS-TE and GMPLS Label Switched Paths (LSPs) via PCEP.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8231"/>
          <seriesInfo name="DOI" value="10.17487/RFC8231"/>
        </reference>
        <reference anchor="RFC8253" target="https://www.rfc-editor.org/info/rfc8253" quoteTitle="true" derivedAnchor="RFC8253">
          <front>
            <title>PCEPS: Usage of TLS to Provide a Secure Transport for the Path Computation Element Communication Protocol (PCEP)</title>
            <author fullname="D. Lopez" initials="D." surname="Lopez"/>
            <author fullname="O. Gonzalez de Dios" initials="O." surname="Gonzalez de Dios"/>
            <author fullname="Q. Wu" initials="Q." surname="Wu"/>
            <author fullname="D. Dhody" initials="D." surname="Dhody"/>
            <date month="October" year="2017"/>
            <abstract>
              <t indent="0">The Path Computation Element Communication Protocol (PCEP) defines the mechanisms for the communication between a Path Computation Client (PCC) and a Path Computation Element (PCE), or among PCEs. This document describes PCEPS -- the usage of Transport Layer Security (TLS) to provide a secure transport for PCEP. The additional security mechanisms are provided by the transport protocol supporting PCEP; therefore, they do not affect the flexibility and extensibility of PCEP.</t>
              <t indent="0">This document updates RFC 5440 in regards to the PCEP initialization phase procedures.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8253"/>
          <seriesInfo name="DOI" value="10.17487/RFC8253"/>
        </reference>
        <reference anchor="RFC8281" target="https://www.rfc-editor.org/info/rfc8281" quoteTitle="true" derivedAnchor="RFC8281">
          <front>
            <title>Path Computation Element Communication Protocol (PCEP) Extensions for PCE-Initiated LSP Setup in a Stateful PCE Model</title>
            <author fullname="E. Crabbe" initials="E." surname="Crabbe"/>
            <author fullname="I. Minei" initials="I." surname="Minei"/>
            <author fullname="S. Sivabalan" initials="S." surname="Sivabalan"/>
            <author fullname="R. Varga" initials="R." surname="Varga"/>
            <date month="December" year="2017"/>
            <abstract>
              <t indent="0">The Path Computation Element Communication Protocol (PCEP) provides mechanisms for Path Computation Elements (PCEs) to perform path computations in response to Path Computation Client (PCC) requests.</t>
              <t indent="0">The extensions for stateful PCE provide active control of Multiprotocol Label Switching (MPLS) Traffic Engineering Label Switched Paths (TE LSPs) via PCEP, for a model where the PCC delegates control over one or more locally configured LSPs to the PCE. This document describes the creation and deletion of PCE-initiated LSPs under the stateful PCE model.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8281"/>
          <seriesInfo name="DOI" value="10.17487/RFC8281"/>
        </reference>
      </references>
      <references pn="section-7.2">
        <name slugifiedName="name-informative-references">Informative References</name>
        <reference anchor="PCEP-YANG" target="https://datatracker.ietf.org/doc/html/draft-ietf-pce-pcep-yang-30" quoteTitle="true" derivedAnchor="PCEP-YANG">
          <front>
            <title>A YANG Data Model for Path Computation Element Communications Protocol (PCEP)</title>
            <author initials="D." surname="Dhody" fullname="Dhruv Dhody" role="editor">
              <organization showOnFrontPage="true">Huawei</organization>
            </author>
            <author initials="V. P." surname="Beeram" fullname="Vishnu Pavan Beeram">
              <organization showOnFrontPage="true">Juniper Networks</organization>
            </author>
            <author initials="J." surname="Hardwick" fullname="Jonathan Hardwick">
         </author>
            <author initials="J." surname="Tantsura" fullname="Jeff Tantsura">
              <organization showOnFrontPage="true">Nvidia</organization>
            </author>
            <date month="January" day="26" year="2025"/>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-ietf-pce-pcep-yang-30"/>
          <refcontent>Work in Progress</refcontent>
        </reference>
        <reference anchor="RFC4655" target="https://www.rfc-editor.org/info/rfc4655" quoteTitle="true" derivedAnchor="RFC4655">
          <front>
            <title>A Path Computation Element (PCE)-Based Architecture</title>
            <author fullname="A. Farrel" initials="A." surname="Farrel"/>
            <author fullname="J.-P. Vasseur" initials="J.-P." surname="Vasseur"/>
            <author fullname="J. Ash" initials="J." surname="Ash"/>
            <date month="August" year="2006"/>
            <abstract>
              <t indent="0">Constraint-based path computation is a fundamental building block for traffic engineering systems such as Multiprotocol Label Switching (MPLS) and Generalized Multiprotocol Label Switching (GMPLS) networks. Path computation in large, multi-domain, multi-region, or multi-layer networks is complex and may require special computational components and cooperation between the different network domains.</t>
              <t indent="0">This document specifies the architecture for a Path Computation Element (PCE)-based model to address this problem space. This document does not attempt to provide a detailed description of all the architectural components, but rather it describes a set of building blocks for the PCE architecture from which solutions may be constructed. This memo provides information for the Internet community.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="4655"/>
          <seriesInfo name="DOI" value="10.17487/RFC4655"/>
        </reference>
        <reference anchor="RFC8051" target="https://www.rfc-editor.org/info/rfc8051" quoteTitle="true" derivedAnchor="RFC8051">
          <front>
            <title>Applicability of a Stateful Path Computation Element (PCE)</title>
            <author fullname="X. Zhang" initials="X." role="editor" surname="Zhang"/>
            <author fullname="I. Minei" initials="I." role="editor" surname="Minei"/>
            <date month="January" year="2017"/>
            <abstract>
              <t indent="0">A stateful Path Computation Element (PCE) maintains information about Label Switched Path (LSP) characteristics and resource usage within a network in order to provide traffic-engineering calculations for its associated Path Computation Clients (PCCs). This document describes general considerations for a stateful PCE deployment and examines its applicability and benefits, as well as its challenges and limitations, through a number of use cases. PCE Communication Protocol (PCEP) extensions required for stateful PCE usage are covered in separate documents.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8051"/>
          <seriesInfo name="DOI" value="10.17487/RFC8051"/>
        </reference>
        <reference anchor="RFC8233" target="https://www.rfc-editor.org/info/rfc8233" quoteTitle="true" derivedAnchor="RFC8233">
          <front>
            <title>Extensions to the Path Computation Element Communication Protocol (PCEP) to Compute Service-Aware Label Switched Paths (LSPs)</title>
            <author fullname="D. Dhody" initials="D." surname="Dhody"/>
            <author fullname="Q. Wu" initials="Q." surname="Wu"/>
            <author fullname="V. Manral" initials="V." surname="Manral"/>
            <author fullname="Z. Ali" initials="Z." surname="Ali"/>
            <author fullname="K. Kumaki" initials="K." surname="Kumaki"/>
            <date month="September" year="2017"/>
            <abstract>
              <t indent="0">In certain networks, such as, but not limited to, financial information networks (e.g., stock market data providers), network performance criteria (e.g., latency) are becoming as critical to data path selection as other metrics and constraints. These metrics are associated with the Service Level Agreement (SLA) between customers and service providers. The link bandwidth utilization (the total bandwidth of a link in actual use for the forwarding) is another important factor to consider during path computation.</t>
              <t indent="0">IGP Traffic Engineering (TE) Metric Extensions describe mechanisms with which network performance information is distributed via OSPF and IS-IS, respectively. The Path Computation Element Communication Protocol (PCEP) provides mechanisms for Path Computation Elements (PCEs) to perform path computations in response to Path Computation Client (PCC) requests. This document describes the extension to PCEP to carry latency, delay variation, packet loss, and link bandwidth utilization as constraints for end-to-end path computation.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8233"/>
          <seriesInfo name="DOI" value="10.17487/RFC8233"/>
        </reference>
        <reference anchor="RFC9325" target="https://www.rfc-editor.org/info/rfc9325" quoteTitle="true" derivedAnchor="RFC9325">
          <front>
            <title>Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)</title>
            <author fullname="Y. Sheffer" initials="Y." surname="Sheffer"/>
            <author fullname="P. Saint-Andre" initials="P." surname="Saint-Andre"/>
            <author fullname="T. Fossati" initials="T." surname="Fossati"/>
            <date month="November" year="2022"/>
            <abstract>
              <t indent="0">Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) are used to protect data exchanged over a wide range of application protocols and can also form the basis for secure transport protocols. Over the years, the industry has witnessed several serious attacks on TLS and DTLS, including attacks on the most commonly used cipher suites and their modes of operation. This document provides the latest recommendations for ensuring the security of deployed services that use TLS and DTLS. These recommendations are applicable to the majority of use cases.</t>
              <t indent="0">RFC 7525, an earlier version of the TLS recommendations, was published when the industry was transitioning to TLS 1.2. Years later, this transition is largely complete, and TLS 1.3 is widely available. This document updates the guidance given the new environment and obsoletes RFC 7525. In addition, this document updates RFCs 5288 and 6066 in view of recent attacks.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="195"/>
          <seriesInfo name="RFC" value="9325"/>
          <seriesInfo name="DOI" value="10.17487/RFC9325"/>
        </reference>
      </references>
    </references>
    <section toc="include" numbered="false" removeInRFC="false" pn="section-appendix.a">
      <name slugifiedName="name-acknowledgments">Acknowledgments</name>
      <t indent="0" pn="section-appendix.a-1">Thanks to <contact fullname="Jonathan Hardwick"/> for the discussion
      and suggestions around this document.</t>
      <t indent="0" pn="section-appendix.a-2">Thanks to <contact fullname="Oscar Gonzalez de Dios"/>, <contact fullname="Mike Koldychev"/>, <contact fullname="Samuel Sidor"/>, and
      <contact fullname="Peng Shaofu"/> for their review comments.</t>
    </section>
    <section toc="include" numbered="false" removeInRFC="false" pn="section-appendix.b">
      <name slugifiedName="name-contributors">Contributors</name>
      <contact fullname="Dhruv Dhody">
        <organization showOnFrontPage="true">Huawei</organization>
        <address>
          <postal>
            <country>India</country>
          </postal>
          <email>dhruv.ietf@gmail.com</email>
        </address>
      </contact>
    </section>
    <section anchor="authors-addresses" numbered="false" removeInRFC="false" toc="include" pn="section-appendix.c">
      <name slugifiedName="name-authors-addresses">Authors' Addresses</name>
      <author fullname="Cheng Li" initials="C." surname="Li">
        <organization showOnFrontPage="true">Huawei Technologies</organization>
        <address>
          <postal>
            <street>Huawei Campus, No. 156 Beiqing Rd.</street>
            <city>Beijing</city>
            <code>100095</code>
            <country>China</country>
          </postal>
          <email>c.l@huawei.com</email>
        </address>
      </author>
      <author fullname="Haomian Zheng" initials="H." surname="Zheng">
        <organization showOnFrontPage="true">Huawei Technologies</organization>
        <address>
          <postal>
            <street>H1, Huawei Xiliu Beipo Village, Songshan Lake</street>
            <city>Dongguan</city>
            <region>Guangdong</region>
            <code>523808</code>
            <country>China</country>
          </postal>
          <email>zhenghaomian@huawei.com</email>
        </address>
      </author>
      <author fullname="Stephane Litkowski" initials="S" surname="Litkowski">
        <organization showOnFrontPage="true">Cisco</organization>
        <address>
          <email>slitkows.ietf@gmail.com</email>
        </address>
      </author>
    </section>
  </back>
</rfc>
