File: rfc9107.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 (1790 lines) | stat: -rw-r--r-- 69,383 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 9107: BGP Optimal Route Reflection (BGP ORR)</title>
<meta content="Robert Raszuk" name="author">
<meta content="Bruno Decraene" name="author">
<meta content="Christian Cassar" name="author">
<meta content="Erik Åman" name="author">
<meta content="Kevin Wang" name="author">
<meta content="
       This document defines an extension to BGP route reflectors. On route reflectors, 
BGP route selection is modified in order to choose the best route from the standpoint 
of their clients, rather than from the standpoint of the route reflectors themselves. Depending 
on the scaling and precision requirements, route selection can be specific for one 
client, common for a set of clients, or common for all clients of a route reflector. 
This solution is particularly applicable in deployments using centralized route 
reflectors, where choosing the best route based on the route reflector's IGP location 
is suboptimal. This  facilitates, for example, a &quot;best exit point&quot; policy (&quot;hot potato 
routing&quot;). 
       The solution relies upon all route reflectors learning all paths that 
are eligible for consideration. BGP route selection is performed in the route 
reflectors based on the IGP cost from configured locations in the link-state IGP. 
    " name="description">
<meta content="xml2rfc 3.9.1" name="generator">
<meta content="IDR" name="keyword">
<meta content="9107" 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="rfc9107.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/rfc9107" rel="alternate">
  <link href="urn:issn:2070-1721" rel="alternate">
  <link href="https://datatracker.ietf.org/doc/draft-ietf-idr-bgp-optimal-route-reflection-28" 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 9107</td>
<td class="center">BGP Optimal Route Reflection</td>
<td class="right">August 2021</td>
</tr></thead>
<tfoot><tr>
<td class="left">Raszuk, 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/rfc9107" class="eref">9107</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">R. Raszuk, <span class="editor">Ed.</span>
</div>
<div class="org">NTT Network Innovations</div>
</div>
<div class="author">
      <div class="author-name">B. Decraene, <span class="editor">Ed.</span>
</div>
<div class="org">Orange</div>
</div>
<div class="author">
      <div class="author-name">C. Cassar</div>
</div>
<div class="author">
      <div class="author-name">E. Åman</div>
</div>
<div class="author">
      <div class="author-name">K. Wang</div>
<div class="org">Juniper Networks</div>
</div>
</dd>
</dl>
</div>
<h1 id="rfcnum">RFC 9107</h1>
<h1 id="title">BGP Optimal Route Reflection (BGP ORR)</h1>
<section id="section-abstract">
      <h2 id="abstract"><a href="#abstract" class="selfRef">Abstract</a></h2>
