File: rfc9015.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 (4929 lines) | stat: -rw-r--r-- 296,719 bytes
<!DOCTYPE html>
<html lang="en" class="RFC">
<head>
<meta charset="utf-8">
<meta content="Common,Latin" name="scripts">
<meta content="initial-scale=1.0" name="viewport">
<title>RFC 9015: BGP Control Plane for the Network Service Header in Service Function Chaining</title>
<meta content="Adrian Farrel" name="author">
<meta content="John Drake" name="author">
<meta content="Eric Rosen" name="author">
<meta content="Jim Uttaro" name="author">
<meta content="Luay Jalil" name="author">
<meta content='
       This document describes the use of BGP as a control plane for networks that support
         service function chaining.  The document introduces a new BGP address family
         called the "Service Function Chain (SFC) Address Family Identifier / Subsequent Address Family Identifier" (SFC
         AFI/SAFI) with two Route Types.  One Route Type is originated by a node to advertise
         that it hosts a particular instance of a specified service function.  This Route Type
         also provides "instructions" on how to send a packet to the hosting node in a way that
         indicates that the service function has to be applied to the packet.  The other Route
         Type is used by a controller to advertise the paths of "chains" of service functions
         and give a unique designator to each such path so that they can be used in
         conjunction with the Network Service Header (NSH) defined in RFC 8300. 
       This document adopts the service function chaining architecture described in RFC 7665. 
    ' name="description">
<meta content="xml2rfc 3.8.0" name="generator">
<meta content="Service Function Chaining" name="keyword">
<meta content="Service Function Chain" name="keyword">
<meta content="Network Service Header" name="keyword">
<meta content="Service Function" name="keyword">
<meta content="Service Function Forwarder" name="keyword">
<meta content="Service Function Path" name="keyword">
<meta content="Service Function Path Route" name="keyword">
<meta content="Service Function Instance" name="keyword">
<meta content="Service Function Instance Route" name="keyword">
<meta content="Service Function Type" name="keyword">
<meta content="Control Plane" name="keyword">
<meta content="9015" name="rfc.number">
<!-- Generator version information:
  xml2rfc 3.8.0
    Python 3.6.10
    appdirs 1.4.4
    ConfigArgParse 1.2.3
    google-i18n-address 2.3.5
    html5lib 1.0.1
    intervaltree 3.0.2
    Jinja2 2.11.2
    kitchen 1.2.6
    lxml 4.4.2
    pycairo 1.19.0
    pycountry 19.8.18
    pyflakes 2.1.1
    PyYAML 5.3.1
    requests 2.22.0
    setuptools 40.6.2
    six 1.14.0
    WeasyPrint 51
-->
<link href="rfc9015.xml" rel="alternate" type="application/rfc+xml">
<link href="#copyright" rel="license">
<style type="text/css">/*

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

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

*/

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

.refInstance {
  margin-bottom: 1.25em;
}

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

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

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

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

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

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

/* pagination */
@media print {
  body {

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

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

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

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

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

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

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

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

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

}

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


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

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

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

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

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

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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

}
/* Tweak the bcp14 keyword presentation */
.bcp14 {
  font-variant: small-caps;
  font-weight: bold;
  font-size: 0.9em;
}
/* Tweak the invisible space above H* in order not to overlay links in text above */
 h2 {
  margin-top: -18px;  /* provide offset for in-page anchors */
  padding-top: 31px;
 }
 h3 {
  margin-top: -18px;  /* provide offset for in-page anchors */
  padding-top: 24px;
 }
 h4 {
  margin-top: -18px;  /* provide offset for in-page anchors */
  padding-top: 24px;
 }
/* Float artwork pilcrow to the right */
@media screen {
  .artwork a.pilcrow {
    display: block;
    line-height: 0.7;
    margin-top: 0.15em;
  }
}
/* Make pilcrows on dd visible */
@media screen {
  dd:hover > a.pilcrow {
    visibility: visible;
  }
}
/* Make the placement of figcaption match that of a table's caption
   by removing the figure's added bottom margin */
.alignLeft.art-text,
.alignCenter.art-text,
.alignRight.art-text {
   margin-bottom: 0;
}
.alignLeft,
.alignCenter,
.alignRight {
  margin: 1em 0 0 0;
}
/* In print, the pilcrow won't show on hover, so prevent it from taking up space,
   possibly even requiring a new line */
@media print {
  a.pilcrow {
    display: none;
  }
}
/* Styling for the external metadata */
div#external-metadata {
  background-color: #eee;
  padding: 0.5em;
  margin-bottom: 0.5em;
  display: none;
}
div#internal-metadata {
  padding: 0.5em;                       /* to match the external-metadata padding */
}
/* Styling for title RFC Number */
h1#rfcnum {
  clear: both;
  margin: 0 0 -1em;
  padding: 1em 0 0 0;
}
/* Make .olPercent look the same as <ol><li> */
dl.olPercent > dd {
  margin-bottom: 0.25em;
  min-height: initial;
}
/* Give aside some styling to set it apart */
aside {
  border-left: 1px solid #ddd;
  margin: 1em 0 1em 2em;
  padding: 0.2em 2em;
}
aside > dl,
aside > ol,
aside > ul,
aside > table,
aside > p {
  margin-bottom: 0.5em;
}
/* Additional page break settings */
@media print {
  figcaption, table caption {
    page-break-before: avoid;
  }
}
/* Font size adjustments for print */
@media print {
  body  { font-size: 10pt;      line-height: normal; max-width: 96%; }
  h1    { font-size: 1.72em;    padding-top: 1.5em; } /* 1*1.2*1.2*1.2 */
  h2    { font-size: 1.44em;    padding-top: 1.5em; } /* 1*1.2*1.2 */
  h3    { font-size: 1.2em;     padding-top: 1.5em; } /* 1*1.2 */
  h4    { font-size: 1em;       padding-top: 1.5em; }
  h5, h6 { font-size: 1em;      margin: initial; padding: 0.5em 0 0.3em; }
}
/* Sourcecode margin in print, when there's no pilcrow */
@media print {
  .artwork,
  .sourcecode {
    margin-bottom: 1em;
  }
}
/* Avoid narrow tables forcing too narrow table captions, which may render badly */
table {
  min-width: 20em;
}
/* ol type a */
ol.type-a { list-style-type: lower-alpha; }
ol.type-A { list-style-type: upper-alpha; }
ol.type-i { list-style-type: lower-roman; }
ol.type-I { list-style-type: lower-roman; }
/* Apply the print table and row borders in general, on request from the RPC,
and increase the contrast between border and odd row background sligthtly */
table {
  border: 1px solid #ddd;
}
td {
  border-top: 1px solid #ddd;
}
tr:nth-child(2n+1) > td {
  background-color: #f8f8f8;
}
/* Use style rules to govern display of the TOC. */
@media screen and (max-width: 1023px) {
  #toc nav { display: none; }
  #toc.active nav { display: block; }
}
/* Add support for keepWithNext */
.keepWithNext {
  break-after: avoid-page;
  break-after: avoid-page;
}
/* Add support for keepWithPrevious */
.keepWithPrevious {
  break-before: avoid-page;
}
/* Change the approach to avoiding breaks inside artwork etc. */
figure, pre, table, .artwork, .sourcecode  {
  break-before: avoid-page;
  break-after: auto;
}
/* Avoid breaks between <dt> and <dd> */
dl {
  break-before: auto;
  break-inside: auto;
}
dt {
  break-before: auto;
  break-after: avoid-page;
}
dd {
  break-before: avoid-page;
  break-after: auto;
  orphans: 3;
  widows: 3
}
span.break, dd.break {
  margin-bottom: 0;
  min-height: 0;
  break-before: auto;
  break-inside: auto;
  break-after: auto;
}
/* Undo break-before ToC */
@media print {
  #toc {
    break-before: auto;
  }
}
/* Text in compact lists should not get extra bottim margin space,
   since that would makes the list not compact */
ul.compact p, .ulCompact p,
ol.compact p, .olCompact p {
 margin: 0;
}
/* But the list as a whole needs the extra space at the end */
section ul.compact,
section .ulCompact,
section ol.compact,
section .olCompact {
  margin-bottom: 1em;                    /* same as p not within ul.compact etc. */
}
/* The tt and code background above interferes with for instance table cell
   backgrounds.  Changed to something a bit more selective. */
tt, code {
  background-color: transparent;
}
p tt, p code, li tt, li code {
  background-color: #f8f8f8;
}
/* Tweak the pre margin -- 0px doesn't come out well */
pre {
   margin-top: 0.5px;
}
/* Tweak the comact list text */
ul.compact, .ulCompact,
ol.compact, .olCompact,
dl.compact, .dlCompact {
  line-height: normal;
}
/* Don't add top margin for nested lists */
li > ul, li > ol, li > dl,
dd > ul, dd > ol, dd > dl,
dl > dd > dl {
  margin-top: initial;
}
/* Elements that should not be rendered on the same line as a <dt> */
/* This should match the element list in writer.text.TextWriter.render_dl() */
dd > div.artwork:first-child,
dd > aside:first-child,
dd > figure:first-child,
dd > ol:first-child,
dd > div:first-child > pre.sourcecode,
dd > table:first-child,
dd > ul:first-child {
  clear: left;
}
/* fix for weird browser behaviour when <dd/> is empty */
dt+dd:empty::before{
  content: "\00a0";
}
/* Make paragraph spacing inside <li> smaller than in body text, to fit better within the list */
li > p {
  margin-bottom: 0.5em
}
/* Don't let p margin spill out from inside list items */
li > p:last-of-type {
  margin-bottom: 0;
}
</style>
<link href="rfc-local.css" rel="stylesheet" type="text/css">
<link href="https://dx.doi.org/10.17487/rfc9015" rel="alternate">
  <link href="urn:issn:2070-1721" rel="alternate">
  <link href="https://datatracker.ietf.org/doc/draft-ietf-bess-nsh-bgp-control-plane-18" 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 9015</td>
<td class="center">BGP for NSH SFC</td>
<td class="right">June 2021</td>
</tr></thead>
<tfoot><tr>
<td class="left">Farrel, et al.</td>
<td class="center">Standards Track</td>
<td class="right">[Page]</td>
</tr></tfoot>
</table>
<div id="external-metadata" class="document-information"></div>
<div id="internal-metadata" class="document-information">
<dl id="identifiers">
<dt class="label-stream">Stream:</dt>
<dd class="stream">Internet Engineering Task Force (IETF)</dd>
<dt class="label-rfc">RFC:</dt>
<dd class="rfc"><a href="https://www.rfc-editor.org/rfc/rfc9015" class="eref">9015</a></dd>
<dt class="label-category">Category:</dt>
<dd class="category">Standards Track</dd>
<dt class="label-published">Published:</dt>
<dd class="published">
<time datetime="2021-06" class="published">June 2021</time>
    </dd>
<dt class="label-issn">ISSN:</dt>
<dd class="issn">2070-1721</dd>
<dt class="label-authors">Authors:</dt>
<dd class="authors">
<div class="author">
      <div class="author-name">A. Farrel</div>
<div class="org">Old Dog Consulting</div>
</div>
<div class="author">
      <div class="author-name">J. Drake</div>
<div class="org">Juniper Networks</div>
</div>
<div class="author">
      <div class="author-name">E. Rosen</div>
<div class="org">Juniper Networks</div>
</div>
<div class="author">
      <div class="author-name">J. Uttaro</div>
<div class="org">AT&amp;T</div>
</div>
<div class="author">
      <div class="author-name">L. Jalil</div>
<div class="org">Verizon</div>
</div>
</dd>
</dl>
</div>
<h1 id="rfcnum">RFC 9015</h1>
<h1 id="title">BGP Control Plane for the Network Service Header in Service Function Chaining</h1>
<section id="section-abstract">
      <h2 id="abstract"><a href="#abstract" class="selfRef">Abstract</a></h2>
<p id="section-abstract-1">This document describes the use of BGP as a control plane for networks that support
         service function chaining.  The document introduces a new BGP address family
         called the "Service Function Chain (SFC) Address Family Identifier / Subsequent Address Family Identifier" (SFC
         AFI/SAFI) with two Route Types.  One Route Type is originated by a node to advertise
         that it hosts a particular instance of a specified service function.  This Route Type
         also provides "instructions" on how to send a packet to the hosting node in a way that
         indicates that the service function has to be applied to the packet.  The other Route
         Type is used by a controller to advertise the paths of "chains" of service functions
         and give a unique designator to each such path so that they can be used in
         conjunction with the Network Service Header (NSH) defined in RFC 8300.<a href="#section-abstract-1" class="pilcrow">¶</a></p>
<p id="section-abstract-2">This document adopts the service function chaining architecture described in RFC 7665.<a href="#section-abstract-2" class="pilcrow">¶</a></p>
</section>
<div id="status-of-memo">
<section id="section-boilerplate.1">
        <h2 id="name-status-of-this-memo">
<a href="#name-status-of-this-memo" class="section-name selfRef">Status of This Memo</a>
        </h2>
<p id="section-boilerplate.1-1">
            This is an Internet Standards Track document.<a href="#section-boilerplate.1-1" class="pilcrow">¶</a></p>
<p id="section-boilerplate.1-2">
            This document is a product of the Internet Engineering Task Force
            (IETF).  It represents the consensus of the IETF community.  It has
            received public review and has been approved for publication by
            the Internet Engineering Steering Group (IESG).  Further
            information on Internet Standards is available in Section 2 of 
            RFC 7841.<a href="#section-boilerplate.1-2" class="pilcrow">¶</a></p>
<p id="section-boilerplate.1-3">
            Information about the current status of this document, any
            errata, and how to provide feedback on it may be obtained at
            <span><a href="https://www.rfc-editor.org/info/rfc9015">https://www.rfc-editor.org/info/rfc9015</a></span>.<a href="#section-boilerplate.1-3" class="pilcrow">¶</a></p>
</section>
</div>
<div id="copyright">
<section id="section-boilerplate.2">
        <h2 id="name-copyright-notice">
<a href="#name-copyright-notice" class="section-name selfRef">Copyright Notice</a>
        </h2>
<p id="section-boilerplate.2-1">
            Copyright (c) 2021 IETF Trust and the persons identified as the
            document authors. All rights reserved.<a href="#section-boilerplate.2-1" class="pilcrow">¶</a></p>
<p id="section-boilerplate.2-2">
            This document is subject to BCP 78 and the IETF Trust's Legal
            Provisions Relating to IETF Documents
            (<span><a href="https://trustee.ietf.org/license-info">https://trustee.ietf.org/license-info</a></span>) in effect on the date of
            publication of this document. Please review these documents
            carefully, as they describe your rights and restrictions with
            respect to this document. Code Components extracted from this
            document must include Simplified BSD License text as described in
            Section 4.e of the Trust Legal Provisions and are provided without
            warranty as described in the Simplified BSD License.<a href="#section-boilerplate.2-2" class="pilcrow">¶</a></p>
</section>
</div>
<div id="toc">
<section id="section-toc.1">
        <a href="#" onclick="scroll(0,0)" class="toplink">▲</a><h2 id="name-table-of-contents">
<a href="#name-table-of-contents" class="section-name selfRef">Table of Contents</a>
        </h2>
<nav class="toc"><ul class="ulEmpty toc compact">
<li class="ulEmpty toc compact" id="section-toc.1-1.1">
            <p id="section-toc.1-1.1.1" class="keepWithNext"><a href="#section-1" class="xref">1</a>.  <a href="#name-introduction" class="xref">Introduction</a></p>
<ul class="compact toc ulEmpty">
<li class="compact toc ulEmpty" id="section-toc.1-1.1.2.1">
                <p id="section-toc.1-1.1.2.1.1" class="keepWithNext"><a href="#section-1.1" class="xref">1.1</a>.  <a href="#name-requirements-language" class="xref">Requirements Language</a></p>
</li>
              <li class="compact toc ulEmpty" id="section-toc.1-1.1.2.2">
                <p id="section-toc.1-1.1.2.2.1" class="keepWithNext"><a href="#section-1.2" class="xref">1.2</a>.  <a href="#name-terminology" class="xref">Terminology</a></p>
</li>
            </ul>
</li>
          <li class="ulEmpty toc compact" 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-overview" class="xref">Overview</a></p>
<ul class="compact toc ulEmpty">
<li class="compact 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-overview-of-service-functio" class="xref">Overview of Service Function Chaining</a></p>
</li>
              <li class="compact 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-control-plane-overview" class="xref">Control Plane Overview</a></p>
</li>
            </ul>
</li>
          <li class="ulEmpty toc compact" id="section-toc.1-1.3">
            <p id="section-toc.1-1.3.1"><a href="#section-3" class="xref">3</a>.  <a href="#name-bgp-sfc-routes" class="xref">BGP SFC Routes</a></p>
<ul class="compact toc ulEmpty">
<li class="compact toc ulEmpty" id="section-toc.1-1.3.2.1">
                <p id="section-toc.1-1.3.2.1.1"><a href="#section-3.1" class="xref">3.1</a>.  <a href="#name-service-function-instance-r" class="xref">Service Function Instance Route (SFIR)</a></p>
<ul class="compact toc ulEmpty">
<li class="compact toc ulEmpty" id="section-toc.1-1.3.2.1.2.1">
                    <p id="section-toc.1-1.3.2.1.2.1.1"><a href="#section-3.1.1" class="xref">3.1.1</a>.  <a href="#name-sfir-pool-identifier-extend" class="xref">SFIR Pool Identifier Extended Community</a></p>
</li>
                  <li class="compact toc ulEmpty" id="section-toc.1-1.3.2.1.2.2">
                    <p id="section-toc.1-1.3.2.1.2.2.1"><a href="#section-3.1.2" class="xref">3.1.2</a>.  <a href="#name-mpls-mixed-swapping-stackin" class="xref">MPLS Mixed Swapping/Stacking Extended Community</a></p>
</li>
                </ul>
</li>
              <li class="compact toc ulEmpty" id="section-toc.1-1.3.2.2">
                <p id="section-toc.1-1.3.2.2.1"><a href="#section-3.2" class="xref">3.2</a>.  <a href="#name-service-function-path-route" class="xref">Service Function Path Route (SFPR)</a></p>
<ul class="compact toc ulEmpty">
<li class="compact toc ulEmpty" id="section-toc.1-1.3.2.2.2.1">
                    <p id="section-toc.1-1.3.2.2.2.1.1"><a href="#section-3.2.1" class="xref">3.2.1</a>.  <a href="#name-the-sfp-attribute" class="xref">The SFP Attribute</a></p>
</li>
                  <li class="compact toc ulEmpty" id="section-toc.1-1.3.2.2.2.2">
                    <p id="section-toc.1-1.3.2.2.2.2.1"><a href="#section-3.2.2" class="xref">3.2.2</a>.  <a href="#name-general-rules-for-the-sfp-a" class="xref">General Rules for the SFP Attribute</a></p>
</li>
                </ul>
</li>
            </ul>
</li>
          <li class="ulEmpty toc compact" id="section-toc.1-1.4">
            <p id="section-toc.1-1.4.1"><a href="#section-4" class="xref">4</a>.  <a href="#name-mode-of-operation" class="xref">Mode of Operation</a></p>
<ul class="compact toc ulEmpty">
<li class="compact toc ulEmpty" id="section-toc.1-1.4.2.1">
                <p id="section-toc.1-1.4.2.1.1"><a href="#section-4.1" class="xref">4.1</a>.  <a href="#name-route-targets" class="xref">Route Targets</a></p>
</li>
              <li class="compact toc ulEmpty" id="section-toc.1-1.4.2.2">
                <p id="section-toc.1-1.4.2.2.1"><a href="#section-4.2" class="xref">4.2</a>.  <a href="#name-service-function-instance-ro" class="xref">Service Function Instance Routes</a></p>
</li>
              <li class="compact toc ulEmpty" id="section-toc.1-1.4.2.3">
                <p id="section-toc.1-1.4.2.3.1"><a href="#section-4.3" class="xref">4.3</a>.  <a href="#name-service-function-path-routes" class="xref">Service Function Path Routes</a></p>
</li>
              <li class="compact toc ulEmpty" id="section-toc.1-1.4.2.4">
                <p id="section-toc.1-1.4.2.4.1"><a href="#section-4.4" class="xref">4.4</a>.  <a href="#name-classifier-operation" class="xref">Classifier Operation</a></p>
</li>
              <li class="compact toc ulEmpty" id="section-toc.1-1.4.2.5">
                <p id="section-toc.1-1.4.2.5.1"><a href="#section-4.5" class="xref">4.5</a>.  <a href="#name-service-function-forwarder-" class="xref">Service Function Forwarder Operation</a></p>
<ul class="compact toc ulEmpty">
<li class="compact toc ulEmpty" id="section-toc.1-1.4.2.5.2.1">
                    <p id="section-toc.1-1.4.2.5.2.1.1"><a href="#section-4.5.1" class="xref">4.5.1</a>.  <a href="#name-processing-with-gaps-in-the" class="xref">Processing with "Gaps" in the SI Sequence</a></p>
</li>
                </ul>
</li>
            </ul>
</li>
          <li class="ulEmpty toc compact" id="section-toc.1-1.5">
            <p id="section-toc.1-1.5.1"><a href="#section-5" class="xref">5</a>.  <a href="#name-selection-within-service-fu" class="xref">Selection within Service Function Paths</a></p>
</li>
          <li class="ulEmpty toc compact" id="section-toc.1-1.6">
            <p id="section-toc.1-1.6.1"><a href="#section-6" class="xref">6</a>.  <a href="#name-looping-jumping-and-branchi" class="xref">Looping, Jumping, and Branching</a></p>
<ul class="compact toc ulEmpty">
<li class="compact 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-protocol-control-of-looping" class="xref">Protocol Control of Looping, Jumping, and Branching</a></p>
</li>
              <li class="compact 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-implications-for-forwarding" class="xref">Implications for Forwarding State</a></p>
</li>
            </ul>
</li>
          <li class="ulEmpty toc compact" id="section-toc.1-1.7">
            <p id="section-toc.1-1.7.1"><a href="#section-7" class="xref">7</a>.  <a href="#name-advanced-topics" class="xref">Advanced Topics</a></p>
<ul class="compact toc ulEmpty">
<li class="compact toc ulEmpty" id="section-toc.1-1.7.2.1">
                <p id="section-toc.1-1.7.2.1.1"><a href="#section-7.1" class="xref">7.1</a>.  <a href="#name-correlating-service-functio" class="xref">Correlating Service Function Path Instances</a></p>
</li>
              <li class="compact toc ulEmpty" id="section-toc.1-1.7.2.2">
                <p id="section-toc.1-1.7.2.2.1"><a href="#section-7.2" class="xref">7.2</a>.  <a href="#name-considerations-for-stateful" class="xref">Considerations for Stateful Service Functions</a></p>
</li>
              <li class="compact toc ulEmpty" id="section-toc.1-1.7.2.3">
                <p id="section-toc.1-1.7.2.3.1"><a href="#section-7.3" class="xref">7.3</a>.  <a href="#name-vpn-considerations-and-priv" class="xref">VPN Considerations and Private Service Functions</a></p>
</li>
              <li class="compact toc ulEmpty" id="section-toc.1-1.7.2.4">
                <p id="section-toc.1-1.7.2.4.1"><a href="#section-7.4" class="xref">7.4</a>.  <a href="#name-flow-specification-for-sfc-" class="xref">Flow Specification for SFC Classifiers</a></p>
</li>
              <li class="compact toc ulEmpty" id="section-toc.1-1.7.2.5">
                <p id="section-toc.1-1.7.2.5.1"><a href="#section-7.5" class="xref">7.5</a>.  <a href="#name-choice-of-data-plane-spi-si" class="xref">Choice of Data Plane SPI/SI Representation</a></p>
<ul class="compact toc ulEmpty">
<li class="compact toc ulEmpty" id="section-toc.1-1.7.2.5.2.1">
                    <p id="section-toc.1-1.7.2.5.2.1.1"><a href="#section-7.5.1" class="xref">7.5.1</a>.  <a href="#name-mpls-representation-of-the-" class="xref">MPLS Representation of the SPI/SI</a></p>
</li>
                </ul>
</li>
              <li class="compact toc ulEmpty" id="section-toc.1-1.7.2.6">
                <p id="section-toc.1-1.7.2.6.1"><a href="#section-7.6" class="xref">7.6</a>.  <a href="#name-mpls-label-swapping-stackin" class="xref">MPLS Label Swapping/Stacking Operation</a></p>
</li>
              <li class="compact toc ulEmpty" id="section-toc.1-1.7.2.7">
                <p id="section-toc.1-1.7.2.7.1"><a href="#section-7.7" class="xref">7.7</a>.  <a href="#name-support-for-mpls-encapsulat" class="xref">Support for MPLS-Encapsulated NSH Packets</a></p>
</li>
            </ul>
</li>
          <li class="ulEmpty toc compact" id="section-toc.1-1.8">
            <p id="section-toc.1-1.8.1"><a href="#section-8" class="xref">8</a>.  <a href="#name-examples" class="xref">Examples</a></p>
<ul class="compact toc ulEmpty">
<li class="compact toc ulEmpty" id="section-toc.1-1.8.2.1">
                <p id="section-toc.1-1.8.2.1.1"><a href="#section-8.1" class="xref">8.1</a>.  <a href="#name-example-explicit-sfp-with-n" class="xref">Example Explicit SFP with No Choices</a></p>
</li>
              <li class="compact toc ulEmpty" id="section-toc.1-1.8.2.2">
                <p id="section-toc.1-1.8.2.2.1"><a href="#section-8.2" class="xref">8.2</a>.  <a href="#name-example-sfp-with-choice-of-" class="xref">Example SFP with Choice of SFIs</a></p>
</li>
              <li class="compact toc ulEmpty" id="section-toc.1-1.8.2.3">
                <p id="section-toc.1-1.8.2.3.1"><a href="#section-8.3" class="xref">8.3</a>.  <a href="#name-example-sfp-with-open-choic" class="xref">Example SFP with Open Choice of SFIs</a></p>
</li>
              <li class="compact toc ulEmpty" id="section-toc.1-1.8.2.4">
                <p id="section-toc.1-1.8.2.4.1"><a href="#section-8.4" class="xref">8.4</a>.  <a href="#name-example-sfp-with-choice-of-s" class="xref">Example SFP with Choice of SFTs</a></p>
</li>
              <li class="compact toc ulEmpty" id="section-toc.1-1.8.2.5">
                <p id="section-toc.1-1.8.2.5.1"><a href="#section-8.5" class="xref">8.5</a>.  <a href="#name-example-correlated-bidirect" class="xref">Example Correlated Bidirectional SFPs</a></p>
</li>
              <li class="compact toc ulEmpty" id="section-toc.1-1.8.2.6">
                <p id="section-toc.1-1.8.2.6.1"><a href="#section-8.6" class="xref">8.6</a>.  <a href="#name-example-correlated-asymmetr" class="xref">Example Correlated Asymmetrical Bidirectional SFPs</a></p>
</li>
              <li class="compact toc ulEmpty" id="section-toc.1-1.8.2.7">
                <p id="section-toc.1-1.8.2.7.1"><a href="#section-8.7" class="xref">8.7</a>.  <a href="#name-example-looping-in-an-sfp" class="xref">Example Looping in an SFP</a></p>
</li>
              <li class="compact toc ulEmpty" id="section-toc.1-1.8.2.8">
                <p id="section-toc.1-1.8.2.8.1"><a href="#section-8.8" class="xref">8.8</a>.  <a href="#name-example-branching-in-an-sfp" class="xref">Example Branching in an SFP</a></p>
</li>
              <li class="compact toc ulEmpty" id="section-toc.1-1.8.2.9">
                <p id="section-toc.1-1.8.2.9.1"><a href="#section-8.9" class="xref">8.9</a>.  <a href="#name-examples-of-sfps-with-state" class="xref">Examples of SFPs with Stateful Service Functions</a></p>
<ul class="compact toc ulEmpty">
<li class="compact toc ulEmpty" id="section-toc.1-1.8.2.9.2.1">
                    <p id="section-toc.1-1.8.2.9.2.1.1"><a href="#section-8.9.1" class="xref">8.9.1</a>.  <a href="#name-forward-and-reverse-choice-" class="xref">Forward and Reverse Choice Made at the SFF</a></p>
</li>
                  <li class="compact toc ulEmpty" id="section-toc.1-1.8.2.9.2.2">
                    <p id="section-toc.1-1.8.2.9.2.2.1"><a href="#section-8.9.2" class="xref">8.9.2</a>.  <a href="#name-parallel-end-to-end-sfps-wi" class="xref">Parallel End-to-End SFPs with Shared SFF</a></p>
</li>
                  <li class="compact toc ulEmpty" id="section-toc.1-1.8.2.9.2.3">
                    <p id="section-toc.1-1.8.2.9.2.3.1"><a href="#section-8.9.3" class="xref">8.9.3</a>.  <a href="#name-parallel-end-to-end-sfps-wit" class="xref">Parallel End-to-End SFPs with Separate SFFs</a></p>
</li>
                  <li class="compact toc ulEmpty" id="section-toc.1-1.8.2.9.2.4">
                    <p id="section-toc.1-1.8.2.9.2.4.1"><a href="#section-8.9.4" class="xref">8.9.4</a>.  <a href="#name-parallel-sfps-downstream-of" class="xref">Parallel SFPs Downstream of the Choice</a></p>
</li>
                </ul>
</li>
              <li class="compact toc ulEmpty" id="section-toc.1-1.8.2.10">
                <p id="section-toc.1-1.8.2.10.1"><a href="#section-8.10" class="xref">8.10</a>. <a href="#name-examples-using-ipv6-address" class="xref">Examples Using IPv6 Addressing</a></p>
<ul class="compact toc ulEmpty">
<li class="compact toc ulEmpty" id="section-toc.1-1.8.2.10.2.1">
                    <p id="section-toc.1-1.8.2.10.2.1.1"><a href="#section-8.10.1" class="xref">8.10.1</a>.  <a href="#name-example-explicit-sfp-with-no" class="xref">Example Explicit SFP with No Choices</a></p>
</li>
                  <li class="compact toc ulEmpty" id="section-toc.1-1.8.2.10.2.2">
                    <p id="section-toc.1-1.8.2.10.2.2.1"><a href="#section-8.10.2" class="xref">8.10.2</a>.  <a href="#name-example-sfp-with-choice-of-sf" class="xref">Example SFP with Choice of SFIs</a></p>
</li>
                  <li class="compact toc ulEmpty" id="section-toc.1-1.8.2.10.2.3">
                    <p id="section-toc.1-1.8.2.10.2.3.1"><a href="#section-8.10.3" class="xref">8.10.3</a>.  <a href="#name-example-sfp-with-open-choice" class="xref">Example SFP with Open Choice of SFIs</a></p>
</li>
                  <li class="compact toc ulEmpty" id="section-toc.1-1.8.2.10.2.4">
                    <p id="section-toc.1-1.8.2.10.2.4.1"><a href="#section-8.10.4" class="xref">8.10.4</a>.  <a href="#name-example-sfp-with-choice-of-sft" class="xref">Example SFP with Choice of SFTs</a></p>
</li>
                </ul>
</li>
            </ul>
</li>
          <li class="ulEmpty toc compact" id="section-toc.1-1.9">
            <p id="section-toc.1-1.9.1"><a href="#section-9" class="xref">9</a>.  <a href="#name-security-considerations" class="xref">Security Considerations</a></p>
</li>
          <li class="ulEmpty toc compact" id="section-toc.1-1.10">
            <p id="section-toc.1-1.10.1"><a href="#section-10" class="xref">10</a>. <a href="#name-iana-considerations" class="xref">IANA Considerations</a></p>
<ul class="compact toc ulEmpty">
<li class="compact toc ulEmpty" id="section-toc.1-1.10.2.1">
                <p id="section-toc.1-1.10.2.1.1"><a href="#section-10.1" class="xref">10.1</a>.  <a href="#name-new-bgp-af-safi" class="xref">New BGP AF/SAFI</a></p>
</li>
              <li class="compact toc ulEmpty" id="section-toc.1-1.10.2.2">
                <p id="section-toc.1-1.10.2.2.1"><a href="#section-10.2" class="xref">10.2</a>.  <a href="#name-sfp-attribute-bgp-path-attr" class="xref">"SFP attribute" BGP Path Attribute</a></p>
</li>
              <li class="compact toc ulEmpty" id="section-toc.1-1.10.2.3">
                <p id="section-toc.1-1.10.2.3.1"><a href="#section-10.3" class="xref">10.3</a>.  <a href="#name-sfp-attribute-tlvs-registry" class="xref">"SFP Attribute TLVs" Registry</a></p>
</li>
              <li class="compact toc ulEmpty" id="section-toc.1-1.10.2.4">
                <p id="section-toc.1-1.10.2.4.1"><a href="#section-10.4" class="xref">10.4</a>.  <a href="#name-sfp-association-type-regist" class="xref">"SFP Association Type" Registry</a></p>
</li>
              <li class="compact toc ulEmpty" id="section-toc.1-1.10.2.5">
                <p id="section-toc.1-1.10.2.5.1"><a href="#section-10.5" class="xref">10.5</a>.  <a href="#name-service-function-chaining-s" class="xref">"Service Function Chaining Service Function Types" Registry</a></p>
</li>
              <li class="compact toc ulEmpty" id="section-toc.1-1.10.2.6">
                <p id="section-toc.1-1.10.2.6.1"><a href="#section-10.6" class="xref">10.6</a>.  <a href="#name-flow-specification-for-sfc-c" class="xref">Flow Specification for SFC Classifiers</a></p>
</li>
              <li class="compact toc ulEmpty" id="section-toc.1-1.10.2.7">
                <p id="section-toc.1-1.10.2.7.1"><a href="#section-10.7" class="xref">10.7</a>.  <a href="#name-new-bgp-transitive-extended" class="xref">New BGP Transitive Extended Community Type</a></p>
</li>
              <li class="compact toc ulEmpty" id="section-toc.1-1.10.2.8">
                <p id="section-toc.1-1.10.2.8.1"><a href="#section-10.8" class="xref">10.8</a>.  <a href="#name-sfc-extended-community-sub-" class="xref">"SFC Extended Community Sub-Types" Registry</a></p>
</li>
              <li class="compact toc ulEmpty" id="section-toc.1-1.10.2.9">
                <p id="section-toc.1-1.10.2.9.1"><a href="#section-10.9" class="xref">10.9</a>.  <a href="#name-new-spi-si-representation-s" class="xref">New SPI/SI Representation Sub-TLV</a></p>
</li>
              <li class="compact toc ulEmpty" id="section-toc.1-1.10.2.10">
                <p id="section-toc.1-1.10.2.10.1"><a href="#section-10.10" class="xref">10.10</a>. <a href="#name-sfc-spi-si-representation-f" class="xref">"SFC SPI/SI Representation Flags" Registry</a></p>
</li>
            </ul>
</li>
          <li class="ulEmpty toc compact" id="section-toc.1-1.11">
            <p id="section-toc.1-1.11.1"><a href="#section-11" class="xref">11</a>. <a href="#name-references" class="xref">References</a></p>
<ul class="compact toc ulEmpty">
<li class="compact toc ulEmpty" id="section-toc.1-1.11.2.1">
                <p id="section-toc.1-1.11.2.1.1"><a href="#section-11.1" class="xref">11.1</a>.  <a href="#name-normative-references" class="xref">Normative References</a></p>
</li>
              <li class="compact toc ulEmpty" id="section-toc.1-1.11.2.2">
                <p id="section-toc.1-1.11.2.2.1"><a href="#section-11.2" class="xref">11.2</a>.  <a href="#name-informative-references" class="xref">Informative References</a></p>
</li>
            </ul>
</li>
          <li class="ulEmpty toc compact" id="section-toc.1-1.12">
            <p id="section-toc.1-1.12.1"><a href="#section-appendix.a" class="xref"></a><a href="#name-acknowledgements" class="xref">Acknowledgements</a></p>
</li>
          <li class="ulEmpty toc compact" id="section-toc.1-1.13">
            <p id="section-toc.1-1.13.1"><a href="#section-appendix.b" class="xref"></a><a href="#name-contributors" class="xref">Contributors</a></p>
</li>
          <li class="ulEmpty toc compact" id="section-toc.1-1.14">
            <p id="section-toc.1-1.14.1"><a href="#section-appendix.c" class="xref"></a><a href="#name-authors-addresses" class="xref">Authors' Addresses</a></p>
</li>
        </ul>
</nav>
</section>
</div>
<div id="introduction">
<section id="section-1">
      <h2 id="name-introduction">
<a href="#section-1" class="section-number selfRef">1. </a><a href="#name-introduction" class="section-name selfRef">Introduction</a>
      </h2>
<p id="section-1-1">As described in <span>[<a href="#RFC7498" class="xref">RFC7498</a>]</span>, the delivery of end-to-end services can
       require a packet to pass through a series of Service Functions (SFs) --
       e.g., WAN and
       application accelerators, Deep Packet Inspection (DPI) engines, firewalls, TCP
       optimizers, and server load balancers -- in a specified order; this is termed
       "service function chaining".  There are a number of issues associated with
       deploying and maintaining service function chaining in production networks, which are
       described below.<a href="#section-1-1" class="pilcrow">¶</a></p>
<p id="section-1-2">Historically, if a packet needed to travel through a particular service chain, the
       nodes hosting the service functions of that chain were placed in the network topology
       in such a way that the packet could not reach its ultimate destination without first
       passing through all the service functions in the proper order.  This need to place the
       service functions at particular topological locations limited the ability to adapt a
       service function chain to changes in network topology (e.g., link or node failures),
       network utilization, or offered service load.  These topological restrictions on where
       the service functions could be placed raised the following issues:<a href="#section-1-2" class="pilcrow">¶</a></p>
<ol start="1" type="1" class="normal type-1" id="section-1-3">
<li id="section-1-3.1">The process of configuring or modifying a service function chain is operationally
            complex and may require changes to the network topology.<a href="#section-1-3.1" class="pilcrow">¶</a>
</li>
        <li id="section-1-3.2">Alternate or redundant service functions may need to be co-located with the
            primary service functions.<a href="#section-1-3.2" class="pilcrow">¶</a>
</li>
        <li id="section-1-3.3">When there is more than one path between source and destination, forwarding may be
            asymmetric, and it may be difficult to support bidirectional service function chains
            using simple routing methodologies and protocols without adding mechanisms for traffic
            steering or traffic engineering.<a href="#section-1-3.3" class="pilcrow">¶</a>
</li>
      </ol>
<p id="section-1-4">In order to address these issues, the service function chaining architecture describes service function chains
       that are built in their own overlay network (the service function overlay network),
       coexisting with other overlay networks, over a common underlay network
       <span>[<a href="#RFC7665" class="xref">RFC7665</a>]</span>.  A service function chain is a sequence of service functions
       through which packet flows that satisfy specified criteria will pass.<a href="#section-1-4" class="pilcrow">¶</a></p>
<p id="section-1-5">This document describes the use of BGP as a control plane for networks that support service function chaining.  The document introduces a new BGP address family
       called the "Service Function Chain (SFC) Address Family Identifier / Subsequent Address Family Identifier"
       (SFC AFI/SAFI) with two Route Types.  One Route Type is originated by a
       node to advertise that it hosts a particular instance of a specified service function.
       This Route Type also provides "instructions" on how to send a packet to the hosting
       node in a way that indicates that the service function has to be applied to the packet.
       The other Route Type is used by a controller (a centralized network component responsible
       for planning and coordinating service function chaining within the network) to advertise
       the paths of "chains" of service functions and give a unique designator to each such
       path so that they can be used in conjunction with the Network Service Header (NSH)
       <span>[<a href="#RFC8300" class="xref">RFC8300</a>]</span>.<a href="#section-1-5" class="pilcrow">¶</a></p>
<p id="section-1-6">This document adopts the service function chaining architecture described in <span>[<a href="#RFC7665" class="xref">RFC7665</a>]</span>.<a href="#section-1-6" class="pilcrow">¶</a></p>
<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 id="terms">
<section id="section-1.2">
        <h3 id="name-terminology">
<a href="#section-1.2" class="section-number selfRef">1.2. </a><a href="#name-terminology" class="section-name selfRef">Terminology</a>
        </h3>
<p id="section-1.2-1">This document uses the following terms from <span>[<a href="#RFC7665" class="xref">RFC7665</a>]</span>:<a href="#section-1.2-1" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-1.2-2.1">Bidirectional Service Function Chain<a href="#section-1.2-2.1" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-1.2-2.2">Classifier<a href="#section-1.2-2.2" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-1.2-2.3">Service Function (SF)<a href="#section-1.2-2.3" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-1.2-2.4">Service Function Chain (SFC)<a href="#section-1.2-2.4" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-1.2-2.5">Service Function Forwarder (SFF)<a href="#section-1.2-2.5" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-1.2-2.6">Service Function Instance (SFI)<a href="#section-1.2-2.6" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-1.2-2.7">Service Function Path (SFP)<a href="#section-1.2-2.7" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-1.2-2.8">SFC branching<a href="#section-1.2-2.8" class="pilcrow">¶</a>
</li>
        </ul>
<p id="section-1.2-3">Additionally, this document uses the following terms from <span>[<a href="#RFC8300" class="xref">RFC8300</a>]</span>:<a href="#section-1.2-3" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-1.2-4.1">Network Service Header (NSH)<a href="#section-1.2-4.1" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-1.2-4.2">Service Index (SI)<a href="#section-1.2-4.2" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-1.2-4.3">Service Path Identifier (SPI)<a href="#section-1.2-4.3" class="pilcrow">¶</a>
</li>
        </ul>
<p id="section-1.2-5">This document introduces the following terms:<a href="#section-1.2-5" class="pilcrow">¶</a></p>
<span class="break"></span><dl class="dlParallel" id="section-1.2-6">
          <dt id="section-1.2-6.1">Service Function Instance Route (SFIR):</dt>
          <dd style="margin-left: 1.5em" id="section-1.2-6.2">A new BGP Route Type advertised by the
                node that hosts an SFI to describe the SFI and to announce the way to forward a
                packet to the node through the underlay network.<a href="#section-1.2-6.2" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-1.2-6.3">Service Function Overlay Network:</dt>
          <dd style="margin-left: 1.5em" id="section-1.2-6.4">The logical network comprised of classifiers,
                SFFs, and SFIs that are connected by paths or tunnels through underlay transport
                networks.<a href="#section-1.2-6.4" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-1.2-6.5">Service Function Path Route (SFPR):</dt>
          <dd style="margin-left: 1.5em" id="section-1.2-6.6">A new BGP Route Type originated by controllers to
                advertise the details of each SFP.<a href="#section-1.2-6.6" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-1.2-6.7">Service Function Type (SFT):</dt>
          <dd style="margin-left: 1.5em" id="section-1.2-6.8">An indication of the function and features of an SFI.<a href="#section-1.2-6.8" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
</dl>
</section>
</div>
</section>
</div>
<div id="overview">
<section id="section-2">
      <h2 id="name-overview">
<a href="#section-2" class="section-number selfRef">2. </a><a href="#name-overview" class="section-name selfRef">Overview</a>
      </h2>
<p id="section-2-1">This section provides an overview of service function chaining in general and the control
       plane defined in this document.  After reading this section, readers may find it helpful to
       look through <a href="#example" class="xref">Section 8</a> for some simple worked examples.<a href="#section-2-1" class="pilcrow">¶</a></p>
<div id="funcover">
<section id="section-2.1">
        <h3 id="name-overview-of-service-functio">
<a href="#section-2.1" class="section-number selfRef">2.1. </a><a href="#name-overview-of-service-functio" class="section-name selfRef">Overview of Service Function Chaining</a>
        </h3>
<p id="section-2.1-1">In <span>[<a href="#RFC8300" class="xref">RFC8300</a>]</span>, a Service Function Chain (SFC) is an ordered list of
         Service Functions (SFs).  A Service Function Path (SFP) is an indication of which instances
         of SFs are acceptable to be traversed in an instantiation of an SFC in a service function
         overlay network.  The Service Path Identifier (SPI) is a 24-bit number that identifies
         a specific SFP, and a Service Index (SI) is an 8-bit number that identifies a specific point
         in that path.  In the context of a particular SFP (identified by an SPI), an SI represents a
         particular service function and indicates the order of that SF in the SFP.<a href="#section-2.1-1" class="pilcrow">¶</a></p>
<p id="section-2.1-2">Within the context of a specific SFP, an SI references a set of one or more SFs.  Each of those SFs
         may be supported by one or more Service Function Instances (SFIs).  Thus, an SI may represent a choice
         of SFIs of one or more service function types.  By deploying multiple SFIs for a single SF, one
         can provide load balancing and redundancy.<a href="#section-2.1-2" class="pilcrow">¶</a></p>
<p id="section-2.1-3">A special functional element, called a "classifier", is located at each ingress point to a service
         function overlay network.  It assigns the packets of a given packet flow to a specific SFP.  This may be done by comparing specific fields in a packet's header with
         local policy, which may be customer/network/service specific.  The classifier picks an SFP and
         sets the SPI accordingly; it then sets the SI to the value of the SI for the first hop in the
         SFP, and then prepends a Network Service Header (NSH) <span>[<a href="#RFC8300" class="xref">RFC8300</a>]</span>
         containing the assigned SPI/SI to that packet.  Note that the classifier and the node that
         hosts the first SF in an SFP need not be located at the same
         point in the service function overlay network.<a href="#section-2.1-3" class="pilcrow">¶</a></p>
<p id="section-2.1-4">Note that the presence of the NSH can make it difficult for nodes in the underlay network
         to locate the fields in the original packet that would normally be
  used to constrain equal-cost multipath (ECMP) forwarding.  Therefore,
  it is recommended that the node prepending the
         NSH also provide some form of entropy indicator that can be used in the underlay network.  How
         this indicator is generated and supplied, and how an SFF generates a new entropy indicator
         when it forwards a packet to the next SFF, are out of the scope of this document.<a href="#section-2.1-4" class="pilcrow">¶</a></p>
<p id="section-2.1-5">The Service Function Forwarder (SFF) receives a packet from the previous node in an SFP, removes the packet's link layer or tunnel encapsulation, and hands the
         packet and the NSH to the SFI for processing.  The SFI has no knowledge
         of the SFP.<a href="#section-2.1-5" class="pilcrow">¶</a></p>
<p id="section-2.1-6">When the SFF receives the packet and the NSH back from the SFI, it must select the next SFI
         along the path using the SPI and SI in the NSH and potentially choosing between multiple SFIs
         (possibly of different SFTs), as described in <a href="#selection" class="xref">Section 5</a>.  In
         the normal case, the SPI remains unchanged, and the SI will have been decremented to indicate the
         next SF along the path.  But other possibilities exist if the SF makes other changes to the NSH
         through a process of reclassification:<a href="#section-2.1-6" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-2.1-7.1">
            <p id="section-2.1-7.1.1">The SI in the NSH may indicate:<a href="#section-2.1-7.1.1" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-2.1-7.1.2.1">A previous SF in the path; this is known as "looping" (see
       <a href="#looping" class="xref">Section 6</a>).<a href="#section-2.1-7.1.2.1" class="pilcrow">¶</a>
