File: rfc8924.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 (2622 lines) | stat: -rw-r--r-- 127,684 bytes
parent folder | download | duplicates (2)
<!DOCTYPE html>
<html lang="en" class="RFC">
<head>
<meta charset="utf-8">
<meta content="Common,Latin" name="scripts">
<meta content="initial-scale=1.0" name="viewport">
<title>RFC 8924: Service Function Chaining (SFC) Operations, Administration, and Maintenance (OAM) Framework</title>
<meta content="Sam K. Aldrin" name="author">
<meta content="Carlos Pignataro" name="author">
<meta content="Nagendra Kumar" name="author">
<meta content="Ram Krishnan" name="author">
<meta content="Anoop Ghanwani" name="author">
<meta content="
       This document provides a reference framework for Operations,
      Administration, and Maintenance (OAM) for Service Function Chaining
      (SFC). 
    " name="description">
<meta content="xml2rfc 3.2.1" name="generator">
<meta content="SFC" name="keyword">
<meta content="OAM" name="keyword">
<meta content="Framework" name="keyword">
<meta content="8924" name="rfc.number">
<!-- Generator version information:
  xml2rfc 3.2.1
    Python 3.6.10
    appdirs 1.4.4
    ConfigArgParse 1.2.3
    google-i18n-address 2.3.5
    html5lib 1.0.1
    intervaltree 3.0.2
    Jinja2 2.11.2
    kitchen 1.2.6
    lxml 4.4.2
    pycairo 1.19.0
    pycountry 19.8.18
    pyflakes 2.1.1
    PyYAML 5.3.1
    requests 2.22.0
    setuptools 40.6.2
    six 1.14.0
    WeasyPrint 51
-->
<link href="rfc8924.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";
}
</style>
<link href="rfc-local.css" rel="stylesheet" type="text/css">
<link href="https://dx.doi.org/10.17487/rfc8924" rel="alternate">
  <link href="urn:issn:2070-1721" rel="alternate">
  <link href="https://datatracker.ietf.org/doc/draft-ietf-sfc-oam-framework-15" 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 8924</td>
<td class="center">SFC OAM Framework</td>
<td class="right">October 2020</td>
</tr></thead>
<tfoot><tr>
<td class="left">Aldrin, et al.</td>
<td class="center">Informational</td>
<td class="right">[Page]</td>
</tr></tfoot>
</table>
<div id="external-metadata" class="document-information"></div>
<div id="internal-metadata" class="document-information">
<dl id="identifiers">
<dt class="label-stream">Stream:</dt>
<dd class="stream">Internet Engineering Task Force (IETF)</dd>
<dt class="label-rfc">RFC:</dt>
<dd class="rfc"><a href="https://www.rfc-editor.org/rfc/rfc8924" class="eref">8924</a></dd>
<dt class="label-category">Category:</dt>
<dd class="category">Informational</dd>
<dt class="label-published">Published:</dt>
<dd class="published">
<time datetime="2020-10" class="published">October 2020</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">S. Aldrin</div>
<div class="org">Google</div>
</div>
<div class="author">
      <div class="author-name">C. Pignataro, <span class="editor">Ed.</span>
</div>
<div class="org">Cisco</div>
</div>
<div class="author">
      <div class="author-name">N. Kumar, <span class="editor">Ed.</span>
</div>
<div class="org">Cisco</div>
</div>
<div class="author">
      <div class="author-name">R. Krishnan</div>
<div class="org">VMware</div>
</div>
<div class="author">
      <div class="author-name">A. Ghanwani</div>
<div class="org">Dell</div>
</div>
</dd>
</dl>
</div>
<h1 id="rfcnum">RFC 8924</h1>
<h1 id="title">Service Function Chaining (SFC) Operations, Administration, and Maintenance (OAM) Framework</h1>
<section id="section-abstract">
      <h2 id="abstract"><a href="#abstract" class="selfRef">Abstract</a></h2>
<p id="section-abstract-1">This document provides a reference framework for Operations,
      Administration, and Maintenance (OAM) for Service Function Chaining
      (SFC).<a href="#section-abstract-1" class="pilcrow">¶</a></p>
</section>
<div id="status-of-memo">
<section id="section-boilerplate.1">
        <h2 id="name-status-of-this-memo">
<a href="#name-status-of-this-memo" class="section-name selfRef">Status of This Memo</a>
        </h2>
<p id="section-boilerplate.1-1">
            This document is not an Internet Standards Track specification; it is
            published for informational purposes.<a href="#section-boilerplate.1-1" class="pilcrow">¶</a></p>
<p id="section-boilerplate.1-2">
            This document is a product of the Internet Engineering Task Force
            (IETF).  It represents the consensus of the IETF community.  It has
            received public review and has been approved for publication by the
            Internet Engineering Steering Group (IESG).  Not all documents
            approved by the IESG are candidates for any level of Internet
            Standard; see Section 2 of RFC 7841.<a href="#section-boilerplate.1-2" class="pilcrow">¶</a></p>
<p id="section-boilerplate.1-3">
            Information about the current status of this document, any
            errata, and how to provide feedback on it may be obtained at
            <span><a href="https://www.rfc-editor.org/info/rfc8924">https://www.rfc-editor.org/info/rfc8924</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) 2020 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="compact toc ulEmpty">
<li class="compact toc ulEmpty" id="section-toc.1-1.1">
            <p id="section-toc.1-1.1.1"><a href="#section-1" class="xref">1</a>.  <a href="#name-introduction" class="xref">Introduction</a><a href="#section-toc.1-1.1.1" class="pilcrow">¶</a></p>
<ul class="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-document-scope" class="xref">Document Scope</a><a href="#section-toc.1-1.1.2.1.1" class="pilcrow">¶</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"><a href="#section-1.2" class="xref">1.2</a>.  <a href="#name-acronyms-and-terminology" class="xref">Acronyms and Terminology</a><a href="#section-toc.1-1.1.2.2.1" class="pilcrow">¶</a></p>
<ul class="compact toc ulEmpty">
<li class="compact toc ulEmpty" id="section-toc.1-1.1.2.2.2.1">
                    <p id="section-toc.1-1.1.2.2.2.1.1" class="keepWithNext"><a href="#section-1.2.1" class="xref">1.2.1</a>.  <a href="#name-acronyms" class="xref">Acronyms</a><a href="#section-toc.1-1.1.2.2.2.1.1" class="pilcrow">¶</a></p>
</li>
                  <li class="compact toc ulEmpty" id="section-toc.1-1.1.2.2.2.2">
                    <p id="section-toc.1-1.1.2.2.2.2.1" class="keepWithNext"><a href="#section-1.2.2" class="xref">1.2.2</a>.  <a href="#name-terminology" class="xref">Terminology</a><a href="#section-toc.1-1.1.2.2.2.2.1" class="pilcrow">¶</a></p>
</li>
                </ul>
</li>
            </ul>
</li>
          <li class="compact toc ulEmpty" id="section-toc.1-1.2">
            <p id="section-toc.1-1.2.1"><a href="#section-2" class="xref">2</a>.  <a href="#name-sfc-layering-model" class="xref">SFC Layering Model</a><a href="#section-toc.1-1.2.1" class="pilcrow">¶</a></p>
</li>
          <li class="compact toc ulEmpty" id="section-toc.1-1.3">
            <p id="section-toc.1-1.3.1"><a href="#section-3" class="xref">3</a>.  <a href="#name-sfc-oam-components" class="xref">SFC OAM Components</a><a href="#section-toc.1-1.3.1" class="pilcrow">¶</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-the-sf-component" class="xref">The SF Component</a><a href="#section-toc.1-1.3.2.1.1" class="pilcrow">¶</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-sf-availability" class="xref">SF Availability</a><a href="#section-toc.1-1.3.2.1.2.1.1" class="pilcrow">¶</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-sf-performance-measurement" class="xref">SF Performance Measurement</a><a href="#section-toc.1-1.3.2.1.2.2.1" class="pilcrow">¶</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-the-sfc-component" class="xref">The SFC Component</a><a href="#section-toc.1-1.3.2.2.1" class="pilcrow">¶</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-sfc-availability" class="xref">SFC Availability</a><a href="#section-toc.1-1.3.2.2.2.1.1" class="pilcrow">¶</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-sfc-performance-measurement" class="xref">SFC Performance Measurement</a><a href="#section-toc.1-1.3.2.2.2.2.1" class="pilcrow">¶</a></p>
</li>
                </ul>
</li>
              <li class="compact toc ulEmpty" id="section-toc.1-1.3.2.3">
                <p id="section-toc.1-1.3.2.3.1"><a href="#section-3.3" class="xref">3.3</a>.  <a href="#name-classifier-component" class="xref">Classifier Component</a><a href="#section-toc.1-1.3.2.3.1" class="pilcrow">¶</a></p>
</li>
              <li class="compact toc ulEmpty" id="section-toc.1-1.3.2.4">
                <p id="section-toc.1-1.3.2.4.1"><a href="#section-3.4" class="xref">3.4</a>.  <a href="#name-underlay-network" class="xref">Underlay Network</a><a href="#section-toc.1-1.3.2.4.1" class="pilcrow">¶</a></p>
</li>
              <li class="compact toc ulEmpty" id="section-toc.1-1.3.2.5">
                <p id="section-toc.1-1.3.2.5.1"><a href="#section-3.5" class="xref">3.5</a>.  <a href="#name-overlay-network" class="xref">Overlay Network</a><a href="#section-toc.1-1.3.2.5.1" class="pilcrow">¶</a></p>
</li>
            </ul>
</li>
          <li class="compact toc ulEmpty" id="section-toc.1-1.4">
            <p id="section-toc.1-1.4.1"><a href="#section-4" class="xref">4</a>.  <a href="#name-sfc-oam-functions" class="xref">SFC OAM Functions</a><a href="#section-toc.1-1.4.1" class="pilcrow">¶</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-connectivity-functions" class="xref">Connectivity Functions</a><a href="#section-toc.1-1.4.2.1.1" class="pilcrow">¶</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-continuity-functions" class="xref">Continuity Functions</a><a href="#section-toc.1-1.4.2.2.1" class="pilcrow">¶</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-trace-functions" class="xref">Trace Functions</a><a href="#section-toc.1-1.4.2.3.1" class="pilcrow">¶</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-performance-measurement-fun" class="xref">Performance Measurement Functions</a><a href="#section-toc.1-1.4.2.4.1" class="pilcrow">¶</a></p>
</li>
            </ul>
</li>
          <li class="compact toc ulEmpty" id="section-toc.1-1.5">
            <p id="section-toc.1-1.5.1"><a href="#section-5" class="xref">5</a>.  <a href="#name-gap-analysis" class="xref">Gap Analysis</a><a href="#section-toc.1-1.5.1" class="pilcrow">¶</a></p>
<ul class="compact toc ulEmpty">
<li class="compact toc ulEmpty" id="section-toc.1-1.5.2.1">
                <p id="section-toc.1-1.5.2.1.1"><a href="#section-5.1" class="xref">5.1</a>.  <a href="#name-existing-oam-functions" class="xref">Existing OAM Functions</a><a href="#section-toc.1-1.5.2.1.1" class="pilcrow">¶</a></p>
</li>
              <li class="compact toc ulEmpty" id="section-toc.1-1.5.2.2">
                <p id="section-toc.1-1.5.2.2.1"><a href="#section-5.2" class="xref">5.2</a>.  <a href="#name-missing-oam-functions" class="xref">Missing OAM Functions</a><a href="#section-toc.1-1.5.2.2.1" class="pilcrow">¶</a></p>
</li>
              <li class="compact toc ulEmpty" id="section-toc.1-1.5.2.3">
                <p id="section-toc.1-1.5.2.3.1"><a href="#section-5.3" class="xref">5.3</a>.  <a href="#name-required-oam-functions" class="xref">Required OAM Functions</a><a href="#section-toc.1-1.5.2.3.1" class="pilcrow">¶</a></p>
</li>
            </ul>
