File: rfc9125.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 (1950 lines) | stat: -rw-r--r-- 80,871 bytes
<!DOCTYPE html>
<html lang="en" class="RFC">
<head>
<meta charset="utf-8">
<meta content="Common,Latin" name="scripts">
<meta content="initial-scale=1.0" name="viewport">
<title>RFC 9125: Gateway Auto-Discovery and Route Advertisement for Site Interconnection Using Segment Routing</title>
<meta content="Adrian Farrel" name="author">
<meta content="John Drake" name="author">
<meta content="Eric Rosen" name="author">
<meta content="Keyur Patel" name="author">
<meta content="Luay Jalil" name="author">
<meta content="
       Data centers are attached to the Internet or a backbone network by
      gateway routers.  One data center typically has more than one gateway
      for commercial, load-balancing, and resiliency reasons.  Other sites,
      such as access networks, also need to be connected across backbone
      networks through gateways. 
       This document defines a mechanism using the BGP Tunnel Encapsulation
      attribute to allow data center gateway routers to advertise routes to
      the prefixes reachable in the site, including advertising them on behalf
      of other gateways at the same site.  This allows segment routing to be
      used to identify multiple paths across the Internet or backbone network
      between different gateways.  The paths can be selected for
      load-balancing, resilience, and quality purposes. 
    " name="description">
<meta content="xml2rfc 3.9.1" name="generator">
<meta content="SR" name="keyword">
<meta content="GW" name="keyword">
<meta content="BGP" name="keyword">
<meta content="9125" name="rfc.number">
<!-- Generator version information:
  xml2rfc 3.9.1
    Python 3.6.10
    appdirs 1.4.4
    ConfigArgParse 1.2.3
    google-i18n-address 2.3.5
    html5lib 1.0.1
    intervaltree 3.0.2
    Jinja2 2.11.2
    kitchen 1.2.6
    lxml 4.4.2
    pycairo 1.19.0
    pycountry 19.8.18
    pyflakes 2.1.1
    PyYAML 5.3.1
    requests 2.22.0
    setuptools 40.6.2
    six 1.14.0
    WeasyPrint 51
-->
<link href="rfc9125.xml" rel="alternate" type="application/rfc+xml">
<link href="#copyright" rel="license">
<style type="text/css">/*

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

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

*/

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

.refInstance {
  margin-bottom: 1.25em;
}

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

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

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

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

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

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

/* pagination */
@media print {
  body {

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

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

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

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

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

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

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

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

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

}

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


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

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

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

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

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

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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

}
/* Tweak the bcp14 keyword presentation */
.bcp14 {
  font-variant: small-caps;
  font-weight: bold;
  font-size: 0.9em;
}
/* Tweak the invisible space above H* in order not to overlay links in text above */
 h2 {
  margin-top: -18px;  /* provide offset for in-page anchors */
  padding-top: 31px;
 }
 h3 {
  margin-top: -18px;  /* provide offset for in-page anchors */
  padding-top: 24px;
 }
 h4 {
  margin-top: -18px;  /* provide offset for in-page anchors */
  padding-top: 24px;
 }
/* Float artwork pilcrow to the right */
@media screen {
  .artwork a.pilcrow {
    display: block;
    line-height: 0.7;
    margin-top: 0.15em;
  }
}
/* Make pilcrows on dd visible */
@media screen {
  dd:hover > a.pilcrow {
    visibility: visible;
  }
}
/* Make the placement of figcaption match that of a table's caption
   by removing the figure's added bottom margin */
.alignLeft.art-text,
.alignCenter.art-text,
.alignRight.art-text {
   margin-bottom: 0;
}
.alignLeft,
.alignCenter,
.alignRight {
  margin: 1em 0 0 0;
}
/* In print, the pilcrow won't show on hover, so prevent it from taking up space,
   possibly even requiring a new line */
@media print {
  a.pilcrow {
    display: none;
  }
}
/* Styling for the external metadata */
div#external-metadata {
  background-color: #eee;
  padding: 0.5em;
  margin-bottom: 0.5em;
  display: none;
}
div#internal-metadata {
  padding: 0.5em;                       /* to match the external-metadata padding */
}
/* Styling for title RFC Number */
h1#rfcnum {
  clear: both;
  margin: 0 0 -1em;
  padding: 1em 0 0 0;
}
/* Make .olPercent look the same as <ol><li> */
dl.olPercent > dd {
  margin-bottom: 0.25em;
  min-height: initial;
}
/* Give aside some styling to set it apart */
aside {
  border-left: 1px solid #ddd;
  margin: 1em 0 1em 2em;
  padding: 0.2em 2em;
}
aside > dl,
aside > ol,
aside > ul,
aside > table,
aside > p {
  margin-bottom: 0.5em;
}
/* Additional page break settings */
@media print {
  figcaption, table caption {
    page-break-before: avoid;
  }
}
/* Font size adjustments for print */
@media print {
  body  { font-size: 10pt;      line-height: normal; max-width: 96%; }
  h1    { font-size: 1.72em;    padding-top: 1.5em; } /* 1*1.2*1.2*1.2 */
  h2    { font-size: 1.44em;    padding-top: 1.5em; } /* 1*1.2*1.2 */
  h3    { font-size: 1.2em;     padding-top: 1.5em; } /* 1*1.2 */
  h4    { font-size: 1em;       padding-top: 1.5em; }
  h5, h6 { font-size: 1em;      margin: initial; padding: 0.5em 0 0.3em; }
}
/* Sourcecode margin in print, when there's no pilcrow */
@media print {
  .artwork,
  .sourcecode {
    margin-bottom: 1em;
  }
}
/* Avoid narrow tables forcing too narrow table captions, which may render badly */
table {
  min-width: 20em;
}
/* ol type a */
ol.type-a { list-style-type: lower-alpha; }
ol.type-A { list-style-type: upper-alpha; }
ol.type-i { list-style-type: lower-roman; }
ol.type-I { list-style-type: lower-roman; }
/* Apply the print table and row borders in general, on request from the RPC,
and increase the contrast between border and odd row background sligthtly */
table {
  border: 1px solid #ddd;
}
td {
  border-top: 1px solid #ddd;
}
tr:nth-child(2n+1) > td {
  background-color: #f8f8f8;
}
/* Use style rules to govern display of the TOC. */
@media screen and (max-width: 1023px) {
  #toc nav { display: none; }
  #toc.active nav { display: block; }
}
/* Add support for keepWithNext */
.keepWithNext {
  break-after: avoid-page;
  break-after: avoid-page;
}
/* Add support for keepWithPrevious */
.keepWithPrevious {
  break-before: avoid-page;
}
/* Change the approach to avoiding breaks inside artwork etc. */
figure, pre, table, .artwork, .sourcecode  {
  break-before: avoid-page;
  break-after: auto;
}
/* Avoid breaks between <dt> and <dd> */
dl {
  break-before: auto;
  break-inside: auto;
}
dt {
  break-before: auto;
  break-after: avoid-page;
}
dd {
  break-before: avoid-page;
  break-after: auto;
  orphans: 3;
  widows: 3
}
span.break, dd.break {
  margin-bottom: 0;
  min-height: 0;
  break-before: auto;
  break-inside: auto;
  break-after: auto;
}
/* Undo break-before ToC */
@media print {
  #toc {
    break-before: auto;
  }
}
/* Text in compact lists should not get extra bottim margin space,
   since that would makes the list not compact */
ul.compact p, .ulCompact p,
ol.compact p, .olCompact p {
 margin: 0;
}
/* But the list as a whole needs the extra space at the end */
section ul.compact,
section .ulCompact,
section ol.compact,
section .olCompact {
  margin-bottom: 1em;                    /* same as p not within ul.compact etc. */
}
/* The tt and code background above interferes with for instance table cell
   backgrounds.  Changed to something a bit more selective. */
