<?xml version='1.0' encoding='utf-8'?> version="1.0" encoding="UTF-8"?>

<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY RFC3209 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3209.xml">
<!ENTITY RFC3473 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3473.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 RFC5440 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5440.xml">
<!ENTITY RFC5441 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5441.xml">
<!ENTITY RFC5520 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5520.xml">
<!ENTITY RFC5541 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5541.xml">
<!ENTITY RFC6805 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6805.xml">
<!ENTITY RFC3060 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3060.xml">
<!ENTITY RFC3460 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3460.xml">
<!ENTITY RFC3630 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3630.xml">
<!ENTITY RFC4090 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4090.xml">
<!ENTITY RFC4203 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4203.xml">
<!ENTITY RFC4920 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4920.xml">
<!ENTITY RFC5088 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5088.xml">
<!ENTITY RFC5089 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5089.xml">
<!ENTITY RFC5305 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5305.xml">
<!ENTITY RFC5307 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5307.xml">
<!ENTITY RFC5316 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5316.xml">
<!ENTITY RFC5392 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5392.xml">
<!ENTITY RFC5394 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5394.xml">
<!ENTITY RFC5521 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5521.xml">
<!ENTITY RFC5886 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5886.xml">
<!ENTITY RFC6007 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6007.xml">
<!ENTITY RFC6952 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6952.xml">
<!ENTITY RFC7334 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7334.xml">
<!ENTITY RFC7420 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7420.xml">
<!ENTITY RFC7525 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7525.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 RFC8253 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8253.xml">
<!ENTITY RFC8453 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8453.xml">
]> "rfc2629-xhtml.ent">

<rfc xmlns:xi="http://www.w3.org/2001/XInclude" submissionType="IETF" docName="draft-ietf-pce-inter-area-as-applicability-08" category="info" ipr="trust200902"> consensus="true" docName="draft-ietf-pce-inter-area-as-applicability-08" number="8694" ipr="trust200902" obsoletes="" updates="" xml:lang="en" sortRefs="false" symRefs="true" tocInclude="true" version="3">

  <!-- xml2rfc v2v3 conversion 2.31.0 -->
  <!-- Generated by id2xml 1.5.0 on 2019-10-01T23:58:47Z -->
	<?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="Applicability of the Path Computation El">Applicability of PCE to MPLS and GMPLS">Applicability of the Path Computation Element to Inter-Area Inter-area and Inter-AS MPLS and GMPLS Traffic Engineering</title>
    <seriesInfo name="RFC" value="8694"/>
    <author fullname="D. fullname="Daniel King" initials="D." surname="King">
      <organization>Old Dog Consulting</organization>
      <address>
	<email>daniel@olddog.co.uk</email>
      </address>
    </author>

    <author fullname="H. Zheng" initials="H." surname="Zheng">
	<organization>Huawei Technologies</organization> fullname="郑好棉" asciiFullname="Haomian Zheng">
      <organization ascii="Huawei Technologies">华为技术有限公司</organization>
      <address>
        <postal>
          <street ascii="H1, Huawei Xiliu Beipo Village, Songshan Lake">松山湖华为溪流背坡村H1</street>
	  <city ascii="Dongguan">东莞</city>
	  <region ascii="Guangdong">广东</region>
          <code>523808</code>
          <country ascii="China">中国</country>
        </postal>
        <email>zhenghaomian@huawei.com</email>
      </address>
    </author>

    <date month="September" month="December" year="2019"/>
    <workgroup>PCE Working Group</workgroup>
	<abstract><t>

    <abstract>
      <t>
   The Path Computation Element (PCE) may be used for computing services
   that traverse multi-area and multi-AS  multi-Autonomous System (multi-AS) Multiprotocol Label Switching
   (MPLS) and Generalized MPLS (GMPLS) Traffic Engineered Traffic-Engineered (TE) networks.</t>
      <t>
   This document examines the applicability of the PCE architecture,
   protocols, and protocol extensions for computing multi-area and
   multi-AS paths in MPLS and GMPLS networks.</t>
    </abstract>
  </front>
  <middle>
    <section title="Introduction" anchor="sect-1"><t> anchor="sect-1" numbered="true" toc="default">
      <name>Introduction</name>
      <t>
   Computing paths across large multi-domain environments may
   require special computational components and cooperation between
   entities in different domains capable of complex path computation.</t>
      <t>
   Issues that may exist when routing in multi-domain networks include:</t>

	<t><list style="symbols"><t>Often there include the
      following:</t>
      <ul spacing="normal">
        <li>There is often a lack of full topology and TE information across
     domains;</t>

	<t>No
     domains.</li>
        <li>No single node has the full visibility to determine an optimal or
     even feasible end-to-end path across domains;</t>

	<t>How domains.</li>
        <li>Knowing how to evaluate and select the exit point and next domain
      boundary from a domain?</t>

	<t>How might domain.</li>
        <li>Understanding how the ingress node determine determines which domains should
      be used for the end-to-end path?</t>

	</list>
	</t> path.</li>
      </ul>
      <t>
   Often
   An information exchange across multiple domains is often limited due to
   the lack of trust relationship, security issues, or scalability
   issues
   issues, even if there is a trust relationship between domains.</t>
      <t>
   The Path Computation Element (PCE) <xref target="RFC4655"/> target="RFC4655" format="default"/> provides an architecture
   and a set of functional components to address the problem space, space and the
   issues highlighted above.</t>
      <t>
   A PCE may be used to compute end-to-end paths across multi-domain
   environments using a per-domain path computation technique <xref target="RFC5152"/>.
   target="RFC5152" format="default"/>.

   The so called so-called backward recursive path PCE-based computation (BRPC) mechanism
   <xref target="RFC5441"/> target="RFC5441" format="default"/> defines a PCE-based path computation procedure to compute
   inter-domain constrained Multiprotocol Label Switching (MPLS) and
   Generalized MPLS (GMPLS) Traffic Engineered Traffic-Engineered (TE) networks.

 However,
   both per-domain and BRPC techniques assume that the sequence of
   domains to be crossed from source to destination is known, either
   fixed by the network operator or obtained by other means.</t>
      <t>
   In more advanced deployments (including multi-area and multi-
   Autonomous multi-Autonomous System (multi-AS) environments) environments), the sequence of domains
   may not be known in advance advance, and the choice of domains in the end-to-
   end end-to-end
   domain sequence might be critical to the determination of an
   optimal end-to-end path. In this case case, the use of the Hierarchical hierarchical PCE
   <xref target="RFC6805"/> target="RFC6805" format="default"/> architecture and mechanisms may be used to discover the
   intra-area path and select the optimal end-to-end domain sequence.</t>
      <t>
   This document describes the processes and procedures available when
   using the PCE architecture and protocols, protocols for computing inter-area
   and inter-AS MPLS and GMPLS Traffic Engineered Traffic-Engineered paths.</t>
      <t>
   This document
   The scope of this document does not include discussion on discussions of deployment
   scenarios for stateful PCE, active PCE, remotely initiated PCE, or
   PCE as a central controller
   (PCECC) deployment scenarios.</t> (PCECC).