<p id="section-abstract-1">This document defines an extension to BGP route reflectors. On route reflectors, 
BGP route selection is modified in order to choose the best route from the standpoint 
of their clients, rather than from the standpoint of the route reflectors themselves. Depending 
on the scaling and precision requirements, route selection can be specific for one 
client, common for a set of clients, or common for all clients of a route reflector. 
This solution is particularly applicable in deployments using centralized route 
reflectors, where choosing the best route based on the route reflector's IGP location 
is suboptimal. This  facilitates, for example, a "best exit point" policy ("hot potato 
routing").<a href="#section-abstract-1" class="pilcrow">¶</a></p>
<p id="section-abstract-2">The solution relies upon all route reflectors learning all paths that 
are eligible for consideration. BGP route selection is performed in the route 
reflectors based on the IGP cost from configured locations in the link-state IGP.<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/rfc9107">https://www.rfc-editor.org/info/rfc9107</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 ulBare ulEmpty compact">
<li class="toc ulBare ulEmpty compact" id="section-toc.1-1.1">
            <p id="section-toc.1-1.1.1" class="keepWithNext"><a href="#section-1" class="xref">1</a>.  <a href="#name-introduction" class="xref">Introduction</a></p>
</li>
          <li class="toc ulBare ulEmpty compact" 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-terminology" class="xref">Terminology</a></p>
</li>
          <li class="toc ulBare ulEmpty compact" id="section-toc.1-1.3">
            <p id="section-toc.1-1.3.1"><a href="#section-3" class="xref">3</a>.  <a href="#name-modifications-to-bgp-route-" class="xref">Modifications to BGP Route Selection</a></p>
<ul class="toc compact ulBare ulEmpty">
<li class="toc compact ulBare ulEmpty" id="section-toc.1-1.3.2.1">
                <p id="section-toc.1-1.3.2.1.1"><a href="#section-3.1" class="xref">3.1</a>.  <a href="#name-route-selection-from-a-diff" class="xref">Route Selection from a Different IGP Location</a></p>
<ul class="toc compact ulBare ulEmpty">
<li class="toc compact ulBare ulEmpty" id="section-toc.1-1.3.2.1.2.1">
                    <p id="section-toc.1-1.3.2.1.2.1.1" class="keepWithNext"><a href="#section-3.1.1" class="xref">3.1.1</a>.  <a href="#name-restriction-when-the-bgp-ne" class="xref">Restriction when the BGP Next Hop Is a BGP Route</a></p>
</li>
                </ul>
</li>
              <li class="toc compact ulBare ulEmpty" id="section-toc.1-1.3.2.2">
                <p id="section-toc.1-1.3.2.2.1"><a href="#section-3.2" class="xref">3.2</a>.  <a href="#name-multiple-route-selections" class="xref">Multiple Route Selections</a></p>
</li>
            </ul>
</li>
          <li class="toc ulBare ulEmpty compact" id="section-toc.1-1.4">
            <p id="section-toc.1-1.4.1"><a href="#section-4" class="xref">4</a>.  <a href="#name-deployment-considerations" class="xref">Deployment Considerations</a></p>
</li>
          <li class="toc ulBare ulEmpty compact" id="section-toc.1-1.5">
            <p id="section-toc.1-1.5.1"><a href="#section-5" class="xref">5</a>.  <a href="#name-security-considerations" class="xref">Security Considerations</a></p>
</li>
          <li class="toc ulBare ulEmpty compact" id="section-toc.1-1.6">
            <p id="section-toc.1-1.6.1"><a href="#section-6" class="xref">6</a>.  <a href="#name-iana-considerations" class="xref">IANA Considerations</a></p>
</li>
          <li class="toc ulBare ulEmpty compact" id="section-toc.1-1.7">
            <p id="section-toc.1-1.7.1"><a href="#section-7" class="xref">7</a>.  <a href="#name-references" class="xref">References</a></p>
<ul class="toc compact ulBare ulEmpty">
<li class="toc compact ulBare 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-normative-references" class="xref">Normative References</a></p>
</li>
              <li class="toc compact ulBare 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-informative-references" class="xref">Informative References</a></p>
</li>
            </ul>
</li>
          <li class="toc ulBare ulEmpty compact" id="section-toc.1-1.8">
            <p id="section-toc.1-1.8.1"><a href="#appendix-A" class="xref"></a><a href="#name-acknowledgments" class="xref">Acknowledgments</a></p>
</li>
          <li class="toc ulBare ulEmpty compact" id="section-toc.1-1.9">
            <p id="section-toc.1-1.9.1"><a href="#appendix-B" class="xref"></a><a href="#name-contributors" class="xref">Contributors</a></p>
</li>
          <li class="toc ulBare ulEmpty compact" id="section-toc.1-1.10">
            <p id="section-toc.1-1.10.1"><a href="#appendix-C" class="xref"></a><a href="#name-authors-addresses" class="xref">Authors' Addresses</a></p>
</li>
        </ul>
</nav>
</section>
</div>
<section id="section-1">
      <h2 id="name-introduction">
<a href="#section-1" class="section-number selfRef">1. </a><a href="#name-introduction" class="section-name selfRef">Introduction</a>
      </h2>
<p id="section-1-1">There are three types of BGP deployments within Autonomous Systems (ASes) today: full mesh, 
confederations, and route reflection. BGP route reflection <span>[<a href="#RFC4456" class="xref">RFC4456</a>]</span> is 
the most popular way to distribute BGP routes between BGP speakers belonging to the same 
AS. However, in some situations, this method suffers from non-optimal 
path selection.<a href="#section-1-1" class="pilcrow">¶</a></p>
<p id="section-1-2"> <span>[<a href="#RFC4456" class="xref">RFC4456</a>]</span> asserts that, because the IGP cost to a given point in 
the network will vary across routers,
 "the route reflection approach may not yield the 
same route selection result as that of the full IBGP mesh approach." ("IBGP" stands for "Internal BGP".) One 
practical implication of this fact is that the deployment of route reflection may thwart 
the ability to achieve "hot potato routing". Hot potato routing attempts to direct traffic to the closest AS exit point in cases where no higher-priority policy 
dictates otherwise. As a consequence of the route reflection method, the choice of exit 
point for a route reflector and its clients will be the exit point that is optimal for 
the route reflector -- not necessarily the one that is optimal for its clients.<a href="#section-1-2" class="pilcrow">¶</a></p>
<p id="section-1-3"><span><a href="https://www.rfc-editor.org/rfc/rfc4456#section-11" class="relref">Section 11</a> of [<a href="#RFC4456" class="xref">RFC4456</a>]</span> describes a deployment approach and a set 
of constraints that, if satisfied, would result in the deployment of route reflection 
yielding the same results as the IBGP full mesh approach. This deployment approach makes 
route reflection compatible with the application of a hot potato routing policy. In 
accordance with these design rules, route reflectors have often been deployed in the 
forwarding path and carefully placed on the boundaries between the Point of Presence (POP) and the network core.<a href="#section-1-3" class="pilcrow">¶</a></p>
<p id="section-1-4">The evolving model of intra-domain network design has enabled deployments of route 
reflectors outside the forwarding path. Initially, this model was only employed for new 
services, e.g., IP VPNs <span>[<a href="#RFC4364" class="xref">RFC4364</a>]</span>; however, it has been gradually 
extended to other BGP services, including the IPv4 and IPv6 Internet. In such 
environments, a hot potato routing policy remains desirable.<a href="#section-1-4" class="pilcrow">¶</a></p>
<p id="section-1-5">Route reflectors outside the forwarding path can be placed on the boundaries between the POP and the network core, 
but they are often placed in arbitrary locations in the core of large 
networks.<a href="#section-1-5" class="pilcrow">¶</a></p>
<p id="section-1-6">Such deployments suffer from a critical drawback in the context of BGP route selection: 
a route reflector with knowledge of multiple paths for a given route will typically pick 
its best path and only advertise that best path to its clients. If the best path for a 
route is selected on the basis of an IGP tie-break, the path advertised will be the exit 
point closest to the route reflector. However, the clients are in a different place in 
the network topology than the route reflector. In networks where the route reflectors are 
not in the forwarding path, this difference will be even more acute.<a href="#section-1-6" class="pilcrow">¶</a></p>
<p id="section-1-7">In addition, there are deployment scenarios where service providers want to have more 
control in choosing the exit points for clients based on other factors, such as traffic 
type, traffic load, etc. This further complicates the issue and makes it less likely for 
the route reflector to select the best path from the client's perspective. It follows 
that the best path chosen by the route reflector is not necessarily the same as the path 
that would have been chosen by the client if the client had considered the same set of 
candidate paths as the route reflector.<a href="#section-1-7" class="pilcrow">¶</a></p>
</section>
<section id="section-2">
      <h2 id="name-terminology">
<a href="#section-2" class="section-number selfRef">2. </a><a href="#name-terminology" class="section-name selfRef">Terminology</a>
      </h2>
<p id="section-2-1">This memo makes use of the terms defined in <span>[<a href="#RFC4271" class="xref">RFC4271</a>]</span> and <span>[<a href="#RFC4456" class="xref">RFC4456</a>]</span>.<a href="#section-2-1" class="pilcrow">¶</a></p>
<p id="section-2-2">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-2" class="pilcrow">¶</a></p>
</section>
<section id="section-3">
      <h2 id="name-modifications-to-bgp-route-">
<a href="#section-3" class="section-number selfRef">3. </a><a href="#name-modifications-to-bgp-route-" class="section-name selfRef">Modifications to BGP Route Selection</a>
      </h2>
<p id="section-3-1">The core of this solution is the ability for an operator to specify the IGP location 
for which the route reflector calculates interior cost to the next hop. The IGP 
location is defined as a node in the IGP topology, it is identified by an IP address 
of this node (e.g., a loopback address), and it may be configured on a
per-route-reflector basis, per set of clients, or on a per-client basis. Such configuration will allow the 
route reflector to select and distribute to a given set of clients routes with the shortest 
distance to the next hops from the position of the selected IGP location. This provides 
for freedom related to the route reflector's physical location and allows transient or permanent 
migration of this network control plane function to an arbitrary location with no 
impact on IP transit.<a href="#section-3-1" class="pilcrow">¶</a></p>
<p id="section-3-2">The choice of specific granularity (route reflector, set of clients, or client) is 
configured by the network operator. An implementation is considered compliant with this 
document if it supports at least one such grouping category.<a href="#section-3-2" class="pilcrow">¶</a></p>
<p id="section-3-3"> For purposes of route selection, the perspective of a client can differ from that of
a route reflector or another client in two distinct ways:<a href="#section-3-3" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-3-4.1">It has a different position in the IGP topology.<a href="#section-3-4.1" class="pilcrow">¶</a>
</li>
        <li class="normal" id="section-3-4.2">It can have a different routing policy.<a href="#section-3-4.2" class="pilcrow">¶</a>
</li>
      </ul>
<p id="section-3-5">
These factors correspond to the issues described earlier.<a href="#section-3-5" class="pilcrow">¶</a></p>
<p id="section-3-6">This document defines, for BGP route reflectors <span>[<a href="#RFC4456" class="xref">RFC4456</a>]</span>, two changes 
to the BGP route selection algorithm:<a href="#section-3-6" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-3-7.1">The first change, introduced in <a href="#sec_IGP_cost" class="xref">Section 3.1</a>, is related to the IGP 
cost to the BGP next hop in the BGP Decision Process. The change consists of using the IGP 
cost from a different IGP location than the route reflector itself.<a href="#section-3-7.1" class="pilcrow">¶</a>
</li>
        <li class="normal" id="section-3-7.2">The second change, introduced in <a href="#sec_multiple" class="xref">Section 3.2</a>, is to extend the 
granularity of the BGP Decision Process, to allow for running multiple Decision Processes 
using different perspectives or policies.<a href="#section-3-7.2" class="pilcrow">¶</a>
</li>
      </ul>
<p id="section-3-8"> A route reflector can implement either or both of the modifications in order to 
allow it to choose the best path for its clients that the clients themselves would have
chosen given the same set of candidate paths.<a href="#section-3-8" class="pilcrow">¶</a></p>
<p id="section-3-9">A significant advantage of these approaches is that the route reflector's clients do 
not need to be modified.<a href="#section-3-9" class="pilcrow">¶</a></p>
<div id="sec_IGP_cost">
<section id="section-3.1">
        <h3 id="name-route-selection-from-a-diff">
<a href="#section-3.1" class="section-number selfRef">3.1. </a><a href="#name-route-selection-from-a-diff" class="section-name selfRef">Route Selection from a Different IGP Location</a>
        </h3>
<p id="section-3.1-1">In this approach, "optimal" refers to the decision where the interior cost of a route is 
determined during step e) of Section <span><a href="https://www.rfc-editor.org/rfc/rfc4271#section-9.1.2.2" class="relref">9.1.2.2</a> (<a href="https://www.rfc-editor.org/rfc/rfc4271#section-9.1.2.2" class="relref">"Breaking Ties (Phase 2)"</a>)</span> of <span>[<a href="#RFC4271" class="xref">RFC4271</a>]</span>. It does not apply to path selection preference based on other policy steps 
and provisions.<a href="#section-3.1-1" class="pilcrow">¶</a></p>
<p id="section-3.1-2">In addition to the change specified in <span><a href="https://www.rfc-editor.org/rfc/rfc4456#section-9" class="relref">Section 9</a> of [<a href="#RFC4456" class="xref">RFC4456</a>]</span>, the text in step e) in <span><a href="https://www.rfc-editor.org/rfc/rfc4271#section-9.1.2.2" class="relref">Section 9.1.2.2</a> of [<a href="#RFC4271" class="xref">RFC4271</a>]</span> is modified as follows.<a href="#section-3.1-2" class="pilcrow">¶</a></p>
<p id="section-3.1-3">RFC 4271 reads:<a href="#section-3.1-3" class="pilcrow">¶</a></p>
<blockquote id="section-3.1-4">
          <span class="break"></span><dl class="dlParallel" id="section-3.1-4.1">
            <dt id="section-3.1-4.1.1">e)</dt>
            <dd style="margin-left: 2.0em" id="section-3.1-4.1.2">Remove from consideration any routes with less-preferred
         interior cost.  The interior cost of a route is determined by
         calculating the metric to the NEXT_HOP for the route using the
         Routing Table.<a href="#section-3.1-4.1.2" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