tt, code {
  background-color: transparent;
}
p tt, p code, li tt, li code {
  background-color: #f8f8f8;
}
/* Tweak the pre margin -- 0px doesn't come out well */
pre {
   margin-top: 0.5px;
}
/* Tweak the comact list text */
ul.compact, .ulCompact,
ol.compact, .olCompact,
dl.compact, .dlCompact {
  line-height: normal;
}
/* Don't add top margin for nested lists */
li > ul, li > ol, li > dl,
dd > ul, dd > ol, dd > dl,
dl > dd > dl {
  margin-top: initial;
}
/* Elements that should not be rendered on the same line as a <dt> */
/* This should match the element list in writer.text.TextWriter.render_dl() */
dd > div.artwork:first-child,
dd > aside:first-child,
dd > figure:first-child,
dd > ol:first-child,
dd > div:first-child > pre.sourcecode,
dd > table:first-child,
dd > ul:first-child {
  clear: left;
}
/* fix for weird browser behaviour when <dd/> is empty */
dt+dd:empty::before{
  content: "\00a0";
}
/* Make paragraph spacing inside <li> smaller than in body text, to fit better within the list */
li > p {
  margin-bottom: 0.5em
}
/* Don't let p margin spill out from inside list items */
li > p:last-of-type {
  margin-bottom: 0;
}
</style>
<link href="rfc-local.css" rel="stylesheet" type="text/css">
<link href="https://dx.doi.org/10.17487/rfc9125" rel="alternate">
  <link href="urn:issn:2070-1721" rel="alternate">
  <link href="https://datatracker.ietf.org/doc/draft-ietf-bess-datacenter-gateway-13" 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 9125</td>
<td class="center">SR DC Gateways</td>
<td class="right">August 2021</td>
</tr></thead>
<tfoot><tr>
<td class="left">Farrel, et al.</td>
<td class="center">Standards Track</td>
<td class="right">[Page]</td>
</tr></tfoot>
</table>
<div id="external-metadata" class="document-information"></div>
<div id="internal-metadata" class="document-information">
<dl id="identifiers">
<dt class="label-stream">Stream:</dt>
<dd class="stream">Internet Engineering Task Force (IETF)</dd>
<dt class="label-rfc">RFC:</dt>
<dd class="rfc"><a href="https://www.rfc-editor.org/rfc/rfc9125" class="eref">9125</a></dd>
<dt class="label-category">Category:</dt>
<dd class="category">Standards Track</dd>
<dt class="label-published">Published:</dt>
<dd class="published">
<time datetime="2021-08" class="published">August 2021</time>
    </dd>
<dt class="label-issn">ISSN:</dt>
<dd class="issn">2070-1721</dd>
<dt class="label-authors">Authors:</dt>
<dd class="authors">
<div class="author">
      <div class="author-name">A. Farrel</div>
<div class="org">Old Dog Consulting</div>
</div>
<div class="author">
      <div class="author-name">J. Drake</div>
<div class="org">Juniper Networks</div>
</div>
<div class="author">
      <div class="author-name">E. Rosen</div>
<div class="org">Juniper Networks</div>
</div>
<div class="author">
      <div class="author-name">K. Patel</div>
<div class="org">Arrcus, Inc.</div>
</div>
<div class="author">
      <div class="author-name">L. Jalil</div>
<div class="org">Verizon</div>
</div>
</dd>
</dl>
</div>
<h1 id="rfcnum">RFC 9125</h1>
<h1 id="title">Gateway Auto-Discovery and Route Advertisement for Site Interconnection Using Segment Routing</h1>
<section id="section-abstract">
      <h2 id="abstract"><a href="#abstract" class="selfRef">Abstract</a></h2>
<p id="section-abstract-1">Data centers are attached to the Internet or a backbone network by
      gateway routers.  One data center typically has more than one gateway
      for commercial, load-balancing, and resiliency reasons.  Other sites,
      such as access networks, also need to be connected across backbone
      networks through gateways.<a href="#section-abstract-1" class="pilcrow">¶</a></p>
<p id="section-abstract-2">This document defines a mechanism using the BGP Tunnel Encapsulation
      attribute to allow data center gateway routers to advertise routes to
      the prefixes reachable in the site, including advertising them on behalf
      of other gateways at the same site.  This allows segment routing to be
      used to identify multiple paths across the Internet or backbone network
      between different gateways.  The paths can be selected for
      load-balancing, resilience, and quality purposes.<a href="#section-abstract-2" class="pilcrow">¶</a></p>
</section>
<div id="status-of-memo">
<section id="section-boilerplate.1">
        <h2 id="name-status-of-this-memo">
<a href="#name-status-of-this-memo" class="section-name selfRef">Status of This Memo</a>
        </h2>
<p id="section-boilerplate.1-1">
            This is an Internet Standards Track document.<a href="#section-boilerplate.1-1" class="pilcrow">¶</a></p>
<p id="section-boilerplate.1-2">
            This document is a product of the Internet Engineering Task Force
            (IETF).  It represents the consensus of the IETF community.  It has
            received public review and has been approved for publication by
            the Internet Engineering Steering Group (IESG).  Further
            information on Internet Standards is available in Section 2 of 
            RFC 7841.<a href="#section-boilerplate.1-2" class="pilcrow">¶</a></p>
<p id="section-boilerplate.1-3">
            Information about the current status of this document, any
            errata, and how to provide feedback on it may be obtained at
            <span><a href="https://www.rfc-editor.org/info/rfc9125">https://www.rfc-editor.org/info/rfc9125</a></span>.<a href="#section-boilerplate.1-3" class="pilcrow">¶</a></p>
</section>
</div>
<div id="copyright">
<section id="section-boilerplate.2">
        <h2 id="name-copyright-notice">
<a href="#name-copyright-notice" class="section-name selfRef">Copyright Notice</a>
        </h2>
<p id="section-boilerplate.2-1">
            Copyright (c) 2021 IETF Trust and the persons identified as the
            document authors. All rights reserved.<a href="#section-boilerplate.2-1" class="pilcrow">¶</a></p>