</li>
              <li class="normal" id="section-2.1-7.1.2.2">An SF further down the path; this is known as "jumping"
       (again see <a href="#looping" class="xref">Section 6</a>).<a href="#section-2.1-7.1.2.2" class="pilcrow">¶</a>
</li>
            </ul>
</li>
          <li class="normal" id="section-2.1-7.2">The SPI and the SI may point to an SF on a different SFP; this is known as "branching" (see
               <a href="#looping" class="xref">Section 6</a>).<a href="#section-2.1-7.2" class="pilcrow">¶</a>
</li>
        </ul>
<p id="section-2.1-8">Such modifications are limited to within the same service function overlay network.  That is, an
         SPI is known within the scope of service function overlay network.  Furthermore, the new SI value
         is interpreted in the context of the SFP identified by the SPI.<a href="#section-2.1-8" class="pilcrow">¶</a></p>
<p id="section-2.1-9">As described in <span>[<a href="#RFC8300" class="xref">RFC8300</a>]</span>, an SPI that is unknown or not valid is treated as an error, and
         the SFF drops the packet; such errors should be logged, and such logs are subject to rate limits.<a href="#section-2.1-9" class="pilcrow">¶</a></p>
<p id="section-2.1-10">Also, as described in <span>[<a href="#RFC8300" class="xref">RFC8300</a>]</span>, an SFF receiving an SI that is unknown in the
         context of the SPI can reduce the value to the next meaningful SI value in the SFP indicated by
         the SPI.  If no such value exists, or if the SFF does not support reducing the SI, the SFF drops the
         packet and should log the event; such logs are also subject to rate limits.<a href="#section-2.1-10" class="pilcrow">¶</a></p>
<p id="section-2.1-11">The SFF then selects an SFI that provides the SF denoted by the SPI/SI and forwards the packet
         to the SFF that supports that SFI.<a href="#section-2.1-11" class="pilcrow">¶</a></p>
<p id="section-2.1-12"><span>[<a href="#RFC8300" class="xref">RFC8300</a>]</span> makes it clear that the intended scope is for use within a single
         provider's operational domain.<a href="#section-2.1-12" class="pilcrow">¶</a></p>
<p id="section-2.1-13">This document adopts the service function chaining architecture described in <span>[<a href="#RFC7665" class="xref">RFC7665</a>]</span> and adds a
         control plane to support the functions, as described in <a href="#ctrlover" class="xref">Section 2.2</a>.  An essential
         component of this solution is the controller.  This is a network component responsible for
         planning SFPs within the network.  It gathers information about the availability of SFIs and SFFs,
         instructs the control plane about the SFPs to be programmed, and instructs the classifiers how
         to assign traffic flows to individual SFPs.<a href="#section-2.1-13" class="pilcrow">¶</a></p>
</section>
</div>
<div id="ctrlover">
<section id="section-2.2">
        <h3 id="name-control-plane-overview">
<a href="#section-2.2" class="section-number selfRef">2.2. </a><a href="#name-control-plane-overview" class="section-name selfRef">Control Plane Overview</a>
        </h3>
<p id="section-2.2-1">To accomplish the function described in <a href="#funcover" class="xref">Section 2.1</a>, this document
         introduces the Service Function Type (SFT), which is the category of SF that is supported
         by an SFF (such as "firewall").  An IANA registry of service function types is introduced
         in <a href="#SFTreg" class="xref">Section 10.5</a> and is consistent with types used in other work, such as
         <span>[<a href="#I-D.dawra-idr-bgp-ls-sr-service-segments" class="xref">BGP-LS-SR</a>]</span>.  An SFF may support SFs of
         multiple different SFTs, and it may support multiple SFIs of each SF.<a href="#section-2.2-1" class="pilcrow">¶</a></p>
<p id="section-2.2-2">The registry of SFT values (see <a href="#SFTreg" class="xref">Section 10.5</a>) is split into three ranges with assignment
         policies per <span>[<a href="#RFC8126" class="xref">RFC8126</a>]</span>:<a href="#section-2.2-2" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-2.2-3.1">The special-purpose SFT values range is assigned through Standards Action.
               Values in that range are used for special SFC operations and do not apply to
               the types of SF that may form part of the SFP.<a href="#section-2.2-3.1" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-2.2-3.2">The First Come First Served range tracks assignments of SFT values made by any
               party that defines an SF type. Reference through an Internet-Draft is desirable,
               but not required.<a href="#section-2.2-3.2" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-2.2-3.3">The Private Use range is not tracked by IANA and is primarily intended for use
               in private networks where the meaning of the SFT values is locally tracked and
               under the control of a local administrator.<a href="#section-2.2-3.3" class="pilcrow">¶</a>
</li>
        </ul>
<p id="section-2.2-4">It is envisaged that the majority of SFT values used will be assigned from the First Come
         First Served space in the registry.  This will ensure interoperability, especially in
         situations where software and hardware from different vendors are deployed in the same
         networks, or when networks are merged. However, operators of private networks may choose
         to develop their own SFs and manage the configuration and operation of their network through
         their own list of SFT values.<a href="#section-2.2-4" class="pilcrow">¶</a></p>
<p id="section-2.2-5">This document also introduces a new BGP AFI/SAFI (values 31 and 9, respectively) for "SFC Routes".
         Two SFC Route Types are defined by this document: the Service Function Instance Route (SFIR) and
         the Service Function Path Route (SFPR).  As detailed in <a href="#sfcBGPRoutes" class="xref">Section 3</a>, the Route
         Type is indicated by a subfield in the Network Layer Reachability Information (NLRI).<a href="#section-2.2-5" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-2.2-6.1">The SFIR is advertised by the node that provides access to the service function instance
               (i.e., the SFF).  The SFIR describes a particular instance of a particular SF
               (i.e., an SFI) and the way to forward a packet to it through
        the underlay network, i.e., IP
               address and encapsulation information.<a href="#section-2.2-6.1" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-2.2-6.2">
            <p id="section-2.2-6.2.1">The SFPRs are originated by controllers.  One SFPR is originated for each SFP.  The SFPR specifies:<a href="#section-2.2-6.2.1" class="pilcrow">¶</a></p>
<ol start="1" type="A" class="normal type-A" id="section-2.2-6.2.2">
<li id="section-2.2-6.2.2.1">the SPI of the path,<a href="#section-2.2-6.2.2.1" class="pilcrow">¶</a>
</li>
              <li id="section-2.2-6.2.2.2">the sequence of SFTs and/or SFIs of which the path consists, and<a href="#section-2.2-6.2.2.2" class="pilcrow">¶</a>
</li>
              <li id="section-2.2-6.2.2.3">for each such SFT or SFI, the SI that represents it in the identified path.<a href="#section-2.2-6.2.2.3" class="pilcrow">¶</a>
</li>
            </ol>
</li>
        </ul>
<p id="section-2.2-7">This approach assumes that there is an underlay network that provides connectivity between
         SFFs and controllers and that the SFFs are grouped to form one or more service function
         overlay networks through which SFPs are built.  We assume that the controllers have BGP
         connectivity to all SFFs and all classifiers within each service function overlay network.<a href="#section-2.2-7" class="pilcrow">¶</a></p>
<p id="section-2.2-8">When choosing the next SFI in a path, the SFF uses the SPI and SI as well as the SFT to choose
         among the SFIs, applying, for example, a load-balancing algorithm or direct knowledge of the
         underlay network topology, as described in <a href="#mode" class="xref">Section 4</a>.<a href="#section-2.2-8" class="pilcrow">¶</a></p>
<p id="section-2.2-9">The SFF then encapsulates the packet using the encapsulation specified by the SFIR of the
         selected SFI and forwards the packet.  See <a href="#SFCarch" class="xref">Figure 1</a>.<a href="#section-2.2-9" class="pilcrow">¶</a></p>
<p id="section-2.2-10">Thus, the SFF can be seen as a portal in the underlay network through which a particular SFI
         is reached.<a href="#section-2.2-10" class="pilcrow">¶</a></p>
<p id="section-2.2-11"><a href="#SFCarch" class="xref">Figure 1</a> shows a reference model for the service function chaining architecture.  There are four SFFs
         (SFF-1 through SFF-4) connected by tunnels across the underlay network.  Packets arrive at
         a classifier and are channeled along SFPs to destinations reachable through SFF-4.<a href="#section-2.2-11" class="pilcrow">¶</a></p>
<p id="section-2.2-12">SFF-1 and SFF-4 each have one instance of one SF attached (SFa and SFe).  SFF-2 has two types
         of SF attached: one instance of one (SFc) and three instances of the other (SFb).
         SFF-3 has just one instance of an SF (SFd), but in this case, the type of SFd is the same
         type as SFb (SFTx).<a href="#section-2.2-12" class="pilcrow">¶</a></p>
<p id="section-2.2-13">This figure demonstrates how load balancing can be achieved by creating several SFPs that satisfy
         the same SFC.  Suppose an SFC needs to include SFa, an SF of type SFTx, and SFc.  A number of SFPs
         can be constructed using any instance of SFb or using SFd.  Load balancing may be applied at two
         places:<a href="#section-2.2-13" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-2.2-14.1">The classifier may distribute different flows onto different SFPs to share the load in the
              network and across SFIs.<a href="#section-2.2-14.1" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-2.2-14.2">SFF-2 may distribute different flows (on the same SFP) to different instances of SFb to share
              the processing load.<a href="#section-2.2-14.2" class="pilcrow">¶</a>
</li>
        </ul>
<p id="section-2.2-15">Note that, for convenience and clarity, <a href="#SFCarch" class="xref">Figure 1</a> shows only a few tunnels between
         SFFs.  There could be a full mesh of such tunnels, or more likely, a selection of tunnels connecting
         key SFFs to enable the construction of SFPs and balance load and traffic in the network.  Further,
         the figure does not show any controllers; these would each have BGP connectivity to the classifier and
         all of the SFFs.<a href="#section-2.2-15" class="pilcrow">¶</a></p>
<span id="name-the-service-function-chaini"></span><div id="SFCarch">
<figure id="figure-1">
          <div class="artwork art-text alignLeft" id="section-2.2-16.1">
<pre>
    Packets
    | | |
 ------------
|            |
| Classifier |
|            |
 ------+-----
       |
    ---+---                 ---------           -------
   |       |    Tunnel     |         |         |       |
   | SFF-1 |===============|  SFF-2  |=========| SFF-4 |
   |       |               |         |         |       |
   |       |                -+-----+-          |       |
   |       |  ,,,,,,,,,,,,,,/,,     \          |       |
   |       | '  .........../.  '   ..\......   |       |
   |       | ' : SFb      /  : '  :   \ SFc :  |       |
   |       | ' :      ---+-  : '  :  --+--  :  |       |
   |       | ' :    -| SFI | : '  : | SFI | :  |       |
   |       | ' :  -|  -----  : '  :  -----  :  |       |
   |       | ' : |  -----    : '   .........   |       |
   |       | ' :  -----      : '               |       |
   |       | '  .............  '               |       |--- Dests
   |       | '                 '               |       |--- Dests
   |       | '    .........    '               |       |
   |       | '   :  -----  :   '               |       |
   |       | '   : | SFI | :   '               |       |
   |       | '   :  --+--  :   '               |       |
   |       | '   :SFd |    :   '               |       |
   |       | '    ....|....    '               |       |
   |       | '        |        '               |       |
   |       | ' SFTx   |        '               |       |
   |       | ',,,,,,,,|,,,,,,,,'               |       |
   |       |          |                        |       |
   |       |       ---+---                     |       |
   |       |      |       |                    |       |
   |       |======| SFF-3 |====================|       |
    ---+---       |       |                     ---+---
       |           -------                         |
   ....|....                                   ....|....
  :    | SFa:                                 :    | SFe:
  :  --+--  :                                 :  --+--  :
  : | SFI | :                                 : | SFI | :
  :  -----  :                                 :  -----  :
   .........                                   .........
</pre>
</div>
<figcaption><a href="#figure-1" class="selfRef">Figure 1</a>:
<a href="#name-the-service-function-chaini" class="selfRef">The Service Function Chaining Architecture Reference Model</a>
          </figcaption></figure>
</div>
<p id="section-2.2-17">As previously noted, <span>[<a href="#RFC8300" class="xref">RFC8300</a>]</span> makes it clear that the mechanisms it defines
         are intended for use within a single provider's operational domain.  This reduces the
        requirements on the control plane function.<a href="#section-2.2-17" class="pilcrow">¶</a></p>
<p id="section-2.2-18"><span><a href="https://www.rfc-editor.org/rfc/rfc7665#section-5.2" class="relref">Section 5.2</a> of [<a href="#RFC7665" class="xref">RFC7665</a>]</span> sets out the functions provided by a control plane for a service function chaining network.
          The functions are broken down into six items, the first four of which are
         completely covered by the mechanisms described in this document:<a href="#section-2.2-18" class="pilcrow">¶</a></p>
<ol start="1" type="1" class="normal type-1" id="section-2.2-19">
<li id="section-2.2-19.1">Visibility of all SFs and the SFFs through which they are reached.<a href="#section-2.2-19.1" class="pilcrow">¶</a>
</li>
          <li id="section-2.2-19.2">Computation of SFPs and programming into the network.<a href="#section-2.2-19.2" class="pilcrow">¶</a>
</li>
          <li id="section-2.2-19.3">Selection of SFIs explicitly in the SFP or dynamically within the network.<a href="#section-2.2-19.3" class="pilcrow">¶</a>
</li>
          <li id="section-2.2-19.4">Programming of SFFs with forwarding path information.<a href="#section-2.2-19.4" class="pilcrow">¶</a>
</li>
        </ol>
<p id="section-2.2-20">The fifth and sixth items in the list in RFC 7665 concern the use of metadata.  These are
         more peripheral to the control plane mechanisms defined in this document but are discussed
         in <a href="#classy" class="xref">Section 4.4</a>.<a href="#section-2.2-20" class="pilcrow">¶</a></p>
</section>
</div>
</section>
</div>
<div id="sfcBGPRoutes">
<section id="section-3">
      <h2 id="name-bgp-sfc-routes">
<a href="#section-3" class="section-number selfRef">3. </a><a href="#name-bgp-sfc-routes" class="section-name selfRef">BGP SFC Routes</a>
      </h2>
<p id="section-3-1">This document defines a new AFI/SAFI for BGP, known as "SFC", with an NLRI that is described
       in this section.<a href="#section-3-1" class="pilcrow">¶</a></p>
<p id="section-3-2">The format of the SFC NLRI is shown in <a href="#SFCnlriFig" class="xref">Figure 2</a>.<a href="#section-3-2" class="pilcrow">¶</a></p>
<span id="name-the-format-of-the-sfc-nlri"></span><div id="SFCnlriFig">
<figure id="figure-2">
        <div class="artwork art-text alignLeft" id="section-3-3.1">
<pre>
                 +---------------------------------------+
                 |  Route Type (2 octets)                |
                 +---------------------------------------+
                 |  Length (2 octets)                    |
                 +---------------------------------------+
                 |  Route Type specific (variable)       |
                 +---------------------------------------+
</pre>
</div>
<figcaption><a href="#figure-2" class="selfRef">Figure 2</a>:
<a href="#name-the-format-of-the-sfc-nlri" class="selfRef">The Format of the SFC NLRI</a>
        </figcaption></figure>
</div>
<p id="section-3-4">The "Route Type" field determines the encoding of the rest of the Route Type specific SFC NLRI.<a href="#section-3-4" class="pilcrow">¶</a></p>
<p id="section-3-5">The "Length" field indicates the length, in octets, of the "Route Type specific" field of the SFC
       NLRI.<a href="#section-3-5" class="pilcrow">¶</a></p>
<p id="section-3-6">This document defines the following Route Types:<a href="#section-3-6" class="pilcrow">¶</a></p>
<ol start="1" type="1" class="normal type-1" id="section-3-7">
<li id="section-3-7.1">Service Function Instance Route (SFIR)<a href="#section-3-7.1" class="pilcrow">¶</a>
</li>
        <li id="section-3-7.2">Service Function Path Route (SFPR)<a href="#section-3-7.2" class="pilcrow">¶</a>
</li>
      </ol>
<p id="section-3-8">An SFIR is used to identify an SFI.  An SFPR defines a sequence of SFs (each of which has at least one instance advertised in
       an SFIR) that form an SFP.<a href="#section-3-8" class="pilcrow">¶</a></p>
<p id="section-3-9">The detailed encoding and procedures for these Route Types are described in subsequent sections.<a href="#section-3-9" class="pilcrow">¶</a></p>
<p id="section-3-10">The SFC NLRI is carried in BGP <span>[<a href="#RFC4271" class="xref">RFC4271</a>]</span> using BGP Multiprotocol Extensions
       <span>[<a href="#RFC4760" class="xref">RFC4760</a>]</span> with an Address Family Identifier (AFI) of 31 and a Subsequent Address
       Family Identifier (SAFI) of 9.  The "NLRI" field in the MP_REACH_NLRI/MP_UNREACH_NLRI attribute
       contains the SFC NLRI, encoded as specified above.<a href="#section-3-10" class="pilcrow">¶</a></p>
<p id="section-3-11">In order for two BGP speakers to exchange SFC NLRIs, they
      <span class="bcp14">MUST</span> use BGP capabilities advertisements
       to ensure that they both are capable of properly processing such NLRIs.  This is done as specified
       in <span>[<a href="#RFC4760" class="xref">RFC4760</a>]</span>, by using capability code
       1 (Multiprotocol BGP) with an AFI of 31 and
       a SAFI of 9.<a href="#section-3-11" class="pilcrow">¶</a></p>
<p id="section-3-12">The "nexthop" field of the MP_REACH_NLRI attribute of the SFC NLRI <span class="bcp14">MUST</span> be set to a loopback address of
       the advertising SFF.<a href="#section-3-12" class="pilcrow">¶</a></p>
<div id="sfiRoutes">
<section id="section-3.1">
        <h3 id="name-service-function-instance-r">
<a href="#section-3.1" class="section-number selfRef">3.1. </a><a href="#name-service-function-instance-r" class="section-name selfRef">Service Function Instance Route (SFIR)</a>
        </h3>
<p id="section-3.1-1"><a href="#sfiRouteFig" class="xref">Figure 3</a> shows the Route Type specific NLRI of the SFIR.<a href="#section-3.1-1" class="pilcrow">¶</a></p>
<span id="name-sfir-route-type-specific-nl"></span><div id="sfiRouteFig">
<figure id="figure-3">
          <div class="artwork art-text alignLeft" id="section-3.1-2.1">
<pre>
                 +--------------------------------------------+
                 |  Route Distinguisher (RD) (8 octets)       |
                 +--------------------------------------------+
                 |  Service Function Type (2 octets)          |
                 +--------------------------------------------+
</pre>
</div>
<figcaption><a href="#figure-3" class="selfRef">Figure 3</a>:
<a href="#name-sfir-route-type-specific-nl" class="selfRef">SFIR Route Type Specific NLRI</a>
          </figcaption></figure>
</div>
<p id="section-3.1-3"><span>[<a href="#RFC4364" class="xref">RFC4364</a>]</span> defines a Route
 Distinguisher (RD) as consisting of a two-byte "Type" field
          and a six-byte "Value" field, and it defines RD types 0, 1, and 2.  In this specification, the RD
          (used for the SFIR) <span class="bcp14">MUST</span> be of type 0, 1, or 2.<a href="#section-3.1-3" class="pilcrow">¶</a></p>