</t>
      <section title="Domains" anchor="sect-1.1"><t> anchor="sect-1.1" numbered="true" toc="default">
        <name>Domains</name>
        <t>
   Generally, a domain can be defined as a separate administrative,
   geographic, or switching environment within the network. A domain
   may be further defined as a zone of routing or computational ability.
   Under these definitions definitions, a domain might be categorized as an
   Autonomous System (AS) or an Interior Gateway Protocol (IGP) area
   (as per <xref target="RFC4726"/> target="RFC4726" format="default"/> and <xref target="RFC4655"/>).</t> target="RFC4655" format="default"/>).</t>
        <t>
   For the purposes of this document, a domain is considered to be a
   collection of network elements within an area or AS that has a
   common sphere of address management or path computational
   responsibility. Wholly or partially overlapping domains are not
   within the scope of this document.</t>
        <t>
   In the context of GMPLS, a particularly important example of a domain
   is the Automatically Switched Optical Network (ASON) subnetwork
   <xref target="G-8080"/>. target="G-8080" format="default"/>. In this case, computation of an end-to-end path requires
   the selection of nodes and links within a parent domain where some
   nodes may, in fact, be subnetworks. Furthermore, a domain might be an
   ASON routing area <xref target="G-7715"/>. target="G-7715" format="default"/>. A PCE may perform the path computation
   function of an ASON routing controller Routing Controller as described in <xref target="G-7715-2"/>.</t> target="G-7715-2" format="default"/>.</t>
        <t>
   It is assumed that the PCE architecture is not applied to a large
   group of domains, such as the Internet.</t>
      </section>
      <section title="Path Computation" anchor="sect-1.2"><t> anchor="sect-1.2" numbered="true" toc="default">
        <name>Path Computation</name>
        <t>
   For the purpose of this document, it is assumed that the path computation is the sole responsibility of the PCE as per the
   architecture defined in <xref target="RFC4655"/>. target="RFC4655" format="default"/>. When a path is required required, the Path
   Computation Client (PCC) will send a request to the PCE. The PCE
   will apply the required constraints and constraints, compute a path path, and return a
   response to the PCC. In the context of this document document, it may be
   necessary for the PCE to co-operate cooperate with other PCEs in adjacent
   domains (as per BRPC <xref target="RFC5441"/>) target="RFC5441" format="default"/>) or cooperate with a Parent parent PCE
   (as per <xref target="RFC6805"/>).</t> target="RFC6805" format="default"/>).</t>
        <t>
   It is entirely feasible that an operator could compute a path across
   multiple domains without the use of a PCE if the relevant domain
   information is available to the network planner or network management
   platform. The definition of what relevant information is required to
   perform this network planning operation and how that information is
   discovered and applied is outside the scope of this document.</t>
        <section title="PCE-based anchor="sect-1.2.1" numbered="true" toc="default">
          <name>PCE-Based Path Computation Procedure" anchor="sect-1.2.1"><t> Procedure</name>
          <t>
   As highlighted, the PCE is an entity capable of computing an
   inter-domain TE path upon receiving a request from a PCC. There could
   be a single PCE per domain, domain or a single PCE responsible for all
   domains. A PCE may or may not reside on the same node as the
   requesting PCC. A path may be computed by either a single PCE node
   or a set of distributed PCE nodes that collaborate during path
   computation.</t>

          <t>
   According to <xref target="RFC4655"/> defines that target="RFC4655" format="default"/>, a PCC should send a path computation request
   to a particular PCE, PCE using <xref target="RFC5440"/> target="RFC5440" format="default"/> (PCC-to-PCE communication).
   This negates the need to broadcast a request to all the PCEs. Each
   PCC can maintain information about the computation capabilities
   of the PCEs, PCEs it is aware of. The PCC-PCE capability awareness can be
   configured using static configurations or by automatic and dynamic
   PCE discovery procedures.</t>
          <t>
   If a network path is required, the PCC will send a path computation
   request to the PCE. A PCE may then compute the end-to-end path
   if it is aware of the topology and TE information required to
   compute the entire path. If the PCE is unable to compute the
   entire path, the PCE architecture provides co-operative cooperative PCE
   mechanisms for the resolution of path computation requests when an
   individual PCE does not have sufficient TE visibility.</t>

          <t>
   End-to-end path segments may be kept confidential through the
   application of path keys, Path-Keys to protect partial or full path
   information. A path key that Path-Key is a token that replaces a path segment
   in an explicit route. The path key Path-Key mechanism is described in
   <xref target="RFC5520"/></t> target="RFC5520" format="default"/>.</t>
        </section>
      </section>
      <section title="Traffic anchor="sect-1.3" numbered="true" toc="default">
        <name>Traffic Engineering Aggregation and Abstraction" anchor="sect-1.3"><t> Abstraction</name>

        <t>
   Networks are often constructed from multiple areas or ASes that are
   interconnected via multiple interconnect points. To maintain
   network confidentiality and scalability scalability, the TE properties of each area
   and AS are not generally advertized advertised outside each specific area or AS.</t>
        <t>
   TE aggregation or abstraction provide a mechanism to hide information
   but may cause failed path setups or the selection of suboptimal
   end-to-end end-
   to-end paths <xref target="RFC4726"/>. target="RFC4726" format="default"/>. The aggregation process may also have
   significant scaling issues for networks with many possible routes
   and multiple TE metrics. Flooding TE information breaks
   confidentiality and does not scale in the routing protocol.</t>
        <t>
   The PCE architecture and associated mechanisms provide a solution
   to avoid the use of TE aggregation and abstraction.</t>
      </section>
      <section title="Traffic Engineered anchor="sect-1.4" numbered="true" toc="default">
        <name>Traffic-Engineered Label Switched Paths" anchor="sect-1.4"><t> Paths</name>
        <t>
   This document highlights the PCE techniques and mechanisms that exist
   for establishing TE packet and optical LSPs Label Switched Paths (LSPs) across multiple areas
   (inter-area TE LSP) and ASes (inter-AS TE LSP). In this context and
   within the remainder of this document, we consider all LSPs to be
   constraint-based
   constraint based and traffic engineered.</t>
        <t>
   Three signaling options are defined for setting up an inter-area or
   inter-AS LSP <xref target="RFC4726"/>:</t>

	<t><list style="symbols"><t>Contiguous LSP</t>

	<t>Stitched LSP</t>

	<t>Nested LSP</t>

	</list>
	</t> target="RFC4726" format="default"/>:</t>
        <ul spacing="normal">
          <li>Contiguous LSP</li>
          <li>Stitched LSP</li>
          <li>Nested LSP</li>
        </ul>
        <t>
   All three signaling methods are applicable to the architectures and
   procedures discussed in this document.</t>
      </section>
      <section title="Inter-area anchor="sect-1.5" numbered="true" toc="default">
        <name>Inter-area and Inter-AS Capable Inter-AS-capable PCE Discovery" anchor="sect-1.5"><t> Discovery</name>
        <t>
   When using a PCE-based approach for inter-area and inter-AS path
   computation, a PCE in one area or AS may need to learn information
   related to inter-AS capable inter-AS-capable PCEs located in other ASes. The PCE
   discovery mechanism defined in <xref target="RFC5088"/> target="RFC5088" format="default"/> and <xref target="RFC5089"/> target="RFC5089" format="default"/> facilitates
   the discovery of PCEs, PCEs and disclosure of information related to
   inter-area and inter-AS capable inter-AS-capable PCEs.</t>
      </section>
      <section title="Objective Functions" anchor="sect-1.6"><t> anchor="sect-1.6" numbered="true" toc="default">
        <name>Objective Functions</name>
        <t>
   An Objective Function (OF) <xref target="RFC5541"/>, target="RFC5541" format="default"/> or a set of OFs, OFs specifies the
   intentions of the path computation and so defines the "optimality", "optimality"
   in the context of the computation request.</t>
        <t>
   An OF specifies the desired outcome of a computation. An OF It does not
   describe or specify the algorithm to use. Also, an implementation
   may apply any algorithm, algorithm or set of algorithms, algorithms to achieve the result
   indicated by the OF. A number of general OFs are specified in
   <xref target="RFC5541"/>.</t> target="RFC5541" format="default"/>.</t>
        <t>
   Various OFs may be included in the PCE computation request to
   satisfy the policies encoded or configured at the PCC, and a PCE
   may be subject to policy in determining whether it meets the OFs
   included in the computation request or whether it applies its own OFs.</t>
        <t>
   During inter-domain path computation, the selection of a domain
   sequence, the computation of each (per-domain) path fragment, and the
   determination of the end-to-end path may each be subject to different
   OFs and policy.</t> policies.
