<?xml version='1.0' encoding='utf-8'?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY RFC2119 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC5440 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5440.xml">
<!ENTITY RFC5541 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5541.xml">
<!ENTITY RFC8174 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml">
<!ENTITY RFC4105 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4105.xml">
<!ENTITY RFC4216 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4216.xml">
<!ENTITY RFC4655 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4655.xml">
<!ENTITY RFC4726 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4726.xml">
<!ENTITY RFC5152 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5152.xml">
<!ENTITY RFC5376 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5376.xml">
<!ENTITY RFC5394 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5394.xml">
<!ENTITY RFC5520 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5520.xml">
<!ENTITY RFC5441 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5441.xml">
<!ENTITY RFC5925 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5925.xml">
<!ENTITY RFC6805 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6805.xml">
<!ENTITY RFC7399 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7399.xml">
<!ENTITY RFC7420 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7420.xml">
<!ENTITY RFC7752 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7752.xml">
<!ENTITY RFC7897 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7897.xml">
<!ENTITY RFC8126 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8126.xml">
<!ENTITY RFC8253 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8253.xml">
<!ENTITY I-D.ietf-pce-pcep-yang SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml3/reference.I-D.draft-ietf-pce-pcep-yang-11.xml">
<!ENTITY I-D.ietf-pce-stateful-hpce SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml3/reference.I-D.draft-ietf-pce-stateful-hpce-07.xml">
<!ENTITY I-D.dhodylee-pce-pcep-ls SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml3/reference.I-D.draft-dhodylee-pce-pcep-ls-13.xml">
]> "rfc2629-xhtml.ent">

<rfc xmlns:xi="http://www.w3.org/2001/XInclude" submissionType="IETF"
     category="std" consensus="true"
     docName="draft-ietf-pce-hierarchy-extensions-11" category="std"> number="8685"
     ipr="trust200902" obsoletes="" updates="" xml:lang="en" sortRefs="false"
     symRefs="true" tocInclude="true" tocDepth="4" version="3">
  <!-- xml2rfc v2v3 conversion 2.32.0 -->
  <!-- Generated by id2xml 1.4.4 on 2019-06-26T18:42:07Z -->
	<?rfc compact="yes"?>
	<?rfc text-list-symbols="o*+-"?>
	<?rfc subcompact="no"?>
	<?rfc sortrefs="no"?>
	<?rfc symrefs="yes"?>
	<?rfc strict="yes"?>
	<?rfc toc="yes"?>
  <front>
    <title abbrev="PCEP Extensions for H-PCE">Extensions to Path H-PCE">Path Computation Element
    Communication Protocol (PCEP) for Hierarchical Extensions for&nbsp;the&nbsp;Hierarchical
    Path Computation Elements (PCE)</title> Element (H-PCE) Architecture</title>
    <seriesInfo name="RFC" value="8685"/>
    <author fullname="Fatai Zhang" initials="F." surname="Zhang">
      <organization>Huawei</organization>
	<address><postal><street>Huawei
      <address>
        <postal>
          <street>Huawei Base, Bantian, Longgang District</street>
	<street>Shenzhen  518129</street>
	<street>China</street>
          <region>Shenzhen</region>
          <code>518129</code>
          <country>China</country>
        </postal>
        <email>zhangfatai@huawei.com</email>
      </address>
    </author>
    <author fullname="Quintin Zhao" initials="Q." surname="Zhao">
      <organization>Huawei</organization>
	<address><postal><street>125
      <address>
        <postal>
          <street>125 Nagog Technology Park</street>
	<street>Acton, MA  01719</street>
	<street>USA</street>
          <city>Acton</city>
          <region>MA</region>
          <code>01719</code>
          <country>United States of America</country>
        </postal>
	<email>quintin.zhao@huawei.com</email>
        <email>quintinzhao@gmail.com</email>
      </address>
    </author>

<!-- [rfced] please review mismatch in affliation names for Oscar Gonzalez de Dios in the header and addresses sections -->
    <author fullname="Oscar Gonzalez de Dios" initials="O." surname="Gonzalez de Dios">
	<organization abbrev="Telefonica I+D">Telefonica</organization>
	<address><postal><street>Don
      <organization>Telefonica I+D</organization>
      <address>
        <postal>
          <street>Don Ramon de la Cruz 82-84</street>
	<street>Madrid  28045</street>
	<street>Spain</street>
          <city>Madrid</city>
          <code>28045</code>
          <country>Spain</country>
        </postal>
        <email>oscar.gonzalezdedios@telefonica.com</email>
      </address>
    </author>
    <author fullname="Ramon Casellas" initials="R." surname="Casellas">
      <organization>CTTC</organization>
	<address><postal><street>Av.
      <address>
        <postal>
          <street>Av. Carl Friedrich Gauss n.7</street>
	<street>Barcelona, Castelldefels</street>
	<street>Spain</street>
          <city>Castelldefels</city>
          <region>Barcelona</region>
          <country>Spain</country>
        </postal>
        <email>ramon.casellas@cttc.es</email>
      </address>
    </author>
    <author fullname="Daniel King" initials="D." surname="King">
      <organization>Old Dog Consulting</organization>
	<address><postal><street>UK</street>
      <address>
        <postal>
          <street/>
          <city/>
          <code/>
          <country>United Kingdom</country>
        </postal>
        <email>daniel@olddog.co.uk</email>
      </address>
    </author>
    <date month="June" month="December" year="2019"/>
	<workgroup>PCE Working Group</workgroup>
	<abstract><t>

<keyword>Traffic Engineering, Inter-domain, Multi-domain</keyword>

    <abstract>
      <t>
   The Hierarchical Path Computation Element (H-PCE) architecture is
   defined in RFC 6805.  It provides a mechanism to derive an optimum
   end-to-end path in a multi-domain environment by using a hierarchical
   relationship between domains to select the optimum sequence of
   domains and optimum paths across those domains.</t>
      <t>
   This document defines extensions to the Path Computation Element
   Communication Protocol (PCEP) to support Hierarchical PCE H-PCE procedures.</t>
    </abstract>
  </front>
  <middle>

<!-- [rfced] original text file has section 7.10.  NO-PATH VECTOR TLV Bit Flag in the table of contents but no corresponding section -->
    <section title="Introduction" anchor="section-1"><t> anchor="sec-1" numbered="true" toc="default">
      <name>Introduction</name>
      <t>
   The Path Computation Element communication Communication Protocol (PCEP) provides
   a mechanism for Path Computation Elements (PCEs) and Path Computation
   Clients (PCCs) to exchange requests for path computation and
   responses that provide computed paths.</t>
      <t>
   The capability to compute the routes of end-to-end inter-domain MPLS
   Traffic Engineering (MPLS-TE) and GMPLS Label Switched Paths (LSPs)
   is expressed as requirements in <xref target="RFC4105"/> target="RFC4105" format="default"/> and <xref target="RFC4216"/>. target="RFC4216" format="default"/>.  This
   capability may be realized by a PCE <xref target="RFC4655"/>. target="RFC4655" format="default"/>.  The methods for
   establishing and controlling inter-domain MPLS-TE and GMPLS LSPs are
   documented in <xref target="RFC4726"/>.</t>

	<t>
   <xref target="RFC6805"/> target="RFC4726" format="default"/>.</t>
      <t><xref target="RFC6805" format="default"/> describes a Hierarchical PCE Path Computation
   Element (H-PCE) architecture which that can be used for computing end-to-end
   paths for inter-domain MPLS Traffic
   Engineering (TE) MPLS-TE and GMPLS Label Switched Paths (LSPs).</t>

	<t>
   Within LSPs.</t>
      <t>In the hierarchical PCE H-PCE architecture, the parent PCE is used to compute a
   multi-domain path based on the domain connectivity
   information.  A child PCE may be responsible for single or multiple
   domains and is used to compute the intra-domain path based on its
   own domain topology information.</t>
      <t>
   The H-PCE end-to-end domain path computation procedure is described
   below:

	<list style="symbols"><t>A path computation client (PCC)

      </t>
      <ul spacing="normal">
        <li>A PCC sends the inter-domain path
      computation requests
    Path Computation Request (PCReq) messages <xref target="RFC5440" format="default"/> to the
    child PCE responsible for its domain;</t>

	<t>The domain.</li>
        <li>The child PCE forwards the request to the parent PCE;</t>

	<t>The PCE.</li>
        <li>The parent PCE computes the likely domain paths from the ingress
      domain to the egress domain;</t>

	<t>The domain.</li>
        <li>The parent PCE sends the intra-domain path computation requests PCReq messages
      (between the domain border nodes) to the child PCEs which that are
      responsible for the domains along the domain path;</t>

	<t>The path.</li>
        <li>The child PCEs return the intra-domain paths to the parent PCE;</t>

	<t>The PCE.</li>
        <li>The parent PCE constructs the end-to-end inter-domain path based
      on the intra-domain paths;</t>

	<t>The paths.</li>
        <li>The parent PCE returns the inter-domain path to the child PCE;</t>

	<t>The PCE.</li>
        <li>The child PCE forwards the inter-domain path to the PCC.</t>

	</list>
	</t> PCC.</li>
      </ul>
      <t>
   The parent PCE may be requested to provide only the sequence of
   domains to a child PCE so that alternative inter-domain path
   computation procedures, including Per Domain per-domain (PD) path computation
   <xref target="RFC5152"/> target="RFC5152" format="default"/> and
   Backwards Recursive Path Backward-Recursive PCE-Based Computation (BRPC)
   <xref target="RFC5441"/>, target="RFC5441" format="default"/>, may be used.</t>
      <t>
   This document defines the PCEP extensions for the purpose of
   implementing Hierarchical PCE H-PCE procedures, which are described in
   <xref target="RFC6805"/>.</t> target="RFC6805" format="default"/>.</t>
      <section title="Scope" anchor="section-1.1"><t> anchor="sec-1.1" numbered="true" toc="default">
        <name>Scope</name>
        <t>
   The following functions are out of scope of for this document:

<list style="symbols">

</t>
        <ul spacing="normal">
          <li>
            <t>Determination of Destination Domain (section 4.5 of <xref target="RFC6805"/>):
