File: rfc9059.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 (2622 lines) | stat: -rw-r--r-- 124,222 bytes
<!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 9059: Path Computation Element Communication Protocol (PCEP) Extensions for Associated Bidirectional Label Switched Paths (LSPs)</title>
<meta content="Rakesh Gandhi" name="author">
<meta content="Colby Barth" name="author">
<meta content="Bin Wen" name="author">
<meta content="
       This document defines Path Computation Element Communication Protocol
      (PCEP) extensions for grouping two unidirectional MPLS-TE Label Switched
      Paths (LSPs), one in each direction in the network, into an associated
      bidirectional LSP.  These PCEP extensions can be applied either using a
      stateful PCE for both PCE-initiated and PCC-initiated LSPs or using
      a stateless PCE. The PCEP procedures defined are applicable
      to the LSPs using RSVP-TE for signaling. 
    " name="description">
<meta content="xml2rfc 3.8.0" name="generator">
<meta content="9059" name="rfc.number">
<!-- Generator version information:
  xml2rfc 3.8.0
    Python 3.6.10
    appdirs 1.4.4
    ConfigArgParse 1.2.3
    google-i18n-address 2.3.5
    html5lib 1.0.1
    intervaltree 3.0.2
    Jinja2 2.11.2
    kitchen 1.2.6
    lxml 4.4.2
    pycairo 1.19.0
    pycountry 19.8.18
    pyflakes 2.1.1
    PyYAML 5.3.1
    requests 2.22.0
    setuptools 40.6.2
    six 1.14.0
    WeasyPrint 51
-->
<link href="rfc9059.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;
  }

}
/* 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; }
}
/* Add support for keepWithNext */
.keepWithNext {
  break-after: avoid-page;
  break-after: avoid-page;
}
/* Add support for keepWithPrevious */
.keepWithPrevious {
  break-before: avoid-page;
}
/* Change the approach to avoiding breaks inside artwork etc. */
figure, pre, table, .artwork, .sourcecode  {
  break-before: avoid-page;
  break-after: auto;
}
/* Avoid breaks between <dt> and <dd> */
dl {
  break-before: auto;
  break-inside: auto;
}
dt {
  break-before: auto;
  break-after: avoid-page;
}
dd {
  break-before: avoid-page;
  break-after: auto;
  orphans: 3;
  widows: 3
}
span.break, dd.break {
  margin-bottom: 0;
  min-height: 0;
  break-before: auto;
  break-inside: auto;
  break-after: auto;
}
/* Undo break-before ToC */
@media print {
  #toc {
    break-before: auto;
  }
}
/* Text in compact lists should not get extra bottim margin space,
   since that would makes the list not compact */
ul.compact p, .ulCompact p,
ol.compact p, .olCompact p {
 margin: 0;
}
/* But the list as a whole needs the extra space at the end */
section ul.compact,
section .ulCompact,
section ol.compact,
section .olCompact {
  margin-bottom: 1em;                    /* same as p not within ul.compact etc. */
}
/* The tt and code background above interferes with for instance table cell
   backgrounds.  Changed to something a bit more selective. */
tt, code {
  background-color: transparent;
}
p tt, p code, li tt, li code {
  background-color: #f8f8f8;
}
/* Tweak the pre margin -- 0px doesn't come out well */
pre {
   margin-top: 0.5px;
}
/* Tweak the comact list text */
ul.compact, .ulCompact,
ol.compact, .olCompact,
dl.compact, .dlCompact {
  line-height: normal;
}
/* Don't add top margin for nested lists */
li > ul, li > ol, li > dl,
dd > ul, dd > ol, dd > dl,
dl > dd > dl {
  margin-top: initial;
}
/* Elements that should not be rendered on the same line as a <dt> */
/* This should match the element list in writer.text.TextWriter.render_dl() */
dd > div.artwork:first-child,
dd > aside:first-child,
dd > figure:first-child,
dd > ol:first-child,
dd > div:first-child > pre.sourcecode,
dd > table:first-child,
dd > ul:first-child {
  clear: left;
}
/* fix for weird browser behaviour when <dd/> is empty */
dt+dd:empty::before{
  content: "\00a0";
}
/* Make paragraph spacing inside <li> smaller than in body text, to fit better within the list */
li > p {
  margin-bottom: 0.5em
}
/* Don't let p margin spill out from inside list items */
li > p:last-of-type {
  margin-bottom: 0;
}
</style>
<link href="rfc-local.css" rel="stylesheet" type="text/css">
<link href="https://dx.doi.org/10.17487/rfc9059" rel="alternate">
  <link href="urn:issn:2070-1721" rel="alternate">
  <link href="https://datatracker.ietf.org/doc/draft-ietf-pce-association-bidir-14" 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 9059</td>
<td class="center">PCEP for Associated Bidirectional LSPs</td>
<td class="right">June 2021</td>
</tr></thead>
<tfoot><tr>
<td class="left">Gandhi, et al.</td>
<td class="center">Standards Track</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/rfc9059" class="eref">9059</a></dd>
<dt class="label-category">Category:</dt>
<dd class="category">Standards Track</dd>
<dt class="label-published">Published:</dt>
<dd class="published">
<time datetime="2021-06" class="published">June 2021</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">R. Gandhi, <span class="editor">Ed.</span>
</div>
<div class="org">Cisco Systems, Inc.</div>
</div>
<div class="author">
      <div class="author-name">C. Barth</div>
<div class="org">Juniper Networks</div>
</div>
<div class="author">
      <div class="author-name">B. Wen</div>
<div class="org">Comcast</div>
</div>
</dd>
</dl>
</div>
<h1 id="rfcnum">RFC 9059</h1>
<h1 id="title">Path Computation Element Communication Protocol (PCEP) Extensions for Associated Bidirectional Label Switched Paths (LSPs)</h1>
<section id="section-abstract">
      <h2 id="abstract"><a href="#abstract" class="selfRef">Abstract</a></h2>
<p id="section-abstract-1">This document defines Path Computation Element Communication Protocol
      (PCEP) extensions for grouping two unidirectional MPLS-TE Label Switched
      Paths (LSPs), one in each direction in the network, into an associated
      bidirectional LSP.  These PCEP extensions can be applied either using a
      stateful PCE for both PCE-initiated and PCC-initiated LSPs or using
      a stateless PCE. The PCEP procedures defined are applicable
      to the LSPs using RSVP-TE for signaling.<a href="#section-abstract-1" 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 is an Internet Standards Track document.<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).  Further
            information on Internet Standards is available in 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/rfc9059">https://www.rfc-editor.org/info/rfc9059</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) 2021 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="ulEmpty compact toc">
<li class="ulEmpty compact toc" id="section-toc.1-1.1">
            <p id="section-toc.1-1.1.1" class="keepWithNext"><a href="#section-1" class="xref">1</a>.  <a href="#name-introduction" class="xref">Introduction</a></p>
</li>
          <li class="ulEmpty compact toc" 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-conventions-used-in-this-do" class="xref">Conventions Used in This Document</a></p>
<ul class="ulEmpty compact toc">
<li class="ulEmpty compact toc" id="section-toc.1-1.2.2.1">
                <p id="section-toc.1-1.2.2.1.1" class="keepWithNext"><a href="#section-2.1" class="xref">2.1</a>.  <a href="#name-key-word-definitions" class="xref">Key Word Definitions</a></p>
</li>
              <li class="ulEmpty compact toc" id="section-toc.1-1.2.2.2">
                <p id="section-toc.1-1.2.2.2.1" class="keepWithNext"><a href="#section-2.2" class="xref">2.2</a>.  <a href="#name-terminology" class="xref">Terminology</a></p>
</li>
            </ul>
</li>
          <li class="ulEmpty compact toc" 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-overview" class="xref">Overview</a></p>
<ul class="ulEmpty compact toc">
<li class="ulEmpty compact toc" 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-single-sided-initiation" class="xref">Single-Sided Initiation</a></p>
<ul class="ulEmpty compact toc">
<li class="ulEmpty compact toc" id="section-toc.1-1.3.2.1.2.1">
                    <p id="section-toc.1-1.3.2.1.2.1.1"><a href="#section-3.1.1" class="xref">3.1.1</a>.  <a href="#name-pce-initiated-single-sided-" class="xref">PCE-Initiated Single-Sided Bidirectional LSP</a></p>
</li>
                  <li class="ulEmpty compact toc" id="section-toc.1-1.3.2.1.2.2">
                    <p id="section-toc.1-1.3.2.1.2.2.1"><a href="#section-3.1.2" class="xref">3.1.2</a>.  <a href="#name-pcc-initiated-single-sided-" class="xref">PCC-Initiated Single-Sided Bidirectional LSP</a></p>
</li>
                </ul>
</li>
              <li class="ulEmpty compact toc" 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-double-sided-initiation" class="xref">Double-Sided Initiation</a></p>
<ul class="ulEmpty compact toc">
<li class="ulEmpty compact toc" id="section-toc.1-1.3.2.2.2.1">
                    <p id="section-toc.1-1.3.2.2.2.1.1"><a href="#section-3.2.1" class="xref">3.2.1</a>.  <a href="#name-pce-initiated-double-sided-" class="xref">PCE-Initiated Double-Sided Bidirectional LSP</a></p>
</li>
                  <li class="ulEmpty compact toc" id="section-toc.1-1.3.2.2.2.2">
                    <p id="section-toc.1-1.3.2.2.2.2.1"><a href="#section-3.2.2" class="xref">3.2.2</a>.  <a href="#name-pcc-initiated-double-sided-" class="xref">PCC-Initiated Double-Sided Bidirectional LSP</a></p>
</li>
                </ul>
</li>
              <li class="ulEmpty compact toc" 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-co-routed-associated-bidire" class="xref">Co-routed Associated Bidirectional LSP</a></p>
</li>
              <li class="ulEmpty compact toc" id="section-toc.1-1.3.2.4">
                <p id="section-toc.1-1.3.2.4.1"><a href="#section-3.4" class="xref">3.4</a>.  <a href="#name-summary-of-pcep-extensions" class="xref">Summary of PCEP Extensions</a></p>
</li>
              <li class="ulEmpty compact toc" id="section-toc.1-1.3.2.5">
                <p id="section-toc.1-1.3.2.5.1"><a href="#section-3.5" class="xref">3.5</a>.  <a href="#name-operational-considerations" class="xref">Operational Considerations</a></p>
</li>
            </ul>
</li>
          <li class="ulEmpty compact toc" 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-protocol-extensions" class="xref">Protocol Extensions</a></p>
<ul class="ulEmpty compact toc">
<li class="ulEmpty compact toc" id="section-toc.1-1.4.2.1">
                <p id="section-toc.1-1.4.2.1.1"><a href="#section-4.1" class="xref">4.1</a>.  <a href="#name-association-object" class="xref">ASSOCIATION Object</a></p>
</li>
              <li class="ulEmpty compact toc" id="section-toc.1-1.4.2.2">
                <p id="section-toc.1-1.4.2.2.1"><a href="#section-4.2" class="xref">4.2</a>.  <a href="#name-bidirectional-lsp-associati" class="xref">Bidirectional LSP Association Group TLV</a></p>
</li>
            </ul>
</li>
          <li class="ulEmpty compact toc" 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-pcep-procedure" class="xref">PCEP Procedure</a></p>
<ul class="ulEmpty compact toc">
<li class="ulEmpty compact toc" 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-pce-initiated-lsps" class="xref">PCE-Initiated LSPs</a></p>
</li>
              <li class="ulEmpty compact toc" 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-pcc-initiated-lsps" class="xref">PCC-Initiated LSPs</a></p>
