File: rfc9087.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 (2483 lines) | stat: -rw-r--r-- 107,156 bytes
<!DOCTYPE html>
<html lang="en" class="RFC">
<head>
<meta charset="utf-8">
<meta content="Common,Latin" name="scripts">
<meta content="initial-scale=1.0" name="viewport">
<title>RFC 9087: Segment Routing Centralized BGP Egress Peer Engineering</title>
<meta content="Clarence Filsfils" name="author">
<meta content="Stefano Previdi" name="author">
<meta content="Gaurav Dawra" name="author">
<meta content="Ebben Aries" name="author">
<meta content="Dmitry Afanasiev" name="author">
<meta content="
       Segment Routing (SR) leverages source routing. A node steers a packet
      through a controlled set of instructions, called segments, by prepending
      the packet with an SR header. A segment can represent any instruction,
      topological or service based. SR allows for the enforcement of a flow
      through any topological path while maintaining per-flow state only at
      the ingress node of the SR domain. 
       The Segment Routing architecture can be directly applied to the MPLS
      data plane with no change on the forwarding plane. It requires a minor
      extension to the existing link-state routing protocols. 
       This document illustrates the application of Segment Routing to solve
      the BGP Egress Peer Engineering (BGP-EPE) requirement. The SR-based
      BGP-EPE solution allows a centralized (Software-Defined Networking, or SDN)
      controller to program any egress peer policy at ingress border routers
      or at hosts within the domain. 
    " name="description">
<meta content="xml2rfc 3.9.1" name="generator">
<meta content="9087" name="rfc.number">
<!-- Generator version information:
  xml2rfc 3.9.1
    Python 3.6.10
    appdirs 1.4.4
    ConfigArgParse 1.2.3
    google-i18n-address 2.3.5
    html5lib 1.0.1
    intervaltree 3.0.2
    Jinja2 2.11.2
    kitchen 1.2.6
    lxml 4.4.2
    pycairo 1.19.0
    pycountry 19.8.18
    pyflakes 2.1.1
    PyYAML 5.3.1
    requests 2.22.0
    setuptools 40.6.2
    six 1.14.0
    WeasyPrint 51
-->
<link href="rfc9087.xml" rel="alternate" type="application/rfc+xml">
<link href="#copyright" rel="license">
<style type="text/css">/*

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

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

*/

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

.refInstance {
  margin-bottom: 1.25em;
}

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

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

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

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

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

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

/* pagination */
@media print {
  body {

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

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

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

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

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

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

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

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

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

}

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


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

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

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

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

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

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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

}
/* Tweak the bcp14 keyword presentation */
.bcp14 {
  font-variant: small-caps;
  font-weight: bold;
  font-size: 0.9em;
}
/* Tweak the invisible space above H* in order not to overlay links in text above */
 h2 {
  margin-top: -18px;  /* provide offset for in-page anchors */
  padding-top: 31px;
 }
 h3 {
  margin-top: -18px;  /* provide offset for in-page anchors */
  padding-top: 24px;
 }
 h4 {
  margin-top: -18px;  /* provide offset for in-page anchors */
  padding-top: 24px;
 }
/* Float artwork pilcrow to the right */
@media screen {
  .artwork a.pilcrow {
    display: block;
    line-height: 0.7;
    margin-top: 0.15em;
  }
}
/* Make pilcrows on dd visible */
@media screen {
  dd:hover > a.pilcrow {
    visibility: visible;
  }
}
/* Make the placement of figcaption match that of a table's caption
   by removing the figure's added bottom margin */
.alignLeft.art-text,
.alignCenter.art-text,
.alignRight.art-text {
   margin-bottom: 0;
}
.alignLeft,
.alignCenter,
.alignRight {
  margin: 1em 0 0 0;
}
/* In print, the pilcrow won't show on hover, so prevent it from taking up space,
   possibly even requiring a new line */
@media print {
  a.pilcrow {
    display: none;
  }
}
/* Styling for the external metadata */
div#external-metadata {
  background-color: #eee;
  padding: 0.5em;
  margin-bottom: 0.5em;
  display: none;
}
div#internal-metadata {
  padding: 0.5em;                       /* to match the external-metadata padding */
}
/* Styling for title RFC Number */
h1#rfcnum {
  clear: both;
  margin: 0 0 -1em;
  padding: 1em 0 0 0;
}
/* Make .olPercent look the same as <ol><li> */
dl.olPercent > dd {
  margin-bottom: 0.25em;
  min-height: initial;
}
/* Give aside some styling to set it apart */
aside {
  border-left: 1px solid #ddd;
  margin: 1em 0 1em 2em;
  padding: 0.2em 2em;
}
aside > dl,
aside > ol,
aside > ul,
aside > table,
aside > p {
  margin-bottom: 0.5em;
}
/* Additional page break settings */
@media print {
  figcaption, table caption {
    page-break-before: avoid;
  }
}
/* Font size adjustments for print */
@media print {
  body  { font-size: 10pt;      line-height: normal; max-width: 96%; }
  h1    { font-size: 1.72em;    padding-top: 1.5em; } /* 1*1.2*1.2*1.2 */
  h2    { font-size: 1.44em;    padding-top: 1.5em; } /* 1*1.2*1.2 */
  h3    { font-size: 1.2em;     padding-top: 1.5em; } /* 1*1.2 */
  h4    { font-size: 1em;       padding-top: 1.5em; }
  h5, h6 { font-size: 1em;      margin: initial; padding: 0.5em 0 0.3em; }
}
/* Sourcecode margin in print, when there's no pilcrow */
@media print {
  .artwork,
  .sourcecode {
    margin-bottom: 1em;
  }
}
/* Avoid narrow tables forcing too narrow table captions, which may render badly */
table {
  min-width: 20em;
}
/* ol type a */
ol.type-a { list-style-type: lower-alpha; }
ol.type-A { list-style-type: upper-alpha; }
ol.type-i { list-style-type: lower-roman; }
ol.type-I { list-style-type: lower-roman; }
/* Apply the print table and row borders in general, on request from the RPC,
and increase the contrast between border and odd row background sligthtly */
table {
  border: 1px solid #ddd;
}
td {
  border-top: 1px solid #ddd;
}
tr:nth-child(2n+1) > td {
  background-color: #f8f8f8;
}
/* Use style rules to govern display of the TOC. */
@media screen and (max-width: 1023px) {
  #toc nav { display: none; }
  #toc.active nav { display: block; }
}
/* Add support for keepWithNext */
.keepWithNext {
  break-after: avoid-page;
  break-after: avoid-page;
}
/* Add support for keepWithPrevious */
.keepWithPrevious {
  break-before: avoid-page;
}
/* Change the approach to avoiding breaks inside artwork etc. */
figure, pre, table, .artwork, .sourcecode  {
  break-before: avoid-page;
  break-after: auto;
}
/* Avoid breaks between <dt> and <dd> */
dl {
  break-before: auto;
  break-inside: auto;
}
dt {
  break-before: auto;
  break-after: avoid-page;
}
dd {
  break-before: avoid-page;
  break-after: auto;
  orphans: 3;
  widows: 3
}
span.break, dd.break {
  margin-bottom: 0;
  min-height: 0;
  break-before: auto;
  break-inside: auto;
  break-after: auto;
}
/* Undo break-before ToC */
@media print {
  #toc {
    break-before: auto;
  }
}
/* Text in compact lists should not get extra bottim margin space,
   since that would makes the list not compact */
ul.compact p, .ulCompact p,
ol.compact p, .olCompact p {
 margin: 0;
}
/* But the list as a whole needs the extra space at the end */
section ul.compact,
section .ulCompact,
section ol.compact,
section .olCompact {
  margin-bottom: 1em;                    /* same as p not within ul.compact etc. */
}
/* The tt and code background above interferes with for instance table cell
   backgrounds.  Changed to something a bit more selective. */
tt, code {
  background-color: transparent;
}
p tt, p code, li tt, li code {
  background-color: #f8f8f8;
}
/* Tweak the pre margin -- 0px doesn't come out well */
pre {
   margin-top: 0.5px;
}
/* Tweak the comact list text */
ul.compact, .ulCompact,
ol.compact, .olCompact,
dl.compact, .dlCompact {
  line-height: normal;
}
/* Don't add top margin for nested lists */
li > ul, li > ol, li > dl,
dd > ul, dd > ol, dd > dl,
dl > dd > dl {
  margin-top: initial;
}
/* Elements that should not be rendered on the same line as a <dt> */
/* This should match the element list in writer.text.TextWriter.render_dl() */
dd > div.artwork:first-child,
dd > aside:first-child,
dd > figure:first-child,
dd > ol:first-child,
dd > div:first-child > pre.sourcecode,
dd > table:first-child,
dd > ul:first-child {
  clear: left;
}
/* fix for weird browser behaviour when <dd/> is empty */
dt+dd:empty::before{
  content: "\00a0";
}
/* Make paragraph spacing inside <li> smaller than in body text, to fit better within the list */
li > p {
  margin-bottom: 0.5em
}
/* Don't let p margin spill out from inside list items */
li > p:last-of-type {
  margin-bottom: 0;
}
</style>
<link href="rfc-local.css" rel="stylesheet" type="text/css">
<link href="https://dx.doi.org/10.17487/rfc9087" rel="alternate">
  <link href="urn:issn:2070-1721" rel="alternate">
  <link href="https://datatracker.ietf.org/doc/draft-ietf-spring-segment-routing-central-epe-10" 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 9087</td>
<td class="center">Segment Routing Centralized EPE</td>
<td class="right">August 2021</td>
</tr></thead>
<tfoot><tr>
<td class="left">Filsfils, et al.</td>
<td class="center">Informational</td>
<td class="right">[Page]</td>
</tr></tfoot>
</table>
<div id="external-metadata" class="document-information"></div>
<div id="internal-metadata" class="document-information">
<dl id="identifiers">
<dt class="label-stream">Stream:</dt>
<dd class="stream">Internet Engineering Task Force (IETF)</dd>
<dt class="label-rfc">RFC:</dt>
<dd class="rfc"><a href="https://www.rfc-editor.org/rfc/rfc9087" class="eref">9087</a></dd>
<dt class="label-category">Category:</dt>
<dd class="category">Informational</dd>
<dt class="label-published">Published:</dt>
<dd class="published">
<time datetime="2021-08" class="published">August 2021</time>
    </dd>
<dt class="label-issn">ISSN:</dt>
<dd class="issn">2070-1721</dd>
<dt class="label-authors">Authors:</dt>
<dd class="authors">
<div class="author">
      <div class="author-name">C. Filsfils, <span class="editor">Ed.</span>
</div>
<div class="org">Cisco Systems, Inc.</div>
</div>
<div class="author">
      <div class="author-name">S. Previdi</div>
<div class="org">Cisco Systems, Inc.</div>
</div>
<div class="author">
      <div class="author-name">G. Dawra, <span class="editor">Ed.</span>
</div>
<div class="org">Cisco Systems, Inc.</div>
</div>
<div class="author">
      <div class="author-name">E. Aries</div>