</li>
          <li class="compact toc ulEmpty" id="section-toc.1-1.6">
            <p id="section-toc.1-1.6.1"><a href="#section-6" class="xref">6</a>.  <a href="#name-operational-aspects-of-sfc-" class="xref">Operational Aspects of SFC OAM at the Service Layer</a><a href="#section-toc.1-1.6.1" class="pilcrow">¶</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-sfc-oam-packet-marker" class="xref">SFC OAM Packet Marker</a><a href="#section-toc.1-1.6.2.1.1" class="pilcrow">¶</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-oam-packet-processing-and-f" class="xref">OAM Packet Processing and Forwarding Semantic</a><a href="#section-toc.1-1.6.2.2.1" class="pilcrow">¶</a></p>
</li>
              <li class="compact toc ulEmpty" id="section-toc.1-1.6.2.3">
                <p id="section-toc.1-1.6.2.3.1"><a href="#section-6.3" class="xref">6.3</a>.  <a href="#name-oam-function-types" class="xref">OAM Function Types</a><a href="#section-toc.1-1.6.2.3.1" class="pilcrow">¶</a></p>
</li>
            </ul>
</li>
          <li class="compact toc ulEmpty" id="section-toc.1-1.7">
            <p id="section-toc.1-1.7.1"><a href="#section-7" class="xref">7</a>.  <a href="#name-candidate-sfc-oam-tools" class="xref">Candidate SFC OAM Tools</a><a href="#section-toc.1-1.7.1" class="pilcrow">¶</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-icmp" class="xref">ICMP</a><a href="#section-toc.1-1.7.2.1.1" class="pilcrow">¶</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-bfd-seamless-bfd" class="xref">BFD / Seamless BFD</a><a href="#section-toc.1-1.7.2.2.1" class="pilcrow">¶</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-in-situ-oam" class="xref">In Situ OAM</a><a href="#section-toc.1-1.7.2.3.1" class="pilcrow">¶</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-sfc-traceroute" class="xref">SFC Traceroute</a><a href="#section-toc.1-1.7.2.4.1" class="pilcrow">¶</a></p>
</li>
            </ul>
</li>
          <li class="compact toc ulEmpty" id="section-toc.1-1.8">
            <p id="section-toc.1-1.8.1"><a href="#section-8" class="xref">8</a>.  <a href="#name-manageability-consideration" class="xref">Manageability Considerations</a><a href="#section-toc.1-1.8.1" class="pilcrow">¶</a></p>
</li>
          <li class="compact toc ulEmpty" id="section-toc.1-1.9">
            <p id="section-toc.1-1.9.1"><a href="#section-9" class="xref">9</a>.  <a href="#name-security-considerations" class="xref">Security Considerations</a><a href="#section-toc.1-1.9.1" class="pilcrow">¶</a></p>
</li>
          <li class="compact toc ulEmpty" id="section-toc.1-1.10">
            <p id="section-toc.1-1.10.1"><a href="#section-10" class="xref">10</a>. <a href="#name-iana-considerations" class="xref">IANA Considerations</a><a href="#section-toc.1-1.10.1" class="pilcrow">¶</a></p>
</li>
          <li class="compact toc ulEmpty" id="section-toc.1-1.11">
            <p id="section-toc.1-1.11.1"><a href="#section-11" class="xref">11</a>. <a href="#name-informative-references" class="xref">Informative References</a><a href="#section-toc.1-1.11.1" class="pilcrow">¶</a></p>
</li>
          <li class="compact toc ulEmpty" 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><a href="#section-toc.1-1.12.1" class="pilcrow">¶</a></p>
</li>
          <li class="compact toc ulEmpty" 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><a href="#section-toc.1-1.13.1" class="pilcrow">¶</a></p>
</li>
          <li class="compact toc ulEmpty" 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><a href="#section-toc.1-1.14.1" class="pilcrow">¶</a></p>
</li>
        </ul>
</nav>
</section>
</div>
<section id="section-1">
      <h2 id="name-introduction">
<a href="#section-1" class="section-number selfRef">1. </a><a href="#name-introduction" class="section-name selfRef">Introduction</a>
      </h2>
<p id="section-1-1">Service Function Chaining (SFC) enables the creation of composite
      services that consist of an ordered set of Service Functions (SFs) that
      are to be applied to any traffic selected as a result of classification
      <span>[<a href="#RFC7665" class="xref">RFC7665</a>]</span>. SFC is a concept that
      provides for more than just the application of an ordered set of SFs to
      selected traffic; rather, it describes a method for deploying SFs in a
      way that enables dynamic ordering and topological independence of those
      SFs as well as the exchange of metadata between participating
      entities. The foundations of SFC are described in the following
      documents:<a href="#section-1-1" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-1-2.1">SFC Problem Statement <span>[<a href="#RFC7498" class="xref">RFC7498</a>]</span><a href="#section-1-2.1" class="pilcrow">¶</a>
</li>
        <li class="normal" id="section-1-2.2">SFC Architecture <span>[<a href="#RFC7665" class="xref">RFC7665</a>]</span><a href="#section-1-2.2" class="pilcrow">¶</a>
</li>
      </ul>
<p id="section-1-3">The reader is assumed to be familiar with the material in <span>[<a href="#RFC7665" class="xref">RFC7665</a>]</span>.<a href="#section-1-3" class="pilcrow">¶</a></p>
<p id="section-1-4">This document provides a reference framework for Operations,
      Administration, and Maintenance (OAM) <span>[<a href="#RFC6291" class="xref">RFC6291</a>]</span> of SFC. Specifically, this document provides:<a href="#section-1-4" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-1-5.1">an SFC layering model (<a href="#_SFC_Layer" class="xref">Section 2</a>),<a href="#section-1-5.1" class="pilcrow">¶</a>
</li>
        <li class="normal" id="section-1-5.2">aspects monitored by SFC OAM (<a href="#_SFC_OAM_Comp" class="xref">Section 3</a>),<a href="#section-1-5.2" class="pilcrow">¶</a>
</li>
        <li class="normal" id="section-1-5.3">functional requirements for SFC OAM (<a href="#_SFC_OAM_Func" class="xref">Section 4</a>),<a href="#section-1-5.3" class="pilcrow">¶</a>
</li>
        <li class="normal" id="section-1-5.4">a gap analysis for SFC OAM (<a href="#_Gap" class="xref">Section 5</a>),<a href="#section-1-5.4" class="pilcrow">¶</a>
</li>
        <li class="normal" id="section-1-5.5">operational aspects of SFC OAM at the service layer (<a href="#OPS_ASPECTS" class="xref">Section 6</a>),<a href="#section-1-5.5" class="pilcrow">¶</a>
</li>
        <li class="normal" id="section-1-5.6">applicability of various OAM tools (<a href="#_SFC_OAM_MODEL" class="xref">Section 7</a>), and<a href="#section-1-5.6" class="pilcrow">¶</a>
</li>
        <li class="normal" id="section-1-5.7">manageability considerations for SF and SFC (<a href="#Manageability" class="xref">Section 8</a>).<a href="#section-1-5.7" class="pilcrow">¶</a>
</li>
      </ul>
<p id="section-1-6">SFC OAM solution documents should refer to this document to indicate
      the SFC OAM component and the functionality they target.<a href="#section-1-6" class="pilcrow">¶</a></p>
<p id="section-1-7">OAM controllers are SFC-aware network devices that are capable of
      generating OAM packets. They should be within the same administrative
      domain as the target SFC-enabled domain.<a href="#section-1-7" class="pilcrow">¶</a></p>
<section id="section-1.1">
        <h3 id="name-document-scope">
<a href="#section-1.1" class="section-number selfRef">1.1. </a><a href="#name-document-scope" class="section-name selfRef">Document Scope</a>
        </h3>
<p id="section-1.1-1">The focus of this document is to provide an architectural framework
 for SFC OAM, particularly focused on the aspect of the Operations
 component within OAM. Actual solutions and mechanisms are outside the
 scope of this document.<a href="#section-1.1-1" class="pilcrow">¶</a></p>
</section>
<section id="section-1.2">
        <h3 id="name-acronyms-and-terminology">
<a href="#section-1.2" class="section-number selfRef">1.2. </a><a href="#name-acronyms-and-terminology" class="section-name selfRef">Acronyms and Terminology</a>
        </h3>
<section id="section-1.2.1">
          <h4 id="name-acronyms">
<a href="#section-1.2.1" class="section-number selfRef">1.2.1. </a><a href="#name-acronyms" class="section-name selfRef">Acronyms</a>
          </h4>
<span class="break"></span><dl class="dlParallel" id="section-1.2.1-1">
            <dt id="section-1.2.1-1.1">BFD</dt>
            <dd style="margin-left: 5.5em" id="section-1.2.1-1.2">Bidirectional Forwarding Detection<a href="#section-1.2.1-1.2" class="pilcrow">¶</a>
</dd>
            <dd class="break"></dd>
<dt id="section-1.2.1-1.3">CLI</dt>
            <dd style="margin-left: 5.5em" id="section-1.2.1-1.4">Command-Line Interface<a href="#section-1.2.1-1.4" class="pilcrow">¶</a>
</dd>
            <dd class="break"></dd>
<dt id="section-1.2.1-1.5">DWDM</dt>
            <dd style="margin-left: 5.5em" id="section-1.2.1-1.6">Dense Wavelength Division Multiplexing<a href="#section-1.2.1-1.6" class="pilcrow">¶</a>
</dd>
            <dd class="break"></dd>
<dt id="section-1.2.1-1.7">E-OAM</dt>
            <dd style="margin-left: 5.5em" id="section-1.2.1-1.8">Ethernet OAM<a href="#section-1.2.1-1.8" class="pilcrow">¶</a>
</dd>
            <dd class="break"></dd>
<dt id="section-1.2.1-1.9">hSFC</dt>
            <dd style="margin-left: 5.5em" id="section-1.2.1-1.10">Hierarchical Service Function Chaining<a href="#section-1.2.1-1.10" class="pilcrow">¶</a>
</dd>
            <dd class="break"></dd>
<dt id="section-1.2.1-1.11">IBN</dt>
            <dd style="margin-left: 5.5em" id="section-1.2.1-1.12">Internal Boundary Node<a href="#section-1.2.1-1.12" class="pilcrow">¶</a>
</dd>
            <dd class="break"></dd>
<dt id="section-1.2.1-1.13">IPPM</dt>
            <dd style="margin-left: 5.5em" id="section-1.2.1-1.14">IP Performance Metrics<a href="#section-1.2.1-1.14" class="pilcrow">¶</a>
</dd>
            <dd class="break"></dd>
<dt id="section-1.2.1-1.15">MPLS</dt>
            <dd style="margin-left: 5.5em" id="section-1.2.1-1.16">Multiprotocol Label Switching<a href="#section-1.2.1-1.16" class="pilcrow">¶</a>
</dd>
            <dd class="break"></dd>
<dt id="section-1.2.1-1.17">MPLS_PM</dt>
            <dd style="margin-left: 5.5em" id="section-1.2.1-1.18">MPLS Performance Measurement<a href="#section-1.2.1-1.18" class="pilcrow">¶</a>
</dd>
            <dd class="break"></dd>
<dt id="section-1.2.1-1.19">NETCONF</dt>
            <dd style="margin-left: 5.5em" id="section-1.2.1-1.20">Network Configuration Protocol<a href="#section-1.2.1-1.20" class="pilcrow">¶</a>
</dd>
            <dd class="break"></dd>
<dt id="section-1.2.1-1.21">NSH</dt>
            <dd style="margin-left: 5.5em" id="section-1.2.1-1.22">Network Service Header<a href="#section-1.2.1-1.22" class="pilcrow">¶</a>
</dd>
            <dd class="break"></dd>
<dt id="section-1.2.1-1.23">NVO3</dt>
            <dd style="margin-left: 5.5em" id="section-1.2.1-1.24">Network Virtualization over Layer 3<a href="#section-1.2.1-1.24" class="pilcrow">¶</a>
</dd>
            <dd class="break"></dd>
<dt id="section-1.2.1-1.25">OAM</dt>
            <dd style="margin-left: 5.5em" id="section-1.2.1-1.26">Operations, Administration, and Maintenance<a href="#section-1.2.1-1.26" class="pilcrow">¶</a>
</dd>
            <dd class="break"></dd>
<dt id="section-1.2.1-1.27">POS</dt>
            <dd style="margin-left: 5.5em" id="section-1.2.1-1.28">Packet over SONET<a href="#section-1.2.1-1.28" class="pilcrow">¶</a>
</dd>
            <dd class="break"></dd>
