File: rfc8751.html

package info (click to toggle)
doc-rfc 20230121-1
links: PTS, VCS
area: non-free
in suites: bookworm, forky, sid, trixie
size: 1,609,944 kB
file content (2574 lines) | stat: -rw-r--r-- 125,103 bytes
parent folder | download | duplicates (2)
<!DOCTYPE html>
<html lang="en" class="RFC">
<head>
<meta charset="utf-8">
<meta content="Common,Latin" name="scripts">
<meta content="initial-scale=1.0" name="viewport">
<title>RFC 8751: Hierarchical Stateful Path Computation Element (PCE)</title>
<meta content="Dhruv Dhody" name="author">
<meta content="Young Lee" name="author">
<meta content="Daniele Ceccarelli" name="author">
<meta content="Jongyoon Shin" name="author">
<meta content="Daniel King" name="author">
<meta content="
       
   A stateful Path Computation Element (PCE) maintains information on
   the current network state received from the Path Computation Clients
   (PCCs), including computed Label Switched Paths (LSPs), reserved
   resources within the network, and pending path computation requests.
   This information may then be considered when computing the path for a
   new traffic-engineered LSP or for any associated/dependent LSPs. The
   path-computation response from a PCE helps the PCC to
   gracefully establish the computed LSP. 
       
   The Hierarchical Path Computation Element (H-PCE) architecture
   allows the optimum sequence of
   interconnected domains to be selected and network policy to be
   applied if applicable, via the use of a hierarchical relationship
   between PCEs. 
       
   Combining the capabilities of stateful PCE and the hierarchical PCE
   would be advantageous. This document describes general considerations
   and use cases for the deployment of stateful, but not stateless, PCEs
   using the hierarchical PCE architecture. 
    " name="description">
<meta content="xml2rfc 2.41.0" name="generator">
<meta content="8751" name="rfc.number">
<link href="rfc8751.xml" rel="alternate" type="application/rfc+xml">
<link href="#copyright" rel="license">
<style type="text/css">/*

  NOTE: Changes at the bottom of this file overrides some earlier settings.

  Once the style has stabilized and has been adopted as an official RFC style,
  this can be consolidated so that style settings occur only in one place, but
  for now the contents of this file consists first of the initial CSS work as
  provided to the RFC Formatter (xml2rfc) work, followed by itemized and
  commented changes found necssary during the development of the v3
  formatters.

*/

/* fonts */
@import url('https://fonts.googleapis.com/css?family=Noto+Sans'); /* Sans-serif */
@import url('https://fonts.googleapis.com/css?family=Noto+Serif'); /* Serif (print) */
@import url('https://fonts.googleapis.com/css?family=Roboto+Mono'); /* Monospace */

@viewport {
  zoom: 1.0;
  width: extend-to-zoom;
}
@-ms-viewport {
  width: extend-to-zoom;
  zoom: 1.0;
}
/* general and mobile first */
html {
}
body {
  max-width: 90%;
  margin: 1.5em auto;
  color: #222;
  background-color: #fff;
  font-size: 14px;
  font-family: 'Noto Sans', Arial, Helvetica, sans-serif;
  line-height: 1.6;
  scroll-behavior: smooth;
}
.ears {
  display: none;
}

/* headings */
#title, h1, h2, h3, h4, h5, h6 {
  margin: 1em 0 0.5em;
  font-weight: bold;
  line-height: 1.3;
}
#title {
  clear: both;
  border-bottom: 1px solid #ddd;
  margin: 0 0 0.5em 0;
  padding: 1em 0 0.5em;
}
.author {
  padding-bottom: 4px;
}
h1 {
  font-size: 26px;
  margin: 1em 0;
}
h2 {
  font-size: 22px;
  margin-top: -20px;  /* provide offset for in-page anchors */
  padding-top: 33px;
}
h3 {
  font-size: 18px;
  margin-top: -36px;  /* provide offset for in-page anchors */
  padding-top: 42px;
}
h4 {
  font-size: 16px;
  margin-top: -36px;  /* provide offset for in-page anchors */
  padding-top: 42px;
}
h5, h6 {
  font-size: 14px;
}
#n-copyright-notice {
  border-bottom: 1px solid #ddd;
  padding-bottom: 1em;
  margin-bottom: 1em;
}
/* general structure */
p {
  padding: 0;
  margin: 0 0 1em 0;
  text-align: left;
}
div, span {
  position: relative;
}
div {
  margin: 0;
}
.alignRight.art-text {
  background-color: #f9f9f9;
  border: 1px solid #eee;
  border-radius: 3px;
  padding: 1em 1em 0;
  margin-bottom: 1.5em;
}
.alignRight.art-text pre {
  padding: 0;
}
.alignRight {
  margin: 1em 0;
}
.alignRight > *:first-child {
  border: none;
  margin: 0;
  float: right;
  clear: both;
}
.alignRight > *:nth-child(2) {
  clear: both;
  display: block;
  border: none;
}
svg {
  display: block;
}
.alignCenter.art-text {
  background-color: #f9f9f9;
  border: 1px solid #eee;
  border-radius: 3px;
  padding: 1em 1em 0;
  margin-bottom: 1.5em;
}
.alignCenter.art-text pre {
  padding: 0;
}
.alignCenter {
  margin: 1em 0;
}
.alignCenter > *:first-child {
  border: none;
  /* this isn't optimal, but it's an existence proof.  PrinceXML doesn't
     support flexbox yet.
  */
  display: table;
  margin: 0 auto;
}

/* lists */
ol, ul {
  padding: 0;
  margin: 0 0 1em 2em;
}
ol ol, ul ul, ol ul, ul ol {
  margin-left: 1em;
}
li {
  margin: 0 0 0.25em 0;
}
.ulCompact li {
  margin: 0;
}
ul.empty, .ulEmpty {
  list-style-type: none;
}
ul.empty li, .ulEmpty li {
  margin-top: 0.5em;
}
ul.compact, .ulCompact,
ol.compact, .olCompact {
  line-height: 100%;
  margin: 0 0 0 2em;
}

/* definition lists */
dl {
}
dl > dt {
  float: left;
  margin-right: 1em;
}
/* 
dl.nohang > dt {
  float: none;
}
*/
dl > dd {
  margin-bottom: .8em;
  min-height: 1.3em;
}
dl.compact > dd, .dlCompact > dd {
  margin-bottom: 0em;
}
dl > dd > dl {
  margin-top: 0.5em;
  margin-bottom: 0em;
}

/* links */
a {
  text-decoration: none;
}
a[href] {
  color: #22e; /* Arlen: WCAG 2019 */
}
a[href]:hover {
  background-color: #f2f2f2;
}
figcaption a[href],
a[href].selfRef {
  color: #222;
}
/* XXX probably not this:
a.selfRef:hover {
  background-color: transparent;
  cursor: default;
} */

/* Figures */
tt, code, pre, code {
  background-color: #f9f9f9;
  font-family: 'Roboto Mono', monospace;
}
pre {
  border: 1px solid #eee;
  margin: 0;
  padding: 1em;
}
img {
  max-width: 100%;
}
figure {
  margin: 0;
}
figure blockquote {
  margin: 0.8em 0.4em 0.4em;
}
figcaption {
  font-style: italic;
  margin: 0 0 1em 0;
}
@media screen {
  pre {
    overflow-x: auto;
    max-width: 100%;
    max-width: calc(100% - 22px);
  }
}

/* aside, blockquote */
aside, blockquote {
  margin-left: 0;
  padding: 1.2em 2em;
}
blockquote {
  background-color: #f9f9f9;
  color: #111; /* Arlen: WCAG 2019 */
  border: 1px solid #ddd;
  border-radius: 3px;
  margin: 1em 0;
}
cite {
  display: block;
  text-align: right;
  font-style: italic;
}

/* tables */
table {
  width: 100%;
  margin: 0 0 1em;
  border-collapse: collapse;
  border: 1px solid #eee;
}
th, td {
  text-align: left;
  vertical-align: top;
  padding: 0.5em 0.75em;
}
th {
  text-align: left;
  background-color: #e9e9e9;
}
tr:nth-child(2n+1) > td {
  background-color: #f5f5f5;
}
table caption {
  font-style: italic;
  margin: 0;
  padding: 0;
  text-align: left;
}
table p {
  /* XXX to avoid bottom margin on table row signifiers. If paragraphs should
     be allowed within tables more generally, it would be far better to select on a class. */
  margin: 0;
}

/* pilcrow */
a.pilcrow {
  color: #666; /* Arlen: AHDJ 2019 */
  text-decoration: none;
  visibility: hidden;
  user-select: none;
  -ms-user-select: none;
  -o-user-select:none;
  -moz-user-select: none;
  -khtml-user-select: none;
  -webkit-user-select: none;
  -webkit-touch-callout: none;
}
@media screen {
  aside:hover > a.pilcrow,
  p:hover > a.pilcrow,
  blockquote:hover > a.pilcrow,
  div:hover > a.pilcrow,
  li:hover > a.pilcrow,
  pre:hover > a.pilcrow {
    visibility: visible;
  }
  a.pilcrow:hover {
    background-color: transparent;
  }
}

/* misc */
hr {
  border: 0;
  border-top: 1px solid #eee;
}
.bcp14 {
  font-variant: small-caps;
}

.role {
  font-variant: all-small-caps;
}

/* info block */
#identifiers {
  margin: 0;
  font-size: 0.9em;
}
#identifiers dt {
  width: 3em;
  clear: left;
}
#identifiers dd {
  float: left;
  margin-bottom: 0;
}
#identifiers .authors .author {
  display: inline-block;
  margin-right: 1.5em;
}
#identifiers .authors .org {
  font-style: italic;
}

/* The prepared/rendered info at the very bottom of the page */
.docInfo {
  color: #666; /* Arlen: WCAG 2019 */
  font-size: 0.9em;
  font-style: italic;
  margin-top: 2em;
}
.docInfo .prepared {
  float: left;
}
.docInfo .prepared {
  float: right;
}

/* table of contents */
#toc  {
  padding: 0.75em 0 2em 0;
  margin-bottom: 1em;
}
nav.toc ul {
  margin: 0 0.5em 0 0;
  padding: 0;
  list-style: none;
}
nav.toc li {
  line-height: 1.3em;
  margin: 0.75em 0;
  padding-left: 1.2em;
  text-indent: -1.2em;
}
/* references */
.references dt {
  text-align: right;
  font-weight: bold;
  min-width: 7em;
}
.references dd {
  margin-left: 8em;
  overflow: auto;
}

.refInstance {
  margin-bottom: 1.25em;
}

.references .ascii {
  margin-bottom: 0.25em;
}

/* index */
.index ul {
  margin: 0 0 0 1em;
  padding: 0;
  list-style: none;
}
.index ul ul {
  margin: 0;
}
.index li {
  margin: 0;
  text-indent: -2em;
  padding-left: 2em;
  padding-bottom: 5px;
}
.indexIndex {
  margin: 0.5em 0 1em;
}
.index a {
  font-weight: 700;
}
/* make the index two-column on all but the smallest screens */
@media (min-width: 600px) {
  .index ul {
    -moz-column-count: 2;
    -moz-column-gap: 20px;
  }
  .index ul ul {
    -moz-column-count: 1;
    -moz-column-gap: 0;
  }
}

/* authors */
address.vcard {
  font-style: normal;
  margin: 1em 0;
}

address.vcard .nameRole {
  font-weight: 700;
  margin-left: 0;
}
address.vcard .label {
  font-family: "Noto Sans",Arial,Helvetica,sans-serif;
  margin: 0.5em 0;
}
address.vcard .type {
  display: none;
}
.alternative-contact {
  margin: 1.5em 0 1em;
}
hr.addr {
  border-top: 1px dashed;
  margin: 0;
  color: #ddd;
  max-width: calc(100% - 16px);
}

/* temporary notes */
.rfcEditorRemove::before {
  position: absolute;
  top: 0.2em;
  right: 0.2em;
  padding: 0.2em;
  content: "The RFC Editor will remove this note";
  color: #9e2a00; /* Arlen: WCAG 2019 */
  background-color: #ffd; /* Arlen: WCAG 2019 */
}
.rfcEditorRemove {
  position: relative;
  padding-top: 1.8em;
  background-color: #ffd; /* Arlen: WCAG 2019 */
  border-radius: 3px;
}
.cref {
  background-color: #ffd; /* Arlen: WCAG 2019 */
  padding: 2px 4px;
}
.crefSource {
  font-style: italic;
}
/* alternative layout for smaller screens */
@media screen and (max-width: 1023px) {
  body {
    padding-top: 2em;
  }
  #title {
    padding: 1em 0;
  }
  h1 {
    font-size: 24px;
  }
  h2 {
    font-size: 20px;
    margin-top: -18px;  /* provide offset for in-page anchors */
    padding-top: 38px;
  }
  #identifiers dd {
    max-width: 60%;
  }
  #toc {
    position: fixed;
    z-index: 2;
    top: 0;
    right: 0;
    padding: 0;
    margin: 0;
    background-color: inherit;
    border-bottom: 1px solid #ccc;
  }
  #toc h2 {
    margin: -1px 0 0 0;
    padding: 4px 0 4px 6px;
    padding-right: 1em;
    min-width: 190px;
    font-size: 1.1em;
    text-align: right;
    background-color: #444;
    color: white;
    cursor: pointer;
  }
  #toc h2::before { /* css hamburger */
    float: right;
    position: relative;
    width: 1em;
    height: 1px;
    left: -164px;
    margin: 6px 0 0 0;
    background: white none repeat scroll 0 0;
    box-shadow: 0 4px 0 0 white, 0 8px 0 0 white;
    content: "";
  }
  #toc nav {
    display: none;
    padding: 0.5em 1em 1em;
    overflow: auto;
    height: calc(100vh - 48px);
    border-left: 1px solid #ddd;
  }
}

/* alternative layout for wide screens */
@media screen and (min-width: 1024px) {
  body {
    max-width: 724px;
    margin: 42px auto;
    padding-left: 1.5em;
    padding-right: 29em;
  }
  #toc {
    position: fixed;
    top: 42px;
    right: 42px;
    width: 25%;
    margin: 0;
    padding: 0 1em;
    z-index: 1;
  }
  #toc h2 {
    border-top: none;
    border-bottom: 1px solid #ddd;
    font-size: 1em;
    font-weight: normal;
    margin: 0;
    padding: 0.25em 1em 1em 0;
  }
  #toc nav {
    display: block;
    height: calc(90vh - 84px);
    bottom: 0;
    padding: 0.5em 0 0;
    overflow: auto;
  }
  img { /* future proofing */
    max-width: 100%;
    height: auto;
  }
}

/* pagination */
@media print {
  body {

    width: 100%;
  }
  p {
    orphans: 3;
    widows: 3;
  }
  #n-copyright-notice {
    border-bottom: none;
  }
  #toc, #n-introduction {
    page-break-before: always;
  }
  #toc {
    border-top: none;
    padding-top: 0;
  }
  figure, pre {
    page-break-inside: avoid;
  }
  figure {
    overflow: scroll;
  }
  h1, h2, h3, h4, h5, h6 {
    page-break-after: avoid;
  }
  h2+*, h3+*, h4+*, h5+*, h6+* {
    page-break-before: avoid;
  }
  pre {
    white-space: pre-wrap;
    word-wrap: break-word;
    font-size: 10pt;
  }
  table {
    border: 1px solid #ddd;
  }
  td {
    border-top: 1px solid #ddd;
  }
}

/* This is commented out here, as the string-set: doesn't
   pass W3C validation currently */
/*
.ears thead .left {
  string-set: ears-top-left content();
}

.ears thead .center {
  string-set: ears-top-center content();
}

.ears thead .right {
  string-set: ears-top-right content();
}

.ears tfoot .left {
  string-set: ears-bottom-left content();
}

.ears tfoot .center {
  string-set: ears-bottom-center content();
}

.ears tfoot .right {
  string-set: ears-bottom-right content();
}
*/

@page :first {
  padding-top: 0;
  @top-left {
    content: normal;
    border: none;
  }
  @top-center {
    content: normal;
    border: none;
  }
  @top-right {
    content: normal;
    border: none;
  }
}