<div class="org">Juniper Networks</div>
</div>
<div class="author">
      <div class="author-name">D. Afanasiev</div>
<div class="org">Yandex</div>
</div>
</dd>
</dl>
</div>
<h1 id="rfcnum">RFC 9087</h1>
<h1 id="title">Segment Routing Centralized BGP Egress Peer Engineering</h1>
<section id="section-abstract">
      <h2 id="abstract"><a href="#abstract" class="selfRef">Abstract</a></h2>
<p id="section-abstract-1">Segment Routing (SR) leverages source routing. A node steers a packet
      through a controlled set of instructions, called segments, by prepending
      the packet with an SR header. A segment can represent any instruction,
      topological or service based. SR allows for the enforcement of a flow
      through any topological path while maintaining per-flow state only at
      the ingress node of the SR domain.<a href="#section-abstract-1" class="pilcrow">¶</a></p>
<p id="section-abstract-2">The Segment Routing architecture can be directly applied to the MPLS
      data plane with no change on the forwarding plane. It requires a minor
      extension to the existing link-state routing protocols.<a href="#section-abstract-2" class="pilcrow">¶</a></p>
<p id="section-abstract-3">This document illustrates the application of Segment Routing to solve
      the BGP Egress Peer Engineering (BGP-EPE) requirement. The SR-based
      BGP-EPE solution allows a centralized (Software-Defined Networking, or SDN)
      controller to program any egress peer policy at ingress border routers
      or at hosts within the domain.<a href="#section-abstract-3" class="pilcrow">¶</a></p>
</section>
<div id="status-of-memo">
<section id="section-boilerplate.1">
        <h2 id="name-status-of-this-memo">
<a href="#name-status-of-this-memo" class="section-name selfRef">Status of This Memo</a>
        </h2>
<p id="section-boilerplate.1-1">
            This document is not an Internet Standards Track specification; it is
            published for informational purposes.<a href="#section-boilerplate.1-1" class="pilcrow">¶</a></p>
<p id="section-boilerplate.1-2">
            This document is a product of the Internet Engineering Task Force
            (IETF).  It represents the consensus of the IETF community.  It has
            received public review and has been approved for publication by the
            Internet Engineering Steering Group (IESG).  Not all documents
            approved by the IESG are candidates for any level of Internet
            Standard; see Section 2 of RFC 7841.<a href="#section-boilerplate.1-2" class="pilcrow">¶</a></p>
<p id="section-boilerplate.1-3">
            Information about the current status of this document, any
            errata, and how to provide feedback on it may be obtained at
            <span><a href="https://www.rfc-editor.org/info/rfc9087">https://www.rfc-editor.org/info/rfc9087</a></span>.<a href="#section-boilerplate.1-3" class="pilcrow">¶</a></p>
</section>
</div>
<div id="copyright">
<section id="section-boilerplate.2">
        <h2 id="name-copyright-notice">
<a href="#name-copyright-notice" class="section-name selfRef">Copyright Notice</a>
        </h2>
<p id="section-boilerplate.2-1">
            Copyright (c) 2021 IETF Trust and the persons identified as the
            document authors. All rights reserved.<a href="#section-boilerplate.2-1" class="pilcrow">¶</a></p>