</li>
              <li class="ulEmpty compact toc" 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-stateless-pce" class="xref">Stateless PCE</a></p>
</li>
              <li class="ulEmpty compact toc" 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-bidirectional-b-flag" class="xref">Bidirectional (B) Flag</a></p>
</li>
              <li class="ulEmpty compact toc" 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-plsp-id-usage" class="xref">PLSP-ID Usage</a></p>
</li>
              <li class="ulEmpty compact toc" 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-state-synchronization" class="xref">State Synchronization</a></p>
</li>
              <li class="ulEmpty compact toc" 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" class="xref">Error Handling</a></p>
</li>
            </ul>
</li>
          <li class="ulEmpty compact toc" 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-security-considerations" class="xref">Security Considerations</a></p>
</li>
          <li class="ulEmpty compact toc" 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-manageability-consideration" class="xref">Manageability Considerations</a></p>
<ul class="ulEmpty compact toc">
<li class="ulEmpty compact toc" id="section-toc.1-1.7.2.1">
                <p id="section-toc.1-1.7.2.1.1"><a href="#section-7.1" class="xref">7.1</a>.  <a href="#name-control-of-function-and-pol" class="xref">Control of Function and Policy</a></p>
</li>
              <li class="ulEmpty compact toc" id="section-toc.1-1.7.2.2">
                <p id="section-toc.1-1.7.2.2.1"><a href="#section-7.2" class="xref">7.2</a>.  <a href="#name-information-and-data-models" class="xref">Information and Data Models</a></p>
</li>
              <li class="ulEmpty compact toc" id="section-toc.1-1.7.2.3">
                <p id="section-toc.1-1.7.2.3.1"><a href="#section-7.3" class="xref">7.3</a>.  <a href="#name-liveness-detection-and-moni" class="xref">Liveness Detection and Monitoring</a></p>
</li>
              <li class="ulEmpty compact toc" id="section-toc.1-1.7.2.4">
                <p id="section-toc.1-1.7.2.4.1"><a href="#section-7.4" class="xref">7.4</a>.  <a href="#name-verify-correct-operations" class="xref">Verify Correct Operations</a></p>
</li>
              <li class="ulEmpty compact toc" id="section-toc.1-1.7.2.5">
                <p id="section-toc.1-1.7.2.5.1"><a href="#section-7.5" class="xref">7.5</a>.  <a href="#name-requirements-on-other-proto" class="xref">Requirements on Other Protocols</a></p>
</li>
              <li class="ulEmpty compact toc" id="section-toc.1-1.7.2.6">
                <p id="section-toc.1-1.7.2.6.1"><a href="#section-7.6" class="xref">7.6</a>.  <a href="#name-impact-on-network-operation" class="xref">Impact on Network Operations</a></p>
</li>
            </ul>
</li>
          <li class="ulEmpty compact toc" 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-iana-considerations" class="xref">IANA Considerations</a></p>
<ul class="ulEmpty compact toc">
<li class="ulEmpty compact toc" 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-association-types" class="xref">Association Types</a></p>
</li>
              <li class="ulEmpty compact toc" 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-bidirectional-lsp-association" class="xref">Bidirectional LSP Association Group TLV</a></p>
<ul class="ulEmpty compact toc">
<li class="ulEmpty compact toc" id="section-toc.1-1.8.2.2.2.1">
                    <p id="section-toc.1-1.8.2.2.2.1.1"><a href="#section-8.2.1" class="xref">8.2.1</a>.  <a href="#name-flag-field-in-bidirectional" class="xref">Flag Field in Bidirectional LSP Association Group TLV</a></p>
</li>
                </ul>
</li>
              <li class="ulEmpty compact toc" id="section-toc.1-1.8.2.3">
                <p id="section-toc.1-1.8.2.3.1"><a href="#section-8.3" class="xref">8.3</a>.  <a href="#name-pcep-errors" class="xref">PCEP Errors</a></p>
</li>
            </ul>
</li>
          <li class="ulEmpty compact toc" id="section-toc.1-1.9">
            <p id="section-toc.1-1.9.1"><a href="#section-9" class="xref">9</a>.  <a href="#name-references" class="xref">References</a></p>
<ul class="ulEmpty compact toc">
<li class="ulEmpty compact toc" id="section-toc.1-1.9.2.1">
                <p id="section-toc.1-1.9.2.1.1"><a href="#section-9.1" class="xref">9.1</a>.  <a href="#name-normative-references" class="xref">Normative References</a></p>
</li>
              <li class="ulEmpty compact toc" id="section-toc.1-1.9.2.2">
                <p id="section-toc.1-1.9.2.2.1"><a href="#section-9.2" class="xref">9.2</a>.  <a href="#name-informative-references" class="xref">Informative References</a></p>
</li>
            </ul>
</li>
          <li class="ulEmpty compact toc" id="section-toc.1-1.10">
            <p id="section-toc.1-1.10.1"><a href="#section-appendix.a" class="xref"></a><a href="#name-acknowledgments" class="xref">Acknowledgments</a></p>
</li>
          <li class="ulEmpty compact toc" id="section-toc.1-1.11">
            <p id="section-toc.1-1.11.1"><a href="#section-appendix.b" class="xref"></a><a href="#name-authors-addresses" class="xref">Authors' Addresses</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>
<p id="section-1-1"><span>[<a href="#RFC5440" class="xref">RFC5440</a>]</span> describes the Path Computation Element
      Communication Protocol (PCEP) as a communication mechanism between a Path Computation
      Client (PCC) and a Path Computation Element (PCE), or between PCE and PCC,
      that enables computation of Multiprotocol Label Switching (MPLS) - Traffic
      Engineering (TE) Label Switched Paths (LSPs).<a href="#section-1-1" class="pilcrow">¶</a></p>
<p id="section-1-2"><span>[<a href="#RFC8231" class="xref">RFC8231</a>]</span> specifies extensions to PCEP to enable
      stateful control of MPLS-TE LSPs. It describes two modes of operation:
      passive stateful PCE and active stateful PCE. In <span>[<a href="#RFC8231" class="xref">RFC8231</a>]</span>, the focus is on active stateful PCE where LSPs are
      provisioned on the PCC and control over them is delegated to a PCE.
      Further, <span>[<a href="#RFC8281" class="xref">RFC8281</a>]</span> describes the setup, maintenance, and
      teardown of PCE-initiated LSPs for the stateful PCE model.<a href="#section-1-2" class="pilcrow">¶</a></p>
<p id="section-1-3"><span>[<a href="#RFC8697" class="xref">RFC8697</a>]</span> introduces a generic mechanism for creating a grouping of LSPs.
      This grouping can then be used to define associations between
      sets of LSPs or between a set of LSPs and a set of attributes,
      and it is equally applicable to the stateful PCE (active and
      passive modes) and the stateless PCE.<a href="#section-1-3" class="pilcrow">¶</a></p>
<p id="section-1-4">The MPLS Transport Profile (MPLS-TP) requirements document <span>[<a href="#RFC5654" class="xref">RFC5654</a>]</span> specifies that 
      "MPLS-TP <span class="bcp14">MUST</span> support unidirectional, co-routed bidirectional, and
       associated bidirectional point-to-point transport paths".
      <span>[<a href="#RFC7551" class="xref">RFC7551</a>]</span> defines RSVP
      signaling extensions for binding forward and reverse unidirectional LSPs 
      into an associated bidirectional LSP. The fast
      reroute (FRR) procedures for associated bidirectional LSPs are described
      in <span>[<a href="#RFC8537" class="xref">RFC8537</a>]</span>.<a href="#section-1-4" class="pilcrow">¶</a></p>
<p id="section-1-5">This document defines PCEP extensions for grouping two unidirectional
      MPLS-TE LSPs into an associated bidirectional LSP for both single-sided
      and double-sided initiation cases either when using a stateful PCE for both
      PCE-initiated and PCC-initiated LSPs or when using a stateless
      PCE. The procedures defined are applicable to the LSPs using Resource
      Reservation Protocol - Traffic Engineering (RSVP-TE) for signaling <span>[<a href="#RFC3209" class="xref">RFC3209</a>]</span>.
      Specifically, this document defines two new Association Types, Single-Sided  
      Bidirectional LSP Association and Double-Sided Bidirectional 
      LSP Association, as well as the Bidirectional LSP Association Group TLV, to carry 
      additional information for the association.<a href="#section-1-5" class="pilcrow">¶</a></p>
<p id="section-1-6">The procedure for associating two unidirectional Segment Routing (SR) paths 
      to form an associated bidirectional SR path is defined in 
      <span>[<a href="#I-D.ietf-pce-sr-bidir-path" class="xref">BIDIR-PATH</a>]</span> and is outside the scope of 
      this document.<a href="#section-1-6" class="pilcrow">¶</a></p>
</section>
</div>
<div id="sect-2">
<section id="section-2">
      <h2 id="name-conventions-used-in-this-do">
<a href="#section-2" class="section-number selfRef">2. </a><a href="#name-conventions-used-in-this-do" class="section-name selfRef">Conventions Used in This Document</a>
      </h2>
<div id="sect-2.1">
<section id="section-2.1">
        <h3 id="name-key-word-definitions">
<a href="#section-2.1" class="section-number selfRef">2.1. </a><a href="#name-key-word-definitions" class="section-name selfRef">Key Word Definitions</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>
<div id="sect-2.2">
<section id="section-2.2">
        <h3 id="name-terminology">
<a href="#section-2.2" class="section-number selfRef">2.2. </a><a href="#name-terminology" class="section-name selfRef">Terminology</a>
        </h3>
<p id="section-2.2-1">The reader is assumed to be familiar with the terminology defined
        in <span>[<a href="#RFC5440" class="xref">RFC5440</a>]</span>, <span>[<a href="#RFC7551" class="xref">RFC7551</a>]</span>, <span>[<a href="#RFC8231" class="xref">RFC8231</a>]</span>, and <span>[<a href="#RFC8697" class="xref">RFC8697</a>]</span>.<a href="#section-2.2-1" class="pilcrow">¶</a></p>
</section>
</div>
</section>
</div>
<div id="sect-3">
<section id="section-3">
      <h2 id="name-overview">
<a href="#section-3" class="section-number selfRef">3. </a><a href="#name-overview" class="section-name selfRef">Overview</a>
      </h2>
<p id="section-3-1">As shown in <a href="#ure-example-of-associated-bidirectional-lsp" class="xref">Figure 1</a>, forward and reverse unidirectional LSPs can be grouped
      to form an associated bidirectional LSP. Node A is the ingress node for LSP1 and
      egress node for LSP2, whereas node D is the ingress node 
      for LSP2 and egress node for LSP1. There are two methods of
      initiating the Bidirectional LSP Association, single-sided and
      double-sided, as defined in <span>[<a href="#RFC7551" class="xref">RFC7551</a>]</span> and described in
      the following sections.<a href="#section-3-1" class="pilcrow">¶</a></p>
<span id="name-example-of-associated-bidir"></span><div id="ure-example-of-associated-bidirectional-lsp">
<figure id="figure-1">
        <div class="artwork art-text alignLeft" id="section-3-2.1">
<pre>
            LSP1 --&gt;          LSP1 --&gt;          LSP1 --&gt;
   +-----+           +-----+           +-----+           +-----+
   |  A  +-----------+  B  +-----------+  C  +-----------+  D  |
   +-----+           +--+--+           +--+--+           +-----+
            &lt;-- LSP2    |                 |     &lt;-- LSP2
                        |                 |
                        |                 |
                     +--+--+           +--+--+
                     |  E  +-----------+  F  |
                     +-----+           +-----+
                             &lt;-- LSP2