</dl>
</blockquote>
<p id="section-3.1-5">This document modifies this text to read:<a href="#section-3.1-5" class="pilcrow">¶</a></p>
<blockquote id="section-3.1-6">
          <span class="break"></span><dl class="dlParallel" id="section-3.1-6.1">
            <dt id="section-3.1-6.1.1">e)</dt>
            <dd style="margin-left: 2.0em" id="section-3.1-6.1.2">Remove from consideration any routes with less-preferred
         interior cost.  The interior cost of a route is determined by
         calculating the metric from the selected IGP location to the NEXT_HOP for the route
         using the shortest IGP path tree rooted at the selected IGP location.<a href="#section-3.1-6.1.2" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
</dl>
</blockquote>
<p id="section-3.1-7">In order to be able to compute the shortest path tree rooted at the selected IGP 
locations, knowledge of the IGP topology for the area/level that includes each of those 
locations is needed. This knowledge can be gained with the use of the link-state IGP,
such as IS-IS <span>[<a href="#ISO10589" class="xref">ISO10589</a>]</span> or OSPF <span>[<a href="#RFC2328" class="xref">RFC2328</a>]</span>
          <span>[<a href="#RFC5340" class="xref">RFC5340</a>]</span>, or via the Border Gateway Protocol - Link State (BGP-LS) <span>[<a href="#RFC7752" class="xref">RFC7752</a>]</span>. When specifying the logical 