@page {
  size: A4;
  margin-bottom: 45mm;
  padding-top: 20px;
  /* The follwing is commented out here, but set appropriately by in code, as
     the content depends on the document */
  /*
  @top-left {
    content: 'Internet-Draft';
    vertical-align: bottom;
    border-bottom: solid 1px #ccc;
  }
  @top-left {
    content: string(ears-top-left);
    vertical-align: bottom;
    border-bottom: solid 1px #ccc;
  }
  @top-center {
    content: string(ears-top-center);
    vertical-align: bottom;
    border-bottom: solid 1px #ccc;
  }
  @top-right {
    content: string(ears-top-right);
    vertical-align: bottom;
    border-bottom: solid 1px #ccc;
  }
  @bottom-left {
    content: string(ears-bottom-left);
    vertical-align: top;
    border-top: solid 1px #ccc;
  }
  @bottom-center {
    content: string(ears-bottom-center);
    vertical-align: top;
    border-top: solid 1px #ccc;
  }
  @bottom-right {
      content: '[Page ' counter(page) ']';
      vertical-align: top;
      border-top: solid 1px #ccc;
  }
  */

}

/* Changes introduced to fix issues found during implementation */
/* Make sure links are clickable even if overlapped by following H* */
a {
  z-index: 2;
}
/* Separate body from document info even without intervening H1 */
section {
  clear: both;
}


/* Top align author divs, to avoid names without organization dropping level with org names */
.author {
  vertical-align: top;
}

/* Leave room in document info to show Internet-Draft on one line */
#identifiers dt {
  width: 8em;
}

/* Don't waste quite as much whitespace between label and value in doc info */
#identifiers dd {
  margin-left: 1em;
}

/* Give floating toc a background color (needed when it's a div inside section */
#toc {
  background-color: white;
}

/* Make the collapsed ToC header render white on gray also when it's a link */
@media screen and (max-width: 1023px) {
  #toc h2 a,
  #toc h2 a:link,
  #toc h2 a:focus,
  #toc h2 a:hover,
  #toc a.toplink,
  #toc a.toplink:hover {
    color: white;
    background-color: #444;
    text-decoration: none;
  }
}

/* Give the bottom of the ToC some whitespace */
@media screen and (min-width: 1024px) {
  #toc {
    padding: 0 0 1em 1em;
  }
}

/* Style section numbers with more space between number and title */
.section-number {
  padding-right: 0.5em;
}

/* prevent monospace from becoming overly large */
tt, code, pre, code {
  font-size: 95%;
}

/* Fix the height/width aspect for ascii art*/
pre.sourcecode,
.art-text pre {
  line-height: 1.12;
}


/* Add styling for a link in the ToC that points to the top of the document */
a.toplink {
  float: right;
  margin-right: 0.5em;
}

/* Fix the dl styling to match the RFC 7992 attributes */
dl > dt,
dl.dlParallel > dt {
  float: left;
  margin-right: 1em;
}
dl.dlNewline > dt {
  float: none;
}

/* Provide styling for table cell text alignment */
table td.text-left,
table th.text-left {
  text-align: left;
}
table td.text-center,
table th.text-center {
  text-align: center;
}
table td.text-right,
table th.text-right {
  text-align: right;
}

/* Make the alternative author contact informatio look less like just another
   author, and group it closer with the primary author contact information */
.alternative-contact {
  margin: 0.5em 0 0.25em 0;
}
address .non-ascii {
  margin: 0 0 0 2em;
}

/* With it being possible to set tables with alignment
  left, center, and right, { width: 100%; } does not make sense */
table {
  width: auto;
}

/* Avoid reference text that sits in a block with very wide left margin,
   because of a long floating dt label.*/
.references dd {
  overflow: visible;
}

/* Control caption placement */
caption {
  caption-side: bottom;
}

/* Limit the width of the author address vcard, so names in right-to-left
   script don't end up on the other side of the page. */

address.vcard {
  max-width: 30em;
  margin-right: auto;
}

/* For address alignment dependent on LTR or RTL scripts */
address div.left {
  text-align: left;
}
address div.right {
  text-align: right;
}

/* Provide table alignment support.  We can't use the alignX classes above
   since they do unwanted things with caption and other styling. */
table.right {
 margin-left: auto;
 margin-right: 0;
}
table.center {
 margin-left: auto;
 margin-right: auto;
}
table.left {
 margin-left: 0;
 margin-right: auto;
}

/* Give the table caption label the same styling as the figcaption */
caption a[href] {
  color: #222;
}

@media print {
  .toplink {
    display: none;
  }

  /* avoid overwriting the top border line with the ToC header */
  #toc {
    padding-top: 1px;
  }

  /* Avoid page breaks inside dl and author address entries */
  .vcard {
    page-break-inside: avoid;
  }

}
/* Avoid wrapping of URLs in references */
@media screen {
  .references a {
    white-space: nowrap;
  }
}
/* Tweak the bcp14 keyword presentation */
.bcp14 {
  font-variant: small-caps;
  font-weight: bold;
  font-size: 0.9em;
}
/* Tweak the invisible space above H* in order not to overlay links in text above */
 h2 {
  margin-top: -18px;  /* provide offset for in-page anchors */
  padding-top: 31px;
 }
 h3 {
  margin-top: -18px;  /* provide offset for in-page anchors */
  padding-top: 24px;
 }
 h4 {
  margin-top: -18px;  /* provide offset for in-page anchors */
  padding-top: 24px;
 }
/* Float artwork pilcrow to the right */
@media screen {
  .artwork a.pilcrow {
    display: block;
    line-height: 0.7;
    margin-top: 0.15em;
  }
}
/* Make pilcrows on dd visible */
@media screen {
  dd:hover > a.pilcrow {
    visibility: visible;
  }
}
/* Make the placement of figcaption match that of a table's caption
   by removing the figure's added bottom margin */
.alignLeft.art-text,
.alignCenter.art-text,
.alignRight.art-text {
   margin-bottom: 0;
}
.alignLeft,
.alignCenter,
.alignRight {
  margin: 1em 0 0 0;
}
/* In print, the pilcrow won't show on hover, so prevent it from taking up space,
   possibly even requiring a new line */
@media print {
  a.pilcrow {
    display: none;
  }
}
/* Styling for the external metadata */
div#external-metadata {
  background-color: #eee;
  padding: 0.5em;
  margin-bottom: 0.5em;
  display: none;
}
div#internal-metadata {
  padding: 0.5em;                       /* to match the external-metadata padding */
}
/* Styling for title RFC Number */
h1#rfcnum {
  clear: both;
  margin: 0 0 -1em;
  padding: 1em 0 0 0;
}
/* Make .olPercent look the same as <ol><li> */
dl.olPercent > dd {
  margin-bottom: 0.25em;
  min-height: initial;
}
/* Give aside some styling to set it apart */
aside {
  border-left: 1px solid #ddd;
  margin: 1em 0 1em 2em;
  padding: 0.2em 2em;
}
aside > dl,
aside > ol,
aside > ul,
aside > table,
aside > p {
  margin-bottom: 0.5em;
}
/* Additional page break settings */
@media print {
  figcaption, table caption {
    page-break-before: avoid;
  }
}
/* Font size adjustments for print */
@media print {
  body  { font-size: 10pt;      line-height: normal; max-width: 96%; }
  h1    { font-size: 1.72em;    padding-top: 1.5em; } /* 1*1.2*1.2*1.2 */
  h2    { font-size: 1.44em;    padding-top: 1.5em; } /* 1*1.2*1.2 */
  h3    { font-size: 1.2em;     padding-top: 1.5em; } /* 1*1.2 */
  h4    { font-size: 1em;       padding-top: 1.5em; }
  h5, h6 { font-size: 1em;      margin: initial; padding: 0.5em 0 0.3em; }
}
/* Sourcecode margin in print, when there's no pilcrow */
@media print {
  .artwork,
  .sourcecode {
    margin-bottom: 1em;
  }
}
/* Avoid narrow tables forcing too narrow table captions, which may render badly */
table {
  min-width: 20em;
}
/* ol type a */
ol.type-a { list-style-type: lower-alpha; }
ol.type-A { list-style-type: upper-alpha; }
ol.type-i { list-style-type: lower-roman; }
ol.type-I { list-style-type: lower-roman; }
/* Apply the print table and row borders in general, on request from the RPC,
and increase the contrast between border and odd row background sligthtly */
table {
  border: 1px solid #ddd;
}
td {
  border-top: 1px solid #ddd;
}
tr:nth-child(2n+1) > td {
  background-color: #f8f8f8;
}
/* Use style rules to govern display of the TOC. */
@media screen and (max-width: 1023px) {
  #toc nav { display: none; }
  #toc.active nav { display: block; }
}
</style>
<link href="rfc-local.css" rel="stylesheet" type="text/css">
<link href="https://dx.doi.org/10.17487/rfc8751" rel="alternate">
  <link href="urn:issn:2070-1721" rel="alternate">
  <link href="https://datatracker.ietf.org/doc/draft-ietf-pce-stateful-hpce-15" rel="prev">
  </head>
<body>
<script src="https://www.rfc-editor.org/js/metadata.min.js"></script>
<table class="ears">
<thead><tr>
<td class="left">RFC 8751</td>
<td class="center">Hierarchical Stateful PCE</td>
<td class="right">March 2020</td>
</tr></thead>
<tfoot><tr>
<td class="left">Dhody, et al.</td>
<td class="center">Informational</td>
<td class="right">[Page]</td>
</tr></tfoot>
</table>
<div id="external-metadata" class="document-information"></div>
<div id="internal-metadata" class="document-information">
<dl id="identifiers">
<dt class="label-stream">Stream:</dt>
<dd class="stream">Internet Engineering Task Force (IETF)</dd>
<dt class="label-rfc">RFC:</dt>
<dd class="rfc"><a href="https://www.rfc-editor.org/rfc/rfc8751" class="eref">8751</a></dd>
<dt class="label-category">Category:</dt>
<dd class="category">Informational</dd>
<dt class="label-published">Published:</dt>
<dd class="published">
<time datetime="2020-03" class="published">March 2020</time>
    </dd>
<dt class="label-issn">ISSN:</dt>
<dd class="issn">2070-1721</dd>
<dt class="label-authors">Authors:</dt>
<dd class="authors">
<div class="author">
      <div class="author-name">D. Dhody</div>
<div class="org">Huawei Technologies</div>
</div>
<div class="author">
      <div class="author-name">Y. Lee</div>
<div class="org">Samsung Electronics</div>
</div>
<div class="author">
      <div class="author-name">D. Ceccarelli</div>
<div class="org">Ericsson</div>
</div>
<div class="author">
      <div class="author-name">J. Shin</div>
<div class="org">SK Telecom</div>
</div>
<div class="author">
      <div class="author-name">D. King</div>
<div class="org">Lancaster University</div>
</div>
</dd>
</dl>
</div>
<h1 id="rfcnum">RFC 8751</h1>
<h1 id="title">Hierarchical Stateful Path Computation Element (PCE)</h1>
<section id="section-abstract">
      <h2 id="abstract"><a href="#abstract" class="selfRef">Abstract</a></h2>
<p id="section-abstract-1">
   A stateful Path Computation Element (PCE) maintains information on
   the current network state received from the Path Computation Clients
   (PCCs), including computed Label Switched Paths (LSPs), reserved
   resources within the network, and pending path computation requests.
   This information may then be considered when computing the path for a
   new traffic-engineered LSP or for any associated/dependent LSPs. The
   path-computation response from a PCE helps the PCC to
   gracefully establish the computed LSP.<a href="#section-abstract-1" class="pilcrow">¶</a></p>
<p id="section-abstract-2">
   The Hierarchical Path Computation Element (H-PCE) architecture
   allows the optimum sequence of
   interconnected domains to be selected and network policy to be
   applied if applicable, via the use of a hierarchical relationship
   between PCEs.<a href="#section-abstract-2" class="pilcrow">¶</a></p>
<p id="section-abstract-3">
   Combining the capabilities of stateful PCE and the hierarchical PCE
   would be advantageous. This document describes general considerations
   and use cases for the deployment of stateful, but not stateless, PCEs
   using the hierarchical PCE architecture.<a href="#section-abstract-3" class="pilcrow">¶</a></p>
</section>
<div id="status-of-memo">
<section id="section-boilerplate.1">
        <h2 id="name-status-of-this-memo">
<a href="#name-status-of-this-memo" class="section-name selfRef">Status of This Memo</a>
        </h2>
<p id="section-boilerplate.1-1">
            This document is not an Internet Standards Track specification; it is
            published for informational purposes.<a href="#section-boilerplate.1-1" class="pilcrow">¶</a></p>
<p id="section-boilerplate.1-2">
            This document is a product of the Internet Engineering Task Force
            (IETF).  It represents the consensus of the IETF community.  It has
            received public review and has been approved for publication by the
            Internet Engineering Steering Group (IESG).  Not all documents
            approved by the IESG are candidates for any level of Internet
            Standard; see Section 2 of RFC 7841.<a href="#section-boilerplate.1-2" class="pilcrow">¶</a></p>
<p id="section-boilerplate.1-3">
            Information about the current status of this document, any
            errata, and how to provide feedback on it may be obtained at
            <span><a href="https://www.rfc-editor.org/info/rfc8751">https://www.rfc-editor.org/info/rfc8751</a></span>.<a href="#section-boilerplate.1-3" class="pilcrow">¶</a></p>
</section>
</div>
<div id="copyright">
<section id="section-boilerplate.2">
        <h2 id="name-copyright-notice">
<a href="#name-copyright-notice" class="section-name selfRef">Copyright Notice</a>
        </h2>
<p id="section-boilerplate.2-1">
            Copyright (c) 2020 IETF Trust and the persons identified as the
            document authors. All rights reserved.<a href="#section-boilerplate.2-1" class="pilcrow">¶</a></p>