<p id="section-boilerplate.2-2">
            This document is subject to BCP 78 and the IETF Trust's Legal
            Provisions Relating to IETF Documents
            (<span><a href="https://trustee.ietf.org/license-info">https://trustee.ietf.org/license-info</a></span>) in effect on the date of
            publication of this document. Please review these documents
            carefully, as they describe your rights and restrictions with
            respect to this document. Code Components extracted from this
            document must include Simplified BSD License text as described in
            Section 4.e of the Trust Legal Provisions and are provided without
            warranty as described in the Simplified BSD License.<a href="#section-boilerplate.2-2" class="pilcrow">¶</a></p>
</section>
</div>
<div id="toc">
<section id="section-toc.1">
        <a href="#" onclick="scroll(0,0)" class="toplink">▲</a><h2 id="name-table-of-contents">
<a href="#name-table-of-contents" class="section-name selfRef">Table of Contents</a>
        </h2>
<nav class="toc"><ul class="toc ulEmpty compact ulBare">
<li class="toc ulEmpty compact ulBare" id="section-toc.1-1.1">
            <p id="section-toc.1-1.1.1" class="keepWithNext"><a href="#section-1" class="xref">1</a>.  <a href="#name-introduction" class="xref">Introduction</a></p>
</li>
          <li class="toc ulEmpty compact ulBare" id="section-toc.1-1.2">
            <p id="section-toc.1-1.2.1" class="keepWithNext"><a href="#section-2" class="xref">2</a>.  <a href="#name-requirements-language" class="xref">Requirements Language</a></p>
</li>
          <li class="toc ulEmpty compact ulBare" id="section-toc.1-1.3">
            <p id="section-toc.1-1.3.1" class="keepWithNext"><a href="#section-3" class="xref">3</a>.  <a href="#name-site-gateway-auto-discovery" class="xref">Site Gateway Auto-Discovery</a></p>
</li>
          <li class="toc ulEmpty compact ulBare" id="section-toc.1-1.4">
            <p id="section-toc.1-1.4.1"><a href="#section-4" class="xref">4</a>.  <a href="#name-relationship-to-bgp-link-st" class="xref">Relationship to BGP - Link State and Egress Peer Engineering</a></p>
</li>
          <li class="toc ulEmpty compact ulBare" id="section-toc.1-1.5">
            <p id="section-toc.1-1.5.1"><a href="#section-5" class="xref">5</a>.  <a href="#name-advertising-a-site-route-ex" class="xref">Advertising a Site Route Externally</a></p>
</li>
          <li class="toc ulEmpty compact ulBare" id="section-toc.1-1.6">
            <p id="section-toc.1-1.6.1"><a href="#section-6" class="xref">6</a>.  <a href="#name-encapsulation" class="xref">Encapsulation</a></p>
</li>
          <li class="toc ulEmpty compact ulBare" id="section-toc.1-1.7">
            <p id="section-toc.1-1.7.1"><a href="#section-7" class="xref">7</a>.  <a href="#name-iana-considerations" class="xref">IANA Considerations</a></p>
</li>
          <li class="toc ulEmpty compact ulBare" id="section-toc.1-1.8">
            <p id="section-toc.1-1.8.1"><a href="#section-8" class="xref">8</a>.  <a href="#name-security-considerations" class="xref">Security Considerations</a></p>
</li>
          <li class="toc ulEmpty compact ulBare" id="section-toc.1-1.9">
            <p id="section-toc.1-1.9.1"><a href="#section-9" class="xref">9</a>.  <a href="#name-manageability-consideration" class="xref">Manageability Considerations</a></p>
<ul class="ulEmpty compact ulBare toc">
<li class="ulEmpty compact ulBare toc" id="section-toc.1-1.9.2.1">
                <p id="section-toc.1-1.9.2.1.1"><a href="#section-9.1" class="xref">9.1</a>.  <a href="#name-relationship-to-route-targe" class="xref">Relationship to Route Target Constraint</a></p>
</li>
            </ul>
</li>
          <li class="toc ulEmpty compact ulBare" id="section-toc.1-1.10">
            <p id="section-toc.1-1.10.1"><a href="#section-10" class="xref">10</a>. <a href="#name-references" class="xref">References</a></p>
<ul class="ulEmpty compact ulBare toc">
<li class="ulEmpty compact ulBare toc" id="section-toc.1-1.10.2.1">
                <p id="section-toc.1-1.10.2.1.1"><a href="#section-10.1" class="xref">10.1</a>.  <a href="#name-normative-references" class="xref">Normative References</a></p>
</li>
              <li class="ulEmpty compact ulBare toc" id="section-toc.1-1.10.2.2">
                <p id="section-toc.1-1.10.2.2.1"><a href="#section-10.2" class="xref">10.2</a>.  <a href="#name-informative-references" class="xref">Informative References</a></p>
</li>
            </ul>
</li>
          <li class="toc ulEmpty compact ulBare" id="section-toc.1-1.11">
            <p id="section-toc.1-1.11.1"><a href="#appendix-A" class="xref"></a><a href="#name-acknowledgements" class="xref">Acknowledgements</a></p>
</li>
          <li class="toc ulEmpty compact ulBare" id="section-toc.1-1.12">
            <p id="section-toc.1-1.12.1"><a href="#appendix-B" class="xref"></a><a href="#name-authors-addresses" class="xref">Authors' Addresses</a></p>
</li>
        </ul>
</nav>
</section>
</div>
<div id="introduction">
<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">Data centers (DCs) are critical components of the infrastructure used
      by network operators to provide services to their customers.  DCs
      (sites) are interconnected by a backbone network, which consists of any
      number of private networks and/or the Internet.  DCs are attached to the
      backbone network by routers that are gateways (GWs).  One DC typically has more
      than one GW for various reasons including commercial preferences, load
      balancing, or resiliency against connection or device failure.<a href="#section-1-1" class="pilcrow">¶</a></p>
<p id="section-1-2">Segment Routing (SR) (<span>[<a href="#RFC8402" class="xref">RFC8402</a>]</span>) is a
      protocol mechanism that can be used within a DC as well as for steering
      traffic that flows between two DC sites.  In order for a source site
      (also known as an ingress site) that uses SR to load-balance the flows
      it sends to a destination site (also known as an egress site), it needs
      to know the complete set of entry nodes (i.e., GWs) for that egress DC
      from the backbone network connecting the two DCs.  Note that it is
      assumed that the connected set of DC sites and the border nodes in the
      backbone network on the paths that connect the DC sites are part of the
      same SR BGP - Link State (LS) instance (see <span>[<a href="#RFC7752" class="xref">RFC7752</a>]</span> and <span>[<a href="#RFC9086" class="xref">RFC9086</a>]</span>) so
      that traffic engineering using SR may be used for these flows.<a href="#section-1-2" class="pilcrow">¶</a></p>
<p id="section-1-3">Other sites, such as access networks, also need to be connected
      across backbone networks through gateways.  For illustrative purposes,
      consider the ingress and egress sites shown in <a href="#david_hockney" class="xref">Figure 1</a> as separate Autonomous Systems (ASes) (noting that
      the sites could be implemented as part of the ASes to which they are
      attached, or as separate ASes).  

      The various ASes that provide connectivity between the ingress and
      egress sites could each be constructed differently and use different
      technologies such as IP; MPLS using global table routing information
      from BGP; MPLS IP VPN; SR-MPLS IP VPN; or SRv6 IP VPN.

      That is, the ingress and egress sites can be connected by tunnels across
      a variety of technologies. This document describes how SR Segment
      Identifiers (SIDs) are used to identify the paths between the ingress
      and egress sites.<a href="#section-1-3" class="pilcrow">¶</a></p>
<p id="section-1-4">The solution described in this document is agnostic as to whether the
      transit ASes do or do not have SR capabilities.  The solution uses SR to
      stitch together path segments between GWs and through the Autonomous
      System Border Routers (ASBRs).  Thus, there is a requirement that the
      GWs and ASBRs are SR capable.  The solution supports the SR path being
      extended into the ingress and egress sites if they are SR capable.<a href="#section-1-4" class="pilcrow">¶</a></p>
<p id="section-1-5">The solution defined in this document can be seen in the broader
      context of site interconnection in <span>[<a href="#I-D.farrel-spring-sr-domain-interconnect" class="xref">SR-INTERCONNECT</a>]</span>.
      That document shows how other existing protocol elements may be combined
      with the solution defined in this document to provide a full system, but
      it is not a necessary reference for understanding this document.<a href="#section-1-5" class="pilcrow">¶</a></p>
<p id="section-1-6">Suppose that there are two gateways, GW1 and GW2 as shown in <a href="#david_hockney" class="xref">Figure 1</a>, for a given egress site and
      that they each advertise a route to prefix X, which is located within the
      egress site with each setting itself as next hop.  One might think that
      the GWs for X could be inferred from the routes' next-hop fields, but
      typically it is not the case that both routes get distributed across the
      backbone: rather only the best route, as selected by BGP, is
      distributed.  This precludes load-balancing flows across both GWs.<a href="#section-1-6" class="pilcrow">¶</a></p>
<span id="name-example-site-interconnectio"></span><div id="david_hockney">
<figure id="figure-1">
        <div class="artwork art-text alignCenter" id="section-1-7.1">
<pre>
      -----------------                    ---------------------
     | Ingress         |                  | Egress     ------   |
     | Site            |                  | Site      |Prefix|  |
     |                 |                  |           |   X  |  |
     |                 |                  |            ------   |
     |       --        |                  |   ---          ---  |
     |      |GW|       |                  |  |GW1|        |GW2| |
      -------++--------                    ----+-----------+-+--
             | \                               |          /  |
             |  \                              |         /   |
             |  -+-------------        --------+--------+--  |
             | ||ASBR|     ----|      |----  |ASBR| |ASBR| | |
             | | ----     |ASBR+------+ASBR|  ----   ----  | |
             | |           ----|      |----                | |
             | |               |      |                    | |
             | |           ----|      |----                | |
             | | AS1      |ASBR+------+ASBR|           AS2 | |
             | |           ----|      |----                | |
             |  ---------------        --------------------  |
           --+-----------------------------------------------+--
          | |ASBR|                                       |ASBR| |
          |  ----               AS3                       ----  |
          |                                                     |
           -----------------------------------------------------
</pre>
</div>
<figcaption><a href="#figure-1" class="selfRef">Figure 1</a>:
<a href="#name-example-site-interconnectio" class="selfRef">Example Site Interconnection</a>
        </figcaption></figure>
</div>
<p id="section-1-8">The obvious solution to this problem is to use the BGP feature that
      allows the advertisement of multiple paths in BGP (known as Add-Paths)
      (<span>[<a href="#RFC7911" class="xref">RFC7911</a>]</span>) to ensure that all routes to X
      get advertised by BGP.  However, even if this is done, the identity of
      the GWs will be lost as soon as the routes get distributed through an
      ASBR that will set itself to be the
      next hop.  And if there are multiple ASes in the
      backbone, not only will the next hop change several times, but the
      Add-Paths technique will experience scaling issues.  This all means that
      the Add-Paths approach is effectively limited to sites connected over a
      single AS.<a href="#section-1-8" class="pilcrow">¶</a></p>
<p id="section-1-9">This document defines a solution that overcomes this limitation and
      works equally well with a backbone constructed from one or more ASes
      using the Tunnel Encapsulation attribute (<span>[<a href="#RFC9012" class="xref">RFC9012</a>]</span>) as follows:<a href="#section-1-9" class="pilcrow">¶</a></p>
<ul class="ulEmpty normal">
<li class="ulEmpty normal" id="section-1-10.1">When a GW to a given site advertises a route to a prefix X within
        that site, it will include a Tunnel Encapsulation attribute that
        contains the union of the Tunnel Encapsulation attributes advertised
        by each of the GWs to that site, including itself.<a href="#section-1-10.1" class="pilcrow">¶</a>
</li>
      </ul>
<p id="section-1-11">In other words, each route advertised by a GW identifies all of the
      GWs to the same site (see <a href="#DCGWautodisco" class="xref">Section 3</a> for a discussion of how GWs discover each other),
      i.e., the Tunnel Encapsulation attribute advertised by each GW contains
      multiple Tunnel TLVs, one or more from each active GW, and each Tunnel
      TLV will contain a Tunnel Egress Endpoint sub-TLV that identifies the GW
      for that Tunnel TLV.  Therefore, even if only one of the routes is
      distributed to other ASes, it will not matter how many times the next
      hop changes, as the Tunnel Encapsulation attribute will remain
      unchanged.<a href="#section-1-11" class="pilcrow">¶</a></p>
<p id="section-1-12">To put this in the context of <a href="#david_hockney" class="xref">Figure 1</a>, GW1 and GW2 discover each other as gateways for the
      egress site.  Both GW1 and GW2 advertise themselves as having routes to
      prefix X.  Furthermore, GW1 includes a Tunnel Encapsulation attribute,
      which is the union of its Tunnel Encapsulation attribute and GW2's
      Tunnel Encapsulation attribute.  Similarly, GW2 includes a Tunnel
      Encapsulation attribute, which is the union of its Tunnel Encapsulation
      attribute and GW1's Tunnel Encapsulation attribute.  The gateway in the
      ingress site can now see all possible paths to X in the egress site
      regardless of which route is propagated to it, and it can choose one or
      balance traffic flows as it sees fit.<a href="#section-1-12" class="pilcrow">¶</a></p>
</section>
</div>
<section id="section-2">
      <h2 id="name-requirements-language">
<a href="#section-2" class="section-number selfRef">2. </a><a href="#name-requirements-language" class="section-name selfRef">Requirements Language</a>
      </h2>
<p id="section-2-1">
    The key words "<span class="bcp14">MUST</span>", "<span class="bcp14">MUST NOT</span>", "<span class="bcp14">REQUIRED</span>", "<span class="bcp14">SHALL</span>", "<span class="bcp14">SHALL NOT</span>", "<span class="bcp14">SHOULD</span>", "<span class="bcp14">SHOULD NOT</span>", "<span class="bcp14">RECOMMENDED</span>", "<span class="bcp14">NOT RECOMMENDED</span>",
    "<span class="bcp14">MAY</span>", and "<span class="bcp14">OPTIONAL</span>" in this document are to be interpreted as
    described in BCP 14 <span>[<a href="#RFC2119" class="xref">RFC2119</a>]</span> <span>[<a href="#RFC8174" class="xref">RFC8174</a>]</span> 
    when, and only when, they appear in all capitals, as shown here.<a href="#section-2-1" class="pilcrow">¶</a></p>
</section>
<div id="DCGWautodisco">
<section id="section-3">
      <h2 id="name-site-gateway-auto-discovery">
<a href="#section-3" class="section-number selfRef">3. </a><a href="#name-site-gateway-auto-discovery" class="section-name selfRef">Site Gateway Auto-Discovery</a>
      </h2>
<p id="section-3-1">To allow a given site's GWs to auto-discover each other and to coordinate their operations,
        the following procedures are implemented:<a href="#section-3-1" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-3-2.1">A route target (<span>[<a href="#RFC4360" class="xref">RFC4360</a>]</span>) <span class="bcp14">MUST</span> be
        attached to each GW's auto-discovery route (defined below), and its
        value <span class="bcp14">MUST</span> be set to a value that indicates the site identifier.  The
        rules for constructing a route target are detailed in <span>[<a href="#RFC4360" class="xref">RFC4360</a>]</span>.  It is <span class="bcp14">RECOMMENDED</span> that a Type
        x00 or x02 route target be used.<a href="#section-3-2.1" class="pilcrow">¶</a>
</li>
        <li class="normal" id="section-3-2.2">Site identifiers are set through configuration.  The site
        identifiers <span class="bcp14">MUST</span> be the same across all GWs to the site (i.e., the
        same identifier is used by all GWs to the same site) and <span class="bcp14">MUST</span> be
        unique across all sites that are connected (i.e., across all GWs to
        all sites that are interconnected).<a href="#section-3-2.2" class="pilcrow">¶</a>
</li>
        <li class="normal" id="section-3-2.3">Each GW <span class="bcp14">MUST</span> construct an import filtering rule to import any
        route that carries a route target with the same site identifier that
        the GW itself uses.  This means that only these GWs will import those
        routes, and that all GWs to the same site will import each other's
        routes and will learn (auto-discover) the current set of active GWs
        for the site.<a href="#section-3-2.3" class="pilcrow">¶</a>
</li>
      </ul>
<p id="section-3-3">The auto-discovery route that each GW advertises consists of the following:<a href="#section-3-3" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-3-4.1">IPv4 or IPv6 Network Layer Reachability Information (NLRI) (<span>[<a href="#RFC4760" class="xref">RFC4760</a>]</span>) containing one of the GW's
        loopback addresses (that is, with an AFI/SAFI pair that is one of the 
        following: IPv4/NLRI used for unicast forwarding (1/1); IPv6/NLRI used for
        unicast forwarding (2/1); IPv4/NLRI with MPLS Labels (1/4); or
        IPv6/NLRI with MPLS Labels (2/4)).<a href="#section-3-4.1" class="pilcrow">¶</a>
</li>
        <li class="normal" id="section-3-4.2">A Tunnel Encapsulation attribute (<span>[<a href="#RFC9012" class="xref">RFC9012</a>]</span>) containing the GW's encapsulation information
       encoded in one or more Tunnel TLVs.<a href="#section-3-4.2" class="pilcrow">¶</a>
</li>
      </ul>
<p id="section-3-5">To avoid the side effect of applying the Tunnel Encapsulation
      attribute to any packet that is addressed to the GW itself, the address
      advertised for auto-discovery <span class="bcp14">MUST</span> be a different
      loopback address than is advertised for packets directed to the gateway
      itself.<a href="#section-3-5" class="pilcrow">¶</a></p>
<p id="section-3-6">As described in <a href="#introduction" class="xref">Section 1</a>, each
      GW will include a Tunnel Encapsulation attribute with the GW
      encapsulation information for each of the site's active GWs (including
      itself) in every route advertised externally to that site.  As the
      current set of active GWs changes (due to the addition of a new GW or
      the failure/removal of an existing GW), each externally advertised route
      will be re-advertised with a new Tunnel Encapsulation attribute, which
      reflects the current set of active GWs.<a href="#section-3-6" class="pilcrow">¶</a></p>