<p id="section-3.1-4">If two SFIRs are originated from different administrative domains (within the same
          provider's operational domain), they <span class="bcp14">MUST</span> have different RDs.  In particular, SFIRs from
          different VPNs (for different service function overlay networks) <span class="bcp14">MUST</span> have different RDs, and
          those RDs <span class="bcp14">MUST</span> be different from any non-VPN SFIRs.<a href="#section-3.1-4" class="pilcrow">¶</a></p>
<p id="section-3.1-5">The SFT identifies the functions/features an
 SF can offer, e.g.,
          classifier, firewall, load balancer.  There may be several SFIs that can perform a given
          service function.  Each node hosting an SFI <span class="bcp14">MUST</span> originate an SFIR for each type of SF that it
          hosts (as indicated by the SFT value), and it <span class="bcp14">MAY</span> advertise an SFIR for each instance of each type of SF.  A minimal
          advertisement allows construction of valid SFPs and leaves the selection of SFIs to the local SFF;
          a detailed advertisement may have scaling concerns but allows a controller that constructs an
          SFP to make an explicit choice of SFI.<a href="#section-3.1-5" class="pilcrow">¶</a></p>
<p id="section-3.1-6">Note that a node may advertise all its SFIs of one SFT in one shot
 using normal BGP UPDATE packing.
          That is, all of the SFIRs in an Update share a common Tunnel Encapsulation and Route Target (RT) attribute.
          See also <a href="#sfpatt" class="xref">Section 3.2.1</a>.<a href="#section-3.1-6" class="pilcrow">¶</a></p>
<p id="section-3.1-7">The SFIR representing a given SFI will contain an NLRI with "RD" field set to an RD as specified above,
          and with the "SFT" field set to identify that SFI's SFT.  The values for the "SFT"
          field are taken from a registry administered by IANA (see <a href="#iana" class="xref">Section 10</a>).  A BGP UPDATE
          containing one or more SFIRs <span class="bcp14">MUST</span> also include a tunnel encapsulation attribute
          <span>[<a href="#RFC9012" class="xref">RFC9012</a>]</span>.  If a data packet needs to be sent to an SFI identified
          in one of the SFIRs, it will be encapsulated as specified by the tunnel encapsulation attribute and
          then transmitted through the underlay network.<a href="#section-3.1-7" class="pilcrow">¶</a></p>
<p id="section-3.1-8">Note that the tunnel encapsulation attribute <span class="bcp14">MUST</span> contain sufficient information to allow the
          advertising SFF to identify the overlay or VPN network that a received packet is transiting.
          This is because the [SPI, SI] in a received packet is specific to a particular overlay or VPN
          network.<a href="#section-3.1-8" class="pilcrow">¶</a></p>
<div id="poolid">
<section id="section-3.1.1">
          <h4 id="name-sfir-pool-identifier-extend">
<a href="#section-3.1.1" class="section-number selfRef">3.1.1. </a><a href="#name-sfir-pool-identifier-extend" class="section-name selfRef">SFIR Pool Identifier Extended Community</a>
          </h4>
<p id="section-3.1.1-1">This document defines a new transitive Extended Community <span>[<a href="#RFC4360" class="xref">RFC4360</a>]</span> of type 0x0b called
             the "SFC Extended Community".  When used with Sub-Type 1, this is called the "SFIR Pool Identifier extended
             community".  It <span class="bcp14">MAY</span> be included in SFIR
      advertisements, and it is used to indicate the identity of a pool of
             SFIRs to which an SFIR belongs.  Since an SFIR may be a member of
      more than one pool, multiple of these extended
             communities may be present on a single SFIR advertisement.<a href="#section-3.1.1-1" class="pilcrow">¶</a></p>
<p id="section-3.1.1-2">SFIR pools allow SFIRs to be grouped for any purpose.  Possible uses include control plane scalability and
             stability.  A pool identifier may be included in an SFPR to indicate a set of SFIs that are acceptable at
             a specific point on an SFP (see Sections <a href="#sfttlv" class="xref">3.2.1.3</a> and <a href="#SFPR" class="xref">4.3</a>).<a href="#section-3.1.1-2" class="pilcrow">¶</a></p>
<p id="section-3.1.1-3">The SFIR Pool Identifier Extended Community is encoded in 8 octets as shown in <a href="#poolFig" class="xref">Figure 4</a>.<a href="#section-3.1.1-3" class="pilcrow">¶</a></p>
<span id="name-the-sfir-pool-identifier-ex"></span><div id="poolFig">
<figure id="figure-4">
            <div class="artwork art-text alignLeft" id="section-3.1.1-4.1">
<pre>
             +--------------------------------------------+
             |  Type = 0x0b (1 octet)                     |
             +--------------------------------------------+
             |  Sub-Type = 1 (1 octet)                    |
             +--------------------------------------------+
             |  SFIR Pool Identifier value (6 octets)     |
             +--------------------------------------------+
</pre>
</div>
<figcaption><a href="#figure-4" class="selfRef">Figure 4</a>:
<a href="#name-the-sfir-pool-identifier-ex" class="selfRef">The SFIR Pool Identifier Extended Community</a>
            </figcaption></figure>
</div>
<p id="section-3.1.1-5">The SFIR Pool Identifier value is encoded in a 6-octet field in network byte order, and the value is unique
             within the scope of an overlay network.  This means that pool identifiers need to be centrally managed, which
             is consistent with the assignment of SFIs to pools.<a href="#section-3.1.1-5" class="pilcrow">¶</a></p>
</section>
</div>
<div id="swapnstack">
<section id="section-3.1.2">
          <h4 id="name-mpls-mixed-swapping-stackin">
<a href="#section-3.1.2" class="section-number selfRef">3.1.2. </a><a href="#name-mpls-mixed-swapping-stackin" class="section-name selfRef">MPLS Mixed Swapping/Stacking Extended Community</a>
          </h4>
<p id="section-3.1.2-1">As noted in <a href="#poolid" class="xref">Section 3.1.1</a>, this document defines a new transitive Extended Community of type 0x0b
             called the "SFC Extended Community".  When used with Sub-Type 2, this is called the "MPLS Mixed Swapping/Stacking
             Labels Extended Community".  The community is encoded as shown in <a href="#swapFig" class="xref">Figure 5</a>.
             It contains a pair of MPLS labels: an SFC Context Label and an SF Label, as described in
             <span>[<a href="#RFC8595" class="xref">RFC8595</a>]</span>.  Each label is 20 bits encoded in a 3-octet (24-bit) field with
             4 trailing  bits that <span class="bcp14">MUST</span> be set to zero.<a href="#section-3.1.2-1" class="pilcrow">¶</a></p>
<span id="name-the-mpls-mixed-swapping-sta"></span><div id="swapFig">
<figure id="figure-5">
            <div class="artwork art-text alignLeft" id="section-3.1.2-2.1">
<pre>
             +--------------------------------------------+
             |  Type = 0x0b (1 octet)                     |
             +--------------------------------------------|
             |  Sub-Type = 2 (1 octet)                    |
             +--------------------------------------------|
             |  SFC Context Label (3 octets)              |
             +--------------------------------------------|
             |  SF Label (3 octets)                       |
             +--------------------------------------------+
</pre>
</div>
<figcaption><a href="#figure-5" class="selfRef">Figure 5</a>:
<a href="#name-the-mpls-mixed-swapping-sta" class="selfRef">The MPLS Mixed Swapping/Stacking Labels Extended Community</a>
            </figcaption></figure>
</div>
<p id="section-3.1.2-3">Note that it is assumed that each SFF has one or more globally
   unique SFC Context Labels and that the context-label
             space and the SPI-address space are disjoint. In other words, a
      label value cannot be used to indicate both an SFC context and an
      SPI,
             and it can be determined from knowledge of the label spaces
   whether a label indicates an SFC context or an SPI.<a href="#section-3.1.2-3" class="pilcrow">¶</a></p>
<p id="section-3.1.2-4">If an SFF supports SFP Traversal with an MPLS Label Stack, it
   <span class="bcp14">MUST</span> include this Extended Community with the SFIRs
             that it advertises.<a href="#section-3.1.2-4" class="pilcrow">¶</a></p>
<p id="section-3.1.2-5">See <a href="#swapOp" class="xref">Section 7.6</a> for a description of how this Extended Community is used.<a href="#section-3.1.2-5" class="pilcrow">¶</a></p>
</section>
</div>
</section>
</div>
<div id="sfpRoutes">
<section id="section-3.2">
        <h3 id="name-service-function-path-route">
<a href="#section-3.2" class="section-number selfRef">3.2. </a><a href="#name-service-function-path-route" class="section-name selfRef">Service Function Path Route (SFPR)</a>
        </h3>
<p id="section-3.2-1"><a href="#sfpRouteFig" class="xref">Figure 6</a> shows the Route Type specific NLRI of the SFPR.<a href="#section-3.2-1" class="pilcrow">¶</a></p>
<span id="name-sfpr-route-type-specific-nl"></span><div id="sfpRouteFig">
<figure id="figure-6">
          <div class="artwork art-text alignLeft" id="section-3.2-2.1">
<pre>
             +-----------------------------------------------+
             |  Route Distinguisher (RD) (8 octets)          |
             +-----------------------------------------------+
             |  Service Path Identifier (SPI) (3 octets)     |
             +-----------------------------------------------+
</pre>
</div>
<figcaption><a href="#figure-6" class="selfRef">Figure 6</a>:
<a href="#name-sfpr-route-type-specific-nl" class="selfRef">SFPR Route Type Specific NLRI</a>
          </figcaption></figure>
</div>
<p id="section-3.2-3"><span>[<a href="#RFC4364" class="xref">RFC4364</a>]</span> defines a Route Distinguisher (RD) as consisting of a two-byte "Type" field
          and a six-byte "Value" field, and it defines RD types 0, 1, and 2.  In this specification, the RD
          (used for the SFPR) <span class="bcp14">MUST</span> be of type 0, 1, or 2.<a href="#section-3.2-3" class="pilcrow">¶</a></p>
<p id="section-3.2-4">All SFPs <span class="bcp14">MUST</span> be associated with an RD.  The association of an SFP with
          an RD is determined by provisioning.  If two SFPRs are originated from different controllers, they
          <span class="bcp14">MUST</span> have different RDs.  Additionally, SFPRs from different VPNs (i.e., in different service
          function overlay networks) <span class="bcp14">MUST</span> have different RDs, and those RDs <span class="bcp14">MUST</span> be different from any
          non-VPN SFPRs.<a href="#section-3.2-4" class="pilcrow">¶</a></p>
<p id="section-3.2-5">The Service path identifier is defined in <span>[<a href="#RFC8300" class="xref">RFC8300</a>]</span> and is the value
          to be placed in the "Service Path Identifier" field of the NSH of any packet sent on this
          SFP.  It is expected that one or more controllers will originate
          these routes in order to configure a service function overlay network.<a href="#section-3.2-5" class="pilcrow">¶</a></p>
<p id="section-3.2-6">The SFP is described in a new BGP Path attribute, the SFP attribute.  <a href="#sfpatt" class="xref">Section 3.2.1</a>
          shows the format of that attribute.<a href="#section-3.2-6" class="pilcrow">¶</a></p>
<div id="sfpatt">
<section id="section-3.2.1">
          <h4 id="name-the-sfp-attribute">
<a href="#section-3.2.1" class="section-number selfRef">3.2.1. </a><a href="#name-the-sfp-attribute" class="section-name selfRef">The SFP Attribute</a>
          </h4>
<p id="section-3.2.1-1"><span>[<a href="#RFC4271" class="xref">RFC4271</a>]</span> defines BGP Path attributes.  This document introduces a new
             Optional Transitive Path attribute called the "SFP attribute", with value 37.  The first SFP attribute <span class="bcp14">MUST</span> be processed, and subsequent instances <span class="bcp14">MUST</span> be ignored.<a href="#section-3.2.1-1" class="pilcrow">¶</a></p>
<p id="section-3.2.1-2">The common fields of the SFP attribute are set as follows:<a href="#section-3.2.1-2" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-3.2.1-3.1">The Optional bit is set to 1 to indicate that this is an optional attribute.<a href="#section-3.2.1-3.1" class="pilcrow">¶</a>
</li>
            <li class="normal" id="section-3.2.1-3.2">The Transitive bit is set to 1 to indicate that this is a transitive attribute.<a href="#section-3.2.1-3.2" class="pilcrow">¶</a>
</li>
            <li class="normal" id="section-3.2.1-3.3">The Extended Length bit is set if the length of the SFP attribute is encoded in one
                  octet (set to 0) or two octets (set to 1), as described in <span>[<a href="#RFC4271" class="xref">RFC4271</a>]</span>.<a href="#section-3.2.1-3.3" class="pilcrow">¶</a>
</li>
            <li class="normal" id="section-3.2.1-3.4">The Attribute Type Code is set to 37.<a href="#section-3.2.1-3.4" class="pilcrow">¶</a>
</li>
          </ul>
<p id="section-3.2.1-4">The content of the SFP attribute is a series of Type-Length-Value (TLV) constructs.
             Some TLVs may include Sub-TLVs.  All TLVs and Sub-TLVs have a common format:<a href="#section-3.2.1-4" class="pilcrow">¶</a></p>
<span class="break"></span><dl class="dlParallel" id="section-3.2.1-5">
            <dt id="section-3.2.1-5.1">Type:</dt>
            <dd style="margin-left: 1.5em" id="section-3.2.1-5.2"> A single octet indicating the type of the SFP attribute TLV.  Values are
                  taken from the registry described in <a href="#ianasftlv" class="xref">Section 10.3</a>.<a href="#section-3.2.1-5.2" class="pilcrow">¶</a>
</dd>
            <dd class="break"></dd>
<dt id="section-3.2.1-5.3">Length:</dt>
            <dd style="margin-left: 1.5em" id="section-3.2.1-5.4"> A two-octet field indicating the length of the data following the "Length"
                  field, counted in octets.<a href="#section-3.2.1-5.4" class="pilcrow">¶</a>
</dd>
            <dd class="break"></dd>
<dt id="section-3.2.1-5.5">Value:</dt>
            <dd style="margin-left: 1.5em" id="section-3.2.1-5.6"> The contents of the TLV.<a href="#section-3.2.1-5.6" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
</dl>
<p id="section-3.2.1-6">The formats of the TLVs defined in this document are shown in the following sections.
             The presence rules and meanings are as follows.<a href="#section-3.2.1-6" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-3.2.1-7.1">The SFP attribute contains a sequence of zero or more Association TLVs.  That is, the
                  Association TLV is <span class="bcp14">OPTIONAL</span>.  Each Association TLV provides an association between this
                  SFPR and another SFPR.  Each associated SFPR is indicated using the RD with which it is
                  advertised (we say the SFPR-RD to avoid ambiguity).<a href="#section-3.2.1-7.1" class="pilcrow">¶</a>
</li>
            <li class="normal" id="section-3.2.1-7.2">The SFP attribute contains a sequence of one or more Hop TLVs.  Each Hop TLV contains
                  all of the information about a single hop in the SFP.<a href="#section-3.2.1-7.2" class="pilcrow">¶</a>
</li>
            <li class="normal" id="section-3.2.1-7.3">Each Hop TLV contains an SI value and a sequence of one or more SFT TLVs.  Each SFT
                  TLV contains an SFI reference for each instance of an SF that is allowed at this hop
                  of the SFP for the specific SFT.  Each SFI is indicated using the RD with which
                  it is advertised (we say the SFIR-RD to avoid ambiguity).<a href="#section-3.2.1-7.3" class="pilcrow">¶</a>
</li>
          </ul>
<p id="section-3.2.1-8"><span><a href="https://www.rfc-editor.org/rfc/rfc4271#section-6" class="relref">Section 6</a> of [<a href="#RFC4271" class="xref">RFC4271</a>]</span> describes the handling of malformed BGP attributes,
             or those that are in error in some way.  <span>[<a href="#RFC7606" class="xref">RFC7606</a>]</span> revises BGP error handling
             specifically for the UPDATE message, provides guidelines for the authors of documents
             defining new attributes, and revises the error-handling procedures for a number of existing
             attributes.  This document introduces the SFP attribute and so defines error handling as
             follows:<a href="#section-3.2.1-8" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-3.2.1-9.1">When parsing a message, an unknown Attribute Type Code or a length that suggests that
                  the attribute is longer than the remaining message is treated as a malformed message,
                  and the "treat-as-withdraw" approach is used as per <span>[<a href="#RFC7606" class="xref">RFC7606</a>]</span>.<a href="#section-3.2.1-9.1" class="pilcrow">¶</a>
</li>
            <li class="normal" id="section-3.2.1-9.2">
              <p id="section-3.2.1-9.2.1">When parsing a message that contains an SFP attribute, the following cases constitute
                  errors:<a href="#section-3.2.1-9.2.1" class="pilcrow">¶</a></p>
<ol start="1" type="1" class="normal type-1" id="section-3.2.1-9.2.2">
<li id="section-3.2.1-9.2.2.1">Optional bit is set to 0 in the SFP attribute.<a href="#section-3.2.1-9.2.2.1" class="pilcrow">¶</a>
</li>
                <li id="section-3.2.1-9.2.2.2">Transitive bit is set to 0 in the SFP attribute.<a href="#section-3.2.1-9.2.2.2" class="pilcrow">¶</a>
</li>
                <li id="section-3.2.1-9.2.2.3">Unknown "TLV Type" field found in the SFP attribute.<a href="#section-3.2.1-9.2.2.3" class="pilcrow">¶</a>
</li>
                <li id="section-3.2.1-9.2.2.4">TLV length that suggests the TLV extends beyond the end of the SFP attribute.<a href="#section-3.2.1-9.2.2.4" class="pilcrow">¶</a>
</li>
                <li id="section-3.2.1-9.2.2.5">Association TLV contains an unknown SFPR-RD.<a href="#section-3.2.1-9.2.2.5" class="pilcrow">¶</a>
</li>
                <li id="section-3.2.1-9.2.2.6">No Hop TLV found in the SFP attribute.<a href="#section-3.2.1-9.2.2.6" class="pilcrow">¶</a>
</li>
                <li id="section-3.2.1-9.2.2.7">No Sub-TLV found in a Hop TLV.<a href="#section-3.2.1-9.2.2.7" class="pilcrow">¶</a>
</li>
                <li id="section-3.2.1-9.2.2.8">Unknown SFIR-RD found in an SFT TLV.<a href="#section-3.2.1-9.2.2.8" class="pilcrow">¶</a>
</li>
              </ol>
</li>
            <li class="normal" id="section-3.2.1-9.3">
              <p id="section-3.2.1-9.3.1">The errors listed above are treated as follows:<a href="#section-3.2.1-9.3.1" class="pilcrow">¶</a></p>
<span class="break"></span><dl class="dlParallel" id="section-3.2.1-9.3.2">
                <dt id="section-3.2.1-9.3.2.1">1, 2, 4, 6, 7:</dt>
                <dd style="margin-left: 1.5em" id="section-3.2.1-9.3.2.2">The attribute <span class="bcp14">MUST</span> be treated as malformed and
                      the "treat-as-withdraw" approach used as per <span>[<a href="#RFC7606" class="xref">RFC7606</a>]</span>.<a href="#section-3.2.1-9.3.2.2" class="pilcrow">¶</a>
</dd>
                <dd class="break"></dd>
<dt id="section-3.2.1-9.3.2.3">3:</dt>
                <dd style="margin-left: 1.5em" id="section-3.2.1-9.3.2.4">Unknown TLVs <span class="bcp14">MUST</span> be ignored, and message processing <span class="bcp14">MUST</span>
                      continue.<a href="#section-3.2.1-9.3.2.4" class="pilcrow">¶</a>
</dd>
                <dd class="break"></dd>
<dt id="section-3.2.1-9.3.2.5">5, 8:</dt>
                <dd style="margin-left: 1.5em" id="section-3.2.1-9.3.2.6">The absence of an RD with which to correlate is nothing more than
                      a soft error.  The receiver <span class="bcp14">SHOULD</span> store the information from the SFP attribute until
                      a corresponding advertisement is received.<a href="#section-3.2.1-9.3.2.6" class="pilcrow">¶</a>
</dd>
              <dd class="break"></dd>
</dl>
</li>
          </ul>
<div id="assoctlv">
<section id="section-3.2.1.1">
            <h5 id="name-the-association-tlv">
<a href="#section-3.2.1.1" class="section-number selfRef">3.2.1.1. </a><a href="#name-the-association-tlv" class="section-name selfRef">The Association TLV</a>
            </h5>
<p id="section-3.2.1.1-1">The Association TLV is an optional TLV in the SFP attribute.  It <span class="bcp14">MAY</span> be present
                multiple times.  Each occurrence provides an association with another SFP as
                advertised in another SFPR.  The format of the Association TLV is shown in
                <a href="#assoctlvfig" class="xref">Figure 7</a>.<a href="#section-3.2.1.1-1" class="pilcrow">¶</a></p>
<span id="name-the-format-of-the-associati"></span><div id="assoctlvfig">
<figure id="figure-7">
              <div class="artwork art-text alignLeft" id="section-3.2.1.1-2.1">
<pre>
             +--------------------------------------------+
             |  Type = 1 (1 octet)                        |
             +--------------------------------------------|
             |  Length (2 octets)                         |
             +--------------------------------------------|
             |  Association Type (1 octet)                |
             +--------------------------------------------|
             |  Associated SFPR-RD (8 octets)             |
             +--------------------------------------------|
             |  Associated SPI (3 octets)                 |
             +--------------------------------------------+
</pre>
</div>
<figcaption><a href="#figure-7" class="selfRef">Figure 7</a>:
<a href="#name-the-format-of-the-associati" class="selfRef">The Format of the Association TLV</a>
              </figcaption></figure>
</div>
<p id="section-3.2.1.1-3">The fields are as follows:<a href="#section-3.2.1.1-3" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-3.2.1.1-4.1">"Type" is set to 1 to indicate an Association TLV.<a href="#section-3.2.1.1-4.1" class="pilcrow">¶</a>
</li>
              <li class="normal" id="section-3.2.1.1-4.2">"Length" indicates the length in octets of the "Association Type" and "Associated
                     SFPR-RD" fields.  The value of the "Length" field is 12.<a href="#section-3.2.1.1-4.2" class="pilcrow">¶</a>
</li>
              <li class="normal" id="section-3.2.1.1-4.3">The "Association Type" field indicates the type of association.  The values are
                     tracked in an IANA registry (see <a href="#ianaassoc" class="xref">Section 10.4</a>).  Only one value
                     is defined in this document: Type 1 indicates association of two unidirectional
                     SFPs to form a bidirectional SFP.  An SFP attribute <span class="bcp14">SHOULD NOT</span> contain more than
                     one Association TLV with Association Type 1; if more than one is present, the
                     first one <span class="bcp14">MUST</span> be processed, and subsequent instances <span class="bcp14">MUST</span> be ignored.  Note that
                     documents that define new association types must also define the presence rules
                     for Association TLVs of the new type.<a href="#section-3.2.1.1-4.3" class="pilcrow">¶</a>
</li>
              <li class="normal" id="section-3.2.1.1-4.4">The Associated SFPR-RD contains the RD of the associated SFP as advertised in an
                     SFPR.<a href="#section-3.2.1.1-4.4" class="pilcrow">¶</a>
</li>
              <li class="normal" id="section-3.2.1.1-4.5">The Associated SPI contains the SPI of the associated SFP as advertised in an
                     SFPR.<a href="#section-3.2.1.1-4.5" class="pilcrow">¶</a>
</li>
            </ul>
<p id="section-3.2.1.1-5">Association TLVs with unknown Association Type values <span class="bcp14">SHOULD</span> be ignored.  Association TLVs
                that contain an Associated SFPR-RD value equal to the RD of the SFPR in which they are
                contained <span class="bcp14">SHOULD</span> be ignored.  If the Associated SPI is not equal to the SPI advertised in
                the SFPR indicated by the Associated SFPR-RD, then the Association TLV <span class="bcp14">SHOULD</span> be ignored.
                In all three of these cases, an implementation <span class="bcp14">MAY</span> reject the SFP attribute as malformed and
                use the "treat-as-withdraw" approach per <span>[<a href="#RFC7606" class="xref">RFC7606</a>]</span>; however, implementors are
                cautioned that such an approach may make an implementation less flexible in the event of
                future extensions to this protocol.<a href="#section-3.2.1.1-5" class="pilcrow">¶</a></p>
<p id="section-3.2.1.1-6">Note that when two SFPRs reference each other using the Association TLV, one SFPR advertisement
                will be received before the other.  Therefore, processing of an association <span class="bcp14">MUST NOT</span> be
                rejected simply because the Associated SFPR-RD is unknown.<a href="#section-3.2.1.1-6" class="pilcrow">¶</a></p>
<p id="section-3.2.1.1-7">Further discussion of correlation of SFPRs is provided in <a href="#correlation" class="xref">Section 7.1</a>.<a href="#section-3.2.1.1-7" class="pilcrow">¶</a></p>
</section>
</div>
<div id="hoptlv">
<section id="section-3.2.1.2">
            <h5 id="name-the-hop-tlv">
<a href="#section-3.2.1.2" class="section-number selfRef">3.2.1.2. </a><a href="#name-the-hop-tlv" class="section-name selfRef">The Hop TLV</a>
            </h5>
<p id="section-3.2.1.2-1">There is one Hop TLV in the SFP attribute for each hop in the SFP.  The format of
                the Hop TLV is shown in <a href="#hoptlvfig" class="xref">Figure 8</a>.  At least one Hop TLV <span class="bcp14">MUST</span> be
                present in an SFP attribute.<a href="#section-3.2.1.2-1" class="pilcrow">¶</a></p>
<span id="name-the-format-of-the-hop-tlv"></span><div id="hoptlvfig">
<figure id="figure-8">
              <div class="artwork art-text alignLeft" id="section-3.2.1.2-2.1">
<pre>
             +--------------------------------------------+
             |  Type = 2 (1 octet)                        |
             +--------------------------------------------|
             |  Length (2 octets)                         |
             +--------------------------------------------|
             |  Service Index (1 octet)                   |
             +--------------------------------------------|
             |  Hop Details (variable)                    |
             +--------------------------------------------+
</pre>
</div>
<figcaption><a href="#figure-8" class="selfRef">Figure 8</a>:
<a href="#name-the-format-of-the-hop-tlv" class="selfRef">The Format of the Hop TLV</a>
              </figcaption></figure>
</div>
<p id="section-3.2.1.2-3">The fields are as follows:<a href="#section-3.2.1.2-3" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-3.2.1.2-4.1">"Type" is set to 2 to indicate a Hop TLV.<a href="#section-3.2.1.2-4.1" class="pilcrow">¶</a>
</li>
              <li class="normal" id="section-3.2.1.2-4.2">"Length" indicates the length, in octets, of the "Service Index" and "Hop
                     Details" fields.<a href="#section-3.2.1.2-4.2" class="pilcrow">¶</a>
</li>
              <li class="normal" id="section-3.2.1.2-4.3">The Service Index is defined in <span>[<a href="#RFC8300" class="xref">RFC8300</a>]</span> and is the value found in the
                     "Service Index" field of the NSH that an SFF will
      use to look up to which next
                     SFI a packet is to be sent.<a href="#section-3.2.1.2-4.3" class="pilcrow">¶</a>
</li>
              <li class="normal" id="section-3.2.1.2-4.4">The "Hop Details" field consists of a sequence of one or more Sub-TLVs.<a href="#section-3.2.1.2-4.4" class="pilcrow">¶</a>
</li>
            </ul>
<p id="section-3.2.1.2-5">Each hop of the SFP may demand that a specific type of SF is executed, and that type is
                indicated in Sub-TLVs of the Hop TLV.  At least one Sub-TLV <span class="bcp14">MUST</span> be present. This document
                defines the SFT Sub-TLV (see <a href="#sfttlv" class="xref">Section 3.2.1.3</a>) and the MPLS Swapping/Stacking Sub-TLV
                (see <a href="#swapTLV" class="xref">Section 3.2.1.4</a>); other Sub-TLVs may be defined in future. The SFT Sub-TLV
                provides a list of which types of SF are acceptable at a specific hop, and for each type it
                allows a degree of control to be imposed on the choice of SFIs of that particular type.  The MPLS 
  Swapping/Stacking Sub-TLV indicates the type of SFC encoding to use
  in an MPLS label stack.<a href="#section-3.2.1.2-5" class="pilcrow">¶</a></p>
<p id="section-3.2.1.2-6">If no Hop TLV is present in an SFP attribute, it is a malformed attribute.<a href="#section-3.2.1.2-6" class="pilcrow">¶</a></p>
</section>
</div>
<div id="sfttlv">
<section id="section-3.2.1.3">
            <h5 id="name-the-sft-sub-tlv">
<a href="#section-3.2.1.3" class="section-number selfRef">3.2.1.3. </a><a href="#name-the-sft-sub-tlv" class="section-name selfRef">The SFT Sub-TLV</a>
            </h5>
<p id="section-3.2.1.3-1">The SFT Sub-TLV <span class="bcp14">MAY</span> be included in the list of Sub-TLVs of the Hop TLV.  The format of the SFT Sub-TLV
                is shown in <a href="#sfttlvfig" class="xref">Figure 9</a>.  The Hop Sub-TLV contains a list of SFIR-RD values each taken from
                the advertisement of an SFI.  Together they form a list of acceptable SFIs of the indicated type.<a href="#section-3.2.1.3-1" class="pilcrow">¶</a></p>
<span id="name-the-format-of-the-sft-sub-t"></span><div id="sfttlvfig">
<figure id="figure-9">
              <div class="artwork art-text alignLeft" id="section-3.2.1.3-2.1">
<pre>
             +--------------------------------------------+
             |  Type = 3 (1 octet)                        |
             +--------------------------------------------|
             |  Length (2 octets)                         |
             +--------------------------------------------|
             |  Service Function Type (2 octets)          |
             +--------------------------------------------|
             |  SFIR-RD List (variable)                   |
             +--------------------------------------------+
</pre>
</div>
<figcaption><a href="#figure-9" class="selfRef">Figure 9</a>:
<a href="#name-the-format-of-the-sft-sub-t" class="selfRef">The Format of the SFT Sub-TLV</a>
              </figcaption></figure>
</div>
<p id="section-3.2.1.3-3">The fields are as follows:<a href="#section-3.2.1.3-3" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-3.2.1.3-4.1">"Type" is set to 3 to indicate an SFT Sub-TLV.<a href="#section-3.2.1.3-4.1" class="pilcrow">¶</a>
</li>
              <li class="normal" id="section-3.2.1.3-4.2">"Length" indicates the length, in octets, of the "Service
       Function Type" and "SFIR-RD List" fields.<a href="#section-3.2.1.3-4.2" class="pilcrow">¶</a>
</li>
              <li class="normal" id="section-3.2.1.3-4.3">The SFT value indicates the category (type) of SF that is to be
                     executed at this hop.  The types are as advertised for the SFs supported by the SFFs.
                     SFT values in the range 1-31 are special-purpose SFT values and have meanings defined by
                     the documents that describe them -- the value "Change Sequence" is defined in
                     <a href="#changeseq" class="xref">Section 6.1</a> of this document.<a href="#section-3.2.1.3-4.3" class="pilcrow">¶</a>
</li>
              <li class="normal" id="section-3.2.1.3-4.4">The hop description is further qualified beyond the specification of the SFTs by listing, for
                     each SFT in each hop, the SFIs that may be used at the hop.  The SFIs are identified using
                     the SFIR-RDs from the advertisements of the SFIs in the SFIRs.  Note that if the list contains
                     one or more SFIR Pool Identifiers, then for each, the SFIR-RD list is effectively expanded to
                     include the SFIR-RD of each SFIR advertised with that SFIR Pool Identifier.  An SFIR-RD of value
                     zero has special meaning, as described in <a href="#selection" class="xref">Section 5</a>.  Each entry in the list
                     is eight octets long, and the number of entries in the list can be deduced from the value of the
                     "Length" field.<a href="#section-3.2.1.3-4.4" class="pilcrow">¶</a>
</li>
              <li class="normal" id="section-3.2.1.3-4.5">Note that an SFIR-RD is of type 0, 1, or 2 (as described in
       <a href="#sfiRoutes" class="xref">Section 3.1</a>).  Thus, the
                     high-order octet of an RD found in an SFIR-RD List always
      has a value of 0x00.  However, the high-order octet of an
      SFIR Pool Identifier (an Extended Community with "Type"
      field 0x0b) will always
                     have a nonzero value.  This allows the node processing the SFIR-RD list to distinguish between
                     the two types of list entry.<a href="#section-3.2.1.3-4.5" class="pilcrow">¶</a>
</li>
            </ul>
</section>
</div>
<div id="swapTLV">
<section id="section-3.2.1.4">
            <h5 id="name-mpls-swapping-stacking-sub-">
<a href="#section-3.2.1.4" class="section-number selfRef">3.2.1.4. </a><a href="#name-mpls-swapping-stacking-sub-" class="section-name selfRef">MPLS Swapping/Stacking Sub-TLV</a>
            </h5>
<p id="section-3.2.1.4-1">The MPLS Swapping/Stacking Sub-TLV (Type value 4) is a zero-length Sub-TLV that is <span class="bcp14">OPTIONAL</span> in the Hop TLV
                and is used when the data representation is MPLS (see <a href="#representation" class="xref">Section 7.5</a>).  When present, it indicates to
                the classifier imposing an MPLS label stack that the current hop is to use an {SFC Context Label, SF label} rather
                than an {SPI, SF} label pair.  See <a href="#swapOp" class="xref">Section 7.6</a> for more details.<a href="#section-3.2.1.4-1" class="pilcrow">¶</a></p>
</section>
</div>
<div id="sfpTraverse">
<section id="section-3.2.1.5">
            <h5 id="name-sfp-traversal-with-mpls-lab">
<a href="#section-3.2.1.5" class="section-number selfRef">3.2.1.5. </a><a href="#name-sfp-traversal-with-mpls-lab" class="section-name selfRef">SFP Traversal With MPLS Label Stack TLV</a>
            </h5>
<p id="section-3.2.1.5-1">The SFP Traversal With MPLS Label Stack TLV (Type value 5) is a zero-length TLV that can be carried in the
                SFP attribute and indicates to the classifier and the SFFs on the SFP that an MPLS label stack with label
                swapping/stacking is to be used for packets traversing the SFP.  All of the SFFs specified at each of the SFP's
                hops <span class="bcp14">MUST</span> have advertised an  MPLS Mixed Swapping/Stacking Extended Community (see <a href="#swapnstack" class="xref">Section 3.1.2</a>)
                for the SFP to be considered usable.<a href="#section-3.2.1.5-1" class="pilcrow">¶</a></p>
</section>
</div>
</section>
</div>
<div id="sfparules">
<section id="section-3.2.2">
          <h4 id="name-general-rules-for-the-sfp-a">
<a href="#section-3.2.2" class="section-number selfRef">3.2.2. </a><a href="#name-general-rules-for-the-sfp-a" class="section-name selfRef">General Rules for the SFP Attribute</a>
          </h4>
<p id="section-3.2.2-1">It is possible for the same SFI, as described by an SFIR, to be used in multiple SFPRs.<a href="#section-3.2.2-1" class="pilcrow">¶</a></p>
<p id="section-3.2.2-2">When two SFPRs have the same SPI but different SFPR-RDs, there can be three cases:<a href="#section-3.2.2-2" class="pilcrow">¶</a></p>
<ol start="1" type="1" class="normal type-1" id="section-3.2.2-3">
            <li id="section-3.2.2-3.1">Two or more controllers are originating SFPRs for the same SFP.  In this case, the
                   content of the SFPRs is identical, and the duplication is to ensure receipt and
                   provide controller redundancy.<a href="#section-3.2.2-3.1" class="pilcrow">¶</a>
</li>
            <li id="section-3.2.2-3.2">There is a transition in content of the advertised SFP, and the advertisements may
                   originate from one or more controllers.  In this case, the content of the SFPRs will be
                   different.<a href="#section-3.2.2-3.2" class="pilcrow">¶</a>
</li>
            <li id="section-3.2.2-3.3">The reuse of an SPI may result from a configuration error.<a href="#section-3.2.2-3.3" class="pilcrow">¶</a>
</li>
          </ol>
<p id="section-3.2.2-4">There is no way in any of these cases for the receiving SFF to know which SFPR to process, and the
              SFPRs could be received in any order.  At any point in time, when multiple SFPRs have the
              same SPI but different SFPR-RDs, the SFF <span class="bcp14">MUST</span> use the SFPR with the numerically lowest
              SFPR-RD when interpreting the RDs as 8-octet integers in network byte order.  The SFF
              <span class="bcp14">SHOULD</span> log this occurrence to assist with debugging.<a href="#section-3.2.2-4" class="pilcrow">¶</a></p>
<p id="section-3.2.2-5">Furthermore, a controller that wants to change the content of an SFP is <span class="bcp14">RECOMMENDED</span> to use a
              new SPI and so create a new SFP onto which the classifiers can transition packet flows before
              the SFPR for the old SFP is withdrawn.  This avoids any race conditions with SFPR advertisements.<a href="#section-3.2.2-5" class="pilcrow">¶</a></p>
<p id="section-3.2.2-6">Additionally, a controller <span class="bcp14">SHOULD NOT</span> reuse an SPI after it has withdrawn the SFPR that used it
              until at least a configurable amount of time has passed.  This timer <span class="bcp14">SHOULD</span> have a default of one
              hour.<a href="#section-3.2.2-6" class="pilcrow">¶</a></p>
</section>
</div>
</section>
</div>
</section>
</div>
<div id="mode">
<section id="section-4">
      <h2 id="name-mode-of-operation">
<a href="#section-4" class="section-number selfRef">4. </a><a href="#name-mode-of-operation" class="section-name selfRef">Mode of Operation</a>
      </h2>
<p id="section-4-1">This document describes the use of BGP as a control plane to create and manage a service
       function overlay network.<a href="#section-4-1" class="pilcrow">¶</a></p>
<div id="rt">
<section id="section-4.1">
        <h3 id="name-route-targets">
<a href="#section-4.1" class="section-number selfRef">4.1. </a><a href="#name-route-targets" class="section-name selfRef">Route Targets</a>
        </h3>
<p id="section-4.1-1">The main feature introduced by this document is the ability to create multiple service
          function overlay networks through the use of Route Targets (RTs) <span>[<a href="#RFC4364" class="xref">RFC4364</a>]</span>.<a href="#section-4.1-1" class="pilcrow">¶</a></p>
<p id="section-4.1-2">Every BGP UPDATE containing an SFIR or SFPR carries one or more RTs.  The RT carried by a particular
          SFIR or SFPR is determined by the provisioning of the route's originator.<a href="#section-4.1-2" class="pilcrow">¶</a></p>
<p id="section-4.1-3">Every node in a service function overlay network is configured with one or more import RTs.
          Thus, each SFF will import only the SFPRs with matching RTs, allowing the construction of
          multiple service function overlay networks or the instantiation of SFCs
          within a Layer 3 Virtual Private Network (L3VPN) or Ethernet VPN (EVPN) instance
          (see <a href="#private" class="xref">Section 7.3</a>).  An SFF that has a presence in multiple service function
          overlay networks (i.e., one that imports more than one RT) will
   usually maintain separate forwarding
          state for each overlay network.<a href="#section-4.1-3" class="pilcrow">¶</a></p>
</section>
</div>
<div id="SFIR">
<section id="section-4.2">
        <h3 id="name-service-function-instance-ro">
<a href="#section-4.2" class="section-number selfRef">4.2. </a><a href="#name-service-function-instance-ro" class="section-name selfRef">Service Function Instance Routes</a>
        </h3>
<p id="section-4.2-1">The SFIR (see <a href="#sfiRoutes" class="xref">Section 3.1</a>) is used to advertise the existence and location
          of a specific SFI; it consists of:<a href="#section-4.2-1" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-4.2-2.1">The RT as just described.<a href="#section-4.2-2.1" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-4.2-2.2">A Service Function Type (SFT) that is the type of service function that is
                provided (such as "firewall").<a href="#section-4.2-2.2" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-4.2-2.3">A Route Distinguisher (RD) that is unique to a specific overlay.<a href="#section-4.2-2.3" class="pilcrow">¶</a>
</li>
        </ul>
</section>
</div>
<div id="SFPR">
<section id="section-4.3">
        <h3 id="name-service-function-path-routes">
<a href="#section-4.3" class="section-number selfRef">4.3. </a><a href="#name-service-function-path-routes" class="section-name selfRef">Service Function Path Routes</a>
        </h3>
<p id="section-4.3-1">The SFPR (see <a href="#sfpRoutes" class="xref">Section 3.2</a>)
 describes a specific path of an SFC.
          The SFPR contains the Service Path Identifier (SPI) used to identify the SFP in the NSH
          in the data plane.  It also contains a sequence of Service Indexes (SIs).  Each SI
          identifies a hop in the SFP, and each hop is a choice between one or more SFIs.<a href="#section-4.3-1" class="pilcrow">¶</a></p>
<p id="section-4.3-2">As described in this document, each SFP route is identified in the
          service function overlay network by an RD and an SPI.  The SPI is unique within a single
          VPN instance supported by the underlay network.<a href="#section-4.3-2" class="pilcrow">¶</a></p>
<p id="section-4.3-3">The SFPR advertisement comprises:<a href="#section-4.3-3" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-4.3-4.1">An RT as described in <a href="#rt" class="xref">Section 4.1</a>.<a href="#section-4.3-4.1" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-4.3-4.2">
            <p id="section-4.3-4.2.1">A tuple that identifies the SFPR.<a href="#section-4.3-4.2.1" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-4.3-4.2.2.1">An RD that identifies an advertisement of an SFPR.<a href="#section-4.3-4.2.2.1" class="pilcrow">¶</a>
</li>
              <li class="normal" id="section-4.3-4.2.2.2">The SPI that uniquely identifies this path within the VPN instance distinguished
                     by the RD.  This SPI also appears in the NSH.<a href="#section-4.3-4.2.2.2" class="pilcrow">¶</a>
</li>
            </ul>
</li>
          <li class="normal" id="section-4.3-4.3">A series of SIs.  Each SI is used in the context of a particular SPI and
               identifies one or more SFs (distinguished by their SFTs). For
        each SF, it identifies a set of
               SFIs that instantiate the SF.  The values of the SI indicate the order in which the
               SFs are to be executed in the SFP that is represented by the SPI.<a href="#section-4.3-4.3" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-4.3-4.4">The SI is used in the NSH to identify the entries in the SFP.  Note that the SI values
               have meaning only relative to a specific path.  They have no semantic other than to indicate
               the order of SFs within the path and are assumed to be monotonically
               decreasing from the start to the end of the path <span>[<a href="#RFC8300" class="xref">RFC8300</a>]</span>.<a href="#section-4.3-4.4" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-4.3-4.5">
            <p id="section-4.3-4.5.1">Each SI is associated with a set of one or more SFIs
               that can be used to provide the indexed SF within the path.  Each member of
               the set comprises:<a href="#section-4.3-4.5.1" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-4.3-4.5.2.1">The RD used in an SFIR advertisement of the SFI.<a href="#section-4.3-4.5.2.1" class="pilcrow">¶</a>
</li>
              <li class="normal" id="section-4.3-4.5.2.2">The SFT that indicates the type of function as used in the same SFIR advertisement
                     of the SFI.<a href="#section-4.3-4.5.2.2" class="pilcrow">¶</a>
</li>
            </ul>
</li>
        </ul>
<p id="section-4.3-5">This may be summarized as follows, where the notations "SFPR-RD" and "SFIR-RD" are used
          to distinguish the two different RDs, and where "*" indicates a multiplier:<a href="#section-4.3-5" class="pilcrow">¶</a></p>
<div class="artwork art-text alignLeft" id="section-4.3-6">
<pre>
   RT, {SFPR-RD, SPI}, m * {SI, {n * {SFT, p * SFIR-RD} } }
</pre><a href="#section-4.3-6" class="pilcrow">¶</a>
</div>
<p id="section-4.3-7">Where:<a href="#section-4.3-7" class="pilcrow">¶</a></p>
<span class="break"></span><dl class="dlParallel" id="section-4.3-8">
          <dt id="section-4.3-8.1">RT:</dt>
          <dd style="margin-left: 1.5em" id="section-4.3-8.2"> Route Target<a href="#section-4.3-8.2" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-4.3-8.3">SFPR-RD:</dt>
          <dd style="margin-left: 1.5em" id="section-4.3-8.4">The Route Descriptor of the SFPR advertisement<a href="#section-4.3-8.4" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-4.3-8.5">SPI:</dt>
          <dd style="margin-left: 1.5em" id="section-4.3-8.6">Service Path Identifier used in the NSH<a href="#section-4.3-8.6" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-4.3-8.7">m:</dt>
          <dd style="margin-left: 1.5em" id="section-4.3-8.8">The number of hops in the SFP<a href="#section-4.3-8.8" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-4.3-8.9">n:</dt>
          <dd style="margin-left: 1.5em" id="section-4.3-8.10">The number of choices of SFT for a specific hop<a href="#section-4.3-8.10" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-4.3-8.11">p:</dt>
          <dd style="margin-left: 1.5em" id="section-4.3-8.12">The number of choices of SFI
   for a given SFT in a specific hop<a href="#section-4.3-8.12" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-4.3-8.13">SI:</dt>
          <dd style="margin-left: 1.5em" id="section-4.3-8.14">Service Index used in the NSH to indicate a specific hop<a href="#section-4.3-8.14" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-4.3-8.15">SFT:</dt>
          <dd style="margin-left: 1.5em" id="section-4.3-8.16">The Service Function Type used in the same advertisement of the SFIR<a href="#section-4.3-8.16" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-4.3-8.17">SFIR-RD:</dt>
          <dd style="margin-left: 1.5em" id="section-4.3-8.18">The Route Descriptor used in an advertisement of the SFIR<a href="#section-4.3-8.18" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
</dl>
<p id="section-4.3-9">That is, there can be multiple SFTs at a given hop, as described in <a href="#selection" class="xref">Section 5</a>.<a href="#section-4.3-9" class="pilcrow">¶</a></p>
<p id="section-4.3-10">Note that the values of SI are from the set {255, ..., 1} and are monotonically decreasing
          within the SFP.  SIs <span class="bcp14">MUST</span> appear in order within the SFPR (i.e., monotonically decreasing)
          and <span class="bcp14">MUST NOT</span> appear more than once.  Gaps <span class="bcp14">MAY</span> appear in the sequence, as described in
          <a href="#lacunae" class="xref">Section 4.5.1</a>.  Malformed SFPRs <span class="bcp14">MUST</span> be discarded and <span class="bcp14">MUST</span> cause any
          previous instance of the SFPR (same SFPR-RD and SPI) to be discarded.<a href="#section-4.3-10" class="pilcrow">¶</a></p>
<p id="section-4.3-11">Note that if the SFIR-RD list in an SFT TLV contains one or more SFIR Pool Identifiers, then
          in the above expression, "p" is the sum of the number of individual SFIR-RD values
          and the sum for each SFIR Pool Identifier of the number of SFIRs advertised with that SFIR Pool
          Identifier.  In other words, the list of SFIR-RD values is effectively expanded to include the SFIR-RD
          of each SFIR advertised with each SFIR Pool Identifier in the SFIR-RD list.<a href="#section-4.3-11" class="pilcrow">¶</a></p>
<p id="section-4.3-12">The choice of SFI is explained further in <a href="#selection" class="xref">Section 5</a>.  Note that an SFIR-RD
          value of zero has special meaning, as described in that section.<a href="#section-4.3-12" class="pilcrow">¶</a></p>
</section>
</div>
<div id="classy">
<section id="section-4.4">
        <h3 id="name-classifier-operation">
<a href="#section-4.4" class="section-number selfRef">4.4. </a><a href="#name-classifier-operation" class="section-name selfRef">Classifier Operation</a>
        </h3>
<p id="section-4.4-1">As shown in <a href="#SFCarch" class="xref">Figure 1</a>, the classifier is a component that is used to assign
           packets to an SFP.<a href="#section-4.4-1" class="pilcrow">¶</a></p>
<p id="section-4.4-2">The classifier is responsible for determining to which packet flow a packet belongs.  The
           mechanism it uses to achieve that classification is out of the scope of this document but might
           include inspection of the packet header.  The classifier has been instructed (by the controller
           or through some other configuration mechanism -- see <a href="#fspecclassy" class="xref">Section 7.4</a>) which flows
           are to be assigned to which SFPs, and so it can impose an NSH on each packet and initialize the
           NSH with the SPI of the selected SFP and the SI of its first hop.<a href="#section-4.4-2" class="pilcrow">¶</a></p>
<p id="section-4.4-3">Note that instructions delivered to the classifier may include information about the metadata
           to encode (and the format for that encoding) on packets that are classified by the classifier
           to a particular SFP.  As mentioned in <a href="#ctrlover" class="xref">Section 2.2</a>, this corresponds to the
           fifth element of control plane functionality described in <span>[<a href="#RFC7665" class="xref">RFC7665</a>]</span>.  Such
           instructions fall outside the scope of this specification (but
    see <a href="#fspecclassy" class="xref">Section 7.4</a>),
           as do instructions to other service function chaining elements on how to interpret metadata (as described in the
           sixth element of control plane functionality described in <span>[<a href="#RFC7665" class="xref">RFC7665</a>]</span>).<a href="#section-4.4-3" class="pilcrow">¶</a></p>
</section>
</div>
<div id="SFF">
<section id="section-4.5">
        <h3 id="name-service-function-forwarder-">
<a href="#section-4.5" class="section-number selfRef">4.5. </a><a href="#name-service-function-forwarder-" class="section-name selfRef">Service Function Forwarder Operation</a>
        </h3>
<p id="section-4.5-1">Each packet sent to an SFF is transmitted encapsulated in an NSH.  The NSH includes an SPI
          and SI: the SPI indicates the SFPR advertisement that announced the SFP;
          the tuple SPI/SI indicates a specific hop in a specific path and maps to the RD/SFT of a
          particular SFIR advertisement.<a href="#section-4.5-1" class="pilcrow">¶</a></p>
<p id="section-4.5-2">When an SFF gets an SFPR advertisement, it will first determine whether to import the route
          by examining the RT.  If the SFPR is imported, the SFF then determines whether it is on the
          SFP by looking for its own SFIR-RDs or any SFIR-RD with value zero in the SFPR.  For each
          occurrence in the SFP, the SFF creates forwarding state for incoming packets and forwarding
          state for outgoing packets that have been processed by the specified SFI.<a href="#section-4.5-2" class="pilcrow">¶</a></p>
<p id="section-4.5-3">The SFF creates local forwarding state for packets that it receives from other SFFs.  This
          state makes the association between the SPI/SI in the NSH of the received packet and one or
          more specific local SFIs, as identified by the SFIR-RD/SFT.  If there are multiple local SFIs
          that match, this is because a single advertisement was made for a set of equivalent SFIs, and
          the SFF may use local policy (such as load balancing) to determine to which SFI to forward a
          received packet.<a href="#section-4.5-3" class="pilcrow">¶</a></p>
<p id="section-4.5-4">The SFF also creates next-hop forwarding state for packets received back from the local SFI
          that need to be forwarded to the next hop in the SFP.  There may be a choice of next hops,
          as described in <a href="#SFPR" class="xref">Section 4.3</a>.  The SFF could install forwarding state for all
          potential next hops or it could choose to only install forwarding state for a subset of the
          potential next hops.  If a choice is made, then it will be as described in
          <a href="#selection" class="xref">Section 5</a>.<a href="#section-4.5-4" class="pilcrow">¶</a></p>
<p id="section-4.5-5">The installed forwarding state may change over time, reacting to changes in the underlay network
          and the availability of particular SFIs.  Note that the forwarding state describes how one SFF
          sends packets to another SFF, but not how those packets are routed through the underlay network.
          SFFs may be connected by tunnels across the underlay, or packets may be sent addressed to the
          next SFF and routed through the underlay.  In any case, transmission across the underlay requires
          encapsulation of packets with a header for transport in the underlay network.<a href="#section-4.5-5" class="pilcrow">¶</a></p>
<p id="section-4.5-6">Note that SFFs only create and store forwarding state for the SFPs on which they are included.
          They do not retain state for all SFPs advertised.<a href="#section-4.5-6" class="pilcrow">¶</a></p>
<p id="section-4.5-7">An SFF may also install forwarding state to support looping, jumping, and branching.
          The protocol mechanism for explicit control of looping, jumping, and
          branching uses a specific reserved SFT value at a given hop of an SFPR and is described in
          <a href="#changeseq" class="xref">Section 6.1</a>.<a href="#section-4.5-7" class="pilcrow">¶</a></p>
<div id="lacunae">
<section id="section-4.5.1">
          <h4 id="name-processing-with-gaps-in-the">
<a href="#section-4.5.1" class="section-number selfRef">4.5.1. </a><a href="#name-processing-with-gaps-in-the" class="section-name selfRef">Processing with "Gaps" in the SI Sequence</a>
          </h4>
<p id="section-4.5.1-1">The behavior of an SF, as described in <span>[<a href="#RFC8300" class="xref">RFC8300</a>]</span>, is to decrement
             the value of the "SI" field in the NSH by one before returning a packet to the local SFF for
             further processing.  This means that there is a good reason to assume that the SFP is
             composed of a series of SFs, each indicated by an SI value one less than the previous.<a href="#section-4.5.1-1" class="pilcrow">¶</a></p>
<p id="section-4.5.1-2">However,  there is an advantage to having nonsuccessive SIs in an SPI.  Consider the case
             where an SPI needs to be modified by the insertion or removal of an SF.  In the latter case,
             this would lead to a "gap" in the sequence of SIs, and in the former case, this could only
             be achieved if a gap already existed into which the new SF with its new SI value could be
             inserted.  Otherwise, all "downstream" SFs would need to be renumbered.<a href="#section-4.5.1-2" class="pilcrow">¶</a></p>
<p id="section-4.5.1-3">Now, of course, such renumbering could be performed, but it would lead to a significant
             disruption to the SFC as all the SFFs along the SFP were "reprogrammed".  Thus, to achieve
             dynamic modification of an SFP (and even in-service modification), it is desirable to be
             able to make these modifications without changing the SIs of the elements that were
             present before the modification.  This will produce much more consistent/predictable
             behavior during the convergence period, where otherwise the change would need to be
             fully propagated.<a href="#section-4.5.1-3" class="pilcrow">¶</a></p>
<p id="section-4.5.1-4">Another approach says that any change to an SFP simply creates a new SFP that can be
             assigned a new SPI.  All that would be needed would be to give a new instruction to the
             classifier, and traffic would be switched to the new SFP that contains the new set of SFs.
             This approach is practical but neglects to consider that the SFP may be referenced by
             other SFPs (through "branch" instructions) and used by many classifiers.  In those cases,
             the corresponding configuration resulting from a change in SPI may have wide ripples and
             create scope for errors that are hard to trace.<a href="#section-4.5.1-4" class="pilcrow">¶</a></p>
<p id="section-4.5.1-5">Therefore, while this document requires that the SI values in an SFP are monotonically decreasing,
             it makes no assumption that the SI values are sequential.  Configuration tools may apply
             that rule, but they are not required to.  To support this, an SFF <span class="bcp14">SHOULD</span> process as follows
             when it receives a packet:<a href="#section-4.5.1-5" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-4.5.1-6.1">If the SI indicates a known entry in the SFP, the SFF <span class="bcp14">MUST</span> process the packet as
                   normal, looking up the SI and determining to which local SFI to deliver the packet.<a href="#section-4.5.1-6.1" class="pilcrow">¶</a>
</li>
            <li class="normal" id="section-4.5.1-6.2">If the SI does not match an entry in the SFP, the SFF <span class="bcp14">MUST</span> reduce the SI value to the
                   next (smaller) value present in the SFP and process the packet using that SI.<a href="#section-4.5.1-6.2" class="pilcrow">¶</a>
</li>
            <li class="normal" id="section-4.5.1-6.3">If there is no smaller SI (i.e., if the end of the SFP has been reached), the SFF <span class="bcp14">MUST</span>
                   treat the SI value as not valid, as described in <span>[<a href="#RFC8300" class="xref">RFC8300</a>]</span>.<a href="#section-4.5.1-6.3" class="pilcrow">¶</a>
</li>
          </ul>
<p id="section-4.5.1-7">
             This makes the behavior described in this document a superset of the function in
             <span>[<a href="#RFC8300" class="xref">RFC8300</a>]</span>.  That is, an implementation that strictly follows RFC 8300 in
             performing SI decrements in units of one is perfectly in line with the mechanisms
             defined in this document.<a href="#section-4.5.1-7" class="pilcrow">¶</a></p>
<p id="section-4.5.1-8">SFF implementations <span class="bcp14">MAY</span> choose to only support contiguous SI values in an SFP.  Such an
             implementation will not support receiving an SI value that is not present in the SFP and
             will discard the packets as described in <span>[<a href="#RFC8300" class="xref">RFC8300</a>]</span>.<a href="#section-4.5.1-8" class="pilcrow">¶</a></p>
</section>
</div>
</section>
</div>
</section>
</div>
<div id="selection">
<section id="section-5">
      <h2 id="name-selection-within-service-fu">
<a href="#section-5" class="section-number selfRef">5. </a><a href="#name-selection-within-service-fu" class="section-name selfRef">Selection within Service Function Paths</a>
      </h2>
<p id="section-5-1">As described in <a href="#overview" class="xref">Section 2</a>, the SPI/SI in the NSH passed back from an SFI to
       the SFF may leave the SFF with a choice of next-hop SFTs and a choice of SFIs for each SFT.
       That is, the SPI indicates an SFPR, and the SI indicates an entry in that SFPR.  Each entry in
       an SFPR is a set of one or more SFT/SFIR-RD pairs.  The SFF <span class="bcp14">MUST</span> choose one of these, identify
       the SFF that supports the chosen SFI, and send the packet to that next-hop SFF.<a href="#section-5-1" class="pilcrow">¶</a></p>
<p id="section-5-2">The choice be may offered for load balancing across multiple SFIs, or for discrimination between
       different actions necessary at a specific hop in the SFP.  Different SFT values may exist at
       a given hop in an SFP to support several cases:<a href="#section-5-2" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-5-3.1">There may be multiple instances of similar service functions that are distinguished by
            different SFT values.  For example, firewalls made by vendor A and vendor B may need to
            be identified by different SFT values because, while they have similar functionality, their
            behavior is not identical.  Then, some SFPs may limit the choice of SF at a given hop by
            specifying the SFT for vendor A, but other SFPs might not need to control which vendor's
            SF is used and so can indicate that either SFT can be used.<a href="#section-5-3.1" class="pilcrow">¶</a>
</li>
        <li class="normal" id="section-5-3.2">There may be an obvious branch needed in an SFP, such as the processing after a firewall
            where admitted packets continue along the SFP, but suspect packets are diverted to a
            "penalty box".  In this case, the next hop in the SFP will be indicated with two
            different SFT values.<a href="#section-5-3.2" class="pilcrow">¶</a>
</li>
      </ul>
<p id="section-5-4">In the typical case, the SFF chooses a next-hop SFF by looking at the set of all SFFs that
       support the SFs identified by the SI (that set having been advertised in individual SFIR
       advertisements), finding the one or more that are "nearest" in the underlay network, and
       choosing between next-hop SFFs using its own load-balancing algorithm.<a href="#section-5-4" class="pilcrow">¶</a></p>
<p id="section-5-5">An SFI may influence this choice process by passing additional information back, along
       with the packet and NSH.  This information may influence local policy
       at the SFF to either cause it to favor a next-hop SFF (perhaps selecting one
       that is not nearest in the underlay) or influence the load-balancing algorithm.<a href="#section-5-5" class="pilcrow">¶</a></p>
<p id="section-5-6">This selection applies to the normal case but also applies in the case of looping,
       jumping, and branching (see <a href="#looping" class="xref">Section 6</a>).<a href="#section-5-6" class="pilcrow">¶</a></p>
<p id="section-5-7">Suppose an SFF in a particular service function overlay network (identified by a particular import
       RT, RT-z) needs to forward an NSH-encapsulated packet whose SPI is SPI-x and whose SI is SI-y.
       It does the following:<a href="#section-5-7" class="pilcrow">¶</a></p>
<ol start="1" type="1" class="normal type-1" id="section-5-8">
<li id="section-5-8.1">It looks for an installed SFPR that carries RT-z and has SPI-x in its NLRI.
             If there is none, then such packets cannot be forwarded.<a href="#section-5-8.1" class="pilcrow">¶</a>
</li>
        <li id="section-5-8.2">From the SFP attribute of that SFPR, it finds the Hop TLV with SI value set to SI-y.
             If there is no such Hop TLV, then such packets cannot be forwarded.<a href="#section-5-8.2" class="pilcrow">¶</a>
</li>
        <li id="section-5-8.3">
          <p id="section-5-8.3.1">It then finds the "relevant" set of SFIRs by going through the list of SFT TLVs
             contained in the Hop TLV as follows:<a href="#section-5-8.3.1" class="pilcrow">¶</a></p>
<ol start="1" type="A" class="normal type-A" id="section-5-8.3.2">
<li id="section-5-8.3.2.1">An SFIR is relevant if it carries RT-z, the SFT in its NLRI matches
                   the SFT value in one of the SFT TLVs, and the RD value in its NLRI matches
                   an entry in the list of SFIR-RDs in that SFT TLV.<a href="#section-5-8.3.2.1" class="pilcrow">¶</a>
</li>
            <li id="section-5-8.3.2.2">If an entry in the SFIR-RD list of an SFT TLV contains the value zero, then
                   an SFIR is relevant if it carries RT-z and the SFT in its NLRI matches
                   the SFT value in that SFT TLV.  That is, any SFIR in the service function
                   overlay network defined by RT-z and with the correct SFT is relevant.<a href="#section-5-8.3.2.2" class="pilcrow">¶</a>
</li>
            <li id="section-5-8.3.2.3">If a pool identifier is in use, then an SFIR is relevant if it is a member of
                   the pool.<a href="#section-5-8.3.2.3" class="pilcrow">¶</a>
</li>
          </ol>
</li>
      </ol>
<p id="section-5-9">Each of the relevant SFIRs identifies a single SFI and contains a tunnel encapsulation
       attribute that specifies how to send a packet to that SFI.  For a particular packet, the
       SFF chooses a particular SFI from the set of relevant SFIRs.  This choice is made according
       to local policy.<a href="#section-5-9" class="pilcrow">¶</a></p>
<p id="section-5-10">A typical policy might be to figure out the set of SFIs that are closest and load balance
       among them.  But this is not the only possible policy.<a href="#section-5-10" class="pilcrow">¶</a></p>
<p id="section-5-11">Thus, at any point in time when an SFF selects its next hop, it chooses from the intersection
       of the set of next-hop RDs contained in the SFPR and the RDs contained in the SFF's local set of
       SFIRs (i.e., according to the determination of "relevance", above).  If the intersection is
       null, the SFPR is unusable.  Similarly, when this condition applies on the controller that originated
       the SFPR, it <span class="bcp14">SHOULD</span> either withdraw the SFPR or re-advertise it with a new set of RDs for the affected
       hop.<a href="#section-5-11" class="pilcrow">¶</a></p>
</section>
</div>
<div id="looping">
<section id="section-6">
      <h2 id="name-looping-jumping-and-branchi">
<a href="#section-6" class="section-number selfRef">6. </a><a href="#name-looping-jumping-and-branchi" class="section-name selfRef">Looping, Jumping, and Branching</a>
      </h2>
<p id="section-6-1">As described in <a href="#overview" class="xref">Section 2</a>, an SFI or an SFF may cause a packet to
       "loop back" to a previous SF on a path in order that a sequence of functions may be
       re-executed.  This is simply achieved by replacing the SI in the NSH with a higher value,
       instead of decreasing it as would normally be the case, to determine the next hop in the
       path.<a href="#section-6-1" class="pilcrow">¶</a></p>
<p id="section-6-2"><a href="#overview" class="xref">Section 2</a> also describes how an SFI or SFF may cause a packet to
       "jump forward" to an SF on a path that is not the immediate next SF in the SFP.  This
       is simply achieved by replacing the SI in the NSH with a lower value than would be
       achieved by decreasing it by the normal amount.<a href="#section-6-2" class="pilcrow">¶</a></p>
<p id="section-6-3">A more complex option to move packets from one SFP to another is described in
       <span>[<a href="#RFC8300" class="xref">RFC8300</a>]</span> and <a href="#overview" class="xref">Section 2</a>, where it is termed
       "branching".  This mechanism allows an SFI or SFF to make a choice of downstream
       treatments for packets based on local policy and the output of the local SF.  Branching is
       achieved by changing the SPI in the NSH to indicate the new path and setting the SI to
       indicate the point in the path at which the packets enter.<a href="#section-6-3" class="pilcrow">¶</a></p>
<p id="section-6-4">Note that the NSH does not include a marker to indicate whether a specific packet has
       been around a loop before.  Therefore, the use of NSH metadata <span>[<a href="#RFC8300" class="xref">RFC8300</a>]</span>
       may be required in order to prevent infinite loops.<a href="#section-6-4" class="pilcrow">¶</a></p>
<div id="changeseq">
<section id="section-6.1">
        <h3 id="name-protocol-control-of-looping">
<a href="#section-6.1" class="section-number selfRef">6.1. </a><a href="#name-protocol-control-of-looping" class="section-name selfRef">Protocol Control of Looping, Jumping, and Branching</a>
        </h3>
<p id="section-6.1-1">If the SFT value in an SFT TLV in an SFPR has the special-purpose SFT value "Change
          Sequence" (see <a href="#iana" class="xref">Section 10</a>), then this is an indication that the SFF may
          make a loop, jump, or branch according to local policy and information returned by
          the local SFI.<a href="#section-6.1-1" class="pilcrow">¶</a></p>
<p id="section-6.1-2">In this case, the SPI and SI of the next hop are encoded in the eight bytes of an entry
          in the SFIR-RD list as follows:<a href="#section-6.1-2" class="pilcrow">¶</a></p>
<ul class="ulEmpty normal">
<li class="ulEmpty normal" id="section-6.1-3.1">3 bytes SPI<a href="#section-6.1-3.1" class="pilcrow">¶</a>
</li>
          <li class="ulEmpty normal" id="section-6.1-3.2">1 byte SI<a href="#section-6.1-3.2" class="pilcrow">¶</a>
</li>
          <li class="ulEmpty normal" id="section-6.1-3.3">4 bytes Reserved (<span class="bcp14">SHOULD</span> be set to zero and ignored)<a href="#section-6.1-3.3" class="pilcrow">¶</a>
</li>
        </ul>
<p id="section-6.1-4">If the SI in this encoding is not part of the SFPR indicated by the SPI in this
          encoding, then this is an explicit error that <span class="bcp14">SHOULD</span> be detected by the SFF when it
          parses the SFPR.  The SFPR <span class="bcp14">SHOULD NOT</span> cause any forwarding state to be installed in
          the SFF, and packets received with the SPI that indicates this SFPR <span class="bcp14">SHOULD</span> be silently
          discarded.<a href="#section-6.1-4" class="pilcrow">¶</a></p>
<p id="section-6.1-5">If the SPI in this encoding is unknown, the SFF <span class="bcp14">SHOULD NOT</span> install any forwarding state
          for this SFPR but <span class="bcp14">MAY</span> hold the SFPR pending receipt of another SFPR that does use the
          encoded SPI.<a href="#section-6.1-5" class="pilcrow">¶</a></p>
<p id="section-6.1-6">If the SPI matches the current SPI for the path, this is a loop or jump.  In this case,
          if the SI is greater than or equal to the current SI, it is a loop.  If the SPI matches and the SI
          is less than the next SI, it is a jump.<a href="#section-6.1-6" class="pilcrow">¶</a></p>
<p id="section-6.1-7">If the SPI indicates another path, this is a branch, and the SI indicates the point at
          which to enter that path.<a href="#section-6.1-7" class="pilcrow">¶</a></p>
<p id="section-6.1-8">The Change Sequence SFT is just another SFT that may appear in a set of SFI/SFT tuples
          within an SI and is selected as described in <a href="#selection" class="xref">Section 5</a>.<a href="#section-6.1-8" class="pilcrow">¶</a></p>
<p id="section-6.1-9">Note that special-purpose SFTs <span class="bcp14">MUST NOT</span> be advertised in SFIRs.  If such an SFIR is
          received, it <span class="bcp14">SHOULD</span> be ignored.<a href="#section-6.1-9" class="pilcrow">¶</a></p>
</section>
</div>
<div id="implications">
<section id="section-6.2">
        <h3 id="name-implications-for-forwarding">
<a href="#section-6.2" class="section-number selfRef">6.2. </a><a href="#name-implications-for-forwarding" class="section-name selfRef">Implications for Forwarding State</a>
        </h3>
<p id="section-6.2-1">Support for looping and jumping requires that the SFF has forwarding state established
        to an SFF that provides access to an instance of the appropriate SF.

 This means
          that the SFF must have seen the relevant SFIR advertisements and mush have known that it needed to
          create the forwarding state.  This is a matter of local configuration and implementation;
          for example, an implementation could be configured to install forwarding state for specific
          looping/jumping.<a href="#section-6.2-1" class="pilcrow">¶</a></p>
<p id="section-6.2-2">Support for branching requires that the SFF has forwarding state established to an SFF that
          provides access to an instance of the appropriate entry SF on the other SFP.  This means
          that the SFF must have seen the relevant SFIR and SFPR advertisements and known that it
          needed to create the forwarding state.  This is a matter of local configuration and
          implementation; for example, an implementation could be configured to install forwarding
          state for specific branching (identified by SPI and SI).<a href="#section-6.2-2" class="pilcrow">¶</a></p>
</section>
</div>
</section>
</div>
<div id="advanced">
<section id="section-7">
      <h2 id="name-advanced-topics">
<a href="#section-7" class="section-number selfRef">7. </a><a href="#name-advanced-topics" class="section-name selfRef">Advanced Topics</a>
      </h2>
<p id="section-7-1">This section highlights several advanced topics introduced elsewhere in this document.<a href="#section-7-1" class="pilcrow">¶</a></p>
<div id="correlation">
<section id="section-7.1">
        <h3 id="name-correlating-service-functio">
<a href="#section-7.1" class="section-number selfRef">7.1. </a><a href="#name-correlating-service-functio" class="section-name selfRef">Correlating Service Function Path Instances</a>
        </h3>
<p id="section-7.1-1">It is often useful to create bidirectional SFPs to enable packet
 flows to traverse the same
         set of SFs, but in the reverse order.  However, packets on SFPs in the data plane (per
         <span>[<a href="#RFC8300" class="xref">RFC8300</a>]</span>) do not contain a direction indicator, so each direction
         must use a different SPI.<a href="#section-7.1-1" class="pilcrow">¶</a></p>
<p id="section-7.1-2">As described in <a href="#assoctlv" class="xref">Section 3.2.1.1</a>, an SFPR can contain one or more correlators
        encoded in Association TLVs.
 If the Association Type indicates "Bidirectional SFP", then
         the SFP advertised in the SFPR is one direction of a bidirectional pair of SFPs, where the
         other in the pair is advertised in the SFPR with RD as carried in the "Associated SFPR-RD"
         field of the Association TLV.  The SPI carried in the "Associated SPI" field of the
         Association TLV provides a cross-check against the SPI advertised in the SFPR with
         RD as carried in the "Associated SFPR-RD" field of the Association TLV.<a href="#section-7.1-2" class="pilcrow">¶</a></p>
<p id="section-7.1-3">As noted in <a href="#assoctlv" class="xref">Section 3.2.1.1</a>, when SFPRs reference each other, one SFPR advertisement
         will be received before the other.  Therefore, processing of an association will require
         that the first SFPR not be rejected simply because the Associated SFPR-RD it carries is
         unknown.  However, the SFP defined by the first SFPR is valid and <span class="bcp14">SHOULD</span> be available for
         use as a unidirectional SFP, even in the absence of an advertisement of its partner.<a href="#section-7.1-3" class="pilcrow">¶</a></p>
<p id="section-7.1-4">Furthermore, in error cases where SFPR-a associates with SFPR-b, but SFPR-b associates
         with SFPR-c such that a bidirectional pair of SFPs cannot be formed, the individual SFPs
         are still valid and <span class="bcp14">SHOULD</span> be available for use as unidirectional SFPs.  An implementation
         <span class="bcp14">SHOULD</span> log this situation, because it represents a controller error.<a href="#section-7.1-4" class="pilcrow">¶</a></p>
<p id="section-7.1-5">Usage of a bidirectional SFP may be programmed into the classifiers by the controller.
         Alternatively, a classifier may look at incoming packets on a bidirectional packet flow,
         extract the SPI from the received NSH, and look up the SFPR to find the reverse-direction
         SFP to use when it sends packets.<a href="#section-7.1-5" class="pilcrow">¶</a></p>
<p id="section-7.1-6">See <a href="#example" class="xref">Section 8</a> for an example of how this works.<a href="#section-7.1-6" class="pilcrow">¶</a></p>
</section>
</div>
<div id="stateful">
<section id="section-7.2">
        <h3 id="name-considerations-for-stateful">
<a href="#section-7.2" class="section-number selfRef">7.2. </a><a href="#name-considerations-for-stateful" class="section-name selfRef">Considerations for Stateful Service Functions</a>
        </h3>
<p id="section-7.2-1">Some service functions are stateful.  That means that they build and maintain state derived
         from configuration or the packet flows that they handle.  In such cases, it can be
         important or necessary that all packets from a flow continue to traverse the same instance
         of a service function so that the state can be leveraged and does not need to be regenerated.<a href="#section-7.2-1" class="pilcrow">¶</a></p>
<p id="section-7.2-2">In the case of bidirectional SFPs, it may be necessary to traverse the same instances of a
         stateful service function in both directions.  A firewall is a good example of such a service
         function.<a href="#section-7.2-2" class="pilcrow">¶</a></p>
<p id="section-7.2-3">This issue becomes a concern where there are multiple parallel instances of a service function
         and a determination of which one to use could normally be left to the SFF as a load-balancing
         or local-policy choice.<a href="#section-7.2-3" class="pilcrow">¶</a></p>
<p id="section-7.2-4">For the forward-direction SFP, the concern is that the same choice of SF is made
         for all packets of a flow under normal network conditions.  It may be possible to guarantee
         that the load-balancing functions applied in the SFFs are stable and repeatable, but a controller
         that constructs SFPs might not want to trust to this.  The controller can, in these cases, build
         a number of more specific SFPs, each traversing a specific instance of the stateful SFs.  In this
         case, the load-balancing choice can be left up to the classifier.  Thus, the classifier selects
         which instance of a stateful SF is used by a particular flow by selecting the SFP that the flow
         uses.<a href="#section-7.2-4" class="pilcrow">¶</a></p>
<p id="section-7.2-5">For bidirectional SFPs where the same instance of a stateful SF must be traversed in both
         directions, it is not enough to leave the choice of SFI as a local choice,
         even if the load balancing is stable, because coordination would be required between the decision
         points in the forward and reverse directions, and this may be hard to achieve in all cases except
         where it is the same SFF that makes the choice in both directions.<a href="#section-7.2-5" class="pilcrow">¶</a></p>
<p id="section-7.2-6">Note that this approach necessarily increases the amount of SFP state in the network (i.e., there
         are more SFPs).  It is possible to mitigate this effect by careful construction of SFPs built
         from a concatenation of other SFPs.<a href="#section-7.2-6" class="pilcrow">¶</a></p>
<p id="section-7.2-7"><a href="#examplestate" class="xref">Section 8.9</a> includes some simple examples of SFPs for stateful SFs.<a href="#section-7.2-7" class="pilcrow">¶</a></p>
</section>
</div>
<div id="private">
<section id="section-7.3">
        <h3 id="name-vpn-considerations-and-priv">
<a href="#section-7.3" class="section-number selfRef">7.3. </a><a href="#name-vpn-considerations-and-priv" class="section-name selfRef">VPN Considerations and Private Service Functions</a>
        </h3>
<p id="section-7.3-1">Likely deployments include reserving specific instances of SFs for specific
         customers or allowing customers to deploy their own SFs within the network.
         Building SFs in such environments requires that suitable identifiers be used
         to ensure that SFFs distinguish which SFIs can be used and which cannot.<a href="#section-7.3-1" class="pilcrow">¶</a></p>
<p id="section-7.3-2">This problem is similar to a problem in the way that VPNs are supported and is solved in a similar way.  The "RT"
         field is used to indicate a set of SFs from which all choices must be made.<a href="#section-7.3-2" class="pilcrow">¶</a></p>
</section>
</div>
<div id="fspecclassy">
<section id="section-7.4">
        <h3 id="name-flow-specification-for-sfc-">
<a href="#section-7.4" class="section-number selfRef">7.4. </a><a href="#name-flow-specification-for-sfc-" class="section-name selfRef">Flow Specification for SFC Classifiers</a>
        </h3>
<p id="section-7.4-1"><span>[<a href="#RFC8955" class="xref">RFC8955</a>]</span> defines a set of BGP
         routes that can be used to identify the packets in a given flow using fields in the header of
         each packet, and a set of actions -- encoded as Extended Communities -- that can be used to
         disposition those packets.  This document enables the use of these mechanisms by SFC
         classifiers by defining a new action Extended Community called "Flow Specification for SFC Classifiers",
         identified by the value 0x0d.  Note that implementation of this section of this specification will be
         controllers or classifiers communicating with each other directly for the purpose of instructing the
         classifier how to place packets onto an SFP.  So that the implementation of classifiers can be
         kept simple, and to avoid the confusion between the purposes of different Extended Communities, a
         controller <span class="bcp14">MUST NOT</span> include other action Extended Communities at the same time as a "Flow Specification
         for SFC Classifiers" Extended Community. A "Flow Specification for SFC Classifiers" Traffic Filtering Action
         Extended Community advertised with any other Traffic Filtering Action Extended Community <span class="bcp14">MUST</span> be treated as
         malformed in line with <span>[<a href="#RFC8955" class="xref">RFC8955</a>]</span> and result in the flow-specification
         UPDATE message being handled as "treat-as-withdraw", according to
 <span>[<a href="#RFC7606" class="xref">RFC7606</a>], <a href="https://www.rfc-editor.org/rfc/rfc7606#section-2" class="relref">Section 2</a></span>.<a href="#section-7.4-1" class="pilcrow">¶</a></p>
<p id="section-7.4-2">To put the flow specification into context, when multiple service function chaining overlays are present in one
         network, each FlowSpec update <span class="bcp14">MUST</span> be tagged with the route target of the overlay or VPN
         network for which it is intended.<a href="#section-7.4-2" class="pilcrow">¶</a></p>
<p id="section-7.4-3">This Extended Community is encoded as an 8-octet value, as shown in <a href="#fspecclassyfig" class="xref">Figure 10</a>.<a href="#section-7.4-3" class="pilcrow">¶</a></p>
<span id="name-the-format-of-the-flow-spec"></span><div id="fspecclassyfig">
<figure id="figure-10">
          <div class="artwork art-text alignLeft" id="section-7.4-4.1">
<pre>
                      1                   2                   3
  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 | Type=0x80     | Sub-Type=0x0d |  SPI                          |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |  SPI  (cont.) |   SI          |  SFT                          |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</pre>
</div>
<figcaption><a href="#figure-10" class="selfRef">Figure 10</a>:
<a href="#name-the-format-of-the-flow-spec" class="selfRef">The Format of the Flow Specification for SFC Classifiers Extended Community</a>
          </figcaption></figure>
</div>
<p id="section-7.4-5">The Extended Community contains the Service Path Identifier (SPI), Service Index (SI), and
         Service Function Type (SFT), as defined elsewhere in this document.  Thus, each action extended
         community defines the entry point (not necessarily the first hop) into a specific SFP.  This allows, for example, different flows to enter the same SFP at different points.<a href="#section-7.4-5" class="pilcrow">¶</a></p>
<p id="section-7.4-6">Note that, according to <span>[<a href="#RFC8955" class="xref">RFC8955</a>]</span>, a given flow-specification
         update may include multiple of these action Extended Communities.  If a given action extended
         community does not contain an installed SFPR with the specified {SPI, SI, SFT}, it <span class="bcp14">MUST NOT</span> be
         used for dispositioning the packets of the specified flow.<a href="#section-7.4-6" class="pilcrow">¶</a></p>
<p id="section-7.4-7">The normal case of packet classification for service function chaining will see a packet enter the SFP at its first
         hop.  In this case, the SI in the Extended Community is superfluous, and the SFT may also be
         unnecessary.  To allow these cases to be handled, a special meaning is assigned to an SI of zero (not a valid value) and an SFT of zero (a reserved value in the registry -- see
         <a href="#SFTreg" class="xref">Section 10.5</a>).<a href="#section-7.4-7" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-7.4-8.1">If an SFC Classifiers Extended Community is received with SI = 0, then it means that the
              first hop of the SFP indicated by the SPI <span class="bcp14">MUST</span> be used.<a href="#section-7.4-8.1" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-7.4-8.2">
            <p id="section-7.4-8.2.1">If an SFC Classifiers Extended Community is received with SFT = 0, then there are two
              subcases:<a href="#section-7.4-8.2.1" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-7.4-8.2.2.1">If there is a choice of SFT in the hop indicated by the value of the SI (including
                    SI = 0), then SFT = 0 means there is a free choice of
       which SFT to use, according to local policy).<a href="#section-7.4-8.2.2.1" class="pilcrow">¶</a>
