File: rfc8660.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 (3200 lines) | stat: -rw-r--r-- 162,690 bytes
parent folder | download | duplicates (2)
<!DOCTYPE html>
<html lang="en" class="RFC">
<head>
<meta charset="utf-8">
<meta content="Common,Latin" name="scripts">
<meta content="initial-scale=1.0" name="viewport">
<title>RFC 8660: Segment Routing with the MPLS Data Plane</title>
<meta content="Ahmed Bashandy" name="author">
<meta content="Clarence Filsfils" name="author">
<meta content="Stefano Previdi" name="author">
<meta content="Bruno Decraene" name="author">
<meta content="Stephane Litkowski" name="author">
<meta content="Rob Shakir" name="author">
<meta content="
       
   Segment Routing (SR) leverages the source-routing paradigm.  A node
   steers a packet through a controlled set of instructions, called
   segments, by prepending the packet with an SR header.  In the MPLS
   data plane, the SR header is instantiated through a label stack. This
   document specifies the forwarding behavior to allow instantiating SR
   over the MPLS data plane (SR-MPLS). 
    " name="description">
<meta content="xml2rfc 2.35.0" name="generator">
<meta content="8660" name="rfc.number">
<link href="rfc8660.xml" type="application/rfc+xml" rel="alternate">
<link href="#copyright" rel="license">
<style type="text/css">/*

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

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

*/

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

.refInstance {
  margin-bottom: 1.25em;
}

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

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

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

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

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

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

/* pagination */
@media print {
  body {

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

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

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

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

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

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

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

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

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

}

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


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

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

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

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

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

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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

}
/* Avoid wrapping of URLs in references */
@media screen {
  .references a {
    white-space: nowrap;
  }
}
/* Tweak the bcp14 keyword presentation */
.bcp14 {
  font-variant: small-caps;
  font-weight: bold;
  font-size: 0.9em;
}
/* Tweak the invisible space above H* in order not to overlay links in text above */
 h2 {
  margin-top: -18px;  /* provide offset for in-page anchors */
  padding-top: 31px;
 }
 h3 {
  margin-top: -18px;  /* provide offset for in-page anchors */
  padding-top: 24px;
 }
 h4 {
  margin-top: -18px;  /* provide offset for in-page anchors */
  padding-top: 24px;
 }
/* Float artwork pilcrow to the right */
@media screen {
  .artwork a.pilcrow {
    display: block;
    line-height: 0.7;
    margin-top: 0.15em;
  }
}
/* Make pilcrows on dd visible */
@media screen {
  dd:hover > a.pilcrow {
    visibility: visible;
  }
}
/* Make the placement of figcaption match that of a table's caption
   by removing the figure's added bottom margin */
.alignLeft.art-text,
.alignCenter.art-text,
.alignRight.art-text {
   margin-bottom: 0;
}
.alignLeft,
.alignCenter,
.alignRight {
  margin: 1em 0 0 0;
}
/* In print, the pilcrow won't show on hover, so prevent it from taking up space,
   possibly even requiring a new line */
@media print {
  a.pilcrow {
    display: none;
  }
}
/* Styling for the external metadata */
div#external-metadata {
  background-color: #eee;
  padding: 0.5em;
  margin-bottom: 0.5em;
  display: none;
}
div#internal-metadata {
  padding: 0.5em;                       /* to match the external-metadata padding */
}
/* Styling for title RFC Number */
h1#rfcnum {
  clear: both;
  margin: 0 0 -1em;
  padding: 1em 0 0 0;
}
/* Make .olPercent look the same as <ol><li> */
dl.olPercent > dd {
  margin: 0 0 0.25em 0;
  min-height: initial;
}
/* Give aside some styling to set it apart */
aside {
  border-left: 1px solid #ddd;
  margin: 1em 0 1em 2em;
  padding: 0.2em 2em;
}
aside > dl,
aside > ol,
aside > ul,
aside > table,
aside > p {
  margin-bottom: 0;
}
/* Additional page break settings */
@media print {
  figcaption, table caption {
    page-break-before: avoid;
  }
}
/* Font size adjustments for print */
@media print {
  body  { font-size: 10pt;      line-height: normal; max-width: 96%; }
  h1    { font-size: 1.72em;    padding-top: 1.5em; } /* 1*1.2*1.2*1.2 */
  h2    { font-size: 1.44em;    padding-top: 1.5em; } /* 1*1.2*1.2 */
  h3    { font-size: 1.2em;     padding-top: 1.5em; } /* 1*1.2 */
  h4    { font-size: 1em;       padding-top: 1.5em; }
  h5, h6 { font-size: 1em;      margin: initial; padding: 0.5em 0 0.3em; }
}
/* Sourcecode margin in print, when there's no pilcrow */
@media print {
  .sourcecode {
    margin-bottom: 1em;
  }
}</style>
<link href="rfc-local.css" type="text/css" rel="stylesheet">
<link href="https://dx.doi.org/10.17487/rfc8660" rel="alternate">
  <link href="urn:issn:2070-1721" rel="alternate">
  <link href="https://datatracker.ietf.org/doc/draft-ietf-spring-segment-routing-mpls-22" 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 8660</td>
<td class="center">Segment Routing with the MPLS Data Plane</td>
<td class="right">December 2019</td>
</tr></thead>
<tfoot><tr>
<td class="left">Bashandy, 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/rfc8660" class="eref">8660</a></dd>
<dt class="label-category">Category:</dt>
<dd class="category">Standards Track</dd>
<dt class="label-published">Published:</dt>
<dd class="published">
<time datetime="2019-12" class="published">December 2019</time>
    </dd>
<dt class="label-issn">ISSN:</dt>
<dd class="issn">2070-1721</dd>
<dt class="label-authors">Authors:</dt>
<dd class="authors">
<div class="author">
      <div class="author-name">A. Bashandy, <span class="editor">Ed.</span>
</div>
<div class="org">Arrcus</div>
</div>
<div class="author">
      <div class="author-name">C. Filsfils, <span class="editor">Ed.</span>
</div>
<div class="org">Cisco Systems, Inc.</div>
</div>
<div class="author">
      <div class="author-name">S. Previdi</div>
<div class="org">Cisco Systems, Inc.</div>
</div>
<div class="author">
      <div class="author-name">B. Decraene</div>
<div class="org">Orange</div>
</div>
<div class="author">
      <div class="author-name">S. Litkowski</div>
<div class="org">Orange</div>
</div>
<div class="author">
      <div class="author-name">R. Shakir</div>
<div class="org">Google</div>
</div>
</dd>
</dl>
</div>
<h1 id="rfcnum">RFC 8660</h1>
<h1 id="title">Segment Routing with the MPLS Data Plane</h1>
<section id="section-abstract">
      <h2 id="abstract"><a href="#abstract" class="selfRef">Abstract</a></h2>
<p id="section-abstract-1">
   Segment Routing (SR) leverages the source-routing paradigm.  A node
   steers a packet through a controlled set of instructions, called
   segments, by prepending the packet with an SR header.  In the MPLS
   data plane, the SR header is instantiated through a label stack. This
   document specifies the forwarding behavior to allow instantiating SR
   over the MPLS data plane (SR-MPLS).<a href="#section-abstract-1" class="pilcrow">¶</a></p>
</section>
<div id="status-of-memo">
<section id="section-boilerplate.1">
        <h2 id="name-status-of-this-memo">
<a href="#name-status-of-this-memo" class="section-name selfRef">Status of This Memo</a>
        </h2>
<p id="section-boilerplate.1-1">
            This is an Internet Standards Track document.<a href="#section-boilerplate.1-1" class="pilcrow">¶</a></p>
<p id="section-boilerplate.1-2">
            This document is a product of the Internet Engineering Task Force
            (IETF).  It represents the consensus of the IETF community.  It has
            received public review and has been approved for publication by
            the Internet Engineering Steering Group (IESG).  Further
            information on Internet Standards is available in Section 2 of 
            RFC 7841.<a href="#section-boilerplate.1-2" class="pilcrow">¶</a></p>
<p id="section-boilerplate.1-3">
            Information about the current status of this document, any
            errata, and how to provide feedback on it may be obtained at
            <span><a href="https://www.rfc-editor.org/info/rfc8660">https://www.rfc-editor.org/info/rfc8660</a></span>.<a href="#section-boilerplate.1-3" class="pilcrow">¶</a></p>
</section>
</div>
<div id="copyright">
<section id="section-boilerplate.2">
        <h2 id="name-copyright-notice">
<a href="#name-copyright-notice" class="section-name selfRef">Copyright Notice</a>
        </h2>
<p id="section-boilerplate.2-1">
            Copyright (c) 2019 IETF Trust and the persons identified as the
            document authors. All rights reserved.<a href="#section-boilerplate.2-1" class="pilcrow">¶</a></p>