</t>
      </section>
    </section>
    <section title="Terminology" anchor="sect-2"><t> anchor="sect-2" numbered="true" toc="default">
      <name>Terminology</name>
      <t>
   This document also uses the terminology defined in <xref target="RFC4655"/> target="RFC4655" format="default"/> and
   <xref target="RFC5440"/>. target="RFC5440" format="default"/>. Additional terminology is defined below:

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

	<t hangText="ABR:">

      </t>
      <dl newline="false" spacing="normal" indent="6">
        <dt>ABR:</dt>
        <dd> IGP Area Border Router, Router -- a router that is attached to more than
	one IGP area. </t>

	<t hangText="ASBR:"> </dd>
        <dt>ASBR:</dt>
        <dd> Autonomous System Border Router, Router -- a router used to connect
	together ASes of a different or the same Service Provider via one or more inter-AS links.
	</t>

	<t hangText="Inter-area
	</dd>
        <dt>Inter-area TE LSP:"> LSP:</dt>
        <dd> A TE LSP whose path transits through two or more
	IGP areas. </t>

	<t hangText="Inter-AS </dd>
        <dt>Inter-AS MPLS TE LSP:"> LSP:</dt>
        <dd> A TE LSP whose path transits through two or
	more ASes or sub-ASes (BGP confederations </t>

        <t hangText="SRLG:"> confederations) </dd>
        <dt>SRLG:</dt>
        <dd> Shared Risk Link Group.</t>

	<t hangText="TED:"> Group.</dd>
        <dt>TED:</dt>
        <dd> Traffic Engineering Database, which contains the
	topology and resource information of the domain.  The TED may be fed
	by Interior Gateway Protocol (IGP) extensions or potentially by other
	means.	</t>

	</list>
	</t>	</dd>
      </dl>
    </section>
    <section title="Issues anchor="sect-3" numbered="true" toc="default">
      <name>Issues and Considerations" anchor="sect-3"><section title="Multi-homing" anchor="sect-3.1"><t> Considerations</name>
      <section anchor="sect-3.1" numbered="true" toc="default">
        <name>Multihoming</name>
        <t>
   Networks constructed from multi-areas or multi-AS environments
   may have multiple interconnect points (multi-homing). (multihoming). End-to-end path
   computations may need to use different interconnect points to avoid
   a single point single-point failure disrupting both the primary and backup services.</t>
      </section>
      <section title="Destination Location" anchor="sect-3.2"><t>
   The anchor="sect-3.2" numbered="true" toc="default">
        <name>Destination Location</name>
        <t>
   A PCC asking for an inter-domain path computation is typically
   aware of the identity of the destination node. If the PCC is aware
   of the destination domain, it may supply the destination domain
   information as part of the path computation request. However, if the
   PCC does not know the destination domain domain, this information must be
   determined by another method.</t>
      </section>
      <section title="Domain Confidentiality" anchor="sect-3.3"><t>
   Where anchor="sect-3.3" numbered="true" toc="default">
        <name>Domain Confidentiality</name>
        <t>
   When the end-to-end path crosses multiple domains, it may be possible that
   each domain (AS or area) are is administered by separate Service Providers, it would break confidentiality rules for Providers.
   Thus, if a PCE
   to supply supplies a path segment to a PCE in another domain, thus disclosing it may
   break confidentiality rules and could disclose AS-internal topology
   information.</t>
        <t>
   If confidentiality is required between domains (ASes and areas)
   belonging to different Service Providers, then cooperating PCEs
   cannot exchange path segments or else segments; otherwise, the receiving PCE or PCC will
   be able to see the individual hops through another domain.</t>
        <t>
   This topic is discussed further in Section 8 <xref target="sect-8"/> of this document.</t>
      </section>
    </section>
    <section title="Domain Topologies" anchor="sect-4"><t> anchor="sect-4" numbered="true" toc="default">
      <name>Domain Topologies</name>
      <t>
   Constraint-based inter-domain path computation is a fundamental
   requirement for operating traffic engineered traffic-engineered MPLS <xref target="RFC3209"/> target="RFC3209" format="default"/> and
   GMPLS <xref target="RFC3473"/> networks, target="RFC3473" format="default"/> networks in inter-area and inter-AS (multi-domain)
   environments. Path computation across multi-domain networks is
   complex and requires computational co-operational cooperational entities like the
   PCE.</t>
      <section title="Selecting anchor="sect-4.1" numbered="true" toc="default">
        <name>Selecting Domain Paths" anchor="sect-4.1"><t> Paths</name>
        <t>
   Where the sequence of domains is known a priori, various techniques
   can be employed to derive an optimal multi-domain path. If the
   domains are connected to a simple path with no branches and single
   links between all domains, domains or if the preferred points of
   interconnection is are also known, the Per-Domain Path Computation per-domain path computation
   <xref target="RFC5152"/> target="RFC5152" format="default"/> technique may be used. Where there are multiple connections
   between domains and there is no preference for the choice of points
   of interconnection, BRPC <xref target="RFC5441"/> target="RFC5441" format="default"/> can be used to derive an optimal
   path.</t>
        <t>
   When the sequence of domains is not known in advance, advance or the
   end-to-end path will have to navigate a mesh of small domains
   (especially typical in optical networks), the optimum path may be
   derived through the application of a Hierarchical hierarchical PCE <xref target="RFC6805"/>.</t> target="RFC6805" format="default"/>.</t>
      </section>
      <section title="Domain Sizes" anchor="sect-4.2"><t> anchor="sect-4.2" numbered="true" toc="default">
        <name>Domain Sizes</name>
        <t>
   Very frequently frequently, network domains are composed of dozens or hundreds of
   network elements. These network elements are usually interconnected
   in a partial-mesh fashion, fashion to provide survivability against dual
   failures,
   failures and to benefit from the traffic engineering traffic-engineering capabilities
   from
   of MPLS and GMPLS protocols. Network operator feedback in the
   development of the document highlighted that the node degree (the number
   of neighbors per node) typically ranges from 3 to 10 (4-5 is quite
   common).</t>
      </section>
      <section title="Domain Diversity" anchor="sect-4.3"><t> anchor="sect-4.3" numbered="true" toc="default">
        <name>Domain Diversity</name>
        <t>
   Domain and path diversity may also be required when computing
   end-to-end paths. Domain diversity should facilitate the selection
   of paths that share ingress and egress domains, domains but do not share
   transit domains. Therefore, there must be a method allowing the
   inclusion or exclusion of specific domains when computing end-to-end paths.</t>
      </section>
      <section title="Synchronized anchor="sect-4.4" numbered="true" toc="default">
        <name>Synchronized Path Computations" anchor="sect-4.4"><t> Computations</name>
        <t>
   In some scenarios, it would be beneficial for the operator to rely on
   the capability of the PCE to perform synchronized path computation.</t>
        <t>
   Synchronized path computations, known as Synchronization VECtors
   (SVECs)
   (SVECs), are used for dependent path computations. SVECs are
   defined in <xref target="RFC5440"/> target="RFC5440" format="default"/>, and <xref target="RFC6007"/> target="RFC6007" format="default"/> provides an overview for of the
   use of the PCE SVEC list for synchronized path computations when
   computing dependent requests.</t>
        <t>
   In H-PCE hierarchical PCE (H-PCE) deployments, a child PCE will be able to request both
   dependent and synchronized domain diverse end to end domain-diverse end-to-end paths from its
   parent PCE.</t>
      </section>
      <section title="Domain anchor="sect-4.5" numbered="true" toc="default">
        <name>Domain Inclusion or Exclusion" anchor="sect-4.5"><t> Exclusion</name>
        <t>
   A domain sequence is an ordered sequence of domains traversed to
   reach the destination domain.  A domain sequence may be supplied
   during path computation to guide the PCEs or are derived via the use of
   Hierarchical
   hierarchical PCE (H-PCE).</t>
        <t>
   During multi-domain path computation, a PCC may request
   specific domains to be included or excluded in the domain sequence
   using the Include Route Object (IRO) <xref target="RFC5440"/> target="RFC5440" format="default"/> and Exclude Route
   Object (XRO) <xref target="RFC5521"/>. target="RFC5521" format="default"/>. The use of Autonomous Number (AS) as an
   abstract node representing a domain is defined in <xref target="RFC3209"/>. target="RFC3209" format="default"/>.
   <xref target="RFC7897"/> target="RFC7897" format="default"/> specifies new sub-objects subobjects to include or exclude domains
   such as an IGP area or a 4-Byte 4-byte AS number.</t>
        <t>
   An operator may also need to avoid a path that uses specified nodes
   for administrative reasons, or if reasons.  If a specific connectivity service is
   required to have a 1+1 protection capability, two
   completely separate disjoint
   paths must be established.
 A mechanism known as
   Shared Risk Link Group (SRLG) information may be used to ensure
   path diversity.</t>
      </section>
    </section>
    <section title="Applicability anchor="sect-5" numbered="true" toc="default">
      <name>Applicability of the PCE to Inter-area Traffic Engineering" anchor="sect-5"><t> Engineering</name>
      <t>
   As networks increase in size and complexity, it may be required to
   introduce scaling methods to reduce the amount of information
   flooded within the network and make the network more manageable. An
   IGP hierarchy is designed to improve IGP scalability by dividing the
   IGP domain into areas and limiting the flooding scope of topology
   information to within area boundaries. This restricts visibility of
   the area to routers in a single area. If a router needs to compute
   the route to a destination located in another area, a method would
   be required to compute a path across area boundaries.</t>
      <t>
   In order to support multiple vendors in a network, network in cases where
   data or control plane control-plane technologies cannot interoperate, it is useful
   to divide the network into vendor domains. Each vendor domain is
   an IGP area, and the flooding scope of the topology (as well as any
   other relevant information) is limited to the area boundaries.</t>
      <t>
   Per-domain path computation <xref target="RFC5152"/> target="RFC5152" format="default"/> exists to provide a method of
   inter-area path computation. The per-domain solution is based on
   loose hop routing with an Explicit Route Object (ERO) expansion on
   each Area Border Router (ABR).  This allows an LSP to be established
   using a constrained path, however path. However, at least two issues exist:</t>

	<t><list style="symbols"><t>This
      <ul spacing="normal">
        <li>This method does not guarantee an optimal constrained path.</t>

	<t>The path.</li>
        <li>The method may require several crankback signaling messages, as per
     <xref target="RFC4920"/>, target="RFC4920" format="default"/>, increasing signaling traffic and delaying the LSP setup.</t>

	</list>
	</t> setup.</li>
      </ul>
      <t>
   The
   PCE-based architecture <xref target="RFC4655"/> target="RFC4655" format="default"/> is designed to solve inter-area
   path computation problems. The issue of limited topology visibility
   is resolved by introducing path computation entities that are able to
   cooperate in order to establish LSPs with the source and destinations
   located in different areas.</t>
      <section title="Inter-area Routing" anchor="sect-5.1"><t> anchor="sect-5.1" numbered="true" toc="default">
        <name>Inter-area Routing</name>
        <t>
   An inter-area TE-LSP is an LSP that transits through at least two
   IGP areas. In a multi-area network, topology visibility remains
   local to a given area for scaling and privacy purposes, a purposes. A node
   in one area will not be able to compute an end-to-end path across
   multiple areas without the use of a PCE.</t>
        <section title="Area anchor="sect-5.1.1" numbered="true" toc="default">
          <name>Area Inclusion and Exclusion" anchor="sect-5.1.1"><t> Exclusion</name>
          <t>
   The BRPC method <xref target="RFC5441"/> target="RFC5441" format="default"/> of path computation provides a more optimal
   method to specify inclusion or exclusion of an ABR. Using the BRPC
   procedure
   procedure, an end-to-end path is recursively computed in reverse from
   the destination domain, domain towards the source domain. Using this method,
   an operator might decide if an area must be included or excluded from
   the inter-area path computation.</t>
        </section>
        <section title="Strict anchor="sect-5.1.2" numbered="true" toc="default">
          <name>Strict Explicit Path and Loose Path" anchor="sect-5.1.2"><t> Path</name>
          <t>
   A strict explicit Path path is defined as a set of strict hops, while a
   loose path is defined as a set of at least one loose hop and zero or
   more strict hops.  It may be useful to indicate, during the
   path computation request, if indicate whether a strict explicit path is required or
   not. during the path computation request. An inter-area path may be strictly explicit or loose (e.g., a
   list of ABRs as loose hops).</t>
          <t>
   A PCC request to a PCE does allow the indication of whether a strict
   explicit path across specific areas (<xref target="RFC7897"/>) target="RFC7897" format="default"/>) is required or
   desired,
   desired or if whether the path request is loose.</t>
        </section>
        <section title="Inter-Area anchor="sect-5.1.3" numbered="true" toc="default">
          <name>Inter-Area Diverse Path Computation" anchor="sect-5.1.3"><t> Computation</name>
          <t>
   It may be necessary to compute a path that is partially or entirely
   diverse,
   diverse from a previously computed path, path to avoid fate sharing of
   a primary service with a corresponding backup service. There are
   various levels of diversity in the context of an inter-area network:</t>

	<t><list style="symbols"><t>Per-area
          <ul spacing="normal">
            <li>Per-area diversity (intra-area (the intra-area path segments are a link, node node, or
     SRLG disjoint.</t>

	<t>Inter-area disjoint).</li>
            <li>Inter-area diversity (end-to-end (the end-to-end inter-area paths are a link,
     node
     node, or SRLG disjoint).</t>

	</list>
	</t> disjoint).</li>
          </ul>
          <t>
   Note that two paths may be disjoint disjointed in the backbone area but non-
   disjoint non-disjointed in peripheral areas. Also, two paths may be node disjoint disjointed
   within areas but may share ABRs, in which case path segments within
   an area is are node disjoint, disjointed but end-to-end paths are not node-disjoint.
   Per-Domain node disjointed.
   Per-domain <xref target="RFC5152"/>, target="RFC5152" format="default"/>, BRPC <xref target="RFC5441"/> target="RFC5441" format="default"/>, and H-PCE <xref target="RFC6805"/> target="RFC6805" format="default"/> mechanisms
   all support the capability to compute diverse paths across multi-area
   topologies.</t>
        </section>
      </section>
    </section>
    <section title="Applicability anchor="sect-6" numbered="true" toc="default">
      <name>Applicability of the PCE to Inter-AS Traffic Engineering" anchor="sect-6"><t> Engineering</name>
      <t>
   As discussed in section 4 (Applicability of the PCE to Inter-area
   Traffic Engineering) <xref target="sect-5" format="default"/> (<xref target="sect-5" format="title" />), it is necessary to divide the network into
   smaller administrative domains, or ASes. If an LSR within an AS needs
   to compute a path across an AS boundary, it must also use an inter-AS
   computation technique. <xref target="RFC5152"/> target="RFC5152" format="default"/> defines mechanisms for the
   computation of inter-domain TE LSPs using network elements along the
   signaling paths to compute per-domain constrained path segments.</t>
      <t>
   The PCE was designed to be capable of computing MPLS and GMPLS paths
   across AS boundaries. This section outlines the features of a
   PCE-enabled solution for computing inter-AS paths.</t>
      <section title="Inter-AS Routing" anchor="sect-6.1"><section title="AS anchor="sect-6.1" numbered="true" toc="default">
        <name>Inter-AS Routing</name>
        <section anchor="sect-6.1.1" numbered="true" toc="default">
          <name>AS Inclusion and Exclusion" anchor="sect-6.1.1"><t> Exclusion</name>
          <t>
   <xref target="RFC5441"/> target="RFC5441" format="default"/> allows the specifying specification of inclusion or exclusion of an AS or an ASBR.
   ASBR inclusion or exclusion. Using this method, an operator might decide if whether an AS
   must be include included or exclude excluded from the inter-AS path computation.
   Exclusion and/or inclusion could also be specified at any step in
   the LSP path computation process by a PCE (within the BRPC
   algorithm)
   algorithm), but the best practice would be to specify them at the
   edge. In opposition to the strict and loose path, AS inclusion or
   exclusion doesn't impose topology disclosure as ASes and their
   interconnection are public
   entity as well as their interconnection.</t>
   entities.</t>
        </section>
      </section>
      <section title="Inter-AS anchor="sect-6.2" numbered="true" toc="default">
        <name>Inter-AS Bandwidth Guarantees" anchor="sect-6.2"><t> Guarantees</name>
        <t>
   Many operators with multi-AS domains will have deployed the MPLS-TE
   DiffServ
   Diffserv either across their entire network or at the domain edges
   on CE-PE links. In situations where strict QOS QoS bounds are required,
   admission control inside the network may also be required.</t>
        <t>
   When the propagation delay can be bounded, the performance targets,
   such as maximum one-way transit delay delay, may be guaranteed by providing
   bandwidth guarantees along the DiffServ-enabled path, these Diffserv-enabled path. These
   requirements are described in <xref target="RFC4216"/>.</t> target="RFC4216" format="default"/>.</t>
        <t>
   One typical example of the requirements in <xref target="RFC4216"/> target="RFC4216" format="default"/> is to provide
   bandwidth guarantees over an end-to-end path for VoIP traffic
   classified as an EF (Expedited Forwarding) class in a DiffServ-enabled Diffserv-enabled
   network. In the case cases where the EF path is extended across multiple
   ASes, an inter-AS bandwidth guarantee would be required.</t>
        <t>
   Another case for an inter-AS bandwidth guarantee is the requirement for
   guaranteeing to guarantee a certain amount of transit bandwidth across one or
   multiple ASes.</t>
      </section>
      <section title="Inter-AS Recovery" anchor="sect-6.3"><t> anchor="sect-6.3" numbered="true" toc="default">
        <name>Inter-AS Recovery</name>