<p id="section-boilerplate.2-2">
            This document is subject to BCP 78 and the IETF Trust's Legal
            Provisions Relating to IETF Documents
            (<span><a href="https://trustee.ietf.org/license-info">https://trustee.ietf.org/license-info</a></span>) in effect on the date of
            publication of this document. Please review these documents
            carefully, as they describe your rights and restrictions with
            respect to this document. Code Components extracted from this
            document must include Simplified BSD License text as described in
            Section 4.e of the Trust Legal Provisions and are provided without
            warranty as described in the Simplified BSD License.<a href="#section-boilerplate.2-2" class="pilcrow">¶</a></p>
</section>
</div>
<div id="toc">
<section id="section-toc.1">
        <a href="#" onclick="scroll(0,0)" class="toplink">▲</a><h2 id="name-table-of-contents">
<a href="#name-table-of-contents" class="section-name selfRef">Table of Contents</a>
        </h2>
<nav class="toc"><ul class="compact ulEmpty toc ulBare">
<li class="compact ulEmpty toc ulBare" id="section-toc.1-1.1">
            <p id="section-toc.1-1.1.1" class="keepWithNext"><a href="#section-1" class="xref">1</a>.  <a href="#name-introduction" class="xref">Introduction</a></p>
<ul class="ulEmpty toc ulBare compact">
<li class="ulEmpty toc ulBare compact" id="section-toc.1-1.1.2.1">
                <p id="section-toc.1-1.1.2.1.1" class="keepWithNext"><a href="#section-1.1" class="xref">1.1</a>.  <a href="#name-problem-statement" class="xref">Problem Statement</a></p>
</li>
              <li class="ulEmpty toc ulBare compact" id="section-toc.1-1.1.2.2">
                <p id="section-toc.1-1.1.2.2.1" class="keepWithNext"><a href="#section-1.2" class="xref">1.2</a>.  <a href="#name-requirements-language" class="xref">Requirements Language</a></p>
</li>
            </ul>
</li>
          <li class="compact ulEmpty toc ulBare" 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-bgp-peering-segments" class="xref">BGP Peering Segments</a></p>
</li>
          <li class="compact ulEmpty toc ulBare" 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-distribution-of-topology-an" class="xref">Distribution of Topology and TE Information Using BGP-LS</a></p>
<ul class="ulEmpty toc ulBare compact">
<li class="ulEmpty toc ulBare compact" id="section-toc.1-1.3.2.1">
                <p id="section-toc.1-1.3.2.1.1"><a href="#section-3.1" class="xref">3.1</a>.  <a href="#name-peernode-sid-to-d" class="xref">PeerNode SID to D</a></p>
</li>
              <li class="ulEmpty toc ulBare compact" id="section-toc.1-1.3.2.2">
                <p id="section-toc.1-1.3.2.2.1"><a href="#section-3.2" class="xref">3.2</a>.  <a href="#name-peernode-sid-to-e" class="xref">PeerNode SID to E</a></p>
</li>
              <li class="ulEmpty toc ulBare compact" id="section-toc.1-1.3.2.3">
                <p id="section-toc.1-1.3.2.3.1"><a href="#section-3.3" class="xref">3.3</a>.  <a href="#name-peernode-sid-to-f" class="xref">PeerNode SID to F</a></p>
</li>
              <li class="ulEmpty toc ulBare compact" id="section-toc.1-1.3.2.4">
                <p id="section-toc.1-1.3.2.4.1"><a href="#section-3.4" class="xref">3.4</a>.  <a href="#name-first-peeradj-to-f" class="xref">First PeerAdj to F</a></p>
</li>
              <li class="ulEmpty toc ulBare compact" id="section-toc.1-1.3.2.5">
                <p id="section-toc.1-1.3.2.5.1"><a href="#section-3.5" class="xref">3.5</a>.  <a href="#name-second-peeradj-to-f" class="xref">Second PeerAdj to F</a></p>
</li>
              <li class="ulEmpty toc ulBare compact" id="section-toc.1-1.3.2.6">
                <p id="section-toc.1-1.3.2.6.1"><a href="#section-3.6" class="xref">3.6</a>.  <a href="#name-fast-reroute-frr" class="xref">Fast Reroute (FRR)</a></p>
</li>
            </ul>
</li>
          <li class="compact ulEmpty toc ulBare" 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-bgp-epe-controller" class="xref">BGP-EPE Controller</a></p>
<ul class="ulEmpty toc ulBare compact">
<li class="ulEmpty toc ulBare compact" id="section-toc.1-1.4.2.1">
                <p id="section-toc.1-1.4.2.1.1"><a href="#section-4.1" class="xref">4.1</a>.  <a href="#name-valid-paths-from-peers" class="xref">Valid Paths from Peers</a></p>
</li>
              <li class="ulEmpty toc ulBare compact" id="section-toc.1-1.4.2.2">
                <p id="section-toc.1-1.4.2.2.1"><a href="#section-4.2" class="xref">4.2</a>.  <a href="#name-intra-domain-topology" class="xref">Intra-Domain Topology</a></p>
</li>
              <li class="ulEmpty toc ulBare compact" id="section-toc.1-1.4.2.3">
                <p id="section-toc.1-1.4.2.3.1"><a href="#section-4.3" class="xref">4.3</a>.  <a href="#name-external-topology" class="xref">External Topology</a></p>
</li>
              <li class="ulEmpty toc ulBare compact" id="section-toc.1-1.4.2.4">
                <p id="section-toc.1-1.4.2.4.1"><a href="#section-4.4" class="xref">4.4</a>.  <a href="#name-sla-characteristics-of-each" class="xref">SLA Characteristics of Each Peer</a></p>
</li>
              <li class="ulEmpty toc ulBare compact" id="section-toc.1-1.4.2.5">
                <p id="section-toc.1-1.4.2.5.1"><a href="#section-4.5" class="xref">4.5</a>.  <a href="#name-traffic-matrix" class="xref">Traffic Matrix</a></p>
</li>
              <li class="ulEmpty toc ulBare compact" id="section-toc.1-1.4.2.6">
                <p id="section-toc.1-1.4.2.6.1"><a href="#section-4.6" class="xref">4.6</a>.  <a href="#name-business-policies" class="xref">Business Policies</a></p>
</li>
              <li class="ulEmpty toc ulBare compact" id="section-toc.1-1.4.2.7">
                <p id="section-toc.1-1.4.2.7.1"><a href="#section-4.7" class="xref">4.7</a>.  <a href="#name-bgp-epe-policy" class="xref">BGP-EPE Policy</a></p>
</li>
            </ul>
</li>
          <li class="compact ulEmpty toc ulBare" 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-programming-an-input-policy" class="xref">Programming an Input Policy</a></p>
<ul class="ulEmpty toc ulBare compact">
<li class="ulEmpty toc ulBare compact" 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-at-a-host" class="xref">At a Host</a></p>
</li>
              <li class="ulEmpty toc ulBare compact" 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-at-a-router-sr-traffic-engi" class="xref">At a Router - SR Traffic-Engineering Tunnel</a></p>
</li>
              <li class="ulEmpty toc ulBare compact" 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-at-a-router-unicast-route-l" class="xref">At a Router - Unicast Route Labeled Using BGP (RFC 8277)</a></p>
</li>
              <li class="ulEmpty toc ulBare compact" 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-at-a-router-vpn-policy-rout" class="xref">At a Router - VPN Policy Route</a></p>
</li>
            </ul>
</li>
          <li class="compact ulEmpty toc ulBare" 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-ipv6-data-plane" class="xref">IPv6 Data Plane</a></p>
</li>
          <li class="compact ulEmpty toc ulBare" 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-benefits" class="xref">Benefits</a></p>
</li>
          <li class="compact ulEmpty toc ulBare" id="section-toc.1-1.8">
            <p id="section-toc.1-1.8.1"><a href="#section-8" class="xref">8</a>.  <a href="#name-iana-considerations" class="xref">IANA Considerations</a></p>
</li>
          <li class="compact ulEmpty toc ulBare" 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-manageability-consideration" class="xref">Manageability Considerations</a></p>
</li>
          <li class="compact ulEmpty toc ulBare" 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-security-considerations" class="xref">Security Considerations</a></p>
</li>
          <li class="compact ulEmpty toc ulBare" 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-references" class="xref">References</a></p>
<ul class="ulEmpty toc ulBare compact">
<li class="ulEmpty toc ulBare compact" id="section-toc.1-1.11.2.1">
                <p id="section-toc.1-1.11.2.1.1"><a href="#section-11.1" class="xref">11.1</a>.  <a href="#name-normative-references" class="xref">Normative References</a></p>
</li>
              <li class="ulEmpty toc ulBare compact" id="section-toc.1-1.11.2.2">
                <p id="section-toc.1-1.11.2.2.1"><a href="#section-11.2" class="xref">11.2</a>.  <a href="#name-informative-references" class="xref">Informative References</a></p>
</li>
            </ul>
</li>
          <li class="compact ulEmpty toc ulBare" id="section-toc.1-1.12">
            <p id="section-toc.1-1.12.1"><a href="#appendix-A" class="xref"></a><a href="#name-acknowledgements" class="xref">Acknowledgements</a></p>
</li>
          <li class="compact ulEmpty toc ulBare" id="section-toc.1-1.13">
            <p id="section-toc.1-1.13.1"><a href="#appendix-B" class="xref"></a><a href="#name-contributors" class="xref">Contributors</a></p>
</li>
          <li class="compact ulEmpty toc ulBare" id="section-toc.1-1.14">
            <p id="section-toc.1-1.14.1"><a href="#appendix-C" class="xref"></a><a href="#name-authors-addresses" class="xref">Authors' Addresses</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">The document is structured as follows:<a href="#section-1-1" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-1-2.1">
          <a href="#INTRO" class="xref">Section 1</a> states the BGP-EPE problem statement and provides the key references.<a href="#section-1-2.1" class="pilcrow">¶</a>
</li>
        <li class="normal" id="section-1-2.2">
          <a href="#BGPSEGMENTS" class="xref">Section 2</a> defines the different BGP
Peering Segments and the semantic associated to them.<a href="#section-1-2.2" class="pilcrow">¶</a>
</li>
        <li class="normal" id="section-1-2.3">
          <a href="#TOPOBGPLS" class="xref">Section 3</a> describes the automated
allocation of BGP Peering Segment-IDs (SIDs) by the BGP-EPE-enabled egress
border router and the automated signaling of the external peering topology and
the related BGP Peering SIDs to the collector <span>[<a href="#RFC9086" class="xref">RFC9086</a>]</span>.<a href="#section-1-2.3" class="pilcrow">¶</a>
</li>
        <li class="normal" id="section-1-2.4">
          <a href="#BGPPECTRL" class="xref">Section 4</a> overviews the components of a
centralized BGP-EPE controller. The definition of the BGP-EPE controller is
outside the scope of this document.<a href="#section-1-2.4" class="pilcrow">¶</a>
</li>
        <li class="normal" id="section-1-2.5">
          <a href="#PROGRINPUTPOL" class="xref">Section 5</a> overviews the methods that
could be used by the centralized BGP-EPE controller to implement a BGP-EPE
policy at an ingress border router or at a source host within the domain. The
exhaustive definition of all the means to program a BGP-EPE input policy is
outside the scope of this document.<a href="#section-1-2.5" class="pilcrow">¶</a>
</li>
      </ul>
<p id="section-1-3">For editorial reasons, the solution is described with IPv6 addresses
      and MPLS SIDs. This solution is equally applicable to IPv4 with MPLS
      SIDs and also to IPv6 with native IPv6 SIDs.<a href="#section-1-3" class="pilcrow">¶</a></p>
<div id="PROBSTATE">
<section id="section-1.1">
        <h3 id="name-problem-statement">
<a href="#section-1.1" class="section-number selfRef">1.1. </a><a href="#name-problem-statement" class="section-name selfRef">Problem Statement</a>
        </h3>
<p id="section-1.1-1">The BGP-EPE problem statement is defined in <span>[<a href="#RFC7855" class="xref">RFC7855</a>]</span>.<a href="#section-1.1-1" class="pilcrow">¶</a></p>
<p id="section-1.1-2">A centralized controller should be able to instruct an ingress
        Provider Edge (PE) router or a content source within the domain to use
        a specific egress PE and a specific external interface/neighbor to
        reach a particular destination.<a href="#section-1.1-2" class="pilcrow">¶</a></p>
<p id="section-1.1-3">Let's call this solution "BGP-EPE" for "BGP Egress Peer
        Engineering". The centralized controller is called the "BGP-EPE
        controller". The egress border router where the BGP-EPE traffic
        steering functionality is implemented is called a BGP-EPE-enabled
        border router. The input policy programmed at an ingress border router
        or at a source host is called a BGP-EPE policy.<a href="#section-1.1-3" class="pilcrow">¶</a></p>
<p id="section-1.1-4">The requirements that have motivated the solution described in this
        document are listed here below:<a href="#section-1.1-4" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-1.1-5.1">The solution <span class="bcp14">MUST</span> apply to the Internet use case
          where the Internet routes are assumed to use IPv4 unlabeled or IPv6
          unlabeled. 

   It is not required to place the Internet routes in a VPN Routing and
   Forwarding (VRF) instance and allocate labels on a per-route or
   per-path basis.<a href="#section-1.1-5.1" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-1.1-5.2">The solution <span class="bcp14">MUST</span> support any deployed Internal BGP (iBGP)
   schemes (Route Reflectors (RRs),
            confederations, or iBGP full meshes).<a href="#section-1.1-5.2" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-1.1-5.3">The solution <span class="bcp14">MUST</span> be applicable to both routers with external
            and internal peers.<a href="#section-1.1-5.3" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-1.1-5.4">The solution should minimize the need for new BGP capabilities
            at the ingress PEs.<a href="#section-1.1-5.4" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-1.1-5.5">The solution <span class="bcp14">MUST</span> accommodate an ingress BGP-EPE policy at an
            ingress PE or directly at a source within the domain.<a href="#section-1.1-5.5" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-1.1-5.6">The solution <span class="bcp14">MAY</span> support automated Fast Reroute (FRR) and fast
            convergence mechanisms.<a href="#section-1.1-5.6" class="pilcrow">¶</a>
</li>
        </ul>
<p id="section-1.1-6">The following reference diagram is used throughout this
        document.<a href="#section-1.1-6" class="pilcrow">¶</a></p>
<span id="name-reference-diagram"></span><div id="REFDIAGRAMFIG">
<figure id="figure-1">
          <div class="artwork art-text alignLeft" id="section-1.1-7.1">
<pre>+---------+      +------+
|         |      |      |
|    H    B------D      G
|         | +---/| AS 2 |\  +------+
|         |/     +------+ \ |      |---L/8
A   AS1   C---+            \|      |
|         |\\  \  +------+ /| AS 4 |---M/8
|         | \\  +-E      |/ +------+
|    X    |  \\   |      K
|         |   +===F AS 3 |
+---------+       +------+
</pre>
</div>
<figcaption><a href="#figure-1" class="selfRef">Figure 1</a>:
<a href="#name-reference-diagram" class="selfRef">Reference Diagram</a>
          </figcaption></figure>
</div>
<p id="section-1.1-8">IP addressing:<a href="#section-1.1-8" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-1.1-9.1">C's interface to D: 2001:db8:cd::c/64, D's
            interface: 2001:db8:cd::d/64<a href="#section-1.1-9.1" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-1.1-9.2">C's interface to E: 2001:db8:ce::c/64, E's
            interface: 2001:db8:ce::e/64<a href="#section-1.1-9.2" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-1.1-9.3">C's upper interface to F: 2001:db8:cf1::c/64, F's
            interface: 2001:db8:cf1::f/64<a href="#section-1.1-9.3" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-1.1-9.4">C's lower interface to F: 2001:db8:cf2::c/64, F's
            interface: 2001:db8:cf2::f/64<a href="#section-1.1-9.4" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-1.1-9.5">BGP router-ID of C: 192.0.2.3<a href="#section-1.1-9.5" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-1.1-9.6">BGP router-ID of D: 192.0.2.4<a href="#section-1.1-9.6" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-1.1-9.7">BGP router-ID of E: 192.0.2.5<a href="#section-1.1-9.7" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-1.1-9.8">BGP router-ID of F: 192.0.2.6<a href="#section-1.1-9.8" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-1.1-9.9">Loopback of F used for External BGP (eBGP) multi-hop peering to
          C: 2001:db8:f::f/128<a href="#section-1.1-9.9" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-1.1-9.10">C's loopback is 2001:db8:c::c/128 with SID 64<a href="#section-1.1-9.10" class="pilcrow">¶</a>
</li>
        </ul>
<p id="section-1.1-10">C's BGP peering:<a href="#section-1.1-10" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-1.1-11.1">Single-hop eBGP peering with neighbor 2001:db8:cd::d (D)<a href="#section-1.1-11.1" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-1.1-11.2">Single-hop eBGP peering with neighbor 2001:db8:ce::e (E)<a href="#section-1.1-11.2" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-1.1-11.3">Multi-hop eBGP peering with F on IP address 2001:db8:f::f
            (F)<a href="#section-1.1-11.3" class="pilcrow">¶</a>
</li>
        </ul>
<p id="section-1.1-12">C's resolution of the multi-hop eBGP session to F:<a href="#section-1.1-12" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-1.1-13.1">Static route to 2001:db8:f::f/128 via 2001:db8:cf1::f<a href="#section-1.1-13.1" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-1.1-13.2">Static route to 2001:db8:f::f/128 via 2001:db8:cf2::f<a href="#section-1.1-13.2" class="pilcrow">¶</a>
</li>
        </ul>
<p id="section-1.1-14">C is configured with a local policy that defines a BGP PeerSet as the
        set of peers (2001:db8:ce::e for E and 2001:db8:f::f for F).<a href="#section-1.1-14" class="pilcrow">¶</a></p>
<p id="section-1.1-15">X is the BGP-EPE controller within the AS1 domain.<a href="#section-1.1-15" class="pilcrow">¶</a></p>
<p id="section-1.1-16">H is a content source within the AS1 domain.<a href="#section-1.1-16" class="pilcrow">¶</a></p>
</section>
</div>
<section id="section-1.2">
        <h3 id="name-requirements-language">
<a href="#section-1.2" class="section-number selfRef">1.2. </a><a href="#name-requirements-language" class="section-name selfRef">Requirements Language</a>
        </h3>
<p id="section-1.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-1.2-1" class="pilcrow">¶</a></p>
</section>
</section>
</div>
<div id="BGPSEGMENTS">
<section id="section-2">
      <h2 id="name-bgp-peering-segments">
<a href="#section-2" class="section-number selfRef">2. </a><a href="#name-bgp-peering-segments" class="section-name selfRef">BGP Peering Segments</a>
      </h2>
<p id="section-2-1">As defined in <span>[<a href="#RFC8402" class="xref">RFC8402</a>]</span>, certain
      segments are defined by a BGP-EPE-capable node and correspond to their
      attached peers. These segments are called BGP Peering Segments or BGP
      Peering SIDs. They enable the expression of source-routed inter-domain
      paths.<a href="#section-2-1" class="pilcrow">¶</a></p>
<p id="section-2-2">An ingress border router of an AS may compose a list of segments to
      steer a flow along a selected path within the AS, towards a selected
      egress border router C of the AS and through a specific peer. At
      minimum, a BGP Egress Peer Engineering policy applied at an ingress
      EPE involves two segments: the Node SID of the chosen egress EPE and
      then the BGP Peering Segment for the chosen egress EPE peer or peering
      interface.<a href="#section-2-2" class="pilcrow">¶</a></p>
<p id="section-2-3"><span>[<a href="#RFC8402" class="xref">RFC8402</a>]</span> defines three types
      of BGP Peering Segments/SIDs: PeerNode SID, PeerAdj SID, and PeerSet
      SID.<a href="#section-2-3" class="pilcrow">¶</a></p>
<ul class="ulEmpty normal">
<li class="ulEmpty normal" id="section-2-4.1">
          <span class="break"></span><dl class="dlParallel" id="section-2-4.1.1">
            <dt id="section-2-4.1.1.1">Peer Node Segment:
</dt>
            <dd style="margin-left: 1.5em" id="section-2-4.1.1.2">A segment describing a peer, including the SID (PeerNode SID) allocated to it<a href="#section-2-4.1.1.2" class="pilcrow">¶</a>
</dd>
            <dd class="break"></dd>
<dt id="section-2-4.1.1.3">Peer Adjacency Segment:
</dt>
            <dd style="margin-left: 1.5em" id="section-2-4.1.1.4">A segment describing a link, including the SID (PeerAdj SID) allocated to it<a href="#section-2-4.1.1.4" class="pilcrow">¶</a>
</dd>
            <dd class="break"></dd>
<dt id="section-2-4.1.1.5">Peer Set Segment:
</dt>
            <dd style="margin-left: 1.5em" id="section-2-4.1.1.6">A segment describing a link or a node that is part of the set, including
the SID (PeerSet SID) allocated to the set<a href="#section-2-4.1.1.6" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
</dl>
</li>
      </ul>
</section>
</div>
<div id="TOPOBGPLS">
<section id="section-3">
      <h2 id="name-distribution-of-topology-an">
<a href="#section-3" class="section-number selfRef">3. </a><a href="#name-distribution-of-topology-an" class="section-name selfRef">Distribution of Topology and TE Information Using BGP-LS</a>
      </h2>
<p id="section-3-1">In ships-in-the-night mode with respect to the pre-existing iBGP
      design, a Border Gateway Protocol - Link State (BGP-LS) <span>[<a href="#RFC7752" class="xref">RFC7752</a>]</span> session is established between the
      BGP-EPE-enabled border router and the BGP-EPE controller.<a href="#section-3-1" class="pilcrow">¶</a></p>
<p id="section-3-2">As a result of its local configuration and according to the behavior
      described in <span>[<a href="#RFC9086" class="xref">RFC9086</a>]</span>,
      Node C allocates the following BGP Peering Segments <span>[<a href="#RFC8402" class="xref">RFC8402</a>]</span>:<a href="#section-3-2" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-3-3.1">A PeerNode segment for each of its defined peers (D: 1012, E: 1022
          and F: 1052).<a href="#section-3-3.1" class="pilcrow">¶</a>