</pre>
</div>
<figcaption><a href="#figure-1" class="selfRef">Figure 1</a>:
<a href="#name-example-of-associated-bidir" class="selfRef">Example of Associated Bidirectional LSP</a>
        </figcaption></figure>
</div>
<div id="sect-3.1">
<section id="section-3.1">
        <h3 id="name-single-sided-initiation">
<a href="#section-3.1" class="section-number selfRef">3.1. </a><a href="#name-single-sided-initiation" class="section-name selfRef">Single-Sided Initiation</a>
        </h3>
<p id="section-3.1-1">As specified in <span>[<a href="#RFC7551" class="xref">RFC7551</a>]</span>, in the single-sided case,
        the bidirectional tunnel is provisioned only on one endpoint node
        (PCC) of the tunnel. Both endpoint nodes act as PCCs. 
        Both forward and reverse LSPs of this tunnel are
        initiated with the Association Type set to "Single-Sided Bidirectional
        LSP Association" on the originating endpoint node. The forward and
        reverse LSPs are identified in the Bidirectional LSP Association Group
        TLV of their PCEP ASSOCIATION objects.<a href="#section-3.1-1" class="pilcrow">¶</a></p>
<p id="section-3.1-2">The originating endpoint node signals the properties for the reverse
        LSP in the RSVP REVERSE_LSP object <span>[<a href="#RFC7551" class="xref">RFC7551</a>]</span> of the
        forward LSP Path message. The remote endpoint node then creates the
        corresponding reverse tunnel and reverse LSP, and it then signals the reverse LSP in response
        to the received RSVP-TE Path message. Similarly, the remote endpoint node
        deletes the reverse LSP when it receives the RSVP-TE message to delete the forward LSP
        <span>[<a href="#RFC3209" class="xref">RFC3209</a>]</span>.<a href="#section-3.1-2" class="pilcrow">¶</a></p>
<p id="section-3.1-3">As specified in <span>[<a href="#RFC8537" class="xref">RFC8537</a>]</span>, for fast reroute bypass
        tunnel assignment, the LSP starting from the originating endpoint node is
        identified as the forward LSP of the single-sided initiated
        bidirectional LSP.<a href="#section-3.1-3" class="pilcrow">¶</a></p>
<div id="sect-3.1.1">
<section id="section-3.1.1">
          <h4 id="name-pce-initiated-single-sided-">
<a href="#section-3.1.1" class="section-number selfRef">3.1.1. </a><a href="#name-pce-initiated-single-sided-" class="section-name selfRef">PCE-Initiated Single-Sided Bidirectional LSP</a>
          </h4>
<span id="name-example-of-pce-initiated-si"></span><div id="ure-example-of-pce-initiated-single-sided-bidirectional-lsp">
<figure id="figure-2">
            <div class="artwork art-text alignLeft" id="section-3.1.1-1.1">
<pre>
                                +-----+
                                | PCE |
                                +-----+
    Initiates:                   |    \
    Tunnel 1 (F)                 |     \
    (LSP1 (F, 0), LSP2 (R, 0))   |      \
    Association #1               v       \
                              +-----+    +-----+
                              |  A  |    |  D  |
                              +-----+    +-----+


                                +-----+
                                | PCE |
                                +-----+
    Reports:                     ^    ^      Reports:
    Tunnel 1 (F)                 |     \     Tunnel 2 (F)
    (LSP1 (F, P1), LSP2 (R, P2)) |      \    (LSP2 (F, P3))
    Association #1               |       \   Association #1
                              +-----+    +-----+
                              |  A  |    |  D  |
                              +-----+    +-----+

  Legend: F = Forward LSP, R = Reverse LSP, (0,P1,P2,P3) = PLSP-IDs
</pre>
</div>
<figcaption><a href="#figure-2" class="selfRef">Figure 2</a>:
<a href="#name-example-of-pce-initiated-si" class="selfRef">Example of PCE-Initiated Single-Sided Bidirectional LSP</a>
            </figcaption></figure>
</div>
<p id="section-3.1.1-2">Using partial topology from <a href="#ure-example-of-associated-bidirectional-lsp" class="xref">Figure 1</a>, as shown in <a href="#ure-example-of-pce-initiated-single-sided-bidirectional-lsp" class="xref">Figure 2</a>, the forward Tunnel 1 and both forward LSP1 and reverse LSP2 are initiated on the originating endpoint node
       A by the PCE.  The PCEP-specific LSP identifiers (PLSP-IDs) used are P1 and P2 on the originating endpoint node A
       and P3 on the remote endpoint node D.
       The originating endpoint node A reports Tunnel 1 and forward LSP1 and reverse LSP2 
       to the PCE. The endpoint (PCC) node D reports Tunnel 2 and LSP2 to the PCE.<a href="#section-3.1.1-2" class="pilcrow">¶</a></p>
</section>
</div>
<div id="sect-3.1.2">
<section id="section-3.1.2">
          <h4 id="name-pcc-initiated-single-sided-">
<a href="#section-3.1.2" class="section-number selfRef">3.1.2. </a><a href="#name-pcc-initiated-single-sided-" class="section-name selfRef">PCC-Initiated Single-Sided Bidirectional LSP</a>
          </h4>
<span id="name-example-of-pcc-initiated-si"></span><div id="ure-example-of-pcc-initiated-single-sided-bidirectional-lsp">
<figure id="figure-3">
            <div class="artwork art-text alignLeft" id="section-3.1.2-1.1">
<pre>
                                +-----+
                                | PCE |
                                +-----+
    Reports/Delegates:           ^    ^      Reports:
    Tunnel 1 (F)                 |     \     Tunnel 2 (F)
    (LSP1 (F, P1), LSP2 (R, P2)) |      \    (LSP2 (F, P3))
    Association #2               |       \   Association #2
                              +-----+    +-----+
                              |  A  |    |  D  |
                              +-----+    +-----+

  Legend: F = Forward LSP, R = Reverse LSP, (P1,P2,P3) = PLSP-IDs
</pre>
</div>
<figcaption><a href="#figure-3" class="selfRef">Figure 3</a>:
<a href="#name-example-of-pcc-initiated-si" class="selfRef">Example of PCC-Initiated Single-Sided Bidirectional LSP</a>
            </figcaption></figure>
</div>
<p id="section-3.1.2-2">Using partial topology from <a href="#ure-example-of-associated-bidirectional-lsp" class="xref">Figure 1</a>, as shown in <a href="#ure-example-of-pcc-initiated-single-sided-bidirectional-lsp" class="xref">Figure 3</a>, the forward Tunnel 1 and both forward LSP1 and reverse LSP2 are initiated on the originating endpoint node
       A (the originating PCC). 
       The PLSP-IDs used are P1 and P2 on the originating endpoint node A
       and P3 on the remote endpoint node D.
       The originating endpoint (PCC) node A may delegate the
       forward LSP1 and reverse LSP2 to the PCE. 
       The originating endpoint node A reports Tunnel 1 and forward LSP1 and reverse LSP2 
       to the PCE. The endpoint (PCC) node D reports
       Tunnel 2 and LSP2 to the PCE.<a href="#section-3.1.2-2" class="pilcrow">¶</a></p>
</section>
</div>
</section>
</div>
<div id="sect-3.2">
<section id="section-3.2">
        <h3 id="name-double-sided-initiation">
<a href="#section-3.2" class="section-number selfRef">3.2. </a><a href="#name-double-sided-initiation" class="section-name selfRef">Double-Sided Initiation</a>
        </h3>
<p id="section-3.2-1">As specified in <span>[<a href="#RFC7551" class="xref">RFC7551</a>]</span>, in the double-sided case,
        the bidirectional tunnel is provisioned on both endpoint nodes (PCCs)
        of the tunnel. The forward and reverse LSPs of this tunnel are
        initiated with the Association Type set to "Double-Sided Bidirectional
        LSP Association" on both endpoint nodes. The forward and reverse LSPs
        are identified in the Bidirectional LSP Association Group TLV of their
        ASSOCIATION objects.<a href="#section-3.2-1" class="pilcrow">¶</a></p>
<p id="section-3.2-2">As specified in <span>[<a href="#RFC8537" class="xref">RFC8537</a>]</span>, for fast reroute bypass
        tunnel assignment, the LSP with the higher source address <span>[<a href="#RFC3209" class="xref">RFC3209</a>]</span> is identified as the forward LSP of the
        double-sided initiated bidirectional LSP.<a href="#section-3.2-2" class="pilcrow">¶</a></p>
<div id="sect-3.2.1">
<section id="section-3.2.1">
          <h4 id="name-pce-initiated-double-sided-">
<a href="#section-3.2.1" class="section-number selfRef">3.2.1. </a><a href="#name-pce-initiated-double-sided-" class="section-name selfRef">PCE-Initiated Double-Sided Bidirectional LSP</a>
          </h4>
<span id="name-example-of-pce-initiated-do"></span><div id="ure-example-of-pce-initiated-double-sided-bidirectional-lsp">
<figure id="figure-4">
            <div class="artwork art-text alignLeft" id="section-3.2.1-1.1">
<pre>
                            +-----+
                            | PCE |
                            +-----+
          Initiates:         |    \      Initiates:
          Tunnel 1 (F)       |     \     Tunnel 2 (F)
          (LSP1 (F, 0))      |      \    (LSP2 (F, 0))
          Association #3     v       v   Association #3
                          +-----+    +-----+
                          |  A  |    |  D  |
                          +-----+    +-----+


                            +-----+
                            | PCE |
                            +-----+
          Reports:           ^    ^      Reports:
          Tunnel 1 (F)       |     \     Tunnel 2 (F)
          (LSP1 (F, P4))     |      \    (LSP2 (F, P5))
          Association #3     |       \   Association #3
                          +-----+    +-----+
                          |  A  |    |  D  |
                          +-----+    +-----+

  Legend: F = Forward LSP, (0,P4,P5) = PLSP-IDs
</pre>
</div>
<figcaption><a href="#figure-4" class="selfRef">Figure 4</a>:
<a href="#name-example-of-pce-initiated-do" class="selfRef">Example of PCE-Initiated Double-Sided Bidirectional LSP</a>
            </figcaption></figure>
</div>
<p id="section-3.2.1-2">Using partial topology from <a href="#ure-example-of-associated-bidirectional-lsp" class="xref">Figure 1</a>, as shown in <a href="#ure-example-of-pce-initiated-double-sided-bidirectional-lsp" class="xref">Figure 4</a>, the forward Tunnel 1 and forward LSP1
        are initiated on the endpoint node A, and the reverse Tunnel 2 and
        reverse LSP2 are initiated on the endpoint node D by the PCE.
        The PLSP-IDs used are P4 on the endpoint node A
        and P5 on the endpoint node D.
        The endpoint node A (PCC) reports the forward LSP1, and endpoint node D reports the forward LSP2 to the PCE.<a href="#section-3.2.1-2" class="pilcrow">¶</a></p>
</section>
</div>
<div id="sect-3.2.2">
<section id="section-3.2.2">
          <h4 id="name-pcc-initiated-double-sided-">
<a href="#section-3.2.2" class="section-number selfRef">3.2.2. </a><a href="#name-pcc-initiated-double-sided-" class="section-name selfRef">PCC-Initiated Double-Sided Bidirectional LSP</a>
          </h4>