</li>
              <li class="normal" id="section-7.4-8.2.2.2">If there is no choice of SFT in the hop indicated by the value of SI, then SFT = 0
                    means that the value of the SFT at that hop, as indicated in the SFPR for the
                    indicated SPI, <span class="bcp14">MUST</span> be used.<a href="#section-7.4-8.2.2.2" class="pilcrow">¶</a>
</li>
            </ul>
</li>
        </ul>
<p id="section-7.4-9">One of the filters that the flow specification may describe is the VPN to which the traffic belongs.
         Additionally, as noted above, to put the indicated SPI into context when multiple SFC overlays are
         present in one network, each FlowSpec update <span class="bcp14">MUST</span> be tagged with the route target of the
         overlay or VPN network for which it is intended.<a href="#section-7.4-9" class="pilcrow">¶</a></p>
<p id="section-7.4-10">Note that future extensions might be made to the Flow Specification for SFC Classifiers Extended Community
         to provide instruction to the classifier about what metadata to add to packets that it classifies
         for forwarding on a specific SFP; however, that is outside the scope of this document.<a href="#section-7.4-10" class="pilcrow">¶</a></p>
</section>
</div>
<div id="representation">
<section id="section-7.5">
        <h3 id="name-choice-of-data-plane-spi-si">
<a href="#section-7.5" class="section-number selfRef">7.5. </a><a href="#name-choice-of-data-plane-spi-si" class="section-name selfRef">Choice of Data Plane SPI/SI Representation</a>
        </h3>