<p id="section-boilerplate.2-2">
            This document is subject to BCP 78 and the IETF Trust's Legal
            Provisions Relating to IETF Documents
            (<span><a href="https://trustee.ietf.org/license-info">https://trustee.ietf.org/license-info</a></span>) in effect on the date of
            publication of this document. Please review these documents
            carefully, as they describe your rights and restrictions with
            respect to this document. Code Components extracted from this
            document must include Simplified BSD License text as described in
            Section 4.e of the Trust Legal Provisions and are provided without
            warranty as described in the Simplified BSD License.<a href="#section-boilerplate.2-2" class="pilcrow">¶</a></p>
</section>
</div>
<div id="toc">
<section id="section-toc.1">
        <a href="#" onclick="scroll(0,0)" class="toplink">▲</a><h2 id="name-table-of-contents">
<a href="#name-table-of-contents" class="section-name selfRef">Table of Contents</a>
        </h2>
<nav class="toc"><ul class="toc ulEmpty">
<li class="toc ulEmpty" id="section-toc.1-1.1">
            <p id="section-toc.1-1.1.1"><a href="#section-1" class="xref">1</a>.  <a href="#name-introduction" class="xref">Introduction</a><a href="#section-toc.1-1.1.1" class="pilcrow">¶</a></p>
<ul class="toc ulEmpty">
<li class="toc ulEmpty" id="section-toc.1-1.1.2.1">
                <p id="section-toc.1-1.1.2.1.1"><a href="#section-1.1" class="xref">1.1</a>.  <a href="#name-background" class="xref">Background</a><a href="#section-toc.1-1.1.2.1.1" class="pilcrow">¶</a></p>
</li>
<li class="toc ulEmpty" id="section-toc.1-1.1.2.2">
                <p id="section-toc.1-1.1.2.2.1"><a href="#section-1.2" class="xref">1.2</a>.  <a href="#name-use-cases-and-applicability" class="xref">Use Cases and Applicability of Hierarchical Stateful PCE</a><a href="#section-toc.1-1.1.2.2.1" class="pilcrow">¶</a></p>
<ul class="toc ulEmpty">
<li class="toc ulEmpty" id="section-toc.1-1.1.2.2.2.1">
                    <p id="section-toc.1-1.1.2.2.2.1.1"><a href="#section-1.2.1" class="xref">1.2.1</a>.  <a href="#name-applicability-to-actn" class="xref">Applicability to ACTN</a><a href="#section-toc.1-1.1.2.2.2.1.1" class="pilcrow">¶</a></p>
</li>
<li class="toc ulEmpty" id="section-toc.1-1.1.2.2.2.2">
                    <p id="section-toc.1-1.1.2.2.2.2.1"><a href="#section-1.2.2" class="xref">1.2.2</a>.  <a href="#name-end-to-end-contiguous-lsp" class="xref">End-to-End Contiguous LSP</a><a href="#section-toc.1-1.1.2.2.2.2.1" class="pilcrow">¶</a></p>
</li>
<li class="toc ulEmpty" id="section-toc.1-1.1.2.2.2.3">
                    <p id="section-toc.1-1.1.2.2.2.3.1"><a href="#section-1.2.3" class="xref">1.2.3</a>.  <a href="#name-applicability-of-a-stateful" class="xref">Applicability of a Stateful P-PCE</a><a href="#section-toc.1-1.1.2.2.2.3.1" class="pilcrow">¶</a></p>
</li>
</ul>
</li>
</ul>
</li>
<li class="toc ulEmpty" id="section-toc.1-1.2">
            <p id="section-toc.1-1.2.1"><a href="#section-2" class="xref">2</a>.  <a href="#name-terminology" class="xref">Terminology</a><a href="#section-toc.1-1.2.1" class="pilcrow">¶</a></p>
<ul class="toc ulEmpty">
<li class="toc ulEmpty" id="section-toc.1-1.2.2.1">
                <p id="section-toc.1-1.2.2.1.1"><a href="#section-2.1" class="xref">2.1</a>.  <a href="#name-requirements-language" class="xref">Requirements Language</a><a href="#section-toc.1-1.2.2.1.1" class="pilcrow">¶</a></p>
</li>
</ul>
</li>
<li class="toc ulEmpty" id="section-toc.1-1.3">
            <p id="section-toc.1-1.3.1"><a href="#section-3" class="xref">3</a>.  <a href="#name-hierarchical-stateful-pce" class="xref">Hierarchical Stateful PCE</a><a href="#section-toc.1-1.3.1" class="pilcrow">¶</a></p>
<ul class="toc ulEmpty">
<li class="toc ulEmpty" id="section-toc.1-1.3.2.1">
                <p id="section-toc.1-1.3.2.1.1"><a href="#section-3.1" class="xref">3.1</a>.  <a href="#name-passive-operations" class="xref">Passive Operations</a><a href="#section-toc.1-1.3.2.1.1" class="pilcrow">¶</a></p>
</li>
<li class="toc ulEmpty" id="section-toc.1-1.3.2.2">
                <p id="section-toc.1-1.3.2.2.1"><a href="#section-3.2" class="xref">3.2</a>.  <a href="#name-active-operations" class="xref">Active Operations</a><a href="#section-toc.1-1.3.2.2.1" class="pilcrow">¶</a></p>
</li>
<li class="toc ulEmpty" id="section-toc.1-1.3.2.3">
                <p id="section-toc.1-1.3.2.3.1"><a href="#section-3.3" class="xref">3.3</a>.  <a href="#name-pce-initiation-of-lsps" class="xref">PCE Initiation of LSPs</a><a href="#section-toc.1-1.3.2.3.1" class="pilcrow">¶</a></p>
<ul class="toc ulEmpty">
<li class="toc ulEmpty" id="section-toc.1-1.3.2.3.2.1">
                    <p id="section-toc.1-1.3.2.3.2.1.1"><a href="#section-3.3.1" class="xref">3.3.1</a>.  <a href="#name-per-domain-stitched-lsp" class="xref">Per-Domain Stitched LSP</a><a href="#section-toc.1-1.3.2.3.2.1.1" class="pilcrow">¶</a></p>
</li>
</ul>
</li>
</ul>
</li>
<li class="toc ulEmpty" id="section-toc.1-1.4">
            <p id="section-toc.1-1.4.1"><a href="#section-4" class="xref">4</a>.  <a href="#name-security-considerations" class="xref">Security Considerations</a><a href="#section-toc.1-1.4.1" class="pilcrow">¶</a></p>
</li>
<li class="toc ulEmpty" id="section-toc.1-1.5">
            <p id="section-toc.1-1.5.1"><a href="#section-5" class="xref">5</a>.  <a href="#name-manageability-consideration" class="xref">Manageability Considerations</a><a href="#section-toc.1-1.5.1" class="pilcrow">¶</a></p>
<ul class="toc ulEmpty">
<li class="toc ulEmpty" id="section-toc.1-1.5.2.1">
                <p id="section-toc.1-1.5.2.1.1"><a href="#section-5.1" class="xref">5.1</a>.  <a href="#name-control-of-function-and-pol" class="xref">Control of Function and Policy</a><a href="#section-toc.1-1.5.2.1.1" class="pilcrow">¶</a></p>
</li>
<li class="toc ulEmpty" id="section-toc.1-1.5.2.2">
                <p id="section-toc.1-1.5.2.2.1"><a href="#section-5.2" class="xref">5.2</a>.  <a href="#name-information-and-data-models" class="xref">Information and Data Models</a><a href="#section-toc.1-1.5.2.2.1" class="pilcrow">¶</a></p>
</li>
<li class="toc ulEmpty" id="section-toc.1-1.5.2.3">
                <p id="section-toc.1-1.5.2.3.1"><a href="#section-5.3" class="xref">5.3</a>.  <a href="#name-liveness-detection-and-moni" class="xref">Liveness Detection and Monitoring</a><a href="#section-toc.1-1.5.2.3.1" class="pilcrow">¶</a></p>
</li>
<li class="toc ulEmpty" id="section-toc.1-1.5.2.4">
                <p id="section-toc.1-1.5.2.4.1"><a href="#section-5.4" class="xref">5.4</a>.  <a href="#name-verification-of-correct-ope" class="xref">Verification of Correct Operations</a><a href="#section-toc.1-1.5.2.4.1" class="pilcrow">¶</a></p>
</li>
<li class="toc ulEmpty" id="section-toc.1-1.5.2.5">
                <p id="section-toc.1-1.5.2.5.1"><a href="#section-5.5" class="xref">5.5</a>.  <a href="#name-requirements-on-other-proto" class="xref">Requirements on Other Protocols</a><a href="#section-toc.1-1.5.2.5.1" class="pilcrow">¶</a></p>
</li>
<li class="toc ulEmpty" id="section-toc.1-1.5.2.6">
                <p id="section-toc.1-1.5.2.6.1"><a href="#section-5.6" class="xref">5.6</a>.  <a href="#name-impact-on-network-operation" class="xref">Impact on Network Operations</a><a href="#section-toc.1-1.5.2.6.1" class="pilcrow">¶</a></p>
</li>
<li class="toc ulEmpty" id="section-toc.1-1.5.2.7">
                <p id="section-toc.1-1.5.2.7.1"><a href="#section-5.7" class="xref">5.7</a>.  <a href="#name-error-handling-between-pces" class="xref">Error Handling between PCEs</a><a href="#section-toc.1-1.5.2.7.1" class="pilcrow">¶</a></p>
</li>
</ul>
</li>
<li class="toc ulEmpty" id="section-toc.1-1.6">
            <p id="section-toc.1-1.6.1"><a href="#section-6" class="xref">6</a>.  <a href="#name-other-considerations" class="xref">Other Considerations</a><a href="#section-toc.1-1.6.1" class="pilcrow">¶</a></p>
<ul class="toc ulEmpty">
<li class="toc ulEmpty" id="section-toc.1-1.6.2.1">
                <p id="section-toc.1-1.6.2.1.1"><a href="#section-6.1" class="xref">6.1</a>.  <a href="#name-applicability-to-interlayer" class="xref">Applicability to Interlayer Traffic Engineering</a><a href="#section-toc.1-1.6.2.1.1" class="pilcrow">¶</a></p>
</li>
<li class="toc ulEmpty" id="section-toc.1-1.6.2.2">
                <p id="section-toc.1-1.6.2.2.1"><a href="#section-6.2" class="xref">6.2</a>.  <a href="#name-scalability-considerations" class="xref">Scalability Considerations</a><a href="#section-toc.1-1.6.2.2.1" class="pilcrow">¶</a></p>
</li>
<li class="toc ulEmpty" id="section-toc.1-1.6.2.3">
                <p id="section-toc.1-1.6.2.3.1"><a href="#section-6.3" class="xref">6.3</a>.  <a href="#name-confidentiality" class="xref">Confidentiality</a><a href="#section-toc.1-1.6.2.3.1" class="pilcrow">¶</a></p>
</li>
</ul>
</li>
<li class="toc ulEmpty" id="section-toc.1-1.7">
            <p id="section-toc.1-1.7.1"><a href="#section-7" class="xref">7</a>.  <a href="#name-iana-considerations" class="xref">IANA Considerations</a><a href="#section-toc.1-1.7.1" class="pilcrow">¶</a></p>
</li>
<li class="toc ulEmpty" id="section-toc.1-1.8">
            <p id="section-toc.1-1.8.1"><a href="#section-8" class="xref">8</a>.  <a href="#name-references" class="xref">References</a><a href="#section-toc.1-1.8.1" class="pilcrow">¶</a></p>
<ul class="toc ulEmpty">
<li class="toc ulEmpty" id="section-toc.1-1.8.2.1">
                <p id="section-toc.1-1.8.2.1.1"><a href="#section-8.1" class="xref">8.1</a>.  <a href="#name-normative-references" class="xref">Normative References</a><a href="#section-toc.1-1.8.2.1.1" class="pilcrow">¶</a></p>
</li>
<li class="toc ulEmpty" id="section-toc.1-1.8.2.2">
                <p id="section-toc.1-1.8.2.2.1"><a href="#section-8.2" class="xref">8.2</a>.  <a href="#name-informative-references" class="xref">Informative References</a><a href="#section-toc.1-1.8.2.2.1" class="pilcrow">¶</a></p>
</li>
</ul>
</li>
<li class="toc ulEmpty" id="section-toc.1-1.9">
            <p id="section-toc.1-1.9.1"><a href="#section-appendix.a" class="xref"></a><a href="#name-acknowledgments" class="xref">Acknowledgments</a><a href="#section-toc.1-1.9.1" class="pilcrow">¶</a></p>
</li>
<li class="toc ulEmpty" id="section-toc.1-1.10">
            <p id="section-toc.1-1.10.1"><a href="#section-appendix.b" class="xref"></a><a href="#name-contributors" class="xref">Contributors</a><a href="#section-toc.1-1.10.1" class="pilcrow">¶</a></p>
</li>
<li class="toc ulEmpty" id="section-toc.1-1.11">
            <p id="section-toc.1-1.11.1"><a href="#section-appendix.c" class="xref"></a><a href="#name-authors-addresses" class="xref">Authors' Addresses</a><a href="#section-toc.1-1.11.1" class="pilcrow">¶</a></p>
</li>
</ul>
</nav>
</section>
</div>
<div id="sect-1">
<section id="section-1">
      <h2 id="name-introduction">
<a href="#section-1" class="section-number selfRef">1. </a><a href="#name-introduction" class="section-name selfRef">Introduction</a>
      </h2>
<div id="sect-1.1">
<section id="section-1.1">
        <h3 id="name-background">
<a href="#section-1.1" class="section-number selfRef">1.1. </a><a href="#name-background" class="section-name selfRef">Background</a>
        </h3>
<p id="section-1.1-1">
   The Path Computation Element communication Protocol (PCEP) <span>[<a href="#RFC5440" class="xref">RFC5440</a>]</span>
   provides mechanisms for Path Computation Elements (PCEs) to perform
   path computations in response to the requests of Path Computation Clients (PCCs).<a href="#section-1.1-1" class="pilcrow">¶</a></p>
<p id="section-1.1-2">
   A stateful PCE is capable of considering, for the purposes of path
   computation, not only the network state in terms of links and nodes
   (referred to as the Traffic Engineering Database or TED) but also the
   status of active services (previously computed paths, and currently
   reserved resources, stored in the Label Switched Paths Database
   (LSPDB).<a href="#section-1.1-2" class="pilcrow">¶</a></p>
<p id="section-1.1-3">
   <span>[<a href="#RFC8051" class="xref">RFC8051</a>]</span> describes general considerations for a stateful PCE
   deployment; it also examines its applicability and benefits as well as
   its challenges and limitations through a number of use cases.<a href="#section-1.1-3" class="pilcrow">¶</a></p>
<p id="section-1.1-4">
   <span>[<a href="#RFC8231" class="xref">RFC8231</a>]</span> describes a set of extensions to PCEP to provide stateful
   control. For its computations, a stateful PCE has access to not only the information
   carried by the network's Interior Gateway Protocol (IGP), but also
   the set of active paths and their reserved resources.  The additional state
   allows the PCE to compute
   constrained paths while considering individual LSPs and their
   interactions.  <span>[<a href="#RFC8281" class="xref">RFC8281</a>]</span> describes the setup, maintenance, and
   teardown of PCE-initiated LSPs under the stateful PCE model.<a href="#section-1.1-4" class="pilcrow">¶</a></p>
<p id="section-1.1-5">
   <span>[<a href="#RFC8231" class="xref">RFC8231</a>]</span> also describes the active stateful PCE. The
   active PCE functionality allows a PCE to reroute an existing LSP, make
   changes to the attributes of an existing LSP, or delegate control of
   specific LSPs to a new PCE.<a href="#section-1.1-5" class="pilcrow">¶</a></p>
<p id="section-1.1-6">
   The ability to compute constrained paths for Traffic Engineering (TE) LSPs in Multiprotocol
   Label Switching (MPLS) and Generalized MPLS (GMPLS) networks across
   multiple domains has been identified as a key motivation for PCE
   development.  <span>[<a href="#RFC6805" class="xref">RFC6805</a>]</span> describes a Hierarchical PCE (H-PCE)
   architecture that can be used for computing end-to-end paths for
   interdomain MPLS TE and GMPLS Label Switched
   Paths (LSPs).  Within the H-PCE architecture
   <span>[<a href="#RFC6805" class="xref">RFC6805</a>]</span>, the Parent PCE (P-PCE) is used to compute a multidomain
   path based on the domain connectivity information.  A Child PCE
   (C-PCE) may be responsible for a single domain or multiple domains.
   The C-PCE is used to compute the intradomain path based on its
   domain topology information.<a href="#section-1.1-6" class="pilcrow">¶</a></p>
<p id="section-1.1-7">
   This document presents general considerations for stateful PCEs, and
   not stateless PCEs, in the hierarchical PCE architecture.  It focuses
   on the behavior changes and additions to the existing stateful PCE
   mechanisms (including PCE-initiated LSP setup and active stateful PCE
   usage) in the context of networks using the H-PCE architecture.<a href="#section-1.1-7" class="pilcrow">¶</a></p>
<p id="section-1.1-8">
   In this document, Sections <a href="#sect-3.1" class="xref">3.1</a> and
   <a href="#sect-3.2" class="xref">3.2</a> focus on end-to-end (E2E)
   interdomain TE LSP. <a href="#sect-3.3.1" class="xref">Section 3.3.1</a> describes the operations for
   stitching per-domain LSPs.<a href="#section-1.1-8" class="pilcrow">¶</a></p>
</section>
</div>
<div id="sect-1.2">
<section id="section-1.2">
        <h3 id="name-use-cases-and-applicability">
<a href="#section-1.2" class="section-number selfRef">1.2. </a><a href="#name-use-cases-and-applicability" class="section-name selfRef">Use Cases and Applicability of Hierarchical Stateful PCE</a>
        </h3>
<p id="section-1.2-1">
   As per <span>[<a href="#RFC6805" class="xref">RFC6805</a>]</span>, in the hierarchical PCE architecture, a P-PCE
   maintains a domain topology map that contains the child domains and
   their interconnections.  Usually, the P-PCE has no information about
   the content of the child domains.  But, if the PCE is applied to the
   Abstraction and Control of TE Networks (ACTN) <span>[<a href="#RFC8453" class="xref">RFC8453</a>]</span> as described
   in <span>[<a href="#RFC8637" class="xref">RFC8637</a>]</span>, the Provisioning Network
   Controller (PNC) can provide
   an abstract topology to the Multi-Domain Service Coordinator (MDSC).
   Thus, the P-PCE in MDSC could be aware of topology information in much
   more detail than just the domain topology.<a href="#section-1.2-1" class="pilcrow">¶</a></p>
<p id="section-1.2-2">
   In a PCEP session between a PCC (ingress) and a C-PCE, the C-PCE acts
   as per the stateful PCE operations described in <span>[<a href="#RFC8231" class="xref">RFC8231</a>]</span> and
   <span>[<a href="#RFC8281" class="xref">RFC8281</a>]</span>. The same C-PCE behaves as a PCC on the PCEP session
   towards the P-PCE. The P-PCE is stateful in nature; thus, it maintains
   the state of the interdomain LSPs that are reported to it. The
   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
   any other LSP. It could also be a change in topology at the P-PCE,
   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
   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
   update would require an interdomain path recomputation as described
   in <span>[<a href="#RFC6805" class="xref">RFC6805</a>]</span>.<a href="#section-1.2-2" class="pilcrow">¶</a></p>
<p id="section-1.2-3">
   The end-to-end interdomain path computation and setup is described in
   <span>[<a href="#RFC6805" class="xref">RFC6805</a>]</span>. Additionally, a per-domain
   stitched-LSP model is
   also applicable in a P-PCE initiation model. Sections <a href="#sect-3.1" class="xref">3.1</a>, <a href="#sect-3.2" class="xref">3.2</a>, and
   <a href="#sect-3.3" class="xref">3.3</a> describe the
   end-to-end contiguous LSP setup, whereas <a href="#sect-3.3.1" class="xref">Section 3.3.1</a>
   describes the per-domain stitching.<a href="#section-1.2-3" class="pilcrow">¶</a></p>
<div id="sect-1.2.1">
<section id="section-1.2.1">
          <h4 id="name-applicability-to-actn">
<a href="#section-1.2.1" class="section-number selfRef">1.2.1. </a><a href="#name-applicability-to-actn" class="section-name selfRef">Applicability to ACTN</a>
          </h4>
<p id="section-1.2.1-1">
   <span>[<a href="#RFC8453" class="xref">RFC8453</a>]</span> describes a framework for the
   Abstraction and Control of TE
   Networks (ACTN), where each Provisioning Network Controller (PNC) is
   equivalent to a C-PCE, and the P-PCE is the Multi-Domain Service
   Coordinator (MDSC).  The per-domain stitched LSP is well suited for ACTN
   deployments, as per the
   hierarchical PCE architecture described in <a href="#sect-3.3.1" class="xref">Section 3.3.1</a> of this document and <span><a href="https://www.rfc-editor.org/rfc/rfc8453#section-4.1" class="relref">Section 4.1</a> of [<a href="#RFC8453" class="xref">RFC8453</a>]</span>.<a href="#section-1.2.1-1" class="pilcrow">¶</a></p>
<p id="section-1.2.1-2">
   <span>[<a href="#RFC8637" class="xref">RFC8637</a>]</span> examines the applicability of PCE to the ACTN framework. To
   support the function of multidomain coordination via hierarchy, the
   hierarchy of stateful PCEs plays a crucial role.<a href="#section-1.2.1-2" class="pilcrow">¶</a></p>
<p id="section-1.2.1-3">
   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)
   requirements before requesting that the VN be provisioned. The H-PCE
   architecture as described in <span>[<a href="#RFC6805" class="xref">RFC6805</a>]</span> can support 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
   multiple interdomain LSP provisioning requests, which might be further
   decomposed into per-domain path segments. This is described in
   <a href="#sect-3.3.1" class="xref">Section 3.3.1</a>. The MDSC uses the LSP
   initiate request (PCInitiate)
   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
   P-PCE could make changes to the LSP via the use of a Path Computation
   Update Request (PCUpd) message.<a href="#section-1.2.1-3" class="pilcrow">¶</a></p>
<p id="section-1.2.1-4">
   In this case, the P-PCE (as MDSC) interacts with multiple C-PCEs (as
   PNCs) along the interdomain path of the LSP.<a href="#section-1.2.1-4" class="pilcrow">¶</a></p>
</section>
</div>
<div id="sect-1.2.2">
<section id="section-1.2.2">
          <h4 id="name-end-to-end-contiguous-lsp">
<a href="#section-1.2.2" class="section-number selfRef">1.2.2. </a><a href="#name-end-to-end-contiguous-lsp" class="section-name selfRef">End-to-End Contiguous LSP</a>
          </h4>
<p id="section-1.2.2-1">
 Different signaling options for interdomain RSVP-TE are identified in
 <span>[<a href="#RFC4726" class="xref">RFC4726</a>]</span>. Contiguous LSPs are achieved using the
 procedures of <span>[<a href="#RFC3209" class="xref">RFC3209</a>]</span> and <span>[<a href="#RFC3473" class="xref">RFC3473</a>]</span> to
 create a single end-to-end LSP that spans all domains. <span>[<a href="#RFC6805" class="xref">RFC6805</a>]</span> describes the technique for establishing the optimum
 path when the sequence of domains is not known in advance.<a href="#section-1.2.2-1" class="pilcrow">¶</a></p>
<p id="section-1.2.2-2">
   That document shows how the PCE architecture can be extended to allow the
   optimum sequence of domains to be selected and the optimum
   end-to-end path to be derived.<a href="#section-1.2.2-2" class="pilcrow">¶</a></p>
<p id="section-1.2.2-3">
   A stateful P-PCE has to be aware of the interdomain LSPs for it to
   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
   LSP. This is the passive stateful P-PCE, as described in <a href="#sect-3.1" class="xref">Section 3.1</a>. Additionally, the interdomain LSP
   could be delegated
   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
   indicates a status change of this LSP or some other LSP. The other LSP
   could be an associated LSP (such as a protection LSP <span>[<a href="#RFC8745" class="xref">RFC8745</a>]</span>) or an unrelated LSP whose
   resource change leads to reoptimization at the P-PCE. This is the active
   stateful operation, as described in <a href="#sect-3.2" class="xref">Section 3.2</a>. 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
   PCInitiate message to the ingress domain C-PCE, which would further
   instruct the ingress PCC.<a href="#section-1.2.2-3" class="pilcrow">¶</a></p>
<p id="section-1.2.2-4">
   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
   stateful operations for an interdomain LSP between the
   transit/egress domain C-PCEs and the P-PCE is out of the scope of this
   document.<a href="#section-1.2.2-4" class="pilcrow">¶</a></p>
</section>
</div>
<div id="sect-1.2.3">
<section id="section-1.2.3">
          <h4 id="name-applicability-of-a-stateful">
<a href="#section-1.2.3" class="section-number selfRef">1.2.3. </a><a href="#name-applicability-of-a-stateful" class="section-name selfRef">Applicability of a Stateful P-PCE</a>
          </h4>
<p id="section-1.2.3-1"> <span>[<a href="#RFC8051" class="xref">RFC8051</a>]</span> describes general
 considerations for a stateful PCE deployment and examines its
 applicability and benefits, as well as its challenges and limitations,
 through a number of use cases. These are also applicable to the
 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
 direct visibility inside the child domain, it could still trigger
 reoptimization with the help of child PCEs based on LSP state
 changes, abstract topology changes, or some other external
 factors.<a href="#section-1.2.3-1" class="pilcrow">¶</a></p>
<p id="section-1.2.3-2">
   The C-PCE would delegate control of the interdomain LSP to the P-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
   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
   a change to the LSP (refer to <span>[<a href="#RFC8741" class="xref">RFC8741</a>]</span>).<a href="#section-1.2.3-2" class="pilcrow">¶</a></p>
</section>
</div>
</section>
</div>
</section>
</div>
<div id="sect-2">
<section id="section-2">
      <h2 id="name-terminology">
<a href="#section-2" class="section-number selfRef">2. </a><a href="#name-terminology" class="section-name selfRef">Terminology</a>
      </h2>
<p id="section-2-1"> The terminology is as
      per <span>[<a href="#RFC4655" class="xref">RFC4655</a>]</span>, <span>[<a href="#RFC5440" class="xref">RFC5440</a>]</span>, <span>[<a href="#RFC6805" class="xref">RFC6805</a>]</span>, <span>[<a href="#RFC8051" class="xref">RFC8051</a>]</span>, <span>[<a href="#RFC8231" class="xref">RFC8231</a>]</span>, and <span>[<a href="#RFC8281" class="xref">RFC8281</a>]</span>.<a href="#section-2-1" class="pilcrow">¶</a></p>
<p id="section-2-2">Some key terms are listed below for easy reference.<a href="#section-2-2" class="pilcrow">¶</a></p>
<dl class="dlParallel" id="section-2-3">
        <dt id="section-2-3.1">ACTN:</dt>
<dd style="margin-left: 4.5em" id="section-2-3.2"> Abstraction and Control of Traffic Engineering Networks<a href="#section-2-3.2" class="pilcrow">¶</a>
</dd>
<dt id="section-2-3.3">CNC:</dt>
<dd style="margin-left: 4.5em" id="section-2-3.4"> Customer Network Controller<a href="#section-2-3.4" class="pilcrow">¶</a>
</dd>
<dt id="section-2-3.5">C-PCE:</dt>
<dd style="margin-left: 4.5em" id="section-2-3.6"> Child Path Computation Element<a href="#section-2-3.6" class="pilcrow">¶</a>
</dd>
<dt id="section-2-3.7">H-PCE:</dt>
<dd style="margin-left: 4.5em" id="section-2-3.8"> Hierarchical Path Computation Element<a href="#section-2-3.8" class="pilcrow">¶</a>
</dd>
<dt id="section-2-3.9">IGP:</dt>
<dd style="margin-left: 4.5em" id="section-2-3.10"> Interior Gateway Protocol<a href="#section-2-3.10" class="pilcrow">¶</a>
</dd>
<dt id="section-2-3.11">LSP:</dt>
<dd style="margin-left: 4.5em" id="section-2-3.12"> Label Switched Path<a href="#section-2-3.12" class="pilcrow">¶</a>
</dd>
<dt id="section-2-3.13">LSPDB:</dt>
<dd style="margin-left: 4.5em" id="section-2-3.14"> Label Switched Path Database<a href="#section-2-3.14" class="pilcrow">¶</a>
</dd>
<dt id="section-2-3.15">LSR:</dt>
<dd style="margin-left: 4.5em" id="section-2-3.16"> Label Switching Router<a href="#section-2-3.16" class="pilcrow">¶</a>
</dd>
<dt id="section-2-3.17">MDSC:</dt>
<dd style="margin-left: 4.5em" id="section-2-3.18"> Multi-Domain Service Coordinator<a href="#section-2-3.18" class="pilcrow">¶</a>
</dd>
<dt id="section-2-3.19">PCC:</dt>
<dd style="margin-left: 4.5em" id="section-2-3.20"> Path Computation Client<a href="#section-2-3.20" class="pilcrow">¶</a>
</dd>
<dt id="section-2-3.21">PCE:</dt>
<dd style="margin-left: 4.5em" id="section-2-3.22"> Path Computation Element<a href="#section-2-3.22" class="pilcrow">¶</a>
</dd>
<dt id="section-2-3.23">PCEP:</dt>
<dd style="margin-left: 4.5em" id="section-2-3.24"> Path Computation Element communication Protocol<a href="#section-2-3.24" class="pilcrow">¶</a>
</dd>
<dt id="section-2-3.25">PNC:</dt>
<dd style="margin-left: 4.5em" id="section-2-3.26"> Provisioning Network Controller<a href="#section-2-3.26" class="pilcrow">¶</a>
</dd>
<dt id="section-2-3.27">P-PCE:</dt>
<dd style="margin-left: 4.5em" id="section-2-3.28"> Parent Path Computation Element<a href="#section-2-3.28" class="pilcrow">¶</a>
</dd>
<dt id="section-2-3.29">TED:</dt>
<dd style="margin-left: 4.5em" id="section-2-3.30"> Traffic Engineering Database<a href="#section-2-3.30" class="pilcrow">¶</a>
</dd>
<dt id="section-2-3.31">VN:</dt>
<dd style="margin-left: 4.5em" id="section-2-3.32"> Virtual Network<a href="#section-2-3.32" class="pilcrow">¶</a>
</dd>
</dl>
<div id="sect-2.1">
<section id="section-2.1">
        <h3 id="name-requirements-language">
<a href="#section-2.1" class="section-number selfRef">2.1. </a><a href="#name-requirements-language" class="section-name selfRef">Requirements Language</a>
        </h3>
<p id="section-2.1-1">
   The key words "<span class="bcp14">MUST</span>", "<span class="bcp14">MUST NOT</span>",
   "<span class="bcp14">REQUIRED</span>", "<span class="bcp14">SHALL</span>", "<span class="bcp14">SHALL NOT</span>", "<span class="bcp14">SHOULD</span>", "<span class="bcp14">SHOULD NOT</span>",
   "<span class="bcp14">RECOMMENDED</span>", "<span class="bcp14">NOT RECOMMENDED</span>",
   "<span class="bcp14">MAY</span>", and "<span class="bcp14">OPTIONAL</span>" in this document
   are to be interpreted as
   described in BCP 14 <span>[<a href="#RFC2119" class="xref">RFC2119</a>]</span> <span>[<a href="#RFC8174" class="xref">RFC8174</a>]</span> 
   when, and only when, they appear in all capitals, as shown here.<a href="#section-2.1-1" class="pilcrow">¶</a></p>
</section>
</div>
</section>
</div>
<div id="sect-3">
<section id="section-3">
      <h2 id="name-hierarchical-stateful-pce">
<a href="#section-3" class="section-number selfRef">3. </a><a href="#name-hierarchical-stateful-pce" class="section-name selfRef">Hierarchical Stateful PCE</a>
      </h2>
<p id="section-3-1"> As described in <span>[<a href="#RFC6805" class="xref">RFC6805</a>]</span>, in the hierarchical PCE
 architecture, a P-PCE maintains a domain topology map that contains the
 child domains (seen as vertices in the topology) and their
 interconnections (links in the topology). Usually, the P-PCE has no
 information about the content of the child domains. Each child domain
 has at least one PCE capable of computing paths across the domain.
 These PCEs are known as Child PCEs (C-PCEs) <span>[<a href="#RFC6805" class="xref">RFC6805</a>]</span>
 and have a direct relationship with the P-PCE. The P-PCE builds the
 domain topology map either via direct configuration or from learned
 information received from each C-PCE. The network policy could be
 applied while building the domain topology map. This has been
 described in detail in <span>[<a href="#RFC6805" class="xref">RFC6805</a>]</span>.<a href="#section-3-1" class="pilcrow">¶</a></p>
<p id="section-3-2">
   Note that, in the scope of this document, both the C-PCEs and the P-PCE are
   stateful in nature.<a href="#section-3-2" class="pilcrow">¶</a></p>
<p id="section-3-3">
   <span>[<a href="#RFC8231" class="xref">RFC8231</a>]</span> specifies new functions to support a stateful PCE.
   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).<a href="#section-3-3" class="pilcrow">¶</a></p>