<span id="name-example-of-pcc-initiated-do"></span><div id="ure-example-of-pcc-initiated-double-sided-bidirectional-lsp">
<figure id="figure-5">
            <div class="artwork art-text alignLeft" id="section-3.2.2-1.1">
<pre>
                            +-----+
                            | PCE |
                            +-----+
        Reports/Delegates:   ^    ^      Reports/Delegates:
        Tunnel 1 (F)         |     \     Tunnel 2 (F)
        (LSP1 (F, P4))       |      \    (LSP2 (F, P5))
        Association #4       |       \   Association #4
                          +-----+    +-----+
                          |  A  |    |  D  |
                          +-----+    +-----+

  Legend: F = Forward LSP, (P4,P5) = PLSP-IDs
</pre>
</div>
<figcaption><a href="#figure-5" class="selfRef">Figure 5</a>:
<a href="#name-example-of-pcc-initiated-do" class="selfRef">Example of PCC-Initiated Double-Sided Bidirectional LSP</a>
            </figcaption></figure>
</div>
<p id="section-3.2.2-2">Using partial topology from <a href="#ure-example-of-associated-bidirectional-lsp" class="xref">Figure 1</a>, as shown in <a href="#ure-example-of-pcc-initiated-double-sided-bidirectional-lsp" class="xref">Figure 5</a>, the forward Tunnel 1 and forward LSP1
        are initiated on the endpoint node A, and the reverse Tunnel 2 and
        reverse LSP2 are initiated on the endpoint node D (the PCCs).
        The PLSP-IDs used are P4 on the endpoint node A and P5 on the endpoint node D.
        Both endpoint (PCC) nodes may delegate the forward LSP1 and LSP2 to the PCE.
        The endpoint node A (PCC) reports the forward LSP1, and endpoint node D reports the forward LSP2 to the PCE.<a href="#section-3.2.2-2" class="pilcrow">¶</a></p>
</section>
</div>
</section>
</div>
<div id="sect-3.3">
<section id="section-3.3">
        <h3 id="name-co-routed-associated-bidire">
<a href="#section-3.3" class="section-number selfRef">3.3. </a><a href="#name-co-routed-associated-bidire" class="section-name selfRef">Co-routed Associated Bidirectional LSP</a>
        </h3>
<p id="section-3.3-1">In both single-sided and double-sided initiation cases, forward and
        reverse LSPs can be co-routed as shown in <a href="#ure-example-of-co-routed-associated-bidirectional-lsp" class="xref">Figure 6</a>, where both forward
        and reverse LSPs of a bidirectional LSP follow the same congruent path
        in the forward and reverse directions, respectively.<a href="#section-3.3-1" class="pilcrow">¶</a></p>
<span id="name-example-of-co-routed-associ"></span><div id="ure-example-of-co-routed-associated-bidirectional-lsp">
<figure id="figure-6">
          <div class="artwork art-text alignLeft" id="section-3.3-2.1">
<pre>
            LSP3 --&gt;          LSP3 --&gt;          LSP3 --&gt;
   +-----+           +-----+           +-----+           +-----+
   |  A  +-----------+  B  +-----------+  C  +-----------+  D  |
   +-----+           +-----+           +-----+           +-----+
           &lt;-- LSP4          &lt;-- LSP4          &lt;-- LSP4
</pre>
</div>
<figcaption><a href="#figure-6" class="selfRef">Figure 6</a>:
<a href="#name-example-of-co-routed-associ" class="selfRef">Example of Co-routed Associated Bidirectional LSP</a>
          </figcaption></figure>
</div>
<p id="section-3.3-3">The procedure specified in <span>[<a href="#RFC8537" class="xref">RFC8537</a>]</span> for fast reroute bypass tunnel 
    assignment is also applicable to the co-routed associated bidirectional LSPs.<a href="#section-3.3-3" class="pilcrow">¶</a></p>
</section>
</div>
<div id="sect-3.4">
<section id="section-3.4">
        <h3 id="name-summary-of-pcep-extensions">
<a href="#section-3.4" class="section-number selfRef">3.4. </a><a href="#name-summary-of-pcep-extensions" class="section-name selfRef">Summary of PCEP Extensions</a>
        </h3>
<p id="section-3.4-1">
      The PCEP extensions defined in this document cover the following modes of 
      operation under the stateful PCE model:<a href="#section-3.4-1" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-3.4-2.1">A PCC initiates the forward and reverse LSP of a single-sided
          bidirectional LSP and retains control of the
          LSPs. Similarly, both PCCs initiate the forward LSPs of a 
          double-sided bidirectional LSP and retain control of the
          LSPs. The PCC computes the path itself or makes a request for path
          computation to a PCE. After the path setup, it reports the
          information and state of the path to the PCE. This includes the
          association group identifying the bidirectional LSP. This is the
          passive stateful mode defined in <span>[<a href="#RFC8051" class="xref">RFC8051</a>]</span>.<a href="#section-3.4-2.1" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-3.4-2.2">A PCC initiates the forward and reverse LSP of a single-sided
          bidirectional LSP and delegates control of the
          LSPs to a stateful PCE. Similarly, both PCCs initiate the forward LSPs of a 
          double-sided bidirectional LSP and delegate control of the
          LSPs to a stateful PCE. During delegation, the association group
          identifying the bidirectional LSP is included. The PCE computes the
          path of the LSP and updates the PCC with the information about the
          path as long as it controls the LSP. This is the active stateful
          mode defined in <span>[<a href="#RFC8051" class="xref">RFC8051</a>]</span>.<a href="#section-3.4-2.2" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-3.4-2.3">A PCE initiates the forward and reverse LSP of a single-sided
          bidirectional LSP on a PCC and retains control
          of the LSP. Similarly, a PCE initiates the forward LSPs of a 
          double-sided bidirectional LSP on both PCCs and retains control
          of the LSPs. The PCE is responsible for computing the path of the LSP
          and updating the PCC with the information about the path as well as
          the association group identifying the bidirectional LSP. This is the
          PCE-initiated mode defined in <span>[<a href="#RFC8281" class="xref">RFC8281</a>]</span>.<a href="#section-3.4-2.3" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-3.4-2.4">A PCC requests co-routed or non-co-routed paths for forward and
          reverse LSPs of a bidirectional LSP, including when using a stateless PCE <span>[<a href="#RFC5440" class="xref">RFC5440</a>]</span>.<a href="#section-3.4-2.4" class="pilcrow">¶</a>
</li>
        </ul>
</section>
</div>
<div id="sect-3.5">
<section id="section-3.5">
        <h3 id="name-operational-considerations">
<a href="#section-3.5" class="section-number selfRef">3.5. </a><a href="#name-operational-considerations" class="section-name selfRef">Operational Considerations</a>
        </h3>
<p id="section-3.5-1">
      The double-sided case has an advantage when compared to the single-sided 
      case, summarized as follows:<a href="#section-3.5-1" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-3.5-2.1">In the double-sided case, two existing unidirectional LSPs in reverse 
      directions in the network can be associated to form a bidirectional LSP without 
      significantly increasing the operational complexity.<a href="#section-3.5-2.1" class="pilcrow">¶</a>
</li>
        </ul>
<p id="section-3.5-3">The single-sided case has some advantages when compared to the double-sided case, summarized as follows:<a href="#section-3.5-3" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-3.5-4.1">Some Operations, Administration, and Maintenance (OAM) use cases 
       may require an endpoint node to know both forward and 
       reverse paths for monitoring the bidirectional LSP. For such use cases, the
       single-sided case may be preferred.<a href="#section-3.5-4.1" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-3.5-4.2">For co-routed associated bidirectional LSPs in PCC-initiated mode, 
       the single-sided case allows the originating PCC to dynamically compute 
       co-routed forward and reverse paths. This may not be possible with the double-sided 
       case where the forward and reverse paths are computed 
       separately as triggered by two different PCCs.<a href="#section-3.5-4.2" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-3.5-4.3">The associated bidirectional LSPs in the single-sided case can be deployed 
       in a network where PCEP is only enabled on the originating endpoint nodes as
       remote endpoint nodes create the reverse tunnels using RSVP-TE Path messages.<a href="#section-3.5-4.3" class="pilcrow">¶</a>
</li>
        </ul>
</section>
</div>
</section>
</div>
<div id="sect-4">
<section id="section-4">
      <h2 id="name-protocol-extensions">
<a href="#section-4" class="section-number selfRef">4. </a><a href="#name-protocol-extensions" class="section-name selfRef">Protocol Extensions</a>
      </h2>
<div id="sect-4.1">
<section id="section-4.1">
        <h3 id="name-association-object">
<a href="#section-4.1" class="section-number selfRef">4.1. </a><a href="#name-association-object" class="section-name selfRef">ASSOCIATION Object</a>
        </h3>
<p id="section-4.1-1">As per <span>[<a href="#RFC8697" class="xref">RFC8697</a>]</span>, LSPs are associated by adding them
        to a common association group. This document defines two new Association Types, called
        "Single-Sided Bidirectional LSP Association" (4) and "Double-Sided
        Bidirectional LSP Association" (5), using the generic ASSOCIATION
        object (Object-Class value 40).
        A member of the Bidirectional LSP Association
        can take the role of a forward or reverse LSP and follows the following rules:<a href="#section-4.1-1" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-4.1-2.1">An LSP (forward or reverse) <span class="bcp14">MUST NOT</span> be part of more than one
         Bidirectional LSP Association.<a href="#section-4.1-2.1" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-4.1-2.2">The LSPs in a Bidirectional LSP Association <span class="bcp14">MUST</span> have matching endpoint 
         nodes in the reverse directions.<a href="#section-4.1-2.2" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-4.1-2.3">The same tunnel (as defined in <span><a href="https://www.rfc-editor.org/rfc/rfc3209#section-2.1" class="relref">Section 2.1</a> of [<a href="#RFC3209" class="xref">RFC3209</a>]</span>) <span class="bcp14">MUST</span> contain the
          forward and reverse LSPs of the Single-Sided Bidirectional LSP
          Association on the originating node, albeit both LSPs have reversed
          endpoint nodes.<a href="#section-4.1-2.3" class="pilcrow">¶</a>
</li>
        </ul>
<p id="section-4.1-3">The Bidirectional LSP Association Types are considered to be both dynamic and 
        operator configured in nature.  As per <span>[<a href="#RFC8697" class="xref">RFC8697</a>]</span>, the association group could
        be manually created by the operator on the PCEP peers, and the LSPs
        belonging to this association are conveyed via PCEP messages to the
        PCEP peer; alternately, the association group could be created
        dynamically by the PCEP speaker, and both the association group
        information and the LSPs belonging to the association group are
        conveyed to the PCEP peer.  The operator-configured Association Range
        <span class="bcp14">MUST</span> be set for this Association Type to mark a range of Association
        Identifiers that are used for operator-configured associations to
        avoid any Association Identifier clash within the scope of the
        Association Source (refer to <span>[<a href="#RFC8697" class="xref">RFC8697</a>]</span>).<a href="#section-4.1-3" class="pilcrow">¶</a></p>
<p id="section-4.1-4">Specifically, for the PCE-initiated bidirectional LSPs, these associations 
        are dynamically created by the PCE on the PCE peers. Similarly, 
        for both the PCE-initiated and the PCC-initiated single-sided cases, 
        these associations are also dynamically created on the 
        remote endpoint node using the information 
        received from the RSVP message from the originating node.<a href="#section-4.1-4" class="pilcrow">¶</a></p>
