File: rfc9026.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 (2921 lines) | stat: -rw-r--r-- 138,499 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 9026: Multicast VPN Fast Upstream Failover</title>
<meta content="Thomas Morin" name="author">
<meta content="Robert Kebler" name="author">
<meta content="Greg Mirsky" name="author">
<meta content='
       This document defines Multicast Virtual Private Network (VPN)
      extensions and procedures that allow fast failover for upstream failures
      by allowing downstream Provider Edges (PEs) to consider the status of
      Provider-Tunnels (P-tunnels) when selecting the Upstream PE for a VPN
      multicast flow.  The fast failover is enabled by using "Bidirectional
      Forwarding Detection (BFD) for Multipoint Networks" (RFC 8562)  and the
      new BGP Attribute, BFD Discriminator.  Also, this document introduces a
      new BGP Community, Standby PE, extending BGP Multicast VPN (MVPN) routing so
      that a C-multicast route can be advertised toward a Standby Upstream
      PE. 
    ' name="description">
<meta content="xml2rfc 3.7.0" name="generator">
<meta content="BFD" name="keyword">
<meta content="P2MP" name="keyword">
<meta content="9026" name="rfc.number">
<!-- Generator version information:
  xml2rfc 3.7.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="rfc9026.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/rfc9026" rel="alternate">
  <link href="urn:issn:2070-1721" rel="alternate">
  <link href="https://datatracker.ietf.org/doc/draft-ietf-bess-mvpn-fast-failover-15" rel="prev">
  </head>
<body>
<script src="https://www.rfc-editor.org/js/metadata.min.js"></script>
<table class="ears">
<thead><tr>
<td class="left">RFC 9026</td>
<td class="center">MVPN Fast Upstream Failover</td>
<td class="right">April 2021</td>
</tr></thead>
<tfoot><tr>
<td class="left">Morin, 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/rfc9026" class="eref">9026</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-04" class="published">April 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">T. Morin, <span class="editor">Ed.</span>
</div>
<div class="org">Orange</div>
</div>
<div class="author">
      <div class="author-name">R. Kebler, <span class="editor">Ed.</span>
</div>
<div class="org">Juniper Networks</div>
</div>
<div class="author">
      <div class="author-name">G. Mirsky, <span class="editor">Ed.</span>
</div>
<div class="org">ZTE Corp.</div>
</div>
</dd>
</dl>
</div>
<h1 id="rfcnum">RFC 9026</h1>
<h1 id="title">Multicast VPN Fast Upstream Failover</h1>
<section id="section-abstract">
      <h2 id="abstract"><a href="#abstract" class="selfRef">Abstract</a></h2>
<p id="section-abstract-1">This document defines Multicast Virtual Private Network (VPN)
      extensions and procedures that allow fast failover for upstream failures
      by allowing downstream Provider Edges (PEs) to consider the status of
      Provider-Tunnels (P-tunnels) when selecting the Upstream PE for a VPN
      multicast flow.  The fast failover is enabled by using "Bidirectional
      Forwarding Detection (BFD) for Multipoint Networks" (RFC 8562)  and the
      new BGP Attribute, BFD Discriminator.  Also, this document introduces a
      new BGP Community, Standby PE, extending BGP Multicast VPN (MVPN) routing so
      that a C-multicast route can be advertised toward a Standby Upstream
      PE.<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/rfc9026">https://www.rfc-editor.org/info/rfc9026</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 toc compact">
<li class="ulEmpty toc compact" 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 toc compact" 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 toc compact">
<li class="ulEmpty toc compact" 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-requirements-language" class="xref">Requirements Language</a></p>
</li>
              <li class="ulEmpty toc compact" 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>
              <li class="ulEmpty toc compact" id="section-toc.1-1.2.2.3">
                <p id="section-toc.1-1.2.2.3.1"><a href="#section-2.3" class="xref">2.3</a>.  <a href="#name-abbreviations" class="xref">Abbreviations</a></p>
</li>
            </ul>
</li>
          <li class="ulEmpty toc compact" 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-umh-selection-based-on-tunn" class="xref">UMH Selection Based on Tunnel Status</a></p>
<ul class="ulEmpty toc compact">
<li class="ulEmpty toc compact" 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-determining-the-status-of-a" class="xref">Determining the Status of a Tunnel</a></p>
<ul class="ulEmpty toc compact">
<li class="ulEmpty toc compact" 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-mvpn-tunnel-root-tracking" class="xref">MVPN Tunnel Root Tracking</a></p>
</li>
                  <li class="ulEmpty toc compact" 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-pe-p-upstream-link-status" class="xref">PE-P Upstream Link Status</a></p>
</li>
                  <li class="ulEmpty toc compact" id="section-toc.1-1.3.2.1.2.3">
                    <p id="section-toc.1-1.3.2.1.2.3.1"><a href="#section-3.1.3" class="xref">3.1.3</a>.  <a href="#name-p2mp-rsvp-te-tunnels" class="xref">P2MP RSVP-TE Tunnels</a></p>
</li>
                  <li class="ulEmpty toc compact" id="section-toc.1-1.3.2.1.2.4">
                    <p id="section-toc.1-1.3.2.1.2.4.1"><a href="#section-3.1.4" class="xref">3.1.4</a>.  <a href="#name-leaf-initiated-p-tunnels" class="xref">Leaf-Initiated P-Tunnels</a></p>
</li>
                  <li class="ulEmpty toc compact" id="section-toc.1-1.3.2.1.2.5">
                    <p id="section-toc.1-1.3.2.1.2.5.1"><a href="#section-3.1.5" class="xref">3.1.5</a>.  <a href="#name-c-sc-g-counter-information" class="xref">(C-S,C-G) Counter Information</a></p>
</li>
                  <li class="ulEmpty toc compact" id="section-toc.1-1.3.2.1.2.6">
                    <p id="section-toc.1-1.3.2.1.2.6.1"><a href="#section-3.1.6" class="xref">3.1.6</a>.  <a href="#name-bfd-discriminator-attribute" class="xref">BFD Discriminator Attribute</a></p>
</li>
                  <li class="ulEmpty toc compact" id="section-toc.1-1.3.2.1.2.7">
                    <p id="section-toc.1-1.3.2.1.2.7.1"><a href="#section-3.1.7" class="xref">3.1.7</a>.  <a href="#name-bfd-discriminator-per-pe-ce" class="xref">BFD Discriminator per PE-CE Link</a></p>
</li>
                  <li class="ulEmpty toc compact" id="section-toc.1-1.3.2.1.2.8">
                    <p id="section-toc.1-1.3.2.1.2.8.1"><a href="#section-3.1.8" class="xref">3.1.8</a>.  <a href="#name-operational-considerations-" class="xref">Operational Considerations for Monitoring a P-Tunnel's Status</a></p>
</li>
                </ul>
</li>
            </ul>
</li>
          <li class="ulEmpty toc compact" 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-standby-c-multicast-route" class="xref">Standby C-Multicast Route</a></p>
<ul class="ulEmpty toc compact">
<li class="ulEmpty toc compact" 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-downstream-pe-behavior" class="xref">Downstream PE Behavior</a></p>
</li>
              <li class="ulEmpty toc compact" 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-upstream-pe-behavior" class="xref">Upstream PE Behavior</a></p>
</li>
              <li class="ulEmpty toc compact" id="section-toc.1-1.4.2.3">
                <p id="section-toc.1-1.4.2.3.1"><a href="#section-4.3" class="xref">4.3</a>.  <a href="#name-reachability-determination" class="xref">Reachability Determination</a></p>
</li>
              <li class="ulEmpty toc compact" id="section-toc.1-1.4.2.4">
                <p id="section-toc.1-1.4.2.4.1"><a href="#section-4.4" class="xref">4.4</a>.  <a href="#name-inter-as" class="xref">Inter-AS</a></p>
<ul class="ulEmpty toc compact">
<li class="ulEmpty toc compact" id="section-toc.1-1.4.2.4.2.1">
                    <p id="section-toc.1-1.4.2.4.2.1.1"><a href="#section-4.4.1" class="xref">4.4.1</a>.  <a href="#name-inter-as-procedures-for-dow" class="xref">Inter-AS Procedures for Downstream PEs, ASBR Fast Failover</a></p>
</li>
                  <li class="ulEmpty toc compact" id="section-toc.1-1.4.2.4.2.2">
                    <p id="section-toc.1-1.4.2.4.2.2.1"><a href="#section-4.4.2" class="xref">4.4.2</a>.  <a href="#name-inter-as-procedures-for-asb" class="xref">Inter-AS Procedures for ASBRs</a></p>
</li>
                </ul>
</li>
            </ul>
</li>
          <li class="ulEmpty toc compact" 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-hot-root-standby" class="xref">Hot Root Standby</a></p>
</li>
          <li class="ulEmpty toc compact" 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-duplicate-packets" class="xref">Duplicate Packets</a></p>
</li>
          <li class="ulEmpty toc compact" id="section-toc.1-1.7">
            <p id="section-toc.1-1.7.1"><a href="#section-7" class="xref">7</a>.  <a href="#name-iana-considerations" class="xref">IANA Considerations</a></p>
<ul class="ulEmpty toc compact">
<li class="ulEmpty toc compact" 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-standby-pe-community" class="xref">Standby PE Community</a></p>
</li>
              <li class="ulEmpty toc compact" 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-bfd-discriminator" class="xref">BFD Discriminator</a></p>
</li>
              <li class="ulEmpty toc compact" 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-bfd-discriminator-optional-" class="xref">BFD Discriminator Optional TLV Type</a></p>
</li>
            </ul>
</li>
          <li class="ulEmpty toc compact" 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-security-considerations" class="xref">Security Considerations</a></p>
</li>
          <li class="ulEmpty toc compact" 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 toc compact">
<li class="ulEmpty toc compact" 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 toc compact" 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 toc compact" 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 toc compact" 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-contributors" class="xref">Contributors</a></p>
</li>
          <li class="ulEmpty toc compact" id="section-toc.1-1.12">
            <p id="section-toc.1-1.12.1"><a href="#section-appendix.c" class="xref"></a><a href="#name-authors-addresses" class="xref">Authors' Addresses</a></p>
</li>
        </ul>
</nav>
</section>
</div>
<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">It is assumed that the reader is familiar with the workings of
      multicast MPLS/BGP IP VPNs as described in <span>[<a href="#RFC6513" class="xref">RFC6513</a>]</span> and
      <span>[<a href="#RFC6514" class="xref">RFC6514</a>]</span>.<a href="#section-1-1" class="pilcrow">¶</a></p>
<p id="section-1-2">In the context of multicast in BGP/MPLS VPNs <span>[<a href="#RFC6513" class="xref">RFC6513</a>]</span>, it is desirable to provide mechanisms allowing fast
      recovery of connectivity on different types of failures. This document
      addresses failures of elements in the provider network that are upstream
      of PEs connected to VPN sites with receivers.<a href="#section-1-2" class="pilcrow">¶</a></p>
<p id="section-1-3">
          <a href="#tunnel-status" class="xref">Section 3</a>
          describes local procedures allowing an egress PE (a PE connected to
          a receiver site) to take into account the status of P-tunnels to
          determine the Upstream Multicast Hop (UMH) for a given
          (C-S,C-G). One of the optional methods uses <span>[<a href="#RFC8562" class="xref">RFC8562</a>]</span>
          and the new BGP Attribute, BFD Discriminator.  None of these methods
          provide a "fast failover" solution when used alone but can be used
          together with the mechanism described in <a href="#standby-join" class="xref">Section 4</a> for a "fast failover" solution.<a href="#section-1-3" class="pilcrow">¶</a></p>
<p id="section-1-4">
          <a href="#standby-join" class="xref">Section 4</a>
          describes an optional BGP extension, a new Standby PE
          Community, that can speed up failover by not requiring any Multicast
          VPN (MVPN) routing message exchange at recovery time.<a href="#section-1-4" class="pilcrow">¶</a></p>
<p id="section-1-5">
      <a href="#hot-standby" class="xref">Section 5</a>
      describes a "hot root standby" mechanism that can be used to improve
      failover time in MVPN.  The approach combines mechanisms defined in
      Sections <a href="#tunnel-status" class="xref">3</a> and <a href="#standby-join" class="xref">4</a> and
      has similarities with the solution described in <span>[<a href="#RFC7431" class="xref">RFC7431</a>]</span>
      to improve failover times when PIM routing is used in a network given
      some topology and metric constraints.<a href="#section-1-5" class="pilcrow">¶</a></p>