<dt id="section-1.2.1-1.29">RSP</dt>
            <dd style="margin-left: 5.5em" id="section-1.2.1-1.30">Rendered Service Path<a href="#section-1.2.1-1.30" class="pilcrow">¶</a>
</dd>
            <dd class="break"></dd>
<dt id="section-1.2.1-1.31">SF</dt>
            <dd style="margin-left: 5.5em" id="section-1.2.1-1.32">Service Function<a href="#section-1.2.1-1.32" class="pilcrow">¶</a>
</dd>
            <dd class="break"></dd>
<dt id="section-1.2.1-1.33">SFC</dt>
            <dd style="margin-left: 5.5em" id="section-1.2.1-1.34">Service Function Chain<a href="#section-1.2.1-1.34" class="pilcrow">¶</a>
</dd>
            <dd class="break"></dd>
<dt id="section-1.2.1-1.35">SFF</dt>
            <dd style="margin-left: 5.5em" id="section-1.2.1-1.36">Service Function Forwarder<a href="#section-1.2.1-1.36" class="pilcrow">¶</a>
</dd>
            <dd class="break"></dd>
<dt id="section-1.2.1-1.37">SFP</dt>
            <dd style="margin-left: 5.5em" id="section-1.2.1-1.38">Service Function Path<a href="#section-1.2.1-1.38" class="pilcrow">¶</a>
</dd>
            <dd class="break"></dd>
<dt id="section-1.2.1-1.39">SNMP</dt>
            <dd style="margin-left: 5.5em" id="section-1.2.1-1.40">Simple Network Management Protocol<a href="#section-1.2.1-1.40" class="pilcrow">¶</a>
</dd>
            <dd class="break"></dd>
<dt id="section-1.2.1-1.41">TRILL</dt>
            <dd style="margin-left: 5.5em" id="section-1.2.1-1.42">Transparent Interconnection of Lots of Links<a href="#section-1.2.1-1.42" class="pilcrow">¶</a>
</dd>
            <dd class="break"></dd>
<dt id="section-1.2.1-1.43">VM</dt>
            <dd style="margin-left: 5.5em" id="section-1.2.1-1.44">Virtual Machine<a href="#section-1.2.1-1.44" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
</dl>
</section>
<section id="section-1.2.2">
          <h4 id="name-terminology">
<a href="#section-1.2.2" class="section-number selfRef">1.2.2. </a><a href="#name-terminology" class="section-name selfRef">Terminology</a>
          </h4>
<p id="section-1.2.2-1">This document uses the terminology defined in <span>[<a href="#RFC7665" class="xref">RFC7665</a>]</span> and <span>[<a href="#RFC8300" class="xref">RFC8300</a>]</span>, and readers are expected to be familiar
   with it.<a href="#section-1.2.2-1" class="pilcrow">¶</a></p>
</section>
</section>
</section>
<div id="_SFC_Layer">
<section id="section-2">
      <h2 id="name-sfc-layering-model">
<a href="#section-2" class="section-number selfRef">2. </a><a href="#name-sfc-layering-model" class="section-name selfRef">SFC Layering Model</a>
      </h2>
<p id="section-2-1">Multiple layers come into play for implementing the SFC. These
      include the service layer and the underlying layers (network layer, link
      layer, etc.).<a href="#section-2-1" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-2-2.1">The service layer consists of SFC data-plane elements that
 include classifiers, Service Functions (SFs), Service Function
 Forwarders (SFF), and SFC Proxies. This layer uses the overlay network
 layer for ensuring connectivity between SFC data-plane elements.<a href="#section-2-2.1" class="pilcrow">¶</a>
</li>
        <li class="normal" id="section-2-2.2">The overlay network layer leverages various overlay network
 technologies (e.g., Virtual eXtensible Local Area Network
 (VXLAN)) for interconnecting SFC data-plane elements and 
 allows establishing Service Function Paths (SFPs). This layer is
 mostly transparent to the SFC data-plane elements, as not all the data-plane elements process the overlay header.<a href="#section-2-2.2" class="pilcrow">¶</a>
</li>
        <li class="normal" id="section-2-2.3">The underlay network layer is dictated by the networking
 technology deployed within a network (e.g., IP, MPLS).<a href="#section-2-2.3" class="pilcrow">¶</a>
</li>
        <li class="normal" id="section-2-2.4">The link layer is tightly coupled with the physical
 technology used. Ethernet is one such choice for this layer, but other
 alternatives may be deployed (e.g., POS and DWDM). In a virtual environment,
 virtualized I/O technologies, such as Single Root I/O Virtualization
 (SR-IOV) or similar, are also 
 applicable for this layer. The same or distinct link layer
 technologies may be used in each leg shown in <a href="#SFC-example" class="xref">Figure 1</a>.<a href="#section-2-2.4" class="pilcrow">¶</a>
</li>
      </ul>
<p id="section-2-3" class="keepWithNext"></p>
<span id="name-sfc-layering-example"></span><div id="SFC-example">
<figure id="figure-1">
        <div class="artwork art-text alignLeft" id="section-2-4.1">
<pre>
   o----------------------Service Layer----------------------o

+------+   +---+   +---+   +---+   +---+   +---+   +---+   +---+
|Classi|---|SF1|---|SF2|---|SF3|---|SF4|---|SF5|---|SF6|---|SF7|
|fier  |   +---+   +---+   +---+   +---+   +---+   +---+   +---+
+------+
             &lt;------VM1------&gt;       &lt;--VM2--&gt;       &lt;--VM3--&gt;

   ^-----------------^-------------------^---------------^  Overlay
                                                            Network

   o-----------------o-------------------o---------------o  Underlay
                                                            Network

   o--------o--------o--------o----------o-------o-------o  Link
</pre>
</div>
<figcaption><a href="#figure-1" class="selfRef">Figure 1</a>:
<a href="#name-sfc-layering-example" class="selfRef">SFC Layering Example</a>
        </figcaption></figure>
</div>
<p id="section-2-5">In <a href="#SFC-example" class="xref">Figure 1</a>, the service-layer elements, such as
      classifier and SF, are depicted as virtual entities that are
      interconnected using an overlay network. The underlay network may
      comprise multiple intermediate nodes not shown in the figure that
      provide underlay connectivity between the service-layer elements.<a href="#section-2-5" class="pilcrow">¶</a></p>
<p id="section-2-6">While <a href="#SFC-example" class="xref">Figure 1</a> depicts an example where SFs are
      enabled as virtual entities, the SFC architecture does not make any
      assumptions on how the SFC data-plane elements are deployed. The SFC
      architecture is flexible and accommodates physical or virtual entity
      deployment. SFC OAM accounts for this flexibility, and accordingly it is
      applicable whether SFC data-plane elements are deployed directly on
      physical hardware, as one or more virtual entities, or any combination
      thereof.<a href="#section-2-6" class="pilcrow">¶</a></p>
</section>
</div>
<div id="_SFC_OAM_Comp">
<section id="section-3">
      <h2 id="name-sfc-oam-components">
<a href="#section-3" class="section-number selfRef">3. </a><a href="#name-sfc-oam-components" class="section-name selfRef">SFC OAM Components</a>
      </h2>
<p id="section-3-1">The SFC operates at the service layer. For the purpose of defining
      the OAM framework, the service layer is broken up into three distinct
      components:<a href="#section-3-1" class="pilcrow">¶</a></p>
<span class="break"></span><dl class="dlNewline" id="section-3-2">
        <dt id="section-3-2.1">SF component:</dt>
        <dd style="margin-left: 1.5em" id="section-3-2.2">OAM functions applicable at this component include
 testing the SFs from any SFC-aware network device (e.g., classifiers,
 controllers, and other service nodes). Testing an SF may be more expansive
 than just checking connectivity to the SF, such as checking if the SF
 is providing its intended service. Refer to <a href="#SF-avail" class="xref">Section 3.1.1</a>
 for a more detailed discussion.<a href="#section-3-2.2" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
<dt id="section-3-2.3">SFC component:</dt>
        <dd style="margin-left: 1.5em" id="section-3-2.4">OAM functions applicable at this component include
 (but are not limited to) testing the SFCs and the
 SFPs, validation of the correlation between an SFC and the actual
 forwarding path followed by a packet matching that SFC, i.e., the
 Rendered Service Path (RSP). Some of the hops of an SFC may not be
 visible when Hierarchical Service Function Chaining (hSFC) <span>[<a href="#RFC8459" class="xref">RFC8459</a>]</span> is in use. In such schemes, it is
 the responsibility of the Internal Boundary Node (IBN) to glue the
 connectivity between different levels for end-to-end OAM
 functionality.<a href="#section-3-2.4" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
<dt id="section-3-2.5">Classifier component:</dt>
        <dd style="margin-left: 1.5em" id="section-3-2.6">OAM functions applicable at this component
 include testing the validity of the classification rules and detecting
 any incoherence among the rules installed when more than one
 classifier is used, as explained in <span><a href="https://www.rfc-editor.org/rfc/rfc7665#section-2.2" class="relref">Section 2.2</a> of [<a href="#RFC7665" class="xref">RFC7665</a>]</span>.<a href="#section-3-2.6" class="pilcrow">¶</a>
</dd>
      <dd class="break"></dd>
</dl>
<p id="section-3-3"><a href="#SFC-OAM" class="xref">Figure 2</a> illustrates an example where OAM for the
      three defined components are used within the SFC environment.<a href="#section-3-3" class="pilcrow">¶</a></p>
<p id="section-3-4" class="keepWithNext"></p>
<span id="name-sfc-oam-components-2"></span><div id="SFC-OAM">
<figure id="figure-2">
        <div class="artwork art-text alignLeft" id="section-3-5.1">
<pre>
+-Classifier  +-Service Function Chain OAM
| OAM         |
|             |        ___________________________________________
|              \      /\          Service Function Chain          \
|               \    /  \      +---+      +---+     +-----+  +---+ \
|                \  /    \     |SF1|      |SF2|     |Proxy|--|SF3|  \
|      +------+   \/      \    +---+      +---+     +-----+  +---+   \
+----&gt; |      |...(+-&gt;     )     |          |         |               )
       |Classi|    \      /   +-----+    +-----+    +-----+          /
       |fier  |     \    /    | SFF1|----| SFF2|----| SFF3|         /
       |      |      \  /     +--^--+    +-----+    +-----+        /
       +----|-+       \/_________|________________________________/
            |                    |
            +-------SF_OAM-------+
                                     +---+   +---+
                             +SF_OAM&gt;|SF3|   |SF5|
                             |       +-^-+   +-^-+
                      +------|---+     |       |
                      |Controller|     +-SF_OAM+
                      +----------+
                           Service Function OAM (SF_OAM)
</pre>
</div>
<figcaption><a href="#figure-2" class="selfRef">Figure 2</a>:
<a href="#name-sfc-oam-components-2" class="selfRef">SFC OAM Components</a>
        </figcaption></figure>
</div>
<p id="section-3-6">It is expected that multiple SFC OAM solutions will be defined, each
      targeting one specific component of the service layer. However, it is
      critical that SFC OAM solutions together provide the coverage of all
      three SFC OAM components: the SF component, the SFC component, and the
      classifier component.<a href="#section-3-6" class="pilcrow">¶</a></p>
<section id="section-3.1">
        <h3 id="name-the-sf-component">
<a href="#section-3.1" class="section-number selfRef">3.1. </a><a href="#name-the-sf-component" class="section-name selfRef">The SF Component</a>
        </h3>
<div id="SF-avail">
<section id="section-3.1.1">
          <h4 id="name-sf-availability">
<a href="#section-3.1.1" class="section-number selfRef">3.1.1. </a><a href="#name-sf-availability" class="section-name selfRef">SF Availability</a>
          </h4>
<p id="section-3.1.1-1">One SFC OAM requirement for the SF component is to allow an
   SFC-aware network device to check the availability of a specific SF
   (instance), located on the same or different network device(s). For
   cases where multiple instances of an SF are used to realize a given
   SF for the purpose of load sharing, SF availability can be performed
   by checking the availability of any one of those instances, or the
   availability check may be targeted at a specific instance. SF
   availability is an aspect that raises an interesting question: How
   does one determine that an SF is available?  At one end
   of the spectrum, one might argue that an SF is sufficiently
   available if the service node (physical or virtual) hosting the SF
   is available and is functional.  At the other end of the spectrum,
   one might argue that the SF's availability can only be deduced if
   the packet, after passing through the SF, was examined and it was
   verified that the packet did indeed get the expected service.<a href="#section-3.1.1-1" class="pilcrow">¶</a></p>