<list style="symbols">
    <t>via the destination domain (<xref target="RFC6805" sectionFormat="of" section="4.5"/>):
            </t>
            <ul spacing="normal">
              <li>via a collection of reachability information from child domain;</t>
    <t>via domains,</li>
              <li>via requests to the child PCEs to discover if they contain the
    destination node;</t>
    <t>or node, or</li>
              <li>via any other methods.</t>

	</list>
	</t> methods.</li>
            </ul>
          </li>
          <li>
            <t>Parent Traffic Engineering Database (TED) methods (section 4.4 of
      <xref target="RFC6805"/>), (<xref target="RFC6805" sectionFormat="of" section="4.4"/>), although suitable mechanisms include:<list style="symbols"><t>YANG-based include:
            </t>
            <ul spacing="normal">
              <li>YANG-based management interfaces;</t>

	<t>BGP-LS <xref target="RFC7752"/>;</t>

	<t>Future extension interfaces.</li>
              <li>BGP - Link State (BGP-LS) <xref target="RFC7752" format="default"/>.</li>
              <li>Future extensions to PCEP (such as (for example, see
        <xref target="I-D.dhodylee-pce-pcep-ls"/>).</t>

	</list>
	</t> target="I-D.dhodylee-pce-pcep-ls" format="default"/>).</li>
            </ul>
          </li>
          <li>
            <t>Learning of Domain domain connectivity and boundary nodes (BN) addresses,
      methods border node addresses.
    Methods to achieve this function include:<list style="symbols"><t>YANG-based include:
            </t>
            <ul spacing="normal">
              <li>YANG-based management interfaces;</t>

	<t>BGP-LS interfaces.</li>
              <li>BGP-LS <xref target="RFC7752"/>;</t>

	<t>Future extension target="RFC7752" format="default"/>.</li>
              <li>Future extensions to PCEP (such as (for example, see
      <xref target="I-D.dhodylee-pce-pcep-ls"/>).</t>

	</list>
	</t>

	<t>Stateful target="I-D.dhodylee-pce-pcep-ls" format="default"/>).</li>
            </ul>
          </li>
          <li>Stateful PCE Operations operations. (Refer to <xref target="I-D.ietf-pce-stateful-hpce"/>)</t> target="I-D.ietf-pce-stateful-hpce" format="default"/>.)</li>
          <li>
            <t>Applicability of hierarchical PCE the H-PCE model to large multi-domain
      environments.<list style="symbols"><t>The
    environments.
            </t>
            <ul spacing="normal">
              <li>The hierarchical relationship model is described in <xref target="RFC6805"/>. target="RFC6805" format="default"/>.  It is applicable to environments with small groups
      of domains where visibility from the ingress LSRs Label Switching Routers
      (LSRs) is limited.
  As highlighted in <xref target="RFC7399"/> target="RFC7399" format="default"/>, applying
      the hierarchical PCE H-PCE model to very large groups of domains, such as the Internet,
      is not considered feasible or desirable.</t>

	</list>
	</t>

	</list>
	</t> desirable.</li>
            </ul>
          </li>
        </ul>
      </section>
      <section title="Terminology" anchor="section-1.2"><t> anchor="sec-1.2" numbered="true" toc="default">
        <name>Terminology</name>
        <t>
   This document uses the terminology defined in <xref target="RFC4655"/>, target="RFC4655" format="default"/> and
   <xref target="RFC5440"/> target="RFC5440" format="default"/>, and the additional terms defined in Section 1.4 of
   <xref target="RFC6805"/>.</t> target="RFC6805" sectionFormat="of" section="1.4"/>.</t>
      </section>
      <section title="Requirements Language" anchor="section-1.3"><t>
   The anchor="sec-1.3" numbered="true" toc="default">
        <name>Requirements Language</name>
    <t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
    "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>",
    "<bcp14>SHALL NOT</bcp14>", "<bcp14>SHOULD</bcp14>",
    "<bcp14>SHOULD NOT</bcp14>",
    "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
    "<bcp14>MAY</bcp14>", and
   "OPTIONAL" "<bcp14>OPTIONAL</bcp14>" in this document are
    to be interpreted as described in BCP
   14 BCP&nbsp;14 <xref target="RFC2119"/>
    <xref target="RFC8174"/> when, and only when, they appear in all capitals,
    as shown here.</t>

      </section>
    </section>
    <section title="Requirements anchor="sec-2" numbered="true" toc="default">
      <name>Requirements for H-PCE" anchor="section-2"><t> the H-PCE Architecture</name>
      <t>
   This section compiles the set of requirements to for the PCEP extensions
   to support the H-PCE architecture and procedures.
   <xref target="RFC6805"/> target="RFC6805" format="default"/> identifies high-level requirements of for PCEP
   extensions that are required to support for supporting the hierarchical PCE H-PCE model.</t>
      <section title="Path anchor="sec-2.1" numbered="true" toc="default">
        <name>Path Computation Request" anchor="section-2.1"><t> Requests</name>
        <t>
   The Path Computation Request (PCReq) <xref target="RFC5440"/> PCReq messages <xref target="RFC5440" format="default"/> are used by a PCC or a PCE to make a path computation request to a PCE.  In
   order to achieve the full functionality of the H-PCE procedures, the PCReq
   message needs to include:

	<list style="symbols"><t>Qualification

        </t>
        <ul spacing="normal">
          <li>Qualification of PCE Requests (Section 4.8.1. of <xref target="RFC6805"/>);</t>

	<t>Multi-domain requests
    (<xref target="RFC6805" sectionFormat="of" section="4.8.1"/>).</li>
          <li>Multi-domain Objective Functions (OF);</t>

	<t>Multi-domain Metrics.</t>

	</list>
	</t>

	<section title="Qualification (OFs).</li>
          <li>Multi-domain metrics.</li>
        </ul>
        <section anchor="sec-2.1.1" numbered="true" toc="default">
          <name>Qualification of PCEP Requests" anchor="section-2.1.1"><t> Requests</name>
          <t>
   As described in Section 4.8.1 of <xref target="RFC6805"/>, target="RFC6805" sectionFormat="of" section="4.8.1"/>, the H-PCE
   architecture introduces new request qualifications, which are:

      <list style="symbols"><t>The are as follows:

          </t>
          <ul spacing="normal">
            <li>The ability for a child PCE to indicate that a path computation
      request
   PCReq message sent to a parent PCE should be satisfied by a
   domain sequence only, only -- that is, not by a full end-to-end path. This allows
   the child PCE to initiate a per-domain (PD) PD path computation per <xref target="RFC5152"/> target="RFC5152" format="default"/> or a
      backward recursive path computation (BRPC) BRPC procedure <xref target="RFC5441"/>.</t>

	<t>As target="RFC5441" format="default"/>.</li>
            <li>As stated in <xref target="RFC6805"/>, Section 4.5, target="RFC6805" sectionFormat="comma" section="4.5"/>, if a PCC knows
    the egress domain, it can supply this information as part of the path computation
      request. PCReq