<p id="section-1-6">
      The procedures described in this document are optional and allow an
      operator to provide protection for multicast services in BGP/MPLS IP
      VPNs.  An operator would enable these mechanisms using a method
      discussed in <a href="#tunnel-status" class="xref">Section 3</a> combined with the redundancy
      provided by a standby PE connected to the multicast flow source.  PEs
      that support these mechanisms would converge faster and thus provide a
      more stable multicast service.  In the case that a BGP implementation
      does not recognize or is configured not to support the extensions
      defined in this document, the implementation will continue to provide
      the multicast service, as described in <span>[<a href="#RFC6513" class="xref">RFC6513</a>]</span>.<a href="#section-1-6" class="pilcrow">¶</a></p>
</section>
<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>
<section id="section-2.1">
        <h3 id="name-requirements-language">
<a href="#section-2.1" class="section-number selfRef">2.1. </a><a href="#name-requirements-language" class="section-name selfRef">Requirements Language</a>
        </h3>
<p id="section-2.1-1">
    The key words "<span class="bcp14">MUST</span>", "<span class="bcp14">MUST NOT</span>", "<span class="bcp14">REQUIRED</span>", "<span class="bcp14">SHALL</span>", "<span class="bcp14">SHALL NOT</span>", "<span class="bcp14">SHOULD</span>", "<span class="bcp14">SHOULD NOT</span>", "<span class="bcp14">RECOMMENDED</span>", "<span class="bcp14">NOT RECOMMENDED</span>",
    "<span class="bcp14">MAY</span>", and "<span class="bcp14">OPTIONAL</span>" in this document are to be interpreted as
    described in BCP 14 <span>[<a href="#RFC2119" class="xref">RFC2119</a>]</span> <span>[<a href="#RFC8174" class="xref">RFC8174</a>]</span> 
    when, and only when, they appear in all capitals, as shown here.<a href="#section-2.1-1" class="pilcrow">¶</a></p>
</section>
<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 terminology used in this document is the terminology defined in
      <span>[<a href="#RFC6513" class="xref">RFC6513</a>]</span> and <span>[<a href="#RFC6514" class="xref">RFC6514</a>]</span>.<a href="#section-2.2-1" class="pilcrow">¶</a></p>
<p id="section-2.2-2">The term "upstream" (lower case) throughout this document refers to links and nodes
      that are upstream to a PE connected to VPN sites with receivers of a multicast flow.<a href="#section-2.2-2" class="pilcrow">¶</a></p>
<p id="section-2.2-3">The term "Upstream" (capitalized) throughout this document refers to a  PE or an Autonomous
   System Border Router (ASBR) at which (S,G) or (*,G) data packets enter the VPN backbone or the local AS
   when traveling through the VPN backbone.<a href="#section-2.2-3" class="pilcrow">¶</a></p>
</section>
<section id="section-2.3">
        <h3 id="name-abbreviations">
<a href="#section-2.3" class="section-number selfRef">2.3. </a><a href="#name-abbreviations" class="section-name selfRef">Abbreviations</a>
        </h3>
<span class="break"></span><dl class="dlParallel" id="section-2.3-1">
          <dt id="section-2.3-1.1">PMSI:
</dt>
          <dd style="margin-left: 6.0em" id="section-2.3-1.2">P-Multicast Service Interface<a href="#section-2.3-1.2" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-2.3-1.3">I-PMSI:
</dt>
          <dd style="margin-left: 6.0em" id="section-2.3-1.4">Inclusive PMSI<a href="#section-2.3-1.4" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-2.3-1.5">S-PMSI:
</dt>
          <dd style="margin-left: 6.0em" id="section-2.3-1.6">Selective PMSI<a href="#section-2.3-1.6" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-2.3-1.7">x-PMSI:
</dt>
          <dd style="margin-left: 6.0em" id="section-2.3-1.8">Either an I-PMSI or an S-PMSI<a href="#section-2.3-1.8" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-2.3-1.9">P-tunnel:
</dt>
          <dd style="margin-left: 6.0em" id="section-2.3-1.10">Provider-Tunnel<a href="#section-2.3-1.10" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-2.3-1.11">UMH:
</dt>
          <dd style="margin-left: 6.0em" id="section-2.3-1.12">Upstream Multicast Hop<a href="#section-2.3-1.12" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-2.3-1.13">VPN:
</dt>
          <dd style="margin-left: 6.0em" id="section-2.3-1.14">Virtual Private Network<a href="#section-2.3-1.14" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-2.3-1.15">MVPN:
</dt>
          <dd style="margin-left: 6.0em" id="section-2.3-1.16">Multicast VPN<a href="#section-2.3-1.16" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-2.3-1.17">RD:
</dt>
          <dd style="margin-left: 6.0em" id="section-2.3-1.18">Route Distinguisher<a href="#section-2.3-1.18" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-2.3-1.19">RP:
</dt>
          <dd style="margin-left: 6.0em" id="section-2.3-1.20">Rendezvous Point<a href="#section-2.3-1.20" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-2.3-1.21">NLRI:
</dt>
          <dd style="margin-left: 6.0em" id="section-2.3-1.22">Network Layer Reachability Information<a href="#section-2.3-1.22" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-2.3-1.23">VRF:
</dt>
          <dd style="margin-left: 6.0em" id="section-2.3-1.24">VPN Routing and Forwarding Table<a href="#section-2.3-1.24" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-2.3-1.25">MED:
</dt>
          <dd style="margin-left: 6.0em" id="section-2.3-1.26">Multi-Exit Discriminator<a href="#section-2.3-1.26" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-2.3-1.27">P2MP:
</dt>
          <dd style="margin-left: 6.0em" id="section-2.3-1.28">Point-to-Multipoint<a href="#section-2.3-1.28" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
</dl>
</section>
</section>
<div id="tunnel-status">
<section id="section-3">
      <h2 id="name-umh-selection-based-on-tunn">
<a href="#section-3" class="section-number selfRef">3. </a><a href="#name-umh-selection-based-on-tunn" class="section-name selfRef">UMH Selection Based on Tunnel Status</a>
      </h2>
<p id="section-3-1">
      <span><a href="https://www.rfc-editor.org/rfc/rfc6513#section-5.1" class="relref">Section 5.1</a> of [<a href="#RFC6513" class="xref">RFC6513</a>]</span> describes
      procedures used by an MVPN downstream PE to determine the
      Upstream Multicast Hop (UMH) for a given (C-S,C-G).<a href="#section-3-1" class="pilcrow">¶</a></p>
<p id="section-3-2">
   For a given downstream PE and a given VRF, the P-tunnel corresponding
   to a given Upstream PE for a given (C-S,C-G) state is the S-PMSI
   tunnel advertised by that Upstream PE for that (C-S,C-G) and
    imported into that VRF or, if there isn't any such S-PMSI, the I-PMSI
   tunnel advertised by that PE and imported into that VRF.<a href="#section-3-2" class="pilcrow">¶</a></p>
<p id="section-3-3">
The procedure described here is optional one, based on a
downstream PE taking into account the status of P-tunnels rooted at each
possible Upstream PE, for including or not including each given PE in the list
of candidate UMHs for a given (C-S,C-G) state.  If it is not possible to
determine whether a P-tunnel's current status is Up, the state shall be
considered "not known to be Down", and it may be treated as if it is Up so
that attempts to use the tunnel are acceptable.  The result is that, if a
P-tunnel is Down (see <a href="#tunnel-status-determination" class="xref">Section 3.1</a>), the PE
that is the root of the P-tunnel will not be considered for UMH
selection. This will result in the downstream PE failing over to use the next
Upstream PE in the list of candidates.

Some downstream PEs could arrive at a different conclusion regarding the
tunnel's state because the failure impacts only a subset of branches.  Because
of that, the procedures of <span><a href="https://www.rfc-editor.org/rfc/rfc6513#section-9.1.1" class="relref">Section 9.1.1</a> of [<a href="#RFC6513" class="xref">RFC6513</a>]</span> are applicable when using I-PMSI P-tunnels.  That document
is a foundation for this document, and its processes all apply here.<a href="#section-3-3" class="pilcrow">¶</a></p>
<p id="section-3-4">
   There are three options specified in <span><a href="https://www.rfc-editor.org/rfc/rfc6513#section-5.1" class="relref">Section 5.1</a> of [<a href="#RFC6513" class="xref">RFC6513</a>]</span> for a downstream PE to select an
   Upstream PE.<a href="#section-3-4" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-3-5.1">
          <p id="section-3-5.1.1">
          The first two options select the Upstream PE from a candidate PE
      set based either on an IP address or a hashing algorithm.  When used
      together with the optional procedure of considering the P-tunnel
      status as in this document, a candidate Upstream PE is included in
      the set if it either:<a href="#section-3-5.1.1" class="pilcrow">¶</a></p>
<ol start="1" type="a" class="normal type-a" id="section-3-5.1.2">
<li id="section-3-5.1.2.1">
          advertises an x-PMSI bound to a tunnel, where the specified tunnel's state
          is not known to be Down, or,<a href="#section-3-5.1.2.1" class="pilcrow">¶</a>
</li>
            <li id="section-3-5.1.2.2">
          does not advertise any x-PMSI applicable to the given (C-S,C-G)
          but has associated a VRF Route Import BGP Extended Community to the
          unicast VPN route for S. That is necessary to avoid
          incorrectly invalidating a UMH PE that would use a policy
          where no I-PMSI is advertised for a given VRF and where only
          S-PMSIs are used. The S-PMSI can be advertised
          only after the Upstream PE receives a C-multicast route for
          (C-S,C-G) / (C-*,C-G) to be carried over the advertised
          S-PMSI.<a href="#section-3-5.1.2.2" class="pilcrow">¶</a>
</li>
          </ol>
<p id="section-3-5.1.3">
      If the resulting candidate set is empty, then the procedure is
      repeated without considering the P-tunnel status.<a href="#section-3-5.1.3" class="pilcrow">¶</a></p>
</li>
        <li class="normal" id="section-3-5.2">
      The third option uses the installed UMH Route (i.e., the "best"
      route towards the C-root) as the Selected UMH Route, and its
      originating PE is the selected Upstream PE.  With the optional
      procedure of considering P-tunnel status as in this document, the
      Selected UMH Route is the best one among those whose originating
      PE's P-tunnel is not "down".  If that does not exist, the
      installed UMH Route is selected regardless of the P-tunnel status.<a href="#section-3-5.2" class="pilcrow">¶</a>
</li>
      </ul>
<div id="tunnel-status-determination">
<section id="section-3.1">
        <h3 id="name-determining-the-status-of-a">
<a href="#section-3.1" class="section-number selfRef">3.1. </a><a href="#name-determining-the-status-of-a" class="section-name selfRef">Determining the Status of a Tunnel</a>
        </h3>
<p id="section-3.1-1">
        Different factors can be considered to determine the "status" of a
        P-tunnel and are described in the following subsections. The optional
        procedures described in this section also handle the case when the
        downstream PEs do not all apply the same rules to define what the
        status of a P-tunnel is (please see <a href="#dups" class="xref">Section 6</a>), and
        some of them will produce a result that may be different for different
        downstream PEs.  Thus, the "status" of a P-tunnel in this section is
        not a characteristic of the tunnel in itself but is the tunnel
        status, as seen from a particular downstream PE. Additionally, some of
        the following methods determine the ability of a downstream PE to
        receive traffic on the P-tunnel and not specifically on the status of
        the P-tunnel itself.  That could be referred to as "P-tunnel reception
        status", but for simplicity, we will use the terminology of P-tunnel
        "status" for all of these methods.<a href="#section-3.1-1" class="pilcrow">¶</a></p>
<p id="section-3.1-2">Depending on the criteria used to determine the status of a
        P-tunnel, there may be an interaction with another resiliency mechanism
        used for the P-tunnel itself, and the UMH update may happen
        immediately or may need to be delayed. Each particular case is covered
        in each separate subsection below.<a href="#section-3.1-2" class="pilcrow">¶</a></p>
<p id="section-3.1-3">An implementation may support any combination of the methods
        described in this section and provide a network operator with control
        to choose which one to use in the particular deployment.<a href="#section-3.1-3" class="pilcrow">¶</a></p>
<div id="root-track-sec">
<section id="section-3.1.1">
          <h4 id="name-mvpn-tunnel-root-tracking">
<a href="#section-3.1.1" class="section-number selfRef">3.1.1. </a><a href="#name-mvpn-tunnel-root-tracking" class="section-name selfRef">MVPN Tunnel Root Tracking</a>
          </h4>