</li>
        <li class="normal" id="section-3-3.2">A PeerAdj segment for each recursing interface to a multi-hop
          peer (e.g., the upper and lower interfaces from C to F in <a href="#REFDIAGRAMFIG" class="xref">Figure 1</a>).<a href="#section-3-3.2" class="pilcrow">¶</a>
</li>
        <li class="normal" id="section-3-3.3">A PeerSet segment to the set of peers (E and F). In this case, the
          PeerSet represents a set of peers (E, F) belonging to the same AS
          (AS 3).<a href="#section-3-3.3" class="pilcrow">¶</a>
</li>
      </ul>
<p id="section-3-4">C programs its forwarding table accordingly:<a href="#section-3-4" class="pilcrow">¶</a></p>
<div id="c-table">
<table class="center" id="table-1">
        <caption><a href="#table-1" class="selfRef">Table 1</a></caption>
<thead>
          <tr>
            <th class="text-left" rowspan="1" colspan="1">Incoming Label</th>
            <th class="text-left" rowspan="1" colspan="1">Operation</th>
            <th class="text-left" rowspan="1" colspan="1">Outgoing Interface</th>
          </tr>
        </thead>
        <tbody>
          <tr>
            <td class="text-left" rowspan="1" colspan="1">1012</td>
            <td class="text-left" rowspan="1" colspan="1">POP</td>
            <td class="text-left" rowspan="1" colspan="1">link to D</td>
          </tr>
          <tr>
            <td class="text-left" rowspan="1" colspan="1">1022</td>
            <td class="text-left" rowspan="1" colspan="1">POP</td>
            <td class="text-left" rowspan="1" colspan="1">link to E</td>
          </tr>
          <tr>
            <td class="text-left" rowspan="1" colspan="1">1032</td>
            <td class="text-left" rowspan="1" colspan="1">POP</td>
            <td class="text-left" rowspan="1" colspan="1">upper link to F</td>
          </tr>
          <tr>
            <td class="text-left" rowspan="1" colspan="1">1042</td>
            <td class="text-left" rowspan="1" colspan="1">POP</td>
            <td class="text-left" rowspan="1" colspan="1">lower link to F</td>
          </tr>
          <tr>
            <td class="text-left" rowspan="1" colspan="1">1052</td>
            <td class="text-left" rowspan="1" colspan="1">POP</td>
            <td class="text-left" rowspan="1" colspan="1">load balance on any link to F</td>
          </tr>
          <tr>
            <td class="text-left" rowspan="1" colspan="1">1060</td>
            <td class="text-left" rowspan="1" colspan="1">POP</td>
            <td class="text-left" rowspan="1" colspan="1">load balance on any link to E or to F</td>
          </tr>
        </tbody>
      </table>
</div>
<p id="section-3-6">C signals each related BGP-LS instance of Network Layer Reachability
      Information (NLRI) to the BGP-EPE controller.  Each such BGP-LS route is
      described in the following subsections according to the encoding details
      defined in <span>[<a href="#RFC9086" class="xref">RFC9086</a>]</span>.<a href="#section-3-6" class="pilcrow">¶</a></p>
<div id="PEERNODED">
<section id="section-3.1">
        <h3 id="name-peernode-sid-to-d">
<a href="#section-3.1" class="section-number selfRef">3.1. </a><a href="#name-peernode-sid-to-d" class="section-name selfRef">PeerNode SID to D</a>
        </h3>
<p id="section-3.1-1">Descriptors:<a href="#section-3.1-1" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-3.1-2.1">Local Node Descriptors (BGP router-ID, ASN, BGP-LS Identifier):
            192.0.2.3, AS1, 1000<a href="#section-3.1-2.1" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-3.1-2.2">Remote Node Descriptors (BGP router-ID, ASN): 192.0.2.4,
            AS2<a href="#section-3.1-2.2" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-3.1-2.3">Link Descriptors (IPv6 Interface Address, IPv6 Neighbor
            Address): 2001:db8:cd::c, 2001:db8:cd::d<a href="#section-3.1-2.3" class="pilcrow">¶</a>
</li>
        </ul>
<p id="section-3.1-3">Attributes:<a href="#section-3.1-3" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-3.1-4.1">PeerNode SID: 1012<a href="#section-3.1-4.1" class="pilcrow">¶</a>
</li>
        </ul>
</section>
</div>
<div id="PEERNODEE">
<section id="section-3.2">
        <h3 id="name-peernode-sid-to-e">
<a href="#section-3.2" class="section-number selfRef">3.2. </a><a href="#name-peernode-sid-to-e" class="section-name selfRef">PeerNode SID to E</a>
        </h3>
<p id="section-3.2-1">Descriptors:<a href="#section-3.2-1" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-3.2-2.1">Local Node Descriptors (BGP router-ID, ASN, BGP-LS
            Identifier): 192.0.2.3, AS1, 1000<a href="#section-3.2-2.1" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-3.2-2.2">Remote Node Descriptors (BGP router-ID, ASN): 192.0.2.5,
            AS3<a href="#section-3.2-2.2" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-3.2-2.3">Link Descriptors (IPv6 Interface Address, IPv6 Neighbor
            Address): 2001:db8:ce::c, 2001:db8:ce::e<a href="#section-3.2-2.3" class="pilcrow">¶</a>
</li>
        </ul>
<p id="section-3.2-3">Attributes:<a href="#section-3.2-3" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-3.2-4.1">PeerNode SID: 1022<a href="#section-3.2-4.1" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-3.2-4.2">PeerSetSID: 1060<a href="#section-3.2-4.2" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-3.2-4.3">Link Attributes: see <span><a href="https://www.rfc-editor.org/rfc/rfc7752#section-3.3.2" class="relref">Section 3.3.2</a> of [<a href="#RFC7752" class="xref">RFC7752</a>]</span><a href="#section-3.2-4.3" class="pilcrow">¶</a>
</li>
        </ul>
</section>
</div>
<div id="PEERNODEF">
<section id="section-3.3">
        <h3 id="name-peernode-sid-to-f">
<a href="#section-3.3" class="section-number selfRef">3.3. </a><a href="#name-peernode-sid-to-f" class="section-name selfRef">PeerNode SID to F</a>
        </h3>
<p id="section-3.3-1">Descriptors:<a href="#section-3.3-1" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-3.3-2.1">Local Node Descriptors (BGP router-ID, ASN, BGP-LS
            Identifier): 192.0.2.3, AS1, 1000<a href="#section-3.3-2.1" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-3.3-2.2">Remote Node Descriptors (BGP router-ID, ASN): 192.0.2.6,
            AS3<a href="#section-3.3-2.2" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-3.3-2.3">Link Descriptors (IPv6 Interface Address, IPv6 Neighbor
            Address): 2001:db8:c::c, 2001:db8:f::f<a href="#section-3.3-2.3" class="pilcrow">¶</a>
</li>
        </ul>
<p id="section-3.3-3">Attributes:<a href="#section-3.3-3" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-3.3-4.1">PeerNode SID: 1052<a href="#section-3.3-4.1" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-3.3-4.2">PeerSetSID: 1060<a href="#section-3.3-4.2" class="pilcrow">¶</a>
</li>
        </ul>
</section>
</div>
<div id="PEERNODEFLINK1">
<section id="section-3.4">
        <h3 id="name-first-peeradj-to-f">
<a href="#section-3.4" class="section-number selfRef">3.4. </a><a href="#name-first-peeradj-to-f" class="section-name selfRef">First PeerAdj to F</a>
        </h3>
