<?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 category="std" docName="draft-sidor-pce-circuit-style-pcep-extensions-01" ipr="trust200902">
  <front>
    <title abbrev="PCEP extensions for Circuit Style Policies">
    PCEP extensions for Circuit Style Policies
    </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="Praveen Maheshwari" initials="P." surname="Maheshwari">
      <organization>Airtel India</organization>
      <address>
        <email>Praveen.Maheshwari@airtel.com</email>
      </address>
    </author>
	
	<author fullname="Reza Rokui" initials="R." surname="Rokui">
      <organization>Ciena</organization>
      <address>
        <email>rrokui@ciena.com</email>
      </address>
    </author>
    <author fullname="Andrew Stone" initials="A." surname="Stone">
      <organization>Nokia</organization>
      <address>
        <email>andrew.stone@nokia.com</email>
      </address>
    </author>
    <author fullname="Luay Jalil" initials="L." surname="Jalil">
      <organization>Verizon</organization>
      <address>
        <email>luay.jalil@verizon.com</email>
      </address>
    </author>
    <author fullname="Shuping Peng" initials="S." surname="Peng">
      <organization>Huawei Technologies</organization>
      <address>
        <email>pengshuping@huawei.com</email>
      </address>
    </author>
    <author fullname="Tarek Saad" initials="T." surname="Saad">
      <organization>Juniper Networks</organization>
      <address>
        <email>tsaad@juniper.net</email>
      </address>
    </author>
    <author fullname="Daniel Voyer" initials="D." surname="Voyer">
      <organization>Bell Canada</organization>
      <address>
        <email>daniel.voyer@bell.ca</email>
      </address>
    </author>


    <date year="2022" month="May" day="13"/>

    <workgroup>PCE Working Group</workgroup>

    <abstract>

      <t>This document proposes a set of extensions for Path Computation
	  Element Communication Protocol (PCEP) for Circuit Style
	  Policies - Segment-Routing Policy designed to satisfy requirements
	  for connection-oriented transport services.
	  
	  New TLV is introduced to control path recomputation triggers and new
	  flag to add ability to request path with strict hops only.</t> 

    </abstract> 

    <note 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>
    </note>
  </front>
  <middle>

    <section title="Introduction" anchor="Introduction">

      <t>Usage of Segment-routing and PCEP in connection-oriented transport
	  services require path persistancy and hop-by-hop behavior for PCE computed paths.</t>
	  
	  <t>Circuit-Style Policy introduced in <xref target="I-D.schmutzer-pce-cs-sr-policy"/>
	  requires PCEP extensions, which are covered in this document. </t>

      <t>This document:</t>
		    <t><list style="symbols">
            <t>Introduces possibility to request strict path from the PCE by extending LSP-EXTENDED-FLAG TLV</t>
			<t>Adding new TLV for encoding blocked path recomputation triggers to the PCE is introduced, to be carried inside the LSP object, which is defined in <xref target="RFC8231"/>.</t>
			<t>Clarifies usage of existing O-flag from RP object in Segment-routing</t>
        </list></t>

      <t>PCEP extensions described in this document are applicable to RSVP-TE and SR-TE.</t>

    </section>

    <section title="Terminology">
      <t>The following terminologies are used in this document:
	    <list style="hanging">
          <t hangText="ERO:"> Explicit Route Object</t>
          <t hangText="IGP:"> Interior Gateway Protocol</t>
		  <t hangText="LSP:"> Label Switched Path.</t>
          <t hangText="LSPA:"> Label Switched Path Attributes.</t>
		  <t hangText="OTN:"> Optical Transport Network.</t>
		  <t hangText="PCC:"> Path Computation Client</t>
          <t hangText="PCE:"> Path Computation Element</t>
          <t hangText="PCEP:"> Path Computation Element Protocol.</t>
		  <t hangText="SDH:"> Synchronous Digital Hierarchy</t>
          <t hangText="SID:"> Segment Identifier</t>
		  <t hangText="SONET:"> Synchronous Optical Network</t>
          <t hangText="SR:"> Segment Routing.</t>
          <t hangText="SR-TE:"> Segment Routing Traffic Engineering.</t>
        </list>
      </t>
    </section>

    <section anchor="PCEP_EXTENSIONS" title="Overview of Extensions to PCEP">
	  <section anchor="LSP_EXTENDED_FLAG_TLV" title="LSP-EXTENDED-FLAG TLV">
        <t>O-flag is proposed in the LSP-EXTENDED-FLAG TLV, which was introduced in 5.1.2 of <xref target="I-D.ietf-pce-lsp-extended-flags"/> and extended with E-flag in <xref target="I-D.peng-pce-entropy-label-position"/></t>

        <t>The format of the LSP-EXTENDED-FLAG is as follows:</t>
        <figure anchor="LSP_EXTENDED_FLAG_TLV_FMT" title="LSP-EXTENDED-FLAG TLV Format">
          <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
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |           Type=TBD1           |          Length               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                                                           |O|E|
       //                 LSP Extended Flags                          //
       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
          ]]></artwork>
        </figure>

        <t>Type (16 bits): the value is TBD1 by IANA.</t>
	  
        <t>Length (16 bits): multiple of 4 octets.</t>
		
		<t>O (Strict-Path): If set to 1, this indicates to the PCE that a path exclusively made of strict hops is required. Strict hop definition can be found in Section 4.1</t>

      </section>
	
	  <section anchor="RECOMPUTATION_TLV" title="RECOMPUTATION-TRIGGERS TLV">