<p id="section-7.5-1">This document ties together the control and data planes of a service function chaining overlay network through the use
         of the SPI/SI that is nominally carried in the NSH of a given packet.  However, in order to handle
         situations in which the NSH is not ubiquitously deployed, it is also possible to use alternative
         data plane representations of the SPI/SI by carrying the identical semantics in other protocol fields,
         such as MPLS labels <span>[<a href="#RFC8595" class="xref">RFC8595</a>]</span>.<a href="#section-7.5-1" class="pilcrow">¶</a></p>
<p id="section-7.5-2">This document defines a new Sub-TLV for the tunnel encapsulation attribute <span>[<a href="#RFC9012" class="xref">RFC9012</a>]</span>,
         the SPI/SI Representation Sub-TLV of type 16.  This Sub-TLV <span class="bcp14">MAY</span> be present in each Tunnel TLV contained
         in a tunnel encapsulation attribute when the attribute is carried by an SFIR.  The "Value" field of this
         Sub-TLV is a two-octet field of flags numbered counting from the most significant bit, each of which
         describes how the originating SFF expects to see the SPI/SI represented in the data plane for packets
         carried in the tunnels described by the Tunnel TLV.<a href="#section-7.5-2" class="pilcrow">¶</a></p>
<p id="section-7.5-3">The following bits are defined by this document and are tracked in an IANA registry described in
         <a href="#IANAbits" class="xref">Section 10.10</a>:<a href="#section-7.5-3" class="pilcrow">¶</a></p>
<span class="break"></span><dl class="dlParallel" id="section-7.5-4">
          <dt id="section-7.5-4.1">Bit 0:</dt>
          <dd style="margin-left: 1.5em" id="section-7.5-4.2">If this bit is set, the NSH is to be used to carry the SPI/SI in the data plane.<a href="#section-7.5-4.2" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-7.5-4.3">Bit 1:</dt>
          <dd style="margin-left: 1.5em" id="section-7.5-4.4">If this bit is set, two labels in an MPLS label stack are to be used as described in
                                <a href="#MPLS-NSH" class="xref">Section 7.5.1</a>.<a href="#section-7.5-4.4" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
</dl>
<p id="section-7.5-5">If a given Tunnel TLV does not contain an SPI/SI Representation Sub-TLV, then it <span class="bcp14">MUST</span> be processed as if
         such a Sub-TLV is present with Bit 0 set and no other bits set.  That is, the absence of the Sub-TLV
         <span class="bcp14">SHALL</span> be interpreted to mean that the NSH is to be used.<a href="#section-7.5-5" class="pilcrow">¶</a></p>
<p id="section-7.5-6">If a given Tunnel TLV contains an SPI/SI Representation Sub-TLV
 with a "Value" field that has no flag set, then
         the tunnel indicated by the Tunnel TLV <span class="bcp14">MUST NOT</span> be used for forwarding SFC packets.  If a given Tunnel TLV
         contains an SPI/SI Representation Sub-TLV with both bit 0 and bit 1 set, then the tunnel indicated by the
         Tunnel TLV <span class="bcp14">MUST NOT</span> be used for forwarding SFC
  packets.  The meaning and rules for the presence of other bits
         is to be defined in future documents, but implementations of this specification <span class="bcp14">MUST</span> set other bits to
         zero and ignore them on receipt.<a href="#section-7.5-6" class="pilcrow">¶</a></p>
<p id="section-7.5-7">If a given Tunnel TLV contains more than one SPI/SI Representation Sub-TLV, then the first one <span class="bcp14">MUST</span> be
         considered and subsequent instances <span class="bcp14">MUST</span> be ignored.<a href="#section-7.5-7" class="pilcrow">¶</a></p>
<p id="section-7.5-8">Note that the MPLS representation of the logical NSH may be used even if the tunnel is not an MPLS tunnel.
         Conversely, MPLS tunnels may be used to carry other encodings of the logical NSH (specifically, the NSH
         itself).  It is a requirement that both ends of a tunnel over the underlay network know that the tunnel is
         used for service function chaining and know what form of NSH representation is used.  The signaling mechanism described here
         allows coordination of this information.<a href="#section-7.5-8" class="pilcrow">¶</a></p>
<div id="MPLS-NSH">
<section id="section-7.5.1">
          <h4 id="name-mpls-representation-of-the-">
<a href="#section-7.5.1" class="section-number selfRef">7.5.1. </a><a href="#name-mpls-representation-of-the-" class="section-name selfRef">MPLS Representation of the SPI/SI</a>
          </h4>
<p id="section-7.5.1-1">If bit 1 is set in the SPI/SI Representation Sub-TLV, then labels in the MPLS label stack are
            used to indicate SFC forwarding and processing instructions to achieve the semantics of a logical NSH.
            The label stack is encoded as shown in <span>[<a href="#RFC8595" class="xref">RFC8595</a>]</span>.<a href="#section-7.5.1-1" class="pilcrow">¶</a></p>
</section>
</div>
</section>
</div>
<div id="swapOp">
<section id="section-7.6">
        <h3 id="name-mpls-label-swapping-stackin">
<a href="#section-7.6" class="section-number selfRef">7.6. </a><a href="#name-mpls-label-swapping-stackin" class="section-name selfRef">MPLS Label Swapping/Stacking Operation</a>
        </h3>
<p id="section-7.6-1">When a classifier constructs an MPLS label stack for an SFP, it starts with that SFP's last hop.  If the
         last hop requires an {SPI, SI} label pair for label swapping, it pushes the SI (set to the SI value of the
         last hop) and the SFP's SPI onto the MPLS label stack.  If the last hop requires a {context label, SFI
         label} label pair for label stacking, it selects a specific SFIR and pushes that SFIR's SFI label and
         context label onto the MPLS label stack.<a href="#section-7.6-1" class="pilcrow">¶</a></p>
<p id="section-7.6-2">The classifier then moves sequentially back through the SFP one hop at a time.  For each hop, if the hop
         requires an {SPI, SI} and there is an {SPI, SI} at the top of the MPLS label stack, the SI is set to the
         SI value of the current hop.  If there is not an {SPI, SI} at the top of the MPLS label stack, it pushes
         the SI (set to the SI value of the current hop) and the SFP's SPI onto the MPLS label stack.<a href="#section-7.6-2" class="pilcrow">¶</a></p>
<p id="section-7.6-3">If the hop requires a {context label, SFI label}, it selects a specific SFIR and pushes that SFIR's
         SFI label and context label onto the MPLS label stack.<a href="#section-7.6-3" class="pilcrow">¶</a></p>
</section>
</div>
<div id="mpls-encaps">
<section id="section-7.7">
        <h3 id="name-support-for-mpls-encapsulat">
<a href="#section-7.7" class="section-number selfRef">7.7. </a><a href="#name-support-for-mpls-encapsulat" class="section-name selfRef">Support for MPLS-Encapsulated NSH Packets</a>
        </h3>
<p id="section-7.7-1"><span>[<a href="#RFC8596" class="xref">RFC8596</a>]</span> describes how to transport SFC packets using the NSH 
        over an MPLS transport network.

   Signaling that this approach is in use is supported by this document
  as follows:<a href="#section-7.7-1" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-7.7-2.1">A "BGP Tunnel Encapsulation Attribute" Sub-TLV is included with the
    codepoint 10 (representing "MPLS Label Stack") from the "BGP Tunnel
    Encapsulation Attribute Sub-TLVs" registry defined in
    <span>[<a href="#RFC9012" class="xref">RFC9012</a>]</span>.<a href="#section-7.7-2.1" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-7.7-2.2">An "SFP Traversal With MPLS Label Stack" TLV is included containing
    an "SPI/SI Representation" Sub-TLV with bit 0 set and bit 1 cleared.<a href="#section-7.7-2.2" class="pilcrow">¶</a>
</li>
        </ul>
<p id="section-7.7-3">In this case, the MPLS label stack constructed by the SFF to forward a packet to the next SFF on the
          SFP will consist of the labels needed to reach that SFF, and if label stacking is used, it will also
          include the labels advertised in the MPLS Label Stack Sub-TLV and the labels remaining in the stack
          needed to traverse the remainder of the SFP.<a href="#section-7.7-3" class="pilcrow">¶</a></p>
</section>
</div>
</section>
</div>
<div id="example">
<section id="section-8">
      <h2 id="name-examples">
<a href="#section-8" class="section-number selfRef">8. </a><a href="#name-examples" class="section-name selfRef">Examples</a>
      </h2>
<p id="section-8-1">Most of the examples in this section use IPv4 addressing.  But there is nothing special about
       IPv4 in the mechanisms described in this document, and they are equally applicable to IPv6.  A
       few examples using IPv6 addressing are provided in <a href="#v6samples" class="xref">Section 8.10</a>.<a href="#section-8-1" class="pilcrow">¶</a></p>
<p id="section-8-2">Assume we have a service function overlay network with four SFFs (SFF1, SFF2, SFF3, and SFF4).
       The SFFs have addresses in the underlay network as follows:<a href="#section-8-2" class="pilcrow">¶</a></p>
<div id="section-8-3">
<pre class="sourcecode">
   SFF1 192.0.2.1
   SFF2 192.0.2.2
   SFF3 192.0.2.3
   SFF4 192.0.2.4
</pre><a href="#section-8-3" class="pilcrow">¶</a>
</div>
<p id="section-8-4">Each SFF provides access to some SFIs from the four SFTs, SFT=41, SFT=42,
       SFT=43, and SFT=44, as follows:<a href="#section-8-4" class="pilcrow">¶</a></p>
<div id="section-8-5">
<pre class="sourcecode">
   SFF1 SFT=41 and SFT=42
   SFF2 SFT=41 and SFT=43
   SFF3 SFT=42 and SFT=44
   SFF4 SFT=43 and SFT=44
</pre><a href="#section-8-5" class="pilcrow">¶</a>
</div>
<p id="section-8-6">The service function network also contains a controller with address 198.51.100.1.<a href="#section-8-6" class="pilcrow">¶</a></p>
<p id="section-8-7">This example service function overlay network is shown in <a href="#examplefig" class="xref">Figure 11</a>.<a href="#section-8-7" class="pilcrow">¶</a></p>
<span id="name-example-service-function-ov"></span><div id="examplefig">
<figure id="figure-11">
        <div class="artwork art-text alignLeft" id="section-8-8.1">
<pre>
       --------------
      |  Controller  |
      | 198.51.100.1 |   ------     ------    ------     ------
       --------------   | SFI  |   | SFI  |  | SFI  |   | SFI  |
                        |SFT=41|   |SFT=42|  |SFT=41|   |SFT=43|
                         ------     ------    ------     ------
                              \     /              \     /
                             ---------            ---------
               ----------   |   SFF1  |          |   SFF2  |
   Packet --&gt; |          |  |192.0.2.1|          |192.0.2.2|
   Flows  --&gt; |Classifier|   ---------            ---------  --&gt;Dest
              |          |                                   --&gt;
               ----------    ---------            ---------
                            |   SFF3  |          |   SFF4  |
                            |192.0.2.3|          |192.0.2.4|
                             ---------            ---------
                              /     \              /     \
                         ------     ------    ------     ------
                        | SFI  |   | SFI  |  | SFI  |   | SFI  |
                        |SFT=42|   |SFT=44|  |SFT=43|   |SFT=44|
                         ------     ------    ------     ------
</pre>
</div>
<figcaption><a href="#figure-11" class="selfRef">Figure 11</a>:
<a href="#name-example-service-function-ov" class="selfRef">Example Service Function Overlay Network</a>
        </figcaption></figure>
</div>
<p id="section-8-9">The SFFs advertise routes to the SFIs they support.  These advertisements
       contain RDs that are set according to the network operator's
       configuration model.  In all of these IPv4 examples, we use RDs of Type 1 such that the
       available six octets are partitioned as four octets for the IPv4 address of the advertising
       SFF, and two octets that are a local index of the SFI.  This scheme is chosen purely for
       convenience of documentation, and an operator is totally free to use any other scheme so
       long as it conforms to the definitions of SFIR and SFPR in Sections
       <a href="#sfiRoutes" class="xref">3.1</a> and
       <a href="#sfpRoutes" class="xref">3.2</a>.<a href="#section-8-9" class="pilcrow">¶</a></p>
<p id="section-8-10">Thus, we see the following SFIRs advertised:<a href="#section-8-10" class="pilcrow">¶</a></p>
<div id="section-8-11">
<pre class="sourcecode">
   RD = 192.0.2.1/1, SFT = 41
   RD = 192.0.2.1/2, SFT = 42
   RD = 192.0.2.2/1, SFT = 41
   RD = 192.0.2.2/2, SFT = 43
   RD = 192.0.2.3/7, SFT = 42
   RD = 192.0.2.3/8, SFT = 44
   RD = 192.0.2.4/5, SFT = 43
   RD = 192.0.2.4/6, SFT = 44
</pre><a href="#section-8-11" class="pilcrow">¶</a>
</div>
<p id="section-8-12">Note that the addressing used for communicating between SFFs is taken
       from the tunnel encapsulation attribute of the SFIR and not from the SFIR-RD.<a href="#section-8-12" class="pilcrow">¶</a></p>
<div id="exampleexplicit">
<section id="section-8.1">
        <h3 id="name-example-explicit-sfp-with-n">
<a href="#section-8.1" class="section-number selfRef">8.1. </a><a href="#name-example-explicit-sfp-with-n" class="section-name selfRef">Example Explicit SFP with No Choices</a>
        </h3>
<p id="section-8.1-1">Consider the following SFPR.<a href="#section-8.1-1" class="pilcrow">¶</a></p>
<div id="section-8.1-2">
<pre class="sourcecode">
   SFP1:  RD = 198.51.100.1/101, SPI = 15,
          [SI = 255, SFT = 41, RD = 192.0.2.1/1],
          [SI = 250, SFT = 43, RD = 192.0.2.2/2]
</pre><a href="#section-8.1-2" class="pilcrow">¶</a>
</div>
<p id="section-8.1-3">The SFP consists of an SF of Type 41 located at SFF1, followed by an SF
          of Type 43 located at SFF2.  This path is fully explicit, and each SFF is
          offered no choice in forwarding packets along the path.<a href="#section-8.1-3" class="pilcrow">¶</a></p>
<p id="section-8.1-4">SFF1 will receive packets on the path from the classifier and will identify the path
          from the SPI (15).  The initial SI will be 255, and so SFF1 will deliver the packets to the
          SFI for SFT 41.<a href="#section-8.1-4" class="pilcrow">¶</a></p>
<p id="section-8.1-5">When the packets are returned to SFF1 by the SFI, the SI will be decreased to 250 for the next hop.
           SFF1 has no flexibility in the choice of SFF to support the next-hop SFI and will forward
           the packet to SFF2, which will send the packets to the SFI that supports SFT 43 before
           forwarding the packets to their destinations.<a href="#section-8.1-5" class="pilcrow">¶</a></p>
</section>
</div>
<div id="examplechoice">
<section id="section-8.2">
        <h3 id="name-example-sfp-with-choice-of-">
<a href="#section-8.2" class="section-number selfRef">8.2. </a><a href="#name-example-sfp-with-choice-of-" class="section-name selfRef">Example SFP with Choice of SFIs</a>
        </h3>
<div id="section-8.2-1">
<pre class="sourcecode">
   SFP2:  RD = 198.51.100.1/102, SPI = 16,
          [SI = 255, SFT = 41, RD = 192.0.2.1/1],
          [SI = 250, SFT = 43, {RD = 192.0.2.2/2,
                                RD = 192.0.2.4/5 } ]
</pre><a href="#section-8.2-1" class="pilcrow">¶</a>
</div>
<p id="section-8.2-2">In this example, the path also consists of an SF of Type 41 located at SFF1, and this is
          followed by an SF of Type 43. However, in this case, the SI = 250 contains a choice between the
          SFI located at SFF2 and the SFI located at SFF4.<a href="#section-8.2-2" class="pilcrow">¶</a></p>
<p id="section-8.2-3">SFF1 will receive packets on the path from the classifier and will identify the path
          from the SPI (16).  The initial SI will be 255, and so SFF1 will deliver the packets to the
          SFI for SFT 41.<a href="#section-8.2-3" class="pilcrow">¶</a></p>
<p id="section-8.2-4">When the packets are returned to SFF1 by the SFI, the SI will be decreased to 250 for
           the next hop.  SFF1 now has a choice of next-hop SFFs to execute the next hop in the path.
           It can either forward packets to SFF2 or SFF4 to execute a function of Type 43.  It uses
           its local load-balancing algorithm to make this choice.  The chosen SFF will send the
           packets to the SFI that supports SFT 43 before forwarding the packets to their
           destinations.<a href="#section-8.2-4" class="pilcrow">¶</a></p>
</section>
</div>
<div id="exampleopen">
<section id="section-8.3">
        <h3 id="name-example-sfp-with-open-choic">
<a href="#section-8.3" class="section-number selfRef">8.3. </a><a href="#name-example-sfp-with-open-choic" class="section-name selfRef">Example SFP with Open Choice of SFIs</a>
        </h3>
<div id="section-8.3-1">
<pre class="sourcecode">
   SFP3:  RD = 198.51.100.1/103, SPI = 17,
          [SI = 255, SFT = 41, RD = 192.0.2.1/1],
          [SI = 250, SFT = 44, RD = 0]
</pre><a href="#section-8.3-1" class="pilcrow">¶</a>
</div>
<p id="section-8.3-2">In this example, the path also consists of an SF of Type 41 located at SFF1, and this is
          followed by an SI with an RD of zero and SF of Type 44.  This means that a choice can be
          made between any SFF that supports an SFI of Type 44.<a href="#section-8.3-2" class="pilcrow">¶</a></p>
<p id="section-8.3-3">SFF1 will receive packets on the path from the classifier and will identify the path
          from the SPI (17).  The initial SI will be 255, and so SFF1 will deliver the packets to the
          SFI for SFT 41.<a href="#section-8.3-3" class="pilcrow">¶</a></p>
