rfc8751xml2.original.xml   rfc8751.xml 
<?xml version='1.0' encoding='utf-8'?> <?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY RFC2119 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.2119.xml">
<!ENTITY RFC4655 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.4655.xml">
<!ENTITY RFC5440 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.5440.xml">
<!ENTITY RFC5520 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.5520.xml">
<!ENTITY RFC5925 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.5925.xml">
<!ENTITY RFC6805 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.6805.xml">
<!ENTITY RFC7525 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.7525.xml">
<!ENTITY RFC8174 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.8174.xml">
<!ENTITY RFC8231 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.8231.xml">
<!ENTITY RFC8253 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.8253.xml">
<!ENTITY RFC8281 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.8281.xml">
<!ENTITY RFC8446 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.8446.xml">
<!ENTITY RFC3209 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.3209.xml">
<!ENTITY RFC3473 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.3473.xml">
<!ENTITY RFC4726 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.4726.xml">
<!ENTITY RFC5623 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.5623.xml">
<!ENTITY RFC8051 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.8051.xml">
<!ENTITY RFC8232 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.8232.xml">
<!ENTITY RFC8453 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.8453.xml">
<!ENTITY RFC8637 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.8637.xml">
<!ENTITY I-D.litkowski-pce-state-sync SYSTEM "https://xml2rfc.ietf.org/public/rf
c/bibxml3/reference.I-D.draft-litkowski-pce-state-sync-06.xml">
<!ENTITY I-D.ietf-pce-hierarchy-extensions SYSTEM "https://xml2rfc.ietf.org/publ
ic/rfc/bibxml3/reference.I-D.draft-ietf-pce-hierarchy-extensions-11.xml">
<!ENTITY I-D.ietf-pce-pcep-yang SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibx
ml3/reference.I-D.draft-ietf-pce-pcep-yang-12.xml">
<!ENTITY I-D.dugeon-pce-stateful-interdomain SYSTEM "https://xml2rfc.ietf.org/pu
blic/rfc/bibxml3/reference.I-D.draft-dugeon-pce-stateful-interdomain-02.xml">
<!ENTITY I-D.ietf-pce-lsp-control-request SYSTEM "https://xml2rfc.ietf.org/publi
c/rfc/bibxml3/reference.I-D.draft-ietf-pce-lsp-control-request-11.xml">
<!ENTITY I-D.ietf-pce-enhanced-errors SYSTEM "https://xml2rfc.ietf.org/public/rf
c/bibxml3/reference.I-D.ietf-pce-enhanced-errors.xml">
<!ENTITY I-D.ietf-pce-stateful-path-protection SYSTEM "https://xml2rfc.ietf.org/
public/rfc/bibxml3/reference.I-D.draft-ietf-pce-stateful-path-protection-11.xml"
>
]>
<rfc submissionType="IETF" docName="draft-ietf-pce-stateful-hpce-15" category="i
nfo" ipr="trust200902">
<!-- Generated by id2xml 1.5.0 on 2019-11-08T17:24:21Z -->
<?rfc compact="yes"?>
<?rfc text-list-symbols="oo*+-"?>
<?rfc subcompact="no"?>
<?rfc sortrefs="no"?>
<?rfc symrefs="yes"?>
<?rfc strict="yes"?>
<?rfc toc="yes"?>
<front>
<title abbrev="Hierarchical Stateful Path Computation E">Hierarchical Sta
teful Path Computation Element (PCE)</title>
<author fullname="Dhruv Dhody" initials="D." surname="Dhody">
<organization>Huawei Technologies</organization>
<address><postal><street>Divyashree Techno Park, Whitefield</street>
<street>Bangalore, Karnataka 560066</street>
<street>India</street>
</postal>
<email>dhruv.ietf@gmail.com</email>
</address>
</author>
<author fullname="Young Lee" initials="Y." surname="Lee"> <!DOCTYPE rfc SYSTEM "rfc2629-xhtml.ent">
<organization>SKKU</organization>
<address><email>younglee.tx@gmail.com</email>
</address>
</author>
<author fullname="Daniele Ceccarelli" initials="D." surname="Ceccarelli"> <rfc xmlns:xi="http://www.w3.org/2001/XInclude" submissionType="IETF"
<organization>Ericsson</organization> consensus="true" docName="draft-ietf-pce-stateful-hpce-15" number="8751"
<address><postal><street>Torshamnsgatan,48</street> category="info" ipr="trust200902" obsoletes="" updates="" xml:lang="en"
<street>Stockholm</street> sortRefs="false" symRefs="true" tocInclude="true" version="3">
<street>Sweden</street>
</postal>
<email>daniele.ceccarelli@ericsson.com</email>
</address>
</author>
<author fullname="Jongyoon Shin" initials="J." surname="Shin"> <!-- xml2rfc v2v3 conversion 2.35.0 -->
<organization>SK Telecom</organization> <!-- Generated by id2xml 1.5.0 on 2019-11-08T17:24:21Z -->
<address><postal><street>6 Hwangsaeul-ro, 258 beon-gil, Bundang-gu, Seong <front>
nam-si,</street>
<street>Gyeonggi-do 463-784</street>
<street>Republic of Korea</street>
</postal>
<email>jongyoon.shin@sk.com</email>
</address>
</author>
<author fullname="Daniel King" initials="D." surname="King"> <title abbrev="Hierarchical Stateful PCE">Hierarchical Stateful Path
<organization>Lancaster University</organization> Computation Element (PCE)</title>
<address><postal><street>UK</street>
</postal>
<email>d.king@lancaster.ac.uk</email>
</address>
</author>
<date month="October" year="2019"/> <seriesInfo name="RFC" value="8751"/>
<workgroup>PCE Working Group</workgroup>
<abstract><t> <author fullname="Dhruv Dhody" initials="D." surname="Dhody">
A Stateful Path Computation Element (PCE) maintains information on <organization>Huawei Technologies</organization>
<address>
<postal>
<street>Divyashree Techno Park, Whitefield</street>
<city>Bangalore</city> <region>Karnataka</region> <code> 560066</code>
<country>India</country>
</postal>
<email>dhruv.ietf@gmail.com</email>
</address>
</author>
<author fullname="Young Lee" initials="Y." surname="Lee">
<organization>Samsung Electronics</organization>
<address>
<email>younglee.tx@gmail.com</email>
</address>
</author>
<author fullname="Daniele Ceccarelli" initials="D." surname="Ceccarelli">
<organization>Ericsson</organization>
<address>
<postal>
<street>Torshamnsgatan, 48</street>
<city>Stockholm</city>
<country>Sweden</country>
</postal>
<email>daniele.ceccarelli@ericsson.com</email>
</address>
</author>
<author fullname="Jongyoon Shin" initials="J." surname="Shin">
<organization>SK Telecom</organization>
<address>
<postal>
<extaddr>6 Hwangsaeul-ro, 258 beon-gil</extaddr>
<street> Bundang-gu, Seongnam-si,</street>
<region>Gyeonggi-do</region> <code>463-784</code>
<country>Republic of Korea</country>
</postal>
<email>jongyoon.shin@sk.com</email>
</address>
</author>
<author fullname="Daniel King" initials="D." surname="King">
<organization>Lancaster University</organization>
<address>
<postal>
<country>UK</country>
</postal>
<email>d.king@lancaster.ac.uk</email>
</address>
</author>
<date month="March" year="2020"/>
<workgroup>PCE Working Group</workgroup>
<abstract>
<t>
A stateful Path Computation Element (PCE) maintains information on
the current network state received from the Path Computation Clients the current network state received from the Path Computation Clients
(PCCs), including: computed Label Switched Path (LSPs), reserved (PCCs), including computed Label Switched Paths (LSPs), reserved
resources within the network, and pending path computation requests. resources within the network, and pending path computation requests.
This information may then be considered when computing the path for a This information may then be considered when computing the path for a
new traffic-engineered LSP or for any associated/dependent LSPs. The new traffic-engineered LSP or for any associated/dependent LSPs. The
Path computation response from a PCE is helpful for the PCC to path-computation response from a PCE helps the PCC to
gracefully establish the computed LSP.</t> gracefully establish the computed LSP.</t>
<t>
<t>
The Hierarchical Path Computation Element (H-PCE) architecture The Hierarchical Path Computation Element (H-PCE) architecture
provides an architecture to allow the optimum sequence of allows the optimum sequence of
inter-connected domains to be selected, and network policy to be interconnected domains to be selected and network policy to be
applied if applicable, via the use of a hierarchical relationship applied if applicable, via the use of a hierarchical relationship
between PCEs.</t> between PCEs.</t>
<t>
<t> Combining the capabilities of stateful PCE and the hierarchical PCE
Combining the capabilities of Stateful PCE and the Hierarchical PCE
would be advantageous. This document describes general considerations would be advantageous. This document describes general considerations
and use cases for the deployment of Stateful, and not Stateless, PCEs and use cases for the deployment of stateful, but not stateless, PCEs
using the Hierarchical PCE architecture.</t> using the hierarchical PCE architecture.</t>
</abstract>
</abstract> </front>
</front> <middle>
<section anchor="sect-1" numbered="true" toc="default">
<middle> <name>Introduction</name>
<section title="Introduction" anchor="sect-1"><section title="Background" <section anchor="sect-1.1" numbered="true" toc="default">
anchor="sect-1.1"><t> <name>Background</name>
The Path Computation Element communication Protocol (PCEP) <xref target="RFC5 <t>
440"/> The Path Computation Element communication Protocol (PCEP) <xref target="RFC5
440" format="default"/>
provides mechanisms for Path Computation Elements (PCEs) to perform provides mechanisms for Path Computation Elements (PCEs) to perform
path computations in response to Path Computation Clients' (PCCs) path computations in response to the requests of Path Computation Clients (PC
requests.</t> Cs).</t>
<t>
<t>
A stateful PCE is capable of considering, for the purposes of path A stateful PCE is capable of considering, for the purposes of path
computation, not only the network state in terms of links and nodes computation, not only the network state in terms of links and nodes
(referred to as the Traffic Engineering Database or TED) but also the (referred to as the Traffic Engineering Database or TED) but also the
status of active services (previously computed paths, and currently status of active services (previously computed paths, and currently
reserved resources, stored in the Label Switched Paths Database reserved resources, stored in the Label Switched Paths Database
(LSP-DB).</t> (LSPDB).</t>
<t>
<t> <xref target="RFC8051" format="default"/> describes general considerations fo
<xref target="RFC8051"/> describes general considerations for a stateful PCE r a stateful PCE
deployment and examines its applicability and benefits, as well as deployment; it also examines its applicability and benefits as well as
its challenges and limitations through a number of use cases.</t> its challenges and limitations through a number of use cases.</t>
<t>
<t> <xref target="RFC8231" format="default"/> describes a set of extensions to PC
<xref target="RFC8231"/> describes a set of extensions to PCEP to provide sta EP to provide stateful
teful control. For its computations, a stateful PCE has access to not only the info
control. A stateful PCE has access to not only the information rmation
carried by the network's Interior Gateway Protocol (IGP), but also carried by the network's Interior Gateway Protocol (IGP), but also
the set of active paths and their reserved resources for its the set of active paths and their reserved resources. The additional state
computations. The additional state allows the PCE to compute allows the PCE to compute
constrained paths while considering individual LSPs and their constrained paths while considering individual LSPs and their
interactions. <xref target="RFC8281"/> describes the setup, maintenance and interactions. <xref target="RFC8281" format="default"/> describes the setup, maintenance, and
teardown of PCE-initiated LSPs under the stateful PCE model.</t> teardown of PCE-initiated LSPs under the stateful PCE model.</t>
<t>
<t> <xref target="RFC8231" format="default"/> also describes the active stateful
<xref target="RFC8231"/> also describes the active stateful PCE. The PCE. The
active PCE functionality allows a PCE to reroute an existing LSP or make active PCE functionality allows a PCE to reroute an existing LSP, make
changes to the attributes of an existing LSP, or delegate control of changes to the attributes of an existing LSP, or delegate control of
specific LSPs to a new PCE.</t> specific LSPs to a new PCE.</t>
<t>
<t> The ability to compute constrained paths for Traffic Engineering (TE) LSPs in
The ability to compute constrained paths for TE LSPs in Multiprotocol Multiprotocol
Label Switching (MPLS) and Generalized MPLS (GMPLS) networks across Label Switching (MPLS) and Generalized MPLS (GMPLS) networks across
multiple domains has been identified as a key motivation for PCE multiple domains has been identified as a key motivation for PCE
development. <xref target="RFC6805"/> describes a Hierarchical PCE (H-PCE) development. <xref target="RFC6805" format="default"/> describes a Hierarchi
architecture which can be used for computing end-to-end paths for cal PCE (H-PCE)
inter-domain MPLS Traffic Engineering (TE) and GMPLS Label Switched architecture that can be used for computing end-to-end paths for
Paths (LSPs). Within the Hierarchical PCE (H-PCE) architecture interdomain MPLS TE and GMPLS Label Switched
<xref target="RFC6805"/>, the Parent PCE (P-PCE) is used to compute a multi-d Paths (LSPs). Within the H-PCE architecture
omain <xref target="RFC6805" format="default"/>, the Parent PCE (P-PCE) is used to
compute a multidomain
path based on the domain connectivity information. A Child PCE path based on the domain connectivity information. A Child PCE
(C-PCE) may be responsible for a single domain or multiple domains. (C-PCE) may be responsible for a single domain or multiple domains.
The C-PCE is used to compute the intra-domain path based on its The C-PCE is used to compute the intradomain path based on its
domain topology information.</t> domain topology information.</t>
<t>
<t>
This document presents general considerations for stateful PCEs, and This document presents general considerations for stateful PCEs, and
not Stateless PCEs, in the hierarchical PCE architecture. It focuses not stateless PCEs, in the hierarchical PCE architecture. It focuses
on the behavior changes and additions to the existing stateful PCE on the behavior changes and additions to the existing stateful PCE
mechanisms (including PCE-initiated LSP setup and active stateful PCE mechanisms (including PCE-initiated LSP setup and active stateful PCE
usage) in the context of networks using the H-PCE architecture.</t> usage) in the context of networks using the H-PCE architecture.</t>
<t>
<t> In this document, Sections <xref target="sect-3.1" format="counter"/> and
In this document, Sections 3.1 and 3.2 focus on end to end (E2E) <xref target="sect-3.2" format="counter" /> focus on end-to-end (E2E)
inter-domain TE LSP. <xref target="sect-3.3.1"/> describes the operations for interdomain TE LSP. <xref target="sect-3.3.1" format="default"/> describes th
stitching Per-Domain LSPs.</t> e operations for
stitching per-domain LSPs.</t>
</section> </section>
<section anchor="sect-1.2" numbered="true" toc="default">
<section title="Use cases and Applicability of Hierarchical Stateful PCE" <name>Use Cases and Applicability of Hierarchical Stateful PCE</name>
anchor="sect-1.2"><t> <t>
As per <xref target="RFC6805"/>, in the hierarchical PCE architecture, a P-PC As per <xref target="RFC6805" format="default"/>, in the hierarchical PCE arc
E hitecture, a P-PCE
maintains a domain topology map that contains the child domains and maintains a domain topology map that contains the child domains and
their interconnections. Usually, the P-PCE has no information about their interconnections. Usually, the P-PCE has no information about
the content of the child domains. But if the PCE is applied to the the content of the child domains. But, if the PCE is applied to the
Abstraction and Control of TE Networks (ACTN) <xref target="RFC8453"/> as des Abstraction and Control of TE Networks (ACTN) <xref target="RFC8453"
cribed format="default"/> as described
in <xref target="RFC8637"/>, the Provisioning Network Controller (PNC) can pr in <xref target="RFC8637" format="default"/>, the Provisioning Network
ovide Controller (PNC) can provide
an abstract topology to the Multi-Domain Service Coordinator (MDSC). an abstract topology to the Multi-Domain Service Coordinator (MDSC).
Thus the P-PCE in MDSC could be aware of topology information in much Thus, the P-PCE in MDSC could be aware of topology information in much
more detail than just the domain topology.</t> more detail than just the domain topology.</t>
<t>
<t> In a PCEP session between a PCC (ingress) and a C-PCE, the C-PCE acts
In a PCEP session between a PCC (Ingress) and a C-PCE, the C-PCE acts as per the stateful PCE operations described in <xref target="RFC8231" format
as per the stateful PCE operations described in <xref target="RFC8231"/> and ="default"/> and
<xref target="RFC8281"/>. The same C-PCE behaves as a PCC on the PCEP session <xref target="RFC8281" format="default"/>. The same C-PCE behaves as a PCC on
towards the P-PCE. The P-PCE is stateful in nature and thus maintains the PCEP session
the state of the inter-domain LSPs that are reported to it. The towards the P-PCE. The P-PCE is stateful in nature; thus, it maintains
inter-domain LSP could also be delegated by the C-PCE to the P-PCE, the state of the interdomain LSPs that are reported to it. The
so that the P-PCE could update the inter-domain path. The trigger for interdomain LSP could also be delegated by the C-PCE to the P-PCE,
so that the P-PCE could update the interdomain path. The trigger for
this update could be the LSP state change reported for this LSP or this update could be the LSP state change reported for this LSP or
any other LSP. It could also be a change in topology at the P-PCE, any other LSP. It could also be a change in topology at the P-PCE,
such as inter-domain link status change. In case of use of stateful such as interdomain link status change. In case of use of stateful
H-PCE in ACTN, a change in abstract topology learned by the P-PCE H-PCE in ACTN, a change in abstract topology learned by the P-PCE
could also trigger the update. Some other external factors (such as a could also trigger the update. Some other external factors (such as a
measurement probe) could also be a trigger at the P-PCE. Any such measurement probe) could also be a trigger at the P-PCE. Any such
update would require an inter-domain path recomputation as described update would require an interdomain path recomputation as described
in <xref target="RFC6805"/>.</t> in <xref target="RFC6805" format="default"/>.</t>
<t>
<t> The end-to-end interdomain path computation and setup is described in
The end-to-end inter-domain path computation and setup is described in <xref target="RFC6805" format="default"/>. Additionally, a per-domain
<xref target="RFC6805"/>. Additionally, a per-domain stitched LSP model is stitched-LSP model is
also applicable in a P-PCE initiation model. <xref target="sect-3.1"/>, also applicable in a P-PCE initiation model. Sections <xref target="sect-3.1"
<xref target="sect-3.2"/>, and <xref target="sect-3.3"/> describe the format="counter"/>, <xref target="sect-3.2" format="counter"/>, and
end-to-end Contiguous LSP setup, whereas <xref target="sect-3.3.1"/> <xref target="sect-3.3" format="counter"/> describe the
end-to-end contiguous LSP setup, whereas <xref target="sect-3.3.1" format="de
fault"/>
describes the per-domain stitching.</t> describes the per-domain stitching.</t>
<section anchor="sect-1.2.1" numbered="true" toc="default">
<section title="Applicability to ACTN" anchor="sect-1.2.1"><t> <name>Applicability to ACTN</name>
<xref target="RFC8453"/> describes a framework for the Abstraction and Contro <t>
l of TE <xref target="RFC8453" format="default"/> describes a framework for the
Abstraction and Control of TE
Networks (ACTN), where each Provisioning Network Controller (PNC) is Networks (ACTN), where each Provisioning Network Controller (PNC) is
equivalent to a C-PCE, and the P-PCE is the Multi-Domain Service equivalent to a C-PCE, and the P-PCE is the Multi-Domain Service
Coordinator (MDSC). The Per-Domain stitched LSP as per the Coordinator (MDSC). The per-domain stitched LSP is well suited for ACTN
Hierarchical PCE architecture described in <xref target="sect-3.3.1"/> and Se deployments, as per the
ction hierarchical PCE architecture described in <xref target="sect-3.3.1"
4.1 is well suited for ACTN deployments.</t> format="default"/> of this document and <xref target="RFC8453" sectionFormat=
"of"
<t> section="4.1" />.</t>
<xref target="RFC8637"/> examines the applicability of PCE to the ACTN framew <t>
ork. To <xref target="RFC8637" format="default"/> examines the applicability of PCE t
support the function of multi-domain coordination via hierarchy, the o the ACTN framework. To
support the function of multidomain coordination via hierarchy, the
hierarchy of stateful PCEs plays a crucial role.</t> hierarchy of stateful PCEs plays a crucial role.</t>
<t>
<t>
In the ACTN framework, a Customer Network Controller (CNC) can request the In the ACTN framework, a Customer Network Controller (CNC) can request the
MDSC to check whether there is a possibility to meet Virtual Network (VN) MDSC to check whether there is a possibility to meet Virtual Network (VN)
requirements before requesting that the VN be provisioned. The H-PCE requirements before requesting that the VN be provisioned. The H-PCE
architecture as described in <xref target="RFC6805"/> can support this architecture as described in <xref target="RFC6805" format="default"/> can su
function using PCReq and PCRep messages between the P-PCE and C-PCEs. When pport this
function using Path Computation Request and Reply (PCReq and PCRep,
respectively) messages between the P-PCE and C-PCEs. When
the CNC requests VN provisioning, the MDSC decomposes this request into the CNC requests VN provisioning, the MDSC decomposes this request into
multiple inter-domain LSP provisioning requests, which might be further multiple interdomain LSP provisioning requests, which might be further
decomposed to per-domain path segments. This is described in <xref decomposed into per-domain path segments. This is described in
target="sect-3.3.1"/>. The MDSC uses the LSP Initiate Request (PCInitiate) <xref target="sect-3.3.1" format="default"/>. The MDSC uses the LSP
initiate request (PCInitiate)
message from the P-PCE towards the C-PCE, and the C-PCE reports the state message from the P-PCE towards the C-PCE, and the C-PCE reports the state
back to the P-PCE via a Path Computation State Report (PCRpt) message. The back to the P-PCE via a Path Computation State Report (PCRpt) message. The
P-PCE could make changes to the LSP via the use of a Path Computation P-PCE could make changes to the LSP via the use of a Path Computation
Update Request (PCUpd) message.</t> Update Request (PCUpd) message.</t>
<t>
<t>
In this case, the P-PCE (as MDSC) interacts with multiple C-PCEs (as In this case, the P-PCE (as MDSC) interacts with multiple C-PCEs (as
PNCs) along the inter-domain path of the LSP.</t> PNCs) along the interdomain path of the LSP.</t>
</section>
</section> <section anchor="sect-1.2.2" numbered="true" toc="default">
<name>End-to-End Contiguous LSP</name>
<section title="End-to-End Contiguous LSP" anchor="sect-1.2.2"><t> <t>
Different signaling options for inter-domain RSVP-TE are identified in Different signaling options for interdomain RSVP-TE are identified in
<xref target="RFC4726"/>. Contiguous LSPs are achieved using the <xref target="RFC4726" format="default"/>. Contiguous LSPs are achieved u
procedures of <xref target="RFC3209"/> and <xref target="RFC3473"/> to sing the
create a single end-to-end LSP that spans all domains. <xref procedures of <xref target="RFC3209" format="default"/> and <xref target=
target="RFC6805"/> describes the technique to establish the optimum "RFC3473" format="default"/> to
create a single end-to-end LSP that spans all domains. <xref target="RFC6
805" format="default"/> describes the technique for establishing the optimum
path when the sequence of domains is not known in advance.</t> path when the sequence of domains is not known in advance.</t>
<t>
<t> That document shows how the PCE architecture can be extended to allow the
It shows how the PCE architecture can be extended to allow the optimum sequence of domains to be selected and the optimum
optimum sequence of domains to be selected, and the optimum
end-to-end path to be derived.</t> end-to-end path to be derived.</t>
<t>
<t> A stateful P-PCE has to be aware of the interdomain LSPs for it to
A stateful P-PCE has to be aware of the inter-domain LSPs for it to consider them during path computation. For instance, when a domain-diverse
consider them during path computation. For instance when a domain diverse
path is required from another LSP, the P-PCE needs to be aware of the path is required from another LSP, the P-PCE needs to be aware of the
LSP. This is the Passive Stateful P-PCE as described in <xref LSP. This is the passive stateful P-PCE, as described in <xref
target="sect-3.1"/>. Additionally, the inter-domain LSP could be delegated target="sect-3.1" format="default"/>. Additionally, the interdomain LSP
could be delegated
to the P-PCE, so that P-PCE could trigger an update via a PCUpd message. to the P-PCE, so that P-PCE could trigger an update via a PCUpd message.
The update could be triggered on receipt of the PCRpt message that The update could be triggered on receipt of the PCRpt message that
indicates a status change of this LSP or some other LSP. The other LSP indicates a status change of this LSP or some other LSP. The other LSP
could be an associated LSP (such as protection <xref could be an associated LSP (such as a protection LSP <xref target="RFC8745"
target="I-D.ietf-pce-stateful-path-protection"/>) or an unrelated LSP whose format="default"/>) or an unrelated LSP whose
resource change leads to re-optimization at the P-PCE. This is the Active resource change leads to reoptimization at the P-PCE. This is the active
Stateful Operation as described in <xref target="sect-3.2"/>. Further, the stateful operation, as described in <xref target="sect-3.2" format="default"/
P-PCE could be instructed to create an inter-domain LSP on its own using >. Further, the
P-PCE could be instructed to create an interdomain LSP on its own using
the PCInitiate message for an E2E contiguous LSP. The P-PCE would send the the PCInitiate message for an E2E contiguous LSP. The P-PCE would send the
PCInitiate message to the Ingress domain C-PCE, which would further PCInitiate message to the ingress domain C-PCE, which would further
instruct the Ingress PCC.</t> instruct the ingress PCC.</t>
<t>
<t> In this document, for the contiguous LSP, the above interactions are
In this document, for the Contiguous LSP, the above interactions are
only between the ingress domain C-PCE and the P-PCE. The use of only between the ingress domain C-PCE and the P-PCE. The use of
stateful operations for an inter-domain LSP between the stateful operations for an interdomain LSP between the
transit/egress domain C-PCEs and the P-PCE is out of scope of this transit/egress domain C-PCEs and the P-PCE is out of the scope of this
document.</t> document.</t>
</section>
</section> <section anchor="sect-1.2.3" numbered="true" toc="default">
<name>Applicability of a Stateful P-PCE</name>
<section title="Applicability of a Stateful P-PCE" <t> <xref target="RFC8051" format="default"/> describes general
anchor="sect-1.2.3"><t> <xref target="RFC8051"/> describes general
considerations for a stateful PCE deployment and examines its considerations for a stateful PCE deployment and examines its
applicability and benefits, as well as its challenges and limitations, applicability and benefits, as well as its challenges and limitations,
through a number of use cases. These are also applicable to the through a number of use cases. These are also applicable to the
stateful P-PCE when used for the inter-domain LSP path computation and stateful P-PCE when used for the interdomain LSP path computation and
setup. It should be noted that though the stateful P-PCE has limited setup. It should be noted that though the stateful P-PCE has limited
direct visibility inside the child domain, it could still trigger direct visibility inside the child domain, it could still trigger
re-optimization with the help of child PCEs based on LSP state reoptimization with the help of child PCEs based on LSP state
changes, abstract topology changes, or some other external changes, abstract topology changes, or some other external
factors.</t> factors.</t>
<t>
<t> The C-PCE would delegate control of the interdomain LSP to the P-PCE
The C-PCE would delegate control of the inter-domain LSP to the P-PCE
so that the P-PCE can make changes to it. Note that, if the C-PCE so that the P-PCE can make changes to it. Note that, if the C-PCE
becomes aware of a topology change that is hidden from the P-PCE, it becomes aware of a topology change that is hidden from the P-PCE, it
could take back the delegation from the P-PCE to act on it itself. could take back the delegation from the P-PCE to act on it itself.
Similarly, a P-PCE could also request delegation if it needs to make Similarly, a P-PCE could also request delegation if it needs to make
a change to the LSP (refer to <xref target="I-D.ietf-pce-lsp-control-request" a change to the LSP (refer to <xref target="RFC8741" format="default"/>).</t>
/>).</t> </section>
</section>
</section> </section>
<section anchor="sect-2" numbered="true" toc="default">
</section> <name>Terminology</name>
<t> The terminology is as
</section> per <xref target="RFC4655" format="default"/>, <xref target="RFC5440"
format="default"/>, <xref target="RFC6805" format="default"/>, <xref
<section title="Terminology" anchor="sect-2"><t> The terminology is as target="RFC8051" format="default"/>, <xref target="RFC8231"
per <xref target="RFC4655"/>, <xref target="RFC5440"/>, <xref format="default"/>, and <xref target="RFC8281" format="default"/>.</t>
target="RFC6805"/>, <xref target="RFC8051"/>, <xref <t>Some key terms are listed below for easy reference.</t>
target="RFC8231"/>, and <xref target="RFC8281"/>.</t> <dl newline="false" spacing="normal" indent="9">
<dt>ACTN:</dt>
<t>Some key terms are listed below for easy reference.</t> <dd> Abstraction and Control of Traffic Engineering Networks</dd>
<dt>CNC:</dt>
<t><list style="hanging" hangIndent="3"> <dd> Customer Network Controller</dd>
<dt>C-PCE:</dt>
<t hangText="ACTN:"> Abstraction and Control of Traffic Engineering Netw <dd> Child Path Computation Element</dd>
orks</t> <dt>H-PCE:</dt>
<t hangText="CNC:"> Customer Network Controller</t> <dd> Hierarchical Path Computation Element</dd>
<t hangText="C-PCE:"> Child Path Computation Element</t> <dt>IGP:</dt>
<t hangText="H-PCE:"> Hierarchical Path Computation Element</t> <dd> Interior Gateway Protocol</dd>
<t hangText="IGP:"> Interior Gateway Protocol</t> <dt>LSP:</dt>
<t hangText="LSP:"> Label Switched Path</t> <dd> Label Switched Path</dd>
<t hangText="LSP-DB:"> Label Switched Path Database</t> <dt>LSPDB:</dt>
<t hangText="LSR:"> Label Switching Router</t> <dd> Label Switched Path Database</dd>
<t hangText="MDSC:"> Multi-Domain Service Coordinator</t> <dt>LSR:</dt>
<t hangText="PCC:"> Path Computation Client</t> <dd> Label Switching Router</dd>
<t hangText="PCE:"> Path Computation Element</t> <dt>MDSC:</dt>
<t hangText="PCEP:"> Path Computation Element communication Protocol</t> <dd> Multi-Domain Service Coordinator</dd>
<t hangText="PNC:"> Provisioning Network Controller</t> <dt>PCC:</dt>
<t hangText="P-PCE:"> Parent Path Computation Element</t> <dd> Path Computation Client</dd>
<t hangText="TED:"> Traffic Engineering Database</t> <dt>PCE:</dt>
<t hangText="VN:"> Virtual Network</t> <dd> Path Computation Element</dd>
<dt>PCEP:</dt>
</list> <dd> Path Computation Element communication Protocol</dd>
</t> <dt>PNC:</dt>
<dd> Provisioning Network Controller</dd>
<section title="Requirement Language" anchor="sect-2.1"><t> <dt>P-PCE:</dt>
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", <dd> Parent Path Computation Element</dd>
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and <dt>TED:</dt>
"OPTIONAL" in this document are to be interpreted as described in BCP <dd> Traffic Engineering Database</dd>
14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only when, the <dt>VN:</dt>
y appear in all <dd> Virtual Network</dd>
capitals, as shown here.</t> </dl>
<section anchor="sect-2.1" numbered="true" toc="default">
</section> <name>Requirements Language</name>
<t>
</section> The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
"<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
<section title="Hierarchical Stateful PCE" anchor="sect-3"><t> As NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>",
described in <xref target="RFC6805"/>, in the hierarchical PCE "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
architecture a P-PCE maintains a domain topology map that contains the "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document
are to be interpreted as
described in 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 anchor="sect-3" numbered="true" toc="default">
<name>Hierarchical Stateful PCE</name>
<t> As described in <xref target="RFC6805" format="default"/>, in the hier
archical PCE
architecture, a P-PCE maintains a domain topology map that contains the
child domains (seen as vertices in the topology) and their child domains (seen as vertices in the topology) and their
interconnections (links in the topology). Usually, the P-PCE has no interconnections (links in the topology). Usually, the P-PCE has no
information about the content of the child domains. Each child domain information about the content of the child domains. Each child domain
has at least one PCE capable of computing paths across the domain. has at least one PCE capable of computing paths across the domain.
These PCEs are known as Child PCEs (C-PCEs) <xref target="RFC6805"/> These PCEs are known as Child PCEs (C-PCEs) <xref target="RFC6805" format ="default"/>
and have a direct relationship with the P-PCE. The P-PCE builds the and have a direct relationship with the P-PCE. The P-PCE builds the
domain topology map either via direct configuration or from learned domain topology map either via direct configuration or from learned
information received from each C-PCE. The network policy could be be information received from each C-PCE. The network policy could be
applied while building the domain topology map. This has been applied while building the domain topology map. This has been
described in detail in <xref target="RFC6805"/>.</t> described in detail in <xref target="RFC6805" format="default"/>.</t>
<t>
<t>
Note that, in the scope of this document, both the C-PCEs and the P-PCE are Note that, in the scope of this document, both the C-PCEs and the P-PCE are
stateful in nature.</t> stateful in nature.</t>
<t>
<t> <xref target="RFC8231" format="default"/> specifies new functions to support
<xref target="RFC8231"/> specifies new functions to support a stateful PCE. a stateful PCE.
It also specifies that a function can be initiated either from a PCC It also specifies that a function can be initiated either from a PCC
towards a PCE (C-E) or from a PCE towards a PCC (E-C).</t> towards a PCE (C-E) or from a PCE towards a PCC (E-C).</t>
<t>
<t>
This document extends these functions to support H-PCE Architecture This document extends these functions to support H-PCE Architecture
from a C-PCE towards P-PCE (EC-EP) or from a P-PCE towards C-PCE from a C-PCE towards P-PCE (EC-EP) or from a P-PCE towards C-PCE
(EP-EC). All PCE types herein (EC-EP and EP-EC) are assumed to be (EP-EC). All PCE types herein (EC-EP and EP-EC) are assumed to be
"Stateful PCE".</t> "stateful PCE".</t>
<t>
<t> A number of interactions are expected in the hierarchical stateful
A number of interactions are expected in the Hierarchical Stateful
PCE architecture. These include:</t> PCE architecture. These include:</t>
<dl newline="false" spacing="normal" indent="3">
<dt>LSP State Report (EC-EP):</dt>
<dd>A child stateful PCE sends an
LSP state report to a parent stateful PCE to indicate the state of an LS
P.
</dd>
<dt>LSP State Synchronization (EC-EP):</dt>
<dd>After the session
between the child and parent stateful PCEs is initialized, the P-PCE
must learn the state of the C-PCE's TE LSPs.
</dd>
<dt>LSP Control Delegation (EC-EP, EP-EC):</dt>
<t><list style="hanging" hangIndent="3"> <dd>A C-PCE grants to the P-PCE
the right to update LSP attributes on one or more LSPs; at any
<t hangText="LSP State Report (EC-EP):"> a child stateful PCE sends an time, the C-PCE
LSP state report to a Parent Stateful PCE to indicate the state of a may withdraw the delegation or the P-PCE may give up the
LSP. delegation.</dd>
</t> <dt>LSP Update Request (EP-EC):</dt>
<dd>A stateful P-PCE requests
<t hangText="LSP State Synchronization (EC-EP):"> after the session
between the Child and Parent stateful PCEs is initialized, the P-PCE
must learn the state of C-PCE's TE LSPs.
</t>
<t hangText="LSP Control Delegation (EC-EP,EP-EC):"> a C-PCE grants to
the P-PCE the right to update LSP attributes on one or more LSPs; the
C-PCE may withdraw the delegation or the P-PCE may give up the
delegation at any time.
</t>
<t hangText="LSP Update Request (EP-EC):"> a stateful P-PCE requests
modification of attributes on a C-PCE's TE LSP. modification of attributes on a C-PCE's TE LSP.
</t> </dd>
<dt>PCE LSP Initiation Request (EP-EC):</dt>
<t hangText="PCE LSP Initiation Request (EP-EC):"> a stateful P-PCE <dd>A stateful P-PCE requests a C-PCE to initiate a TE LSP.
requests C-PCE to initiate a TE LSP. </dd>
</t> </dl>
<t>
</list>
</t>
<t>
Note that this hierarchy is recursive, so a Label Switching Router Note that this hierarchy is recursive, so a Label Switching Router
(LSR), as a PCC, could delegate control to a PCE, which may in turn (LSR), as a PCC, could delegate control to a PCE. That PCE may, in turn,
delegate to its parent, which may further delegate to its parent (if delegate to its parent, which may further delegate to its parent (if
it exists). Similarly, update operations can also be applied it exists). Similarly, update operations can also be applied
recursively.</t> recursively.</t>
<t>
<t> <xref target="RFC8685" format="default"/> defines the H-PCE-CAPABILITY TLV th
<xref target="I-D.ietf-pce-hierarchy-extensions"/> defines the H-PCE at is used in the Open message to advertise the H-PCE
Capability TLV that is used in the Open message to advertise the H-PCE capability. <xref target="RFC8231" format="default"/> defines the STATEFUL-PC
capability. <xref target="RFC8231"/> defines the Stateful PCE Capability E-CAPABILITY
TLV used in the Open message to indicate stateful support. To indicates the TLV used in the Open message to indicate stateful support. To indicate the
support for stateful H-PCE operations described in this document, a PCEP support for stateful H-PCE operations described in this document, a PCEP
speaker MUST include both TLVs in an Open message. It is RECOMMENDED that speaker <bcp14>MUST</bcp14> include both TLVs in an Open message. It is <bcp1
any implementation that supports stateful operations <xref 4>RECOMMENDED</bcp14> that
target="RFC8231"/> and H-PCE <xref any implementation that supports stateful operations <xref target="RFC8231" f
target="I-D.ietf-pce-hierarchy-extensions"/> would also implements the ormat="default"/> and H-PCE <xref target="RFC8685" format="default"/> also imple
ment the
stateful H-PCE operations as described in this document.</t> stateful H-PCE operations as described in this document.</t>
<t>
<t>
Further consideration may be made for optional procedures for stateful Further consideration may be made for optional procedures for stateful
communication coordination between PCEs, including procedures to minimize communication coordination between PCEs, including procedures to minimize
computational loops. The procedures described in <xref computational loops. The procedures described in <xref target="I-D.litkowski-
target="I-D.litkowski-pce-state-sync"/> facilitate stateful communication pce-state-sync" format="default"/> facilitate stateful communication
between PCEs for various use cases. The procedures and extensions as between PCEs for various use cases. The procedures and extensions as
described in Section 3 of <xref target="I-D.litkowski-pce-state-sync"/> are described in <xref target="I-D.litkowski-pce-state-sync"
also applicable to Child and Parent PCE communication. The sectionFormat="of" section="3"/> are
SPEAKER-IDENTITY-TLV (defined in <xref target="RFC8232"/>) is included in also applicable to child and parent PCE communication. The
the LSP object to identify the Ingress (PCC). The PLSP-ID (PCEP-specific SPEAKER-IDENTITY-ID TLV (defined in <xref target="RFC8232" format="default"/>
identifier for the LSP, as per <xref target="RFC8231"/>) used in the ) is included in
forwarded PCRpt by the C-PCE to P-PCE is same as the original one used by the LSP object to identify the ingress (PCC). The PCEP-specific identifier
for the LSP (PLSP-ID <xref target="RFC8231" format="default"/>) used in the
forwarded PCRpt by the C-PCE to the P-PCE is the same as the original one use
d by
the PCC.</t> the PCC.</t>
<section anchor="sect-3.1" numbered="true" toc="default">
<section title="Passive Operations" anchor="sect-3.1"><t> Procedures <name>Passive Operations</name>
as described in <xref target="RFC6805"/> are applied, where the <t> Procedures described in <xref target="RFC6805" format="default"/> ar
e applied, where the
ingress PCC triggers a path computation request for the destination ingress PCC triggers a path computation request for the destination
towards the C-PCE in the domain where the LSP originates. The C-PCE towards the C-PCE in the domain where the LSP originates. The C-PCE
further forwards the request to the P-PCE. The P-PCE selects a set of further forwards the request to the P-PCE. The P-PCE selects a set of
candidate domain paths based on the domain topology and the state of candidate domain paths based on the domain topology and the state of
the inter-domain links. It then sends computation requests to the the interdomain links. It then sends computation requests to the
C-PCEs responsible for each of the domains on the candidate domain C-PCEs responsible for each of the domains on the candidate domain
paths. Each C-PCE computes a set of candidate path segments across paths. Each C-PCE computes a set of candidate path segments across
its domain and sends the results to the P-PCE. The P-PCE uses this its domain and sends the results to the P-PCE. The P-PCE uses this
information to select path segments and concatenate them to derive the information to select path segments and concatenate them to derive the
optimal end-to-end inter-domain path. The end-to-end path is then optimal end-to-end interdomain path. The end-to-end path is then
sent to the C-PCE that received the initial path request, and this sent to the C-PCE that received the initial path request, and this
C-PCE passes the path on to the PCC that issued the original C-PCE passes the path on to the PCC that issued the original
request.</t> request.</t>
<t>
<t> As per <xref target="RFC8231" format="default"/>, the PCC sends an LSP State
As per <xref target="RFC8231"/>, PCC sends an LSP State Report carried on a P Report carried on a PCRpt
CRpt
message to the C-PCE, indicating the LSP's status. The C-PCE may message to the C-PCE, indicating the LSP's status. The C-PCE may
further propagate the State Report to the P-PCE. A local policy at further propagate the State Report to the P-PCE. A local policy at the
C-PCE may dictate which LSPs are reported to the P-PCE. The PCRpt C-PCE may dictate which LSPs are reported to the P-PCE. The PCRpt
message is sent from C-PCE to P-PCE.</t> message is sent from C-PCE to P-PCE.</t>
<t>
<t> State synchronization mechanisms as described in <xref target="RFC8231" forma
State synchronization mechanisms as described in <xref target="RFC8231"/> and t="default"/> and
<xref target="RFC8232"/> are applicable to a PCEP session between C-PCE and P <xref target="RFC8232" format="default"/> are applicable to a PCEP session be
-PCE as tween C-PCE and P-PCE as
well.</t> well.</t>
<t>
<t> We use the hierarchical domain topology example from <xref target="RFC6805" f
We use the hierarchical domain topology example from <xref target="RFC6805"/> ormat="default"/> as the
as the
reference topology for the entirety of this document. It is shown in reference topology for the entirety of this document. It is shown in
Figure 1.</t> Figure 1.</t>
<figure title="Hierarchical Domain Topology Example" anchor="ure-hierarch <figure anchor="ure-hierarchical-domain-topology-example">
ical-domain-topology-example"><artwork><![CDATA[ <name>Hierarchical Domain Topology Example</name>
<artwork name="" type="" align="left" alt=""><![CDATA[
----------------------------------------------------------------- -----------------------------------------------------------------
| Domain 5 | | Domain 5 |
| ----- | | ----- |
| |PCE 5| | | |PCE 5| |
| ----- | | ----- |
| | | |
| ---------------- ---------------- ---------------- | | ---------------- ---------------- ---------------- |
| | Domain 1 | | Domain 2 | | Domain 3 | | | | Domain 1 | | Domain 2 | | Domain 3 | |
| | | | | | | | | | | | | | | |
| | ----- | | ----- | | ----- | | | | ----- | | ----- | | ----- | |
skipping to change at line 523 skipping to change at line 504
| | | | | | | |
| | ----- | | | | ----- | |
| | |PCE 4| | | | | |PCE 4| | |
| | ----- | | | | ----- | |
| | | | | | | |
| | Domain 4 | | | | Domain 4 | |
| ---------------- | | ---------------- |
| | | |
----------------------------------------------------------------- -----------------------------------------------------------------
]]></artwork> ]]></artwork>
</figure> </figure>
<t> <t>
Steps 1 to 11 are exactly as described in section 4.6.2 of <xref target="RFC6 Steps 1 to 11 are exactly as described in <xref
805"/> target="RFC6805" sectionFormat="of" section="4.6.2"/>
(Hierarchical PCE End-to-End Path Computation Procedure), the ("Hierarchical PCE End-to-End Path Computation Procedure"); the
following additional steps are added for stateful PCE, to be executed following additional steps are added for stateful PCE, to be executed
at the end:</t> at the end:</t>
<dl newline="false" spacing="normal" indent="5">
<t><list style="hanging" hangIndent="5"> <dt>(A)</dt>
<dd>The ingress LSR initiates the setup of the LSP as
<t hangText="(A)"> The Ingress LSR initiates the setup of the LSP as per the path and reports the LSP status to PCE1 ("GOING-UP").</dd>
per the path and reports to the PCE1 the LSP status ("GOING-UP").</t> <dt>(B)</dt>
<dd>PCE1 further reports the status of the LSP to
<t hangText="(B)"> The PCE1 further reports the status of the LSP to the P-PCE (PCE5).</dd>
the P-PCE (PCE5).</t> <dt>(C)</dt>
<dd>The ingress LSR notifies PCE1 of the LSP state when the
<t hangText="(C)"> The Ingress LSR notifies the LSP state to PCE1 when state is "UP".</dd>
the state is "UP".</t> <dt>(D)</dt>
<dd>PCE1 further reports the status of the LSP to the P-PCE
<t hangText="(D)"> The PCE1 further reports the status of the LSP to the (PCE5). </dd>
P-PCE </dl>
(PCE5). </t> <t>
The ingress LSR could trigger path reoptimization by sending the
</list> path computation request as described in <xref target="RFC6805"
</t> format="default"/>; at this time, it
can include the LSP object in the PCReq message, as described in
<t> <xref target="RFC8231" format="default"/>.</t>
The Ingress LSR could trigger path re-optimization by sending the </section>
path computation request as described in <xref target="RFC6805"/>, at this ti <section anchor="sect-3.2" numbered="true" toc="default">
me it <name>Active Operations</name>
can include the LSP object in the PCReq message as described in <t> <xref target="RFC8231" format="default"/> describes the case of an
<xref target="RFC8231"/>.</t> active stateful PCE. The
</section>
<section title="Active Operations" anchor="sect-3.2"><t> <xref
target="RFC8231"/> describes the case of active stateful PCE. The
active PCE functionality uses two specific PCEP messages:</t> active PCE functionality uses two specific PCEP messages:</t>
<ul spacing="normal">
<t><list style="symbols"><t>Update Request (PCUpd)</t> <li>Update Request (PCUpd)</li>
<li>State Report (PCRpt)</li>
<t>State Report (PCRpt)</t> </ul>
<t>
</list>
</t>
<t>
The first is sent by the PCE to a PCC for modifying LSP attributes. The first is sent by the PCE to a PCC for modifying LSP attributes.
The PCC sends back a PCRpt to acknowledge the requested operation or The PCC sends back a PCRpt to acknowledge the requested operation or
report any change in LSP's state.</t> report any change in the LSP's state.</t>
<t>
<t> As per <xref target="RFC8051" format="default"/>, delegation is an
As per <xref target="RFC8051"/>, Delegation is an operation to grant a PCE te operation to grant a PCE temporary
mporary rights to modify a subset of LSP parameters on the LSPs of one or more
rights to modify a subset of LSP parameters on one or more PCC's PCCs. The C-PCE may further choose to delegate to its P-PCE based on
LSPs. The C-PCE may further choose to delegate to its P-PCE based on
a local policy. The PCRpt message with the "D" (delegate) flag is a local policy. The PCRpt message with the "D" (delegate) flag is
sent from C-PCE to P-PCE.</t> sent from C-PCE to P-PCE.</t>
<t>
<t>
To update an LSP, a PCE sends an LSP Update Request to the PCC using To update an LSP, a PCE sends an LSP Update Request to the PCC using
a PCUpd message. For an LSP delegated to a P-PCE via the C-PCE; the a PCUpd message. For an LSP delegated to a P-PCE via the C-PCE, the
P-PCE can use the same PCUpd message to request a change to the C-PCE P-PCE can use the same PCUpd message to request a change to the C-PCE
(the Ingress domain PCE). The C-PCE further propagates the update (the ingress domain PCE). The C-PCE further propagates the update
request to the PCC.</t> request to the PCC.</t>
<t>
<t> The P-PCE uses the same mechanism described in <xref target="sect-3.1" format
The P-PCE uses the same mechanism described in <xref target="sect-3.1"/> to ="default"/> to
compute the end to end path using PCReq and PCRep messages.</t> compute the end-to-end path using PCReq and PCRep messages.</t>
<t>
<t>
For active operations, the following steps are required when For active operations, the following steps are required when
delegating the LSP, again using the reference architecture described delegating the LSP, again using the reference architecture described
in Figure 1 (Hierarchical Domain Topology Example).</t> in Figure 1 ("Hierarchical Domain Topology Example").</t>
<dl newline="false" spacing="normal" indent="5">
<t><list style="hanging" hangIndent="5"> <dt>(A)</dt>
<dd>The ingress LSR delegates the LSP to PCE1 via a
<t hangText="(A)"> The Ingress LSR delegates the LSP to the PCE1 via PCRpt message with D flag set.</dd>
PCRpt message with D flag set.</t> <dt>(B)</dt>
<dd>PCE1 further delegates the LSP to the P-PCE
<t hangText="(B)"> The PCE1 further delegates the LSP to the P-PCE (PCE5).</dd>
(PCE5).</t> <dt>(C)</dt>
<dd>Steps 4 to 10 in <xref target="RFC6805"
<t hangText="(C)"> Steps 4 to 10 of section 4.6.2 of <xref sectionFormat="of" section="4.6.2"/> are executed at P-PCE (PCE5) to
target="RFC6805"/> are executed at P-PCE (PCE5) to determine the end determine the end-to-end path.</dd>
to end path.</t> <dt>(D)</dt>
<dd>The P-PCE (PCE5) sends the update request to the
<t hangText="(D)"> The P-PCE (PCE5) sends the update request to the C-PCE (PCE1) via PCUpd message.</dd>
C-PCE (PCE1) via PCUpd message.</t> <dt>(E)</dt>
<dd>PCE1 further updates the LSP to the ingress LSR
<t hangText="(E)"> The PCE1 further updates the LSP to the Ingress LSR (PCC).</dd>
(PCC).</t> <dt>(F)</dt>
<dd>The ingress LSR initiates the setup of the LSP as
<t hangText="(F)"> The Ingress LSR initiates the setup of the LSP as per the path and reports the LSP status to PCE1 ("GOING-UP").</dd>
per the path and reports to the PCE1 the LSP status ("GOING-UP").</t> <dt>(G)</dt>
<dd>PCE1 further reports the status of the LSP to
<t hangText="(G)"> The PCE1 further reports the status of the LSP to the P-PCE (PCE5).</dd>
the P-PCE (PCE5).</t> <dt>(H)</dt>
<dd>The ingress LSR notifies PCE1 of the LSP state when
<t hangText="(H)"> The Ingress LSR notifies the LSP state to PCE1 when the state is "UP".</dd>
the state is "UP".</t> <dt>(I)</dt>
<dd>PCE1 further reports the status of the LSP to
<t hangText="(I)"> The PCE1 further reports the status of the LSP to the P-PCE (PCE5).</dd>
the P-PCE (PCE5).</t> </dl>
</section>
</list> <section anchor="sect-3.3" numbered="true" toc="default">
</t> <name>PCE Initiation of LSPs</name>
<t> <xref target="RFC8281" format="default"/> describes the setup,
</section> maintenance, and teardown of
<section title="PCE Initiation of LSPs" anchor="sect-3.3"><t> <xref
target="RFC8281"/> describes the setup, maintenance and teardown of
PCE-initiated LSPs under the stateful PCE model, without the need for PCE-initiated LSPs under the stateful PCE model, without the need for
local configuration on the PCC, thus allowing for a dynamic network local configuration on the PCC, thus allowing for a dynamic network
that is centrally controlled and deployed. To instantiate or delete that is centrally controlled and deployed. To instantiate or delete
an LSP, the PCE sends the Path Computation LSP Initiate Request an LSP, the PCE sends the Path Computation LSP initiate request
(PCInitiate) message to the PCC. In case of an inter-domain LSP in (PCInitiate) message to the PCC. In the case of an interdomain LSP in
Hierarchical PCE architecture, the initiation operations can be hierarchical PCE architecture, the initiation operations can be
carried out at the P-PCE. In which case after the P-PCE finishes the carried out at the P-PCE. In that case, after the P-PCE finishes the
E2E path computation, it can send the PCInitiate message to the C-PCE E2E path computation, it can send the PCInitiate message to the C-PCE
(the Ingress domain PCE), the C-PCE further propagates the initiate (the ingress domain PCE), and the C-PCE further propagates the initiate
request to the PCC.</t> request to the PCC.</t>
<t>
<t>
The following steps are performed for PCE-initiated operations, again The following steps are performed for PCE-initiated operations, again
using the reference architecture described in Figure 1 (Hierarchical using the reference architecture described in Figure 1 ("Hierarchical
Domain Topology Example):</t> Domain Topology Example"):</t>
<dl newline="false" spacing="normal" indent="5">
<t><list style="hanging" hangIndent="5"> <dt>(A)</dt>
<dd> The P-PCE (PCE5) is requested to initiate an
<t hangText="(A)"> The P-PCE (PCE5) is requested to initiate a LSP. Steps 4 to 10 in <xref target="RFC6805"
LSP. Steps 4 to 10 of section 4.6.2 of <xref target="RFC6805"/> are sectionFormat="of" section="4.6.2"/> are
executed to determine the end to end path.</t> executed to determine the end-to-end path.</dd>
<dt>(B)</dt>
<t hangText="(B)"> The P-PCE (PCE5) sends the initiate request to the <dd> The P-PCE (PCE5) sends the initiate request to the
child PCE (PCE1) via PCInitiate message.</t> child PCE (PCE1) via PCInitiate message.</dd>
<dt>(C)</dt>
<t hangText="(C)">The PCE1 further propagates the initiate message to <dd>PCE1 further propagates the initiate message to
the Ingress LSR (PCC).</t> the ingress LSR (PCC).</dd>
<dt>(D)</dt>
<t hangText="(D)">The Ingress LSR initiates the setup of the LSP as per t <dd>The ingress LSR initiates the setup of the LSP as per the path
he path and reports to PCE1 the LSP status ("GOING-UP").</dd>
and reports to the PCE1 the LSP status ("GOING-UP").</t> <dt>(E)</dt>
<dd>PCE1 further reports the status of the LSP to the P-PCE
<t hangText="(E)">The PCE1 further reports the status of the LSP to the P (PCE5).</dd>
-PCE <dt>(F)</dt>
(PCE5).</t> <dd>The ingress LSR notifies PCE1 of the LSP state when the state is
"UP".</dd>
<t hangText="(F)">The Ingress LSR notifies the LSP state to PCE1 when the <dt>(G)</dt>
state is <dd>PCE1 further reports the status of the LSP to the P-PCE
"UP".</t> (PCE5).</dd>
</dl>
<t hangText="(G)">The PCE1 further reports the status of the LSP to the P <t>
-PCE The ingress LSR (PCC) generates the PLSP-ID for the LSP and
(PCE5).</t>
</list>
</t>
<t>
The Ingress LSR (PCC) would generate the PLSP-ID for the LSP and
inform the C-PCE, which is propagated to the P-PCE.</t> inform the C-PCE, which is propagated to the P-PCE.</t>
<section anchor="sect-3.3.1" numbered="true" toc="default">
<section title="Per-Domain Stitched LSP" anchor="sect-3.3.1"><t> The <name>Per-Domain Stitched LSP</name>
Hierarchical PCE architecture as per <xref target="RFC6805"/> is <t> The hierarchical PCE architecture, as per <xref target="RFC6805"
primarily used for E2E LSP. With PCE-Initiated capability, another format="default"/>, is
mode of operation is possible, where multiple intra-domain LSPs are primarily used for E2E LSP. With PCE-initiated capability, another
initiated in each domain, which are further stitched to form an E2E mode of operation is possible, where multiple intradomain LSPs are
initiated in each domain and are further stitched to form an E2E
LSP. The P-PCE sends PCInitiate message to each C-PCE separately to LSP. The P-PCE sends PCInitiate message to each C-PCE separately to
initiate individual LSP segments along the domain path. These initiate individual LSP segments along the domain path. These
individual Per-Domain LSP are stitched together by some mechanism, individual per-domain LSPs are stitched together by some mechanism,
which is out of scope of this document (Refer <xref which is out of the scope of this document (Refer to <xref
target="I-D.dugeon-pce-stateful-interdomain"/>).</t> target="I-D.dugeon-pce-stateful-interdomain" format="default"/>).</t>
<t>
<t> The following steps are performed for the per-domain stitched LSP
The following steps are performed for the Per-Domain stitched LSP
operation, again using the reference architecture described in Figure operation, again using the reference architecture described in Figure
1 (Hierarchical Domain Topology Example):</t> 1 ("Hierarchical Domain Topology Example"):</t>
<dl newline="false" spacing="normal" indent="5">
<t><list style="hanging" hangIndent="5"> <dt>(A)</dt>
<dd>
<t hangText="(A)"> The P-PCE (PCE5) is requested to initiate a <t> The P-PCE (PCE5) is requested to initiate an LSP. Steps 4 to
LSP. Steps 4 to 10 of section 4.6.2 of <xref target="RFC6805"/> are 10 in <xref target="RFC6805"
executed to determine the end to end path, which are broken into sectionFormat="of" section="4.6.2"/> are
per-domain LSPs say - executed to determine the end-to-end path, which is broken into
per-domain LSPs. For example:
<list style="symbols"> </t>
<ul spacing="normal">
<t>S-BN41</t> <li>S-BN41</li>
<t>BN41-BN33</t> <li>BN41-BN33</li>
<t>BN33-D</t> <li>BN33-D</li>
</ul>
</list> </dd>
</t> </dl>
<t>
</list>
</t>
<t>
It should be noted that the P-PCE may use other mechanisms to It should be noted that the P-PCE may use other mechanisms to
determine the suitable per-domain LSPs (apart from <xref target="RFC6805"/>). determine the suitable per-domain LSPs (apart from <xref target="RFC6805" for
</t> mat="default"/>).</t>
<t>
<t> For LSP (BN33-D):</t>
For LSP (BN33-D)</t> <dl newline="false" spacing="normal" indent="5">
<dt>(B)</dt>
<t><list style="hanging" hangIndent="5"> <dd>The P-PCE (PCE5) sends the initiate request to the
child PCE (PCE3) via a PCInitiate message for the LSP (BN33-D).</dd>
<t hangText="(B)">The P-PCE (PCE5) sends the initiate request to the <dt>(C)</dt>
child PCE (PCE3) via PCInitiate message for LSP (BN33-D).</t> <dd>PCE3 further propagates the initiate message to
BN33. </dd>
<t hangText="(C)">The PCE3 further propagates the initiate message to <dt>(D)</dt>
BN33. </t> <dd>BN33 initiates the setup of the LSP as per the path
and reports to PCE3 the LSP status ("GOING-UP").</dd>
<t hangText="(D)">BN33 initiates the setup of the LSP as per the path <dt>(E)</dt>
and reports to the PCE3 the LSP status ("GOING-UP").</t> <dd>PCE3 further reports the status of the LSP to
the P-PCE (PCE5).</dd>
<t hangText="(E)"> The PCE3 further reports the status of the LSP to <dt>(F)</dt>
the P-PCE (PCE5).</t> <dd>The node BN33 notifies PCE3 of the LSP state when
the state is "UP".</dd>
<t hangText="(F)">The node BN33 notifies the LSP state to PCE3 when <dt>(G)</dt>
the state is "UP".</t> <dd>PCE3 further reports the status of the LSP to the P-PCE
(PCE5).</dd>
<t hangText="(G)">The PCE3 further reports the status of the LSP to the P </dl>
-PCE <t>
(PCE5).</t> For LSP (BN41-BN33):</t>
<dl newline="false" spacing="normal" indent="5">
</list> <dt>(H)</dt>
</t> <dd>The P-PCE (PCE5) sends the initiate request to the
child PCE (PCE4) via PCInitiate message for LSP (BN41-BN33).</dd>
<t> <dt>(I)</dt>
For LSP (BN41-BN33)</t> <dd>PCE4 further propagates the initiate message to
BN41.</dd>
<t><list style="hanging" hangIndent="5"> <dt>(J)</dt>
<dd>BN41 initiates the setup of the LSP as per the path
<t hangText="(H)">The P-PCE (PCE5) sends the initiate request to the and reports to PCE4 the LSP status ("GOING-UP").</dd>
child PCE (PCE4) via PCInitiate message for LSP (BN41-BN33).</t> <dt>(K)</dt>
<dd>PCE4 further reports the status of the LSP to
<t hangText="(I)">The PCE4 further propagates the initiate message to the P-PCE (PCE5).</dd>
BN41.</t> <dt>(L)</dt>
<dd>The node BN41 notifies PCE4 of the LSP state when
<t hangText="(J)">BN41 initiates the setup of the LSP as per the path the state is "UP".</dd>
and reports to the PCE4 the LSP status ("GOING-UP").</t> <dt>(M)</dt>
<dd>PCE4 further reports the status of the LSP to the P-PCE
<t hangText="(K)">The PCE4 further reports the status of the LSP to (PCE5).</dd>
the P-PCE (PCE5).</t> </dl>
<t>
<t hangText="(L)">The node BN41 notifies the LSP state to PCE4 when For LSP (S-BN41):</t>
the state is "UP".</t> <dl newline="false" spacing="normal" indent="5">
<dt>(N)</dt>
<t hangText="(M)">The PCE4 further reports the status of the LSP to the P <dd>The P-PCE (PCE5) sends the initiate request to the
-PCE child PCE (PCE1) via a PCInitiate message for the LSP (S-BN41).</dd>
(PCE5).</t> <dt>(O)</dt>
<dd>PCE1 further propagates the initiate message to
</list> node S.</dd>
</t> <dt>(P)</dt>
<dd>S initiates the setup of the LSP as per the path and
<t> reports to PCE1 the LSP status ("GOING-UP").</dd>
For LSP (S-BN41)</t> <dt>(Q)</dt>
<dd>PCE1 further reports the status of the LSP to
<t><list style="hanging" hangIndent="5"> the P-PCE (PCE5).</dd>
<dt>(R)</dt>
<t hangText="(N)">The P-PCE (PCE5) sends the initiate request to the <dd>The node S notifies PCE1 of the LSP state when the state is
child PCE (PCE1) via PCInitiate message for LSP (S-BN41).</t> "UP".</dd>
<dt>(S)</dt>
<t hangText="(O)">The PCE1 further propagates the initiate message to <dd>PCE1 further reports the status of the LSP to
node S.</t> the P-PCE (PCE5).</dd>
</dl>
<t hangText="(P)">S initiates the setup of the LSP as per the path and <t>
reports to the PCE1 the LSP status ("GOING-UP").</t>
<t hangText="(Q)">The PCE1 further reports the status of the LSP to
the P-PCE (PCE5).</t>
<t hangText="(R)">The node S notifies the LSP state to PCE1 when the stat
e is
"UP".</t>
<t hangText="(S)">The PCE1 further reports the status of the LSP to
the P-PCE (PCE5).</t>
</list>
</t>
<t>
Additionally:</t> Additionally:</t>
<dl newline="false" spacing="normal" indent="5">
<t><list style="hanging" hangIndent="5"> <dt>(T)</dt>
<dd>Once the P-PCE receives a report of each per-domain LSP,
<t hangText="(T)">Once P-PCE receives report of each per-domain LSP, it should use a suitable stitching mechanism, which is out of the scope
it should use suitable stitching mechanism, which is out of scope of of
this document. In this step, P-PCE (PCE5) could also initiate an E2E this document. In this step, the P-PCE (PCE5) could also initiate an E2E
LSP (S-D) by sending the PCInitiate message to Ingress C-PCE LSP (S-D) by sending the PCInitiate message to the ingress C-PCE
(PCE1).</t> (PCE1).</dd>
</dl>
</list> <t>
</t>
<t>
Note that each per-domain LSP can be set up in parallel. Further, it Note that each per-domain LSP can be set up in parallel. Further, it
is also possible to stitch the per-domain LSP at the same time as the is also possible to stitch the per-domain LSP at the same time as the
per-domain LSPs are initiated. This option is defined in per-domain LSPs are initiated. This option is defined in
<xref target="I-D.dugeon-pce-stateful-interdomain"/>.</t> <xref target="I-D.dugeon-pce-stateful-interdomain" format="default"/>.</t>
</section>
</section> </section>
</section>
</section> <section anchor="sect-4" numbered="true" toc="default">
<name>Security Considerations</name>
</section> <t> The
security considerations listed in <xref target="RFC8231"
<section title="Security Considerations" anchor="sect-4"><t> The format="default"/>, <xref target="RFC6805" format="default"/>, and
security considerations listed in <xref target="RFC8231"/>,<xref <xref target="RFC5440" format="default"/> apply to this document,
target="RFC6805"/> and <xref target="RFC5440"/> apply to this document as well. As per <xref target="RFC6805" format="default"/>, it is expected
as well. As per <xref target="RFC6805"/>, it is expected that the that the
parent PCE will require all child PCEs to use full security (i.e. the parent PCE will require all child PCEs to use full security (i.e., the
highest security mechanism available for PCEP) when communicating with highest security mechanism available for PCEP) when communicating with
the parent.</t> the parent.</t>
<t>
<t> Any multidomain operation necessarily involves the exchange of information
Any multi-domain operation necessarily involves the exchange of information
across domain boundaries. This is bound to represent a significant across domain boundaries. This is bound to represent a significant
security and confidentiality risk especially when the child domains are security and confidentiality risk, especially when the child domains are
controlled by different commercial concerns. PCEP allows individual PCEs controlled by different commercial concerns. PCEP allows individual PCEs
to maintain confidentiality of their domain path information using to maintain the confidentiality of their domain-path information using
path-keys <xref target="RFC5520"/>, and the hierarchical PCE architecture path-keys <xref target="RFC5520" format="default"/>, and the hierarchical PCE
is specifically designed to enable as much isolation of domain topology and architecture
capabilities information as is possible. The LSP state in the PCRpt message is specifically designed to enable as much isolation of information about dom
ain topology and
capabilities as is possible. The LSP state in the PCRpt message
must continue to maintain the internal domain confidentiality when must continue to maintain the internal domain confidentiality when
required.</t> required.</t>
<t>
<t> The security considerations for PCE-initiated LSP in <xref
The security consideration for PCE-Initiated LSP as per <xref target="RFC8281 target="RFC8281" format="default"/> are
"/> is
also applicable from P-PCE to C-PCE.</t> also applicable from P-PCE to C-PCE.</t>
<t>
<t> Further, <xref target="sect-6.3" /> describes the use of a path-key <xref
Further, section 6.3 describes the use of path-key <xref target="RFC5520"/> f target="RFC5520" format="default"/> for
or
confidentiality between C-PCE and P-PCE.</t> confidentiality between C-PCE and P-PCE.</t>
<t>
<t> Thus, it is <bcp14>RECOMMENDED</bcp14> to secure the PCEP session (between th
Thus it is RECOMMENDED to secure the PCEP session (between the P-PCE and e P-PCE and
the C-PCE) using Transport Layer Security (TLS) <xref target="RFC8446"/> the C-PCE) using Transport Layer Security (TLS) <xref target="RFC8446" format
(per the recommendations and best current practices in BCP 195 <xref ="default"/>
target="RFC7525"/>) and/or TCP Authentication Option (TCP-AO) <xref (per the recommendations and best current practices in BCP 195 <xref target="
target="RFC5925"/>. The guidance for implementing PCEP with TLS can be RFC7525" format="default"/>) and/or TCP Authentication Option (TCP-AO) <xref tar
found in <xref target="RFC8253"/>.</t> get="RFC5925" format="default"/>. The guidance for implementing PCEP with TLS ca
n be
<t> found in <xref target="RFC8253" format="default"/>.</t>
In case of TLS, due care needs to be taken while exposing the parameters of <t>
the X.509 certificate, such as subjectAltName:otherName which is set to In the case of TLS, due care needs to be taken while exposing the parameters
Speaker Entity Identifier <xref target="RFC8232"/> as per <xref of
target="RFC8253"/>, to ensure uniqueness and avoid any mismatch.</t> the X.509 certificate -- such as subjectAltName:otherName, which is set to
Speaker Entity Identifier <xref target="RFC8232" format="default"/> as per
</section> <xref target="RFC8253" format="default"/> -- to ensure uniqueness and
avoid any mismatch.</t>
<section title="Manageability Considerations" anchor="sect-5"><t> All </section>
manageability requirements and considerations listed in <xref <section anchor="sect-5" numbered="true" toc="default">
target="RFC5440"/>, <xref target="RFC6805"/>, <xref <name>Manageability Considerations</name>
target="RFC8231"/>, and <xref target="RFC8281"/> apply to Stateful <t> All
manageability requirements and considerations listed in <xref target="RFC
5440" format="default"/>, <xref target="RFC6805" format="default"/>, <xref targe
t="RFC8231" format="default"/>, and <xref target="RFC8281" format="default"/> ap
ply to stateful
H-PCE defined in this document. In addition, requirements and H-PCE defined in this document. In addition, requirements and
considerations listed in this section apply.</t> considerations listed in this section apply.</t>
<section anchor="sect-5.1" numbered="true" toc="default">
<section title="Control of Function and Policy" anchor="sect-5.1"><t> <name>Control of Function and Policy</name>
<t>
Support of the hierarchical procedure will be controlled by the Support of the hierarchical procedure will be controlled by the
management organization responsible for each child PCE. The parent management organization responsible for each child PCE. The parent
PCE must only accept path computation requests from authorized child PCE must only accept path-computation requests from authorized child
PCEs. If a parent PCE receives a report from an unauthorized child PCEs. If a parent PCE receives a report from an unauthorized child
PCE, the report should be dropped. All mechanisms as described in PCE, the report should be dropped. All mechanisms described in
<xref target="RFC8231"/> and <xref target="RFC8281"/> continue to apply.</t> <xref target="RFC8231" format="default"/> and <xref target="RFC8281" format="
default"/> continue to apply.</t>
</section> </section>
<section anchor="sect-5.2" numbered="true" toc="default">
<section title="Information and Data Models" anchor="sect-5.2"><t> <name>Information and Data Models</name>
<t>
An implementation should allow the operator to view the stateful and An implementation should allow the operator to view the stateful and
H-PCE capabilities advertised by each peer. The "ietf-pcep" PCEP YANG H-PCE capabilities advertised by each peer. The "ietf-pcep" PCEP YANG
module is specified in <xref target="I-D.ietf-pce-pcep-yang"/>. This YANG mod ule module is specified in <xref target="I-D.ietf-pce-pcep-yang" format="default" />. This YANG module
will be required to be augmented to also include details for stateful will be required to be augmented to also include details for stateful
H-PCE deployment and operation. The exact model and attributes are H-PCE deployment and operation. The exact model and attributes are
out of scope for this document.</t> out of scope for this document.</t>
</section>
</section> <section anchor="sect-5.3" numbered="true" toc="default">
<name>Liveness Detection and Monitoring</name>
<section title="Liveness Detection and Monitoring" anchor="sect-5.3"><t> <t>
Mechanisms defined in this document do not imply any new liveness Mechanisms defined in this document do not imply any new liveness-detection
detection and monitoring requirements in addition to those already or monitoring requirements in addition to those already
listed in <xref target="RFC5440"/>.</t> listed in <xref target="RFC5440" format="default"/>.</t>
</section>
</section> <section anchor="sect-5.4" numbered="true" toc="default">
<name>Verification of Correct Operations</name>
<section title="Verify Correct Operations" anchor="sect-5.4"><t> <t>
Mechanisms defined in this document do not imply any new operation Mechanisms defined in this document do not imply any new
verification requirements in addition to those already listed in operation-verification requirements in addition to those already listed in
<xref target="RFC5440"/> and <xref target="RFC8231"/>.</t> <xref target="RFC5440" format="default"/> and <xref target="RFC8231" format="
default"/>.</t>
</section> </section>
<section anchor="sect-5.5" numbered="true" toc="default">
<section title="Requirements On Other Protocols" anchor="sect-5.5"><t> <name>Requirements on Other Protocols</name>
<t>
Mechanisms defined in this document do not imply any new requirements Mechanisms defined in this document do not imply any new requirements
on other protocols.</t> on other protocols.</t>
</section>
</section> <section anchor="sect-5.6" numbered="true" toc="default">
<name>Impact on Network Operations</name>
<section title="Impact On Network Operations" anchor="sect-5.6"><t> <t>
Mechanisms defined in <xref target="RFC5440"/> and <xref target="RFC8231"/> a Mechanisms defined in <xref target="RFC5440" format="default"/> and <xref tar
lso apply to PCEP get="RFC8231" format="default"/> also apply to PCEP
extensions defined in this document.</t> extensions defined in this document.</t>
<t> <t>
The stateful H-PCE technique brings the applicability of stateful PCE The stateful H-PCE technique brings the applicability of stateful PCE
as described in <xref target="RFC8051"/>, for the LSP traversing multiple dom (described in <xref target="RFC8051" format="default"/>) to the LSP traversin
ains.</t> g multiple domains.</t>
<t>
<t> As described in <xref target="sect-3" format="default"/>, a PCEP speaker incl
As described in <xref target="sect-3"/>, a PCEP speaker includes both the udes both the
H-PCE Capability TLV <xref target="I-D.ietf-pce-hierarchy-extensions"/> and H-PCE-CAPABILITY TLV <xref target="RFC8685" format="default"/> and
Stateful PCE Capability TLV <xref target="RFC8231"/> to indicate support STATEFUL-PCE-CAPABILITY TLV <xref target="RFC8231" format="default"/> to indi
for Stateful H-PCE. Note that there is a possibility of a PCEP speaker that cate support
does not support the Stateful H-PCE feature but does provide support for for stateful H-PCE. Note that there is a possibility of a PCEP speaker that
Stateful PCE <xref target="RFC8231"/> and H-PCE <xref does not support the stateful H-PCE feature but does provide support for
target="I-D.ietf-pce-hierarchy-extensions"/> features. This PCEP speaker stateful-PCE <xref target="RFC8231" format="default"/> and H-PCE <xref target
will also include both the TLVs and in this case a PCEP peer could falsely ="RFC8685" format="default"/> features. This PCEP speaker
will also include both the TLVs; in this case, a PCEP peer could falsely
assume that the stateful H-PCE feature is also supported. On further PCEP assume that the stateful H-PCE feature is also supported. On further PCEP
message exchange, the stateful messages will not get further propagated (as message exchange, the stateful messages will not be propagated further (as
described in this document) and a stateful H-PCE based 'parent' control of described in this document), and a stateful H-PCE-based "parent" control of
the LSP will not happen. A PCEP peer should be prepared for this the LSP will not happen. A PCEP peer should be prepared for this
eventuality as a part of normal procedures.</t> eventuality as a part of normal procedures.</t>
</section>
</section> <section anchor="sect-5.7" numbered="true" toc="default">
<name>Error Handling between PCEs</name>
<section title="Error Handling between PCEs" anchor="sect-5.7"><t> <t>
Apart from the basic error handling described in this document, an Apart from the basic error handling described in this document, an
implementation could also use the enhanced error and notification implementation could also use the enhanced error and notification
mechanism for stateful H-PCE operations as per <xref mechanism for stateful H-PCE operations described in <xref
target="I-D.ietf-pce-enhanced-errors"/>. Enhanced features such as target="I-D.ietf-pce-enhanced-errors" format="default"/>. Enhanced
error behavior propagation, notification and error criticality level, features such as
are further defined in <xref error-behavior propagation, notification, and error-criticality level
target="I-D.ietf-pce-enhanced-errors"/>.</t> are further defined in <xref target="I-D.ietf-pce-enhanced-errors" format
="default"/>.</t>
</section> </section>
</section>
</section> <section anchor="sect-6" numbered="true" toc="default">
<name>Other Considerations</name>
<section title="Other Considerations" anchor="sect-6"><section title="App <section anchor="sect-6.1" numbered="true" toc="default">
licability to Inter-Layer Traffic Engineering" anchor="sect-6.1"><t> <name>Applicability to Interlayer Traffic Engineering</name>
<xref target="RFC5623"/> describes a framework for applying the PCE-based <t>
architecture to inter-layer (G)MPLS traffic engineering. The H-PCE <xref target="RFC5623" format="default"/> describes a framework for applying
Stateful architecture with stateful P-PCE coordinating with the the PCE-based
stateful C-PCEs of higher and lower layer is shown in the figure architecture to interlayer (G)MPLS traffic engineering. The H-PCE
below.</t> stateful architecture with stateful P-PCE coordinating with the
stateful C-PCEs of higher and lower layer is shown in <xref
<figure title="Sample Inter-Layer Topology" anchor="ure-sample-inter-laye target="ure-sample-inter-layer-topology" />.</t>
r-topology"><artwork><![CDATA[ <figure anchor="ure-sample-inter-layer-topology">
<name>Sample Interlayer Topology</name>
<artwork name="" type="" align="left" alt=""><![CDATA[
+----------+ +----------+
| Parent | | Parent |
/| PCE | /| PCE |
/ +----------+ / +----------+
/ / Stateful / / Stateful
/ / P-PCE / / P-PCE
/ / / /
/ / / /
Stateful+-----+ / / Stateful+-----+ / /
C-PCE | PCE |/ / C-PCE | PCE |/ /
skipping to change at line 983 skipping to change at line 921
+---+ +---+\ +-----+/ /+---+ +---+ +---+ +---+\ +-----+/ /+---+ +---+
\ | PCE | / \ | PCE | /
\ | Lo | / \ | Lo | /
Stateful \ +-----+ / Stateful \ +-----+ /
C-PCE \ / C-PCE \ /
Lo \+---+ +---+/ Lo \+---+ +---+/
+ LSR +--+ LSR + + LSR +--+ LSR +
+ L1 + + L2 + + L1 + + L2 +
+---+ +---+ +---+ +---+
]]></artwork> ]]></artwork>
</figure> </figure>
<t> <t>
All procedures described in <xref target="sect-3"/> are applicable to inter-l All procedures described in <xref target="sect-3" format="default"/> are also
ayer applicable to interlayer path setup, and therefore to separate domains.</t>
(and therefore separate domains) path setup as well.</t> </section>
<section anchor="sect-6.2" numbered="true" toc="default">
</section> <name>Scalability Considerations</name>
<t>
<section title="Scalability Considerations" anchor="sect-6.2"><t> It should be noted that if all the C-PCEs were to report all the LSPs
It should be noted that if all the C-PCEs would report all the LSPs
in their domain, it could lead to scalability issues for the P-PCE. in their domain, it could lead to scalability issues for the P-PCE.
Thus it is recommended to only report the LSPs which are involved in Thus, it is recommended to only report the LSPs that are involved in
H-PCE, i.e. the LSPs which are either delegated to the P-PCE or H-PCE -- i.e., the LSPs that are either delegated to the P-PCE or
initiated by the P-PCE. Scalability considerations for PCEP as per initiated by the P-PCE. Scalability considerations for PCEP as per
<xref target="RFC8231"/> continue to apply for the PCEP session between child and <xref target="RFC8231" format="default"/> continue to apply for the PCEP sess ion between child and
parent PCE.</t> parent PCE.</t>
</section>
</section> <section anchor="sect-6.3" numbered="true" toc="default">
<name>Confidentiality</name>
<section title="Confidentiality" anchor="sect-6.3"><t> <t>
As described in section 4.2 of <xref target="RFC6805"/>, information about th As described in <xref target="RFC6805" sectionFormat="of" section="4.2"/>,
e information about the
content of child domains is not shared for both scaling and content of child domains is not shared, for both scaling and
confidentiality reasons. The child PCE could also conceal the path confidentiality reasons. The child PCE could also conceal the path
information during path computation. A C-PCE may replace a path information during path computation. A C-PCE may replace a path
segment with a path-key <xref target="RFC5520"/>, effectively hiding the cont ent of segment with a path-key <xref target="RFC5520" format="default"/>, effectivel y hiding the content of
a segment of a path.</t> a segment of a path.</t>
</section>
</section>
<section anchor="sect-7" numbered="true" toc="default">
<name>IANA Considerations</name>
<t>
This document has no IANA actions.</t>
</section>
</middle>
<back>
</section> <displayreference target="I-D.litkowski-pce-state-sync" to="PCE-STATE-SYNC"/>
<displayreference target="I-D.ietf-pce-pcep-yang" to="PCE-PCEP-YANG"/>
<displayreference target="I-D.dugeon-pce-stateful-interdomain" to="STATEFUL-INTE
RDOMAIN"/>
<displayreference target="I-D.ietf-pce-enhanced-errors" to="PCE-ENHANCED-ERRORS"
/>
</section> <references>
<name>References</name>
<references>
<name>Normative References</name>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.2119.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.4655.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.5440.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.5520.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.5925.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.6805.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.7525.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.8174.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.8231.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.8253.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.8281.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.8446.xml"/>
</references>
<references>
<name>Informative References</name>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.3209.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.3473.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.4726.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.5623.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.8051.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.8232.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.8453.xml"/>
<xi:include
href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.
8637.xml"/>
<xi:include
href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.
8685.xml"/>
<section title="IANA Considerations" anchor="sect-7"><t> <xi:include
There are no IANA considerations.</t> href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.
8741.xml"/>
</section> <xi:include
href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.
8745.xml"/>
<section title="Acknowledgments" anchor="sect-8"><t> <!-- draft-ietf-pce-enhanced-errors; I-D Exists -->
Thanks to Manuela Scarella, Haomian Zheng, Sergio Marmo, Stefano <xi:include
Parodi, Giacomo Agostini, Jeff Tantsura, Rajan Rao, Adrian Farrel and href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D
Haomian Zheng, for their reviews and suggestions.</t> .draft-ietf-pce-enhanced-errors-06.xml"/>
<t> <!-- draft-ietf-pce-pcep-yang; I-D Exists -->
Thanks to Tal Mazrahi for the RTGDIR review, Paul Kyzivat for the <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/refe
GENART review, and Stephen Farrell for SECDIR review.</t> rence.I-D.draft-ietf-pce-pcep-yang-13.xml"/>
<t> <!-- draft-litkowski-pce-state-sync; I-D Exists -->
Thanks to Barry Leiba, Martin Vigoureux, Benjamin Kaduk, and Roman <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/refe
Danyliw for IESG review.</t> rence.I-D.draft-litkowski-pce-state-sync-07.xml"/>
</section> <!-- draft-dugeon-pce-stateful-interdomain; I-D Exists -->
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/refe
rence.I-D.draft-dugeon-pce-stateful-interdomain-02.xml"/>
</middle> </references>
</references>
<back> <section anchor="sect-8" numbered="false" toc="default">
<references title="Normative References"> <name>Acknowledgments</name>
&RFC2119; <t>
&RFC4655; Thanks to <contact fullname="Manuela Scarella"></contact>, <contact fullname=
&RFC5440; "Haomian Zheng"></contact>, <contact fullname="Sergio Marmo"></contact>, <contac
&RFC5520; t fullname="Stefano
&RFC5925; Parodi"></contact>, <contact fullname="Giacomo Agostini"></contact>, <contact
&RFC6805; fullname="Jeff Tantsura"></contact>, <contact fullname="Rajan Rao"></contact>,
&RFC7525; <contact fullname="Adrian Farrel"></contact>, and
&RFC8174; <contact fullname="Haomian Zheng"></contact> for their reviews and suggestion
&RFC8231; s.</t>
&RFC8253; <t>
&RFC8281; Thanks to <contact fullname="Tal Mazrahi"></contact> for the RTGDIR
&RFC8446; review, <contact fullname="Paul Kyzivat"></contact> for the
</references> GENART review, and <contact fullname="Stephen Farrell"></contact>
<references title="Informative References"> for the SECDIR review.</t>
&RFC3209; <t>
&RFC3473; Thanks to <contact fullname="Barry Leiba"></contact>, <contact fullname="Mart
&RFC4726; in Vigoureux"></contact>, <contact fullname="Benjamin Kaduk"></contact>, and <co
&RFC5623; ntact fullname="Roman
&RFC8051; Danyliw"></contact> for the IESG review.</t>
&RFC8232; </section>
&RFC8453;
&RFC8637;
&I-D.litkowski-pce-state-sync;
&I-D.ietf-pce-hierarchy-extensions;
&I-D.ietf-pce-pcep-yang;
&I-D.dugeon-pce-stateful-interdomain;
&I-D.ietf-pce-lsp-control-request;
&I-D.ietf-pce-enhanced-errors;
&I-D.ietf-pce-stateful-path-protection;
</references>
<section title="Contributors" numbered="no" anchor="contributors"><figure
><artwork><![CDATA[
Avantika
ECI Telecom
India
EMail: avantika.srm@gmail.com <section numbered="false" anchor="contributors" toc="default">
<name>Contributors</name>
Xian Zhang <contact fullname="Avantika">
Huawei Technologies <organization>ECI Telecom</organization>
Bantian, Longgang District <address><postal><country>India</country></postal>
Shenzhen, Guangdong 518129
P.R.China
EMail: zhang.xian@huawei.com <email>avantika.srm@gmail.com</email></address></contact>
Udayasree Palle <contact fullname="Xian Zhang">
<organization>Huawei Technologies</organization>
<address>
<postal>
<street>Bantian, Longgang District</street>
<region>Shenzhen</region>
<city>Guangdong</city>
<code>518129</code>
<country>China</country>
</postal>
EMail: udayasreereddy@gmail.com <email>zhang.xian@huawei.com</email></address></contact>
Oscar Gonzalez de Dios <contact fullname="Udayasree Palle">
Telefonica I+D <address>
Don Ramon de la Cruz 82-84 <email>udayasreereddy@gmail.com</email></address></contact>
Madrid, 28045
Spain
Phone: +34913128832
EMail: oscar.gonzalezdedios@telefonica.com <contact fullname="Oscar Gonzalez de Dios">
]]></artwork> <organization>Telefonica I+D</organization>
</figure> <address>
</section> <postal>
<street>Don Ramon de la Cruz 82-84</street>
<city>Madrid</city> <code>28045</code>
<country>Spain</country></postal>
<phone>+34913128832</phone>
</back> <email>oscar.gonzalezdedios@telefonica.com</email>
</address>
</contact>
</rfc> </section>
</back>
</rfc>
 End of changes. 131 change blocks. 
902 lines changed or deleted 899 lines changed or added

This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/