<p id="section-3.4-1">Descriptors:<a href="#section-3.4-1" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-3.4-2.1">Local Node Descriptors (BGP router-ID, ASN, BGP-LS
            Identifier): 192.0.2.3, AS1, 1000<a href="#section-3.4-2.1" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-3.4-2.2">Remote Node Descriptors (BGP router-ID, ASN): 192.0.2.6,
            AS3<a href="#section-3.4-2.2" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-3.4-2.3">Link Descriptors (IPv6 Interface Address, IPv6 Neighbor
            Address): 2001:db8:cf1::c, 2001:db8:cf1::f<a href="#section-3.4-2.3" class="pilcrow">¶</a>
</li>
        </ul>
<p id="section-3.4-3">Attributes:<a href="#section-3.4-3" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-3.4-4.1">PeerAdj-SID: 1032<a href="#section-3.4-4.1" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-3.4-4.2">Link Attributes: see <span><a href="https://www.rfc-editor.org/rfc/rfc7752#section-3.3.2" class="relref">Section 3.3.2</a> of [<a href="#RFC7752" class="xref">RFC7752</a>]</span><a href="#section-3.4-4.2" class="pilcrow">¶</a>
</li>
        </ul>
</section>
</div>
<div id="PEERNODEFLINK2">
<section id="section-3.5">
        <h3 id="name-second-peeradj-to-f">
<a href="#section-3.5" class="section-number selfRef">3.5. </a><a href="#name-second-peeradj-to-f" class="section-name selfRef">Second PeerAdj to F</a>
        </h3>
<p id="section-3.5-1">Descriptors:<a href="#section-3.5-1" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-3.5-2.1">Local Node Descriptors (BGP router-ID, ASN, BGP-LS
            Identifier): 192.0.2.3 , AS1, 1000<a href="#section-3.5-2.1" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-3.5-2.2">Remote Node Descriptors (peer router-ID, peer ASN): 192.0.2.6,
            AS3<a href="#section-3.5-2.2" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-3.5-2.3">Link Descriptors (IPv6 Interface Address, IPv6 Neighbor
            Address): 2001:db8:cf2::c, 2001:db8:cf2::f<a href="#section-3.5-2.3" class="pilcrow">¶</a>
</li>
        </ul>
<p id="section-3.5-3">Attributes:<a href="#section-3.5-3" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-3.5-4.1">PeerAdj-SID: 1042<a href="#section-3.5-4.1" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-3.5-4.2">Link Attributes: see <span><a href="https://www.rfc-editor.org/rfc/rfc7752#section-3.3.2" class="relref">Section 3.3.2</a> of [<a href="#RFC7752" class="xref">RFC7752</a>]</span><a href="#section-3.5-4.2" class="pilcrow">¶</a>
</li>
        </ul>
</section>
</div>
<div id="FRR">
<section id="section-3.6">
        <h3 id="name-fast-reroute-frr">
<a href="#section-3.6" class="section-number selfRef">3.6. </a><a href="#name-fast-reroute-frr" class="section-name selfRef">Fast Reroute (FRR)</a>
        </h3>
<p id="section-3.6-1">A BGP-EPE-enabled border router <span class="bcp14">MAY</span> allocate an FRR backup entry on
        a per-BGP-Peering-SID basis. One example is as follows:<a href="#section-3.6-1" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-3.6-2.1">
            <p id="section-3.6-2.1.1">PeerNode SID<a href="#section-3.6-2.1.1" class="pilcrow">¶</a></p>
<ol start="1" type="1" class="normal type-1" id="section-3.6-2.1.2">
              <li id="section-3.6-2.1.2.1">If multi-hop, back up via the remaining PeerADJ SIDs (if
                available) to the same peer.<a href="#section-3.6-2.1.2.1" class="pilcrow">¶</a>
</li>
              <li id="section-3.6-2.1.2.2">Else, back up via another PeerNode SID to the same AS.<a href="#section-3.6-2.1.2.2" class="pilcrow">¶</a>
</li>
              <li id="section-3.6-2.1.2.3">Else, pop the PeerNode SID and perform an IP lookup.<a href="#section-3.6-2.1.2.3" class="pilcrow">¶</a>
</li>
            </ol>
</li>
          <li class="normal" id="section-3.6-2.2">
            <p id="section-3.6-2.2.1">PeerAdj SID<a href="#section-3.6-2.2.1" class="pilcrow">¶</a></p>
<ol start="1" type="1" class="normal type-1" id="section-3.6-2.2.2">
              <li id="section-3.6-2.2.2.1">If to a multi-hop peer, back up via the remaining PeerADJ
                SIDs (if available) to the same peer.<a href="#section-3.6-2.2.2.1" class="pilcrow">¶</a>
</li>
              <li id="section-3.6-2.2.2.2">Else, back up via a PeerNode SID to the same AS.<a href="#section-3.6-2.2.2.2" class="pilcrow">¶</a>
</li>
              <li id="section-3.6-2.2.2.3">Else, pop the PeerNode SID and perform an IP lookup.<a href="#section-3.6-2.2.2.3" class="pilcrow">¶</a>
</li>
            </ol>
</li>
          <li class="normal" id="section-3.6-2.3">
            <p id="section-3.6-2.3.1">PeerSet SID<a href="#section-3.6-2.3.1" class="pilcrow">¶</a></p>
<ol start="1" type="1" class="normal type-1" id="section-3.6-2.3.2">
              <li id="section-3.6-2.3.2.1">Back up via remaining PeerNode SIDs in the same PeerSet.<a href="#section-3.6-2.3.2.1" class="pilcrow">¶</a>
</li>
              <li id="section-3.6-2.3.2.2">Else, pop the PeerNode SID and IP lookup.<a href="#section-3.6-2.3.2.2" class="pilcrow">¶</a>
</li>
            </ol>
</li>
        </ul>
<p id="section-3.6-3">Let's illustrate different types of possible backups using the
        reference diagram and considering the Peering SIDs allocated by C.<a href="#section-3.6-3" class="pilcrow">¶</a></p>
<p id="section-3.6-4">PeerNode SID 1052, allocated by C for peer F:<a href="#section-3.6-4" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-3.6-5.1">Upon the failure of the upper connected link CF, C can reroute
            all the traffic onto the lower CF link to the same peer (F).<a href="#section-3.6-5.1" class="pilcrow">¶</a>
</li>
        </ul>
<p id="section-3.6-6">PeerNode SID 1022, allocated by C for peer E:<a href="#section-3.6-6" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-3.6-7.1">Upon the failure of the connected link CE, C can reroute all
            the traffic onto the link to PeerNode SID 1052 (F).<a href="#section-3.6-7.1" class="pilcrow">¶</a>
</li>
        </ul>
<p id="section-3.6-8">PeerNode SID 1012, allocated by C for peer D:<a href="#section-3.6-8" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-3.6-9.1">Upon the failure of the connected link CD, C can pop the
            PeerNode SID and look up the IP destination address in its FIB and
            route accordingly.<a href="#section-3.6-9.1" class="pilcrow">¶</a>
</li>
        </ul>
<p id="section-3.6-10">PeerSet SID 1060, allocated by C for the set of peers E and F:<a href="#section-3.6-10" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-3.6-11.1">Upon the failure of a connected link in the group, the traffic
            to PeerSet SID 1060 is rerouted on any other member of the
            group.<a href="#section-3.6-11.1" class="pilcrow">¶</a>
</li>
        </ul>
<p id="section-3.6-12">For specific business reasons, the operator might not want the
        default FRR behavior applied to a PeerNode SID or any of its dependent
        PeerADJ SIDs.<a href="#section-3.6-12" class="pilcrow">¶</a></p>
<p id="section-3.6-13">The operator should be able to associate a specific backup PeerNode
        SID for a PeerNode SID; e.g., 1022 (E) must be backed up by 1012 (D),
        which overrules the default behavior that would have preferred F as a
        backup for E.<a href="#section-3.6-13" class="pilcrow">¶</a></p>
</section>
</div>
</section>
</div>
<div id="BGPPECTRL">
<section id="section-4">
      <h2 id="name-bgp-epe-controller">
<a href="#section-4" class="section-number selfRef">4. </a><a href="#name-bgp-epe-controller" class="section-name selfRef">BGP-EPE Controller</a>
      </h2>
<p id="section-4-1">In this section, Let's provide a non-exhaustive set of inputs that a
      BGP-EPE controller would likely collect such as to perform the BGP-EPE
      policy decision.<a href="#section-4-1" class="pilcrow">¶</a></p>
<p id="section-4-2">The exhaustive definition is outside the scope of this document.<a href="#section-4-2" class="pilcrow">¶</a></p>
<div id="PATHSFROMPEERS">
<section id="section-4.1">
        <h3 id="name-valid-paths-from-peers">
<a href="#section-4.1" class="section-number selfRef">4.1. </a><a href="#name-valid-paths-from-peers" class="section-name selfRef">Valid Paths from Peers</a>
        </h3>
<p id="section-4.1-1">The BGP-EPE controller should collect all the BGP paths (i.e., IP
        destination prefixes) advertised by all the BGP-EPE-enabled border
        routers.<a href="#section-4.1-1" class="pilcrow">¶</a></p>
<p id="section-4.1-2">This could be realized by setting an iBGP session with the
        BGP-EPE-enabled border router, with the router configured to advertise
        all paths using BGP ADD-PATH <span>[<a href="#RFC7911" class="xref">RFC7911</a>]</span>
        and the original next hop preserved.<a href="#section-4.1-2" class="pilcrow">¶</a></p>
<p id="section-4.1-3">In this case, C would advertise the following Internet routes to
        the BGP-EPE controller:<a href="#section-4.1-3" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-4.1-4.1">
            <p id="section-4.1-4.1.1">NLRI &lt;2001:db8:abcd::/48&gt;, next hop 2001:db8:cd::d, AS Path {AS 2, 4}<a href="#section-4.1-4.1.1" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-4.1-4.1.2.1">X (i.e., the BGP-EPE controller) knows that C receives a
                path to 2001:db8:abcd::/48 via neighbor 2001:db8:cd::d of
                AS2.<a href="#section-4.1-4.1.2.1" class="pilcrow">¶</a>
</li>
            </ul>
</li>
          <li class="normal" id="section-4.1-4.2">
            <p id="section-4.1-4.2.1">NLRI &lt;2001:db8:abcd::/48&gt;, next hop 2001:db8:ce::e, AS Path {AS 3, 4}<a href="#section-4.1-4.2.1" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-4.1-4.2.2.1">X knows that C receives a path to 2001:db8:abcd::/48 via
                neighbor 2001:db8:ce::e of AS2.<a href="#section-4.1-4.2.2.1" class="pilcrow">¶</a>
</li>
            </ul>
</li>
          <li class="normal" id="section-4.1-4.3">
            <p id="section-4.1-4.3.1">NLRI &lt;2001:db8:abcd::/48&gt;, next hop 2001:db8:f::f, AS Path {AS 3, 4}<a href="#section-4.1-4.3.1" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-4.1-4.3.2.1">X knows that C has an eBGP path to 2001:db8:abcd::/48 via
                AS3 via neighbor 2001:db8:f::f.<a href="#section-4.1-4.3.2.1" class="pilcrow">¶</a>
</li>
            </ul>
