<?xml version='1.0' encoding='utf-8'?>
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" version="3" category="std" consensus="true" docName="draft-ietf-pce-stateful-path-protection-11" indexInclude="true" ipr="trust200902" number="8745" prepTime="2020-03-29T14:29:10" scripts="Common,Latin" sortRefs="true" submissionType="IETF" symRefs="true" tocDepth="3" tocInclude="true" xml:lang="en">
  <link href="https://datatracker.ietf.org/doc/draft-ietf-pce-stateful-path-protection-11" rel="prev"/>
  <link href="https://dx.doi.org/10.17487/rfc8745" rel="alternate"/>
  <link href="urn:issn:2070-1721" rel="alternate"/>
  <front>
    <title abbrev="Stateful PCE LSP Path Protection">Path Computation Element Communication Protocol (PCEP) Extensions for Associating Working and Protection Label Switched Paths (LSPs) with Stateful PCE</title>
    <seriesInfo name="RFC" value="8745" stream="IETF"/>
    <author fullname="Hariharan Ananthakrishnan" initials="H." surname="Ananthakrishnan">
      <organization showOnFrontPage="true">Netflix</organization>
      <address>
        <postal>
          <street/>
          <city/>
          <country>United States of America</country>
        </postal>
        <email>hari@netflix.com</email>
      </address>
    </author>
    <author fullname="Siva Sivabalan" initials="S." surname="Sivabalan">
      <organization showOnFrontPage="true">Cisco</organization>
      <address>
        <postal>
          <street>2000 Innovation Drive</street>
          <city>Kanata</city>
          <region>Ontario</region>
          <code>K2K 3E8</code>
          <country>Canada</country>
        </postal>
        <email>msiva@cisco.com</email>
      </address>
    </author>
    <author fullname="Colby Barth" initials="C." surname="Barth">
      <organization showOnFrontPage="true">Juniper Networks</organization>
      <address>
        <postal>
          <street>1194 N Mathilda Ave</street>
          <city>Sunnyvale</city>
          <region>CA</region>
          <code>94086</code>
          <country>United States of America</country>
        </postal>
        <email>cbarth@juniper.net</email>
      </address>
    </author>
    <author fullname="Ina Minei" initials="I." surname="Minei">
      <organization showOnFrontPage="true">Google, Inc</organization>
      <address>
        <postal>
          <street>1600 Amphitheatre Parkway</street>
          <city>Mountain View</city>
          <region>CA</region>
          <code>94043</code>
          <country>United States of America</country>
        </postal>
        <email>inaminei@google.com</email>
      </address>
    </author>
    <author initials="M" surname="Negi" fullname="Mahendra Singh Negi">
      <organization showOnFrontPage="true">Huawei Technologies</organization>
      <address>
        <postal>
          <street>Divyashree Techno Park, Whitefield</street>
          <city>Bangalore</city>
          <region>Karnataka</region>
          <code>560066</code>
          <country>India</country>
        </postal>
        <email>mahend.ietf@gmail.com</email>
      </address>
    </author>
    <date month="03" year="2020"/>
    <workgroup>PCE Working Group</workgroup>
    <keyword>PCEP</keyword>
    <abstract pn="section-abstract">
      <t pn="section-abstract-1"> An active stateful Path Computation Element (PCE) is capable of computing as well as controlling via 
Path Computation Element Communication Protocol (PCEP) Multiprotocol Label Switching Traffic Engineering (MPLS-TE) Label Switched Paths (LSPs).  
Furthermore, it is also possible for an active stateful PCE to create, maintain, and delete LSPs. This document defines the PCEP extension to associate two or more LSPs to provide end-to-end path protection.</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 pn="section-boilerplate.1-1">
            This is an Internet Standards Track document.
        </t>
        <t 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 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/rfc8745" 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 pn="section-boilerplate.2-1">
            Copyright (c) 2020 IETF Trust and the persons identified as the
            document authors. All rights reserved.
        </t>
        <t 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 Simplified BSD License text as described in
            Section 4.e of the Trust Legal Provisions and are provided without
            warranty as described in the Simplified 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 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 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 keepWithNext="true" 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-terminology">Terminology</xref></t>
          </li>
          <li pn="section-toc.1-1.3">
            <t keepWithNext="true" 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-extensions">PCEP Extensions</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 keepWithNext="true" 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-path-protection-association">Path Protection Association Type</xref></t>
              </li>
              <li pn="section-toc.1-1.3.2.2">
                <t keepWithNext="true" 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-path-protection-association-">Path Protection Association TLV</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.4">
            <t keepWithNext="true" 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-operation">Operation</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.4.2">
              <li pn="section-toc.1-1.4.2.1">
                <t keepWithNext="true" pn="section-toc.1-1.4.2.1.1"><xref derivedContent="4.1" format="counter" sectionFormat="of" target="section-4.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-state-synchronization">State Synchronization</xref></t>
              </li>
              <li pn="section-toc.1-1.4.2.2">
                <t keepWithNext="true" pn="section-toc.1-1.4.2.2.1"><xref derivedContent="4.2" format="counter" sectionFormat="of" target="section-4.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-pcc-initiated-lsps">PCC-Initiated LSPs</xref></t>
              </li>
              <li pn="section-toc.1-1.4.2.3">
                <t keepWithNext="true" pn="section-toc.1-1.4.2.3.1"><xref derivedContent="4.3" format="counter" sectionFormat="of" target="section-4.3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-pce-initiated-lsps">PCE-Initiated LSPs</xref></t>
              </li>
              <li pn="section-toc.1-1.4.2.4">
                <t keepWithNext="true" pn="section-toc.1-1.4.2.4.1"><xref derivedContent="4.4" format="counter" sectionFormat="of" target="section-4.4"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-session-termination">Session Termination</xref></t>
              </li>
              <li pn="section-toc.1-1.4.2.5">
                <t keepWithNext="true" pn="section-toc.1-1.4.2.5.1"><xref derivedContent="4.5" format="counter" sectionFormat="of" target="section-4.5"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-error-handling">Error Handling</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.5">
            <t keepWithNext="true" 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-other-considerations">Other Considerations</xref></t>
          </li>
          <li pn="section-toc.1-1.6">
            <t keepWithNext="true" 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-iana-considerations">IANA 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 keepWithNext="true" 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-association-type">Association Type</xref></t>
              </li>
              <li pn="section-toc.1-1.6.2.2">
                <t keepWithNext="true" 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-path-protection-association-tl">Path Protection Association TLV</xref></t>
              </li>
              <li pn="section-toc.1-1.6.2.3">
                <t keepWithNext="true" 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-pcep-errors">PCEP Errors</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.7">
            <t keepWithNext="true" 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-security-considerations">Security Considerations</xref></t>
          </li>
          <li pn="section-toc.1-1.8">
            <t keepWithNext="true" pn="section-toc.1-1.8.1"><xref derivedContent="8" format="counter" sectionFormat="of" target="section-8"/>.  <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.8.2">
              <li pn="section-toc.1-1.8.2.1">
                <t keepWithNext="true" pn="section-toc.1-1.8.2.1.1"><xref derivedContent="8.1" format="counter" sectionFormat="of" target="section-8.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.8.2.2">
                <t keepWithNext="true" pn="section-toc.1-1.8.2.2.1"><xref derivedContent="8.2" format="counter" sectionFormat="of" target="section-8.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.8.2.3">
                <t keepWithNext="true" pn="section-toc.1-1.8.2.3.1"><xref derivedContent="8.3" format="counter" sectionFormat="of" target="section-8.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.8.2.4">
                <t keepWithNext="true" pn="section-toc.1-1.8.2.4.1"><xref derivedContent="8.4" format="counter" sectionFormat="of" target="section-8.4"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-verify-correct-operations">Verify Correct Operations</xref></t>
              </li>
              <li pn="section-toc.1-1.8.2.5">
                <t keepWithNext="true" pn="section-toc.1-1.8.2.5.1"><xref derivedContent="8.5" format="counter" sectionFormat="of" target="section-8.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.8.2.6">
                <t keepWithNext="true" pn="section-toc.1-1.8.2.6.1"><xref derivedContent="8.6" format="counter" sectionFormat="of" target="section-8.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.9">
            <t keepWithNext="true" pn="section-toc.1-1.9.1"><xref derivedContent="9" format="counter" sectionFormat="of" target="section-9"/>.  <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.9.2">
              <li pn="section-toc.1-1.9.2.1">
                <t keepWithNext="true" pn="section-toc.1-1.9.2.1.1"><xref derivedContent="9.1" format="counter" sectionFormat="of" target="section-9.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-normative-references">Normative References</xref></t>
              </li>
              <li pn="section-toc.1-1.9.2.2">
                <t keepWithNext="true" pn="section-toc.1-1.9.2.2.1"><xref derivedContent="9.2" format="counter" sectionFormat="of" target="section-9.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-informative-references">Informative References</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.10">
            <t keepWithNext="true" pn="section-toc.1-1.10.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.11">
            <t keepWithNext="true" pn="section-toc.1-1.11.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.12">
            <t keepWithNext="true" pn="section-toc.1-1.12.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 numbered="true" toc="include" removeInRFC="false" pn="section-1">
      <name slugifiedName="name-introduction">Introduction</name>
      <t pn="section-1-1"><xref target="RFC5440" format="default" sectionFormat="of" derivedContent="RFC5440"/> describes Path Computation
      Element Communication Protocol (PCEP) for communication between a Path
      Computation Client (PCC) and a PCE or between a pair of PCEs as per
      <xref target="RFC4655" format="default" sectionFormat="of" derivedContent="RFC4655"/>.  A PCE computes paths for
      MPLS-TE Label Switched Paths (LSPs) based on various constraints and
      optimization criteria. </t>
      <t pn="section-1-2">Stateful PCE <xref target="RFC8231" format="default" sectionFormat="of" derivedContent="RFC8231"/> specifies a set of extensions to PCEP to enable 