<p id="section-3-7">If a gateway becomes disconnected from the backbone network, or if
      the site operator decides to terminate the gateway's activity, it
      <span class="bcp14">MUST</span> withdraw the advertisements described above.  This
      means that remote gateways at other sites will stop seeing
      advertisements from or about this gateway.  Note that if the routing
      within a site is broken (for example, such that there is a route from
      one GW to another but not in the reverse direction), then it is
      possible that incoming traffic will be routed to the wrong GW to reach
      the destination prefix; in this degraded network situation, traffic may
      be dropped.<a href="#section-3-7" class="pilcrow">¶</a></p>
<p id="section-3-8">Note that if a GW is (mis)configured with a different site identifier
      from the other GWs to the same site, then it will not be auto-discovered
      by the other GWs (and will not auto-discover the other GWs).  This would
      result in a GW for another site receiving only the Tunnel Encapsulation
      attribute included in the BGP best route, i.e., the Tunnel Encapsulation
      attribute of the (mis)configured GW or that of the other GWs.<a href="#section-3-8" class="pilcrow">¶</a></p>
</section>
</div>
<div id="EPE">
<section id="section-4">
      <h2 id="name-relationship-to-bgp-link-st">
<a href="#section-4" class="section-number selfRef">4. </a><a href="#name-relationship-to-bgp-link-st" class="section-name selfRef">Relationship to BGP - Link State and Egress Peer Engineering</a>
      </h2>
