File: rfc9062.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 (2414 lines) | stat: -rw-r--r-- 106,974 bytes
<!DOCTYPE html>
<html lang="en" class="RFC">
<head>
<meta charset="utf-8">
<meta content="Common,Latin" name="scripts">
<meta content="initial-scale=1.0" name="viewport">
<title>RFC 9062: Framework and Requirements for Ethernet VPN (EVPN) Operations, Administration, and Maintenance (OAM)</title>
<meta content="Samer Salam" name="author">
<meta content="Ali Sajassi" name="author">
<meta content="Sam Aldrin" name="author">
<meta content="John E. Drake" name="author">
<meta content="Donald E. Eastlake 3rd" name="author">
<meta content="
       
   This document specifies the requirements and reference framework for
   Ethernet VPN (EVPN) Operations, Administration, and Maintenance (OAM).
   The requirements cover the OAM aspects of EVPN and Provider Backbone Bridge EVPN (PBB-EVPN).  The framework defines the layered OAM model
   encompassing the EVPN service layer, network layer, underlying Packet
   Switched Network (PSN) transport layer, and link layer but focuses on
   the service and network layers. 
    " name="description">
<meta content="xml2rfc 3.9.1" name="generator">
<meta content="PBB-EVPN" name="keyword">
<meta content="fault management" name="keyword">
<meta content="performance management" name="keyword">
<meta content="9062" name="rfc.number">
<!-- Generator version information:
  xml2rfc 3.9.1
    Python 3.6.10
    appdirs 1.4.4
    ConfigArgParse 1.2.3
    google-i18n-address 2.3.5
    html5lib 1.0.1
    intervaltree 3.0.2
    Jinja2 2.11.2
    kitchen 1.2.6
    lxml 4.4.2
    pycairo 1.19.0
    pycountry 19.8.18
    pyflakes 2.1.1
    PyYAML 5.3.1
    requests 2.22.0
    setuptools 40.6.2
    six 1.14.0
    WeasyPrint 51
-->
<link href="rfc9062.xml" rel="alternate" type="application/rfc+xml">
<link href="#copyright" rel="license">
<style type="text/css">/*

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

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

*/

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

.refInstance {
  margin-bottom: 1.25em;
}

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

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

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

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

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

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

/* pagination */
@media print {
  body {

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

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

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

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

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

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

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

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

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

}

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


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

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

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

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

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

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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

}
/* Tweak the bcp14 keyword presentation */
.bcp14 {
  font-variant: small-caps;
  font-weight: bold;
  font-size: 0.9em;
}
/* Tweak the invisible space above H* in order not to overlay links in text above */
 h2 {
  margin-top: -18px;  /* provide offset for in-page anchors */
  padding-top: 31px;
 }
 h3 {
  margin-top: -18px;  /* provide offset for in-page anchors */
  padding-top: 24px;
 }
 h4 {
  margin-top: -18px;  /* provide offset for in-page anchors */
  padding-top: 24px;
 }
/* Float artwork pilcrow to the right */
@media screen {
  .artwork a.pilcrow {
    display: block;
    line-height: 0.7;
    margin-top: 0.15em;
  }
}
/* Make pilcrows on dd visible */
@media screen {
  dd:hover > a.pilcrow {
    visibility: visible;
  }
}
/* Make the placement of figcaption match that of a table's caption
   by removing the figure's added bottom margin */
.alignLeft.art-text,
.alignCenter.art-text,
.alignRight.art-text {
   margin-bottom: 0;
}
.alignLeft,
.alignCenter,
.alignRight {
  margin: 1em 0 0 0;
}
/* In print, the pilcrow won't show on hover, so prevent it from taking up space,
   possibly even requiring a new line */
@media print {
  a.pilcrow {
    display: none;
  }
}
/* Styling for the external metadata */
div#external-metadata {
  background-color: #eee;
  padding: 0.5em;
  margin-bottom: 0.5em;
  display: none;
}
div#internal-metadata {
  padding: 0.5em;                       /* to match the external-metadata padding */
}
/* Styling for title RFC Number */
h1#rfcnum {
  clear: both;
  margin: 0 0 -1em;
  padding: 1em 0 0 0;
}
/* Make .olPercent look the same as <ol><li> */
dl.olPercent > dd {
  margin-bottom: 0.25em;
  min-height: initial;
}
/* Give aside some styling to set it apart */
aside {
  border-left: 1px solid #ddd;
  margin: 1em 0 1em 2em;
  padding: 0.2em 2em;
}
aside > dl,
aside > ol,
aside > ul,
aside > table,
aside > p {
  margin-bottom: 0.5em;
}
/* Additional page break settings */
@media print {
  figcaption, table caption {
    page-break-before: avoid;
  }
}
/* Font size adjustments for print */
@media print {
  body  { font-size: 10pt;      line-height: normal; max-width: 96%; }
  h1    { font-size: 1.72em;    padding-top: 1.5em; } /* 1*1.2*1.2*1.2 */
  h2    { font-size: 1.44em;    padding-top: 1.5em; } /* 1*1.2*1.2 */
  h3    { font-size: 1.2em;     padding-top: 1.5em; } /* 1*1.2 */
  h4    { font-size: 1em;       padding-top: 1.5em; }
  h5, h6 { font-size: 1em;      margin: initial; padding: 0.5em 0 0.3em; }
}
/* Sourcecode margin in print, when there's no pilcrow */
@media print {
  .artwork,
  .sourcecode {
    margin-bottom: 1em;
  }
}
/* Avoid narrow tables forcing too narrow table captions, which may render badly */
table {
  min-width: 20em;
}
/* ol type a */
ol.type-a { list-style-type: lower-alpha; }
ol.type-A { list-style-type: upper-alpha; }
ol.type-i { list-style-type: lower-roman; }
ol.type-I { list-style-type: lower-roman; }
/* Apply the print table and row borders in general, on request from the RPC,
and increase the contrast between border and odd row background sligthtly */
table {
  border: 1px solid #ddd;
}
td {
  border-top: 1px solid #ddd;
}
tr:nth-child(2n+1) > td {
  background-color: #f8f8f8;
}
/* Use style rules to govern display of the TOC. */
@media screen and (max-width: 1023px) {
  #toc nav { display: none; }
  #toc.active nav { display: block; }
}
/* Add support for keepWithNext */
.keepWithNext {
  break-after: avoid-page;
  break-after: avoid-page;
}
/* Add support for keepWithPrevious */
.keepWithPrevious {
  break-before: avoid-page;
}
/* Change the approach to avoiding breaks inside artwork etc. */
figure, pre, table, .artwork, .sourcecode  {
  break-before: avoid-page;
  break-after: auto;
}
/* Avoid breaks between <dt> and <dd> */
dl {
  break-before: auto;
  break-inside: auto;
}
dt {
  break-before: auto;
  break-after: avoid-page;
}
dd {
  break-before: avoid-page;
  break-after: auto;
  orphans: 3;
  widows: 3
}
span.break, dd.break {
  margin-bottom: 0;
  min-height: 0;
  break-before: auto;
  break-inside: auto;
  break-after: auto;
}
/* Undo break-before ToC */
@media print {
  #toc {
    break-before: auto;
  }
}
/* Text in compact lists should not get extra bottim margin space,
   since that would makes the list not compact */
ul.compact p, .ulCompact p,
ol.compact p, .olCompact p {
 margin: 0;
}
/* But the list as a whole needs the extra space at the end */
section ul.compact,
section .ulCompact,
section ol.compact,
section .olCompact {
  margin-bottom: 1em;                    /* same as p not within ul.compact etc. */
}
/* The tt and code background above interferes with for instance table cell
   backgrounds.  Changed to something a bit more selective. */
tt, code {
  background-color: transparent;
}
p tt, p code, li tt, li code {
  background-color: #f8f8f8;
}
/* Tweak the pre margin -- 0px doesn't come out well */
pre {
   margin-top: 0.5px;
}
/* Tweak the comact list text */
ul.compact, .ulCompact,
ol.compact, .olCompact,
dl.compact, .dlCompact {
  line-height: normal;
}
/* Don't add top margin for nested lists */
li > ul, li > ol, li > dl,
dd > ul, dd > ol, dd > dl,
dl > dd > dl {
  margin-top: initial;
}
/* Elements that should not be rendered on the same line as a <dt> */
/* This should match the element list in writer.text.TextWriter.render_dl() */
dd > div.artwork:first-child,
dd > aside:first-child,
dd > figure:first-child,
dd > ol:first-child,
dd > div:first-child > pre.sourcecode,
dd > table:first-child,
dd > ul:first-child {
  clear: left;
}
/* fix for weird browser behaviour when <dd/> is empty */
dt+dd:empty::before{
  content: "\00a0";
}
/* Make paragraph spacing inside <li> smaller than in body text, to fit better within the list */
li > p {
  margin-bottom: 0.5em
}
/* Don't let p margin spill out from inside list items */
li > p:last-of-type {
  margin-bottom: 0;
}
</style>
<link href="rfc-local.css" rel="stylesheet" type="text/css">
<link href="https://dx.doi.org/10.17487/rfc9062" rel="alternate">
  <link href="urn:issn:2070-1721" rel="alternate">
  <link href="https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-oam-req-frmwk-10" 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 9062</td>
<td class="center">EVPN OAM Requirements/Framework</td>
<td class="right">June 2021</td>
</tr></thead>
<tfoot><tr>
<td class="left">Salam, 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/rfc9062" class="eref">9062</a></dd>
<dt class="label-category">Category:</dt>
<dd class="category">Informational</dd>
<dt class="label-published">Published:</dt>
<dd class="published">
<time datetime="2021-06" class="published">June 2021</time>
    </dd>
<dt class="label-issn">ISSN:</dt>
<dd class="issn">2070-1721</dd>
<dt class="label-authors">Authors:</dt>
<dd class="authors">
<div class="author">
      <div class="author-name">S. Salam</div>
<div class="org">Cisco</div>
</div>
<div class="author">
      <div class="author-name">A. Sajassi</div>
<div class="org">Cisco</div>
</div>
<div class="author">
      <div class="author-name">S. Aldrin</div>
<div class="org">Google</div>
</div>
<div class="author">
      <div class="author-name">J. Drake</div>
<div class="org">Juniper</div>
</div>
<div class="author">
      <div class="author-name">D. Eastlake 3rd</div>