<p id="section-8.3-4">When the packets are returned to SFF1 by the SFI, the SI will be decreased to 250 for
           the next hop.  SFF1 now has a free choice of next-hop SFFs to execute the next hop in the
           path, selecting between all SFFs that support SFs of Type 44.  Looking at the SFIRs it
           has received, SFF1 knows that SF Type 44 is supported by SFF3 and SFF4.  SFF1 uses its
           local load-balancing algorithm to make this choice.  The chosen SFF will send the packets
           to the SFI that supports SFT 44 before forwarding the packets to their destinations.<a href="#section-8.3-4" class="pilcrow">¶</a></p>
</section>
</div>
<div id="examplesft">
<section id="section-8.4">
        <h3 id="name-example-sfp-with-choice-of-s">
<a href="#section-8.4" class="section-number selfRef">8.4. </a><a href="#name-example-sfp-with-choice-of-s" class="section-name selfRef">Example SFP with Choice of SFTs</a>
        </h3>
<div id="section-8.4-1">
<pre class="sourcecode">
   SFP4:  RD = 198.51.100.1/104, SPI = 18,
          [SI = 255, SFT = 41, RD = 192.0.2.1/1],
          [SI = 250, {SFT = 43, RD = 192.0.2.2/2,
                      SFT = 44, RD = 192.0.2.3/8 } ]
</pre><a href="#section-8.4-1" class="pilcrow">¶</a>
</div>
<p id="section-8.4-2">This example provides a choice of SF type in the second hop in the path.  The SI of 250
          indicates a choice between SF Type 43 located at SF2 and SF Type 44 located at SF3.<a href="#section-8.4-2" class="pilcrow">¶</a></p>
<p id="section-8.4-3">SFF1 will receive packets on the path from the classifier and will identify the path
          from the SPI (18).  The initial SI will be 255, and so SFF1 will deliver the packets to the
          SFI for SFT 41.<a href="#section-8.4-3" class="pilcrow">¶</a></p>
<p id="section-8.4-4">When the packets are returned to SFF1 by the SFI, the SI will be decreased to 250 for
          the next hop.  SFF1 now has a free choice of next-hop SFFs to execute the next hop in the
          path, selecting between all SFFs that support an SF of Type 43 and
   SFF3, which supports an
          SF of Type 44.  These may be completely different functions that are to be executed dependent
          on specific conditions, or they may be similar functions identified with different type
          identifiers (such as firewalls from different vendors).  SFF1 uses
   its local policy and load-balancing algorithm to make this choice
   and may use additional information passed back from
          the local SFI to help inform its selection.  The chosen SFF will send the packets to the SFI
          that supports the chosen SFT before forwarding the packets to their destinations.<a href="#section-8.4-4" class="pilcrow">¶</a></p>
</section>
</div>
<div id="exampleco">
<section id="section-8.5">
        <h3 id="name-example-correlated-bidirect">
<a href="#section-8.5" class="section-number selfRef">8.5. </a><a href="#name-example-correlated-bidirect" class="section-name selfRef">Example Correlated Bidirectional SFPs</a>
        </h3>
<div id="section-8.5-1">
<pre class="sourcecode">
  SFP5:  RD = 198.51.100.1/105, SPI = 19,
         Assoc-Type = 1, Assoc-RD = 198.51.100.1/106, Assoc-SPI = 20,
         [SI = 255, SFT = 41, RD = 192.0.2.1/1],
         [SI = 250, SFT = 43, RD = 192.0.2.2/2]

  SFP6:  RD = 198.51.100.1/106, SPI = 20,
         Assoc-Type = 1, Assoc-RD = 198.51.100.1/105, Assoc-SPI = 19,
         [SI = 254, SFT = 43, RD = 192.0.2.2/2],
         [SI = 249, SFT = 41, RD = 192.0.2.1/1]
</pre><a href="#section-8.5-1" class="pilcrow">¶</a>
</div>
<p id="section-8.5-2">This example demonstrates correlation of two SFPs to form a bidirectional SFP, as
          described in <a href="#correlation" class="xref">Section 7.1</a>.<a href="#section-8.5-2" class="pilcrow">¶</a></p>
<p id="section-8.5-3">Two SFPRs are advertised by the controller.  They have different SPIs (19 and 20),
          so they are known to be separate SFPs, but they both have Association TLVs with Association Type
          set to 1, indicating bidirectional SFPs.  Each has an "Associated SFPR-RD" field containing the value
          of the other SFPR-RD to correlate the two SFPs as a bidirectional pair.<a href="#section-8.5-3" class="pilcrow">¶</a></p>
<p id="section-8.5-4">As can be seen from the SFPRs in this example, the paths are symmetric: the hops in
          SFP5 appear in the reverse order in SFP6.<a href="#section-8.5-4" class="pilcrow">¶</a></p>
</section>
</div>
<div id="exampleass">
<section id="section-8.6">
        <h3 id="name-example-correlated-asymmetr">
<a href="#section-8.6" class="section-number selfRef">8.6. </a><a href="#name-example-correlated-asymmetr" class="section-name selfRef">Example Correlated Asymmetrical Bidirectional SFPs</a>
        </h3>
<div id="section-8.6-1">
<pre class="sourcecode">
  SFP7:  RD = 198.51.100.1/107, SPI = 21,
         Assoc-Type = 1, Assoc-RD = 198.51.100.1/108, Assoc-SPI = 22,
         [SI = 255, SFT = 41, RD = 192.0.2.1/1],
         [SI = 250, SFT = 43, RD = 192.0.2.2/2]

  SFP8:  RD = 198.51.100.1/108, SPI = 22,
         Assoc-Type = 1, Assoc-RD = 198.51.100.1/107, Assoc-SPI = 21,
         [SI = 254, SFT = 44, RD = 192.0.2.4/6],
         [SI = 249, SFT = 41, RD = 192.0.2.1/1]
</pre><a href="#section-8.6-1" class="pilcrow">¶</a>
</div>
<p id="section-8.6-2">Asymmetric bidirectional SFPs can also be created.  This example shows a pair of SFPs
          with distinct SPIs (21 and 22) that are correlated in the same way as in the example in
          <a href="#exampleco" class="xref">Section 8.5</a>.<a href="#section-8.6-2" class="pilcrow">¶</a></p>
<p id="section-8.6-3">However, unlike in that example, the SFPs are different in each direction.  Both paths
          include a hop of SF Type 41, but SFP7 includes a hop of SF Type 43 supported at SFF2, while
          SFP8 includes a hop of SF Type 44 supported at SFF4.<a href="#section-8.6-3" class="pilcrow">¶</a></p>
</section>
</div>
<div id="exampleloop">
<section id="section-8.7">
        <h3 id="name-example-looping-in-an-sfp">
<a href="#section-8.7" class="section-number selfRef">8.7. </a><a href="#name-example-looping-in-an-sfp" class="section-name selfRef">Example Looping in an SFP</a>
        </h3>
<div id="section-8.7-1">
<pre class="sourcecode">
   SFP9:  RD = 198.51.100.1/109, SPI = 23,
          [SI = 255, SFT = 41, RD = 192.0.2.1/1],
          [SI = 250, SFT = 44, RD = 192.0.2.4/5],
          [SI = 245, {SFT = 1, RD = {SPI=23, SI=255, Rsv=0},
                      SFT = 42, RD = 192.0.2.3/7 } ]
</pre><a href="#section-8.7-1" class="pilcrow">¶</a>
</div>
<p id="section-8.7-2">Looping and jumping are described in <a href="#looping" class="xref">Section 6</a>.  This example shows
          an SFP that contains an explicit loop-back instruction that is presented as a choice
          within an SFP hop.<a href="#section-8.7-2" class="pilcrow">¶</a></p>
<p id="section-8.7-3">The first two hops in the path (SI = 255 and SI = 250) are normal.  That is, the packets
          will be delivered to SFF1 and SFF4 in turn for execution of SFs of Type 41 and 44,
          respectively.<a href="#section-8.7-3" class="pilcrow">¶</a></p>
<p id="section-8.7-4">The third hop (SI = 245) presents SFF4 with a choice of next hop.  It can either forward
          the packets to SFF3 for an SF of Type 42 (the second choice) or it can loop back.<a href="#section-8.7-4" class="pilcrow">¶</a></p>
<p id="section-8.7-5">The loop-back entry in the SFPR for SI = 245 is indicated by the special-purpose SFT value
          1 ("Change Sequence").  Within this hop, the RD is interpreted as encoding the SPI and SI
          of the next hop (see <a href="#changeseq" class="xref">Section 6.1</a>).
   In this case, the SPI is 23, which
          indicates that this is a loop or branch, i.e., the next hop is on the same SFP.  The SI is
          set to 255; this is a higher number than the current SI (245), indicating a loop.<a href="#section-8.7-5" class="pilcrow">¶</a></p>
<p id="section-8.7-6">SFF4 must make a choice between these two next hops. The packet
 will be either forwarded to SFF3 with the NSH SI decreased
 to 245 or looped back to SFF1 with the NSH SI reset to 255.
          This choice will be made according to local policy, information passed back by the local SFI,
          and details in the packets' metadata that are used to prevent infinite looping.<a href="#section-8.7-6" class="pilcrow">¶</a></p>
</section>
</div>
<div id="examplebranch">
<section id="section-8.8">
        <h3 id="name-example-branching-in-an-sfp">
<a href="#section-8.8" class="section-number selfRef">8.8. </a><a href="#name-example-branching-in-an-sfp" class="section-name selfRef">Example Branching in an SFP</a>
        </h3>
<div id="section-8.8-1">
<pre class="sourcecode">
   SFP10:  RD = 198.51.100.1/110, SPI = 24,
          [SI = 254, SFT = 42, RD = 192.0.2.3/7],
          [SI = 249, SFT = 43, RD = 192.0.2.2/2]

   SFP11:  RD = 198.51.100.1/111, SPI = 25,
          [SI = 255, SFT = 41, RD = 192.0.2.1/1],
          [SI = 250, SFT = 1, RD = {SPI=24, SI=254, Rsv=0}]
</pre><a href="#section-8.8-1" class="pilcrow">¶</a>
</div>
<p id="section-8.8-2">Branching follows a similar procedure to that for looping (and jumping), as shown in
          <a href="#exampleloop" class="xref">Section 8.7</a>. However, there are two SFPs involved.<a href="#section-8.8-2" class="pilcrow">¶</a></p>
<p id="section-8.8-3">SFP10 shows a normal path with packets forwarded to SFF3 and SFF2 for execution of
          service functions of Type 42 and 43, respectively.<a href="#section-8.8-3" class="pilcrow">¶</a></p>
<p id="section-8.8-4">SFP11 starts as normal (SFF1 for an SF of Type 41), but then SFF1 processes the
          next hop in the path and finds a "Change Sequence" special-purpose SFT.  The "SFIR-RD"
          field includes an SPI of 24, which indicates SFP10, not the current SFP.  The SI in the
          SFIR-RD is 254, so SFF1 knows that it must set the SPI/SI in the NSH to 24/254 and
          send the packets to the appropriate SFF, as advertised in the SFPR for SFP10 (that is,
          SFF3).<a href="#section-8.8-4" class="pilcrow">¶</a></p>
</section>
</div>
<div id="examplestate">
<section id="section-8.9">
        <h3 id="name-examples-of-sfps-with-state">
<a href="#section-8.9" class="section-number selfRef">8.9. </a><a href="#name-examples-of-sfps-with-state" class="section-name selfRef">Examples of SFPs with Stateful Service Functions</a>
        </h3>
<p id="section-8.9-1">This section provides some examples to demonstrate establishing SFPs when there is a choice
          of service functions at a particular hop, and where consistency of choice is required in
          both directions.  The scenarios that give rise to this requirement are discussed in
          <a href="#stateful" class="xref">Section 7.2</a>.<a href="#section-8.9-1" class="pilcrow">¶</a></p>
<div id="stateegsff">
<section id="section-8.9.1">
          <h4 id="name-forward-and-reverse-choice-">
<a href="#section-8.9.1" class="section-number selfRef">8.9.1. </a><a href="#name-forward-and-reverse-choice-" class="section-name selfRef">Forward and Reverse Choice Made at the SFF</a>
          </h4>
<p id="section-8.9.1-1">Consider the topology shown in <a href="#egsfffig" class="xref">Figure 12</a>.  There are three SFFs
             arranged neatly in a line, and the middle one (SFF2) supports three SFIs all of
             SFT 42.  These three instances can be used by SFF2 to load balance so that no
             one instance is swamped.<a href="#section-8.9.1-1" class="pilcrow">¶</a></p>
<span id="name-example-where-choice-is-mad"></span><div id="egsfffig">
<figure id="figure-12">
            <div class="artwork art-text alignLeft" id="section-8.9.1-2.1">
<pre>
                ------     ------   ------   ------    ------
               | SFI  |   | SFIa | | SFIb | | SFIc |  | SFI  |
               |SFT=41|   |SFT=42| |SFT=42| |SFT=42|  |SFT=43|
                ------     ------\  ------  /------    ------
                     \            \   |    /           /
                    ---------     ---------     ---------
      ----------   |   SFF1  |   |   SFF2  |   |   SFF3  |
 --&gt; |          |..|192.0.2.1|...|192.0.2.2|...|192.0.2.3|--&gt;
 --&gt; |Classifier|   ---------     ---------     ---------
     |          |
      ----------
</pre>
</div>
<figcaption><a href="#figure-12" class="selfRef">Figure 12</a>:
<a href="#name-example-where-choice-is-mad" class="selfRef">Example Where Choice Is Made at the SFF</a>
            </figcaption></figure>
</div>
<p id="section-8.9.1-3">This leads to the following SFIRs being advertised.<a href="#section-8.9.1-3" class="pilcrow">¶</a></p>
<div id="section-8.9.1-4">
<pre class="sourcecode">
   RD = 192.0.2.1/11, SFT = 41
   RD = 192.0.2.2/11, SFT = 42  (for SFIa)
   RD = 192.0.2.2/12, SFT = 42  (for SFIb)
   RD = 192.0.2.2/13, SFT = 42  (for SFIc)
   RD = 192.0.2.3/11, SFT = 43
</pre><a href="#section-8.9.1-4" class="pilcrow">¶</a>
</div>
<p id="section-8.9.1-5">The controller can create a single forward SFP (SFP12), giving SFF2 the choice
             of which SFI to use to provide a function of SFT 42, as follows.  The
             load-balancing choice between the three available SFIs is assumed to be
             within the capabilities of the SFF, and if the SFs are stateful, it is
             assumed that the SFF knows this and arranges load balancing in a stable,
             flow-dependent way.<a href="#section-8.9.1-5" class="pilcrow">¶</a></p>
<div id="section-8.9.1-6">
<pre class="sourcecode">
   SFP12:  RD = 198.51.100.1/112, SPI = 26,
         Assoc-Type = 1, Assoc-RD = 198.51.100.1/113, Assoc-SPI = 27,
          [SI = 255, SFT = 41, RD = 192.0.2.1/11],
          [SI = 254, SFT = 42, {RD = 192.0.2.2/11,
                                     192.0.2.2/12,
                                     192.0.2.2/13 }],
          [SI = 253, SFT = 43, RD = 192.0.2.3/11]
</pre><a href="#section-8.9.1-6" class="pilcrow">¶</a>
</div>
<p id="section-8.9.1-7">The reverse SFP (SFP13) in this case may also be created as shown below, using
            association with the forward SFP and giving the load-balancing choice to
            SFF2.  This is safe, even in the case that the SFs of Type 42 are stateful,
            because SFF2 is doing the load balancing in both directions and can apply
            the same algorithm to ensure that packets associated with the same flow use
            the same SFI regardless of the direction of travel.<a href="#section-8.9.1-7" class="pilcrow">¶</a></p>
<div id="section-8.9.1-8">
<pre class="sourcecode">
   SFP13:  RD = 198.51.100.1/113, SPI = 27,
         Assoc-Type = 1, Assoc-RD = 198.51.100.1/112, Assoc-SPI = 26,
          [SI = 255, SFT = 43, RD = 192.0.2.3/11],
          [SI = 254, SFT = 42, {RD = 192.0.2.2/11,
                                     192.0.2.2/12,
                                     192.0.2.2/13 }],
          [SI = 253, SFT = 41, RD = 192.0.2.1/11]
</pre><a href="#section-8.9.1-8" class="pilcrow">¶</a>
</div>
<p id="section-8.9.1-9">How an SFF knows that an attached SFI is stateful is out of the scope of this
            document.  It is assumed that this will form part of the process by which
            SFIs are registered as local to SFFs.  <a href="#stateful" class="xref">Section 7.2</a> provides
            additional observations about the coordination of the use of stateful SFIs
            in the case of bidirectional SFPs.<a href="#section-8.9.1-9" class="pilcrow">¶</a></p>
<p id="section-8.9.1-10">In general, the problems of load balancing and the selection of the same SFIs
            in both directions of a bidirectional SFP can be addressed by using sufficiently
            precisely specified SFPs (specifying the exact SFIs to use) and suitable
            programming of the classifiers at each end of the SFPs to make sure that the
            matching pair of SFPs are used.<a href="#section-8.9.1-10" class="pilcrow">¶</a></p>
</section>
</div>
<div id="stateeg1pll">
<section id="section-8.9.2">
          <h4 id="name-parallel-end-to-end-sfps-wi">
<a href="#section-8.9.2" class="section-number selfRef">8.9.2. </a><a href="#name-parallel-end-to-end-sfps-wi" class="section-name selfRef">Parallel End-to-End SFPs with Shared SFF</a>
          </h4>
<p id="section-8.9.2-1">The mechanism described in <a href="#stateegsff" class="xref">Section 8.9.1</a> might not be desirable because of
            the functional assumptions it places on SFF2 to be able to load balance with suitable flow
            identification, stability, and equality in both directions.  Instead, it may be desirable
            to place the responsibility for flow classification in the classifier and let it determine
            load balancing with the implied choice of SFIs.<a href="#section-8.9.2-1" class="pilcrow">¶</a></p>
<p id="section-8.9.2-2">Consider the network graph as shown in <a href="#egsfffig" class="xref">Figure 12</a> and with the same set of
            SFIRs as listed in <a href="#stateegsff" class="xref">Section 8.9.1</a>.
     In this case, the controller could specify
            three forward SFPs with their corresponding associated reverse SFPs.  Each bidirectional
            pair of SFPs uses a different SFI for the SF of Type 42.  The controller can instruct the
            classifier how to place traffic on the three bidirectional SFPs,
     or it can treat them as a group,
            leaving the classifier responsible for balancing the load.<a href="#section-8.9.2-2" class="pilcrow">¶</a></p>
<div id="section-8.9.2-3">
<pre class="sourcecode">
   SFP14:  RD = 198.51.100.1/114, SPI = 28,
         Assoc-Type = 1, Assoc-RD = 198.51.100.1/117, Assoc-SPI = 31,
          [SI = 255, SFT = 41, RD = 192.0.2.1/11],
          [SI = 254, SFT = 42, RD = 192.0.2.2/11],
          [SI = 253, SFT = 43, RD = 192.0.2.3/11]

   SFP15:  RD = 198.51.100.1/115, SPI = 29,
         Assoc-Type = 1, Assoc-RD = 198.51.100.1/118, Assoc-SPI = 32,
          [SI = 255, SFT = 41, RD = 192.0.2.1/11],
          [SI = 254, SFT = 42, RD = 192.0.2.2/12],
          [SI = 253, SFT = 43, RD = 192.0.2.3/11]

   SFP16:  RD = 198.51.100.1/116, SPI = 30,
         Assoc-Type = 1, Assoc-RD = 198.51.100.1/119, Assoc-SPI = 33,
          [SI = 255, SFT = 41, RD = 192.0.2.1/11],
          [SI = 254, SFT = 42, RD = 192.0.2.2/13],
          [SI = 253, SFT = 43, RD = 192.0.2.3/11]

   SFP17:  RD = 198.51.100.1/117, SPI = 31,
         Assoc-Type = 1, Assoc-RD = 198.51.100.1/114, Assoc-SPI = 28,
          [SI = 255, SFT = 43, RD = 192.0.2.3/11],
          [SI = 254, SFT = 42, RD = 192.0.2.2/11],
          [SI = 253, SFT = 41, RD = 192.0.2.1/11]

   SFP18:  RD = 198.51.100.1/118, SPI = 32,
         Assoc-Type = 1, Assoc-RD = 198.51.100.1/115, Assoc-SPI = 29,
          [SI = 255, SFT = 43, RD = 192.0.2.3/11],
          [SI = 254, SFT = 42, RD = 192.0.2.2/12],
          [SI = 253, SFT = 41, RD = 192.0.2.1/11]

   SFP19:  RD = 198.51.100.1/119, SPI = 33,
         Assoc-Type = 1, Assoc-RD = 198.51.100.1/116, Assoc-SPI = 30,
          [SI = 255, SFT = 43, RD = 192.0.2.3/11],
          [SI = 254, SFT = 42, RD = 192.0.2.2/13],
          [SI = 253, SFT = 41, RD = 192.0.2.1/11]
</pre><a href="#section-8.9.2-3" class="pilcrow">¶</a>
</div>
</section>
</div>
<div id="stateeg2pll">
<section id="section-8.9.3">
          <h4 id="name-parallel-end-to-end-sfps-wit">
<a href="#section-8.9.3" class="section-number selfRef">8.9.3. </a><a href="#name-parallel-end-to-end-sfps-wit" class="section-name selfRef">Parallel End-to-End SFPs with Separate SFFs</a>
          </h4>
<p id="section-8.9.3-1">While the examples in Sections <a href="#stateegsff" class="xref">8.9.1</a> and <a href="#stateeg1pll" class="xref">8.9.2</a>
            place the choice of SFI as subtended from the same SFF, it is also possible that the
            SFIs are each subtended from a different SFF, as shown in <a href="#eg2pllfig" class="xref">Figure 13</a>.
            In this case, it is harder to coordinate the choices for forward and reverse paths
            without some form of coordination between SFF1 and SFF3.  Therefore, it would be
            normal to consider end-to-end parallel SFPs, as described in <a href="#stateeg1pll" class="xref">Section 8.9.2</a>.<a href="#section-8.9.3-1" class="pilcrow">¶</a></p>
<span id="name-second-example-with-paralle"></span><div id="eg2pllfig">
<figure id="figure-13">
            <div class="artwork art-text alignLeft" id="section-8.9.3-2.1">
<pre>
                                     ------
                                    | SFIa |
                                    |SFT=42|
                                     ------
                      ------           |
                     | SFI  |      ---------
                     |SFT=41|     |   SFF5  |
                      ------    ..|192.0.2.5|..
                        |     ..:  ---------  :..
                    ---------.:                 :.---------
      ----------   |   SFF1  |     ---------     |   SFF3  |
 --&gt; |          |..|192.0.2.1|....|   SFF6  |....|192.0.2.3| --&gt;
 --&gt; |Classifier|   ---------:    |192.0.2.6|    :---------
     |          |            :     ---------     :    |
      ----------             :         |         :  ------
                             :       ------      : | SFI  |
                             :..    | SFIb |   ..: |SFT=43|
                               :..  |SFT=42| ..:    ------
                                 :   ------  :
                                 :.---------.:
                                  |   SFF7  |
                                  |192.0.2.7|
                                   ---------
                                       |
                                     ------
                                    | SFIc |
                                    |SFT=42|
                                     ------
</pre>
</div>
<figcaption><a href="#figure-13" class="selfRef">Figure 13</a>:
<a href="#name-second-example-with-paralle" class="selfRef">Second Example with Parallel End-to-End SFPs</a>
            </figcaption></figure>
</div>
<p id="section-8.9.3-3">In this case, five SFIRs are advertised as follows:<a href="#section-8.9.3-3" class="pilcrow">¶</a></p>
<div id="section-8.9.3-4">
<pre class="sourcecode">
   RD = 192.0.2.1/11, SFT = 41
   RD = 192.0.2.5/11, SFT = 42  (for SFIa)
   RD = 192.0.2.6/11, SFT = 42  (for SFIb)
   RD = 192.0.2.7/11, SFT = 42  (for SFIc)
   RD = 192.0.2.3/11, SFT = 43
</pre><a href="#section-8.9.3-4" class="pilcrow">¶</a>
</div>
<p id="section-8.9.3-5">In this case, the controller could specify three forward SFPs with their corresponding
            associated reverse SFPs.  Each bidirectional pair of SFPs uses a different SFF and SFI
            for the middle hop (for an SF of Type 42).  The controller can instruct the classifier how
            to place traffic on the three bidirectional SFPs, or it can treat them as a group, leaving
            the classifier responsible for balancing the load.<a href="#section-8.9.3-5" class="pilcrow">¶</a></p>
<div id="section-8.9.3-6">
<pre class="sourcecode">
   SFP20:  RD = 198.51.100.1/120, SPI = 34,
         Assoc-Type = 1, Assoc-RD = 198.51.100.1/123, Assoc-SPI = 37,
          [SI = 255, SFT = 41, RD = 192.0.2.1/11],
          [SI = 254, SFT = 42, RD = 192.0.2.5/11],
          [SI = 253, SFT = 43, RD = 192.0.2.3/11]

   SFP21:  RD = 198.51.100.1/121, SPI = 35,
         Assoc-Type = 1, Assoc-RD = 198.51.100.1/124, Assoc-SPI = 38,
          [SI = 255, SFT = 41, RD = 192.0.2.1/11],
          [SI = 254, SFT = 42, RD = 192.0.2.6/11],
          [SI = 253, SFT = 43, RD = 192.0.2.3/11]

   SFP22:  RD = 198.51.100.1/122, SPI = 36,
         Assoc-Type = 1, Assoc-RD = 198.51.100.1/125, Assoc-SPI = 39,
          [SI = 255, SFT = 41, RD = 192.0.2.1/11],
          [SI = 254, SFT = 42, RD = 192.0.2.7/11],
          [SI = 253, SFT = 43, RD = 192.0.2.3/11]

   SFP23:  RD = 198.51.100.1/123, SPI = 37,
         Assoc-Type = 1, Assoc-RD = 198.51.100.1/120, Assoc-SPI = 34,
          [SI = 255, SFT = 43, RD = 192.0.2.3/11],
          [SI = 254, SFT = 42, RD = 192.0.2.5/11],
          [SI = 253, SFT = 41, RD = 192.0.2.1/11]

   SFP24:  RD = 198.51.100.1/124, SPI = 38,
         Assoc-Type = 1, Assoc-RD = 198.51.100.1/121, Assoc-SPI = 35,
          [SI = 255, SFT = 43, RD = 192.0.2.3/11],
          [SI = 254, SFT = 42, RD = 192.0.2.6/11],
          [SI = 253, SFT = 41, RD = 192.0.2.1/11]

   SFP25:  RD = 198.51.100.1/125, SPI = 39,
         Assoc-Type = 1, Assoc-RD = 198.51.100.1/122, Assoc-SPI = 36,
          [SI = 255, SFT = 43, RD = 192.0.2.3/11],
          [SI = 254, SFT = 42, RD = 192.0.2.7/11],
          [SI = 253, SFT = 41, RD = 192.0.2.1/11]
</pre><a href="#section-8.9.3-6" class="pilcrow">¶</a>
</div>
</section>
</div>
<div id="stateegpllchc">
<section id="section-8.9.4">
          <h4 id="name-parallel-sfps-downstream-of">
<a href="#section-8.9.4" class="section-number selfRef">8.9.4. </a><a href="#name-parallel-sfps-downstream-of" class="section-name selfRef">Parallel SFPs Downstream of the Choice</a>
          </h4>
<p id="section-8.9.4-1">The mechanism of parallel SFPs demonstrated in <a href="#stateeg2pll" class="xref">Section 8.9.3</a>
            is perfectly functional and may be practical in many environments.  However,
            there may be scaling concerns because of the large amount of state (knowledge
            of SFPs -- i.e., SFPR advertisements retained) if there is a very large number
            of possible SFIs (for example, tens of instances of the same stateful SF) or
            if there are multiple choices of stateful SF along a path.  This situation may
            be mitigated using SFP fragments that are combined to form the end-to-end SFPs.<a href="#section-8.9.4-1" class="pilcrow">¶</a></p>
<p id="section-8.9.4-2">The example presented here is necessarily simplistic but should convey the
            basic principle.  The example presented in <a href="#eg2pllchcfig" class="xref">Figure 14</a> is
            similar to that in <a href="#stateeg2pll" class="xref">Section 8.9.3</a> but with an additional first
            hop.<a href="#section-8.9.4-2" class="pilcrow">¶</a></p>
<span id="name-example-with-parallel-sfps-"></span><div id="eg2pllchcfig">
<figure id="figure-14">
            <div class="artwork art-text alignLeft" id="section-8.9.4-3.1">
<pre>
                                          ------
                                         | SFIa |
                                         |SFT=43|
                                          ------
               ------      ------           |
              | SFI  |    | SFI  |      ---------
              |SFT=41|    |SFT=42|     |   SFF5  |
               ------      ------    ..|192.0.2.5|..
                 |           |     ..:  ---------  :..
             ---------   ---------.:                 :.---------
    ------  |   SFF1  | |   SFF2  |     ---------     |   SFF3  |
--&gt;|Class-|.|192.0.2.1|.|192.0.2.2|....|   SFF6  |....|192.0.2.3|--&gt;
--&gt;| ifier|  ---------   ---------:    |192.0.2.6|    :---------
    ------                        :     ---------     :    |
                                  :         |         :  ------
                                  :       ------      : | SFI  |
                                  :..    | SFIb |   ..: |SFT=44|
                                    :..  |SFT=43| ..:    ------
                                      :   ------  :
                                      :.---------.:
                                       |   SFF7  |
                                       |192.0.2.7|
                                        ---------
                                            |
                                          ------
                                         | SFIc |
                                         |SFT=43|
                                          ------
</pre>
</div>
<figcaption><a href="#figure-14" class="selfRef">Figure 14</a>:
<a href="#name-example-with-parallel-sfps-" class="selfRef">Example with Parallel SFPs Downstream of Choice</a>
            </figcaption></figure>
</div>
<p id="section-8.9.4-4">The six SFIs are advertised as follows:<a href="#section-8.9.4-4" class="pilcrow">¶</a></p>
<div id="section-8.9.4-5">
<pre class="sourcecode">
   RD = 192.0.2.1/11, SFT = 41
   RD = 192.0.2.2/11, SFT = 42
   RD = 192.0.2.5/11, SFT = 43  (for SFIa)
   RD = 192.0.2.6/11, SFT = 43  (for SFIb)
   RD = 192.0.2.7/11, SFT = 43  (for SFIc)
   RD = 192.0.2.3/11, SFT = 44
</pre><a href="#section-8.9.4-5" class="pilcrow">¶</a>
</div>
<p id="section-8.9.4-6">SFF2 is the point at which a load-balancing choice must be made.  So "tail-end"
            SFPs are constructed as follows.  Each takes in a different SFF that provides
            access to an SF of Type 43.<a href="#section-8.9.4-6" class="pilcrow">¶</a></p>
<div id="section-8.9.4-7">
<pre class="sourcecode">
   SFP26:  RD = 198.51.100.1/126, SPI = 40,
         Assoc-Type = 1, Assoc-RD = 198.51.100.1/130, Assoc-SPI = 44,
          [SI = 255, SFT = 43, RD = 192.0.2.5/11],
          [SI = 254, SFT = 44, RD = 192.0.2.3/11]

   SFP27:  RD = 198.51.100.1/127, SPI = 41,
         Assoc-Type = 1, Assoc-RD = 198.51.100.1/131, Assoc-SPI = 45,
          [SI = 255, SFT = 43, RD = 192.0.2.6/11],
          [SI = 254, SFT = 44, RD = 192.0.2.3/11]

   SFP28:  RD = 198.51.100.1/128, SPI = 42,
         Assoc-Type = 1, Assoc-RD = 198.51.100.1/132, Assoc-SPI = 46,
          [SI = 255, SFT = 43, RD = 192.0.2.7/11],
          [SI = 254, SFT = 44, RD = 192.0.2.3/11]
</pre><a href="#section-8.9.4-7" class="pilcrow">¶</a>
</div>
<p id="section-8.9.4-8">Now an end-to-end SFP with load-balancing choice can be constructed as follows.
            The choice made by SFF2 is expressed in terms of entering one of the three
            "tail-end" SFPs.<a href="#section-8.9.4-8" class="pilcrow">¶</a></p>
<div id="section-8.9.4-9">
<pre class="sourcecode">
   SFP29:  RD = 198.51.100.1/129, SPI = 43,
          [SI = 255, SFT = 41, RD = 192.0.2.1/11],
          [SI = 254, SFT = 42, RD = 192.0.2.2/11],
          [SI = 253, {SFT = 1, RD = {SPI=40, SI=255, Rsv=0},
                               RD = {SPI=41, SI=255, Rsv=0},
                               RD = {SPI=42, SI=255, Rsv=0} } ]
</pre><a href="#section-8.9.4-9" class="pilcrow">¶</a>
</div>
<p id="section-8.9.4-10">Now, despite the load-balancing choice being made elsewhere than at the initial
            classifier, it is possible for the reverse SFPs to be well constructed without
            any ambiguity.  The three reverse paths appear as follows.<a href="#section-8.9.4-10" class="pilcrow">¶</a></p>