message.  The PCC may also want to specify the destination
    domain information in a PCEP request, if it is known.</t>

	<t>An inter domain known.</li>
            <li>An inter-domain path computed by a parent PCE should be capable of
      disallowing specific domain re-entry.</t>

	</list>
	</t> re-entry into a specified domain.</li>
          </ul>
        </section>
        <section title="Multi-domain anchor="sec-2.1.2" numbered="true" toc="default">
          <name>Multi-domain Objective Functions" anchor="section-2.1.2"><t>
   For Functions</name>
          <t>For H-PCE inter-domain path computation, there are three new
   Objective Functions
    OFs defined in this document:

	<list style="symbols"><t>Minimize

          </t>
          <ul spacing="normal">
            <li>Minimize the number of Transit Domains (MTD)</t>

	<t>Minimize (MTD)</li>
            <li>Minimize the number of border nodes (MBN)</t>

	<t>Minimize Border Nodes (MBN)</li>
            <li>Minimize the number of Common Transit Domains (MCTD)</t>

	</list>
	</t> (MCTD)</li>
          </ul>
          <t>
   The PCC may specify the multi-domain Objective Function OF code to
   use when requesting inter-domain path computation, it computation. It may also
   include intra-domain OFs, such as Minimum Cost Path (MCP) <xref target="RFC5441"/>, target="RFC5541" format="default"/>, which must be considered by participating child
   PCEs.</t>
        </section>
        <section title="Multi-domain Metrics" anchor="section-2.1.3"><t> anchor="sec-2.1.3" numbered="true" toc="default">
          <name>Multi-domain Metrics</name>
          <t>
   For inter-domain path computation, there are several two path metrics of
   interest.</t>

	<t><list style="symbols"><t>Domain count
          <ul spacing="normal">
            <li>Domain Count (number of domains crossed);</t>

	<t>Border crossed).</li>
            <li>Border Node count.</t>

	</list>
	</t> Count.</li>
          </ul>
          <t>
   A PCC may be able to limit the number of domains crossed by applying
   a limit on these metrics.  Details in  See <xref target="section-3.4"/>.</t> target="sec-3.4" format="default"/> for
   details.</t>
        </section>
      </section>
      <section title="Parent anchor="sec-2.2" numbered="true" toc="default">
        <name>Parent PCE Capability Advertisement" anchor="section-2.2"><t> Advertisement</name>
        <t>
   A PCEP Speaker (Parent speaker (parent PCE or Child child PCE) that supports and wishes
   to use the procedures described in this document must advertise
   the
   this fact and negotiate its role with its PCEP peers. It does this
   using the "H-PCE Capability" TLV, as described in <xref target="section-3.2.1"/>, target="sec-3.2.1" format="default"/>, in the OPEN Object to object <xref target="RFC5440" format="default"/> to
   advertise its support for PCEP extensions for the H-PCE
   Capability.</t> capability.</t>
        <t>
   During the PCEP session establishment procedure, the child PCE needs
   to be capable of indicating to the parent PCE whether it requests the
   parent PCE capability or not.</t>
      </section>
      <section title="PCE anchor="sec-2.3" numbered="true" toc="default">
        <name>PCE Domain Identification" anchor="section-2.3"><t> Identification</name>
        <t>
   A PCE domain is a single domain with an associated PCE.  Although PCE, although it
   is possible for a PCE to manage multiple domains simultaneously.  The
   PCE domain could be an IGP area or AS.</t> Autonomous System (AS).</t>
        <t>
   The PCE domain identifiers MAY <bcp14>MAY</bcp14> be provided during the PCEP session
   establishment procedure.</t>
      </section>
      <section title="Domain Diversity" anchor="section-2.4">
<t>In anchor="sec-2.4" numbered="true" toc="default">
        <name>Domain Diversity</name>
        <t>"Domain diversity" in the context of a multi-domain environment, Domain Diversity environment
    is defined in <xref target="RFC6805"/> target="RFC6805" format="default"/> and described as "A follows:
        </t>
        <blockquote>
     A pair of paths are domain-diverse if
     they do not transit any of the same domains.  A pair of paths that
     share a common ingress and egress are domain-diverse if they only
     share the same domains at the ingress and egress (the ingress and
     egress domains).  Domain diversity may be maximized for a pair of
     paths by selecting paths that have the smallest number of shared
domains."</t>
     domains.
        </blockquote>

        <t>The main motivation behind domain diversity is to avoid fate sharing,
but it can
fate-sharing. However, domain diversity may also be because of some geo-political reasons requested to avoid
specific transit domains due to security, geopolitical, and commercial relationships that would require domain diversity. reasons.
  For
example, a pair of paths should choose different transit Autonomous
System (AS) ASes because of some
certain policy considerations.</t>

<t> In
        <t>In the case when full domain diversity could not be achieved, it is
   helpful to minimize the commonly shared domains.  Also, it is
   interesting to note that other scope of diversity domain-diversity techniques (node, link, SRLG
   Shared Risk Link Group (SRLG), etc.) can still be applied inside the
   commonly shared domains.</t>
      </section>
    </section>
    <section title="PCEP Extensions" anchor="section-3"><t> anchor="sec-3" numbered="true" toc="default">
      <name>PCEP Extensions</name>
      <t>
   This section defines extensions to PCEP <xref target="RFC5440"/> target="RFC5440" format="default"/> to support
   the H-PCE procedures.</t>
      <section title="Applicability anchor="sec-3.1" numbered="true" toc="default">
        <name>Applicability to PCC-PCE Communications" anchor="section-3.1"><t> Communications</name>
        <t>
   Although the extensions defined in this document are intended
   primarily for use between a child PCE and a parent PCE, they are
   also applicable for communications between a PCC and its PCE.</t>
        <t>
   Thus, the information that may be encoded in a PCReq can be sent
   from a PCC towards the child PCE. This includes the RP
   Request Parameters (RP) object (<xref target="section-3.3"/>) target="RFC5440" format="default"/> and <xref target="sec-3.3" format="default"/>), the Objective Function (OF) OF codes
   (<xref target="sec-3.4.1" format="default"/>), and objects the OF object
   (<xref target="section-3.4"/>). target="sec-3.4.2" format="default"/>). A PCC and a child PCE
   could also exchange the H-PCE capability (<xref target="section-3.2.1"/>) target="sec-3.2.1" format="default"/>) during
   its session.</t>
        <t>
   This allows a PCC to request paths that transit multiple
   domains utilizing the capabilities defined in this document.</t>
      </section>
      <section title="OPEN Object" anchor="section-3.2"><t>
   Two anchor="sec-3.2" numbered="true" toc="default">
        <name>OPEN Object</name>
        <t>
   This document defines two new TLVs are defined in this document  to be carried within in an
   OPEN object.  This way, during the PCEP session establishment, the
   H-PCE capability and Domain domain information can be advertised.</t>
        <section title="H-PCE Capability TLV" anchor="section-3.2.1"><t> anchor="sec-3.2.1" numbered="true" toc="default">
          <name>H-PCE-CAPABILITY TLV</name>
          <t>
   The H-PCE-CAPABILITY TLV is an optional TLV associated with the
   OPEN
   Object object <xref target="RFC5440"/> target="RFC5440" format="default"/> to exchange the H-PCE capability of
   PCEP speakers.</t>
          <t>Its format is shown in the following figure:</t>

          <figure title="H-PCE-CAPABILITY anchor="ref-h-pce-capability-tlv-format">
            <name>H-PCE-CAPABILITY TLV format" anchor="ref-h-pce-capability-tlv-format"><artwork><![CDATA[ Format</name>
            <artwork name="" type="" align="left" alt=""><![CDATA[
 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|               Type= TBD1               Type=13         |            Length=4           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                         Flags                               |P|
+---------------------------------------------------------------+ ]]></artwork>
          </figure>
	<t>
   The

          <t>The type of the TLV is TBD1 (to be assigned by IANA), 13, and it has a fixed length of
    4 octets.</t>

          <t>The value comprises a single field - -- Flags (32 bits):
	<list style="hanging" hangIndent="6"> <t hangText="P bits):</t>