<p id="section-4.1-5">The Association ID, Association Source, optional Global Association
        Source TLV, and optional Extended Association ID TLV in the Bidirectional LSP
        ASSOCIATION object are initialized using the procedures defined
        in <span>[<a href="#RFC8697" class="xref">RFC8697</a>]</span> and <span>[<a href="#RFC7551" class="xref">RFC7551</a>]</span>.<a href="#section-4.1-5" class="pilcrow">¶</a></p>
<p id="section-4.1-6"><span>[<a href="#RFC8697" class="xref">RFC8697</a>]</span> specifies the mechanism for the capability advertisement of
        the Association Types supported by a PCEP speaker by defining an
        ASSOC-Type-List TLV to be carried within an OPEN object.  This
        capability exchange for the Bidirectional LSP Association Types <span class="bcp14">MUST</span> be
        done before using the Bidirectional LSP Association.  Thus, the PCEP
        speaker <span class="bcp14">MUST</span> include the Bidirectional LSP Association Types in the
        ASSOC-Type-List TLV and <span class="bcp14">MUST</span> receive the same from the PCEP peer
        before using the Bidirectional LSP Association in PCEP messages.<a href="#section-4.1-6" class="pilcrow">¶</a></p>
</section>
</div>
<div id="sect-4.2">
<section id="section-4.2">
        <h3 id="name-bidirectional-lsp-associati">
<a href="#section-4.2" class="section-number selfRef">4.2. </a><a href="#name-bidirectional-lsp-associati" class="section-name selfRef">Bidirectional LSP Association Group TLV</a>
        </h3>
<p id="section-4.2-1">The Bidirectional LSP Association Group TLV is an <span class="bcp14">OPTIONAL</span> TLV for use with
        Bidirectional LSP Associations (ASSOCIATION object with Association
        Type 4 for Single-Sided Bidirectional LSP Association or 5 for Double-Sided Bidirectional LSP Association).<a href="#section-4.2-1" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-4.2-2.1">The Bidirectional LSP Association Group TLV follows the PCEP
            TLV format from <span>[<a href="#RFC5440" class="xref">RFC5440</a>]</span>.<a href="#section-4.2-2.1" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-4.2-2.2">The Type (16 bits) of the TLV is 54.<a href="#section-4.2-2.2" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-4.2-2.3">The Length is 4 bytes.<a href="#section-4.2-2.3" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-4.2-2.4">The value comprises of a single field, the 
            Flags field (32 bits), where each bit represents a flag
            option.<a href="#section-4.2-2.4" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-4.2-2.5">If the Bidirectional LSP Association Group TLV is missing, it
            means the LSP is the forward LSP, and it is not a co-routed LSP.<a href="#section-4.2-2.5" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-4.2-2.6">When the Bidirectional LSP Association Group TLV is present, the R 
            flag <span class="bcp14">MUST</span> be reset for the forward LSP for both co-routed and non-co-routed LSPs.<a href="#section-4.2-2.6" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-4.2-2.7">For co-routed LSPs, this TLV <span class="bcp14">MUST</span> be present and the C flag set.<a href="#section-4.2-2.7" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-4.2-2.8">For reverse LSPs, this TLV <span class="bcp14">MUST</span> be present and the R flag set.<a href="#section-4.2-2.8" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-4.2-2.9">The Bidirectional LSP Association Group TLV <span class="bcp14">MUST NOT</span> be present
            more than once. If it appears more than once, only the first
            occurrence is processed, and any others <span class="bcp14">MUST</span> be ignored.<a href="#section-4.2-2.9" class="pilcrow">¶</a>
</li>
        </ul>
<p id="section-4.2-3">The format of the Bidirectional LSP Association Group TLV is shown
        in <a href="#ure-bidirectional-lsp-association-group-tlv-format" class="xref">Figure 7</a>.<a href="#section-4.2-3" class="pilcrow">¶</a></p>
<span id="name-bidirectional-lsp-associatio"></span><div id="ure-bidirectional-lsp-association-group-tlv-format">
<figure id="figure-7">
          <div class="artwork art-text alignLeft" id="section-4.2-4.1">
<pre>
  0                   1                   2                   3
  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |         Type = 54             |             Length            |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                       Flags                               |C|R|
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</pre>
</div>
<figcaption><a href="#figure-7" class="selfRef">Figure 7</a>:
<a href="#name-bidirectional-lsp-associatio" class="selfRef">Bidirectional LSP Association Group TLV Format</a>
          </figcaption></figure>
</div>
<p id="section-4.2-5">Flags for the Bidirectional LSP Association Group TLV are defined as follows.<a href="#section-4.2-5" class="pilcrow">¶</a></p>
<span class="break"></span><dl class="dlParallel" id="section-4.2-6">
          <dt id="section-4.2-6.1">R (Reverse LSP, 1 bit, bit number 31):</dt>
          <dd style="margin-left: 1.5em" id="section-4.2-6.2">Indicates whether the LSP associated is
        the reverse LSP of the bidirectional LSP. If this flag is set, the LSP
        is a reverse LSP. If this flag is not set, the LSP is a forward LSP.<a href="#section-4.2-6.2" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-4.2-6.3">C (Co-routed Path, 1 bit, bit number 30):</dt>
          <dd style="margin-left: 1.5em" id="section-4.2-6.4">Indicates whether the bidirectional LSP
        is co-routed. This flag <span class="bcp14">MUST</span> be set for both the forward and reverse
        LSPs of a co-routed bidirectional LSP.<a href="#section-4.2-6.4" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
</dl>
<p id="section-4.2-7">The C flag is used by the PCE (both stateful and stateless) to
        compute bidirectional paths of the forward and reverse LSPs of a
        co-routed bidirectional LSP.<a href="#section-4.2-7" class="pilcrow">¶</a></p>
<p id="section-4.2-8">The unassigned flags (bit numbers 0-29) <span class="bcp14">MUST</span> be set to 0 when sent and <span class="bcp14">MUST</span> be ignored
        when received.<a href="#section-4.2-8" class="pilcrow">¶</a></p>
</section>
</div>
</section>
</div>
<div id="sect-5">
<section id="section-5">
      <h2 id="name-pcep-procedure">
<a href="#section-5" class="section-number selfRef">5. </a><a href="#name-pcep-procedure" class="section-name selfRef">PCEP Procedure</a>
      </h2>
<p id="section-5-1">The PCEP procedure defined in this document is applicable to the following three scenarios:<a href="#section-5-1" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-5-2.1">Neither unidirectional LSP exists, and both must be established.<a href="#section-5-2.1" class="pilcrow">¶</a>
</li>
        <li class="normal" id="section-5-2.2">Both unidirectional LSPs exist, but the association must be established.<a href="#section-5-2.2" class="pilcrow">¶</a>
</li>
        <li class="normal" id="section-5-2.3">One LSP exists, but the reverse associated LSP must be established.<a href="#section-5-2.3" class="pilcrow">¶</a>
</li>
      </ul>
<div id="sect-5.1">
<section id="section-5.1">
        <h3 id="name-pce-initiated-lsps">
<a href="#section-5.1" class="section-number selfRef">5.1. </a><a href="#name-pce-initiated-lsps" class="section-name selfRef">PCE-Initiated LSPs</a>
        </h3>
<p id="section-5.1-1">As specified in <span>[<a href="#RFC8697" class="xref">RFC8697</a>]</span>, Bidirectional LSP
        Associations can be created and updated by a stateful PCE.<a href="#section-5.1-1" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-5.1-2.1">For a Single-Sided Bidirectional LSP Association initiated by the PCE, 
        the PCE <span class="bcp14">MUST</span> send a PCInitiate message to the originating endpoint node with both forward and reverse LSPs. For a Double-Sided Bidirectional LSP Association 
        initiated by the PCE, it <span class="bcp14">MUST</span> send a PCInitiate message to both 
        endpoint nodes with forward LSPs.<a href="#section-5.1-2.1" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-5.1-2.2">Both PCCs <span class="bcp14">MUST</span> report the forward and reverse LSPs in the 
            Bidirectional LSP Association to the PCE. A PCC reports via a PCRpt message.<a href="#section-5.1-2.2" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-5.1-2.3">Stateful PCEs <span class="bcp14">MAY</span> create and update the forward and reverse LSPs
            independently for the Single-Sided Bidirectional
            LSP Association on the originating endpoint node.<a href="#section-5.1-2.3" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-5.1-2.4">Stateful PCEs <span class="bcp14">MAY</span> create and update the forward LSP
            independently for the Double-Sided Bidirectional
            LSP Association on the endpoint nodes.<a href="#section-5.1-2.4" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-5.1-2.5">Stateful PCEs establish and remove the association
            relationship on a per-LSP basis.<a href="#section-5.1-2.5" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-5.1-2.6">Stateful PCEs create and update the LSP and the association
            on PCCs via PCInitiate and PCUpd messages, respectively, using
            the procedures described in <span>[<a href="#RFC8697" class="xref">RFC8697</a>]</span>.<a href="#section-5.1-2.6" class="pilcrow">¶</a>
</li>
        </ul>
</section>
</div>
<div id="sect-5.2">
<section id="section-5.2">
        <h3 id="name-pcc-initiated-lsps">
<a href="#section-5.2" class="section-number selfRef">5.2. </a><a href="#name-pcc-initiated-lsps" class="section-name selfRef">PCC-Initiated LSPs</a>
        </h3>
<p id="section-5.2-1">As specified in <span>[<a href="#RFC8697" class="xref">RFC8697</a>]</span>, Bidirectional LSP
        Associations can also be created and updated by a PCC.<a href="#section-5.2-1" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-5.2-2.1">For a Single-Sided Bidirectional LSP Association initiated at a PCC, 
        the PCC <span class="bcp14">MUST</span> send a PCRpt message to the PCE with both forward and reverse LSPs. 
        For a Double-Sided Bidirectional LSP Association initiated at the PCCs, 
        both PCCs <span class="bcp14">MUST</span> send a PCRpt message to the PCE with forward LSPs.<a href="#section-5.2-2.1" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-5.2-2.2">PCCs on the originating endpoint node <span class="bcp14">MAY</span> create and update the forward and reverse LSPs
            independently for the Single-Sided Bidirectional LSP Association.<a href="#section-5.2-2.2" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-5.2-2.3">PCCs on the endpoint nodes <span class="bcp14">MAY</span> create and update the forward LSP
            independently for the Double-Sided Bidirectional LSP Association.<a href="#section-5.2-2.3" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-5.2-2.4">PCCs establish and remove the association group on a
            per-LSP basis. PCCs <span class="bcp14">MUST</span> report the change in the association group of an LSP
            to PCE(s) via a PCRpt message.<a href="#section-5.2-2.4" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-5.2-2.5">PCCs report the forward and reverse LSPs in the Bidirectional LSP Association independently to
            PCE(s) via a PCRpt message.<a href="#section-5.2-2.5" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-5.2-2.6">PCCs for the single-sided case <span class="bcp14">MAY</span> delegate the forward and reverse LSPs independently to
            a stateful PCE, where the PCE would control the LSPs. In this case,
            the originating (PCC) endpoint node <span class="bcp14">SHOULD</span> delegate both forward and reverse
            LSPs of a tunnel together to a stateful PCE in order to avoid any race condition.<a href="#section-5.2-2.6" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-5.2-2.7">PCCs for the double-sided case <span class="bcp14">MAY</span> delegate the forward LSPs to
            a stateful PCE, where the PCE would control the LSPs.<a href="#section-5.2-2.7" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-5.2-2.8">A stateful PCE updates the LSPs in the Bidirectional LSP
            Association via a PCUpd message, using the procedures
            described in <span>[<a href="#RFC8697" class="xref">RFC8697</a>]</span>.<a href="#section-5.2-2.8" class="pilcrow">¶</a>