<p id="section-3.1.1-1">When determining if the status of a P-tunnel is Up, a condition
          to consider is whether the root of the tunnel, as specified
          in the x-PMSI Tunnel attribute, is reachable through unicast routing tables. In this case,
          the downstream PE can immediately update its UMH when the
          reachability condition changes.<a href="#section-3.1.1-1" class="pilcrow">¶</a></p>
<p id="section-3.1.1-2">That is similar to BGP next-hop tracking for VPN routes, except
          that the address considered is not the BGP next-hop address but the
          root address in the x-PMSI Tunnel attribute. BGP next-hop tracking monitors
          BGP next-hop address changes in the routing table. In general,
          when a change is detected, it performs a next-hop scan to find
          if any of the next hops in the BGP table is affected and updates it accordingly.<a href="#section-3.1.1-2" class="pilcrow">¶</a></p>
<p id="section-3.1.1-3">If BGP next-hop tracking is done for VPN routes and the root
          address of a given tunnel happens to be the same as the next-hop
          address in the BGP A-D Route advertising the tunnel, then checking,
          in unicast routing tables, whether the tunnel root is reachable will
          be unnecessary duplication and will thus not bring any specific
          benefit.<a href="#section-3.1.1-3" class="pilcrow">¶</a></p>
</section>
</div>
<div id="pe-p-link-status-sec">
<section id="section-3.1.2">
          <h4 id="name-pe-p-upstream-link-status">
<a href="#section-3.1.2" class="section-number selfRef">3.1.2. </a><a href="#name-pe-p-upstream-link-status" class="section-name selfRef">PE-P Upstream Link Status</a>
          </h4>
<p id="section-3.1.2-1">
          When determining if the status of a P-tunnel is Up, a condition to
          consider is whether the last-hop link of the P-tunnel is Up.
          Conversely, if the last-hop link of the P-tunnel is Down, then this
          can be taken as an indication that the P-tunnel is Down.<a href="#section-3.1.2-1" class="pilcrow">¶</a></p>
<p id="section-3.1.2-2">
          Using this method when a fast restoration mechanism (such as MPLS
          Fast Reroute (FRR) <span>[<a href="#RFC4090" class="xref">RFC4090</a>]</span>) is in place for the link requires
          careful consideration and coordination of defect detection intervals
          for the link and the tunnel.  When using multi-layer protection,
          particular consideration must be given to the interaction of defect
          detections at different network layers.  It is recommended to use
          longer detection intervals at the higher layers.  Some
          recommendations suggest using a multiplier of 3 or larger, e.g., 10
          msec detection for the link failure detection and at least 100 msec
          for the tunnel failure detection.  In many cases, it is not
          practical to use both protection methods simultaneously because
          uncorrelated timers might cause unnecessary switchovers and
          destabilize the network.<a href="#section-3.1.2-2" class="pilcrow">¶</a></p>
</section>
</div>
<div id="rsvp-te-tunnel">
<section id="section-3.1.3">
          <h4 id="name-p2mp-rsvp-te-tunnels">
<a href="#section-3.1.3" class="section-number selfRef">3.1.3. </a><a href="#name-p2mp-rsvp-te-tunnels" class="section-name selfRef">P2MP RSVP-TE Tunnels</a>
          </h4>
<p id="section-3.1.3-1">
          For P-tunnels of type P2MP MPLS-TE, the status of the P-tunnel is
          considered Up if the sub-LSP to this downstream PE is in the Up
          state. The determination of whether a P2MP RSVP-TE Label Switched Path (LSP) is in the Up
          state requires Path and Resv state for the LSP and is based on
          procedures specified in <span>[<a href="#RFC4875" class="xref">RFC4875</a>]</span>.  As a result, the
          downstream PE can immediately update its UMH when the reachability
          condition changes.<a href="#section-3.1.3-1" class="pilcrow">¶</a></p>
<p id="section-3.1.3-2">
          When using this method and if the signaling state for a P2MP TE LSP is removed (e.g., if the
          ingress of the P2MP TE LSP sends a PathTear message) or the P2MP TE
          LSP changes state from Up to Down as determined by procedures in
          <span>[<a href="#RFC4875" class="xref">RFC4875</a>]</span>, the status of the corresponding
          P-tunnel <span class="bcp14">MUST</span> be re-evaluated. If the P-tunnel transitions from Up
          to Down state, the Upstream PE that is the ingress of the P-tunnel
          <span class="bcp14">MUST NOT</span> be considered to be a valid candidate UMH.<a href="#section-3.1.3-2" class="pilcrow">¶</a></p>
</section>
</div>
<div id="leaf-init-tunnel">
<section id="section-3.1.4">
          <h4 id="name-leaf-initiated-p-tunnels">
<a href="#section-3.1.4" class="section-number selfRef">3.1.4. </a><a href="#name-leaf-initiated-p-tunnels" class="section-name selfRef">Leaf-Initiated P-Tunnels</a>
          </h4>
<p id="section-3.1.4-1">An Upstream PE <span class="bcp14">MUST</span> be removed from the UMH candidate list for a given (C-S,C-G)
          if the P-tunnel (I-PMSI or S-PMSI) for this (S,G) is leaf triggered
          (PIM, mLDP), but for some reason, internal to the protocol, the
          upstream one-hop branch of the tunnel from P to PE cannot be built.
          As a result, the downstream PE can immediately update its UMH when
          the reachability condition changes.<a href="#section-3.1.4-1" class="pilcrow">¶</a></p>
</section>
</div>
<div id="counter-info-tunnel">
<section id="section-3.1.5">
          <h4 id="name-c-sc-g-counter-information">
<a href="#section-3.1.5" class="section-number selfRef">3.1.5. </a><a href="#name-c-sc-g-counter-information" class="section-name selfRef">(C-S,C-G) Counter Information</a>
          </h4>
<p id="section-3.1.5-1">In cases where the downstream node can be configured so that the
          maximum inter-packet time is known for all the multicast flows
          mapped on a P-tunnel, the local traffic counter
          information per (C-S,C-G) for traffic received on this P-tunnel can be used to
          determine the status of the P-tunnel.<a href="#section-3.1.5-1" class="pilcrow">¶</a></p>
<p id="section-3.1.5-2">When such a procedure is used, in the context where fast
          restoration mechanisms are used for the P-tunnels, a configurable
          timer <span class="bcp14">MUST</span> be set on the downstream PE to wait before
          updating the UMH to let the P-tunnel restoration mechanism execute
          its actions.  Determining that a tunnel is probably down by waiting
          for enough packets to fail to arrive as expected is a heuristic and
          operational matter that depends on the maximum inter-packet time. A
          timeout of three seconds is a generally suitable default waiting
          period to ascertain that the tunnel is down, though other values
          would be needed for atypical conditions.<a href="#section-3.1.5-2" class="pilcrow">¶</a></p>
<p id="section-3.1.5-3">In cases where this mechanism is used in conjunction with the
          method described in <a href="#hot-standby" class="xref">Section 5</a>, no prior knowledge
          of the rate or maximum inter-packet time on the multicast streams is
          required; downstream PEs can periodically compare actual packet
          reception statistics on the two P-tunnels to determine when one of
          them is down. The detailed specification of this mechanism is
          outside the scope of this document.<a href="#section-3.1.5-3" class="pilcrow">¶</a></p>
</section>
</div>
<div id="bfd-tunnel">
<section id="section-3.1.6">
          <h4 id="name-bfd-discriminator-attribute">
<a href="#section-3.1.6" class="section-number selfRef">3.1.6. </a><a href="#name-bfd-discriminator-attribute" class="section-name selfRef">BFD Discriminator Attribute</a>
          </h4>
<p id="section-3.1.6-1">
          The P-tunnel status may be derived from the status of a multipoint
          BFD session <span>[<a href="#RFC8562" class="xref">RFC8562</a>]</span> whose discriminator is
          advertised along with an x-PMSI A-D Route.  A P2MP BFD session can
          be instantiated using a mechanism other than the BFD Discriminator
          attribute, e.g., MPLS LSP Ping (<span>[<a href="#MPLS-P2MP-BFD" class="xref">MPLS-P2MP-BFD</a>]</span>).
          The description of these methods is outside the scope of this
          document.<a href="#section-3.1.6-1" class="pilcrow">¶</a></p>
<p id="section-3.1.6-2">
          This document defines the format and ways of using a new BGP
          attribute called the "BFD Discriminator" (38).  It is an optional
          transitive BGP attribute. Thus, it is expected that an implementation
          that does not recognize or is configured not to support this
          attribute, as if the attribute was unrecognized, follows procedures
          defined for optional transitive path attributes in <span><a href="https://www.rfc-editor.org/rfc/rfc4271#section-5" class="relref">Section 5</a> of [<a href="#RFC4271" class="xref">RFC4271</a>]</span>.  See <a href="#iana-bfd-discr" class="xref">Section 7.2</a> for more information.  The format of this attribute is shown in
          <a href="#bfd-attr-fig" class="xref">Figure 1</a>.<a href="#section-3.1.6-2" class="pilcrow">¶</a></p>
<span id="name-format-of-the-bfd-discrimin"></span><div id="bfd-attr-fig">
<figure id="figure-1">
            <div class="artwork art-text alignLeft" id="section-3.1.6-3.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
   +-+-+-+-+-+-+-+-+
   |    BFD Mode   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       BFD Discriminator                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   ~                         Optional TLVs                         ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</pre>
</div>
<figcaption><a href="#figure-1" class="selfRef">Figure 1</a>:
<a href="#name-format-of-the-bfd-discrimin" class="selfRef">Format of the BFD Discriminator Attribute</a>
            </figcaption></figure>
</div>
<p id="section-3.1.6-4">
          Where:<a href="#section-3.1.6-4" class="pilcrow">¶</a></p>
<span class="break"></span><dl class="dlParallel" id="section-3.1.6-5">
            <dt id="section-3.1.6-5.1"></dt>
            <dd style="margin-left: 1.5em" id="section-3.1.6-5.2">BFD Mode field is 1 octet long. This specification defines
            P2MP BFD Session as value 1 (<a href="#iana-bfd-discr" class="xref">Section 7.2</a>).<a href="#section-3.1.6-5.2" class="pilcrow">¶</a>
</dd>
            <dd class="break"></dd>
<dt id="section-3.1.6-5.3"></dt>
            <dd style="margin-left: 1.5em" id="section-3.1.6-5.4">BFD Discriminator field is 4 octets long.<a href="#section-3.1.6-5.4" class="pilcrow">¶</a>
</dd>
            <dd class="break"></dd>
<dt id="section-3.1.6-5.5"></dt>
            <dd style="margin-left: 1.5em" id="section-3.1.6-5.6">
              <p id="section-3.1.6-5.6.1">Optional TLVs is the optional variable-length field that <span class="bcp14">MAY</span> be used in the BFD Discriminator attribute for future extensions.
          TLVs <span class="bcp14">MAY</span> be included in a sequential or nested manner. To allow for TLV nesting,
          it is advised to define a new TLV as a variable-length object.
          <a href="#opt-tlv-fig" class="xref">Figure 2</a> presents the Optional TLV format TLV that consists of:<a href="#section-3.1.6-5.6.1" class="pilcrow">¶</a></p>
<span class="break"></span><dl class="dlParallel" id="section-3.1.6-5.6.2">
                <dt id="section-3.1.6-5.6.2.1">Type:</dt>
                <dd style="margin-left: 1.5em" id="section-3.1.6-5.6.2.2">a 1-octet-long field that characterizes the
                interpretation of the Value field (<a href="#iana-bfd-attr-ext" class="xref">Section 7.3</a>)<a href="#section-3.1.6-5.6.2.2" class="pilcrow">¶</a>
</dd>
                <dd class="break"></dd>
<dt id="section-3.1.6-5.6.2.3">Length:</dt>
                <dd style="margin-left: 1.5em" id="section-3.1.6-5.6.2.4">a 1-octet-long field equal to the length of the Value field in octets<a href="#section-3.1.6-5.6.2.4" class="pilcrow">¶</a>
</dd>
                <dd class="break"></dd>
<dt id="section-3.1.6-5.6.2.5">Value:</dt>
                <dd style="margin-left: 1.5em" id="section-3.1.6-5.6.2.6">a variable-length field<a href="#section-3.1.6-5.6.2.6" class="pilcrow">¶</a>
</dd>
              <dd class="break"></dd>
</dl>
<p id="section-3.1.6-5.6.3">
             All multibyte fields in TLVs defined in this specification are in network byte order.<a href="#section-3.1.6-5.6.3" class="pilcrow">¶</a></p>
</dd>
          <dd class="break"></dd>