<ul empty="true"><li>
          <dl newline="true" spacing="normal">
            <dt>P (Parent PCE Request bit):">if bit):</dt>
             <dd>If set, will signal that the child
    PCE wishes to use the peer PCE as a parent PCE.
	</t>

	</list>
	</t>

	<t>
   Unassigned PCE.</dd>
	  </dl></li></ul>
          <t>Unassigned bits MUST <bcp14>MUST</bcp14> be set to 0 on transmission and MUST <bcp14>MUST</bcp14> be ignored
   on receipt.</t>

	<t>
   The
          <t>The inclusion of this TLV in an OPEN object indicates that the H-PCE
   extensions are supported by the PCEP speaker.  The child PCE MUST <bcp14>MUST</bcp14>
   include this TLV and set the P flag. P-flag.  The parent PCE MUST <bcp14>MUST</bcp14> include
   this TLV and unset the P flag.</t>

	<t>
   The P-flag.</t>
          <t>The setting of the P flag (parent P-flag (Parent PCE request Request bit) would mean that
   the PCEP speaker wants the peer to be a parent PCE, so in the case
   of a PCC to Child-PCE PCC-to-child-PCE relationship, neither entity would set the P
   flag.</t>

	<t>
   If
   P-flag.</t>
          <t>If both peers attempt to set the P flag P-flag, then the session establishment MUST
   <bcp14>MUST</bcp14> fail, and the PCEP speaker MUST <bcp14>MUST</bcp14> respond with a PCErr message using
   Error-Type 1: "PCEP Session Establishment Failure" 1 (PCEP session establishment failure) as per <xref target="RFC5440"/>.</t>

	<t>
   If target="RFC5440" format="default"/>.</t>
          <t>If the PCE understands the H-PCE path computation request PCReq message but did not
   advertise its H-PCE capability, it MUST <bcp14>MUST</bcp14> send a PCErr message with
   Error-Type=TBD8 ("H-PCE error")
   Error-Type=28 (H-PCE Error) and Error-Value=1 ("H-PCE
   (H-PCE Capability not advertised").</t> advertised).</t>
          <section title="Backwards Compatibility" anchor="section-3.2.1.1"><t>
   Section 7.1 of anchor="sec-3.2.1.1" numbered="true" toc="default">
            <name>Backwards Compatibility</name>
            <t>
   <xref target="RFC5440"/> requires that target="RFC5440" sectionFormat="of" section="7.1"/> specifies the following
   requirement: "Unrecognized TLVs MUST <bcp14>MUST</bcp14> be ignored.</t>

	<t>
   That means that a ignored."</t>
            <t>The OPEN object <xref target="RFC5440" format="default"/> contains the necessary PCEP
    information between the PCE entities, including session information and PCE
    capabilities via TLVs (including if H-PCE is supported). If the PCE that does
    not support this document but that receives an Open Message message containing an Open Object OPEN
    object that includes an H-PCE-CAPABILITIES TLV H-PCE-CAPABILITY TLV, it will ignore that TLV
    and will continue to attempt to establish a PCEP session. It will, however,
 However, it will not include
   the TLV in the Open message that it sends, so the H-PCE relationship
   will not be created.</t>
            <t>
   If a PCE does not support the extensions defined in this document but
   receives them in a PCEP message (notwithstanding the fact that the
   session was not established as supporting a an H-PCE relationship), the
   receiving PCE will ignore the H-PCE related parameters because they
   are all encoded in TLVs within in standard PCEP objects.</t>
          </section>
        </section>
        <section title="Domain-ID TLV" anchor="section-3.2.2"><t> anchor="sec-3.2.2" numbered="true" toc="default">
          <name>Domain-ID TLV</name>
          <t>
   The Domain-ID TLV, when used in the OPEN object, identifies the
   domains served by the PCE.  The child PCE uses this mechanism to
   inform
   provide the domain information to the parent PCE.</t>
          <t>The Domain-ID TLV is defined below:</t>
          <figure title="Domain-ID anchor="ref-domain-id-tlv-format">
            <name>Domain-ID TLV format" anchor="ref-domain-id-tlv-format"><artwork><![CDATA[ Format</name>
            <artwork name="" type="" align="left" alt=""><![CDATA[
 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|               Type= TBD2               Type=14         |            Length             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Domain Type   |                  Reserved                     |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
//                          Domain ID                          //
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ]]></artwork>
          </figure>
          <t>
   The type of the TLV is TBD2 (to be assigned by IANA), 14, and it has a variable Length of the value
   portion.  The value part comprises:

<list style="hanging">

      <t hangText="Domain comprises the following:

</t>
<ul empty="true"><li><dl newline="false" spacing="normal">
            <dt>Domain Type (8 bits):">Indicates bits):</dt>
             <dd><t>Indicates the domain type.  Four
         types of domain domains are currently defined:

<list style="hanging" hangIndent="9">

      <t hangText="Type=1:">the defined:</t>
             <dl newline="false" spacing="normal" indent="10">
                <dt>Type=1:</dt>
                 <dd>The Domain ID field carries a 2-byte AS number.
      Padded with trailing zeros to a 4-byte boundary. </t>

      <t hangText="Type=2:">the boundary.</dd>
                <dt>Type=2:</dt>
                 <dd>The Domain ID field carries a 4-byte AS
number. </t>

      <t hangText="Type=3:">the number.</dd>
                <dt>Type=3:</dt>
                 <dd>The Domain ID field carries a 4-byte OSPF area
ID. </t>

      <t hangText="Type=4:">the ID.</dd>
                <dt>Type=4:</dt>
                 <dd>The Domain ID field carries (2-byte Area-Len,
              variable length a 2-byte Area-Len and a
               variable-length IS-IS area ID). ID.  Padded with trailing zeros to
              a4-byte boundary. </t>
</list> </t>

   <t hangText="Reserved:">Zero
               a 4-byte boundary.</dd>
            </dl>
	     </dd>
          <dt>Reserved:</dt>
           <dd>Zero at transmission; ignored at the receipt. </t>

   <t hangText="Domain on receipt.</dd>
          <dt>Domain ID (variable):">Indicates (variable):</dt>
           <dd>Indicates an IGP Area area ID or AS number as
      per the Domain Type field.  It can be 2 bytes, 4 bytes bytes, or
      variable length length, depending on the domain identifier used.  It is
      padded with trailing zeros to a 4-byte boundary.  In the case of
         IS-IS
      IS-IS, it includes the Area-Len as well.</t>

</list>
</t>

	<t>
   In well.</dd>
  </dl></li></ul>
          <t>In the case where a PCE serves more than one domain, multiple
    Domain-ID TLVs are included for each domain it serves.</t>
        </section>
      </section>
      <section title="RP Object" anchor="section-3.3"><section title="H-PCE-FLAG TLV" anchor="section-3.3.1"><t> anchor="sec-3.3" numbered="true" toc="default">
        <name>RP Object</name>
        <section anchor="sec-3.3.1" numbered="true" toc="default">
          <name>H-PCE-FLAG TLV</name>
          <t>
   The H-PCE-FLAG TLV is an optional TLV associated with the RP Object object
   <xref target="RFC5440"/> target="RFC5440" format="default"/> to indicate the H-PCE path computation request PCReq message and
   options.</t>
          <t>Its format is shown in the following figure:</t>
          <figure title="H-PCE-FLAG anchor="ref-h-pce-flag-tlv-format">
            <name>H-PCE-FLAG TLV format" anchor="ref-h-pce-flag-tlv-format"><artwork><![CDATA[ Format</name>
            <artwork name="" type="" align="left" alt=""><![CDATA[
 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|               Type= TBD3               Type=15         |             Length=4          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                         Flags                             |D|S|
+---------------------------------------------------------------+ ]]></artwork>
          </figure>
          <t>
   The type of the TLV is TBD3 (to be assigned by IANA), 15, and it has a fixed length of 4 octets.</t>
          <t> The value comprises a single field - -- Flags (32 bits):

<list style="hanging">
<t hangText="S (Domain Sequence bit):">if set, will signal that the child PCE
      wishes to get only the domain sequence in the path computation
      reply.  Refer to Section 3.7 of <xref target="RFC7897"/> for details. </t>

<t hangText="D (Disallow Domain Re-entry bit):"> if
</t>
<ul empty="true"><li>
          <dl newline="true" spacing="normal">
            <dt>D (Disallow Domain Re-entry bit):</dt>
             <dd>If set, will signal that the
   computed path does not enter a domain more than once.</t>
</list></t> once.</dd>
            <dt>S (Domain Sequence bit):</dt>
             <dd>If set, will signal that the child PCE
   wishes to get only the domain sequence in the
   Path Computation Reply (PCRep) message <xref target="RFC5440" format="default"/>.  Refer to
   <xref target="RFC7897" sectionFormat="of" section="3.7"/> for details.</dd>
	  </dl></li></ul>
          <t> Unassigned bits MUST <bcp14>MUST</bcp14> be set to 0 on transmission and MUST <bcp14>MUST</bcp14> be ignored
   on receipt.</t>
          <t>
   The presence of the TLV indicates that the H-PCE based H-PCE-based path
   computation is requested as per this document.</t>
        </section>
        <section title="Domain-ID TLV" anchor="section-3.3.2"><t> anchor="sec-3.3.2" numbered="true" toc="default">
          <name>Domain-ID TLV</name>
          <t>
   The Domain-ID TLV, carried in an OPEN object, is used to indicate a
   (list of)
   managed domains domain (or a list of managed domains) and is described in <xref target="section-3.3.1"/>. target="sec-3.2.2" format="default"/>. This TLV, when carried in an RP object,
   indicates the destination domain ID. If a PCC knows the egress domain, it
   can supply this information in the PCReq message.  The  <xref target="sec-3.2.2" format="default"/> also defines the format and procedure of for this TLV are
   defined in <xref target="section-3.2.2"/>.</t> and the
   procedure for using it.</t>
          <t>If a Domain-id Domain-ID TLV is used in the RP object, object and the destination is
   not actually in the indicated domain, then the parent PCE should
   respond with a NO-PATH object and NO-PATH VECTOR the NO-PATH-VECTOR TLV should be used.
   A new bit number is assigned to indicate "Destination is not found in the
   indicated domain" (see Section 3.7).</t> <xref target="sec-3.8" format="default"/>).</t>
        </section>
      </section>
      <section title="Objective Functions" anchor="section-3.4"><section title="OF Codes" anchor="section-3.4.1"><t>
   <xref target="RFC5541"/> anchor="sec-3.4" numbered="true" toc="default">
        <name>Objective Functions</name>
        <section anchor="sec-3.4.1" numbered="true" toc="default">
          <name>OF Codes</name>
          <t><xref target="RFC5541" format="default"/> defines a mechanism to specify an Objective Function
   OF that is used by a PCE when it computes a path.
   Three new Objective
   Functions OFs are defined for H-PCE, the H-PCE model; these are:

<list style="symbols">

<t> "MTD"

<list style="symbols">
      <t>Name: Minimize are:</t>

<ul spacing="normal">
    <li>
      <t>MTD</t>
<dl spacing="normal">
<dt>Name:</dt><dd>Minimize the number of Transit Domains (MTD)</t>

      <t>Objective Function Code - TBD4 (to be assigned by IANA)</t>

      <t>Description: Find (MTD)</dd>
<dt>OF code:</dt><dd>12</dd>
<dt>Description:</dt><dd>Find a path P such that it passes through the least
number of transit domains.</t>

      <t>Objective functions domains.</dd>
</dl>

  <ul>
      <li>
       <t>OFs are formulated using the following
         terminology:

<list style="symbols">
         <t>A
       terminology:</t>
          <ul spacing="normal">
          <li>A network comprises a set of N domains {Di, (i=1...N)}.</t>

         <t>A (i=1...N)}.</li>
          <li>A path P passes through K unique domains {Dpi,(i=1...K)}.</t>

         <t>Find {Dpi, (i=1...K)}.</li>
          <li>Find a path P such that the value of K is minimized.</t>

</list>
</t>
</list>
</t>

<t>  MBN

<list style="symbols">

      <t>Name: Minimize minimized.</li>
          </ul>
        </li>
    </ul>
    </li>
   </ul>

<ul spacing="normal">
       <li>
         <t>MBN</t>
<dl spacing="normal">
<dt>Name:</dt><dd>Minimize the number of border nodes.</t>

      <t>Objective Function Code - TBD5 (to be assigned by IANA)</t>

      <t>Description: Find Border Nodes (MBN)</dd>
<dt>OF code:</dt><dd>13</dd>
<dt>Description:</dt><dd>Find a path P such that it passes through the least
number of border nodes.</t>

      <t>Objective functions nodes.</dd>
</dl>
  <ul>
     <li>
        <t>OFs are formulated using the following
         terminology:

<list style="symbols">

         <t>A terminology:</t>
          <ul spacing="normal">
           <li>A network comprises a set of N links {Li, (i=1...N)}.</t>

         <t>A (i=1...N)}.</li>
           <li>A path P is a list of K links {Lpi,(i=1...K)}.</t>

         <t>D(Lpi) if {Lpi, (i=1...K)}.</li>
           <li>D(Lpi) is a function that determines if the links Lpi and
           Lpi+1 belong to different domains, domains. D(Li) = 1 if link Li and
           Li+1 belong to different domains, domains; D(Lk) = 0 if link Lk and
           Lk+1 belong to the same domain.</t>

         <t>The domain.</li>
           <li>The number of border node nodes in a path P is denoted by B(P),
           where B(P) = sum{D(Lpi),(i=1...K-1)}.</t>

 <t>Find sum{D(Lpi), (i=1...K-1)}.</li>
           <li>Find a path P such that B(P) is minimized.</t>
</list>
</t>
</list>
</t>
</list>
</t>

	<t>
   There minimized.</li>
          </ul>
     </li>
    </ul>
       </li>
   </ul>

  <t>There is one objective function OF that applies to a set of
   synchronized path computation requests PCReq messages to increase the domain diversity:

	<list style="symbols"><t>MCTD<list style="symbols"><t>Name: Minimize
          </t>
  <ul spacing="normal">
        <li>
          <t>MCTD</t>
<dl spacing="normal">
<dt>Name:</dt><dd>Minimize the number of Common Transit Domains</t>

	<t>Objective Function Code - TBD13 (to be assigned by IANA)</t>

	<t>Description: Find Domains (MCTD)</dd>
<dt>OF code:</dt><dd>14</dd>
<dt>Description:</dt><dd>Find a set of paths such that it passes through the
least number of common transit domains.<list style="symbols"><t>A domains.</dd>
</dl>
                  <ul spacing="normal">
                    <li>A network comprises a set of N domains {Di, (i=1...N)}.</t>

	<t>A (i=1...N)}.</li>
                    <li>A path P passes through K unique domains {Dpi,(i=1...K)}.</t>

	<t>A {Dpi, (i=1...K)}.</li>
                    <li>A set of paths {P1...Pm} have has L transit domains that are
       common to more than one path {Dpi,(i=1...L)}.</t>

	<t>Find {Dpi, (i=1...L)}.</li>
                    <li>Find a set of paths such that the value of L is minimized.</t>

	</list>
	</t>

	</list>
	</t>

	</list>
	</t> minimized.</li>
                  </ul>
                </li>
              </ul>
        </section>
        <section title="OF Object" anchor="section-3.4.2"><t> anchor="sec-3.4.2" numbered="true" toc="default">
          <name>OF Object</name>
          <t>
   The OF (Objective Function) object <xref target="RFC5541"/> target="RFC5541" format="default"/> is carried within in a
   PCReq message so as to indicate the desired/required objective
   function OF
   to be applied by the PCE during path computation.  As per
   Section 3.2 of
   <xref target="RFC5541"/> target="RFC5541" sectionFormat="of" section="3.2"/>, a single OF object may be
   included in a path
   computation request.</t>

	<t>
   The PCReq message.</t>
          <t>The new OF codes described in <xref target="section-3.4.1"/> target="sec-3.4.1" format="default"/> are
   applicable at to the inter-domain path computation performed by the parent PCE, it
   PCE. It is also necessary to specify the OF code that may be applied for the
   intra-domain path computation performed by the child PCE.  To
   accommodate this, the OF-List TLV (described in Section 2.1. of <xref target="RFC5541"/>) target="RFC5541" sectionFormat="of" section="2.1"/>) is included in the OF object as an
   optional TLV.</t>

	<t>
   The
          <t>The OF-List TLV allows the encoding of multiple OF codes.  When this TLV
   is included inside the OF object, only the first OF-code OF code in the
   OF-LIST
   OF-List TLV is considered.  The parent PCE MUST <bcp14>MUST</bcp14> use this OF code in
   the OF object when sending the intra domain path computation request intra-domain PCReq message
   to the child PCE. If the OF list OF-List TLV is included in the OF Object, object,
   the OF Code code inside the OF Object MUST object <bcp14>MUST</bcp14> include one of the H-PCE
   Objective Functions
   OFs defined in this document, the document. The OF Code code inside the
   OF List
   OF-List TLV MUST NOT <bcp14>MUST NOT</bcp14> include an H-PCE Objective Function. OF. If this
   condition is not met, the PCEP speaker MUST <bcp14>MUST</bcp14> respond with a PCErr
   message with Error-Type=10 (Reception of an invalid object) and
   Error-Value=TBD15
   Error-Value=23 (Incompatible OF codes in H-PCE).</t>

	<t>
   If
          <t>If the Objective Functions OFs defined in this document are unknown or
   unsupported by a PCE, then the procedure as defined in <xref target="RFC5541"/> target="RFC5440" format="default"/> is followed.</t>
        </section>
      </section>
      <section title="Metric Object" anchor="section-3.5"><t> anchor="sec-3.5" numbered="true" toc="default">
        <name>METRIC Object</name>
        <t>
   The METRIC object is defined in Section 7.8 of <xref target="RFC5440"/>, comprising target="RFC5440" sectionFormat="of" section="7.8"/>
   and is comprised of metric-value, metric-type (T field) the metric-value field, the metric type (the T field),
   and flags. flags (the Flags field).  This document defines the following types for
   the METRIC object for H-PCE:

<list style="symbols">
<t>T=TBD6: Domain count the H-PCE model:

        </t>
<ul empty="true"><li>
        <dl newline="false" spacing="normal">
          <dt>T=20:</dt>
           <dd>Domain Count metric (number of domains crossed);</t>
<t>T=TBD7: Border crossed).</dd>
           <dt>T=21:</dt>
            <dd>Border Node count Count metric (number of border nodes crossed).</t>
	</list>
	</t>

	<t>
   The domain count crossed).</dd>
	</dl></li></ul>
        <t>The Domain Count metric type of the METRIC object encodes the number
   of domains crossed in the path.  The border node count Border Node Count metric type of
   the METRIC object encodes the number of border nodes in the path. If
   a domain is re-entered, then the domain should be double counted.</t>

	<t>
   A
        <t>A PCC or child PCE MAY <bcp14>MAY</bcp14> use the metric in a PCReq message for an
   inter-domain path computation, meeting the requirement for the number of domain
   domains or border nodes crossing requirement. being crossed. As per <xref target="RFC5440"/>, target="RFC5440" format="default"/>, in
   this case, the B bit B-bit is set to suggest a bound (a maximum) for the
   metric that must not be exceeded for the PCC to consider the computed path as
   acceptable.</t>

	<t>
   A
        <t>A PCC or child PCE MAY <bcp14>MAY</bcp14> also use this metric to ask the PCE to
   optimize the metric during inter-domain path computation.  In this
   case, the B flag B-flag is cleared, and the C flag C-flag is set.</t>

	<t>
   The Parent
        <t>The parent PCE MAY <bcp14>MAY</bcp14> use the metric in a PCRep message along with a
   NO-PATH object in the case where the PCE cannot compute a path
   meeting that
   meets this constraint.  A PCE MAY <bcp14>MAY</bcp14> also use this metric to send the computed end to end
   end-to-end metric value in a reply message.</t>
      </section>
      <section title="SVEC Object" anchor="section-3.6"><t> anchor="sec-3.6" numbered="true" toc="default">
        <name>SVEC Object</name>
        <t>
   <xref target="RFC5440"/> target="RFC5440" format="default"/> defines SVEC object the Synchronization Vector (SVEC) object,
   which includes flags for the potential dependency between the set of path computation requests
   PCReq messages (Link, Node Node, and SRLG diverse).  This document defines
   a new flag O (the O-bit) for domain diversity.</t>

	<t>
   The
        <t>The following new bit is added to the Flags field:

	<list style="hanging" hangIndent="3"><t hangText="Domain

        </t>
<ul empty="true"><li>
        <dl newline="true" spacing="normal">
          <dt>Domain Diverse O-bit-TBD14:"> when O-bit - 18:</dt>
           <dd>When set, this indicates that the
     computed paths corresponding to the requests specified by the following
     any RP objects MUST NOT that might be provided <bcp14>MUST NOT</bcp14> have any transit domains in common.</t>

	</list>
	</t>

	<t>
   The common.</dd>
	</dl></li></ul>
        <t>The Domain Diverse O-bit can be used in Hierarchical PCE H-PCE path
   computation to compute synchronized domain diverse end to end path domain-diverse end-to-end
   paths or diverse domain sequences.</t>

	<t>
   When domain diverse O bit
        <t>When the Domain Diverse O-bit is set, it is applied to the transit
   domains.  The other bit in SVEC object (N, L, L (Link diverse),
   N (Node diverse), S etc.) MAY (SRLG diverse), etc.&nbsp;<bcp14>MAY</bcp14> be set
   and
   MUST <bcp14>MUST</bcp14> still be applied in the ingress and egress shared domain.</t>
      </section>
      <section title="PCEP-ERROR Object" anchor="section-3.7"><section title="Hierarchy anchor="sec-3.7" numbered="true" toc="default">
        <name>PCEP-ERROR Object</name>
        <section anchor="sec-3.7.1" numbered="true" toc="default">
          <name>Hierarchical PCE Error-Type" anchor="section-3.7.1"><t>
   A Error-Type</name>
          <t>A new PCEP Error-Type <xref target="RFC5440"/> target="RFC5440" format="default"/> is used for the H-PCE
   extension as defined below:</t>

	<figure title="H-PCE error" anchor="ref-h-pce-error"><artwork><![CDATA[
 +------------+-----------------------------------------+
 | Error-Type | Meaning                                 |
 +------------+-----------------------------------------+
 | TBD8       | H-PCE error                             |
 |            | Error-value=1:

<table anchor="tab-1">
  <name>H-PCE Error</name>
  <thead>
    <tr>
      <th>Error-Type</th>
      <th>Meaning</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td align='left'>28</td>
<td align='left'> <ul empty="true" spacing="compact" indent="0">
 <li><t>H-PCE Error</t>
 <t>Error-Value=1: H-PCE capability         |
 |            | was not advertised                      |
 |            | Error-value=2: parent Capability</t>
 <t>not advertised</t>
 <t>Error-Value=2: Parent PCE capability    |
 |            | cannot Capability</t>
 <t>cannot be provided                      |
 +------------+-----------------------------------------+
]]></artwork>
	</figure> provided</t></li>
 </ul>
</td>
    </tr>
  </tbody>
</table>

        </section>
      </section>
      <section title="NO-PATH Object" anchor="section-3.8"><t> anchor="sec-3.8" numbered="true" toc="default">
        <name>NO-PATH Object</name>
        <t>
   To communicate the reason(s) for not being able to find a multi-domain
   path or domain sequence, the NO-PATH object can be used in the PCRep
   message.  <xref target="RFC5440"/> target="RFC5440" format="default"/> defines the format of the NO-PATH
   object.  The object may contain a NO-PATH-VECTOR TLV to provide additional
   information about why a path computation has failed.</t>
        <t>
   Three
   This document defines four new bit flags in the "NO-PATH-VECTOR TLV Flag
   Field" subregistry.  These flags are defined to be carried in the Flags field
   in the NO-PATH-VECTOR TLV carried in the NO-PATH Object.

   <list style="hanging">

     <t hangText="Bit object.
        </t>

<ul empty="true"><li>
        <dl newline="false" spacing="normal" indent="15">
   <dt>Bit number TBD9:">When 22:</dt>
           <dd>When set, the parent PCE indicates that the
     destination domain unknown;</t>

<t hangText="Bit is unknown.</dd>
          <dt>Bit number TBD10:">When 21:</dt>
           <dd>When set, the parent PCE indicates unresponsive that one or more
     child PCE(s);</t>

<t hangText="Bit PCEs are unresponsive.</dd>
          <dt>Bit number TBD11:"> When 20:</dt>
           <dd>When set, the parent PCE indicates that no
available
      resource
     resources are available in one or more domains.</t>

<t hangText="Bit domains.</dd>
          <dt>Bit number TBD12:"> When 19:</dt>
           <dd>When set, the parent PCE indicates that
     the destination is not found in the indicated domain.</t>

</list>
</t> domain.</dd>
	</dl></li></ul>
      </section>
    </section>
    <section title="H-PCE Procedures" anchor="section-4"><t>
