File: rfc8679.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 (2118 lines) | stat: -rw-r--r-- 127,899 bytes
parent folder | download | duplicates (2)
<!DOCTYPE html>
<html lang="en" class="RFC">
<head>
<meta charset="utf-8">
<meta content="Common,Latin" name="scripts">
<meta content="initial-scale=1.0" name="viewport">
<title>RFC 8679: MPLS Egress Protection Framework</title>
<meta content="Yimin Shen" name="author">
<meta content="Minto Jeyananth" name="author">
<meta content="Bruno Decraene" name="author">
<meta content="Hannes Gredler" name="author">
<meta content="Carsten Michel" name="author">
<meta content="Huaimo Chen" name="author">
<meta content="
       
 This document specifies a fast reroute framework for protecting IP/MPLS services and MPLS transport tunnels against egress node and egress link failures. For each type of egress failure, it defines the roles of Point of Local Repair (PLR), protector, and backup egress router and the procedures of establishing a bypass tunnel from a PLR to a protector. It describes the behaviors of these routers in handling an egress failure, including local repair on the PLR and context-based forwarding on the protector. The framework can be used to develop egress protection mechanisms to reduce traffic loss before global repair reacts to an egress failure and control-plane protocols converge on the topology changes due to the egress failure.
       
    " name="description">
<meta content="xml2rfc 2.35.0" name="generator">
<meta content="fast reroute" name="keyword">
<meta content="egress protection" name="keyword">
<meta content="local repair" name="keyword">
<meta content="8679" name="rfc.number">
<link href="rfc8679.xml" type="application/rfc+xml" rel="alternate">
<link href="#copyright" rel="license">
<style type="text/css">/*

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

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

*/

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

.refInstance {
  margin-bottom: 1.25em;
}

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

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

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

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

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

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

/* pagination */
@media print {
  body {

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

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

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

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

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

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

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

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

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

}

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


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

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

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

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

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

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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

}
/* Avoid wrapping of URLs in references */
@media screen {
  .references a {
    white-space: nowrap;
  }
}
/* Tweak the bcp14 keyword presentation */
.bcp14 {
  font-variant: small-caps;
  font-weight: bold;
  font-size: 0.9em;
}
/* Tweak the invisible space above H* in order not to overlay links in text above */
 h2 {
  margin-top: -18px;  /* provide offset for in-page anchors */
  padding-top: 31px;
 }
 h3 {
  margin-top: -18px;  /* provide offset for in-page anchors */
  padding-top: 24px;
 }
 h4 {
  margin-top: -18px;  /* provide offset for in-page anchors */
  padding-top: 24px;
 }
/* Float artwork pilcrow to the right */
@media screen {
  .artwork a.pilcrow {
    display: block;
    line-height: 0.7;
    margin-top: 0.15em;
  }
}
/* Make pilcrows on dd visible */
@media screen {
  dd:hover > a.pilcrow {
    visibility: visible;
  }
}
/* Make the placement of figcaption match that of a table's caption
   by removing the figure's added bottom margin */
.alignLeft.art-text,
.alignCenter.art-text,
.alignRight.art-text {
   margin-bottom: 0;
}
.alignLeft,
.alignCenter,
.alignRight {
  margin: 1em 0 0 0;
}
/* In print, the pilcrow won't show on hover, so prevent it from taking up space,
   possibly even requiring a new line */