<p id="section-4-1">When a remote GW receives a route to a prefix X, it uses the Tunnel
      Egress Endpoint sub-TLVs in the containing Tunnel Encapsulation
      attribute to identify the GWs through which X can be reached.  It uses
      this information to compute SR Traffic Engineering (SR TE) paths across
      the backbone network looking at the information advertised to it in SR
      BGP - Link State (BGP-LS) (<span>[<a href="#RFC9085" class="xref">RFC9085</a>]</span>) and
      correlated using the site identity.  SR Egress Peer Engineering (EPE)
      (<span>[<a href="#RFC9086" class="xref">RFC9086</a>]</span>) can be used to supplement the information advertised
      in BGP-LS.<a href="#section-4-1" class="pilcrow">¶</a></p>
</section>
</div>
<div id="advertising">
<section id="section-5">
      <h2 id="name-advertising-a-site-route-ex">
<a href="#section-5" class="section-number selfRef">5. </a><a href="#name-advertising-a-site-route-ex" class="section-name selfRef">Advertising a Site Route Externally</a>
      </h2>
<p id="section-5-1">When a packet destined for prefix X is sent on an SR TE path to a GW
      for the site containing X (that is, the packet is sent in the ingress
      site on an SR TE path that describes the whole path including those
      parts that are within the egress site), it needs to carry the receiving
      GW's SID for X such that this SID becomes the next SID that is due to be
      processed before the GW completes its processing of the packet.  To
      achieve this, each Tunnel TLV in the Tunnel Encapsulation attribute
      contains a Prefix-SID sub-TLV (<span>[<a href="#RFC9012" class="xref">RFC9012</a>]</span>) for X.<a href="#section-5-1" class="pilcrow">¶</a></p>
<p id="section-5-2">As defined in <span>[<a href="#RFC9012" class="xref">RFC9012</a>]</span>, the
      Prefix-SID sub-TLV is only for IPv4/IPV6 Labeled Unicast routes, so the
      solution described in this document only applies to routes of those
      types.  If the use of the Prefix-SID sub-TLV for routes of other types
      is defined in the future, further documents will be needed to describe
      their use for site interconnection consistent with this document.<a href="#section-5-2" class="pilcrow">¶</a></p>
<p id="section-5-3">Alternatively, if MPLS SR is in use and if the GWs for a given egress
      site are configured to allow GWs at remote ingress sites to perform SR
      TE through that egress site for a prefix X, then each GW to the egress
      site computes an SR TE path through the egress site to X and places each
      in an MPLS Label Stack sub-TLV (<span>[<a href="#RFC9012" class="xref">RFC9012</a>]</span>) in the SR Tunnel TLV for that GW.<a href="#section-5-3" class="pilcrow">¶</a></p>
<p id="section-5-4">Please refer to <span><a href="https://datatracker.ietf.org/doc/html/draft-farrel-spring-sr-domain-interconnect-06#section-7" class="relref">Section 7</a> of [<a href="#I-D.farrel-spring-sr-domain-interconnect" class="xref">SR-INTERCONNECT</a>]</span> for worked examples of how the SID stack
      is constructed in this case and how the advertisements would work.<a href="#section-5-4" class="pilcrow">¶</a></p>
</section>
</div>
<div id="encaps">
<section id="section-6">
      <h2 id="name-encapsulation">
<a href="#section-6" class="section-number selfRef">6. </a><a href="#name-encapsulation" class="section-name selfRef">Encapsulation</a>
      </h2>
<p id="section-6-1">
 If a site is configured to allow remote GWs to send packets to the site in
 the site's native encapsulation, then each GW to the site will also include
 multiple instances of a Tunnel TLV for that native encapsulation in
 externally advertised routes: one for each GW.  Each Tunnel TLV contains a
 Tunnel Egress Endpoint sub-TLV with the address of the GW that the Tunnel TLV
 identifies. A remote GW may then encapsulate a packet according to the rules
 defined via the sub-TLVs included in each of the Tunnel TLVs.<a href="#section-6-1" class="pilcrow">¶</a></p>
</section>
</div>
<div id="iana">
<section id="section-7">
      <h2 id="name-iana-considerations">
<a href="#section-7" class="section-number selfRef">7. </a><a href="#name-iana-considerations" class="section-name selfRef">IANA Considerations</a>
      </h2>
<p id="section-7-1">
 IANA maintains the "BGP Tunnel Encapsulation Attribute Tunnel
 Types" registry in the "Border Gateway Protocol (BGP) Tunnel
 Encapsulation" registry.<a href="#section-7-1" class="pilcrow">¶</a></p>
<p id="section-7-2">
 IANA had previously assigned the value 17 from this subregistry
 for "SR Tunnel", referencing this document as an Internet-Draft.
 At that time, the assignment policy for this range of the registry
 was "First Come First Served" <span>[<a href="#RFC8126" class="xref">RFC8126</a>]</span>.<a href="#section-7-2" class="pilcrow">¶</a></p>
<p id="section-7-3">

IANA has marked that assignment as deprecated. IANA may reclaim that 
codepoint at such a time that the registry is depleted.<a href="#section-7-3" class="pilcrow">¶</a></p>
</section>
</div>
<div id="security">
<section id="section-8">
      <h2 id="name-security-considerations">
<a href="#section-8" class="section-number selfRef">8. </a><a href="#name-security-considerations" class="section-name selfRef">Security Considerations</a>
      </h2>