location of a route reflector for a group of clients, one or more backup IGP locations 
<span class="bcp14">SHOULD</span> be allowed to be specified for redundancy. Further deployment considerations 
are discussed in <a href="#deployment-cons" class="xref">Section 4</a>.<a href="#section-3.1-7" class="pilcrow">¶</a></p>
<section id="section-3.1.1">
          <h4 id="name-restriction-when-the-bgp-ne">
<a href="#section-3.1.1" class="section-number selfRef">3.1.1. </a><a href="#name-restriction-when-the-bgp-ne" class="section-name selfRef">Restriction when the BGP Next Hop Is a BGP Route</a>
          </h4>
<p id="section-3.1.1-1">In situations where the BGP next hop is a BGP route itself, the IGP metric of a route 
used for its resolution <span class="bcp14">SHOULD</span> be the final IGP cost to reach such a next hop. Implementations 
that cannot inform BGP of the final IGP metric to a recursive next hop <span class="bcp14">MUST</span> treat such 
paths as least preferred during next-hop metric comparisons. However, such paths <span class="bcp14">MUST</span> 
still be considered valid for BGP Phase 2 route selection.<a href="#section-3.1.1-1" class="pilcrow">¶</a></p>
</section>
</section>
</div>
<div id="sec_multiple">
<section id="section-3.2">
        <h3 id="name-multiple-route-selections">