</dl>
<span id="name-format-of-the-optional-tlv"></span><div id="opt-tlv-fig">
<figure id="figure-2">
            <div class="artwork art-text alignLeft" id="section-3.1.6-6.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     |     Length    |           Value             ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</pre>
</div>
<figcaption><a href="#figure-2" class="selfRef">Figure 2</a>:
<a href="#name-format-of-the-optional-tlv" class="selfRef">Format of the Optional TLV</a>
            </figcaption></figure>
</div>
<p id="section-3.1.6-7">
An optional Source IP Address TLV is defined in this document.
The Source IP Address TLV <span class="bcp14">MUST</span> be used when the value of the BFD Mode field's value is P2MP BFD Session.
The BFD Discriminator attribute that does not include the Source IP Address TLV <span class="bcp14">MUST</span> be handled
according to the "attribute discard" approach, as defined in <span>[<a href="#RFC7606" class="xref">RFC7606</a>]</span>.
For the Source IP Address TLV, fields are set as follows:<a href="#section-3.1.6-7" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-3.1.6-8.1">
The Type field is set to 1 (<a href="#iana-bfd-attr-ext" class="xref">Section 7.3</a>).<a href="#section-3.1.6-8.1" class="pilcrow">¶</a>
</li>
            <li class="normal" id="section-3.1.6-8.2">
The Length field is 4 for the IPv4 address family and 16 for the IPv6 address family.
The TLV is considered malformed if the field is set to any other value.<a href="#section-3.1.6-8.2" class="pilcrow">¶</a>
</li>
            <li class="normal" id="section-3.1.6-8.3">
The Value field contains the address associated with the MultipointHead of the P2MP BFD session.<a href="#section-3.1.6-8.3" class="pilcrow">¶</a>
</li>
          </ul>
<p id="section-3.1.6-9">
          The BFD Discriminator attribute <span class="bcp14">MUST</span> be considered malformed
          if its length is smaller than 11 octets or if Optional TLVs are present but not well formed.
           If the attribute is deemed to be malformed,
           the UPDATE message <span class="bcp14">SHALL</span> be handled using the approach of Attribute Discard per <span>[<a href="#RFC7606" class="xref">RFC7606</a>]</span>.<a href="#section-3.1.6-9" class="pilcrow">¶</a></p>
<section id="section-3.1.6.1">
            <h5 id="name-upstream-pe-procedures">
<a href="#section-3.1.6.1" class="section-number selfRef">3.1.6.1. </a><a href="#name-upstream-pe-procedures" class="section-name selfRef">Upstream PE Procedures</a>
            </h5>
<p id="section-3.1.6.1-1">
          To enable downstream PEs to track the P-tunnel status using a
          point-to-multipoint (P2MP) BFD session, the Upstream PE:<a href="#section-3.1.6.1-1" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-3.1.6.1-2.1">
                <span class="bcp14">MUST</span> initiate the BFD session and set bfd.SessionType
          = MultipointHead as described in <span>[<a href="#RFC8562" class="xref">RFC8562</a>]</span>;<a href="#section-3.1.6.1-2.1" class="pilcrow">¶</a>
</li>
              <li class="normal" id="section-3.1.6.1-2.2">
          when transmitting BFD Control packets <span class="bcp14">MUST</span> set the IP
          destination address of the inner IP header to the internal loopback
          address 127.0.0.1/32 for IPv4 <span>[<a href="#RFC1122" class="xref">RFC1122</a>]</span>.  For IPv6,
          it <span class="bcp14">MUST</span> use the loopback address ::1/128 <span>[<a href="#RFC4291" class="xref">RFC4291</a>]</span>;<a href="#section-3.1.6.1-2.2" class="pilcrow">¶</a>
</li>
              <li class="normal" id="section-3.1.6.1-2.3">
                <span class="bcp14">MUST</span> use the IP address included in the Source IP
          Address TLV of the BFD Discriminator attribute as the source IP
          address when transmitting BFD Control packets;<a href="#section-3.1.6.1-2.3" class="pilcrow">¶</a>
</li>
              <li class="normal" id="section-3.1.6.1-2.4">
                <span class="bcp14">MUST</span> include the BFD Discriminator attribute in the
          x-PMSI A-D Route with the value set to the My Discriminator value;<a href="#section-3.1.6.1-2.4" class="pilcrow">¶</a>
</li>
              <li class="normal" id="section-3.1.6.1-2.5">
                <span class="bcp14">MUST</span> periodically transmit BFD Control packets over
          the x-PMSI P-tunnel after the P-tunnel is considered established.
          Note that the methods to declare that a P-tunnel has been
          established are outside the scope of this specification.<a href="#section-3.1.6.1-2.5" class="pilcrow">¶</a>
</li>
            </ul>
<p id="section-3.1.6.1-3">
   If the tracking of the P-tunnel by using a P2MP BFD session is enabled
   after the x-PMSI A-D Route has been already advertised, the x-PMSI A-D
   Route <span class="bcp14">MUST</span> be resent with the only change between the
   previous advertisement and the new advertisement to be the inclusion of the
   BFD Discriminator attribute.<a href="#section-3.1.6.1-3" class="pilcrow">¶</a></p>
<p id="section-3.1.6.1-4">
   If the x-PMSI A-D Route is advertised with P-tunnel status tracked using
   the P2MP BFD session, and it is desired to stop tracking P-tunnel
   status using BFD, then:<a href="#section-3.1.6.1-4" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-3.1.6.1-5.1">
          the x-PMSI A-D Route <span class="bcp14">MUST</span> be resent with the only
          change between the previous advertisement and the new advertisement
          be the exclusion of the BFD Discriminator attribute;<a href="#section-3.1.6.1-5.1" class="pilcrow">¶</a>
</li>
              <li class="normal" id="section-3.1.6.1-5.2">
          the P2MP BFD session <span class="bcp14">MUST</span> be deleted. The session
          <span class="bcp14">MAY</span> be deleted after some configurable delay, which
          should have a reasonable default.<a href="#section-3.1.6.1-5.2" class="pilcrow">¶</a>
</li>
            </ul>
</section>
<section id="section-3.1.6.2">
            <h5 id="name-downstream-pe-procedures">
<a href="#section-3.1.6.2" class="section-number selfRef">3.1.6.2. </a><a href="#name-downstream-pe-procedures" class="section-name selfRef">Downstream PE Procedures</a>
            </h5>
<p id="section-3.1.6.2-1">
          Upon receiving the BFD Discriminator attribute in the x-PMSI A-D Route, the downstream PE:<a href="#section-3.1.6.2-1" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-3.1.6.2-2.1">
                <span class="bcp14">MUST</span> associate the received BFD Discriminator value with the P-tunnel
          originating from the Upstream PE and the IP address of the Upstream PE;<a href="#section-3.1.6.2-2.1" class="pilcrow">¶</a>
</li>
              <li class="normal" id="section-3.1.6.2-2.2">
                <span class="bcp14">MUST</span> create a P2MP BFD session and set bfd.SessionType = MultipointTail
          as described in <span>[<a href="#RFC8562" class="xref">RFC8562</a>]</span>;<a href="#section-3.1.6.2-2.2" class="pilcrow">¶</a>
</li>
              <li class="normal" id="section-3.1.6.2-2.3">
                <p id="section-3.1.6.2-2.3.1">
          to properly demultiplex BFD session, <span class="bcp14">MUST</span> use:<a href="#section-3.1.6.2-2.3.1" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-3.1.6.2-2.3.2.1">the IP address in the Source IP Address TLV included the BFD Discriminator
attribute in the x-PMSI A-D Route;<a href="#section-3.1.6.2-2.3.2.1" class="pilcrow">¶</a>
</li>
                  <li class="normal" id="section-3.1.6.2-2.3.2.2">the value of the BFD Discriminator field in the BFD Discriminator
attribute;<a href="#section-3.1.6.2-2.3.2.2" class="pilcrow">¶</a>
</li>
                  <li class="normal" id="section-3.1.6.2-2.3.2.3">the x-PMSI Tunnel Identifier <span>[<a href="#RFC6514" class="xref">RFC6514</a>]</span> the BFD Control
packet was received on.<a href="#section-3.1.6.2-2.3.2.3" class="pilcrow">¶</a>
</li>
                </ul>
</li>
            </ul>
<p id="section-3.1.6.2-3">
          After the state of the P2MP BFD session is up, i.e., bfd.SessionState == Up,
           the session state will then be used to track the health of the P-tunnel.<a href="#section-3.1.6.2-3" class="pilcrow">¶</a></p>
<p id="section-3.1.6.2-4">
          According to <span>[<a href="#RFC8562" class="xref">RFC8562</a>]</span>, if the downstream PE receives
          Down or AdminDown in the State field of the BFD Control packet, or
          if the Detection Timer associated with the BFD session expires, the
          BFD session is down, i.e., bfd.SessionState == Down. When the BFD
          session state is Down, then the P-tunnel associated with the BFD
          session <span class="bcp14">MUST</span> be considered down.  If the site that
          contains C-S is connected to two or more PEs, a downstream PE will
          select one as its Primary Upstream PE, while others are considered
          to be Standby Upstream PEs.  In such a scenario, when the P-tunnel
          is considered down, the downstream PE <span class="bcp14">MAY</span> initiate a
          switchover of the traffic from the Primary Upstream PE to the
          Standby Upstream PE only if the Standby Upstream PE is deemed to be
          in the Up state.  That <span class="bcp14">MAY</span> be determined from the
          state of a P2MP BFD session with the Standby Upstream PE as the
          MultipointHead.<a href="#section-3.1.6.2-4" class="pilcrow">¶</a></p>
<p id="section-3.1.6.2-5">

          If the downstream PE's P-tunnel is already established when the
          downstream PE receives the new x-PMSI A-D Route with the BFD
          Discriminator attribute, the downstream PE <span class="bcp14">MUST</span>
          associate the value of the BFD Discriminator field with the P-tunnel
          and follow procedures listed above in this section if and only if
          the x-PMSI A-D Route was properly processed as per <span>[<a href="#RFC6514" class="xref">RFC6514</a>]</span>, and the BFD Discriminator attribute was
          validated.<a href="#section-3.1.6.2-5" class="pilcrow">¶</a></p>
<p id="section-3.1.6.2-6">
          If the downstream PE's P-tunnel is already established, its state
          being monitored by the P2MP BFD session set up using the BFD
          Discriminator attribute, and both the downstream PE receives the new
          x-PMSI A-D Route without the BFD Discriminator attribute and the
          x-PMSI A-D Route was processed without any error as per the relevant
          specifications, then:<a href="#section-3.1.6.2-6" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-3.1.6.2-7.1">
          The downstream PE <span class="bcp14">MUST</span> stop processing BFD Control
          packets for this P2MP BFD session;<a href="#section-3.1.6.2-7.1" class="pilcrow">¶</a>
</li>
              <li class="normal" id="section-3.1.6.2-7.2">
          The P2MP BFD session associated with the P-tunnel
          <span class="bcp14">MUST</span> be deleted. The session <span class="bcp14">MAY</span> be
          deleted after some configurable delay, which should have a
          reasonable default.<a href="#section-3.1.6.2-7.2" class="pilcrow">¶</a>
</li>
              <li class="normal" id="section-3.1.6.2-7.3">
          The downstream PE <span class="bcp14">MUST NOT</span> switch the traffic to the
          Standby Upstream PE.<a href="#section-3.1.6.2-7.3" class="pilcrow">¶</a>
</li>
            </ul>
</section>
</section>
</div>
<section id="section-3.1.7">
          <h4 id="name-bfd-discriminator-per-pe-ce">
<a href="#section-3.1.7" class="section-number selfRef">3.1.7. </a><a href="#name-bfd-discriminator-per-pe-ce" class="section-name selfRef">BFD Discriminator per PE-CE Link</a>
          </h4>
<p id="section-3.1.7-1">
   The following approach is defined in response to the detection by the
   Upstream PE of a PE-CE link failure.  Even though the provider tunnel is
   still up, it is desired for the downstream PEs to switch to a backup
   Upstream PE. To achieve that, if the Upstream PE detects that its PE-CE
   link fails, it <span class="bcp14">MUST</span> set the bfd.LocalDiag of the P2MP BFD
   session to Concatenated Path Down or Reverse Concatenated Path Down (per
   <span><a href="https://www.rfc-editor.org/rfc/rfc5880#section-6.8.17" class="relref">Section 6.8.17</a> of [<a href="#RFC5880" class="xref">RFC5880</a>]</span>) unless it
   switches to a new PE-CE link within the time of bfd.DesiredMinTxInterval
   for the P2MP BFD session (in that case, the Upstream PE will start tracking
   the status of the new PE-CE link).  When a downstream PE receives that
   bfd.LocalDiag code, it treats it as if the tunnel itself failed and tries
   to switch to a backup PE.<a href="#section-3.1.7-1" class="pilcrow">¶</a></p>