<p id="section-3.1.1-2">The former approach will likely not provide sufficient confidence
   about the actual SF availability, i.e., a service node and an SF are two
   different entities.  The latter approach is capable of providing an
   extensive verification but comes at a cost.  Some SFs make direct
   modifications to packets, while others do not.  Additionally, the
   purpose of some SFs may be to drop certain packets
   intentionally.  In such cases, it is normal behavior that certain
   packets will not be egressing out from the SF.  The
   OAM mechanism needs to take into account such SF specifics when
   assessing SF availability. Note that there are many flavors of SFs
   available and many more that are likely be introduced in the future.
   Even a given SF may introduce a new functionality (e.g., a new
   signature in a firewall).  The cost of this approach is that the OAM
   mechanism for some SF will need to be continuously modified in order
   to "keep up" with new functionality being introduced.<a href="#section-3.1.1-2" class="pilcrow">¶</a></p>
<p id="section-3.1.1-3">The SF availability check can be performed using a generalized
   approach, i.e., at an adequate granularity to provide a basic SF
   service.  The task of evaluating the true availability of an SF is a complex activity, currently having no simple, unified
   solution.  There is currently no standard means of doing so. Any
   such mechanism would be far from a typical OAM function, so it is
   not explored as part of the analysis in Sections <a href="#_SFC_OAM_Func" class="xref">4</a> and <a href="#_Gap" class="xref">5</a>.<a href="#section-3.1.1-3" class="pilcrow">¶</a></p>
</section>
</div>
<section id="section-3.1.2">
          <h4 id="name-sf-performance-measurement">
<a href="#section-3.1.2" class="section-number selfRef">3.1.2. </a><a href="#name-sf-performance-measurement" class="section-name selfRef">SF Performance Measurement</a>
          </h4>
<p id="section-3.1.2-1">The second SFC OAM requirement for the SF component is to allow
   an SFC-aware network device to check the performance metrics, such as
   loss and delay induced by a specific SF for processing legitimate
   traffic. Performance measurement can be passive by using live
   traffic, an active measurement by using synthetic probe packets, or
   a hybrid method that uses a combination of active and passive
   measurement. More details about this OAM function is explained in
   <a href="#Perform_Funct" class="xref">Section 4.4</a>.<a href="#section-3.1.2-1" class="pilcrow">¶</a></p>
<p id="section-3.1.2-2">On the one hand, the performance of any specific SF can be quantified by
 measuring the loss and delay metrics of the traffic from the SFF to the respective 
 SF, while on the other hand, the performance can be measured by 
 leveraging the loss and delay metrics from the respective SFs. The 
 latter requires SF involvement to perform the measurement, while the 
 former does not. For cases where multiple instances of an SF are used to realize a    
 given SF for the purpose of load sharing, SF performance can be quantified by 
 measuring the metrics for any one instance of SF or by measuring the metrics for 
 a specific instance.<a href="#section-3.1.2-2" class="pilcrow">¶</a></p>
<p id="section-3.1.2-3">The metrics measured to quantify the performance of the SF
   component are not just limited to loss and delay. Other metrics, such
   as throughput, also exist and the choice of metrics for performance
   measurement is outside the scope of this document.<a href="#section-3.1.2-3" class="pilcrow">¶</a></p>
</section>
</section>
<section id="section-3.2">
        <h3 id="name-the-sfc-component">
<a href="#section-3.2" class="section-number selfRef">3.2. </a><a href="#name-the-sfc-component" class="section-name selfRef">The SFC Component</a>
        </h3>
<section id="section-3.2.1">
          <h4 id="name-sfc-availability">
<a href="#section-3.2.1" class="section-number selfRef">3.2.1. </a><a href="#name-sfc-availability" class="section-name selfRef">SFC Availability</a>
          </h4>
<p id="section-3.2.1-1">An SFC could comprise varying SFs, and so the OAM layer is
   required to perform validation and verification of SFs within an
   SFP, in addition to connectivity verification and fault
   isolation.<a href="#section-3.2.1-1" class="pilcrow">¶</a></p>
<p id="section-3.2.1-2">In order to perform service connectivity verification of an
   SFC/SFP, the OAM functions could be initiated from any SFC-aware
   network device of an SFC-enabled domain for end-to-end paths, or
   partial paths terminating on a specific SF, within the SFC/SFP. The
   goal of this OAM function is to ensure the SFs chained together have
   connectivity, as was intended at the time when the SFC was
   established. The necessary return codes should be defined for
   sending back in the response to the OAM packet, in order to complete
   the verification.<a href="#section-3.2.1-2" class="pilcrow">¶</a></p>
<p id="section-3.2.1-3">When ECMP is in use at the service layer for any given SFC, there
   must be the ability to discover and traverse all available
   paths.<a href="#section-3.2.1-3" class="pilcrow">¶</a></p>
<p id="section-3.2.1-4">A detailed explanation of the mechanism is outside the scope of
   this document and is expected to be included in the actual solution
   document.<a href="#section-3.2.1-4" class="pilcrow">¶</a></p>
</section>
<section id="section-3.2.2">
          <h4 id="name-sfc-performance-measurement">
<a href="#section-3.2.2" class="section-number selfRef">3.2.2. </a><a href="#name-sfc-performance-measurement" class="section-name selfRef">SFC Performance Measurement</a>
          </h4>
<p id="section-3.2.2-1">Any SFC-aware network device should have the ability to make
   performance measurements over the entire SFC (i.e., end-to-end) or
   on a specific segment of SFs within the SFC.<a href="#section-3.2.2-1" class="pilcrow">¶</a></p>
</section>
</section>
<section id="section-3.3">
        <h3 id="name-classifier-component">
<a href="#section-3.3" class="section-number selfRef">3.3. </a><a href="#name-classifier-component" class="section-name selfRef">Classifier Component</a>
        </h3>
<p id="section-3.3-1">A classifier maintains the classification rules that map a flow to
 a specific SFC. It is vital that the classifier is correctly
 configured with updated classification rules and is functioning as
 expected. The SFC OAM must be able to validate the classification
 rules by assessing whether a flow is appropriately mapped to the
 relevant SFC and detect any misclassification. Sample OAM packets can
 be presented to the classifiers to assess the behavior with regard to
 a given classification entry.<a href="#section-3.3-1" class="pilcrow">¶</a></p>
<p id="section-3.3-2">The classifier availability check may be performed to check the
 availability of the classifier to apply the rules and classify the
 traffic flows. Any SFC-aware network device should have the ability to
 perform availability checking of the classifier component for each
 SFC.<a href="#section-3.3-2" class="pilcrow">¶</a></p>
<p id="section-3.3-3">Any SFC-aware network device should have the ability to perform
 performance measurement of the classifier component for each SFC. The
 performance can be quantified by measuring the performance metrics of
 the traffic from the classifier for each SFC/SFP.<a href="#section-3.3-3" class="pilcrow">¶</a></p>
</section>
<section id="section-3.4">
        <h3 id="name-underlay-network">
<a href="#section-3.4" class="section-number selfRef">3.4. </a><a href="#name-underlay-network" class="section-name selfRef">Underlay Network</a>
        </h3>
<p id="section-3.4-1">The underlay network provides connectivity between the SFC
 components, so the availability or the performance of the underlay
 network directly impacts the SFC OAM.<a href="#section-3.4-1" class="pilcrow">¶</a></p>
<p id="section-3.4-2">Any SFC-aware network device may have the ability to perform an
 availability check or performance measurement of the underlay network
 using any existing OAM functions listed in Section 5.1.<a href="#section-3.4-2" class="pilcrow">¶</a></p>
</section>
<section id="section-3.5">
        <h3 id="name-overlay-network">
<a href="#section-3.5" class="section-number selfRef">3.5. </a><a href="#name-overlay-network" class="section-name selfRef">Overlay Network</a>
        </h3>
<p id="section-3.5-1">The overlay network provides connectivity for the service plane between
 the SFC components and is mostly transparent to the SFC data-plane
 elements.<a href="#section-3.5-1" class="pilcrow">¶</a></p>
<p id="section-3.5-2">Any SFC-aware network device may have the ability to perform an
 availability check or performance measurement of the overlay network
 using any existing OAM functions listed in <a href="#_Exist_FUNC" class="xref">Section 5.1</a>.<a href="#section-3.5-2" class="pilcrow">¶</a></p>
</section>
</section>
</div>
<div id="_SFC_OAM_Func">
<section id="section-4">
      <h2 id="name-sfc-oam-functions">
<a href="#section-4" class="section-number selfRef">4. </a><a href="#name-sfc-oam-functions" class="section-name selfRef">SFC OAM Functions</a>
      </h2>
<p id="section-4-1"><a href="#_SFC_OAM_Comp" class="xref">Section 3</a> described SFC OAM
      components and the associated OAM operations on each of them. This
      section explores SFC OAM functions that are applicable for more than one
      SFC component.<a href="#section-4-1" class="pilcrow">¶</a></p>
<p id="section-4-2">The various SFC OAM requirements listed in <a href="#_SFC_OAM_Comp" class="xref">Section 3</a> highlight the need for
      various OAM functions at the service layer. As listed in <a href="#_Exist_FUNC" class="xref">Section 5.1</a>,
      various OAM functions are in existence that are defined to perform OAM
      functionality at different layers. In order to apply such OAM functions
      at the service layer, they need to be enhanced to operate on a single
      SF/SFF or multiple SFs/SFFs spanning across one or more SFCs.<a href="#section-4-2" class="pilcrow">¶</a></p>
<div id="Connect_Func">
<section id="section-4.1">
        <h3 id="name-connectivity-functions">
<a href="#section-4.1" class="section-number selfRef">4.1. </a><a href="#name-connectivity-functions" class="section-name selfRef">Connectivity Functions</a>
        </h3>
<p id="section-4.1-1">Connectivity is mainly an on-demand function to verify that
 connectivity exists between certain network elements and that the SFs
 are available. For example, Label Switched Path (LSP) Ping <span>[<a href="#RFC8029" class="xref">RFC8029</a>]</span> is a common tool used to perform this function for
 an MPLS network. Some of the OAM functions performed by connectivity
 functions are as follows:<a href="#section-4.1-1" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-4.1-2.1">Verify the Path MTU from a source to the destination SF or
   through the SFC. This requires the ability for the OAM packet to be
   of variable length.<a href="#section-4.1-2.1" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-4.1-2.2">Detect any packet reordering and corruption.<a href="#section-4.1-2.2" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-4.1-2.3">Verify that an SFC or SF is applying the expected policy.<a href="#section-4.1-2.3" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-4.1-2.4">Verify and validate forwarding paths.<a href="#section-4.1-2.4" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-4.1-2.5">Proactively test alternate or protected paths to ensure
   reliability of network configurations.<a href="#section-4.1-2.5" class="pilcrow">¶</a>
</li>
        </ul>
</section>
</div>
<section id="section-4.2">
        <h3 id="name-continuity-functions">
<a href="#section-4.2" class="section-number selfRef">4.2. </a><a href="#name-continuity-functions" class="section-name selfRef">Continuity Functions</a>
        </h3>
<p id="section-4.2-1">Continuity is a model where OAM messages are sent periodically to
 validate or verify the reachability of a given SF within an SFC or for
 the entire SFC. This allows a monitoring network device (such as the
 classifier or controller) to quickly detect failures, such as link
 failures, network element failures, SF outages, or SFC outages. BFD
 <span>[<a href="#RFC5880" class="xref">RFC5880</a>]</span> is one such protocol that
 helps in detecting failures quickly. OAM functions supported by
 continuity functions are as follows:<a href="#section-4.2-1" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-4.2-2.1">Provision a continuity check to a given SF within an
   SFC or for the entire SFC.<a href="#section-4.2-2.1" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-4.2-2.2">Proactively test alternate or protected paths to ensure
   reliability of network configurations.<a href="#section-4.2-2.2" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-4.2-2.3">Notifying other OAM functions or applications of the detected
   failures so they can take appropriate action.<a href="#section-4.2-2.3" class="pilcrow">¶</a>
