<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?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 docName="draft-sidor-pce-binding-label-sid-extensions-00" submissionType="IETF" category="std" ipr="trust200902" obsoletes="" updates="">
  <front>
    <title abbrev="PCEP Binding SID Extensions">Binding Label/Segment Identifier (SID) Extensions in Path Computation Element Communication Protocol (PCEP)</title>
    <author fullname="Samuel Sidor" initials="S." surname="Sidor">
      <organization>Cisco Systems, Inc.</organization>
      <address>
        <postal>
          <street>Eurovea Central 3</street>
          <street>Pribinova 10</street>
          <city>Bratislava</city>
          <code>811 09</code>
          <country>Slovakia</country>
        </postal>
        <email>ssidor@cisco.com</email>
      </address>
    </author>
    <author fullname="Zafar Ali" initials="Z." surname="Ali">
      <organization>Cisco Systems, Inc.</organization>
      <address>
        <email>zali@cisco.com</email>
      </address>
    </author>
    <author fullname="Cheng Li" initials="C." surname="Li">
      <organization>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="Mike Koldychev" initials="M." surname="Koldychev">
      <organization>Ciena Corporation</organization>
      <address>
        <postal>
          <street>385 Terry Fox Dr.</street>
          <city>Kanata</city>
          <region>Ontario</region>
          <code>K2K 0L1</code>
          <country>Canada</country>
        </postal>
        <email>mkoldych@proton.me</email>
      </address>
    </author>
    <date/>
    <area>Routing</area>
    <workgroup>PCE Working Group</workgroup>
    <abstract>
      <t>
        The Path Computation Element Communication Protocol (PCEP) provides mechanisms for Path Computation Elements (PCEs) to instantiate and manage Label Switched Paths (LSPs) on a Path Computation Client (PCC). This includes the ability for a PCE to specify a Binding Segment Identifier (SID) for an LSP as described in RFC9604.
      </t>
      <t>
        A binding value specified by a PCE may not be available for use on the PCC. This can lead to LSP instantiation failures or entire PCEP message being rejected.
      </t>
      <t>
        This document proposes extensions to PCEP to allow a PCC to fall back to allocating a Binding SID from its own dynamic range if the value specified by the PCE is unavailable. It also defines a mechanism for the PCC to report both the requested and the allocated binding values back to the PCE.
      </t>
    </abstract>
  </front>
  <middle>
    <section title="Introduction">
      <t>
        A Stateful PCE <xref target="RFC8231"/> can instantiate LSPs on a PCC. When instantiating an Segment Routing Traffic Engineering (SR-TE) LSP <xref target="RFC8664"/>, the PCE may request a specific Binding SID (BSID) to be associated with the LSP using the TE-PATH-BINDING TLV <xref target="RFC9604"/>. A problem arises if the BSID requested by the PCE is already in use or is outside the valid range on the PCC. In the current PCEP specification, this would result in an LSP instantiation failure.
      </t>
      <t>
        This document specifies PCEP extensions to handle this situation gracefully. It introduces a capability that allows a PCC to signal its ability to fall back to local allocation. It also extends the TE-PATH-BINDING TLV to allow a PCE to control the fallback behavior and for a PCC to report the actual allocated BSID back to the PCE.
      </t>
  	  <section anchor="Language" title="Requirements Language">
      <t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
      "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
      "OPTIONAL" in this document are to be interpreted as described in BCP
      14 <xref target="RFC2119"></xref> <xref target="RFC8174"></xref> when,
      and only when, they appear in all capitals, as shown here.</t>
    </section>
    </section>
    <section title="Terminology">
      <t>This document uses the following terms defined in <xref target="RFC5440"/>: PCC, PCE, PCEP Peer, and PCEP speaker.</t>

      <t>The base PCEP specification <xref target="RFC4655"/> originally defined the use of the PCE architecture for MPLS and GMPLS networks
         with LSPs instantiated using the RSVP-TE signaling protocol. Over time, support for additional path setup types, such as
         SRv6, has been introduced <xref target="RFC9603"/>. The term "LSP" is used extensively in PCEP specifications and, in the
         context of this document, refers to a Candidate Path within an SR Policy, which may be an SRv6 path (still represented
         using the LSP Object as specified in <xref target="RFC8231"/>.
      </t>
    </section>
    <section title="PCEP Extensions">
      <section title="STATEFUL-PCE-CAPABILITY TLV">
        <t>
          A new flag is proposed for the STATEFUL-PCE-CAPABILITY TLV, originally defined in <xref format="default" section="5.4" sectionFormat="of" target="RFC8231"/>.
        </t>
        <t>
          <ul spacing="compact">
            <li>F (BSID-FALLBACK-CAPABILITY): If set, indicates that the PCEP peer supports LSP creation and fall back to dynamic binding value allocation if the specific binding value is unavailable, as detailed in <xref target="Operation"/>.</li>
          </ul>
        </t>
      </section>
      <section title="TE-PATH-BINDING TLV">
        <t>
          New flags are proposed in the TE-PATH-BINDING TLV, which was originally defined in <xref format="default" section="4" sectionFormat="of" target="RFC9604"/>.
        </t>
        <t>
          <ul spacing="compact">
            <li>A (Allocated): If set, indicates that the binding value encoded in the TLV represents an allocated binding value.</li>
            <li>D (Down on BSID Unavailability): If set, indicates that LSP can be created even if specified binding value is unavailable, but LSP will be in down state.</li>
            <li>F (Fallback): If set, indicates that binding value allocation from the dynamic range will be performed if the specified binding value is unavailable.</li>
          </ul>
        </t>
      </section>
    </section>
    <section anchor="Operation" title="Operation">
      <t>
        The PCEP protocol extensions defined in this document MUST NOT be used if one or both PCEP speakers have not indicated support for the extensions by setting the F flag (BSID-FALLBACK-CAPABILITY) in the STATEFUL-PCE-CAPABILITY TLV in their respective OPEN messages.
      </t>
      <t>
        When a PCE wants to instantiate or update an LSP and suggest a binding value, it includes the TE-PATH-BINDING TLV in the PCInitiate or PCUpd message. The PCE can set the F flag or the D flag in this TLV to control the PCC's behavior in case the requested binding value is unavailable. The F and D flags are mutually exclusive.
      </t>
      <t>
        If the PCC receives a TE-PATH-BINDING TLV with the F flag set and the requested binding value is unavailable, the PCC MUST attempt to allocate a new binding value from its dynamic pool. If successful, the LSP is brought up with the new binding value.
      </t>
      <t>
        If the PCC receives a TE-PATH-BINDING TLV with the D flag set and the requested binding value is unavailable, the PCC MUST instantiate the LSP but keep it in a down state.
      </t>
      <t>
        In its PCRpt message, the PCC reports the status of the binding value allocation. If the originally requested binding value and the allocated binding value differ, two instances of the TE-PATH-BINDING TLV MUST be included in the PCRpt message:
        <ul spacing="compact">
          <li>A TLV instance with the originally requested binding value with the A flag cleared.</li>
          <li>A TLV instance with the actually allocated binding value with the A flag set.</li>
        </ul>
      </t>
      <t>
        If the requested binding value was successfully allocated, only a single instance of the TE-PATH-BINDING TLV with the A flag set SHOULD be included in the PCEP message.
      </t>
      <t>
        The A, D and F flags in the TE-PATH-BINDING TLV MUST NOT be used if one or both PCEP speakers have not set the BSID-FALLBACK-CAPABILITY in the STATEFUL-PCE-CAPABILITY TLV in their respective OPEN messages.
      </t>
    </section>
    <section title="Manageability Considerations">
      <t>
        All manageability requirements and considerations listed in <xref target="RFC5440"/>, <xref target="RFC8231"/>, and <xref target="RFC9604"/> apply to the PCEP extensions defined in this document.
      </t>
      <t>
        A PCE or PCC implementation MAY allow the capability of supporting PCEP extensions introduced in this document to be enabled/disabled as part of the global configuration. An implementation SHOULD allow the operator to view the advertised and received capabilities.
      </t>
    </section>
    <section title="Security Considerations">
      <t>
        The security considerations described in <xref target="RFC5440"/>, <xref target="RFC8231"/>, and <xref target="RFC9604"/> are applicable to this document. No additional security measures are required.
      </t>
    </section>
    <section title="IANA Considerations">
     <section anchor="SR-CAPABILITY-FLAG" title="STATEFUL-PCE-CAPABILITY TLV Flag">
      <t>
        IANA maintains a registry, named "STATEFUL-PCE-CAPABILITY TLV Flag Field", within the "Path Computation Element Protocol (PCEP) Numbers" registry group. IANA is requested to make the following assignment:
      </t>
      <texttable>
        <ttcol>Bit</ttcol>
        <ttcol>Description</ttcol>
        <ttcol>Reference</ttcol>
        <c>TBA1</c>
        <c>F (BSID-FALLBACK-CAPABILITY)</c>
        <c>This document</c>
      </texttable>
	 </section>
	 <section anchor="TE-PATH-BINDING-FLAG" title="TE-PATH-BINDING TLV Flags">
      <t>
        IANA maintains a registry, named "TE-PATH-BINDING TLV Flag Field", within the "Path Computation Element Protocol (PCEP) Numbers" registry group. IANA is requested to make the following assignments:
      </t>
      <texttable>
        <ttcol>Bit</ttcol>
        <ttcol>Description</ttcol>
        <ttcol>Reference</ttcol>
        <c>TBA2</c>
        <c>A (Allocated)</c>
        <c>This document</c>
        <c>TBA3</c>
        <c>D (Down on BSID Unavailability)</c>
        <c>This document</c>
        <c>TBA4</c>
        <c>F (Fallback)</c>
        <c>This document</c>
      </texttable>
	 </section>
    </section>
  </middle>
  <back>
    <references title="Normative References">
      <?rfc include="reference.RFC.2119"?>
      <?rfc include="reference.RFC.8174"?>
      <?rfc include="reference.RFC.5440"?>
      <?rfc include="reference.RFC.8231"?>
      <?rfc include="reference.RFC.8664"?>
	  <?rfc include="reference.RFC.9604"?>
    </references>
    <references title="Informative References">
      <?rfc include="reference.RFC.4655"?>
      <?rfc include="reference.RFC.9603"?>
    </references>
    <section title="Acknowledgements">
      <t>The authors would like to thank Rajesh Melarcode Venkateswaran for their contributions to this document.</t>
    </section>
  </back>
</rfc>