<p id="section-boilerplate.2-2">
            This document is subject to BCP 78 and the IETF Trust's Legal
            Provisions Relating to IETF Documents
            (<span><a href="https://trustee.ietf.org/license-info">https://trustee.ietf.org/license-info</a></span>) in effect on the date of
            publication of this document. Please review these documents
            carefully, as they describe your rights and restrictions with
            respect to this document. Code Components extracted from this
            document must include Simplified BSD License text as described in
            Section 4.e of the Trust Legal Provisions and are provided without
            warranty as described in the Simplified BSD License.<a href="#section-boilerplate.2-2" class="pilcrow">¶</a></p>
</section>
</div>
<div id="toc">
<section id="section-toc.1">
        <a href="#" onclick="scroll(0,0)" class="toplink">▲</a><h2 id="name-table-of-contents">
<a href="#name-table-of-contents" class="section-name selfRef">Table of Contents</a>
        </h2>
<nav class="toc"><ul class="toc ulEmpty">
<li class="toc ulEmpty" id="section-toc.1-1.1">
            <p id="section-toc.1-1.1.1"><a href="#section-1" class="xref">1</a>.  <a href="#name-introduction" class="xref">Introduction</a><a href="#section-toc.1-1.1.1" class="pilcrow">¶</a></p>
<ul class="toc ulEmpty">
<li class="toc ulEmpty" id="section-toc.1-1.1.2.1">
                <p id="section-toc.1-1.1.2.1.1"><a href="#section-1.1" class="xref">1.1</a>.  <a href="#name-requirements-language" class="xref">Requirements Language</a><a href="#section-toc.1-1.1.2.1.1" class="pilcrow">¶</a></p>
</li>
            </ul>
</li>
          <li class="toc ulEmpty" id="section-toc.1-1.2">
            <p id="section-toc.1-1.2.1"><a href="#section-2" class="xref">2</a>.  <a href="#name-mpls-instantiation-of-segme" class="xref">MPLS Instantiation of Segment Routing</a><a href="#section-toc.1-1.2.1" class="pilcrow">¶</a></p>
<ul class="toc ulEmpty">
<li class="toc ulEmpty" id="section-toc.1-1.2.2.1">
                <p id="section-toc.1-1.2.2.1.1"><a href="#section-2.1" class="xref">2.1</a>.  <a href="#name-multiple-forwarding-behavio" class="xref">Multiple Forwarding Behaviors for the Same Prefix</a><a href="#section-toc.1-1.2.2.1.1" class="pilcrow">¶</a></p>
</li>
              <li class="toc ulEmpty" id="section-toc.1-1.2.2.2">
                <p id="section-toc.1-1.2.2.2.1"><a href="#section-2.2" class="xref">2.2</a>.  <a href="#name-sid-representation-in-the-m" class="xref">SID Representation in the MPLS Forwarding Plane</a><a href="#section-toc.1-1.2.2.2.1" class="pilcrow">¶</a></p>
</li>
              <li class="toc ulEmpty" id="section-toc.1-1.2.2.3">
                <p id="section-toc.1-1.2.2.3.1"><a href="#section-2.3" class="xref">2.3</a>.  <a href="#name-segment-routing-global-bloc" class="xref">Segment Routing Global Block and Local Block</a><a href="#section-toc.1-1.2.2.3.1" class="pilcrow">¶</a></p>
</li>
              <li class="toc ulEmpty" id="section-toc.1-1.2.2.4">
                <p id="section-toc.1-1.2.2.4.1"><a href="#section-2.4" class="xref">2.4</a>.  <a href="#name-mapping-a-sid-index-to-an-m" class="xref">Mapping a SID Index to an MPLS Label</a><a href="#section-toc.1-1.2.2.4.1" class="pilcrow">¶</a></p>
</li>
              <li class="toc ulEmpty" id="section-toc.1-1.2.2.5">
                <p id="section-toc.1-1.2.2.5.1"><a href="#section-2.5" class="xref">2.5</a>.  <a href="#name-incoming-label-collision" class="xref">Incoming Label Collision</a><a href="#section-toc.1-1.2.2.5.1" class="pilcrow">¶</a></p>
<ul class="toc ulEmpty">
<li class="toc ulEmpty" id="section-toc.1-1.2.2.5.2.1">
                    <p id="section-toc.1-1.2.2.5.2.1.1"><a href="#section-2.5.1" class="xref">2.5.1</a>.  <a href="#name-tiebreaking-rules" class="xref">Tiebreaking Rules</a><a href="#section-toc.1-1.2.2.5.2.1.1" class="pilcrow">¶</a></p>
</li>
                  <li class="toc ulEmpty" id="section-toc.1-1.2.2.5.2.2">
                    <p id="section-toc.1-1.2.2.5.2.2.1"><a href="#section-2.5.2" class="xref">2.5.2</a>.  <a href="#name-redistribution-between-rout" class="xref">Redistribution between Routing Protocol Instances</a><a href="#section-toc.1-1.2.2.5.2.2.1" class="pilcrow">¶</a></p>
</li>
                </ul>
</li>
              <li class="toc ulEmpty" id="section-toc.1-1.2.2.6">
                <p id="section-toc.1-1.2.2.6.1"><a href="#section-2.6" class="xref">2.6</a>.  <a href="#name-effect-of-incoming-label-co" class="xref">Effect of Incoming Label Collision on Outgoing Label Programming</a><a href="#section-toc.1-1.2.2.6.1" class="pilcrow">¶</a></p>
</li>
              <li class="toc ulEmpty" id="section-toc.1-1.2.2.7">
                <p id="section-toc.1-1.2.2.7.1"><a href="#section-2.7" class="xref">2.7</a>.  <a href="#name-push-continue-and-next" class="xref">PUSH, CONTINUE, and NEXT</a><a href="#section-toc.1-1.2.2.7.1" class="pilcrow">¶</a></p>
<ul class="toc ulEmpty">
<li class="toc ulEmpty" id="section-toc.1-1.2.2.7.2.1">
                    <p id="section-toc.1-1.2.2.7.2.1.1"><a href="#section-2.7.1" class="xref">2.7.1</a>.  <a href="#name-push" class="xref">PUSH</a><a href="#section-toc.1-1.2.2.7.2.1.1" class="pilcrow">¶</a></p>
</li>
                  <li class="toc ulEmpty" id="section-toc.1-1.2.2.7.2.2">
                    <p id="section-toc.1-1.2.2.7.2.2.1"><a href="#section-2.7.2" class="xref">2.7.2</a>.  <a href="#name-continue" class="xref">CONTINUE</a><a href="#section-toc.1-1.2.2.7.2.2.1" class="pilcrow">¶</a></p>
</li>
                  <li class="toc ulEmpty" id="section-toc.1-1.2.2.7.2.3">
                    <p id="section-toc.1-1.2.2.7.2.3.1"><a href="#section-2.7.3" class="xref">2.7.3</a>.  <a href="#name-next" class="xref">NEXT</a><a href="#section-toc.1-1.2.2.7.2.3.1" class="pilcrow">¶</a></p>
</li>
                </ul>
</li>
              <li class="toc ulEmpty" id="section-toc.1-1.2.2.8">
                <p id="section-toc.1-1.2.2.8.1"><a href="#section-2.8" class="xref">2.8</a>.  <a href="#name-mpls-label-downloaded-to-th" class="xref">MPLS Label Downloaded to the FIB for Global and Local SIDs</a><a href="#section-toc.1-1.2.2.8.1" class="pilcrow">¶</a></p>
</li>
              <li class="toc ulEmpty" id="section-toc.1-1.2.2.9">
                <p id="section-toc.1-1.2.2.9.1"><a href="#section-2.9" class="xref">2.9</a>.  <a href="#name-active-segment" class="xref">Active Segment</a><a href="#section-toc.1-1.2.2.9.1" class="pilcrow">¶</a></p>
</li>
              <li class="toc ulEmpty" id="section-toc.1-1.2.2.10">
                <p id="section-toc.1-1.2.2.10.1"><a href="#section-2.10" class="xref">2.10</a>. <a href="#name-forwarding-behavior-for-glo" class="xref">Forwarding Behavior for Global SIDs</a><a href="#section-toc.1-1.2.2.10.1" class="pilcrow">¶</a></p>
<ul class="toc ulEmpty">
<li class="toc ulEmpty" id="section-toc.1-1.2.2.10.2.1">
                    <p id="section-toc.1-1.2.2.10.2.1.1"><a href="#section-2.10.1" class="xref">2.10.1</a>.  <a href="#name-forwarding-for-push-and-con" class="xref">Forwarding for PUSH and CONTINUE of Global SIDs</a><a href="#section-toc.1-1.2.2.10.2.1.1" class="pilcrow">¶</a></p>
</li>
                  <li class="toc ulEmpty" id="section-toc.1-1.2.2.10.2.2">
                    <p id="section-toc.1-1.2.2.10.2.2.1"><a href="#section-2.10.2" class="xref">2.10.2</a>.  <a href="#name-forwarding-for-the-next-ope" class="xref">Forwarding for the NEXT Operation for Global SIDs</a><a href="#section-toc.1-1.2.2.10.2.2.1" class="pilcrow">¶</a></p>
</li>
                </ul>
</li>
              <li class="toc ulEmpty" id="section-toc.1-1.2.2.11">
                <p id="section-toc.1-1.2.2.11.1"><a href="#section-2.11" class="xref">2.11</a>. <a href="#name-forwarding-behavior-for-loc" class="xref">Forwarding Behavior for Local SIDs</a><a href="#section-toc.1-1.2.2.11.1" class="pilcrow">¶</a></p>
<ul class="toc ulEmpty">
<li class="toc ulEmpty" id="section-toc.1-1.2.2.11.2.1">
                    <p id="section-toc.1-1.2.2.11.2.1.1"><a href="#section-2.11.1" class="xref">2.11.1</a>.  <a href="#name-forwarding-for-the-push-ope" class="xref">Forwarding for the PUSH Operation on Local SIDs</a><a href="#section-toc.1-1.2.2.11.2.1.1" class="pilcrow">¶</a></p>
</li>
                  <li class="toc ulEmpty" id="section-toc.1-1.2.2.11.2.2">
                    <p id="section-toc.1-1.2.2.11.2.2.1"><a href="#section-2.11.2" class="xref">2.11.2</a>.  <a href="#name-forwarding-for-the-continue" class="xref">Forwarding for the CONTINUE Operation for Local SIDs</a><a href="#section-toc.1-1.2.2.11.2.2.1" class="pilcrow">¶</a></p>
</li>
                  <li class="toc ulEmpty" id="section-toc.1-1.2.2.11.2.3">
                    <p id="section-toc.1-1.2.2.11.2.3.1"><a href="#section-2.11.3" class="xref">2.11.3</a>.  <a href="#name-outgoing-label-for-the-next" class="xref">Outgoing Label for the NEXT Operation for Local SIDs</a><a href="#section-toc.1-1.2.2.11.2.3.1" class="pilcrow">¶</a></p>
</li>
                </ul>
</li>
            </ul>
</li>
          <li class="toc ulEmpty" id="section-toc.1-1.3">
            <p id="section-toc.1-1.3.1"><a href="#section-3" class="xref">3</a>.  <a href="#name-iana-considerations" class="xref">IANA Considerations</a><a href="#section-toc.1-1.3.1" class="pilcrow">¶</a></p>
</li>
          <li class="toc ulEmpty" id="section-toc.1-1.4">
            <p id="section-toc.1-1.4.1"><a href="#section-4" class="xref">4</a>.  <a href="#name-manageability-consideration" class="xref">Manageability Considerations</a><a href="#section-toc.1-1.4.1" class="pilcrow">¶</a></p>
</li>
          <li class="toc ulEmpty" id="section-toc.1-1.5">
            <p id="section-toc.1-1.5.1"><a href="#section-5" class="xref">5</a>.  <a href="#name-security-considerations" class="xref">Security Considerations</a><a href="#section-toc.1-1.5.1" class="pilcrow">¶</a></p>
</li>
          <li class="toc ulEmpty" id="section-toc.1-1.6">
            <p id="section-toc.1-1.6.1"><a href="#section-6" class="xref">6</a>.  <a href="#name-references" class="xref">References</a><a href="#section-toc.1-1.6.1" class="pilcrow">¶</a></p>
<ul class="toc ulEmpty">
<li class="toc ulEmpty" id="section-toc.1-1.6.2.1">
                <p id="section-toc.1-1.6.2.1.1"><a href="#section-6.1" class="xref">6.1</a>.  <a href="#name-normative-references" class="xref">Normative References</a><a href="#section-toc.1-1.6.2.1.1" class="pilcrow">¶</a></p>
</li>
              <li class="toc ulEmpty" id="section-toc.1-1.6.2.2">
                <p id="section-toc.1-1.6.2.2.1"><a href="#section-6.2" class="xref">6.2</a>.  <a href="#name-informative-references" class="xref">Informative References</a><a href="#section-toc.1-1.6.2.2.1" class="pilcrow">¶</a></p>
</li>
            </ul>
</li>
          <li class="toc ulEmpty" id="section-toc.1-1.7">
            <p id="section-toc.1-1.7.1"><a href="#section-appendix.a" class="xref">Appendix A</a>.  <a href="#name-examples" class="xref">Examples</a><a href="#section-toc.1-1.7.1" class="pilcrow">¶</a></p>
<ul class="toc ulEmpty">
<li class="toc ulEmpty" id="section-toc.1-1.7.2.1">
                <p id="section-toc.1-1.7.2.1.1"><a href="#section-a.1" class="xref">A.1</a>.  <a href="#name-igp-segment-examples" class="xref">IGP Segment Examples</a><a href="#section-toc.1-1.7.2.1.1" class="pilcrow">¶</a></p>
</li>
              <li class="toc ulEmpty" id="section-toc.1-1.7.2.2">
                <p id="section-toc.1-1.7.2.2.1"><a href="#section-a.2" class="xref">A.2</a>.  <a href="#name-incoming-label-collision-ex" class="xref">Incoming Label Collision Examples</a><a href="#section-toc.1-1.7.2.2.1" class="pilcrow">¶</a></p>
<ul class="toc ulEmpty">
<li class="toc ulEmpty" id="section-toc.1-1.7.2.2.2.1">
                    <p id="section-toc.1-1.7.2.2.2.1.1"><a href="#section-a.2.1" class="xref">A.2.1</a>.  <a href="#name-example-1" class="xref">Example 1</a><a href="#section-toc.1-1.7.2.2.2.1.1" class="pilcrow">¶</a></p>
</li>
                  <li class="toc ulEmpty" id="section-toc.1-1.7.2.2.2.2">
                    <p id="section-toc.1-1.7.2.2.2.2.1"><a href="#section-a.2.2" class="xref">A.2.2</a>.  <a href="#name-example-2" class="xref">Example 2</a><a href="#section-toc.1-1.7.2.2.2.2.1" class="pilcrow">¶</a></p>
</li>
                  <li class="toc ulEmpty" id="section-toc.1-1.7.2.2.2.3">
                    <p id="section-toc.1-1.7.2.2.2.3.1"><a href="#section-a.2.3" class="xref">A.2.3</a>.  <a href="#name-example-3" class="xref">Example 3</a><a href="#section-toc.1-1.7.2.2.2.3.1" class="pilcrow">¶</a></p>
</li>
                  <li class="toc ulEmpty" id="section-toc.1-1.7.2.2.2.4">
                    <p id="section-toc.1-1.7.2.2.2.4.1"><a href="#section-a.2.4" class="xref">A.2.4</a>.  <a href="#name-example-4" class="xref">Example 4</a><a href="#section-toc.1-1.7.2.2.2.4.1" class="pilcrow">¶</a></p>
</li>
                  <li class="toc ulEmpty" id="section-toc.1-1.7.2.2.2.5">
                    <p id="section-toc.1-1.7.2.2.2.5.1"><a href="#section-a.2.5" class="xref">A.2.5</a>.  <a href="#name-example-5" class="xref">Example 5</a><a href="#section-toc.1-1.7.2.2.2.5.1" class="pilcrow">¶</a></p>
</li>
                  <li class="toc ulEmpty" id="section-toc.1-1.7.2.2.2.6">
                    <p id="section-toc.1-1.7.2.2.2.6.1"><a href="#section-a.2.6" class="xref">A.2.6</a>.  <a href="#name-example-6" class="xref">Example 6</a><a href="#section-toc.1-1.7.2.2.2.6.1" class="pilcrow">¶</a></p>
</li>
                  <li class="toc ulEmpty" id="section-toc.1-1.7.2.2.2.7">
                    <p id="section-toc.1-1.7.2.2.2.7.1"><a href="#section-a.2.7" class="xref">A.2.7</a>.  <a href="#name-example-7" class="xref">Example 7</a><a href="#section-toc.1-1.7.2.2.2.7.1" class="pilcrow">¶</a></p>
</li>
                  <li class="toc ulEmpty" id="section-toc.1-1.7.2.2.2.8">
                    <p id="section-toc.1-1.7.2.2.2.8.1"><a href="#section-a.2.8" class="xref">A.2.8</a>.  <a href="#name-example-8" class="xref">Example 8</a><a href="#section-toc.1-1.7.2.2.2.8.1" class="pilcrow">¶</a></p>
</li>
                  <li class="toc ulEmpty" id="section-toc.1-1.7.2.2.2.9">
                    <p id="section-toc.1-1.7.2.2.2.9.1"><a href="#section-a.2.9" class="xref">A.2.9</a>.  <a href="#name-example-9" class="xref">Example 9</a><a href="#section-toc.1-1.7.2.2.2.9.1" class="pilcrow">¶</a></p>
</li>
                  <li class="toc ulEmpty" id="section-toc.1-1.7.2.2.2.10">
                    <p id="section-toc.1-1.7.2.2.2.10.1"><a href="#section-a.2.10" class="xref">A.2.10</a>. <a href="#name-example-10" class="xref">Example 10</a><a href="#section-toc.1-1.7.2.2.2.10.1" class="pilcrow">¶</a></p>
</li>
                  <li class="toc ulEmpty" id="section-toc.1-1.7.2.2.2.11">
                    <p id="section-toc.1-1.7.2.2.2.11.1"><a href="#section-a.2.11" class="xref">A.2.11</a>. <a href="#name-example-11" class="xref">Example 11</a><a href="#section-toc.1-1.7.2.2.2.11.1" class="pilcrow">¶</a></p>
</li>
                  <li class="toc ulEmpty" id="section-toc.1-1.7.2.2.2.12">
                    <p id="section-toc.1-1.7.2.2.2.12.1"><a href="#section-a.2.12" class="xref">A.2.12</a>. <a href="#name-example-12" class="xref">Example 12</a><a href="#section-toc.1-1.7.2.2.2.12.1" class="pilcrow">¶</a></p>
</li>
                  <li class="toc ulEmpty" id="section-toc.1-1.7.2.2.2.13">
                    <p id="section-toc.1-1.7.2.2.2.13.1"><a href="#section-a.2.13" class="xref">A.2.13</a>. <a href="#name-example-13" class="xref">Example 13</a><a href="#section-toc.1-1.7.2.2.2.13.1" class="pilcrow">¶</a></p>
</li>
                  <li class="toc ulEmpty" id="section-toc.1-1.7.2.2.2.14">
                    <p id="section-toc.1-1.7.2.2.2.14.1"><a href="#section-a.2.14" class="xref">A.2.14</a>. <a href="#name-example-14" class="xref">Example 14</a><a href="#section-toc.1-1.7.2.2.2.14.1" class="pilcrow">¶</a></p>
</li>
                </ul>
</li>
              <li class="toc ulEmpty" id="section-toc.1-1.7.2.3">
                <p id="section-toc.1-1.7.2.3.1"><a href="#section-a.3" class="xref">A.3</a>.  <a href="#name-examples-for-the-effect-of-" class="xref">Examples for the Effect of Incoming Label Collision on an Outgoing Label</a><a href="#section-toc.1-1.7.2.3.1" class="pilcrow">¶</a></p>
<ul class="toc ulEmpty">
<li class="toc ulEmpty" id="section-toc.1-1.7.2.3.2.1">
                    <p id="section-toc.1-1.7.2.3.2.1.1"><a href="#section-a.3.1" class="xref">A.3.1</a>.  <a href="#name-example-1-2" class="xref">Example 1</a><a href="#section-toc.1-1.7.2.3.2.1.1" class="pilcrow">¶</a></p>
</li>
                  <li class="toc ulEmpty" id="section-toc.1-1.7.2.3.2.2">
                    <p id="section-toc.1-1.7.2.3.2.2.1"><a href="#section-a.3.2" class="xref">A.3.2</a>.  <a href="#name-example-2-2" class="xref">Example 2</a><a href="#section-toc.1-1.7.2.3.2.2.1" class="pilcrow">¶</a></p>
</li>
                </ul>
</li>
            </ul>
</li>
          <li class="toc ulEmpty" id="section-toc.1-1.8">
            <p id="section-toc.1-1.8.1"><a href="#section-appendix.b" class="xref"></a><a href="#name-acknowledgements" class="xref">Acknowledgements</a><a href="#section-toc.1-1.8.1" class="pilcrow">¶</a></p>
</li>
          <li class="toc ulEmpty" id="section-toc.1-1.9">
            <p id="section-toc.1-1.9.1"><a href="#section-appendix.c" class="xref"></a><a href="#name-contributors" class="xref">Contributors</a><a href="#section-toc.1-1.9.1" class="pilcrow">¶</a></p>
</li>
          <li class="toc ulEmpty" id="section-toc.1-1.10">
            <p id="section-toc.1-1.10.1"><a href="#section-appendix.d" class="xref"></a><a href="#name-authors-addresses" class="xref">Authors' Addresses</a><a href="#section-toc.1-1.10.1" class="pilcrow">¶</a></p>
</li>
        </ul>
</nav>
</section>
</div>
<div id="convert-section-1">
<section id="section-1">
      <h2 id="name-introduction">
<a href="#section-1" class="section-number selfRef">1. </a><a href="#name-introduction" class="section-name selfRef">Introduction</a>
      </h2>
<p id="section-1-1">
   The Segment Routing architecture <span>[<a href="#RFC8402" class="xref">RFC8402</a>]</span> can be directly applied to
   the MPLS architecture with no change in the MPLS forwarding plane.
   This document specifies forwarding-plane behavior to allow
   Segment Routing to operate on top of the MPLS data plane (SR-MPLS). This
   document does not address control-plane behavior. Control-plane
   behavior is specified in other documents such as <span>[<a href="#RFC8665" class="xref">RFC8665</a>]</span>, <span>[<a href="#RFC8666" class="xref">RFC8666</a>]</span>, and <span>[<a href="#RFC8667" class="xref">RFC8667</a>]</span>.<a href="#section-1-1" class="pilcrow">¶</a></p>
<p id="section-1-2">
   The Segment Routing problem statement is described in <span>[<a href="#RFC7855" class="xref">RFC7855</a>]</span>.<a href="#section-1-2" class="pilcrow">¶</a></p>
<p id="section-1-3">
   Coexistence of SR over the MPLS forwarding plane with LDP <span>[<a href="#RFC5036" class="xref">RFC5036</a>]</span> is
   specified in <span>[<a href="#RFC8661" class="xref">RFC8661</a>]</span>.<a href="#section-1-3" class="pilcrow">¶</a></p>
<p id="section-1-4">
   Policy routing and traffic engineering using Segment Routing can be
   found in <span>[<a href="#ROUTING-POLICY" class="xref">ROUTING-POLICY</a>]</span>.<a href="#section-1-4" class="pilcrow">¶</a></p>
<div id="convert-section-1.1">
<section id="section-1.1">
        <h3 id="name-requirements-language">
<a href="#section-1.1" class="section-number selfRef">1.1. </a><a href="#name-requirements-language" class="section-name selfRef">Requirements Language</a>
        </h3>
<p id="section-1.1-1">
       The key words "<span class="bcp14">MUST</span>", "<span class="bcp14">MUST NOT</span>", "<span class="bcp14">REQUIRED</span>", "<span class="bcp14">SHALL</span>", "<span class="bcp14">SHALL NOT</span>", "<span class="bcp14">SHOULD</span>", "<span class="bcp14">SHOULD NOT</span>", "<span class="bcp14">RECOMMENDED</span>", "<span class="bcp14">NOT RECOMMENDED</span>",
    "<span class="bcp14">MAY</span>", and "<span class="bcp14">OPTIONAL</span>" in this document are to be interpreted as
    described in BCP 14 <span>[<a href="#RFC2119" class="xref">RFC2119</a>]</span> <span>[<a href="#RFC8174" class="xref">RFC8174</a>]</span> 
    when, and only when, they appear in all capitals, as shown here.<a href="#section-1.1-1" class="pilcrow">¶</a></p>
</section>
</div>
</section>
</div>
<div id="convert-section-2">
<section id="section-2">
      <h2 id="name-mpls-instantiation-of-segme">
<a href="#section-2" class="section-number selfRef">2. </a><a href="#name-mpls-instantiation-of-segme" class="section-name selfRef">MPLS Instantiation of Segment Routing</a>
      </h2>
<p id="section-2-1">
   MPLS instantiation of Segment Routing fits in the MPLS architecture
   as defined in <span>[<a href="#RFC3031" class="xref">RFC3031</a>]</span> from both a control-plane and forwarding-plane
   perspective:<a href="#section-2-1" class="pilcrow">¶</a></p>
<ul>
<li id="section-2-2.1">From a control-plane perspective, <span>[<a href="#RFC3031" class="xref">RFC3031</a>]</span> does not mandate a
      single signaling protocol.  Segment Routing makes use of various
      control-plane protocols such as link-state IGPs <span>[<a href="#RFC8665" class="xref">RFC8665</a>]</span> <span>[<a href="#RFC8666" class="xref">RFC8666</a>]</span> <span>[<a href="#RFC8667" class="xref">RFC8667</a>]</span>.
      The flooding mechanisms of link-state IGPs fit very well with
      label stacking on the ingress. A future control-layer protocol and/or
      policy/configuration can be used to specify the label stack.<a href="#section-2-2.1" class="pilcrow">¶</a>
</li>
        <li id="section-2-2.2">From a forwarding-plane perspective, Segment Routing does not
      require any change to the forwarding plane because Segment IDs
      (SIDs) are instantiated as MPLS labels, and the Segment Routing
      header is instantiated as a stack of MPLS labels.<a href="#section-2-2.2" class="pilcrow">¶</a>
</li>
      </ul>
<p id="section-2-3">
   We call the "MPLS Control Plane Client (MCC)" any control-plane entity
   installing forwarding entries in the MPLS data plane. Local
   configuration and policies applied on a router are examples of MCCs.<a href="#section-2-3" class="pilcrow">¶</a></p>
<p id="section-2-4">

   In order to have a node segment reach the node, a network operator
   <span class="bcp14">SHOULD</span> configure at least one node segment per routing instance,
   topology, or algorithm. Otherwise, the node is not reachable within
   the routing instance, within the topology, 
   or along the routing algorithm, which restricts 
   its ability to be used by an SR Policy and as a 
   Topology Independent Loop-Free Alternate (TI-LFA).<a href="#section-2-4" class="pilcrow">¶</a></p>
<div id="convert-section-2.1">
<section id="section-2.1">
        <h3 id="name-multiple-forwarding-behavio">
<a href="#section-2.1" class="section-number selfRef">2.1. </a><a href="#name-multiple-forwarding-behavio" class="section-name selfRef">Multiple Forwarding Behaviors for the Same Prefix</a>
        </h3>
<p id="section-2.1-1">
   The SR architecture does not prohibit having more than one SID for
   the same prefix. In fact, by allowing multiple SIDs for the same
   prefix, it is possible to have different forwarding behaviors (such
   as different paths, different ECMP and Unequal-Cost Multipath (UCMP) behaviors, etc.) for the
   same destination.<a href="#section-2.1-1" class="pilcrow">¶</a></p>
<p id="section-2.1-2">
   Instantiating Segment Routing over the MPLS forwarding plane fits
   seamlessly with this principle. An operator may assign multiple MPLS
   labels or indices to the same prefix and assign different forwarding
   behaviors to each label/SID. The MCC in the network downloads
   different MPLS labels/SIDs to the FIB for different forwarding
   behaviors. The MCC at the entry of an SR domain or at any point in
   the domain can choose to apply a particular forwarding behavior to a
   particular packet by applying the PUSH action to that packet using
   the corresponding SID.<a href="#section-2.1-2" class="pilcrow">¶</a></p>
</section>
</div>
<div id="convert-section-2.2">
<section id="section-2.2">
        <h3 id="name-sid-representation-in-the-m">
<a href="#section-2.2" class="section-number selfRef">2.2. </a><a href="#name-sid-representation-in-the-m" class="section-name selfRef">SID Representation in the MPLS Forwarding Plane</a>
        </h3>
<p id="section-2.2-1">
   When instantiating SR over the MPLS forwarding plane, a SID is
   represented by an MPLS label or an index <span>[<a href="#RFC8402" class="xref">RFC8402</a>]</span>.<a href="#section-2.2-1" class="pilcrow">¶</a></p>
<p id="section-2.2-2">
   A global SID is a label, or an index that may be mapped to an
   MPLS label within the Segment Routing Global Block (SRGB), of the node
   that installs a global SID in its FIB and receives the labeled
   packet. <a href="#convert-section-2.4" class="xref">Section 2.4</a> specifies the procedure to map a global segment
   represented by an index to an MPLS label within the SRGB.<a href="#section-2.2-2" class="pilcrow">¶</a></p>
<p id="section-2.2-3">
   The MCC <span class="bcp14">MUST</span> ensure that any label value corresponding to any SID it
   installs in the forwarding plane follows the rules below:<a href="#section-2.2-3" class="pilcrow">¶</a></p>
<ul>
<li id="section-2.2-4.1">The label value <span class="bcp14">MUST</span> be unique within the router on which the MCC
      is running, i.e., the label <span class="bcp14">MUST</span> only be used to represent the SID
      and <span class="bcp14">MUST NOT</span> be used to represent more than one SID or for any
      other forwarding purpose on the router.<a href="#section-2.2-4.1" class="pilcrow">¶</a>
</li>
          <li id="section-2.2-4.2">The label value <span class="bcp14">MUST NOT</span> come from the range of special-purpose
      labels <span>[<a href="#RFC7274" class="xref">RFC7274</a>]</span>.<a href="#section-2.2-4.2" class="pilcrow">¶</a>
</li>
        </ul>
<p id="section-2.2-5">
   Labels allocated in this document are considered per-platform downstream
   allocated labels <span>[<a href="#RFC3031" class="xref">RFC3031</a>]</span>.<a href="#section-2.2-5" class="pilcrow">¶</a></p>
</section>
</div>
<div id="convert-section-2.3">
<section id="section-2.3">
        <h3 id="name-segment-routing-global-bloc">
<a href="#section-2.3" class="section-number selfRef">2.3. </a><a href="#name-segment-routing-global-bloc" class="section-name selfRef">Segment Routing Global Block and Local Block</a>
        </h3>
<p id="section-2.3-1">
   The concepts of SRGB and global SID
   are explained in <span>[<a href="#RFC8402" class="xref">RFC8402</a>]</span>. In general, the SRGB need not be a
   contiguous range of labels.<a href="#section-2.3-1" class="pilcrow">¶</a></p>
<p id="section-2.3-2">
For the rest of this document, the SRGB is specified by the list of
MPLS label ranges [Ll(1),Lh(1)], [Ll(2),Lh(2)],..., [Ll(k),Lh(k)]
where  Ll(i) =&lt; Lh(i).<a href="#section-2.3-2" class="pilcrow">¶</a></p>
<p id="section-2.3-3">
   The following rules apply to the list of MPLS ranges representing the
   SRGB:<a href="#section-2.3-3" class="pilcrow">¶</a></p>
<ul>
<li id="section-2.3-4.1">The list of ranges comprising the SRGB <span class="bcp14">MUST NOT</span> overlap.<a href="#section-2.3-4.1" class="pilcrow">¶</a>
</li>
          <li id="section-2.3-4.2">Every range in the list of ranges specifying the SRGB <span class="bcp14">MUST NOT</span>
      cover or overlap with a reserved label value or range <span>[<a href="#RFC7274" class="xref">RFC7274</a>]</span>,
      respectively.<a href="#section-2.3-4.2" class="pilcrow">¶</a>
</li>
          <li id="section-2.3-4.3">If the SRGB of a node does not conform to the structure specified
      in this section or to the previous two rules, the SRGB <span class="bcp14">MUST</span>
      be completely ignored by all routers in the routing domain, and the
      node <span class="bcp14">MUST</span> be treated as if it does not have an SRGB.<a href="#section-2.3-4.3" class="pilcrow">¶</a>
</li>
          <li id="section-2.3-4.4">The list of label ranges <span class="bcp14">MUST</span> only be used to instantiate global
      SIDs into the MPLS forwarding plane.<a href="#section-2.3-4.4" class="pilcrow">¶</a>
</li>
        </ul>
<p id="section-2.3-5">
   A local segment <span class="bcp14">MAY</span> be allocated from the Segment Routing Local Block
   (SRLB) <span>[<a href="#RFC8402" class="xref">RFC8402</a>]</span> or from any unused label as long as it does not use
   a special-purpose label. The SRLB consists of the range of local
   labels reserved by the node for certain local segments.  In a
   controller-driven network, some controllers or applications <span class="bcp14">MAY</span> use
   the control plane to discover the available set of Local SIDs on a
   particular router <span>[<a href="#ROUTING-POLICY" class="xref">ROUTING-POLICY</a>]</span>. The rules
   applicable to the SRGB are also applicable to the SRLB, except the
   SRGB <span class="bcp14">MUST</span> only be used to instantiate global
   SIDs into the MPLS forwarding plane. The recommended, minimum, or
   maximum size of the SRGB and/or SRLB is a matter of future study.<a href="#section-2.3-5" class="pilcrow">¶</a></p>
</section>
</div>
<div id="convert-section-2.4">
<section id="section-2.4">
        <h3 id="name-mapping-a-sid-index-to-an-m">
<a href="#section-2.4" class="section-number selfRef">2.4. </a><a href="#name-mapping-a-sid-index-to-an-m" class="section-name selfRef">Mapping a SID Index to an MPLS Label</a>
        </h3>
<p id="section-2.4-1">
   This subsection specifies how the MPLS label value is calculated
   given the index of a SID. The value of the index is determined by an
   MCC such as IS-IS <span>[<a href="#RFC8667" class="xref">RFC8667</a>]</span> or OSPF
   <span>[<a href="#RFC8665" class="xref">RFC8665</a>]</span>. This section only
   specifies how to map the index to an MPLS label. The calculated MPLS
   label is downloaded to the FIB, sent out with a forwarded packet, or
   both.<a href="#section-2.4-1" class="pilcrow">¶</a></p>
<p id="section-2.4-2">
   Consider a SID represented by the index "I". Consider an SRGB as
   specified in <a href="#convert-section-2.3" class="xref">Section 2.3</a>. The total size of the SRGB, represented by
   the variable "Size", is calculated according to the formula:<a href="#section-2.4-2" class="pilcrow">¶</a></p>
<div class="artwork art-text alignLeft" id="section-2.4-3">
<pre>
size = Lh(1)- Ll(1) + 1 + Lh(2)- Ll(2) + 1 + ... + Lh(k)- Ll(k) + 1</pre><a href="#section-2.4-3" class="pilcrow">¶</a>
</div>
<p id="section-2.4-4"> The following rules <span class="bcp14">MUST</span> be applied by the MCC when calculating the
   MPLS label value corresponding to the SID index value "I".<a href="#section-2.4-4" class="pilcrow">¶</a></p>
<ul class="ulEmpty">
<li class="ulEmpty" id="section-2.4-5.1">0 =&lt; I &lt; size. If index "I" does not satisfy the previous inequality, then the label cannot be calculated.<a href="#section-2.4-5.1" class="pilcrow">¶</a>
</li>
          <li class="ulEmpty" id="section-2.4-5.2">
            <p id="section-2.4-5.2.1">The label value corresponding to the SID index "I" is calculated
 as follows:<a href="#section-2.4-5.2.1" class="pilcrow">¶</a></p>
<ul class="ulEmpty">
<li class="ulEmpty" id="section-2.4-5.2.2.1">j = 1 , temp = 0<a href="#section-2.4-5.2.2.1" class="pilcrow">¶</a>
</li>
              <li class="ulEmpty" id="section-2.4-5.2.2.2">
                <p id="section-2.4-5.2.2.2.1">While temp + Lh(j)- Ll(j) &lt; I<a href="#section-2.4-5.2.2.2.1" class="pilcrow">¶</a></p>
<ul class="ulEmpty">
<li class="ulEmpty" id="section-2.4-5.2.2.2.2.1">temp = temp + Lh(j)- Ll(j) + 1<a href="#section-2.4-5.2.2.2.2.1" class="pilcrow">¶</a>
</li>
                  <li class="ulEmpty" id="section-2.4-5.2.2.2.2.2">j = j+1<a href="#section-2.4-5.2.2.2.2.2" class="pilcrow">¶</a>
</li>
                </ul>
</li>
              <li class="ulEmpty" id="section-2.4-5.2.2.3">label = I - temp + Ll(j)<a href="#section-2.4-5.2.2.3" class="pilcrow">¶</a>
</li>
            </ul>
</li>
        </ul>
<p id="section-2.4-6">
   An example for how a router calculates labels and forwards traffic
   based on the procedure described in this section can be found in
   <a href="#convert-section-a.1" class="xref">Appendix A.1</a>.<a href="#section-2.4-6" class="pilcrow">¶</a></p>
</section>
</div>
<div id="convert-section-2.5">
<section id="section-2.5">
        <h3 id="name-incoming-label-collision">
<a href="#section-2.5" class="section-number selfRef">2.5. </a><a href="#name-incoming-label-collision" class="section-name selfRef">Incoming Label Collision</a>
        </h3>
<p id="section-2.5-1">
   The MPLS Architecture <span>[<a href="#RFC3031" class="xref">RFC3031</a>]</span> defines the term Forwarding
   Equivalence Class (FEC) as the set of packets with similar and/or
   identical characteristics that are forwarded the same way and are
   bound to the same MPLS incoming (local) label. In Segment Routing
   MPLS, a local label serves as the SID for a given FEC.<a href="#section-2.5-1" class="pilcrow">¶</a></p>
<p id="section-2.5-2">
   We define SR FEC <span>[<a href="#RFC8402" class="xref">RFC8402</a>]</span> as one of the following:<a href="#section-2.5-2" class="pilcrow">¶</a></p>
<ul>
<li id="section-2.5-3.1">(Prefix, Routing Instance, Topology, Algorithm) <span>[<a href="#RFC8402" class="xref">RFC8402</a>]</span>, where a
      topology identifies a set of links with metrics. For the purpose
      of incoming label collision resolution, the same Topology
      numerical value <span class="bcp14">SHOULD</span> be used on all routers to identify the same
      set of links with metrics. For MCCs where the "Topology" and/or
      "Algorithm" fields are not defined, the numerical value of zero
      <span class="bcp14">MUST</span> be used for these two fields. For the purpose of incoming
      label collision resolution, a routing instance is identified by a
      single incoming label downloader to the FIB. Two MCCs running on the
      same router are considered different routing instances if the only
      way the two instances know about each other's incoming labels
      is through redistribution. The numerical value used to identify a
      routing instance <span class="bcp14">MAY</span> be derived from other configuration or <span class="bcp14">MAY</span> be
      explicitly configured. If it is derived from other configuration,
      then the same numerical value <span class="bcp14">SHOULD</span> be derived from the same
      configuration as long as the configuration survives router reload.
      If the derived numerical value varies for the same configuration,
      then an implementation <span class="bcp14">SHOULD</span> make the numerical value used to
      identify a routing instance configurable.<a href="#section-2.5-3.1" class="pilcrow">¶</a>
</li>
          <li id="section-2.5-3.2">(next hop, outgoing interface), where the outgoing interface is
      physical or virtual.<a href="#section-2.5-3.2" class="pilcrow">¶</a>
</li>
          <li id="section-2.5-3.3">(number of adjacencies, list of next hops, list of outgoing
      interfaces IDs in ascending numerical order). This FEC represents
      parallel adjacencies <span>[<a href="#RFC8402" class="xref">RFC8402</a>]</span>.<a href="#section-2.5-3.3" class="pilcrow">¶</a>
</li>
          <li id="section-2.5-3.4">(Endpoint, Color). This FEC represents an SR Policy <span>[<a href="#RFC8402" class="xref">RFC8402</a>]</span>.<a href="#section-2.5-3.4" class="pilcrow">¶</a>
</li>
          <li id="section-2.5-3.5">(Mirror SID). The Mirror SID (see <span>[<a href="#RFC8402" class="xref">RFC8402</a>], <a href="https://www.rfc-editor.org/rfc/rfc8402#section-5.1" class="relref">Section 5.1</a></span>) is the IP
      address advertised by the advertising node to identify the Mirror SID.
      The IP address is encoded as specified in <a href="#convert-section-2.5.1" class="xref">Section 2.5.1</a>.<a href="#section-2.5-3.5" class="pilcrow">¶</a>
</li>
        </ul>
<p id="section-2.5-4">
   This section covers the <span class="bcp14">RECOMMENDED</span> procedure for handling the scenario
   where, because of an error/misconfiguration, more than one SR FEC as
   defined in this section maps to the same incoming MPLS label.
   Examples illustrating the behavior specified in this section can be
   found in <a href="#convert-section-a.2" class="xref">Appendix A.2</a>.<a href="#section-2.5-4" class="pilcrow">¶</a></p>
<p id="section-2.5-5">

   An incoming label collision occurs if the SIDs of the set of FECs
   {FEC1, FEC2, ..., FECk} map to the same incoming SR MPLS label "L1".<a href="#section-2.5-5" class="pilcrow">¶</a></p>
<p id="section-2.5-6">
   Suppose an anycast prefix is advertised with a Prefix-SID by some,
   but not all, of the nodes that advertise that prefix. If the Prefix-SID
   sub-TLVs result in mapping that anycast prefix to the same
   incoming label, then the advertisement of the Prefix-SID by some, but
   not all, of the advertising nodes <span class="bcp14">MUST NOT</span> be treated as a label
   collision.<a href="#section-2.5-6" class="pilcrow">¶</a></p>
<p id="section-2.5-7">
   An implementation <span class="bcp14">MUST NOT</span> allow the MCCs belonging to the same
   router to assign the same incoming label to more than one SR FEC.<a href="#section-2.5-7" class="pilcrow">¶</a></p>
<p id="section-2.5-8">
   The objective of the following steps is to deterministically install
   in the MPLS Incoming Label Map, also known as label FIB, a single FEC
   with the incoming label "L1". By "deterministically install", we mean
   if the set of FECs {FEC1, FEC2,..., FECk} map to the same incoming SR
   MPLS label "L1", then the steps below assign the same FEC to the
   label "L1" irrespective of the order by which the mappings of this
   set of FECs to the label "L1" are received. For example, first-
   come, first-served tiebreaking is not allowed. The remaining FECs may
   be installed in the IP FIB without an incoming label.<a href="#section-2.5-8" class="pilcrow">¶</a></p>
<p id="section-2.5-9">
   The procedure in this section relies completely on the local FEC and
   label database within a given router.<a href="#section-2.5-9" class="pilcrow">¶</a></p>
<p id="section-2.5-10">
   The collision resolution procedure is as follows:<a href="#section-2.5-10" class="pilcrow">¶</a></p>
<ol start="1" type="1" class="normal" id="section-2.5-11">
          <li id="section-2.5-11.1">Given the SIDs of the set of FECs, {FEC1, FEC2,..., FECk} map to
      the same MPLS label "L1".<a href="#section-2.5-11.1" class="pilcrow">¶</a>
</li>
          <li id="section-2.5-11.2">
            <p id="section-2.5-11.2.1">Within an MCC, apply tiebreaking rules to select one FEC only, and
      assign the label to it. The losing FECs are handled as if no
      labels are attached to them. The losing FECs with algorithms other
      than the shortest path first <span>[<a href="#RFC8402" class="xref">RFC8402</a>]</span> are not installed in the
      FIB.<a href="#section-2.5-11.2.1" class="pilcrow">¶</a></p>
<ol start="1" type="a" class="normal" id="section-2.5-11.2.2">
              <li id="section-2.5-11.2.2.1"> If the same set of FECs are attached to the same label "L1",
          then the tiebreaking rules <span class="bcp14">MUST</span> always select the same FEC
          irrespective of the order in which the FECs and the label "L1"
          are received. In other words, the tiebreaking rule <span class="bcp14">MUST</span> be
          deterministic.<a href="#section-2.5-11.2.2.1" class="pilcrow">¶</a>
</li>
            </ol>
</li>
          <li id="section-2.5-11.3">If there is still collision between the FECs belonging to
      different MCCs, then reapply the tiebreaking rules to the
      remaining FECs to select one FEC only, and assign the label to that
      FEC.<a href="#section-2.5-11.3" class="pilcrow">¶</a>
</li>
          <li id="section-2.5-11.4">Install the selected FEC into the IP FIB and its incoming label into
        the label FIB.<a href="#section-2.5-11.4" class="pilcrow">¶</a>
</li>
          <li id="section-2.5-11.5">The remaining FECs with the default algorithm (see the
      Prefix-SID algorithm specification <span>[<a href="#RFC8402" class="xref">RFC8402</a>]</span>) may be installed
      in the FIB natively, such as pure IP entries in case of Prefix
      FEC, without any incoming labels corresponding to their SIDs. The
      remaining FECs with algorithms other than the shortest path first
      <span>[<a href="#RFC8402" class="xref">RFC8402</a>]</span> are not installed in the FIB.<a href="#section-2.5-11.5" class="pilcrow">¶</a>
</li>
        </ol>
<div id="convert-section-2.5.1">
<section id="section-2.5.1">
          <h4 id="name-tiebreaking-rules">
<a href="#section-2.5.1" class="section-number selfRef">2.5.1. </a><a href="#name-tiebreaking-rules" class="section-name selfRef">Tiebreaking Rules</a>
          </h4>
<p id="section-2.5.1-1">
   The default tiebreaking rules are specified as follows:<a href="#section-2.5.1-1" class="pilcrow">¶</a></p>
<ol start="1" type="1" class="normal" id="section-2.5.1-2">
            <li id="section-2.5.1-2.1">Determine the lowest administrative distance among the competing FECs as defined in the section below. Then filter away all the competing FECs with a higher administrative distance.<a href="#section-2.5.1-2.1" class="pilcrow">¶</a>
</li>
            <li id="section-2.5.1-2.2">If more than one competing FEC remains after step 1, select the
      smallest numerical FEC value. The numerical value of the FEC is
      determined according to the FEC encoding described later in this
      section.<a href="#section-2.5.1-2.2" class="pilcrow">¶</a>
</li>
          </ol>
<p id="section-2.5.1-3">
   These rules deterministically select which FEC to install in the MPLS
   forwarding plane for the given incoming label.<a href="#section-2.5.1-3" class="pilcrow">¶</a></p>
<p id="section-2.5.1-4">
   This document defines the default tiebreaking rules that <span class="bcp14">SHOULD</span> be
   implemented. An implementation <span class="bcp14">MAY</span> choose to support different tiebreaking
   rules and <span class="bcp14">MAY</span> use one of these instead of the default
   tiebreaking rules. To maximize MPLS forwarding consistency in case
   of a SID configuration error, the network operator <span class="bcp14">MUST</span> deploy, within
   an IGP flooding area, routers implementing the same tiebreaking
   rules.<a href="#section-2.5.1-4" class="pilcrow">¶</a></p>
<p id="section-2.5.1-5">
   Each FEC is assigned an administrative distance. The FEC
   administrative distance is encoded as an 8-bit value. The lower the
   value, the better the administrative distance.<a href="#section-2.5.1-5" class="pilcrow">¶</a></p>
<p id="section-2.5.1-6">
   The default FEC administrative distance order starting from the
   lowest value <span class="bcp14">SHOULD</span> be:<a href="#section-2.5.1-6" class="pilcrow">¶</a></p>
<ul>
<li id="section-2.5.1-7.1">
              <p id="section-2.5.1-7.1.1">Explicit SID assignment to a FEC that maps to a label outside the
      SRGB irrespective of the owner MCC. An explicit SID assignment is
      a static assignment of a label to a FEC such that the assignment
      survives a router reboot.<a href="#section-2.5.1-7.1.1" class="pilcrow">¶</a></p>
<ul>
<li id="section-2.5.1-7.1.2.1">An example of explicit SID allocation is static assignment of
         a specific label to an Adj-SID.<a href="#section-2.5.1-7.1.2.1" class="pilcrow">¶</a>
</li>
                <li id="section-2.5.1-7.1.2.2">An implementation of explicit SID assignment <span class="bcp14">MUST</span> guarantee
         collision freeness on the same router.<a href="#section-2.5.1-7.1.2.2" class="pilcrow">¶</a>
</li>
              </ul>
</li>
            <li id="section-2.5.1-7.2">
              <p id="section-2.5.1-7.2.1">Dynamic SID assignment:<a href="#section-2.5.1-7.2.1" class="pilcrow">¶</a></p>
<ul>
<li id="section-2.5.1-7.2.2.1">All FEC types, except for the SR Policy, are
         ordered using the default administrative distance
         defined by the implementation.<a href="#section-2.5.1-7.2.2.1" class="pilcrow">¶</a>
</li>
                <li id="section-2.5.1-7.2.2.2">The Binding SID <span>[<a href="#RFC8402" class="xref">RFC8402</a>]</span> assigned to the SR Policy always has a
         higher default administrative distance than the default
         administrative distance of any other FEC type.<a href="#section-2.5.1-7.2.2.2" class="pilcrow">¶</a>
</li>
              </ul>
</li>
          </ul>
<p id="section-2.5.1-8">
   To maximize MPLS forwarding consistency, if the same FEC is advertised
   in more than one protocol, a user <span class="bcp14">MUST</span> ensure that the administrative
   distance preference between protocols is the same on all routers of
   the IGP flooding domain. Note that this is not really new as this
   already applies to IP forwarding.<a href="#section-2.5.1-8" class="pilcrow">¶</a></p>
<p id="section-2.5.1-9">
   The numerical sort across FECs <span class="bcp14">SHOULD</span> be performed as follows:<a href="#section-2.5.1-9" class="pilcrow">¶</a></p>
<ul>
<li id="section-2.5.1-10.1">
              <p id="section-2.5.1-10.1.1">Each FEC is assigned a FEC type encoded in 8 bits. The type codepoints 
      for each SR FEC defined at the beginning
      of this section are as follows:<a href="#section-2.5.1-10.1.1" class="pilcrow">¶</a></p>
<ul class="ulEmpty">
<li class="ulEmpty" id="section-2.5.1-10.1.2.1">
                  <dl class="dlParallel" id="section-2.5.1-10.1.2.1.1">
                    <dt id="section-2.5.1-10.1.2.1.1.1">120:</dt>
                    <dd id="section-2.5.1-10.1.2.1.1.2">(Prefix, Routing Instance, Topology, Algorithm)<a href="#section-2.5.1-10.1.2.1.1.2" class="pilcrow">¶</a>
</dd>
<dt id="section-2.5.1-10.1.2.1.1.3">130:</dt>
                    <dd id="section-2.5.1-10.1.2.1.1.4"> (next hop, outgoing interface)<a href="#section-2.5.1-10.1.2.1.1.4" class="pilcrow">¶</a>
</dd>
<dt id="section-2.5.1-10.1.2.1.1.5">140:</dt>
                    <dd id="section-2.5.1-10.1.2.1.1.6"> Parallel Adjacency <span>[<a href="#RFC8402" class="xref">RFC8402</a>]</span><a href="#section-2.5.1-10.1.2.1.1.6" class="pilcrow">¶</a>
</dd>
<dt id="section-2.5.1-10.1.2.1.1.7">150:</dt>
                    <dd id="section-2.5.1-10.1.2.1.1.8">SR Policy <span>[<a href="#RFC8402" class="xref">RFC8402</a>]</span><a href="#section-2.5.1-10.1.2.1.1.8" class="pilcrow">¶</a>
</dd>
<dt id="section-2.5.1-10.1.2.1.1.9">160:</dt>
                    <dd id="section-2.5.1-10.1.2.1.1.10"> Mirror SID <span>[<a href="#RFC8402" class="xref">RFC8402</a>]</span><a href="#section-2.5.1-10.1.2.1.1.10" class="pilcrow">¶</a>
</dd>
</dl>
</li>
              </ul>
<p id="section-2.5.1-10.1.3">The numerical values above are mentioned to guide
         implementation. If other numerical values are used, then the
         numerical values must maintain the same greater-than ordering
         of the numbers mentioned here.<a href="#section-2.5.1-10.1.3" class="pilcrow">¶</a></p>
</li>
            <li id="section-2.5.1-10.2">
              <p id="section-2.5.1-10.2.1">The fields of each FEC are encoded as follows:<a href="#section-2.5.1-10.2.1" class="pilcrow">¶</a></p>
<ul>
<li id="section-2.5.1-10.2.2.1">All fields in all FECs are encoded in big endian order.<a href="#section-2.5.1-10.2.2.1" class="pilcrow">¶</a>
</li>
                <li id="section-2.5.1-10.2.2.2">The Routing Instance ID is represented by 16 bits. For routing
         instances that are identified by less than 16 bits, encode the
         Instance ID in the least significant bits while the most
         significant bits are set to zero.<a href="#section-2.5.1-10.2.2.2" class="pilcrow">¶</a>
</li>
                <li id="section-2.5.1-10.2.2.3">The address family is represented by 8 bits, where IPv4 is encoded as
         100, and IPv6 is encoded as 110. These numerical values are
         mentioned to guide implementations. If other numerical values
         are used, then the numerical value of IPv4 <span class="bcp14">MUST</span> be less than
         the numerical value for IPv6.<a href="#section-2.5.1-10.2.2.3" class="pilcrow">¶</a>
</li>
                <li id="section-2.5.1-10.2.2.4">
                  <p id="section-2.5.1-10.2.2.4.1">All addresses are represented in 128 bits as follows:<a href="#section-2.5.1-10.2.2.4.1" class="pilcrow">¶</a></p>
<ul>
<li id="section-2.5.1-10.2.2.4.2.1">The IPv6 address is encoded natively.<a href="#section-2.5.1-10.2.2.4.2.1" class="pilcrow">¶</a>
</li>
                    <li id="section-2.5.1-10.2.2.4.2.2">The IPv4 address is encoded in the most significant bits, and
               the remaining bits are set to zero.<a href="#section-2.5.1-10.2.2.4.2.2" class="pilcrow">¶</a>
</li>
                  </ul>
</li>
                <li id="section-2.5.1-10.2.2.5">
                  <p id="section-2.5.1-10.2.2.5.1">All prefixes are represented by (8 + 128) bits.<a href="#section-2.5.1-10.2.2.5.1" class="pilcrow">¶</a></p>
<ul>
<li id="section-2.5.1-10.2.2.5.2.1">A prefix is encoded in the most significant bits, and the
        remaining bits are set to zero.<a href="#section-2.5.1-10.2.2.5.2.1" class="pilcrow">¶</a>
</li>
                    <li id="section-2.5.1-10.2.2.5.2.2">The prefix length is encoded before the prefix in an 8-bit field.<a href="#section-2.5.1-10.2.2.5.2.2" class="pilcrow">¶</a>
</li>
                  </ul>
</li>
                <li id="section-2.5.1-10.2.2.6">The Topology ID is represented by 16 bits. For routing instances
         that identify topologies using less than 16 bits, encode the
         topology ID in the least significant bits while the most
         significant bits are set to zero.<a href="#section-2.5.1-10.2.2.6" class="pilcrow">¶</a>
</li>
                <li id="section-2.5.1-10.2.2.7">The Algorithm is encoded in a 16-bit field.<a href="#section-2.5.1-10.2.2.7" class="pilcrow">¶</a>
</li>
                <li id="section-2.5.1-10.2.2.8">The Color ID is encoded using 32 bits.<a href="#section-2.5.1-10.2.2.8" class="pilcrow">¶</a>
</li>
              </ul>
</li>
            <li id="section-2.5.1-10.3">Choose the set of FECs of the smallest FEC type codepoint.<a href="#section-2.5.1-10.3" class="pilcrow">¶</a>
</li>
            <li id="section-2.5.1-10.4">Out of these FECs, choose the FECs with the smallest address
      family codepoint.<a href="#section-2.5.1-10.4" class="pilcrow">¶</a>
</li>
            <li id="section-2.5.1-10.5">
              <p id="section-2.5.1-10.5.1">Encode the remaining set of FECs as follows:<a href="#section-2.5.1-10.5.1" class="pilcrow">¶</a></p>
<ul>
<li id="section-2.5.1-10.5.2.1">(Prefix, Routing Instance, Topology, Algorithm) is encoded as
         (Prefix Length, Prefix, routing_instance_id, Topology, SR
         Algorithm).<a href="#section-2.5.1-10.5.2.1" class="pilcrow">¶</a>
</li>
                <li id="section-2.5.1-10.5.2.2">(next hop, outgoing interface) is encoded as (next hop,
         outgoing_interface_id).<a href="#section-2.5.1-10.5.2.2" class="pilcrow">¶</a>
</li>
                <li id="section-2.5.1-10.5.2.3">(number of adjacencies, list of next hops in ascending
         numerical order, list of outgoing interface IDs in ascending
         numerical order) is used to encode a parallel
         adjacency <span>[<a href="#RFC8402" class="xref">RFC8402</a>]</span>.<a href="#section-2.5.1-10.5.2.3" class="pilcrow">¶</a>
</li>
                <li id="section-2.5.1-10.5.2.4">(Endpoint, Color) is encoded as (Endpoint_address, Color_id).<a href="#section-2.5.1-10.5.2.4" class="pilcrow">¶</a>
</li>
                <li id="section-2.5.1-10.5.2.5">(IP address) is the encoding for a Mirror SID FEC. The IP
         address is encoded as described above in this section.<a href="#section-2.5.1-10.5.2.5" class="pilcrow">¶</a>
</li>
              </ul>
</li>
            <li id="section-2.5.1-10.6">Select the FEC with the smallest numerical value.<a href="#section-2.5.1-10.6" class="pilcrow">¶</a>
</li>
          </ul>
<p id="section-2.5.1-11">
   The numerical values mentioned in this section are for guidance only.
   If other numerical values are used, then the other numerical values
   <span class="bcp14">MUST</span> maintain the same numerical ordering among different SR FECs.<a href="#section-2.5.1-11" class="pilcrow">¶</a></p>
</section>
</div>
<div id="convert-section-2.5.2">
<section id="section-2.5.2">
          <h4 id="name-redistribution-between-rout">
<a href="#section-2.5.2" class="section-number selfRef">2.5.2. </a><a href="#name-redistribution-between-rout" class="section-name selfRef">Redistribution between Routing Protocol Instances</a>
          </h4>
<p id="section-2.5.2-1">
   The following rule <span class="bcp14">SHOULD</span> be applied when redistributing SIDs with
   prefixes between routing protocol instances:<a href="#section-2.5.2-1" class="pilcrow">¶</a></p>
<ul>
<li id="section-2.5.2-2.1">
              <p id="section-2.5.2-2.1.1">If the SRGB of the receiving instance is the same as the SRGB of the origin
       instance, then:<a href="#section-2.5.2-2.1.1" class="pilcrow">¶</a></p>
<ul>
<li id="section-2.5.2-2.1.2.1">the index is redistributed with the route.<a href="#section-2.5.2-2.1.2.1" class="pilcrow">¶</a>
</li>
              </ul>
</li>
            <li id="section-2.5.2-2.2">
              <p id="section-2.5.2-2.2.1">Else,<a href="#section-2.5.2-2.2.1" class="pilcrow">¶</a></p>
<ul>
<li id="section-2.5.2-2.2.2.1">the index is not redistributed and if the receiving instance
         decides to advertise an index with the redistributed route, it
         is the duty of the receiving instance to allocate a fresh
         index relative to its own SRGB. Note that in this case, the
         receiving instance <span class="bcp14">MUST</span> compute the local label it assigns to
         the route according to <a href="#convert-section-2.4" class="xref">Section 2.4</a> and install it in FIB.<a href="#section-2.5.2-2.2.2.1" class="pilcrow">¶</a>
</li>
              </ul>
</li>
          </ul>
<p id="section-2.5.2-3">
   It is outside the scope of this document to define local node
   behaviors that would allow the mapping of the original index into a new index
   in the receiving instance via the addition of an offset or other
   policy means.<a href="#section-2.5.2-3" class="pilcrow">¶</a></p>
<div id="convert-section-2.5.2.1">
<section id="section-2.5.2.1">
            <h5 id="name-illustration">
<a href="#section-2.5.2.1" class="section-number selfRef">2.5.2.1. </a><a href="#name-illustration" class="section-name selfRef">Illustration</a>
            </h5>
<div class="artwork art-text alignLeft" id="section-2.5.2.1-1">
<pre>
        A----IS-IS----B---OSPF----C-192.0.2.1/32 (20001)</pre><a href="#section-2.5.2.1-1" class="pilcrow">¶</a>
</div>
<p id="section-2.5.2.1-2">Consider the simple topology above, where:<a href="#section-2.5.2.1-2" class="pilcrow">¶</a></p>
<ul>
<li id="section-2.5.2.1-3.1">A and B are in the IS-IS domain with SRGB = [16000-17000]<a href="#section-2.5.2.1-3.1" class="pilcrow">¶</a>
</li>
              <li id="section-2.5.2.1-3.2">B and C are in the OSPF domain with SRGB = [20000-21000]<a href="#section-2.5.2.1-3.2" class="pilcrow">¶</a>
</li>
              <li id="section-2.5.2.1-3.3">B redistributes 192.0.2.1/32 into the IS-IS domain<a href="#section-2.5.2.1-3.3" class="pilcrow">¶</a>
</li>
            </ul>
<p id="section-2.5.2.1-4">In this case, A learns 192.0.2.1/32 as an IP leaf connected to B, which is
      usual for IP prefix redistribution<a href="#section-2.5.2.1-4" class="pilcrow">¶</a></p>
<p id="section-2.5.2.1-5">However, according to the redistribution rule above, B
      decides not to advertise any index with 192.0.2.1/32 into IS-IS
      because the SRGB is not the same.<a href="#section-2.5.2.1-5" class="pilcrow">¶</a></p>
</section>
</div>
<div id="convert-section-2.5.2.2">
<section id="section-2.5.2.2">
            <h5 id="name-illustration-2">
<a href="#section-2.5.2.2" class="section-number selfRef">2.5.2.2. </a><a href="#name-illustration-2" class="section-name selfRef">Illustration 2</a>
            </h5>
<p id="section-2.5.2.2-1">
   Consider the example in the illustration described in <a href="#convert-section-2.5.2.1" class="xref">Section 2.5.2.1</a>.<a href="#section-2.5.2.2-1" class="pilcrow">¶</a></p>
<p id="section-2.5.2.2-2">
   When router B redistributes the prefix 192.0.2.1/32, router B decides
   to allocate and advertise the same index 1 with the prefix
   192.0.2.1/32.<a href="#section-2.5.2.2-2" class="pilcrow">¶</a></p>
<p id="section-2.5.2.2-3">
   Within the SRGB of the IS-IS domain, index 1 corresponds to the local
   label 16001. Hence, according to the redistribution rule above, router B
      programs the incoming label 16001 in its FIB to match traffic
      arriving from the IS-IS domain destined to the prefix
      192.0.2.1/32.<a href="#section-2.5.2.2-3" class="pilcrow">¶</a></p>
</section>
</div>
</section>
</div>
</section>
</div>
<div id="convert-section-2.6">
<section id="section-2.6">
        <h3 id="name-effect-of-incoming-label-co">
<a href="#section-2.6" class="section-number selfRef">2.6. </a><a href="#name-effect-of-incoming-label-co" class="section-name selfRef">Effect of Incoming Label Collision on Outgoing Label Programming</a>
        </h3>
<p id="section-2.6-1">

   When determining what outgoing label to use, the ingress node
   that pushes new segments, and hence a stack of MPLS labels, <span class="bcp14">MUST</span> use, for
   a given FEC, the label that has been selected by the node
   receiving the packet with that label exposed as the top label. So in case
   of incoming label collision on this receiving node, the ingress node
   <span class="bcp14">MUST</span> resolve this collision by using this same "Incoming Label Collision resolution procedure" and by using the data of the receiving node.<a href="#section-2.6-1" class="pilcrow">¶</a></p>
<p id="section-2.6-2">
   In the general case, the ingress node may not have the exact same
   data as the receiving node, so the result may be different. This is
   under the responsibility of the network operator. But in a typical
   case, e.g., where a centralized node or a distributed link-state IGP
   is used, all nodes would have the same database. However, to minimize
   the chance of misforwarding, a FEC that loses its incoming label to
   the tiebreaking rules specified in <a href="#convert-section-2.5" class="xref">Section 2.5</a> <span class="bcp14">MUST NOT</span> be
   installed in FIB with an outgoing Segment Routing label based on the
   SID corresponding to the lost incoming label.<a href="#section-2.6-2" class="pilcrow">¶</a></p>
<p id="section-2.6-3">
   Examples for the behavior specified in this section can be found in
   <a href="#convert-section-a.3" class="xref">Appendix A.3</a>.<a href="#section-2.6-3" class="pilcrow">¶</a></p>
</section>
</div>
<div id="convert-section-2.7">
<section id="section-2.7">
        <h3 id="name-push-continue-and-next">
<a href="#section-2.7" class="section-number selfRef">2.7. </a><a href="#name-push-continue-and-next" class="section-name selfRef">PUSH, CONTINUE, and NEXT</a>
        </h3>
<p id="section-2.7-1">
   PUSH, NEXT, and CONTINUE are operations applied by the forwarding
   plane. The specifications of these operations can be found in
   <span>[<a href="#RFC8402" class="xref">RFC8402</a>]</span>. This subsection specifies how to implement each of these
   operations in the MPLS forwarding plane.<a href="#section-2.7-1" class="pilcrow">¶</a></p>
<div id="convert-section-2.7.1">
<section id="section-2.7.1">
          <h4 id="name-push">
<a href="#section-2.7.1" class="section-number selfRef">2.7.1. </a><a href="#name-push" class="section-name selfRef">PUSH</a>
          </h4>
<p id="section-2.7.1-1">
   As described in <span>[<a href="#RFC8402" class="xref">RFC8402</a>]</span>, PUSH corresponds to pushing one or more
   labels on top of an incoming packet then sending it out of a
   particular physical interface or virtual interface, such as a UDP
   tunnel <span>[<a href="#RFC7510" class="xref">RFC7510</a>]</span> or the Layer 2 Tunneling Protocol version 3 (L2TPv3) <span>[<a href="#RFC4817" class="xref">RFC4817</a>]</span>, towards a particular
   next hop.

 When pushing labels onto a packet's label stack, the Time-to-Live
   (TTL) field <span>[<a href="#RFC3032" class="xref">RFC3032</a>]</span> <span>[<a href="#RFC3443" class="xref">RFC3443</a>]</span> and the Traffic Class (TC)
   field <span>[<a href="#RFC3032" class="xref">RFC3032</a>]</span> <span>[<a href="#RFC5462" class="xref">RFC5462</a>]</span> of each label stack entry must, of
   course, be set.  This document does not specify any set of rules for
   setting these fields; that is a matter of local policy. Sections <a href="#convert-section-2.10" class="xref">2.10</a> and <a href="#convert-section-2.11" class="xref">2.11</a> specify additional details about forwarding
   behavior.<a href="#section-2.7.1-1" class="pilcrow">¶</a></p>
</section>
</div>
<div id="convert-section-2.7.2">
<section id="section-2.7.2">
          <h4 id="name-continue">
<a href="#section-2.7.2" class="section-number selfRef">2.7.2. </a><a href="#name-continue" class="section-name selfRef">CONTINUE</a>
          </h4>
<p id="section-2.7.2-1">
   As described in <span>[<a href="#RFC8402" class="xref">RFC8402</a>]</span>, the CONTINUE operation corresponds to
   swapping the incoming label with an outgoing label. The value of the
   outgoing label is calculated as specified in Sections <a href="#convert-section-2.10" class="xref">2.10</a> and <a href="#convert-section-2.11" class="xref">2.11</a>.<a href="#section-2.7.2-1" class="pilcrow">¶</a></p>
</section>
</div>
<div id="convert-section-2.7.3">
<section id="section-2.7.3">
          <h4 id="name-next">
<a href="#section-2.7.3" class="section-number selfRef">2.7.3. </a><a href="#name-next" class="section-name selfRef">NEXT</a>
          </h4>
<p id="section-2.7.3-1">
   As described in <span>[<a href="#RFC8402" class="xref">RFC8402</a>]</span>, NEXT corresponds to popping the topmost
   label. The action before and/or after the popping depends on the
   instruction associated with the active SID on the received packet
   prior to the popping. For example, suppose the active SID in the
   received packet was an Adj-SID <span>[<a href="#RFC8402" class="xref">RFC8402</a>]</span>; on receiving the
   packet, the node applies the NEXT operation, which corresponds to popping
   the topmost label, and then sends the packet out of the physical or
   virtual interface (e.g., the UDP tunnel <span>[<a href="#RFC7510" class="xref">RFC7510</a>]</span> or L2TPv3 tunnel
   <span>[<a href="#RFC4817" class="xref">RFC4817</a>]</span>) towards the next hop corresponding to the Adj-SID.<a href="#section-2.7.3-1" class="pilcrow">¶</a></p>
<div id="convert-section-2.7.3.1">
<section id="section-2.7.3.1">
            <h5 id="name-mirror-sid">
<a href="#section-2.7.3.1" class="section-number selfRef">2.7.3.1. </a><a href="#name-mirror-sid" class="section-name selfRef">Mirror SID</a>
            </h5>
<p id="section-2.7.3.1-1">
   If the active SID in the received packet was a Mirror SID (see <span>[<a href="#RFC8402" class="xref">RFC8402</a>], <a href="https://www.rfc-editor.org/rfc/rfc8402#section-5.1" class="relref">Section 5.1</a></span>) allocated by the receiving router, the receiving
   router applies the NEXT operation, which corresponds to popping the topmost
   label, and then performs a lookup using the contents of the packet
   after popping the outermost label in the mirrored forwarding table. 
   The method by which the lookup is made, and/or the actions applied to
   the packet after the lookup in the mirror table, depends on the
   contents of the packet and the mirror table. Note that the packet
   exposed after popping the topmost label may or may not be an MPLS
   packet. A Mirror SID can be viewed as a generalization of the context
   label in <span>[<a href="#RFC5331" class="xref">RFC5331</a>]</span> because a Mirror SID does not make any
   assumptions about the packet underneath the top label.<a href="#section-2.7.3.1-1" class="pilcrow">¶</a></p>
</section>
</div>
</section>
</div>
</section>
</div>
<div id="convert-section-2.8">
<section id="section-2.8">
        <h3 id="name-mpls-label-downloaded-to-th">
<a href="#section-2.8" class="section-number selfRef">2.8. </a><a href="#name-mpls-label-downloaded-to-th" class="section-name selfRef">MPLS Label Downloaded to the FIB for Global and Local SIDs</a>
        </h3>
<p id="section-2.8-1">
   The label corresponding to the global SID "Si", which is represented by the
   global index "I" and downloaded to the FIB, is used to match packets whose
   active segment (and hence topmost label) is "Si". The value of this
   label is calculated as specified in <a href="#convert-section-2.4" class="xref">Section 2.4</a>.<a href="#section-2.8-1" class="pilcrow">¶</a></p>
<p id="section-2.8-2">
   For Local SIDs, the MCC is responsible for downloading the correct
   label value to the FIB. For example, an IGP with SR extensions <span>[<a href="#RFC8667" class="xref">RFC8667</a>]</span> <span>[<a href="#RFC8665" class="xref">RFC8665</a>]</span> downloads the MPLS label corresponding to an Adj-SID <span>[<a href="#RFC8402" class="xref">RFC8402</a>]</span>.<a href="#section-2.8-2" class="pilcrow">¶</a></p>
</section>
</div>
<div id="convert-section-2.9">
<section id="section-2.9">
        <h3 id="name-active-segment">
<a href="#section-2.9" class="section-number selfRef">2.9. </a><a href="#name-active-segment" class="section-name selfRef">Active Segment</a>
        </h3>
<p id="section-2.9-1">
   When instantiated in the MPLS domain, the active segment on a packet
   corresponds to the topmost label and is calculated
   according to the procedure specified in Sections <a href="#convert-section-2.10" class="xref">2.10</a> and <a href="#convert-section-2.11" class="xref">2.11</a>. When
   arriving at a node, the topmost label corresponding to the active SID
   matches the MPLS label downloaded to the FIB as specified in <a href="#convert-section-2.4" class="xref">Section 2.4</a>.<a href="#section-2.9-1" class="pilcrow">¶</a></p>
</section>
</div>
<div id="convert-section-2.10">
<section id="section-2.10">
        <h3 id="name-forwarding-behavior-for-glo">
<a href="#section-2.10" class="section-number selfRef">2.10. </a><a href="#name-forwarding-behavior-for-glo" class="section-name selfRef">Forwarding Behavior for Global SIDs</a>
        </h3>
<p id="section-2.10-1">
   This section specifies the forwarding behavior, including the calculation
   of outgoing labels, that corresponds to a global SID when applying
   the PUSH, CONTINUE, and NEXT operations in the MPLS forwarding plane.<a href="#section-2.10-1" class="pilcrow">¶</a></p>
<p id="section-2.10-2">
   This document covers the calculation of the outgoing label for the
   top label only. The case where the outgoing label is not the top
   label and is part of a stack of labels that instantiates a routing
   policy or a traffic-engineering tunnel is outside the scope of this
   document and may be covered in other documents such as <span>[<a href="#ROUTING-POLICY" class="xref">ROUTING-POLICY</a>]</span>.<a href="#section-2.10-2" class="pilcrow">¶</a></p>
<div id="convert-section-2.10.1">
<section id="section-2.10.1">
          <h4 id="name-forwarding-for-push-and-con">
<a href="#section-2.10.1" class="section-number selfRef">2.10.1. </a><a href="#name-forwarding-for-push-and-con" class="section-name selfRef">Forwarding for PUSH and CONTINUE of Global SIDs</a>
          </h4>
<p id="section-2.10.1-1">
  Suppose an MCC on router "R0" determines that, before sending the packet towards a neighbor "N", the PUSH or CONTINUE
  operation is to be applied to an incoming packet related to the global SID "Si".
  SID  "Si" is represented by the global index "I" and owned by the router Ri.  Neighbor "N" may be directly
  connected to "R0" through either a physical or a virtual interface (e.g., 
  UDP tunnel <span>[<a href="#RFC7510" class="xref">RFC7510</a>]</span> or L2TPv3 tunnel <span>[<a href="#RFC4817" class="xref">RFC4817</a>]</span>).<a href="#section-2.10.1-1" class="pilcrow">¶</a></p>
<p id="section-2.10.1-2">
   The method by which the MCC on router "R0" determines that the PUSH or
   CONTINUE operation must be applied using the SID "Si" is beyond the
   scope of this document.

   An example of a method to determine the SID
   "Si" for the PUSH operation is the case where IS-IS <span>[<a href="#RFC8667" class="xref">RFC8667</a>]</span> 
   receives the Prefix-SID "Si" sub-TLV
   advertised with the prefix "P/m" in TLV 135, and the prefix "P/m" is the longest matching 
   network prefix for the incoming IPv4 packet.<a href="#section-2.10.1-2" class="pilcrow">¶</a></p>
<p id="section-2.10.1-3">
   For the CONTINUE operation, an example of a method used to determine the SID
   "Si" is the case where IS-IS <span>[<a href="#RFC8667" class="xref">RFC8667</a>]</span> receives the Prefix-SID "Si" sub-TLV advertised with
   prefix "P" in TLV 135, and the top label of the incoming packet
   matches the MPLS label in the FIB corresponding to the SID "Si" on
   router "R0".<a href="#section-2.10.1-3" class="pilcrow">¶</a></p>
<p id="section-2.10.1-4">
   The forwarding behavior for PUSH and CONTINUE corresponding to the
   SID "Si" is as follows:<a href="#section-2.10.1-4" class="pilcrow">¶</a></p>
<ul>
<li id="section-2.10.1-5.1">
              <p id="section-2.10.1-5.1.1">If neighbor "N" does not support SR or advertises an invalid
       SRGB or a SRGB that is too small for the SID "Si", then:<a href="#section-2.10.1-5.1.1" class="pilcrow">¶</a></p>
<ul>
<li id="section-2.10.1-5.1.2.1">If it is possible to send the packet towards neighbor "N"
         using standard MPLS forwarding behavior as specified in
         <span>[<a href="#RFC3031" class="xref">RFC3031</a>]</span> and <span>[<a href="#RFC3032" class="xref">RFC3032</a>]</span>, forward the packet. The method
         by which a router decides whether it is possible to send the
         packet to "N" or not is beyond the scope of this document. For
         example, the router "R0" can use the downstream label
         determined by another MCC, such as LDP <span>[<a href="#RFC5036" class="xref">RFC5036</a>]</span>, to send the
         packet.<a href="#section-2.10.1-5.1.2.1" class="pilcrow">¶</a>
</li>
                <li id="section-2.10.1-5.1.2.2">Else, if there are other usable next hops, use them to forward the incoming packet. 
         The method by which the
         router "R0" decides on the possibility of using other next hops
         is beyond the scope of this document. For example, the
         MCC on "R0" may chose the send an IPv4 packet without pushing
         any label to another next hop.<a href="#section-2.10.1-5.1.2.2" class="pilcrow">¶</a>
</li>
                <li id="section-2.10.1-5.1.2.3">Otherwise, drop the packet.<a href="#section-2.10.1-5.1.2.3" class="pilcrow">¶</a>
</li>
              </ul>
</li>
            <li id="section-2.10.1-5.2">
              <p id="section-2.10.1-5.2.1">Else,<a href="#section-2.10.1-5.2.1" class="pilcrow">¶</a></p>
<ul>
<li id="section-2.10.1-5.2.2.1">
                  Calculate the outgoing label as specified in <a href="#convert-section-2.4" class="xref">Section 2.4</a> using
          the SRGB of neighbor "N".<a href="#section-2.10.1-5.2.2.1" class="pilcrow">¶</a>
</li>
                <li id="section-2.10.1-5.2.2.2">
                  <p id="section-2.10.1-5.2.2.2.1">Determine the outgoing label stack<a href="#section-2.10.1-5.2.2.2.1" class="pilcrow">¶</a></p>
<ul>
<li id="section-2.10.1-5.2.2.2.2.1">
                      <p id="section-2.10.1-5.2.2.2.2.1.1">If the operation is PUSH:<a href="#section-2.10.1-5.2.2.2.2.1.1" class="pilcrow">¶</a></p>
<ul>
<li id="section-2.10.1-5.2.2.2.2.1.2.1">Push the calculated label according to the MPLS label
              pushing rules specified in <span>[<a href="#RFC3032" class="xref">RFC3032</a>]</span>.<a href="#section-2.10.1-5.2.2.2.2.1.2.1" class="pilcrow">¶</a>
</li>
                      </ul>
</li>
                    <li id="section-2.10.1-5.2.2.2.2.2">
                      <p id="section-2.10.1-5.2.2.2.2.2.1">Else,<a href="#section-2.10.1-5.2.2.2.2.2.1" class="pilcrow">¶</a></p>
<ul>
<li id="section-2.10.1-5.2.2.2.2.2.2.1">swap the incoming label with the calculated label
           according to the label-swapping rules in <span>[<a href="#RFC3031" class="xref">RFC3031</a>]</span>.<a href="#section-2.10.1-5.2.2.2.2.2.2.1" class="pilcrow">¶</a>
</li>
                      </ul>
</li>
                    <li id="section-2.10.1-5.2.2.2.2.3">Send the packet towards neighbor "N".<a href="#section-2.10.1-5.2.2.2.2.3" class="pilcrow">¶</a>
</li>
                  </ul>
</li>
              </ul>
</li>
          </ul>
</section>
</div>
<div id="convert-section-2.10.2">
<section id="section-2.10.2">
          <h4 id="name-forwarding-for-the-next-ope">
<a href="#section-2.10.2" class="section-number selfRef">2.10.2. </a><a href="#name-forwarding-for-the-next-ope" class="section-name selfRef">Forwarding for the NEXT Operation for Global SIDs</a>
          </h4>
<p id="section-2.10.2-1">
   As specified in <a href="#convert-section-2.7.3" class="xref">Section 2.7.3</a>, the NEXT operation corresponds to popping
   the topmost label. The forwarding behavior is as follows:<a href="#section-2.10.2-1" class="pilcrow">¶</a></p>
<ul>
<li id="section-2.10.2-2.1">Pop the topmost label<a href="#section-2.10.2-2.1" class="pilcrow">¶</a>
</li>
            <li id="section-2.10.2-2.2">Apply the instruction associated with the incoming label that has
      been popped<a href="#section-2.10.2-2.2" class="pilcrow">¶</a>
</li>
          </ul>
<p id="section-2.10.2-3">
   The action on the packet after popping the topmost label depends on
   the instruction associated with the incoming label as well as the
   contents of the packet right underneath the top label that was
   popped. Examples of the NEXT operation are described in <a href="#convert-section-a.1" class="xref">Appendix A.1</a><a href="#section-2.10.2-3" class="pilcrow">¶</a></p>
</section>
</div>
</section>
</div>
<div id="convert-section-2.11">
<section id="section-2.11">
        <h3 id="name-forwarding-behavior-for-loc">
<a href="#section-2.11" class="section-number selfRef">2.11. </a><a href="#name-forwarding-behavior-for-loc" class="section-name selfRef">Forwarding Behavior for Local SIDs</a>
        </h3>
<p id="section-2.11-1">
   This section specifies the forwarding behavior for Local SIDs when SR
   is instantiated over the MPLS forwarding plane.<a href="#section-2.11-1" class="pilcrow">¶</a></p>
<div id="convert-section-2.11.1">
<section id="section-2.11.1">
          <h4 id="name-forwarding-for-the-push-ope">
<a href="#section-2.11.1" class="section-number selfRef">2.11.1. </a><a href="#name-forwarding-for-the-push-ope" class="section-name selfRef">Forwarding for the PUSH Operation on Local SIDs</a>
          </h4>
<p id="section-2.11.1-1">
   Suppose an MCC on router "R0" determines that the PUSH operation is to
   be applied to an incoming packet using the Local SID "Si" before
   sending the packet towards neighbor "N", which is directly connected to R0
   through a physical or virtual interface such as a UDP tunnel <span>[<a href="#RFC7510" class="xref">RFC7510</a>]</span>
   or L2TPv3 tunnel <span>[<a href="#RFC4817" class="xref">RFC4817</a>]</span>.<a href="#section-2.11.1-1" class="pilcrow">¶</a></p>
<p id="section-2.11.1-2">
   An example of such a Local SID is an Adj-SID allocated and advertised
   by IS-IS <span>[<a href="#RFC8667" class="xref">RFC8667</a>]</span>. The method by
   which the MCC on "R0" determines that the PUSH operation is to be applied
   to the incoming packet is beyond the scope of this document. An
   example of such a method is the backup path used to protect against a
   failure using TI-LFA <span>[<a href="#FAST-REROUTE" class="xref">FAST-REROUTE</a>]</span>.<a href="#section-2.11.1-2" class="pilcrow">¶</a></p>
<p id="section-2.11.1-3">
   As mentioned in <span>[<a href="#RFC8402" class="xref">RFC8402</a>]</span>, a Local SID is specified by an MPLS label.
   Hence, the PUSH operation for a Local SID is identical to the label push
   operation using any MPLS label <span>[<a href="#RFC3031" class="xref">RFC3031</a>]</span>. The forwarding action after
   pushing the MPLS label corresponding to the Local SID is also
   determined by the MCC. For example, if the PUSH operation was done to
   forward a packet over a backup path calculated using TI-LFA, then the
   forwarding action may be sending the packet to a certain neighbor
   that will in turn continue to forward the packet along the backup
   path.<a href="#section-2.11.1-3" class="pilcrow">¶</a></p>
</section>
</div>
<div id="convert-section-2.11.2">
<section id="section-2.11.2">
          <h4 id="name-forwarding-for-the-continue">
<a href="#section-2.11.2" class="section-number selfRef">2.11.2. </a><a href="#name-forwarding-for-the-continue" class="section-name selfRef">Forwarding for the CONTINUE Operation for Local SIDs</a>
          </h4>
<p id="section-2.11.2-1">
   A Local SID on router "R0" corresponds to a local label.
   In such a
   scenario, the outgoing label towards next hop "N" is determined by
   the MCC running on the router "R0", and the forwarding behavior for the
   CONTINUE operation is identical to the swap operation on an
   MPLS label <span>[<a href="#RFC3031" class="xref">RFC3031</a>]</span>.<a href="#section-2.11.2-1" class="pilcrow">¶</a></p>
</section>
</div>
<div id="convert-section-2.11.3">
<section id="section-2.11.3">
          <h4 id="name-outgoing-label-for-the-next">
<a href="#section-2.11.3" class="section-number selfRef">2.11.3. </a><a href="#name-outgoing-label-for-the-next" class="section-name selfRef">Outgoing Label for the NEXT Operation for Local SIDs</a>
          </h4>
<p id="section-2.11.3-1">
  The  NEXT operation for Local SIDs is identical to the NEXT operation for
   global SIDs as specified in <a href="#convert-section-2.10.2" class="xref">Section 2.10.2</a>.<a href="#section-2.11.3-1" class="pilcrow">¶</a></p>
</section>
</div>
</section>
</div>
</section>
</div>
<div id="convert-section-3">
<section id="section-3">
      <h2 id="name-iana-considerations">
<a href="#section-3" class="section-number selfRef">3. </a><a href="#name-iana-considerations" class="section-name selfRef">IANA Considerations</a>
      </h2>
<p id="section-3-1">
 This document has no IANA actions.<a href="#section-3-1" class="pilcrow">¶</a></p>
</section>
</div>
<div id="convert-section-4">
<section id="section-4">
      <h2 id="name-manageability-consideration">
<a href="#section-4" class="section-number selfRef">4. </a><a href="#name-manageability-consideration" class="section-name selfRef">Manageability Considerations</a>
      </h2>
<p id="section-4-1">
   This document describes the applicability of Segment Routing over the
   MPLS data plane.  Segment Routing does not introduce any change in
   the MPLS data plane.  Manageability considerations described in
   <span>[<a href="#RFC8402" class="xref">RFC8402</a>]</span> apply to the MPLS data plane when used with Segment
   Routing. SR Operations, Administration, and Maintenance (OAM) use cases for the MPLS data plane are defined in
   <span>[<a href="#RFC8403" class="xref">RFC8403</a>]</span>.  SR OAM procedures for the MPLS data plane are defined in
   <span>[<a href="#RFC8287" class="xref">RFC8287</a>]</span>.<a href="#section-4-1" class="pilcrow">¶</a></p>
</section>
</div>
<div id="convert-section-5">
<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">
   This document does not introduce additional security requirements and
   mechanisms other than the ones described in <span>[<a href="#RFC8402" class="xref">RFC8402</a>]</span>.<a href="#section-5-1" class="pilcrow">¶</a></p>
</section>
</div>
<section id="section-6">
      <h2 id="name-references">
<a href="#section-6" class="section-number selfRef">6. </a><a href="#name-references" class="section-name selfRef">References</a>
      </h2>
<section id="section-6.1">
        <h3 id="name-normative-references">
<a href="#section-6.1" class="section-number selfRef">6.1. </a><a href="#name-normative-references" class="section-name selfRef">Normative References</a>
        </h3>
<dl class="references">
<dt id="RFC2119">[RFC2119]</dt>
        <dd>
<span class="refAuthor">Bradner, S.</span>, <span class="refTitle">"Key words for use in RFCs to Indicate Requirement Levels"</span>, <span class="seriesInfo">BCP 14</span>, <span class="seriesInfo">RFC 2119</span>, <span class="seriesInfo">DOI 10.17487/RFC2119</span>, <time datetime="1997-03">March 1997</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc2119">https://www.rfc-editor.org/info/rfc2119</a>&gt;</span>. </dd>
<dt id="RFC3031">[RFC3031]</dt>
        <dd>
<span class="refAuthor">Rosen, E.</span><span class="refAuthor">, Viswanathan, A.</span><span class="refAuthor">, and R. Callon</span>, <span class="refTitle">"Multiprotocol Label Switching Architecture"</span>, <span class="seriesInfo">RFC 3031</span>, <span class="seriesInfo">DOI 10.17487/RFC3031</span>, <time datetime="2001-01">January 2001</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc3031">https://www.rfc-editor.org/info/rfc3031</a>&gt;</span>. </dd>
<dt id="RFC3032">[RFC3032]</dt>
        <dd>
<span class="refAuthor">Rosen, E.</span><span class="refAuthor">, Tappan, D.</span><span class="refAuthor">, Fedorkow, G.</span><span class="refAuthor">, Rekhter, Y.</span><span class="refAuthor">, Farinacci, D.</span><span class="refAuthor">, Li, T.</span><span class="refAuthor">, and A. Conta</span>, <span class="refTitle">"MPLS Label Stack Encoding"</span>, <span class="seriesInfo">RFC 3032</span>, <span class="seriesInfo">DOI 10.17487/RFC3032</span>, <time datetime="2001-01">January 2001</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc3032">https://www.rfc-editor.org/info/rfc3032</a>&gt;</span>. </dd>
<dt id="RFC3443">[RFC3443]</dt>
        <dd>
<span class="refAuthor">Agarwal, P.</span><span class="refAuthor"> and B. Akyol</span>, <span class="refTitle">"Time To Live (TTL) Processing in Multi-Protocol Label Switching (MPLS) Networks"</span>, <span class="seriesInfo">RFC 3443</span>, <span class="seriesInfo">DOI 10.17487/RFC3443</span>, <time datetime="2003-01">January 2003</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc3443">https://www.rfc-editor.org/info/rfc3443</a>&gt;</span>. </dd>
<dt id="RFC5462">[RFC5462]</dt>
        <dd>
<span class="refAuthor">Andersson, L.</span><span class="refAuthor"> and R. Asati</span>, <span class="refTitle">"Multiprotocol Label Switching (MPLS) Label Stack Entry: "EXP" Field Renamed to "Traffic Class" Field"</span>, <span class="seriesInfo">RFC 5462</span>, <span class="seriesInfo">DOI 10.17487/RFC5462</span>, <time datetime="2009-02">February 2009</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc5462">https://www.rfc-editor.org/info/rfc5462</a>&gt;</span>. </dd>
<dt id="RFC7274">[RFC7274]</dt>
        <dd>
<span class="refAuthor">Kompella, K.</span><span class="refAuthor">, Andersson, L.</span><span class="refAuthor">, and A. Farrel</span>, <span class="refTitle">"Allocating and Retiring Special-Purpose MPLS Labels"</span>, <span class="seriesInfo">RFC 7274</span>, <span class="seriesInfo">DOI 10.17487/RFC7274</span>, <time datetime="2014-06">June 2014</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc7274">https://www.rfc-editor.org/info/rfc7274</a>&gt;</span>. </dd>
<dt id="RFC8174">[RFC8174]</dt>
        <dd>
<span class="refAuthor">Leiba, B.</span>, <span class="refTitle">"Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words"</span>, <span class="seriesInfo">BCP 14</span>, <span class="seriesInfo">RFC 8174</span>, <span class="seriesInfo">DOI 10.17487/RFC8174</span>, <time datetime="2017-05">May 2017</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8174">https://www.rfc-editor.org/info/rfc8174</a>&gt;</span>. </dd>
<dt id="RFC8402">[RFC8402]</dt>
      <dd>
<span class="refAuthor">Filsfils, C., Ed.</span><span class="refAuthor">, Previdi, S., Ed.</span><span class="refAuthor">, Ginsberg, L.</span><span class="refAuthor">, Decraene, B.</span><span class="refAuthor">, Litkowski, S.</span><span class="refAuthor">, and R. Shakir</span>, <span class="refTitle">"Segment Routing Architecture"</span>, <span class="seriesInfo">RFC 8402</span>, <span class="seriesInfo">DOI 10.17487/RFC8402</span>, <time datetime="2018-07">July 2018</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8402">https://www.rfc-editor.org/info/rfc8402</a>&gt;</span>. </dd>
</dl>
</section>
<section id="section-6.2">
        <h3 id="name-informative-references">
<a href="#section-6.2" class="section-number selfRef">6.2. </a><a href="#name-informative-references" class="section-name selfRef">Informative References</a>
        </h3>
<dl class="references">
<dt id="FAST-REROUTE">[FAST-REROUTE]</dt>
        <dd>
<span class="refAuthor">Litkowski, S.</span><span class="refAuthor">, Bashandy, A.</span><span class="refAuthor">, Filsfils, C.</span><span class="refAuthor">, Decraene, B.</span><span class="refAuthor">, Francois, P.</span><span class="refAuthor">, Voyer, D.</span><span class="refAuthor">, Clad, F.</span><span class="refAuthor">, and P. Camarillo</span>, <span class="refTitle">"Topology Independent Fast Reroute using Segment Routing"</span>, <span class="refContent">Work in Progress</span>, <span class="seriesInfo">Internet-Draft, draft-ietf-rtgwg-segment-routing-ti-lfa-01</span>, <time datetime="2019-03-05">5 March 2019</time>, <span>&lt;<a href="https://tools.ietf.org/html/draft-ietf-rtgwg-segment-routing-ti-lfa-01">https://tools.ietf.org/html/draft-ietf-rtgwg-segment-routing-ti-lfa-01</a>&gt;</span>. </dd>
<dt id="RFC4817">[RFC4817]</dt>
        <dd>
<span class="refAuthor">Townsley, M.</span><span class="refAuthor">, Pignataro, C.</span><span class="refAuthor">, Wainner, S.</span><span class="refAuthor">, Seely, T.</span><span class="refAuthor">, and J. Young</span>, <span class="refTitle">"Encapsulation of MPLS over Layer 2 Tunneling Protocol Version 3"</span>, <span class="seriesInfo">RFC 4817</span>, <span class="seriesInfo">DOI 10.17487/RFC4817</span>, <time datetime="2007-03">March 2007</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc4817">https://www.rfc-editor.org/info/rfc4817</a>&gt;</span>. </dd>
<dt id="RFC5036">[RFC5036]</dt>
        <dd>
<span class="refAuthor">Andersson, L., Ed.</span><span class="refAuthor">, Minei, I., Ed.</span><span class="refAuthor">, and B. Thomas, Ed.</span>, <span class="refTitle">"LDP Specification"</span>, <span class="seriesInfo">RFC 5036</span>, <span class="seriesInfo">DOI 10.17487/RFC5036</span>, <time datetime="2007-10">October 2007</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc5036">https://www.rfc-editor.org/info/rfc5036</a>&gt;</span>. </dd>
<dt id="RFC5331">[RFC5331]</dt>
        <dd>
<span class="refAuthor">Aggarwal, R.</span><span class="refAuthor">, Rekhter, Y.</span><span class="refAuthor">, and E. Rosen</span>, <span class="refTitle">"MPLS Upstream Label Assignment and Context-Specific Label Space"</span>, <span class="seriesInfo">RFC 5331</span>, <span class="seriesInfo">DOI 10.17487/RFC5331</span>, <time datetime="2008-08">August 2008</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc5331">https://www.rfc-editor.org/info/rfc5331</a>&gt;</span>. </dd>
<dt id="RFC7510">[RFC7510]</dt>
        <dd>
<span class="refAuthor">Xu, X.</span><span class="refAuthor">, Sheth, N.</span><span class="refAuthor">, Yong, L.</span><span class="refAuthor">, Callon, R.</span><span class="refAuthor">, and D. Black</span>, <span class="refTitle">"Encapsulating MPLS in UDP"</span>, <span class="seriesInfo">RFC 7510</span>, <span class="seriesInfo">DOI 10.17487/RFC7510</span>, <time datetime="2015-04">April 2015</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc7510">https://www.rfc-editor.org/info/rfc7510</a>&gt;</span>. </dd>
<dt id="RFC7855">[RFC7855]</dt>
        <dd>
<span class="refAuthor">Previdi, S., Ed.</span><span class="refAuthor">, Filsfils, C., Ed.</span><span class="refAuthor">, Decraene, B.</span><span class="refAuthor">, Litkowski, S.</span><span class="refAuthor">, Horneffer, M.</span><span class="refAuthor">, and R. Shakir</span>, <span class="refTitle">"Source Packet Routing in Networking (SPRING) Problem Statement and Requirements"</span>, <span class="seriesInfo">RFC 7855</span>, <span class="seriesInfo">DOI 10.17487/RFC7855</span>, <time datetime="2016-05">May 2016</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc7855">https://www.rfc-editor.org/info/rfc7855</a>&gt;</span>. </dd>
<dt id="RFC8287">[RFC8287]</dt>
        <dd>
<span class="refAuthor">Kumar, N., Ed.</span><span class="refAuthor">, Pignataro, C., Ed.</span><span class="refAuthor">, Swallow, G.</span><span class="refAuthor">, Akiya, N.</span><span class="refAuthor">, Kini, S.</span><span class="refAuthor">, and M. Chen</span>, <span class="refTitle">"Label Switched Path (LSP) Ping/Traceroute for Segment Routing (SR) IGP-Prefix and IGP-Adjacency Segment Identifiers (SIDs) with MPLS Data Planes"</span>, <span class="seriesInfo">RFC 8287</span>, <span class="seriesInfo">DOI 10.17487/RFC8287</span>, <time datetime="2017-12">December 2017</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8287">https://www.rfc-editor.org/info/rfc8287</a>&gt;</span>. </dd>
<dt id="RFC8403">[RFC8403]</dt>
        <dd>
<span class="refAuthor">Geib, R., Ed.</span><span class="refAuthor">, Filsfils, C.</span><span class="refAuthor">, Pignataro, C., Ed.</span><span class="refAuthor">, and N. Kumar</span>, <span class="refTitle">"A Scalable and Topology-Aware MPLS Data-Plane Monitoring System"</span>, <span class="seriesInfo">RFC 8403</span>, <span class="seriesInfo">DOI 10.17487/RFC8403</span>, <time datetime="2018-07">July 2018</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8403">https://www.rfc-editor.org/info/rfc8403</a>&gt;</span>. </dd>
<dt id="RFC8661">[RFC8661]</dt>
        <dd>
<span class="refAuthor">Bashandy, A., Ed.</span><span class="refAuthor">, Filsfils, C., Ed.</span><span class="refAuthor">, Previdi, S.</span><span class="refAuthor">, Decraene, B.</span><span class="refAuthor">, and S. Litkowski</span>, <span class="refTitle">"Segment Routing MPLS Interworking with LDP"</span>, <span class="seriesInfo">RFC 8661</span>, <span class="seriesInfo">DOI 10.17487/RFC8661</span>, <time datetime="2019-12">December 2019</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfC8661">https://www.rfc-editor.org/info/rfC8661</a>&gt;</span>. </dd>
<dt id="RFC8665">[RFC8665]</dt>
        <dd>
<span class="refAuthor">Psenak, P., Ed.</span><span class="refAuthor">, Previdi, S., Ed.</span><span class="refAuthor">, Filsfils, C.</span><span class="refAuthor">, Gredler, H.</span><span class="refAuthor">, Shakir, R.</span><span class="refAuthor">, Henderickx, W.</span><span class="refAuthor">, and J. Tantsura</span>, <span class="refTitle">"OSPF Extensions for Segment Routing"</span>, <span class="seriesInfo">RFC 8665</span>, <span class="seriesInfo">DOI 10.17487/RFC8665</span>, <time datetime="2019-12">December 2019</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8665">https://www.rfc-editor.org/info/rfc8665</a>&gt;</span>. </dd>
<dt id="RFC8666">[RFC8666]</dt>
        <dd>
<span class="refAuthor">Psenak, P., Ed.</span><span class="refAuthor"> and S. Previdi, Ed.</span>, <span class="refTitle">"OSPFv3 Extensions for Segment Routing"</span>, <span class="seriesInfo">RFC 8666</span>, <span class="seriesInfo">DOI 10.17487/RFC8666</span>, <time datetime="2019-12">December 2019</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8666">https://www.rfc-editor.org/info/rfc8666</a>&gt;</span>. </dd>
<dt id="RFC8667">[RFC8667]</dt>
        <dd>
<span class="refAuthor">Previdi, S., Ed.</span><span class="refAuthor">, Ginsberg, L., Ed.</span><span class="refAuthor">, Filsfils, C.</span><span class="refAuthor">, Bashandy, A.</span><span class="refAuthor">, Gredler, H.</span><span class="refAuthor">, and B. Decraene</span>, <span class="refTitle">"IS-IS Extensions for Segment Routing"</span>, <span class="seriesInfo">RFC 8667</span>, <span class="seriesInfo">DOI 10.17487/RFC8667</span>, <time datetime="2019-12">December 2019</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8667">https://www.rfc-editor.org/info/rfc8667</a>&gt;</span>. </dd>
<dt id="ROUTING-POLICY">[ROUTING-POLICY]</dt>
      <dd>
<span class="refAuthor">Filsfils, C.</span><span class="refAuthor">, Sivabalan, S.</span><span class="refAuthor">, Voyer, D.</span><span class="refAuthor">, Bogdanov, A.</span><span class="refAuthor">, and P. Mattes</span>, <span class="refTitle">"Segment Routing Policy Architecture"</span>, <span class="refContent">Work in Progress</span>, <span class="seriesInfo">Internet-Draft, draft-ietf-spring-segment-routing-policy-05</span>, <time datetime="2019-11-17">17 November 2019</time>, <span>&lt;<a href="https://tools.ietf.org/html/draft-ietf-spring-segment-routing-policy-05">https://tools.ietf.org/html/draft-ietf-spring-segment-routing-policy-05</a>&gt;</span>. </dd>
</dl>
</section>
</section>
<div id="convert-section-a">
<section id="section-appendix.a">
      <h2 id="name-examples">
<a href="#section-appendix.a" class="section-number selfRef">Appendix A. </a><a href="#name-examples" class="section-name selfRef">Examples</a>
      </h2>
<div id="convert-section-a.1">
<section id="section-a.1">
        <h2 id="name-igp-segment-examples">
<a href="#section-a.1" class="section-number selfRef">A.1. </a><a href="#name-igp-segment-examples" class="section-name selfRef">IGP Segment Examples</a>
        </h2>
<p id="section-a.1-1">
   Consider the network diagram of <a href="#fig1" class="xref">Figure 1</a> and the IP addresses and IGP
   segment allocations of <a href="#fig2" class="xref">Figure 2</a>. Assume that the network is running
   IS-IS with SR extensions <span>[<a href="#RFC8667" class="xref">RFC8667</a>]</span>,
   and all links have the same metric. The following examples can be
   constructed.<a href="#section-a.1-1" class="pilcrow">¶</a></p>
<span id="name-igp-segments-illustration"></span><div id="fig1">
<figure id="figure-1">
          <div class="artwork art-text alignLeft" id="section-a.1-2.1">
<pre>
                             +--------+
                            /          \
             R0-----R1-----R2----------R3-----R8
                           | \        / |
                           |  +--R4--+  |
                           |            |
                           +-----R5-----+</pre>
</div>
<figcaption><a href="#figure-1" class="selfRef">Figure 1</a>:
<a href="#name-igp-segments-illustration" class="selfRef">IGP Segments -- Illustration</a>
          </figcaption></figure>
</div>
<span id="name-igp-address-and-segment-all"></span><div id="fig2">
<figure id="figure-2">
          <div class="artwork art-text alignLeft" id="section-a.1-3.1">
<pre>
       +-----------------------------------------------------------+
       | IP addresses allocated by the operator:                   |
       |                      192.0.2.1/32 as a loopback of R1     |
       |                      192.0.2.2/32 as a loopback of R2     |
       |                      192.0.2.3/32 as a loopback of R3     |
       |                      192.0.2.4/32 as a loopback of R4     |
       |                      192.0.2.5/32 as a loopback of R5     |
       |                      192.0.2.8/32 as a loopback of R8     |
       |              198.51.100.9/32 as an anycast loopback of R4 |
       |              198.51.100.9/32 as an anycast loopback of R5 |
       |                                                           |
       | SRGB defined by the operator as [1000,5000]               |
       |                                                           |
       | Global IGP SID indices allocated by the operator:         |
       |                      1 allocated to 192.0.2.1/32          |
       |                      2 allocated to 192.0.2.2/32          |
       |                      3 allocated to 192.0.2.3/32          |
       |                      4 allocated to 192.0.2.4/32          |
       |                      8 allocated to 192.0.2.8/32          |
       |                   1009 allocated to 198.51.100.9/32       |
       |                                                           |
       | Local IGP SID allocated dynamically by R2                 |
       |                     for its "north" adjacency to R3: 9001 |
       |                     for its "east" adjacency to R3 : 9002 |
       |                     for its "south" adjacency to R3: 9003 |
       |                     for its only adjacency to R4   : 9004 |
       |                     for its only adjacency to R1   : 9005 |
       +-----------------------------------------------------------+</pre>
</div>
<figcaption><a href="#figure-2" class="selfRef">Figure 2</a>:
<a href="#name-igp-address-and-segment-all" class="selfRef">IGP Address and Segment Allocation -- Illustration</a>
          </figcaption></figure>
</div>
<p id="section-a.1-4">
   Suppose R1 wants to send IPv4 packet P1 to R8. In this case, R1
   needs to apply the PUSH operation to the IPv4 packet.<a href="#section-a.1-4" class="pilcrow">¶</a></p>
<p id="section-a.1-5">
   Remember that the SID index "8" is a global IGP segment attached to
   the IP prefix 192.0.2.8/32. Its semantic is global within the IGP
   domain: any router forwards a packet received with active segment 8
   to the next hop along the ECMP-aware shortest path to the related
   prefix.<a href="#section-a.1-5" class="pilcrow">¶</a></p>
<p id="section-a.1-6">
   R2 is the next hop along the shortest path towards R8. By applying
   the steps in <a href="#convert-section-2.8" class="xref">Section 2.8</a>, the outgoing label downloaded to R1's FIB
   corresponding to the global SID index "8" is 1008 because the SRGB of
   R2 = [1000,5000] as shown in <a href="#fig2" class="xref">Figure 2</a>.<a href="#section-a.1-6" class="pilcrow">¶</a></p>
<p id="section-a.1-7">
   Because the packet is IPv4, R1 applies the PUSH operation using the
   label value 1008 as specified in <a href="#convert-section-2.10.1" class="xref">Section 2.10.1</a>. The resulting MPLS
   header will have the "S" bit <span>[<a href="#RFC3032" class="xref">RFC3032</a>]</span> set because it is followed
   directly by an IPv4 packet.<a href="#section-a.1-7" class="pilcrow">¶</a></p>
<p id="section-a.1-8">
   The packet arrives at router R2.

 Because top label 1008
   corresponds to the IGP SID index "8", which is the Prefix-SID attached to
   the prefix 192.0.2.8/32 owned by Node R8, the instruction
   associated with the SID is "forward the packet using one of the ECMP interfaces or next hops along the shortest path(s) towards R8". Because R2 is not the penultimate hop, R2
   applies the CONTINUE operation to the packet and sends it to R3 using
   one of the two links connected to R3 with top label 1008 as specified
   in <a href="#convert-section-2.10.1" class="xref">Section 2.10.1</a>.<a href="#section-a.1-8" class="pilcrow">¶</a></p>
<p id="section-a.1-9">
   R3 receives the packet with top label 1008. Because top label
   1008 corresponds to the IGP SID index "8", which is the Prefix-SID attached
   to the prefix 192.0.2.8/32 owned by Node R8, the instruction
   associated with the SID is "send the packet using one of the ECMP interfaces and next hops along the shortest path towards R8". Because R3
   is the penultimate hop, we assume that R3 performs penultimate hop
   popping, which corresponds to the NEXT operation; the packet is then sent to 
   R8. The NEXT operation results in popping the outer label
   and sending the packet as a pure IPv4 packet to R8.<a href="#section-a.1-9" class="pilcrow">¶</a></p>
<p id="section-a.1-10">
   In conclusion, the path followed by P1 is R1-R2--R3-R8.  The ECMP
   awareness ensures that the traffic is load-shared between any ECMP
   path; in this case, it's the two links between R2 and R3.<a href="#section-a.1-10" class="pilcrow">¶</a></p>
</section>
</div>
<div id="convert-section-a.2">
<section id="section-a.2">
        <h2 id="name-incoming-label-collision-ex">
<a href="#section-a.2" class="section-number selfRef">A.2. </a><a href="#name-incoming-label-collision-ex" class="section-name selfRef">Incoming Label Collision Examples</a>
        </h2>
<p id="section-a.2-1">
   This section outlines several examples to illustrate the handling of
   label collision described in <a href="#convert-section-2.5" class="xref">Section 2.5</a>.<a href="#section-a.2-1" class="pilcrow">¶</a></p>
<p id="section-a.2-2">
   For the examples in this section, we assume that Node A has the
   following:<a href="#section-a.2-2" class="pilcrow">¶</a></p>
<ul>
<li id="section-a.2-3.1">OSPF default admin distance for implementation=50<a href="#section-a.2-3.1" class="pilcrow">¶</a>
</li>
          <li id="section-a.2-3.2">IS-IS default admin distance for implementation=60<a href="#section-a.2-3.2" class="pilcrow">¶</a>
</li>
        </ul>
<div id="convert-section-a.2.1">
<section id="section-a.2.1">
          <h3 id="name-example-1">
<a href="#section-a.2.1" class="section-number selfRef">A.2.1. </a><a href="#name-example-1" class="section-name selfRef">Example 1</a>
          </h3>
<p id="section-a.2.1-1">
   The following example illustrates incoming label collision resolution for the same FEC
   type using MCC administrative distance.<a href="#section-a.2.1-1" class="pilcrow">¶</a></p>
<p id="section-a.2.1-2">
   FEC1:<a href="#section-a.2.1-2" class="pilcrow">¶</a></p>
<p id="section-a.2.1-3">
            Node A receives an OSPF Prefix-SID Advertisement from Node B for 198.51.100.5/32 with index=5.
            Assuming that OSPF SRGB on Node A = [1000,1999], the incoming label is 1005.<a href="#section-a.2.1-3" class="pilcrow">¶</a></p>
<p id="section-a.2.1-4">
   FEC2:<a href="#section-a.2.1-4" class="pilcrow">¶</a></p>
<p id="section-a.2.1-5">
            IS-IS on Node A receives a Prefix-SID Advertisement from Node C for 203.0.113.105/32
      with index=5. Assuming that IS-IS SRGB on Node A = [1000,1999], the incoming label is 1005.<a href="#section-a.2.1-5" class="pilcrow">¶</a></p>
<p id="section-a.2.1-6">
   FEC1 and FEC2 both use dynamic SID assignment. 

   Since neither of the
   FECs are of type 'SR Policy', we use the default admin distances of 50 and
   60 to break the tie.  So FEC1 wins.<a href="#section-a.2.1-6" class="pilcrow">¶</a></p>
</section>
</div>
<div id="convert-section-a.2.2">
<section id="section-a.2.2">
          <h3 id="name-example-2">
<a href="#section-a.2.2" class="section-number selfRef">A.2.2. </a><a href="#name-example-2" class="section-name selfRef">Example 2</a>
          </h3>
<p id="section-a.2.2-1">
   The following example Illustrates incoming label collision resolution for different FEC
   types using the MCC administrative distance.<a href="#section-a.2.2-1" class="pilcrow">¶</a></p>
<p id="section-a.2.2-2">
   FEC1:<a href="#section-a.2.2-2" class="pilcrow">¶</a></p>
<p id="section-a.2.2-3">
            Node A receives an OSPF Prefix-SID Advertisement from Node B for
      198.51.100.6/32 with index=6.
           Assuming that OSPF SRGB on Node A = [1000,1999],
           the incoming label on Node A corresponding to
      198.51.100.6/32 is 1006.<a href="#section-a.2.2-3" class="pilcrow">¶</a></p>
<p id="section-a.2.2-4">
   FEC2:<a href="#section-a.2.2-4" class="pilcrow">¶</a></p>
<p id="section-a.2.2-5">
   IS-IS on Node A assigns label 1006 to the globally significant
   Adj-SID (i.e., when advertised, the L-Flag is clear in the Adj-SID
   sub-TLV as described in <span>[<a href="#RFC8667" class="xref">RFC8667</a>]</span>). Hence, the incoming label corresponding
   to this Adj-SID is 1006. Assume Node A allocates this Adj-SID
   dynamically, and it may differ across router reboots.<a href="#section-a.2.2-5" class="pilcrow">¶</a></p>
<p id="section-a.2.2-6">
   FEC1 and FEC2 both use dynamic SID assignment.  Since neither of the
   FECs are of type 'SR Policy', we use the default admin distances of 50 and
   60 to break the tie.  So FEC1 wins.<a href="#section-a.2.2-6" class="pilcrow">¶</a></p>
</section>
</div>
<div id="convert-section-a.2.3">
<section id="section-a.2.3">
          <h3 id="name-example-3">
<a href="#section-a.2.3" class="section-number selfRef">A.2.3. </a><a href="#name-example-3" class="section-name selfRef">Example 3</a>
          </h3>
<p id="section-a.2.3-1">
   The following example illustrates incoming label collision resolution based on
   preferring static over dynamic SID assignment.<a href="#section-a.2.3-1" class="pilcrow">¶</a></p>
<p id="section-a.2.3-2">
   FEC1:<a href="#section-a.2.3-2" class="pilcrow">¶</a></p>
<p id="section-a.2.3-3">
   OSPF on Node A receives a Prefix-SID Advertisement from Node B for
   198.51.100.7/32 with index=7. Assuming that the OSPF SRGB on Node A
   = [1000,1999], the incoming label corresponding to 198.51.100.7/32
   is 1007.<a href="#section-a.2.3-3" class="pilcrow">¶</a></p>
<p id="section-a.2.3-4">
   FEC2:<a href="#section-a.2.3-4" class="pilcrow">¶</a></p>
<p id="section-a.2.3-5">
   The operator on Node A configures IS-IS on Node A to assign label
   1007 to the globally significant Adj-SID (i.e., when advertised, the
   L-Flag is clear in the Adj-SID sub-TLV as described in <span>[<a href="#RFC8667" class="xref">RFC8667</a>]</span>).<a href="#section-a.2.3-5" class="pilcrow">¶</a></p>
<p id="section-a.2.3-6">
   Node A assigns this Adj-SID explicitly via configuration, so the Adj-SID
   survives router reboots.<a href="#section-a.2.3-6" class="pilcrow">¶</a></p>
<p id="section-a.2.3-7">
   FEC1 uses dynamic SID assignment, while FEC2 uses explicit SID
   assignment. So FEC2 wins.<a href="#section-a.2.3-7" class="pilcrow">¶</a></p>
</section>
</div>
<div id="convert-section-a.2.4">
<section id="section-a.2.4">
          <h3 id="name-example-4">
<a href="#section-a.2.4" class="section-number selfRef">A.2.4. </a><a href="#name-example-4" class="section-name selfRef">Example 4</a>
          </h3>
<p id="section-a.2.4-1">
   The following example illustrates incoming label collision resolution using FEC type
   default administrative distance.<a href="#section-a.2.4-1" class="pilcrow">¶</a></p>
<p id="section-a.2.4-2">
   FEC1:<a href="#section-a.2.4-2" class="pilcrow">¶</a></p>
<p id="section-a.2.4-3">
   OSPF on Node A receives a Prefix-SID Advertisement from Node B for
   198.51.100.8/32 with index=8. Assuming that OSPF SRGB on Node A =
   [1000,1999], the incoming label corresponding to 198.51.100.8/32  is
   1008.<a href="#section-a.2.4-3" class="pilcrow">¶</a></p>
<p id="section-a.2.4-4">
   FEC2:<a href="#section-a.2.4-4" class="pilcrow">¶</a></p>
<p id="section-a.2.4-5">
   Suppose the SR Policy Advertisement from the controller to Node A for the
   policy identified by (Endpoint = 192.0.2.208, color = 100) that
   consists of SID-List=&lt;S1, S2&gt; assigns the globally significant
   Binding-SID label 1008.<a href="#section-a.2.4-5" class="pilcrow">¶</a></p>
<p id="section-a.2.4-6">
   From the point of view of Node A, FEC1 and FEC2 both use dynamic SID
   assignment. Based on the default administrative distance outlined in
   <a href="#convert-section-2.5.1" class="xref">Section 2.5.1</a>, the Binding SID has a higher administrative distance
   than the Prefix-SID; hence, FEC1 wins.<a href="#section-a.2.4-6" class="pilcrow">¶</a></p>
</section>
</div>
<div id="convert-section-a.2.5">
<section id="section-a.2.5">
          <h3 id="name-example-5">
<a href="#section-a.2.5" class="section-number selfRef">A.2.5. </a><a href="#name-example-5" class="section-name selfRef">Example 5</a>
          </h3>
<p id="section-a.2.5-1">
   The following example illustrates incoming label collision resolution based on FEC type
   preference.<a href="#section-a.2.5-1" class="pilcrow">¶</a></p>
<p id="section-a.2.5-2">
   FEC1:<a href="#section-a.2.5-2" class="pilcrow">¶</a></p>
<p id="section-a.2.5-3">
   IS-IS on Node A receives a Prefix-SID Advertisement from Node B for
   203.0.113.110/32 with index=10. Assuming that the IS-IS SRGB on Node A
   = [1000,1999], the incoming label corresponding to 203.0.113.110/32
   is 1010.<a href="#section-a.2.5-3" class="pilcrow">¶</a></p>
<p id="section-a.2.5-4">
   FEC2:<a href="#section-a.2.5-4" class="pilcrow">¶</a></p>
<p id="section-a.2.5-5">
   IS-IS on Node A assigns label 1010 to the globally significant
   Adj-SID (i.e., when advertised, the L-Flag is clear in the Adj-SID
   sub-TLV as described in <span>[<a href="#RFC8667" class="xref">RFC8667</a>]</span>).<a href="#section-a.2.5-5" class="pilcrow">¶</a></p>
<p id="section-a.2.5-6">
   Node A allocates this Adj-SID dynamically, and it may differ across
   router reboots. Hence, both FEC1 and FEC2 both use dynamic SID
   assignment.<a href="#section-a.2.5-6" class="pilcrow">¶</a></p>
<p id="section-a.2.5-7">
   Since both FECs are from the same MCC, they have the same default
   admin distance. So we compare the FEC type codepoints. FEC1 has FEC type
   codepoint=120, while FEC2 has FEC type codepoint=130. Therefore,
   FEC1 wins.<a href="#section-a.2.5-7" class="pilcrow">¶</a></p>
</section>
</div>
<div id="convert-section-a.2.6">
<section id="section-a.2.6">
          <h3 id="name-example-6">
<a href="#section-a.2.6" class="section-number selfRef">A.2.6. </a><a href="#name-example-6" class="section-name selfRef">Example 6</a>
          </h3>
<p id="section-a.2.6-1">
   The following example illustrates incoming label collision resolution based on address
   family preference.<a href="#section-a.2.6-1" class="pilcrow">¶</a></p>
<p id="section-a.2.6-2">
   FEC1:<a href="#section-a.2.6-2" class="pilcrow">¶</a></p>
<p id="section-a.2.6-3">
   IS-IS on Node A receives a Prefix-SID Advertisement from Node B for
   203.0.113.111/32 with index=11. Assuming that the IS-IS SRGB on Node A
   = [1000,1999], the incoming label on Node A for 203.0.113.111/32 is
   1011.<a href="#section-a.2.6-3" class="pilcrow">¶</a></p>
<p id="section-a.2.6-4">
   FEC2:<a href="#section-a.2.6-4" class="pilcrow">¶</a></p>
<p id="section-a.2.6-5">
   IS-IS on Node A receives a Prefix-SID Advertisement from Node C for
   2001:DB8:1000::11/128 with index=11. Assuming that the IS-IS SRGB on
   Node A = [1000,1999], the incoming label on Node A for
   2001:DB8:1000::11/128 is 1011.<a href="#section-a.2.6-5" class="pilcrow">¶</a></p>
<p id="section-a.2.6-6">
   FEC1 and FEC2 both use dynamic SID assignment. Since both FECs are
   from the same MCC, they have the same default admin distance. So we
   compare the FEC type codepoints. Both FECs have FEC type codepoint=120.
   So we compare the address family. Since IPv4 is preferred over IPv6, FEC1
   wins.<a href="#section-a.2.6-6" class="pilcrow">¶</a></p>
</section>
</div>
<div id="convert-section-a.2.7">
<section id="section-a.2.7">
          <h3 id="name-example-7">
<a href="#section-a.2.7" class="section-number selfRef">A.2.7. </a><a href="#name-example-7" class="section-name selfRef">Example 7</a>
          </h3>
<p id="section-a.2.7-1">
   The following example illustrates incoming label collision resolution based on prefix
   length.<a href="#section-a.2.7-1" class="pilcrow">¶</a></p>
<p id="section-a.2.7-2">
   FEC1:<a href="#section-a.2.7-2" class="pilcrow">¶</a></p>
<p id="section-a.2.7-3">
   IS-IS on Node A receives a Prefix-SID Advertisement from Node B for
   203.0.113.112/32 with index=12. Assuming that IS-IS SRGB on Node A =
   [1000,1999], the incoming label for 203.0.113.112/32 on Node A is
   1012.<a href="#section-a.2.7-3" class="pilcrow">¶</a></p>
<p id="section-a.2.7-4">
   FEC2:<a href="#section-a.2.7-4" class="pilcrow">¶</a></p>
<p id="section-a.2.7-5">
   IS-IS on Node A receives a Prefix-SID Advertisement from Node C for
   203.0.113.128/30 with index=12. Assuming that the IS-IS SRGB on Node A
   = [1000,1999], the incoming label for 203.0.113.128/30 on Node A is
   1012.<a href="#section-a.2.7-5" class="pilcrow">¶</a></p>
<p id="section-a.2.7-6">
   FEC1 and FEC2 both use dynamic SID assignment. Since both FECs are
   from the same MCC, they have the same default admin distance. So we
   compare the FEC type codepoints.  Both FECs have FEC type codepoint=120.
   So we compare the address family.  Both are a part of the IPv4 address family, so we
   compare the prefix length.  FEC1 has prefix length=32, and FEC2 has
   prefix length=30, so FEC2 wins.<a href="#section-a.2.7-6" class="pilcrow">¶</a></p>
</section>
</div>
<div id="convert-section-a.2.8">
<section id="section-a.2.8">
          <h3 id="name-example-8">
<a href="#section-a.2.8" class="section-number selfRef">A.2.8. </a><a href="#name-example-8" class="section-name selfRef">Example 8</a>
          </h3>
<p id="section-a.2.8-1">
   The following example illustrates incoming label collision resolution based on the
   numerical value of the FECs.<a href="#section-a.2.8-1" class="pilcrow">¶</a></p>
<p id="section-a.2.8-2">
   FEC1:<a href="#section-a.2.8-2" class="pilcrow">¶</a></p>
<p id="section-a.2.8-3">
   IS-IS on Node A receives a Prefix-SID Advertisement from Node B for
   203.0.113.113/32 with index=13. Assuming that IS-IS SRGB on Node A =
   [1000,1999], the incoming label for 203.0.113.113/32 on Node A
   is 1013.<a href="#section-a.2.8-3" class="pilcrow">¶</a></p>
<p id="section-a.2.8-4">
   FEC2:<a href="#section-a.2.8-4" class="pilcrow">¶</a></p>
<p id="section-a.2.8-5">
   IS-IS on Node A receives a Prefix-SID Advertisement from Node C for
   203.0.113.213/32 with index=13. Assuming that IS-IS SRGB on Node A =
   [1000,1999], the incoming label for 203.0.113.213/32 on Node A
   is 1013.<a href="#section-a.2.8-5" class="pilcrow">¶</a></p>
<p id="section-a.2.8-6">
   FEC1 and FEC2 both use dynamic SID assignment. Since both FECs are
   from the same MCC, they have the same default admin distance. So we
   compare the FEC type codepoints.  Both FECs have FEC type codepoint=120.
   So we compare the address family.  Both are a part of the IPv4 address family, so we
   compare the prefix length.  Prefix lengths are the same, so we compare
   the prefix. FEC1 has the lower prefix, so FEC1 wins.<a href="#section-a.2.8-6" class="pilcrow">¶</a></p>
</section>
</div>
<div id="convert-section-a.2.9">
<section id="section-a.2.9">
          <h3 id="name-example-9">
<a href="#section-a.2.9" class="section-number selfRef">A.2.9. </a><a href="#name-example-9" class="section-name selfRef">Example 9</a>
          </h3>
<p id="section-a.2.9-1">
   The following example illustrates incoming label collision resolution based on the Routing
   Instance ID.<a href="#section-a.2.9-1" class="pilcrow">¶</a></p>
<p id="section-a.2.9-2">
   FEC1:<a href="#section-a.2.9-2" class="pilcrow">¶</a></p>
<p id="section-a.2.9-3">
   IS-IS on Node A receives a Prefix-SID Advertisement from Node B for
   203.0.113.114/32 with index=14. Assume that this IS-IS instance on
   Node A has Routing Instance ID = 1000 and SRGB = [1000,1999]. Hence,
   the incoming label for 203.0.113.114/32 on Node A is 1014.<a href="#section-a.2.9-3" class="pilcrow">¶</a></p>
<p id="section-a.2.9-4">
   FEC2:<a href="#section-a.2.9-4" class="pilcrow">¶</a></p>
<p id="section-a.2.9-5">
   IS-IS on Node A receives a Prefix-SID Advertisement from Node C for
   203.0.113.114/32 with index=14. Assume that this is another instance
   of IS-IS on Node A but Routing Instance ID = 2000 is different and
   SRGB = [1000,1999] is the same. Hence, the incoming label for 203.0.113.114/32 on
   Node A is 1014.<a href="#section-a.2.9-5" class="pilcrow">¶</a></p>
<p id="section-a.2.9-6">
   These two FECs match all the way through the prefix length and
   prefix. So the Routing Instance ID breaks the tie, and FEC1 wins.<a href="#section-a.2.9-6" class="pilcrow">¶</a></p>
</section>
</div>
<div id="convert-section-a.2.10">
<section id="section-a.2.10">
          <h3 id="name-example-10">
<a href="#section-a.2.10" class="section-number selfRef">A.2.10. </a><a href="#name-example-10" class="section-name selfRef">Example 10</a>
          </h3>
<p id="section-a.2.10-1">
   The following example illustrates incoming label collision resolution based on the topology
   ID.<a href="#section-a.2.10-1" class="pilcrow">¶</a></p>
<p id="section-a.2.10-2">
   FEC1:<a href="#section-a.2.10-2" class="pilcrow">¶</a></p>
<p id="section-a.2.10-3">
   IS-IS on Node A receives a Prefix-SID Advertisement from Node B for
   203.0.113.115/32 with index=15. Assume that this IS-IS instance on
   Node A has Routing Instance ID = 1000. Assume that the prefix
   advertisement of 203.0.113.115/32 was received in the IS-IS Multi-topology
   advertisement with ID = 50. If the IS-IS SRGB for this routing
   instance on Node A = [1000,1999], then the incoming label of
   203.0.113.115/32 for topology 50 on Node A is 1015.<a href="#section-a.2.10-3" class="pilcrow">¶</a></p>
<p id="section-a.2.10-4">
   FEC2:<a href="#section-a.2.10-4" class="pilcrow">¶</a></p>
<p id="section-a.2.10-5">
   IS-IS on Node A receives a Prefix-SID Advertisement from Node C for
   203.0.113.115/32 with index=15. Assume that it has the same Routing
   Instance ID = 1000, but 203.0.113.115/32 was advertised with
   IS-IS Multi-topology ID = 40, which is different. If the IS-IS SRGB on Node A =
   [1000,1999], then the incoming label of 203.0.113.115/32 for topology 40
   on Node A is also 1015.<a href="#section-a.2.10-5" class="pilcrow">¶</a></p>
<p id="section-a.2.10-6">
   Since these two FECs match all the way through the prefix length, prefix,
   and Routing Instance ID, we compare the IS-IS Multi-topology ID, so FEC2
   wins.<a href="#section-a.2.10-6" class="pilcrow">¶</a></p>
</section>
</div>
<div id="convert-section-a.2.11">
<section id="section-a.2.11">
          <h3 id="name-example-11">
<a href="#section-a.2.11" class="section-number selfRef">A.2.11. </a><a href="#name-example-11" class="section-name selfRef">Example 11</a>
          </h3>
<p id="section-a.2.11-1">
   The following example illustrates incoming label collision for resolution based on
   the algorithm ID.<a href="#section-a.2.11-1" class="pilcrow">¶</a></p>
<p id="section-a.2.11-2">
   FEC1:<a href="#section-a.2.11-2" class="pilcrow">¶</a></p>
<p id="section-a.2.11-3">
   IS-IS on Node A receives a Prefix-SID Advertisement from Node B for
   203.0.113.116/32 with index=16. Assume that IS-IS on Node A has Routing
   Instance ID = 1000. Assume that Node B advertised 203.0.113.116/32
   with IS-IS Multi-topology ID = 50 and SR algorithm = 0. Assume that
   the IS-IS SRGB on Node A = [1000,1999]. Hence, the incoming label
   corresponding to this advertisement of 203.0.113.116/32 is 1016.<a href="#section-a.2.11-3" class="pilcrow">¶</a></p>
<p id="section-a.2.11-4">
   FEC2:<a href="#section-a.2.11-4" class="pilcrow">¶</a></p>
<p id="section-a.2.11-5">
   IS-IS on Node A receives a Prefix-SID Advertisement from Node C for
   203.0.113.116/32 with index=16. Assume that it is the same IS-IS
   instance on Node A with Routing Instance ID = 1000. Also assume that
   Node C advertised 203.0.113.116/32 with IS-IS Multi-topology ID = 50
   but with SR algorithm = 22. Since it is the same routing instance,
   the SRGB on Node A = [1000,1999]. Hence, the incoming label
   corresponding to this advertisement of 203.0.113.116/32 by Node C is
   also 1016.<a href="#section-a.2.11-5" class="pilcrow">¶</a></p>
<p id="section-a.2.11-6">
   Since these two FECs match all the way through in terms of the prefix length, prefix,
   Routing Instance ID, and Multi-topology ID, we compare the SR
   algorithm IDs, so FEC1 wins.<a href="#section-a.2.11-6" class="pilcrow">¶</a></p>
</section>
</div>
<div id="convert-section-a.2.12">
<section id="section-a.2.12">
          <h3 id="name-example-12">
<a href="#section-a.2.12" class="section-number selfRef">A.2.12. </a><a href="#name-example-12" class="section-name selfRef">Example 12</a>
          </h3>
<p id="section-a.2.12-1">
   The following example illustrates incoming label collision resolution based on the FEC
   numerical value, independent of how the SID is assigned to the
   colliding FECs.<a href="#section-a.2.12-1" class="pilcrow">¶</a></p>
<p id="section-a.2.12-2">
   FEC1:<a href="#section-a.2.12-2" class="pilcrow">¶</a></p>
<p id="section-a.2.12-3">
   IS-IS on Node A receives a Prefix-SID Advertisement from Node B for
   203.0.113.117/32 with index=17. Assume that the IS-IS SRGB on Node A
   = [1000,1999]; thus, the incoming label is 1017.<a href="#section-a.2.12-3" class="pilcrow">¶</a></p>
<p id="section-a.2.12-4">
   FEC2:<a href="#section-a.2.12-4" class="pilcrow">¶</a></p>
<p id="section-a.2.12-5">
   Suppose there is an IS-IS Mapping Server Advertisement (SID / Label
   Binding TLV) from Node D that has range = 100 and prefix = 203.0.113.1/32.
   Suppose this Mapping Server Advertisement generates 100 mappings, one
   of which maps 203.0.113.17/32 to index=17.
   Assuming that it is the
   same IS-IS instance, the SRGB = [1000,1999] and hence the
   incoming label for 1017.<a href="#section-a.2.12-5" class="pilcrow">¶</a></p>
<p id="section-a.2.12-6">
   Even though FEC1 comes from a normal Prefix-SID Advertisement and
   FEC2 is generated from a Mapping Server Advertisement, it is not used as
   a tiebreaking parameter. Both FECs use dynamic SID assignment, are
   from the same MCC, and have the same FEC type codepoint=120. Their
   prefix lengths are the same as well.  FEC2 wins based on its lower
   numerical prefix value, since 203.0.113.17 is less than
   203.0.113.117.<a href="#section-a.2.12-6" class="pilcrow">¶</a></p>
</section>
</div>
<div id="convert-section-a.2.13">
<section id="section-a.2.13">
          <h3 id="name-example-13">
<a href="#section-a.2.13" class="section-number selfRef">A.2.13. </a><a href="#name-example-13" class="section-name selfRef">Example 13</a>
          </h3>
<p id="section-a.2.13-1">
   The following example illustrates incoming label collision resolution based on address
   family preference.<a href="#section-a.2.13-1" class="pilcrow">¶</a></p>
<p id="section-a.2.13-2">
   FEC1:<a href="#section-a.2.13-2" class="pilcrow">¶</a></p>
<p id="section-a.2.13-3">
   SR Policy Advertisement from the controller to Node A. Endpoint
   address=2001:DB8:3000::100, color=100, SID-List=&lt;S1, S2&gt;, and the
   Binding-SID label=1020.<a href="#section-a.2.13-3" class="pilcrow">¶</a></p>
<p id="section-a.2.13-4">
   FEC2:<a href="#section-a.2.13-4" class="pilcrow">¶</a></p>
<p id="section-a.2.13-5">
SR Policy Advertisement from controller to Node A. Endpoint
address=192.0.2.60, color=100, SID-List=&lt;S3, S4&gt;, and the Binding-SID
label=1020.<a href="#section-a.2.13-5" class="pilcrow">¶</a></p>
<p id="section-a.2.13-6">The FEC tiebreakers match, and they have the
same FEC type codepoint=140. Thus, FEC2 wins based on the IPv4 address family
being preferred over IPv6.<a href="#section-a.2.13-6" class="pilcrow">¶</a></p>
</section>
</div>
<div id="convert-section-a.2.14">
<section id="section-a.2.14">
          <h3 id="name-example-14">
<a href="#section-a.2.14" class="section-number selfRef">A.2.14. </a><a href="#name-example-14" class="section-name selfRef">Example 14</a>
          </h3>
<p id="section-a.2.14-1">
   The following example illustrates incoming label resolution based on the numerical value of
   the policy endpoint.<a href="#section-a.2.14-1" class="pilcrow">¶</a></p>
<p id="section-a.2.14-2">
   FEC1:<a href="#section-a.2.14-2" class="pilcrow">¶</a></p>
<p id="section-a.2.14-3">
   SR Policy Advertisement from the controller to Node A. Endpoint
   address=192.0.2.70, color=100, SID-List=&lt;S1, S2&gt;, and Binding-SID
   label=1021.<a href="#section-a.2.14-3" class="pilcrow">¶</a></p>
<p id="section-a.2.14-4">
   FEC2:<a href="#section-a.2.14-4" class="pilcrow">¶</a></p>
<p id="section-a.2.14-5">
   SR Policy Advertisement from the controller to Node A. Endpoint
   address=192.0.2.71, color=100, SID-List=&lt;S3, S4&gt;, and Binding-SID
   label=1021.<a href="#section-a.2.14-5" class="pilcrow">¶</a></p>
<p id="section-a.2.14-6">
   The FEC tiebreakers match, and they have the
   same address family. Thus, FEC1 wins by having the lower numerical endpoint
   address value.<a href="#section-a.2.14-6" class="pilcrow">¶</a></p>
</section>
</div>
</section>
</div>
<div id="convert-section-a.3">
<section id="section-a.3">
        <h2 id="name-examples-for-the-effect-of-">
<a href="#section-a.3" class="section-number selfRef">A.3. </a><a href="#name-examples-for-the-effect-of-" class="section-name selfRef">Examples for the Effect of Incoming Label Collision on an Outgoing Label</a>
        </h2>
<p id="section-a.3-1">
   This section presents examples to illustrate the effect of incoming
   label collision on the selection of the outgoing label as described in
   <a href="#convert-section-2.6" class="xref">Section 2.6</a>.<a href="#section-a.3-1" class="pilcrow">¶</a></p>
<div id="convert-section-a.3.1">
<section id="section-a.3.1">
          <h3 id="name-example-1-2">
<a href="#section-a.3.1" class="section-number selfRef">A.3.1. </a><a href="#name-example-1-2" class="section-name selfRef">Example 1</a>
          </h3>
<p id="section-a.3.1-1">
   The following example illustrates the effect of incoming label resolution on the
   outgoing label.<a href="#section-a.3.1-1" class="pilcrow">¶</a></p>
<p id="section-a.3.1-2">
   FEC1:<a href="#section-a.3.1-2" class="pilcrow">¶</a></p>
<p id="section-a.3.1-3">
   IS-IS on Node A receives a Prefix-SID Advertisement from Node B for
   203.0.113.122/32 with index=22. Assuming that the IS-IS SRGB on Node A
   = [1000,1999], the corresponding incoming label is 1022.<a href="#section-a.3.1-3" class="pilcrow">¶</a></p>
<p id="section-a.3.1-4">
   FEC2:<a href="#section-a.3.1-4" class="pilcrow">¶</a></p>
<p id="section-a.3.1-5">
   IS-IS on Node A receives a Prefix-SID Advertisement from Node C for
   203.0.113.222/32 with index=22. Assuming that the IS-IS SRGB on Node A
   = [1000,1999], the corresponding incoming label is 1022.<a href="#section-a.3.1-5" class="pilcrow">¶</a></p>
<p id="section-a.3.1-6">

   FEC1 wins based on the lowest numerical prefix value.  This means that
   Node A installs a transit MPLS forwarding entry to swap incoming
   label 1022 with outgoing label N and to use outgoing interface I. N is
   determined by the index associated with FEC1 (index=22) and the SRGB
   advertised by the next-hop node on the shortest path to reach
   203.0.113.122/32.<a href="#section-a.3.1-6" class="pilcrow">¶</a></p>
<p id="section-a.3.1-7">
   Node A will generally also install an imposition MPLS forwarding
   entry corresponding to FEC1 for incoming prefix=203.0.113.122/32
   pushing outgoing label N, and using outgoing interface I.<a href="#section-a.3.1-7" class="pilcrow">¶</a></p>
<p id="section-a.3.1-8">
   The rule in <a href="#convert-section-2.6" class="xref">Section 2.6</a> means Node A <span class="bcp14">MUST NOT</span> install an ingress
   MPLS forwarding entry corresponding to FEC2 (the losing FEC, which
   would be for prefix 203.0.113.222/32).<a href="#section-a.3.1-8" class="pilcrow">¶</a></p>
</section>
</div>
<div id="convert-section-a.3.2">
<section id="section-a.3.2">
          <h3 id="name-example-2-2">
<a href="#section-a.3.2" class="section-number selfRef">A.3.2. </a><a href="#name-example-2-2" class="section-name selfRef">Example 2</a>
          </h3>
<p id="section-a.3.2-1">
   The following example illustrates the effect of incoming label collision resolution on
   outgoing label programming on Node A.<a href="#section-a.3.2-1" class="pilcrow">¶</a></p>
<p id="section-a.3.2-2">
   FEC1:<a href="#section-a.3.2-2" class="pilcrow">¶</a></p>
<p id="section-a.3.2-3">SR Policy Advertisement from the controller to Node A.
            Endpoint address=192.0.2.80, color=100, SID-List=&lt;S1, S2&gt;, and 
            Binding-SID label=1023.<a href="#section-a.3.2-3" class="pilcrow">¶</a></p>
<p id="section-a.3.2-4">
   FEC2:<a href="#section-a.3.2-4" class="pilcrow">¶</a></p>
<p id="section-a.3.2-5">
            SR Policy Advertisement from controller to Node A.
            Endpoint address=192.0.2.81, color=100, SID-List=&lt;S3, S4&gt;, and
            Binding-SID label=1023.<a href="#section-a.3.2-5" class="pilcrow">¶</a></p>
<p id="section-a.3.2-6">
   FEC1 wins by having the lower numerical endpoint address value. This
   means that Node A installs a transit MPLS forwarding entry to swap
   incoming label=1023 with outgoing labels, and the outgoing interface
   is determined by the SID-List for FEC1.<a href="#section-a.3.2-6" class="pilcrow">¶</a></p>
<p id="section-a.3.2-7">
   In this example, we assume that Node A receives two BGP/VPN routes:<a href="#section-a.3.2-7" class="pilcrow">¶</a></p>
<ul>
<li id="section-a.3.2-8.1">R1 with VPN label=V1, BGP next hop = 192.0.2.80, and color=100<a href="#section-a.3.2-8.1" class="pilcrow">¶</a>
</li>
            <li id="section-a.3.2-8.2">R2 with VPN label=V2, BGP next hop = 192.0.2.81, and color=100<a href="#section-a.3.2-8.2" class="pilcrow">¶</a>
</li>
          </ul>
<p id="section-a.3.2-9">
   We also assume that Node A has a BGP policy that matches color=100
   and allows its usage as Service Level Agreement (SLA) steering information. In this case,
   Node A will install a VPN route with label stack = &lt;S1,S2,V1&gt;
   (corresponding to FEC1).<a href="#section-a.3.2-9" class="pilcrow">¶</a></p>
<p id="section-a.3.2-10">
   The rule described in <a href="#convert-section-2.6" class="xref">Section 2.6</a> means that Node A <span class="bcp14">MUST NOT</span> install
   a VPN route with label stack = &lt;S3,S4,V1&gt; (corresponding to FEC2.)<a href="#section-a.3.2-10" class="pilcrow">¶</a></p>
</section>
</div>
</section>
</div>
</section>
</div>
<div id="convert-section-7">
<section id="section-appendix.b">
      <h2 id="name-acknowledgements">
<a href="#name-acknowledgements" class="section-name selfRef">Acknowledgements</a>
      </h2>
<p id="section-appendix.b-1">
   The authors would like to thank Les Ginsberg, Chris Bowers, Himanshu
   Shah, Adrian Farrel, Alexander Vainshtein, Przemyslaw Krol, Darren
   Dukes, Zafar Ali, and Martin Vigoureux for their valuable comments on
   this document.<a href="#section-appendix.b-1" class="pilcrow">¶</a></p>
</section>
</div>
<div id="convert-section-6">
<section id="section-appendix.c">
      <h2 id="name-contributors">
<a href="#name-contributors" class="section-name selfRef">Contributors</a>
      </h2>
<p id="section-appendix.c-1">
   The following contributors have substantially helped the definition
   and editing of the content of this document:<a href="#section-appendix.c-1" class="pilcrow">¶</a></p>
<div class="artwork art-text alignLeft" id="section-appendix.c-2">
<pre>
Martin Horneffer
Deutsche Telekom
Email: Martin.Horneffer@telekom.de</pre><a href="#section-appendix.c-2" class="pilcrow">¶</a>
</div>
<div class="artwork art-text alignLeft" id="section-appendix.c-3">
<pre>
Wim Henderickx
Nokia
Email: wim.henderickx@nokia.com</pre><a href="#section-appendix.c-3" class="pilcrow">¶</a>
</div>
<div class="artwork art-text alignLeft" id="section-appendix.c-4">
<pre>
Jeff Tantsura
Email: jefftant@gmail.com</pre><a href="#section-appendix.c-4" class="pilcrow">¶</a>
</div>
<div class="artwork art-text alignLeft" id="section-appendix.c-5">
<pre>
Edward Crabbe
Email: edward.crabbe@gmail.com</pre><a href="#section-appendix.c-5" class="pilcrow">¶</a>
</div>
<div class="artwork art-text alignLeft" id="section-appendix.c-6">
<pre>
Igor Milojevic
Email: milojevicigor@gmail.com</pre><a href="#section-appendix.c-6" class="pilcrow">¶</a>
</div>
<div class="artwork art-text alignLeft" id="section-appendix.c-7">
<pre>
Saku Ytti
Email: saku@ytti.fi</pre><a href="#section-appendix.c-7" class="pilcrow">¶</a>
</div>
</section>
</div>
<div id="authors-addresses">
<section id="section-appendix.d">
      <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">Ahmed Bashandy (<span class="role">editor</span>)</span></div>
<div dir="auto" class="left"><span class="org">Arrcus</span></div>
<div class="email">
<span>Email:</span>
<a href="mailto:abashandy.ietf@gmail.com" class="email">abashandy.ietf@gmail.com</a>
</div>
</address>
<address class="vcard">
        <div dir="auto" class="left"><span class="fn nameRole">Clarence Filsfils (<span class="role">editor</span>)</span></div>
<div dir="auto" class="left"><span class="org">Cisco Systems, Inc.</span></div>
<div dir="auto" class="left"><span class="street-address">Brussels</span></div>
<div dir="auto" class="left"><span class="country-name">Belgium</span></div>
<div class="email">
<span>Email:</span>
<a href="mailto:cfilsfil@cisco.com" class="email">cfilsfil@cisco.com</a>
</div>
</address>
<address class="vcard">
        <div dir="auto" class="left"><span class="fn nameRole">Stefano Previdi</span></div>
<div dir="auto" class="left"><span class="org">Cisco Systems, Inc.</span></div>
<div dir="auto" class="left"><span class="country-name">Italy</span></div>
<div class="email">
<span>Email:</span>
<a href="mailto:stefano@previdi.net" class="email">stefano@previdi.net</a>
</div>
</address>
<address class="vcard">
        <div dir="auto" class="left"><span class="fn nameRole">Bruno Decraene</span></div>
<div dir="auto" class="left"><span class="org">Orange</span></div>
<div dir="auto" class="left"><span class="country-name">France</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">Stephane Litkowski</span></div>
<div dir="auto" class="left"><span class="org">Orange</span></div>
<div dir="auto" class="left"><span class="country-name">France</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">Rob Shakir</span></div>
<div dir="auto" class="left"><span class="org">Google</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:robjs@google.com" class="email">robjs@google.com</a>
</div>
</address>
</section>
</div>
<script>var toc = document.getElementById("toc");
var tocToggle = toc.querySelector("h2");
var tocNav = toc.querySelector("nav");

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

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

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