</section>
<div id="operational-sec">
<section id="section-3.1.8">
          <h4 id="name-operational-considerations-">
<a href="#section-3.1.8" class="section-number selfRef">3.1.8. </a><a href="#name-operational-considerations-" class="section-name selfRef">Operational Considerations for Monitoring a P-Tunnel's Status</a>
          </h4>
<p id="section-3.1.8-1">
Several methods to monitor the status of a P-tunnel are described in <a href="#tunnel-status-determination" class="xref">Section 3.1</a>.<a href="#section-3.1.8-1" class="pilcrow">¶</a></p>
<p id="section-3.1.8-2">
Tracking the root of an MVPN (<a href="#root-track-sec" class="xref">Section 3.1.1</a>) reveals the
status of a P-tunnel based on the control plane information. Because, in
general, the MPLS data plane is not fate sharing with the control plane, this
method might produce false-positive or false-negative alarms, for example,
resulting in tunnels that are considered Up but are not able to reach the
root, or ones that are declared down prematurely. On the other hand, because
BGP next-hop tracking is broadly supported and deployed, this method might be
the easiest to deploy.<a href="#section-3.1.8-2" class="pilcrow">¶</a></p>
<p id="section-3.1.8-3">
The method described in <a href="#pe-p-link-status-sec" class="xref">Section 3.1.2</a> monitors the state
of the data plane but only for an egress P-PE link of a P-tunnel. As a result,
network failures that affect upstream links might not be detected using this
method and the MVPN convergence would be determined by the convergence of the
BGP control plane.<a href="#section-3.1.8-3" class="pilcrow">¶</a></p>
<p id="section-3.1.8-4">
Using the state change of a P2MP RSVP-TE LSP as the trigger to re-evaluate the status of the P-tunnel (<a href="#rsvp-te-tunnel" class="xref">Section 3.1.3</a>)
relies on the mechanism used to monitor the state of the P2MP LSP.<a href="#section-3.1.8-4" class="pilcrow">¶</a></p>
<p id="section-3.1.8-5">
The method described in <a href="#leaf-init-tunnel" class="xref">Section 3.1.4</a> is simple
and is safe from causing false alarms, e.g., considering a tunnel operationally Up even though its data path has a defect or, conversely, declaring a tunnel failed when it is unaffected.
 But the method applies to a subset of MVPNs, those that use the leaf-triggered x-PMSI tunnels.<a href="#section-3.1.8-5" class="pilcrow">¶</a></p>
<p id="section-3.1.8-6">
Though some MVPNs might be used to provide a multicast service with
predictable inter-packet intervals (<a href="#counter-info-tunnel" class="xref">Section 3.1.5</a>), the number of such cases seem limited.<a href="#section-3.1.8-6" class="pilcrow">¶</a></p>
<p id="section-3.1.8-7">


Monitoring the status of a P-tunnel using a P2MP BFD session (<a href="#bfd-tunnel" class="xref">Section 3.1.6</a>) may produce the most accurate and expedient failure
notification of all monitoring methods discussed.  On the other hand, it
requires careful consideration of the additional load of BFD sessions onto
network and PE nodes.  Operators should consider the rate of BFD Control
packets transmitted by root PEs combined with the number of such PEs in the
network. In addition, the number of P2MP BFD sessions per PE determines the
amount of state information that a PE maintains.<a href="#section-3.1.8-7" class="pilcrow">¶</a></p>
</section>
</div>
</section>
</div>
</section>
</div>
<div id="standby-join">
<section id="section-4">
      <h2 id="name-standby-c-multicast-route">
<a href="#section-4" class="section-number selfRef">4. </a><a href="#name-standby-c-multicast-route" class="section-name selfRef">Standby C-Multicast Route</a>
      </h2>
<p id="section-4-1">
      The procedures described below are limited to the case where the site
      that contains C-S is connected to two or more PEs, though to simplify
      the description, the case of dual homing is described. In the case where
      more than two PEs are connected to the C-S site, selection of the
      Standby PE can be performed using one of the methods of selecting a
      UMH. Details of the selection are outside the scope of this document.
      The procedures require all the PEs of that MVPN to follow the same UMH
      selection procedure, as specified in <span>[<a href="#RFC6513" class="xref">RFC6513</a>]</span>,
      regardless of whether the PE selected based on its IP address, the
      hashing algorithm described in <span><a href="https://www.rfc-editor.org/rfc/rfc6513#section-5.1.3" class="relref">Section 5.1.3</a> of [<a href="#RFC6513" class="xref">RFC6513</a>]</span>, or the Installed UMH Route.  The consistency of the
      UMH selection method used among all PEs is expected to be provided by
      the management plane.  The procedures assume that if a site of a given
      MVPN that contains C-S is dual homed to two PEs, then all the other
      sites of that MVPN would have two unicast VPN routes (VPN-IPv4 or
      VPN-IPv6) to C-S, each with its own RD.<a href="#section-4-1" class="pilcrow">¶</a></p>
<p id="section-4-2">As long as C-S is reachable via both PEs, a given downstream PE will
      select one of the PEs connected to C-S as its Upstream PE for C-S.  We
      will refer to the other PE connected to C-S as the "Standby Upstream
      PE". Note that if the connectivity to C-S through the Primary Upstream
      PE becomes unavailable, then the PE will select the Standby Upstream PE
      as its Upstream PE for C-S. When the Primary PE later becomes available,
      the PE will select the Primary Upstream PE again as its Upstream
      PE. Such behavior is referred to as "revertive" behavior and
      <span class="bcp14">MUST</span> be supported.  Non-revertive behavior refers to the
      behavior of continuing to select the backup PE as the UMH even after the
      Primary has come up. This non-revertive behavior <span class="bcp14">MAY</span> also
      be supported by an implementation and would be enabled through some
      configuration.  Selection of the behavior, revertive or non-revertive,
      is an operational issue, but it <span class="bcp14">MUST</span> be consistent on all
      PEs in the given MVPN. While revertive is considered the default
      behavior, there might be cases where the switchover to the standby
      tunnel does not affect other services and provides the required quality
      of service. In this case, an operator might use non-revertive behavior
      to avoid unnecessary switchover and thus minimize disruption to the
      multicast service.<a href="#section-4-2" class="pilcrow">¶</a></p>
<p id="section-4-3">For readability, in the following subsections, the procedures are
      described for BGP C-multicast Source Tree Join routes, but they apply
      equally to BGP C-multicast Shared Tree Join routes for the case where
      the customer RP is dual homed (substitute "C-RP" to "C-S").<a href="#section-4-3" class="pilcrow">¶</a></p>
<div id="ds-behavior">
<section id="section-4.1">
        <h3 id="name-downstream-pe-behavior">
<a href="#section-4.1" class="section-number selfRef">4.1. </a><a href="#name-downstream-pe-behavior" class="section-name selfRef">Downstream PE Behavior</a>
        </h3>
<p id="section-4.1-1">When a (downstream) PE connected to some site of an MVPN needs to
        send a C-multicast route (C-S,C-G), then following the procedures
        specified in <span><a href="https://www.rfc-editor.org/rfc/rfc6514#section-11.1" class="relref">Section 11.1</a> of [<a href="#RFC6514" class="xref">RFC6514</a>]</span>, the PE sends the C-multicast route with an RT that
        identifies the Upstream PE selected by the PE originating the
        route. As long as C-S is reachable via the Primary Upstream PE, the
        Upstream PE is the Primary Upstream PE. If C-S is reachable only via
        the Standby Upstream PE, then the Upstream PE is the Standby Upstream
        PE.<a href="#section-4.1-1" class="pilcrow">¶</a></p>
<p id="section-4.1-2">If C-S is reachable via both the Primary and the Standby Upstream
        PE, then in addition to sending the C-multicast route with an RT that
        identifies the Primary Upstream PE, the downstream PE also originates and sends a
        C-multicast route with an RT that identifies the Standby Upstream PE.
        The route that has the semantics of being a "standby" C-multicast
        route is further called a "Standby BGP C-multicast route", and is
        constructed as follows:<a href="#section-4.1-2" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-4.1-3.1">The NLRI is constructed as the C-multicast route with an RT that
          identifies the Primary Upstream PE, except that the RD is the same
          as if the C-multicast route was built using the Standby Upstream PE
          as the UMH (it will carry the RD associated to the unicast VPN route
          advertised by the Standby Upstream PE for S and a Route Target
          derived from the Standby Upstream PE's UMH route's VRF RT Import
          EC);<a href="#section-4.1-3.1" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-4.1-3.2">It <span class="bcp14">MUST</span> carry the "Standby PE" BGP Community
          (0xFFFF0009); see <a href="#pe-standby-com-iana" class="xref">Section 7.1</a>.<a href="#section-4.1-3.2" class="pilcrow">¶</a>
</li>
        </ul>
<p id="section-4.1-4">
        The Local Preference attribute of both the normal and the standby
        C-multicast route needs to be adjusted as follows: if a BGP peer
        receives two C-multicast routes with the same NLRI, one carrying the
        "Standby PE" community and the other one not carrying the "Standby PE"
        community, preference is given to the one not carrying the
        "Standby PE" community. Such a situation can happen when, for
        instance, due to transient unicast routing inconsistencies or lack of
        support of the Standby PE community, two different downstream PEs
        consider different Upstream PEs to be the primary one. In that case,
        without any precaution taken, both Upstream PEs would process a
        standby C-multicast route and possibly stop forwarding at the same
        time. For this purpose, routes that carry the Standby PE BGP Community
        must have the LOCAL_PREF attribute set to the value lower than the
        value specified as the LOCAL_PREF attribute for the route that does
        not carry the Standby PE BGP Community. The value of zero is
        <span class="bcp14">RECOMMENDED</span>.<a href="#section-4.1-4" class="pilcrow">¶</a></p>
<p id="section-4.1-5">Note that when a PE advertises such a Standby C-multicast join for
        a (C-S,C-G), it <span class="bcp14">MUST</span> join the corresponding P-tunnel.<a href="#section-4.1-5" class="pilcrow">¶</a></p>
<p id="section-4.1-6">If, at some later point, the PE determines that C-S is no longer
        reachable through the Primary Upstream PE, the Standby Upstream PE
        becomes the Upstream PE, and the PE resends the C-multicast route with
        the RT that identifies the Standby Upstream PE, except that now the
        route does not carry the Standby PE BGP Community (which results in
        replacing the old route with a new route, with the only difference
        between these routes being the absence of the Standby PE BGP
        Community). The new Upstream PE must set the LOCAL_PREF attribute for
        that C-multicast route to the same value as when the Standby PE BGP
        Community was included in the advertisement.<a href="#section-4.1-6" class="pilcrow">¶</a></p>
</section>
</div>
<div id="us-behavior">
<section id="section-4.2">
        <h3 id="name-upstream-pe-behavior">
<a href="#section-4.2" class="section-number selfRef">4.2. </a><a href="#name-upstream-pe-behavior" class="section-name selfRef">Upstream PE Behavior</a>
        </h3>
<p id="section-4.2-1">
When a PE supporting this specification receives a C-multicast route for a particular (C-S,C-G) for which all of the following are true:<a href="#section-4.2-1" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-4.2-2.1">the RT carried in the route results in importing the route into a particular VRF on the PE;<a href="#section-4.2-2.1" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-4.2-2.2">the route carries the Standby PE BGP Community; and<a href="#section-4.2-2.2" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-4.2-2.3">
the PE determines (via a method of failure detection that is outside the scope of this document)
that C-S is not reachable through some other PE (more details are in <a href="#reach-sec" class="xref">Section 4.3</a>),<a href="#section-4.2-2.3" class="pilcrow">¶</a>
</li>
        </ul>
<p id="section-4.2-3">
then the PE <span class="bcp14">MAY</span> install VRF PIM state corresponding to this Standby BGP C-multicast route
(the result will be that a PIM Join message will be sent to the CE towards C-S, and that
the PE will receive (C-S,C-G) traffic), and the PE <span class="bcp14">MAY</span> forward (C-S,C-G)
traffic received by the PE to other PEs through a P-tunnel rooted at the PE.<a href="#section-4.2-3" class="pilcrow">¶</a></p>
<p id="section-4.2-4">Furthermore, irrespective of whether C-S carried in that route is
        reachable through some other PE:<a href="#section-4.2-4" class="pilcrow">¶</a></p>