<p id="section-3-4">
   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
   (EP-EC). All PCE types herein (EC-EP and EP-EC) are assumed to be
   "stateful PCE".<a href="#section-3-4" class="pilcrow">¶</a></p>
<p id="section-3-5">
   A number of interactions are expected in the hierarchical stateful
   PCE architecture. These include:<a href="#section-3-5" class="pilcrow">¶</a></p>
<dl class="dlParallel" id="section-3-6">
        <dt id="section-3-6.1">LSP State Report (EC-EP):</dt>
<dd style="margin-left: 1.5em" id="section-3-6.2">A child stateful PCE sends an
        LSP state report to a parent stateful PCE to indicate the state of an LSP.<a href="#section-3-6.2" class="pilcrow">¶</a>
</dd>
<dt id="section-3-6.3">LSP State Synchronization (EC-EP):</dt>
<dd style="margin-left: 1.5em" id="section-3-6.4">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.<a href="#section-3-6.4" class="pilcrow">¶</a>
</dd>
<dt id="section-3-6.5">LSP Control Delegation (EC-EP, EP-EC):</dt>
<dd style="margin-left: 1.5em" id="section-3-6.6">A C-PCE grants to the P-PCE
     the right to update LSP attributes on one or more LSPs; at any
     time, the C-PCE
     may withdraw the delegation or the P-PCE may give up the
     delegation.<a href="#section-3-6.6" class="pilcrow">¶</a>
</dd>
<dt id="section-3-6.7">LSP Update Request (EP-EC):</dt>
<dd style="margin-left: 1.5em" id="section-3-6.8">A stateful P-PCE requests
 modification of attributes on a C-PCE's TE LSP.<a href="#section-3-6.8" class="pilcrow">¶</a>
</dd>
<dt id="section-3-6.9">PCE LSP Initiation Request (EP-EC):</dt>
<dd style="margin-left: 1.5em" id="section-3-6.10">A stateful P-PCE requests a C-PCE to initiate a TE LSP.<a href="#section-3-6.10" class="pilcrow">¶</a>
</dd>
</dl>
<p id="section-3-7">
   Note that this hierarchy is recursive, so a Label Switching Router
   (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
   it exists). Similarly, update operations can also be applied
   recursively.<a href="#section-3-7" class="pilcrow">¶</a></p>
<p id="section-3-8">
   <span>[<a href="#RFC8685" class="xref">RFC8685</a>]</span> defines the H-PCE-CAPABILITY TLV that is used in the Open message to advertise the H-PCE
   capability. <span>[<a href="#RFC8231" class="xref">RFC8231</a>]</span> defines the STATEFUL-PCE-CAPABILITY
   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
   speaker <span class="bcp14">MUST</span> include both TLVs in an Open message. It is <span class="bcp14">RECOMMENDED</span> that
   any implementation that supports stateful operations <span>[<a href="#RFC8231" class="xref">RFC8231</a>]</span> and H-PCE <span>[<a href="#RFC8685" class="xref">RFC8685</a>]</span> also implement the
   stateful H-PCE operations as described in this document.<a href="#section-3-8" class="pilcrow">¶</a></p>