</li>
        </ul>
<p id="section-4.1-5">An alternative option would be for a BGP-EPE collector to use the
        BGP Monitoring Protocol (BMP) <span>[<a href="#RFC7854" class="xref">RFC7854</a>]</span> to track the Adj-RIB-In of BGP-EPE-enabled border
        routers.<a href="#section-4.1-5" class="pilcrow">¶</a></p>
</section>
</div>
<div id="INTRATOPO">
<section id="section-4.2">
        <h3 id="name-intra-domain-topology">
<a href="#section-4.2" class="section-number selfRef">4.2. </a><a href="#name-intra-domain-topology" class="section-name selfRef">Intra-Domain Topology</a>
        </h3>
<p id="section-4.2-1">The BGP-EPE controller should collect the internal topology and the
        related IGP SIDs.<a href="#section-4.2-1" class="pilcrow">¶</a></p>
<p id="section-4.2-2">This could be realized by collecting the IGP Link-State Database
        (LSDB) of each area or running a BGP-LS session with a node in each
        IGP area.<a href="#section-4.2-2" class="pilcrow">¶</a></p>
</section>
</div>
<div id="EXTRATOPO">
<section id="section-4.3">
        <h3 id="name-external-topology">
<a href="#section-4.3" class="section-number selfRef">4.3. </a><a href="#name-external-topology" class="section-name selfRef">External Topology</a>
        </h3>
<p id="section-4.3-1">Thanks to the collected BGP-LS routes described in <a href="#TOPOBGPLS" class="xref">Section 3</a>, the BGP-EPE controller is able to maintain an
        accurate description of the egress topology of Node C. Furthermore,
        the BGP-EPE controller is able to associate BGP Peering SIDs to the
        various components of the external topology.<a href="#section-4.3-1" class="pilcrow">¶</a></p>
</section>
</div>
<div id="SLA">
<section id="section-4.4">
        <h3 id="name-sla-characteristics-of-each">
<a href="#section-4.4" class="section-number selfRef">4.4. </a><a href="#name-sla-characteristics-of-each" class="section-name selfRef">SLA Characteristics of Each Peer</a>
        </h3>
<p id="section-4.4-1">The BGP-EPE controller might collect Service Level Agreement (SLA)
        characteristics across peers. This requires a BGP-EPE solution, as the
        SLA probes need to be steered via non-best-path peers.<a href="#section-4.4-1" class="pilcrow">¶</a></p>
<p id="section-4.4-2">Unidirectional SLA monitoring of the desired path is likely
        required. This might be possible when the application is controlled at
        the source and the receiver side. Unidirectional monitoring
        dissociates the SLA characteristic of the return path (which cannot
        usually be controlled) from the forward path (the one of interest for
        pushing content from a source to a consumer and the one that can be
        controlled).<a href="#section-4.4-2" class="pilcrow">¶</a></p>
<p id="section-4.4-3">Alternatively, Metric Extensions, as defined in <span>[<a href="#RFC8570" class="xref">RFC8570</a>]</span>, could also be advertised using BGP-LS <span>[<a href="#RFC8571" class="xref">RFC8571</a>]</span>.<a href="#section-4.4-3" class="pilcrow">¶</a></p>
</section>
</div>
<div id="MATRIX">
<section id="section-4.5">
        <h3 id="name-traffic-matrix">
<a href="#section-4.5" class="section-number selfRef">4.5. </a><a href="#name-traffic-matrix" class="section-name selfRef">Traffic Matrix</a>
        </h3>
<p id="section-4.5-1">The BGP-EPE controller might collect the traffic matrix to its
        peers or the final destinations. IP Flow Information Export (IPFIX)
        <span>[<a href="#RFC7011" class="xref">RFC7011</a>]</span> is a likely option.<a href="#section-4.5-1" class="pilcrow">¶</a></p>
<p id="section-4.5-2">An alternative option consists of collecting the link utilization
        statistics of each of the internal and external links, also available
        in the current definition in <span>[<a href="#RFC7752" class="xref">RFC7752</a>]</span>.<a href="#section-4.5-2" class="pilcrow">¶</a></p>
</section>
</div>
<div id="BUSINESS">
<section id="section-4.6">
        <h3 id="name-business-policies">
<a href="#section-4.6" class="section-number selfRef">4.6. </a><a href="#name-business-policies" class="section-name selfRef">Business Policies</a>
        </h3>
<p id="section-4.6-1">The BGP-EPE controller should be configured or collect business
        policies through any desired mechanisms. These mechanisms by which
        these policies are configured or collected are outside the scope of
        this document.<a href="#section-4.6-1" class="pilcrow">¶</a></p>
</section>
</div>
<div id="BGPPOLICY">
<section id="section-4.7">
        <h3 id="name-bgp-epe-policy">
<a href="#section-4.7" class="section-number selfRef">4.7. </a><a href="#name-bgp-epe-policy" class="section-name selfRef">BGP-EPE Policy</a>
        </h3>
<p id="section-4.7-1">On the basis of all these inputs (and likely others), the BGP-EPE
        controller decides to steer some demands away from their best BGP
        path.<a href="#section-4.7-1" class="pilcrow">¶</a></p>
<p id="section-4.7-2">The BGP-EPE policy is likely expressed as a two-entry segment list
        where the first element is the IGP Prefix-SID of the selected egress
        border router and the second element is a BGP Peering SID at the
        selected egress border router.<a href="#section-4.7-2" class="pilcrow">¶</a></p>
<p id="section-4.7-3">A few examples are provided hereafter:<a href="#section-4.7-3" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-4.7-4.1">Prefer egress PE C and peer AS AS2: {64, 1012}. "64" being the
            SID of PE C as defined in <a href="#PROBSTATE" class="xref">Section 1.1</a>.<a href="#section-4.7-4.1" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-4.7-4.2">Prefer egress PE C and peer AS AS3 via eBGP peer
            2001:db8:ce::e, {64, 1022}.<a href="#section-4.7-4.2" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-4.7-4.3">Prefer egress PE C and peer AS AS3 via eBGP peer 2001:db8:f::f,
            {64, 1052}.<a href="#section-4.7-4.3" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-4.7-4.4">Prefer egress PE C and peer AS AS3 via interface
            2001:db8:cf2::f of multi-hop eBGP peer 2001:db8:f::f, {64,
            1042}.<a href="#section-4.7-4.4" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-4.7-4.5">Prefer egress PE C and any interface to any peer in the group
            1060: {64, 1060}.<a href="#section-4.7-4.5" class="pilcrow">¶</a>
</li>
        </ul>
<p id="section-4.7-5">Note that the first SID could be replaced by a list of segments.
        This is useful when an explicit path within the domain is required for
        traffic-engineering purposes. For example, if the Prefix-SID of Node B
        is 60 and the BGP-EPE controller would like to steer the traffic from
        A to C via B then through the external link to peer D, then the segment
        list would be {60, 64, 1012}.<a href="#section-4.7-5" class="pilcrow">¶</a></p>
</section>
</div>
</section>
</div>
<div id="PROGRINPUTPOL">
<section id="section-5">
      <h2 id="name-programming-an-input-policy">
<a href="#section-5" class="section-number selfRef">5. </a><a href="#name-programming-an-input-policy" class="section-name selfRef">Programming an Input Policy</a>
      </h2>
<p id="section-5-1">The detailed/exhaustive description of all the means to implement a
      BGP-EPE policy are outside the scope of this document. A few examples
      are provided in this section.<a href="#section-5-1" class="pilcrow">¶</a></p>
<div id="ATHOST">
<section id="section-5.1">
        <h3 id="name-at-a-host">
<a href="#section-5.1" class="section-number selfRef">5.1. </a><a href="#name-at-a-host" class="section-name selfRef">At a Host</a>
        </h3>
<p id="section-5.1-1">A static IP/MPLS route can be programmed at the host H. The static
        route would define a destination prefix, a next hop, and a label stack
        to push. Assuming the same Segment Routing Global Block (SRGB), at
        least on all access routers connecting the hosts, the same policy can
        be programmed across all hosts, which is convenient.<a href="#section-5.1-1" class="pilcrow">¶</a></p>
</section>
</div>
<div id="ATROUTER">
<section id="section-5.2">
        <h3 id="name-at-a-router-sr-traffic-engi">
<a href="#section-5.2" class="section-number selfRef">5.2. </a><a href="#name-at-a-router-sr-traffic-engi" class="section-name selfRef">At a Router - SR Traffic-Engineering Tunnel</a>
        </h3>
<p id="section-5.2-1">The BGP-EPE controller can configure the ingress border router with
        an SR traffic-engineering tunnel T1 and a steering policy S1, which
        causes a certain class of traffic to be mapped on the tunnel T1.<a href="#section-5.2-1" class="pilcrow">¶</a></p>
<p id="section-5.2-2">The tunnel T1 would be configured to push the required segment
        list.<a href="#section-5.2-2" class="pilcrow">¶</a></p>
<p id="section-5.2-3">The tunnel and the steering policy could be configured via multiple
        means. A few examples are given below:<a href="#section-5.2-3" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-5.2-4.1">The Path Computation Element Communication Protocol (PCEP) according
          to <span>[<a href="#RFC8664" class="xref">RFC8664</a>]</span> and <span>[<a href="#RFC8281" class="xref">RFC8281</a>]</span><a href="#section-5.2-4.1" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-5.2-4.2">NETCONF <span>[<a href="#RFC6241" class="xref">RFC6241</a>]</span><a href="#section-5.2-4.2" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-5.2-4.3">Other static or ephemeral APIs<a href="#section-5.2-4.3" class="pilcrow">¶</a>
</li>
        </ul>
<p id="section-5.2-5">Example: at router A (<a href="#REFDIAGRAMFIG" class="xref">Figure 1</a>).<a href="#section-5.2-5" class="pilcrow">¶</a></p>
<div id="section-5.2-6">
<pre class="sourcecode">
Tunnel T1: push {64, 1042}
IP route L/8 set next-hop T1
</pre><a href="#section-5.2-6" class="pilcrow">¶</a>
</div>
</section>
</div>
<div id="ATROUTER8277">
<section id="section-5.3">
        <h3 id="name-at-a-router-unicast-route-l">
<a href="#section-5.3" class="section-number selfRef">5.3. </a><a href="#name-at-a-router-unicast-route-l" class="section-name selfRef">At a Router - Unicast Route Labeled Using BGP (RFC 8277)</a>
        </h3>
<p id="section-5.3-1">The BGP-EPE controller could build a unicast route labeled using BGP
   <span>[<a href="#RFC8277" class="xref">RFC8277</a>]</span> (from scratch) and send it to the ingress
   router.<a href="#section-5.3-1" class="pilcrow">¶</a></p>
<p id="section-5.3-2">Such a route would require the following:<a href="#section-5.3-2" class="pilcrow">¶</a></p>
<span class="break"></span><dl class="dlNewline" id="section-5.3-3">
          <dt id="section-5.3-3.1">NLRI 
</dt>
          <dd style="margin-left: 1.5em" id="section-5.3-3.2">the destination prefix to engineer (e.g., L/8)<a href="#section-5.3-3.2" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-5.3-3.3">Next Hop