<ol start="1" type="a" class="normal type-a" id="section-4.2-5">

<li id="section-4.2-5.1">based on local policy, as soon as the PE receives this Standby BGP
C-multicast route, the PE <span class="bcp14">MAY</span> install VRF PIM state
corresponding to this BGP Source Tree Join route (the result will be that Join
messages will be sent to the CE toward C-S, and that the PE will receive (C-S,C-G) traffic); and<a href="#section-4.2-5.1" class="pilcrow">¶</a>
</li>
          <li id="section-4.2-5.2">based on local policy, as soon as the PE receives this Standby BGP
C-multicast route, the PE <span class="bcp14">MAY</span> forward (C-S,C-G) traffic to
other PEs through a P-tunnel independently of the reachability of C-S through
some other PE. (note that this implies also doing step a.)<a href="#section-4.2-5.2" class="pilcrow">¶</a>
</li>
        </ol>
<p id="section-4.2-6">Doing neither step a nor step b for a given (C-S,C-G) is called "cold
        root standby".<a href="#section-4.2-6" class="pilcrow">¶</a></p>
<p id="section-4.2-7">Doing step a but not step b for a given (C-S,C-G) is called "warm root
        standby".<a href="#section-4.2-7" class="pilcrow">¶</a></p>
<p id="section-4.2-8">Doing step b (which implies also doing step a) for a given (C-S,C-G) is
        called "hot root standby".<a href="#section-4.2-8" class="pilcrow">¶</a></p>
<p id="section-4.2-9">Note that, if an Upstream PE uses an S-PMSI-only policy, it shall
        advertise an S-PMSI for a (C-S,C-G) as soon as it receives a C-multicast
        route for (C-S,C-G), normal or Standby; that is, it shall not wait for
        receiving a non-Standby C-multicast route before advertising the
        corresponding S-PMSI.<a href="#section-4.2-9" class="pilcrow">¶</a></p>
<p id="section-4.2-10"><span><a href="https://www.rfc-editor.org/rfc/rfc6513#section-9.3.2" class="relref">Section 9.3.2</a> of [<a href="#RFC6513" class="xref">RFC6513</a>]</span>
        describes the procedures of sending a Source-Active A-D Route as a
        result of receiving the C-multicast route.  These procedures
        <span class="bcp14">MUST</span> be followed for both the normal and Standby
        C-multicast routes.<a href="#section-4.2-10" class="pilcrow">¶</a></p>
</section>
</div>
<div id="reach-sec">
<section id="section-4.3">
        <h3 id="name-reachability-determination">
<a href="#section-4.3" class="section-number selfRef">4.3. </a><a href="#name-reachability-determination" class="section-name selfRef">Reachability Determination</a>
        </h3>
<p id="section-4.3-1">
        The Standby Upstream PE can use the following information to determine that
        C-S can or cannot be reached through the Primary Upstream PE:<a href="#section-4.3-1" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-4.3-2.1">presence/absence of a unicast VPN route toward C-S<a href="#section-4.3-2.1" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-4.3-2.2">supposing that the Standby Upstream PE is the egress of the tunnel rooted
            at the Primary Upstream PE, the Standby Upstream PE can determine the reachability
            of C-S through the Primary Upstream PE based on the status of this tunnel,
            determined thanks to the same criteria as the ones described in
            <a href="#tunnel-status-determination" class="xref">Section 3.1</a> (without using
            the UMH selection procedures of <a href="#tunnel-status" class="xref">Section 3</a>);<a href="#section-4.3-2.2" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-4.3-2.3">other mechanisms<a href="#section-4.3-2.3" class="pilcrow">¶</a>
</li>
        </ul>
</section>
</div>
<div id="interas">
<section id="section-4.4">
        <h3 id="name-inter-as">
<a href="#section-4.4" class="section-number selfRef">4.4. </a><a href="#name-inter-as" class="section-name selfRef">Inter-AS</a>
        </h3>
<p id="section-4.4-1">If the non-segmented inter-AS approach is used, the procedures described in
        <a href="#ds-behavior" class="xref">Section 4.1</a> through <a href="#reach-sec" class="xref">Section 4.3</a> can be applied.<a href="#section-4.4-1" class="pilcrow">¶</a></p>
<p id="section-4.4-2">When MVPNs are used in an inter-AS context with the
        segmented inter-AS approach described in <span><a href="https://www.rfc-editor.org/rfc/rfc6514#section-9.2" class="relref">Section 9.2</a> of [<a href="#RFC6514" class="xref">RFC6514</a>]</span>, the procedures in this section can
        be applied.<a href="#section-4.4-2" class="pilcrow">¶</a></p>
<p id="section-4.4-3">Prerequisites for the procedures described below to be applied
        for a source of a given MVPN are:<a href="#section-4.4-3" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-4.4-4.1">that any PE of this MVPN receives two or more Inter-AS I-PMSI
            A-D Routes advertised by the AS of the source<a href="#section-4.4-4.1" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-4.4-4.2">that these Inter-AS I-PMSI A-D Routes have distinct
            Route Distinguishers (as described in item "(2)" of <span><a href="https://www.rfc-editor.org/rfc/rfc6514#section-9.2" class="relref">Section 9.2</a> of [<a href="#RFC6514" class="xref">RFC6514</a>]</span>).<a href="#section-4.4-4.2" class="pilcrow">¶</a>
</li>
        </ul>
<p id="section-4.4-5">
          As an example, these conditions will be satisfied when the source is
          dual homed to an AS that connects to the receiver AS through two
          ASBR using autoconfigured RDs.<a href="#section-4.4-5" class="pilcrow">¶</a></p>
<section id="section-4.4.1">
          <h4 id="name-inter-as-procedures-for-dow">
<a href="#section-4.4.1" class="section-number selfRef">4.4.1. </a><a href="#name-inter-as-procedures-for-dow" class="section-name selfRef">Inter-AS Procedures for Downstream PEs, ASBR Fast Failover</a>
          </h4>
<p id="section-4.4.1-1">The following procedure is applied by downstream PEs of an AS,
          for a source S in a remote AS.<a href="#section-4.4.1-1" class="pilcrow">¶</a></p>
<p id="section-4.4.1-2">In additional to choosing an Inter-AS I-PMSI A-D Route advertised
          from the AS of the source to construct a C-multicast route, as
          described in <span><a href="https://www.rfc-editor.org/rfc/rfc6514#section-11.1.3" class="relref">Section 11.1.3</a> of [<a href="#RFC6514" class="xref">RFC6514</a>]</span>, a downstream PE will choose a second Inter-AS
          I-PMSI A-D Route advertised from the AS of the source and use this
          route to construct and advertise a Standby C-multicast route
          (C-multicast route carrying the Standby extended community), as
          described in <a href="#ds-behavior" class="xref">Section 4.1</a>.<a href="#section-4.4.1-2" class="pilcrow">¶</a></p>
</section>
<section id="section-4.4.2">
          <h4 id="name-inter-as-procedures-for-asb">
<a href="#section-4.4.2" class="section-number selfRef">4.4.2. </a><a href="#name-inter-as-procedures-for-asb" class="section-name selfRef">Inter-AS Procedures for ASBRs</a>
          </h4>
<p id="section-4.4.2-1">When an Upstream ASBR receives a C-multicast route, and at least
          one of the RTs of the route matches one of the ASBR Import RTs, the
          ASBR that supports this specification must try to locate an Inter-AS
          I-PMSI A-D Route whose RD and Source AS respectively match the RD
          and Source AS carried in the C-multicast route. If the match is
          found, and the C-multicast route carries the Standby PE BGP
          Community, then the ASBR implementation that supports this
          specification <span class="bcp14">MUST</span> be configurable to perform as
          follows:<a href="#section-4.4.2-1" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-4.4.2-2.1">If the route was received over iBGP and its LOCAL_PREF
            attribute is set to zero, then it <span class="bcp14">MUST</span> be
            re-advertised in eBGP with a MED attribute (MULTI_EXIT_DISC) set
            to the highest possible value (0xffff).<a href="#section-4.4.2-2.1" class="pilcrow">¶</a>
</li>
            <li class="normal" id="section-4.4.2-2.2">If the route was received over eBGP and its MED attribute is set
            to 0xffff, then it <span class="bcp14">MUST</span> be re-advertised in iBGP
            with a LOCAL_PREF attribute set to zero.<a href="#section-4.4.2-2.2" class="pilcrow">¶</a>
</li>
          </ul>
<p id="section-4.4.2-3">
            Other ASBR procedures are applied without modification and, when applied, <span class="bcp14">MAY</span> modify the above-listed behavior.<a href="#section-4.4.2-3" class="pilcrow">¶</a></p>
</section>
</section>
</div>
</section>
</div>
<div id="hot-standby">
<section id="section-5">
      <h2 id="name-hot-root-standby">
<a href="#section-5" class="section-number selfRef">5. </a><a href="#name-hot-root-standby" class="section-name selfRef">Hot Root Standby</a>
      </h2>
<p id="section-5-1">The mechanisms defined in Sections <a href="#tunnel-status" class="xref">3</a> and <a href="#standby-join" class="xref">4</a> can be used
      together as follows.<a href="#section-5-1" class="pilcrow">¶</a></p>
<p id="section-5-2">The principle is that, for a given VRF (or possibly only for a given
      (C-S,C-G)):<a href="#section-5-2" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-5-3.1">Downstream PEs advertise a Standby BGP C-multicast route (based on
        <a href="#standby-join" class="xref">Section 4</a>).<a href="#section-5-3.1" class="pilcrow">¶</a>
</li>
        <li class="normal" id="section-5-3.2">Upstream PEs use the "hot standby" optional behavior and will thus
        start forwarding traffic for a given multicast state after they have a
        (primary) BGP C-multicast route or a Standby BGP C-multicast route for
        that state (or both).<a href="#section-5-3.2" class="pilcrow">¶</a>
</li>
        <li class="normal" id="section-5-3.3">A policy controls from which tunnel downstream PEs accept traffic.
        For example, the policy could be based on the status of the tunnel or
        tunnel-monitoring method (<a href="#counter-info-tunnel" class="xref">Section 3.1.5</a>).<a href="#section-5-3.3" class="pilcrow">¶</a>
</li>
      </ul>
<p id="section-5-4">Other combinations of the mechanisms proposed in Sections <a href="#tunnel-status" class="xref">3</a> and <a href="#standby-join" class="xref">4</a> are for further study.<a href="#section-5-4" class="pilcrow">¶</a></p>
<p id="section-5-5">Note that the same level of protection would be achievable with a
      simple C-multicast Source Tree Join route advertised to both the primary
      and secondary Upstream PEs (carrying, as Route Target extended
      communities, the values of the VRF Route Import Extended Community of each VPN
      route from each Upstream PE). The advantage of using the Standby
      semantic is that, supposing that downstream PEs always advertise a
      Standby C-multicast route to the secondary Upstream PE, it allows to
      choose the protection level through a change of configuration on the
      secondary Upstream PE without requiring any reconfiguration of all the
      downstream PEs.<a href="#section-5-5" class="pilcrow">¶</a></p>
</section>
</div>
<div id="dups">
<section id="section-6">
      <h2 id="name-duplicate-packets">
<a href="#section-6" class="section-number selfRef">6. </a><a href="#name-duplicate-packets" class="section-name selfRef">Duplicate Packets</a>
      </h2>
<p id="section-6-1"><span><a href="#RFC6513" class="xref">Multicast VPN specifications</a> [<a href="#RFC6513" class="xref">RFC6513</a>]</span> impose
      that a PE only forwards to CEs the packets coming from the expected
      Upstream PE (<span><a href="https://www.rfc-editor.org/rfc/rfc6513#section-9.1" class="relref">Section 9.1</a> of [<a href="#RFC6513" class="xref">RFC6513</a>]</span>).<a href="#section-6-1" class="pilcrow">¶</a></p>
<p id="section-6-2">We draw the reader's attention to the fact that the respect of this
      part of MVPN specifications is especially important when two
      distinct Upstream PEs are susceptible to forward the same traffic on
      P-tunnels at the same time in the steady state. That will be the case
      when "hot root standby" mode is used (<a href="#hot-standby" class="xref">Section 5</a>) and
      can also be the case if the procedures of <a href="#tunnel-status" class="xref">Section 3</a>
      are used; likewise, it can also be the case when a) the rules
      determining the status of a tree are not the same on two distinct
      downstream PEs or b) the rule determining the status of a tree depends
      on conditions local to a PE (e.g., the PE-P upstream link being Up).<a href="#section-6-2" class="pilcrow">¶</a></p>