</li>
        </ul>
</section>
</div>
<div id="sect-5.3">
<section id="section-5.3">
        <h3 id="name-stateless-pce">
<a href="#section-5.3" class="section-number selfRef">5.3. </a><a href="#name-stateless-pce" class="section-name selfRef">Stateless PCE</a>
        </h3>
<p id="section-5.3-1">For a stateless PCE, it might be useful to associate a path computation request to an association group, thus enabling it to
        associate a common set of configuration parameters or behaviors with
        the request <span>[<a href="#RFC8697" class="xref">RFC8697</a>]</span>. A PCC can request co-routed or non-co-routed forward and
        reverse paths from a stateless PCE for a Bidirectional LSP Association.<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-bidirectional-b-flag">
<a href="#section-5.4" class="section-number selfRef">5.4. </a><a href="#name-bidirectional-b-flag" class="section-name selfRef">Bidirectional (B) Flag</a>
        </h3>
<p id="section-5.4-1">As defined in <span>[<a href="#RFC5440" class="xref">RFC5440</a>]</span>, the Bidirectional (B) flag
        in the Request Parameters (RP) object is set when the PCC specifies
        that the path computation request is for a bidirectional TE LSP with the 
        same TE requirements in each direction. For an
        associated bidirectional LSP, the B flag is also set when the PCC makes
        the path computation request for the same TE requirements for the
        forward and reverse LSPs.<a href="#section-5.4-1" class="pilcrow">¶</a></p>
<p id="section-5.4-2">Note that the B flag defined in a Stateful PCE Request Parameter (SRP)
        object <span>[<a href="#I-D.ietf-pce-pcep-stateful-pce-gmpls" class="xref">STATEFUL-PCE-GMPLS</a>]</span> to 
        indicate "bidirectional co-routed LSP" is used for GMPLS-signaled bidirectional LSPs 
        and is not applicable to the associated bidirectional LSPs.<a href="#section-5.4-2" class="pilcrow">¶</a></p>
</section>
</div>
<div id="sect-5.5">
<section id="section-5.5">
        <h3 id="name-plsp-id-usage">
<a href="#section-5.5" class="section-number selfRef">5.5. </a><a href="#name-plsp-id-usage" class="section-name selfRef">PLSP-ID Usage</a>
        </h3>
<p id="section-5.5-1">As defined in <span>[<a href="#RFC8231" class="xref">RFC8231</a>]</span>, a PCEP-specific LSP
        Identifier (PLSP-ID) is created by a PCC to uniquely identify an LSP,
        and it remains the same for the lifetime of a PCEP session.<a href="#section-5.5-1" class="pilcrow">¶</a></p>
<p id="section-5.5-2">In the case of a Single-Sided Bidirectional LSP Association, the reverse
        LSP of a bidirectional LSP created on the originating endpoint node is
        identified by the PCE using two different PLSP-IDs, based on the PCEP
        session on the ingress or egress node PCCs for the LSP. In other words,
        the LSP will have a PLSP-ID P2 allocated at the
        ingress node PCC, while it will have a PLSP-ID P3 allocated at the egress node PCC 
        (as shown in Figures <a href="#ure-example-of-pce-initiated-single-sided-bidirectional-lsp" class="xref">2</a> and <a href="#ure-example-of-pcc-initiated-single-sided-bidirectional-lsp" class="xref">3</a>).  There is no change in the PLSP-ID
        allocation procedure for the forward LSP of a single-sided
 bidirectional LSP created on the originating endpoint node.<a href="#section-5.5-2" class="pilcrow">¶</a></p>
<p id="section-5.5-3">In the case of a Double-Sided Bidirectional LSP
        Association, there is no change in the PLSP-ID allocation
        procedure for the forward LSPs on either PCC.<a href="#section-5.5-3" class="pilcrow">¶</a></p>
<p id="section-5.5-4">For an associated bidirectional LSP, the LSP-IDENTIFIERS TLV <span>[<a href="#RFC8231" class="xref">RFC8231</a>]</span> <span class="bcp14">MUST</span> be included in all forward and reverse
        LSPs.<a href="#section-5.5-4" class="pilcrow">¶</a></p>
</section>
</div>
<div id="sect-5.6">
<section id="section-5.6">
        <h3 id="name-state-synchronization">
<a href="#section-5.6" class="section-number selfRef">5.6. </a><a href="#name-state-synchronization" class="section-name selfRef">State Synchronization</a>
        </h3>
<p id="section-5.6-1">During state synchronization, a PCC <span class="bcp14">MUST</span> report all the existing
        Bidirectional LSP Associations to the stateful PCE, as per <span>[<a href="#RFC8697" class="xref">RFC8697</a>]</span>.  After the state synchronization, the PCE <span class="bcp14">MUST</span> 
        remove all previous
        Bidirectional LSP Associations absent in the report.<a href="#section-5.6-1" class="pilcrow">¶</a></p>
</section>
</div>
<div id="sect-5.7">
<section id="section-5.7">
        <h3 id="name-error-handling">
<a href="#section-5.7" class="section-number selfRef">5.7. </a><a href="#name-error-handling" class="section-name selfRef">Error Handling</a>
        </h3>
<p id="section-5.7-1">If a PCE speaker receives an LSP with a 
        Bidirectional LSP Association Type that it does not support, 
        the PCE speaker <span class="bcp14">MUST</span> send PCErr with Error-Type =
        26 (Association Error) and Error-value = 1 (Association Type
        is not supported).<a href="#section-5.7-1" class="pilcrow">¶</a></p>
<p id="section-5.7-2">An LSP (forward or reverse) cannot be part of more than one
        Bidirectional LSP Association. If a PCE speaker receives an LSP
        not complying to this rule, the PCE speaker <span class="bcp14">MUST</span> send PCErr with Error-Type =
        26 (Association Error) and Error-value = 14 (Association group mismatch).<a href="#section-5.7-2" class="pilcrow">¶</a></p>
<p id="section-5.7-3">The LSPs (forward or reverse) in a Single-Sided Bidirectional
        Association <span class="bcp14">MUST</span> belong to the same TE tunnel (as defined in
        <span>[<a href="#RFC3209" class="xref">RFC3209</a>]</span>). If a PCE speaker attempts to add an LSP in a
        Single-Sided Bidirectional LSP Association for a different
        tunnel, the PCE speaker <span class="bcp14">MUST</span> send PCErr with Error-Type = 26 (Association
        Error) and Error-value = 15 (Tunnel mismatch in the association group).<a href="#section-5.7-3" class="pilcrow">¶</a></p>
<p id="section-5.7-4">The PCEP Path Setup Type (PST) for RSVP-TE is set to
        "Path is set up using the RSVP-TE signaling protocol" (Value 0) 
        <span>[<a href="#RFC8408" class="xref">RFC8408</a>]</span>. If a PCEP speaker receives a
        different PST value for the Bidirectional LSP Associations 
        defined in this document, the PCE speaker <span class="bcp14">MUST</span> return a PCErr message with Error-Type =
        26 (Association Error) and Error-value = 16 (Path Setup Type not supported).<a href="#section-5.7-4" class="pilcrow">¶</a></p>
<p id="section-5.7-5">A Bidirectional LSP Association cannot have both unidirectional 
        LSPs identified as reverse LSPs or both LSPs
        identified as forward LSPs. If a PCE speaker receives an LSP
        not complying to this rule, the PCE speaker <span class="bcp14">MUST</span> send PCErr with Error-Type =
        26 (Association Error) and Error-value = 17 (Bidirectional LSP direction mismatch).<a href="#section-5.7-5" class="pilcrow">¶</a></p>
<p id="section-5.7-6">A Bidirectional LSP Association cannot have one unidirectional 
        LSP identified as co-routed and the other identified as non-co-routed. If a PCE speaker receives an LSP
        not complying to this rule, the PCE speaker <span class="bcp14">MUST</span> send PCErr with Error-Type =
        26 (Association Error) and Error-value = 18 (Bidirectional LSP co-routed mismatch).<a href="#section-5.7-6" class="pilcrow">¶</a></p>
<p id="section-5.7-7">The unidirectional LSPs forming the Bidirectional
        LSP Association <span class="bcp14">MUST</span> have matching endpoint nodes in the reverse directions. 
        If a PCE speaker receives an LSP
        not complying to this rule, the PCE speaker <span class="bcp14">MUST</span> send PCErr with Error-Type =
        26 (Association Error) and Error-value = 19 (Endpoint mismatch in the association group).<a href="#section-5.7-7" class="pilcrow">¶</a></p>
<p id="section-5.7-8">The processing rules as specified in <span><a href="https://www.rfc-editor.org/rfc/rfc8697#section-6.4" class="relref">Section 6.4</a> of [<a href="#RFC8697" class="xref">RFC8697</a>]</span> continue to apply to the Association Types defined
        in this document.<a href="#section-5.7-8" class="pilcrow">¶</a></p>
</section>
</div>
</section>
</div>
<div id="sect-7">
<section id="section-6">
      <h2 id="name-security-considerations">
<a href="#section-6" class="section-number selfRef">6. </a><a href="#name-security-considerations" class="section-name selfRef">Security Considerations</a>
      </h2>
<p id="section-6-1">The security considerations described in <span>[<a href="#RFC5440" class="xref">RFC5440</a>]</span>,
      <span>[<a href="#RFC8231" class="xref">RFC8231</a>]</span>, and <span>[<a href="#RFC8281" class="xref">RFC8281</a>]</span> apply to the
      extensions defined in this document as well.<a href="#section-6-1" class="pilcrow">¶</a></p>
<p id="section-6-2">Two new Association Types for the ASSOCIATION object, Single-Sided
      Bidirectional LSP Association and Double-Sided Bidirectional LSP
      Association, are introduced in this document. Additional security
      considerations related to LSP associations due to a malicious PCEP
      speaker are described in <span>[<a href="#RFC8697" class="xref">RFC8697</a>]</span> and apply to these
      Association Types. Hence, securing the PCEP session using Transport
      Layer Security (TLS) <span>[<a href="#RFC8253" class="xref">RFC8253</a>]</span> is <span class="bcp14">RECOMMENDED</span>.<a href="#section-6-2" class="pilcrow">¶</a></p>
</section>
</div>
<div id="sect-8">
<section id="section-7">
      <h2 id="name-manageability-consideration">
<a href="#section-7" class="section-number selfRef">7. </a><a href="#name-manageability-consideration" class="section-name selfRef">Manageability Considerations</a>
      </h2>
<div id="sect-8.1">
<section id="section-7.1">
        <h3 id="name-control-of-function-and-pol">
<a href="#section-7.1" class="section-number selfRef">7.1. </a><a href="#name-control-of-function-and-pol" class="section-name selfRef">Control of Function and Policy</a>
        </h3>
<p id="section-7.1-1">The mechanisms defined in this document do not imply any control or
        policy requirements in addition to those already listed in <span>[<a href="#RFC5440" class="xref">RFC5440</a>]</span>, <span>[<a href="#RFC8231" class="xref">RFC8231</a>]</span>, and <span>[<a href="#RFC8281" class="xref">RFC8281</a>]</span>.<a href="#section-7.1-1" class="pilcrow">¶</a></p>
</section>
</div>
<div id="sect-8.2">
<section id="section-7.2">
        <h3 id="name-information-and-data-models">