<t>
   During a path computation process, a PCC request may contain the
   requirement to compute a backup LSP for protecting the primary LSP, such as
   1+1 protection.
   A single LSP or multiple backup LSPs may also be
   used for a group of primary LSPs, LSPs; this is typically known as m:n
   protection.</t>
        <t>
   Other inter-AS recovery mechanisms include <xref target="RFC4090"/> target="RFC4090" format="default"/>, which adds fast
   re-route Fast
   Reroute (FRR) protection to an LSP. So, the PCE could be used to
   trigger computation of backup tunnels in order to protect Inter-AS inter-AS
   connectivity.</t>
        <t>
   Inter-AS recovery clearly requires backup LSPs for service
   protection
   protection, but it would also be advisable to have multiple PCEs
   deployed for path computation redundancy, especially for service
   restoration in the event of catastrophic network failure.</t>
      </section>
      <section title="Inter-AS anchor="sect-6.4" numbered="true" toc="default">
        <name>Inter-AS PCE Peering Policies" anchor="sect-6.4"><t> Policies</name>
        <t>
   Like BGP peering policies, inter-AS PCE peering policies is a
   requirement are required for
   an operator. In an inter-AS BRPC process, the PCE must
   cooperate in order to compute the end-to-end LSP. So, Therefore, the AS path
   must not only follow technical constraints, e.g. e.g., bandwidth
   availability, but also the policies defined by the operator.</t>

        <t>
   Typically
   Typically, PCE interconnections at an AS level must follow the agreed
   contract obligations, also known as peering agreements. The PCE
   peering policies are the result of the contract negotiation and
   govern the relation between the different PCE.</t> PCEs.</t>
      </section>
    </section>
    <section title="Multi-domain anchor="sect-7" numbered="true" toc="default">
      <name>Multi-domain PCE Deployment Options" anchor="sect-7"><section title="Traffic Options</name>
      <section anchor="sect-7.1" numbered="true" toc="default">
        <name>Traffic Engineering Database and Synchronization" anchor="sect-7.1"><t> Synchronization</name>
        <t>
   An optimal path computation requires knowledge of the available
   network resources, including nodes and links, constraints,
   link connectivity, available bandwidth, and link costs.  The PCE
   operates on a view of the network topology as presented by a
   TED.  As discussed in <xref target="RFC4655"/> target="RFC4655" format="default"/>, the TED used by a PCE may be learnt learned
   by the relevant IGP extensions.</t>
        <t>
   Thus, the PCE may operate its TED is by participating
   in the IGP running in the network.  In an MPLS-TE network, this
   would require OSPF-TE <xref target="RFC3630"/> target="RFC3630" format="default"/> or ISIS-TE <xref target="RFC5305"/>. target="RFC5305" format="default"/>.  In a GMPLS
   network
   network, it would utilize the GMPLS extensions to OSPF and IS-IS
   defined in <xref target="RFC4203"/> target="RFC4203" format="default"/> and <xref target="RFC5307"/>. Inter-as target="RFC5307" format="default"/>. Inter-AS connectivity
   information may be populated via <xref target="RFC5316"/> target="RFC5316" format="default"/> and <xref target="RFC5392"/>.</t> target="RFC5392" format="default"/>.</t>
        <t>
   An alternative method to provide providing network topology and resource
   information is offered by <xref target="RFC7752"/>, target="RFC7752" format="default"/>, which is described in the
   following section.</t>
        <section title="Applicability anchor="sect-7.1.1" numbered="true" toc="default">
          <name>Applicability of BGP-LS to PCE" anchor="sect-7.1.1"><t> PCE</name>
          <t>
   The concept of the exchange of TE information between Autonomous Systems
   (ASes) is discussed in <xref target="RFC7752"/>. target="RFC7752" format="default"/>.  The information exchanged in this
   way could be the full TE information from the AS, an aggregation of
   that information, or a representation of the potential connectivity
   across the AS.  Furthermore, that information could be updated
   frequently (for example, for every new LSP that is set up across the
   AS) or only at threshold-crossing events.</t>
          <t>
   In an H-PCE deployment, the parent PCE will require the inter-domain
   topology and link status between child domains. This information may
   be learnt learned by a BGP-LS speaker and provided to the parent PCE,
   furthermore PCE.
   Furthermore, link-state performance performance, including delay, available
   bandwidth
   bandwidth, and utilized bandwidth bandwidth, may also be provided to the parent
   PCE for optimal path link selection.</t>
        </section>
      </section>
      <section title="Pre-Planning anchor="sect-7.2" numbered="true" toc="default">
        <name>Pre-planning and Management-Based Solutions" anchor="sect-7.2"><t> Solutions</name>
        <t>
   Offline path computation is performed ahead of time, time before the LSP
   setup is requested.  That means that it is requested by, by or performed
   as part of, of an Operation Support System (OSS) management application.
   This model can be seen in Section 5.5 of <xref target="RFC4655"/>.</t> target="RFC4655" section="5.5" sectionFormat="of"/>.</t>
        <t>
   The offline model is particularly appropriate to for long-lived LSPs
   (such as those present in a transport network) or for planned
   responses to network failures.  In these scenarios, more planning is
   normally a feature of LSP provisioning.</t>

	<figure><artwork><![CDATA[

<t>
The management system may also use a PCE and BRPC to pre-plan an AS
sequence, and the source domain PCE and per-domain path
computation to be used when the actual end-to-end path is
required. This model may also be used where the operator
wishes to retain full manual control of the placement of LSPs,
using the PCE only as a computation tool to assist the operator, operator and
not as part of an automated network.
]]></artwork>
	</figure>