</section>
</div>
<div id="IANA">
<section id="section-7">
      <h2 id="name-iana-considerations">
<a href="#section-7" class="section-number selfRef">7. </a><a href="#name-iana-considerations" class="section-name selfRef">IANA Considerations</a>
      </h2>
<div id="pe-standby-com-iana">
<section id="section-7.1">
        <h3 id="name-standby-pe-community">
<a href="#section-7.1" class="section-number selfRef">7.1. </a><a href="#name-standby-pe-community" class="section-name selfRef">Standby PE Community</a>
        </h3>
<p id="section-7.1-1">IANA has allocated the BGP "Standby PE" community value 0xFFFF0009
      from the "Border Gateway Protocol (BGP) Well-known Communities"
      registry using the First Come First Served registration policy.<a href="#section-7.1-1" class="pilcrow">¶</a></p>
</section>
</div>
<div id="iana-bfd-discr">
<section id="section-7.2">
        <h3 id="name-bfd-discriminator">
<a href="#section-7.2" class="section-number selfRef">7.2. </a><a href="#name-bfd-discriminator" class="section-name selfRef">BFD Discriminator</a>
        </h3>
<p id="section-7.2-1">This document defines a new BGP optional transitive attribute called
   "BFD Discriminator". IANA has allocated codepoint 38 in the "BGP Path
   Attributes" registry to the BFD Discriminator attribute.<a href="#section-7.2-1" class="pilcrow">¶</a></p>
<p id="section-7.2-2">
   IANA has created a new "BFD Mode" subregistry in the "Border Gateway Protocol (BGP)
   Parameters" registry.
      The registration policies, per <span>[<a href="#RFC8126" class="xref">RFC8126</a>]</span>, for
      this subregistry are according to <a href="#iana-bfd-mode-reg" class="xref">Table 1</a>.<a href="#section-7.2-2" class="pilcrow">¶</a></p>
<span id="name-bfd-mode-subregistry-regist"></span><div id="iana-bfd-mode-reg">
<table class="center" id="table-1">
          <caption>
<a href="#table-1" class="selfRef">Table 1</a>:
<a href="#name-bfd-mode-subregistry-regist" class="selfRef">"BFD Mode" Subregistry Registration Policies</a>
          </caption>
<thead>
            <tr>
              <th class="text-left" rowspan="1" colspan="1">Value</th>
              <th class="text-center" rowspan="1" colspan="1">Policy</th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">0- 175</td>
              <td class="text-center" rowspan="1" colspan="1">IETF Review</td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">176 - 249</td>
              <td class="text-center" rowspan="1" colspan="1">First Come First Served</td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">250 - 254</td>
              <td class="text-center" rowspan="1" colspan="1">Experimental Use</td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">255</td>
              <td class="text-center" rowspan="1" colspan="1">IETF Review</td>
            </tr>
          </tbody>
        </table>
</div>
<p id="section-7.2-4">
   IANA has made initial assignments according to <a href="#iana-bfd-mode-alloc-tbl" class="xref">Table 2</a>.<a href="#section-7.2-4" class="pilcrow">¶</a></p>
<span id="name-bfd-mode-subregistry"></span><div id="iana-bfd-mode-alloc-tbl">
<table class="center" id="table-2">
          <caption>
<a href="#table-2" class="selfRef">Table 2</a>:
<a href="#name-bfd-mode-subregistry" class="selfRef">"BFD Mode" Subregistry</a>
          </caption>
<thead>
            <tr>
              <th class="text-left" rowspan="1" colspan="1">Value</th>
              <th class="text-center" 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</td>
              <td class="text-center" rowspan="1" colspan="1">Reserved</td>
              <td class="text-left" rowspan="1" colspan="1">This document</td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">1</td>
              <td class="text-center" rowspan="1" colspan="1">P2MP BFD Session</td>
              <td class="text-left" rowspan="1" colspan="1">This document</td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">2- 175</td>
              <td class="text-center" 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">176 - 249</td>
              <td class="text-center" 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">250 - 254</td>
              <td class="text-center" rowspan="1" colspan="1">Experimental Use</td>
              <td class="text-left" rowspan="1" colspan="1">This document</td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">255</td>
              <td class="text-center" rowspan="1" colspan="1">Reserved</td>
              <td class="text-left" rowspan="1" colspan="1">This document</td>
            </tr>
          </tbody>
        </table>
</div>
</section>
</div>
<div id="iana-bfd-attr-ext">
<section id="section-7.3">
        <h3 id="name-bfd-discriminator-optional-">
<a href="#section-7.3" class="section-number selfRef">7.3. </a><a href="#name-bfd-discriminator-optional-" class="section-name selfRef">BFD Discriminator Optional TLV Type</a>
        </h3>
<p id="section-7.3-1">
   IANA has created a new "BFD Discriminator Optional TLV Type" subregistry in the "Border Gateway Protocol (BGP) Parameters" registry.
   The registration policies, per <span>[<a href="#RFC8126" class="xref">RFC8126</a>]</span>, for
   this subregistry are according to <a href="#iana-bfd-discr-ext-reg" class="xref">Table 3</a>.<a href="#section-7.3-1" class="pilcrow">¶</a></p>
<span id="name-bfd-discriminator-optional-t"></span><div id="iana-bfd-discr-ext-reg">
<table class="center" id="table-3">
          <caption>
<a href="#table-3" class="selfRef">Table 3</a>:
<a href="#name-bfd-discriminator-optional-t" class="selfRef">"BFD Discriminator Optional TLV Type" Subregistry Registration Policies</a>
          </caption>
<thead>
            <tr>
              <th class="text-left" rowspan="1" colspan="1">Value</th>
              <th class="text-center" rowspan="1" colspan="1">Policy</th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">0- 175</td>
              <td class="text-center" rowspan="1" colspan="1">IETF Review</td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">176 - 249</td>
              <td class="text-center" rowspan="1" colspan="1">First Come First Served</td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">250 - 254</td>
              <td class="text-center" rowspan="1" colspan="1">Experimental Use</td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">255</td>
              <td class="text-center" rowspan="1" colspan="1">IETF Review</td>
            </tr>
          </tbody>
        </table>
</div>
<p id="section-7.3-3">
IANA has made initial assignments according to <a href="#iana-bfd-discr-ext-tbl" class="xref">Table 4</a>.<a href="#section-7.3-3" class="pilcrow">¶</a></p>
<span id="name-bfd-discriminator-optional-tl"></span><div id="iana-bfd-discr-ext-tbl">
<table class="center" id="table-4">
          <caption>
<a href="#table-4" class="selfRef">Table 4</a>:
<a href="#name-bfd-discriminator-optional-tl" class="selfRef">"BFD Discriminator Optional TLV Type" Subregistry</a>
          </caption>
<thead>
            <tr>
              <th class="text-left" rowspan="1" colspan="1">Value</th>
              <th class="text-center" 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</td>
              <td class="text-center" rowspan="1" colspan="1">Reserved</td>
              <td class="text-left" rowspan="1" colspan="1">This document</td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">1</td>
              <td class="text-center" rowspan="1" colspan="1">Source IP Address</td>
              <td class="text-left" rowspan="1" colspan="1">This document</td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">2- 175</td>
              <td class="text-center" 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">176 - 249</td>
              <td class="text-center" 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">250 - 254</td>
              <td class="text-center" rowspan="1" colspan="1">Experimental Use</td>
              <td class="text-left" rowspan="1" colspan="1">This document</td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">255</td>
              <td class="text-center" rowspan="1" colspan="1">Reserved</td>
              <td class="text-left" rowspan="1" colspan="1">This document</td>
            </tr>
          </tbody>
        </table>
</div>
</section>
</div>
</section>
</div>
<div id="Security">
<section id="section-8">
      <h2 id="name-security-considerations">
<a href="#section-8" class="section-number selfRef">8. </a><a href="#name-security-considerations" class="section-name selfRef">Security Considerations</a>
      </h2>
<p id="section-8-1">
    This document describes procedures based on <span>[<a href="#RFC6513" class="xref">RFC6513</a>]</span> and
    <span>[<a href="#RFC6514" class="xref">RFC6514</a>]</span>; hence, it shares the security considerations
    respectively represented in those specifications.<a href="#section-8-1" class="pilcrow">¶</a></p>
<p id="section-8-2">
This document uses P2MP BFD, as defined in <span>[<a href="#RFC8562" class="xref">RFC8562</a>]</span>, which, in
turn, is based on <span>[<a href="#RFC5880" class="xref">RFC5880</a>]</span>.  Security considerations relevant
to each protocol are discussed in the respective protocol specifications.  An
implementation that supports this specification <span class="bcp14">MUST</span> provide a
mechanism to limit the overall amount of capacity used by the BFD traffic (as
the combination of the number of active P2MP BFD sessions and the rate of BFD
Control packets to process).<a href="#section-8-2" class="pilcrow">¶</a></p>
<p id="section-8-3">
        The methods described in <a href="#tunnel-status-determination" class="xref">Section 3.1</a>
        may produce false-negative state changes that can be the trigger for
        an unnecessary convergence in the control plane, ultimately negatively
        impacting the multicast service provided by the VPN. An operator is
        expected to consider the network environment and use available
        controls of the mechanism used to determine the status of a P-tunnel.<a href="#section-8-3" class="pilcrow">¶</a></p>
</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="RFC4271">[RFC4271]</dt>
        <dd>
<span class="refAuthor">Rekhter, Y., Ed.</span>, <span class="refAuthor">Li, T., Ed.</span>, and <span class="refAuthor">S. Hares, Ed.</span>, <span class="refTitle">"A Border Gateway Protocol 4 (BGP-4)"</span>, <span class="seriesInfo">RFC 4271</span>, <span class="seriesInfo">DOI 10.17487/RFC4271</span>, <time datetime="2006-01" class="refDate">January 2006</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc4271">https://www.rfc-editor.org/info/rfc4271</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC4875">[RFC4875]</dt>
        <dd>
<span class="refAuthor">Aggarwal, R., Ed.</span>, <span class="refAuthor">Papadimitriou, D., Ed.</span>, and <span class="refAuthor">S. Yasukawa, Ed.</span>, <span class="refTitle">"Extensions to Resource Reservation Protocol - Traffic Engineering (RSVP-TE) for Point-to-Multipoint TE Label Switched Paths (LSPs)"</span>, <span class="seriesInfo">RFC 4875</span>, <span class="seriesInfo">DOI 10.17487/RFC4875</span>, <time datetime="2007-05" class="refDate">May 2007</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc4875">https://www.rfc-editor.org/info/rfc4875</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC5880">[RFC5880]</dt>
        <dd>
<span class="refAuthor">Katz, D.</span> and <span class="refAuthor">D. Ward</span>, <span class="refTitle">"Bidirectional Forwarding Detection (BFD)"</span>, <span class="seriesInfo">RFC 5880</span>, <span class="seriesInfo">DOI 10.17487/RFC5880</span>, <time datetime="2010-06" class="refDate">June 2010</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc5880">https://www.rfc-editor.org/info/rfc5880</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC6513">[RFC6513]</dt>
        <dd>
<span class="refAuthor">Rosen, E., Ed.</span> and <span class="refAuthor">R. Aggarwal, Ed.</span>, <span class="refTitle">"Multicast in MPLS/BGP IP VPNs"</span>, <span class="seriesInfo">RFC 6513</span>, <span class="seriesInfo">DOI 10.17487/RFC6513</span>, <time datetime="2012-02" class="refDate">February 2012</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc6513">https://www.rfc-editor.org/info/rfc6513</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC6514">[RFC6514]</dt>
        <dd>
<span class="refAuthor">Aggarwal, R.</span>, <span class="refAuthor">Rosen, E.</span>, <span class="refAuthor">Morin, T.</span>, and <span class="refAuthor">Y. Rekhter</span>, <span class="refTitle">"BGP Encodings and Procedures for Multicast in MPLS/BGP IP VPNs"</span>, <span class="seriesInfo">RFC 6514</span>, <span class="seriesInfo">DOI 10.17487/RFC6514</span>, <time datetime="2012-02" class="refDate">February 2012</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc6514">https://www.rfc-editor.org/info/rfc6514</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC7606">[RFC7606]</dt>
        <dd>