@media print {
  a.pilcrow {
    display: none;
  }
}
/* Styling for the external metadata */
div#external-metadata {
  background-color: #eee;
  padding: 0.5em;
  margin-bottom: 0.5em;
  display: none;
}
div#internal-metadata {
  padding: 0.5em;                       /* to match the external-metadata padding */
}
/* Styling for title RFC Number */
h1#rfcnum {
  clear: both;
  margin: 0 0 -1em;
  padding: 1em 0 0 0;
}
/* Make .olPercent look the same as <ol><li> */
dl.olPercent > dd {
  margin: 0 0 0.25em 0;
  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;
}
/* 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 {
  .sourcecode {
    margin-bottom: 1em;
  }
}</style>
<link href="rfc-local.css" type="text/css" rel="stylesheet">
<link href="https://dx.doi.org/10.17487/rfc8679" rel="alternate">
  <link href="urn:issn:2070-1721" rel="alternate">
  <link href="https://datatracker.ietf.org/doc/draft-ietf-mpls-egress-protection-framework-07" 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 8679</td>
<td class="center">MPLS Egress Protection Framework</td>
<td class="right">December 2019</td>
</tr></thead>
<tfoot><tr>
<td class="left">Shen, 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/rfc8679" class="eref">8679</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="2019-12" class="published">December 2019</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">Y. Shen</div>
<div class="org">Juniper Networks</div>
</div>
<div class="author">
      <div class="author-name">M. Jeyananth</div>
<div class="org">Juniper Networks</div>
</div>
<div class="author">
      <div class="author-name">B. Decraene</div>
<div class="org">Orange</div>
</div>
<div class="author">
      <div class="author-name">H. Gredler</div>
<div class="org">RtBrick Inc.</div>
</div>
<div class="author">
      <div class="author-name">C. Michel</div>
<div class="org">Deutsche Telekom</div>
</div>
<div class="author">
      <div class="author-name">H. Chen</div>
<div class="org">Futurewei</div>
</div>
</dd>
</dl>
</div>
<h1 id="rfcnum">RFC 8679</h1>
<h1 id="title">MPLS Egress Protection Framework</h1>
<section id="section-abstract">
      <h2 id="abstract"><a href="#abstract" class="selfRef">Abstract</a></h2>
<p id="section-abstract-1">
 This document specifies a fast reroute framework for protecting IP/MPLS services and MPLS transport tunnels against egress node and egress link failures. For each type of egress failure, it defines the roles of Point of Local Repair (PLR), protector, and backup egress router and the procedures of establishing a bypass tunnel from a PLR to a protector. It describes the behaviors of these routers in handling an egress failure, including local repair on the PLR and context-based forwarding on the protector. The framework can be used to develop egress protection mechanisms to reduce traffic loss before global repair reacts to an egress failure and control-plane protocols converge on the topology changes due to the egress failure.<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/rfc8679">https://www.rfc-editor.org/info/rfc8679</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) 2019 IETF Trust and the persons identified as the
            document authors. All rights reserved.<a href="#section-boilerplate.2-1" class="pilcrow">¶</a></p>
<p id="section-boilerplate.2-2">
            This document is subject to BCP 78 and the IETF Trust's Legal
            Provisions Relating to IETF Documents
            (<span><a href="https://trustee.ietf.org/license-info">https://trustee.ietf.org/license-info</a></span>) in effect on the date of
            publication of this document. Please review these documents
            carefully, as they describe your rights and restrictions with
            respect to this document. Code Components extracted from this
            document must include Simplified BSD License text as described in
            Section 4.e of the Trust Legal Provisions and are provided without
            warranty as described in the Simplified BSD License.<a href="#section-boilerplate.2-2" class="pilcrow">¶</a></p>
</section>
</div>
<div id="toc">
<section id="section-toc.1">
        <a href="#" onclick="scroll(0,0)" class="toplink">▲</a><h2 id="name-table-of-contents">
<a href="#name-table-of-contents" class="section-name selfRef">Table of Contents</a>
        </h2>
<nav class="toc"><ul class="toc ulEmpty">
<li class="toc ulEmpty" id="section-toc.1-1.1">
            <p id="section-toc.1-1.1.1"><a href="#section-1" class="xref">1</a>.  <a href="#name-introduction" class="xref">Introduction</a><a href="#section-toc.1-1.1.1" class="pilcrow">¶</a></p>
</li>
          <li class="toc ulEmpty" id="section-toc.1-1.2">
            <p id="section-toc.1-1.2.1"><a href="#section-2" class="xref">2</a>.  <a href="#name-specification-of-requiremen" class="xref">Specification of Requirements</a><a href="#section-toc.1-1.2.1" class="pilcrow">¶</a></p>
</li>
          <li class="toc ulEmpty" id="section-toc.1-1.3">
            <p id="section-toc.1-1.3.1"><a href="#section-3" class="xref">3</a>.  <a href="#name-terminology" class="xref">Terminology</a><a href="#section-toc.1-1.3.1" class="pilcrow">¶</a></p>
</li>
          <li class="toc ulEmpty" id="section-toc.1-1.4">
            <p id="section-toc.1-1.4.1"><a href="#section-4" class="xref">4</a>.  <a href="#name-requirements" class="xref">Requirements</a><a href="#section-toc.1-1.4.1" class="pilcrow">¶</a></p>
</li>
          <li class="toc ulEmpty" id="section-toc.1-1.5">
            <p id="section-toc.1-1.5.1"><a href="#section-5" class="xref">5</a>.  <a href="#name-egress-node-protection" class="xref">Egress Node Protection</a><a href="#section-toc.1-1.5.1" class="pilcrow">¶</a></p>
<ul class="toc ulEmpty">
<li class="toc ulEmpty" id="section-toc.1-1.5.2.1">
                <p id="section-toc.1-1.5.2.1.1"><a href="#section-5.1" class="xref">5.1</a>.  <a href="#name-reference-topology" class="xref">Reference Topology</a><a href="#section-toc.1-1.5.2.1.1" class="pilcrow">¶</a></p>
</li>
              <li class="toc ulEmpty" id="section-toc.1-1.5.2.2">
                <p id="section-toc.1-1.5.2.2.1"><a href="#section-5.2" class="xref">5.2</a>.  <a href="#name-egress-node-failure-and-det" class="xref">Egress Node Failure and Detection</a><a href="#section-toc.1-1.5.2.2.1" class="pilcrow">¶</a></p>
</li>
              <li class="toc ulEmpty" id="section-toc.1-1.5.2.3">
                <p id="section-toc.1-1.5.2.3.1"><a href="#section-5.3" class="xref">5.3</a>.  <a href="#name-protector-and-plr" class="xref">Protector and PLR</a><a href="#section-toc.1-1.5.2.3.1" class="pilcrow">¶</a></p>
</li>
              <li class="toc ulEmpty" id="section-toc.1-1.5.2.4">
                <p id="section-toc.1-1.5.2.4.1"><a href="#section-5.4" class="xref">5.4</a>.  <a href="#name-protected-egress" class="xref">Protected Egress</a><a href="#section-toc.1-1.5.2.4.1" class="pilcrow">¶</a></p>
</li>
              <li class="toc ulEmpty" id="section-toc.1-1.5.2.5">
                <p id="section-toc.1-1.5.2.5.1"><a href="#section-5.5" class="xref">5.5</a>.  <a href="#name-egress-protected-tunnel-and" class="xref">Egress-Protected Tunnel and Service</a><a href="#section-toc.1-1.5.2.5.1" class="pilcrow">¶</a></p>
</li>
              <li class="toc ulEmpty" id="section-toc.1-1.5.2.6">
                <p id="section-toc.1-1.5.2.6.1"><a href="#section-5.6" class="xref">5.6</a>.  <a href="#name-egress-protection-bypass-tu" class="xref">Egress-Protection Bypass Tunnel</a><a href="#section-toc.1-1.5.2.6.1" class="pilcrow">¶</a></p>
</li>
              <li class="toc ulEmpty" id="section-toc.1-1.5.2.7">
                <p id="section-toc.1-1.5.2.7.1"><a href="#section-5.7" class="xref">5.7</a>.  <a href="#name-context-id-context-label-an" class="xref">Context ID, Context Label, and Context-Based Forwarding</a><a href="#section-toc.1-1.5.2.7.1" class="pilcrow">¶</a></p>
</li>
              <li class="toc ulEmpty" id="section-toc.1-1.5.2.8">
                <p id="section-toc.1-1.5.2.8.1"><a href="#section-5.8" class="xref">5.8</a>.  <a href="#name-advertisement-and-path-reso" class="xref">Advertisement and Path Resolution for Context ID</a><a href="#section-toc.1-1.5.2.8.1" class="pilcrow">¶</a></p>
</li>
              <li class="toc ulEmpty" id="section-toc.1-1.5.2.9">
                <p id="section-toc.1-1.5.2.9.1"><a href="#section-5.9" class="xref">5.9</a>.  <a href="#name-egress-protection-bypass-tun" class="xref">Egress-Protection Bypass Tunnel Establishment</a><a href="#section-toc.1-1.5.2.9.1" class="pilcrow">¶</a></p>
</li>
              <li class="toc ulEmpty" id="section-toc.1-1.5.2.10">
                <p id="section-toc.1-1.5.2.10.1"><a href="#section-5.10" class="xref">5.10</a>. <a href="#name-local-repair-on-plr" class="xref">Local Repair on PLR</a><a href="#section-toc.1-1.5.2.10.1" class="pilcrow">¶</a></p>
</li>
              <li class="toc ulEmpty" id="section-toc.1-1.5.2.11">
                <p id="section-toc.1-1.5.2.11.1"><a href="#section-5.11" class="xref">5.11</a>. <a href="#name-service-label-distribution-" class="xref">Service Label Distribution from Egress Router to Protector</a><a href="#section-toc.1-1.5.2.11.1" class="pilcrow">¶</a></p>
</li>
              <li class="toc ulEmpty" id="section-toc.1-1.5.2.12">
                <p id="section-toc.1-1.5.2.12.1"><a href="#section-5.12" class="xref">5.12</a>. <a href="#name-centralized-protector-mode" class="xref">Centralized Protector Mode</a><a href="#section-toc.1-1.5.2.12.1" class="pilcrow">¶</a></p>
</li>
            </ul>
</li>
          <li class="toc ulEmpty" id="section-toc.1-1.6">
            <p id="section-toc.1-1.6.1"><a href="#section-6" class="xref">6</a>.  <a href="#name-egress-link-protection" class="xref">Egress Link Protection</a><a href="#section-toc.1-1.6.1" class="pilcrow">¶</a></p>
</li>
          <li class="toc ulEmpty" id="section-toc.1-1.7">
            <p id="section-toc.1-1.7.1"><a href="#section-7" class="xref">7</a>.  <a href="#name-global-repair" class="xref">Global Repair</a><a href="#section-toc.1-1.7.1" class="pilcrow">¶</a></p>
</li>
          <li class="toc ulEmpty" id="section-toc.1-1.8">
            <p id="section-toc.1-1.8.1"><a href="#section-8" class="xref">8</a>.  <a href="#name-operational-considerations" class="xref">Operational Considerations</a><a href="#section-toc.1-1.8.1" class="pilcrow">¶</a></p>
</li>
          <li class="toc ulEmpty" 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-general-context-based-forwa" class="xref">General Context-Based Forwarding</a><a href="#section-toc.1-1.9.1" class="pilcrow">¶</a></p>
</li>
          <li class="toc ulEmpty" id="section-toc.1-1.10">
            <p id="section-toc.1-1.10.1"><a href="#section-10" class="xref">10</a>. <a href="#name-example-layer-3-vpn-egress-" class="xref">Example: Layer 3 VPN Egress Protection</a><a href="#section-toc.1-1.10.1" class="pilcrow">¶</a></p>
<ul class="toc ulEmpty">
<li class="toc ulEmpty" id="section-toc.1-1.10.2.1">
                <p id="section-toc.1-1.10.2.1.1"><a href="#section-10.1" class="xref">10.1</a>.  <a href="#name-egress-node-protection-2" class="xref">Egress Node Protection</a><a href="#section-toc.1-1.10.2.1.1" class="pilcrow">¶</a></p>
</li>
              <li class="toc ulEmpty" id="section-toc.1-1.10.2.2">
                <p id="section-toc.1-1.10.2.2.1"><a href="#section-10.2" class="xref">10.2</a>.  <a href="#name-egress-link-protection-2" class="xref">Egress Link Protection</a><a href="#section-toc.1-1.10.2.2.1" class="pilcrow">¶</a></p>
</li>
              <li class="toc ulEmpty" id="section-toc.1-1.10.2.3">
                <p id="section-toc.1-1.10.2.3.1"><a href="#section-10.3" class="xref">10.3</a>.  <a href="#name-global-repair-2" class="xref">Global Repair</a><a href="#section-toc.1-1.10.2.3.1" class="pilcrow">¶</a></p>
</li>
              <li class="toc ulEmpty" id="section-toc.1-1.10.2.4">
                <p id="section-toc.1-1.10.2.4.1"><a href="#section-10.4" class="xref">10.4</a>.  <a href="#name-other-modes-of-vpn-label-al" class="xref">Other Modes of VPN Label Allocation</a><a href="#section-toc.1-1.10.2.4.1" class="pilcrow">¶</a></p>
</li>
            </ul>
</li>
          <li class="toc ulEmpty" id="section-toc.1-1.11">
            <p id="section-toc.1-1.11.1"><a href="#section-11" class="xref">11</a>. <a href="#name-iana-considerations" class="xref">IANA Considerations</a><a href="#section-toc.1-1.11.1" class="pilcrow">¶</a></p>
</li>
          <li class="toc ulEmpty" id="section-toc.1-1.12">
            <p id="section-toc.1-1.12.1"><a href="#section-12" class="xref">12</a>. <a href="#name-security-considerations" class="xref">Security Considerations</a><a href="#section-toc.1-1.12.1" class="pilcrow">¶</a></p>
</li>
          <li class="toc ulEmpty" id="section-toc.1-1.13">
            <p id="section-toc.1-1.13.1"><a href="#section-13" class="xref">13</a>. <a href="#name-references" class="xref">References</a><a href="#section-toc.1-1.13.1" class="pilcrow">¶</a></p>
<ul class="toc ulEmpty">
<li class="toc ulEmpty" id="section-toc.1-1.13.2.1">
                <p id="section-toc.1-1.13.2.1.1"><a href="#section-13.1" class="xref">13.1</a>.  <a href="#name-normative-references" class="xref">Normative References</a><a href="#section-toc.1-1.13.2.1.1" class="pilcrow">¶</a></p>
</li>
              <li class="toc ulEmpty" id="section-toc.1-1.13.2.2">
                <p id="section-toc.1-1.13.2.2.1"><a href="#section-13.2" class="xref">13.2</a>.  <a href="#name-informative-references" class="xref">Informative References</a><a href="#section-toc.1-1.13.2.2.1" class="pilcrow">¶</a></p>
</li>
            </ul>
</li>
          <li class="toc ulEmpty" id="section-toc.1-1.14">
            <p id="section-toc.1-1.14.1"><a href="#section-appendix.a" class="xref"></a><a href="#name-acknowledgements" class="xref">Acknowledgements</a><a href="#section-toc.1-1.14.1" class="pilcrow">¶</a></p>
</li>
          <li class="toc ulEmpty" id="section-toc.1-1.15">
            <p id="section-toc.1-1.15.1"><a href="#section-appendix.b" class="xref"></a><a href="#name-authors-addresses" class="xref">Authors' Addresses</a><a href="#section-toc.1-1.15.1" class="pilcrow">¶</a></p>
</li>
        </ul>
</nav>
</section>
</div>
<div id="intro">
<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">
       In MPLS networks, Label Switched Paths (LSPs) are widely used as transport tunnels to carry IP and MPLS services across MPLS domains. Examples of MPLS services are Layer 2 VPNs, Layer 3 VPNs, hierarchical LSPs, and others. In general, a tunnel may carry multiple services of one or multiple types, if the tunnel satisfies both individual and aggregate requirements (e.g., Class of Service (CoS) and QoS) of these services. The egress router of the tunnel hosts the service instances of the services. An MPLS service instance forwards service packets via an egress link to the service destination, based on a service label. An IP service instance does the same, based on an IP service address. The egress link is often called a Provider Edge - Customer Edge (PE-CE) link or Attachment Circuit (AC).<a href="#section-1-1" class="pilcrow">¶</a></p>
<p id="section-1-2">
       Today, local-repair-based fast reroute mechanisms (see <span>[<a href="#RFC4090" class="xref">RFC4090</a>]</span>, <span>[<a href="#RFC5286" class="xref">RFC5286</a>]</span>, <span>[<a href="#RFC7490" class="xref">RFC7490</a>]</span>, and
<span>[<a href="#RFC7812" class="xref">RFC7812</a>]</span>) have been widely deployed to protect MPLS tunnels against transit link/node failures, with traffic restoration time in the order of tens of milliseconds. Local repair refers to the scenario where the router upstream to an anticipated failure, a.k.a., PLR, pre-establishes a bypass tunnel to the router downstream of the failure, a.k.a., Merge Point (MP), pre-installs the forwarding state of the bypass tunnel in the data plane, and uses a rapid mechanism (e.g., link-layer Operations, Administration, and Maintenance (OAM), Bidirectional Forwarding Detection (BFD), and others) to locally detect the failure in the data plane. When the failure occurs, the PLR reroutes traffic through the bypass tunnel to the MP, allowing the traffic to continue to flow to the tunnel's egress router.<a href="#section-1-2" class="pilcrow">¶</a></p>
<p id="section-1-3">
       This document specifies a fast reroute framework for egress node and egress link protection. Similar to transit link/node protection, this framework also relies on a PLR to perform local failure detection and local repair. In egress node protection, the PLR is the penultimate hop router of a tunnel. In egress link protection, the PLR is the egress router of the tunnel. The framework further uses a so-called "protector" to serve as the tail end of a bypass tunnel. The protector is a router that hosts "protection service instances" and has its own connectivity or paths to service destinations. When a PLR does local repair, the protector performs "context label switching" for rerouted MPLS service packets and "context IP forwarding" for rerouted IP service packets, to allow the service packets to continue to reach the service destinations.<a href="#section-1-3" class="pilcrow">¶</a></p>
<p id="section-1-4">
       This framework considers an egress node failure as a failure of a tunnel and a failure of all the services carried by the tunnel as service packets that can no longer reach the service instances on the egress router. Therefore, the framework addresses egress node protection at both the tunnel level and service level, simultaneously. Likewise, the framework considers an egress link failure as a failure of all the services traversing the link and addresses egress link protection at the service level.<a href="#section-1-4" class="pilcrow">¶</a></p>
<p id="section-1-5">
       This framework requires that the destination (a CE or site) of a service <span class="bcp14">MUST</span> be dual-homed or have dual paths to an MPLS network, via two MPLS edge routers. One of the routers is the egress router of the service's transport tunnel, and the other is a backup egress router that hosts a "backup service instance". In the "co-located" protector mode in this document, the backup egress router serves as the protector; hence, the backup service instance acts as the protection service instance. In the "centralized" protector mode (<a href="#centralized" class="xref">Section 5.12</a>), the protector and the backup egress router are decoupled, and the protection service instance and the backup service instance are hosted separately by the two routers.<a href="#section-1-5" class="pilcrow">¶</a></p>
<p id="section-1-6">
       The framework is described by mainly referring to point-to-point (P2P) tunnels. However, it is equally applicable to point-to-multipoint (P2MP), multipoint-to-point (MP2P), and multipoint-to-multipoint (MP2MP) tunnels, as the sub-LSPs of these tunnels can be viewed as P2P tunnels.<a href="#section-1-6" class="pilcrow">¶</a></p>
<p id="section-1-7">
       The framework is a multi-service and multi-transport framework. It assumes a generic model where each service is comprised of a common set of components, including a service instance, a service label, a service label distribution protocol, and an MPLS transport tunnel. The framework also assumes that the service label is downstream assigned, i.e., assigned by an egress router. Therefore, the framework is generally applicable to most existing and future services. However, there are services with certain modes, where a protector is unable to pre-establish the forwarding state for egress protection, or a PLR is not allowed to reroute traffic to other routers in order to avoid traffic duplication, e.g., the broadcast, multicast, and unknown unicast traffic in Virtual Private LAN Service (VPLS) and Ethernet VPN (EVPN). These cases are left for future study. Services that use upstream-assigned service labels are also out of scope of this document and left for future study.<a href="#section-1-7" class="pilcrow">¶</a></p>
<p id="section-1-8">
       The framework does not require extensions for the existing signaling and
label distribution protocols (e.g., RSVP, LDP, BGP, etc.) of MPLS tunnels. It
assumes that transport tunnels and bypass tunnels are to be established by using the
generic procedures provided by the protocols. On the other hand, it does not
preclude extensions to the protocols that may facilitate the procedures. One
example of such extension is <span>[<a href="#RFC8400" class="xref">RFC8400</a>]</span>. The framework does see the need for extensions of IGPs and service label distribution protocols in some procedures, particularly for supporting protection establishment and context label switching. This document provides guidelines for these extensions, but it leaves the specific details to separate documents.<a href="#section-1-8" class="pilcrow">¶</a></p>
<p id="section-1-9">
       The framework is intended to complement control-plane convergence and
global repair. Control-plane convergence relies on control protocols to react
on the topology changes due to a failure. Global repair relies on an ingress
router to remotely detect a failure and switch traffic to an alternative
path. An example of global repair is the BGP prefix independent convergence
mechanism <span>[<a href="#I-D.ietf-rtgwg-bgp-pic" class="xref">BGP-PIC</a>]</span> for BGP-established services. Compared with these mechanisms, this framework is considered faster in traffic restoration, due to the nature of local failure detection and local repair. It is <span class="bcp14">RECOMMENDED</span> that the framework be used in conjunction with control-plane convergence or global repair, in order to take the advantages of both approaches. That is, the framework provides fast and temporary repair, while control-plane convergence or global repair provides ultimate and permanent repair.<a href="#section-1-9" class="pilcrow">¶</a></p>
</section>
</div>
<section id="section-2">
      <h2 id="name-specification-of-requiremen">
<a href="#section-2" class="section-number selfRef">2. </a><a href="#name-specification-of-requiremen" class="section-name selfRef">Specification of Requirements</a>
      </h2>
<p id="section-2-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" class="pilcrow">¶</a></p>
</section>
<div id="terms">
<section id="section-3">
      <h2 id="name-terminology">
<a href="#section-3" class="section-number selfRef">3. </a><a href="#name-terminology" class="section-name selfRef">Terminology</a>
      </h2>
<dl class="dlNewline" id="section-3-1">
        <dt id="section-3-1.1">Egress router:</dt>
        <dd id="section-3-1.2">A router at the egress endpoint of a tunnel. It hosts service instances for all the services carried by the tunnel and has connectivity with the destinations of the services.<a href="#section-3-1.2" class="pilcrow">¶</a>
</dd>
<dt id="section-3-1.3">Egress node failure:</dt>
        <dd id="section-3-1.4">A failure of an egress router.<a href="#section-3-1.4" class="pilcrow">¶</a>
</dd>
<dt id="section-3-1.5">
       Egress link failure:</dt>
        <dd id="section-3-1.6">A failure of the egress link (e.g., PE-CE link, attachment circuit) of a service.<a href="#section-3-1.6" class="pilcrow">¶</a>
</dd>
<dt id="section-3-1.7">
       Egress failure:</dt>
        <dd id="section-3-1.8"> An egress node failure or an egress link failure.<a href="#section-3-1.8" class="pilcrow">¶</a>
</dd>
<dt id="section-3-1.9">
       Egress-protected tunnel:</dt>
        <dd id="section-3-1.10">A tunnel whose egress router is protected by a mechanism according to this framework. The egress router is hence called a protected egress router.<a href="#section-3-1.10" class="pilcrow">¶</a>
</dd>
<dt id="section-3-1.11">
       Egress-protected service:</dt>
        <dd id="section-3-1.12">An IP or MPLS service that is carried by an egress-protected tunnel and hence protected by a mechanism according to this framework.<a href="#section-3-1.12" class="pilcrow">¶</a>
</dd>
<dt id="section-3-1.13">
       Backup egress router:</dt>
        <dd id="section-3-1.14">Given an egress-protected tunnel and its egress router, this is another router that has connectivity with all or a subset of the destinations of the egress-protected services carried by the egress-protected tunnel.<a href="#section-3-1.14" class="pilcrow">¶</a>
</dd>
<dt id="section-3-1.15">
       Backup service instance:</dt>
        <dd id="section-3-1.16">A service instance that is hosted by a backup egress router and corresponds to an egress-protected service on a protected egress router.<a href="#section-3-1.16" class="pilcrow">¶</a>
</dd>
<dt id="section-3-1.17">
       Protector:</dt>
        <dd id="section-3-1.18">A role acted by a router as an alternate of a protected egress router, to handle service packets in the event of an egress failure. A protector may be physically co-located with or decoupled from a backup egress router, depending on the co-located or centralized protector mode.<a href="#section-3-1.18" class="pilcrow">¶</a>
</dd>
<dt id="section-3-1.19">
       Protection service instance:</dt>
        <dd id="section-3-1.20">A service instance hosted by a protector that corresponds to the service instance of an egress-protected service on a protected egress router. A protection service instance is a backup service instance, if the protector is co-located with a backup egress router.<a href="#section-3-1.20" class="pilcrow">¶</a>
</dd>
<dt id="section-3-1.21">
       PLR:</dt>
        <dd id="section-3-1.22"> A router at the point of local repair. In egress node protection, it is the penultimate hop router on an egress-protected tunnel. In egress link protection, it is the egress router of the egress-protected tunnel.<a href="#section-3-1.22" class="pilcrow">¶</a>
</dd>
<dt id="section-3-1.23">
       Protected egress {E, P}:</dt>
        <dd id="section-3-1.24"> A virtual node consisting of an ordered pair of egress router E and protector P. It serves as the virtual destination of an egress-protected tunnel and as the virtual location of the egress-protected services carried by the tunnel.<a href="#section-3-1.24" class="pilcrow">¶</a>
</dd>
<dt id="section-3-1.25">
       Context identifier (ID):</dt>
        <dd id="section-3-1.26">A globally unique IP address assigned to a protected egress {E, P}.<a href="#section-3-1.26" class="pilcrow">¶</a>
</dd>
<dt id="section-3-1.27">
       Context label:</dt>
        <dd id="section-3-1.28">A non-reserved label assigned to a context ID by a protector.<a href="#section-3-1.28" class="pilcrow">¶</a>
</dd>
<dt id="section-3-1.29">
       Egress-protection bypass tunnel:</dt>
        <dd id="section-3-1.30">A tunnel used to reroute service packets around an egress failure.<a href="#section-3-1.30" class="pilcrow">¶</a>
</dd>
<dt id="section-3-1.31">
       Co-located protector mode:</dt>
        <dd id="section-3-1.32">The scenario where a protector and a backup egress router are co-located as one router; hence, each backup service instance serves as a protection service instance.<a href="#section-3-1.32" class="pilcrow">¶</a>
</dd>
<dt id="section-3-1.33">
       Centralized protector mode:</dt>
        <dd id="section-3-1.34">The scenario where a protector is a dedicated router and is decoupled from backup egress routers.<a href="#section-3-1.34" class="pilcrow">¶</a>
</dd>
<dt id="section-3-1.35">
       Context label switching:</dt>
        <dd id="section-3-1.36">Label switching performed by a protector in the label space of an egress router indicated by a context label.<a href="#section-3-1.36" class="pilcrow">¶</a>
</dd>
<dt id="section-3-1.37">
       Context IP forwarding:</dt>
        <dd id="section-3-1.38">IP forwarding performed by a protector in the IP address space of an egress router indicated by a context label.<a href="#section-3-1.38" class="pilcrow">¶</a>
</dd>
</dl>
</section>
</div>
<div id="req">
<section id="section-4">
      <h2 id="name-requirements">
<a href="#section-4" class="section-number selfRef">4. </a><a href="#name-requirements" class="section-name selfRef">Requirements</a>
      </h2>
<p id="section-4-1">
       This document considers the following as the design requirements of this egress protection framework.<a href="#section-4-1" class="pilcrow">¶</a></p>
<ul>
<li id="section-4-2.1">
    The framework must support P2P tunnels. It should equally support P2MP, MP2P, and MP2MP tunnels, by treating each sub-LSP as a P2P tunnel.<a href="#section-4-2.1" class="pilcrow">¶</a>
</li>
        <li id="section-4-2.2">
    The framework must support multi-service and multi-transport networks. It must accommodate existing and future signaling and label-distribution protocols of tunnels and bypass tunnels, including RSVP, LDP, BGP, IGP, Segment Routing, and others. It must also accommodate existing and future IP/MPLS services, including Layer 2 VPNs, Layer 3 VPNs, hierarchical LSP, and others. It <span class="bcp14">MUST</span> provide a general solution for networks where different types of services and tunnels co-exist.<a href="#section-4-2.2" class="pilcrow">¶</a>
</li>
        <li id="section-4-2.3">
    The framework must consider minimizing disruption during deployment. It should only involve routers close to the egress and be transparent to ingress routers and other transit routers.<a href="#section-4-2.3" class="pilcrow">¶</a>
</li>
        <li id="section-4-2.4">
    In egress node protection, for scalability and performance reasons, a PLR must be agnostic to services and service labels. It must maintain bypass tunnels and bypass forwarding state on a per-transport-tunnel basis rather than on a per-service-destination or per-service-label basis. It should also support bypass tunnel sharing between transport tunnels.<a href="#section-4-2.4" class="pilcrow">¶</a>
</li>
        <li id="section-4-2.5">
    A PLR must be able to use its local visibility or information of routing or TE topology to compute or resolve a path for a bypass tunnel.<a href="#section-4-2.5" class="pilcrow">¶</a>
</li>
        <li id="section-4-2.6">
    A protector must be able to perform context label switching for rerouted MPLS service packets, based on a service label(s) assigned by an egress router. It must be able to perform context IP forwarding for rerouted IP service packets, in the public or private IP address space used by an egress router.<a href="#section-4-2.6" class="pilcrow">¶</a>
</li>
        <li id="section-4-2.7">
    The framework must be able to work seamlessly with transit link/node protection mechanisms to achieve end-to-end coverage.<a href="#section-4-2.7" class="pilcrow">¶</a>
</li>
        <li id="section-4-2.8">
    The framework must be able to work in conjunction with global repair and control-plane convergence.<a href="#section-4-2.8" class="pilcrow">¶</a>
</li>
      </ul>
</section>
</div>
<div id="egress-node-protection">
<section id="section-5">
      <h2 id="name-egress-node-protection">
<a href="#section-5" class="section-number selfRef">5. </a><a href="#name-egress-node-protection" class="section-name selfRef">Egress Node Protection</a>
      </h2>
<div id="ref-topo">
<section id="section-5.1">
        <h3 id="name-reference-topology">
<a href="#section-5.1" class="section-number selfRef">5.1. </a><a href="#name-reference-topology" class="section-name selfRef">Reference Topology</a>
        </h3>
<p id="section-5.1-1">
  This document refers to the following topology when describing the procedures of egress node protection.<a href="#section-5.1-1" class="pilcrow">¶</a></p>
<div id="Figure-1">
<figure id="figure-1">
          <div class="artwork art-text alignCenter art-ascii-art" id="section-5.1-2.1">
<pre>
               services 1, ..., N
     =====================================&gt; tunnel
                                                 
   I ------ R1 ------- PLR --------------- E ----
ingress          penultimate hop        egress    \
                        |  .           (primary    \    
                        |  .            service     \
                        |  .            instances )  \
                        |  .                          \
                        |  .                           \   service
                        |  .                             destinations
                        |  .                           / (CEs, sites)
                        |  .                          /
                        |  . bypass                  /
                        |  . tunnel                 /
                        |  .                       /
                        |  ...............        /
                        R2 --------------- P ----
                                       protector
                                      (protection
                                       service
                                       instances) </pre>
</div>
<figcaption><a href="#figure-1" class="selfRef">Figure 1</a></figcaption></figure>
</div>
</section>
</div>
<div id="egress-node-failure">
<section id="section-5.2">
        <h3 id="name-egress-node-failure-and-det">
<a href="#section-5.2" class="section-number selfRef">5.2. </a><a href="#name-egress-node-failure-and-det" class="section-name selfRef">Egress Node Failure and Detection</a>
        </h3>
<p id="section-5.2-1">
  An egress node failure refers to the failure of an MPLS tunnel's egress router. At the service level, it is also a service instance failure for each IP/MPLS service carried by the tunnel.<a href="#section-5.2-1" class="pilcrow">¶</a></p>
<p id="section-5.2-2">
  An egress node failure can be detected by an adjacent router (i.e., PLR in this framework) through a node liveness detection mechanism or a mechanism based on a collective failure of all the links to that node. The mechanisms <span class="bcp14">MUST</span> be reasonably fast, i.e., faster than control-plane failure detection and remote failure detection. Otherwise, local repair will not be able to provide much benefit compared to control-plane convergence or global repair. In general, the speed, accuracy, and reliability of a failure detection mechanism are the key factors to decide its applicability in egress node protection. This document provides the following guidelines for network operators to choose a proper type of protection on a PLR.<a href="#section-5.2-2" class="pilcrow">¶</a></p>
<ul>
<li id="section-5.2-3.1">
      If the PLR has a mechanism to detect and differentiate a link failure (of the link between the PLR and the egress node) and an egress node failure, it <span class="bcp14">SHOULD</span> set up both link protection and egress node protection and trigger one and only one protection upon a corresponding failure.<a href="#section-5.2-3.1" class="pilcrow">¶</a>
</li>
          <li id="section-5.2-3.2">
            <p id="section-5.2-3.2.1">
      If the PLR has a fast mechanism to detect a link failure and an egress node failure, but it cannot distinguish them, or if the PLR has a fast mechanism to detect a link failure only, but not an egress node failure, the PLR has two options:<a href="#section-5.2-3.2.1" class="pilcrow">¶</a></p>
<ol start="1" type="1" class="normal" id="section-5.2-3.2.2">
              <li id="section-5.2-3.2.2.1">
  It <span class="bcp14">MAY</span> set up link protection only and leave the egress node failure to be handled by global repair and control-plane convergence.<a href="#section-5.2-3.2.2.1" class="pilcrow">¶</a>
</li>
              <li id="section-5.2-3.2.2.2">
  It <span class="bcp14">MAY</span> set up egress node protection only and treat a link failure as a trigger for the egress node protection. The assumption is that treating a link failure as an egress node failure <span class="bcp14">MUST NOT</span> have a negative impact on services. Otherwise, it <span class="bcp14">SHOULD</span> adopt the previous option.<a href="#section-5.2-3.2.2.2" class="pilcrow">¶</a>
</li>
            </ol>
</li>
        </ul>
</section>
</div>
<div id="protector">
<section id="section-5.3">
        <h3 id="name-protector-and-plr">
<a href="#section-5.3" class="section-number selfRef">5.3. </a><a href="#name-protector-and-plr" class="section-name selfRef">Protector and PLR</a>
        </h3>
<p id="section-5.3-1">
  A router is assigned to the "protector" role to protect a tunnel and the services carried by the tunnel against an egress node failure. The protector is responsible for hosting a protection service instance for each protected service, serving as the tail end of a bypass tunnel, and performing context label switching and/or context IP forwarding for rerouted service packets.<a href="#section-5.3-1" class="pilcrow">¶</a></p>
<p id="section-5.3-2">
  A tunnel is protected by only one protector. Multiple tunnels to a given egress router may be protected by a common protector or different protectors. A protector may protect multiple tunnels with a common egress router or different egress routers.<a href="#section-5.3-2" class="pilcrow">¶</a></p>
<p id="section-5.3-3">
  For each tunnel, its penultimate hop router acts as a PLR. The PLR pre-establishes a bypass tunnel to the protector and pre-installs bypass forwarding state in the data plane. Upon detection of an egress node failure, the PLR reroutes all the service packets received on the tunnel through the bypass tunnel to the protector. For MPLS service packets, the PLR keeps service labels intact in the packets. In turn, the protector forwards the service packets towards the ultimate service destinations. Specifically, it performs context label switching for MPLS service packets, based on the service labels assigned by the protected egress router; it performs context IP forwarding for IP service packets, based on their destination addresses.<a href="#section-5.3-3" class="pilcrow">¶</a></p>
<p id="section-5.3-4">
  The protector <span class="bcp14">MUST</span> have its own connectivity with each service destination, via a direct link or a multi-hop path, which <span class="bcp14">MUST NOT</span> traverse the protected egress router or be affected by the egress node failure. This also means that each service destination <span class="bcp14">MUST</span> be dual-homed or have dual paths to the egress router and a backup egress router that may serve as the protector. Each protection service instance on the protector relies on such connectivity to set up forwarding state for context label switching and context IP forwarding.<a href="#section-5.3-4" class="pilcrow">¶</a></p>
</section>
</div>
<div id="protected-egress">
<section id="section-5.4">
        <h3 id="name-protected-egress">
<a href="#section-5.4" class="section-number selfRef">5.4. </a><a href="#name-protected-egress" class="section-name selfRef">Protected Egress</a>
        </h3>
<p id="section-5.4-1">
  This document introduces the notion of "protected egress" as a virtual node consisting of the egress router E of a tunnel and a protector P. It is denoted by an ordered pair of {E, P}, indicating the primary-and-protector relationship between the two routers. It serves as the virtual destination of the tunnel and the virtual location of service instances for the services carried by the tunnel. The tunnel and services are considered as being "associated" with the protected egress {E, P}.<a href="#section-5.4-1" class="pilcrow">¶</a></p>
<p id="section-5.4-2">
       A given egress router E may be the tail end of multiple tunnels. In general, the tunnels may be protected by multiple protectors, e.g., P1, P2, and so on, with each Pi protecting a subset of the tunnels. Thus, these routers form multiple protected egresses, i.e., {E, P1}, {E, P2}, and so on. Each tunnel is associated with one and only one protected egress {E, Pi}.  All the services carried by the tunnel are then automatically associated with the protected egress {E, Pi}. Conversely, a service associated with a protected egress {E, Pi} <span class="bcp14">MUST</span> be carried by a tunnel associated with the protected egress {E, Pi}. This mapping <span class="bcp14">MUST</span> be ensured by the ingress router of the tunnel and the service (<a href="#ep-tunnel-service" class="xref">Section 5.5</a>).<a href="#section-5.4-2" class="pilcrow">¶</a></p>
<p id="section-5.4-3">
  The two routers X and Y may be protectors for each other. In this case, they form two distinct protected egresses: {X, Y} and {Y, X}.<a href="#section-5.4-3" class="pilcrow">¶</a></p>
</section>
</div>
<div id="ep-tunnel-service">
<section id="section-5.5">
        <h3 id="name-egress-protected-tunnel-and">
<a href="#section-5.5" class="section-number selfRef">5.5. </a><a href="#name-egress-protected-tunnel-and" class="section-name selfRef">Egress-Protected Tunnel and Service</a>
        </h3>
<p id="section-5.5-1">
  A tunnel, which is associated with a protected egress {E, P}, is called an egress-protected tunnel. It is associated with one and only one protected egress {E, P}.  Multiple egress-protected tunnels may be associated with a given protected egress {E, P}.  In this case, they share the common egress router and protector, but they may or may not share a common ingress router or a common PLR (i.e., penultimate hop router).<a href="#section-5.5-1" class="pilcrow">¶</a></p>
<p id="section-5.5-2">
  An egress-protected tunnel is considered as logically "destined" for its protected egress {E, P}.  Its path <span class="bcp14">MUST</span> be resolved and established with E as the physical tail end.<a href="#section-5.5-2" class="pilcrow">¶</a></p>
<p id="section-5.5-3">
  A service, which is associated with a protected egress {E, P}, is called an egress-protected service. Egress router E hosts the primary instance of the service, and protector P hosts the protection instance of the service.<a href="#section-5.5-3" class="pilcrow">¶</a></p>
<p id="section-5.5-4">
  An egress-protected service is associated with one and only one protected egress {E, P}.  Multiple egress-protected services may be associated with a given protected egress {E, P}.  In this case, these services share the common egress router and protector, but they may or may not be carried by a common egress-protected tunnel or a common ingress router.<a href="#section-5.5-4" class="pilcrow">¶</a></p>
<p id="section-5.5-5"> 
  An egress-protected service <span class="bcp14">MUST</span> be mapped to an egress-protected tunnel by its ingress router, based on the common protected egress {E, P} of the service and the tunnel. This is achieved by introducing the notion of a "context ID" for a protected egress {E, P}, as described in <a href="#cid" class="xref">Section 5.7</a>.<a href="#section-5.5-5" class="pilcrow">¶</a></p>
</section>
</div>
<div id="ep-bypass">
<section id="section-5.6">
        <h3 id="name-egress-protection-bypass-tu">
<a href="#section-5.6" class="section-number selfRef">5.6. </a><a href="#name-egress-protection-bypass-tu" class="section-name selfRef">Egress-Protection Bypass Tunnel</a>
        </h3>
<p id="section-5.6-1">
  An egress-protected tunnel destined for a protected egress {E, P} <span class="bcp14">MUST</span> have a bypass tunnel from its PLR to protector P. This bypass tunnel is called an egress-protection bypass tunnel. The bypass tunnel is considered as logically "destined" for the protected egress {E, P}. Due to its bypass nature, it <span class="bcp14">MUST</span> be established with P as the physical tail end and E as the node to avoid.

The bypass tunnel <span class="bcp14">MUST NOT</span> be affected by the topology change caused by an egress node failure; thus, it <span class="bcp14">MUST</span> contain a property that protects it from this scenario.<a href="#section-5.6-1" class="pilcrow">¶</a></p>
<p id="section-5.6-2">
  An egress-protection bypass tunnel is associated with one and only one protected egress {E, P}. A PLR may share an egress-protection bypass tunnel for multiple egress-protected tunnels associated with a common protected egress {E, P}.<a href="#section-5.6-2" class="pilcrow">¶</a></p>
</section>
</div>
<div id="cid">
<section id="section-5.7">
        <h3 id="name-context-id-context-label-an">
<a href="#section-5.7" class="section-number selfRef">5.7. </a><a href="#name-context-id-context-label-an" class="section-name selfRef">Context ID, Context Label, and Context-Based Forwarding</a>
        </h3>
<p id="section-5.7-1"> 
  In this framework, a globally unique IPv4 or IPv6 address is assigned as the identifier of the protected egress {E, P}. It is called a "context ID" due to its specific usage in context label switching and context IP forwarding on the protector. It is an IP address that is logically owned by both the egress router and the protector. For the egress router, it indicates the protector. For the protector, it indicates the egress router, particularly the egress router's forwarding context. For other routers in the network, it is an address reachable via both the egress router and the protector (<a href="#adv" class="xref">Section 5.8</a>), similar to an anycast address.<a href="#section-5.7-1" class="pilcrow">¶</a></p>
<p id="section-5.7-2">
  The main purpose of a context ID is to coordinate the ingress router, egress router, PLR, and protector to establish egress protection. The procedures are described below, given an egress-protected service associated with a protected egress {E, P} with a context ID.<a href="#section-5.7-2" class="pilcrow">¶</a></p>
<ul>
<li id="section-5.7-3.1">
      If the service is an MPLS service, when E distributes a service label binding message to the ingress router, E attaches the context ID to the message. If the service is an IP service, when E advertises the service destination address to the ingress router, E attaches the context ID to the advertisement message. The service protocol chooses how the context ID is encoded in the messages. A protocol extension of a "context ID" object may be needed, if there is no existing mechanism for this purpose.<a href="#section-5.7-3.1" class="pilcrow">¶</a>
</li>
          <li id="section-5.7-3.2">
      The ingress router uses the service's context ID as the destination to establish or resolve an egress-protected tunnel. The ingress router then maps the service to the tunnel for transportation. The semantics of the context ID is transparent to the ingress router. The ingress router only treats the context ID as an IP address of E, in the same manner as establishing or resolving a regular transport tunnel.<a href="#section-5.7-3.2" class="pilcrow">¶</a>
</li>
          <li id="section-5.7-3.3">
      The context ID is conveyed to the PLR by the signaling protocol of the egress-protected tunnel or learned by the PLR via an IGP (i.e., OSPF or IS-IS) or a topology-driven label distribution protocol (e.g., LDP). The PLR uses the context ID as the destination to establish or resolve an egress-protection bypass tunnel to P while avoiding E.<a href="#section-5.7-3.3" class="pilcrow">¶</a>
</li>
          <li id="section-5.7-3.4">
      P maintains a dedicated label space and a dedicated IP address space for E. They are referred to as "E's label space" and "E's IP address space", respectively. P uses the context ID to identify the label space and IP address space.<a href="#section-5.7-3.4" class="pilcrow">¶</a>
</li>
          <li id="section-5.7-3.5">
      If the service is an MPLS service, E also distributes the service label binding message to P. This is the same label binding message that E advertises to the ingress router, which includes the context ID. Based on the context ID, P installs the service label in an MPLS forwarding table corresponding to E's label space. If the service is an IP service, P installs an IP route in an IP forwarding table corresponding to E's IP address space. In either case, the protection service instance on P constructs the forwarding state for the label route or IP route based on P's own connectivity with the service's destination.<a href="#section-5.7-3.5" class="pilcrow">¶</a>
</li>
          <li id="section-5.7-3.6">
      P assigns a non-reserved label to the context ID. In the data plane, this label represents the context ID and indicates E's label space and IP address space. Therefore, it is called a "context label".<a href="#section-5.7-3.6" class="pilcrow">¶</a>
</li>
          <li id="section-5.7-3.7">
      The PLR may establish the egress-protection bypass tunnel to P in several manners. If the bypass tunnel is established by RSVP, the PLR signals the bypass tunnel with the context ID as the destination, and P binds the context label to the bypass tunnel. If the bypass tunnel is established by LDP, P advertises the context label for the context ID as an IP prefix Forwarding
   Equivalence Class (FEC). If the bypass tunnel is established by the PLR in a hierarchical manner, the PLR treats the context label as a one-hop LSP over a regular bypass tunnel to P (e.g., a bypass tunnel to P's loopback IP address). If the bypass tunnel is constructed by using Segment Routing, the bypass tunnel is represented by a stack of Segment Identifier (SID) labels with the context label as the inner-most SID label (<a href="#bypass-estb" class="xref">Section 5.9</a>). In any case, the bypass tunnel is an ultimate hop-popping (UHP) tunnel whose incoming label on P is the context label.<a href="#section-5.7-3.7" class="pilcrow">¶</a>
</li>
          <li id="section-5.7-3.8">
      During local repair, all the service packets received by P on the bypass tunnel have the context label as the top label. P first pops the context label. For an MPLS service packet, P looks up the service label in E's label space indicated by the context label. Such kind of forwarding is called context label switching. For an IP service packet, P looks up the IP destination address in E's IP address space indicated by the context label. Such kind of forwarding is called context IP forwarding.<a href="#section-5.7-3.8" class="pilcrow">¶</a>
</li>
        </ul>
</section>
</div>
<div id="adv">
<section id="section-5.8">
        <h3 id="name-advertisement-and-path-reso">
<a href="#section-5.8" class="section-number selfRef">5.8. </a><a href="#name-advertisement-and-path-reso" class="section-name selfRef">Advertisement and Path Resolution for Context ID</a>
        </h3>
<p id="section-5.8-1">
  Path resolution and computation for a context ID are done on ingress routers for egress-protected tunnels and on PLRs for egress-protection bypass tunnels. Given a protected egress {E, P} and its context ID, E and P <span class="bcp14">MUST</span> coordinate on the reachability of the context ID in the routing domain and the TE domain. The context ID <span class="bcp14">MUST</span> be advertised in such a manner that all egress-protected tunnels <span class="bcp14">MUST</span> have E as the tail end, and all egress-protection bypass tunnels <span class="bcp14">MUST</span> have P as the tail end while avoiding E.<a href="#section-5.8-1" class="pilcrow">¶</a></p>
<p id="section-5.8-2">
  This document suggests three approaches:<a href="#section-5.8-2" class="pilcrow">¶</a></p>
<ul class="ulEmpty">
<li class="ulEmpty" id="section-5.8-3.1">
            <ol start="1" type="1" class="normal" id="section-5.8-3.1.1">
              <li id="section-5.8-3.1.1.1">
      The first approach is called "proxy mode". It requires E and P, but not the PLR, to have the knowledge of the egress protection schema. E and P advertise the context ID as a virtual proxy node (i.e., a logical node) connected to the two routers, with the link between the proxy node and E having more preferable IGP and TE metrics than the link between the proxy node and P. Therefore, all egress-protected tunnels destined for the context ID will automatically follow the IGP or TE paths to E. Each PLR will no longer view itself as a penultimate hop but rather as two hops away from the proxy node, via E. The PLR will be able to find a bypass path via P to the proxy node, while the bypass tunnel is actually terminated by P.<a href="#section-5.8-3.1.1.1" class="pilcrow">¶</a>
</li>
              <li id="section-5.8-3.1.1.2">
      The second approach is called "alias mode". It requires P and the
PLR, but not E, to have the knowledge of the egress protection schema. E simply
advertises the context ID as an IP address. P advertises the context ID and the
context label by using a "context ID label binding" advertisement. In both
the routing domain and TE domain, the context ID is only reachable via
E. Therefore, all egress-protected tunnels destined for the context ID will
have E as the tail end. Based on the "context ID label binding" advertisement, the
PLR can establish an egress-protection bypass tunnel in several manners (<a href="#bypass-estb" class="xref">Section 5.9</a>). The "context ID label binding" advertisement is
defined as the IGP Mirroring Context segment in <span>[<a href="#RFC8402" class="xref">RFC8402</a>]</span> and <span>[<a href="#RFC8667" class="xref">RFC8667</a>]</span>. These IGP extensions are generic in nature and hence can be used for egress protection purposes. It is <span class="bcp14">RECOMMENDED</span> that a similar advertisement be defined for OSPF as well.<a href="#section-5.8-3.1.1.2" class="pilcrow">¶</a>
</li>
              <li id="section-5.8-3.1.1.3">
      The third approach is called "stub link mode". In this mode, both E and P advertise the context ID as a link to a stub network, essentially modeling the context ID as an anycast IP address owned by the two routers. E, P, and the PLR do not need to have the knowledge of the egress protection schema. The correctness of the egress-protected tunnels and the bypass tunnels relies on the path computations for the anycast IP address performed by the ingress routers and PLR. Therefore, care <span class="bcp14">MUST</span> be taken for the applicability of this approach to a network.<a href="#section-5.8-3.1.1.3" class="pilcrow">¶</a>
</li>
            </ol>
</li>
        </ul>
<p id="section-5.8-4">
  This framework considers the above approaches as technically equal and the feasibility of each approach in a given network as dependent on the topology, manageability, and available protocols of the network. For a given context ID, all relevant routers, including the primary PE, protector, and PLR, <span class="bcp14">MUST</span> support and agree on the chosen approach. The coordination between these routers can be achieved by configuration.<a href="#section-5.8-4" class="pilcrow">¶</a></p>
<p id="section-5.8-5">
  In a scenario where an egress-protected tunnel is an inter-area or inter-Autonomous-System (inter-AS) tunnel, its associated context ID <span class="bcp14">MUST</span> be propagated by IGP or BGP from the original area or AS to the area or AS of the ingress router. The propagation process of the context ID <span class="bcp14">SHOULD</span> be the same as that of an IP address in an inter-area or inter-AS environment.<a href="#section-5.8-5" class="pilcrow">¶</a></p>
</section>
</div>
<div id="bypass-estb">
<section id="section-5.9">
        <h3 id="name-egress-protection-bypass-tun">
<a href="#section-5.9" class="section-number selfRef">5.9. </a><a href="#name-egress-protection-bypass-tun" class="section-name selfRef">Egress-Protection Bypass Tunnel Establishment</a>
        </h3>
<p id="section-5.9-1">
  A PLR <span class="bcp14">MUST</span> know the context ID of a protected egress {E, P} in order to establish an egress-protection bypass tunnel. The information is obtained from the signaling or label distribution protocol of the egress-protected tunnel. The PLR may or may not need to have the knowledge of the egress-protection schema. All it does is set up a bypass tunnel to a context ID while avoiding the next-hop router (i.e., egress router). This is achievable by using a constraint-based computation algorithm similar to those commonly used for traffic engineering paths and Loop-Free Alternate (LFA) paths. Since the context ID is advertised in the routing domain and in the TE domain by IGP according to <a href="#adv" class="xref">Section 5.8</a>, the PLR is able to resolve or establish such a bypass path with the protector as the tail end. In the case of proxy mode, the PLR may do so in the same manner as transit node protection.<a href="#section-5.9-1" class="pilcrow">¶</a></p>
<p id="section-5.9-2">
  An egress-protection bypass tunnel may be established via several methods:<a href="#section-5.9-2" class="pilcrow">¶</a></p>
<ul class="ulEmpty">
<li class="ulEmpty" id="section-5.9-3.1">
            <ol start="1" type="1" class="normal" id="section-5.9-3.1.1">
              <li id="section-5.9-3.1.1.1">It may be established by a signaling protocol (e.g., RSVP), with the context ID as the destination. The protector binds the context label to the bypass tunnel.<a href="#section-5.9-3.1.1.1" class="pilcrow">¶</a>
</li>
              <li id="section-5.9-3.1.1.2"> It may be formed by a topology-driven protocol (e.g., LDP with various LFA mechanisms). The protector advertises the context ID as an IP prefix FEC, with the context label bound to it.<a href="#section-5.9-3.1.1.2" class="pilcrow">¶</a>
</li>
              <li id="section-5.9-3.1.1.3">It may be constructed as a hierarchical tunnel. When the protector uses the alias mode (<a href="#adv" class="xref">Section 5.8</a>), the PLR will have the knowledge of the context ID, context label, and protector (i.e., the advertiser). The PLR can then establish the bypass tunnel in a hierarchical manner, with the context label as a one-hop LSP over a regular bypass tunnel to the protector's IP address (e.g., loopback address). This regular bypass tunnel may be established by RSVP, LDP, Segment Routing, or another protocol.<a href="#section-5.9-3.1.1.3" class="pilcrow">¶</a>
</li>
            </ol>
</li>
        </ul>
</section>
</div>
<div id="local-repair">
<section id="section-5.10">
        <h3 id="name-local-repair-on-plr">
<a href="#section-5.10" class="section-number selfRef">5.10. </a><a href="#name-local-repair-on-plr" class="section-name selfRef">Local Repair on PLR</a>
        </h3>
<p id="section-5.10-1">
  In this framework, a PLR is agnostic to services and service labels. This obviates the need to maintain bypass forwarding state on a per-service basis and allows bypass tunnel sharing between egress-protected tunnels. The PLR may share an egress-protection bypass tunnel for multiple egress-protected tunnels associated with a common protected egress {E, P}. During local repair, the PLR reroutes all service packets received on the egress-protected tunnels to the egress-protection bypass tunnel. Service labels remain intact in MPLS service packets.<a href="#section-5.10-1" class="pilcrow">¶</a></p>
<p id="section-5.10-2">
  Label operation performed by the PLR depends on the bypass tunnel's characteristics. If the bypass tunnel is a single level tunnel, the rerouting will involve swapping the incoming label of an egress-protected tunnel to the outgoing label of the bypass tunnel. If the bypass tunnel is a hierarchical tunnel, the rerouting will involve swapping the incoming label of an egress-protected tunnel to a context label and pushing the outgoing label of a regular bypass tunnel. If the bypass tunnel is constructed by Segment Routing, the rerouting will involve swapping the incoming label of an egress-protected tunnel to a context label and pushing the stack of SID labels of the bypass tunnel.<a href="#section-5.10-2" class="pilcrow">¶</a></p>
</section>
</div>
<div id="upstream-label-distrib">
<section id="section-5.11">
        <h3 id="name-service-label-distribution-">
<a href="#section-5.11" class="section-number selfRef">5.11. </a><a href="#name-service-label-distribution-" class="section-name selfRef">Service Label Distribution from Egress Router to Protector</a>
        </h3>
<p id="section-5.11-1">
  When a protector receives a rerouted MPLS service packet, it performs context label switching based on the packet's service label, which is assigned by the corresponding egress router. In order to achieve this, the protector <span class="bcp14">MUST</span> maintain the labels of egress-protected services in dedicated label spaces on a per-protected-egress {E, P} basis, i.e., one label space for each egress router that it protects.<a href="#section-5.11-1" class="pilcrow">¶</a></p>
<p id="section-5.11-2">
  Also, there <span class="bcp14">MUST</span> be a service label distribution protocol session between each egress router and the protector. Through this protocol, the protector learns the label binding of each egress-protected service. This is the same label binding that the egress router advertises to the service's ingress router, which includes a context ID. The corresponding protection service instance on the protector recognizes the service and resolves forwarding state based on its own connectivity with the service's destination. It then installs the service label with the forwarding state in the label space of the egress router, which is indicated by the context ID (i.e., context label).<a href="#section-5.11-2" class="pilcrow">¶</a></p>
<p id="section-5.11-3">
  Different service protocols may use different mechanisms for such kind
of label distribution. Specific extensions may be needed on a per-protocol
or per-service-type basis. The details of the extensions should be
specified in separate documents. As an example, the LDP extensions for pseudowire services are specified in <span>[<a href="#RFC8104" class="xref">RFC8104</a>]</span>.<a href="#section-5.11-3" class="pilcrow">¶</a></p>
</section>
</div>
<div id="centralized">
<section id="section-5.12">
        <h3 id="name-centralized-protector-mode">
<a href="#section-5.12" class="section-number selfRef">5.12. </a><a href="#name-centralized-protector-mode" class="section-name selfRef">Centralized Protector Mode</a>
        </h3>
<p id="section-5.12-1">
  In this framework, it is assumed that the service destination of an egress-protected service <span class="bcp14">MUST</span> be dual-homed to two edge routers of an MPLS network. One of them is the protected egress router, and the other is a backup egress router. So far in this document, the focus of discussion has been on the scenario where a protector and a backup egress router are co-located as one router. Therefore, the number of protectors in a network is equal to the number of backup egress routers. As another scenario, a network may assign a small number of routers to serve as dedicated protectors, each protecting a subset of egress routers. These protectors are called centralized protectors.<a href="#section-5.12-1" class="pilcrow">¶</a></p>
<p id="section-5.12-2">
  Topologically, a centralized protector may be decoupled from all backup egress routers, or it may be co-located with one backup egress router while decoupled from the other backup egress routers. The procedures in this section assume that a protector and a backup egress router are decoupled.<a href="#section-5.12-2" class="pilcrow">¶</a></p>
<div id="Figure-2">
<figure id="figure-2">
          <div class="artwork art-text alignCenter art-ascii-art" id="section-5.12-3.1">
<pre>
               services 1, ..., N
     =====================================&gt; tunnel
                                                 
   I ------ R1 ------- PLR --------------- E ----
ingress          penultimate hop        egress    \
                        |  .           (primary    \    
                        |  .            service     \
                        |  .            instances)   \
                        |  .                          \
                        |  . bypass                    \   service
                       R2  . tunnel                      destinations
                        |  .                           / (CEs, sites)
                        |  .                          /
                        |  .                         /
                        |  .                        /
                        |  .    tunnel             /
                        |   =============&gt;        /
                        P ---------------- E' ---
                    protector        backup egress
                   (protection         (backup
                    service             service
                    instances)          instances) </pre>
</div>
<figcaption><a href="#figure-2" class="selfRef">Figure 2</a></figcaption></figure>
</div>
<p id="section-5.12-4">
  Like a co-located protector, a centralized protector hosts protection service instances, receives rerouted service packets from PLRs, and performs context label switching and/or context IP forwarding. For each service, instead of sending service packets directly to the service destination, the protector <span class="bcp14">MUST</span> send them via another transport tunnel to the corresponding backup service instance on a backup egress router. The backup service instance in turn forwards the service packets to the service destination. Specifically, if the service is an MPLS service, the protector <span class="bcp14">MUST</span> swap the service label in each received service packet to the label of the backup service advertised by the backup egress router, and then push the label (or label stack) of the transport tunnel.<a href="#section-5.12-4" class="pilcrow">¶</a></p>
<p id="section-5.12-5">
  In order for a centralized protector to map an egress-protected MPLS service to a service hosted on a backup egress router, there <span class="bcp14">MUST</span> be a service label distribution protocol session between the backup egress router and the protector. Through this session, the backup egress router advertises the service label of the backup service, attached with the FEC of the egress-protected service and the context ID of the protected egress {E, P}. Based on this information, the protector associates the egress-protected service with the backup service, resolves or establishes a transport tunnel to the backup egress router, and sets up forwarding state for the label of the egress-protected service in the label space of the egress router.<a href="#section-5.12-5" class="pilcrow">¶</a></p>
<p id="section-5.12-6">
  The service label that the backup egress router advertises to the protector can be the same as the label that the backup egress router advertises to the ingress router(s), if and only if the forwarding state of the label does not direct service packets towards the protected egress router. Otherwise, the label <span class="bcp14">MUST NOT</span> be used for egress protection, because it would create a loop for the service packets. In this case, the backup egress router <span class="bcp14">MUST</span> advertise a unique service label for egress protection and set up the forwarding state of the label to use the backup egress router's own connectivity with the service destination.<a href="#section-5.12-6" class="pilcrow">¶</a></p>
</section>
</div>
</section>
</div>
<div id="link-protection">
<section id="section-6">
      <h2 id="name-egress-link-protection">
<a href="#section-6" class="section-number selfRef">6. </a><a href="#name-egress-link-protection" class="section-name selfRef">Egress Link Protection</a>
      </h2>
<p id="section-6-1">
       Egress link protection is achievable through procedures similar to that of egress node protection. In normal situations, an egress router forwards service packets to a service destination based on a service label, whose forwarding state points to an egress link. In egress link protection, the egress router acts as the PLR and performs local failure detection and local repair. Specifically, the egress router pre-establishes an egress-protection bypass tunnel to a protector and sets up the bypass forwarding state for the service label to point to the bypass tunnel. During local repair, the egress router reroutes service packets via the bypass tunnel to the protector. The protector in turn forwards the packets to the service destination (in the co-located protector mode, as shown in <a href="#Figure-3" class="xref">Figure 3</a>) or forwards the packets to a backup egress router (in the centralized protector mode, as shown in <a href="#Figure-4" class="xref">Figure 4</a>).<a href="#section-6-1" class="pilcrow">¶</a></p>
<div id="Figure-3">
<figure id="figure-3">
        <div class="artwork art-text alignCenter art-ascii-art" id="section-6-2.1">
<pre>
                     service
     =====================================&gt; tunnel
                                                 
   I ------ R1 -------  R2 --------------- E ----
ingress                 |  ............. egress   \
                        |  .              PLR      \
                        |  .             (primary   \    
                        |  .              service    \
                        |  .              instance)   \
                        |  .                           \
                        |  . bypass                        service
                        |  . tunnel                      destination
                        |  .                           / (CE, site)
                        |  .                          /
                        |  .                         /
                        |  .                        /
                        |  .                       /
                        |  ...............        /
                        R3 --------------- P ----
                                       protector
                                      (protection
                                       service
                                       instance) </pre>
</div>
<figcaption><a href="#figure-3" class="selfRef">Figure 3</a></figcaption></figure>
</div>
<div id="Figure-4">
<figure id="figure-4">
        <div class="artwork art-text alignCenter art-ascii-art" id="section-6-3.1">
<pre>
                     service
     =====================================&gt; tunnel
                                                 
   I ------ R1 -------  R2 --------------- E ----
ingress                 |  ............. egress   \
                        |  .              PLR      \
                        |  .             (primary   \    
                        |  .              service    \
                        |  .              instance)   \
                        |  .                           \
                        |  . bypass                        service
                        |  . tunnel                      destination
                        |  .                           / (CE, site)
                        |  .                          /
                        |  .                         /
                        |  .                        /
                        |  .    tunnel             /
                        |   =============&gt;        /
                        R3 --------------- P ----
                    protector        backup egress
                   (protection      (backup
                    service          service
                    instance)        instance) </pre>
</div>
<figcaption><a href="#figure-4" class="selfRef">Figure 4</a></figcaption></figure>
</div>
<p id="section-6-4">
        There are two approaches for setting up the bypass forwarding state on the egress router, depending on whether the egress router knows the service label allocated by the backup egress router. The difference is that one approach requires the protector to perform context label switching, and the other one does not. Both approaches are equally supported by this framework.<a href="#section-6-4" class="pilcrow">¶</a></p>
<ul class="ulEmpty">
<li class="ulEmpty" id="section-6-5.1">
          <ol start="1" type="1" class="normal" id="section-6-5.1.1">
            <li id="section-6-5.1.1.1">The first approach applies when the egress router does not know the service label allocated by the backup egress router. In this case, the egress router sets up the bypass forwarding state as a label push with the outgoing label of the egress-protection bypass tunnel. Rerouted packets will have the egress router's service label intact. Therefore, the protector <span class="bcp14">MUST</span> perform context label switching, and the bypass tunnel <span class="bcp14">MUST</span> be destined for the context ID of the protected egress {E, P} and established as described in <a href="#bypass-estb" class="xref">Section 5.9</a>. This approach is consistent with egress node protection. Hence, a protector can serve in egress node protection and egress link protection in a consistent manner, and both the co-located protector mode and the centralized protector mode are supported (see Figures <a href="#Figure-3" class="xref">3</a> and <a href="#Figure-4" class="xref">4</a>).<a href="#section-6-5.1.1.1" class="pilcrow">¶</a>
</li>
            <li id="section-6-5.1.1.2"> The second approach applies when the egress router knows the service label allocated by the backup egress router, via a label distribution protocol session. In this case, the backup egress router serves as the protector for egress link protection, regardless of the protector of egress node protection, which will be the same router in the co-located protector mode but a different router in the centralized protector mode. The egress router sets up the bypass forwarding state as a label swap from the incoming service label to the service label of the backup egress router (i.e., protector), followed by a push with the outgoing label (or label stack) of the egress link protection bypass tunnel. The bypass tunnel is a regular tunnel destined for an IP address of the protector, instead of the context ID of the protected egress {E, P}. The protector simply forwards rerouted service packets based on its own service label rather than performing context label switching. In this approach, only the co-located protector mode is applicable.<a href="#section-6-5.1.1.2" class="pilcrow">¶</a>
</li>
          </ol>
</li>
      </ul>
<p id="section-6-6">
       Note that for a bidirectional service, the physical link of an egress link may carry service traffic bidirectionally. Therefore, an egress link failure may simultaneously be an ingress link failure for the traffic in the opposite direction. Protection for ingress link failure <span class="bcp14">SHOULD</span> be provided by a separate mechanism and hence is out of the scope of this document.<a href="#section-6-6" class="pilcrow">¶</a></p>
</section>
</div>
<section id="section-7">
      <h2 id="name-global-repair">
<a href="#section-7" class="section-number selfRef">7. </a><a href="#name-global-repair" class="section-name selfRef">Global Repair</a>
      </h2>
<p id="section-7-1">
       This framework provides a fast but temporary repair for egress node and egress link failures. For permanent repair, the services affected by a failure <span class="bcp14">SHOULD</span> be moved to an alternative tunnel, or replaced by alternative services, which are fully functional. This is referred to as global repair. Possible triggers of global repair include control-plane notifications of tunnel status and service status, end-to-end OAM and fault detection at the tunnel and service level, and others. The alternative tunnel and services may be pre-established in standby state or dynamically established as a result of the triggers or network protocol convergence.<a href="#section-7-1" class="pilcrow">¶</a></p>
</section>
<section id="section-8">
      <h2 id="name-operational-considerations">
<a href="#section-8" class="section-number selfRef">8. </a><a href="#name-operational-considerations" class="section-name selfRef">Operational Considerations</a>
      </h2>
<p id="section-8-1">
       When a PLR performs local repair, the router <span class="bcp14">SHOULD</span> generate an alert for the event. The alert may be logged locally for tracking purposes, or it may be sent to the operator at a management station. The communication channel and protocol between the PLR and the management station may vary depending on networks and are out of the scope of this document.<a href="#section-8-1" class="pilcrow">¶</a></p>
</section>
<section id="section-9">
      <h2 id="name-general-context-based-forwa">
<a href="#section-9" class="section-number selfRef">9. </a><a href="#name-general-context-based-forwa" class="section-name selfRef">General Context-Based Forwarding</a>
      </h2>
<p id="section-9-1">
       So far, this document has been focusing on the cases where service
       packets are MPLS or IP packets, and protectors perform context label
       switching or context IP forwarding. 


Although this should cover most common services, it is worth mentioning that the framework is also applicable to services or sub-modes of services where service packets are Layer 2 packets or encapsulated in non-IP and non-MPLS formats. The only specific in these cases is that a protector <span class="bcp14">MUST</span> perform context-based forwarding based on the Layer 2 table or corresponding lookup table, which is indicated by a context ID (i.e., context label).<a href="#section-9-1" class="pilcrow">¶</a></p>
</section>
<section id="section-10">
      <h2 id="name-example-layer-3-vpn-egress-">
<a href="#section-10" class="section-number selfRef">10. </a><a href="#name-example-layer-3-vpn-egress-" class="section-name selfRef">Example: Layer 3 VPN Egress Protection</a>
      </h2>
<p id="section-10-1">
       This section shows an example of egress protection for Layer 3 IPv4 and IPv6 VPNs.<a href="#section-10-1" class="pilcrow">¶</a></p>
<div id="Figure-5">
<figure id="figure-5">
        <div class="artwork art-text alignCenter art-ascii-art" id="section-10-2.1">
<pre>
                        ---------- R1 ----------- PE2 -
                       /          (PLR)          (PLR)  \
 (          )         /            |               |     (          )
 (          )        /             |               |     (          )
 (  site 1  )-- PE1 &lt;              |               R3    (  site 2  )
 (          )        \             |               |     (          )
 (          )         \            |               |     (          )
                       \           |               |    /
                        ---------- R2 ----------- PE3 -
                                              (protector) </pre>
</div>
<figcaption><a href="#figure-5" class="selfRef">Figure 5</a></figcaption></figure>
</div>
<p id="section-10-3">
       In this example, the core network is IPv4 and MPLS. Both of the IPv4 and IPv6 VPNs consist of sites 1 and 2. Site 1 is connected to PE1, and site 2 is dual-homed to PE2 and PE3. Site 1 includes an IPv4 subnet 203.0.113.64/26 and an IPv6 subnet 2001:db8:1:1::/64. Site 2 includes an IPv4 subnet 203.0.113.128/26 and an IPv6 subnet 2001:db8:1:2::/64. PE2 is the primary PE for site 2, and PE3 is the backup PE. Each of PE1, PE2, and PE3 hosts an IPv4 VPN instance and an IPv6 VPN instance. The PEs use BGP to exchange VPN prefixes and VPN labels between each other. In the core network, R1 and R2 are transit routers, OSPF is used as the routing protocol, and RSVP-TE is used as the tunnel signaling protocol.<a href="#section-10-3" class="pilcrow">¶</a></p>
<p id="section-10-4">
       Using the framework in this document, the network assigns PE3 to be the protector of PE2 to protect the VPN traffic in the direction from site 1 to site 2. This is the co-located protector mode. PE2 and PE3 form a protected egress {PE2, PE3}. Context ID 198.51.100.1 is assigned to the protected egress {PE2, PE3}. (If the core network is IPv6, the context ID would be an IPv6 address.) The IPv4 and IPv6 VPN instances on PE3 serve as protection instances for the corresponding VPN instances on PE2. On PE3, context label 100 is assigned to the context ID, and a label table pe2.mpls is created to represent PE2's label space. PE3 installs label 100 in its MPLS forwarding table, with the next hop pointing to the label table pe2.mpls. PE2 and PE3 are coordinated to use the proxy mode to advertise the context ID in the routing domain and the TE domain.<a href="#section-10-4" class="pilcrow">¶</a></p>
<p id="section-10-5">
       PE2 uses the label allocation mode per Virtual Routing and Forwarding (VRF) for both of its IPv4 and IPv6 VPN instances. It assigns label 9000 to the IPv4 VRF, and label 9001 to the IPv6 VRF. For the IPv4 prefix 203.0.113.128/26 in site 2, PE2 advertises it with label 9000 and NEXT_HOP 198.51.100.1 to PE1 and PE3 via BGP. Likewise, for the IPv6 prefix 2001:db8:1:2::/64 in site 2, PE2 advertises it with label 9001 and NEXT_HOP 198.51.100.1 to PE1 and PE3 via BGP.<a href="#section-10-5" class="pilcrow">¶</a></p>
<p id="section-10-6">
       PE3 also uses per-VRF VPN label allocation mode for both of its IPv4 and IPv6 VPN instances. It assigns label 10000 to the IPv4 VRF and label 10001 to the IPv6 VRF. For the prefix 203.0.113.128/26 in site 2, PE3 advertises it with label 10000 and NEXT_HOP as itself to PE1 and PE2 via BGP. For the IPv6 prefix 2001:db8:1:2::/64 in site 2, PE3 advertises it with label 10001 and NEXT_HOP as itself to PE1 and PE2 via BGP.<a href="#section-10-6" class="pilcrow">¶</a></p>
<p id="section-10-7">
       Upon receipt of the above BGP advertisements from PE2, PE1 uses the context ID 198.51.100.1 as the destination to compute a path for an egress-protected tunnel. The resultant path is PE1-&gt;R1-&gt;PE2. PE1 then uses RSVP to signal the tunnel, with the context ID 198.51.100.1 as the destination, with the "node protection desired" flag set in the SESSION_ATTRIBUTE of the RSVP Path message. Once the tunnel comes up, PE1 maps the VPN prefixes 203.0.113.128/26 and 2001:db8:1:2::/64 to the tunnel and installs a route for each prefix in the corresponding IPv4 or IPv6 VRF. The next hop of route 203.0.113.128/26 is a push of the VPN label 9000, followed by a push of the outgoing label of the egress-protected tunnel. The next hop of route 2001:db8:1:2::/64 is a push of the VPN label 9001, followed by a push of the outgoing label of the egress-protected tunnel.<a href="#section-10-7" class="pilcrow">¶</a></p>
<p id="section-10-8">
       Upon receipt of the above BGP advertisements from PE2, PE3 recognizes the context ID 198.51.100.1 in the NEXT_HOP attribute and installs a route for label 9000 and a route for label 9001 in the label table pe2.mpls. PE3 sets the next hop of route 9000 to the IPv4 protection VRF and the next hop of route 9001 to the IPv6 protection VRF. The IPv4 protection VRF contains the routes to the IPv4 prefixes in site 2. The IPv6 protection VRF contains the routes to the IPv6 prefixes in site 2. The next hops of these routes must be based on PE3's connectivity with site 2, even if the connectivity may not have the best metrics (e.g., Multi-Exit Discriminator (MED), local preference, etc.) to be used in PE3's own VRF. The next hops must not use any path traversing PE2. Note that the protection VRFs are a logical concept, and they may simply be PE3's own VRFs if they satisfy the requirement.<a href="#section-10-8" class="pilcrow">¶</a></p>
<section id="section-10.1">
        <h3 id="name-egress-node-protection-2">
<a href="#section-10.1" class="section-number selfRef">10.1. </a><a href="#name-egress-node-protection-2" class="section-name selfRef">Egress Node Protection</a>
        </h3>
<p id="section-10.1-1">
  R1, i.e., the penultimate hop router of the egress-protected tunnel, serves as the PLR for egress node protection. Based on the "node protection desired" flag and the destination address (i.e., context ID 198.51.100.1) of the tunnel, R1 computes a bypass path to 198.51.100.1 while avoiding PE2. The resultant bypass path is R1-&gt;R2-&gt;PE3. R1 then signals the path (i.e., egress-protection bypass tunnel), with 198.51.100.1 as the destination.<a href="#section-10.1-1" class="pilcrow">¶</a></p>
<p id="section-10.1-2">
  Upon receipt of an RSVP Path message of the egress-protection bypass tunnel, PE3 recognizes the context ID 198.51.100.1 as the destination and responds with context label 100 in an RSVP Resv message.<a href="#section-10.1-2" class="pilcrow">¶</a></p>
<p id="section-10.1-3">
  After the egress-protection bypass tunnel comes up, R1 installs a bypass next hop for the egress-protected tunnel. The bypass next hop is a label swap from the incoming label of the egress-protected tunnel to the outgoing label of the egress-protection bypass tunnel.<a href="#section-10.1-3" class="pilcrow">¶</a></p>
<p id="section-10.1-4">
  When R1 detects a failure of PE2, it will invoke the above bypass next hop to reroute VPN packets. Each IPv4 VPN packet will have the label of the bypass tunnel as outer label, and the IPv4 VPN label 9000 as inner label. Each IPv6 VPN packet will have the label of the bypass tunnel as the outer label and the IPv6 VPN label 9001 as the inner label. When the packets arrive at PE3, they will have the context label 100 as the outer label and the VPN label 9000 or 9001 as the inner label. The context label will first be popped, and then the VPN label will be looked up in the label table pe2.mpls. The lookup will cause the VPN label to be popped and the IPv4 and IPv6 packets to be forwarded to site 2 based on the IPv4 and IPv6 protection VRFs, respectively.<a href="#section-10.1-4" class="pilcrow">¶</a></p>
</section>
<section id="section-10.2">
        <h3 id="name-egress-link-protection-2">
<a href="#section-10.2" class="section-number selfRef">10.2. </a><a href="#name-egress-link-protection-2" class="section-name selfRef">Egress Link Protection</a>
        </h3>
<p id="section-10.2-1">
  PE2 serves as the PLR for egress link protection. It has already learned PE3's IPv4 VPN label 10000 and IPv6 VPN label 10001. Hence, it uses approach (2) as described in <a href="#link-protection" class="xref">Section 6</a> to set up the bypass forwarding state. It signals an egress-protection bypass tunnel to PE3, by using the path PE2-&gt;R3-&gt;PE3, and PE3's IP address as the destination. After the bypass tunnel comes up, PE2 installs a bypass next hop for the IPv4 VPN label 9000 and a bypass next hop for the IPv6 VPN label 9001. For label 9000, the bypass next hop is a label swap to label 10000, followed by a label push with the outgoing label of the bypass tunnel. For label 9001, the bypass next hop is a label swap to label 10001, followed by a label push with the outgoing label of the bypass tunnel.<a href="#section-10.2-1" class="pilcrow">¶</a></p>
<p id="section-10.2-2">
  When PE2 detects a failure of the egress link, it will invoke the above bypass next hop to reroute VPN packets. Each IPv4 VPN packet will have the label of the bypass tunnel as the outer label and label 10000 as the inner label. Each IPv6 VPN packet will have the label of the bypass tunnel as the outer label and label 10001 as the inner label. When the packets arrive at PE3, the VPN label 10000 or 10001 will be popped, and the exposed IPv4 and IPv6 packets will be forwarded based on PE3's IPv4 and IPv6 VRFs, respectively.<a href="#section-10.2-2" class="pilcrow">¶</a></p>
</section>
<section id="section-10.3">
        <h3 id="name-global-repair-2">
<a href="#section-10.3" class="section-number selfRef">10.3. </a><a href="#name-global-repair-2" class="section-name selfRef">Global Repair</a>
        </h3>
<p id="section-10.3-1">
  Eventually, global repair will take effect, as control-plane protocols converge on the new topology. PE1 will choose PE3 as a new entrance to site 2. Before that happens, the VPN traffic has been protected by the above local repair.<a href="#section-10.3-1" class="pilcrow">¶</a></p>
</section>
<section id="section-10.4">
        <h3 id="name-other-modes-of-vpn-label-al">
<a href="#section-10.4" class="section-number selfRef">10.4. </a><a href="#name-other-modes-of-vpn-label-al" class="section-name selfRef">Other Modes of VPN Label Allocation</a>
        </h3>
<p id="section-10.4-1">
  It is also possible that PE2 may use per-route or per-interface VPN label allocation mode. In either case, PE3 will have multiple VPN label routes in the pe2.mpls table, corresponding to the VPN labels advertised by PE2. PE3 forwards rerouted packets by popping a VPN label and performing an IP lookup in the corresponding protection VRF. PE3's forwarding behavior is consistent with the above case where PE2 uses per-VRF VPN label allocation mode. PE3 does not need to know PE2's VPN label allocation mode or construct a specific next hop for each VPN label route in the pe2.mpls table.<a href="#section-10.4-1" class="pilcrow">¶</a></p>
</section>
</section>
<div id="IANA">
<section id="section-11">
      <h2 id="name-iana-considerations">
<a href="#section-11" class="section-number selfRef">11. </a><a href="#name-iana-considerations" class="section-name selfRef">IANA Considerations</a>
      </h2>
<p id="section-11-1">
      This document has no IANA actions.<a href="#section-11-1" class="pilcrow">¶</a></p>
</section>
</div>
<div id="Security">
<section id="section-12">
      <h2 id="name-security-considerations">
<a href="#section-12" class="section-number selfRef">12. </a><a href="#name-security-considerations" class="section-name selfRef">Security Considerations</a>
      </h2>
<p id="section-12-1">
       The framework in this document involves rerouting traffic around an egress node or link failure, via a bypass path from a PLR to a protector, and ultimately to a backup egress router. The forwarding performed by the routers in the data plane is anticipated, as part of the planning of egress protection.<a href="#section-12-1" class="pilcrow">¶</a></p>
<p id="section-12-2">
       Control-plane protocols <span class="bcp14">MAY</span> be used to facilitate the provisioning of the egress protection on the routers.  In particular, the framework requires a service label distribution protocol between an egress router and a protector over a secure session.  The security properties of this provisioning and label distribution depend entirely on the underlying protocol chosen to implement these activities. Their associated security considerations apply. This framework introduces no new security requirements or guarantees relative to these activities.<a href="#section-12-2" class="pilcrow">¶</a></p>
<p id="section-12-3">
       Also, the PLR, protector, and backup egress router are located close to the protected egress router, which is normally in the same administrative domain.  If they are not in the same administrative domain, a certain level of trust <span class="bcp14">MUST</span> be established between them in order for the protocols to run securely across the domain boundary.  The basis of this trust is the security model of the protocols (as described above), and further security considerations for inter-domain scenarios should be addressed by the protocols as a common requirement.<a href="#section-12-3" class="pilcrow">¶</a></p>
<p id="section-12-4">
       Security attacks may sometimes come from a customer domain. Such attacks are not introduced by the framework in this document and may occur regardless of the existence of egress protection. In one possible case, the egress link between an egress router and a CE could become a point of attack.  An attacker that gains control of the CE might use it to simulate link failures and trigger constant and cascading activities in the network. If egress link protection is in place, egress link protection activities may also be triggered. As a general solution to defeat the attack, a damping mechanism <span class="bcp14">SHOULD</span> be used by the egress router to promptly
   suppress the services associated with the link or CE.  The egress router would stop advertising the services, essentially detaching them from the network and eliminating the effect of the simulated link failures.<a href="#section-12-4" class="pilcrow">¶</a></p>
<p id="section-12-5">
       From the above perspectives, this framework does not introduce any new security threat to networks.<a href="#section-12-5" class="pilcrow">¶</a></p>
</section>
</div>
<section id="section-13">
      <h2 id="name-references">
<a href="#section-13" class="section-number selfRef">13. </a><a href="#name-references" class="section-name selfRef">References</a>
      </h2>
<section id="section-13.1">
        <h3 id="name-normative-references">
<a href="#section-13.1" class="section-number selfRef">13.1. </a><a href="#name-normative-references" class="section-name selfRef">Normative References</a>
        </h3>
<dl class="references">
<dt id="RFC2119">[RFC2119]</dt>
        <dd>
<span class="refAuthor">Bradner, S.</span>, <span class="refTitle">"Key words for use in RFCs to Indicate Requirement Levels"</span>, <span class="seriesInfo">BCP 14</span>, <span class="seriesInfo">RFC 2119</span>, <span class="seriesInfo">DOI 10.17487/RFC2119</span>, <time datetime="1997-03">March 1997</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc2119">https://www.rfc-editor.org/info/rfc2119</a>&gt;</span>. </dd>
<dt id="RFC8174">[RFC8174]</dt>
        <dd>
<span class="refAuthor">Leiba, B.</span>, <span class="refTitle">"Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words"</span>, <span class="seriesInfo">BCP 14</span>, <span class="seriesInfo">RFC 8174</span>, <span class="seriesInfo">DOI 10.17487/RFC8174</span>, <time datetime="2017-05">May 2017</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8174">https://www.rfc-editor.org/info/rfc8174</a>&gt;</span>. </dd>
<dt id="RFC8402">[RFC8402]</dt>
        <dd>
<span class="refAuthor">Filsfils, C., Ed.</span><span class="refAuthor">, Previdi, S., Ed.</span><span class="refAuthor">, Ginsberg, L.</span><span class="refAuthor">, Decraene, B.</span><span class="refAuthor">, Litkowski, S.</span><span class="refAuthor">, and R. Shakir</span>, <span class="refTitle">"Segment Routing Architecture"</span>, <span class="seriesInfo">RFC 8402</span>, <span class="seriesInfo">DOI 10.17487/RFC8402</span>, <time datetime="2018-07">July 2018</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8402">https://www.rfc-editor.org/info/rfc8402</a>&gt;</span>. </dd>
<dt id="RFC8667">[RFC8667]</dt>
      <dd>
<span class="refAuthor">Previdi, S.</span><span class="refAuthor">, Ginsberg, L.</span><span class="refAuthor">, Filsfils, C.</span><span class="refAuthor">, Bashandy, A.</span><span class="refAuthor">, Gredler, H.</span><span class="refAuthor">, and B. Decraene</span>, <span class="refTitle">"IS-IS Extensions for Segment Routing"</span>, <span class="seriesInfo">RFC 8667</span>, <span class="seriesInfo">DOI 10.17487/RFC8667</span>, <time datetime="2019-12">December 2019</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8667">https://www.rfc-editor.org/info/rfc8667</a>&gt;</span>. </dd>
</dl>
</section>
<section id="section-13.2">
        <h3 id="name-informative-references">
<a href="#section-13.2" class="section-number selfRef">13.2. </a><a href="#name-informative-references" class="section-name selfRef">Informative References</a>
        </h3>
<dl class="references">
<dt id="I-D.ietf-rtgwg-bgp-pic">[BGP-PIC]</dt>
        <dd>
<span class="refAuthor">Bashandy, A.</span><span class="refAuthor">, Filsfils, C.</span><span class="refAuthor">, and P. Mohapatra</span>, <span class="refTitle">"BGP Prefix Independent Convergence"</span>, <span class="refContent">Work in Progress</span>, <span class="seriesInfo">Internet-Draft, draft-ietf-rtgwg-bgp-pic-10</span>, <time datetime="2019-10-02">2 October 2019</time>, <span>&lt;<a href="https://tools.ietf.org/html/draft-ietf-rtgwg-bgp-pic-10">https://tools.ietf.org/html/draft-ietf-rtgwg-bgp-pic-10</a>&gt;</span>. </dd>
<dt id="RFC4090">[RFC4090]</dt>
        <dd>
<span class="refAuthor">Pan, P., Ed.</span><span class="refAuthor">, Swallow, G., Ed.</span><span class="refAuthor">, and 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">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>
<dt id="RFC5286">[RFC5286]</dt>
        <dd>
<span class="refAuthor">Atlas, A., Ed.</span><span class="refAuthor"> and A. Zinin, Ed.</span>, <span class="refTitle">"Basic Specification for IP Fast Reroute: Loop-Free Alternates"</span>, <span class="seriesInfo">RFC 5286</span>, <span class="seriesInfo">DOI 10.17487/RFC5286</span>, <time datetime="2008-09">September 2008</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc5286">https://www.rfc-editor.org/info/rfc5286</a>&gt;</span>. </dd>
<dt id="RFC7490">[RFC7490]</dt>
        <dd>
<span class="refAuthor">Bryant, S.</span><span class="refAuthor">, Filsfils, C.</span><span class="refAuthor">, Previdi, S.</span><span class="refAuthor">, Shand, M.</span><span class="refAuthor">, and N. So</span>, <span class="refTitle">"Remote Loop-Free Alternate (LFA) Fast Reroute (FRR)"</span>, <span class="seriesInfo">RFC 7490</span>, <span class="seriesInfo">DOI 10.17487/RFC7490</span>, <time datetime="2015-04">April 2015</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc7490">https://www.rfc-editor.org/info/rfc7490</a>&gt;</span>. </dd>
<dt id="RFC7812">[RFC7812]</dt>
        <dd>
<span class="refAuthor">Atlas, A.</span><span class="refAuthor">, Bowers, C.</span><span class="refAuthor">, and G. Enyedi</span>, <span class="refTitle">"An Architecture for IP/LDP Fast Reroute Using Maximally Redundant Trees (MRT-FRR)"</span>, <span class="seriesInfo">RFC 7812</span>, <span class="seriesInfo">DOI 10.17487/RFC7812</span>, <time datetime="2016-06">June 2016</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc7812">https://www.rfc-editor.org/info/rfc7812</a>&gt;</span>. </dd>
<dt id="RFC8104">[RFC8104]</dt>
        <dd>
<span class="refAuthor">Shen, Y.</span><span class="refAuthor">, Aggarwal, R.</span><span class="refAuthor">, Henderickx, W.</span><span class="refAuthor">, and Y. Jiang</span>, <span class="refTitle">"Pseudowire (PW) Endpoint Fast Failure Protection"</span>, <span class="seriesInfo">RFC 8104</span>, <span class="seriesInfo">DOI 10.17487/RFC8104</span>, <time datetime="2017-03">March 2017</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8104">https://www.rfc-editor.org/info/rfc8104</a>&gt;</span>. </dd>
<dt id="RFC8400">[RFC8400]</dt>
      <dd>
<span class="refAuthor">Chen, H.</span><span class="refAuthor">, Liu, A.</span><span class="refAuthor">, Saad, T.</span><span class="refAuthor">, Xu, F.</span><span class="refAuthor">, and L. Huang</span>, <span class="refTitle">"Extensions to RSVP-TE for Label Switched Path (LSP) Egress Protection"</span>, <span class="seriesInfo">RFC 8400</span>, <span class="seriesInfo">DOI 10.17487/RFC8400</span>, <time datetime="2018-06">June 2018</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8400">https://www.rfc-editor.org/info/rfc8400</a>&gt;</span>. </dd>
</dl>
</section>
</section>
<div id="ack">
<section id="section-appendix.a">
      <h2 id="name-acknowledgements">
<a href="#name-acknowledgements" class="section-name selfRef">Acknowledgements</a>
      </h2>
<p id="section-appendix.a-1">
       This document leverages work done by Yakov Rekhter, Kevin Wang, and Zhaohui Zhang on MPLS egress protection. Thanks to Alexander Vainshtein, Rolf Winter, Lizhong Jin, Krzysztof Szarkowicz, Roman Danyliw, and Yuanlong Jiang for their valuable comments that helped to shape this document and improve its clarity.<a href="#section-appendix.a-1" class="pilcrow">¶</a></p>
</section>
</div>
<div id="authors-addresses">
<section id="section-appendix.b">
      <h2 id="name-authors-addresses">
<a href="#name-authors-addresses" class="section-name selfRef">Authors' Addresses</a>
      </h2>
<address class="vcard">
        <div dir="auto" class="left"><span class="fn nameRole">Yimin Shen</span></div>
<div dir="auto" class="left"><span class="org">Juniper Networks</span></div>
<div dir="auto" class="left"><span class="street-address">10 Technology Park Drive</span></div>
<div dir="auto" class="left">
<span class="locality">Westford</span>, <span class="region">MA</span> <span class="postal-code">01886</span>
</div>
<div dir="auto" class="left"><span class="country-name">United States of America</span></div>
<div class="tel">
<span>Phone:</span>
<a href="tel:+1%20978%20589%200722" class="tel">+1 978 589 0722</a>
</div>
<div class="email">
<span>Email:</span>
<a href="mailto:yshen@juniper.net" class="email">yshen@juniper.net</a>
</div>
</address>
<address class="vcard">
        <div dir="auto" class="left"><span class="fn nameRole">Minto Jeyananth</span></div>
<div dir="auto" class="left"><span class="org">Juniper Networks</span></div>
<div dir="auto" class="left"><span class="street-address">1133 Innovation Way</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="tel">
<span>Phone:</span>
<a href="tel:+1%20408%20936%207563" class="tel">+1 408 936 7563</a>
</div>
<div class="email">
<span>Email:</span>
<a href="mailto:minto@juniper.net" class="email">minto@juniper.net</a>
</div>
</address>
<address class="vcard">
        <div dir="auto" class="left"><span class="fn nameRole">Bruno Decraene</span></div>
<div dir="auto" class="left"><span class="org">Orange</span></div>
<div class="email">
<span>Email:</span>
<a href="mailto:bruno.decraene@orange.com" class="email">bruno.decraene@orange.com</a>
</div>
</address>
<address class="vcard">
        <div dir="auto" class="left"><span class="fn nameRole">Hannes Gredler</span></div>
<div dir="auto" class="left"><span class="org">RtBrick Inc.</span></div>
<div class="email">
<span>Email:</span>
<a href="mailto:hannes@rtbrick.com" class="email">hannes@rtbrick.com</a>
</div>
</address>
<address class="vcard">
        <div dir="auto" class="left"><span class="fn nameRole">Carsten Michel</span></div>
<div dir="auto" class="left"><span class="org">Deutsche Telekom</span></div>
<div class="email">
<span>Email:</span>
<a href="mailto:c.michel@telekom.de" class="email">c.michel@telekom.de</a>
</div>
</address>
<address class="vcard">
        <div dir="auto" class="left"><span class="fn nameRole">Huaimo Chen</span></div>
<div dir="auto" class="left"><span class="org">Futurewei</span></div>
<div dir="auto" class="left">
<span class="locality">Boston</span>, <span class="region">MA</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:Huaimo.chen@futurewei.com" class="email">Huaimo.chen@futurewei.com</a>
</div>
</address>
</section>
</div>
<script>var toc = document.getElementById("toc");
var tocToggle = toc.querySelector("h2");
var tocNav = toc.querySelector("nav");

// mobile menu toggle
tocToggle.onclick = function(event) {
    if (window.innerWidth < 1024) {
 var tocNavDisplay = tocNav.currentStyle ? tocNav.currentStyle.display : getComputedStyle(tocNav, null).display;
 if (tocNavDisplay == "none") {
     tocNav.style.display = "block";
 } else {
     tocNav.style.display = "none";
 }
    }
}

// toc anchor scroll to anchor
tocNav.addEventListener("click", function (event) {
    event.preventDefault();
    if (event.target.nodeName == 'A') {
 if (window.innerWidth < 1024) {
     tocNav.style.display = "none";
 }
 var href = event.target.getAttribute("href");
 var anchorId = href.substr(1);
 var anchor =  document.getElementById(anchorId);
 anchor.scrollIntoView(true);
 window.history.pushState("","",href);
    }
});

// switch toc mode when window resized
window.onresize = function () {
    if (window.innerWidth < 1024) {
 tocNav.style.display = "none";
    } else {
 tocNav.style.display = "block";
    }
}
</script>
</body>
</html>