<a href="#section-3.2" class="section-number selfRef">3.2. </a><a href="#name-multiple-route-selections" class="section-name selfRef">Multiple Route Selections</a>
        </h3>
<p id="section-3.2-1">A BGP route reflector as per <span>[<a href="#RFC4456" class="xref">RFC4456</a>]</span> runs a single BGP Decision 
Process. BGP Optimal Route Reflection (BGP ORR) may require multiple BGP Decision Processes or 
subsets of the Decision Process in order to consider different IGP locations or 
BGP policies for different sets of clients. This is very similar to what is defined 
in <span>[<a href="#RFC7947" class="xref">RFC7947</a>], <a href="https://www.rfc-editor.org/rfc/rfc7947#section-2.3.2.1" class="relref">Section 2.3.2.1</a></span>.<a href="#section-3.2-1" class="pilcrow">¶</a></p>
<p id="section-3.2-2"> If the required routing optimization is limited to the IGP cost to the BGP 
next hop, only step e) and subsequent steps as defined in 
<span>[<a href="#RFC4271" class="xref">RFC4271</a>], <a href="https://www.rfc-editor.org/rfc/rfc4271#section-9.1.2.2" class="relref">Section 9.1.2.2</a></span> need to be run multiple times.<a href="#section-3.2-2" class="pilcrow">¶</a></p>
<p id="section-3.2-3"> If the routing optimization requires the use of different BGP policies for 
different sets of clients, a larger part of the Decision Process needs to be run 
multiple times, up to the whole Decision Process as defined in <span><a href="https://www.rfc-editor.org/rfc/rfc4271#section-9.1" class="relref">Section 9.1</a> of [<a href="#RFC4271" class="xref">RFC4271</a>]</span>. This is, for example, the case when there is a need to 
use different policies to compute different degrees of preference during Phase 1. 
This is needed for use cases involving traffic engineering or dedicating certain 
exit points for certain clients. In the latter case, the user may specify and apply 
a general policy on the route reflector for a set of clients. Regular path selection, 
including IGP perspectives for a set of clients as per <a href="#sec_IGP_cost" class="xref">Section 3.1</a>, 
is then applied to the candidate paths to select the final paths to advertise to the 
clients.<a href="#section-3.2-3" class="pilcrow">¶</a></p>
</section>
</div>
</section>
<div id="deployment-cons">
<section id="section-4">
      <h2 id="name-deployment-considerations">
<a href="#section-4" class="section-number selfRef">4. </a><a href="#name-deployment-considerations" class="section-name selfRef">Deployment Considerations</a>
      </h2>