<a href="#section-7.2" class="section-number selfRef">7.2. </a><a href="#name-information-and-data-models" class="section-name selfRef">Information and Data Models</a>
        </h3>
<p id="section-7.2-1"><span>[<a href="#RFC7420" class="xref">RFC7420</a>]</span> describes the PCEP MIB; there are no new
        MIB objects defined for LSP associations.<a href="#section-7.2-1" class="pilcrow">¶</a></p>
<p id="section-7.2-2">The PCEP YANG module <span>[<a href="#I-D.ietf-pce-pcep-yang" class="xref">PCE-PCEP-YANG</a>]</span>
        defines a data model for LSP associations.<a href="#section-7.2-2" class="pilcrow">¶</a></p>
</section>
</div>
<div id="sect-8.3">
<section id="section-7.3">
        <h3 id="name-liveness-detection-and-moni">
<a href="#section-7.3" class="section-number selfRef">7.3. </a><a href="#name-liveness-detection-and-moni" class="section-name selfRef">Liveness Detection and Monitoring</a>
        </h3>
<p id="section-7.3-1">The mechanisms defined in this document do not imply any new
        liveness detection and monitoring requirements in addition to those
        already listed in <span>[<a href="#RFC5440" class="xref">RFC5440</a>]</span>, <span>[<a href="#RFC8231" class="xref">RFC8231</a>]</span>,
        and <span>[<a href="#RFC8281" class="xref">RFC8281</a>]</span>.<a href="#section-7.3-1" class="pilcrow">¶</a></p>
</section>
</div>
<div id="sect-8.4">
<section id="section-7.4">
        <h3 id="name-verify-correct-operations">
<a href="#section-7.4" class="section-number selfRef">7.4. </a><a href="#name-verify-correct-operations" class="section-name selfRef">Verify Correct Operations</a>
        </h3>
<p id="section-7.4-1">The 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>, <span>[<a href="#RFC8231" class="xref">RFC8231</a>]</span>, and
        <span>[<a href="#RFC8281" class="xref">RFC8281</a>]</span>.<a href="#section-7.4-1" class="pilcrow">¶</a></p>
</section>
</div>
<div id="sect-8.5">
<section id="section-7.5">
        <h3 id="name-requirements-on-other-proto">
<a href="#section-7.5" class="section-number selfRef">7.5. </a><a href="#name-requirements-on-other-proto" class="section-name selfRef">Requirements on Other Protocols</a>
        </h3>
<p id="section-7.5-1">The mechanisms defined in this document do not add any new
        requirements on other protocols.<a href="#section-7.5-1" class="pilcrow">¶</a></p>
</section>
</div>
<div id="sect-8.6">
<section id="section-7.6">
        <h3 id="name-impact-on-network-operation">
<a href="#section-7.6" class="section-number selfRef">7.6. </a><a href="#name-impact-on-network-operation" class="section-name selfRef">Impact on Network Operations</a>
        </h3>
<p id="section-7.6-1">The mechanisms defined in this document do not have any impact on
        network operations in addition to those already listed in <span>[<a href="#RFC5440" class="xref">RFC5440</a>]</span>, <span>[<a href="#RFC8231" class="xref">RFC8231</a>]</span>, and <span>[<a href="#RFC8281" class="xref">RFC8281</a>]</span>.<a href="#section-7.6-1" class="pilcrow">¶</a></p>
</section>
</div>
</section>
</div>
<div id="sect-9">
<section id="section-8">
      <h2 id="name-iana-considerations">
<a href="#section-8" class="section-number selfRef">8. </a><a href="#name-iana-considerations" class="section-name selfRef">IANA Considerations</a>
      </h2>
<div id="sect-9.1">
<section id="section-8.1">
        <h3 id="name-association-types">
<a href="#section-8.1" class="section-number selfRef">8.1. </a><a href="#name-association-types" class="section-name selfRef">Association Types</a>
        </h3>
<p id="section-8.1-1">This document defines two new Association Types
    <span>[<a href="#RFC8697" class="xref">RFC8697</a>]</span>.  IANA has assigned the following new values in the
    "ASSOCIATION Type Field" subregistry <span>[<a href="#RFC8697" class="xref">RFC8697</a>]</span> within the "Path
    Computation Element Protocol (PCEP) Numbers" registry:<a href="#section-8.1-1" class="pilcrow">¶</a></p>
<span id="name-additions-to-association-ty"></span><div id="assoc-types">
<table class="center" id="table-1">
          <caption>
<a href="#table-1" class="selfRef">Table 1</a>:
<a href="#name-additions-to-association-ty" class="selfRef">Additions to ASSOCIATION Type Field Subregistry</a>
          </caption>
<thead>
            <tr>
              <th class="text-left" rowspan="1" colspan="1">Type</th>
              <th class="text-left" rowspan="1" colspan="1">Name</th>
              <th class="text-left" rowspan="1" colspan="1">Reference</th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">4</td>
              <td class="text-left" rowspan="1" colspan="1">Single-Sided Bidirectional LSP Association</td>
              <td class="text-left" rowspan="1" colspan="1">RFC 9059</td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">5</td>
              <td class="text-left" rowspan="1" colspan="1">Double-Sided Bidirectional LSP Association</td>
              <td class="text-left" rowspan="1" colspan="1">RFC 9059</td>
            </tr>
          </tbody>
        </table>
</div>
</section>
</div>
<div id="sect-9.2">
<section id="section-8.2">
        <h3 id="name-bidirectional-lsp-association">
<a href="#section-8.2" class="section-number selfRef">8.2. </a><a href="#name-bidirectional-lsp-association" class="section-name selfRef">Bidirectional LSP Association Group TLV</a>
        </h3>
<p id="section-8.2-1">This document defines a new TLV for carrying additional information
        about LSPs within a Bidirectional LSP Association. IANA has
        assigned the following value in the "PCEP
        TLV Type Indicators" subregistry within the "Path Computation Element Protocol (PCEP) Numbers" registry:<a href="#section-8.2-1" class="pilcrow">¶</a></p>
<span id="name-addition-to-pcep-tlv-type-i"></span><div id="new-tlv">
<table class="center" id="table-2">
          <caption>
<a href="#table-2" class="selfRef">Table 2</a>:
<a href="#name-addition-to-pcep-tlv-type-i" class="selfRef">Addition to PCEP TLV Type Indicators Subregistry</a>
          </caption>
<thead>
            <tr>
              <th class="text-left" rowspan="1" colspan="1">Value</th>
              <th class="text-left" rowspan="1" colspan="1">Meaning</th>
              <th class="text-left" rowspan="1" colspan="1">Reference</th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">54</td>
              <td class="text-left" rowspan="1" colspan="1">Bidirectional LSP Association Group TLV</td>
              <td class="text-left" rowspan="1" colspan="1">RFC 9059</td>
            </tr>
          </tbody>
        </table>
</div>
<div id="sect-9.2.1">
<section id="section-8.2.1">
          <h4 id="name-flag-field-in-bidirectional">
<a href="#section-8.2.1" class="section-number selfRef">8.2.1. </a><a href="#name-flag-field-in-bidirectional" class="section-name selfRef">Flag Field in Bidirectional LSP Association Group TLV</a>
          </h4>
<p id="section-8.2.1-1">IANA has created a new subregistry, named
          "Bidirectional LSP Association Group TLV Flag Field",
          within the "Path Computation Element Protocol (PCEP) Numbers"
          registry to manage the Flag field in the Bidirectional LSP
          Association Group TLV. New values are assigned by Standards
          Action <span>[<a href="#RFC8126" class="xref">RFC8126</a>]</span>. Each bit should be tracked with the
          following qualities:<a href="#section-8.2.1-1" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-8.2.1-2.1">Bit number (count from 0 as the most significant bit)<a href="#section-8.2.1-2.1" class="pilcrow">¶</a>
</li>
            <li class="normal" id="section-8.2.1-2.2">Description<a href="#section-8.2.1-2.2" class="pilcrow">¶</a>
</li>
            <li class="normal" id="section-8.2.1-2.3">Reference<a href="#section-8.2.1-2.3" class="pilcrow">¶</a>
</li>
          </ul>
<p id="section-8.2.1-3">The initial contents of this registry are as follows:<a href="#section-8.2.1-3" class="pilcrow">¶</a></p>
<span id="name-new-bidirectional-lsp-assoc"></span><div id="flag-field">
<table class="center" id="table-3">
            <caption>
<a href="#table-3" class="selfRef">Table 3</a>:
<a href="#name-new-bidirectional-lsp-assoc" class="selfRef">New Bidirectional LSP Association Group TLV Flag Field Subregistry</a>
            </caption>
<thead>
              <tr>
                <th class="text-left" rowspan="1" colspan="1">Bit</th>
                <th class="text-left" rowspan="1" colspan="1">Description</th>
                <th class="text-left" rowspan="1" colspan="1">Reference</th>
              </tr>
            </thead>
            <tbody>
              <tr>
                <td class="text-left" rowspan="1" colspan="1">0-29</td>
                <td class="text-left" rowspan="1" colspan="1">Unassigned</td>
                <td class="text-left" rowspan="1" colspan="1"></td>
              </tr>
              <tr>
                <td class="text-left" rowspan="1" colspan="1">30</td>
                <td class="text-left" rowspan="1" colspan="1">C - Co-routed Path</td>
                <td class="text-left" rowspan="1" colspan="1">RFC 9059</td>
              </tr>
              <tr>
                <td class="text-left" rowspan="1" colspan="1">31</td>
                <td class="text-left" rowspan="1" colspan="1">R - Reverse LSP</td>
                <td class="text-left" rowspan="1" colspan="1">RFC 9059</td>
              </tr>
            </tbody>
          </table>
</div>
</section>
</div>
</section>
</div>
<div id="sect-9.3">
<section id="section-8.3">
        <h3 id="name-pcep-errors">
<a href="#section-8.3" class="section-number selfRef">8.3. </a><a href="#name-pcep-errors" class="section-name selfRef">PCEP Errors</a>
        </h3>
<p id="section-8.3-1">This document defines new Error-values for Error-Type 26
        (Association Error). IANA has allocated the following new Error-values
        within the "PCEP-ERROR Object Error Types and Values" subregistry of
        the "Path Computation Element Protocol (PCEP) Numbers" registry:<a href="#section-8.3-1" class="pilcrow">¶</a></p>
<span id="name-additions-to-pcep-error-obj"></span><div id="error-value">
<table class="center" id="table-4">
          <caption>
<a href="#table-4" class="selfRef">Table 4</a>:
<a href="#name-additions-to-pcep-error-obj" class="selfRef">Additions to PCEP-ERROR Object Error Types and Values Subregistry</a>
          </caption>
<thead>
            <tr>
              <th class="text-left" rowspan="1" colspan="1">Error-Type</th>
              <th class="text-left" rowspan="1" colspan="1">Meaning</th>
              <th class="text-left" rowspan="1" colspan="1">Error-value</th>
              <th class="text-left" rowspan="1" colspan="1">Reference</th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td class="text-left" rowspan="6" colspan="1">26</td>
              <td class="text-left" rowspan="6" colspan="1">Association Error</td>
              <td class="text-left" rowspan="1" colspan="1">14: Association group mismatch</td>
              <td class="text-left" rowspan="1" colspan="1">RFC 9059</td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">15: Tunnel mismatch in the association group</td>
              <td class="text-left" rowspan="1" colspan="1">RFC 9059</td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">16: Path Setup Type not supported</td>
              <td class="text-left" rowspan="1" colspan="1">RFC 9059</td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">17: Bidirectional LSP direction mismatch</td>
              <td class="text-left" rowspan="1" colspan="1">RFC 9059</td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">18: Bidirectional LSP co-routed mismatch</td>
              <td class="text-left" rowspan="1" colspan="1">RFC 9059</td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">19: Endpoint mismatch in the association group</td>
              <td class="text-left" rowspan="1" colspan="1">RFC 9059</td>
            </tr>
          </tbody>
        </table>