<p id="section-8-1">From a protocol point of view, the mechanisms described in this
      document can leverage the security mechanisms already defined for BGP.
      Further discussion of security considerations for BGP may be found in
      the BGP specification itself (<span>[<a href="#RFC4271" class="xref">RFC4271</a>]</span>)
      and in the security analysis for BGP (<span>[<a href="#RFC4272" class="xref">RFC4272</a>]</span>).  The original discussion of the use of the TCP MD5
      signature option to protect BGP sessions is found in <span>[<a href="#RFC5925" class="xref">RFC5925</a>]</span>, while <span>[<a href="#RFC6952" class="xref">RFC6952</a>]</span> includes an analysis of BGP keying and authentication
      issues.<a href="#section-8-1" class="pilcrow">¶</a></p>
<p id="section-8-2">The mechanisms described in this document involve sharing routing or
      reachability information between sites, which may mean disclosing
      information that is normally contained within a site.  So it needs to be
      understood that normal security paradigms based on the boundaries of
      sites are weakened and interception of BGP messages may result in
      information being disclosed to third parties.  Discussion of these
      issues with respect to VPNs can be found in <span>[<a href="#RFC4364" class="xref">RFC4364</a>]</span>, while <span>[<a href="#RFC7926" class="xref">RFC7926</a>]</span>
      describes many of the issues associated with the exchange of topology or
      TE information between sites.<a href="#section-8-2" class="pilcrow">¶</a></p>
<p id="section-8-3">Particular exposures resulting from this work include:<a href="#section-8-3" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-8-4.1">Gateways to a site will know about all other gateways to the same
        site.  This feature applies within a site, so it is not a substantial
        exposure, but it does mean that if the BGP exchanges within a site can
        be snooped or if a gateway can be subverted, then an attacker may learn
        the full set of gateways to a site.  This would facilitate more
        effective attacks on that site.<a href="#section-8-4.1" class="pilcrow">¶</a>
</li>
        <li class="normal" id="section-8-4.2">The existence of multiple gateways to a site becomes more visible
        across the backbone and even into remote sites.  This means that an
        attacker is able to prepare a more comprehensive attack than exists
        when only the locally attached backbone network (e.g., the AS that
        hosts the site) can see all of the gateways to a site.  For example, a
        Denial-of-Service attack on a single GW is mitigated by the existence
        of other GWs, but if the attacker knows about all the gateways, then
        the whole set can be attacked at once.<a href="#section-8-4.2" class="pilcrow">¶</a>
</li>
        <li class="normal" id="section-8-4.3">A node in a site that does not have external BGP peering (i.e., is
        not really a site gateway and cannot speak BGP into the backbone
        network) may be able to get itself advertised as a gateway by letting
        other genuine gateways discover it (by speaking BGP to them within the
        site), so it may get those genuine gateways to advertise it as a
        gateway into the backbone network.  This would allow the malicious
        node to attract traffic without having to have secure BGP peerings
        with out-of-site nodes.<a href="#section-8-4.3" class="pilcrow">¶</a>
</li>
        <li class="normal" id="section-8-4.4">An external party intercepting BGP messages anywhere between sites
        may learn information about the functioning of the sites and the
        locations of endpoints.  While this is not necessarily a significant
        security or privacy risk, it is possible that the disclosure of this
        information could be used by an attacker.<a href="#section-8-4.4" class="pilcrow">¶</a>
</li>
        <li class="normal" id="section-8-4.5">If it is possible to modify a BGP message within the backbone, it
        may be possible to spoof the existence of a gateway.  This could cause
        traffic to be attracted to a specific node and might result in traffic
        not being delivered.<a href="#section-8-4.5" class="pilcrow">¶</a>
</li>
      </ul>
<p id="section-8-5">All of the issues in the list above could cause disruption to site
      interconnection, but they are not new protocol vulnerabilities so much
      as new exposures of information that <span class="bcp14">SHOULD</span> be protected
      against using existing protocol mechanisms such as securing the TCP
      sessions over which the BGP messages flow.  Furthermore, it is a general
      observation that if these attacks are possible, then it is highly likely
      that far more significant attacks can be made on the routing system.  It
      should be noted that BGP peerings are not discovered but always arise
      from explicit configuration.<a href="#section-8-5" class="pilcrow">¶</a></p>
<p id="section-8-6">Given that the gateways and ASBRs are connected by tunnels that may
      run across parts of the network that are not trusted, data center
      operators using the approach set out in this network <span class="bcp14">MUST</span>
      consider using gateway-to-gateway encryption to protect the data center
      traffic.  Additionally, due consideration <span class="bcp14">MUST</span> be given
      to encrypting end-to-end traffic as it would be for any traffic that
      uses a public or untrusted network for transport.<a href="#section-8-6" class="pilcrow">¶</a></p>
</section>
</div>
<div id="manageability">
<section id="section-9">
      <h2 id="name-manageability-consideration">
<a href="#section-9" class="section-number selfRef">9. </a><a href="#name-manageability-consideration" class="section-name selfRef">Manageability Considerations</a>
      </h2>
<p id="section-9-1">The principal configuration item added by this solution is the
      allocation of a site identifier.  The same identifier
      <span class="bcp14">MUST</span> be assigned to every GW to the same site, and each
      site <span class="bcp14">MUST</span> have a different identifier.  This requires
      coordination, probably through a central management agent.<a href="#section-9-1" class="pilcrow">¶</a></p>
<p id="section-9-2">It should be noted that BGP peerings are not discovered but always
      arise from explicit configuration.  This is no different from any other
      BGP operation.<a href="#section-9-2" class="pilcrow">¶</a></p>
<p id="section-9-3">The site identifiers that are configured and carried in route targets
      (see <a href="#DCGWautodisco" class="xref">Section 3</a>) are an important
      feature to ensure that all of the gateways to a site discover each
      other.  Therefore, it is important that this value is not misconfigured
      since that would result in the gateways not discovering each other and
      not advertising each other.<a href="#section-9-3" class="pilcrow">¶</a></p>
<div id="rtc">
<section id="section-9.1">
        <h3 id="name-relationship-to-route-targe">
<a href="#section-9.1" class="section-number selfRef">9.1. </a><a href="#name-relationship-to-route-targe" class="section-name selfRef">Relationship to Route Target Constraint</a>
        </h3>
<p id="section-9.1-1">

 In order to limit the VPN routing information that is maintained at a given
 route reflector, <span>[<a href="#RFC4364" class="xref">RFC4364</a>]</span> suggests that route reflectors use
 "Cooperative Route Filtering", which was renamed "Outbound Route Filtering"
 and defined in <span>[<a href="#RFC5291" class="xref">RFC5291</a>]</span>.


<span>[<a href="#RFC4684" class="xref">RFC4684</a>]</span> defines an extension to that
        mechanism to include support for multiple autonomous systems and
        asymmetric VPN topologies such as hub-and-spoke.  The mechanism in RFC
        4684 is known as Route Target Constraint (RTC).<a href="#section-9.1-1" class="pilcrow">¶</a></p>
<p id="section-9.1-2">An operator would not normally configure RTC by default for any
        AFI/SAFI combination and would only enable it after careful
        consideration.  When using the mechanisms defined in this document,
        the operator should carefully consider the effects of filtering
        routes.  In some cases, this may be desirable, and in others, it could
        limit the effectiveness of the procedures.<a href="#section-9.1-2" class="pilcrow">¶</a></p>
</section>
</div>
</section>
</div>
<section id="section-10">
      <h2 id="name-references">
<a href="#section-10" class="section-number selfRef">10. </a><a href="#name-references" class="section-name selfRef">References</a>
      </h2>
<section id="section-10.1">
        <h3 id="name-normative-references">
<a href="#section-10.1" class="section-number selfRef">10.1. </a><a href="#name-normative-references" class="section-name selfRef">Normative References</a>
        </h3>
<dl class="references">
<dt id="RFC2119">[RFC2119]</dt>
        <dd>