<span class="refAuthor">Chen, E., Ed.</span>, <span class="refAuthor">Scudder, J., Ed.</span>, <span class="refAuthor">Mohapatra, P.</span>, and <span class="refAuthor">K. Patel</span>, <span class="refTitle">"Revised Error Handling for BGP UPDATE Messages"</span>, <span class="seriesInfo">RFC 7606</span>, <span class="seriesInfo">DOI 10.17487/RFC7606</span>, <time datetime="2015-08" class="refDate">August 2015</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc7606">https://www.rfc-editor.org/info/rfc7606</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="RFC8562">[RFC8562]</dt>
      <dd>
<span class="refAuthor">Katz, D.</span>, <span class="refAuthor">Ward, D.</span>, <span class="refAuthor">Pallagatti, S., Ed.</span>, and <span class="refAuthor">G. Mirsky, Ed.</span>, <span class="refTitle">"Bidirectional Forwarding Detection (BFD) for Multipoint Networks"</span>, <span class="seriesInfo">RFC 8562</span>, <span class="seriesInfo">DOI 10.17487/RFC8562</span>, <time datetime="2019-04" class="refDate">April 2019</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8562">https://www.rfc-editor.org/info/rfc8562</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="MPLS-P2MP-BFD">[MPLS-P2MP-BFD]</dt>
        <dd>
<span class="refAuthor">Mirsky, G.</span>, <span class="refAuthor">Mishra, G.</span>, and <span class="refAuthor">D. Eastlake 3rd</span>, <span class="refTitle">"BFD for Multipoint Networks over Point-to-Multi-Point MPLS LSP"</span>, <span class="refContent">Work in Progress</span>, <span class="seriesInfo">Internet-Draft, draft-mirsky-mpls-p2mp-bfd-14</span>, <time datetime="2021-03" class="refDate">March 2021</time>, <span>&lt;<a href="https://tools.ietf.org/html/draft-mirsky-mpls-p2mp-bfd-14">https://tools.ietf.org/html/draft-mirsky-mpls-p2mp-bfd-14</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC1122">[RFC1122]</dt>
        <dd>
<span class="refAuthor">Braden, R., Ed.</span>, <span class="refTitle">"Requirements for Internet Hosts - Communication Layers"</span>, <span class="seriesInfo">STD 3</span>, <span class="seriesInfo">RFC 1122</span>, <span class="seriesInfo">DOI 10.17487/RFC1122</span>, <time datetime="1989-10" class="refDate">October 1989</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc1122">https://www.rfc-editor.org/info/rfc1122</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC4090">[RFC4090]</dt>
        <dd>
<span class="refAuthor">Pan, P., Ed.</span>, <span class="refAuthor">Swallow, G., Ed.</span>, and <span class="refAuthor">A. Atlas, Ed.</span>, <span class="refTitle">"Fast Reroute Extensions to RSVP-TE for LSP Tunnels"</span>, <span class="seriesInfo">RFC 4090</span>, <span class="seriesInfo">DOI 10.17487/RFC4090</span>, <time datetime="2005-05" class="refDate">May 2005</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc4090">https://www.rfc-editor.org/info/rfc4090</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC4291">[RFC4291]</dt>
        <dd>
<span class="refAuthor">Hinden, R.</span> and <span class="refAuthor">S. Deering</span>, <span class="refTitle">"IP Version 6 Addressing Architecture"</span>, <span class="seriesInfo">RFC 4291</span>, <span class="seriesInfo">DOI 10.17487/RFC4291</span>, <time datetime="2006-02" class="refDate">February 2006</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc4291">https://www.rfc-editor.org/info/rfc4291</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC7431">[RFC7431]</dt>
      <dd>
<span class="refAuthor">Karan, A.</span>, <span class="refAuthor">Filsfils, C.</span>, <span class="refAuthor">Wijnands, IJ., Ed.</span>, and <span class="refAuthor">B. Decraene</span>, <span class="refTitle">"Multicast-Only Fast Reroute"</span>, <span class="seriesInfo">RFC 7431</span>, <span class="seriesInfo">DOI 10.17487/RFC7431</span>, <time datetime="2015-08" class="refDate">August 2015</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc7431">https://www.rfc-editor.org/info/rfc7431</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 want to thank <span class="contact-name">Greg Reaume</span>, <span class="contact-name">Eric Rosen</span>, <span class="contact-name">Jeffrey Zhang</span>, <span class="contact-name">Martin Vigoureux</span>, <span class="contact-name">Adrian Farrel</span>, and
      <span class="contact-name">Zheng (Sandy) Zhang</span> for their reviews, useful
      comments, and helpful suggestions.<a href="#section-appendix.a-1" class="pilcrow">¶</a></p>
</section>
</div>
<div id="Contributors">
<section id="section-appendix.b">
      <h2 id="name-contributors">
<a href="#name-contributors" class="section-name selfRef">Contributors</a>
      </h2>
<p id="section-appendix.b-1">Below is a list of other contributing authors in alphabetical order:<a href="#section-appendix.b-1" class="pilcrow">¶</a></p>
<address class="vcard">
        <div dir="auto" class="left"><span class="fn nameRole">Rahul Aggarwal</span></div>
<div dir="auto" class="left"><span class="org">Arktan</span></div>
<div class="email">
<span>Email:</span>
<a href="mailto:raggarwa_1@yahoo.com" class="email">raggarwa_1@yahoo.com</a>
</div>
</address>
<address class="vcard">
        <div dir="auto" class="left"><span class="fn nameRole">Nehal Bhau</span></div>
<div dir="auto" class="left"><span class="org">Cisco</span></div>
<div class="email">
<span>Email:</span>
<a href="mailto:NBhau@cisco.com" class="email">NBhau@cisco.com</a>
</div>
</address>
<address class="vcard">
        <div dir="auto" class="left"><span class="fn nameRole">Clayton Hassen</span></div>
<div dir="auto" class="left"><span class="org">Bell Canada</span></div>
<div dir="auto" class="left"><span class="street-address">2955 Virtual Way</span></div>
<div dir="auto" class="left">
<span class="locality">Vancouver</span>  </div>
<div dir="auto" class="left"><span class="country-name">Canada</span></div>
<div class="email">
<span>Email:</span>
<a href="mailto:Clayton.Hassen@bell.ca" class="email">Clayton.Hassen@bell.ca</a>
</div>
</address>
<address class="vcard">
        <div dir="auto" class="left"><span class="fn nameRole">Wim Henderickx</span></div>
<div dir="auto" class="left"><span class="org">Nokia</span></div>
<div dir="auto" class="left"><span class="street-address">Copernicuslaan 50</span></div>
<div dir="auto" class="left">
<span class="postal-code">2018</span> <span class="locality">Antwerp</span>
</div>
<div dir="auto" class="left"><span class="country-name">Belgium</span></div>
<div class="email">
<span>Email:</span>
<a href="mailto:wim.henderickx@nokia.com" class="email">wim.henderickx@nokia.com</a>
</div>
</address>
<address class="vcard">
        <div dir="auto" class="left"><span class="fn nameRole">Pradeep Jain</span></div>
<div dir="auto" class="left"><span class="org">Nokia</span></div>
<div dir="auto" class="left"><span class="street-address">701 E Middlefield Rd</span></div>
<div dir="auto" class="left">
<span class="locality">Mountain View</span>,  <span class="postal-code">CA 94043</span>
</div>
<div dir="auto" class="left"><span class="country-name">United States of America</span></div>
<div class="email">
<span>Email:</span>
<a href="mailto:pradeep.jain@nokia.com" class="email">pradeep.jain@nokia.com</a>
</div>
</address>
<address class="vcard">
        <div dir="auto" class="left"><span class="fn nameRole">Jayant Kotalwar</span></div>
<div dir="auto" class="left"><span class="org">Nokia</span></div>
<div dir="auto" class="left"><span class="street-address">701 E Middlefield Rd</span></div>
<div dir="auto" class="left">
<span class="locality">Mountain View</span>,  <span class="postal-code">CA 94043</span>
</div>
<div dir="auto" class="left"><span class="country-name">United States of America</span></div>
<div class="email">
<span>Email:</span>
<a href="mailto:Jayant.Kotalwar@nokia.com" class="email">Jayant.Kotalwar@nokia.com</a>
</div>
</address>
<address class="vcard">
        <div dir="auto" class="left"><span class="fn nameRole">Praveen Muley</span></div>
<div dir="auto" class="left"><span class="org">Nokia</span></div>
<div dir="auto" class="left"><span class="street-address">701 East Middlefield Rd</span></div>
<div dir="auto" class="left">
<span class="locality">Mountain View</span>,  <span class="postal-code">CA 94043</span>
</div>
<div dir="auto" class="left"><span class="country-name">United States of America</span></div>
<div class="email">
<span>Email:</span>
<a href="mailto:praveen.muley@nokia.com" class="email">praveen.muley@nokia.com</a>
</div>
</address>
<address class="vcard">
        <div dir="auto" class="left"><span class="fn nameRole">Ray (Lei) Qiu</span></div>
<div dir="auto" class="left"><span class="org">Juniper Networks</span></div>
<div dir="auto" class="left"><span class="street-address">1194 North Mathilda Ave.</span></div>
<div dir="auto" class="left">
<span class="locality">Sunnyvale</span>,  <span class="postal-code">CA 94089</span>
</div>
<div dir="auto" class="left"><span class="country-name">United States of America</span></div>
<div class="email">
<span>Email:</span>
<a href="mailto:rqiu@juniper.net" class="email">rqiu@juniper.net</a>
</div>
</address>
<address class="vcard">
        <div dir="auto" class="left"><span class="fn nameRole">Yakov Rekhter</span></div>
<div dir="auto" class="left"><span class="org">Juniper Networks</span></div>
<div dir="auto" class="left"><span class="street-address">1194 North Mathilda Ave.</span></div>
<div dir="auto" class="left">
<span class="locality">Sunnyvale</span>,  <span class="postal-code">CA 94089</span>
</div>
<div dir="auto" class="left"><span class="country-name">United States of America</span></div>
<div class="email">
<span>Email:</span>
<a href="mailto:yakov@juniper.net" class="email">yakov@juniper.net</a>
</div>
</address>
<address class="vcard">
        <div dir="auto" class="left"><span class="fn nameRole">Kanwar Singh</span></div>
<div dir="auto" class="left"><span class="org">Nokia</span></div>
<div dir="auto" class="left"><span class="street-address">701 E Middlefield Rd</span></div>
<div dir="auto" class="left">
<span class="locality">Mountain View</span>,  <span class="postal-code">CA 94043</span>
</div>
<div dir="auto" class="left"><span class="country-name">United States of America</span></div>
<div class="email">
<span>Email:</span>
<a href="mailto:kanwar.singh@nokia.com" class="email">kanwar.singh@nokia.com</a>
</div>
</address>
</section>
</div>
<div id="authors-addresses">
<section id="section-appendix.c">
      <h2 id="name-authors-addresses">
<a href="#name-authors-addresses" class="section-name selfRef">Authors' Addresses</a>
      </h2>
<address class="vcard">
        <div dir="auto" class="left"><span class="fn nameRole">Thomas Morin (<span class="role">editor</span>)</span></div>
<div dir="auto" class="left"><span class="org">Orange</span></div>
<div dir="auto" class="left"><span class="street-address">2, avenue Pierre Marzin</span></div>
<div dir="auto" class="left">
<span class="postal-code">22307</span> <span class="locality">Lannion</span>
</div>
<div dir="auto" class="left"><span class="country-name">France</span></div>
<div class="email">
<span>Email:</span>
<a href="mailto:thomas.morin@orange.com" class="email">thomas.morin@orange.com</a>
</div>
</address>
<address class="vcard">
        <div dir="auto" class="left"><span class="fn nameRole">Robert Kebler (<span class="role">editor</span>)</span></div>
<div dir="auto" class="left"><span class="org">Juniper Networks</span></div>
<div dir="auto" class="left"><span class="street-address">1194 North Mathilda Avenue</span></div>
<div dir="auto" class="left">
<span class="locality">Sunnyvale</span>, <span class="region">CA</span> <span class="postal-code">94089</span>
</div>
<div dir="auto" class="left"><span class="country-name">United States of America</span></div>
<div class="email">
<span>Email:</span>
<a href="mailto:rkebler@juniper.net" class="email">rkebler@juniper.net</a>
</div>
</address>
<address class="vcard">
        <div dir="auto" class="left"><span class="fn nameRole">Greg Mirsky (<span class="role">editor</span>)</span></div>
<div dir="auto" class="left"><span class="org">ZTE Corp.</span></div>
<div class="email">
<span>Email:</span>
<a href="mailto:gregimirsky@gmail.com" class="email">gregimirsky@gmail.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>