</li>
        </ul>
</section>
<section id="section-4.3">
        <h3 id="name-trace-functions">
<a href="#section-4.3" class="section-number selfRef">4.3. </a><a href="#name-trace-functions" class="section-name selfRef">Trace Functions</a>
        </h3>
<p id="section-4.3-1">Tracing is an OAM function that allows the operation to trigger an
 action (e.g., response generation) from every transit device (e.g., SFF,
 SF, and SFC Proxy) on the tested layer. This function is typically useful
 for gathering information from every transit device or for isolating
 the failure point to a specific SF within an SFC or for an entire
 SFC. Some of the OAM functions supported by trace functions are:<a href="#section-4.3-1" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-4.3-2.1">the ability to trigger an action from every transit device at the
   SFC layer, using TTL or other means,<a href="#section-4.3-2.1" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-4.3-2.2">the ability to trigger every transit device at the SFC layer to
   generate a response with OAM code(s) using TTL or other means,<a href="#section-4.3-2.2" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-4.3-2.3">the ability to discover and traverse ECMP paths within an SFC, and<a href="#section-4.3-2.3" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-4.3-2.4">the ability to skip SFs that do not support OAM while tracing SFs in an SFC.<a href="#section-4.3-2.4" class="pilcrow">¶</a>
</li>
        </ul>
</section>
<div id="Perform_Funct">
<section id="section-4.4">
        <h3 id="name-performance-measurement-fun">
<a href="#section-4.4" class="section-number selfRef">4.4. </a><a href="#name-performance-measurement-fun" class="section-name selfRef">Performance Measurement Functions</a>
        </h3>
<p id="section-4.4-1">Performance measurement functions involve measuring of packet loss,
 delay, delay variance, etc. These performance metrics may be measured
 proactively or on demand.<a href="#section-4.4-1" class="pilcrow">¶</a></p>
<p id="section-4.4-2">SFC OAM should provide the ability to measure packet loss for an
 SFC. On-demand measurement can be used to estimate packet loss using
 statistical methods. To ensure accurate estimations, one needs to
 ensure that OAM packets are treated the same and also share the same
 fate as regular data traffic.<a href="#section-4.4-2" class="pilcrow">¶</a></p>
<p id="section-4.4-3">Delay within an SFC could be measured based on the time it takes
 for a packet to traverse the SFC from the ingress SFC node to the
 egress SFF. Measurement protocols, such as the One-Way Active Measurement
 Protocol (OWAMP) <span>[<a href="#RFC4656" class="xref">RFC4656</a>]</span> and the Two-Way
 Active Measurement Protocol (TWAMP) <span>[<a href="#RFC5357" class="xref">RFC5357</a>]</span>, can be used to measure delay characteristics. As SFCs
 are unidirectional in nature, measurement of one-way delay <span>[<a href="#RFC7679" class="xref">RFC7679</a>]</span> is important. In order to measure
 one-way delay, time synchronization must be supported by means such as
 NTP, GPS, Precision Time Protocol (PTP), etc.<a href="#section-4.4-3" class="pilcrow">¶</a></p>
<p id="section-4.4-4">One-way delay variation <span>[<a href="#RFC3393" class="xref">RFC3393</a>]</span>
 could also be calculated by sending OAM packets and measuring the
 jitter for traffic passing through an SFC.<a href="#section-4.4-4" class="pilcrow">¶</a></p>
<p id="section-4.4-5">Some of the OAM functions supported by the performance measurement
 functions are:<a href="#section-4.4-5" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-4.4-6.1">the ability to measure the packet processing delay induced by a
      single SF or the one-way delay to traverse an SFP bound to a given
      SFC, and<a href="#section-4.4-6.1" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-4.4-6.2">the ability to measure the packet loss <span>[<a href="#RFC7680" class="xref">RFC7680</a>]</span> within an SF or an SFP bound to a given SFC.<a href="#section-4.4-6.2" class="pilcrow">¶</a>
</li>
        </ul>
</section>
</div>
</section>
</div>
<div id="_Gap">
<section id="section-5">
      <h2 id="name-gap-analysis">
<a href="#section-5" class="section-number selfRef">5. </a><a href="#name-gap-analysis" class="section-name selfRef">Gap Analysis</a>
      </h2>
<p id="section-5-1">This section identifies various OAM functions available at different
      layers introduced in <a href="#_SFC_Layer" class="xref">Section 2</a>. It also identifies various gaps that
      exist within the current toolset for performing OAM functions required
      for SFC.<a href="#section-5-1" class="pilcrow">¶</a></p>
<div id="_Exist_FUNC">
<section id="section-5.1">
        <h3 id="name-existing-oam-functions">
<a href="#section-5.1" class="section-number selfRef">5.1. </a><a href="#name-existing-oam-functions" class="section-name selfRef">Existing OAM Functions</a>
        </h3>
<p id="section-5.1-1">There are various OAM toolsets available to perform OAM functions
 within various layers. These OAM functions may be used to validate
 some of the underlay and overlay networks. Tools like ping and trace
 are in existence to perform connectivity checks and trace
 intermediate hops in a network. These tools support different network
 types, like IP, MPLS, TRILL, etc. Ethernet OAM (E-OAM) <span>[<a href="#Y.1731" class="xref">Y.1731</a>]</span> <span>[<a href="#EFM" class="xref">EFM</a>]</span> and Connectivity Fault Management (CFM) <span>[<a href="#DOT1Q" class="xref">DOT1Q</a>]</span> offer OAM mechanisms, such as a
 continuity check for Ethernet links. There is an effort
 around NVO3 OAM to provide connectivity and continuity checks for
 networks that use NVO3.  BFD is used for the detection of data-plane
 forwarding failures. The IPPM framework <span>[<a href="#RFC2330" class="xref">RFC2330</a>]</span> offers tools such as OWAMP <span>[<a href="#RFC4656" class="xref">RFC4656</a>]</span> and TWAMP <span>[<a href="#RFC5357" class="xref">RFC5357</a>]</span>
 (collectively referred to as IPPM in this section) to measure various
 performance metrics. MPLS Packet Loss Measurement (LM) and Packet
 Delay Measurement (DM) (collectively referred to as MPLS_PM in this
 section) <span>[<a href="#RFC6374" class="xref">RFC6374</a>]</span> offer the ability
 to measure performance metrics in MPLS networks. There is also an
 effort to extend the toolset to provide connectivity and continuity
 checks within overlay networks. BFD is another tool that helps in
 detecting data forwarding failures. <a href="#OAM-Analysis" class="xref">Table 1</a>
 below is not exhaustive.<a href="#section-5.1-1" class="pilcrow">¶</a></p>
<p id="section-5.1-2" class="keepWithNext"></p>
<span id="name-oam-tool-gap-analysis"></span><div id="OAM-Analysis">
<table class="center" id="table-1">
          <caption>
<a href="#table-1" class="selfRef">Table 1</a>:
<a href="#name-oam-tool-gap-analysis" class="selfRef">OAM Tool Gap Analysis</a>
          </caption>
<thead>
            <tr>
              <th class="text-left" rowspan="1" colspan="1">Layer</th>
              <th class="text-left" rowspan="1" colspan="1">Connectivity</th>
              <th class="text-left" rowspan="1" colspan="1">Continuity</th>
              <th class="text-left" rowspan="1" colspan="1">Trace</th>
              <th class="text-left" rowspan="1" colspan="1">Performance</th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">Underlay network</td>
              <td class="text-left" rowspan="1" colspan="1">Ping</td>
              <td class="text-left" rowspan="1" colspan="1">E-OAM, BFD</td>
              <td class="text-left" rowspan="1" colspan="1">Trace</td>
              <td class="text-left" rowspan="1" colspan="1">IPPM, MPLS_PM</td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">Overlay network</td>
              <td class="text-left" rowspan="1" colspan="1">Ping</td>
              <td class="text-left" rowspan="1" colspan="1">BFD, NVO3 OAM</td>
              <td class="text-left" rowspan="1" colspan="1">Trace</td>
              <td class="text-left" rowspan="1" colspan="1">IPPM</td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">Classifier</td>
              <td class="text-left" rowspan="1" colspan="1">Ping</td>
              <td class="text-left" rowspan="1" colspan="1">BFD</td>
              <td class="text-left" rowspan="1" colspan="1">Trace</td>
              <td class="text-left" rowspan="1" colspan="1">None</td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">SF</td>
              <td class="text-left" rowspan="1" colspan="1">None</td>
              <td class="text-left" rowspan="1" colspan="1">None</td>
              <td class="text-left" rowspan="1" colspan="1">None</td>
              <td class="text-left" rowspan="1" colspan="1">None</td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">SFC</td>
              <td class="text-left" rowspan="1" colspan="1">None</td>
              <td class="text-left" rowspan="1" colspan="1">None</td>
              <td class="text-left" rowspan="1" colspan="1">None</td>
              <td class="text-left" rowspan="1" colspan="1">None</td>
            </tr>
          </tbody>
        </table>
</div>
</section>
</div>
<section id="section-5.2">
        <h3 id="name-missing-oam-functions">
<a href="#section-5.2" class="section-number selfRef">5.2. </a><a href="#name-missing-oam-functions" class="section-name selfRef">Missing OAM Functions</a>
        </h3>
<p id="section-5.2-1">As shown in <a href="#OAM-Analysis" class="xref">Table 1</a>, there are no
 standards-based tools available 
 at the time of this writing that can be used natively (i.e., without
 enhancement) for the verification of SFs and SFCs.<a href="#section-5.2-1" class="pilcrow">¶</a></p>
</section>
<section id="section-5.3">
        <h3 id="name-required-oam-functions">
<a href="#section-5.3" class="section-number selfRef">5.3. </a><a href="#name-required-oam-functions" class="section-name selfRef">Required OAM Functions</a>
        </h3>
<p id="section-5.3-1">Primary OAM functions exist for underlying layers. Tools like ping,
 trace, BFD, etc. exist in order to perform these OAM functions.<a href="#section-5.3-1" class="pilcrow">¶</a></p>
<p id="section-5.3-2">As depicted in <a href="#OAM-Analysis" class="xref">Table 1</a>, toolsets and solutions are required to
 perform the OAM functions at the service layer.<a href="#section-5.3-2" class="pilcrow">¶</a></p>
</section>
</section>
</div>
<div id="OPS_ASPECTS">
<section id="section-6">
      <h2 id="name-operational-aspects-of-sfc-">
<a href="#section-6" class="section-number selfRef">6. </a><a href="#name-operational-aspects-of-sfc-" class="section-name selfRef">Operational Aspects of SFC OAM at the Service Layer</a>
      </h2>
<p id="section-6-1">This section describes the operational aspects of SFC OAM at the
      service layer to perform the SFC OAM function defined in <a href="#_SFC_OAM_Func" class="xref">Section 4</a> and analyzes the applicability
      of various existing OAM toolsets in the service layer.<a href="#section-6-1" class="pilcrow">¶</a></p>
<section id="section-6.1">
        <h3 id="name-sfc-oam-packet-marker">
<a href="#section-6.1" class="section-number selfRef">6.1. </a><a href="#name-sfc-oam-packet-marker" class="section-name selfRef">SFC OAM Packet Marker</a>
        </h3>
<p id="section-6.1-1">SFC OAM messages should be encapsulated with the necessary SFC header
 and with OAM markings when testing the SFC component. SFC OAM messages
 may be encapsulated with the necessary SFC header and with OAM
 markings when testing the SF component.<a href="#section-6.1-1" class="pilcrow">¶</a></p>
<p id="section-6.1-2">The SFC OAM function described in <a href="#_SFC_OAM_Func" class="xref">Section 4</a> performed at the service layer or overlay network
 layer must mark the packet as an OAM packet so that relevant nodes can
 differentiate OAM packets from data packets. The base header defined
 in <span><a href="https://www.rfc-editor.org/rfc/rfc8300#section-2.2" class="relref">Section 2.2</a> of [<a href="#RFC8300" class="xref">RFC8300</a>]</span> assigns a
 bit to indicate OAM packets. When NSH encapsulation is used at the
 service layer, the O bit must be set to differentiate the OAM
 packet. Any other overlay encapsulations used at the service layer
 must have a way to mark the packet as an OAM packet.<a href="#section-6.1-2" class="pilcrow">¶</a></p>