<span class="refAuthor">Bradner, S.</span>, <span class="refTitle">"Key words for use in RFCs to Indicate Requirement Levels"</span>, <span class="seriesInfo">BCP 14</span>, <span class="seriesInfo">RFC 2119</span>, <span class="seriesInfo">DOI 10.17487/RFC2119</span>, <time datetime="1997-03" class="refDate">March 1997</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc2119">https://www.rfc-editor.org/info/rfc2119</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC4271">[RFC4271]</dt>
        <dd>
<span class="refAuthor">Rekhter, Y., Ed.</span>, <span class="refAuthor">Li, T., Ed.</span>, and <span class="refAuthor">S. Hares, Ed.</span>, <span class="refTitle">"A Border Gateway Protocol 4 (BGP-4)"</span>, <span class="seriesInfo">RFC 4271</span>, <span class="seriesInfo">DOI 10.17487/RFC4271</span>, <time datetime="2006-01" class="refDate">January 2006</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc4271">https://www.rfc-editor.org/info/rfc4271</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC4360">[RFC4360]</dt>
        <dd>
<span class="refAuthor">Sangli, S.</span>, <span class="refAuthor">Tappan, D.</span>, and <span class="refAuthor">Y. Rekhter</span>, <span class="refTitle">"BGP Extended Communities Attribute"</span>, <span class="seriesInfo">RFC 4360</span>, <span class="seriesInfo">DOI 10.17487/RFC4360</span>, <time datetime="2006-02" class="refDate">February 2006</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc4360">https://www.rfc-editor.org/info/rfc4360</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC4760">[RFC4760]</dt>
        <dd>
<span class="refAuthor">Bates, T.</span>, <span class="refAuthor">Chandra, R.</span>, <span class="refAuthor">Katz, D.</span>, and <span class="refAuthor">Y. Rekhter</span>, <span class="refTitle">"Multiprotocol Extensions for BGP-4"</span>, <span class="seriesInfo">RFC 4760</span>, <span class="seriesInfo">DOI 10.17487/RFC4760</span>, <time datetime="2007-01" class="refDate">January 2007</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc4760">https://www.rfc-editor.org/info/rfc4760</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC5925">[RFC5925]</dt>
        <dd>
<span class="refAuthor">Touch, J.</span>, <span class="refAuthor">Mankin, A.</span>, and <span class="refAuthor">R. Bonica</span>, <span class="refTitle">"The TCP Authentication Option"</span>, <span class="seriesInfo">RFC 5925</span>, <span class="seriesInfo">DOI 10.17487/RFC5925</span>, <time datetime="2010-06" class="refDate">June 2010</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc5925">https://www.rfc-editor.org/info/rfc5925</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC7752">[RFC7752]</dt>
        <dd>
<span class="refAuthor">Gredler, H., Ed.</span>, <span class="refAuthor">Medved, J.</span>, <span class="refAuthor">Previdi, S.</span>, <span class="refAuthor">Farrel, A.</span>, and <span class="refAuthor">S. Ray</span>, <span class="refTitle">"North-Bound Distribution of Link-State and Traffic Engineering (TE) Information Using BGP"</span>, <span class="seriesInfo">RFC 7752</span>, <span class="seriesInfo">DOI 10.17487/RFC7752</span>, <time datetime="2016-03" class="refDate">March 2016</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc7752">https://www.rfc-editor.org/info/rfc7752</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC8174">[RFC8174]</dt>
        <dd>
<span class="refAuthor">Leiba, B.</span>, <span class="refTitle">"Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words"</span>, <span class="seriesInfo">BCP 14</span>, <span class="seriesInfo">RFC 8174</span>, <span class="seriesInfo">DOI 10.17487/RFC8174</span>, <time datetime="2017-05" class="refDate">May 2017</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8174">https://www.rfc-editor.org/info/rfc8174</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC9012">[RFC9012]</dt>
      <dd>
<span class="refAuthor">Patel, K.</span>, <span class="refAuthor">Van de Velde, G.</span>, <span class="refAuthor">Sangli, S.</span>, and <span class="refAuthor">J. Scudder</span>, <span class="refTitle">"The BGP Tunnel Encapsulation Attribute"</span>, <span class="seriesInfo">RFC 9012</span>, <span class="seriesInfo">DOI 10.17487/RFC9012</span>, <time datetime="2021-04" class="refDate">April 2021</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc9012">https://www.rfc-editor.org/info/rfc9012</a>&gt;</span>. </dd>
<dd class="break"></dd>
</dl>
</section>
<section id="section-10.2">
        <h3 id="name-informative-references">
<a href="#section-10.2" class="section-number selfRef">10.2. </a><a href="#name-informative-references" class="section-name selfRef">Informative References</a>
        </h3>
<dl class="references">
<dt id="RFC4272">[RFC4272]</dt>
        <dd>
<span class="refAuthor">Murphy, S.</span>, <span class="refTitle">"BGP Security Vulnerabilities Analysis"</span>, <span class="seriesInfo">RFC 4272</span>, <span class="seriesInfo">DOI 10.17487/RFC4272</span>, <time datetime="2006-01" class="refDate">January 2006</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc4272">https://www.rfc-editor.org/info/rfc4272</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC4364">[RFC4364]</dt>
        <dd>
<span class="refAuthor">Rosen, E.</span> and <span class="refAuthor">Y. Rekhter</span>, <span class="refTitle">"BGP/MPLS IP Virtual Private Networks (VPNs)"</span>, <span class="seriesInfo">RFC 4364</span>, <span class="seriesInfo">DOI 10.17487/RFC4364</span>, <time datetime="2006-02" class="refDate">February 2006</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc4364">https://www.rfc-editor.org/info/rfc4364</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC4684">[RFC4684]</dt>
        <dd>
<span class="refAuthor">Marques, P.</span>, <span class="refAuthor">Bonica, R.</span>, <span class="refAuthor">Fang, L.</span>, <span class="refAuthor">Martini, L.</span>, <span class="refAuthor">Raszuk, R.</span>, <span class="refAuthor">Patel, K.</span>, and <span class="refAuthor">J. Guichard</span>, <span class="refTitle">"Constrained Route Distribution for Border Gateway Protocol/MultiProtocol Label Switching (BGP/MPLS) Internet Protocol (IP) Virtual Private Networks (VPNs)"</span>, <span class="seriesInfo">RFC 4684</span>, <span class="seriesInfo">DOI 10.17487/RFC4684</span>, <time datetime="2006-11" class="refDate">November 2006</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc4684">https://www.rfc-editor.org/info/rfc4684</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC5291">[RFC5291]</dt>
        <dd>
<span class="refAuthor">Chen, E.</span> and <span class="refAuthor">Y. Rekhter</span>, <span class="refTitle">"Outbound Route Filtering Capability for BGP-4"</span>, <span class="seriesInfo">RFC 5291</span>, <span class="seriesInfo">DOI 10.17487/RFC5291</span>, <time datetime="2008-08" class="refDate">August 2008</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc5291">https://www.rfc-editor.org/info/rfc5291</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC6952">[RFC6952]</dt>
        <dd>
<span class="refAuthor">Jethanandani, M.</span>, <span class="refAuthor">Patel, K.</span>, and <span class="refAuthor">L. Zheng</span>, <span class="refTitle">"Analysis of BGP, LDP, PCEP, and MSDP Issues According to the Keying and Authentication for Routing Protocols (KARP) Design Guide"</span>, <span class="seriesInfo">RFC 6952</span>, <span class="seriesInfo">DOI 10.17487/RFC6952</span>, <time datetime="2013-05" class="refDate">May 2013</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc6952">https://www.rfc-editor.org/info/rfc6952</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC7911">[RFC7911]</dt>
        <dd>
<span class="refAuthor">Walton, D.</span>, <span class="refAuthor">Retana, A.</span>, <span class="refAuthor">Chen, E.</span>, and <span class="refAuthor">J. Scudder</span>, <span class="refTitle">"Advertisement of Multiple Paths in BGP"</span>, <span class="seriesInfo">RFC 7911</span>, <span class="seriesInfo">DOI 10.17487/RFC7911</span>, <time datetime="2016-07" class="refDate">July 2016</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc7911">https://www.rfc-editor.org/info/rfc7911</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC7926">[RFC7926]</dt>
        <dd>