</t>
        <t>
   In environments where operators peer with each other to provide end-
   to-end end-to-end
	paths, the operator responsible for each domain must agree
   to what on the
	extent to which paths must be pre-planned or manually controlled.</t>
      </section>
    </section>
    <section title="Domain Confidentiality" anchor="sect-8"><t> anchor="sect-8" numbered="true" toc="default">
      <name>Domain Confidentiality</name>
      <t>
   This section discusses the techniques that co-operating cooperating PCEs
   can use to compute inter-domain paths without each domain
   disclosing sensitive internal topology information (such as
   explicit nodes or links within the domain) to the other domains.</t>

      <t>
   Confidentiality typically applies to inter-provider (inter-AS) PCE
   communication.
   Where the TE LSP crosses multiple domains (ASes or areas), the path may be
   computed by multiple PCEs that cooperate
   together. together, with each local PCE
   responsible for computing a segment of the path.
 With each local PCE responsible for computing a segment
   of the path.</t>

      <t>
   In situations where ASes are administered by separate Service
   Providers, it would break confidentiality rules for a PCE to supply
   a
   path segment details to a PCE responsible for another domain, thus
   disclosing AS-internal or area topology information.</t>
      <section title="Loose Hops" anchor="sect-8.1"><t> anchor="sect-8.1" numbered="true" toc="default">
        <name>Loose Hops</name>
        <t>
   A method for preserving the confidentiality of the path segment is
   for the PCE to return a path containing a loose hop in place of the
   segment that must be kept confidential.  The concept of loose and
   strict hops for the route of a TE LSP is described in <xref target="RFC3209"/>.</t> target="RFC3209" format="default"/>.</t>