<p id="section-4-1">BGP ORR provides a model for integrating the client's
perspective into the BGP route selection Decision Process for route reflectors. 
More specifically, the choice of BGP path takes into account either the IGP 
cost between the client and the next hop (rather than the IGP cost from the 
route reflector to the next hop) or other user-configured policies.<a href="#section-4-1" class="pilcrow">¶</a></p>
<p id="section-4-2">The achievement of optimal routing between clients of different clusters 
relies upon all route reflectors learning all paths that are eligible for 
consideration. In order to satisfy this requirement, BGP ADD-PATH 
<span>[<a href="#RFC7911" class="xref">RFC7911</a>]</span> needs to be deployed between route reflectors.<a href="#section-4-2" class="pilcrow">¶</a></p>
<p id="section-4-3">This solution can be deployed in hop-by-hop forwarding 
networks as well as in end-to-end tunneled environments. To avoid routing 
loops in networks with multiple route reflectors and hop-by-hop forwarding 
without encapsulation, it is essential that the network topology be carefully 
considered in designing a route reflection topology (see also <span><a href="https://www.rfc-editor.org/rfc/rfc4456#section-11" class="relref">Section 11</a> of [<a href="#RFC4456" class="xref">RFC4456</a>]</span>).<a href="#section-4-3" class="pilcrow">¶</a></p>
<p id="section-4-4">As discussed in <span><a href="https://www.rfc-editor.org/rfc/rfc4456#section-11" class="relref">Section 11</a> of [<a href="#RFC4456" class="xref">RFC4456</a>]</span>, the IGP locations 
of BGP route reflectors are important and have routing implications. This 
equally applies to the choice of the IGP locations configured on optimal route 
reflectors. If a backup location is provided, it is used when the primary IGP 
location disappears from the IGP (i.e., fails). Just like the failure of a route reflector <span>[<a href="#RFC4456" class="xref">RFC4456</a>]</span>, it may result in changing the paths selected and 
advertised to the clients, and in general, the post-failure paths are expected to 
be less optimal. This is dependent on the IGP topologies and the IGP distance
between the primary and backup IGP locations: the smaller the distance, the 
smaller the potential impact.<a href="#section-4-4" class="pilcrow">¶</a></p>
<p id="section-4-5">
After selecting N suitable IGP locations, an operator can choose to enable route 
selection for all of them on all or on a subset of their route reflectors. The 
operator may alternatively deploy single or multiple (backup case) route 
reflectors for each IGP location or create any design in between.  This 
choice may depend on the operational model (centralized vs. per region), an acceptable 
blast radius in the case of failure, an acceptable number of IBGP sessions for the mesh between the route reflectors, performance, and configuration granularity of the equipment.<a href="#section-4-5" class="pilcrow">¶</a></p>
<p id="section-4-6">With this approach, an ISP can effect a hot potato routing policy 
even if route reflection has been moved out of the forwarding plane and 
hop-by-hop forwarding has been replaced by end-to-end MPLS or IP 
encapsulation. Compared with a deployment of ADD-PATH on all routers, BGP ORR
reduces the amount of state that needs to 
be pushed to the edge of the network in order to perform hot potato routing.<a href="#section-4-6" class="pilcrow">¶</a></p>
<p id="section-4-7">Modifying the IGP location of BGP ORR does not interfere with policies 
enforced before IGP tie-breaking (step e) of
<span>[<a href="#RFC4271" class="xref">RFC4271</a>], <a href="https://www.rfc-editor.org/rfc/rfc4271#section-9.1.2.2" class="relref">Section 9.1.2.2</a></span>) in the BGP Decision Process.<a href="#section-4-7" class="pilcrow">¶</a></p>
<p id="section-4-8">Calculating routes for different IGP locations requires multiple Shortest 
Path First (SPF) calculations and multiple (subsets of) BGP Decision Processes.
This scenario calls for more computing resources. This document allows for different 
granularity, such as one Decision Process per route reflector, per set of clients,
or per client. A more fine-grained granularity may translate into more optimal 
hot potato routing at the cost of more computing power. Choosing to configure 
an IGP location per client has the highest precision, as each client can be 
associated with their ideal (own) IGP location.  However, doing so may have an 
impact on performance (as explained above).  Using an IGP location per set 
of clients implies a loss of precision but reduces the impact on the performance 
of the route reflector.  Similarly, if an IGP location is selected for the whole 
routing instance, the lowest precision is achieved, but the impact on performance 
is minimal. In the last mode of operation (where an IGP location is selected for the whole routing instance), both precision and performance 
metrics are equal to route reflection as described in 
<span>[<a href="#RFC4456" class="xref">RFC4456</a>]</span>. The ability to run fine-grained computations depends on the platform/hardware 
deployed, the number of clients, the number of BGP routes, and the size of the 
IGP topology. In essence, sizing considerations are similar to the deployments 
of BGP route reflectors.<a href="#section-4-8" class="pilcrow">¶</a></p>
</section>
</div>
<section id="section-5">
      <h2 id="name-security-considerations">
<a href="#section-5" class="section-number selfRef">5. </a><a href="#name-security-considerations" class="section-name selfRef">Security Considerations</a>
      </h2>
