File: rfc8670.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 (2492 lines) | stat: -rw-r--r-- 106,243 bytes
parent folder | download | duplicates (2)
<!DOCTYPE html>
<html lang="en" class="RFC">
<head>
<meta charset="utf-8">
<meta content="Common,Latin" name="scripts">
<meta content="initial-scale=1.0" name="viewport">
<title>RFC 8670: BGP Prefix Segment in Large-Scale Data Centers</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="Petr Lapukhov" name="author">
<meta content="
       This document describes the motivation for, and benefits of, applying
      Segment Routing (SR) in BGP-based large-scale data centers. It describes the
      design to deploy SR in those data centers for both the
      MPLS and IPv6 data planes. 
    " name="description">
<meta content="xml2rfc 2.35.0" name="generator">
<meta content="example" name="keyword">
<meta content="8670" name="rfc.number">
<link href="rfc8670.xml" type="application/rfc+xml" rel="alternate">
<link href="#copyright" rel="license">
<style type="text/css">/*

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

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

*/

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

.refInstance {
  margin-bottom: 1.25em;
}

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

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

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

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

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

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

/* pagination */
@media print {
  body {

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

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

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

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

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

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

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

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

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

}

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


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

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

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

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

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

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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

}
/* Avoid wrapping of URLs in references */
@media screen {
  .references a {
    white-space: nowrap;
  }
}
/* Tweak the bcp14 keyword presentation */
.bcp14 {
  font-variant: small-caps;
  font-weight: bold;
  font-size: 0.9em;
}
/* Tweak the invisible space above H* in order not to overlay links in text above */
 h2 {
  margin-top: -18px;  /* provide offset for in-page anchors */
  padding-top: 31px;
 }
 h3 {
  margin-top: -18px;  /* provide offset for in-page anchors */
  padding-top: 24px;
 }
 h4 {
  margin-top: -18px;  /* provide offset for in-page anchors */
  padding-top: 24px;
 }
/* Float artwork pilcrow to the right */
@media screen {
  .artwork a.pilcrow {
    display: block;
    line-height: 0.7;
    margin-top: 0.15em;
  }
}
/* Make pilcrows on dd visible */
@media screen {
  dd:hover > a.pilcrow {
    visibility: visible;
  }
}
/* Make the placement of figcaption match that of a table's caption
   by removing the figure's added bottom margin */
.alignLeft.art-text,
.alignCenter.art-text,
.alignRight.art-text {
   margin-bottom: 0;
}
.alignLeft,
.alignCenter,
.alignRight {
  margin: 1em 0 0 0;
}
/* In print, the pilcrow won't show on hover, so prevent it from taking up space,
   possibly even requiring a new line */
@media print {
  a.pilcrow {
    display: none;
  }
}
/* Styling for the external metadata */
div#external-metadata {
  background-color: #eee;
  padding: 0.5em;
  margin-bottom: 0.5em;
  display: none;
}
div#internal-metadata {
  padding: 0.5em;                       /* to match the external-metadata padding */
}
/* Styling for title RFC Number */
h1#rfcnum {
  clear: both;
  margin: 0 0 -1em;
  padding: 1em 0 0 0;
}
/* Make .olPercent look the same as <ol><li> */
dl.olPercent > dd {
  margin: 0 0 0.25em 0;
  min-height: initial;
}
/* Give aside some styling to set it apart */
aside {
  border-left: 1px solid #ddd;
  margin: 1em 0 1em 2em;
  padding: 0.2em 2em;
}
aside > dl,
aside > ol,
aside > ul,
aside > table,
aside > p {
  margin-bottom: 0;
}
/* Additional page break settings */
@media print {
  figcaption, table caption {
    page-break-before: avoid;
  }
}
/* Font size adjustments for print */
@media print {
  body  { font-size: 10pt;      line-height: normal; max-width: 96%; }
  h1    { font-size: 1.72em;    padding-top: 1.5em; } /* 1*1.2*1.2*1.2 */
  h2    { font-size: 1.44em;    padding-top: 1.5em; } /* 1*1.2*1.2 */
  h3    { font-size: 1.2em;     padding-top: 1.5em; } /* 1*1.2 */
  h4    { font-size: 1em;       padding-top: 1.5em; }
  h5, h6 { font-size: 1em;      margin: initial; padding: 0.5em 0 0.3em; }
}
/* Sourcecode margin in print, when there's no pilcrow */
@media print {
  .sourcecode {
    margin-bottom: 1em;
  }
}</style>
<link href="rfc-local.css" type="text/css" rel="stylesheet">
<link href="https://dx.doi.org/10.17487/rfc8670" rel="alternate">
  <link href="urn:issn:2070-1721" rel="alternate">
  <link href="https://datatracker.ietf.org/doc/draft-ietf-spring-segment-routing-msdc-11" 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 8670</td>
<td class="center">BGP Prefix-SID in Large-Scale DCs</td>
<td class="right">December 2019</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/rfc8670" class="eref">8670</a></dd>
<dt class="label-category">Category:</dt>
<dd class="category">Informational</dd>
<dt class="label-published">Published:</dt>
<dd class="published">
<time datetime="2019-12" class="published">December 2019</time>
    </dd>
<dt class="label-issn">ISSN:</dt>
<dd class="issn">2070-1721</dd>
<dt class="label-authors">Authors:</dt>
<dd class="authors">
<div class="author">
      <div class="author-name">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</div>
<div class="org">LinkedIn</div>
</div>
<div class="author">
      <div class="author-name">E. Aries</div>
<div class="org">Arrcus, Inc.</div>
</div>
<div class="author">
      <div class="author-name">P. Lapukhov</div>
<div class="org">Facebook</div>
</div>
</dd>
</dl>
</div>
<h1 id="rfcnum">RFC 8670</h1>
<h1 id="title">BGP Prefix Segment in Large-Scale Data Centers</h1>
<section id="section-abstract">
      <h2 id="abstract"><a href="#abstract" class="selfRef">Abstract</a></h2>
<p id="section-abstract-1">This document describes the motivation for, and benefits of, applying
      Segment Routing (SR) in BGP-based large-scale data centers. It describes the
      design to deploy SR in those data centers for both the
      MPLS and IPv6 data planes.<a href="#section-abstract-1" class="pilcrow">¶</a></p>
</section>
<div id="status-of-memo">
<section id="section-boilerplate.1">
        <h2 id="name-status-of-this-memo">
<a href="#name-status-of-this-memo" class="section-name selfRef">Status of This Memo</a>
        </h2>
<p id="section-boilerplate.1-1">
            This 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/rfc8670">https://www.rfc-editor.org/info/rfc8670</a></span>.<a href="#section-boilerplate.1-3" class="pilcrow">¶</a></p>
</section>
</div>
<div id="copyright">
<section id="section-boilerplate.2">
        <h2 id="name-copyright-notice">
<a href="#name-copyright-notice" class="section-name selfRef">Copyright Notice</a>
        </h2>
<p id="section-boilerplate.2-1">
            Copyright (c) 2019 IETF Trust and the persons identified as the
            document authors. All rights reserved.<a href="#section-boilerplate.2-1" class="pilcrow">¶</a></p>