The anchor="sec-4" numbered="true" toc="default">
      <name>H-PCE Procedures</name>
      <t>The H-PCE path computation procedure is described in <xref target="RFC6805"/>.</t> target="RFC6805" format="default"/>.</t>
      <section title="OPEN anchor="sec-4.1" numbered="true" toc="default">
        <name>OPEN Procedure between Child PCE and Parent PCE" anchor="section-4.1"><t>
   If PCE</name>
        <t>If a child PCE wants to use the peer PCE as a parent, it MUST <bcp14>MUST</bcp14> set the
   P (parent
   P-flag (Parent PCE request Request flag) in the H-PCE-CAPABILITY TLV inside the
   OPEN object carried in the Open message during the PCEP session
   initialization procedure.</t>

	<t>
   The
        <t>The child PCE MAY <bcp14>MAY</bcp14> also report its list of domain IDs, IDs to the parent
   PCE,
   PCE by specifying them in the Domain-ID TLVs in the OPEN object.
   This object is carried in the OPEN Open message during the PCEP session
   initialization procedure</t>

	<t>
   The procedure.</t>
        <t>The OF codes defined in this document can be carried in the OF-list OF-List
   TLV of the OPEN object.  If the OF-list OF-List TLV carries the OF codes, it
   means that the PCE is capable of implementing the corresponding
   objective functions.
   OFs.  This information can be used for selecting a
   proper parent PCE when a child PCE wants to get a path that satisfies
   a certain Objective Function.</t>

	<t>
   When OF.</t>
        <t>When a child PCE sends a PCReq to a peer PCE, which PCE that requires parental
 activity and H-PCE capability flags the H-PCE-CAPABILITY TLV but which these items were not included
 taken into account in the session establishment procedure described
 above, the peer PCE
   SHOULD <bcp14>SHOULD</bcp14> send a PCErr message to the child PCE and MUST
 <bcp14>MUST</bcp14> specify the
   error-type=TBD8 Error-Type=28 (H-PCE error) Error) and error-value=1 Error-Value=1
 (H-PCE capability was Capability not advertised) in the PCEP-ERROR object.</t>

	<t>
   When
        <t>When a specific child PCE sends a PCReq to a peer PCE, PCE that requires
   parental activity and the peer PCE does not want to act as the parent
   for it, the peer PCE SHOULD <bcp14>SHOULD</bcp14> send a PCErr message to the child PCE and
   MUST
   <bcp14>MUST</bcp14> specify the error-type=TBD8 Error-Type=28 (H-PCE error) Error) and error-value=2 Error-Value=2
   (Parent PCE capability Capability cannot be provided) in the PCEP-ERROR object.</t>
      </section>
      <section title="Procedure to Obtain anchor="sec-4.2" numbered="true" toc="default">
        <name>Procedure for Obtaining the Domain Sequence" anchor="section-4.2"><t>
   If Sequence</name>
        <t>If a child PCE only wants to get the domain sequence for a
   multi-domain path computation from a parent PCE, it can set the Domain
   Path Request bit in the H-PCE-FLAG TLV in the RP object carried in a PCReq
   message. The parent PCE which that receives the PCReq message tries to compute
   a domain sequence for it (instead of the E2E end-to-end path). If the domain
   path computation succeeds succeeds, the parent PCE sends a PCRep message
   which that
   carries the domain sequence in the Explicit Route Object (ERO) to the child
   PCE. Refer to <xref target="RFC7897"/> target="RFC7897" format="default"/> for more details about domain
   sub-objects
   subobjects in the ERO. Otherwise, it sends a PCReq message which that carries
   the NO-PATH object to the child PCE.</t>
      </section>
    </section>
    <section title="Error Handling" anchor="section-5"><t>
   A anchor="sec-5" numbered="true" toc="default">
      <name>Error Handling</name>
      <t>A PCE that is capable of acting as a parent PCE might not be
   configured or willing to act as the parent for a specific child PCE.
   This fact could be determined when
   When the child PCE sends a PCReq that requires parental activity, and could result in
   a negative response in the form of a PCEP Error (PCErr) message and indicate the hierarchy PCE error-type=TBD8
   that includes H-PCE Error-Type=28 (H-PCE error) Error) and suitable error-value.
   an applicable Error-Value (<xref target="section-3.7"/>)</t>

	<t>
   Additionally, target="sec-3.7" format="default"/>) might result.
      </t>
      <t>Additionally, the parent PCE may fail to find the multi-domain path
   or domain sequence due to for one or more of the following reasons:

	<list style="symbols"><t>A

      </t>
      <ul spacing="normal">
        <li>A child PCE cannot find a suitable path to the egress;</t>

	<t>The
    egress.</li>
        <li>The parent PCE does not hear from a child PCE for a specified
      time;</t>

	<t>The Objective Functions
      time.</li>
        <li>The OFs specified in the path request cannot
    be
      met.</t>

	</list>
	</t>

	<t>
   In met.</li>
      </ul>
      <t>In this case, the parent PCE MAY <bcp14>MAY</bcp14> need to send a negative path
   computation reply PCRep message
   specifying the reason. reason for the failure.  This can be
   achieved by including the NO-PATH object in the PCRep message.  Extension
   An extension to the NO-PATH object is needed in order to include the aforementioned
   reasons described defined in <xref target="section-3.7"/>.</t> target="sec-3.8" format="default"/>.</t>
    </section>
    <section title="Manageability Considerations" anchor="section-6"><t> anchor="sec-6" numbered="true" toc="default">
      <name>Manageability Considerations</name>
      <t>
   General PCE and PCEP management management/manageability considerations are discussed
   in <xref target="RFC4655"/> target="RFC4655" format="default"/> and <xref target="RFC5440"/>. target="RFC5440" format="default"/>.  There are
   additional management considerations for the H-PCE which model; these are
   described in <xref target="RFC6805"/>, target="RFC6805" format="default"/> and repeated in this section.</t>
      <t>
   The administrative entity responsible for the management of the
   parent PCEs must be determined for the following cases:

	<list style="symbols"><t>multi-domains

      </t>
      <ul spacing="normal">
        <li>Multiple domains (e.g., IGP areas or multiple
    ASes) within in a single service provider network, the network. The management responsibility
    for the parent PCE would most likely be handled by the service provider,</t>

	<t>multiple
    provider.</li>
        <li>Multiple ASes within in different service provider networks, it networks. It may
      be necessary for a third party to manage the parent PCEs according
      to commercial and policy agreements from each of the participating
      service providers.</t>

	</list>
	</t> providers.</li>
      </ul>
      <section title="Control anchor="sec-6.1" numbered="true" toc="default">
        <name>Control of Function and Policy" anchor="section-6.1"><t>
   Control and function Policy</name>
        <t>Control of H-PCE function will need to be carefully managed in an H-PCE
   network. via
   configuration and interaction policies, which may be controlled via a policy
   module on the H-PCE. A child PCE will need to be configured with the
   address of its parent PCE.  It is expected that there will only be one or
   two parents of any child.</t>
        <t>
   The parent PCE also needs to be aware of the child PCEs for all child
   domains that it can see.  This information is most likely to be
   configured (as part of the administrative definition of each domain).</t>
        <t>
   Discovery of the relationships between parent PCEs and child PCEs
   do
   does not form part of the hierarchical PCE H-PCE architecture.  Mechanisms
   that rely on advertising or querying PCE locations across domain or
   provider boundaries are undesirable for security, scaling,
   commercial, and confidentiality reasons.  The specific behaviour behavior of
   the child and parent PCE are PCEs is described in the following sub-sections.</t> subsections.</t>
        <section title="Child PCE" anchor="section-6.1.1"><t> anchor="sec-6.1.1" numbered="true" toc="default">
          <name>Child PCE</name>
          <t>
   Support of the hierarchical procedure will be controlled by the
   management organization responsible for each child PCE.  A child PCE
   must be configured with the address of its parent PCE in order for it
   to interact with its parent PCE.  The child PCE must also be
   authorized to peer with the parent PCE.</t>
        </section>
        <section title="Parent PCE" anchor="section-6.1.2"><t> anchor="sec-6.1.2" numbered="true" toc="default">
          <name>Parent PCE</name>
          <t>
   The parent PCE MUST <bcp14>MUST</bcp14> only accept path computation requests PCReq messages from
   authorized child PCEs.  If a parent PCE receives requests from an
   unauthorized child PCE, the request SHOULD <bcp14>SHOULD</bcp14> be dropped.  This means
   that a parent PCE MUST <bcp14>MUST</bcp14> be able to cryptographically authenticate
   requests from child PCEs.</t>

	<t>
   Multi-party
          <t>Multi-party shared key authentication schemes are not recommended for
   inter-domain relationships because of (1) the potential for
   impersonation and repudiation and for the (2) operational difficulties should
   revocation be required.</t>

	<t>
   The
          <t>The choice of authentication schemes to employ may be left to
   implementers of the H-PCE architecture and are not discussed further in
   this document.</t>
        </section>
        <section title="Policy Control" anchor="section-6.1.3"><t>
   It anchor="sec-6.1.3" numbered="true" toc="default">
          <name>Policy Control</name>
          <t>It may be necessary to maintain H-PCE policy <xref target="RFC5394" format="default"/>
   via a policy control module on the parent PCE
   <xref target="RFC5394"/>. PCE.
   This would allow the parent PCE to apply
   commercially relevant constraints such as SLAs, security, peering
   preferences, and monetary costs.</t>
          <t>
   It may also be necessary for the parent PCE to limit the
   end-to-end path selection by including or excluding specific domains
   based on commercial relationships, security implications, and
   reliability.</t>
        </section>
      </section>
      <section title="Information anchor="sec-6.2" numbered="true" toc="default">
        <name>Information and Data Models" anchor="section-6.2"><t>
   A Models</name>
        <t><xref target="RFC7420" format="default"/> provides a MIB module for PCEP was published as RFC 7420 <xref target="RFC7420"/> that and describes
   managed objects for modelling the modeling of PCEP communication.  A
   YANG module for PCEP has also been proposed <xref target="I-D.ietf-pce-pcep-yang"/>.</t>

	<t>
   Additionally, target="PCEP-YANG" format="default"/>.</t>
        <t>An H-PCE MIB module, module or an additional data model, model will also be
   required to report for reporting parent PCE and child PCE information, including:

	<list style="symbols"><t>parent

        </t>
        <ul spacing="normal">
          <li>parent PCE configuration and status,</t>

	<t>child status,</li>
          <li>child PCE configuration and information,</t>

	<t>notifications information,</li>
          <li>notifications to indicate session changes between parent PCEs and
      child PCEs, and</t>

	<t>notification and</li>
          <li>notification of parent PCE TED updates and changes.</t>

	</list>
	</t> changes.</li>
        </ul>
      </section>
      <section title="Liveness anchor="sec-6.3" numbered="true" toc="default">
        <name>Liveness Detection and Monitoring" anchor="section-6.3"><t>
   The Monitoring</name>
        <t>The hierarchical procedure requires interaction with multiple PCEs.
   Once a child PCE requests an end-to-end path, a sequence of events
   occurs that requires interaction between the parent PCE and each
   child PCE.  If a child PCE is not operational, operational and an alternate
   transit domain is not available, then the failure must be reported.</t>
      </section>
      <section title="Verify anchor="sec-6.4" numbered="true" toc="default">
        <name>Verifying Correct Operations" anchor="section-6.4"><t> Operations</name>
        <t>
   Verifying the correct operation of a parent PCE can be performed by
   monitoring a set of parameters.  The parent PCE implementation should
   provide the following parameters monitored at the parent PCE:

	<list style="symbols"><t>number

        </t>
        <ul spacing="normal">
          <li>number of child PCE requests,</t>

	<t>number requests,</li>
          <li>number of successful hierarchical PCE procedures H-PCE procedure completions on a
      per-PCE-peer basis,</t>

	<t>number basis,</li>
          <li>number of hierarchical PCE procedure completion H-PCE procedure-completion failures on a per-PCE-peer basis, and</t>

	<t>number
    and</li>
          <li>number of hierarchical PCE H-PCE procedure requests from unauthorized child PCEs.</t>

	</list>
	</t> PCEs.</li>
        </ul>
      </section>
      <section title="Requirements On anchor="sec-6.5" numbered="true" toc="default">
        <name>Requirements on Other Protocols" anchor="section-6.5"><t> Protocols</name>
        <t>
   Mechanisms defined in this document do not imply any new requirements
   on other protocols.</t>
      </section>
      <section title="Impact On anchor="sec-6.6" numbered="true" toc="default">
        <name>Impact on Network Operations" anchor="section-6.6"><t> Operations</name>
        <t>
   The hierarchical PCE H-PCE procedure is a multiple-PCE path computation
   scheme.  Subsequent requests to and from the child and parent PCEs do
   not differ from other path computation requests and should not have
   any significant impact on network operations.</t>
      </section>
    </section>
    <section title="IANA Considerations" anchor="section-7"><t> anchor="sec-7" numbered="true" toc="default">
      <name>IANA Considerations</name>
      <t>
   IANA maintains the "Path Computation Element Protocol (PCEP) Numbers"
   registry.  This document requests IANA actions to allocate has allocated code points for the protocol elements
   defined in this document.</t>
      <section title="PCEP anchor="sec-7.1" numbered="true" toc="default">
        <name>PCEP TLV Type Indicators" anchor="section-7.1"><t>
   IANA Manages the PCEP TLV code point registry (see <xref target="RFC5440"/>).  This
   is maintained as Indicators</name>
        <t>IANA maintains the "PCEP TLV Type Indicators" sub-registry of
   subregistry (see <xref target="RFC5440" format="default"/>) within the
	"Path Computation Element Protocol (PCEP) Numbers" registry.</t>

	<t>
   This document defines
        <t>IANA has allocated the following three new PCEP TLVs.  IANA is requested to make
   the following allocation:</t>

	<figure><artwork><![CDATA[
      Type      TLV name                  References
      -----------------------------------------------
      TBD1      H-PCE-CAPABILITY TLV      This I-D
      TBD2      Domain-ID TLV             This I-D
      TBD3      H-PCE-FLAG TLV            This I-D
]]></artwork>
	</figure>
	</section>

	<section title="H-PCE-CAPABILITY TLVs:</t>