<div id="section-8.9.4-11">
<pre class="sourcecode">
   SFP30:  RD = 198.51.100.1/130, SPI = 44,
         Assoc-Type = 1, Assoc-RD = 198.51.100.1/126, Assoc-SPI = 40,
          [SI = 255, SFT = 44, RD = 192.0.2.4/11],
          [SI = 254, SFT = 43, RD = 192.0.2.5/11],
          [SI = 253, SFT = 42, RD = 192.0.2.2/11],
          [SI = 252, SFT = 41, RD = 192.0.2.1/11]

   SFP31:  RD = 198.51.100.1/131, SPI = 45,
         Assoc-Type = 1, Assoc-RD = 198.51.100.1/127, Assoc-SPI = 41,
          [SI = 255, SFT = 44, RD = 192.0.2.4/11],
          [SI = 254, SFT = 43, RD = 192.0.2.6/11],
          [SI = 253, SFT = 42, RD = 192.0.2.2/11],
          [SI = 252, SFT = 41, RD = 192.0.2.1/11]

   SFP32:  RD = 198.51.100.1/132, SPI = 46,
         Assoc-Type = 1, Assoc-RD = 198.51.100.1/128, Assoc-SPI = 42,
          [SI = 255, SFT = 44, RD = 192.0.2.4/11],
          [SI = 254, SFT = 43, RD = 192.0.2.7/11],
          [SI = 253, SFT = 42, RD = 192.0.2.2/11],
          [SI = 252, SFT = 41, RD = 192.0.2.1/11]
</pre><a href="#section-8.9.4-11" class="pilcrow">¶</a>
</div>
</section>
</div>
</section>
</div>
<div id="v6samples">
<section id="section-8.10">
        <h3 id="name-examples-using-ipv6-address">
<a href="#section-8.10" class="section-number selfRef">8.10. </a><a href="#name-examples-using-ipv6-address" class="section-name selfRef">Examples Using IPv6 Addressing</a>
        </h3>
<p id="section-8.10-1">This section provides several examples using IPv6 addressing.  As
          will be seen from the examples, there is nothing special or clever
          about using IPv6 addressing rather than IPv4 addressing.<a href="#section-8.10-1" class="pilcrow">¶</a></p>
<p id="section-8.10-2">The reference network for these IPv6 examples is based on that described
          at the top of <a href="#example" class="xref">Section 8</a> and shown in <a href="#examplefig" class="xref">Figure 11</a>.<a href="#section-8.10-2" class="pilcrow">¶</a></p>
<p id="section-8.10-3">Assume we have a service function overlay network with four SFFs (SFF1, SFF3, SFF3, and SFF4).
          The SFFs have addresses in the underlay network as follows:<a href="#section-8.10-3" class="pilcrow">¶</a></p>
<div id="section-8.10-4">
<pre class="sourcecode">
      SFF1 2001:db8::192:0:2:1
      SFF2 2001:db8::192:0:2:2
      SFF3 2001:db8::192:0:2:3
      SFF4 2001:db8::192:0:2:4
</pre><a href="#section-8.10-4" class="pilcrow">¶</a>
</div>
<p id="section-8.10-5">Each SFF provides access to some SFIs from the four service function types SFT=41, SFT=42,
          SFT=43, and SFT=44, just as before:<a href="#section-8.10-5" class="pilcrow">¶</a></p>
<div id="section-8.10-6">
<pre class="sourcecode">
      SFF1 SFT=41 and SFT=42
      SFF2 SFT=41 and SFT=43
      SFF3 SFT=42 and SFT=44
      SFF4 SFT=43 and SFT=44
</pre><a href="#section-8.10-6" class="pilcrow">¶</a>
</div>
<p id="section-8.10-7">The service function network also contains a controller with address 2001:db8::198:51:100:1.<a href="#section-8.10-7" class="pilcrow">¶</a></p>
<p id="section-8.10-8">This example service function overlay network is shown in <a href="#eg6fig" class="xref">Figure 15</a>.<a href="#section-8.10-8" class="pilcrow">¶</a></p>
<span id="name-example-service-function-ove"></span><div id="eg6fig">
<figure id="figure-15">
          <div class="artwork art-text alignLeft" id="section-8.10-9.1">
<pre>
       ------------------------
      |       Controller       |
      | 2001:db8::198:51:100:1 |
       ------------------------
                    ------     ------        ------     ------
                   | SFI  |   | SFI  |      | SFI  |   | SFI  |
                   |SFT=41|   |SFT=42|      |SFT=41|   |SFT=43|
                    ------     ------        ------     ------
                         \     /                  \     /
                    -------------------     -------------------
                   |       SFF1        |   |       SFF2        |
                   |2001:db8::192:0:2:1|   |2001:db8::192:0:2:2|
                    -------------------     -------------------
               ----------
   Packet --&gt; |          |                                    --&gt;
   Flows  --&gt; |Classifier|                                    --&gt;Dest
              |          |                                    --&gt;
               ----------
                   -------------------      -------------------
                  |       SFF3        |    |       SFF4        |
                  |2001:db8::192:0:2:3|    |2001:db8::192:0:2:4|
                   -------------------      -------------------
                         /     \                  /     \
                    ------     ------        ------     ------
                   | SFI  |   | SFI  |      | SFI  |   | SFI  |
                   |SFT=42|   |SFT=44|      |SFT=43|   |SFT=44|
                    ------     ------        ------     ------
</pre>
</div>
<figcaption><a href="#figure-15" class="selfRef">Figure 15</a>:
<a href="#name-example-service-function-ove" class="selfRef">Example Service Function Overlay Network</a>
          </figcaption></figure>
</div>
<p id="section-8.10-10">The SFFs advertise routes to the SFIs they support.  These advertisements
       contain RDs that are set according to the network operator's
       configuration model.  Note that in an IPv6 network, the RD is not large enough to
       contain the full IPv6 address, as only six octets are available. So, in all of these IPv6
       examples, we use RDs of Type 1 such that the available six octets are partitioned as four
       octets for an IPv4 address of the advertising SFF, and two octets that are a local index
       of the SFI.  Furthermore, we have chosen an IPv6 addressing scheme so that the low-order
       four octets of the IPv6 address match an IPv4 address of the advertising node.  This scheme
       is chosen purely for convenience of documentation, and an operator is totally free to use
       any other scheme so long as it conforms to the definitions of SFIR and
       SFPR in Sections
       <a href="#sfiRoutes" class="xref">3.1</a> and <a href="#sfpRoutes" class="xref">3.2</a>.<a href="#section-8.10-10" class="pilcrow">¶</a></p>
<p id="section-8.10-11">Observant readers will notice that this makes the BGP advertisements shown in these examples
       exactly the same as in the previous examples.  All that is different is that the advertising
       SFFs and controller have IPv6 addresses.<a href="#section-8.10-11" class="pilcrow">¶</a></p>
<p id="section-8.10-12">Thus, we see the following SFIRs advertised.<a href="#section-8.10-12" class="pilcrow">¶</a></p>
<p id="section-8.10-13">The SFFs advertise routes to the SFIs they support.  So we see the following
          SFIRs:<a href="#section-8.10-13" class="pilcrow">¶</a></p>
<div id="section-8.10-14">
<pre class="sourcecode">
      RD = 192.0.2.1/1, SFT = 41
      RD = 192.0.2.1/2, SFT = 42
      RD = 192.0.2.2/1, SFT = 41
      RD = 192.0.2.2/2, SFT = 43
      RD = 192.0.2.3/7, SFT = 42
      RD = 192.0.2.3/8, SFT = 44
      RD = 192.0.2.4/5, SFT = 43
      RD = 192.0.2.4/6, SFT = 44
</pre><a href="#section-8.10-14" class="pilcrow">¶</a>
</div>
<p id="section-8.10-15">Note that the addressing used for communicating between SFFs is taken
          from the tunnel encapsulation attribute of the SFIR and not from the SFIR-RD.<a href="#section-8.10-15" class="pilcrow">¶</a></p>
<div id="eg6explicit">
<section id="section-8.10.1">
          <h4 id="name-example-explicit-sfp-with-no">
<a href="#section-8.10.1" class="section-number selfRef">8.10.1. </a><a href="#name-example-explicit-sfp-with-no" class="section-name selfRef">Example Explicit SFP with No Choices</a>
          </h4>
<p id="section-8.10.1-1">Consider the following SFPR similar to that in <a href="#exampleexplicit" class="xref">Section 8.1</a>.<a href="#section-8.10.1-1" class="pilcrow">¶</a></p>
<div id="section-8.10.1-2">
<pre class="sourcecode">
      SFP1:  RD = 198.51.100.1/101, SPI = 15,
             [SI = 255, SFT = 41, RD = 192.0.2.1/1],
             [SI = 250, SFT = 43, RD = 192.0.2.2/2]
</pre><a href="#section-8.10.1-2" class="pilcrow">¶</a>
</div>
<p id="section-8.10.1-3">The SFP consists of an SF of Type 41 located at SFF1, followed by an SF
             of Type 43 located at SFF2.  This path is fully explicit, and each SFF is
             offered no choice in forwarding a packet along the path.<a href="#section-8.10.1-3" class="pilcrow">¶</a></p>
<p id="section-8.10.1-4">SFF1 will receive packets on the path from the classifier and will identify the path
             from the SPI (15).  The initial SI will be 255, and so SFF1 will deliver the packets to the
             SFI for SFT 41.<a href="#section-8.10.1-4" class="pilcrow">¶</a></p>
<p id="section-8.10.1-5">When the packets are returned to SFF1 by the SFI, the SI will be
   decreased to 250 for the next hop.
              SFF1 has no flexibility in the choice of SFF to support the next-hop SFI and will forward
              the packet to SFF2, which will send the packets to the SFI that supports SFT 43 before
              forwarding the packets to their destinations.<a href="#section-8.10.1-5" class="pilcrow">¶</a></p>
</section>
</div>
<div id="eg6choice">
<section id="section-8.10.2">
          <h4 id="name-example-sfp-with-choice-of-sf">
<a href="#section-8.10.2" class="section-number selfRef">8.10.2. </a><a href="#name-example-sfp-with-choice-of-sf" class="section-name selfRef">Example SFP with Choice of SFIs</a>
          </h4>
<div id="section-8.10.2-1">
<pre class="sourcecode">
      SFP2:  RD = 198.51.100.1/102, SPI = 16,
             [SI = 255, SFT = 41, RD = 192.0.2.1/1],
             [SI = 250, SFT = 43, {RD = 192.0.2.2/2,
                                   RD = 192.0.2.4/5 } ]
</pre><a href="#section-8.10.2-1" class="pilcrow">¶</a>
</div>
<p id="section-8.10.2-2">In this example, like that in <a href="#examplechoice" class="xref">Section 8.2</a>, the path also consists of an
             SF of Type 41 located at SFF1, and this is followed by an SF of
      Type 43; but in this case, the
             SI = 250 contains a choice between the SFI located at SFF2 and the SFI located at SFF4.<a href="#section-8.10.2-2" class="pilcrow">¶</a></p>
<p id="section-8.10.2-3">SFF1 will receive packets on the path from the classifier and will identify the path
             from the SPI (16).  The initial SI will be 255, and so SFF1 will deliver the packets to the
             SFI for SFT 41.<a href="#section-8.10.2-3" class="pilcrow">¶</a></p>
<p id="section-8.10.2-4">When the packets are returned to SFF1 by the SFI, the SI will be decreased to 250 for
              the next hop.  SFF1 now has a choice of next-hop SFFs to execute the next hop in the path.
              It can either forward packets to SFF2 or SFF4 to execute a function of Type 43.  It uses
              its local load-balancing algorithm to make this choice.  The chosen SFF will send the
              packets to the SFI that supports SFT 43 before forwarding the packets to their
              destinations.<a href="#section-8.10.2-4" class="pilcrow">¶</a></p>
</section>
</div>
<div id="eg6open">
<section id="section-8.10.3">
          <h4 id="name-example-sfp-with-open-choice">
<a href="#section-8.10.3" class="section-number selfRef">8.10.3. </a><a href="#name-example-sfp-with-open-choice" class="section-name selfRef">Example SFP with Open Choice of SFIs</a>
          </h4>
<div id="section-8.10.3-1">
<pre class="sourcecode">
      SFP3:  RD = 198.51.100.1/103, SPI = 17,
             [SI = 255, SFT = 41, RD = 192.0.2.1/1],
             [SI = 250, SFT = 44, RD = 0]
</pre><a href="#section-8.10.3-1" class="pilcrow">¶</a>
</div>
<p id="section-8.10.3-2">In this example, like that in <a href="#exampleopen" class="xref">Section 8.3</a>, the path also consists of an
             SF of Type 41 located at SFF1, and this is followed by an SI with an RD of zero and SF of
             Type 44.  This means that a choice can be made between any SFF that supports an SFI of
             Type 44.<a href="#section-8.10.3-2" class="pilcrow">¶</a></p>
<p id="section-8.10.3-3">SFF1 will receive packets on the path from the classifier and will identify the path
             from the SPI (17).  The initial SI will be 255, and so SFF1 will deliver the packets to the
             SFI for SFT 41.<a href="#section-8.10.3-3" class="pilcrow">¶</a></p>
<p id="section-8.10.3-4">When the packets are returned to SFF1 by the SFI, the SI will be decreased to 250 for
              the next hop.  SFF1 now has a free choice of next-hop SFFs to execute the next hop in the
              path, selecting between all SFFs that support SFs of Type 44.  Looking at the SFIRs it
              has received, SFF1 knows that SF Type 44 is supported by SFF3 and SFF4.  SFF1 uses its
              local load-balancing algorithm to make this choice.  The chosen SFF will send the packets
              to the SFI that supports SFT 44 before forwarding the packets to their destinations.<a href="#section-8.10.3-4" class="pilcrow">¶</a></p>
</section>
</div>
<div id="eg6sft">
<section id="section-8.10.4">
          <h4 id="name-example-sfp-with-choice-of-sft">
<a href="#section-8.10.4" class="section-number selfRef">8.10.4. </a><a href="#name-example-sfp-with-choice-of-sft" class="section-name selfRef">Example SFP with Choice of SFTs</a>
          </h4>
<div id="section-8.10.4-1">
<pre class="sourcecode">
      SFP4:  RD = 198.51.100.1/104, SPI = 18,
             [SI = 255, SFT = 41, RD = 192.0.2.1/1],
             [SI = 250, {SFT = 43, RD = 192.0.2.2/2,
                         SFT = 44, RD = 192.0.2.3/8 } ]
</pre><a href="#section-8.10.4-1" class="pilcrow">¶</a>
</div>
<p id="section-8.10.4-2">This example, similar to that in <a href="#examplesft" class="xref">Section 8.4</a>, provides a choice of SF type
             in the second hop in the path.  The SI of 250 indicates a choice between SF Type 43 located
             through SF2 and SF Type 44 located at SF3.<a href="#section-8.10.4-2" class="pilcrow">¶</a></p>
<p id="section-8.10.4-3">SFF1 will receive packets on the path from the classifier and will identify the path
             from the SPI (18).  The initial SI will be 255, and so SFF1 will deliver the packets to the
             SFI for SFT 41.<a href="#section-8.10.4-3" class="pilcrow">¶</a></p>
<p id="section-8.10.4-4">When the packets are returned to SFF1 by the SFI, the SI will be decreased to 250 for
             the next hop.  SFF1 now has a free choice of next-hop SFFs to execute the next hop in the
             path, selecting between all SFFs that support an SF of Type 43
      and SFF3, which supports an
             SF of Type 44.  These may be completely different functions that are to be executed dependent
             on specific conditions, or they may be similar functions identified with different type
             identifiers (such as firewalls from different vendors).  SFF1
      uses its local policy and load-balancing algorithm to make this
      choice, and it may use additional information passed back from
             the local SFI to help inform its selection.  The chosen SFF will send the packets to the SFI
             that supports the chosen SFT before forwarding the packets to their destinations.<a href="#section-8.10.4-4" class="pilcrow">¶</a></p>
</section>
</div>
</section>
</div>
</section>
</div>
<div id="security">
<section id="section-9">
      <h2 id="name-security-considerations">
<a href="#section-9" class="section-number selfRef">9. </a><a href="#name-security-considerations" class="section-name selfRef">Security Considerations</a>
      </h2>
<p id="section-9-1">The mechanisms in this document use BGP for the control plane.
       Hence, techniques such as those discussed in <span>[<a href="#RFC5925" class="xref">RFC5925</a>]</span>
       can be used to help authenticate BGP sessions and, thus, the messages
       between BGP peers, making it harder to spoof updates (which
       could be used to install bogus SFPs or advertise false SIs)
       or withdrawals.<a href="#section-9-1" class="pilcrow">¶</a></p>
<p id="section-9-2">Further discussion of security considerations for BGP may be found in
       the BGP specification itself <span>[<a href="#RFC4271" class="xref">RFC4271</a>]</span> and the security
       analysis for BGP <span>[<a href="#RFC4272" class="xref">RFC4272</a>]</span>.





<span>[<a href="#RFC5925" class="xref">RFC5925</a>]</span> contains a discussion of the inappropriateness of the TCP
MD5 signature option for protecting BGP sessions.  <span>[<a href="#RFC6952" class="xref">RFC6952</a>]</span> includes
an analysis of BGP keying and authentication issues.<a href="#section-9-2" class="pilcrow">¶</a></p>
<p id="section-9-3">Additionally, this document depends on other documents that specify BGP
       Multiprotocol Extensions and the documents that define the attributes that
       are carried by BGP UPDATEs of the SFC AFI/SAFI.  <span>[<a href="#RFC4760" class="xref">RFC4760</a>]</span>
       observes that the use of AFI/SAFI does not change the underlying security issues
       inherent in the existing BGP.  Relevant additional security measures are
       considered in <span>[<a href="#RFC9012" class="xref">RFC9012</a>]</span>.<a href="#section-9-3" class="pilcrow">¶</a></p>
<p id="section-9-4">This document does not fundamentally change the security behavior of BGP
       deployments, which depend considerably on the network operator's perception
       of risk in their network.  It may be observed that the application of the
       mechanisms described in this document is scoped to a single domain, as implied
       by <span>[<a href="#RFC8300" class="xref">RFC8300</a>]</span> and noted in <a href="#funcover" class="xref">Section 2.1</a> of this document.
       Applicability of BGP within a single domain may enable a network operator to make
       easier and more consistent decisions about what security measures to apply, and the
       domain boundary, which BGP enforces by definition, provides a safeguard that prevents
       leakage of SFC programming in either direction at the boundary.<a href="#section-9-4" class="pilcrow">¶</a></p>
<p id="section-9-5">Service function chaining provides a significant attack opportunity; packets can be diverted
       from their normal paths through the network, packets can be made to execute unexpected functions, and
       the functions that are instantiated in software can be subverted.  However, this specification
       does not change the existence of service function chaining, and security issues specific to
       service function chaining are covered in <span>[<a href="#RFC7665" class="xref">RFC7665</a>]</span> and
       <span>[<a href="#RFC8300" class="xref">RFC8300</a>]</span>.<a href="#section-9-5" class="pilcrow">¶</a></p>
<p id="section-9-6">This document defines a control plane for service function chaining.  Clearly, this provides
       an attack vector for a service function chaining system, as an attack on this control plane
       could be used to make the system misbehave.  Thus, the security of the BGP system is critically
       important to the security of the whole service function chaining system.  The control plane
       mechanisms are very similar to those used for BGP/MPLS IP VPNs as described in              
       <span>[<a href="#RFC4364" class="xref">RFC4364</a>]</span>, and so the security considerations in that document (Section <a href="https://www.rfc-editor.org/rfc/rfc4364#section-13" class="relref">13</a>)
       provide good guidance for securing service function chaining systems reliant on this specification.  Of particular
       relevance is the need to securely distinguish between messages intended for the control of
       different SFC overlays, which is similar to the need to distinguish between different VPNs.
       <span><a href="https://www.rfc-editor.org/rfc/rfc7432#section-19" class="relref">Section 19</a> of [<a href="#RFC7432" class="xref">RFC7432</a>]</span> also provides useful guidance on the use of BGP in a
       similar environment.<a href="#section-9-6" class="pilcrow">¶</a></p>
<p id="section-9-7">Note that a component of a service function chaining system that uses the procedures described in this document also
       requires communications between a controller and the service function chaining network elements (specifically the SFFs
       and classifiers).  This communication covers instructing the classifiers using BGP mechanisms (see
       <a href="#fspecclassy" class="xref">Section 7.4</a>); therefore, the use of BGP security is strongly recommended.  But it also
       covers other mechanisms for programming the classifier and instructing the SFFs and SFs (for
       example, to bind SFs to an SFF, and to cause the establishment of tunnels between SFFs).  This
       document does not cover these latter mechanisms, and so their security is out of scope, but it
       should be noted that these communications provide an attack vector on the service function chaining system, and so
       attention must be paid to ensuring that they are secure.<a href="#section-9-7" class="pilcrow">¶</a></p>
<p id="section-9-8">There is an intrinsic assumption in service function chaining systems that nodes that announce support for specific
       SFs actually offer those functions and that SFs are not, themselves, attacked or subverted.
       This is particularly important when the SFs are implemented as software that can be updated.
       Protection against this sort of concern forms part of the security of any service function chaining system and so is
       outside the scope of the control plane mechanisms described in this document.<a href="#section-9-8" class="pilcrow">¶</a></p>
<p id="section-9-9">Similarly, there is a vulnerability if a rogue or subverted controller announces SFPs, especially
       if that controller "takes over" an existing SFP and changes its contents.  This corresponds
       to a rogue BGP speaker entering a routing system, or even a Route Reflector becoming
       subverted.  Protection mechanisms, as above, include securing BGP sessions and protecting
       software loads on the controllers.<a href="#section-9-9" class="pilcrow">¶</a></p>
<p id="section-9-10">In an environment where there is concern that rogue controllers might be introduced to the
       network and inject false SFPRs or take over and change existing SFPRs, it is <span class="bcp14">RECOMMENDED</span> that
       each SFF and classifier be configured with the identities of authorized controllers.  Thus, the
       announcement of an SFPR by any other BGP peer would be rejected.<a href="#section-9-10" class="pilcrow">¶</a></p>
<p id="section-9-11">Lastly, note that <a href="#sfparules" class="xref">Section 3.2.2</a> makes two operational suggestions that have
       implications for the stability and security of the mechanisms described in this document:<a href="#section-9-11" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-9-12.1">That modifications to active SFPs not be made.<a href="#section-9-12.1" class="pilcrow">¶</a>
</li>
        <li class="normal" id="section-9-12.2">That SPIs not be immediately reused.<a href="#section-9-12.2" class="pilcrow">¶</a>
</li>
      </ul>
</section>
</div>
<div id="iana">
<section id="section-10">
      <h2 id="name-iana-considerations">
<a href="#section-10" class="section-number selfRef">10. </a><a href="#name-iana-considerations" class="section-name selfRef">IANA Considerations</a>
      </h2>
<div id="afisafi">
<section id="section-10.1">
        <h3 id="name-new-bgp-af-safi">
<a href="#section-10.1" class="section-number selfRef">10.1. </a><a href="#name-new-bgp-af-safi" class="section-name selfRef">New BGP AF/SAFI</a>
        </h3>
<p id="section-10.1-1">IANA maintains the "Address Family Numbers" registry.  IANA has assigned a new
          Address Family Number from the "Standards Action" range called "BGP SFC" (31), with this document as a reference.<a href="#section-10.1-1" class="pilcrow">¶</a></p>
<p id="section-10.1-2">IANA maintains the "Subsequent Address Family Identifiers (SAFI) Parameters" registry.  IANA
          has assigned a new SAFI value from the "Standards Action" range called "BGP SFC"
          (9), with this document as a reference.<a href="#section-10.1-2" class="pilcrow">¶</a></p>
</section>
</div>
<div id="ianasfpatt">
<section id="section-10.2">
        <h3 id="name-sfp-attribute-bgp-path-attr">
<a href="#section-10.2" class="section-number selfRef">10.2. </a><a href="#name-sfp-attribute-bgp-path-attr" class="section-name selfRef">"SFP attribute" BGP Path Attribute</a>
        </h3>
<p id="section-10.2-1">IANA maintains a registry of "Border Gateway Protocol (BGP) Parameters" with a subregistry of
          "BGP Path Attributes".  IANA has assigned a new Path attribute called "SFP attribute" with a value of 37 and with this document as a reference.<a href="#section-10.2-1" class="pilcrow">¶</a></p>
</section>
</div>
<div id="ianasftlv">
<section id="section-10.3">
        <h3 id="name-sfp-attribute-tlvs-registry">
<a href="#section-10.3" class="section-number selfRef">10.3. </a><a href="#name-sfp-attribute-tlvs-registry" class="section-name selfRef">"SFP Attribute TLVs" Registry</a>
        </h3>
<p id="section-10.3-1">IANA maintains a registry of "Border Gateway Protocol (BGP) Parameters".  IANA has created a new subregistry called the "SFP Attribute TLVs" registry.<a href="#section-10.3-1" class="pilcrow">¶</a></p>
<p id="section-10.3-2">Valid values are in the range 0 to 65535.<a href="#section-10.3-2" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-10.3-3.1">Values 0 and 65535 are marked "Reserved".<a href="#section-10.3-3.1" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-10.3-3.2">Values 1 through 65534 are to be assigned according to the "First Come
               First Served" policy <span>[<a href="#RFC8126" class="xref">RFC8126</a>]</span>.<a href="#section-10.3-3.2" class="pilcrow">¶</a>
</li>
        </ul>
<p id="section-10.3-4">This document is a reference for this registry.<a href="#section-10.3-4" class="pilcrow">¶</a></p>
<p id="section-10.3-5">The registry tracks:<a href="#section-10.3-5" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-10.3-6.1">Type<a href="#section-10.3-6.1" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-10.3-6.2">Name<a href="#section-10.3-6.2" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-10.3-6.3">Reference<a href="#section-10.3-6.3" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-10.3-6.4">Registration Date<a href="#section-10.3-6.4" class="pilcrow">¶</a>
</li>
        </ul>
<p id="section-10.3-7">The registry is initially populated as follows:<a href="#section-10.3-7" class="pilcrow">¶</a></p>
<span id="name-sfp-attribute-tlvs-subregis"></span><table class="center" id="table-1">
          <caption>
<a href="#table-1" class="selfRef">Table 1</a>:
<a href="#name-sfp-attribute-tlvs-subregis" class="selfRef">SFP Attribute TLVs Subregistry Initial Contents</a>
          </caption>
<thead>
            <tr>
              <th class="text-left" rowspan="1" colspan="1">Type</th>
              <th class="text-left" rowspan="1" colspan="1">Name</th>
              <th class="text-left" rowspan="1" colspan="1">Reference</th>
              <th class="text-left" rowspan="1" colspan="1">Registration Date</th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">1</td>
              <td class="text-left" rowspan="1" colspan="1">Association TLV</td>
              <td class="text-left" rowspan="1" colspan="1">RFC 9015</td>
              <td class="text-left" rowspan="1" colspan="1">2020-09-02</td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">2</td>
              <td class="text-left" rowspan="1" colspan="1">Hop TLV</td>
              <td class="text-left" rowspan="1" colspan="1">RFC 9015</td>
              <td class="text-left" rowspan="1" colspan="1">2020-09-02</td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">3</td>
              <td class="text-left" rowspan="1" colspan="1">SFT TLV</td>
              <td class="text-left" rowspan="1" colspan="1">RFC 9015</td>
              <td class="text-left" rowspan="1" colspan="1">2020-09-02</td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">4</td>
              <td class="text-left" rowspan="1" colspan="1">MPLS Swapping/Stacking</td>
              <td class="text-left" rowspan="1" colspan="1">RFC 9015</td>
              <td class="text-left" rowspan="1" colspan="1">2020-09-02</td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">5</td>
              <td class="text-left" rowspan="1" colspan="1">SFP Traversal With MPLS</td>
              <td class="text-left" rowspan="1" colspan="1">RFC 9015</td>
              <td class="text-left" rowspan="1" colspan="1">2020-09-02</td>
            </tr>
          </tbody>
        </table>
</section>
</div>
<div id="ianaassoc">
<section id="section-10.4">
        <h3 id="name-sfp-association-type-regist">
<a href="#section-10.4" class="section-number selfRef">10.4. </a><a href="#name-sfp-association-type-regist" class="section-name selfRef">"SFP Association Type" Registry</a>
        </h3>
<p id="section-10.4-1">IANA maintains a registry of "Border Gateway Protocol (BGP) Parameters".  IANA has created a new subregistry called the "SFP Association Type" registry.<a href="#section-10.4-1" class="pilcrow">¶</a></p>
<p id="section-10.4-2">Valid values are in the range 0 to 65535.<a href="#section-10.4-2" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-10.4-3.1">Values 0 and 65535 are marked "Reserved".<a href="#section-10.4-3.1" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-10.4-3.2">Values 1 through 65534 are assigned according to the "First Come
               First Served" policy <span>[<a href="#RFC8126" class="xref">RFC8126</a>]</span>.<a href="#section-10.4-3.2" class="pilcrow">¶</a>
</li>
        </ul>
<p id="section-10.4-4">This document is given as a reference for this registry.<a href="#section-10.4-4" class="pilcrow">¶</a></p>
<p id="section-10.4-5">The new registry tracks:<a href="#section-10.4-5" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-10.4-6.1">Association Type<a href="#section-10.4-6.1" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-10.4-6.2">Name<a href="#section-10.4-6.2" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-10.4-6.3">Reference<a href="#section-10.4-6.3" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-10.4-6.4">Registration Date<a href="#section-10.4-6.4" class="pilcrow">¶</a>
</li>
        </ul>
<p id="section-10.4-7">The registry should initially be populated as follows:<a href="#section-10.4-7" class="pilcrow">¶</a></p>
<span id="name-sfp-association-type-subreg"></span><table class="center" id="table-2">
          <caption>
<a href="#table-2" class="selfRef">Table 2</a>:
<a href="#name-sfp-association-type-subreg" class="selfRef">SFP Association Type Subregistry Initial Contents</a>
          </caption>
<thead>
            <tr>
              <th class="text-left" rowspan="1" colspan="1">Association Type</th>
              <th class="text-left" rowspan="1" colspan="1">Name</th>
              <th class="text-left" rowspan="1" colspan="1">Reference</th>
              <th class="text-left" rowspan="1" colspan="1">Date</th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">1</td>
              <td class="text-left" rowspan="1" colspan="1">Bidirectional SFP</td>
              <td class="text-left" rowspan="1" colspan="1">RFC 9015</td>
              <td class="text-left" rowspan="1" colspan="1">2020-09-02</td>
            </tr>
          </tbody>
        </table>
</section>
</div>
<div id="SFTreg">
<section id="section-10.5">
        <h3 id="name-service-function-chaining-s">
<a href="#section-10.5" class="section-number selfRef">10.5. </a><a href="#name-service-function-chaining-s" class="section-name selfRef">"Service Function Chaining Service Function Types" Registry</a>
        </h3>
<p id="section-10.5-1">IANA has created a new top-level registry called "Service Function Chaining Service Function Types".<a href="#section-10.5-1" class="pilcrow">¶</a></p>
<p id="section-10.5-2">Valid values are in the range 0 to 65535.<a href="#section-10.5-2" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-10.5-3.1">Values 0 and 65535 are marked "Reserved".<a href="#section-10.5-3.1" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-10.5-3.2">Values 1 through 31 are to be assigned by "Standards Action" <span>[<a href="#RFC8126" class="xref">RFC8126</a>]</span> and are referred to
               as the "special-purpose SFT values".<a href="#section-10.5-3.2" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-10.5-3.3">Values 32 through 64495 are to be assigned according to the "First Come
               First Served" policy <span>[<a href="#RFC8126" class="xref">RFC8126</a>]</span>.<a href="#section-10.5-3.3" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-10.5-3.4">Values 64496 through 65534 are for Private Use and are not to be recorded by IANA.<a href="#section-10.5-3.4" class="pilcrow">¶</a>
</li>
        </ul>
<p id="section-10.5-4">This document is given as a reference for this registry.<a href="#section-10.5-4" class="pilcrow">¶</a></p>
<p id="section-10.5-5">The registry tracks:<a href="#section-10.5-5" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-10.5-6.1">Value<a href="#section-10.5-6.1" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-10.5-6.2">Name<a href="#section-10.5-6.2" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-10.5-6.3">Reference<a href="#section-10.5-6.3" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-10.5-6.4">Registration Date<a href="#section-10.5-6.4" class="pilcrow">¶</a>
</li>
        </ul>
<p id="section-10.5-7">The registry is initially populated as follows.<a href="#section-10.5-7" class="pilcrow">¶</a></p>
<span id="name-service-function-chaining-se"></span><table class="center" id="table-3">
          <caption>
<a href="#table-3" class="selfRef">Table 3</a>:
<a href="#name-service-function-chaining-se" class="selfRef">Service Function Chaining Service Function Types Registry Initial Contents</a>
          </caption>
<thead>
            <tr>
              <th class="text-left" rowspan="1" colspan="1">Value</th>
              <th class="text-left" rowspan="1" colspan="1">Name</th>
              <th class="text-left" rowspan="1" colspan="1">Reference</th>
              <th class="text-left" rowspan="1" colspan="1">Date</th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">0</td>
              <td class="text-left" rowspan="1" colspan="1">Reserved</td>
              <td class="text-left" rowspan="1" colspan="1">RFC 9015</td>
              <td class="text-left" rowspan="1" colspan="1">2020-09-02</td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">1</td>
              <td class="text-left" rowspan="1" colspan="1">Change Sequence</td>
              <td class="text-left" rowspan="1" colspan="1">RFC 9015</td>
              <td class="text-left" rowspan="1" colspan="1">2020-09-02</td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">2-31</td>
              <td class="text-left" rowspan="1" colspan="1">Unassigned</td>
              <td class="text-left" rowspan="1" colspan="1"></td>
              <td class="text-left" rowspan="1" colspan="1"></td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">32</td>
              <td class="text-left" rowspan="1" colspan="1">Classifier</td>
              <td class="text-left" rowspan="1" colspan="1">RFC 9015, <span>[<a href="#I-D.dawra-idr-bgp-ls-sr-service-segments" class="xref">BGP-LS-SR</a>]</span>