</section>
<section id="section-6.2">
        <h3 id="name-oam-packet-processing-and-f">
<a href="#section-6.2" class="section-number selfRef">6.2. </a><a href="#name-oam-packet-processing-and-f" class="section-name selfRef">OAM Packet Processing and Forwarding Semantic</a>
        </h3>
<p id="section-6.2-1">Upon receiving an OAM packet, an SFC-aware SF may choose to discard
 the packet if it does not support OAM functionality or if the local
 policy prevents it from processing the OAM packet. When an SF
 supports OAM functionality, it is desirable to process the packet and
 provide an appropriate response to allow end-to-end verification. To
 limit performance impact due to OAM, SFC-aware SFs should rate-limit
 the number of OAM packets processed.<a href="#section-6.2-1" class="pilcrow">¶</a></p>
<p id="section-6.2-2">An SFF may choose to not forward the OAM packet to an SF if the SF
 does not support OAM or if the policy does not allow the forwarding of OAM
 packets to that SF. The SFF may choose to skip the SF, modify the
 packet's header,
 and forward the packet to the next SFC node in the chain. It should be noted that
 skipping an SF might have implications on some OAM functions (e.g., the
 delay measurement may not be accurate). The method by which an SFF
 detects if the connected SF supports or is allowed to process OAM
 packets is outside the scope of this document. It could be a
 configuration parameter instructed by the controller, or it can be done
 by dynamic negotiation between the SF and SFF.<a href="#section-6.2-2" class="pilcrow">¶</a></p>
<p id="section-6.2-3">If the SFF receiving the OAM packet bound to a given SFC is the
 last SFF in the chain, it must send a relevant response to the
 initiator of the OAM packet. Depending on the type of OAM solution and
 toolset used, the response could be a simple response (such as ICMP
 reply) or could include additional data from the received OAM packet
 (like statistical data consolidated along the path). The details are
 expected to be covered in the solution documents.<a href="#section-6.2-3" class="pilcrow">¶</a></p>
<p id="section-6.2-4">Any SFC-aware node that initiates an OAM packet must set the OAM
 marker in the overlay encapsulation.<a href="#section-6.2-4" class="pilcrow">¶</a></p>
</section>
<section id="section-6.3">
        <h3 id="name-oam-function-types">
<a href="#section-6.3" class="section-number selfRef">6.3. </a><a href="#name-oam-function-types" class="section-name selfRef">OAM Function Types</a>
        </h3>
<p id="section-6.3-1">As described in <a href="#_SFC_OAM_Func" class="xref">Section 4</a>,
 there are different OAM functions that may require different OAM
 solutions. While the presence of the OAM marker in the overlay header
 (e.g., O bit in the NSH header) indicates it as an OAM packet, it is
 not sufficient to indicate what OAM function the packet is intended
 for. The Next Protocol field in the NSH header may be used to indicate
 what OAM function is intended or what toolset is used. Any other
 overlay encapsulations used at the service layer must have a similar
 way to indicate the intended OAM function.<a href="#section-6.3-1" class="pilcrow">¶</a></p>
</section>
</section>
</div>
<div id="_SFC_OAM_MODEL">
<section id="section-7">
      <h2 id="name-candidate-sfc-oam-tools">
<a href="#section-7" class="section-number selfRef">7. </a><a href="#name-candidate-sfc-oam-tools" class="section-name selfRef">Candidate SFC OAM Tools</a>
      </h2>
<p id="section-7-1">As described in <a href="#_Exist_FUNC" class="xref">Section 5.1</a>, there
      are different toolsets available to perform  OAM functions at different
      layers. This section describe the applicability of some of the available
      toolsets in the service layer.<a href="#section-7-1" class="pilcrow">¶</a></p>
<section id="section-7.1">
        <h3 id="name-icmp">
<a href="#section-7.1" class="section-number selfRef">7.1. </a><a href="#name-icmp" class="section-name selfRef">ICMP</a>
        </h3>
<p id="section-7.1-1"><span>[<a href="#RFC0792" class="xref">RFC0792</a>]</span> and <span>[<a href="#RFC4443" class="xref">RFC4443</a>]</span> describe the use of ICMP in IPv4
 and IPv6 networks respectively. It explains how ICMP messages can be
 used to test the network reachability between different end points and
 perform basic network diagnostics.<a href="#section-7.1-1" class="pilcrow">¶</a></p>
<p id="section-7.1-2">ICMP could be leveraged for connectivity functions (defined in
 <a href="#Connect_Func" class="xref">Section 4.1</a>) to verify the availability of an SF or
 SFC. The initiator 
 can generate an ICMP echo request message and control the service-layer encapsulation header to get the response from the relevant
 node. For example, a classifier initiating OAM can generate an ICMP
 echo request message, set the TTL field in the NSH header <span>[<a href="#RFC8300" class="xref">RFC8300</a>]</span> to 63 to get the response from the
 last SFF, and thereby test the SFC availability. Alternatively, the
 initiator can set the TTL to some other value to get the response from
 a specific SF and thereby partially test SFC availability, or the
 initiator could send OAM packets with sequentially incrementing TTL in
 the NSH to trace the SFP.<a href="#section-7.1-2" class="pilcrow">¶</a></p>
<p id="section-7.1-3">It could be observed that ICMP as currently defined may not be able
 to perform all required SFC OAM functions, but as explained above, it
 can be used for some of the connectivity functions.<a href="#section-7.1-3" class="pilcrow">¶</a></p>
</section>
<section id="section-7.2">
        <h3 id="name-bfd-seamless-bfd">
<a href="#section-7.2" class="section-number selfRef">7.2. </a><a href="#name-bfd-seamless-bfd" class="section-name selfRef">BFD / Seamless BFD</a>
        </h3>
<p id="section-7.2-1"><span>[<a href="#RFC5880" class="xref">RFC5880</a>]</span> defines the Bidirectional
 Forwarding Detection (BFD) mechanism for failure detection. <span>[<a href="#RFC5881" class="xref">RFC5881</a>]</span> and <span>[<a href="#RFC5884" class="xref">RFC5884</a>]</span> define the applicability of BFD in IPv4, IPv6, and
 MPLS networks. <span>[<a href="#RFC7880" class="xref">RFC7880</a>]</span> defines
 Seamless BFD (S-BFD), a simplified mechanism of using BFD. <span>[<a href="#RFC7881" class="xref">RFC7881</a>]</span> explains its applicability in
 IPv4, IPv6, and MPLS networks.<a href="#section-7.2-1" class="pilcrow">¶</a></p>
<p id="section-7.2-2">BFD or S-BFD could be leveraged to perform the continuity function
 for SF or SFC. An initiator could generate a BFD control packet and
 set the "Your Discriminator" value in the
 control packet to identify the last SFF. Upon receiving the control packet, the last SFF in the
 SFC will reply back with the relevant DIAG code. The TTL field in the
 NSH header could be used to perform a partial SFC availability
 check. For example, the initiator can  set the "Your Discriminator"
 value to identify the SF that is intended to be tested and set the TTL
 field in the NSH header in a way that it expires at the relevant
 SF. How the initiator gets the Discriminator value to identify the SF
 is outside the scope of this document.<a href="#section-7.2-2" class="pilcrow">¶</a></p>
</section>
<section id="section-7.3">
        <h3 id="name-in-situ-oam">
<a href="#section-7.3" class="section-number selfRef">7.3. </a><a href="#name-in-situ-oam" class="section-name selfRef">In Situ OAM</a>
        </h3>
<p id="section-7.3-1"><span>[<a href="#I-D.ietf-sfc-ioam-nsh" class="xref">IOAM-NSH</a>]</span> defines how
 In situ OAM data fields <span>[<a href="#I-D.ietf-ippm-ioam-data" class="xref">IPPM-IOAM-DATA</a>]</span> are transported using the NSH header. <span>[<a href="#I-D.ietf-sfc-proof-of-transit" class="xref">PROOF-OF-TRANSIT</a>]</span> defines a
 mechanism to perform proof of transit to securely verify if a packet
 traversed the relevant SFP or SFC. While the mechanism is defined
 inband (i.e., it will be included in data packets), IOAM Option-Types,
 such as IOAM Trace Option-Types, can also be used to perform other SFC
 OAM functions, such as SFC tracing.<a href="#section-7.3-1" class="pilcrow">¶</a></p>
<p id="section-7.3-2">In situ OAM could be leveraged to perform SF availability  and SFC
 availability or performance measurement. For example, if SFC is
 realized using NSH, the O bit in the NSH header could be set to
 indicate the OAM traffic, as defined in <span><a href="https://tools.ietf.org/html/draft-ietf-sfc-ioam-nsh-04#section-4.2" class="relref">Section 4.2</a> of [<a href="#I-D.ietf-sfc-ioam-nsh" class="xref">IOAM-NSH</a>]</span>.<a href="#section-7.3-2" class="pilcrow">¶</a></p>
</section>
<section id="section-7.4">
        <h3 id="name-sfc-traceroute">
<a href="#section-7.4" class="section-number selfRef">7.4. </a><a href="#name-sfc-traceroute" class="section-name selfRef">SFC Traceroute</a>
        </h3>
<p id="section-7.4-1"><span>[<a href="#I-D.penno-sfc-trace" class="xref">SFC-TRACE</a>]</span> defines a
 protocol that checks for path liveliness and traces the service hops
 in any SFP. <span><a href="https://tools.ietf.org/html/draft-penno-sfc-trace-03#section-3" class="relref">Section 3</a> of [<a href="#I-D.penno-sfc-trace" class="xref">SFC-TRACE</a>]</span> defines the SFC trace packet format,
 while Sections <a href="https://tools.ietf.org/html/draft-penno-sfc-trace-03#section-4" class="relref">4</a> and <a href="https://tools.ietf.org/html/draft-penno-sfc-trace-03#section-5" class="relref">5</a> of <span>[<a href="#I-D.penno-sfc-trace" class="xref">SFC-TRACE</a>]</span>
 define the behavior of SF and SFF respectively. While <span>[<a href="#I-D.penno-sfc-trace" class="xref">SFC-TRACE</a>]</span> has expired, the
 proposal is implemented in Open Daylight and is available.<a href="#section-7.4-1" class="pilcrow">¶</a></p>
<p id="section-7.4-2">An initiator can control the Service Index Limit (SIL) in an SFC trace
 packet to perform SF and SFC availability tests.<a href="#section-7.4-2" class="pilcrow">¶</a></p>
</section>
</section>
</div>
<div id="Manageability">
<section id="section-8">
      <h2 id="name-manageability-consideration">
<a href="#section-8" class="section-number selfRef">8. </a><a href="#name-manageability-consideration" class="section-name selfRef">Manageability Considerations</a>
      </h2>
<p id="section-8-1">This document does not define any new manageability tools but
      consolidates the manageability tool gap analysis for SF and SFC. <a href="#OAM-Analysis-2" class="xref">Table 2</a> below is not exhaustive.<a href="#section-8-1" class="pilcrow">¶</a></p>
<p id="section-8-2" class="keepWithNext"></p>
<span id="name-oam-tool-gap-analysis-2"></span><div id="OAM-Analysis-2">
<table class="center" id="table-2">
        <caption>
<a href="#table-2" class="selfRef">Table 2</a>:
<a href="#name-oam-tool-gap-analysis-2" class="selfRef">OAM Tool Gap Analysis</a>
        </caption>