<t>This document defines new TLV for the LSP Object for encoding information about blocked path recomputation triggers.</t>
<figure><artwork align="center" name="" type="" alt="">
0                   1                   2                   3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|           Type = TBD2        |             Length = 4         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|             Reserved         |      Flags                 |T|P|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+</artwork></figure>

       <t>Type (16 bits): the value is TBD2 by IANA.</t>
	  
       <t>Length (16 bits): 4 octets </t>

       <t><list style="hanging">
            <t hangText="Reserved:"> MUST be set to zero by the sender and MUST be ignored by the receiver.</t>
            <t hangText="Flags:"> This document defines the following flag bits.  The other bits
              MUST be set to zero by the sender and MUST be ignored by the receiver.
              <list style="symbols">
                <t>T (Topology-change): If set to 1, the PCE MUST NOT trigger recomputation as a result of received updated topology information.</t>
				<t>P (Periodic-timer): If set to 1, the PCE MUST NOT trigger recomputation based on any periodic timer.</t>
              </list>
            </t>
          </list></t>
	  </section>
	  
	</section>

    <section anchor="Operation" title="Operation">

      <section anchor="STRICT_PATH" title="Strict path enforcement">

        <t>PCC MAY set the O flag in LSP-EXTENDED-FLAG TLV in PCRpt message to the PCE to indicate that a path exclusively made of strict hops is required.</t>
	
	    <t>O flag cleared or LSP-EXTENDED-FLAG TLV not included indicates that a loose path is acceptable.</t>

        <t>In PCUpdate or PCInitiate messages, when the O bit is set, this indicates that strict path is provided.</t>
		
		<t>The flag is applicable only for stateful messages. Existing O flag in RP object MAY be used to indicate similar behavior in PCReq and PCRep messages as described in as described in Section 7.4.1 of <xref target="RFC5440"/>.</t>
		
		<t>If O flag is set to 1 for both stateful and stateless messages for SR paths introduced in <xref target="RFC8664"/>, the PCE MUST use Adjacency SIDs only.</t>
      </section>

      <section anchor="RECOMP_TRIGGERS" title="Path computation triggers">

        <t>PCC MAY set flags in RECOMPUTATION-TRIGGERS-TLV to block specific triggers. If TLV is not included or all flags are set to 0, then the PCE MAY use any event to start path computation.</t>
		
		<t>Disabled recomputation triggered by topology event is not blocking path computation started based PCRpt or based on updated state of associated LSP.</t>
		
		<t>If trigger blocked by specific flag is not supported or allowed on the PCE, then PCE MAY ignore received flag value. The PCE SHOULD reflect blocked triggers in PCUpdate message.</t>
		
		<t>TLV MAY be included in PCInitiate and PCUpdate messages to indicate, which triggers will be disabled on the PCE. PCC should reflect flag values in PCRpt messages to forward requirement to other PCEs in the network.</t>

      </section>

    </section>

    <section anchor="Security" title="Security Considerations">

      <t>No additional security measure is required.</t>

    </section>

    <section anchor="IANA" title="IANA Considerations">

      <section anchor="IANA_O_FLAG" title="LSP-EXTENDED-FLAG TLV">

        <t><xref target="I-D.ietf-pce-lsp-extended-flags"/> defines the LSP-EXTENDED-FLAG TLV.
   IANA is requested to make the following assignment from the "LSP-EXTENDED-FLAG TLV Flag Field" registry:</t>
   
        <texttable anchor="EXTENDED_TLV_O_FLAG-VALUE" style="none" suppress-title="true">
          <ttcol align="center" width='15%'>Bit</ttcol>
          <ttcol align="left" width='30%'>Description </ttcol>
          <ttcol align="left" width='55%'>Reference </ttcol>
          <c>TBD1</c><c>Strict-Path Flag (O)</c><c>This document</c>
        </texttable>
	  </section>
	  
	  <section anchor="IANA_RECOMP_TLV" title="RECOMPUTATION-TRIGGERS TLV">

        <t>IANA is requested to make the assignment of a new value for the existing "PCEP TLV Type Indicators" registry as follows:</t>
   
        <texttable anchor="RECOMP_TLV_TYPE" style="none" suppress-title="true">
          <ttcol align="center" width='15%'>TLV Type</ttcol>
          <ttcol align="left" width='30%'>TLV Name</ttcol>
          <ttcol align="left" width='55%'>Reference </ttcol>
          <c>TBD2</c><c>RECOMPUTATION-TRIGGERS TLV</c><c>This document</c>
        </texttable>
	  </section>
	  
    </section>

  </middle>

  <back>
    <references title="Normative References">
      <?rfc include="reference.RFC.2119"?>
      <?rfc include="reference.RFC.5440"?>
      <?rfc include="reference.RFC.8174"?>
	  <?rfc include="reference.RFC.8231"?>
      <?rfc include="reference.RFC.8664"?>
      <?rfc include="reference.I-D.draft-ietf-pce-lsp-extended-flags"?>
	  <?rfc include="reference.I-D.draft-peng-pce-entropy-label-position"?>
    </references>
	<references title="Informative References">
	  <?rfc include="reference.I-D.draft-schmutzer-pce-cs-sr-policy"?>
    </references>

  </back>

</rfc>