<div class="org">Futurewei</div>
</div>
</dd>
</dl>
</div>
<h1 id="rfcnum">RFC 9062</h1>
<h1 id="title">Framework and Requirements for Ethernet VPN (EVPN) Operations, Administration, and Maintenance (OAM)</h1>
<section id="section-abstract">
      <h2 id="abstract"><a href="#abstract" class="selfRef">Abstract</a></h2>
<p id="section-abstract-1">
   This document specifies the requirements and reference framework for
   Ethernet VPN (EVPN) Operations, Administration, and Maintenance (OAM).
   The requirements cover the OAM aspects of EVPN and Provider Backbone Bridge EVPN (PBB-EVPN).  The framework defines the layered OAM model
   encompassing the EVPN service layer, network layer, underlying Packet
   Switched Network (PSN) transport layer, and link layer but focuses on
   the service and network layers.<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/rfc9062">https://www.rfc-editor.org/info/rfc9062</a></span>.<a href="#section-boilerplate.1-3" class="pilcrow">¶</a></p>
</section>
</div>
<div id="copyright">
<section id="section-boilerplate.2">
        <h2 id="name-copyright-notice">
<a href="#name-copyright-notice" class="section-name selfRef">Copyright Notice</a>
        </h2>
<p id="section-boilerplate.2-1">
            Copyright (c) 2021 IETF Trust and the persons identified as the
            document authors. All rights reserved.<a href="#section-boilerplate.2-1" class="pilcrow">¶</a></p>