<thead>
          <tr>
            <th class="text-left" rowspan="1" colspan="1">Layer</th>
            <th class="text-left" rowspan="1" colspan="1">Configuration</th>
            <th class="text-left" rowspan="1" colspan="1">Orchestration</th>
            <th class="text-left" rowspan="1" colspan="1">Topology</th>
            <th class="text-left" rowspan="1" colspan="1">Notification</th>
          </tr>
        </thead>
        <tbody>
          <tr>
            <td class="text-left" rowspan="1" colspan="1">Underlay network</td>
            <td class="text-left" rowspan="1" colspan="1">CLI, NETCONF</td>
            <td class="text-left" rowspan="1" colspan="1">CLI, NETCONF</td>
            <td class="text-left" rowspan="1" colspan="1">SNMP</td>
            <td class="text-left" rowspan="1" colspan="1">SNMP, Syslog, NETCONF</td>
          </tr>
          <tr>
            <td class="text-left" rowspan="1" colspan="1">Overlay network</td>
            <td class="text-left" rowspan="1" colspan="1">CLI, NETCONF</td>
            <td class="text-left" rowspan="1" colspan="1">CLI, NETCONF</td>
            <td class="text-left" rowspan="1" colspan="1">SNMP</td>
            <td class="text-left" rowspan="1" colspan="1">SNMP, Syslog, NETCONF</td>
          </tr>
          <tr>
            <td class="text-left" rowspan="1" colspan="1">Classifier</td>
            <td class="text-left" rowspan="1" colspan="1">CLI, NETCONF</td>
            <td class="text-left" rowspan="1" colspan="1">CLI, NETCONF</td>
            <td class="text-left" rowspan="1" colspan="1">None</td>
            <td class="text-left" rowspan="1" colspan="1">None</td>
          </tr>
          <tr>
            <td class="text-left" rowspan="1" colspan="1">SF</td>
            <td class="text-left" rowspan="1" colspan="1">CLI, NETCONF</td>
            <td class="text-left" rowspan="1" colspan="1">CLI, NETCONF</td>
            <td class="text-left" rowspan="1" colspan="1">None</td>
            <td class="text-left" rowspan="1" colspan="1">None</td>
          </tr>
          <tr>
            <td class="text-left" rowspan="1" colspan="1">SFC</td>
            <td class="text-left" rowspan="1" colspan="1">CLI, NETCONF</td>
            <td class="text-left" rowspan="1" colspan="1">CLI, NETCONF</td>
            <td class="text-left" rowspan="1" colspan="1">None</td>
            <td class="text-left" rowspan="1" colspan="1">None</td>
          </tr>
        </tbody>
      </table>
</div>
<p id="section-8-4">Configuration, orchestration, and other manageability tasks of SF and
      SFC could be performed using CLI, NETCONF <span>[<a href="#RFC6241" class="xref">RFC6241</a>]</span>, etc.<a href="#section-8-4" class="pilcrow">¶</a></p>
<p id="section-8-5">While the NETCONF capabilities are readily available, as depicted in
      <a href="#OAM-Analysis-2" class="xref">Table 2</a>, the information and data models are
      needed for configuration, manageability, and orchestration for SFC. With
      virtualized SF and SFC, manageability needs to be done programmatically.<a href="#section-8-5" class="pilcrow">¶</a></p>
</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">Any security considerations defined in <span>[<a href="#RFC7665" class="xref">RFC7665</a>]</span> and <span>[<a href="#RFC8300" class="xref">RFC8300</a>]</span> are
      applicable for this document.<a href="#section-9-1" class="pilcrow">¶</a></p>
<p id="section-9-2">The OAM information from the service layer at different components
      may collectively or independently reveal sensitive information. The
      information may reveal the type of service functions hosted in the
      network, the classification rules and the associated service chains,
      specific service function paths, etc. The sensitivity of the information
      from the SFC layer raises a need for careful security
      considerations.<a href="#section-9-2" class="pilcrow">¶</a></p>
<p id="section-9-3">The mapping and the rules information at the classifier component may
      reveal the traffic rules and the traffic mapped to the SFC. The SFC
      information collected at an SFC component may reveal the SFs associated
      within each chain, and this information together with classifier rules
      may be used to manipulate the header of synthetic attack packets that
      may be used to bypass the SFC and trigger any internal attacks.<a href="#section-9-3" class="pilcrow">¶</a></p>
<p id="section-9-4">The SF information at the SF component may be used by a malicious
      user to trigger a Denial of Service (DoS) attack by overloading any
      specific SF using rogue OAM traffic.<a href="#section-9-4" class="pilcrow">¶</a></p>
<p id="section-9-5">To address the above concerns, SFC and SF OAM should provide
      mechanisms for mitigating:<a href="#section-9-5" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-9-6.1">misuse of the OAM channel for denial of services,<a href="#section-9-6.1" class="pilcrow">¶</a>
</li>
        <li class="normal" id="section-9-6.2">leakage of OAM packets across SFC instances, and<a href="#section-9-6.2" class="pilcrow">¶</a>
</li>
        <li class="normal" id="section-9-6.3">leakage of SFC information beyond the SFC domain.<a href="#section-9-6.3" class="pilcrow">¶</a>
</li>
      </ul>
<p id="section-9-7">The documents proposing the OAM solution for SF components should
      provide rate-limiting the OAM probes at a frequency guided by the
      implementation choice. Rate-limiting may be applied at the classifier,
      SFF, or the SF. The OAM initiator may not receive a response for the
      probes that are rate-limited resulting in false negatives, and the
      implementation should be aware of this. To mitigate any attacks that
      leverage OAM packets, future documents proposing OAM solutions should
      describe the use of any technique to detect and mitigate anomalies and
      various security attacks.<a href="#section-9-7" class="pilcrow">¶</a></p>
<p id="section-9-8">The documents proposing the OAM solution for any service-layer
      components should consider some form of message filtering to control the
      OAM packets entering the administrative domain or prevent leaking any
      internal service-layer information outside the administrative
      domain.<a href="#section-9-8" class="pilcrow">¶</a></p>
</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>
<p id="section-10-1">This document has no IANA actions.<a href="#section-10-1" class="pilcrow">¶</a></p>
</section>
</div>
<section id="section-11">
      <h2 id="name-informative-references">
<a href="#section-11" class="section-number selfRef">11. </a><a href="#name-informative-references" class="section-name selfRef">Informative References</a>
      </h2>
<dl class="references">
<dt id="DOT1Q">[DOT1Q]</dt>
      <dd>
<span class="refAuthor">IEEE</span>, <span class="refTitle">"IEEE Standard for Local and metropolitan area networks--Bridges and Bridged Networks"</span>, <span class="seriesInfo">IEEE 802.1Q-2014</span>, <span class="seriesInfo">DOI 10.1109/IEEESTD.2014.6991462</span>, <time datetime="2014-11" class="refDate">November 2014</time>, <span>&lt;<a href="https://doi.org/10.1109/IEEESTD.2014.6991462">https://doi.org/10.1109/IEEESTD.2014.6991462</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="EFM">[EFM]</dt>
      <dd>
<span class="refAuthor">IEEE</span>, <span class="refTitle">"IEEE Standard for Ethernet"</span>, <span class="seriesInfo">IEEE 802.3-2018</span>, <span class="seriesInfo">DOI 10.1109/IEEESTD.2018.8457469</span>, <time datetime="2018-06" class="refDate">June 2018</time>, <span>&lt;<a href="https://doi.org/10.1109/IEEESTD.2018.8457469">https://doi.org/10.1109/IEEESTD.2018.8457469</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="I-D.ietf-sfc-ioam-nsh">[IOAM-NSH]</dt>
      <dd>
<span class="refAuthor">Brockners, F.</span><span class="refAuthor"> and S. Bhandari</span>, <span class="refTitle">"Network Service Header (NSH) Encapsulation for In-situ OAM (IOAM) Data"</span>, <span class="refContent">Work in Progress</span>, <span class="seriesInfo">Internet-Draft, draft-ietf-sfc-ioam-nsh-04</span>, <time datetime="2020-06-16" class="refDate">16 June 2020</time>, <span>&lt;<a href="https://tools.ietf.org/html/draft-ietf-sfc-ioam-nsh-04">https://tools.ietf.org/html/draft-ietf-sfc-ioam-nsh-04</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="I-D.ietf-ippm-ioam-data">[IPPM-IOAM-DATA]</dt>
      <dd>
<span class="refAuthor">Brockners, F.</span><span class="refAuthor">, Bhandari, S.</span><span class="refAuthor">, and T. Mizrahi</span>, <span class="refTitle">"Data Fields for In-situ OAM"</span>, <span class="refContent">Work in Progress</span>, <span class="seriesInfo">Internet-Draft, draft-ietf-ippm-ioam-data-10</span>, <time datetime="2020-07-13" class="refDate">13 July 2020</time>, <span>&lt;<a href="https://tools.ietf.org/html/draft-ietf-ippm-ioam-data-10">https://tools.ietf.org/html/draft-ietf-ippm-ioam-data-10</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="I-D.ietf-sfc-proof-of-transit">[PROOF-OF-TRANSIT]</dt>
      <dd>
<span class="refAuthor">Brockners, F.</span><span class="refAuthor">, Bhandari, S.</span><span class="refAuthor">, Mizrahi, T.</span><span class="refAuthor">, Dara, S.</span><span class="refAuthor">, and S. Youell</span>, <span class="refTitle">"Proof of Transit"</span>, <span class="refContent">Work in Progress</span>, <span class="seriesInfo">Internet-Draft, draft-ietf-sfc-proof-of-transit-06</span>, <time datetime="2020-06-16" class="refDate">16 June 2020</time>, <span>&lt;<a href="https://tools.ietf.org/html/draft-ietf-sfc-proof-of-transit-06">https://tools.ietf.org/html/draft-ietf-sfc-proof-of-transit-06</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC0792">[RFC0792]</dt>
      <dd>
<span class="refAuthor">Postel, J.</span>, <span class="refTitle">"Internet Control Message Protocol"</span>, <span class="seriesInfo">STD 5</span>, <span class="seriesInfo">RFC 792</span>, <span class="seriesInfo">DOI 10.17487/RFC0792</span>, <time datetime="1981-09" class="refDate">September 1981</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc792">https://www.rfc-editor.org/info/rfc792</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC2330">[RFC2330]</dt>
      <dd>
<span class="refAuthor">Paxson, V.</span><span class="refAuthor">, Almes, G.</span><span class="refAuthor">, Mahdavi, J.</span><span class="refAuthor">, and M. Mathis</span>, <span class="refTitle">"Framework for IP Performance Metrics"</span>, <span class="seriesInfo">RFC 2330</span>, <span class="seriesInfo">DOI 10.17487/RFC2330</span>, <time datetime="1998-05" class="refDate">May 1998</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc2330">https://www.rfc-editor.org/info/rfc2330</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC3393">[RFC3393]</dt>
      <dd>
<span class="refAuthor">Demichelis, C.</span><span class="refAuthor"> and P. Chimento</span>, <span class="refTitle">"IP Packet Delay Variation Metric for IP Performance Metrics (IPPM)"</span>, <span class="seriesInfo">RFC 3393</span>, <span class="seriesInfo">DOI 10.17487/RFC3393</span>, <time datetime="2002-11" class="refDate">November 2002</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc3393">https://www.rfc-editor.org/info/rfc3393</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC4443">[RFC4443]</dt>
      <dd>
<span class="refAuthor">Conta, A.</span><span class="refAuthor">, Deering, S.</span><span class="refAuthor">, and M. Gupta, Ed.</span>, <span class="refTitle">"Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification"</span>, <span class="seriesInfo">STD 89</span>, <span class="seriesInfo">RFC 4443</span>, <span class="seriesInfo">DOI 10.17487/RFC4443</span>, <time datetime="2006-03" class="refDate">March 2006</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc4443">https://www.rfc-editor.org/info/rfc4443</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC4656">[RFC4656]</dt>
      <dd>
<span class="refAuthor">Shalunov, S.</span><span class="refAuthor">, Teitelbaum, B.</span><span class="refAuthor">, Karp, A.</span><span class="refAuthor">, Boote, J.</span><span class="refAuthor">, and M. Zekauskas</span>, <span class="refTitle">"A One-way Active Measurement Protocol (OWAMP)"</span>, <span class="seriesInfo">RFC 4656</span>, <span class="seriesInfo">DOI 10.17487/RFC4656</span>, <time datetime="2006-09" class="refDate">September 2006</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc4656">https://www.rfc-editor.org/info/rfc4656</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC5357">[RFC5357]</dt>
      <dd>
<span class="refAuthor">Hedayat, K.</span><span class="refAuthor">, Krzanowski, R.</span><span class="refAuthor">, Morton, A.</span><span class="refAuthor">, Yum, K.</span><span class="refAuthor">, and J. Babiarz</span>, <span class="refTitle">"A Two-Way Active Measurement Protocol (TWAMP)"</span>, <span class="seriesInfo">RFC 5357</span>, <span class="seriesInfo">DOI 10.17487/RFC5357</span>, <time datetime="2008-10" class="refDate">October 2008</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc5357">https://www.rfc-editor.org/info/rfc5357</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC5880">[RFC5880]</dt>
      <dd>