</div>
</section>
</div>
</section>
</div>
<section id="section-9">
      <h2 id="name-references">
<a href="#section-9" class="section-number selfRef">9. </a><a href="#name-references" class="section-name selfRef">References</a>
      </h2>
<section id="section-9.1">
        <h3 id="name-normative-references">
<a href="#section-9.1" class="section-number selfRef">9.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" class="refDate">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>
<dd class="break"></dd>
<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>, and <span class="refAuthor">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" class="refDate">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>
<dd class="break"></dd>
<dt id="RFC5440">[RFC5440]</dt>
        <dd>
<span class="refAuthor">Vasseur, JP., Ed.</span> and <span class="refAuthor">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" class="refDate">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>
<dd class="break"></dd>
<dt id="RFC7551">[RFC7551]</dt>
        <dd>
<span class="refAuthor">Zhang, F., Ed.</span>, <span class="refAuthor">Jing, R.</span>, and <span class="refAuthor">R. Gandhi, Ed.</span>, <span class="refTitle">"RSVP-TE Extensions for Associated Bidirectional Label Switched Paths (LSPs)"</span>, <span class="seriesInfo">RFC 7551</span>, <span class="seriesInfo">DOI 10.17487/RFC7551</span>, <time datetime="2015-05" class="refDate">May 2015</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc7551">https://www.rfc-editor.org/info/rfc7551</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC8126">[RFC8126]</dt>
        <dd>
<span class="refAuthor">Cotton, M.</span>, <span class="refAuthor">Leiba, B.</span>, and <span class="refAuthor">T. Narten</span>, <span class="refTitle">"Guidelines for Writing an IANA Considerations Section in RFCs"</span>, <span class="seriesInfo">BCP 26</span>, <span class="seriesInfo">RFC 8126</span>, <span class="seriesInfo">DOI 10.17487/RFC8126</span>, <time datetime="2017-06" class="refDate">June 2017</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8126">https://www.rfc-editor.org/info/rfc8126</a>&gt;</span>. </dd>
<dd class="break"></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" class="refDate">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>
<dd class="break"></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>, and <span class="refAuthor">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" class="refDate">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>
<dd class="break"></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>, and <span class="refAuthor">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" class="refDate">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>
<dd class="break"></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>, and <span class="refAuthor">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" class="refDate">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>
<dd class="break"></dd>
<dt id="RFC8537">[RFC8537]</dt>
        <dd>
<span class="refAuthor">Gandhi, R., Ed.</span>, <span class="refAuthor">Shah, H.</span>, and <span class="refAuthor">J. Whittaker</span>, <span class="refTitle">"Updates to the Fast Reroute Procedures for Co-routed Associated Bidirectional Label Switched Paths (LSPs)"</span>, <span class="seriesInfo">RFC 8537</span>, <span class="seriesInfo">DOI 10.17487/RFC8537</span>, <time datetime="2019-02" class="refDate">February 2019</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8537">https://www.rfc-editor.org/info/rfc8537</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC8697">[RFC8697]</dt>
      <dd>
<span class="refAuthor">Minei, I.</span>, <span class="refAuthor">Crabbe, E.</span>, <span class="refAuthor">Sivabalan, S.</span>, <span class="refAuthor">Ananthakrishnan, H.</span>, <span class="refAuthor">Dhody, D.</span>, and <span class="refAuthor">Y. Tanaka</span>, <span class="refTitle">"Path Computation Element Communication Protocol (PCEP) Extensions for Establishing Relationships between Sets of Label Switched Paths (LSPs)"</span>, <span class="seriesInfo">RFC 8697</span>, <span class="seriesInfo">DOI 10.17487/RFC8697</span>, <time datetime="2020-01" class="refDate">January 2020</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8697">https://www.rfc-editor.org/info/rfc8697</a>&gt;</span>. </dd>
<dd class="break"></dd>
</dl>
</section>
<section id="section-9.2">
        <h3 id="name-informative-references">
<a href="#section-9.2" class="section-number selfRef">9.2. </a><a href="#name-informative-references" class="section-name selfRef">Informative References</a>
        </h3>
<dl class="references">
<dt id="I-D.ietf-pce-sr-bidir-path">[BIDIR-PATH]</dt>
        <dd>
<span class="refAuthor">Li, C.</span>, <span class="refAuthor">Chen, M.</span>, <span class="refAuthor">Cheng, W.</span>, <span class="refAuthor">Gandhi, R.</span>, and <span class="refAuthor">Q. Xiong</span>, <span class="refTitle">"Path Computation Element Communication Protocol (PCEP) Extensions for Associated Bidirectional Segment Routing (SR) Paths"</span>, <span class="refContent">Work in Progress</span>, <span class="seriesInfo">Internet-Draft, draft-ietf-pce-sr-bidir-path-05</span>, <time datetime="2021-01-26" class="refDate">26 January 2021</time>, <span>&lt;<a href="https://tools.ietf.org/html/draft-ietf-pce-sr-bidir-path-05">https://tools.ietf.org/html/draft-ietf-pce-sr-bidir-path-05</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="I-D.ietf-pce-pcep-yang">[PCE-PCEP-YANG]</dt>
        <dd>
<span class="refAuthor">Dhody, D., Ed.</span>, <span class="refAuthor">Hardwick, J.</span>, <span class="refAuthor">Beeram, V.</span>, and <span class="refAuthor">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-16</span>, <time datetime="2021-02-22" class="refDate">22 February 2021</time>, <span>&lt;<a href="https://tools.ietf.org/html/draft-ietf-pce-pcep-yang-16">https://tools.ietf.org/html/draft-ietf-pce-pcep-yang-16</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC5654">[RFC5654]</dt>
        <dd>
<span class="refAuthor">Niven-Jenkins, B., Ed.</span>, <span class="refAuthor">Brungard, D., Ed.</span>, <span class="refAuthor">Betts, M., Ed.</span>, <span class="refAuthor">Sprecher, N.</span>, and <span class="refAuthor">S. Ueno</span>, <span class="refTitle">"Requirements of an MPLS Transport Profile"</span>, <span class="seriesInfo">RFC 5654</span>, <span class="seriesInfo">DOI 10.17487/RFC5654</span>, <time datetime="2009-09" class="refDate">September 2009</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc5654">https://www.rfc-editor.org/info/rfc5654</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC7420">[RFC7420]</dt>
        <dd>
<span class="refAuthor">Koushik, A.</span>, <span class="refAuthor">Stephan, E.</span>, <span class="refAuthor">Zhao, Q.</span>, <span class="refAuthor">King, D.</span>, and <span class="refAuthor">J. Hardwick</span>, <span class="refTitle">"Path Computation Element Communication Protocol (PCEP) Management Information Base (MIB) Module"</span>, <span class="seriesInfo">RFC 7420</span>, <span class="seriesInfo">DOI 10.17487/RFC7420</span>, <time datetime="2014-12" class="refDate">December 2014</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc7420">https://www.rfc-editor.org/info/rfc7420</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC8051">[RFC8051]</dt>
        <dd>
<span class="refAuthor">Zhang, X., Ed.</span> and <span class="refAuthor">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" class="refDate">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>
<dd class="break"></dd>
<dt id="RFC8408">[RFC8408]</dt>
        <dd>
<span class="refAuthor">Sivabalan, S.</span>, <span class="refAuthor">Tantsura, J.</span>, <span class="refAuthor">Minei, I.</span>, <span class="refAuthor">Varga, R.</span>, and <span class="refAuthor">J. Hardwick</span>, <span class="refTitle">"Conveying Path Setup Type in PCE Communication Protocol (PCEP) Messages"</span>, <span class="seriesInfo">RFC 8408</span>, <span class="seriesInfo">DOI 10.17487/RFC8408</span>, <time datetime="2018-07" class="refDate">July 2018</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8408">https://www.rfc-editor.org/info/rfc8408</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="I-D.ietf-pce-pcep-stateful-pce-gmpls">[STATEFUL-PCE-GMPLS]</dt>
      <dd>
<span class="refAuthor">Lee, Y., Ed.</span>, <span class="refAuthor">Zheng, H., Ed.</span>, <span class="refAuthor">de Dios, O.</span>, <span class="refAuthor">Lopez, V.</span>, and <span class="refAuthor">Z. Ali</span>, <span class="refTitle">"Path Computation Element (PCE) Protocol Extensions for Stateful PCE Usage in GMPLS-controlled Networks"</span>, <span class="refContent">Work in Progress</span>, <span class="seriesInfo">Internet-Draft, draft-ietf-pce-pcep-stateful-pce-gmpls-14</span>, <time datetime="2020-12-28" class="refDate">28 December 2020</time>, <span>&lt;<a href="https://tools.ietf.org/html/draft-ietf-pce-pcep-stateful-pce-gmpls-14">https://tools.ietf.org/html/draft-ietf-pce-pcep-stateful-pce-gmpls-14</a>&gt;</span>. </dd>
<dd class="break"></dd>
</dl>
</section>
</section>
<div id="acknowledgments">
<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">The authors would like to thank <span class="contact-name">Dhruv Dhody</span> for various discussions
      on association groups and inputs to this document. The authors would
      also like to thank  <span class="contact-name">Mike Taillon</span>, <span class="contact-name">Harish Sitaraman</span>, <span class="contact-name">Al Morton</span>, and <span class="contact-name">Marina Fizgeer</span> for
      reviewing this document and providing valuable comments.
      The authors would like to thank the following IESG members for their 
      review comments and suggestions: <span class="contact-name">Barry Leiba</span>, <span class="contact-name">Éric Vyncke</span>, <span class="contact-name">Benjamin Kaduk</span>, 
      <span class="contact-name">Murray Kucherawy</span>, <span class="contact-name">Martin Duke</span>, and <span class="contact-name">Alvaro Retana</span>.<a href="#section-appendix.a-1" class="pilcrow">¶</a></p>
</section>
</div>
<div id="authors-addresses">
<section id="section-appendix.b">
      <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">Rakesh Gandhi (<span class="role">editor</span>)</span></div>
<div dir="auto" class="left"><span class="org">Cisco Systems, Inc.</span></div>
<div dir="auto" class="left"><span class="street-address">Canada</span></div>
<div class="email">
<span>Email:</span>
<a href="mailto:rgandhi@cisco.com" class="email">rgandhi@cisco.com</a>
</div>
</address>
<address class="vcard">
        <div dir="auto" class="left"><span class="fn nameRole">Colby Barth</span></div>
<div dir="auto" class="left"><span class="org">Juniper Networks</span></div>
<div class="email">
<span>Email:</span>
<a href="mailto:cbarth@juniper.net" class="email">cbarth@juniper.net</a>
</div>
</address>
<address class="vcard">
        <div dir="auto" class="left"><span class="fn nameRole">Bin Wen</span></div>
<div dir="auto" class="left"><span class="org">Comcast</span></div>
<div class="email">
<span>Email:</span>
<a href="mailto:Bin_Wen@cable.comcast.com" class="email">Bin_Wen@cable.comcast.com</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>