<t>
   <xref target="RFC5440"/> target="RFC5440" format="default"/> supports the use of paths with
   loose hops, and it is a
   local policy decision at a PCE hops; whether it returns a full explicit
   path with strict hops or uses loose hops. hops is a
   local policy decision at a PCE.  A path computation
   request may require an explicit path with strict hops, hops or may allow
   loose hops hops, as detailed in <xref target="RFC5440"/>.</t> target="RFC5440" format="default"/>.</t>
      </section>
      <section title="Confidential anchor="sect-8.2" numbered="true" toc="default">
        <name>Confidential Path Segments and Path Keys" anchor="sect-8.2"><t> Path-Keys</name>
        <t>
   <xref target="RFC5520"/> target="RFC5520" format="default"/> defines the concept and mechanism
   of a Path-Key. A Path-Key
   is a token that replaces the path segment information in an explicit
   route. The Path-Key allows the explicit route information to be
   encoded and is contained in the PCEP Path Computation Element Communication Protocol (PCEP) (<xref target="RFC5440"/>) target="RFC5440" format="default"/>) messages exchanged between the
   PCE and PCC.</t>
        <t>
   This Path-Key technique allows explicit route information to be used
   for end-to-end path computation, computation without disclosing internal topology
   information between domains.</t>
      </section>
    </section>
    <section title="Point-to-Multipoint" anchor="sect-9"><t> anchor="sect-9" numbered="true" toc="default">
      <name>Point to Multipoint</name>
      <t>
   For inter-domain point-to-multipoint application scenarios using
   MPLS-TE LSPs, the complexity of domain sequences, domain policies,
   and the choice and number of domain interconnects is magnified compared to
   point-to-point path computations. As the size of the network
   grows, the number of leaves and branches increase, increases, further
   increasing the complexity of the overall path computation problem.
   A solution for managing point-to-multipoint path computations may
   be achieved using the PCE inter-domain point-to-multipoint path
   computation <xref target="RFC7334"/> target="RFC7334" format="default"/> procedure.</t>
    </section>
    <section title="Optical Domains" anchor="sect-10"><t> anchor="sect-10" numbered="true" toc="default">
      <name>Optical Domains</name>
      <t>
   The International Telecommunications Telecommunication Union (ITU) defines the ASON
   architecture in <xref target="G-8080"/>. target="G-8080" format="default"/>. <xref target="G-7715"/> target="G-7715" format="default"/> defines the routing architecture
   for ASON and introduces a hierarchical architecture. In this
   architecture, the Routing Areas (RAs) have a hierarchical
   relationship between different routing levels, which means a parent
   (or higher level) RA can contain multiple child RAs. The
   interconnectivity of the lower RAs is visible to the higher-level RA.</t>
      <t>
   In the ASON framework, a path computation request is termed a Route
   Query. route
   query. This query is executed before signaling is used to establish
   an LSP LSP, which is termed a Switched Connection (SC) or a Soft Permanent
   Connection (SPC).
  <xref target="G-7715-2"/> target="G-7715-2" format="default"/> defines the requirements and
   architecture for the functions performed by Routing Controllers (RC)
   during the operation of remote route queries - an queries. An RC is synonymous
   with a PCE.</t>
      <t>
   In the ASON routing environment, an RC responsible for an RA may
   communicate with its neighbor RC to request the computation of an
   end-to-end path across several RAs. The path computation components
   and sequences are defined as follows:</t>

	<t><list style="symbols"><t>Remote
      <ul spacing="normal">

        <li>Remote route query. An operation where a routing controller Routing Controller
     communicates with another routing controller, Routing Controller, which does not have
     the same set of layer resources, in order to compute a routing
     path in a collaborative manner.</t>

	<t>Route manner.</li>
        <li>Route query requester. The connection controller or RC that sends a
     route query message to a routing controller requesting for Routing Controller that requests one or
     more routing paths that satisfy satisfying a set of routing constraints.</t>

	<t>Route constraints.</li>

        <li>Route query responder. An RC that performs the path computation
        upon reception of a route query message from a routing controller Routing Controller or
        connection controller, sending and sends a response back at the end of
     computation.</t>

	</list>
	</t> the
        computation.</li>
      </ul>
      <t>
   When computing an end-to-end connection, the route may be computed by
   a single RC or multiple RCs in a collaborative manner manner, and the two
   scenarios can be considered a centralized remote route query model
   and a distributed remote route query model. RCs in an ASON environment
   can also use the hierarchical PCE <xref target="RFC6805"/> target="RFC6805" format="default"/>
   model to match fully match the
   ASON hierarchical routing model.</t>
      <section title="Abstraction anchor="sect-10.1" numbered="true" toc="default">
        <name>Abstraction and Control of TE Networks (ACTN)" anchor="sect-10.1"><t> (ACTN)</name>
        <t>
   Where a single operator operates multiple TE domains (including
   optical environments) then environments), an Abstraction and Control of TE Networks
   (ACTN) framework <xref target="RFC8453"/> target="RFC8453" format="default"/> may be used to create an abstracted
   (virtualized network) view of underlay interconnected underlay-interconnected domains. This
   underlay connectivity is then be exposed to higher-layer control
   entities and applications.</t>
        <t>
   ACTN describes the method and procedure for coordinating the
   underlay per-domain Physical Provisioning Network Controllers (PNCs), which may
   be PCEs, via a hierarchical model to facilitate setup of
   end-to-end connections across inter-connected interconnected TE domains.</t>
      </section>
    </section>
    <section title="Policy" anchor="sect-11"><t> anchor="sect-11" numbered="true" toc="default">
      <name>Policy</name>
      <t>
   Policy is important in the deployment of new services and the
   operation of the network. <xref target="RFC5394"/> target="RFC5394" format="default"/> provides a framework for PCE-
   based PCE-based policy-enabled path computation. This framework is based on
   the Policy Core Information Model (PCIM) as defined in <xref target="RFC3060"/> target="RFC3060" format="default"/> and
   further extended by <xref target="RFC3460"/>.</t> target="RFC3460" format="default"/>.</t>
      <t>
   When using a PCE to compute inter-domain paths, policy may be
   invoked by specifying:</t>

	<t><list style="symbols"><t>Each specifying the following:</t>
      <ul spacing="normal">
        <li>Each PCC must select which computations it will be requested to request from a PCE;</t>

	<t>Each PCE.</li>
        <li>Each PCC must select which PCEs it will use;</t>

	<t>Each use.</li>
        <li>Each PCE must determine which PCCs are allowed to use its services
     and for what computations;</t>

	<t>The computations.</li>
        <li>The PCE must determine how to collect the information in its TED,
     whom to trust for that information, and how to refresh/update the
     information;</t>

	<t>Each
     information.</li>
        <li>Each PCE must determine which objective functions and which algorithms to apply.</t>

	</list>
	</t> apply.</li>
      </ul>
    </section>
    <section title="Manageability Considerations" anchor="sect-12"><t> anchor="sect-12" numbered="true" toc="default">
      <name>Manageability Considerations</name>
      <t>
   General PCE management considerations are discussed in <xref target="RFC4655"/>. target="RFC4655" format="default"/>.
   In the case of multi-domains within a single service provider
   network, the management responsibility for each PCE would most
   likely be handled by the same service provider.  In the case of
   multiple ASes within different service provider networks, it will
   likely be necessary for each PCE to be configured and managed
   separately by each participating service provider, with policy
   being implemented based on a previously agreed set of principles.</t>
      <section title="Control anchor="sect-12.1" numbered="true" toc="default">
        <name>Control of Function and Policy" anchor="sect-12.1"><t> Policy</name>
        <t>
   As per PCEP <xref target="RFC5440"/> target="RFC5440" format="default"/>, PCEP implementation allow allows the user to configure
   a number of PCEP session parameters. These are detailed in section
   8.1 of <xref target="RFC5440"/>.</t> target="RFC5440" section="8.1" sectionFormat="of"/>.</t>
        <t>
   In H-PCE deployments deployments, the administrative entity responsible for the
   management of the parent PCEs for multi-areas would typically be a
   single service provider. In the multiple ASes (managed by different
   service providers), it may be necessary for a third party to manage
   the parent PCE.</t>
      </section>
      <section title="Information anchor="sect-12.2" numbered="true" toc="default">
        <name>Information and Data Models" anchor="sect-12.2"><t> Models</name>
        <t>
   A PCEP MIB module is defined in <xref target="RFC7420"/> that target="RFC7420" format="default"/>,
   which describes managed
   objects for modeling of PCEP communication communication, including:</t>

	<t><list style="symbols"><t>PCEP
        <ul spacing="normal">
          <li>PCEP client configuration and status,</t>

	<t>PCEP status.</li>
          <li>PCEP peer configuration and information,</t>

	<t>PCEP information.</li>
          <li>PCEP session configuration and information,</t>

	<t>Notifications information.</li>
          <li>Notifications to indicate PCEP session changes.</t>

	</list>
	</t> changes.</li>
        </ul>
        <t>
   A YANG module for PCEP has also been proposed <xref target="PCEP-YANG"/>.</t> target="I-D.ietf-pce-pcep-yang" format="default"/>.</t>
        <t>
   An H-PCE MIB module, module or YANG data model, model will be required to
   report parent PCE and child PCE information, including:</t>

	<t><list style="symbols"><t>parent
        <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 PCEs.</li>
          <li>Notification of parent PCE TED updates and changes.</t>

	</list>
	</t> changes.</li>
        </ul>
      </section>
      <section title="Liveness anchor="sect-12.3" numbered="true" toc="default">
        <name>Liveness Detection and Monitoring" anchor="sect-12.3"><t> Monitoring</name>
        <t>
   PCEP includes a keepalive mechanism to check the liveliness of a PCEP
   peer and a notification procedure allowing a PCE to advertise its
   overloaded state to a PCC. In a multi-domain environment environment, <xref target="RFC5886"/> target="RFC5886" format="default"/>
   provides the procedures necessary to monitor the liveliness and
   performances
   performance of a given PCE chain.</t>
      </section>
      <section title="Verifying anchor="sect-12.4" numbered="true" toc="default">
        <name>Verifying Correct Operation" anchor="sect-12.4"><t> Operation</name>
        <t>
   It is important to verify the correct operation of PCEP, PCEP. <xref target="RFC5440"/> target="RFC5440" format="default"/>
   specifies the monitoring of key parameters. These parameters are
   detailed in <xref target="RFC5520"/>.</t> target="RFC5520" format="default"/>.</t>
      </section>
      <section title="Impact anchor="sect-12.5" numbered="true" toc="default">
        <name>Impact on Network Operation" anchor="sect-12.5"><t> Operation</name>
        <t>
   <xref target="RFC5440"/> target="RFC5440" format="default"/> states that in order to avoid any unacceptable impact on
   network operations, a PCEP implementation should allow a limit to be
   placed on the number of sessions that can be set up on a PCEP
   speaker,
   speaker and that it may also be practical to place a limit on the rate
   of messages sent by a PCC and received my by the PCE.</t>
      </section>
    </section>
    <section title="Security Considerations" anchor="sect-13"><t> anchor="sect-13" numbered="true" toc="default">
      <name>Security Considerations</name>
      <t>
   PCEP Security security considerations are discussed in <xref target="RFC5440"/> target="RFC5440" format="default"/> and <xref target="RFC6952"/> target="RFC6952" format="default"/>.
   Potential vulnerabilities include spoofing, snooping, falsification falsification,
   and using PCEP as a mechanism for denial of service attacks.</t>
      <t>
   As PCEP operates over TCP, it may make use of TCP security
   encryption mechanisms, such as Transport Layer Security (TLS) and TCP
   Authentication Option (TCP-AO). Usage of these security mechanisms
   for PCEP is described in <xref target="RFC8253"/>, target="RFC8253" format="default"/>, and recommendations and best
   current practices are described in <xref target="RFC7525"/>.</t> target="RFC7525" format="default"/>.</t>
      <section title="Multi-domain Security" anchor="sect-13.1"><t> anchor="sect-13.1" numbered="true" toc="default">
        <name>Multi-domain Security</name>
        <t>
   Any multi-domain operation necessarily involves the exchange of
   information across domain boundaries.  This does represent represents a
   significant security and confidentiality risk.</t>
        <t>
   It is expected that PCEP is used between PCCs and PCEs belonging that belong to the
   same administrative authority, and authority while also using one of the aforementioned
   encryption mechanisms.
   Furthermore, PCEP allows
   individual PCEs to maintain the confidentiality of their domain path
   information using path-keys.</t>
      </section>
    </section>
    <section title="IANA Considerations" anchor="sect-14"><t> anchor="sect-14" numbered="true" toc="default">
      <name>IANA Considerations</name>
      <t>
   This document makes has no requests for IANA action.</t>

	</section>

	<section title="Acknowledgements" anchor="sect-15"><t>
   The author would like to thank Adrian Farrel for his review, and
   Meral Shirazipour and Francisco Javier Jimenex Chico for their
   comments.</t> actions.</t>
    </section>

  </middle>
  <back>
	<references title="Normative References">
	&RFC3209;
	&RFC3473;
	&RFC4216;
	&RFC4655;
	&RFC4726;
	&RFC5152;
	&RFC5440;
	&RFC5441;
	&RFC5520;
	&RFC5541;
	&RFC6805;