<p id="section-3-9">
   Further consideration may be made for optional procedures for stateful
   communication coordination between PCEs, including procedures to minimize
   computational loops. The procedures described in <span>[<a href="#I-D.litkowski-pce-state-sync" class="xref">PCE-STATE-SYNC</a>]</span> facilitate stateful communication
   between PCEs for various use cases. The procedures and extensions as
   described in <span><a href="https://tools.ietf.org/html/draft-litkowski-pce-state-sync-07#section-3" class="relref">Section 3</a> of [<a href="#I-D.litkowski-pce-state-sync" class="xref">PCE-STATE-SYNC</a>]</span> are
   also applicable to child and parent PCE communication. The
   SPEAKER-IDENTITY-ID TLV (defined in <span>[<a href="#RFC8232" class="xref">RFC8232</a>]</span>) is included in
   the LSP object to identify the ingress (PCC). The PCEP-specific identifier
   for the LSP (PLSP-ID <span>[<a href="#RFC8231" class="xref">RFC8231</a>]</span>) used in the
   forwarded PCRpt by the C-PCE to the P-PCE is the same as the original one used by
   the PCC.<a href="#section-3-9" class="pilcrow">¶</a></p>
<div id="sect-3.1">
<section id="section-3.1">
        <h3 id="name-passive-operations">
<a href="#section-3.1" class="section-number selfRef">3.1. </a><a href="#name-passive-operations" class="section-name selfRef">Passive Operations</a>
        </h3>
<p id="section-3.1-1"> Procedures described in <span>[<a href="#RFC6805" class="xref">RFC6805</a>]</span> are applied, where the
 ingress PCC triggers a path computation request for the destination
 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
 candidate domain paths based on the domain topology and the state of
 the interdomain links. It then sends computation requests to the
 C-PCEs responsible for each of the domains on the candidate domain
 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
 information to select path segments and concatenate them to derive the
 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
 C-PCE passes the path on to the PCC that issued the original
 request.<a href="#section-3.1-1" class="pilcrow">¶</a></p>
<p id="section-3.1-2">
   As per <span>[<a href="#RFC8231" class="xref">RFC8231</a>]</span>, the PCC sends an LSP State
   Report carried on a PCRpt
   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 the
   C-PCE may dictate which LSPs are reported to the P-PCE.  The PCRpt
   message is sent from C-PCE to P-PCE.<a href="#section-3.1-2" class="pilcrow">¶</a></p>
<p id="section-3.1-3">
   State synchronization mechanisms as described in <span>[<a href="#RFC8231" class="xref">RFC8231</a>]</span> and
   <span>[<a href="#RFC8232" class="xref">RFC8232</a>]</span> are applicable to a PCEP session between C-PCE and P-PCE as
   well.<a href="#section-3.1-3" class="pilcrow">¶</a></p>
<p id="section-3.1-4">
   We use the hierarchical domain topology example from <span>[<a href="#RFC6805" class="xref">RFC6805</a>]</span> as the
   reference topology for the entirety of this document.  It is shown in
   Figure 1.<a href="#section-3.1-4" class="pilcrow">¶</a></p>
<span id="name-hierarchical-domain-topolog"></span><div id="ure-hierarchical-domain-topology-example">
<figure id="figure-1">
          <div class="artwork art-text alignLeft" id="section-3.1-5.1">
<pre>
   -----------------------------------------------------------------
  |   Domain 5                                                      |
  |                              -----                              |
  |                             |PCE 5|                             |
  |                              -----                              |
  |                                                                 |
  |    ----------------     ----------------     ----------------   |
  |   | Domain 1       |   | Domain 2       |   | Domain 3       |  |
  |   |                |   |                |   |                |  |
  |   |        -----   |   |        -----   |   |        -----   |  |
  |   |       |PCE 1|  |   |       |PCE 2|  |   |       |PCE 3|  |  |
  |   |        -----   |   |        -----   |   |        -----   |  |
  |   |                |   |                |   |                |  |
  |   |            ----|   |----        ----|   |----            |  |
  |   |           |BN11+---+BN21|      |BN23+---+BN31|           |  |
  |   |   -        ----|   |----        ----|   |----        -   |  |
  |   |  |S|           |   |                |   |           |D|  |  |
  |   |   -        ----|   |----        ----|   |----        -   |  |
  |   |           |BN12+---+BN22|      |BN24+---+BN32|           |  |
  |   |            ----|   |----        ----|   |----            |  |
  |   |                |   |                |   |                |  |
  |   |         ----   |   |                |   |   ----         |  |
  |   |        |BN13|  |   |                |   |  |BN33|        |  |
  |    -----------+----     ----------------     ----+-----------   |
  |                \                                /               |
  |                 \       ----------------       /                |
  |                  \     |                |     /                 |
  |                   \    |----        ----|    /                  |
  |                    ----+BN41|      |BN42+----                   |
  |                        |----        ----|                       |
  |                        |                |                       |
  |                        |        -----   |                       |
  |                        |       |PCE 4|  |                       |
  |                        |        -----   |                       |
  |                        |                |                       |
  |                        | Domain 4       |                       |
  |                         ----------------                        |
  |                                                                 |
   -----------------------------------------------------------------
</pre>
</div>
<figcaption><a href="#figure-1" class="selfRef">Figure 1</a>:
<a href="#name-hierarchical-domain-topolog" class="selfRef">Hierarchical Domain Topology Example</a>
          </figcaption></figure>
</div>
<p id="section-3.1-6">
   Steps 1 to 11 are exactly as described in <span><a href="https://www.rfc-editor.org/rfc/rfc6805#section-4.6.2" class="relref">Section 4.6.2</a> of [<a href="#RFC6805" class="xref">RFC6805</a>]</span>
   ("Hierarchical PCE End-to-End Path Computation Procedure"); the
   following additional steps are added for stateful PCE, to be executed
   at the end:<a href="#section-3.1-6" class="pilcrow">¶</a></p>
<dl class="dlParallel" id="section-3.1-7">
          <dt id="section-3.1-7.1">(A)</dt>
<dd style="margin-left: 2.5em" id="section-3.1-7.2">The ingress LSR initiates the setup of the LSP as
        per the path and reports the LSP status to PCE1 ("GOING-UP").<a href="#section-3.1-7.2" class="pilcrow">¶</a>
</dd>
<dt id="section-3.1-7.3">(B)</dt>
<dd style="margin-left: 2.5em" id="section-3.1-7.4">PCE1 further reports the status of the LSP to
 the P-PCE (PCE5).<a href="#section-3.1-7.4" class="pilcrow">¶</a>
</dd>
<dt id="section-3.1-7.5">(C)</dt>
<dd style="margin-left: 2.5em" id="section-3.1-7.6">The ingress LSR notifies PCE1 of the LSP state when the
   state is "UP".<a href="#section-3.1-7.6" class="pilcrow">¶</a>
</dd>
<dt id="section-3.1-7.7">(D)</dt>
<dd style="margin-left: 2.5em" id="section-3.1-7.8">PCE1 further reports the status of the LSP to the P-PCE
 (PCE5).<a href="#section-3.1-7.8" class="pilcrow">¶</a>
</dd>
</dl>
<p id="section-3.1-8">
   The ingress LSR could trigger path reoptimization by sending the
   path computation request as described in <span>[<a href="#RFC6805" class="xref">RFC6805</a>]</span>; at this time, it
   can include the LSP object in the PCReq message, as described in
   <span>[<a href="#RFC8231" class="xref">RFC8231</a>]</span>.<a href="#section-3.1-8" class="pilcrow">¶</a></p>
</section>
</div>
<div id="sect-3.2">
<section id="section-3.2">
        <h3 id="name-active-operations">
<a href="#section-3.2" class="section-number selfRef">3.2. </a><a href="#name-active-operations" class="section-name selfRef">Active Operations</a>
        </h3>
<p id="section-3.2-1"> <span>[<a href="#RFC8231" class="xref">RFC8231</a>]</span> describes the case of an
 active stateful PCE. The
 active PCE functionality uses two specific PCEP messages:<a href="#section-3.2-1" class="pilcrow">¶</a></p>
<ul>
<li id="section-3.2-2.1">Update Request (PCUpd)<a href="#section-3.2-2.1" class="pilcrow">¶</a>
</li>
<li id="section-3.2-2.2">State Report (PCRpt)<a href="#section-3.2-2.2" class="pilcrow">¶</a>
</li>
</ul>
<p id="section-3.2-3">
   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
   report any change in the LSP's state.<a href="#section-3.2-3" class="pilcrow">¶</a></p>
<p id="section-3.2-4">
   As per <span>[<a href="#RFC8051" class="xref">RFC8051</a>]</span>, delegation is an
   operation to grant a PCE temporary
   rights to modify a subset of LSP parameters on the LSPs of one or more
   PCCs.  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
   sent from C-PCE to P-PCE.<a href="#section-3.2-4" class="pilcrow">¶</a></p>
<p id="section-3.2-5">
   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
   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
   request to the PCC.<a href="#section-3.2-5" class="pilcrow">¶</a></p>
<p id="section-3.2-6">
   The P-PCE uses the same mechanism described in <a href="#sect-3.1" class="xref">Section 3.1</a> to
   compute the end-to-end path using PCReq and PCRep messages.<a href="#section-3.2-6" class="pilcrow">¶</a></p>
<p id="section-3.2-7">
   For active operations, the following steps are required when
   delegating the LSP, again using the reference architecture described
   in Figure 1 ("Hierarchical Domain Topology Example").<a href="#section-3.2-7" class="pilcrow">¶</a></p>
<dl class="dlParallel" id="section-3.2-8">
          <dt id="section-3.2-8.1">(A)</dt>
<dd style="margin-left: 2.5em" id="section-3.2-8.2">The ingress LSR delegates the LSP to PCE1 via a
        PCRpt message with D flag set.<a href="#section-3.2-8.2" class="pilcrow">¶</a>
</dd>
<dt id="section-3.2-8.3">(B)</dt>
<dd style="margin-left: 2.5em" id="section-3.2-8.4">PCE1 further delegates the LSP to the P-PCE
 (PCE5).<a href="#section-3.2-8.4" class="pilcrow">¶</a>
</dd>
<dt id="section-3.2-8.5">(C)</dt>
<dd style="margin-left: 2.5em" id="section-3.2-8.6">Steps 4 to 10 in <span><a href="https://www.rfc-editor.org/rfc/rfc6805#section-4.6.2" class="relref">Section 4.6.2</a> of [<a href="#RFC6805" class="xref">RFC6805</a>]</span> are executed at P-PCE (PCE5) to
   determine the end-to-end path.<a href="#section-3.2-8.6" class="pilcrow">¶</a>
</dd>
<dt id="section-3.2-8.7">(D)</dt>
<dd style="margin-left: 2.5em" id="section-3.2-8.8">The P-PCE (PCE5) sends the update request to the
 C-PCE (PCE1) via PCUpd message.<a href="#section-3.2-8.8" class="pilcrow">¶</a>
</dd>
<dt id="section-3.2-8.9">(E)</dt>
<dd style="margin-left: 2.5em" id="section-3.2-8.10">PCE1 further updates the LSP to the ingress LSR
 (PCC).<a href="#section-3.2-8.10" class="pilcrow">¶</a>
</dd>
<dt id="section-3.2-8.11">(F)</dt>
<dd style="margin-left: 2.5em" id="section-3.2-8.12">The ingress LSR initiates the setup of the LSP as
 per the path and reports the LSP status to PCE1 ("GOING-UP").<a href="#section-3.2-8.12" class="pilcrow">¶</a>
</dd>
<dt id="section-3.2-8.13">(G)</dt>
<dd style="margin-left: 2.5em" id="section-3.2-8.14">PCE1 further reports the status of the LSP to
 the P-PCE (PCE5).<a href="#section-3.2-8.14" class="pilcrow">¶</a>
</dd>
<dt id="section-3.2-8.15">(H)</dt>
<dd style="margin-left: 2.5em" id="section-3.2-8.16">The ingress LSR notifies PCE1 of the LSP state when
 the state is "UP".<a href="#section-3.2-8.16" class="pilcrow">¶</a>
</dd>
<dt id="section-3.2-8.17">(I)</dt>
<dd style="margin-left: 2.5em" id="section-3.2-8.18">PCE1 further reports the status of the LSP to
 the P-PCE (PCE5).<a href="#section-3.2-8.18" class="pilcrow">¶</a>
</dd>
</dl>
</section>
</div>
<div id="sect-3.3">
<section id="section-3.3">
        <h3 id="name-pce-initiation-of-lsps">
<a href="#section-3.3" class="section-number selfRef">3.3. </a><a href="#name-pce-initiation-of-lsps" class="section-name selfRef">PCE Initiation of LSPs</a>
        </h3>
<p id="section-3.3-1"> <span>[<a href="#RFC8281" class="xref">RFC8281</a>]</span> describes the setup,
 maintenance, and teardown of
 PCE-initiated LSPs under the stateful PCE model, without the need for
 local configuration on the PCC, thus allowing for a dynamic network
 that is centrally controlled and deployed.  To instantiate or delete
 an LSP, the PCE sends the Path Computation LSP initiate request
 (PCInitiate) message to the PCC.  In the case of an interdomain LSP in
 hierarchical PCE architecture, the initiation operations can be
 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
 (the ingress domain PCE), and the C-PCE further propagates the initiate
 request to the PCC.<a href="#section-3.3-1" class="pilcrow">¶</a></p>
