<?xml version="1.0" encoding="US-ASCII"?>
<?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"?> encoding="UTF-8"?>

<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC4657 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4657.xml">
<!ENTITY RFC5440 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5440.xml">
<!ENTITY RFC8174 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.8174.xml">
<!ENTITY RFC8231 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.8231.xml">
<!ENTITY RFC8281 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.8281.xml">
]> "rfc2629-xhtml.ent">

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

  <front>
    <title abbrev="Stateful PCEP Flags">Updated Rules for Processing Stateful PCE Request Parameters Flags</title>
    <seriesInfo name="RFC" value="8786"/>
    <author fullname="Adrian Farrel" initials="A." surname="Farrel">
      <organization>Old Dog Consulting</organization>
      <address>
        <email>adrian@olddog.co.uk</email>
      </address>
    </author>
    <date month="" month="May" year="2020"/>

    <area>Routing Area</area>

    <workgroup>PCE Working Group</workgroup>
    <area>Routing</area>
    <workgroup>PCE</workgroup>
    <keyword>PCEP</keyword>
    <keyword>Path Computation Element</keyword>
    <keyword>Stateful PCE</keyword>
    <keyword>Flags</keyword>

    <abstract>

      <t>Extensions to the Path Computation Element Communication Protocol
      (PCEP) to support stateful Path Computation Elements (PCEs) are defined
      in RFC 8231.  One of the extensions is the Stateful PCE Request
      Parameters (SRP) object.  That object includes a Flags field that is a
      set of 32 bit flags, and RFC 8281 defines an IANA registry for tracking
      assigned flags.  However, RFC 8231 does not explain how an
      implementation should set unassigned flags in transmitted messages, nor
      how an implementation should process unassigned, unknown, or unsupported
      flags in received messages.</t>
      <t>This document updates RFC 8231 by defining the correct behaviors.</t>
    </abstract>
  </front>
  <middle>
    <section title="Introduction"> numbered="true" toc="default">
      <name>Introduction</name>
      <t><xref target="RFC5440" /> format="default"/> describes the Path
      Computation Element Communication Protocol (PCEP).  PCEP defines the
      communication between a Path Computation Client (PCC) and a Path
      Computation Element (PCE), or between PCEs, enabling computation of
      Multiprotocol Label Switching (MPLS) for Traffic Engineering Label
      Switched Path (TE LSP) characteristics.</t>
      <t><xref target="RFC8231" /> format="default"/> specifies a set of
      extensions to PCEP to enable stateful control of LSPs within and across
      PCEP sessions in compliance with <xref target="RFC4657" />.
      format="default"/>.  It includes mechanisms to effect Label Switched
      Path (LSP) State Synchronization between PCCs and PCEs, delegation of
      control over LSPs to PCEs, and PCE control of timing and sequence of
      path computations within and across PCEP sessions.</t>
      <t>One of the extensions defined in <xref target="RFC8231" />
      format="default"/> is the Stateful PCE Request Parameters (SRP) object.
      That object includes a Flags field that is a set of 32 bit flags, and
      RFC 8281 defines an IANA registry for tracking assigned
      flags.  However, RFC 8231 does not explain how an
      implementation should set unassigned flags in transmitted messages, nor
      how an implementation should process unassigned or unknown flags in
      received messages.</t>
      <t>Furthermore, <xref target="RFC8231" /> target="RFC8231"/> gives no
      guidance to the authors of future specifications about how to describe
      the interaction between flags that have already been defined and flags
      being defined in the new specifications.</t>
      <t>This document updates RFC 8231 by defining the correct behaviors.</t>
    </section>
    <section title="Requirements Language">

      <t>The numbered="true" toc="default">
      <name>Requirements Language</name>

        <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 anchor="update" title="Updated Procedures"> numbered="true" toc="default">
      <name>Updated Procedures</name>
      <section anchor="advice" title="Advice numbered="true" toc="default">
        <name>Advice for Specification of New Flags">

        <t>Section 7 of <xref Flags</name>

        <t><xref target="RFC8231" /> sectionFormat="of" section="7"/> introduces
        changes to existing PCEP objects and the definition of defines new PCEP objects and TLVs
        in support of stateful PCE functionality.  That text does not advise
        future specifications on how to describe the interaction between flags
        that may be defined.</t>

        <t>The text in Section 7 <xref target="RFC8231" sectionFormat="of" section="7"/>
        is updated to read as follows:
           <list style="empty">
              <t>The
        </t>

        <ul empty="true" spacing="normal">
          <li>The PCEP objects defined in this document are compliant with the
          PCEP object format defined in <xref target="RFC5440" />.
          format="default"/>.  The P and I flags of the PCEP objects defined
          in the current document MUST <bcp14>MUST</bcp14> be set to 0 on
          transmission and SHOULD <bcp14>SHOULD</bcp14> be ignored on receipt since
          they are exclusively related to path computation requests.</t>
              <t>The requests.</li>
          <li>The sections that follow define PCEP objects and TLVs that
          contain flags Flags fields, and some flag values are defined.  Future
          specifications may define further flags, and each new specification
          that defines additional flags is expected to describe the
          interaction between these new flags and any existing flags.  In
          particular, new specifications are expected to explain how to handle
          the cases when both new and pre-existing flags are set.</t>
           </list></t> set.</li>
        </ul>
      </section>
      <section anchor="SRPflags" title="Flags numbered="true" toc="default">
        <name>Flags Field of the SRP Object">

        <t>Section 7.2 of <xref Object</name>
        <t><xref target="RFC8231" /> sectionFormat="of" section="7.2"/> defines the PCEP SRP object.  It describes
           the flags Flags field as:
           <list style="empty">
              <t>Flags
        </t>
        <ul empty="true" spacing="normal">
          <li>Flags (32 bits): None defined yet.</t>
           </list></t> yet.</li>
        </ul>
        <t>This document updates that text as follows:
           <list style="empty">
              <t>Flags
        </t>
        <ul empty="true" spacing="normal">
          <li>Flags (32 bits): This document does not define any flags.  Unassigned flags
                 MUST
                 <bcp14>MUST</bcp14> be set to zero on transmission and MUST <bcp14>MUST</bcp14> be ignored on receipt.
                 Implementations that do not understand any particular flag MUST <bcp14>MUST</bcp14> ignore the
                 flag.</t>
           </list></t>
                 flag.</li>
        </ul>
      </section>
    </section>
    <section anchor="Backward" title="Compatibility Considerations"> numbered="true" toc="default">
      <name>Compatibility Considerations</name>
      <t>While one of the main objectives of the changes made by this document
      is to enable backward compatibility, there remains an issue of
      compatibility between existing implementations of RFC 8231 and
      implementations that are consistent with this document.</t>
      <t>It should be noted that common behavior for flags Flags fields is as
      described by the updated text presented in <xref target="update" />.
      format="default"/>.  Thus, many implementations, lacking guidance from
      RFC 8231, will still have implemented a consistent and future-proof
      approach.  However, for completeness completeness, it is worth noting how behaviors
      might interact between implementations.</t>
      <t>SRP objects generated by an implementation of this document will set
      all unknown flag bits to zero and will therefore cause no issues to an
      older implementation even if it inspects those bits.  Similarly, an
      implementation of this document will not inspect any unknown flag bits
      and will therefore be unaffected by older implementations no matter how
      they set the flags.</t>

      <t>There will remain an issue with compatibility between implementations
      and how they set the flags. An implementation of RFC 8231 that might set any
      of the unassigned flags, and but an implementation of a future or current
      specification (such as <xref target="RFC8281" />) and future
          (such as format="default"/> or
      <xref target="I-D.ietf-pce-lsp-control-request" />) specifications that assign target="RFC8741" format="default"/>) assigns specific meanings to flags
      a flag if set. That problem cannot be fixed in old implementations by
      any amount of
          documentation, documentation and can only be handled for future
      specifications by obsoleting the Flags field and using a new technique.
      Fortunately, however, most implementations will have been constructed to
      set unused flags to zero zero, which is consistent with the behavior
      described in this document document, and so the risk of bad interactions is
      sufficiently small that there is no need to obsolete the existing Flags
      field.</t>
    </section>

    <section anchor="Imps" title="Implementation Status">

       <t>[NOTE TO RFC EDITOR: Please remove this section before publication as an RFC.]</t>

       <t>While this document describes changes to <xref target="RFC8231" /> that are important for
          implementation, and while the document gives advice to implementations, there is nothing
          specific in this document to implement.</t>

       <t>A private and unscientific poll of implementers of RFC 8231 conducted by the author suggests
          that existing implementations already abide by the modification set out in this document.</t>

    </section>

    <section anchor="Management" title="Management Considerations"> numbered="true" toc="default">
      <name>Management Considerations</name>
      <t>Implementations receiving set SRP flags that they do not recognize MAY <bcp14>MAY</bcp14> log this.  That could
          be helpful for diagnosing backward compatibility issues with future features that utilize those
          flags.</t>
    </section>
    <section anchor="Security" title="Security Considerations"> numbered="true" toc="default">
      <name>Security Considerations</name>
      <t><xref target="RFC8231" /> format="default"/> sets out security considerations for PCEP when used for communication
         with a stateful PCE.  This document does not change those considerations.</t>
      <t>However, by defining the expected behavior of implementations, this
      document may improve the stability of networks and thus reduce the
      attack surface.  That is, by reminding implementations to ignore unset
      bits, it is less possible to attack them by randomly tweaking bits.
      Furthermore, by reminding implementations to leave undefined bits unset,
      the network is future-proofed against new definitions of previously
      undefined bits.</t>
    </section>
    <section anchor="IANA" title="IANA Considerations"> numbered="true" toc="default">
      <name>IANA Considerations</name>
      <t>IANA maintains a registry called the "Path Computation Element
      Protocol (PCEP) Numbers" registry with a subregistry called " SRP "SRP Object
      Flag Field". IANA is requested to update has updated the Reference in reference for that
      subregistry to include a reference to list this document in addition to [RFC8281].</t>
      <xref target="RFC8281"/>.</t>
    </section>

  </middle>
  <back>
    <references>
      <name>References</name>
      <references>
        <name>Normative References</name>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8231.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8281.xml"/>
      </references>
      <references>
        <name>Informative References</name>

        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8741.xml"/>

        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4657.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5440.xml"/>
      </references>
    </references>

    <section anchor="Acknowledgements" title="Acknowledgements"> numbered="false" toc="default">
      <name>Acknowledgements</name>
      <t>Thanks to the authors of <xref target="I-D.ietf-pce-lsp-control-request" /> target="RFC8741" format="default"/>
      for exposing the need for this work.  Thanks to Dhruv Dhody and Julien Meuric <contact fullname="Dhruv
      Dhody"/> and <contact fullname="Julien Meuric"/> for discussing the
      solution.  Additional thanks to Hariharan Ananthakrishnan <contact fullname="Hariharan
      Ananthakrishnan"/> for his Shepherd&apos;s Shepherd's review.  Thanks to
         Benjamin Kaduk and Alvaro Retana <contact
      fullname="Benjamin Kaduk"/> and <contact fullname="Alvaro Retana"/> for
      helpful comments during IESG review.</t>
    </section>

  </middle>

  <back>

    <references title="Normative References">
      &RFC2119;
      &RFC8174;
      &RFC8231;
      &RFC8281;
    </references>

    <references title="Informative References">
      <?rfc include="reference.I-D.ietf-pce-lsp-control-request"?>
      &RFC4657;
      &RFC5440;
    </references>

  </back>
</rfc>