</dt>
          <dd style="margin-left: 1.5em" id="section-5.3-3.4">the selected egress border router: C<a href="#section-5.3-3.4" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-5.3-3.5">Label 
</dt>
          <dd style="margin-left: 1.5em" id="section-5.3-3.6">the selected egress peer: 1042<a href="#section-5.3-3.6" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-5.3-3.7">Autonomous System (AS) path
</dt>
          <dd style="margin-left: 1.5em" id="section-5.3-3.8">the selected valid AS path<a href="#section-5.3-3.8" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
</dl>
<p id="section-5.3-4">
  Some BGP policy to ensure it will be selected as best by the ingress
  router. Note that as discussed in <span><a href="https://www.rfc-editor.org/rfc/rfc8277#section-5" class="relref">Section 5</a> of [<a href="#RFC8277" class="xref">RFC8277</a>]</span>, the comparison of a labeled and unlabeled unicast BGP route
  is implementation dependent and hence may require an implementation-specific
  policy on each ingress router.<a href="#section-5.3-4" class="pilcrow">¶</a></p>
<p id="section-5.3-5">This unicast route labeled using BGP <span>[<a href="#RFC8277" class="xref">RFC8277</a>]</span> "overwrites"
        an equivalent or less-specific "best path". As the
        best path is changed, this BGP-EPE input policy option may influence
        the path propagated to the upstream peer/customers. Indeed,
        implementations treating the SAFI-1 and SAFI-4 routes for a given
        prefix as comparable would trigger a BGP WITHDRAW of the SAFI-1 route
        to their BGP upstream peers.<a href="#section-5.3-5" class="pilcrow">¶</a></p>
</section>
</div>
<div id="ATROUTERVPN">
<section id="section-5.4">
        <h3 id="name-at-a-router-vpn-policy-rout">
<a href="#section-5.4" class="section-number selfRef">5.4. </a><a href="#name-at-a-router-vpn-policy-rout" class="section-name selfRef">At a Router - VPN Policy Route</a>
        </h3>
<p id="section-5.4-1">The BGP-EPE controller could build a VPNv4 route (from scratch) and
        send it to the ingress router.<a href="#section-5.4-1" class="pilcrow">¶</a></p>
<p id="section-5.4-2">Such a route would require the following:<a href="#section-5.4-2" class="pilcrow">¶</a></p>
<span class="break"></span><dl class="dlNewline" id="section-5.4-3">
          <dt id="section-5.4-3.1">NLRI
</dt>
          <dd style="margin-left: 1.5em" id="section-5.4-3.2">the destination prefix to engineer: e.g., L/8<a href="#section-5.4-3.2" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-5.4-3.3">Next Hop
</dt>
          <dd style="margin-left: 1.5em" id="section-5.4-3.4">the selected egress border router: C<a href="#section-5.4-3.4" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-5.4-3.5">Label
</dt>
          <dd style="margin-left: 1.5em" id="section-5.4-3.6">the selected egress peer: 1042<a href="#section-5.4-3.6" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-5.4-3.7">Route-Target
</dt>
          <dd style="margin-left: 1.5em" id="section-5.4-3.8">the selected appropriate VRF instance at the ingress router<a href="#section-5.4-3.8" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-5.4-3.9">AS path
</dt>
          <dd style="margin-left: 1.5em" id="section-5.4-3.10">the selected valid AS path<a href="#section-5.4-3.10" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
</dl>
<p id="section-5.4-4">
    Some BGP policy to ensure it will be selected as best by the ingress
    router in the related VRF instance.<a href="#section-5.4-4" class="pilcrow">¶</a></p>
<p id="section-5.4-5">The related VRF instance must be preconfigured. A VRF fallback to the main
        FIB might be beneficial to avoid replicating all the "normal" Internet
        paths in each VRF instance.<a href="#section-5.4-5" class="pilcrow">¶</a></p>
</section>
</div>
</section>
</div>
<div id="IPv6">
<section id="section-6">
      <h2 id="name-ipv6-data-plane">
<a href="#section-6" class="section-number selfRef">6. </a><a href="#name-ipv6-data-plane" class="section-name selfRef">IPv6 Data Plane</a>
      </h2>
<p id="section-6-1">The described solution is applicable to IPv6, either with MPLS-based
      or IPv6-native segments. In both cases, the same three steps of the
      solution are applicable:<a href="#section-6-1" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-6-2.1">BGP-LS-based signaling of the external topology and BGP Peering
          Segments to the BGP-EPE controller.<a href="#section-6-2.1" class="pilcrow">¶</a>
</li>
        <li class="normal" id="section-6-2.2">Collecting, by the BGP-EPE controller, various inputs to come up
        with a policy decision.<a href="#section-6-2.2" class="pilcrow">¶</a>
</li>
        <li class="normal" id="section-6-2.3">Programming at an ingress router or source host of the desired
          BGP-EPE policy, which consists of a list of segments to push on a
          defined traffic class.<a href="#section-6-2.3" class="pilcrow">¶</a>
</li>
      </ul>
</section>
</div>
<div id="BENEFITS">
<section id="section-7">
      <h2 id="name-benefits">
<a href="#section-7" class="section-number selfRef">7. </a><a href="#name-benefits" class="section-name selfRef">Benefits</a>
      </h2>
<p id="section-7-1">The BGP-EPE solutions described in this document have the following
      benefits:<a href="#section-7-1" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-7-2.1">No assumption on the iBGP design within AS1.<a href="#section-7-2.1" class="pilcrow">¶</a>
</li>
        <li class="normal" id="section-7-2.2">Next-hop-self on the Internet routes propagated to the ingress
          border routers is possible. This is a common design rule to minimize
          the number of IGP routes and to avoid importing external churn into
          the internal routing domain.<a href="#section-7-2.2" class="pilcrow">¶</a>
</li>
        <li class="normal" id="section-7-2.3">Consistent support for traffic engineering within the domain and
          at the external edge of the domain.<a href="#section-7-2.3" class="pilcrow">¶</a>
</li>
        <li class="normal" id="section-7-2.4">Support for both host and ingress border router BGP-EPE policy
          programming.<a href="#section-7-2.4" class="pilcrow">¶</a>
</li>
        <li class="normal" id="section-7-2.5">BGP-EPE functionality is only required on the BGP-EPE-enabled
          egress border router and the BGP-EPE controller; an ingress policy
          can be programmed at the ingress border router without any new
          functionality.<a href="#section-7-2.5" class="pilcrow">¶</a>
</li>
        <li class="normal" id="section-7-2.6">Ability to deploy the same input policy across hosts connected to
        different routers (assuming the global property of IGP
        Prefix-SIDs).<a href="#section-7-2.6" class="pilcrow">¶</a>
</li>
      </ul>
</section>
</div>
<div id="IANA">
<section id="section-8">
      <h2 id="name-iana-considerations">
<a href="#section-8" class="section-number selfRef">8. </a><a href="#name-iana-considerations" class="section-name selfRef">IANA Considerations</a>
      </h2>
<p id="section-8-1">This document has no IANA actions.<a href="#section-8-1" class="pilcrow">¶</a></p>
</section>
</div>
<div id="Manageability">
<section id="section-9">
      <h2 id="name-manageability-consideration">
<a href="#section-9" class="section-number selfRef">9. </a><a href="#name-manageability-consideration" class="section-name selfRef">Manageability Considerations</a>
      </h2>
<p id="section-9-1">
The BGP-EPE use case described in this document requires BGP-LS <span>[<a href="#RFC7752" class="xref">RFC7752</a>]</span> extensions that are described in <span>[<a href="#RFC9086" class="xref">RFC9086</a>]</span> and that consists of additional BGP-LS
descriptors and TLVs.  Manageability functions of BGP-LS, described in <span>[<a href="#RFC7752" class="xref">RFC7752</a>]</span>, also apply to the extensions required by
the EPE use case.<a href="#section-9-1" class="pilcrow">¶</a></p>
<p id="section-9-2">Additional manageability considerations are described in <span>[<a href="#RFC9086" class="xref">RFC9086</a>]</span>.<a href="#section-9-2" class="pilcrow">¶</a></p>
</section>
</div>
<div id="Security">
<section id="section-10">
      <h2 id="name-security-considerations">
<a href="#section-10" class="section-number selfRef">10. </a><a href="#name-security-considerations" class="section-name selfRef">Security Considerations</a>
      </h2>
<p id="section-10-1"><span>[<a href="#RFC7752" class="xref">RFC7752</a>]</span> defines BGP-LS NLRI
      instances and their associated security aspects.<a href="#section-10-1" class="pilcrow">¶</a></p>
<p id="section-10-2"><span>[<a href="#RFC9086" class="xref">RFC9086</a>]</span> defines the BGP-LS extensions required by the BGP-EPE
      mechanisms described in this document. BGP-EPE BGP-LS extensions also
      include the related security.<a href="#section-10-2" class="pilcrow">¶</a></p>
</section>
</div>
<section id="section-11">
      <h2 id="name-references">
<a href="#section-11" class="section-number selfRef">11. </a><a href="#name-references" class="section-name selfRef">References</a>
      </h2>
<section id="section-11.1">
        <h3 id="name-normative-references">
<a href="#section-11.1" class="section-number selfRef">11.1. </a><a href="#name-normative-references" class="section-name selfRef">Normative References</a>
        </h3>
<dl class="references">
<dt id="RFC2119">[RFC2119]</dt>
        <dd>
<span class="refAuthor">Bradner, S.</span>, <span class="refTitle">"Key words for use in RFCs to Indicate Requirement Levels"</span>, <span class="seriesInfo">BCP 14</span>, <span class="seriesInfo">RFC 2119</span>, <span class="seriesInfo">DOI 10.17487/RFC2119</span>, <time datetime="1997-03" class="refDate">March 1997</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc2119">https://www.rfc-editor.org/info/rfc2119</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC7752">[RFC7752]</dt>
        <dd>
<span class="refAuthor">Gredler, H., Ed.</span>, <span class="refAuthor">Medved, J.</span>, <span class="refAuthor">Previdi, S.</span>, <span class="refAuthor">Farrel, A.</span>, and <span class="refAuthor">S. Ray</span>, <span class="refTitle">"North-Bound Distribution of Link-State and Traffic Engineering (TE) Information Using BGP"</span>, <span class="seriesInfo">RFC 7752</span>, <span class="seriesInfo">DOI 10.17487/RFC7752</span>, <time datetime="2016-03" class="refDate">March 2016</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc7752">https://www.rfc-editor.org/info/rfc7752</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC8174">[RFC8174]</dt>
        <dd>
<span class="refAuthor">Leiba, B.</span>, <span class="refTitle">"Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words"</span>, <span class="seriesInfo">BCP 14</span>, <span class="seriesInfo">RFC 8174</span>, <span class="seriesInfo">DOI 10.17487/RFC8174</span>, <time datetime="2017-05" class="refDate">May 2017</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8174">https://www.rfc-editor.org/info/rfc8174</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="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>, and <span class="refAuthor">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" class="refDate">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>
<dd class="break"></dd>
<dt id="RFC9086">[RFC9086]</dt>
      <dd>