<p id="section-3.3-2">
   The following steps are performed for PCE-initiated operations, again
   using the reference architecture described in Figure 1 ("Hierarchical
   Domain Topology Example"):<a href="#section-3.3-2" class="pilcrow">¶</a></p>
<dl class="dlParallel" id="section-3.3-3">
          <dt id="section-3.3-3.1">(A)</dt>
<dd style="margin-left: 2.5em" id="section-3.3-3.2"> The P-PCE (PCE5) is requested to initiate an
        LSP. Steps 4 to 10 in <span><a href="https://www.rfc-editor.org/rfc/rfc6805#section-4.6.2" class="relref">Section 4.6.2</a> of [<a href="#RFC6805" class="xref">RFC6805</a>]</span> are
        executed to determine the end-to-end path.<a href="#section-3.3-3.2" class="pilcrow">¶</a>
</dd>
<dt id="section-3.3-3.3">(B)</dt>
<dd style="margin-left: 2.5em" id="section-3.3-3.4"> The P-PCE (PCE5) sends the initiate request to the
 child PCE (PCE1) via PCInitiate message.<a href="#section-3.3-3.4" class="pilcrow">¶</a>
</dd>
<dt id="section-3.3-3.5">(C)</dt>
<dd style="margin-left: 2.5em" id="section-3.3-3.6">PCE1 further propagates the initiate message to
 the ingress LSR (PCC).<a href="#section-3.3-3.6" class="pilcrow">¶</a>
</dd>
<dt id="section-3.3-3.7">(D)</dt>
<dd style="margin-left: 2.5em" id="section-3.3-3.8">The ingress LSR initiates the setup of the LSP as per the path
 and reports to PCE1 the LSP status ("GOING-UP").<a href="#section-3.3-3.8" class="pilcrow">¶</a>
</dd>
<dt id="section-3.3-3.9">(E)</dt>
<dd style="margin-left: 2.5em" id="section-3.3-3.10">PCE1 further reports the status of the LSP to the P-PCE
 (PCE5).<a href="#section-3.3-3.10" class="pilcrow">¶</a>
</dd>
<dt id="section-3.3-3.11">(F)</dt>
<dd style="margin-left: 2.5em" id="section-3.3-3.12">The ingress LSR notifies PCE1 of the LSP state when the state is
 "UP".<a href="#section-3.3-3.12" class="pilcrow">¶</a>
</dd>
<dt id="section-3.3-3.13">(G)</dt>
<dd style="margin-left: 2.5em" id="section-3.3-3.14">PCE1 further reports the status of the LSP to the P-PCE
 (PCE5).<a href="#section-3.3-3.14" class="pilcrow">¶</a>
</dd>
</dl>
<p id="section-3.3-4">
   The ingress LSR (PCC) generates the PLSP-ID for the LSP and
   inform the C-PCE, which is propagated to the P-PCE.<a href="#section-3.3-4" class="pilcrow">¶</a></p>
<div id="sect-3.3.1">
<section id="section-3.3.1">
          <h4 id="name-per-domain-stitched-lsp">
<a href="#section-3.3.1" class="section-number selfRef">3.3.1. </a><a href="#name-per-domain-stitched-lsp" class="section-name selfRef">Per-Domain Stitched LSP</a>
          </h4>
<p id="section-3.3.1-1"> The hierarchical PCE architecture, as per <span>[<a href="#RFC6805" class="xref">RFC6805</a>]</span>, is
 primarily used for E2E LSP.  With PCE-initiated capability, another
 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
 initiate individual LSP segments along the domain path. These
 individual per-domain LSPs are stitched together by some mechanism,
 which is out of the scope of this document (Refer to <span>[<a href="#I-D.dugeon-pce-stateful-interdomain" class="xref">STATEFUL-INTERDOMAIN</a>]</span>).<a href="#section-3.3.1-1" class="pilcrow">¶</a></p>
<p id="section-3.3.1-2">
   The following steps are performed for the per-domain stitched LSP
   operation, again using the reference architecture described in Figure
   1 ("Hierarchical Domain Topology Example"):<a href="#section-3.3.1-2" class="pilcrow">¶</a></p>
<dl class="dlParallel" id="section-3.3.1-3">
            <dt id="section-3.3.1-3.1">(A)</dt>
<dd style="margin-left: 2.5em" id="section-3.3.1-3.2">
              <p id="section-3.3.1-3.2.1"> The P-PCE (PCE5) is requested to initiate an LSP. Steps 4 to
       10 in <span><a href="https://www.rfc-editor.org/rfc/rfc6805#section-4.6.2" class="relref">Section 4.6.2</a> of [<a href="#RFC6805" class="xref">RFC6805</a>]</span> are
        executed to determine the end-to-end path, which is broken into
        per-domain LSPs. For example:<a href="#section-3.3.1-3.2.1" class="pilcrow">¶</a></p>
<ul>
<li id="section-3.3.1-3.2.2.1">S-BN41<a href="#section-3.3.1-3.2.2.1" class="pilcrow">¶</a>
</li>
<li id="section-3.3.1-3.2.2.2">BN41-BN33<a href="#section-3.3.1-3.2.2.2" class="pilcrow">¶</a>
</li>
<li id="section-3.3.1-3.2.2.3">BN33-D<a href="#section-3.3.1-3.2.2.3" class="pilcrow">¶</a>
</li>
</ul>
</dd>
</dl>
<p id="section-3.3.1-4">
   It should be noted that the P-PCE may use other mechanisms to
   determine the suitable per-domain LSPs (apart from <span>[<a href="#RFC6805" class="xref">RFC6805</a>]</span>).<a href="#section-3.3.1-4" class="pilcrow">¶</a></p>
<p id="section-3.3.1-5">
   For LSP (BN33-D):<a href="#section-3.3.1-5" class="pilcrow">¶</a></p>
<dl class="dlParallel" id="section-3.3.1-6">
            <dt id="section-3.3.1-6.1">(B)</dt>
<dd style="margin-left: 2.5em" id="section-3.3.1-6.2">The P-PCE (PCE5) sends the initiate request to the
        child PCE (PCE3) via a PCInitiate message for the LSP (BN33-D).<a href="#section-3.3.1-6.2" class="pilcrow">¶</a>
</dd>
<dt id="section-3.3.1-6.3">(C)</dt>
<dd style="margin-left: 2.5em" id="section-3.3.1-6.4">PCE3 further propagates the initiate message to
 BN33.<a href="#section-3.3.1-6.4" class="pilcrow">¶</a>
</dd>
<dt id="section-3.3.1-6.5">(D)</dt>
<dd style="margin-left: 2.5em" id="section-3.3.1-6.6">BN33 initiates the setup of the LSP as per the path
 and reports to PCE3 the LSP status ("GOING-UP").<a href="#section-3.3.1-6.6" class="pilcrow">¶</a>
</dd>
<dt id="section-3.3.1-6.7">(E)</dt>
<dd style="margin-left: 2.5em" id="section-3.3.1-6.8">PCE3 further reports the status of the LSP to
 the P-PCE (PCE5).<a href="#section-3.3.1-6.8" class="pilcrow">¶</a>
</dd>
<dt id="section-3.3.1-6.9">(F)</dt>
<dd style="margin-left: 2.5em" id="section-3.3.1-6.10">The node BN33 notifies PCE3 of the LSP state when
 the state is "UP".<a href="#section-3.3.1-6.10" class="pilcrow">¶</a>
</dd>
<dt id="section-3.3.1-6.11">(G)</dt>
<dd style="margin-left: 2.5em" id="section-3.3.1-6.12">PCE3 further reports the status of the LSP to the P-PCE
 (PCE5).<a href="#section-3.3.1-6.12" class="pilcrow">¶</a>
</dd>
</dl>
<p id="section-3.3.1-7">
   For LSP (BN41-BN33):<a href="#section-3.3.1-7" class="pilcrow">¶</a></p>
<dl class="dlParallel" id="section-3.3.1-8">
            <dt id="section-3.3.1-8.1">(H)</dt>
<dd style="margin-left: 2.5em" id="section-3.3.1-8.2">The P-PCE (PCE5) sends the initiate request to the
        child PCE (PCE4) via PCInitiate message for LSP (BN41-BN33).<a href="#section-3.3.1-8.2" class="pilcrow">¶</a>
</dd>
<dt id="section-3.3.1-8.3">(I)</dt>
<dd style="margin-left: 2.5em" id="section-3.3.1-8.4">PCE4 further propagates the initiate message to
 BN41.<a href="#section-3.3.1-8.4" class="pilcrow">¶</a>
</dd>
<dt id="section-3.3.1-8.5">(J)</dt>
<dd style="margin-left: 2.5em" id="section-3.3.1-8.6">BN41 initiates the setup of the LSP as per the path
 and reports to PCE4 the LSP status ("GOING-UP").<a href="#section-3.3.1-8.6" class="pilcrow">¶</a>
</dd>
<dt id="section-3.3.1-8.7">(K)</dt>
<dd style="margin-left: 2.5em" id="section-3.3.1-8.8">PCE4 further reports the status of the LSP to
 the P-PCE (PCE5).<a href="#section-3.3.1-8.8" class="pilcrow">¶</a>
</dd>
<dt id="section-3.3.1-8.9">(L)</dt>
<dd style="margin-left: 2.5em" id="section-3.3.1-8.10">The node BN41 notifies PCE4 of the LSP state when
 the state is "UP".<a href="#section-3.3.1-8.10" class="pilcrow">¶</a>
</dd>
<dt id="section-3.3.1-8.11">(M)</dt>
<dd style="margin-left: 2.5em" id="section-3.3.1-8.12">PCE4 further reports the status of the LSP to the P-PCE
 (PCE5).<a href="#section-3.3.1-8.12" class="pilcrow">¶</a>
</dd>
</dl>
<p id="section-3.3.1-9">
   For LSP (S-BN41):<a href="#section-3.3.1-9" class="pilcrow">¶</a></p>
<dl class="dlParallel" id="section-3.3.1-10">
            <dt id="section-3.3.1-10.1">(N)</dt>
<dd style="margin-left: 2.5em" id="section-3.3.1-10.2">The P-PCE (PCE5) sends the initiate request to the
        child PCE (PCE1) via a PCInitiate message for the LSP (S-BN41).<a href="#section-3.3.1-10.2" class="pilcrow">¶</a>
</dd>
<dt id="section-3.3.1-10.3">(O)</dt>
<dd style="margin-left: 2.5em" id="section-3.3.1-10.4">PCE1 further propagates the initiate message to
 node S.<a href="#section-3.3.1-10.4" class="pilcrow">¶</a>
</dd>
<dt id="section-3.3.1-10.5">(P)</dt>
<dd style="margin-left: 2.5em" id="section-3.3.1-10.6">S initiates the setup of the LSP as per the path and
 reports to PCE1 the LSP status ("GOING-UP").<a href="#section-3.3.1-10.6" class="pilcrow">¶</a>
</dd>
<dt id="section-3.3.1-10.7">(Q)</dt>
<dd style="margin-left: 2.5em" id="section-3.3.1-10.8">PCE1 further reports the status of the LSP to
 the P-PCE (PCE5).<a href="#section-3.3.1-10.8" class="pilcrow">¶</a>
</dd>
<dt id="section-3.3.1-10.9">(R)</dt>
<dd style="margin-left: 2.5em" id="section-3.3.1-10.10">The node S notifies PCE1 of the LSP state when the state is
 "UP".<a href="#section-3.3.1-10.10" class="pilcrow">¶</a>
</dd>
<dt id="section-3.3.1-10.11">(S)</dt>
<dd style="margin-left: 2.5em" id="section-3.3.1-10.12">PCE1 further reports the status of the LSP to
 the P-PCE (PCE5).<a href="#section-3.3.1-10.12" class="pilcrow">¶</a>
</dd>
</dl>
<p id="section-3.3.1-11">
   Additionally:<a href="#section-3.3.1-11" class="pilcrow">¶</a></p>
<dl class="dlParallel" id="section-3.3.1-12">
            <dt id="section-3.3.1-12.1">(T)</dt>
<dd style="margin-left: 2.5em" id="section-3.3.1-12.2">Once the P-PCE receives a report of each per-domain LSP,
        it should use a suitable stitching mechanism, which is out of the scope of
        this document. In this step, the P-PCE (PCE5) could also initiate an E2E
        LSP (S-D) by sending the PCInitiate message to the ingress C-PCE
        (PCE1).<a href="#section-3.3.1-12.2" class="pilcrow">¶</a>
</dd>
</dl>
<p id="section-3.3.1-13">
   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
   per-domain LSPs are initiated. This option is defined in
   <span>[<a href="#I-D.dugeon-pce-stateful-interdomain" class="xref">STATEFUL-INTERDOMAIN</a>]</span>.<a href="#section-3.3.1-13" class="pilcrow">¶</a></p>
</section>
</div>
</section>
</div>
</section>
</div>
<div id="sect-4">
<section id="section-4">
      <h2 id="name-security-considerations">
<a href="#section-4" class="section-number selfRef">4. </a><a href="#name-security-considerations" class="section-name selfRef">Security Considerations</a>
      </h2>
<p id="section-4-1"> The
 security considerations listed in <span>[<a href="#RFC8231" class="xref">RFC8231</a>]</span>, <span>[<a href="#RFC6805" class="xref">RFC6805</a>]</span>, and
 <span>[<a href="#RFC5440" class="xref">RFC5440</a>]</span> apply to this document,
 as well. As per <span>[<a href="#RFC6805" class="xref">RFC6805</a>]</span>, it is expected that the
 parent PCE will require all child PCEs to use full security (i.e., the
 highest security mechanism available for PCEP) when communicating with
 the parent.<a href="#section-4-1" class="pilcrow">¶</a></p>
<p id="section-4-2">
   Any multidomain operation necessarily involves the exchange of information
   across domain boundaries.  This is bound to represent a significant
   security and confidentiality risk, especially when the child domains are
   controlled by different commercial concerns.  PCEP allows individual PCEs
   to maintain the confidentiality of their domain-path information using
   path-keys <span>[<a href="#RFC5520" class="xref">RFC5520</a>]</span>, and the hierarchical PCE architecture
   is specifically designed to enable as much isolation of information about domain topology and
   capabilities as is possible. The LSP state in the PCRpt message
   must continue to maintain the internal domain confidentiality when
   required.<a href="#section-4-2" class="pilcrow">¶</a></p>
<p id="section-4-3">
   The security considerations for PCE-initiated LSP in <span>[<a href="#RFC8281" class="xref">RFC8281</a>]</span> are
   also applicable from P-PCE to C-PCE.<a href="#section-4-3" class="pilcrow">¶</a></p>
<p id="section-4-4">
   Further, <a href="#sect-6.3" class="xref">Section 6.3</a> describes the use of a path-key <span>[<a href="#RFC5520" class="xref">RFC5520</a>]</span> for
   confidentiality between C-PCE and P-PCE.<a href="#section-4-4" class="pilcrow">¶</a></p>
<p id="section-4-5">
   Thus, it is <span class="bcp14">RECOMMENDED</span> to secure the PCEP session (between the P-PCE and
   the C-PCE) using Transport Layer Security (TLS) <span>[<a href="#RFC8446" class="xref">RFC8446</a>]</span>
   (per the recommendations and best current practices in BCP 195 <span>[<a href="#RFC7525" class="xref">RFC7525</a>]</span>) and/or TCP Authentication Option (TCP-AO) <span>[<a href="#RFC5925" class="xref">RFC5925</a>]</span>. The guidance for implementing PCEP with TLS can be
   found in <span>[<a href="#RFC8253" class="xref">RFC8253</a>]</span>.<a href="#section-4-5" class="pilcrow">¶</a></p>
<p id="section-4-6">
   In the case of TLS, due care needs to be taken while exposing the parameters of
   the X.509 certificate -- such as subjectAltName:otherName, which is set to
   Speaker Entity Identifier <span>[<a href="#RFC8232" class="xref">RFC8232</a>]</span> as per
      <span>[<a href="#RFC8253" class="xref">RFC8253</a>]</span> -- to ensure uniqueness and
      avoid any mismatch.<a href="#section-4-6" class="pilcrow">¶</a></p>
</section>
</div>
<div id="sect-5">
<section id="section-5">
      <h2 id="name-manageability-consideration">
<a href="#section-5" class="section-number selfRef">5. </a><a href="#name-manageability-consideration" class="section-name selfRef">Manageability Considerations</a>
      </h2>
<p id="section-5-1"> All
 manageability requirements and considerations listed in <span>[<a href="#RFC5440" class="xref">RFC5440</a>]</span>, <span>[<a href="#RFC6805" class="xref">RFC6805</a>]</span>, <span>[<a href="#RFC8231" class="xref">RFC8231</a>]</span>, and <span>[<a href="#RFC8281" class="xref">RFC8281</a>]</span> apply to stateful
 H-PCE defined in this document. In addition, requirements and
 considerations listed in this section apply.<a href="#section-5-1" class="pilcrow">¶</a></p>
<div id="sect-5.1">
<section id="section-5.1">
        <h3 id="name-control-of-function-and-pol">
<a href="#section-5.1" class="section-number selfRef">5.1. </a><a href="#name-control-of-function-and-pol" class="section-name selfRef">Control of Function and Policy</a>
        </h3>
<p id="section-5.1-1">
   Support of the hierarchical procedure will be controlled by the
   management organization responsible for each child PCE. The parent
   PCE must only accept path-computation requests from authorized child
   PCEs. If a parent PCE receives a report from an unauthorized child
   PCE, the report should be dropped. All mechanisms described in
   <span>[<a href="#RFC8231" class="xref">RFC8231</a>]</span> and <span>[<a href="#RFC8281" class="xref">RFC8281</a>]</span> continue to apply.<a href="#section-5.1-1" class="pilcrow">¶</a></p>
</section>
</div>
<div id="sect-5.2">
<section id="section-5.2">
        <h3 id="name-information-and-data-models">
<a href="#section-5.2" class="section-number selfRef">5.2. </a><a href="#name-information-and-data-models" class="section-name selfRef">Information and Data Models</a>
        </h3>
<p id="section-5.2-1">
   An implementation should allow the operator to view the stateful and
   H-PCE capabilities advertised by each peer. The "ietf-pcep" PCEP YANG
   module is specified in <span>[<a href="#I-D.ietf-pce-pcep-yang" class="xref">PCE-PCEP-YANG</a>]</span>. This YANG module
   will be required to be augmented to also include details for stateful
   H-PCE deployment and operation. The exact model and attributes are
   out of scope for this document.<a href="#section-5.2-1" class="pilcrow">¶</a></p>
</section>
</div>
<div id="sect-5.3">
<section id="section-5.3">
        <h3 id="name-liveness-detection-and-moni">
<a href="#section-5.3" class="section-number selfRef">5.3. </a><a href="#name-liveness-detection-and-moni" class="section-name selfRef">Liveness Detection and Monitoring</a>
        </h3>
<p id="section-5.3-1">
   Mechanisms defined in this document do not imply any new liveness-detection
   or monitoring requirements in addition to those already
   listed in <span>[<a href="#RFC5440" class="xref">RFC5440</a>]</span>.<a href="#section-5.3-1" class="pilcrow">¶</a></p>
</section>
</div>
<div id="sect-5.4">
<section id="section-5.4">
        <h3 id="name-verification-of-correct-ope">
<a href="#section-5.4" class="section-number selfRef">5.4. </a><a href="#name-verification-of-correct-ope" class="section-name selfRef">Verification of Correct Operations</a>
        </h3>
<p id="section-5.4-1">
   Mechanisms defined in this document do not imply any new
   operation-verification requirements in addition to those already listed in
   <span>[<a href="#RFC5440" class="xref">RFC5440</a>]</span> and <span>[<a href="#RFC8231" class="xref">RFC8231</a>]</span>.<a href="#section-5.4-1" class="pilcrow">¶</a></p>
</section>
</div>
<div id="sect-5.5">
<section id="section-5.5">
        <h3 id="name-requirements-on-other-proto">
<a href="#section-5.5" class="section-number selfRef">5.5. </a><a href="#name-requirements-on-other-proto" class="section-name selfRef">Requirements on Other Protocols</a>
        </h3>
<p id="section-5.5-1">
   Mechanisms defined in this document do not imply any new requirements
   on other protocols.<a href="#section-5.5-1" class="pilcrow">¶</a></p>
</section>
</div>
<div id="sect-5.6">
<section id="section-5.6">
        <h3 id="name-impact-on-network-operation">
<a href="#section-5.6" class="section-number selfRef">5.6. </a><a href="#name-impact-on-network-operation" class="section-name selfRef">Impact on Network Operations</a>
        </h3>
<p id="section-5.6-1">
   Mechanisms defined in <span>[<a href="#RFC5440" class="xref">RFC5440</a>]</span> and <span>[<a href="#RFC8231" class="xref">RFC8231</a>]</span> also apply to PCEP
   extensions defined in this document.<a href="#section-5.6-1" class="pilcrow">¶</a></p>
<p id="section-5.6-2">
   The stateful H-PCE technique brings the applicability of stateful PCE
   (described in <span>[<a href="#RFC8051" class="xref">RFC8051</a>]</span>) to the LSP traversing multiple domains.<a href="#section-5.6-2" class="pilcrow">¶</a></p>
<p id="section-5.6-3">
   As described in <a href="#sect-3" class="xref">Section 3</a>, a PCEP speaker includes both the
   H-PCE-CAPABILITY TLV <span>[<a href="#RFC8685" class="xref">RFC8685</a>]</span> and
   STATEFUL-PCE-CAPABILITY TLV <span>[<a href="#RFC8231" class="xref">RFC8231</a>]</span> to indicate support
   for stateful H-PCE. Note that there is a possibility of a PCEP speaker that
   does not support the stateful H-PCE feature but does provide support for
   stateful-PCE <span>[<a href="#RFC8231" class="xref">RFC8231</a>]</span> and H-PCE <span>[<a href="#RFC8685" class="xref">RFC8685</a>]</span> 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
   message exchange, the stateful messages will not be propagated further (as
   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
   eventuality as a part of normal procedures.<a href="#section-5.6-3" class="pilcrow">¶</a></p>
</section>
</div>
<div id="sect-5.7">
<section id="section-5.7">
        <h3 id="name-error-handling-between-pces">
<a href="#section-5.7" class="section-number selfRef">5.7. </a><a href="#name-error-handling-between-pces" class="section-name selfRef">Error Handling between PCEs</a>
        </h3>
<p id="section-5.7-1">
 Apart from the basic error handling described in this document, an
 implementation could also use the enhanced error and notification
 mechanism for stateful H-PCE operations described in <span>[<a href="#I-D.ietf-pce-enhanced-errors" class="xref">PCE-ENHANCED-ERRORS</a>]</span>. Enhanced
 features such as
 error-behavior propagation, notification, and error-criticality level
 are further defined in <span>[<a href="#I-D.ietf-pce-enhanced-errors" class="xref">PCE-ENHANCED-ERRORS</a>]</span>.<a href="#section-5.7-1" class="pilcrow">¶</a></p>
</section>
</div>
</section>
</div>
<div id="sect-6">
<section id="section-6">
      <h2 id="name-other-considerations">
<a href="#section-6" class="section-number selfRef">6. </a><a href="#name-other-considerations" class="section-name selfRef">Other Considerations</a>
      </h2>
<div id="sect-6.1">
<section id="section-6.1">
        <h3 id="name-applicability-to-interlayer">
<a href="#section-6.1" class="section-number selfRef">6.1. </a><a href="#name-applicability-to-interlayer" class="section-name selfRef">Applicability to Interlayer Traffic Engineering</a>
        </h3>
<p id="section-6.1-1">
   <span>[<a href="#RFC5623" class="xref">RFC5623</a>]</span> describes a framework for applying the PCE-based
   architecture to interlayer (G)MPLS traffic engineering.  The H-PCE
   stateful architecture with stateful P-PCE coordinating with the
   stateful C-PCEs of higher and lower layer is shown in <a href="#ure-sample-inter-layer-topology" class="xref">Figure 2</a>.<a href="#section-6.1-1" class="pilcrow">¶</a></p>
<span id="name-sample-interlayer-topology"></span><div id="ure-sample-inter-layer-topology">
<figure id="figure-2">
          <div class="artwork art-text alignLeft" id="section-6.1-2.1">
<pre>
                                              +----------+
                                              | Parent   |
                                             /| PCE      |
                                            / +----------+
                                           /     /   Stateful
                                          /     /    P-PCE
                                         /     /
                                        /     /
                       Stateful+-----+ /     /
                       C-PCE   | PCE |/     /
                       Hi      | Hi  |     /
                               +-----+    /
       +---+    +---+                    /     +---+    +---+
      + LSR +--+ LSR +........................+ LSR +--+ LSR +
      + H1  +  + H2  +                 /      + H3  +  + H4  +
       +---+    +---+\         +-----+/       /+---+    +---+
                      \        | PCE |       /
                       \       | Lo  |      /
             Stateful   \      +-----+     /
             C-PCE       \                /
             Lo           \+---+    +---+/
                          + LSR +--+ LSR +
                          + L1  +  + L2  +
                           +---+    +---+
</pre>
</div>
<figcaption><a href="#figure-2" class="selfRef">Figure 2</a>:
<a href="#name-sample-interlayer-topology" class="selfRef">Sample Interlayer Topology</a>
          </figcaption></figure>
</div>
<p id="section-6.1-3">
   All procedures described in <a href="#sect-3" class="xref">Section 3</a> are also
   applicable to interlayer path setup, and therefore to separate domains.<a href="#section-6.1-3" class="pilcrow">¶</a></p>
</section>
</div>
<div id="sect-6.2">
<section id="section-6.2">
        <h3 id="name-scalability-considerations">
<a href="#section-6.2" class="section-number selfRef">6.2. </a><a href="#name-scalability-considerations" class="section-name selfRef">Scalability Considerations</a>
        </h3>
<p id="section-6.2-1">
   It should be noted that if all the C-PCEs were to report all the LSPs
   in their domain, it could lead to scalability issues for the P-PCE.
   Thus, it is recommended to only report the LSPs that are involved in
   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
   <span>[<a href="#RFC8231" class="xref">RFC8231</a>]</span> continue to apply for the PCEP session between child and
   parent PCE.<a href="#section-6.2-1" class="pilcrow">¶</a></p>
</section>
</div>
<div id="sect-6.3">
<section id="section-6.3">
        <h3 id="name-confidentiality">
<a href="#section-6.3" class="section-number selfRef">6.3. </a><a href="#name-confidentiality" class="section-name selfRef">Confidentiality</a>
        </h3>
<p id="section-6.3-1">
   As described in <span><a href="https://www.rfc-editor.org/rfc/rfc6805#section-4.2" class="relref">Section 4.2</a> of [<a href="#RFC6805" class="xref">RFC6805</a>]</span>,
   information about the
   content of child domains is not shared, for both scaling and
   confidentiality reasons. The child PCE could also conceal the path
   information during path computation. A C-PCE may replace a path
   segment with a path-key <span>[<a href="#RFC5520" class="xref">RFC5520</a>]</span>, effectively hiding the content of
   a segment of a path.<a href="#section-6.3-1" class="pilcrow">¶</a></p>
</section>
</div>
</section>
</div>
<div id="sect-7">
<section id="section-7">
      <h2 id="name-iana-considerations">
<a href="#section-7" class="section-number selfRef">7. </a><a href="#name-iana-considerations" class="section-name selfRef">IANA Considerations</a>
      </h2>
<p id="section-7-1">
      This document has no IANA actions.<a href="#section-7-1" class="pilcrow">¶</a></p>
</section>
</div>
<section id="section-8">
      <h2 id="name-references">
<a href="#section-8" class="section-number selfRef">8. </a><a href="#name-references" class="section-name selfRef">References</a>
      </h2>
<section id="section-8.1">
        <h3 id="name-normative-references">
<a href="#section-8.1" class="section-number selfRef">8.1. </a><a href="#name-normative-references" class="section-name selfRef">Normative References</a>
        </h3>
<dl class="references">
<dt id="RFC2119">[RFC2119]</dt>
<dd>
<span class="refAuthor">Bradner, S.</span>, <span class="refTitle">"Key words for use in RFCs to Indicate Requirement Levels"</span>, <span class="seriesInfo">BCP 14</span>, <span class="seriesInfo">RFC 2119</span>, <span class="seriesInfo">DOI 10.17487/RFC2119</span>, <time datetime="1997-03">March 1997</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc2119">https://www.rfc-editor.org/info/rfc2119</a>&gt;</span>. </dd>
<dt id="RFC4655">[RFC4655]</dt>
<dd>
<span class="refAuthor">Farrel, A.</span><span class="refAuthor">, Vasseur, J.-P.</span><span class="refAuthor">, and J. Ash</span>, <span class="refTitle">"A Path Computation Element (PCE)-Based Architecture"</span>, <span class="seriesInfo">RFC 4655</span>, <span class="seriesInfo">DOI 10.17487/RFC4655</span>, <time datetime="2006-08">August 2006</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc4655">https://www.rfc-editor.org/info/rfc4655</a>&gt;</span>. </dd>
<dt id="RFC5440">[RFC5440]</dt>
<dd>
<span class="refAuthor">Vasseur, JP., Ed.</span><span class="refAuthor"> and JL. Le Roux, Ed.</span>, <span class="refTitle">"Path Computation Element (PCE) Communication Protocol (PCEP)"</span>, <span class="seriesInfo">RFC 5440</span>, <span class="seriesInfo">DOI 10.17487/RFC5440</span>, <time datetime="2009-03">March 2009</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc5440">https://www.rfc-editor.org/info/rfc5440</a>&gt;</span>. </dd>
<dt id="RFC5520">[RFC5520]</dt>
<dd>
<span class="refAuthor">Bradford, R., Ed.</span><span class="refAuthor">, Vasseur, JP.</span><span class="refAuthor">, and A. Farrel</span>, <span class="refTitle">"Preserving Topology Confidentiality in Inter-Domain Path Computation Using a Path-Key-Based Mechanism"</span>, <span class="seriesInfo">RFC 5520</span>, <span class="seriesInfo">DOI 10.17487/RFC5520</span>, <time datetime="2009-04">April 2009</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc5520">https://www.rfc-editor.org/info/rfc5520</a>&gt;</span>. </dd>
<dt id="RFC5925">[RFC5925]</dt>
<dd>
<span class="refAuthor">Touch, J.</span><span class="refAuthor">, Mankin, A.</span><span class="refAuthor">, and R. Bonica</span>, <span class="refTitle">"The TCP Authentication Option"</span>, <span class="seriesInfo">RFC 5925</span>, <span class="seriesInfo">DOI 10.17487/RFC5925</span>, <time datetime="2010-06">June 2010</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc5925">https://www.rfc-editor.org/info/rfc5925</a>&gt;</span>. </dd>
<dt id="RFC6805">[RFC6805]</dt>
<dd>
<span class="refAuthor">King, D., Ed.</span><span class="refAuthor"> and A. Farrel, Ed.</span>, <span class="refTitle">"The Application of the Path Computation Element Architecture to the Determination of a Sequence of Domains in MPLS and GMPLS"</span>, <span class="seriesInfo">RFC 6805</span>, <span class="seriesInfo">DOI 10.17487/RFC6805</span>, <time datetime="2012-11">November 2012</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc6805">https://www.rfc-editor.org/info/rfc6805</a>&gt;</span>. </dd>
<dt id="RFC7525">[RFC7525]</dt>
<dd>
<span class="refAuthor">Sheffer, Y.</span><span class="refAuthor">, Holz, R.</span><span class="refAuthor">, and P. Saint-Andre</span>, <span class="refTitle">"Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)"</span>, <span class="seriesInfo">BCP 195</span>, <span class="seriesInfo">RFC 7525</span>, <span class="seriesInfo">DOI 10.17487/RFC7525</span>, <time datetime="2015-05">May 2015</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc7525">https://www.rfc-editor.org/info/rfc7525</a>&gt;</span>. </dd>
<dt id="RFC8174">[RFC8174]</dt>
<dd>
<span class="refAuthor">Leiba, B.</span>, <span class="refTitle">"Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words"</span>, <span class="seriesInfo">BCP 14</span>, <span class="seriesInfo">RFC 8174</span>, <span class="seriesInfo">DOI 10.17487/RFC8174</span>, <time datetime="2017-05">May 2017</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8174">https://www.rfc-editor.org/info/rfc8174</a>&gt;</span>. </dd>
<dt id="RFC8231">[RFC8231]</dt>
<dd>
<span class="refAuthor">Crabbe, E.</span><span class="refAuthor">, Minei, I.</span><span class="refAuthor">, Medved, J.</span><span class="refAuthor">, and R. Varga</span>, <span class="refTitle">"Path Computation Element Communication Protocol (PCEP) Extensions for Stateful PCE"</span>, <span class="seriesInfo">RFC 8231</span>, <span class="seriesInfo">DOI 10.17487/RFC8231</span>, <time datetime="2017-09">September 2017</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8231">https://www.rfc-editor.org/info/rfc8231</a>&gt;</span>. </dd>
<dt id="RFC8253">[RFC8253]</dt>
<dd>
<span class="refAuthor">Lopez, D.</span><span class="refAuthor">, Gonzalez de Dios, O.</span><span class="refAuthor">, Wu, Q.</span><span class="refAuthor">, and D. Dhody</span>, <span class="refTitle">"PCEPS: Usage of TLS to Provide a Secure Transport for the Path Computation Element Communication Protocol (PCEP)"</span>, <span class="seriesInfo">RFC 8253</span>, <span class="seriesInfo">DOI 10.17487/RFC8253</span>, <time datetime="2017-10">October 2017</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8253">https://www.rfc-editor.org/info/rfc8253</a>&gt;</span>. </dd>
<dt id="RFC8281">[RFC8281]</dt>
<dd>
<span class="refAuthor">Crabbe, E.</span><span class="refAuthor">, Minei, I.</span><span class="refAuthor">, Sivabalan, S.</span><span class="refAuthor">, and R. Varga</span>, <span class="refTitle">"Path Computation Element Communication Protocol (PCEP) Extensions for PCE-Initiated LSP Setup in a Stateful PCE Model"</span>, <span class="seriesInfo">RFC 8281</span>, <span class="seriesInfo">DOI 10.17487/RFC8281</span>, <time datetime="2017-12">December 2017</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8281">https://www.rfc-editor.org/info/rfc8281</a>&gt;</span>. </dd>
<dt id="RFC8446">[RFC8446]</dt>
<dd>
<span class="refAuthor">Rescorla, E.</span>, <span class="refTitle">"The Transport Layer Security (TLS) Protocol Version 1.3"</span>, <span class="seriesInfo">RFC 8446</span>, <span class="seriesInfo">DOI 10.17487/RFC8446</span>, <time datetime="2018-08">August 2018</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8446">https://www.rfc-editor.org/info/rfc8446</a>&gt;</span>. </dd>
</dl>
</section>
<section id="section-8.2">
        <h3 id="name-informative-references">
<a href="#section-8.2" class="section-number selfRef">8.2. </a><a href="#name-informative-references" class="section-name selfRef">Informative References</a>
        </h3>
<dl class="references">
<dt id="RFC3209">[RFC3209]</dt>
<dd>
<span class="refAuthor">Awduche, D.</span><span class="refAuthor">, Berger, L.</span><span class="refAuthor">, Gan, D.</span><span class="refAuthor">, Li, T.</span><span class="refAuthor">, Srinivasan, V.</span><span class="refAuthor">, and G. Swallow</span>, <span class="refTitle">"RSVP-TE: Extensions to RSVP for LSP Tunnels"</span>, <span class="seriesInfo">RFC 3209</span>, <span class="seriesInfo">DOI 10.17487/RFC3209</span>, <time datetime="2001-12">December 2001</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc3209">https://www.rfc-editor.org/info/rfc3209</a>&gt;</span>. </dd>
<dt id="RFC3473">[RFC3473]</dt>
<dd>
<span class="refAuthor">Berger, L., Ed.</span>, <span class="refTitle">"Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions"</span>, <span class="seriesInfo">RFC 3473</span>, <span class="seriesInfo">DOI 10.17487/RFC3473</span>, <time datetime="2003-01">January 2003</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc3473">https://www.rfc-editor.org/info/rfc3473</a>&gt;</span>. </dd>
<dt id="RFC4726">[RFC4726]</dt>
<dd>
<span class="refAuthor">Farrel, A.</span><span class="refAuthor">, Vasseur, J.-P.</span><span class="refAuthor">, and A. Ayyangar</span>, <span class="refTitle">"A Framework for Inter-Domain Multiprotocol Label Switching Traffic Engineering"</span>, <span class="seriesInfo">RFC 4726</span>, <span class="seriesInfo">DOI 10.17487/RFC4726</span>, <time datetime="2006-11">November 2006</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc4726">https://www.rfc-editor.org/info/rfc4726</a>&gt;</span>. </dd>
<dt id="RFC5623">[RFC5623]</dt>
<dd>
<span class="refAuthor">Oki, E.</span><span class="refAuthor">, Takeda, T.</span><span class="refAuthor">, Le Roux, JL.</span><span class="refAuthor">, and A. Farrel</span>, <span class="refTitle">"Framework for PCE-Based Inter-Layer MPLS and GMPLS Traffic Engineering"</span>, <span class="seriesInfo">RFC 5623</span>, <span class="seriesInfo">DOI 10.17487/RFC5623</span>, <time datetime="2009-09">September 2009</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc5623">https://www.rfc-editor.org/info/rfc5623</a>&gt;</span>. </dd>
<dt id="RFC8051">[RFC8051]</dt>
<dd>
<span class="refAuthor">Zhang, X., Ed.</span><span class="refAuthor"> and I. Minei, Ed.</span>, <span class="refTitle">"Applicability of a Stateful Path Computation Element (PCE)"</span>, <span class="seriesInfo">RFC 8051</span>, <span class="seriesInfo">DOI 10.17487/RFC8051</span>, <time datetime="2017-01">January 2017</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8051">https://www.rfc-editor.org/info/rfc8051</a>&gt;</span>. </dd>
<dt id="RFC8232">[RFC8232]</dt>
<dd>
<span class="refAuthor">Crabbe, E.</span><span class="refAuthor">, Minei, I.</span><span class="refAuthor">, Medved, J.</span><span class="refAuthor">, Varga, R.</span><span class="refAuthor">, Zhang, X.</span><span class="refAuthor">, and D. Dhody</span>, <span class="refTitle">"Optimizations of Label Switched Path State Synchronization Procedures for a Stateful PCE"</span>, <span class="seriesInfo">RFC 8232</span>, <span class="seriesInfo">DOI 10.17487/RFC8232</span>, <time datetime="2017-09">September 2017</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8232">https://www.rfc-editor.org/info/rfc8232</a>&gt;</span>. </dd>
<dt id="RFC8453">[RFC8453]</dt>
<dd>
<span class="refAuthor">Ceccarelli, D., Ed.</span><span class="refAuthor"> and Y. Lee, Ed.</span>, <span class="refTitle">"Framework for Abstraction and Control of TE Networks (ACTN)"</span>, <span class="seriesInfo">RFC 8453</span>, <span class="seriesInfo">DOI 10.17487/RFC8453</span>, <time datetime="2018-08">August 2018</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8453">https://www.rfc-editor.org/info/rfc8453</a>&gt;</span>. </dd>
<dt id="RFC8637">[RFC8637]</dt>
<dd>
<span class="refAuthor">Dhody, D.</span><span class="refAuthor">, Lee, Y.</span><span class="refAuthor">, and D. Ceccarelli</span>, <span class="refTitle">"Applicability of the Path Computation Element (PCE) to the Abstraction and Control of TE Networks (ACTN)"</span>, <span class="seriesInfo">RFC 8637</span>, <span class="seriesInfo">DOI 10.17487/RFC8637</span>, <time datetime="2019-07">July 2019</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8637">https://www.rfc-editor.org/info/rfc8637</a>&gt;</span>. </dd>
<dt id="RFC8685">[RFC8685]</dt>
<dd>
<span class="refAuthor">Zhang, F.</span><span class="refAuthor">, Zhao, Q.</span><span class="refAuthor">, Gonzalez de Dios, O.</span><span class="refAuthor">, Casellas, R.</span><span class="refAuthor">, and D. King</span>, <span class="refTitle">"Path Computation Element Communication Protocol (PCEP) Extensions for the Hierarchical Path Computation Element (H-PCE) Architecture"</span>, <span class="seriesInfo">RFC 8685</span>, <span class="seriesInfo">DOI 10.17487/RFC8685</span>, <time datetime="2019-12">December 2019</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8685">https://www.rfc-editor.org/info/rfc8685</a>&gt;</span>. </dd>
<dt id="RFC8741">[RFC8741]</dt>
<dd>
<span class="refAuthor">Raghuram, A.</span><span class="refAuthor">, Goddard, A.</span><span class="refAuthor">, Karthik, J.</span><span class="refAuthor">, Sivabalan, S.</span><span class="refAuthor">, and M. Negi</span>, <span class="refTitle">"Ability for a Stateful Path Computation Element (PCE) to Request and Obtain Control of a Label Switched Path (LSP)"</span>, <span class="seriesInfo">RFC 8741</span>, <span class="seriesInfo">DOI 10.17487/RFC8741</span>, <time datetime="2020-03">March 2020</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8741">https://www.rfc-editor.org/info/rfc8741</a>&gt;</span>. </dd>
<dt id="RFC8745">[RFC8745]</dt>
<dd>
<span class="refAuthor">Ananthakrishnan, H.</span><span class="refAuthor">, Sivabalan, S.</span><span class="refAuthor">, Barth, C.</span><span class="refAuthor">, Minei, I.</span><span class="refAuthor">, and M. Negi</span>, <span class="refTitle">"Path Computation Element Communication Protocol (PCEP) Extensions for Associating Working and Protection Label Switched Paths (LSPs) with Stateful PCE"</span>, <span class="seriesInfo">RFC 8745</span>, <span class="seriesInfo">DOI 10.17487/RFC8745</span>, <time datetime="2020-03">March 2020</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8745">https://www.rfc-editor.org/info/rfc8745</a>&gt;</span>. </dd>
<dt id="I-D.ietf-pce-enhanced-errors">[PCE-ENHANCED-ERRORS]</dt>
<dd>
<span class="refAuthor">Poullyau, H.</span><span class="refAuthor">, Theillaud, R.</span><span class="refAuthor">, Meuric, J.</span><span class="refAuthor">, Zheng, H.</span><span class="refAuthor">, and X. Zhang</span>, <span class="refTitle">"Extensions to the Path Computation Element Communication Protocol for Enhanced Errors and Notifications"</span>, <span class="refContent">Work in Progress</span>, <span class="seriesInfo">Internet-Draft, draft-ietf-pce-enhanced-errors-06</span>, <time datetime="2019-08-14">14 August 2019</time>, <span>&lt;<a href="https://tools.ietf.org/html/draft-ietf-pce-enhanced-errors-06">https://tools.ietf.org/html/draft-ietf-pce-enhanced-errors-06</a>&gt;</span>. </dd>
<dt id="I-D.ietf-pce-pcep-yang">[PCE-PCEP-YANG]</dt>
<dd>
<span class="refAuthor">Dhody, D.</span><span class="refAuthor">, Hardwick, J.</span><span class="refAuthor">, Beeram, V.</span><span class="refAuthor">, and J. Tantsura</span>, <span class="refTitle">"A YANG Data Model for Path Computation Element Communications Protocol (PCEP)"</span>, <span class="refContent">Work in Progress</span>, <span class="seriesInfo">Internet-Draft, draft-ietf-pce-pcep-yang-13</span>, <time datetime="2019-10-31">31 October 2019</time>, <span>&lt;<a href="https://tools.ietf.org/html/draft-ietf-pce-pcep-yang-13">https://tools.ietf.org/html/draft-ietf-pce-pcep-yang-13</a>&gt;</span>. </dd>
<dt id="I-D.litkowski-pce-state-sync">[PCE-STATE-SYNC]</dt>
<dd>
<span class="refAuthor">Litkowski, S.</span><span class="refAuthor">, Sivabalan, S.</span><span class="refAuthor">, Li, C.</span><span class="refAuthor">, and H. Zheng</span>, <span class="refTitle">"Inter Stateful Path Computation Element (PCE) Communication Procedures."</span>, <span class="refContent">Work in Progress</span>, <span class="seriesInfo">Internet-Draft, draft-litkowski-pce-state-sync-07</span>, <time datetime="2020-01-11">11 January 2020</time>, <span>&lt;<a href="https://tools.ietf.org/html/draft-litkowski-pce-state-sync-07">https://tools.ietf.org/html/draft-litkowski-pce-state-sync-07</a>&gt;</span>. </dd>
<dt id="I-D.dugeon-pce-stateful-interdomain">[STATEFUL-INTERDOMAIN]</dt>
<dd>
<span class="refAuthor">Dugeon, O.</span><span class="refAuthor">, Meuric, J.</span><span class="refAuthor">, Lee, Y.</span><span class="refAuthor">, and D. Ceccarelli</span>, <span class="refTitle">"PCEP Extension for Stateful Inter-Domain Tunnels"</span>, <span class="refContent">Work in Progress</span>, <span class="seriesInfo">Internet-Draft, draft-dugeon-pce-stateful-interdomain-02</span>, <time datetime="2019-03-04">4 March 2019</time>, <span>&lt;<a href="https://tools.ietf.org/html/draft-dugeon-pce-stateful-interdomain-02">https://tools.ietf.org/html/draft-dugeon-pce-stateful-interdomain-02</a>&gt;</span>. </dd>
</dl>
</section>
</section>
<div id="sect-8">
<section id="section-appendix.a">
      <h2 id="name-acknowledgments">
<a href="#name-acknowledgments" class="section-name selfRef">Acknowledgments</a>
      </h2>
<p id="section-appendix.a-1">
   Thanks to <span class="contact-name">Manuela Scarella</span>, <span class="contact-name">Haomian Zheng</span>, <span class="contact-name">Sergio Marmo</span>, <span class="contact-name">Stefano    Parodi</span>, <span class="contact-name">Giacomo Agostini</span>, <span class="contact-name">Jeff Tantsura</span>, <span class="contact-name">Rajan Rao</span>, <span class="contact-name">Adrian Farrel</span>, and
   <span class="contact-name">Haomian Zheng</span> for their reviews and suggestions.<a href="#section-appendix.a-1" class="pilcrow">¶</a></p>
<p id="section-appendix.a-2">
   Thanks to <span class="contact-name">Tal Mazrahi</span> for the RTGDIR
   review, <span class="contact-name">Paul Kyzivat</span> for the
   GENART review, and <span class="contact-name">Stephen Farrell</span>
      for the SECDIR review.<a href="#section-appendix.a-2" class="pilcrow">¶</a></p>
<p id="section-appendix.a-3">
   Thanks to <span class="contact-name">Barry Leiba</span>, <span class="contact-name">Martin Vigoureux</span>, <span class="contact-name">Benjamin Kaduk</span>, and <span class="contact-name">Roman    Danyliw</span> for the IESG review.<a href="#section-appendix.a-3" class="pilcrow">¶</a></p>
</section>
</div>
<div id="contributors">
<section id="section-appendix.b">
      <h2 id="name-contributors">
<a href="#name-contributors" class="section-name selfRef">Contributors</a>
      </h2>
<address class="vcard">
        <div dir="auto" class="left"><span class="fn nameRole">Avantika</span></div>
<div dir="auto" class="left"><span class="org">ECI Telecom</span></div>
<div dir="auto" class="left"><span class="country-name">India</span></div>
<div class="email">
<span>Email:</span>
<a href="mailto:avantika.srm@gmail.com" class="email">avantika.srm@gmail.com</a>
</div>
</address>
<address class="vcard">
        <div dir="auto" class="left"><span class="fn nameRole">Xian Zhang</span></div>
<div dir="auto" class="left"><span class="org">Huawei Technologies</span></div>
<div dir="auto" class="left"><span class="street-address">Bantian, Longgang District</span></div>
<div dir="auto" class="left"><span class="locality">Guangdong</span></div>
<div dir="auto" class="left">
<span class="region">Shenzhen</span>, <span class="postal-code">518129</span>
</div>
<div dir="auto" class="left"><span class="country-name">China</span></div>
<div class="email">
<span>Email:</span>
<a href="mailto:zhang.xian@huawei.com" class="email">zhang.xian@huawei.com</a>
</div>
</address>
<address class="vcard">
        <div dir="auto" class="left"><span class="fn nameRole">Udayasree Palle</span></div>
<div class="email">
<span>Email:</span>
<a href="mailto:udayasreereddy@gmail.com" class="email">udayasreereddy@gmail.com</a>
</div>
</address>
<address class="vcard">
        <div dir="auto" class="left"><span class="fn nameRole">Oscar Gonzalez de Dios</span></div>
<div dir="auto" class="left"><span class="org">Telefonica I+D</span></div>
<div dir="auto" class="left"><span class="street-address">Don Ramon de la Cruz 82-84</span></div>
<div dir="auto" class="left">
<span class="postal-code">28045</span> <span class="locality">Madrid</span> </div>
<div dir="auto" class="left"><span class="country-name">Spain</span></div>
<div class="tel">
<span>Phone:</span>
<a href="tel:+34913128832" class="tel">+34913128832</a>
</div>
<div class="email">
<span>Email:</span>
<a href="mailto:oscar.gonzalezdedios@telefonica.com" class="email">oscar.gonzalezdedios@telefonica.com</a>
</div>
</address>
</section>
</div>
<div id="authors-addresses">
<section id="section-appendix.c">
      <h2 id="name-authors-addresses">
<a href="#name-authors-addresses" class="section-name selfRef">Authors' Addresses</a>
      </h2>
<address class="vcard">
        <div dir="auto" class="left"><span class="fn nameRole">Dhruv Dhody</span></div>
<div dir="auto" class="left"><span class="org">Huawei Technologies</span></div>
<div dir="auto" class="left"><span class="street-address">Divyashree Techno Park, Whitefield</span></div>
<div dir="auto" class="left">
<span class="locality">Bangalore</span> <span class="postal-code">560066</span>
</div>
<div dir="auto" class="left"><span class="region">Karnataka</span></div>
<div dir="auto" class="left"><span class="country-name">India</span></div>
<div class="email">
<span>Email:</span>
<a href="mailto:dhruv.ietf@gmail.com" class="email">dhruv.ietf@gmail.com</a>
</div>
</address>
<address class="vcard">
        <div dir="auto" class="left"><span class="fn nameRole">Young Lee</span></div>
<div dir="auto" class="left"><span class="org">Samsung Electronics</span></div>
<div class="email">
<span>Email:</span>
<a href="mailto:younglee.tx@gmail.com" class="email">younglee.tx@gmail.com</a>
</div>
</address>
<address class="vcard">
        <div dir="auto" class="left"><span class="fn nameRole">Daniele Ceccarelli</span></div>
<div dir="auto" class="left"><span class="org">Ericsson</span></div>
<div dir="auto" class="left"><span class="street-address">Torshamnsgatan, 48</span></div>
<div dir="auto" class="left"><span class="locality">Stockholm</span></div>
<div dir="auto" class="left"><span class="country-name">Sweden</span></div>
<div class="email">
<span>Email:</span>
<a href="mailto:daniele.ceccarelli@ericsson.com" class="email">daniele.ceccarelli@ericsson.com</a>
</div>
</address>
<address class="vcard">
        <div dir="auto" class="left"><span class="fn nameRole">Jongyoon Shin</span></div>
<div dir="auto" class="left"><span class="org">SK Telecom</span></div>
<div dir="auto" class="left"><span class="extended-address">6 Hwangsaeul-ro, 258 beon-gil</span></div>
<div dir="auto" class="left"><span class="street-address">Bundang-gu, Seongnam-si,</span></div>
<div dir="auto" class="left"><span class="region">Gyeonggi-do</span></div>
<div dir="auto" class="left"><span class="postal-code">463-784</span></div>
<div dir="auto" class="left"><span class="country-name">Republic of Korea</span></div>
<div class="email">
<span>Email:</span>
<a href="mailto:jongyoon.shin@sk.com" class="email">jongyoon.shin@sk.com</a>
</div>
</address>
<address class="vcard">
        <div dir="auto" class="left"><span class="fn nameRole">Daniel King</span></div>
<div dir="auto" class="left"><span class="org">Lancaster University</span></div>
<div dir="auto" class="left"><span class="country-name">United Kingdom</span></div>
<div class="email">
<span>Email:</span>
<a href="mailto:d.king@lancaster.ac.uk" class="email">d.king@lancaster.ac.uk</a>
</div>
</address>
</section>
</div>
<script>const toc = document.getElementById("toc");
toc.querySelector("h2").addEventListener("click", e => {
  toc.classList.toggle("active");
});
toc.querySelector("nav").addEventListener("click", e => {
  toc.classList.remove("active");
});
</script>
</body>
</html>