stateful control of paths such as MPLS-TE LSPs between and across PCEP sessions in compliance with <xref target="RFC4657" format="default" sectionFormat="of" derivedContent="RFC4657"/>. 
It includes mechanisms to affect LSP state synchronization between PCCs and PCEs,
delegation of control of LSPs to PCEs, and PCE control of timing and
sequence of path computations within and across PCEP sessions. The
focus is on a model where LSPs are configured on the PCC, and control
over them is delegated to the stateful PCE.

Furthermore, <xref target="RFC8281" format="default" sectionFormat="of" derivedContent="RFC8281"/> specifies a mechanism to
dynamically instantiate LSPs on a PCC based on the requests from a
stateful PCE or a controller using stateful PCE.

</t>
      <t pn="section-1-3">Path protection <xref target="RFC4427" format="default" sectionFormat="of" derivedContent="RFC4427"/> refers to a
      paradigm in which the working LSP is protected by one or more protection
      LSP(s).  When the working LSP fails, protection LSP(s) is/are
      activated. When the working LSPs are computed and controlled by the PCE,
      there is benefit in a mode of operation where protection LSPs are also
      computed and controlled by the same PCE. <xref target="RFC8051" format="default" sectionFormat="of" derivedContent="RFC8051"/> describes the applicability of path protection in PCE
      deployments.</t>
      <t pn="section-1-4">This document specifies a stateful PCEP extension to associate two or
      more LSPs for the purpose of setting up path protection. The extension
      defined in this document covers the following scenarios:
      </t>
      <ul spacing="normal" bare="false" empty="false" pn="section-1-5">
        <li pn="section-1-5.1">A PCC initiates a protection LSP and retains the control of the
        LSP. The PCC computes the path itself or makes a request for path
        computation to a PCE. After the path setup, it reports the information
        and state of the path to the PCE.  This includes the association group
        identifying the working and protection LSPs.  This is the passive
        stateful mode <xref target="RFC8051" format="default" sectionFormat="of" derivedContent="RFC8051"/>.
    </li>
        <li pn="section-1-5.2">A PCC initiates a protection LSP and delegates the control of the
        LSP to a stateful PCE. During delegation, the association group
        identifying the working and protection LSPs is included. The PCE
        computes the path for the protection LSP and updates the PCC with the
        information about the path as long as it controls the LSP.  This is
        the active stateful mode <xref target="RFC8051" format="default" sectionFormat="of" derivedContent="RFC8051"/>.
    </li>
        <li pn="section-1-5.3">A protection LSP could be initiated by a stateful PCE, which retains the control of the LSP. 
    The PCE is responsible for computing the path of the LSP and updating to the PCC with the information about the path. 
    This is the PCE-Initiated mode <xref target="RFC8281" format="default" sectionFormat="of" derivedContent="RFC8281"/>.
    </li>
      </ul>
      <t pn="section-1-6">


   Note that a protection LSP can be established (signaled) before
   the failure (in which case the LSP is said to be either in standby mode
   <xref target="RFC4427" format="default" sectionFormat="of" derivedContent="RFC4427"/> or a primary LSP <xref target="RFC4872" format="default" sectionFormat="of" derivedContent="RFC4872"/>) or after failure of the
   corresponding working LSP (known as a secondary LSP <xref target="RFC4872" format="default" sectionFormat="of" derivedContent="RFC4872"/>).
   Whether to establish it before or after failure is according
   to operator choice or policy.

</t>
      <t pn="section-1-7"><xref target="RFC8697" format="default" sectionFormat="of" derivedContent="RFC8697"/> introduces a generic mechanism to
   create a grouping of LSPs, which can then be used to define
   associations between a set of LSPs.  The mechanism is equally
   applicable to stateful PCE (active and passive modes) and stateless
   PCE.</t>
      <t pn="section-1-8">This document specifies a PCEP extension to associate one working LSP with one or more
   protection LSPs using the generic association mechanism.</t>
      <t pn="section-1-9">This document describes a PCEP
   extension to associate protection LSPs by creating the Path Protection Association Group (PPAG)
   and encoding this association in PCEP messages for stateful PCEP
   sessions.
      </t>
      <section toc="include" numbered="true" removeInRFC="false" pn="section-1.1">
        <name slugifiedName="name-requirements-language">Requirements Language</name>
        <t 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 numbered="true" toc="include" removeInRFC="false" pn="section-2">
      <name slugifiedName="name-terminology">Terminology</name>
      <t pn="section-2-1">The following terms are used in this document:
      </t>
      <ul empty="true" bare="false" spacing="normal" pn="section-2-2">
        <li pn="section-2-2.1">
          <dl newline="false" spacing="normal" pn="section-2-2.1.1">
            <dt pn="section-2-2.1.1.1">ERO:</dt>
            <dd pn="section-2-2.1.1.2"> Explicit Route Object</dd>
            <dt pn="section-2-2.1.1.3">LSP:</dt>
            <dd pn="section-2-2.1.1.4"> Label Switched Path</dd>
            <dt pn="section-2-2.1.1.5">PCC:</dt>
            <dd pn="section-2-2.1.1.6"> Path Computation Client</dd>
            <dt pn="section-2-2.1.1.7">PCE:</dt>
            <dd pn="section-2-2.1.1.8"> Path Computation Element</dd>
            <dt pn="section-2-2.1.1.9">PCEP:</dt>
            <dd pn="section-2-2.1.1.10"> Path Computation Element Communication Protocol</dd>
            <dt pn="section-2-2.1.1.11">PPAG:</dt>
            <dd pn="section-2-2.1.1.12"> Path Protection Association Group</dd>
            <dt pn="section-2-2.1.1.13">TLV:</dt>
            <dd pn="section-2-2.1.1.14"> Type, Length, and Value</dd>
          </dl>
        </li>
      </ul>
    </section>
    <section anchor="Extension-Overview" numbered="true" toc="include" removeInRFC="false" pn="section-3">
      <name slugifiedName="name-pcep-extensions">PCEP Extensions</name>
      <section anchor="Path-Protection-Association-Type" numbered="true" toc="include" removeInRFC="false" pn="section-3.1">
        <name slugifiedName="name-path-protection-association">Path Protection Association Type</name>
        <t pn="section-3.1-1">As per <xref target="RFC8697" format="default" sectionFormat="of" derivedContent="RFC8697"/>, LSPs are not associated by listing the other LSPs
        with which they interact but, rather, by making them belong to an
        association group. All LSPs join an association group
        individually. The generic ASSOCIATION object is used to associate two
        or more LSPs as specified in <xref target="RFC8697" format="default" sectionFormat="of" derivedContent="RFC8697"/>. This
        document defines a new Association type called "Path Protection
        Association Type" of value 1 and a "Path Protection Association
        Group" (PPAG).  A member LSP of a PPAG can take the role of working or
        protection LSP.  A PPAG can have one working LSP and/or one or more
        protection LSPs. The source, destination, Tunnel ID (as carried in
        LSP-IDENTIFIERS TLV <xref target="RFC8231" format="default" sectionFormat="of" derivedContent="RFC8231"/>, with
        description as per <xref target="RFC3209" format="default" sectionFormat="of" derivedContent="RFC3209"/>), and
        Protection Type (PT) (in Path Protection Association TLV) of all LSPs
        within a PPAG <bcp14>MUST</bcp14> be the same. As per <xref target="RFC3209" format="default" sectionFormat="of" derivedContent="RFC3209"/>, a TE tunnel is used to associate a
        set of LSPs during reroute or to spread a traffic trunk over multiple
        paths.</t>
        <t pn="section-3.1-2">The format of the ASSOCIATION object used for PPAG is specified in 