<span class="refAuthor">Previdi, S.</span>, <span class="refAuthor">Talaulikar, K., Ed.</span>, <span class="refAuthor">Filsfils, C.</span>, <span class="refAuthor">Patel, K.</span>, <span class="refAuthor">Ray, S.</span>, and <span class="refAuthor">J. Dong</span>, <span class="refTitle">"Border Gateway Protocol - Link State (BGP-LS) Extensions for Segment Routing BGP Egress Peer Engineering"</span>, <span class="seriesInfo">RFC 9086</span>, <span class="seriesInfo">DOI 10.17487/RFC9086</span>, <time datetime="2021-08" class="refDate">August 2021</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc9086">https://www.rfc-editor.org/info/rfc9086</a>&gt;</span>. </dd>
<dd class="break"></dd>
</dl>
</section>
<section id="section-11.2">
        <h3 id="name-informative-references">
<a href="#section-11.2" class="section-number selfRef">11.2. </a><a href="#name-informative-references" class="section-name selfRef">Informative References</a>
        </h3>
<dl class="references">
<dt id="RFC6241">[RFC6241]</dt>
        <dd>
<span class="refAuthor">Enns, R., Ed.</span>, <span class="refAuthor">Bjorklund, M., Ed.</span>, <span class="refAuthor">Schoenwaelder, J., Ed.</span>, and <span class="refAuthor">A. Bierman, Ed.</span>, <span class="refTitle">"Network Configuration Protocol (NETCONF)"</span>, <span class="seriesInfo">RFC 6241</span>, <span class="seriesInfo">DOI 10.17487/RFC6241</span>, <time datetime="2011-06" class="refDate">June 2011</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc6241">https://www.rfc-editor.org/info/rfc6241</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC7011">[RFC7011]</dt>
        <dd>
<span class="refAuthor">Claise, B., Ed.</span>, <span class="refAuthor">Trammell, B., Ed.</span>, and <span class="refAuthor">P. Aitken</span>, <span class="refTitle">"Specification of the IP Flow Information Export (IPFIX) Protocol for the Exchange of Flow Information"</span>, <span class="seriesInfo">STD 77</span>, <span class="seriesInfo">RFC 7011</span>, <span class="seriesInfo">DOI 10.17487/RFC7011</span>, <time datetime="2013-09" class="refDate">September 2013</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc7011">https://www.rfc-editor.org/info/rfc7011</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC7854">[RFC7854]</dt>
        <dd>
<span class="refAuthor">Scudder, J., Ed.</span>, <span class="refAuthor">Fernando, R.</span>, and <span class="refAuthor">S. Stuart</span>, <span class="refTitle">"BGP Monitoring Protocol (BMP)"</span>, <span class="seriesInfo">RFC 7854</span>, <span class="seriesInfo">DOI 10.17487/RFC7854</span>, <time datetime="2016-06" class="refDate">June 2016</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc7854">https://www.rfc-editor.org/info/rfc7854</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC7855">[RFC7855]</dt>
        <dd>
<span class="refAuthor">Previdi, S., Ed.</span>, <span class="refAuthor">Filsfils, C., Ed.</span>, <span class="refAuthor">Decraene, B.</span>, <span class="refAuthor">Litkowski, S.</span>, <span class="refAuthor">Horneffer, M.</span>, and <span class="refAuthor">R. Shakir</span>, <span class="refTitle">"Source Packet Routing in Networking (SPRING) Problem Statement and Requirements"</span>, <span class="seriesInfo">RFC 7855</span>, <span class="seriesInfo">DOI 10.17487/RFC7855</span>, <time datetime="2016-05" class="refDate">May 2016</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc7855">https://www.rfc-editor.org/info/rfc7855</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC7911">[RFC7911]</dt>
        <dd>
<span class="refAuthor">Walton, D.</span>, <span class="refAuthor">Retana, A.</span>, <span class="refAuthor">Chen, E.</span>, and <span class="refAuthor">J. Scudder</span>, <span class="refTitle">"Advertisement of Multiple Paths in BGP"</span>, <span class="seriesInfo">RFC 7911</span>, <span class="seriesInfo">DOI 10.17487/RFC7911</span>, <time datetime="2016-07" class="refDate">July 2016</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc7911">https://www.rfc-editor.org/info/rfc7911</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC8277">[RFC8277]</dt>
        <dd>
<span class="refAuthor">Rosen, E.</span>, <span class="refTitle">"Using BGP to Bind MPLS Labels to Address Prefixes"</span>, <span class="seriesInfo">RFC 8277</span>, <span class="seriesInfo">DOI 10.17487/RFC8277</span>, <time datetime="2017-10" class="refDate">October 2017</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8277">https://www.rfc-editor.org/info/rfc8277</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC8281">[RFC8281]</dt>
        <dd>
<span class="refAuthor">Crabbe, E.</span>, <span class="refAuthor">Minei, I.</span>, <span class="refAuthor">Sivabalan, S.</span>, and <span class="refAuthor">R. Varga</span>, <span class="refTitle">"Path Computation Element Communication Protocol (PCEP) Extensions for PCE-Initiated LSP Setup in a Stateful PCE Model"</span>, <span class="seriesInfo">RFC 8281</span>, <span class="seriesInfo">DOI 10.17487/RFC8281</span>, <time datetime="2017-12" class="refDate">December 2017</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8281">https://www.rfc-editor.org/info/rfc8281</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC8570">[RFC8570]</dt>
        <dd>
<span class="refAuthor">Ginsberg, L., Ed.</span>, <span class="refAuthor">Previdi, S., Ed.</span>, <span class="refAuthor">Giacalone, S.</span>, <span class="refAuthor">Ward, D.</span>, <span class="refAuthor">Drake, J.</span>, and <span class="refAuthor">Q. Wu</span>, <span class="refTitle">"IS-IS Traffic Engineering (TE) Metric Extensions"</span>, <span class="seriesInfo">RFC 8570</span>, <span class="seriesInfo">DOI 10.17487/RFC8570</span>, <time datetime="2019-03" class="refDate">March 2019</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8570">https://www.rfc-editor.org/info/rfc8570</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC8571">[RFC8571]</dt>
        <dd>
<span class="refAuthor">Ginsberg, L., Ed.</span>, <span class="refAuthor">Previdi, S.</span>, <span class="refAuthor">Wu, Q.</span>, <span class="refAuthor">Tantsura, J.</span>, and <span class="refAuthor">C. Filsfils</span>, <span class="refTitle">"BGP - Link State (BGP-LS) Advertisement of IGP Traffic Engineering Performance Metric Extensions"</span>, <span class="seriesInfo">RFC 8571</span>, <span class="seriesInfo">DOI 10.17487/RFC8571</span>, <time datetime="2019-03" class="refDate">March 2019</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8571">https://www.rfc-editor.org/info/rfc8571</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC8664">[RFC8664]</dt>
      <dd>
<span class="refAuthor">Sivabalan, S.</span>, <span class="refAuthor">Filsfils, C.</span>, <span class="refAuthor">Tantsura, J.</span>, <span class="refAuthor">Henderickx, W.</span>, and <span class="refAuthor">J. Hardwick</span>, <span class="refTitle">"Path Computation Element Communication Protocol (PCEP) Extensions for Segment Routing"</span>, <span class="seriesInfo">RFC 8664</span>, <span class="seriesInfo">DOI 10.17487/RFC8664</span>, <time datetime="2019-12" class="refDate">December 2019</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8664">https://www.rfc-editor.org/info/rfc8664</a>&gt;</span>. </dd>
<dd class="break"></dd>
</dl>
</section>
</section>
<div id="Acknowledgements">
<section id="appendix-A">
      <h2 id="name-acknowledgements">
<a href="#name-acknowledgements" class="section-name selfRef">Acknowledgements</a>
      </h2>
<p id="appendix-A-1">The authors would like to thank <span class="contact-name">Acee Lindem</span> for his comments and
      contribution.<a href="#appendix-A-1" class="pilcrow">¶</a></p>
</section>
</div>
<div id="Contributors">
<section id="appendix-B">
      <h2 id="name-contributors">
<a href="#name-contributors" class="section-name selfRef">Contributors</a>
      </h2>
<p id="appendix-B-1"><span class="contact-name">Daniel Ginsburg</span> substantially contributed to the content of this
      document.<a href="#appendix-B-1" class="pilcrow">¶</a></p>
</section>
</div>
<div id="authors-addresses">
<section id="appendix-C">
      <h2 id="name-authors-addresses">
<a href="#name-authors-addresses" class="section-name selfRef">Authors' Addresses</a>
      </h2>
<address class="vcard">
        <div dir="auto" class="left"><span class="fn nameRole">Clarence Filsfils (<span class="role">editor</span>)</span></div>
<div dir="auto" class="left"><span class="org">Cisco Systems, Inc.</span></div>
<div dir="auto" class="left"><span class="locality">Brussels</span></div>
<div dir="auto" class="left"><span class="country-name">Belgium</span></div>
<div class="email">
<span>Email:</span>
<a href="mailto:cfilsfil@cisco.com" class="email">cfilsfil@cisco.com</a>
</div>
</address>
<address class="vcard">
        <div dir="auto" class="left"><span class="fn nameRole">Stefano Previdi</span></div>
<div dir="auto" class="left"><span class="org">Cisco Systems, Inc.</span></div>
<div dir="auto" class="left"><span class="country-name">Italy</span></div>
<div class="email">
<span>Email:</span>
<a href="mailto:stefano@previdi.net" class="email">stefano@previdi.net</a>
</div>
</address>
<address class="vcard">
        <div dir="auto" class="left"><span class="fn nameRole">Gaurav Dawra (<span class="role">editor</span>)</span></div>
<div dir="auto" class="left"><span class="org">Cisco Systems, Inc.</span></div>
<div dir="auto" class="left"><span class="country-name">United States of America</span></div>
<div class="email">
<span>Email:</span>
<a href="mailto:gdawra.ietf@gmail.com" class="email">gdawra.ietf@gmail.com</a>
</div>
</address>
<address class="vcard">
        <div dir="auto" class="left"><span class="fn nameRole">Ebben Aries</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="email">
<span>Email:</span>
<a href="mailto:exa@juniper.net" class="email">exa@juniper.net</a>
</div>
</address>
<address class="vcard">
        <div dir="auto" class="left"><span class="fn nameRole">Dmitry Afanasiev</span></div>
<div dir="auto" class="left"><span class="org">Yandex</span></div>
<div dir="auto" class="left"><span class="country-name">Russian Federation</span></div>
<div class="email">
<span>Email:</span>
<a href="mailto:fl0w@yandex-team.ru" class="email">fl0w@yandex-team.ru</a>
</div>
</address>
</section>
</div>
<script>const toc = document.getElementById("toc");
toc.querySelector("h2").addEventListener("click", e => {
  toc.classList.toggle("active");
});
toc.querySelector("nav").addEventListener("click", e => {
  toc.classList.remove("active");
});
</script>
</body>
</html>