</td>
              <td class="text-left" rowspan="1" colspan="1">2020-09-02</td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">33</td>
              <td class="text-left" rowspan="1" colspan="1">Firewall</td>
              <td class="text-left" rowspan="1" colspan="1">RFC 9015, <span>[<a href="#I-D.dawra-idr-bgp-ls-sr-service-segments" class="xref">BGP-LS-SR</a>]</span>
</td>
              <td class="text-left" rowspan="1" colspan="1">2020-09-02</td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">34</td>
              <td class="text-left" rowspan="1" colspan="1">Load balancer</td>
              <td class="text-left" rowspan="1" colspan="1">RFC 9015, <span>[<a href="#I-D.dawra-idr-bgp-ls-sr-service-segments" class="xref">BGP-LS-SR</a>]</span>
</td>
              <td class="text-left" rowspan="1" colspan="1">2020-09-02</td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">35</td>
              <td class="text-left" rowspan="1" colspan="1">Deep packet inspection engine</td>
              <td class="text-left" rowspan="1" colspan="1">RFC 9015, <span>[<a href="#I-D.dawra-idr-bgp-ls-sr-service-segments" class="xref">BGP-LS-SR</a>]</span>
</td>
              <td class="text-left" rowspan="1" colspan="1">2020-09-02</td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">36</td>
              <td class="text-left" rowspan="1" colspan="1">Penalty box</td>
              <td class="text-left" rowspan="1" colspan="1">RFC 9015, <span>[<a href="#RFC8300" class="xref">RFC8300</a>]</span>
</td>
              <td class="text-left" rowspan="1" colspan="1">2020-09-02</td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">37</td>
              <td class="text-left" rowspan="1" colspan="1">WAN accelerator</td>
              <td class="text-left" rowspan="1" colspan="1">RFC 9015, <span>[<a href="#RFC7665" class="xref">RFC7665</a>]</span>, <span>[<a href="#RFC8300" class="xref">RFC8300</a>]</span>
</td>
              <td class="text-left" rowspan="1" colspan="1">2020-09-02</td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">38</td>
              <td class="text-left" rowspan="1" colspan="1">Application accelerator</td>
              <td class="text-left" rowspan="1" colspan="1">RFC 9015, <span>[<a href="#RFC7665" class="xref">RFC7665</a>]</span>
</td>
              <td class="text-left" rowspan="1" colspan="1">2020-09-02</td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">39</td>
              <td class="text-left" rowspan="1" colspan="1">TCP optimizer</td>
              <td class="text-left" rowspan="1" colspan="1">RFC 9015, <span>[<a href="#RFC7665" class="xref">RFC7665</a>]</span>
</td>
              <td class="text-left" rowspan="1" colspan="1">2020-09-02</td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">40</td>
              <td class="text-left" rowspan="1" colspan="1">Network Address Translator</td>
              <td class="text-left" rowspan="1" colspan="1">RFC 9015, <span>[<a href="#RFC7665" class="xref">RFC7665</a>]</span>
</td>
              <td class="text-left" rowspan="1" colspan="1">2020-09-02</td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">41</td>
              <td class="text-left" rowspan="1" colspan="1">NAT44</td>
              <td class="text-left" rowspan="1" colspan="1">RFC 9015, <span>[<a href="#RFC7665" class="xref">RFC7665</a>]</span>, <span>[<a href="#RFC3022" class="xref">RFC3022</a>]</span>
</td>
              <td class="text-left" rowspan="1" colspan="1">2020-09-02</td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">42</td>
              <td class="text-left" rowspan="1" colspan="1">NAT64</td>
              <td class="text-left" rowspan="1" colspan="1">RFC 9015, <span>[<a href="#RFC7665" class="xref">RFC7665</a>]</span>, <span>[<a href="#RFC6146" class="xref">RFC6146</a>]</span>
</td>
              <td class="text-left" rowspan="1" colspan="1">2020-09-02</td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">43</td>
              <td class="text-left" rowspan="1" colspan="1">NPTv6</td>
              <td class="text-left" rowspan="1" colspan="1">RFC 9015, <span>[<a href="#RFC7665" class="xref">RFC7665</a>]</span>, <span>[<a href="#RFC6296" class="xref">RFC6296</a>]</span>
</td>
              <td class="text-left" rowspan="1" colspan="1">2020-09-02</td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">44</td>
              <td class="text-left" rowspan="1" colspan="1">Lawful intercept</td>
              <td class="text-left" rowspan="1" colspan="1">RFC 9015, <span>[<a href="#RFC7665" class="xref">RFC7665</a>]</span>
</td>
              <td class="text-left" rowspan="1" colspan="1">2020-09-02</td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">45</td>
              <td class="text-left" rowspan="1" colspan="1">HOST_ID injection</td>
              <td class="text-left" rowspan="1" colspan="1">RFC 9015, <span>[<a href="#RFC7665" class="xref">RFC7665</a>]</span>
</td>
              <td class="text-left" rowspan="1" colspan="1">2020-09-02</td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">46</td>
              <td class="text-left" rowspan="1" colspan="1">HTTP header enrichment</td>
              <td class="text-left" rowspan="1" colspan="1">RFC 9015, <span>[<a href="#RFC7665" class="xref">RFC7665</a>]</span>
</td>
              <td class="text-left" rowspan="1" colspan="1">2020-09-02</td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">47</td>
              <td class="text-left" rowspan="1" colspan="1">Caching engine </td>
              <td class="text-left" rowspan="1" colspan="1">RFC 9015, <span>[<a href="#RFC7665" class="xref">RFC7665</a>]</span>
</td>
              <td class="text-left" rowspan="1" colspan="1">2020-09-02</td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">48-64495</td>
              <td class="text-left" rowspan="1" colspan="1">Unassigned</td>
              <td class="text-left" rowspan="1" colspan="1"></td>
              <td class="text-left" rowspan="1" colspan="1"></td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">64496-65534</td>
              <td class="text-left" rowspan="1" colspan="1">Reserved for Private Use</td>
              <td class="text-left" rowspan="1" colspan="1"></td>
              <td class="text-left" rowspan="1" colspan="1"></td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">65535</td>
              <td class="text-left" rowspan="1" colspan="1">Reserved, not to be allocated </td>
              <td class="text-left" rowspan="1" colspan="1">RFC 9015</td>
              <td class="text-left" rowspan="1" colspan="1">2020-09-02</td>
            </tr>
          </tbody>
        </table>
</section>
</div>
<div id="ExpExtComreg">
<section id="section-10.6">
        <h3 id="name-flow-specification-for-sfc-c">
<a href="#section-10.6" class="section-number selfRef">10.6. </a><a href="#name-flow-specification-for-sfc-c" class="section-name selfRef">Flow Specification for SFC Classifiers</a>
        </h3>
<p id="section-10.6-1">IANA maintains a registry of "Border Gateway Protocol (BGP) Extended Communities" with a subregistry of
          "Generic Transitive Experimental Use Extended Community Sub-Types".  IANA has assigned a
          new subtype as follows:<a href="#section-10.6-1" class="pilcrow">¶</a></p>
<ul class="ulEmpty normal">
<li class="ulEmpty normal" id="section-10.6-2.1">"Flow Specification for SFC Classifiers" with a value of 0x0d and with this document as the reference.<a href="#section-10.6-2.1" class="pilcrow">¶</a>
</li>
        </ul>
</section>
</div>
<div id="TransExtComreg">
<section id="section-10.7">
        <h3 id="name-new-bgp-transitive-extended">
<a href="#section-10.7" class="section-number selfRef">10.7. </a><a href="#name-new-bgp-transitive-extended" class="section-name selfRef">New BGP Transitive Extended Community Type</a>
        </h3>
<p id="section-10.7-1">IANA maintains a registry of "Border Gateway Protocol (BGP) Extended Communities" with a subregistry of
          "BGP Transitive Extended Community Types".  IANA has assigned a new type as follows:<a href="#section-10.7-1" class="pilcrow">¶</a></p>
<ul class="ulEmpty normal">
<li class="ulEmpty normal" id="section-10.7-2.1">SFC (Sub-Types are defined in the "SFC Extended Community
   Sub-Types" registry) with a value of 0x0b and with this document as
   the reference.<a href="#section-10.7-2.1" class="pilcrow">¶</a>
</li>
        </ul>
</section>
</div>
<div id="SFCExtComreg">
<section id="section-10.8">
        <h3 id="name-sfc-extended-community-sub-">
<a href="#section-10.8" class="section-number selfRef">10.8. </a><a href="#name-sfc-extended-community-sub-" class="section-name selfRef">"SFC Extended Community Sub-Types" Registry</a>
        </h3>
<p id="section-10.8-1">IANA maintains a registry of "Border Gateway Protocol (BGP) Parameters".  IANA has created a new subregistry called the "SFC Extended Community Sub-Types" registry.<a href="#section-10.8-1" class="pilcrow">¶</a></p>
<p id="section-10.8-2">IANA has included the following note:<a href="#section-10.8-2" class="pilcrow">¶</a></p>
<aside id="section-10.8-3">
          <p id="section-10.8-3.1">
          This registry contains values of the second octet (the "Sub-Type"
               field) of an extended community when the value of the first
               octet (the "Type" field) is set to 0x0b.<a href="#section-10.8-3.1" class="pilcrow">¶</a></p>
</aside>
<p id="section-10.8-4">The allocation policy for this registry is First Come First Served.<a href="#section-10.8-4" class="pilcrow">¶</a></p>
<p id="section-10.8-5">Valid values are 0 to 255.  The value 0 is reserved and should not be allocated.<a href="#section-10.8-5" class="pilcrow">¶</a></p>
<p id="section-10.8-6">IANA has populated this registry with the following entries:<a href="#section-10.8-6" class="pilcrow">¶</a></p>
<span id="name-sfc-extended-community-sub-t"></span><table class="center" id="table-4">
          <caption>
<a href="#table-4" class="selfRef">Table 4</a>:
<a href="#name-sfc-extended-community-sub-t" class="selfRef">SFC Extended Community Sub-Types Subregistry Initial Contents</a>
          </caption>
<thead>
            <tr>
              <th class="text-left" rowspan="1" colspan="1">Sub-Type                                    
       Value</th>
              <th class="text-left" rowspan="1" colspan="1">Name</th>
              <th class="text-left" rowspan="1" colspan="1">Reference</th>
              <th class="text-left" rowspan="1" colspan="1">Date</th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">0</td>
              <td class="text-left" rowspan="1" colspan="1">Reserved</td>
              <td class="text-left" rowspan="1" colspan="1">RFC 9015</td>
              <td class="text-left" rowspan="1" colspan="1"></td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">1</td>
              <td class="text-left" rowspan="1" colspan="1">SFIR pool identifier</td>
              <td class="text-left" rowspan="1" colspan="1">RFC 9015</td>
              <td class="text-left" rowspan="1" colspan="1">2020-09-02</td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">2</td>
              <td class="text-left" rowspan="1" colspan="1">MPLS Label Stack Mixed Swapping/Stacking Labels</td>
              <td class="text-left" rowspan="1" colspan="1">RFC 9015</td>
              <td class="text-left" rowspan="1" colspan="1">2020-09-02</td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">3-255</td>
              <td class="text-left" rowspan="1" colspan="1">Unassigned</td>
              <td class="text-left" rowspan="1" colspan="1"></td>
              <td class="text-left" rowspan="1" colspan="1"></td>
            </tr>
          </tbody>
        </table>
</section>
</div>
<div id="SpiSiRep">
<section id="section-10.9">
        <h3 id="name-new-spi-si-representation-s">
<a href="#section-10.9" class="section-number selfRef">10.9. </a><a href="#name-new-spi-si-representation-s" class="section-name selfRef">New SPI/SI Representation Sub-TLV</a>
        </h3>
<p id="section-10.9-1">IANA has assigned a codepoint from the "BGP Tunnel Encapsulation Attribute
          Sub-TLVs" registry for the "SPI/SI Representation Sub-TLV"  with a value of 16 and with this
          document as the reference.<a href="#section-10.9-1" class="pilcrow">¶</a></p>
</section>
</div>
<div id="IANAbits">
<section id="section-10.10">
        <h3 id="name-sfc-spi-si-representation-f">
<a href="#section-10.10" class="section-number selfRef">10.10. </a><a href="#name-sfc-spi-si-representation-f" class="section-name selfRef">"SFC SPI/SI Representation Flags" Registry</a>
        </h3>
<p id="section-10.10-1">IANA maintains the "BGP Tunnel Encapsulation Attribute Sub-TLVs" registry and has created an associated registry called the "SFC SPI/SI Representation Flags" registry.<a href="#section-10.10-1" class="pilcrow">¶</a></p>
<p id="section-10.10-2">Bits are to be assigned by Standards Action. The field is 16 bits long, and bits are counted
         from the most significant bit as bit zero.<a href="#section-10.10-2" class="pilcrow">¶</a></p>
<p id="section-10.10-3">IANA has populated the registry as follows:<a href="#section-10.10-3" class="pilcrow">¶</a></p>
<span id="name-sfc-spi-si-representation-fl"></span><table class="center" id="table-5">
          <caption>
<a href="#table-5" class="selfRef">Table 5</a>:
<a href="#name-sfc-spi-si-representation-fl" class="selfRef">SFC SPI/SI Representation Flags Registry Initial Contents</a>
          </caption>
<thead>
            <tr>
              <th class="text-left" rowspan="1" colspan="1">Value</th>
              <th class="text-left" rowspan="1" colspan="1">Name</th>
              <th class="text-left" rowspan="1" colspan="1">Reference</th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">0</td>
              <td class="text-left" rowspan="1" colspan="1">NSH data plane</td>
              <td class="text-left" rowspan="1" colspan="1">RFC 9015</td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">1</td>
              <td class="text-left" rowspan="1" colspan="1">MPLS data plane</td>
              <td class="text-left" rowspan="1" colspan="1">RFC 9015</td>
            </tr>
          </tbody>
        </table>
</section>
</div>
</section>
</div>
<section id="section-11">
      <h2 id="name-references">
<a href="#section-11" class="section-number selfRef">11. </a><a href="#name-references" class="section-name selfRef">References</a>
      </h2>
<section id="section-11.1">
        <h3 id="name-normative-references">
<a href="#section-11.1" class="section-number selfRef">11.1. </a><a href="#name-normative-references" class="section-name selfRef">Normative References</a>
        </h3>
<dl class="references">
<dt id="RFC2119">[RFC2119]</dt>
        <dd>
<span class="refAuthor">Bradner, S.</span>, <span class="refTitle">"Key words for use in RFCs to Indicate Requirement Levels"</span>, <span class="seriesInfo">BCP 14</span>, <span class="seriesInfo">RFC 2119</span>, <span class="seriesInfo">DOI 10.17487/RFC2119</span>, <time datetime="1997-03" class="refDate">March 1997</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc2119">https://www.rfc-editor.org/info/rfc2119</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC4271">[RFC4271]</dt>
        <dd>
<span class="refAuthor">Rekhter, Y., Ed.</span>, <span class="refAuthor">Li, T., Ed.</span>, and <span class="refAuthor">S. Hares, Ed.</span>, <span class="refTitle">"A Border Gateway Protocol 4 (BGP-4)"</span>, <span class="seriesInfo">RFC 4271</span>, <span class="seriesInfo">DOI 10.17487/RFC4271</span>, <time datetime="2006-01" class="refDate">January 2006</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc4271">https://www.rfc-editor.org/info/rfc4271</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC4360">[RFC4360]</dt>
        <dd>
<span class="refAuthor">Sangli, S.</span>, <span class="refAuthor">Tappan, D.</span>, and <span class="refAuthor">Y. Rekhter</span>, <span class="refTitle">"BGP Extended Communities Attribute"</span>, <span class="seriesInfo">RFC 4360</span>, <span class="seriesInfo">DOI 10.17487/RFC4360</span>, <time datetime="2006-02" class="refDate">February 2006</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc4360">https://www.rfc-editor.org/info/rfc4360</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC4364">[RFC4364]</dt>
        <dd>
<span class="refAuthor">Rosen, E.</span> and <span class="refAuthor">Y. Rekhter</span>, <span class="refTitle">"BGP/MPLS IP Virtual Private Networks (VPNs)"</span>, <span class="seriesInfo">RFC 4364</span>, <span class="seriesInfo">DOI 10.17487/RFC4364</span>, <time datetime="2006-02" class="refDate">February 2006</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc4364">https://www.rfc-editor.org/info/rfc4364</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC4760">[RFC4760]</dt>
        <dd>
<span class="refAuthor">Bates, T.</span>, <span class="refAuthor">Chandra, R.</span>, <span class="refAuthor">Katz, D.</span>, and <span class="refAuthor">Y. Rekhter</span>, <span class="refTitle">"Multiprotocol Extensions for BGP-4"</span>, <span class="seriesInfo">RFC 4760</span>, <span class="seriesInfo">DOI 10.17487/RFC4760</span>, <time datetime="2007-01" class="refDate">January 2007</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc4760">https://www.rfc-editor.org/info/rfc4760</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC7432">[RFC7432]</dt>
        <dd>
<span class="refAuthor">Sajassi, A., Ed.</span>, <span class="refAuthor">Aggarwal, R.</span>, <span class="refAuthor">Bitar, N.</span>, <span class="refAuthor">Isaac, A.</span>, <span class="refAuthor">Uttaro, J.</span>, <span class="refAuthor">Drake, J.</span>, and <span class="refAuthor">W. Henderickx</span>, <span class="refTitle">"BGP MPLS-Based Ethernet VPN"</span>, <span class="seriesInfo">RFC 7432</span>, <span class="seriesInfo">DOI 10.17487/RFC7432</span>, <time datetime="2015-02" class="refDate">February 2015</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc7432">https://www.rfc-editor.org/info/rfc7432</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC7606">[RFC7606]</dt>
        <dd>
<span class="refAuthor">Chen, E., Ed.</span>, <span class="refAuthor">Scudder, J., Ed.</span>, <span class="refAuthor">Mohapatra, P.</span>, and <span class="refAuthor">K. Patel</span>, <span class="refTitle">"Revised Error Handling for BGP UPDATE Messages"</span>, <span class="seriesInfo">RFC 7606</span>, <span class="seriesInfo">DOI 10.17487/RFC7606</span>, <time datetime="2015-08" class="refDate">August 2015</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc7606">https://www.rfc-editor.org/info/rfc7606</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC7665">[RFC7665]</dt>
        <dd>
<span class="refAuthor">Halpern, J., Ed.</span> and <span class="refAuthor">C. Pignataro, Ed.</span>, <span class="refTitle">"Service Function Chaining (SFC) Architecture"</span>, <span class="seriesInfo">RFC 7665</span>, <span class="seriesInfo">DOI 10.17487/RFC7665</span>, <time datetime="2015-10" class="refDate">October 2015</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc7665">https://www.rfc-editor.org/info/rfc7665</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC8126">[RFC8126]</dt>
        <dd>
<span class="refAuthor">Cotton, M.</span>, <span class="refAuthor">Leiba, B.</span>, and <span class="refAuthor">T. Narten</span>, <span class="refTitle">"Guidelines for Writing an IANA Considerations Section in RFCs"</span>, <span class="seriesInfo">BCP 26</span>, <span class="seriesInfo">RFC 8126</span>, <span class="seriesInfo">DOI 10.17487/RFC8126</span>, <time datetime="2017-06" class="refDate">June 2017</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8126">https://www.rfc-editor.org/info/rfc8126</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC8174">[RFC8174]</dt>
        <dd>
<span class="refAuthor">Leiba, B.</span>, <span class="refTitle">"Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words"</span>, <span class="seriesInfo">BCP 14</span>, <span class="seriesInfo">RFC 8174</span>, <span class="seriesInfo">DOI 10.17487/RFC8174</span>, <time datetime="2017-05" class="refDate">May 2017</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8174">https://www.rfc-editor.org/info/rfc8174</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC8300">[RFC8300]</dt>
        <dd>
<span class="refAuthor">Quinn, P., Ed.</span>, <span class="refAuthor">Elzur, U., Ed.</span>, and <span class="refAuthor">C. Pignataro, Ed.</span>, <span class="refTitle">"Network Service Header (NSH)"</span>, <span class="seriesInfo">RFC 8300</span>, <span class="seriesInfo">DOI 10.17487/RFC8300</span>, <time datetime="2018-01" class="refDate">January 2018</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8300">https://www.rfc-editor.org/info/rfc8300</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC8595">[RFC8595]</dt>
        <dd>
<span class="refAuthor">Farrel, A.</span>, <span class="refAuthor">Bryant, S.</span>, and <span class="refAuthor">J. Drake</span>, <span class="refTitle">"An MPLS-Based Forwarding Plane for Service Function Chaining"</span>, <span class="seriesInfo">RFC 8595</span>, <span class="seriesInfo">DOI 10.17487/RFC8595</span>, <time datetime="2019-06" class="refDate">June 2019</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8595">https://www.rfc-editor.org/info/rfc8595</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC8596">[RFC8596]</dt>
        <dd>
<span class="refAuthor">Malis, A.</span>, <span class="refAuthor">Bryant, S.</span>, <span class="refAuthor">Halpern, J.</span>, and <span class="refAuthor">W. Henderickx</span>, <span class="refTitle">"MPLS Transport Encapsulation for the Service Function Chaining (SFC) Network Service Header (NSH)"</span>, <span class="seriesInfo">RFC 8596</span>, <span class="seriesInfo">DOI 10.17487/RFC8596</span>, <time datetime="2019-06" class="refDate">June 2019</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8596">https://www.rfc-editor.org/info/rfc8596</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC8955">[RFC8955]</dt>
        <dd>
<span class="refAuthor">Loibl, C.</span>, <span class="refAuthor">Hares, S.</span>, <span class="refAuthor">Raszuk, R.</span>, <span class="refAuthor">McPherson, D.</span>, and <span class="refAuthor">M. Bacher</span>, <span class="refTitle">"Dissemination of Flow Specification Rules"</span>, <span class="seriesInfo">RFC 8955</span>, <span class="seriesInfo">DOI 10.17487/RFC8955</span>, <time datetime="2020-12" class="refDate">December 2020</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8955">https://www.rfc-editor.org/info/rfc8955</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC9012">[RFC9012]</dt>
      <dd>
<span class="refAuthor">Patel, K.</span>, <span class="refAuthor">Van de Velde, G.</span>, <span class="refAuthor">Sangli, S.</span>, and <span class="refAuthor">J. Scudder</span>, <span class="refTitle">"The BGP Tunnel Encapsulation Attribute"</span>, <span class="seriesInfo">RFC 9012</span>, <span class="seriesInfo">DOI 10.17487/RFC9012</span>, <time datetime="2021-04" class="refDate">April 2021</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc9012">https://www.rfc-editor.org/info/rfc9012</a>&gt;</span>. </dd>
<dd class="break"></dd>
</dl>
</section>
<section id="section-11.2">
        <h3 id="name-informative-references">
<a href="#section-11.2" class="section-number selfRef">11.2. </a><a href="#name-informative-references" class="section-name selfRef">Informative References</a>
        </h3>
<dl class="references">
<dt id="I-D.dawra-idr-bgp-ls-sr-service-segments">[BGP-LS-SR]</dt>
        <dd>
<span class="refAuthor">Dawra, G.</span>, <span class="refAuthor">Filsfils, C.</span>, <span class="refAuthor">Talaulikar, K.</span>, <span class="refAuthor">Clad, F.</span>, <span class="refAuthor">Bernier, D.</span>, <span class="refAuthor">Uttaro, J.</span>, <span class="refAuthor">Decraene, B.</span>, <span class="refAuthor">Elmalky, H.</span>, <span class="refAuthor">Xu, X.</span>, <span class="refAuthor">Guichard, J.</span>, and <span class="refAuthor">C. Li</span>, <span class="refTitle">"BGP-LS Advertisement of Segment Routing Service Segments"</span>, <span class="refContent">Work in Progress</span>, <span class="seriesInfo">Internet-Draft, draft-dawra-idr-bgp-ls-sr-service-segments-05</span>, <time datetime="2021-02-15" class="refDate">15 February 2021</time>, <span>&lt;<a href="https://tools.ietf.org/html/draft-dawra-idr-bgp-ls-sr-service-segments-05">https://tools.ietf.org/html/draft-dawra-idr-bgp-ls-sr-service-segments-05</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC3022">[RFC3022]</dt>
        <dd>
<span class="refAuthor">Srisuresh, P.</span> and <span class="refAuthor">K. Egevang</span>, <span class="refTitle">"Traditional IP Network Address Translator (Traditional NAT)"</span>, <span class="seriesInfo">RFC 3022</span>, <span class="seriesInfo">DOI 10.17487/RFC3022</span>, <time datetime="2001-01" class="refDate">January 2001</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc3022">https://www.rfc-editor.org/info/rfc3022</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC4272">[RFC4272]</dt>
        <dd>
<span class="refAuthor">Murphy, S.</span>, <span class="refTitle">"BGP Security Vulnerabilities Analysis"</span>, <span class="seriesInfo">RFC 4272</span>, <span class="seriesInfo">DOI 10.17487/RFC4272</span>, <time datetime="2006-01" class="refDate">January 2006</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc4272">https://www.rfc-editor.org/info/rfc4272</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC5925">[RFC5925]</dt>
        <dd>
<span class="refAuthor">Touch, J.</span>, <span class="refAuthor">Mankin, A.</span>, and <span class="refAuthor">R. Bonica</span>, <span class="refTitle">"The TCP Authentication Option"</span>, <span class="seriesInfo">RFC 5925</span>, <span class="seriesInfo">DOI 10.17487/RFC5925</span>, <time datetime="2010-06" class="refDate">June 2010</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc5925">https://www.rfc-editor.org/info/rfc5925</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC6146">[RFC6146]</dt>
        <dd>
<span class="refAuthor">Bagnulo, M.</span>, <span class="refAuthor">Matthews, P.</span>, and <span class="refAuthor">I. van Beijnum</span>, <span class="refTitle">"Stateful NAT64: Network Address and Protocol Translation from IPv6 Clients to IPv4 Servers"</span>, <span class="seriesInfo">RFC 6146</span>, <span class="seriesInfo">DOI 10.17487/RFC6146</span>, <time datetime="2011-04" class="refDate">April 2011</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc6146">https://www.rfc-editor.org/info/rfc6146</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC6296">[RFC6296]</dt>
        <dd>
<span class="refAuthor">Wasserman, M.</span> and <span class="refAuthor">F. Baker</span>, <span class="refTitle">"IPv6-to-IPv6 Network Prefix Translation"</span>, <span class="seriesInfo">RFC 6296</span>, <span class="seriesInfo">DOI 10.17487/RFC6296</span>, <time datetime="2011-06" class="refDate">June 2011</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc6296">https://www.rfc-editor.org/info/rfc6296</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC6952">[RFC6952]</dt>
        <dd>
<span class="refAuthor">Jethanandani, M.</span>, <span class="refAuthor">Patel, K.</span>, and <span class="refAuthor">L. Zheng</span>, <span class="refTitle">"Analysis of BGP, LDP, PCEP, and MSDP Issues According to the Keying and Authentication for Routing Protocols (KARP) Design Guide"</span>, <span class="seriesInfo">RFC 6952</span>, <span class="seriesInfo">DOI 10.17487/RFC6952</span>, <time datetime="2013-05" class="refDate">May 2013</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc6952">https://www.rfc-editor.org/info/rfc6952</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC7498">[RFC7498]</dt>
      <dd>
<span class="refAuthor">Quinn, P., Ed.</span> and <span class="refAuthor">T. Nadeau, Ed.</span>, <span class="refTitle">"Problem Statement for Service Function Chaining"</span>, <span class="seriesInfo">RFC 7498</span>, <span class="seriesInfo">DOI 10.17487/RFC7498</span>, <time datetime="2015-04" class="refDate">April 2015</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc7498">https://www.rfc-editor.org/info/rfc7498</a>&gt;</span>. </dd>
<dd class="break"></dd>
</dl>
</section>
</section>
<div id="acks">
<section id="section-appendix.a">
      <h2 id="name-acknowledgements">
<a href="#name-acknowledgements" class="section-name selfRef">Acknowledgements</a>
      </h2>
<p id="section-appendix.a-1">Thanks to <span class="contact-name">Tony Przygienda</span>, <span class="contact-name">Jeff Haas</span>, and <span class="contact-name">Andy Malis</span> for helpful
      comments, and to
       <span class="contact-name">Joel Halpern</span> for discussions that improved this
       document.  <span class="contact-name">Yuanlong Jiang</span> provided
       a useful review and caught some important issues.  <span class="contact-name">Stephane Litkowski</span> did an
       exceptionally good and detailed Document Shepherd review.<a href="#section-appendix.a-1" class="pilcrow">¶</a></p>
<p id="section-appendix.a-2"><span class="contact-name">Andy Malis</span> contributed text that formed the
      basis of <a href="#mpls-encaps" class="xref">Section 7.7</a>.<a href="#section-appendix.a-2" class="pilcrow">¶</a></p>
<p id="section-appendix.a-3"><span class="contact-name">Brian Carpenter</span> and <span class="contact-name">Martin       Vigoureux</span> provided useful reviews during IETF Last Call.
       Thanks also to <span class="contact-name">Sheng Jiang</span>, <span class="contact-name">Med Boucadair</span>, <span class="contact-name">Ravi Singh</span>, <span class="contact-name">Benjamin Kaduk</span>, <span class="contact-name">Roman Danyliw</span>,
       <span class="contact-name">Adam Roach</span>, <span class="contact-name">Alvaro Retana</span>, <span class="contact-name">Barry Leiba</span>, and <span class="contact-name">Murray Kucherawy</span> for review comments.
       <span class="contact-name">Ketan Talaulikar</span> provided helpful discussion of
       the SFT codepoint registry.  <span class="contact-name">Ron Bonica</span>
       kept us honest on the difference between an RD and an RT; <span class="contact-name">Benjamin Kaduk</span> kept us on message
       about the difference between an RD and an Extended Community.<a href="#section-appendix.a-3" class="pilcrow">¶</a></p>
</section>
</div>
<div id="contributors">
<section id="section-appendix.b">
      <h2 id="name-contributors">
<a href="#name-contributors" class="section-name selfRef">Contributors</a>
      </h2>
<address class="vcard">
        <div dir="auto" class="left"><span class="fn nameRole">Stuart Mackie</span></div>
<div dir="auto" class="left"><span class="org">Juniper Networks</span></div>
<div class="email">
<span>Email:</span>
<a href="mailto:wsmackie@juinper.net" class="email">wsmackie@juinper.net</a>
</div>
</address>
<address class="vcard">
        <div dir="auto" class="left"><span class="fn nameRole">Keyur Patel</span></div>
<div dir="auto" class="left"><span class="org">Arrcus, Inc.</span></div>
<div class="email">
<span>Email:</span>
<a href="mailto:keyur@arrcus.com" class="email">keyur@arrcus.com</a>
</div>
</address>
<address class="vcard">
        <div dir="auto" class="left"><span class="fn nameRole">Avinash Lingala</span></div>
<div dir="auto" class="left"><span class="org">AT&amp;T</span></div>
<div class="email">
<span>Email:</span>
<a href="mailto:ar977m@att.com" class="email">ar977m@att.com</a>
</div>
</address>
</section>
</div>
<div id="authors-addresses">
<section id="section-appendix.c">
      <h2 id="name-authors-addresses">
<a href="#name-authors-addresses" class="section-name selfRef">Authors' Addresses</a>
      </h2>
<address class="vcard">
        <div dir="auto" class="left"><span class="fn nameRole">Adrian Farrel</span></div>
<div dir="auto" class="left"><span class="org">Old Dog Consulting</span></div>
<div class="email">
<span>Email:</span>
<a href="mailto:adrian@olddog.co.uk" class="email">adrian@olddog.co.uk</a>
</div>
</address>
<address class="vcard">
        <div dir="auto" class="left"><span class="fn nameRole">John Drake</span></div>
<div dir="auto" class="left"><span class="org">Juniper Networks</span></div>
<div class="email">
<span>Email:</span>
<a href="mailto:jdrake@juniper.net" class="email">jdrake@juniper.net</a>
</div>
</address>
<address class="vcard">
        <div dir="auto" class="left"><span class="fn nameRole">Eric Rosen</span></div>
<div dir="auto" class="left"><span class="org">Juniper Networks</span></div>
<div class="email">
<span>Email:</span>
<a href="mailto:erosen52@gmail.com" class="email">erosen52@gmail.com</a>
</div>
</address>
<address class="vcard">
        <div dir="auto" class="left"><span class="fn nameRole">Jim Uttaro</span></div>
<div dir="auto" class="left"><span class="org">AT&amp;T</span></div>
<div class="email">
<span>Email:</span>
<a href="mailto:ju1738@att.com" class="email">ju1738@att.com</a>
</div>
</address>
<address class="vcard">
        <div dir="auto" class="left"><span class="fn nameRole">Luay Jalil</span></div>
<div dir="auto" class="left"><span class="org">Verizon</span></div>
<div class="email">
<span>Email:</span>
<a href="mailto:luay.jalil@verizon.com" class="email">luay.jalil@verizon.com</a>
</div>
</address>
</section>
</div>
<script>const toc = document.getElementById("toc");
toc.querySelector("h2").addEventListener("click", e => {
  toc.classList.toggle("active");
});
toc.querySelector("nav").addEventListener("click", e => {
  toc.classList.remove("active");
});
</script>
</body>
</html>