<span class="refAuthor">Farrel, A., Ed.</span>, <span class="refAuthor">Drake, J.</span>, <span class="refAuthor">Bitar, N.</span>, <span class="refAuthor">Swallow, G.</span>, <span class="refAuthor">Ceccarelli, D.</span>, and <span class="refAuthor">X. Zhang</span>, <span class="refTitle">"Problem Statement and Architecture for Information Exchange between Interconnected Traffic-Engineered Networks"</span>, <span class="seriesInfo">BCP 206</span>, <span class="seriesInfo">RFC 7926</span>, <span class="seriesInfo">DOI 10.17487/RFC7926</span>, <time datetime="2016-07" class="refDate">July 2016</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc7926">https://www.rfc-editor.org/info/rfc7926</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC8126">[RFC8126]</dt>
        <dd>
<span class="refAuthor">Cotton, M.</span>, <span class="refAuthor">Leiba, B.</span>, and <span class="refAuthor">T. Narten</span>, <span class="refTitle">"Guidelines for Writing an IANA Considerations Section in RFCs"</span>, <span class="seriesInfo">BCP 26</span>, <span class="seriesInfo">RFC 8126</span>, <span class="seriesInfo">DOI 10.17487/RFC8126</span>, <time datetime="2017-06" class="refDate">June 2017</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8126">https://www.rfc-editor.org/info/rfc8126</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC8402">[RFC8402]</dt>
        <dd>
<span class="refAuthor">Filsfils, C., Ed.</span>, <span class="refAuthor">Previdi, S., Ed.</span>, <span class="refAuthor">Ginsberg, L.</span>, <span class="refAuthor">Decraene, B.</span>, <span class="refAuthor">Litkowski, S.</span>, and <span class="refAuthor">R. Shakir</span>, <span class="refTitle">"Segment Routing Architecture"</span>, <span class="seriesInfo">RFC 8402</span>, <span class="seriesInfo">DOI 10.17487/RFC8402</span>, <time datetime="2018-07" class="refDate">July 2018</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8402">https://www.rfc-editor.org/info/rfc8402</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC9085">[RFC9085]</dt>
        <dd>
<span class="refAuthor">Previdi, S.</span>, <span class="refAuthor">Talaulikar, K., Ed.</span>, <span class="refAuthor">Filsfils, C.</span>, <span class="refAuthor">Gredler, H.</span>, and <span class="refAuthor">M. Chen</span>, <span class="refTitle">"Border Gateway Protocol - Link State (BGP-LS) Extensions for Segment Routing"</span>, <span class="seriesInfo">RFC 9085</span>, <span class="seriesInfo">DOI 10.17487/RFC9085</span>, <time datetime="2021-08" class="refDate">August 2021</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc9085">https://www.rfc-editor.org/info/rfc9085</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC9086">[RFC9086]</dt>
        <dd>
<span class="refAuthor">Previdi, S.</span>, <span class="refAuthor">Talaulikar, K., Ed.</span>, <span class="refAuthor">Filsfils, C.</span>, <span class="refAuthor">Patel, K.</span>, <span class="refAuthor">Ray, S.</span>, and <span class="refAuthor">J. Dong</span>, <span class="refTitle">"Border Gateway Protocol - Link State (BGP-LS) Extensions for Segment Routing BGP Egress Peer Engineering"</span>, <span class="seriesInfo">RFC 9086</span>, <span class="seriesInfo">DOI 10.17487/RFC9086</span>, <time datetime="2021-08" class="refDate">August 2021</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc9086">https://www.rfc-editor.org/info/rfc9086</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="I-D.farrel-spring-sr-domain-interconnect">[SR-INTERCONNECT]</dt>
      <dd>
<span class="refAuthor">Farrel, A.</span> and <span class="refAuthor">J. Drake</span>, <span class="refTitle">"Interconnection of Segment Routing Sites - Problem Statement and Solution Landscape"</span>, <span class="refContent">Work in Progress</span>, <span class="seriesInfo">Internet-Draft, draft-farrel-spring-sr-domain-interconnect-06</span>, <time datetime="2021-05-19" class="refDate">19 May 2021</time>, <span>&lt;<a href="https://datatracker.ietf.org/doc/html/draft-farrel-spring-sr-domain-interconnect-06">https://datatracker.ietf.org/doc/html/draft-farrel-spring-sr-domain-interconnect-06</a>&gt;</span>. </dd>
<dd class="break"></dd>
</dl>
</section>
</section>
<div id="acks">
<section id="appendix-A">
      <h2 id="name-acknowledgements">
<a href="#name-acknowledgements" class="section-name selfRef">Acknowledgements</a>
      </h2>
<p id="appendix-A-1">Thanks to <span class="contact-name">Bruno Rijsman</span>, <span class="contact-name">Stephane Litkowski</span>, <span class="contact-name">Boris Hassanov</span>,
      <span class="contact-name">Linda Dunbar</span>, <span class="contact-name">Ravi Singh</span>,
      and <span class="contact-name">Daniel Migault</span> for review comments, and to
      <span class="contact-name">Robert Raszuk</span> for useful discussions.  <span class="contact-name">Gyan Mishra</span> provided a helpful GenArt review, and <span class="contact-name">John Scudder</span> and <span class="contact-name">Benjamin Kaduk</span> made
      helpful comments during IESG review.<a href="#appendix-A-1" class="pilcrow">¶</a></p>
</section>
</div>
<div id="authors-addresses">
<section id="appendix-B">
      <h2 id="name-authors-addresses">
<a href="#name-authors-addresses" class="section-name selfRef">Authors' Addresses</a>
      </h2>
<address class="vcard">
        <div dir="auto" class="left"><span class="fn nameRole">Adrian Farrel</span></div>
<div dir="auto" class="left"><span class="org">Old Dog Consulting</span></div>
<div class="email">
<span>Email:</span>
<a href="mailto:adrian@olddog.co.uk" class="email">adrian@olddog.co.uk</a>
</div>
</address>
<address class="vcard">
        <div dir="auto" class="left"><span class="fn nameRole">John Drake</span></div>
<div dir="auto" class="left"><span class="org">Juniper Networks</span></div>
<div class="email">
<span>Email:</span>
<a href="mailto:jdrake@juniper.net" class="email">jdrake@juniper.net</a>
</div>
</address>
<address class="vcard">
        <div dir="auto" class="left"><span class="fn nameRole">Eric Rosen</span></div>
<div dir="auto" class="left"><span class="org">Juniper Networks</span></div>
<div class="email">
<span>Email:</span>
<a href="mailto:erosen52@gmail.com" class="email">erosen52@gmail.com</a>
</div>
</address>
<address class="vcard">
        <div dir="auto" class="left"><span class="fn nameRole">Keyur Patel</span></div>
<div dir="auto" class="left"><span class="org">Arrcus, Inc.</span></div>
<div class="email">
<span>Email:</span>
<a href="mailto:keyur@arrcus.com" class="email">keyur@arrcus.com</a>
</div>
</address>
<address class="vcard">
        <div dir="auto" class="left"><span class="fn nameRole">Luay Jalil</span></div>
<div dir="auto" class="left"><span class="org">Verizon</span></div>
<div class="email">
<span>Email:</span>
<a href="mailto:luay.jalil@verizon.com" class="email">luay.jalil@verizon.com</a>
</div>
</address>
</section>
</div>
<script>const toc = document.getElementById("toc");
toc.querySelector("h2").addEventListener("click", e => {
  toc.classList.toggle("active");
});
toc.querySelector("nav").addEventListener("click", e => {
  toc.classList.remove("active");
});
</script>
</body>
</html>