<displayreference target="I-D.ietf-pce-pcep-yang" to="PCEP-YANG"/>

    <references>
      <name>References</name>
      <references>
        <name>Normative References</name>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.3209.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.3473.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.4216.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.4655.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.4726.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.5152.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.5440.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.5441.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.5520.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.5541.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6805.xml"/>
      </references>
	<references title="Informative References">
	&RFC3060;
	&RFC3460;
	&RFC3630;
	&RFC4090;
	&RFC4203;
	&RFC4920;
	&RFC5088;
	&RFC5089;
	&RFC5305;
	&RFC5307;
	&RFC5316;
	&RFC5392;
	&RFC5394;
	&RFC5521;
	&RFC5886;
	&RFC6007;
      <references>
        <name>Informative References</name>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.3060.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.3460.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.3630.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.4090.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.4203.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.4920.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.5088.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.5089.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.5305.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.5307.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.5316.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.5392.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.5394.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.5521.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.5886.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6007.xml"/>

<!-- [G-8080] URL https://www.itu.int/rec/T-REC-G.8080-201202-I/en -->

        <reference anchor="G-8080"><front> anchor="G-8080">
          <front>
            <title>Architecture for the automatically switched optical network (ASON)</title> network</title>
<seriesInfo name="ITU-T Recommendation" value="G.8080/Y.1304"/>
            <author>
	<organization>ITU-T Recommendation G.8080/Y.1304</organization>
              <organization>ITU-T</organization>
            </author>
	<date/>