<table anchor="tab-2">
  <name>New PCEP TLVs</name>
  <thead>
    <tr>
      <th>Type</th>
      <th>TLV Name</th>
      <th>Reference</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td>13</td>
      <td>H-PCE-CAPABILITY</td>
      <td>RFC 8685</td>
    </tr>
    <tr>
      <td>14</td>
      <td>Domain-ID</td>
      <td>RFC 8685</td>
    </tr>
    <tr>
      <td>15</td>
      <td>H-PCE-FLAG</td>
      <td>RFC 8685</td>
    </tr>
  </tbody>
</table>
      </section>
      <section anchor="sec-7.2" numbered="true" toc="default">
        <name>H-PCE-CAPABILITY TLV Flags" anchor="section-7.2"><t>
   This document requests that a new sub-registry, named Flags</name>
        <t>IANA has created the "H-PCE-CAPABILITY TLV Flag Field", is created Field" subregistry within the
   "Path Computation Element Protocol (PCEP) Numbers" registry to manage
   the Flag field in the H-PCE-CAPABILITY TLV of the
   PCEP OPEN object.</t>

	<t>
   New
        <t>New values are to be assigned by Standards Action <xref target="RFC8126"/>. target="RFC8126"
	format="default"/>.  Each registered bit should be tracked with include the following qualities:

	<list style="symbols"><t>Bit information:
        </t>
        <ul spacing="normal">
          <li>Bit number (counting from bit 0 as the most
    significant bit)</t>

	<t>Capability description</t>

	<t>Defining RFC</t>
</list>
</t> bit)</li>
          <li>Capability description</li>
          <li>Defining RFC</li>
        </ul>
        <t>The following values are value is defined in this document:</t>

	<figure><artwork><![CDATA[
      Bit     Description                      Reference
      --------------------------------------------------
      31      P
<table anchor="tab-3">
  <name>Parent PCE Request Bit</name>
  <thead>
    <tr>
      <th>Bit</th>
      <th>Description</th>
      <th>Reference</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td>31</td>
      <td>P (Parent PCE Request bit)       This I.D.
]]></artwork>
	</figure> bit)</td>
      <td>RFC 8685</td>
    </tr>
  </tbody>
</table>
      </section>
      <section title="Domain-ID anchor="sec-7.3" numbered="true" toc="default">
        <name>Domain-ID TLV Domain type" anchor="section-7.3"><t>
   This document requests that a new sub-registry, named Type</name>
        <t>
   IANA has created the "Domain-ID TLV Domain type", is created Type" subregistry
   within the "Path Computation Element Protocol (PCEP)
   Numbers" registry to manage the Domain-Type Domain Type field of
   the Domain-ID TLV. The allocation policy for this new sub-registry subregistry is
   IETF Review <xref target="RFC8126"/>.</t>

	<figure><artwork><![CDATA[
      Value     Meaning
      -----------------------------------------------
       1        2-byte target="RFC8126" format="default"/>.</t>
<t>The following values are defined in this document:</t>

<table anchor="tab-4">
  <name>Parameters for Domain-ID TLV Domain Type</name>
  <thead>
    <tr>
      <th>Value</th>
      <th>Meaning</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td>0</td>
      <td>Reserved</td>
    </tr>
    <tr>
      <td>1</td>
      <td>2-byte AS number
       2        4-byte number</td>
    </tr>
    <tr>
      <td>2</td>
      <td>4-byte AS number
       3        4-byte number</td>
    </tr>
    <tr>
      <td>3</td>
      <td>4-byte OSPF area ID
       4        Variable length ID</td>
    </tr>
    <tr>
      <td>4</td>
      <td>Variable-length IS-IS area ID
]]></artwork>
	</figure>
	</section>

	<section title="H-PCE-FLAG ID</td>
    </tr>
   <tr>
     <td>5-255</td>
     <td>Unassigned</td>
  </tr>
  </tbody>
</table>

      </section>
      <section anchor="sec-7.4" numbered="true" toc="default">
        <name>H-PCE-FLAG TLV Flags" anchor="section-7.4"><t>
   This document requests that a new sub-registry, named Flags</name>
        <t>
   IANA has created the "H-PCE-FLAG TLV Flag Field", is created Field" subregistry within the
   "Path Computation Element Protocol (PCEP) Numbers" registry to manage the Flag field in the H-PCE-FLAGS
   H-PCE-FLAG TLV of the PCEP RP object.
   New values are to be assigned by Standards Action <xref target="RFC8126"/>. target="RFC8126"
   format="default"/>.  Each registered bit should be tracked with include the following qualities:

	<list style="symbols"><t>Bit
   information:
        </t>
        <ul spacing="normal">
          <li>Bit number (counting from bit 0 as the most
    significant bit)</t>

	<t>Capability description</t>

	<t>Defining RFC</t>
</list>
</t> bit)</li>
          <li>Capability description</li>
          <li>Defining RFC</li>
        </ul>
        <t>The following values are defined in this document:</t>

	<figure><artwork><![CDATA[
      Bit     Description           Reference
      -----------------------------------------------
      31      S (Domain             This I.D.
                 Sequence bit)
      30      D (Disallow

<table anchor="tab-5">
  <name>New H-PCE-FLAG TLV Flag Field Entries</name>
  <thead>
    <tr>
      <th>Bit</th>
      <th>Description</th>
      <th>Reference</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td>30</td>
      <td>D (Disallow Domain    This I.D. Re-entry bit)
]]></artwork>
	</figure> bit)</td>
      <td>RFC 8685</td>
    </tr>
    <tr>
      <td>31</td>
      <td>S (Domain Sequence bit)</td>
      <td>RFC 8685</td>
    </tr>
  </tbody>
</table>
      </section>
      <section title="OF Codes" anchor="section-7.5"><t> anchor="sec-7.5" numbered="true" toc="default">
        <name>OF Codes</name>
        <t>
   IANA maintains a registry list of Objective Function OFs (described in
   <xref target="RFC5541"/>) at target="RFC5541" format="default"/>) in the sub-registry "Objective Function".  Three new
   Objective Functions have been defined in this document.</t> Function"
   subregistry within the "Path Computation Element Protocol (PCEP) Numbers" registry.</t>
        <t>IANA is requested to make has allocated the following allocations:</t>

	<figure><artwork><![CDATA[
    Code
    Point    Name                           Reference
    ------------------------------------------------------
    TBD4     Minimum OFs:</t>
<table anchor="tab-6">
  <name>New OF Codes</name>
  <thead>
    <tr>
      <th>Code Point</th>
      <th>Name</th>
      <th>Reference</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td>12</td>
      <td>Minimize the number of Transit      This I.D. Domains (MTD)
    TBD5     Minimize (MTD)</td>
      <td>RFC 8685</td>
    </tr>
    <tr>
      <td>13</td>
      <td>Minimize the number of Border      This I.D. Nodes (MBN)
    TBD13    Minimize (MBN)</td>
      <td>RFC 8685</td>
    </tr>
    <tr>
      <td>14</td>
      <td>Minimize the number of         This I.D. Common Transit Domains
             (MCTD)
]]></artwork>
	</figure> (MCTD)</td>
      <td>RFC 8685</td>
    </tr>
  </tbody>
</table>

      </section>
      <section title="METRIC Types" anchor="section-7.6"><t> anchor="sec-7.6" numbered="true" toc="default">
        <name>METRIC Object Types</name>
        <t>
   IANA maintains one sub-registry for the "METRIC object Object T field".  Two Field" subregistry <xref
   target="RFC5440" format="default"/> within the "Path
   Computation Element Protocol (PCEP) Numbers" registry. </t>
        <t>The following two new metric types are defined in this document for the
	METRIC object
   (specified are defined in <xref target="RFC5440"/>). </t>

   <t>IANA is requested to make the following allocations:</t>

	<figure><artwork><![CDATA[
    Value    Description                    Reference
    ----------------------------------------------------------
    TBD6     Domain this document:</t>

<table anchor="tab-7">
  <name>New METRIC Object Types</name>
  <thead>
    <tr>
      <th>Value</th>
      <th>Description</th>
      <th>Reference</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td>20</td>
      <td>Domain Count metric            This I.D.
    TBD7     Border metric</td>
      <td>RFC 8685</td>
    </tr>
    <tr>
      <td>21</td>
      <td>Border Node Count metric       This I.D.
]]></artwork>
	</figure> metric</td>
      <td>RFC 8685</td>
    </tr>
  </tbody>