<p id="section-boilerplate.2-2">
            This document is subject to BCP 78 and the IETF Trust's Legal
            Provisions Relating to IETF Documents
            (<span><a href="https://trustee.ietf.org/license-info">https://trustee.ietf.org/license-info</a></span>) in effect on the date of
            publication of this document. Please review these documents
            carefully, as they describe your rights and restrictions with
            respect to this document. Code Components extracted from this
            document must include Simplified BSD License text as described in
            Section 4.e of the Trust Legal Provisions and are provided without
            warranty as described in the Simplified BSD License.<a href="#section-boilerplate.2-2" class="pilcrow">¶</a></p>
</section>
</div>
<div id="toc">
<section id="section-toc.1">
        <a href="#" onclick="scroll(0,0)" class="toplink">▲</a><h2 id="name-table-of-contents">
<a href="#name-table-of-contents" class="section-name selfRef">Table of Contents</a>
        </h2>
<nav class="toc"><ul class="toc ulBare ulEmpty compact">
<li class="toc ulBare ulEmpty compact" id="section-toc.1-1.1">
            <p id="section-toc.1-1.1.1"><a href="#section-1" class="xref">1</a>.  <a href="#name-introduction" class="xref">Introduction</a></p>
<ul class="toc ulBare ulEmpty compact">
<li class="toc ulBare ulEmpty compact" 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-relationship-to-other-oam-w" class="xref">Relationship to Other OAM Work</a></p>
</li>
              <li class="toc ulBare ulEmpty compact" id="section-toc.1-1.1.2.2">
                <p id="section-toc.1-1.1.2.2.1" class="keepWithNext"><a href="#section-1.2" class="xref">1.2</a>.  <a href="#name-specification-of-requiremen" class="xref">Specification of Requirements</a></p>
</li>
              <li class="toc ulBare ulEmpty compact" id="section-toc.1-1.1.2.3">
                <p id="section-toc.1-1.1.2.3.1" class="keepWithNext"><a href="#section-1.3" class="xref">1.3</a>.  <a href="#name-terminology" class="xref">Terminology</a></p>
</li>
            </ul>
</li>
          <li class="toc ulBare ulEmpty compact" id="section-toc.1-1.2">
            <p id="section-toc.1-1.2.1"><a href="#section-2" class="xref">2</a>.  <a href="#name-evpn-oam-framework" class="xref">EVPN OAM Framework</a></p>
<ul class="toc ulBare ulEmpty compact">
<li class="toc ulBare ulEmpty compact" id="section-toc.1-1.2.2.1">
                <p id="section-toc.1-1.2.2.1.1"><a href="#section-2.1" class="xref">2.1</a>.  <a href="#name-oam-layering" class="xref">OAM Layering</a></p>
</li>
              <li class="toc ulBare ulEmpty compact" id="section-toc.1-1.2.2.2">
                <p id="section-toc.1-1.2.2.2.1"><a href="#section-2.2" class="xref">2.2</a>.  <a href="#name-evpn-service-oam" class="xref">EVPN Service OAM</a></p>
</li>
              <li class="toc ulBare ulEmpty compact" id="section-toc.1-1.2.2.3">
                <p id="section-toc.1-1.2.2.3.1"><a href="#section-2.3" class="xref">2.3</a>.  <a href="#name-evpn-network-oam" class="xref">EVPN Network OAM</a></p>
</li>
              <li class="toc ulBare ulEmpty compact" id="section-toc.1-1.2.2.4">
                <p id="section-toc.1-1.2.2.4.1"><a href="#section-2.4" class="xref">2.4</a>.  <a href="#name-transport-oam-for-evpn" class="xref">Transport OAM for EVPN</a></p>
</li>
              <li class="toc ulBare ulEmpty compact" id="section-toc.1-1.2.2.5">
                <p id="section-toc.1-1.2.2.5.1"><a href="#section-2.5" class="xref">2.5</a>.  <a href="#name-link-oam" class="xref">Link OAM</a></p>
</li>
              <li class="toc ulBare ulEmpty compact" id="section-toc.1-1.2.2.6">
                <p id="section-toc.1-1.2.2.6.1"><a href="#section-2.6" class="xref">2.6</a>.  <a href="#name-oam-interworking" class="xref">OAM Interworking</a></p>
</li>
            </ul>
</li>
          <li class="toc ulBare ulEmpty compact" id="section-toc.1-1.3">
            <p id="section-toc.1-1.3.1"><a href="#section-3" class="xref">3</a>.  <a href="#name-evpn-oam-requirements" class="xref">EVPN OAM Requirements</a></p>
<ul class="toc ulBare ulEmpty compact">
<li class="toc ulBare ulEmpty compact" 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-fault-management-requiremen" class="xref">Fault Management Requirements</a></p>
<ul class="toc ulBare ulEmpty compact">
<li class="toc ulBare ulEmpty compact" 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-proactive-fault-management-" class="xref">Proactive Fault Management Functions</a></p>
<ul class="toc ulBare ulEmpty compact">
<li class="toc ulBare ulEmpty compact" id="section-toc.1-1.3.2.1.2.1.2.1">
                        <p id="section-toc.1-1.3.2.1.2.1.2.1.1"><a href="#section-3.1.1.1" class="xref">3.1.1.1</a>.  <a href="#name-fault-detection-continuity-" class="xref">Fault Detection (Continuity Check)</a></p>
</li>
                      <li class="toc ulBare ulEmpty compact" id="section-toc.1-1.3.2.1.2.1.2.2">
                        <p id="section-toc.1-1.3.2.1.2.1.2.2.1"><a href="#section-3.1.1.2" class="xref">3.1.1.2</a>.  <a href="#name-defect-indication" class="xref">Defect Indication</a></p>
<ul class="toc ulBare ulEmpty compact">
<li class="toc ulBare ulEmpty compact" id="section-toc.1-1.3.2.1.2.1.2.2.2.1">
                            <p id="section-toc.1-1.3.2.1.2.1.2.2.2.1.1"><a href="#section-3.1.1.2.1" class="xref">3.1.1.2.1</a>.  <a href="#name-forward-defect-indication-f" class="xref">Forward Defect Indication (FDI)</a></p>
</li>
                          <li class="toc ulBare ulEmpty compact" id="section-toc.1-1.3.2.1.2.1.2.2.2.2">
                            <p id="section-toc.1-1.3.2.1.2.1.2.2.2.2.1"><a href="#section-3.1.1.2.2" class="xref">3.1.1.2.2</a>.  <a href="#name-reverse-defect-indication-r" class="xref">Reverse Defect Indication (RDI)</a></p>
</li>
                        </ul>
</li>
                    </ul>
</li>
                  <li class="toc ulBare ulEmpty compact" 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-on-demand-fault-management-" class="xref">On-Demand Fault Management Functions</a></p>
<ul class="toc ulBare ulEmpty compact">
<li class="toc ulBare ulEmpty compact" id="section-toc.1-1.3.2.1.2.2.2.1">
                        <p id="section-toc.1-1.3.2.1.2.2.2.1.1"><a href="#section-3.1.2.1" class="xref">3.1.2.1</a>.  <a href="#name-connectivity-verification" class="xref">Connectivity Verification</a></p>
</li>
                      <li class="toc ulBare ulEmpty compact" id="section-toc.1-1.3.2.1.2.2.2.2">
                        <p id="section-toc.1-1.3.2.1.2.2.2.2.1"><a href="#section-3.1.2.2" class="xref">3.1.2.2</a>.  <a href="#name-fault-isolation" class="xref">Fault Isolation</a></p>
</li>
                    </ul>
</li>
                </ul>
</li>
              <li class="toc ulBare ulEmpty compact" 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-performance-management" class="xref">Performance Management</a></p>
<ul class="toc ulBare ulEmpty compact">
<li class="toc ulBare ulEmpty compact" 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-packet-loss" class="xref">Packet Loss</a></p>
</li>
                  <li class="toc ulBare ulEmpty compact" 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-packet-delay-and-jitter" class="xref">Packet Delay and Jitter</a></p>
</li>
                </ul>
</li>
            </ul>
</li>
          <li class="toc ulBare ulEmpty compact" id="section-toc.1-1.4">
            <p id="section-toc.1-1.4.1"><a href="#section-4" class="xref">4</a>.  <a href="#name-security-considerations" class="xref">Security Considerations</a></p>
</li>
          <li class="toc ulBare ulEmpty compact" id="section-toc.1-1.5">
            <p id="section-toc.1-1.5.1"><a href="#section-5" class="xref">5</a>.  <a href="#name-iana-considerations" class="xref">IANA Considerations</a></p>
</li>
          <li class="toc ulBare ulEmpty compact" id="section-toc.1-1.6">
            <p id="section-toc.1-1.6.1"><a href="#section-6" class="xref">6</a>.  <a href="#name-references" class="xref">References</a></p>
<ul class="toc ulBare ulEmpty compact">
<li class="toc ulBare ulEmpty compact" id="section-toc.1-1.6.2.1">
                <p id="section-toc.1-1.6.2.1.1"><a href="#section-6.1" class="xref">6.1</a>.  <a href="#name-normative-references" class="xref">Normative References</a></p>
</li>
              <li class="toc ulBare ulEmpty compact" id="section-toc.1-1.6.2.2">
                <p id="section-toc.1-1.6.2.2.1"><a href="#section-6.2" class="xref">6.2</a>.  <a href="#name-informative-references" class="xref">Informative References</a></p>
</li>
            </ul>
</li>
          <li class="toc ulBare ulEmpty compact" id="section-toc.1-1.7">
            <p id="section-toc.1-1.7.1"><a href="#appendix-A" class="xref"></a><a href="#name-acknowledgements" class="xref">Acknowledgements</a></p>
</li>
          <li class="toc ulBare ulEmpty compact" id="section-toc.1-1.8">
            <p id="section-toc.1-1.8.1"><a href="#appendix-B" class="xref"></a><a href="#name-authors-addresses" class="xref">Authors' Addresses</a></p>
</li>
        </ul>
</nav>
</section>
</div>
<div id="sect-1">
<section id="section-1">
      <h2 id="name-introduction">
<a href="#section-1" class="section-number selfRef">1. </a><a href="#name-introduction" class="section-name selfRef">Introduction</a>
      </h2>
<p id="section-1-1">
   This document specifies the requirements and defines a reference
   framework for Ethernet VPN (EVPN) Operations, Administration, and
   Maintenance (OAM) <span>[<a href="#RFC6291" class="xref">RFC6291</a>]</span>. In this context, we use the term "EVPN OAM" to loosely refer to the OAM functions required for and/or
   applicable to <span>[<a href="#RFC7432" class="xref">RFC7432</a>]</span> and <span>[<a href="#RFC7623" class="xref">RFC7623</a>]</span>.<a href="#section-1-1" class="pilcrow">¶</a></p>
<p id="section-1-2">
   EVPN is a Layer 2 VPN (L2VPN) solution for multipoint Ethernet
   services with advanced multihoming capabilities that uses BGP for
   distributing Customer/Client Media Access Control (C-MAC) address reachability information
   over the core MPLS/IP network.<a href="#section-1-2" class="pilcrow">¶</a></p>
<p id="section-1-3">
   PBB-EVPN combines Provider Backbone Bridging (PBB) <span>[<a href="#IEEE-802.1Q" class="xref">IEEE-802.1Q</a>]</span> with EVPN in
   order to reduce the number of BGP MAC advertisement routes; provide client
   MAC address mobility using C-MAC <span>[<a href="#RFC7623" class="xref">RFC7623</a>]</span> aggregation and
   Backbone MAC (B-MAC) <span>[<a href="#RFC7623" class="xref">RFC7623</a>]</span> sub-netting; confine the scope of C-MAC
   learning to only active flows; offer per-site policies; and avoid C-MAC
   address flushing on topology changes.<a href="#section-1-3" class="pilcrow">¶</a></p>
<p id="section-1-4">
   This document focuses on the fault management and performance
   management aspects of EVPN OAM. It defines the layered OAM model
   encompassing the EVPN service layer, network layer, underlying Packet
   Switched Network (PSN) transport layer, and link layer but focuses on
   the service and network layers.<a href="#section-1-4" class="pilcrow">¶</a></p>
<div id="sect-1.1">
<section id="section-1.1">
        <h3 id="name-relationship-to-other-oam-w">
<a href="#section-1.1" class="section-number selfRef">1.1. </a><a href="#name-relationship-to-other-oam-w" class="section-name selfRef">Relationship to Other OAM Work</a>
        </h3>
<p id="section-1.1-1">
   This document leverages concepts and draws upon elements defined
   and⁠/⁠or used in the following documents:<a href="#section-1.1-1" class="pilcrow">¶</a></p>
<p id="section-1.1-2">
   <span>[<a href="#RFC6136" class="xref">RFC6136</a>]</span> specifies the requirements and a reference model for OAM as
   it relates to L2VPN services, pseudowires, and associated Packet
   Switched Network (PSN) tunnels. This document focuses on Virtual Private LAN Service (VPLS) and Virtual Private Wire Service (VPWS) solutions and services.<a href="#section-1.1-2" class="pilcrow">¶</a></p>
<p id="section-1.1-3">
   <span>[<a href="#RFC8029" class="xref">RFC8029</a>]</span> defines mechanisms for detecting data plane failures in
   MPLS Label Switched Paths (LSPs), including procedures to check the correct operation of the
   data plane as well as mechanisms to verify the data plane against
   the control plane.<a href="#section-1.1-3" class="pilcrow">¶</a></p>
<p id="section-1.1-4">
   <span>[<a href="#IEEE-802.1Q" class="xref">IEEE-802.1Q</a>]</span> specifies the Ethernet Connectivity Fault Management (CFM)
   protocol, which defines the concepts of Maintenance Domains,
   Maintenance Associations, Maintenance End Points, and Maintenance
   Intermediate Points.<a href="#section-1.1-4" class="pilcrow">¶</a></p>
<p id="section-1.1-5">
   <span>[<a href="#Y.1731" class="xref">Y.1731</a>]</span> extends Connectivity Fault Management in the following
   areas: it defines fault notification and alarm suppression functions
   for Ethernet and specifies mechanisms for Ethernet performance
   management, including loss, delay, jitter, and throughput
   measurement.<a href="#section-1.1-5" class="pilcrow">¶</a></p>
</section>
</div>
<div id="sect-1.2">
<section id="section-1.2">
        <h3 id="name-specification-of-requiremen">
<a href="#section-1.2" class="section-number selfRef">1.2. </a><a href="#name-specification-of-requiremen" class="section-name selfRef">Specification of Requirements</a>
        </h3>
<p id="section-1.2-1">
    The key words "<span class="bcp14">MUST</span>", "<span class="bcp14">MUST NOT</span>", "<span class="bcp14">REQUIRED</span>", "<span class="bcp14">SHALL</span>", "<span class="bcp14">SHALL NOT</span>", "<span class="bcp14">SHOULD</span>", "<span class="bcp14">SHOULD NOT</span>", "<span class="bcp14">RECOMMENDED</span>", "<span class="bcp14">NOT RECOMMENDED</span>",
    "<span class="bcp14">MAY</span>", and "<span class="bcp14">OPTIONAL</span>" in this document are to be interpreted as
    described in BCP 14 <span>[<a href="#RFC2119" class="xref">RFC2119</a>]</span> <span>[<a href="#RFC8174" class="xref">RFC8174</a>]</span> 
    when, and only when, they appear in all capitals, as shown here.<a href="#section-1.2-1" class="pilcrow">¶</a></p>
</section>
</div>
<div id="sect-1.3">
<section id="section-1.3">
        <h3 id="name-terminology">
<a href="#section-1.3" class="section-number selfRef">1.3. </a><a href="#name-terminology" class="section-name selfRef">Terminology</a>
        </h3>
<p id="section-1.3-1">
   This document uses the following terminology, much of which is defined
   in <span>[<a href="#RFC6136" class="xref">RFC6136</a>]</span>:<a href="#section-1.3-1" class="pilcrow">¶</a></p>
<span class="break"></span><dl class="dlParallel" id="section-1.3-2">
          <dt id="section-1.3-2.1">CE</dt>
          <dd style="margin-left: 6.0em" id="section-1.3-2.2">Customer Edge device; for example, a host, router, or switch.<a href="#section-1.3-2.2" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-1.3-2.3">CFM</dt>
          <dd style="margin-left: 6.0em" id="section-1.3-2.4">Connectivity Fault Management <span>[<a href="#IEEE-802.1Q" class="xref">IEEE-802.1Q</a>]</span><a href="#section-1.3-2.4" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-1.3-2.5">DF</dt>
          <dd style="margin-left: 6.0em" id="section-1.3-2.6">Designated Forwarder <span>[<a href="#RFC7432" class="xref">RFC7432</a>]</span><a href="#section-1.3-2.6" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-1.3-2.7">Down MEP</dt>
          <dd style="margin-left: 6.0em" id="section-1.3-2.8">A MEP that originates traffic away from and terminates
        traffic towards the core of the device in whose port it is logically located.<a href="#section-1.3-2.8" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-1.3-2.9">EVI</dt>
          <dd style="margin-left: 6.0em" id="section-1.3-2.10">An EVPN instance spanning the Provider Edge (PE)
   devices participating in that EVPN <span>[<a href="#RFC7432" class="xref">RFC7432</a>]</span>.<a href="#section-1.3-2.10" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-1.3-2.11">L2VPN</dt>
          <dd style="margin-left: 6.0em" id="section-1.3-2.12">Layer 2 VPN<a href="#section-1.3-2.12" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-1.3-2.13">LOC</dt>
          <dd style="margin-left: 6.0em" id="section-1.3-2.14">Loss of continuity<a href="#section-1.3-2.14" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-1.3-2.15">MA</dt>
          <dd style="margin-left: 6.0em" id="section-1.3-2.16">Maintenance Association; a set of MEPs belonging
   to the same Maintenance Domain (MD) established to verify the
   integrity of a single service instance <span>[<a href="#IEEE-802.1Q" class="xref">IEEE-802.1Q</a>]</span>.<a href="#section-1.3-2.16" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-1.3-2.17">MD</dt>
          <dd style="margin-left: 6.0em" id="section-1.3-2.18">Maintenance Domain; an OAM Domain that represents a
   region over which OAM frames can operate unobstructed <span>[<a href="#IEEE-802.1Q" class="xref">IEEE-802.1Q</a>]</span>.<a href="#section-1.3-2.18" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-1.3-2.19">MEP</dt>
          <dd style="margin-left: 6.0em" id="section-1.3-2.20">Maintenance End Point; it is responsible for
   origination and termination of OAM frames for a given MA. A MEP is
   logically located in a device's port <span>[<a href="#IEEE-802.1Q" class="xref">IEEE-802.1Q</a>]</span>.<a href="#section-1.3-2.20" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-1.3-2.21">MIP</dt>
          <dd style="margin-left: 6.0em" id="section-1.3-2.22"> Maintenance Intermediate Point; it is located between
   peer MEPs and can process and respond to certain OAM frames but does
   not initiate them. A MIP is logically located in a device's port
   <span>[<a href="#IEEE-802.1Q" class="xref">IEEE-802.1Q</a>]</span>.<a href="#section-1.3-2.22" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-1.3-2.23">MP2P</dt>
          <dd style="margin-left: 6.0em" id="section-1.3-2.24">Multipoint to Point<a href="#section-1.3-2.24" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-1.3-2.25">NMS</dt>
          <dd style="margin-left: 6.0em" id="section-1.3-2.26">Network Management Station <span>[<a href="#RFC6632" class="xref">RFC6632</a>]</span><a href="#section-1.3-2.26" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-1.3-2.27">P</dt>
          <dd style="margin-left: 6.0em" id="section-1.3-2.28">Provider network interior (non-edge) node<a href="#section-1.3-2.28" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-1.3-2.29">P2MP</dt>
          <dd style="margin-left: 6.0em" id="section-1.3-2.30">Point to Multipoint<a href="#section-1.3-2.30" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-1.3-2.31">PBB</dt>
          <dd style="margin-left: 6.0em" id="section-1.3-2.32">Provider Backbone Bridge <span>[<a href="#RFC7623" class="xref">RFC7623</a>]</span><a href="#section-1.3-2.32" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-1.3-2.33">PE</dt>
          <dd style="margin-left: 6.0em" id="section-1.3-2.34">Provider Edge network device<a href="#section-1.3-2.34" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-1.3-2.35">Up MEP</dt>
          <dd style="margin-left: 6.0em" id="section-1.3-2.36"> A MEP that originates traffic towards and
   terminates traffic from the core of the device in whose port it is
   logically located.<a href="#section-1.3-2.36" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-1.3-2.37">VPN</dt>
          <dd style="margin-left: 6.0em" id="section-1.3-2.38">Virtual Private Network<a href="#section-1.3-2.38" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
</dl>
</section>
</div>
</section>
</div>
<div id="sect-2">
<section id="section-2">
      <h2 id="name-evpn-oam-framework">
<a href="#section-2" class="section-number selfRef">2. </a><a href="#name-evpn-oam-framework" class="section-name selfRef">EVPN OAM Framework</a>
      </h2>
<div id="sect-2.1">
<section id="section-2.1">
        <h3 id="name-oam-layering">
<a href="#section-2.1" class="section-number selfRef">2.1. </a><a href="#name-oam-layering" class="section-name selfRef">OAM Layering</a>
        </h3>
<p id="section-2.1-1">
   Multiple layers come into play for implementing an L2VPN service
   using the EVPN family of solutions as listed below. The focus of this
   document is the service and network layers.<a href="#section-2.1-1" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-2.1-2.1">The service layer runs end to end between the sites or Ethernet
     segments that are being interconnected by the EVPN solution.<a href="#section-2.1-2.1" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-2.1-2.2">The network layer extends between the EVPN PE (Provider Edge) nodes
     and is mostly transparent to the P (provider network interior)
     nodes (except where flow entropy comes into play). It leverages
     MPLS for service (i.e., EVI) multiplexing and split-horizon
     functions.<a href="#section-2.1-2.2" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-2.1-2.3">The transport layer is dictated by the networking technology of the
     PSN. It may be based on either MPLS LSPs or IP.<a href="#section-2.1-2.3" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-2.1-2.4">The link layer is dependent upon the physical technology used.
     Ethernet is a popular choice for this layer, but other alternatives
     are deployed (e.g., Packet over SONET (POS), Dense Wavelength Division Multiplexing (DWDM), etc.).<a href="#section-2.1-2.4" class="pilcrow">¶</a>
</li>
        </ul>
<p id="section-2.1-3">
   This layering extends to the set of OAM protocols that are involved
   in the ongoing maintenance and diagnostics of EVPN networks. <a href="#fig-1" class="xref">Figure 1</a>
   below depicts the OAM layering and shows which devices have
   visibility into what OAM layer(s).<a href="#section-2.1-3" class="pilcrow">¶</a></p>
<span id="name-oam-layering-2"></span><div id="fig-1">
<figure id="figure-1">
          <div class="artwork art-text alignLeft" id="section-2.1-4.1">
<pre>
        +---+                               +---+
+--+    |   |    +---+    +---+    +---+    |   |    +--+
|CE|----|PE |----| P |----| P |----| P |----|PE |----|CE|
+--+    |   |    +---+    +---+    +---+    |   |    +--+
        +---+                               +---+

  o-------o----------- Service OAM -----------o-------o

          o----------- Network OAM -----------o

          o--------o--------o--------o--------o  Transport OAM

   o----o   o----o   o----o   o----o   o----o   o----o  Link OAM
</pre>
</div>
<figcaption><a href="#figure-1" class="selfRef">Figure 1</a>:
<a href="#name-oam-layering-2" class="selfRef">OAM Layering</a>
          </figcaption></figure>
</div>
<p id="section-2.1-5">
   Service OAM and Network OAM mechanisms only have visibility to the PE
  nodes but not the P nodes. As
   such, they can be used to deduce whether the fault is in the customer's own network, the local CE-PE segment, the PE-PE segment, or
   the remote CE-PE segment(s). EVPN Transport OAM mechanisms can be
   used for fault isolation between the PEs and P nodes.<a href="#section-2.1-5" class="pilcrow">¶</a></p>
<p id="section-2.1-6">
     
   <a href="#fig-2" class="xref">Figure 2</a> below shows an example network where Ethernet domains
   are interconnected via EVPN using MPLS, and it shows the OAM mechanisms
   that are applicable at each layer. The details of the layers are described in
   the sections below.<a href="#section-2.1-6" class="pilcrow">¶</a></p>
<span id="name-evpn-oam-example"></span><div id="fig-2">
<figure id="figure-2">
          <div class="artwork art-text alignLeft" id="section-2.1-7.1">
<pre>
        +---+                               +---+
+--+    |   |    +---+    +---+    +---+    |   |    +--+
|CE|----|PE |----| P |----| P |----| P |----|PE |----|CE|
+--+    |   |    +---+    +---+    +---+    |   |    +--+
        +---+                               +---+

   o----o---------- CFM (Service OAM) ----------o----o

          o-------- EVPN Network OAM ---------o

          o--------o--------o--------o--------o MPLS OAM

   o----o   o----o   o----o   o----o   o----o   o----o 802.3 OAM
                                                       [IEEE-802.3]
</pre>
</div>
<figcaption><a href="#figure-2" class="selfRef">Figure 2</a>:
<a href="#name-evpn-oam-example" class="selfRef">EVPN OAM Example</a>
          </figcaption></figure>
</div>
</section>
</div>
<div id="sect-2.2">
<section id="section-2.2">
        <h3 id="name-evpn-service-oam">
<a href="#section-2.2" class="section-number selfRef">2.2. </a><a href="#name-evpn-service-oam" class="section-name selfRef">EVPN Service OAM</a>
        </h3>
<p id="section-2.2-1">
   The EVPN Service OAM protocol depends on what service-layer
   technology is being interconnected by the EVPN solution. In the case of
   <span>[<a href="#RFC7432" class="xref">RFC7432</a>]</span> and <span>[<a href="#RFC7623" class="xref">RFC7623</a>]</span>, the service layer is Ethernet; hence, the
   corresponding Service OAM protocol is Ethernet CFM <span>[<a href="#IEEE-802.1Q" class="xref">IEEE-802.1Q</a>]</span>.<a href="#section-2.2-1" class="pilcrow">¶</a></p>
<p id="section-2.2-2">
   EVPN Service OAM is visible to the CEs and EVPN PEs but not to the P
   nodes. This is because the PEs operate at the Ethernet MAC layer in
   <span>[<a href="#RFC7432" class="xref">RFC7432</a>]</span> and <span>[<a href="#RFC7623" class="xref">RFC7623</a>]</span>, whereas the P nodes do not.<a href="#section-2.2-2" class="pilcrow">¶</a></p>
<p id="section-2.2-3">
   The EVPN PE <span class="bcp14">MUST</span> support MIP functions in the applicable Service OAM
   protocol (for example, Ethernet CFM). The EVPN PE <span class="bcp14">SHOULD</span> support MEP
   functions in the applicable Service OAM protocol. This includes both
   Up and Down MEP functions.<a href="#section-2.2-3" class="pilcrow">¶</a></p>
<p id="section-2.2-4">
   As shown in <a href="#fig-3" class="xref">Figure 3</a>, the MIP and MEP functions being referred to are
   logically located within the device's port operating at the customer
   level. (There could be MEPs/MIPs within PE ports facing the provider
   network, but they would not be relevant to EVPN Service OAM as the
   traffic passing through them will be encapsulated/tunneled, so any
   customer-level OAM messages will just be treated as data.)  Down MEP
   functions are away from the core of the device while Up MEP functions
   are towards the core of the device (towards the PE forwarding
   mechanism in the case of a PE). OAM messages between the PE Up MEPs
   shown are a type of EVPN Network OAM, while such messages between the
   CEs or from a PE to its local CE or to the remote CE are Service OAMs.<a href="#section-2.2-4" class="pilcrow">¶</a></p>
<span id="name-cfm-details"></span><div id="fig-3">
<figure id="figure-3">
          <div class="artwork art-text alignLeft" id="section-2.2-5.1">
<pre>
 +-------+   +----------------+       +----------------+   +-------+
 |+-----+|   |+--------------+|       |+--------------+|   |+-----+|
 ||  CE ||   ||     PE       ||  ...  ||       PE     ||   || CE  ||
 |+--+--+|   |+---+--------+-+|       |+-+--------+---+|   |+--+--+|
 |   |   |   |    |        |  |       |  |        |    |   |   |   |
 |+--+--+|   |+---+-----+  .  |       |  .  +-----+---+|   |+--+--+|
 || MEP ||   ||   | Up ^|  .  |  ...  |  .  | Up ^|   ||   || MEP ||
 ||DownV||   ||MIP|MEP  |  .  |       |  .  |MEP  |MIP||   ||DownV||
 |+--+--+|   ||   |DownV|  .  |       |  .  |DownV|   ||   |+--+--+|
 |   |   |   |+---+-----+  |  |       |  |  +-----+---+|   |   |   |
 +---|---+   +----|--------|--+       +--|--------|----+   +---|---+
     |            |        |             |        |            |
     +------------+        +---  ...  ---+        +------------+
</pre>
</div>
<figcaption><a href="#figure-3" class="selfRef">Figure 3</a>:
<a href="#name-cfm-details" class="selfRef">CFM Details</a>
          </figcaption></figure>
</div>
<p id="section-2.2-6">
   The EVPN PE <span class="bcp14">MUST</span>, by default, learn the MAC address of locally
   attached CE MEPs by snooping on CFM frames and advertising them to
   remote PEs as a MAC/IP Advertisement route. Some means to limit the
   number of MAC addresses that a PE will learn <span class="bcp14">SHOULD</span> be implemented.<a href="#section-2.2-6" class="pilcrow">¶</a></p>
<p id="section-2.2-7">
   The EVPN PE <span class="bcp14">SHOULD</span> advertise any MEP/MIP local to the PE as a MAC/IP
   Advertisement route. Since these are not subject to mobility, they
   <span class="bcp14">SHOULD</span> be advertised with the static (sticky) bit set (see <span><a href="https://www.rfc-editor.org/rfc/rfc7432#section-15.2" class="relref">Section 15.2</a> of [<a href="#RFC7432" class="xref">RFC7432</a>]</span>).<a href="#section-2.2-7" class="pilcrow">¶</a></p>
</section>
</div>
<div id="sect-2.3">
<section id="section-2.3">
        <h3 id="name-evpn-network-oam">
<a href="#section-2.3" class="section-number selfRef">2.3. </a><a href="#name-evpn-network-oam" class="section-name selfRef">EVPN Network OAM</a>
        </h3>
<p id="section-2.3-1">
   EVPN Network OAM is visible to the PE nodes only. This OAM layer is
   analogous to Virtual Circuit Connectivity Verification (VCCV) <span>[<a href="#RFC5085" class="xref">RFC5085</a>]</span> in the case of VPLS/VPWS. It provides
   mechanisms to check the correct operation of the data plane as well
   as a mechanism to verify the data plane against the control plane.
   This includes the ability to perform fault detection and diagnostics
   on:<a href="#section-2.3-1" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-2.3-2.1">the MP2P tunnels used for the transport of unicast traffic between
     PEs. EVPN allows for three different models of unicast label
     assignment: label per EVI, label per &lt;ESI, Ethernet Tag&gt;, and label
     per MAC address. In all three models, the label is bound to an EVPN
     Unicast Forwarding Equivalence Class (FEC).  EVPN Network OAM <span class="bcp14">MUST</span> provide mechanisms to check the
     operation of the data plane and verify that operation against the
     control plane view.<a href="#section-2.3-2.1" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-2.3-2.2">the MP2P tunnels used for aliasing unicast traffic destined to a
     multihomed Ethernet segment. The three label assignment models,
     discussed above, apply here as well. In all three models, the label
     is bound to an EVPN Aliasing FEC. EVPN Network OAM <span class="bcp14">MUST</span> provide
     mechanisms to check the operation of the data plane and verify that
     operation against the control plane view.<a href="#section-2.3-2.2" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-2.3-2.3">the multicast tunnels (either MP2P or P2MP) used for the transport
     of broadcast, unknown unicast, and multicast traffic between PEs. In
     the case of ingress replication, a label is allocated per EVI or
     per &lt;EVI, Ethernet Tag&gt; and is bound to an EVPN Multicast FEC. In
     the case of Label Switched Multicast (LSM) and, more specifically,
     aggregate inclusive trees, again, a label may be allocated per EVI
     or per &lt;EVI, Ethernet Tag&gt; and is bound to the tunnel FEC.<a href="#section-2.3-2.3" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-2.3-2.4">the correct operation of the Ethernet Segment Identifier (ESI) split-horizon filtering function.
     In EVPN, a label is allocated per multihomed Ethernet segment for
     the purpose of performing the access split-horizon enforcement. The
     label is bound to an EVPN Ethernet segment.<a href="#section-2.3-2.4" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-2.3-2.5">the correct operation of the Designated Forwarder (DF) <span>[<a href="#RFC7432" class="xref">RFC7432</a>]</span>
     filtering function.  EVPN Network OAM <span class="bcp14">MUST</span> provide mechanisms to
     check the operation of the data plane and verify that operation
     against the control plane view for the DF filtering function.<a href="#section-2.3-2.5" class="pilcrow">¶</a>
</li>
        </ul>
<p id="section-2.3-3">
   EVPN Network OAM mechanisms <span class="bcp14">MUST</span> provide in-band monitoring
   capabilities. It is desirable, to the extent practical, for OAM test
   messages to share fate with data messages. Details of how to achieve
   this are beyond the scope of this document.<a href="#section-2.3-3" class="pilcrow">¶</a></p>
<p id="section-2.3-4">
   EVPN Network OAM <span class="bcp14">SHOULD</span> provide both proactive and on-demand
   mechanisms of monitoring the data plane operation and data plane
   conformance to the state of the control plane.<a href="#section-2.3-4" class="pilcrow">¶</a></p>
</section>
</div>
<div id="sect-2.4">
<section id="section-2.4">
        <h3 id="name-transport-oam-for-evpn">
<a href="#section-2.4" class="section-number selfRef">2.4. </a><a href="#name-transport-oam-for-evpn" class="section-name selfRef">Transport OAM for EVPN</a>
        </h3>
<p id="section-2.4-1">
   The Transport OAM protocol depends on the nature of the underlying
   transport technology in the PSN. MPLS OAM mechanisms <span>[<a href="#RFC8029" class="xref">RFC8029</a>]</span>
          <span>[<a href="#RFC6425" class="xref">RFC6425</a>]</span> as well as ICMP <span>[<a href="#RFC0792" class="xref">RFC0792</a>]</span> and ICMPv6 <span>[<a href="#RFC4443" class="xref">RFC4443</a>]</span> are applicable,
   depending on whether the PSN employs MPLS or IP transport,
   respectively.  Furthermore, Bidirectional Forwarding Detection (BFD) mechanisms per <span>[<a href="#RFC5880" class="xref">RFC5880</a>]</span>, <span>[<a href="#RFC5881" class="xref">RFC5881</a>]</span>,
   <span>[<a href="#RFC5883" class="xref">RFC5883</a>]</span>, and <span>[<a href="#RFC5884" class="xref">RFC5884</a>]</span> apply. Also, the BFD mechanisms pertaining to
   MPLS-TP LSPs per <span>[<a href="#RFC6428" class="xref">RFC6428</a>]</span> are applicable.<a href="#section-2.4-1" class="pilcrow">¶</a></p>
</section>
</div>
<div id="sect-2.5">
<section id="section-2.5">
        <h3 id="name-link-oam">
<a href="#section-2.5" class="section-number selfRef">2.5. </a><a href="#name-link-oam" class="section-name selfRef">Link OAM</a>
        </h3>
<p id="section-2.5-1">
   Link OAM depends on the data-link technology being used between the
   PE and P nodes. For example, if Ethernet links are employed, then
   Ethernet Link OAM (<span>[<a href="#IEEE-802.3" class="xref">IEEE-802.3</a>]</span>, Clause 57) may be used.<a href="#section-2.5-1" class="pilcrow">¶</a></p>
</section>
</div>
<div id="sect-2.6">
<section id="section-2.6">
        <h3 id="name-oam-interworking">
<a href="#section-2.6" class="section-number selfRef">2.6. </a><a href="#name-oam-interworking" class="section-name selfRef">OAM Interworking</a>
        </h3>
<p id="section-2.6-1">
   When interworking two networking domains, such as actual Ethernet
   and EVPN to provide an end-to-end emulated service, there is a need
   to identify the failure domain and location, even when a PE supports
   both the Service OAM mechanisms and the EVPN Network OAM mechanisms.
   In addition, scalability constraints may not allow the running of proactive
   monitoring, such as Ethernet Continuity Check Messages (CCMs)
   <span>[<a href="#IEEE-802.1Q" class="xref">IEEE-802.1Q</a>]</span>, at a PE to detect the failure of an EVI across the EVPN
   domain. Thus, the mapping of alarms generated upon failure detection
   in one domain (e.g., actual Ethernet or EVPN network domain) to the
   other domain is needed. There are also cases where a PE may not be
   able to process Service OAM messages received from a remote PE over
   the PSN even when such messages are defined, as in the Ethernet case,
   thereby necessitating support for fault notification message mapping
   between the EVPN Network domain and the Service domain.<a href="#section-2.6-1" class="pilcrow">¶</a></p>
<p id="section-2.6-2">
   OAM interworking is not limited, though, to scenarios involving disparate
   network domains. It is possible to perform OAM interworking across
   different layers in the same network domain. In general, alarms generated
   within an OAM layer, as a result of proactive fault detection mechanisms, may be injected into its    client-layer OAM mechanisms. This allows the
   client-layer OAM to trigger event-driven (i.e., asynchronous) fault
   notifications. For example, alarms generated by the Link OAM mechanisms may
   be injected into the Transport OAM layer, and alarms generated by the
   Transport OAM mechanism may be injected into the Network OAM mechanism, and
   so on.<a href="#section-2.6-2" class="pilcrow">¶</a></p>
<p id="section-2.6-3">
   EVPN OAM <span class="bcp14">MUST</span> support interworking between the Network OAM and
   Service OAM mechanisms. EVPN OAM <span class="bcp14">MAY</span> support interworking among
   other OAM layers.<a href="#section-2.6-3" class="pilcrow">¶</a></p>
</section>
</div>
</section>
</div>
<div id="sect-3">
<section id="section-3">
      <h2 id="name-evpn-oam-requirements">
<a href="#section-3" class="section-number selfRef">3. </a><a href="#name-evpn-oam-requirements" class="section-name selfRef">EVPN OAM Requirements</a>
      </h2>
<p id="section-3-1">
   This section discusses the EVPN OAM requirements pertaining to fault
   management and performance management.<a href="#section-3-1" class="pilcrow">¶</a></p>
<div id="sect-3.1">
<section id="section-3.1">
        <h3 id="name-fault-management-requiremen">
<a href="#section-3.1" class="section-number selfRef">3.1. </a><a href="#name-fault-management-requiremen" class="section-name selfRef">Fault Management Requirements</a>
        </h3>
<div id="sect-3.1.1">
<section id="section-3.1.1">
          <h4 id="name-proactive-fault-management-">
<a href="#section-3.1.1" class="section-number selfRef">3.1.1. </a><a href="#name-proactive-fault-management-" class="section-name selfRef">Proactive Fault Management Functions</a>
          </h4>
<p id="section-3.1.1-1">
   The network operator configures proactive fault management functions
   to run periodically. Certain actions (for
   example, protection switchover or alarm indication signaling) can be
   associated with specific events, such as entering or clearing fault
   states.<a href="#section-3.1.1-1" class="pilcrow">¶</a></p>
<div id="sect-3.1.1.1">
<section id="section-3.1.1.1">
            <h5 id="name-fault-detection-continuity-">
<a href="#section-3.1.1.1" class="section-number selfRef">3.1.1.1. </a><a href="#name-fault-detection-continuity-" class="section-name selfRef">Fault Detection (Continuity Check)</a>
            </h5>
<p id="section-3.1.1.1-1">
   Proactive fault detection is performed by periodically monitoring the
   reachability between service end points, i.e., MEPs in a given MA,
   through the exchange of CCMs <span>[<a href="#IEEE-802.1Q" class="xref">IEEE-802.1Q</a>]</span>. The
   reachability between any two arbitrary MEPs may be monitored for:<a href="#section-3.1.1.1-1" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-3.1.1.1-2.1">in-band, per-flow monitoring. This enables per-flow monitoring
     between MEPs. EVPN Network OAM <span class="bcp14">MUST</span> support fault detection with
     per-user flow granularity. EVPN Service OAM <span class="bcp14">MAY</span> support fault
     detection with per-user flow granularity.<a href="#section-3.1.1.1-2.1" class="pilcrow">¶</a>
</li>
              <li class="normal" id="section-3.1.1.1-2.2">a representative path. This enables a liveness check of the nodes
     hosting the MEPs, assuming that the loss of continuity (LOC) to the MEP is
     interpreted as a failure of the hosting node. This, however, does
     not conclusively indicate liveness of the path(s) taken by user
     data traffic. This enables node failure detection but not path
     failure detection through the use of a test flow. EVPN Network OAM
     and Service OAM <span class="bcp14">MUST</span> support fault detection using test flows.<a href="#section-3.1.1.1-2.2" class="pilcrow">¶</a>
</li>
              <li class="normal" id="section-3.1.1.1-2.3">all paths. For MPLS/IP networks with ECMP, the monitoring of all unicast
     paths between MEPs (on non-adjacent nodes) may not be possible since the
     per-hop ECMP hashing behavior may yield situations where it is impossible
     for a MEP to pick flow entropy characteristics that result in exercising
     the exhaustive set of ECMP paths. The monitoring of all ECMP paths between
     MEPs (on non-adjacent nodes) is not a requirement for EVPN OAM.<a href="#section-3.1.1.1-2.3" class="pilcrow">¶</a>
</li>
            </ul>
<p id="section-3.1.1.1-3">
   The fact that MPLS/IP networks do not enforce congruency between
   unicast and multicast paths means that the proactive fault detection
   mechanisms for EVPN networks <span class="bcp14">MUST</span> provide procedures to monitor the
   unicast paths independently of the multicast paths. This applies to
   EVPN Service OAM and Network OAM.<a href="#section-3.1.1.1-3" class="pilcrow">¶</a></p>
</section>
</div>
<div id="sect-3.1.1.2">
<section id="section-3.1.1.2">
            <h5 id="name-defect-indication">
<a href="#section-3.1.1.2" class="section-number selfRef">3.1.1.2. </a><a href="#name-defect-indication" class="section-name selfRef">Defect Indication</a>
            </h5>
<p id="section-3.1.1.2-1">
   Defect indications can be categorized into two types: forward and
   reverse, as described below. EVPN Service OAM <span class="bcp14">MUST</span>
   support at least one of these types of event-driven defect indications
   upon the detection of a connectivity defect.<a href="#section-3.1.1.2-1" class="pilcrow">¶</a></p>
<div id="sect-3.1.1.2.1">
<section id="section-3.1.1.2.1">
              <h6 id="name-forward-defect-indication-f">
<a href="#section-3.1.1.2.1" class="section-number selfRef">3.1.1.2.1. </a><a href="#name-forward-defect-indication-f" class="section-name selfRef">Forward Defect Indication (FDI)</a>
              </h6>
<p id="section-3.1.1.2.1-1">
   FDI is used to signal a failure that is detected by a lower-layer
   OAM mechanism. A server MEP (i.e., an actual or virtual MEP)
   transmits a forward defect indication in a direction away
   from the direction of the failure (refer to <a href="#fig-4" class="xref">Figure 4</a> below).<a href="#section-3.1.1.2.1-1" class="pilcrow">¶</a></p>
<span id="name-forward-defect-indication"></span><div id="fig-4">
<figure id="figure-4">
                <div class="artwork art-text alignLeft" id="section-3.1.1.2.1-2.1">
<pre>
                           Failure
                              |
       +-----+      +-----+   V   +-----+      +-----+
       |  A  |------|  B  |--XXX--|  C  |------|  D  |
       +-----+      +-----+       +-----+      +-----+

           &lt;===========|             |============&gt;
             Forward                    Forward
             Defect                     Defect
             Indication                 Indication
</pre>
</div>
<figcaption><a href="#figure-4" class="selfRef">Figure 4</a>:
<a href="#name-forward-defect-indication" class="selfRef">Forward Defect Indication</a>
                </figcaption></figure>
</div>
<p id="section-3.1.1.2.1-3">
   Forward defect indication may be used for alarm suppression and/or
   for the purpose of interworking with other layer OAM protocols. Alarm
   suppression is useful when a transport-level or network-level fault translates
   to multiple service- or flow-level faults. In such a scenario, it is
   enough to alert a network management station (NMS) of the single
   transport-level or network-level fault in lieu of flooding that NMS with a
   multitude of Service or Flow granularity alarms. EVPN PEs <span class="bcp14">SHOULD</span>
   support forward defect indication in the Service OAM mechanisms.<a href="#section-3.1.1.2.1-3" class="pilcrow">¶</a></p>
</section>
</div>
<div id="sect-3.1.1.2.2">
<section id="section-3.1.1.2.2">
              <h6 id="name-reverse-defect-indication-r">
<a href="#section-3.1.1.2.2" class="section-number selfRef">3.1.1.2.2. </a><a href="#name-reverse-defect-indication-r" class="section-name selfRef">Reverse Defect Indication (RDI)</a>
              </h6>
<p id="section-3.1.1.2.2-1">
   RDI is used to signal that the advertising MEP has detected a LOC defect. RDI is transmitted in the direction of the
   failure (refer to <a href="#fig-5" class="xref">Figure 5</a>).<a href="#section-3.1.1.2.2-1" class="pilcrow">¶</a></p>
<span id="name-reverse-defect-indication"></span><div id="fig-5">
<figure id="figure-5">
                <div class="artwork art-text alignLeft" id="section-3.1.1.2.2-2.1">
<pre>
                           Failure
                              |
       +-----+      +-----+   V   +-----+      +-----+
       |  A  |------|  B  |--XXX--|  C  |------|  D  |
       +-----+      +-----+       +-----+      +-----+

           |===========&gt;             &lt;============|
             Reverse                    Reverse
             Defect                     Defect
             Indication                 Indication
</pre>
</div>
<figcaption><a href="#figure-5" class="selfRef">Figure 5</a>:
<a href="#name-reverse-defect-indication" class="selfRef">Reverse Defect Indication</a>
                </figcaption></figure>
</div>
<p id="section-3.1.1.2.2-3">
   RDI allows single-sided management, where the network operator can
   examine the state of a single MEP and deduce the overall health of a
   monitored service. EVPN PEs <span class="bcp14">SHOULD</span> support reverse defect indication
   in the Service OAM mechanisms. This includes both the ability to
   signal a LOC defect to a remote MEP as well as the ability to
   recognize RDI from a remote MEP. Note that, in a multipoint MA, RDI
   is not a useful indicator of unidirectional fault.  This is because
   RDI carries no indication of the affected MEP(s) with which the
   sender had detected a LOC defect.<a href="#section-3.1.1.2.2-3" class="pilcrow">¶</a></p>
</section>
</div>
</section>
</div>
</section>
</div>
<div id="sect-3.1.2">
<section id="section-3.1.2">
          <h4 id="name-on-demand-fault-management-">
<a href="#section-3.1.2" class="section-number selfRef">3.1.2. </a><a href="#name-on-demand-fault-management-" class="section-name selfRef">On-Demand Fault Management Functions</a>
          </h4>
<p id="section-3.1.2-1">
   On-demand fault management functions are initiated manually by the
   network operator and continue for a bounded time period. These
   functions enable the operator to run diagnostics to investigate a
   defect condition.<a href="#section-3.1.2-1" class="pilcrow">¶</a></p>
<div id="sect-3.1.2.1">
<section id="section-3.1.2.1">
            <h5 id="name-connectivity-verification">
<a href="#section-3.1.2.1" class="section-number selfRef">3.1.2.1. </a><a href="#name-connectivity-verification" class="section-name selfRef">Connectivity Verification</a>
            </h5>
<p id="section-3.1.2.1-1">
   EVPN Network OAM <span class="bcp14">MUST</span> support on-demand connectivity verification
   mechanisms for unicast and multicast destinations. The connectivity
   verification mechanisms <span class="bcp14">SHOULD</span> provide a means for specifying and
   carrying the following in the messages:<a href="#section-3.1.2.1-1" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-3.1.2.1-2.1">variable-length payload/padding to test connectivity problems related to the Maximum Transmission Unit (MTU).<a href="#section-3.1.2.1-2.1" class="pilcrow">¶</a>
</li>
              <li class="normal" id="section-3.1.2.1-2.2">test frame formats as defined in <span><a href="https://www.rfc-editor.org/rfc/rfc2544#appendix-C" class="relref">Appendix C</a> of [<a href="#RFC2544" class="xref">RFC2544</a>]</span> to detect
     potential packet corruption.<a href="#section-3.1.2.1-2.2" class="pilcrow">¶</a>
</li>
            </ul>
<p id="section-3.1.2.1-3">
   EVPN Network OAM <span class="bcp14">MUST</span> support connectivity verification at per-flow
   granularity. This includes both user flows (to test a specific path
   between PEs) as well as test flows (to test a representative path
   between PEs).<a href="#section-3.1.2.1-3" class="pilcrow">¶</a></p>
<p id="section-3.1.2.1-4">
   EVPN Service OAM <span class="bcp14">MUST</span> support connectivity verification on test flows
   and <span class="bcp14">MAY</span> support connectivity verification on user flows.<a href="#section-3.1.2.1-4" class="pilcrow">¶</a></p>
<p id="section-3.1.2.1-5">
   For multicast connectivity verification, EVPN Network OAM <span class="bcp14">MUST</span>
   support reporting on:<a href="#section-3.1.2.1-5" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-3.1.2.1-6.1">the DF filtering status of a specific port(s) or all the ports in a
     given bridge domain.<a href="#section-3.1.2.1-6.1" class="pilcrow">¶</a>
</li>
              <li class="normal" id="section-3.1.2.1-6.2">the split-horizon filtering status of a specific port(s) or all the
     ports in a given bridge domain.<a href="#section-3.1.2.1-6.2" class="pilcrow">¶</a>
</li>
            </ul>
</section>
</div>
<div id="sect-3.1.2.2">
<section id="section-3.1.2.2">
            <h5 id="name-fault-isolation">
<a href="#section-3.1.2.2" class="section-number selfRef">3.1.2.2. </a><a href="#name-fault-isolation" class="section-name selfRef">Fault Isolation</a>
            </h5>
<p id="section-3.1.2.2-1">
   EVPN OAM <span class="bcp14">MUST</span> support an on-demand fault localization function. This
   involves the capability to narrow down the locality of a fault to a
   particular port, link, or node. The characteristic of forward/reverse path
   asymmetry in MPLS/IP makes fault isolation a direction-sensitive
   operation. That is, given two PEs A and B, localization of continuity
   failures between them requires running fault-isolation procedures from PE A
   to PE B as well as from PE B to PE A.<a href="#section-3.1.2.2-1" class="pilcrow">¶</a></p>
<p id="section-3.1.2.2-2">
   EVPN Service OAM mechanisms only have visibility to the PEs but not
   the MPLS or IP P nodes. As such, they can be used to deduce whether
   the fault is in the customer's own network, the local CE-PE segment,
   or a remote CE-PE segment(s). EVPN Network and Transport OAM mechanisms
   can be used for fault isolation between the PEs and P nodes.<a href="#section-3.1.2.2-2" class="pilcrow">¶</a></p>
</section>
</div>
</section>
</div>
</section>
</div>
<div id="sect-3.2">
<section id="section-3.2">
        <h3 id="name-performance-management">
<a href="#section-3.2" class="section-number selfRef">3.2. </a><a href="#name-performance-management" class="section-name selfRef">Performance Management</a>
        </h3>
<p id="section-3.2-1">
   Performance management functions can be performed both proactively
   and on demand. Proactive management involves a recurring function,
   where the performance management probes are run continuously without
   a trigger. We cover both proactive and on-demand functions in this
   section.<a href="#section-3.2-1" class="pilcrow">¶</a></p>
<div id="sect-3.2.1">
<section id="section-3.2.1">
          <h4 id="name-packet-loss">
<a href="#section-3.2.1" class="section-number selfRef">3.2.1. </a><a href="#name-packet-loss" class="section-name selfRef">Packet Loss</a>
          </h4>
<p id="section-3.2.1-1">
   EVPN Network OAM <span class="bcp14">SHOULD</span> provide mechanisms for measuring packet loss
   for a given service -- for example, <span>[<a href="#RFC7680" class="xref">RFC7680</a>]</span> and <span>[<a href="#RFC6673" class="xref">RFC6673</a>]</span>.<a href="#section-3.2.1-1" class="pilcrow">¶</a></p>
<p id="section-3.2.1-2">
   Given that EVPN provides inherent support for multipoint-to-multipoint
   connectivity, packet loss cannot be accurately measured by means of
   counting user data packets. This is because user packets can be delivered
   to more PEs or more ports than are necessary (e.g., due to broadcast,
   unpruned multicast, or unknown unicast flooding). As such, a statistical
   means of approximating the packet loss rate is required.  This can be achieved
   by sending "synthetic" OAM packets that are counted only by those ports
   (MEPs) that are required to receive them.  This provides a statistical
   approximation of the number of data frames lost, even with
   multipoint-to-multipoint connectivity.<a href="#section-3.2.1-2" class="pilcrow">¶</a></p>
</section>
</div>
<div id="sect-3.2.2">
<section id="section-3.2.2">
          <h4 id="name-packet-delay-and-jitter">
<a href="#section-3.2.2" class="section-number selfRef">3.2.2. </a><a href="#name-packet-delay-and-jitter" class="section-name selfRef">Packet Delay and Jitter</a>
          </h4>
<p id="section-3.2.2-1">
   EVPN Service OAM <span class="bcp14">SHOULD</span> support measurement of one-way and two-way
   packet delay and delay variation (jitter) across the EVPN network.
   Measurement of one-way delay requires clock synchronization between
   the probe source and target devices. Mechanisms for clock
   synchronization are outside the scope of this document. Note that
   Service OAM performance management mechanisms defined in <span>[<a href="#Y.1731" class="xref">Y.1731</a>]</span> can
   be used. See also <span>[<a href="#RFC7679" class="xref">RFC7679</a>]</span>, <span>[<a href="#RFC2681" class="xref">RFC2681</a>]</span>, and <span>[<a href="#RFC3393" class="xref">RFC3393</a>]</span>.<a href="#section-3.2.2-1" class="pilcrow">¶</a></p>
<p id="section-3.2.2-2">
   EVPN Network OAM <span class="bcp14">MAY</span> support measurement of one-way and two-way
   packet delay and delay variation (jitter) across the EVPN network.<a href="#section-3.2.2-2" class="pilcrow">¶</a></p>
</section>
</div>
</section>
</div>
</section>
</div>
<div id="sect-4">
<section id="section-4">
      <h2 id="name-security-considerations">
<a href="#section-4" class="section-number selfRef">4. </a><a href="#name-security-considerations" class="section-name selfRef">Security Considerations</a>
      </h2>
<p id="section-4-1">
   EVPN OAM <span class="bcp14">MUST</span> prevent OAM packets from leaking outside of the EVPN
   network or outside their corresponding Maintenance Domain. This can
   be done for CFM, for example, by having MEPs implement a filtering
   function based on the Maintenance Level associated with received OAM
   packets.<a href="#section-4-1" class="pilcrow">¶</a></p>
<p id="section-4-2">
   EVPN OAM <span class="bcp14">SHOULD</span> provide mechanisms for implementation and optional
   use to:<a href="#section-4-2" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-4-3.1">prevent denial-of-service attacks caused by exploitation of the OAM
     message channel (for example, by forging messages to exceed a
     Maintenance End Point's capacity to maintain state).<a href="#section-4-3.1" class="pilcrow">¶</a>
</li>
        <li class="normal" id="section-4-3.2">authenticate communicating end points (for example, MEPs and MIPs).<a href="#section-4-3.2" class="pilcrow">¶</a>
</li>
      </ul>
</section>
</div>
<div id="sect-5">
<section id="section-5">
      <h2 id="name-iana-considerations">
<a href="#section-5" class="section-number selfRef">5. </a><a href="#name-iana-considerations" class="section-name selfRef">IANA Considerations</a>
      </h2>
<p id="section-5-1">
   This document has no IANA actions.<a href="#section-5-1" class="pilcrow">¶</a></p>
</section>
</div>
<section id="section-6">
      <h2 id="name-references">
<a href="#section-6" class="section-number selfRef">6. </a><a href="#name-references" class="section-name selfRef">References</a>
      </h2>
<section id="section-6.1">
        <h3 id="name-normative-references">
<a href="#section-6.1" class="section-number selfRef">6.1. </a><a href="#name-normative-references" class="section-name selfRef">Normative References</a>
        </h3>
<dl class="references">
<dt id="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="RFC2119">[RFC2119]</dt>
        <dd>
<span class="refAuthor">Bradner, S.</span>, <span class="refTitle">"Key words for use in RFCs to Indicate Requirement Levels"</span>, <span class="seriesInfo">BCP 14</span>, <span class="seriesInfo">RFC 2119</span>, <span class="seriesInfo">DOI 10.17487/RFC2119</span>, <time datetime="1997-03" class="refDate">March 1997</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc2119">https://www.rfc-editor.org/info/rfc2119</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC4443">[RFC4443]</dt>
        <dd>
<span class="refAuthor">Conta, A.</span>, <span class="refAuthor">Deering, S.</span>, and <span class="refAuthor">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="RFC5880">[RFC5880]</dt>
        <dd>
<span class="refAuthor">Katz, D.</span> and <span class="refAuthor">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> and <span class="refAuthor">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="RFC5883">[RFC5883]</dt>
        <dd>
<span class="refAuthor">Katz, D.</span> and <span class="refAuthor">D. Ward</span>, <span class="refTitle">"Bidirectional Forwarding Detection (BFD) for Multihop Paths"</span>, <span class="seriesInfo">RFC 5883</span>, <span class="seriesInfo">DOI 10.17487/RFC5883</span>, <time datetime="2010-06" class="refDate">June 2010</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc5883">https://www.rfc-editor.org/info/rfc5883</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>, and <span class="refAuthor">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="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>, and <span class="refAuthor">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="RFC6425">[RFC6425]</dt>
        <dd>
<span class="refAuthor">Saxena, S., Ed.</span>, <span class="refAuthor">Swallow, G.</span>, <span class="refAuthor">Ali, Z.</span>, <span class="refAuthor">Farrel, A.</span>, <span class="refAuthor">Yasukawa, S.</span>, and <span class="refAuthor">T. Nadeau</span>, <span class="refTitle">"Detecting Data-Plane Failures in Point-to-Multipoint MPLS - Extensions to LSP Ping"</span>, <span class="seriesInfo">RFC 6425</span>, <span class="seriesInfo">DOI 10.17487/RFC6425</span>, <time datetime="2011-11" class="refDate">November 2011</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc6425">https://www.rfc-editor.org/info/rfc6425</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC6428">[RFC6428]</dt>
        <dd>
<span class="refAuthor">Allan, D., Ed.</span>, <span class="refAuthor">Swallow, G., Ed.</span>, and <span class="refAuthor">J. Drake, Ed.</span>, <span class="refTitle">"Proactive Connectivity Verification, Continuity Check, and Remote Defect Indication for the MPLS Transport Profile"</span>, <span class="seriesInfo">RFC 6428</span>, <span class="seriesInfo">DOI 10.17487/RFC6428</span>, <time datetime="2011-11" class="refDate">November 2011</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc6428">https://www.rfc-editor.org/info/rfc6428</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC7432">[RFC7432]</dt>
        <dd>
<span class="refAuthor">Sajassi, A., Ed.</span>, <span class="refAuthor">Aggarwal, R.</span>, <span class="refAuthor">Bitar, N.</span>, <span class="refAuthor">Isaac, A.</span>, <span class="refAuthor">Uttaro, J.</span>, <span class="refAuthor">Drake, J.</span>, and <span class="refAuthor">W. Henderickx</span>, <span class="refTitle">"BGP MPLS-Based Ethernet VPN"</span>, <span class="seriesInfo">RFC 7432</span>, <span class="seriesInfo">DOI 10.17487/RFC7432</span>, <time datetime="2015-02" class="refDate">February 2015</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc7432">https://www.rfc-editor.org/info/rfc7432</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC7623">[RFC7623]</dt>
        <dd>
<span class="refAuthor">Sajassi, A., Ed.</span>, <span class="refAuthor">Salam, S.</span>, <span class="refAuthor">Bitar, N.</span>, <span class="refAuthor">Isaac, A.</span>, and <span class="refAuthor">W. Henderickx</span>, <span class="refTitle">"Provider Backbone Bridging Combined with Ethernet VPN (PBB-EVPN)"</span>, <span class="seriesInfo">RFC 7623</span>, <span class="seriesInfo">DOI 10.17487/RFC7623</span>, <time datetime="2015-09" class="refDate">September 2015</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc7623">https://www.rfc-editor.org/info/rfc7623</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>, and <span class="refAuthor">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="RFC8174">[RFC8174]</dt>
      <dd>
<span class="refAuthor">Leiba, B.</span>, <span class="refTitle">"Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words"</span>, <span class="seriesInfo">BCP 14</span>, <span class="seriesInfo">RFC 8174</span>, <span class="seriesInfo">DOI 10.17487/RFC8174</span>, <time datetime="2017-05" class="refDate">May 2017</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8174">https://www.rfc-editor.org/info/rfc8174</a>&gt;</span>. </dd>
<dd class="break"></dd>
</dl>
</section>
<section id="section-6.2">
        <h3 id="name-informative-references">
<a href="#section-6.2" class="section-number selfRef">6.2. </a><a href="#name-informative-references" class="section-name selfRef">Informative References</a>
        </h3>
<dl class="references">
<dt id="IEEE-802.1Q">[IEEE-802.1Q]</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 Std 802.1Q-2014</span>, <span class="seriesInfo">DOI 10.1109/IEEESTD.2014.6991462</span>, <time datetime="2014-12" class="refDate">December 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="IEEE-802.3">[IEEE-802.3]</dt>
        <dd>
<span class="refAuthor">IEEE</span>, <span class="refTitle">"IEEE Standard for Ethernet"</span>, <span class="seriesInfo">IEEE Std 802.3-2018</span>, <span class="seriesInfo">DOI 10.1109/IEEESTD.2018.8457469</span>, <time datetime="2018-08" class="refDate">August 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="RFC2544">[RFC2544]</dt>
        <dd>
<span class="refAuthor">Bradner, S.</span> and <span class="refAuthor">J. McQuaid</span>, <span class="refTitle">"Benchmarking Methodology for Network Interconnect Devices"</span>, <span class="seriesInfo">RFC 2544</span>, <span class="seriesInfo">DOI 10.17487/RFC2544</span>, <time datetime="1999-03" class="refDate">March 1999</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc2544">https://www.rfc-editor.org/info/rfc2544</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC2681">[RFC2681]</dt>
        <dd>
<span class="refAuthor">Almes, G.</span>, <span class="refAuthor">Kalidindi, S.</span>, and <span class="refAuthor">M. Zekauskas</span>, <span class="refTitle">"A Round-trip Delay Metric for IPPM"</span>, <span class="seriesInfo">RFC 2681</span>, <span class="seriesInfo">DOI 10.17487/RFC2681</span>, <time datetime="1999-09" class="refDate">September 1999</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc2681">https://www.rfc-editor.org/info/rfc2681</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC3393">[RFC3393]</dt>
        <dd>
<span class="refAuthor">Demichelis, C.</span> and <span class="refAuthor">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="RFC5085">[RFC5085]</dt>
        <dd>
<span class="refAuthor">Nadeau, T., Ed.</span> and <span class="refAuthor">C. Pignataro, Ed.</span>, <span class="refTitle">"Pseudowire Virtual Circuit Connectivity Verification (VCCV): A Control Channel for Pseudowires"</span>, <span class="seriesInfo">RFC 5085</span>, <span class="seriesInfo">DOI 10.17487/RFC5085</span>, <time datetime="2007-12" class="refDate">December 2007</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc5085">https://www.rfc-editor.org/info/rfc5085</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC6136">[RFC6136]</dt>
        <dd>
<span class="refAuthor">Sajassi, A., Ed.</span> and <span class="refAuthor">D. Mohan, Ed.</span>, <span class="refTitle">"Layer 2 Virtual Private Network (L2VPN) Operations, Administration, and Maintenance (OAM) Requirements and Framework"</span>, <span class="seriesInfo">RFC 6136</span>, <span class="seriesInfo">DOI 10.17487/RFC6136</span>, <time datetime="2011-03" class="refDate">March 2011</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc6136">https://www.rfc-editor.org/info/rfc6136</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC6632">[RFC6632]</dt>
        <dd>
<span class="refAuthor">Ersue, M., Ed.</span> and <span class="refAuthor">B. Claise</span>, <span class="refTitle">"An Overview of the IETF Network Management Standards"</span>, <span class="seriesInfo">RFC 6632</span>, <span class="seriesInfo">DOI 10.17487/RFC6632</span>, <time datetime="2012-06" class="refDate">June 2012</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc6632">https://www.rfc-editor.org/info/rfc6632</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC6673">[RFC6673]</dt>
        <dd>
<span class="refAuthor">Morton, A.</span>, <span class="refTitle">"Round-Trip Packet Loss Metrics"</span>, <span class="seriesInfo">RFC 6673</span>, <span class="seriesInfo">DOI 10.17487/RFC6673</span>, <time datetime="2012-08" class="refDate">August 2012</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc6673">https://www.rfc-editor.org/info/rfc6673</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>, and <span class="refAuthor">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>, and <span class="refAuthor">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="Y.1731">[Y.1731]</dt>
      <dd>
<span class="refAuthor">ITU-T</span>, <span class="refTitle">"Operation, administration and maintenance (OAM) functions and mechanisms for Ethernet-based networks"</span>, <span class="seriesInfo">ITU-T Recommendation G.8013/Y.1731</span>, <time datetime="2015-08" class="refDate">August 2015</time>. </dd>
<dd class="break"></dd>
</dl>
</section>
</section>
<div id="sect-6">
<section id="appendix-A">
      <h2 id="name-acknowledgements">
<a href="#name-acknowledgements" class="section-name selfRef">Acknowledgements</a>
      </h2>
<p id="appendix-A-1">
   The authors would like to thank the following for their review of
   this work and their valuable comments:
<span class="contact-name">David Black</span>, <span class="contact-name">Martin Duke</span>, <span class="contact-name">Xiao Min</span>, <span class="contact-name">Gregory Mirsky</span>, <span class="contact-name">Zaheduzzaman Sarker</span>, <span class="contact-name">Dave Schinazi</span>, <span class="contact-name">John Scudder</span>, <span class="contact-name">Melinda Shore</span>, <span class="contact-name">Robert Wilton</span>, <span class="contact-name">Alexander Vainshtein</span>, <span class="contact-name">Stig Venaas</span>, and <span class="contact-name">Éric Vyncke</span>.<a href="#appendix-A-1" class="pilcrow">¶</a></p>
</section>
</div>
<div id="authors-addresses">
<section id="appendix-B">
      <h2 id="name-authors-addresses">
<a href="#name-authors-addresses" class="section-name selfRef">Authors' Addresses</a>
      </h2>
<address class="vcard">
        <div dir="auto" class="left"><span class="fn nameRole">Samer Salam</span></div>
<div dir="auto" class="left"><span class="org">Cisco</span></div>
<div dir="auto" class="left"><span class="street-address">The Atrium Building, Floor 3<br>Weygand St.</span></div>
<div dir="auto" class="left">
<span class="locality">Beirut</span> </div>
<div dir="auto" class="left"><span class="country-name">Lebanon</span></div>
<div class="email">
<span>Email:</span>
<a href="mailto:ssalam@cisco.com" class="email">ssalam@cisco.com</a>
</div>
</address>
<address class="vcard">
        <div dir="auto" class="left"><span class="fn nameRole">Ali Sajassi</span></div>
<div dir="auto" class="left"><span class="org">Cisco</span></div>
<div dir="auto" class="left"><span class="street-address">170 West Tasman Drive</span></div>
<div dir="auto" class="left">
<span class="locality">San Jose</span>, <span class="region">CA</span> <span class="postal-code">95134</span>
</div>
<div dir="auto" class="left"><span class="country-name">United States of America</span></div>
<div class="email">
<span>Email:</span>
<a href="mailto:sajassi@cisco.com" class="email">sajassi@cisco.com</a>
</div>
</address>
<address class="vcard">
        <div dir="auto" class="left"><span class="fn nameRole">Sam Aldrin</span></div>
<div dir="auto" class="left"><span class="org">Google, Inc.</span></div>
<div dir="auto" class="left"><span class="street-address">1600 Amphitheatre Parkway</span></div>
<div dir="auto" class="left">
<span class="locality">Mountain View</span>, <span class="region">CA</span> <span class="postal-code">94043</span>
</div>
<div dir="auto" class="left"><span class="country-name">United States of America</span></div>
<div class="email">
<span>Email:</span>
<a href="mailto: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">John E. Drake</span></div>
<div dir="auto" class="left"><span class="org">Juniper Networks</span></div>
<div dir="auto" class="left"><span class="street-address">1194 N. Mathilda Ave.</span></div>
<div dir="auto" class="left">
<span class="locality">Sunnyvale</span>, <span class="region">CA</span> <span class="postal-code">94089</span>
</div>
<div dir="auto" class="left"><span class="country-name">United States of America</span></div>
<div class="email">
<span>Email:</span>
<a href="mailto:jdrake@juniper.net" class="email">jdrake@juniper.net</a>
</div>
</address>
<address class="vcard">
        <div dir="auto" class="left"><span class="fn nameRole">Donald E. Eastlake 3rd</span></div>
<div dir="auto" class="left"><span class="org">Futurewei Technologies</span></div>
<div dir="auto" class="left"><span class="street-address">2386 Panoramic Circle</span></div>
<div dir="auto" class="left">
<span class="locality">Apopka</span>, <span class="region">FL</span> <span class="postal-code">32703</span>
</div>
<div dir="auto" class="left"><span class="country-name">United States of America</span></div>
<div class="tel">
<span>Phone:</span>
<a href="tel:+1-508-333-2270" class="tel">+1-508-333-2270</a>
</div>
<div class="email">
<span>Email:</span>
<a href="mailto:d3e3e3@gmail.com" class="email">d3e3e3@gmail.com</a>
</div>
</address>
</section>
</div>
<script>const toc = document.getElementById("toc");
toc.querySelector("h2").addEventListener("click", e => {
  toc.classList.toggle("active");
});
toc.querySelector("nav").addEventListener("click", e => {
  toc.classList.remove("active");
});
</script>
</body>
</html>