<date month="February" year="2012"/>
          </front>
        </reference>

<!-- [G-7715] URL https://datatracker.ietf.org/documents/LIAISON/G-7715.htm -->
<!-- this reference has been updated per
https://www.itu.int/rec/T-REC-G.7715/en.
-->
 <reference anchor="G-7715"><front> anchor="G-7715">
          <front>
            <title>Architecture and Requirements requirements for routing in the Automatically Switched Optical Network (ASON)</title>
	    automatically switched optical networks</title>
<seriesInfo name="ITU-T Recommendation" value="G.7715/Y.1706" />
            <author>
	<organization>ITU-T Recommendation G.7715 (2002)</organization>
              <organization>ITU-T</organization>
            </author>
	<date/>
<date month="June" year="2002"/>
          </front>
        </reference>

<!-- [G-7715-2] https://www.itu.int/rec/T-REC-G.7715.2-200702-I/en -->

        <reference anchor="G-7715-2"><front> anchor="G-7715-2">
          <front>
            <title>ASON routing architecture and requirements for remote route
	    query</title>
<seriesInfo name="ITU-T Recommendation" value="G.7715.2/Y.1706.2"/>
            <author>
	<organization>ITU-T Recommendation G.7715.2 (2007)</organization>
	</author>
	<date/>
	</front>

	</reference>
	&RFC6952;
	&RFC7334;
	&RFC7420;
	&RFC7525;
	&RFC7752;
	&RFC7897;
	&RFC8253;
	&RFC8453;
	<reference anchor="PCEP-YANG"><front>
	<title>A YANG Data Model for Path Computation Element Communications Protocol (PCEP)</title>
	<author fullname="D. Dhody" initials="D." surname="Dhody">
	</author>

	<author fullname="J. Hardwick" initials="J." surname="Hardwick">
	</author>

	<author fullname="V. Beeram" initials="V." surname="Beeram">
	</author>

	<author fullname="J. Tantsura" initials="J." surname="Tantsura">
              <organization>ITU-T</organization>
            </author>
<date month="October" year="2018"/> month="February" year="2007"/>
          </front>

	<seriesInfo name="work" value="in progress"/>
        </reference>

        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6952.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7334.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7420.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7525.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7752.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7897.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8253.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8453.xml"/>

<!--  draft-ietf-pce-pcep-yang-13: I-D exists -->
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-pce-pcep-yang.xml"/>

      </references>
    </references>

    <section title="Contributors" anchor="sect-17"><figure><artwork><![CDATA[
Dhruv Dhody
Huawei Technologies
Divyashree anchor="acks" numbered="false" toc="default">
      <name>Acknowledgements</name>
      <t>
   The author would like to thank <contact fullname="Adrian Farrel"/> for his
   review and <contact fullname="Meral Shirazipour"/> and <contact
   fullname="Francisco Javier Jiménez Chico" /> for their comments.</t>
    </section>

    <section anchor="contributors" numbered="false" toc="default">
      <name>Contributors</name>

      <contact fullname="Dhruv Dhody" >
        <organization>Huawei Technologies</organization>
        <address>
          <postal>
            <street>Divyashree Techno Park, Whitefield
Bangalore, Karnataka  560066
India
Email: dhruv.ietf@gmail.com

Quintin Zhao
Huawei Technology
125 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="Quintin Zhao">
        <organization>Huawei Technologies</organization>
        <address>
          <postal>
            <street>125 Nagog Technology Park
Acton, MA  01719
US
Email: qzhao@huawei.com

Julien Meuric
France Telecom
2, Park</street>
            <city>Acton</city>
            <region>MA</region><code>01719</code>
            <country>United States of America</country>
          </postal>
          <email>qzhao@huawei.com</email>
        </address>
      </contact>

      <contact fullname="Julien Meuric">
        <organization>France Telecom</organization>
        <address>
          <postal>
            <street>2, avenue Pierre-Marzin
22307 Lannion Cedex
Email: julien.meuric@orange-ftgroup.com

Olivier Dugeon
France Telecom
2, Pierre-Marzin</street>
            <city>Lannion Cedex</city><code>22307</code>
            <country>France</country>
          </postal>
          <email>julien.meuric@orange.com</email>
        </address>
      </contact>

      <contact fullname="Olivier Dugeon">
        <organization>France Telecom</organization>
        <address>
          <postal>
            <street>2, avenue Pierre-Marzin
22307 Lannion Cedex
Email: olivier.dugeon@orange-ftgroup.com

Jon Hardwick
Metaswitch Networks
100 Pierre-Marzin</street>
            <city>Lannion Cedex</city><code>22307</code>
            <country>France</country>
          </postal>
          <email>olivier.dugeon@orange.com</email>
        </address>
      </contact>

      <contact fullname="Jon Hardwick" >
        <organization>Metaswitch Networks</organization>
        <address>
          <postal>
            <street>100 Church Street
Enfield, Middlesex
United Kingdom
Email: jonathan.hardwick@metaswitch.com

Oscar Gonzalez Street</street>
	    <city>Enfield</city>
            <code>EN2 6BQ</code>
            <country>United Kingdom</country>
          </postal>
          <email>jonathan.hardwick@metaswitch.com</email>
        </address>
      </contact>

      <contact fullname="Óscar González de Dios
Telefonica I+D
Emilio Dios">
        <organization>Telefonica I+D</organization>
        <address>
          <postal>
            <street>Emilio Vargas 6, Madrid
Spain
Email: ogondio@tid.es
]]></artwork>
	</figure> 6</street>
            <city>Madrid</city>
            <country>Spain</country>
          </postal>
          <email>oscar.gonzalezdedios@telefonica.com</email>
        </address>
      </contact>

    </section>

	<section title="Author's Addresses" anchor="sect-18"/>
  </back>

</rfc>