</table>

      </section>
      <section title="New anchor="sec-7.7" numbered="true" toc="default">
        <name>New PCEP Error-Types and Values" anchor="section-7.7"><t>
   IANA Values</name>
        <t>IANA maintains a registry list of Error-Types and Error-values Error-Values for use in
    PCEP messages.  This list is maintained as in the
    "PCEP-ERROR Object Error Types and Values" sub-registry of subregistry within the "Path
    Computation Element Protocol (PCEP) Numbers" registry.</t>
        <t>IANA is requested to make the following allocations:"</t>

<!-- [rfced] Please review has allocated the table alignment of text to column headers -->

	<figure><artwork><![CDATA[
    Error-Type    Meaning following:</t>

<table anchor="tab-8">
  <name>New PCEP Error-Types and Values</name>
  <thead>
    <tr>
      <th>Error-Type</th>
      <th>Meaning and error values  Reference
    ------------------------------------------------------
    TBD8     H-PCE Error                    This I.D.

             Error-value=1 Values</th>
      <th>Reference</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td align='left'>28</td>
      <td align='left'><ul empty="true" spacing="compact">
       <li><t>H-PCE Error</t>
       <t>Error-Value=1: H-PCE
             Capability not advertised

             Error-value=2 Capability</t>
          <t>not advertised</t>
       <t>Error-Value=2: Parent PCE
             Capability cannot Capability</t>
          <t>cannot be provided

    10       Reception provided</t>
       </li>
       </ul>
      </td>
      <td>RFC 8685</td>
    </tr>
    <tr>
      <td align='left'>10</td>
      <td align='left'> <ul empty="true" spacing="compact" indent="0">
       <li><t>Reception of an invalid object [RFC5440]

             Error-value=TBD15: object</t>
           <t>Error-Value=23: Incompatible  This I.D. OF codes in H-PCE

]]></artwork>
	</figure>
	</section>

	<section title="New codes</t>
              <t>in H-PCE</t></li>
       </ul>
      </td>
      <td><t>RFC 5440</t>
          <t>RFC 8685</t></td>
    </tr>
  </tbody>
</table>
      </section>
      <section anchor="sec-7.8" numbered="true" toc="default">
        <name>New NO-PATH-VECTOR TLV Bit Flag" anchor="section-7.8"><t>
   IANA Flag</name>
        <t>IANA maintains a sub-registry the "NO-PATH-VECTOR TLV Flag Field" subregistry,
   which contains a list of bit flags carried in the PCEP NO-PATH-VECTOR TLV
   in the PCEP NO-PATH object as defined in <xref target="RFC5440"/>. IANA is requested to assign three target="RFC5440"
   format="default"/>.</t>
<t>IANA has allocated the following four new bit flag as follows:</t>

	<figure><artwork><![CDATA[
   Bit Number      Name Flag                   Reference
   ------------------------------------------------------
   TBD9            Destination Domain unknown  This I.D.
   TBD10           Unresponsive child PCE(s)   This I.D.
   TBD11           No flags:</t>

<table anchor="tab-9">
  <name>PCEP NO-PATH Object Flags</name>
  <thead>
    <tr>
      <th>Bit Number</th>
      <th>Description</th>
      <th>Reference</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td>22</td>
      <td>Destination domain unknown</td>
      <td>RFC 8685</td>
    </tr>
    <tr>
      <td>21</td>
      <td>Unresponsive child PCE(s)</td>
      <td>RFC 8685</td>
    </tr>
    <tr>
      <td>20</td>
      <td>No available resource in    This I.D. one or more domain
   TBD12           Destination domains</td>
      <td>RFC 8685</td>
    </tr>
    <tr>
      <td>19</td>
      <td>Destination is not found    This I.D. in the indicated domain.
]]></artwork>
	</figure> domain</td>
      <td>RFC 8685</td>
    </tr>
  </tbody>
</table>

      </section>
      <section title="SVEC Flag" anchor="section-7.9"><t>
   IANA anchor="sec-7.9" numbered="true" toc="default">
        <name>SVEC Flag</name>
        <t>IANA maintains a sub-registry the "SVEC Object Flag Field" subregistry, which
   contains a list of bit flags carried in the PCEP SVEC object as defined
   in <xref target="RFC5440"/>.  IANA is
   requested to assign one target="RFC5440" format="default"/>. </t>
   <t>IANA has allocated the following new bit flag as follows:</t>

	<figure><artwork><![CDATA[
   Bit Number      Name Flag                   Reference
   ------------------------------------------------------
   TBD14           Domain flag:</t>

<table anchor="tab-10">
  <name>Domain Diverse O-bit        This I.D.
]]></artwork>
	</figure> O-Bit</name>
  <thead>
    <tr>
      <th>Bit Number</th>
      <th>Description</th>
      <th>Reference</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td>18</td>
      <td>Domain Diverse O-bit</td>
      <td>RFC 8685</td>
    </tr>
  </tbody>
</table>

      </section>
    </section>
    <section title="Security Considerations" anchor="section-8"><t> anchor="sec-8" numbered="true" toc="default">
      <name>Security Considerations</name>
      <t>
   The hierarchical PCE H-PCE procedure relies on PCEP and inherits the
   security considerations defined in <xref target="RFC5440"/>. target="RFC5440" format="default"/>.  As PCEP
   operates over TCP, it may also make use of TCP security mechanisms, such as
   the TCP Authentication Option (TCP-AO) <xref target="RFC5925"/> target="RFC5925" format="default"/> or
   Transport Layer Security (TLS) <xref target="RFC8253"/>.</t> target="RFC8253" format="default"/>
        <xref target="RFC8446" format="default"/>.</t>
      <t>
   Any multi-domain operation necessarily involves the exchange of
   information across domain boundaries.  This may represent a
   significant security and confidentiality risk risk, especially when the
   child domains are controlled by different commercial concerns.  PCEP
   allows individual PCEs to maintain the confidentiality of their
   domain path information using path-keys <xref target="RFC5520"/>, target="RFC5520" format="default"/>, and the
   H-PCE architecture is specifically designed to enable as much
   isolation of information related to domain topology and capabilities information
   as is possible.</t>
      <t>
   For further considerations of regarding the security issues related to
   inter-AS path computation, see <xref target="RFC5376"/>.</t> target="RFC5376" format="default"/>.</t>
    </section>
  </middle>
  <back>

  <displayreference target="I-D.ietf-pce-stateful-hpce" to="STATEFUL-HPCE"/>
  <displayreference target="I-D.dhodylee-pce-pcep-ls" to="PCEP-LS"/>

    <references>
      <name>References</name>
      <references>
        <name>Normative References</name>

<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5440.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5541.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/>
      </references>
      <references>
        <name>Informative References</name>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4105.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4216.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4655.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4726.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5152.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5376.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5394.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5520.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5441.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5925.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6805.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7399.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7420.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7752.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7897.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8126.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8253.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8446.xml"/>

<!-- [rfced] Should contributors authors be in an artwork tag?? draft-ietf-pce-pcep-yang; "long way" because of role="editor" -->
<reference anchor='PCEP-YANG' target="https://tools.ietf.org/html/draft-ietf-pce-pcep-yang-13">
<front>
<title>A YANG Data Model for Path Computation Element Communications Protocol (PCEP)</title>
<author initials='D' surname='Dhody' fullname='Dhruv Dhody' role="editor">
    <organization />
</author>
<author initials='J' surname='Hardwick' fullname='Jonathan Hardwick'>
    <organization />
</author>
<author initials='V' surname='Beeram' fullname='Vishnu Beeram'>
    <organization />
</author>
<author initials='J' surname='Tantsura' fullname='Jeff Tantsura'>
    <organization />
</author>
<date month='October' day='31' year='2019' />
</front>
<seriesInfo name='Work in Progress, Internet-Draft,' value='draft-ietf-pce-pcep-yang-13' />
</reference>

<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-pce-stateful-hpce.xml"/>

<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml3/reference.I-D.dhodylee-pce-pcep-ls.xml"/>

      </references>
    </references>
    <section title="Contributing Authors" anchor="section-9"><figure><artwork><![CDATA[
   Xian Zhang
   Huawei

   EMail: zhang.xian@huawei.com

   Dhruv Dhody
   Huawei Technologies
   Divyashree Techno Park, Whitefield
   Bangalore, Karnataka  560066
   India

   EMail: dhruv.ietf@gmail.com
]]></artwork>
	</figure>
	</section>

	<section title="Acknowledgements" anchor="section-10"><t> numbered="false" toc="default">
      <name>Acknowledgements</name>
      <t>
   The authors would like to thank Mike McBride, Kyle Rose, and Roni Even
   for their detailed review, comments comments, and suggestions suggestions, which helped
   improve this document.</t>
    </section>

	</middle>

	<back>
	<references title="Normative References">
	&RFC2119;
	&RFC5440;
	&RFC5541;
	&RFC8174;
	</references>
	<references title="Informative References">
	&RFC4105;
	&RFC4216;
	&RFC4655;
	&RFC4726;
	&RFC5152;
	&RFC5376;
	&RFC5394;
	&RFC5520;
	&RFC5441;
	&RFC5925;
	&RFC6805;
	&RFC7399;
	&RFC7420;
	&RFC7752;
	&RFC7897;
	&RFC8126;
	&RFC8253;
	&I-D.ietf-pce-pcep-yang;
	&I-D.ietf-pce-stateful-hpce;
	&I-D.dhodylee-pce-pcep-ls;
	</references>
    <section numbered="false" toc="default">
      <name>Contributors</name>
<t>The following people contributed substantially to the content of this
   document and should be considered coauthors:</t>

      <artwork name="" type="" align="left" alt=""><![CDATA[
Xian Zhang
Huawei
Email: zhang.xian@huawei.com ]]></artwork>

<artwork name="" type="" align="left" alt=""><![CDATA[
Dhruv Dhody
Huawei Technologies
Divyashree Techno Park, Whitefield
Bangalore, Karnataka  560066
India
Email: dhruv.ietf@gmail.com ]]></artwork>
    </section>
  </back>
</rfc>