<span class="refAuthor">Katz, D.</span><span class="refAuthor"> and D. Ward</span>, <span class="refTitle">"Bidirectional Forwarding Detection (BFD)"</span>, <span class="seriesInfo">RFC 5880</span>, <span class="seriesInfo">DOI 10.17487/RFC5880</span>, <time datetime="2010-06" class="refDate">June 2010</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc5880">https://www.rfc-editor.org/info/rfc5880</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC5881">[RFC5881]</dt>
      <dd>
<span class="refAuthor">Katz, D.</span><span class="refAuthor"> and D. Ward</span>, <span class="refTitle">"Bidirectional Forwarding Detection (BFD) for IPv4 and IPv6 (Single Hop)"</span>, <span class="seriesInfo">RFC 5881</span>, <span class="seriesInfo">DOI 10.17487/RFC5881</span>, <time datetime="2010-06" class="refDate">June 2010</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc5881">https://www.rfc-editor.org/info/rfc5881</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC5884">[RFC5884]</dt>
      <dd>
<span class="refAuthor">Aggarwal, R.</span><span class="refAuthor">, Kompella, K.</span><span class="refAuthor">, Nadeau, T.</span><span class="refAuthor">, and G. Swallow</span>, <span class="refTitle">"Bidirectional Forwarding Detection (BFD) for MPLS Label Switched Paths (LSPs)"</span>, <span class="seriesInfo">RFC 5884</span>, <span class="seriesInfo">DOI 10.17487/RFC5884</span>, <time datetime="2010-06" class="refDate">June 2010</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc5884">https://www.rfc-editor.org/info/rfc5884</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC6241">[RFC6241]</dt>
      <dd>
<span class="refAuthor">Enns, R., Ed.</span><span class="refAuthor">, Bjorklund, M., Ed.</span><span class="refAuthor">, Schoenwaelder, J., Ed.</span><span class="refAuthor">, and A. Bierman, Ed.</span>, <span class="refTitle">"Network Configuration Protocol (NETCONF)"</span>, <span class="seriesInfo">RFC 6241</span>, <span class="seriesInfo">DOI 10.17487/RFC6241</span>, <time datetime="2011-06" class="refDate">June 2011</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc6241">https://www.rfc-editor.org/info/rfc6241</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC6291">[RFC6291]</dt>
      <dd>
<span class="refAuthor">Andersson, L.</span><span class="refAuthor">, van Helvoort, H.</span><span class="refAuthor">, Bonica, R.</span><span class="refAuthor">, Romascanu, D.</span><span class="refAuthor">, and S. Mansfield</span>, <span class="refTitle">"Guidelines for the Use of the "OAM" Acronym in the IETF"</span>, <span class="seriesInfo">BCP 161</span>, <span class="seriesInfo">RFC 6291</span>, <span class="seriesInfo">DOI 10.17487/RFC6291</span>, <time datetime="2011-06" class="refDate">June 2011</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc6291">https://www.rfc-editor.org/info/rfc6291</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC6374">[RFC6374]</dt>
      <dd>
<span class="refAuthor">Frost, D.</span><span class="refAuthor"> and S. Bryant</span>, <span class="refTitle">"Packet Loss and Delay Measurement for MPLS Networks"</span>, <span class="seriesInfo">RFC 6374</span>, <span class="seriesInfo">DOI 10.17487/RFC6374</span>, <time datetime="2011-09" class="refDate">September 2011</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc6374">https://www.rfc-editor.org/info/rfc6374</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC7498">[RFC7498]</dt>
      <dd>
<span class="refAuthor">Quinn, P., Ed.</span><span class="refAuthor"> and 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>
<dt id="RFC7665">[RFC7665]</dt>
      <dd>
<span class="refAuthor">Halpern, J., Ed.</span><span class="refAuthor"> and 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="RFC7679">[RFC7679]</dt>
      <dd>
<span class="refAuthor">Almes, G.</span><span class="refAuthor">, Kalidindi, S.</span><span class="refAuthor">, Zekauskas, M.</span><span class="refAuthor">, and A. Morton, Ed.</span>, <span class="refTitle">"A One-Way Delay Metric for IP Performance Metrics (IPPM)"</span>, <span class="seriesInfo">STD 81</span>, <span class="seriesInfo">RFC 7679</span>, <span class="seriesInfo">DOI 10.17487/RFC7679</span>, <time datetime="2016-01" class="refDate">January 2016</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc7679">https://www.rfc-editor.org/info/rfc7679</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC7680">[RFC7680]</dt>
      <dd>
<span class="refAuthor">Almes, G.</span><span class="refAuthor">, Kalidindi, S.</span><span class="refAuthor">, Zekauskas, M.</span><span class="refAuthor">, and A. Morton, Ed.</span>, <span class="refTitle">"A One-Way Loss Metric for IP Performance Metrics (IPPM)"</span>, <span class="seriesInfo">STD 82</span>, <span class="seriesInfo">RFC 7680</span>, <span class="seriesInfo">DOI 10.17487/RFC7680</span>, <time datetime="2016-01" class="refDate">January 2016</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc7680">https://www.rfc-editor.org/info/rfc7680</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC7880">[RFC7880]</dt>
      <dd>
<span class="refAuthor">Pignataro, C.</span><span class="refAuthor">, Ward, D.</span><span class="refAuthor">, Akiya, N.</span><span class="refAuthor">, Bhatia, M.</span><span class="refAuthor">, and S. Pallagatti</span>, <span class="refTitle">"Seamless Bidirectional Forwarding Detection (S-BFD)"</span>, <span class="seriesInfo">RFC 7880</span>, <span class="seriesInfo">DOI 10.17487/RFC7880</span>, <time datetime="2016-07" class="refDate">July 2016</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc7880">https://www.rfc-editor.org/info/rfc7880</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC7881">[RFC7881]</dt>
      <dd>
<span class="refAuthor">Pignataro, C.</span><span class="refAuthor">, Ward, D.</span><span class="refAuthor">, and N. Akiya</span>, <span class="refTitle">"Seamless Bidirectional Forwarding Detection (S-BFD) for IPv4, IPv6, and MPLS"</span>, <span class="seriesInfo">RFC 7881</span>, <span class="seriesInfo">DOI 10.17487/RFC7881</span>, <time datetime="2016-07" class="refDate">July 2016</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc7881">https://www.rfc-editor.org/info/rfc7881</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC8029">[RFC8029]</dt>
      <dd>
<span class="refAuthor">Kompella, K.</span><span class="refAuthor">, Swallow, G.</span><span class="refAuthor">, Pignataro, C., Ed.</span><span class="refAuthor">, Kumar, N.</span><span class="refAuthor">, Aldrin, S.</span><span class="refAuthor">, and M. Chen</span>, <span class="refTitle">"Detecting Multiprotocol Label Switched (MPLS) Data-Plane Failures"</span>, <span class="seriesInfo">RFC 8029</span>, <span class="seriesInfo">DOI 10.17487/RFC8029</span>, <time datetime="2017-03" class="refDate">March 2017</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8029">https://www.rfc-editor.org/info/rfc8029</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><span class="refAuthor">, and 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="RFC8459">[RFC8459]</dt>
      <dd>
<span class="refAuthor">Dolson, D.</span><span class="refAuthor">, Homma, S.</span><span class="refAuthor">, Lopez, D.</span><span class="refAuthor">, and M. Boucadair</span>, <span class="refTitle">"Hierarchical Service Function Chaining (hSFC)"</span>, <span class="seriesInfo">RFC 8459</span>, <span class="seriesInfo">DOI 10.17487/RFC8459</span>, <time datetime="2018-09" class="refDate">September 2018</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8459">https://www.rfc-editor.org/info/rfc8459</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="I-D.penno-sfc-trace">[SFC-TRACE]</dt>
      <dd>
<span class="refAuthor">Penno, R.</span><span class="refAuthor">, Quinn, P.</span><span class="refAuthor">, Pignataro, C.</span><span class="refAuthor">, and D. Zhou</span>, <span class="refTitle">"Services Function Chaining Traceroute"</span>, <span class="refContent">Work in Progress</span>, <span class="seriesInfo">Internet-Draft, draft-penno-sfc-trace-03</span>, <time datetime="2015-09-30" class="refDate">30 September 2015</time>, <span>&lt;<a href="https://tools.ietf.org/html/draft-penno-sfc-trace-03">https://tools.ietf.org/html/draft-penno-sfc-trace-03</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="Y.1731">[Y.1731]</dt>
    <dd>
<span class="refAuthor">ITU-T</span>, <span class="refTitle">"G.8013: Operations, administration and maintenance (OAM) functions and mechanisms for Ethernet-based networks"</span>, <time datetime="2015-08" class="refDate">August 2015</time>, <span>&lt;<a href="https://www.itu.int/rec/T-REC-G.8013-201508-I/en">https://www.itu.int/rec/T-REC-G.8013-201508-I/en</a>&gt;</span>. </dd>
<dd class="break"></dd>
</dl>
</section>
<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">We would like to thank <span class="contact-name">Mohamed Boucadair</span>,
      <span class="contact-name">Adrian Farrel</span>, <span class="contact-name">Greg Mirsky</span>,
      <span class="contact-name">Tal Mizrahi</span>, <span class="contact-name">Martin       Vigoureux</span>, <span class="contact-name">Tirumaleswar Reddy</span>, <span class="contact-name">Carlos Bernados</span>, <span class="contact-name">Martin Duke</span>,
      <span class="contact-name">Barry Leiba</span>, <span class="contact-name">Éric Vyncke</span>,
      <span class="contact-name">Roman Danyliw</span>, <span class="contact-name">Erik Kline</span>,
      <span class="contact-name">Benjamin Kaduk</span>, <span class="contact-name">Robert       Wilton</span>, <span class="contact-name">Frank Brockner</span>, <span class="contact-name">Alvaro Retana</span>, <span class="contact-name">Murray Kucherawy</span>,
      and <span class="contact-name">Alissa Cooper</span> for their review and comments.<a href="#section-appendix.a-1" class="pilcrow">¶</a></p>
</section>
<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">Nobo Akiya</span></div>
<div dir="auto" class="left"><span class="org">Ericsson</span></div>
<div class="email">
<span>Email:</span>
<a href="mailto:nobo.akiya.dev@gmail.com" class="email">nobo.akiya.dev@gmail.com</a>
</div>
</address>
</section>
<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">Sam K. Aldrin</span></div>
<div dir="auto" class="left"><span class="org">Google</span></div>
<div class="email">
<span>Email:</span>
<a href="mailto:aldrin.ietf@gmail.com" class="email">aldrin.ietf@gmail.com</a>
</div>
</address>
<address class="vcard">
        <div dir="auto" class="left"><span class="fn nameRole">Carlos Pignataro (<span class="role">editor</span>)</span></div>
<div dir="auto" class="left"><span class="org">Cisco Systems, Inc.</span></div>
<div class="email">
<span>Email:</span>
<a href="mailto:cpignata@cisco.com" class="email">cpignata@cisco.com</a>
</div>
</address>
<address class="vcard">
        <div dir="auto" class="left"><span class="fn nameRole">Nagendra Kumar (<span class="role">editor</span>)</span></div>
<div dir="auto" class="left"><span class="org">Cisco Systems, Inc.</span></div>
<div class="email">
<span>Email:</span>
<a href="mailto:naikumar@cisco.com" class="email">naikumar@cisco.com</a>
</div>
</address>
<address class="vcard">
        <div dir="auto" class="left"><span class="fn nameRole">Ram Krishnan</span></div>
<div dir="auto" class="left"><span class="org">VMware</span></div>
<div class="email">
<span>Email:</span>
<a href="mailto:ramkri123@gmail.com" class="email">ramkri123@gmail.com</a>
</div>
</address>
<address class="vcard">
        <div dir="auto" class="left"><span class="fn nameRole">Anoop Ghanwani</span></div>
<div dir="auto" class="left"><span class="org">Dell</span></div>
<div class="email">
<span>Email:</span>
<a href="mailto:anoop@alumni.duke.edu" class="email">anoop@alumni.duke.edu</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>