<xref target="RFC8697" format="default" sectionFormat="of" derivedContent="RFC8697"/>.</t>
        <t pn="section-3.1-3"><xref target="RFC8697" format="default" sectionFormat="of" derivedContent="RFC8697"/> specifies the mechanism for the
   capability advertisement of the Association types supported by a PCEP
   speaker by defining an ASSOC-Type-List TLV to be carried within an
   OPEN object.  This capability exchange for the Association type
   described in this document (i.e.,  Path Protection Association Type) <bcp14>MAY</bcp14> be
   done before using this association, i.e., the PCEP speaker <bcp14>MAY</bcp14>
   include the Path Protection Association Type (1) in the ASSOC-Type-List TLV
   before using the PPAG in the PCEP messages.</t>
        <t pn="section-3.1-4">This Association type is dynamic in nature and created by the PCC
        or PCE for the LSPs belonging to the same TE tunnel (as described in
        <xref target="RFC3209" format="default" sectionFormat="of" derivedContent="RFC3209"/>) originating at the same
        head node and terminating at the same destination.  These associations
        are conveyed via PCEP messages to the PCEP peer. As per <xref target="RFC8697" format="default" sectionFormat="of" derivedContent="RFC8697"/>, the
        association source is set to the local PCEP speaker address that
        created the association unless local policy dictates
        otherwise. Operator-configured Association Range <bcp14>MUST NOT</bcp14> be set for this Association type and <bcp14>MUST</bcp14>
        be ignored.</t>
      </section>
      <section anchor="Path-Protection-Association-TLV" numbered="true" toc="include" removeInRFC="false" pn="section-3.2">
        <name slugifiedName="name-path-protection-association-">Path Protection Association TLV</name>
        <t pn="section-3.2-1">The Path Protection Association TLV is an optional TLV for use in
        the ASSOCIATION object with the Path Protection Association Type. The
        Path Protection Association TLV <bcp14>MUST NOT</bcp14> be present
        more than once.  If it appears more than once, only the first
        occurrence is processed and any others <bcp14>MUST</bcp14> be
        ignored. </t>
        <t pn="section-3.2-2"> The Path Protection Association TLV follows the PCEP TLV format of
	<xref target="RFC5440" format="default" sectionFormat="of" derivedContent="RFC5440"/>. </t>
        <t pn="section-3.2-3"> The Type (16 bits) of the TLV is 38. The Length 