<p id="section-boilerplate.2-2">
            This document is subject to BCP 78 and the IETF Trust's Legal
            Provisions Relating to IETF Documents
            (<span><a href="https://trustee.ietf.org/license-info">https://trustee.ietf.org/license-info</a></span>) in effect on the date of
            publication of this document. Please review these documents
            carefully, as they describe your rights and restrictions with
            respect to this document. Code Components extracted from this
            document must include Simplified BSD License text as described in
            Section 4.e of the Trust Legal Provisions and are provided without
            warranty as described in the Simplified BSD License.<a href="#section-boilerplate.2-2" class="pilcrow">¶</a></p>
</section>
</div>
<div id="toc">
<section id="section-toc.1">
        <a href="#" onclick="scroll(0,0)" class="toplink">▲</a><h2 id="name-table-of-contents">
<a href="#name-table-of-contents" class="section-name selfRef">Table of Contents</a>
        </h2>
<nav class="toc"><ul class="toc ulEmpty">
<li class="toc ulEmpty" id="section-toc.1-1.1">
            <p id="section-toc.1-1.1.1"><a href="#section-1" class="xref">1</a>.  <a href="#name-introduction" class="xref">Introduction</a><a href="#section-toc.1-1.1.1" class="pilcrow">¶</a></p>
</li>
          <li class="toc ulEmpty" id="section-toc.1-1.2">
            <p id="section-toc.1-1.2.1"><a href="#section-2" class="xref">2</a>.  <a href="#name-large-scale-data-center-net" class="xref">Large-Scale Data-Center Network Design Summary</a><a href="#section-toc.1-1.2.1" class="pilcrow">¶</a></p>
<ul class="toc ulEmpty">
<li class="toc ulEmpty" id="section-toc.1-1.2.2.1">
                <p id="section-toc.1-1.2.2.1.1"><a href="#section-2.1" class="xref">2.1</a>.  <a href="#name-reference-design" class="xref">Reference Design</a><a href="#section-toc.1-1.2.2.1.1" class="pilcrow">¶</a></p>
</li>
            </ul>
</li>
          <li class="toc ulEmpty" id="section-toc.1-1.3">
            <p id="section-toc.1-1.3.1"><a href="#section-3" class="xref">3</a>.  <a href="#name-some-open-problems-in-large" class="xref">Some Open Problems in Large Data-Center Networks</a><a href="#section-toc.1-1.3.1" class="pilcrow">¶</a></p>
</li>
          <li class="toc ulEmpty" id="section-toc.1-1.4">
            <p id="section-toc.1-1.4.1"><a href="#section-4" class="xref">4</a>.  <a href="#name-applying-segment-routing-in" class="xref">Applying Segment Routing in the DC with MPLS Data Plane</a><a href="#section-toc.1-1.4.1" class="pilcrow">¶</a></p>
<ul class="toc ulEmpty">
<li class="toc ulEmpty" 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-bgp-prefix-segment-bgp-pref" class="xref">BGP Prefix Segment (BGP Prefix-SID)</a><a href="#section-toc.1-1.4.2.1.1" class="pilcrow">¶</a></p>
</li>
              <li class="toc ulEmpty" 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-ebgp-labeled-unicast-rfc-82" class="xref">EBGP Labeled Unicast (RFC 8277)</a><a href="#section-toc.1-1.4.2.2.1" class="pilcrow">¶</a></p>
<ul class="toc ulEmpty">
<li class="toc ulEmpty" id="section-toc.1-1.4.2.2.2.1">
                    <p id="section-toc.1-1.4.2.2.2.1.1"><a href="#section-4.2.1" class="xref">4.2.1</a>.  <a href="#name-control-plane" class="xref">Control Plane</a><a href="#section-toc.1-1.4.2.2.2.1.1" class="pilcrow">¶</a></p>
</li>
                  <li class="toc ulEmpty" id="section-toc.1-1.4.2.2.2.2">
                    <p id="section-toc.1-1.4.2.2.2.2.1"><a href="#section-4.2.2" class="xref">4.2.2</a>.  <a href="#name-data-plane" class="xref">Data Plane</a><a href="#section-toc.1-1.4.2.2.2.2.1" class="pilcrow">¶</a></p>
</li>
                  <li class="toc ulEmpty" id="section-toc.1-1.4.2.2.2.3">
                    <p id="section-toc.1-1.4.2.2.2.3.1"><a href="#section-4.2.3" class="xref">4.2.3</a>.  <a href="#name-network-design-variation" class="xref">Network Design Variation</a><a href="#section-toc.1-1.4.2.2.2.3.1" class="pilcrow">¶</a></p>
</li>
                  <li class="toc ulEmpty" id="section-toc.1-1.4.2.2.2.4">
                    <p id="section-toc.1-1.4.2.2.2.4.1"><a href="#section-4.2.4" class="xref">4.2.4</a>.  <a href="#name-global-bgp-prefix-segment-t" class="xref">Global BGP Prefix Segment through the Fabric</a><a href="#section-toc.1-1.4.2.2.2.4.1" class="pilcrow">¶</a></p>
</li>
                  <li class="toc ulEmpty" id="section-toc.1-1.4.2.2.2.5">
                    <p id="section-toc.1-1.4.2.2.2.5.1"><a href="#section-4.2.5" class="xref">4.2.5</a>.  <a href="#name-incremental-deployments" class="xref">Incremental Deployments</a><a href="#section-toc.1-1.4.2.2.2.5.1" class="pilcrow">¶</a></p>
</li>
                </ul>
</li>
              <li class="toc ulEmpty" 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-ibgp-labeled-unicast-rfc-82" class="xref">IBGP Labeled Unicast (RFC 8277)</a><a href="#section-toc.1-1.4.2.3.1" class="pilcrow">¶</a></p>
</li>
            </ul>
</li>
          <li class="toc ulEmpty" id="section-toc.1-1.5">
            <p id="section-toc.1-1.5.1"><a href="#section-5" class="xref">5</a>.  <a href="#name-applying-segment-routing-in-" class="xref">Applying Segment Routing in the DC with IPv6 Data Plane</a><a href="#section-toc.1-1.5.1" class="pilcrow">¶</a></p>
</li>
          <li class="toc ulEmpty" id="section-toc.1-1.6">
            <p id="section-toc.1-1.6.1"><a href="#section-6" class="xref">6</a>.  <a href="#name-communicating-path-informat" class="xref">Communicating Path Information to the Host</a><a href="#section-toc.1-1.6.1" class="pilcrow">¶</a></p>
</li>
          <li class="toc ulEmpty" id="section-toc.1-1.7">
            <p id="section-toc.1-1.7.1"><a href="#section-7" class="xref">7</a>.  <a href="#name-additional-benefits" class="xref">Additional Benefits</a><a href="#section-toc.1-1.7.1" class="pilcrow">¶</a></p>
<ul class="toc ulEmpty">
<li class="toc ulEmpty" id="section-toc.1-1.7.2.1">
                <p id="section-toc.1-1.7.2.1.1"><a href="#section-7.1" class="xref">7.1</a>.  <a href="#name-mpls-data-plane-with-operat" class="xref">MPLS Data Plane with Operational Simplicity</a><a href="#section-toc.1-1.7.2.1.1" class="pilcrow">¶</a></p>
</li>
              <li class="toc ulEmpty" id="section-toc.1-1.7.2.2">
                <p id="section-toc.1-1.7.2.2.1"><a href="#section-7.2" class="xref">7.2</a>.  <a href="#name-minimizing-the-fib-table" class="xref">Minimizing the FIB Table</a><a href="#section-toc.1-1.7.2.2.1" class="pilcrow">¶</a></p>
</li>
              <li class="toc ulEmpty" id="section-toc.1-1.7.2.3">
                <p id="section-toc.1-1.7.2.3.1"><a href="#section-7.3" class="xref">7.3</a>.  <a href="#name-egress-peer-engineering" class="xref">Egress Peer Engineering</a><a href="#section-toc.1-1.7.2.3.1" class="pilcrow">¶</a></p>
</li>
              <li class="toc ulEmpty" id="section-toc.1-1.7.2.4">
                <p id="section-toc.1-1.7.2.4.1"><a href="#section-7.4" class="xref">7.4</a>.  <a href="#name-anycast" class="xref">Anycast</a><a href="#section-toc.1-1.7.2.4.1" class="pilcrow">¶</a></p>
</li>
            </ul>
</li>
          <li class="toc ulEmpty" id="section-toc.1-1.8">
            <p id="section-toc.1-1.8.1"><a href="#section-8" class="xref">8</a>.  <a href="#name-preferred-srgb-allocation" class="xref">Preferred SRGB Allocation</a><a href="#section-toc.1-1.8.1" class="pilcrow">¶</a></p>
</li>
          <li class="toc ulEmpty" id="section-toc.1-1.9">
            <p id="section-toc.1-1.9.1"><a href="#section-9" class="xref">9</a>.  <a href="#name-iana-considerations" class="xref">IANA Considerations</a><a href="#section-toc.1-1.9.1" class="pilcrow">¶</a></p>
</li>
          <li class="toc ulEmpty" id="section-toc.1-1.10">
            <p id="section-toc.1-1.10.1"><a href="#section-10" class="xref">10</a>. <a href="#name-manageability-consideration" class="xref">Manageability Considerations</a><a href="#section-toc.1-1.10.1" class="pilcrow">¶</a></p>
</li>
          <li class="toc ulEmpty" id="section-toc.1-1.11">
            <p id="section-toc.1-1.11.1"><a href="#section-11" class="xref">11</a>. <a href="#name-security-considerations" class="xref">Security Considerations</a><a href="#section-toc.1-1.11.1" class="pilcrow">¶</a></p>
</li>
          <li class="toc ulEmpty" id="section-toc.1-1.12">
            <p id="section-toc.1-1.12.1"><a href="#section-12" class="xref">12</a>. <a href="#name-references" class="xref">References</a><a href="#section-toc.1-1.12.1" class="pilcrow">¶</a></p>
<ul class="toc ulEmpty">
<li class="toc ulEmpty" id="section-toc.1-1.12.2.1">
                <p id="section-toc.1-1.12.2.1.1"><a href="#section-12.1" class="xref">12.1</a>.  <a href="#name-normative-references" class="xref">Normative References</a><a href="#section-toc.1-1.12.2.1.1" class="pilcrow">¶</a></p>
</li>
              <li class="toc ulEmpty" id="section-toc.1-1.12.2.2">
                <p id="section-toc.1-1.12.2.2.1"><a href="#section-12.2" class="xref">12.2</a>.  <a href="#name-informative-references" class="xref">Informative References</a><a href="#section-toc.1-1.12.2.2.1" class="pilcrow">¶</a></p>
</li>
            </ul>
</li>
          <li class="toc ulEmpty" id="section-toc.1-1.13">
            <p id="section-toc.1-1.13.1"><a href="#section-appendix.a" class="xref"></a><a href="#name-acknowledgements" class="xref">Acknowledgements</a><a href="#section-toc.1-1.13.1" class="pilcrow">¶</a></p>
</li>
          <li class="toc ulEmpty" id="section-toc.1-1.14">
            <p id="section-toc.1-1.14.1"><a href="#section-appendix.b" class="xref"></a><a href="#name-contributors" class="xref">Contributors</a><a href="#section-toc.1-1.14.1" class="pilcrow">¶</a></p>
</li>
          <li class="toc ulEmpty" id="section-toc.1-1.15">
            <p id="section-toc.1-1.15.1"><a href="#section-appendix.c" class="xref"></a><a href="#name-authors-addresses" class="xref">Authors' Addresses</a><a href="#section-toc.1-1.15.1" class="pilcrow">¶</a></p>
</li>
        </ul>
</nav>
</section>
</div>
<div id="INTRO">
<section id="section-1">
      <h2 id="name-introduction">
<a href="#section-1" class="section-number selfRef">1. </a><a href="#name-introduction" class="section-name selfRef">Introduction</a>
      </h2>
<p id="section-1-1">Segment Routing (SR), as described in <span>[<a href="#RFC8402" class="xref">RFC8402</a>]</span>, leverages the source-routing
      paradigm. A node steers a packet through an ordered list of
      instructions called "segments". A segment can represent any instruction,
      topological or service based. A segment can have a local semantic to an
      SR node or a global semantic within an SR domain. SR allows the enforcement of a flow
      through any topological path while maintaining per-flow state only from
      the ingress node to the SR domain. SR can be applied to the
      MPLS and IPv6 data planes.<a href="#section-1-1" class="pilcrow">¶</a></p>
<p id="section-1-2">The use cases described in this document should be considered in the
      context of the BGP-based large-scale data-center (DC) design described
      in <span>[<a href="#RFC7938" class="xref">RFC7938</a>]</span>. This document extends it by applying SR
      both with IPv6 and MPLS data planes.<a href="#section-1-2" class="pilcrow">¶</a></p>
</section>
</div>
<div id="LARGESCALEDC">
<section id="section-2">
      <h2 id="name-large-scale-data-center-net">
<a href="#section-2" class="section-number selfRef">2. </a><a href="#name-large-scale-data-center-net" class="section-name selfRef">Large-Scale Data-Center Network Design Summary</a>
      </h2>
<p id="section-2-1">This section provides a brief summary of the Informational RFC
      <span>[<a href="#RFC7938" class="xref">RFC7938</a>]</span>, which outlines a practical network design
      suitable for data centers of various scales:<a href="#section-2-1" class="pilcrow">¶</a></p>
<ul>
<li id="section-2-2.1">Data-center networks have highly symmetric topologies with
          multiple parallel paths between two server-attachment points. The
          well-known Clos topology is most popular among the operators (as
          described in <span>[<a href="#RFC7938" class="xref">RFC7938</a>]</span>). In a Clos topology, the
          minimum number of parallel paths between two elements is determined
          by the "width" of the "Tier-1" stage. See <a href="#FIGLARGE" class="xref">Figure 1</a>
          for an illustration of the concept.<a href="#section-2-2.1" class="pilcrow">¶</a>
</li>
        <li id="section-2-2.2">Large-scale data centers commonly use a routing protocol, such as
          BGP-4 <span>[<a href="#RFC4271" class="xref">RFC4271</a>]</span>, in order to provide endpoint
          connectivity. Therefore, recovery after a network failure is driven
          either by local knowledge of directly available backup paths or by
          distributed signaling between the network devices.<a href="#section-2-2.2" class="pilcrow">¶</a>
</li>
        <li id="section-2-2.3">Within data-center networks, traffic is load shared using the
          Equal Cost Multipath (ECMP) mechanism. With ECMP, every network
          device implements a pseudorandom decision, mapping packets to one
          of the parallel paths by means of a hash function calculated over
          certain parts of the packet, typically a combination of various
          packet header fields.<a href="#section-2-2.3" class="pilcrow">¶</a>
</li>
      </ul>
<p id="section-2-3">The following is a schematic of a five-stage Clos topology with four
      devices in the "Tier-1" stage. Notice that the number of paths between Node1
      and Node12 equals four; the paths have to cross all of the Tier-1
      devices. At the same time, the number of paths between Node1 and Node2
      equals two, and the paths only cross Tier-2 devices. Other topologies
      are possible, but for simplicity, only the topologies that have a single
      path from Tier-1 to Tier-3 are considered below. The rest could be
      treated similarly, with a few modifications to the logic.<a href="#section-2-3" class="pilcrow">¶</a></p>
<div id="REFDESIGN">
<section id="section-2.1">
        <h3 id="name-reference-design">
<a href="#section-2.1" class="section-number selfRef">2.1. </a><a href="#name-reference-design" class="section-name selfRef">Reference Design</a>
        </h3>
<span id="name-5-stage-clos-topology"></span><div id="FIGLARGE">
<figure id="figure-1">
          <div class="artwork art-text alignLeft" id="section-2.1-1.1">
<pre>                                Tier-1
                               +-----+
                               |NODE |
                            +-&gt;|  5  |--+
                            |  +-----+  |
                    Tier-2  |           |   Tier-2
                   +-----+  |  +-----+  |  +-----+
     +------------&gt;|NODE |--+-&gt;|NODE |--+--|NODE |-------------+
     |       +-----|  3  |--+  |  6  |  +--|  9  |-----+       |
     |       |     +-----+     +-----+     +-----+     |       |
     |       |                                         |       |
     |       |     +-----+     +-----+     +-----+     |       |
     | +-----+----&gt;|NODE |--+  |NODE |  +--|NODE |-----+-----+ |
     | |     | +---|  4  |--+-&gt;|  7  |--+--|  10 |---+ |     | |
     | |     | |   +-----+  |  +-----+  |  +-----+   | |     | |
     | |     | |            |           |            | |     | |
   +-----+ +-----+          |  +-----+  |          +-----+ +-----+
   |NODE | |NODE | Tier-3   +-&gt;|NODE |--+   Tier-3 |NODE | |NODE |
   |  1  | |  2  |             |  8  |             | 11  | |  12 |
   +-----+ +-----+             +-----+             +-----+ +-----+
     | |     | |                                     | |     | |
     A O     B O            &lt;- Servers -&gt;            Z O     O O</pre>
</div>
<figcaption><a href="#figure-1" class="selfRef">Figure 1</a>:
<a href="#name-5-stage-clos-topology" class="selfRef">5-Stage Clos Topology</a>
          </figcaption></figure>
</div>
<p id="section-2.1-2">In the reference topology illustrated in <a href="#FIGLARGE" class="xref">Figure 1</a>,
        it is assumed:<a href="#section-2.1-2" class="pilcrow">¶</a></p>
<ul>
<li id="section-2.1-3.1">
            <p id="section-2.1-3.1.1">Each node is its own autonomous system (AS) (Node X has AS X). 4-byte AS numbers
            are recommended (<span>[<a href="#RFC6793" class="xref">RFC6793</a>]</span>).<a href="#section-2.1-3.1.1" class="pilcrow">¶</a></p>
<ul>
<li id="section-2.1-3.1.2.1">For simple and efficient route propagation filtering,
                Node5, Node6, Node7, and Node8 use the same AS; Node3 and Node4
                use the same AS; and Node9 and Node10 use the same AS.<a href="#section-2.1-3.1.2.1" class="pilcrow">¶</a>
</li>
              <li id="section-2.1-3.1.2.2">In the case in which 2-byte autonomous system numbers are used
                for efficient usage of the scarce 2-byte Private Use AS pool,
                different Tier-3 nodes might use the same AS.<a href="#section-2.1-3.1.2.2" class="pilcrow">¶</a>
</li>
              <li id="section-2.1-3.1.2.3">Without loss of generality, these details will be
                simplified in this document. It is to be assumed that each node has its
                own AS.<a href="#section-2.1-3.1.2.3" class="pilcrow">¶</a>
</li>
            </ul>
</li>
          <li id="section-2.1-3.2">Each node peers with its neighbors with a BGP session. If not
            specified, external BGP (EBGP) is assumed. In a specific use case,
            internal BGP (IBGP) will be used, but this will be called out
            explicitly in that case.<a href="#section-2.1-3.2" class="pilcrow">¶</a>
</li>
          <li id="section-2.1-3.3">
            <p id="section-2.1-3.3.1">Each node originates the IPv4 address of its loopback interface
            into BGP and announces it to its neighbors.<a href="#section-2.1-3.3.1" class="pilcrow">¶</a></p>
<ul>
<li id="section-2.1-3.3.2.1">The loopback of Node X is 192.0.2.x/32.<a href="#section-2.1-3.3.2.1" class="pilcrow">¶</a>
</li>
            </ul>
</li>
        </ul>
<p id="section-2.1-4">In this document, the Tier-1, Tier-2, and Tier-3 nodes are referred
        to as "Spine", "Leaf", and "ToR" (top of rack) nodes, respectively.  When a ToR
        node acts as a gateway to the "outside world", it is referred to as a
        "border node".<a href="#section-2.1-4" class="pilcrow">¶</a></p>
</section>
</div>
</section>
</div>
<div id="OPENPROBS">
<section id="section-3">
      <h2 id="name-some-open-problems-in-large">
<a href="#section-3" class="section-number selfRef">3. </a><a href="#name-some-open-problems-in-large" class="section-name selfRef">Some Open Problems in Large Data-Center Networks</a>
      </h2>
<p id="section-3-1">The data-center-network design summarized above provides means for
      moving traffic between hosts with reasonable efficiency. There are few
      open performance and reliability problems that arise in such a design:<a href="#section-3-1" class="pilcrow">¶</a></p>
<ul>
<li id="section-3-2.1">ECMP routing is most commonly realized per flow. This means that
          large, long-lived "elephant" flows may affect performance of
          smaller, short-lived "mouse" flows and may reduce efficiency
          of per-flow load sharing. In other words, per-flow ECMP does not
          perform efficiently when flow-lifetime distribution is heavy tailed.
          Furthermore, due to hash-function inefficiencies, it is possible to
          have frequent flow collisions where more flows get placed on one
          path over the others.<a href="#section-3-2.1" class="pilcrow">¶</a>
</li>
        <li id="section-3-2.2">Shortest-path routing with ECMP implements an oblivious routing
          model that is not aware of the network imbalances. If the network
          symmetry is broken, for example, due to link failures, utilization
          hotspots may appear. For example, if a link fails between Tier-1 and
          Tier-2 devices (e.g., Node5 and Node9), Tier-3 devices Node1 and
          Node2 will not be aware of that since there are other paths
          available from the perspective of Node3. They will continue sending
          roughly equal traffic to Node3 and Node4 as if the failure didn't
          exist, which may cause a traffic hotspot.<a href="#section-3-2.2" class="pilcrow">¶</a>
</li>
        <li id="section-3-2.3">Isolating faults in the network with multiple parallel paths and
          ECMP-based routing is nontrivial due to lack of determinism.
          Specifically, the connections from HostA to HostB may take a
          different path every time a new connection is formed, thus making
          consistent reproduction of a failure much more difficult. This
          complexity scales linearly with the number of parallel paths in the
          network and stems from the random nature of path selection by the
          network devices.<a href="#section-3-2.3" class="pilcrow">¶</a>
</li>
      </ul>
</section>
</div>
<div id="APPLYSR">
<section id="section-4">
      <h2 id="name-applying-segment-routing-in">
<a href="#section-4" class="section-number selfRef">4. </a><a href="#name-applying-segment-routing-in" class="section-name selfRef">Applying Segment Routing in the DC with MPLS Data Plane</a>
      </h2>
<div id="BGPREFIXSEGMENT">
<section id="section-4.1">
        <h3 id="name-bgp-prefix-segment-bgp-pref">
<a href="#section-4.1" class="section-number selfRef">4.1. </a><a href="#name-bgp-prefix-segment-bgp-pref" class="section-name selfRef">BGP Prefix Segment (BGP Prefix-SID)</a>
        </h3>
<p id="section-4.1-1">A BGP Prefix Segment is a segment associated with a BGP prefix. A
        BGP Prefix Segment is a network-wide instruction to forward the packet
        along the ECMP-aware best path to the related prefix.<a href="#section-4.1-1" class="pilcrow">¶</a></p>
<p id="section-4.1-2">The BGP Prefix Segment is defined as the BGP Prefix-SID Attribute
        in <span>[<a href="#RFC8669" class="xref">RFC8669</a>]</span>, which contains an
        index. Throughout this document, the BGP Prefix Segment Attribute is
        referred to as the "BGP Prefix-SID" and the encoded index as the
        label index.<a href="#section-4.1-2" class="pilcrow">¶</a></p>
<p id="section-4.1-3">In this document, the network design decision has been made to
        assume that all the nodes are allocated the same SRGB (Segment Routing
        Global Block), e.g., [16000, 23999]. This provides operational
        simplification as explained in <a href="#SINGLESRGB" class="xref">Section 8</a>, but this
        is not a requirement.<a href="#section-4.1-3" class="pilcrow">¶</a></p>
<p id="section-4.1-4">For illustration purposes, when considering an MPLS data plane, it
        is assumed that the label index allocated to prefix 192.0.2.x/32 is X.
        As a result, a local label (16000+x) is allocated for prefix
        192.0.2.x/32 by each node throughout the DC fabric.<a href="#section-4.1-4" class="pilcrow">¶</a></p>
<p id="section-4.1-5">When the IPv6 data plane is considered, it is assumed that Node X is
        allocated IPv6 address (segment) 2001:DB8::X.<a href="#section-4.1-5" class="pilcrow">¶</a></p>
</section>
</div>
<div id="eBGP8277">
<section id="section-4.2">
        <h3 id="name-ebgp-labeled-unicast-rfc-82">
<a href="#section-4.2" class="section-number selfRef">4.2. </a><a href="#name-ebgp-labeled-unicast-rfc-82" class="section-name selfRef">EBGP Labeled Unicast (RFC 8277)</a>
        </h3>
<p id="section-4.2-1">Referring to <a href="#FIGLARGE" class="xref">Figure 1</a> and 
 <span>[<a href="#RFC7938" class="xref">RFC7938</a>]</span>, the following design modifications are
        introduced:<a href="#section-4.2-1" class="pilcrow">¶</a></p>
<ul>
<li id="section-4.2-2.1">Each node peers with its neighbors via an EBGP session with
            extensions defined in <span>[<a href="#RFC8277" class="xref">RFC8277</a>]</span> (named "EBGP8277"
            throughout this document) and with the BGP Prefix-SID attribute
            extension as defined in <span>[<a href="#RFC8669" class="xref">RFC8669</a>]</span>.<a href="#section-4.2-2.1" class="pilcrow">¶</a>
</li>
          <li id="section-4.2-2.2">The forwarding plane at Tier-2 and Tier-1 is MPLS.<a href="#section-4.2-2.2" class="pilcrow">¶</a>
</li>
          <li id="section-4.2-2.3">The forwarding plane at Tier-3 is either IP2MPLS (if the host
            sends IP traffic) or MPLS2MPLS (if the host sends MPLS-encapsulated traffic).<a href="#section-4.2-2.3" class="pilcrow">¶</a>
</li>
        </ul>
<p id="section-4.2-3"><a href="#FIGSMALL" class="xref">Figure 2</a> zooms into a path from ServerA to ServerZ within the topology of <a href="#FIGLARGE" class="xref">Figure 1</a>.<a href="#section-4.2-3" class="pilcrow">¶</a></p>
<span id="name-path-from-a-to-z-via-nodes-"></span><div id="FIGSMALL">
<figure id="figure-2">
          <div class="artwork art-text alignLeft" id="section-4.2-4.1">
<pre>                   +-----+     +-----+     +-----+    
       +----------&gt;|NODE |     |NODE |     |NODE |
       |           |  4  |--+-&gt;|  7  |--+--|  10 |---+  
       |           +-----+     +-----+     +-----+   |  
       |                                             |  
   +-----+                                         +-----+ 
   |NODE |                                         |NODE |
   |  1  |                                         | 11  |
   +-----+                                         +-----+ 
     |                                              |     
     A                    &lt;- Servers -&gt;             Z</pre>
</div>
<figcaption><a href="#figure-2" class="selfRef">Figure 2</a>:
<a href="#name-path-from-a-to-z-via-nodes-" class="selfRef">Path from A to Z via Nodes 1, 4, 7, 10, and 11</a>
          </figcaption></figure>
</div>
<p id="section-4.2-5">Referring to Figures <a href="#FIGLARGE" class="xref">1</a> and <a href="#FIGSMALL" class="xref">2</a>, and assuming the IP address with the AS and
        label-index allocation previously described, the following sections
        detail the control-plane operation and the data-plane states for the
        prefix 192.0.2.11/32 (loopback of Node11).<a href="#section-4.2-5" class="pilcrow">¶</a></p>
<div id="CONTROLPLANE">
<section id="section-4.2.1">
          <h4 id="name-control-plane">
<a href="#section-4.2.1" class="section-number selfRef">4.2.1. </a><a href="#name-control-plane" class="section-name selfRef">Control Plane</a>
          </h4>
<p id="section-4.2.1-1">Node11 originates 192.0.2.11/32 in BGP and allocates to it a
          BGP Prefix-SID with label-index: index11 <span>[<a href="#RFC8669" class="xref">RFC8669</a>]</span>.<a href="#section-4.2.1-1" class="pilcrow">¶</a></p>
<p id="section-4.2.1-2">Node11 sends the following EBGP8277 update to Node10:<a href="#section-4.2.1-2" class="pilcrow">¶</a></p>
<ul class="ulEmpty">
<li class="ulEmpty" id="section-4.2.1-3.1">
              <dl class="dlParallel" id="section-4.2.1-3.1.1">
                <dt id="section-4.2.1-3.1.1.1">IP Prefix:
</dt>
                <dd id="section-4.2.1-3.1.1.2">192.0.2.11/32<a href="#section-4.2.1-3.1.1.2" class="pilcrow">¶</a>
</dd>
<dt id="section-4.2.1-3.1.1.3">Label:
</dt>
                <dd id="section-4.2.1-3.1.1.4">Implicit NULL<a href="#section-4.2.1-3.1.1.4" class="pilcrow">¶</a>
</dd>
<dt id="section-4.2.1-3.1.1.5">Next hop:
</dt>
                <dd id="section-4.2.1-3.1.1.6">Node11's interface address on the link to Node10<a href="#section-4.2.1-3.1.1.6" class="pilcrow">¶</a>
</dd>
<dt id="section-4.2.1-3.1.1.7">AS Path:
</dt>
                <dd id="section-4.2.1-3.1.1.8">{11}<a href="#section-4.2.1-3.1.1.8" class="pilcrow">¶</a>
</dd>
<dt id="section-4.2.1-3.1.1.9">BGP Prefix-SID:
</dt>
                <dd id="section-4.2.1-3.1.1.10">Label-Index 11<a href="#section-4.2.1-3.1.1.10" class="pilcrow">¶</a>
</dd>
</dl>
</li>
          </ul>
<p id="section-4.2.1-4">Node10 receives the above update. As it is SR capable, Node10 is
          able to interpret the BGP Prefix-SID; therefore, it understands that it
          should allocate the label from its own SRGB block, offset by the
          label index received in the BGP Prefix-SID (16000+11, hence, 16011) to
          the Network Layer Reachability Information (NLRI) instead of
          allocating a nondeterministic label out of a dynamically allocated
          portion of the local label space. The implicit NULL label in the
          NLRI tells Node10 that it is the penultimate hop and that it must pop the
          top label on the stack before forwarding traffic for this prefix to
          Node11.<a href="#section-4.2.1-4" class="pilcrow">¶</a></p>
<p id="section-4.2.1-5">Then, Node10 sends the following EBGP8277 update to Node7:<a href="#section-4.2.1-5" class="pilcrow">¶</a></p>
<ul class="ulEmpty">
<li class="ulEmpty" id="section-4.2.1-6.1">
              <dl class="dlParallel" id="section-4.2.1-6.1.1">
                <dt id="section-4.2.1-6.1.1.1">IP Prefix:
</dt>
                <dd id="section-4.2.1-6.1.1.2">192.0.2.11/32<a href="#section-4.2.1-6.1.1.2" class="pilcrow">¶</a>
</dd>
<dt id="section-4.2.1-6.1.1.3">Label:
</dt>
                <dd id="section-4.2.1-6.1.1.4">16011<a href="#section-4.2.1-6.1.1.4" class="pilcrow">¶</a>
</dd>
<dt id="section-4.2.1-6.1.1.5">Next hop:
</dt>
                <dd id="section-4.2.1-6.1.1.6">Node10's interface address on the link to Node7<a href="#section-4.2.1-6.1.1.6" class="pilcrow">¶</a>
</dd>
<dt id="section-4.2.1-6.1.1.7">AS Path:
</dt>
                <dd id="section-4.2.1-6.1.1.8">{10, 11}<a href="#section-4.2.1-6.1.1.8" class="pilcrow">¶</a>
</dd>
<dt id="section-4.2.1-6.1.1.9">BGP Prefix-SID:
</dt>
                <dd id="section-4.2.1-6.1.1.10">Label-Index 11<a href="#section-4.2.1-6.1.1.10" class="pilcrow">¶</a>
</dd>
</dl>
</li>
          </ul>
<p id="section-4.2.1-7">Node7 receives the above update. As it is SR capable, Node7 is
          able to interpret the BGP Prefix-SID; therefore, it allocates the local
          (incoming) label 16011 (16000 + 11) to the NLRI (instead of
          allocating a "dynamic" local label from its label
          manager). Node7 uses the label in the received EBGP8277 NLRI as the
          outgoing label (the index is only used to derive the local/incoming
          label).<a href="#section-4.2.1-7" class="pilcrow">¶</a></p>
<p id="section-4.2.1-8">Node7 sends the following EBGP8277 update to Node4:<a href="#section-4.2.1-8" class="pilcrow">¶</a></p>
<ul class="ulEmpty">
<li class="ulEmpty" id="section-4.2.1-9.1">
              <dl class="dlParallel" id="section-4.2.1-9.1.1">
                <dt id="section-4.2.1-9.1.1.1">IP Prefix:
</dt>
                <dd id="section-4.2.1-9.1.1.2">192.0.2.11/32<a href="#section-4.2.1-9.1.1.2" class="pilcrow">¶</a>
</dd>
<dt id="section-4.2.1-9.1.1.3">Label:
</dt>
                <dd id="section-4.2.1-9.1.1.4">16011<a href="#section-4.2.1-9.1.1.4" class="pilcrow">¶</a>
</dd>
<dt id="section-4.2.1-9.1.1.5">Next hop:
</dt>
                <dd id="section-4.2.1-9.1.1.6">Node7's interface address on the link to Node4<a href="#section-4.2.1-9.1.1.6" class="pilcrow">¶</a>
</dd>
<dt id="section-4.2.1-9.1.1.7">AS Path:
</dt>
                <dd id="section-4.2.1-9.1.1.8">{7, 10, 11}<a href="#section-4.2.1-9.1.1.8" class="pilcrow">¶</a>
</dd>
<dt id="section-4.2.1-9.1.1.9">BGP Prefix-SID:
</dt>
                <dd id="section-4.2.1-9.1.1.10">Label-Index 11<a href="#section-4.2.1-9.1.1.10" class="pilcrow">¶</a>
</dd>
</dl>
</li>
          </ul>
<p id="section-4.2.1-10">Node4 receives the above update. As it is SR capable, Node4 is
          able to interpret the BGP Prefix-SID; therefore, it allocates the local
          (incoming) label 16011 to the NLRI (instead of allocating a
          "dynamic" local label from its label manager). Node4
          uses the label in the received EBGP8277 NLRI as an outgoing label (the
          index is only used to derive the local/incoming label).<a href="#section-4.2.1-10" class="pilcrow">¶</a></p>
<p id="section-4.2.1-11">Node4 sends the following EBGP8277 update to Node1:<a href="#section-4.2.1-11" class="pilcrow">¶</a></p>
<ul class="ulEmpty">
<li class="ulEmpty" id="section-4.2.1-12.1">
              <dl class="dlParallel" id="section-4.2.1-12.1.1">
                <dt id="section-4.2.1-12.1.1.1">IP Prefix:
</dt>
                <dd id="section-4.2.1-12.1.1.2">192.0.2.11/32<a href="#section-4.2.1-12.1.1.2" class="pilcrow">¶</a>
</dd>
<dt id="section-4.2.1-12.1.1.3">Label:
</dt>
                <dd id="section-4.2.1-12.1.1.4">16011<a href="#section-4.2.1-12.1.1.4" class="pilcrow">¶</a>
</dd>
<dt id="section-4.2.1-12.1.1.5">Next hop:
</dt>
                <dd id="section-4.2.1-12.1.1.6">Node4's interface address on the link to Node1<a href="#section-4.2.1-12.1.1.6" class="pilcrow">¶</a>
</dd>
<dt id="section-4.2.1-12.1.1.7">AS Path:
</dt>
                <dd id="section-4.2.1-12.1.1.8">{4, 7, 10, 11}<a href="#section-4.2.1-12.1.1.8" class="pilcrow">¶</a>
</dd>
<dt id="section-4.2.1-12.1.1.9">BGP Prefix-SID:
</dt>
                <dd id="section-4.2.1-12.1.1.10">Label-Index 11<a href="#section-4.2.1-12.1.1.10" class="pilcrow">¶</a>
</dd>
</dl>
</li>
          </ul>
<p id="section-4.2.1-13">Node1 receives the above update. As it is SR capable, Node1 is
          able to interpret the BGP Prefix-SID; therefore, it allocates the local
          (incoming) label 16011 to the NLRI (instead of allocating a
          "dynamic" local label from its label manager). Node1
          uses the label in the received EBGP8277 NLRI as an outgoing label (the
          index is only used to derive the local/incoming label).<a href="#section-4.2.1-13" class="pilcrow">¶</a></p>
</section>
</div>
<div id="DATAPLANE">
<section id="section-4.2.2">
          <h4 id="name-data-plane">
<a href="#section-4.2.2" class="section-number selfRef">4.2.2. </a><a href="#name-data-plane" class="section-name selfRef">Data Plane</a>
          </h4>
<p id="section-4.2.2-1">Referring to <a href="#FIGLARGE" class="xref">Figure 1</a>, and assuming all nodes
          apply the same advertisement rules described above and all nodes
          have the same SRGB (16000-23999), here are the IP/MPLS forwarding
          tables for prefix 192.0.2.11/32 at Node1, Node4, Node7, and
          Node10.<a href="#section-4.2.2-1" class="pilcrow">¶</a></p>
<span id="name-node1-forwarding-table"></span><div id="NODE1FIB">
<table class="center" id="table-1">
            <caption>
<a href="#table-1" class="selfRef">Table 1</a>:
<a href="#name-node1-forwarding-table" class="selfRef">Node1 Forwarding Table
</a>
            </caption>
<tbody>
              <tr>
                <td class="text-center" rowspan="1" colspan="1">Incoming Label or IP Destination
</td>
                <td class="text-center" rowspan="1" colspan="1">Outgoing Label
</td>
                <td class="text-center" rowspan="1" colspan="1">Outgoing Interface
</td>
              </tr>
              <tr>
                <td class="text-center" rowspan="1" colspan="1">16011
</td>
                <td class="text-center" rowspan="1" colspan="1">16011 
</td>
                <td class="text-center" rowspan="1" colspan="1">ECMP{3, 4}
</td>
              </tr>
              <tr>
                <td class="text-center" rowspan="1" colspan="1">192.0.2.11/32
</td>
                <td class="text-center" rowspan="1" colspan="1">16011 
</td>
                <td class="text-center" rowspan="1" colspan="1">ECMP{3, 4}
</td>
              </tr>
            </tbody>
          </table>
</div>
<span id="name-node4-forwarding-table"></span><div id="NODE4FIB">
<table class="center" id="table-2">
            <caption>
<a href="#table-2" class="selfRef">Table 2</a>:
<a href="#name-node4-forwarding-table" class="selfRef">Node4 Forwarding Table
</a>
            </caption>
<tbody>
              <tr>
                <td class="text-center" rowspan="1" colspan="1">Incoming Label or IP Destination
</td>
                <td class="text-center" rowspan="1" colspan="1">Outgoing Label
</td>
                <td class="text-center" rowspan="1" colspan="1">Outgoing Interface
</td>
              </tr>
              <tr>
                <td class="text-center" rowspan="1" colspan="1">16011
</td>
                <td class="text-center" rowspan="1" colspan="1">16011 
</td>
                <td class="text-center" rowspan="1" colspan="1">ECMP{7, 8}
</td>
              </tr>
              <tr>
                <td class="text-center" rowspan="1" colspan="1">192.0.2.11/32
</td>
                <td class="text-center" rowspan="1" colspan="1">16011 
</td>
                <td class="text-center" rowspan="1" colspan="1">ECMP{7, 8}
</td>
              </tr>
            </tbody>
          </table>
</div>
<span id="name-node7-forwarding-table"></span><div id="NODE7FIB">
<table class="center" id="table-3">
            <caption>
<a href="#table-3" class="selfRef">Table 3</a>:
<a href="#name-node7-forwarding-table" class="selfRef">Node7 Forwarding Table
</a>
            </caption>
<tbody>
              <tr>
                <td class="text-center" rowspan="1" colspan="1">Incoming Label or IP Destination
</td>
                <td class="text-center" rowspan="1" colspan="1">Outgoing Label
</td>
                <td class="text-center" rowspan="1" colspan="1">Outgoing Interface
</td>
              </tr>
              <tr>
                <td class="text-center" rowspan="1" colspan="1">16011
</td>
                <td class="text-center" rowspan="1" colspan="1">16011 
</td>
                <td class="text-center" rowspan="1" colspan="1">10
</td>
              </tr>
              <tr>
                <td class="text-center" rowspan="1" colspan="1">192.0.2.11/32
</td>
                <td class="text-center" rowspan="1" colspan="1">16011 
</td>
                <td class="text-center" rowspan="1" colspan="1">10
</td>
              </tr>
            </tbody>
          </table>
</div>
<span id="name-node10-forwarding-table"></span><div id="NODE10FIB">
<table class="center" id="table-4">
            <caption>
<a href="#table-4" class="selfRef">Table 4</a>:
<a href="#name-node10-forwarding-table" class="selfRef">Node10 Forwarding Table
</a>
            </caption>
<tbody>
              <tr>
                <td class="text-center" rowspan="1" colspan="1">Incoming Label or IP Destination
</td>
                <td class="text-center" rowspan="1" colspan="1">Outgoing Label
</td>
                <td class="text-center" rowspan="1" colspan="1">Outgoing Interface
</td>
              </tr>
              <tr>
                <td class="text-center" rowspan="1" colspan="1">16011
</td>
                <td class="text-center" rowspan="1" colspan="1">POP 
</td>
                <td class="text-center" rowspan="1" colspan="1">11
</td>
              </tr>
              <tr>
                <td class="text-center" rowspan="1" colspan="1">192.0.2.11/32
</td>
                <td class="text-center" rowspan="1" colspan="1">N/A 
</td>
                <td class="text-center" rowspan="1" colspan="1">11
</td>
              </tr>
            </tbody>
          </table>
</div>
</section>
</div>
<div id="VARIATIONS">
<section id="section-4.2.3">
          <h4 id="name-network-design-variation">
<a href="#section-4.2.3" class="section-number selfRef">4.2.3. </a><a href="#name-network-design-variation" class="section-name selfRef">Network Design Variation</a>
          </h4>
<p id="section-4.2.3-1">A network design choice could consist of switching all the
          traffic through Tier-1 and Tier-2 as MPLS traffic. In this case, one
          could filter away the IP entries at Node4, Node7, and Node10. This
          might be beneficial in order to optimize the forwarding table
          size.<a href="#section-4.2.3-1" class="pilcrow">¶</a></p>
<p id="section-4.2.3-2">A network design choice could consist of allowing the hosts to
          send MPLS-encapsulated traffic based on the Egress Peer Engineering
          (EPE) use case as defined in <span>[<a href="#I-D.ietf-spring-segment-routing-central-epe" class="xref">SR-CENTRAL-EPE</a>]</span>. For example,
          applications at HostA would send their Z-destined traffic to Node1
          with an MPLS label stack where the top label is 16011 and the next
          label is an EPE peer segment (<span>[<a href="#I-D.ietf-spring-segment-routing-central-epe" class="xref">SR-CENTRAL-EPE</a>]</span>) at Node11
          directing the traffic to Z.<a href="#section-4.2.3-2" class="pilcrow">¶</a></p>
</section>
</div>
<div id="FABRIC">
<section id="section-4.2.4">
          <h4 id="name-global-bgp-prefix-segment-t">
<a href="#section-4.2.4" class="section-number selfRef">4.2.4. </a><a href="#name-global-bgp-prefix-segment-t" class="section-name selfRef">Global BGP Prefix Segment through the Fabric</a>
          </h4>
<p id="section-4.2.4-1">When the previous design is deployed, the operator enjoys global
          BGP Prefix-SID and label allocation throughout the DC fabric.<a href="#section-4.2.4-1" class="pilcrow">¶</a></p>
<p id="section-4.2.4-2">A few examples follow:<a href="#section-4.2.4-2" class="pilcrow">¶</a></p>
<ul>
<li id="section-4.2.4-3.1">Normal forwarding to Node11: A packet with top label 16011
              received by any node in the fabric will be forwarded along the
              ECMP-aware BGP best path towards Node11, and the label 16011 is
              penultimate popped at Node10 (or at Node 9).<a href="#section-4.2.4-3.1" class="pilcrow">¶</a>
</li>
            <li id="section-4.2.4-3.2">Traffic-engineered path to Node11: An application on a host
              behind Node1 might want to restrict its traffic to paths via the
              Spine node Node5. The application achieves this by sending its
              packets with a label stack of {16005, 16011}. BGP Prefix-SID
              16005 directs the packet up to Node5 along the path (Node1,
              Node3, Node5). BGP Prefix-SID 16011 then directs the packet down
              to Node11 along the path (Node5, Node9, Node11).<a href="#section-4.2.4-3.2" class="pilcrow">¶</a>
</li>
          </ul>
</section>
</div>
<div id="INCRDEP">
<section id="section-4.2.5">
          <h4 id="name-incremental-deployments">
<a href="#section-4.2.5" class="section-number selfRef">4.2.5. </a><a href="#name-incremental-deployments" class="section-name selfRef">Incremental Deployments</a>
          </h4>
<p id="section-4.2.5-1">The design previously described can be deployed incrementally.
          Let us assume that Node7 does not support the BGP Prefix-SID, and let
          us show how the fabric connectivity is preserved.<a href="#section-4.2.5-1" class="pilcrow">¶</a></p>
<p id="section-4.2.5-2">From a signaling viewpoint, nothing would change; even though
          Node7 does not support the BGP Prefix-SID, it does propagate the
          attribute unmodified to its neighbors.<a href="#section-4.2.5-2" class="pilcrow">¶</a></p>
<p id="section-4.2.5-3">From a label-allocation viewpoint, the only difference is that
          Node7 would allocate a dynamic (random) label to the prefix
          192.0.2.11/32 (e.g., 123456) instead of the "hinted" label as
          instructed by the BGP Prefix-SID. The neighbors of Node7 adapt
          automatically as they always use the label in the BGP8277 NLRI as
          an outgoing label.<a href="#section-4.2.5-3" class="pilcrow">¶</a></p>
<p id="section-4.2.5-4">Node4 does understand the BGP Prefix-SID; therefore, it allocates the
          indexed label in the SRGB (16011) for 192.0.2.11/32.<a href="#section-4.2.5-4" class="pilcrow">¶</a></p>
<p id="section-4.2.5-5">As a result, all the data-plane entries across the network would
          be unchanged except the entries at Node7 and its neighbor Node4 as
          shown in the figures below.<a href="#section-4.2.5-5" class="pilcrow">¶</a></p>
<p id="section-4.2.5-6">The key point is that the end-to-end Label Switched Path (LSP) is
          preserved because the outgoing label is always derived from the
          received label within the BGP8277 NLRI. The index in the
          BGP Prefix-SID is only used as a hint on how to allocate the local
          label (the incoming label) but never for the outgoing label.<a href="#section-4.2.5-6" class="pilcrow">¶</a></p>
<span id="name-node7-forwarding-table-2"></span><div id="NODE7FIBINC">
<table class="center" id="table-5">
            <caption>
<a href="#table-5" class="selfRef">Table 5</a>:
<a href="#name-node7-forwarding-table-2" class="selfRef">Node7 Forwarding Table
</a>
            </caption>
<tbody>
              <tr>
                <td class="text-center" rowspan="1" colspan="1">Incoming Label or IP Destination
</td>
                <td class="text-center" rowspan="1" colspan="1">Outgoing Label
</td>
                <td class="text-center" rowspan="1" colspan="1">Outgoing Interface
</td>
              </tr>
              <tr>
                <td class="text-center" rowspan="1" colspan="1">12345
</td>
                <td class="text-center" rowspan="1" colspan="1">16011
</td>
                <td class="text-center" rowspan="1" colspan="1">10
</td>
              </tr>
            </tbody>
          </table>
</div>
<span id="name-node4-forwarding-table-2"></span><div id="NODE4FIBINC">
<table class="center" id="table-6">
            <caption>
<a href="#table-6" class="selfRef">Table 6</a>:
<a href="#name-node4-forwarding-table-2" class="selfRef">Node4 Forwarding Table
</a>
            </caption>
<tbody>
              <tr>
                <td class="text-center" rowspan="1" colspan="1">Incoming Label or IP Destination
</td>
                <td class="text-center" rowspan="1" colspan="1">Outgoing Label
</td>
                <td class="text-center" rowspan="1" colspan="1">Outgoing Interface
</td>
              </tr>
              <tr>
                <td class="text-center" rowspan="1" colspan="1">16011
</td>
                <td class="text-center" rowspan="1" colspan="1">12345
</td>
                <td class="text-center" rowspan="1" colspan="1">7
</td>
              </tr>
            </tbody>
          </table>
</div>
<p id="section-4.2.5-9">The BGP Prefix-SID can thus be deployed incrementally, i.e., one node at
          a time.<a href="#section-4.2.5-9" class="pilcrow">¶</a></p>
<p id="section-4.2.5-10">When deployed together with a homogeneous SRGB (the same SRGB across
          the fabric), the operator incrementally enjoys the global prefix
          segment benefits as the deployment progresses through the
          fabric.<a href="#section-4.2.5-10" class="pilcrow">¶</a></p>
</section>
</div>
</section>
</div>
<div id="iBGP3107">
<section id="section-4.3">
        <h3 id="name-ibgp-labeled-unicast-rfc-82">
<a href="#section-4.3" class="section-number selfRef">4.3. </a><a href="#name-ibgp-labeled-unicast-rfc-82" class="section-name selfRef">IBGP Labeled Unicast (RFC 8277)</a>
        </h3>
<p id="section-4.3-1">The same exact design as EBGP8277 is used with the following
        modifications:<a href="#section-4.3-1" class="pilcrow">¶</a></p>
<ul>
<li id="section-4.3-2.1">All nodes use the same AS number.<a href="#section-4.3-2.1" class="pilcrow">¶</a>
</li>
          <li id="section-4.3-2.2">Each node peers with its neighbors via an internal BGP session
            (IBGP) with extensions defined in <span>[<a href="#RFC8277" class="xref">RFC8277</a>]</span> (named
            "IBGP8277" throughout this document).<a href="#section-4.3-2.2" class="pilcrow">¶</a>
</li>
          <li id="section-4.3-2.3">Each node acts as a route reflector for each of its neighbors
            and with the next-hop-self option. Next-hop-self is a well-known
            operational feature that consists of rewriting the next hop of a
            BGP update prior to sending it to the neighbor. Usually,
            it's a common practice to apply next-hop-self behavior
            towards IBGP peers for EBGP-learned routes. In the case outlined
            in this section, it is proposed to use the next-hop-self mechanism
            also to IBGP-learned routes.<a href="#section-4.3-2.3" class="pilcrow">¶</a>
</li>
        </ul>
<span id="name-ibgp-sessions-with-reflecti"></span><div id="IBGPFIG">
<figure id="figure-3">
          <div class="artwork art-text alignLeft" id="section-4.3-3.1">
<pre>
                               Cluster-1  
                            +-----------+
                            |  Tier-1   |
                            |  +-----+  |
                            |  |NODE |  |
                            |  |  5  |  |
                 Cluster-2  |  +-----+  |  Cluster-3
                +---------+ |           | +---------+
                | Tier-2  | |           | |  Tier-2 |
                | +-----+ | |  +-----+  | | +-----+ |
                | |NODE | | |  |NODE |  | | |NODE | |
                | |  3  | | |  |  6  |  | | |  9  | | 
                | +-----+ | |  +-----+  | | +-----+ |
                |         | |           | |         |
                |         | |           | |         |
                | +-----+ | |  +-----+  | | +-----+ |
                | |NODE | | |  |NODE |  | | |NODE | |
                | |  4  | | |  |  7  |  | | |  10 | |
                | +-----+ | |  +-----+  | | +-----+ |
                +---------+ |           | +---------+
                            |           |
                            |  +-----+  |         
                            |  |NODE |  |      
          Tier-3            |  |  8  |  |         Tier-3       
      +-----+ +-----+       |  +-----+  |      +-----+ +-----+ 
      |NODE | |NODE |       +-----------+      |NODE | |NODE | 
      |  1  | |  2  |                          | 11  | |  12 | 
      +-----+ +-----+                          +-----+ +-----+</pre>
</div>
<figcaption><a href="#figure-3" class="selfRef">Figure 3</a>:
<a href="#name-ibgp-sessions-with-reflecti" class="selfRef">IBGP Sessions with Reflection and Next-Hop-Self</a>
          </figcaption></figure>
</div>
<ul>
<li id="section-4.3-4.1">
            <p id="section-4.3-4.1.1">For simple and efficient route propagation filtering and as
            illustrated in <a href="#IBGPFIG" class="xref">Figure 3</a>:<a href="#section-4.3-4.1.1" class="pilcrow">¶</a></p>
<ul>
<li id="section-4.3-4.1.2.1">Node5, Node6, Node7, and Node8 use the same Cluster ID
                (Cluster-1).<a href="#section-4.3-4.1.2.1" class="pilcrow">¶</a>
</li>
              <li id="section-4.3-4.1.2.2">Node3 and Node4 use the same Cluster ID (Cluster-2).<a href="#section-4.3-4.1.2.2" class="pilcrow">¶</a>
</li>
              <li id="section-4.3-4.1.2.3">Node9 and Node10 use the same Cluster ID (Cluster-3).<a href="#section-4.3-4.1.2.3" class="pilcrow">¶</a>
</li>
            </ul>
</li>
          <li id="section-4.3-4.2">The control-plane behavior is mostly the same as described in
            the previous section; the only difference is that the EBGP8277
            path propagation is simply replaced by an IBGP8277 path reflection
            with next hop changed to self.<a href="#section-4.3-4.2" class="pilcrow">¶</a>
</li>
          <li id="section-4.3-4.3">The data-plane tables are exactly the same.<a href="#section-4.3-4.3" class="pilcrow">¶</a>
</li>
        </ul>
</section>
</div>
</section>
</div>
<div id="IPV6">
<section id="section-5">
      <h2 id="name-applying-segment-routing-in-">
<a href="#section-5" class="section-number selfRef">5. </a><a href="#name-applying-segment-routing-in-" class="section-name selfRef">Applying Segment Routing in the DC with IPv6 Data Plane</a>
      </h2>
<p id="section-5-1">The design described in <span>[<a href="#RFC7938" class="xref">RFC7938</a>]</span> is reused with one
      single modification. It is highlighted using the example of the
      reachability to Node11 via Spine node Node5.<a href="#section-5-1" class="pilcrow">¶</a></p>
<p id="section-5-2">Node5 originates 2001:DB8::5/128 with the attached BGP Prefix-SID for
      IPv6 packets destined to segment 2001:DB8::5 (<span>[<a href="#RFC8402" class="xref">RFC8402</a>]</span>).<a href="#section-5-2" class="pilcrow">¶</a></p>
<p id="section-5-3">Node11 originates 2001:DB8::11/128 with the attached BGP Prefix-SID
      advertising the support of the Segment Routing Header (SRH) for IPv6 packets destined to segment
      2001:DB8::11.<a href="#section-5-3" class="pilcrow">¶</a></p>
<p id="section-5-4">The control-plane and data-plane processing of all the other nodes in
      the fabric is unchanged. Specifically, the routes to 2001:DB8::5 and
      2001:DB8::11 are installed in the FIB along the EBGP best path to Node5
      (Spine node) and Node11 (ToR node) respectively.<a href="#section-5-4" class="pilcrow">¶</a></p>
<p id="section-5-5">An application on HostA that needs to send traffic to HostZ via only
      Node5 (Spine node) can do so by sending IPv6 packets with a Segment
      Routing Header (SRH, <span>[<a href="#I-D.ietf-6man-segment-routing-header" class="xref">IPv6-SRH</a>]</span>). The destination
      address and active segment is set to 2001:DB8::5. The next and last
      segment is set to 2001:DB8::11.<a href="#section-5-5" class="pilcrow">¶</a></p>
<p id="section-5-6">The application must only use IPv6 addresses that have been
      advertised as capable for SRv6 segment processing (e.g., for which the
      BGP Prefix Segment capability has been advertised). How applications
      learn this (e.g., centralized controller and orchestration) is outside
      the scope of this document.<a href="#section-5-6" class="pilcrow">¶</a></p>
</section>
</div>
<div id="COMMHOSTS">
<section id="section-6">
      <h2 id="name-communicating-path-informat">
<a href="#section-6" class="section-number selfRef">6. </a><a href="#name-communicating-path-informat" class="section-name selfRef">Communicating Path Information to the Host</a>
      </h2>
<p id="section-6-1">There are two general methods for communicating path information to
      the end-hosts: "proactive" and "reactive", aka "push" and "pull" models.
      There are multiple ways to implement either of these methods. Here, it
      is noted that one way could be using a centralized controller: the
      controller either tells the hosts of the prefix-to-path mappings
      beforehand and updates them as needed (network event driven push) or
      responds to the hosts making requests for a path to a specific destination
      (host event driven pull). It is also possible to use a hybrid model,
      i.e., pushing some state from the controller in response to particular
      network events, while the host pulls other state on demand.<a href="#section-6-1" class="pilcrow">¶</a></p>
<p id="section-6-2">Note also that when disseminating network-related data to the
      end-hosts, a trade-off is made to balance the amount of information
      vs. the level of visibility in the network state. This applies 
      to both push and pull models. In the extreme case, the host would request
      path information on every flow and keep no local state at all. On the
      other end of the spectrum, information for every prefix in the network
      along with available paths could be pushed and continuously updated on
      all hosts.<a href="#section-6-2" class="pilcrow">¶</a></p>
</section>
</div>
<div id="BENEFITS">
<section id="section-7">
      <h2 id="name-additional-benefits">
<a href="#section-7" class="section-number selfRef">7. </a><a href="#name-additional-benefits" class="section-name selfRef">Additional Benefits</a>
      </h2>
<div id="MPLSIMPLE">
<section id="section-7.1">
        <h3 id="name-mpls-data-plane-with-operat">
<a href="#section-7.1" class="section-number selfRef">7.1. </a><a href="#name-mpls-data-plane-with-operat" class="section-name selfRef">MPLS Data Plane with Operational Simplicity</a>
        </h3>
<p id="section-7.1-1">As required by <span>[<a href="#RFC7938" class="xref">RFC7938</a>]</span>, no new signaling protocol
        is introduced. The BGP Prefix-SID is a lightweight extension to BGP
        Labeled Unicast <span>[<a href="#RFC8277" class="xref">RFC8277</a>]</span>. It applies either to EBGP- or
        IBGP-based designs.<a href="#section-7.1-1" class="pilcrow">¶</a></p>
<p id="section-7.1-2">Specifically, LDP and RSVP-TE are not used. These protocols would
        drastically impact the operational complexity of the data center and
        would not scale. This is in line with the requirements expressed in
        <span>[<a href="#RFC7938" class="xref">RFC7938</a>]</span>.<a href="#section-7.1-2" class="pilcrow">¶</a></p>
<p id="section-7.1-3">Provided the same SRGB is configured on all nodes, all nodes use
        the same MPLS label for a given IP prefix. This is simpler from an
        operation standpoint, as discussed in <a href="#SINGLESRGB" class="xref">Section 8</a>.<a href="#section-7.1-3" class="pilcrow">¶</a></p>
</section>
</div>
<div id="MINFIB">
<section id="section-7.2">
        <h3 id="name-minimizing-the-fib-table">
<a href="#section-7.2" class="section-number selfRef">7.2. </a><a href="#name-minimizing-the-fib-table" class="section-name selfRef">Minimizing the FIB Table</a>
        </h3>
<p id="section-7.2-1">The designer may decide to switch all the traffic at Tier-1 and
        Tier-2 based on MPLS, thereby drastically decreasing the IP table size
        at these nodes.<a href="#section-7.2-1" class="pilcrow">¶</a></p>
<p id="section-7.2-2">This is easily accomplished by encapsulating the traffic either
        directly at the host or at the source ToR node. The encapsulation is
        done by pushing the BGP Prefix-SID of the destination ToR for intra-DC
        traffic, or by pushing the BGP Prefix-SID for the border node for
        inter-DC or DC-to-outside-world traffic.<a href="#section-7.2-2" class="pilcrow">¶</a></p>
</section>
</div>
<div id="EPE">
<section id="section-7.3">
        <h3 id="name-egress-peer-engineering">
<a href="#section-7.3" class="section-number selfRef">7.3. </a><a href="#name-egress-peer-engineering" class="section-name selfRef">Egress Peer Engineering</a>
        </h3>
<p id="section-7.3-1">It is straightforward to combine the design illustrated in this
        document with the Egress Peer Engineering (EPE) use case described in
        <span>[<a href="#I-D.ietf-spring-segment-routing-central-epe" class="xref">SR-CENTRAL-EPE</a>]</span>.<a href="#section-7.3-1" class="pilcrow">¶</a></p>
<p id="section-7.3-2">In such a case, the operator is able to engineer its outbound traffic
        on a per-host-flow basis, without incurring any additional state at
        intermediate points in the DC fabric.<a href="#section-7.3-2" class="pilcrow">¶</a></p>
<p id="section-7.3-3">For example, the controller only needs to inject a per-flow state
        on the HostA to force it to send its traffic destined to a specific
        Internet destination D via a selected border node (say Node12 in <a href="#FIGLARGE" class="xref">Figure 1</a> instead of another border node, Node11) and a
        specific egress peer of Node12 (say peer AS 9999 of local PeerNode
        segment 9999 at Node12 instead of any other peer that provides a path
        to the destination D). Any packet matching this state at HostA would
        be encapsulated with SR segment list (label stack) {16012, 9999}.
        16012 would steer the flow through the DC fabric, leveraging any ECMP,
        along the best path to border node Node12. Once the flow gets to
        border node Node12, the active segment is 9999 (because of Penultimate
        Hop Popping (PHP) on the upstream neighbor of Node12). This EPE
        PeerNode segment forces border node Node12 to forward the packet to
        peer AS 9999 without any IP lookup at the border node. There is no
        per-flow state for this engineered flow in the DC fabric. A benefit of
        SR is that the per-flow state is only required at the
        source.<a href="#section-7.3-3" class="pilcrow">¶</a></p>
<p id="section-7.3-4">As well as allowing full traffic-engineering control, such a design
        also offers FIB table-minimization benefits as the Internet-scale FIB
        at border node Node12 is not required if all FIB lookups are avoided
        there by using EPE.<a href="#section-7.3-4" class="pilcrow">¶</a></p>
</section>
</div>
<div id="ANYCAST">
<section id="section-7.4">
        <h3 id="name-anycast">
<a href="#section-7.4" class="section-number selfRef">7.4. </a><a href="#name-anycast" class="section-name selfRef">Anycast</a>
        </h3>
<p id="section-7.4-1">The design presented in this document preserves the availability
        and load-balancing properties of the base design presented in <span>[<a href="#RFC8402" class="xref">RFC8402</a>]</span>.<a href="#section-7.4-1" class="pilcrow">¶</a></p>
<p id="section-7.4-2">For example, one could assign an anycast loopback 192.0.2.20/32 and
        associate segment index 20 to it on the border nodes Node11 and Node12 (in
        addition to their node-specific loopbacks). Doing so, the EPE
        controller could express a default "go-to-the-Internet via any border
        node" policy as segment list {16020}. Indeed, from any host in the DC
        fabric or from any ToR node, 16020 steers the packet towards the
        border nodes Node11 or Node12 leveraging ECMP where available along the best
        paths to these nodes.<a href="#section-7.4-2" class="pilcrow">¶</a></p>
</section>
</div>
</section>
</div>
<div id="SINGLESRGB">
<section id="section-8">
      <h2 id="name-preferred-srgb-allocation">
<a href="#section-8" class="section-number selfRef">8. </a><a href="#name-preferred-srgb-allocation" class="section-name selfRef">Preferred SRGB Allocation</a>
      </h2>
<p id="section-8-1">In the MPLS case, it is recommended to use the same SRGBs at each node.<a href="#section-8-1" class="pilcrow">¶</a></p>
<p id="section-8-2">Different SRGBs in each node likely increase the complexity of the
      solution both from an operational viewpoint and from a controller
      viewpoint.<a href="#section-8-2" class="pilcrow">¶</a></p>
<p id="section-8-3">From an operational viewpoint, it is much simpler to have the same
      global label at every node for the same destination (the MPLS
      troubleshooting is then similar to the IPv6 troubleshooting where this
      global property is a given).<a href="#section-8-3" class="pilcrow">¶</a></p>
<p id="section-8-4">From a controller viewpoint, this allows us to construct simple
      policies applicable across the fabric.<a href="#section-8-4" class="pilcrow">¶</a></p>
<p id="section-8-5">Let us consider two applications, A and B, respectively connected to
      Node1 and Node2 (ToR nodes). Application A has two flows, FA1 and FA2, destined to Z.
      B has two flows, FB1 and FB2, destined to Z. The controller wants FA1 and
      FB1 to be load shared across the fabric while FA2 and FB2 must be
      respectively steered via Node5 and Node8.<a href="#section-8-5" class="pilcrow">¶</a></p>
<p id="section-8-6">Assuming a consistent unique SRGB across the fabric as described in
      this document, the controller can simply do it by instructing A and B to
      use {16011} respectively for FA1 and FB1 and by instructing A and B to
      use {16005 16011} and {16008 16011} respectively for FA2 and FB2.<a href="#section-8-6" class="pilcrow">¶</a></p>
<p id="section-8-7">Let us assume a design where the SRGB is different at every node and
      where the SRGB of each node is advertised using the Originator SRGB TLV
      of the BGP Prefix-SID as defined in <span>[<a href="#RFC8669" class="xref">RFC8669</a>]</span>: SRGB of Node K starts at value
      K*1000, and the SRGB length is 1000 (e.g., Node1's SRGB is [1000,
      1999], Node2's SRGB is [2000, 2999], ...).<a href="#section-8-7" class="pilcrow">¶</a></p>
<p id="section-8-8">In this case, the controller would need to collect and store all of
      these different SRGBs (e.g., through the Originator SRGB TLV of the
      BGP Prefix-SID); furthermore, it would also need to adapt the policy for
      each host. Indeed, the controller would instruct A to use {1011} for FA1
      while it would have to instruct B to use {2011} for FB1 (while with the
      same SRGB, both policies are the same {16011}).<a href="#section-8-8" class="pilcrow">¶</a></p>
<p id="section-8-9">Even worse, the controller would instruct A to use {1005, 5011} for
      FA1 while it would instruct B to use {2011, 8011} for FB1 (while with
      the same SRGB, the second segment is the same across both policies:
      16011). When combining segments to create a policy, one needs to
      carefully update the label of each segment. This is obviously more error
      prone, more complex, and more difficult to troubleshoot.<a href="#section-8-9" class="pilcrow">¶</a></p>
</section>
</div>
<div id="IANA">
<section id="section-9">
      <h2 id="name-iana-considerations">
<a href="#section-9" class="section-number selfRef">9. </a><a href="#name-iana-considerations" class="section-name selfRef">IANA Considerations</a>
      </h2>
<p id="section-9-1">This document has no IANA actions.<a href="#section-9-1" class="pilcrow">¶</a></p>
</section>
</div>
<div id="MANAGE">
<section id="section-10">
      <h2 id="name-manageability-consideration">
<a href="#section-10" class="section-number selfRef">10. </a><a href="#name-manageability-consideration" class="section-name selfRef">Manageability Considerations</a>
      </h2>
<p id="section-10-1">The design and deployment guidelines described in this document are
      based on the network design described in <span>[<a href="#RFC7938" class="xref">RFC7938</a>]</span>.<a href="#section-10-1" class="pilcrow">¶</a></p>
<p id="section-10-2">The deployment model assumed in this document is based on a single
      domain where the interconnected DCs are part of the same administrative
      domain (which, of course, is split into different autonomous systems).
      The operator has full control of the whole domain, and the usual
      operational and management mechanisms and procedures are used in order
      to prevent any information related to internal prefixes and topology to
      be leaked outside the domain.<a href="#section-10-2" class="pilcrow">¶</a></p>
<p id="section-10-3">As recommended in <span>[<a href="#RFC8402" class="xref">RFC8402</a>]</span>,
      the same SRGB should be allocated in all nodes in order to facilitate
      the design, deployment, and operations of the domain.<a href="#section-10-3" class="pilcrow">¶</a></p>
<p id="section-10-4">When EPE (<span>[<a href="#I-D.ietf-spring-segment-routing-central-epe" class="xref">SR-CENTRAL-EPE</a>]</span>) is used (as
      explained in <a href="#EPE" class="xref">Section 7.3</a>), the same operational model is
      assumed. EPE information is originated and propagated throughout the
      domain towards an internal server, and unless explicitly configured by
      the operator, no EPE information is leaked outside the domain
      boundaries.<a href="#section-10-4" class="pilcrow">¶</a></p>
</section>
</div>
<div id="SEC">
<section id="section-11">
      <h2 id="name-security-considerations">
<a href="#section-11" class="section-number selfRef">11. </a><a href="#name-security-considerations" class="section-name selfRef">Security Considerations</a>
      </h2>
<p id="section-11-1">This document proposes to apply SR to a well-known
      scalability requirement expressed in <span>[<a href="#RFC7938" class="xref">RFC7938</a>]</span> using the
      BGP Prefix-SID as defined in <span>[<a href="#RFC8669" class="xref">RFC8669</a>]</span>.<a href="#section-11-1" class="pilcrow">¶</a></p>
<p id="section-11-2">It has to be noted, as described in <a href="#MANAGE" class="xref">Section 10</a>, that the
      design illustrated in <span>[<a href="#RFC7938" class="xref">RFC7938</a>]</span> and in this document
      refer to a deployment model where all nodes are under the same
      administration. In this context, it is assumed that the operator doesn't
      want to leak outside of the domain any information related to internal
      prefixes and topology. The internal information includes Prefix-SID and
      EPE information. In order to prevent such leaking, the standard BGP
      mechanisms (filters) are applied on the boundary of the domain.<a href="#section-11-2" class="pilcrow">¶</a></p>
<p id="section-11-3">Therefore, the solution proposed in this document does not introduce
      any additional security concerns from what is expressed in <span>[<a href="#RFC7938" class="xref">RFC7938</a>]</span> and <span>[<a href="#RFC8669" class="xref">RFC8669</a>]</span>. It
      is assumed that the security and confidentiality of the prefix and
      topology information is preserved by outbound filters at each peering
      point of the domain as described in <a href="#MANAGE" class="xref">Section 10</a>.<a href="#section-11-3" class="pilcrow">¶</a></p>
</section>
</div>
<section id="section-12">
      <h2 id="name-references">
<a href="#section-12" class="section-number selfRef">12. </a><a href="#name-references" class="section-name selfRef">References</a>
      </h2>
<section id="section-12.1">
        <h3 id="name-normative-references">
<a href="#section-12.1" class="section-number selfRef">12.1. </a><a href="#name-normative-references" class="section-name selfRef">Normative References</a>
        </h3>
<dl class="references">
<dt id="RFC4271">[RFC4271]</dt>
        <dd>
<span class="refAuthor">Rekhter, Y., Ed.</span><span class="refAuthor">, Li, T., Ed.</span><span class="refAuthor">, and S. Hares, Ed.</span>, <span class="refTitle">"A Border Gateway Protocol 4 (BGP-4)"</span>, <span class="seriesInfo">RFC 4271</span>, <span class="seriesInfo">DOI 10.17487/RFC4271</span>, <time datetime="2006-01">January 2006</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc4271">https://www.rfc-editor.org/info/rfc4271</a>&gt;</span>. </dd>
<dt id="RFC7938">[RFC7938]</dt>
        <dd>
<span class="refAuthor">Lapukhov, P.</span><span class="refAuthor">, Premji, A.</span><span class="refAuthor">, and J. Mitchell, Ed.</span>, <span class="refTitle">"Use of BGP for Routing in Large-Scale Data Centers"</span>, <span class="seriesInfo">RFC 7938</span>, <span class="seriesInfo">DOI 10.17487/RFC7938</span>, <time datetime="2016-08">August 2016</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc7938">https://www.rfc-editor.org/info/rfc7938</a>&gt;</span>. </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">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>
<dt id="RFC8402">[RFC8402]</dt>
        <dd>
<span class="refAuthor">Filsfils, C., Ed.</span><span class="refAuthor">, Previdi, S., Ed.</span><span class="refAuthor">, Ginsberg, L.</span><span class="refAuthor">, Decraene, B.</span><span class="refAuthor">, Litkowski, S.</span><span class="refAuthor">, and R. Shakir</span>, <span class="refTitle">"Segment Routing Architecture"</span>, <span class="seriesInfo">RFC 8402</span>, <span class="seriesInfo">DOI 10.17487/RFC8402</span>, <time datetime="2018-07">July 2018</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8402">https://www.rfc-editor.org/info/rfc8402</a>&gt;</span>. </dd>
<dt id="RFC8669">[RFC8669]</dt>
      <dd>
<span class="refAuthor">Previdi, S.</span><span class="refAuthor">, Filsfils, C.</span><span class="refAuthor">, Lindem, A., Ed.</span><span class="refAuthor">, Sreekantiah, A.</span><span class="refAuthor">, and H. Gredler</span>, <span class="refTitle">"Segment Routing Prefix Segment Identifier Extensions for BGP"</span>, <span class="seriesInfo">RFC 8669</span>, <span class="seriesInfo">DOI 10.17487/RFC8669</span>, <time datetime="2019-12">December 2019</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8669">https://www.rfc-editor.org/info/rfc8669</a>&gt;</span>. </dd>
</dl>
</section>
<section id="section-12.2">
        <h3 id="name-informative-references">
<a href="#section-12.2" class="section-number selfRef">12.2. </a><a href="#name-informative-references" class="section-name selfRef">Informative References</a>
        </h3>
<dl class="references">
<dt id="I-D.ietf-6man-segment-routing-header">[IPv6-SRH]</dt>
        <dd>
<span class="refAuthor">Filsfils, C.</span><span class="refAuthor">, Dukes, D.</span><span class="refAuthor">, Previdi, S.</span><span class="refAuthor">, Leddy, J.</span><span class="refAuthor">, Matsushima, S.</span><span class="refAuthor">, and D. Voyer</span>, <span class="refTitle">"IPv6 Segment Routing Header (SRH)"</span>, <span class="refContent">Work in Progress</span>, <span class="seriesInfo">Internet-Draft, draft-ietf-6man-segment-routing-header-26</span>, <time datetime="2019-10-22">22 October 2019</time>, <span>&lt;<a href="https://tools.ietf.org/html/draft-ietf-6man-segment-routing-header-26">https://tools.ietf.org/html/draft-ietf-6man-segment-routing-header-26</a>&gt;</span>. </dd>
<dt id="RFC6793">[RFC6793]</dt>
        <dd>
<span class="refAuthor">Vohra, Q.</span><span class="refAuthor"> and E. Chen</span>, <span class="refTitle">"BGP Support for Four-Octet Autonomous System (AS) Number Space"</span>, <span class="seriesInfo">RFC 6793</span>, <span class="seriesInfo">DOI 10.17487/RFC6793</span>, <time datetime="2012-12">December 2012</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc6793">https://www.rfc-editor.org/info/rfc6793</a>&gt;</span>. </dd>
<dt id="I-D.ietf-spring-segment-routing-central-epe">[SR-CENTRAL-EPE]</dt>
      <dd>
<span class="refAuthor">Filsfils, C.</span><span class="refAuthor">, Previdi, S.</span><span class="refAuthor">, Dawra, G.</span><span class="refAuthor">, Aries, E.</span><span class="refAuthor">, and D. Afanasiev</span>, <span class="refTitle">"Segment Routing Centralized BGP Egress Peer Engineering"</span>, <span class="refContent">Work in Progress</span>, <span class="seriesInfo">Internet-Draft, draft-ietf-spring-segment-routing-central-epe-10</span>, <time datetime="2017-12-21">21 December 2017</time>, <span>&lt;<a href="https://tools.ietf.org/html/draft-ietf-spring-segment-routing-central-epe-10">https://tools.ietf.org/html/draft-ietf-spring-segment-routing-central-epe-10</a>&gt;</span>. </dd>
</dl>
</section>
</section>
<div id="Acknowledgements">
<section id="section-appendix.a">
      <h2 id="name-acknowledgements">
<a href="#name-acknowledgements" class="section-name selfRef">Acknowledgements</a>
      </h2>
<p id="section-appendix.a-1">The authors would like to thank Benjamin Black, Arjun Sreekantiah,
      Keyur Patel, Acee Lindem, and Anoop Ghanwani for their comments and
      review of this document.<a href="#section-appendix.a-1" class="pilcrow">¶</a></p>
</section>
</div>
<div id="Contributors">
<section id="section-appendix.b">
      <h2 id="name-contributors">
<a href="#name-contributors" class="section-name selfRef">Contributors</a>
      </h2>
<div class="artwork art-text alignLeft" id="section-appendix.b-1">
<pre>Gaya Nagarajan
Facebook
United States of America

Email: gaya@fb.com</pre><a href="#section-appendix.b-1" class="pilcrow">¶</a>
</div>
<div class="artwork art-text alignLeft" id="section-appendix.b-2">
<pre>Gaurav Dawra
Cisco Systems
United States of America

Email: gdawra.ietf@gmail.com</pre><a href="#section-appendix.b-2" class="pilcrow">¶</a>
</div>
<div class="artwork art-text alignLeft" id="section-appendix.b-3">
<pre>Dmitry Afanasiev
Yandex
Russian Federation

Email: fl0w@yandex-team.ru</pre><a href="#section-appendix.b-3" class="pilcrow">¶</a>
</div>
<div class="artwork art-text alignLeft" id="section-appendix.b-4">
<pre>Tim Laberge
Cisco
United States of America

Email: tlaberge@cisco.com</pre><a href="#section-appendix.b-4" class="pilcrow">¶</a>
</div>
<div class="artwork art-text alignLeft" id="section-appendix.b-5">
<pre>Edet Nkposong
Salesforce.com Inc.
United States of America

Email: enkposong@salesforce.com</pre><a href="#section-appendix.b-5" class="pilcrow">¶</a>
</div>
<div class="artwork art-text alignLeft" id="section-appendix.b-6">
<pre>Mohan Nanduri
Microsoft
United States of America

Email: mohan.nanduri@oracle.com</pre><a href="#section-appendix.b-6" class="pilcrow">¶</a>
</div>
<div class="artwork art-text alignLeft" id="section-appendix.b-7">
<pre>James Uttaro
ATT
United States of America

Email: ju1738@att.com</pre><a href="#section-appendix.b-7" class="pilcrow">¶</a>
</div>
<div class="artwork art-text alignLeft" id="section-appendix.b-8">
<pre>Saikat Ray
Unaffiliated
United States of America

Email: raysaikat@gmail.com</pre><a href="#section-appendix.b-8" class="pilcrow">¶</a>
</div>
<div class="artwork art-text alignLeft" id="section-appendix.b-9">
<pre>Jon Mitchell
Unaffiliated
United States of America

Email: jrmitche@puck.nether.net</pre><a href="#section-appendix.b-9" class="pilcrow">¶</a>
</div>
</section>
</div>
<div id="authors-addresses">
<section id="section-appendix.c">
      <h2 id="name-authors-addresses">
<a href="#name-authors-addresses" class="section-name selfRef">Authors' Addresses</a>
      </h2>
<address class="vcard">
        <div dir="auto" class="left"><span class="fn nameRole">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></div>
<div dir="auto" class="left"><span class="org">LinkedIn</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">Arrcus, Inc.</span></div>
<div dir="auto" class="left"><span class="street-address">2077 Gateway Place, Suite #400</span></div>
<div dir="auto" class="left">
<span class="locality">San Jose</span>,  <span class="postal-code">CA 95119</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@arrcus.com" class="email">exa@arrcus.com</a>
</div>
</address>
<address class="vcard">
        <div dir="auto" class="left"><span class="fn nameRole">Petr Lapukhov</span></div>
<div dir="auto" class="left"><span class="org">Facebook</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:petr@fb.com" class="email">petr@fb.com</a>
</div>
</address>
</section>
</div>
<script>var toc = document.getElementById("toc");
var tocToggle = toc.querySelector("h2");
var tocNav = toc.querySelector("nav");

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

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

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