<p id="section-5-1">The extension specified in this document provides a new metric value using additional information 
for computing routes for BGP route reflectors.  While any improperly used 
metric value could impact the resiliency of the network, this extension does 
not change the underlying security issues inherent in the existing IBGP per 
<span>[<a href="#RFC4456" class="xref">RFC4456</a>]</span>.<a href="#section-5-1" class="pilcrow">¶</a></p>
<p id="section-5-2">This document does not introduce requirements for any new protection 
measures.<a href="#section-5-2" class="pilcrow">¶</a></p>
</section>
<section id="section-6">
      <h2 id="name-iana-considerations">
<a href="#section-6" class="section-number selfRef">6. </a><a href="#name-iana-considerations" class="section-name selfRef">IANA Considerations</a>
      </h2>
<p id="section-6-1">This document has no IANA actions.<a href="#section-6-1" class="pilcrow">¶</a></p>
</section>
<section id="section-7">
      <h2 id="name-references">
<a href="#section-7" class="section-number selfRef">7. </a><a href="#name-references" class="section-name selfRef">References</a>
      </h2>
<section id="section-7.1">
        <h3 id="name-normative-references">
<a href="#section-7.1" class="section-number selfRef">7.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="RFC4456">[RFC4456]</dt>
        <dd>
<span class="refAuthor">Bates, T.</span>, <span class="refAuthor">Chen, E.</span>, and <span class="refAuthor">R. Chandra</span>, <span class="refTitle">"BGP Route Reflection: An Alternative to Full Mesh Internal BGP (IBGP)"</span>, <span class="seriesInfo">RFC 4456</span>, <span class="seriesInfo">DOI 10.17487/RFC4456</span>, <time datetime="2006-04" class="refDate">April 2006</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc4456">https://www.rfc-editor.org/info/rfc4456</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="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>
</dl>
</section>
<section id="section-7.2">
        <h3 id="name-informative-references">
<a href="#section-7.2" class="section-number selfRef">7.2. </a><a href="#name-informative-references" class="section-name selfRef">Informative References</a>
        </h3>
<dl class="references">
<dt id="ISO10589">[ISO10589]</dt>
        <dd>
<span class="refAuthor">ISO</span>, <span class="refTitle">"Intermediate system to Intermediate system intra-domain routeing information exchange protocol for use in conjunction with the protocol for providing the connectionless-mode Network Service (ISO 8473)"</span>, <span class="refContent">ISO/IEC 10589:2002, Second Edition</span>, <time datetime="2002-11" class="refDate">November 2002</time>. </dd>
<dd class="break"></dd>
<dt id="RFC2328">[RFC2328]</dt>
        <dd>
<span class="refAuthor">Moy, J.</span>, <span class="refTitle">"OSPF Version 2"</span>, <span class="seriesInfo">STD 54</span>, <span class="seriesInfo">RFC 2328</span>, <span class="seriesInfo">DOI 10.17487/RFC2328</span>, <time datetime="1998-04" class="refDate">April 1998</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc2328">https://www.rfc-editor.org/info/rfc2328</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="RFC5340">[RFC5340]</dt>
        <dd>
<span class="refAuthor">Coltun, R.</span>, <span class="refAuthor">Ferguson, D.</span>, <span class="refAuthor">Moy, J.</span>, and <span class="refAuthor">A. Lindem</span>, <span class="refTitle">"OSPF for IPv6"</span>, <span class="seriesInfo">RFC 5340</span>, <span class="seriesInfo">DOI 10.17487/RFC5340</span>, <time datetime="2008-07" class="refDate">July 2008</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc5340">https://www.rfc-editor.org/info/rfc5340</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="RFC7947">[RFC7947]</dt>
      <dd>
<span class="refAuthor">Jasinska, E.</span>, <span class="refAuthor">Hilliard, N.</span>, <span class="refAuthor">Raszuk, R.</span>, and <span class="refAuthor">N. Bakker</span>, <span class="refTitle">"Internet Exchange BGP Route Server"</span>, <span class="seriesInfo">RFC 7947</span>, <span class="seriesInfo">DOI 10.17487/RFC7947</span>, <time datetime="2016-09" class="refDate">September 2016</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc7947">https://www.rfc-editor.org/info/rfc7947</a>&gt;</span>. </dd>
<dd class="break"></dd>
</dl>
</section>
</section>
<section id="appendix-A">
      <h2 id="name-acknowledgments">
<a href="#name-acknowledgments" class="section-name selfRef">Acknowledgments</a>
      </h2>