field (16 bits) has a fixed value of 4.</t>
        <t pn="section-3.2-4">The value is comprised of a single field, the Path Protection Association
   Flags (32 bits), where each bit represents a flag option.</t>
        <t pn="section-3.2-5"> The format of the Path Protection Association TLV (<xref target="PPAG-TLV-Fmt" format="default" sectionFormat="of" derivedContent="Figure 1"/>) is as
        follows:</t>
        <figure anchor="PPAG-TLV-Fmt" align="left" suppress-title="false" pn="figure-1">
          <name slugifiedName="name-path-protection-association-t">Path Protection Association TLV Format</name>
          <artwork name="" type="" align="left" alt="" pn="section-3.2-6.1">
   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 = 38             |            Length = 4         |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |   PT      |               Unassigned Flags                |S|P|
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+            </artwork>
        </figure>
        <t pn="section-3.2-7">Path Protection Association Flags (32 bits)</t>
        <t pn="section-3.2-8">The following flags are currently defined: 
        </t>
        <ul empty="false" spacing="normal" bare="false" pn="section-3.2-9">
          <li pn="section-3.2-9.1">Protecting (P): 1 bit - This bit is as defined in <xref target="RFC4872" sectionFormat="of" section="14.1" format="default" derivedLink="https://rfc-editor.org/rfc/rfc4872#section-14.1" derivedContent="RFC4872"/> to indicate if
          the LSP is a working (0) or protection (1) LSP.</li>
          <li pn="section-3.2-9.2">Secondary (S): 1 bit - This bit is as defined in <xref target="RFC4872" sectionFormat="of" section="14.1" format="default" derivedLink="https://rfc-editor.org/rfc/rfc4872#section-14.1" derivedContent="RFC4872"/> to indicate if
          the LSP is a primary (0) or secondary (1) LSP. The S flag is ignored
          if the P flag is not set.</li>
          <li pn="section-3.2-9.3">Protection Type (PT): 6 bits - This field is as defined in <xref target="RFC4872" sectionFormat="of" section="14.1" format="default" derivedLink="https://rfc-editor.org/rfc/rfc4872#section-14.1" derivedContent="RFC4872"/> (as "LSP
          (Protection Type) Flags") to indicate the LSP protection type in
          use. Any type already defined or that could be defined in the future
          for use in the RSVP-TE PROTECTION object is acceptable in this TLV
          unless explicitly stated otherwise.</li>
          <li pn="section-3.2-9.4">Unassigned bits are considered reserved.  They <bcp14>MUST</bcp14> be set to 0 on
   transmission and <bcp14>MUST</bcp14> be ignored on receipt. </li>
        </ul>
        <t pn="section-3.2-10">If the TLV is missing in the PPAG ASSOCIATION object, it is
        considered that the LSP is a working LSP (i.e., as if the P bit is
        unset).</t>
      </section>
    </section>
    <section anchor="Operation" numbered="true" toc="include" removeInRFC="false" pn="section-4">
      <name slugifiedName="name-operation">Operation</name>
      <t pn="section-4-1">An LSP is associated with
   other LSPs with which it interacts by adding them to a common
   association group via the ASSOCIATION object. All procedures and error handling for the ASSOCIATION 
   object is as per <xref target="RFC8697" format="default" sectionFormat="of" derivedContent="RFC8697"/>.</t>
      <section anchor="Operation-State-Sync" numbered="true" toc="include" removeInRFC="false" pn="section-4.1">
        <name slugifiedName="name-state-synchronization">State Synchronization</name>
        <t pn="section-4.1-1">During state synchronization, a PCC reports all the existing LSP states as described in <xref target="RFC8231" format="default" sectionFormat="of" derivedContent="RFC8231"/>.
   The association group membership pertaining to an LSP is also reported as per <xref target="RFC8697" format="default" sectionFormat="of" derivedContent="RFC8697"/>. This
   includes PPAGs.</t>
      </section>
      <section anchor="Operation-PCC-Init" numbered="true" toc="include" removeInRFC="false" pn="section-4.2">
        <name slugifiedName="name-pcc-initiated-lsps">PCC-Initiated LSPs</name>
        <t pn="section-4.2-1">A PCC can associate a set of LSPs under its control for path
        protection purposes. Similarly, the PCC can remove one or more LSPs
        under its control from the corresponding PPAG. In both cases, the PCC
        reports the change in association to PCE(s) via a Path Computation
        Report (PCRpt) message. A PCC can also delegate the working and
        protection LSPs to an active stateful PCE, where the PCE would control
        the LSPs. The stateful PCE could update the paths and attributes of
        the LSPs in the association group via a Path Computation Update (PCUpd)
        message. A PCE could also update the association to the PCC via a PCUpd
        message. These procedures are described in <xref target="RFC8697" format="default" sectionFormat="of" derivedContent="RFC8697"/>.
</t>
        <t pn="section-4.2-2">It is expected that both working and protection LSPs are delegated together (and to the same PCE) to avoid any race conditions. Refer to <xref target="I-D.litkowski-pce-state-sync" format="default" sectionFormat="of" derivedContent="STATE-PCE-SYNC"/> for the problem description.</t>
      </section>
      <section anchor="Operation-PCE-Init" numbered="true" toc="include" removeInRFC="false" pn="section-4.3">
        <name slugifiedName="name-pce-initiated-lsps">PCE-Initiated LSPs</name>
        <t pn="section-4.3-1">A PCE can create/update working and protection LSPs independently. 
    As specified in <xref target="RFC8697" format="default" sectionFormat="of" derivedContent="RFC8697"/>, 
    Association Groups can be created by both the PCE and the PCC. 
    Furthermore, a PCE can remove a protection LSP from a PPAG as specified in 
    <xref target="RFC8697" format="default" sectionFormat="of" derivedContent="RFC8697"/>. The PCE uses PCUpd 
    or Path Computation Initiate (PCInitiate) messages to communicate the association information to the PCC.</t>
      </section>
      <section anchor="Session-Termination" numbered="true" toc="include" removeInRFC="false" pn="section-4.4">
        <name slugifiedName="name-session-termination">Session Termination</name>
        <t pn="section-4.4-1">As per <xref target="RFC8697" format="default" sectionFormat="of" derivedContent="RFC8697"/>, the association information is cleared along with
        the LSP state information.  When a PCEP session is terminated, after
        expiry of State Timeout Interval at the PCC, the LSP state associated
        with that PCEP session is reverted to operator-defined default
        parameters or behaviors as per <xref target="RFC8231" format="default" sectionFormat="of" derivedContent="RFC8231"/>. The same procedure is also followed for the
        association information.  On session termination at the PCE, when the
        LSP state reported by PCC is cleared, the association information is
        also cleared as per <xref target="RFC8697" format="default" sectionFormat="of" derivedContent="RFC8697"/>.  Where there are no LSPs in an association group,
        the association is considered to be deleted.</t>
      </section>
      <section anchor="Operation-Error-Handling" numbered="true" toc="include" removeInRFC="false" pn="section-4.5">
        <name slugifiedName="name-error-handling">Error Handling</name>
        <t pn="section-4.5-1">As per the processing rules specified in <xref target="RFC8697" sectionFormat="of" section="6.4" format="default" derivedLink="https://rfc-editor.org/rfc/rfc8697#section-6.4" derivedContent="RFC8697"/>, if a PCEP speaker does not support this Path
        Protection Association Type, it would return a PCErr message with
        Error-Type 26 "Association Error" and Error-Value 1 "Association type
        is not supported".</t>
        <t pn="section-4.5-2">All LSPs (working or protection) within a PPAG <bcp14>MUST</bcp14>
        belong to the same TE tunnel (as described in <xref target="RFC3209" format="default" sectionFormat="of" derivedContent="RFC3209"/>) and have the same source and destination.  If a
        PCEP speaker attempts to add or update an LSP to a PPAG and the Tunnel
        ID (as carried in the LSP-IDENTIFIERS TLV <xref target="RFC8231" format="default" sectionFormat="of" derivedContent="RFC8231"/>, with a description as per <xref target="RFC3209" format="default" sectionFormat="of" derivedContent="RFC3209"/>) or source or destination of the LSP is different
        from the LSP(s) in the PPAG, the PCEP speaker <bcp14>MUST</bcp14> send
        PCErr with Error-Type 26 (Association Error) <xref target="RFC8697" format="default" sectionFormat="of" derivedContent="RFC8697"/> and
        Error-Value 9 (Tunnel ID or endpoints mismatch for Path Protection
        Association). In case of Path Protection, an LSP-IDENTIFIERS TLV
        <bcp14>SHOULD</bcp14> be included for all LSPs (including Segment
        Routing (SR) <xref target="RFC8664" format="default" sectionFormat="of" derivedContent="RFC8664"/>). If the Protection Type (PT) (in the Path Protection
        Association TLV) is different from the LSPs in the PPAG, the PCEP
        speaker <bcp14>MUST</bcp14> send PCErr with Error-Type 26 (Association
        Error) <xref target="RFC8697" format="default" sectionFormat="of" derivedContent="RFC8697"/> and Error-Value 6 (Association information
        mismatch) as per <xref target="RFC8697" format="default" sectionFormat="of" derivedContent="RFC8697"/>.</t>
        <t pn="section-4.5-3">When the PCEP peer does not support the protection type set in PPAG, the PCEP peer <bcp14>MUST</bcp14> send PCErr with Error-Type 26 (Association Error) 
  <xref target="RFC8697" format="default" sectionFormat="of" derivedContent="RFC8697"/> and Error-Value 11 (Protection type is not supported).</t>
        <t pn="section-4.5-4">A given LSP <bcp14>MAY</bcp14> belong to more than one PPAG. If there is a conflict between any of the two PPAGs, the PCEP peer <bcp14>MUST</bcp14> send PCErr with Error-Type 26 (Association Error) <xref target="RFC8697" format="default" sectionFormat="of" derivedContent="RFC8697"/> and Error-Value 6 (Association information mismatch) as per <xref target="RFC8697" format="default" sectionFormat="of" derivedContent="RFC8697"/>.</t>
        <t pn="section-4.5-5">When the protection type is set to 1+1 (i.e., protection type=0x08
        or 0x10), there <bcp14>MUST</bcp14> be at maximum only one working LSP
        and one protection LSP within a PPAG.  If a PCEP speaker attempts to
        add another working/protection LSP, the PCEP peer <bcp14>MUST</bcp14>
        send PCErr with Error-Type 26 (Association Error) <xref target="RFC8697" format="default" sectionFormat="of" derivedContent="RFC8697"/> and Error-Value 10 (Attempt to add
        another working/protection LSP for Path Protection Association).</t>
        <t pn="section-4.5-6">When the protection type is set to 1:N (i.e., protection
        type=0x04), there <bcp14>MUST</bcp14> be at maximum only one protection
        LSP, and the number of working LSPs <bcp14>MUST NOT</bcp14> be more
        than N within a PPAG. If a PCEP speaker attempts to add another
        working/protection LSP, the PCEP peer <bcp14>MUST</bcp14> send PCErr
        with Error-Type 26 (Association Error) <xref target="RFC8697" format="default" sectionFormat="of" derivedContent="RFC8697"/> and Error-Value 10 (Attempt to add another
        working/protection LSP for Path Protection Association).</t>
        <t pn="section-4.5-7">During the make-before-break (MBB) procedure, two paths will
        briefly coexist. The error handling related to the number of LSPs allowed
        in a PPAG <bcp14>MUST NOT</bcp14> be applied during MBB.</t>
        <t pn="section-4.5-8">All processing as per <xref target="RFC8697" format="default" sectionFormat="of" derivedContent="RFC8697"/> continues to apply.</t>
      </section>
    </section>
    <section numbered="true" toc="include" removeInRFC="false" pn="section-5">
      <name slugifiedName="name-other-considerations">Other Considerations</name>
      <t pn="section-5-1">The working and protection LSPs are typically resource disjoint
      (e.g., node, Shared Risk Link Group [SRLG] disjoint).  This ensures that
      a single failure will not affect both the working and protection
      LSPs. The disjoint requirement for a group of LSPs is handled via
      another Association type called "Disjointness Association" as described
      in <xref target="I-D.ietf-pce-association-diversity" format="default" sectionFormat="of" derivedContent="PCEP-LSP-EXT"/>.
      The diversity requirements for the protection LSP are also handled by
      including both ASSOCIATION objects identifying both the protection
      association group and the disjoint association group for the group of
      LSPs. The relationship between the Synchronization VECtor (SVEC) object
      and the Disjointness Association is described in <xref target="I-D.ietf-pce-association-diversity" sectionFormat="of" section="5.4" format="default" derivedLink="https://tools.ietf.org/html/draft-ietf-pce-association-diversity-14#section-5.4" derivedContent="PCEP-LSP-EXT"/>.</t>
      <t pn="section-5-2"><xref target="RFC4872" format="default" sectionFormat="of" derivedContent="RFC4872"/> introduces the concept and
      mechanisms to support the association of one LSP to another LSP across
      different RSVP Traffic Engineering (RSVP-TE) sessions using the ASSOCIATION
      and PROTECTION object.  The information in the Path Protection
      Association TLV in PCEP as received from the PCE is used to trigger the
      signaling of the working LSP and protection LSP, with the Path Protection
      Association Flags mapped to the corresponding fields in the PROTECTION
      object in RSVP-TE.</t>
    </section>
    <section numbered="true" toc="include" removeInRFC="false" pn="section-6">
      <name slugifiedName="name-iana-considerations">IANA Considerations</name>
      <section numbered="true" toc="include" removeInRFC="false" pn="section-6.1">
        <name slugifiedName="name-association-type">Association Type</name>
        <t pn="section-6.1-1">This document defines a new Association type, originally
    defined in <xref target="RFC8697" format="default" sectionFormat="of" derivedContent="RFC8697"/>, for path protection. 
    IANA has assigned new value in the
    "ASSOCIATION Type Field" subregistry (created by <xref target="RFC8697" format="default" sectionFormat="of" derivedContent="RFC8697"/>) as follows: </t>
        <table align="center" pn="table-1">
          <name slugifiedName="name-association-type-field">ASSOCIATION Type Field
</name>
          <thead>
            <tr>
              <th align="left" colspan="1" rowspan="1">Type</th>
              <th align="left" colspan="1" rowspan="1">Name</th>
              <th align="left" colspan="1" rowspan="1">Reference</th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td align="left" colspan="1" rowspan="1">1</td>
              <td align="left" colspan="1" rowspan="1">Path Protection Association</td>
              <td align="left" colspan="1" rowspan="1">RFC 8745</td>
            </tr>
          </tbody>
        </table>
      </section>
      <section numbered="true" toc="include" removeInRFC="false" pn="section-6.2">
        <name slugifiedName="name-path-protection-association-tl">Path Protection Association TLV</name>
        <t pn="section-6.2-1"> This document defines a new TLV for carrying the additional information of LSPs within a path protection association group.
      IANA has assigned a new value in the
   "PCEP TLV Type Indicators" subregistry as follows:</t>
        <table align="center" pn="table-2">
          <name slugifiedName="name-pcep-tlv-type-indicators">PCEP TLV Type Indicators
</name>
          <thead>
            <tr>
              <th align="left" colspan="1" rowspan="1">Value</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">38</td>
              <td align="left" colspan="1" rowspan="1">Path Protection Association Group TLV</td>
              <td align="left" colspan="1" rowspan="1">RFC 8745</td>
            </tr>
          </tbody>
        </table>
        <t pn="section-6.2-3"> Per this document, a new subregistry named "Path
        protection Association Group TLV Flag Field" has been created within the
        "Path Computation Element Protocol (PCEP) Numbers" registry to manage
        the Flag field in the Path Protection Association Group TLV.  New
        values are to be assigned by Standards Action <xref target="RFC8126" format="default" sectionFormat="of" derivedContent="RFC8126"/>.  Each bit should be tracked with the following
        qualities:
</t>
        <ul spacing="normal" bare="false" empty="false" pn="section-6.2-4">
          <li pn="section-6.2-4.1">Bit number (count from 0 as the most significant bit)</li>
          <li pn="section-6.2-4.2">Name of the flag</li>
          <li pn="section-6.2-4.3">Reference</li>
        </ul>
        <table anchor="PPAG-TLV-Table-IANA" align="center" pn="table-3">
          <name slugifiedName="name-path-protection-association-g">Path Protection Association Group TLV Flag Field</name>
          <thead>
            <tr>
              <th align="center" colspan="1" rowspan="1">Bit</th>
              <th align="center" colspan="1" rowspan="1">Name</th>
              <th align="center" colspan="1" rowspan="1">Reference</th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td align="center" colspan="1" rowspan="1">31</td>
              <td align="center" colspan="1" rowspan="1">P - PROTECTION-LSP</td>
              <td align="center" colspan="1" rowspan="1">RFC 8745 </td>
            </tr>
            <tr>
              <td align="center" colspan="1" rowspan="1">30</td>
              <td align="center" colspan="1" rowspan="1">S - SECONDARY-LSP</td>
              <td align="center" colspan="1" rowspan="1">RFC 8745</td>
            </tr>
            <tr>
              <td align="center" colspan="1" rowspan="1">6-29</td>
              <td align="center" colspan="1" rowspan="1">Unassigned</td>
              <td align="center" colspan="1" rowspan="1">RFC 8745</td>
            </tr>
            <tr>
              <td align="center" colspan="1" rowspan="1">0-5</td>
              <td align="center" colspan="1" rowspan="1">Protection Type Flags</td>
              <td align="center" colspan="1" rowspan="1">RFC 8745 </td>
            </tr>
          </tbody>
        </table>
      </section>
      <section numbered="true" toc="include" removeInRFC="false" pn="section-6.3">
        <name slugifiedName="name-pcep-errors">PCEP Errors</name>
        <t pn="section-6.3-1">This document defines new Error-Values related to path protection
        association for Error-type 26 "Association Error" defined in <xref target="RFC8697" format="default" sectionFormat="of" derivedContent="RFC8697"/>.  IANA has allocated new error values within the "PCEP-ERROR Object
        Error Types and Values" subregistry of the PCEP Numbers registry as
        follows:</t>
        <table align="center" pn="table-4">
          <name slugifiedName="name-pcep-error-object-error-typ">PCEP-ERROR Object Error Types and Values
</name>
          <thead>
            <tr>
              <th align="left" colspan="1" rowspan="1"> Error-Type </th>
              <th align="left" colspan="1" rowspan="1"> Meaning </th>
              <th align="left" colspan="1" rowspan="1"> Error-value </th>
              <th align="left" colspan="1" rowspan="1"> Reference </th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td align="left" colspan="1" rowspan="1"> 26 </td>
              <td align="left" colspan="1" rowspan="1">Association Error</td>
              <td align="left" colspan="1" rowspan="1"/>
              <td align="left" colspan="1" rowspan="1">
                <xref target="RFC8697" format="default" sectionFormat="of" derivedContent="RFC8697"/></td>
            </tr>
            <tr>
              <td align="left" colspan="1" rowspan="1"/>
              <td align="left" colspan="1" rowspan="1"/>
              <td align="left" colspan="1" rowspan="1">9: Tunnel ID or endpoints mismatch for Path Protection Association</td>
              <td align="left" colspan="1" rowspan="1">RFC 8745</td>
            </tr>
            <tr>
              <td align="left" colspan="1" rowspan="1"/>
              <td align="left" colspan="1" rowspan="1"/>
              <td align="left" colspan="1" rowspan="1">10: Attempt to add another working/protection LSP for Path Protection Association</td>
              <td align="left" colspan="1" rowspan="1">RFC 8745</td>
            </tr>
            <tr>
              <td align="left" colspan="1" rowspan="1"/>
              <td align="left" colspan="1" rowspan="1"/>
              <td align="left" colspan="1" rowspan="1">11: Protection type is not supported</td>
              <td align="left" colspan="1" rowspan="1">RFC 8745</td>
            </tr>
          </tbody>
        </table>
      </section>
    </section>
    <section numbered="true" toc="include" removeInRFC="false" pn="section-7">
      <name slugifiedName="name-security-considerations">Security Considerations</name>
      <t pn="section-7-1">
               The security considerations described in <xref target="RFC8231" format="default" sectionFormat="of" derivedContent="RFC8231"/>, <xref target="RFC8281" format="default" sectionFormat="of" derivedContent="RFC8281"/>,
               and <xref target="RFC5440" format="default" sectionFormat="of" derivedContent="RFC5440"/> apply to the
               extensions described in this document as well.  Additional
               considerations related to associations where a malicious PCEP
               speaker could be spoofed and could be used as an attack vector
               by creating associations are described in <xref target="RFC8697" format="default" sectionFormat="of" derivedContent="RFC8697"/>.
               Adding a spurious protection LSP to the Path Protection
               Association group could give a false sense of network
               reliability, which leads to issues when the working LSP is down
               and the protection LSP fails as well. Thus, securing the PCEP
               session using Transport Layer Security (TLS) <xref target="RFC8253" format="default" sectionFormat="of" derivedContent="RFC8253"/>, as per the recommendations
               and best current practices in BCP 195 <xref target="RFC7525" format="default" sectionFormat="of" derivedContent="RFC7525"/>, is <bcp14>RECOMMENDED</bcp14>.
      </t>
    </section>
    <section toc="include" numbered="true" removeInRFC="false" pn="section-8">
      <name slugifiedName="name-manageability-consideration">Manageability Considerations</name>
      <section toc="include" numbered="true" removeInRFC="false" pn="section-8.1">
        <name slugifiedName="name-control-of-function-and-pol">Control of Function and Policy</name>
        <t pn="section-8.1-1">Mechanisms defined in this document do not imply any control or policy 
            requirements in addition to those already listed 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"/>.</t>
      </section>
      <section toc="include" numbered="true" removeInRFC="false" pn="section-8.2">
        <name slugifiedName="name-information-and-data-models">Information and Data Models</name>
        <t pn="section-8.2-1"><xref target="RFC7420" format="default" sectionFormat="of" derivedContent="RFC7420"/> describes the PCEP MIB; there are no new MIB Objects
        for this document.</t>
        <t pn="section-8.2-2">The PCEP YANG module <xref target="I-D.ietf-pce-pcep-yang" format="default" sectionFormat="of" derivedContent="PCEP-YANG"/> supports
        associations.</t>
      </section>
      <section toc="include" numbered="true" removeInRFC="false" pn="section-8.3">
        <name slugifiedName="name-liveness-detection-and-moni">Liveness Detection and Monitoring</name>
        <t pn="section-8.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"/>, <xref target="RFC8231" format="default" sectionFormat="of" derivedContent="RFC8231"/>, and 
        <xref target="RFC8281" format="default" sectionFormat="of" derivedContent="RFC8281"/>.</t>
      </section>
      <section toc="include" numbered="true" removeInRFC="false" pn="section-8.4">
        <name slugifiedName="name-verify-correct-operations">Verify Correct Operations</name>
        <t pn="section-8.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"/>, <xref target="RFC8231" format="default" sectionFormat="of" derivedContent="RFC8231"/>, and 
        <xref target="RFC8281" format="default" sectionFormat="of" derivedContent="RFC8281"/>.</t>
      </section>
      <section toc="include" numbered="true" removeInRFC="false" pn="section-8.5">
        <name slugifiedName="name-requirements-on-other-proto">Requirements on Other Protocols</name>
        <t pn="section-8.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-8.6">
        <name slugifiedName="name-impact-on-network-operation">Impact on Network Operations</name>
        <t pn="section-8.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"/>, <xref target="RFC8231" format="default" sectionFormat="of" derivedContent="RFC8231"/>, and 
        <xref target="RFC8281" format="default" sectionFormat="of" derivedContent="RFC8281"/>.</t>
      </section>
    </section>
  </middle>
  <back>
    <displayreference target="I-D.ietf-pce-pcep-yang" to="PCEP-YANG"/>
    <displayreference target="I-D.ietf-pce-association-diversity" to="PCEP-LSP-EXT"/>
    <displayreference target="I-D.litkowski-pce-state-sync" to="STATE-PCE-SYNC"/>
    <references pn="section-9">
      <name slugifiedName="name-references">References</name>
      <references pn="section-9.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 initials="S." surname="Bradner" fullname="S. Bradner">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="1997" month="March"/>
            <abstract>
              <t>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="RFC3209" target="https://www.rfc-editor.org/info/rfc3209" quoteTitle="true" derivedAnchor="RFC3209">
          <front>
            <title>RSVP-TE: Extensions to RSVP for LSP Tunnels</title>
            <author initials="D." surname="Awduche" fullname="D. Awduche">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="L." surname="Berger" fullname="L. Berger">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="D." surname="Gan" fullname="D. Gan">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="T." surname="Li" fullname="T. Li">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="V." surname="Srinivasan" fullname="V. Srinivasan">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="G." surname="Swallow" fullname="G. Swallow">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2001" month="December"/>
            <abstract>
              <t>This document describes the use of RSVP (Resource Reservation Protocol), including all the necessary extensions, to establish label-switched paths (LSPs) in MPLS (Multi-Protocol Label Switching).  Since the flow along an LSP is completely identified by the label applied at the ingress node of the path, these paths may be treated as tunnels.  A key application of LSP tunnels is traffic engineering with MPLS as specified in RFC 2702.  [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="3209"/>
          <seriesInfo name="DOI" value="10.17487/RFC3209"/>
        </reference>
        <reference anchor="RFC4872" target="https://www.rfc-editor.org/info/rfc4872" quoteTitle="true" derivedAnchor="RFC4872">
          <front>
            <title>RSVP-TE Extensions in Support of End-to-End Generalized Multi-Protocol Label Switching (GMPLS) Recovery</title>
            <author initials="J.P." surname="Lang" fullname="J.P. Lang" role="editor">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="Y." surname="Rekhter" fullname="Y. Rekhter" role="editor">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="D." surname="Papadimitriou" fullname="D. Papadimitriou" role="editor">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2007" month="May"/>
            <abstract>
              <t>This document describes protocol-specific procedures and extensions for Generalized Multi-Protocol Label Switching (GMPLS) Resource ReSerVation Protocol - Traffic Engineering (RSVP-TE) signaling to support end-to-end Label Switched Path (LSP) recovery that denotes protection and restoration.  A generic functional description of GMPLS recovery can be found in a companion document, RFC 4426.  [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="4872"/>
          <seriesInfo name="DOI" value="10.17487/RFC4872"/>
        </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 initials="JP." surname="Vasseur" fullname="JP. Vasseur" role="editor">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="JL." surname="Le Roux" fullname="JL. Le Roux" role="editor">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2009" month="March"/>
            <abstract>
              <t>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="RFC7525" target="https://www.rfc-editor.org/info/rfc7525" quoteTitle="true" derivedAnchor="RFC7525">
          <front>
            <title>Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)</title>
            <author initials="Y." surname="Sheffer" fullname="Y. Sheffer">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="R." surname="Holz" fullname="R. Holz">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="P." surname="Saint-Andre" fullname="P. Saint-Andre">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2015" month="May"/>
            <abstract>
              <t>Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) are widely used to protect data exchanged over application protocols such as HTTP, SMTP, IMAP, POP, SIP, and XMPP.  Over the last few years, several serious attacks on TLS have emerged, including attacks on its most commonly used cipher suites and their modes of operation.  This document provides recommendations for improving the security of deployed services that use TLS and DTLS. The recommendations are applicable to the majority of use cases.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="195"/>
          <seriesInfo name="RFC" value="7525"/>
          <seriesInfo name="DOI" value="10.17487/RFC7525"/>
        </reference>
        <reference anchor="RFC8126" target="https://www.rfc-editor.org/info/rfc8126" quoteTitle="true" derivedAnchor="RFC8126">
          <front>
            <title>Guidelines for Writing an IANA Considerations Section in RFCs</title>
            <author initials="M." surname="Cotton" fullname="M. Cotton">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="B." surname="Leiba" fullname="B. Leiba">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="T." surname="Narten" fullname="T. Narten">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2017" month="June"/>
            <abstract>
              <t>Many protocols make use of points of extensibility that use constants to identify various protocol parameters.  To ensure that the values in these fields do not have conflicting uses and to promote interoperability, their allocations are often coordinated by a central record keeper.  For IETF protocols, that role is filled by the Internet Assigned Numbers Authority (IANA).</t>
              <t>To make assignments in a given registry prudently, guidance describing the conditions under which new values should be assigned, as well as when and how modifications to existing values can be made, is needed.  This document defines a framework for the documentation of these guidelines by specification authors, in order to assure that the provided guidance for the IANA Considerations is clear and addresses the various issues that are likely in the operation of a registry.</t>
              <t>This is the third edition of this document; it obsoletes RFC 5226.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="26"/>
          <seriesInfo name="RFC" value="8126"/>
          <seriesInfo name="DOI" value="10.17487/RFC8126"/>
        </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 initials="B." surname="Leiba" fullname="B. Leiba">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2017" month="May"/>
            <abstract>
              <t>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 initials="E." surname="Crabbe" fullname="E. Crabbe">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="I." surname="Minei" fullname="I. Minei">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="J." surname="Medved" fullname="J. Medved">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="R." surname="Varga" fullname="R. Varga">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2017" month="September"/>
            <abstract>
              <t>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>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 initials="D." surname="Lopez" fullname="D. Lopez">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="O." surname="Gonzalez de Dios" fullname="O. Gonzalez de Dios">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="Q." surname="Wu" fullname="Q. Wu">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="D." surname="Dhody" fullname="D. Dhody">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2017" month="October"/>
            <abstract>
              <t>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>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 initials="E." surname="Crabbe" fullname="E. Crabbe">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="I." surname="Minei" fullname="I. Minei">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="S." surname="Sivabalan" fullname="S. Sivabalan">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="R." surname="Varga" fullname="R. Varga">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2017" month="December"/>
            <abstract>
              <t>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>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>
        <reference anchor="RFC8697" target="https://www.rfc-editor.org/info/rfc8697" quoteTitle="true" derivedAnchor="RFC8697">
          <front>
            <title>Path Computation Element Communication Protocol (PCEP) Extensions for Establishing Relationships between Sets of Label Switched Paths (LSPs)</title>
            <author initials="I." surname="Minei" fullname="I. Minei">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="E." surname="Crabbe" fullname="E. Crabbe">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="S." surname="Sivabalan" fullname="S. Sivabalan">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="H." surname="Ananthakrishnan" fullname="H. Ananthakrishnan">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="D." surname="Dhody" fullname="D. Dhody">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="Y." surname="Tanaka" fullname="Y. Tanaka">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2020" month="January"/>
            <abstract>
              <t>This document introduces a generic mechanism to create a grouping of Label Switched Paths (LSPs) in the context of a Path Computation Element (PCE). This grouping can then be used to define associations between sets of LSPs or between a set of LSPs and a set of attributes (such as configuration parameters or behaviors), and it is equally applicable to the stateful PCE (active and passive modes) and the stateless PCE.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8697"/>
          <seriesInfo name="DOI" value="10.17487/RFC8697"/>
        </reference>
      </references>
      <references pn="section-9.2">
        <name slugifiedName="name-informative-references">Informative References</name>
        <reference anchor="I-D.ietf-pce-association-diversity" quoteTitle="true" target="https://tools.ietf.org/html/draft-ietf-pce-association-diversity-14" derivedAnchor="PCEP-LSP-EXT">
          <front>
            <title>Path Computation Element Communication Protocol (PCEP) Extension for LSP Diversity Constraint Signaling</title>
            <author initials="S" surname="Litkowski" fullname="Stephane Litkowski">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="S" surname="Sivabalan" fullname="Siva Sivabalan">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="C" surname="Barth" fullname="Colby Barth">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="M" surname="Negi" fullname="Mahendra Negi">
              <organization showOnFrontPage="true"/>
            </author>
            <date month="January" day="26" year="2020"/>
            <abstract>
              <t>This document introduces a simple mechanism to associate a group of Label Switched Paths (LSPs) via an extension to the Path Computation Element (PCE) communication Protocol (PCEP) with the purpose of computing diverse (disjointed) paths for those LSPs.  The proposed extension allows a Path Computation Client (PCC) to advertise to a PCE that a particular LSP belongs to a particular disjoint-group, thus the PCE knows that the LSPs in the same group need to be disjoint from each other.</t>
            </abstract>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-ietf-pce-association-diversity-14"/>
          <format type="TXT" target="http://www.ietf.org/internet-drafts/draft-ietf-pce-association-diversity-14.txt"/>
          <refcontent>Work in Progress</refcontent>
        </reference>
        <reference anchor="I-D.ietf-pce-pcep-yang" quoteTitle="true" target="https://tools.ietf.org/html/draft-ietf-pce-pcep-yang-13" 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">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="J" surname="Hardwick" fullname="Jonathan Hardwick">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="V" surname="Beeram" fullname="Vishnu Beeram">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="J" surname="Tantsura" fullname="Jeff Tantsura">
              <organization showOnFrontPage="true"/>
            </author>
            <date month="October" day="31" year="2019"/>
            <abstract>
              <t>This document defines a YANG data model for the management of Path Computation Element communications Protocol (PCEP) for communications between a Path Computation Client (PCC) and a Path Computation Element (PCE), or between two PCEs.  The data model includes configuration and state data.</t>
            </abstract>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-ietf-pce-pcep-yang-13"/>
          <format type="TXT" target="http://www.ietf.org/internet-drafts/draft-ietf-pce-pcep-yang-13.txt"/>
          <refcontent>Work in Progress</refcontent>
        </reference>
        <reference anchor="RFC4427" target="https://www.rfc-editor.org/info/rfc4427" quoteTitle="true" derivedAnchor="RFC4427">
          <front>
            <title>Recovery (Protection and Restoration) Terminology for Generalized Multi-Protocol Label Switching (GMPLS)</title>
            <author initials="E." surname="Mannie" fullname="E. Mannie" role="editor">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="D." surname="Papadimitriou" fullname="D. Papadimitriou" role="editor">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2006" month="March"/>
            <abstract>
              <t>This document defines a common terminology for Generalized Multi-Protocol Label Switching (GMPLS)-based recovery mechanisms (i.e., protection and restoration).  The terminology is independent of the underlying transport technologies covered by GMPLS.  This memo provides information for the Internet community.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="4427"/>
          <seriesInfo name="DOI" value="10.17487/RFC4427"/>
        </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 initials="A." surname="Farrel" fullname="A. Farrel">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="J.-P." surname="Vasseur" fullname="J.-P. Vasseur">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="J." surname="Ash" fullname="J. Ash">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2006" month="August"/>
            <abstract>
              <t>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>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="RFC4657" target="https://www.rfc-editor.org/info/rfc4657" quoteTitle="true" derivedAnchor="RFC4657">
          <front>
            <title>Path Computation Element (PCE) Communication Protocol Generic Requirements</title>
            <author initials="J." surname="Ash" fullname="J. Ash" role="editor">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="J.L." surname="Le Roux" fullname="J.L. Le Roux" role="editor">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2006" month="September"/>
            <abstract>
              <t>The PCE model is described in the "PCE Architecture" document and facilitates path computation requests from Path Computation Clients (PCCs) to Path Computation Elements (PCEs).  This document specifies generic requirements for a communication protocol between PCCs and PCEs, and also between PCEs where cooperation between PCEs is desirable.  Subsequent documents will specify application-specific requirements for the PCE communication protocol.  This memo provides information for the Internet community.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="4657"/>
          <seriesInfo name="DOI" value="10.17487/RFC4657"/>
        </reference>
        <reference anchor="RFC7420" target="https://www.rfc-editor.org/info/rfc7420" quoteTitle="true" derivedAnchor="RFC7420">
          <front>
            <title>Path Computation Element Communication Protocol (PCEP) Management Information Base (MIB) Module</title>
            <author initials="A." surname="Koushik" fullname="A. Koushik">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="E." surname="Stephan" fullname="E. Stephan">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="Q." surname="Zhao" fullname="Q. Zhao">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="D." surname="King" fullname="D. King">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="J." surname="Hardwick" fullname="J. Hardwick">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2014" month="December"/>
            <abstract>
              <t>This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects for modeling of the Path Computation Element Communication Protocol (PCEP) for communications between a Path Computation Client (PCC) and a Path Computation Element (PCE), or between two PCEs.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="7420"/>
          <seriesInfo name="DOI" value="10.17487/RFC7420"/>
        </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 initials="X." surname="Zhang" fullname="X. Zhang" role="editor">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="I." surname="Minei" fullname="I. Minei" role="editor">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2017" month="January"/>
            <abstract>
              <t>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="RFC8664" target="https://www.rfc-editor.org/info/rfc8664" quoteTitle="true" derivedAnchor="RFC8664">
          <front>
            <title>Path Computation Element Communication Protocol (PCEP) Extensions for Segment Routing</title>
            <author initials="S." surname="Sivabalan" fullname="S. Sivabalan">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="C." surname="Filsfils" fullname="C. Filsfils">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="J." surname="Tantsura" fullname="J. Tantsura">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="W." surname="Henderickx" fullname="W. Henderickx">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="J." surname="Hardwick" fullname="J. Hardwick">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2019" month="December"/>
            <abstract>
              <t>Segment Routing (SR) enables any head-end node to select any path without relying on a hop-by-hop signaling technique (e.g., LDP or RSVP-TE). It depends only on "segments" that are advertised by link-state Interior Gateway Protocols (IGPs). An SR path can be derived from a variety of mechanisms, including an IGP Shortest Path Tree (SPT), an explicit configuration, or a Path Computation Element (PCE). This document specifies extensions to the Path Computation Element Communication Protocol (PCEP) that allow a stateful PCE to compute and initiate Traffic-Engineering (TE) paths, as well as a Path Computation Client (PCC) to request a path subject to certain constraints and optimization criteria in SR networks.</t>
              <t>This document updates RFC 8408.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8664"/>
          <seriesInfo name="DOI" value="10.17487/RFC8664"/>
        </reference>
        <reference anchor="I-D.litkowski-pce-state-sync" quoteTitle="true" target="https://tools.ietf.org/html/draft-litkowski-pce-state-sync-07" derivedAnchor="STATE-PCE-SYNC">
          <front>
            <title>Inter Stateful Path Computation Element (PCE) Communication Procedures.</title>
            <author initials="S" surname="Litkowski" fullname="Stephane Litkowski">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="S" surname="Sivabalan" fullname="Siva Sivabalan">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="C" surname="Li" fullname="Cheng Li">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="H" surname="Zheng" fullname="Haomian Zheng">
              <organization showOnFrontPage="true"/>
            </author>
            <date month="January" day="11" year="2020"/>
            <abstract>
              <t>The Path Computation Element Communication Protocol (PCEP) provides mechanisms for Path Computation Elements (PCEs) to perform path computations in response to Path Computation Clients (PCCs) requests. The stateful PCE extensions allow stateful control of Multi-Protocol Label Switching (MPLS) Traffic Engineering Label Switched Paths (TE LSPs) using PCEP.  A Path Computation Client (PCC) can synchronize an LSP state information to a Stateful Path Computation Element (PCE).  The stateful PCE extension allows a redundancy scenario where a PCC can have redundant PCEP sessions towards multiple PCEs.  In such a case, a PCC gives control on a LSP to only a single PCE, and only one PCE is responsible for path computation for this delegated LSP.  The document does not state the procedures related to an inter-PCE stateful communication.  There are some use cases, where an inter-PCE stateful communication can bring additional resiliency in the design, for instance when some PCC-PCE sessions fails.  The inter-PCE stateful communication may also provide a faster update of the LSP states when such an event occurs.  Finally, when, in a redundant PCE scenario, there is a need to compute a set of paths that are part of a group (so there is a dependency between the paths), there may be some cases where the computation of all paths in the group is not handled by the same PCE: this situation is called a split-brain.  This split-brain scenario may lead to computation loops between PCEs or suboptimal path computation.  This document describes the procedures to allow a stateful communication between PCEs for various use-cases and also the procedures to prevent computations loops.</t>
            </abstract>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-litkowski-pce-state-sync-07"/>
          <format type="TXT" target="http://www.ietf.org/internet-drafts/draft-litkowski-pce-state-sync-07.txt"/>
          <refcontent>Work in Progress</refcontent>
        </reference>
      </references>
    </references>
    <section numbered="false" toc="include" removeInRFC="false" pn="section-appendix.a">
      <name slugifiedName="name-acknowledgments">Acknowledgments</name>
      <t pn="section-appendix.a-1">We would like to thank  <contact fullname="Jeff Tantsura"/>,  <contact fullname="Xian Zhang"/>, and  <contact fullname="Greg Mirsky"/> for
      their contributions to this document.</t>
      <t pn="section-appendix.a-2">Thanks to <contact fullname="Ines Robles"/> for the RTGDIR review.</t>
      <t pn="section-appendix.a-3">Thanks to <contact fullname="Pete Resnick"/> for the GENART review.</t>
      <t pn="section-appendix.a-4">Thanks to <contact fullname="Donald Eastlake"/> for the SECDIR review.</t>
      <t pn="section-appendix.a-5">Thanks to  <contact fullname="Barry Leiba"/>,  <contact fullname="Benjamin Kaduk"/>,  <contact fullname="Éric Vyncke"/>, and  <contact fullname="Roman Danyliw"/> for the IESG review.</t>
    </section>
    <section toc="include" numbered="false" removeInRFC="false" pn="section-appendix.b">
      <name slugifiedName="name-contributors">Contributors</name>
      <contact fullname="Dhruv Dhody" initials="D" surname="Dhody">
        <organization showOnFrontPage="true">Huawei Technologies</organization>
        <address>
          <postal>
            <street>Divyashree Techno Park, Whitefield</street>
            <city>Bangalore</city>
            <region>Karnataka</region>
            <code>560066</code>
            <country>India</country>
          </postal>
          <email>dhruv.ietf@gmail.com</email>
        </address>
      </contact>
      <contact fullname="Raveendra Torvi" initials="R" surname="Torvi">
        <organization showOnFrontPage="true">Juniper Networks</organization>
        <address>
          <postal>
            <street>1194 N Mathilda Ave</street>
            <city>Sunnyvale</city>
            <region>CA</region>
            <code>94086</code>
            <country>United States of America</country>
          </postal>
          <email>rtorvi@juniper.net</email>
        </address>
      </contact>
      <contact fullname="Edward Crabbe" initials="E" surname="Crabbe">
        <organization showOnFrontPage="true">Individual Contributor</organization>
        <address>
          <postal/>
          <email>edward.crabbe@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="Hariharan Ananthakrishnan" initials="H." surname="Ananthakrishnan">
        <organization showOnFrontPage="true">Netflix</organization>
        <address>
          <postal>
            <street/>
            <city/>
            <country>United States of America</country>
          </postal>
          <email>hari@netflix.com</email>
        </address>
      </author>
      <author fullname="Siva Sivabalan" initials="S." surname="Sivabalan">
        <organization showOnFrontPage="true">Cisco</organization>
        <address>
          <postal>
            <street>2000 Innovation Drive</street>
            <city>Kanata</city>
            <region>Ontario</region>
            <code>K2K 3E8</code>
            <country>Canada</country>
          </postal>
          <email>msiva@cisco.com</email>
        </address>
      </author>
      <author fullname="Colby Barth" initials="C." surname="Barth">
        <organization showOnFrontPage="true">Juniper Networks</organization>
        <address>
          <postal>
            <street>1194 N Mathilda Ave</street>
            <city>Sunnyvale</city>
            <region>CA</region>
            <code>94086</code>
            <country>United States of America</country>
          </postal>
          <email>cbarth@juniper.net</email>
        </address>
      </author>
      <author fullname="Ina Minei" initials="I." surname="Minei">
        <organization showOnFrontPage="true">Google, Inc</organization>
        <address>
          <postal>
            <street>1600 Amphitheatre Parkway</street>
            <city>Mountain View</city>
            <region>CA</region>
            <code>94043</code>
            <country>United States of America</country>
          </postal>
          <email>inaminei@google.com</email>
        </address>
      </author>
      <author initials="M" surname="Negi" fullname="Mahendra Singh Negi">
        <organization showOnFrontPage="true">Huawei Technologies</organization>
        <address>
          <postal>
            <street>Divyashree Techno Park, Whitefield</street>
            <city>Bangalore</city>
            <region>Karnataka</region>
            <code>560066</code>
            <country>India</country>
          </postal>
          <email>mahend.ietf@gmail.com</email>
        </address>
      </author>
    </section>
  </back>
</rfc>