<p id="appendix-A-1">The authors would like to thank <span class="contact-name">Keyur Patel</span>, <span class="contact-name">Eric Rosen</span>, <span class="contact-name">Clarence Filsfils</span>, <span class="contact-name">Uli Bornhauser</span>, <span class="contact-name">Russ White</span>, <span class="contact-name">Jakob Heitz</span>, <span class="contact-name">Mike Shand</span>, <span class="contact-name">Jon  Mitchell</span>, <span class="contact-name">John Scudder</span>, <span class="contact-name">Jeff Haas</span>, <span class="contact-name">Martin Djernæs</span>, <span class="contact-name">Daniele Ceccarelli</span>, <span class="contact-name">Kieran Milne</span>, <span class="contact-name">Job Snijders</span>, <span class="contact-name">Randy Bush</span>, <span class="contact-name">Alvaro Retana</span>,  
<span class="contact-name">Francesca Palombini</span>, <span class="contact-name">Benjamin Kaduk</span>, <span class="contact-name">Zaheduzzaman Sarker</span>, <span class="contact-name">Lars Eggert</span>, <span class="contact-name">Murray Kucherawy</span>, <span class="contact-name">Tom Petch</span>, and <span class="contact-name">Nick Hilliard</span> for their 
valuable input.<a href="#appendix-A-1" class="pilcrow">¶</a></p>
</section>
<section id="appendix-B">
      <h2 id="name-contributors">
<a href="#name-contributors" class="section-name selfRef">Contributors</a>
      </h2>
<p id="appendix-B-1">The following persons contributed substantially to the current 
format of the document:<a href="#appendix-B-1" class="pilcrow">¶</a></p>
<address class="vcard">
        <div dir="auto" class="left"><span class="fn nameRole">Stephane Litkowski</span></div>
<div dir="auto" class="left"><span class="org">Cisco Systems</span></div>
<div class="email">
<span>Email:</span>
<a href="mailto:slitkows.ietf@gmail.com" class="email">slitkows.ietf@gmail.com</a>
</div>
</address>
<address class="vcard">
        <div dir="auto" class="left"><span class="fn nameRole">Adam Chappell</span></div>
<div dir="auto" class="left"><span class="org">GTT Communications, Inc.</span></div>
<div dir="auto" class="left"><span class="street-address">Aspira Business Centre<br>Bucharova 2928/14a</span></div>
<div dir="auto" class="left"><span class="locality">158 00 Prague 13 Stodůlky</span></div>
<div dir="auto" class="left"><span class="country-name">Czech Republic</span></div>
<div class="email">
<span>Email:</span>
<a href="mailto:adam.chappell@gtt.net" class="email">adam.chappell@gtt.net</a>
</div>
</address>
</section>
<div id="authors-addresses">
<section id="appendix-C">
      <h2 id="name-authors-addresses">
<a href="#name-authors-addresses" class="section-name selfRef">Authors' Addresses</a>
      </h2>
<address class="vcard">
        <div dir="auto" class="left"><span class="fn nameRole">Robert Raszuk (<span class="role">editor</span>)</span></div>
<div dir="auto" class="left"><span class="org">NTT Network Innovations</span></div>
<div class="email">
<span>Email:</span>
<a href="mailto:robert@raszuk.net" class="email">robert@raszuk.net</a>
</div>
</address>
<address class="vcard">
        <div dir="auto" class="left"><span class="fn nameRole">Bruno Decraene (<span class="role">editor</span>)</span></div>
<div dir="auto" class="left"><span class="org">Orange</span></div>
<div class="email">
<span>Email:</span>
<a href="mailto:bruno.decraene@orange.com" class="email">bruno.decraene@orange.com</a>
</div>
</address>
<address class="vcard">
        <div dir="auto" class="left"><span class="fn nameRole">Christian Cassar</span></div>
<div class="email">
<span>Email:</span>
<a href="mailto:cassar.christian@gmail.com" class="email">cassar.christian@gmail.com</a>
</div>
</address>
<address class="vcard">
        <div dir="auto" class="left"><span class="fn nameRole">Erik Åman</span></div>
<div class="email">
<span>Email:</span>
<a href="mailto:erik.aman@aman.se" class="email">erik.aman@aman.se</a>
</div>
</address>
<address class="vcard">
        <div dir="auto" class="left"><span class="fn nameRole">Kevin Wang</span></div>
<div dir="auto" class="left"><span class="org">Juniper Networks</span></div>
<div dir="auto" class="left"><span class="street-address">10 Technology Park Drive</span></div>
<div dir="auto" class="left">
<span class="locality">Westford</span>, <span class="region">MA</span> <span class="postal-code">01886</span>
</div>
<div dir="auto" class="left"><span class="country-name">United States of America</span></div>
<div class="email">
<span>Email:</span>
<a href="mailto:kfwang@juniper.net" class="email">kfwang@juniper.net</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>