<?xml version='1.0' encoding='utf-8'?> version="1.0" encoding="utf-8"?>

<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY RFC0792 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.0792.xml">
<!ENTITY RFC2119 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC4443 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4443.xml">
<!ENTITY RFC5880 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5880.xml">
<!ENTITY RFC5881 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5881.xml">
<!ENTITY RFC5883 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5883.xml">
<!ENTITY RFC5884 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5884.xml">
<!ENTITY RFC6291 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6291.xml">
<!ENTITY RFC6425 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6425.xml">
<!ENTITY RFC6428 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6428.xml">
<!ENTITY RFC7432 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7432.xml">
<!ENTITY RFC7623 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7623.xml">
<!ENTITY RFC8029 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8029.xml">
<!ENTITY RFC8174 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml">
<!ENTITY RFC2544 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2544.xml">
<!ENTITY RFC2681 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2681.xml">
<!ENTITY RFC3393 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3393.xml">
<!ENTITY RFC5085 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5085.xml">
<!ENTITY RFC6136 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6136.xml">
<!ENTITY RFC6632 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6632.xml">
<!ENTITY RFC6673 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6673.xml">
<!ENTITY RFC7679 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7679.xml">
<!ENTITY RFC7680 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7680.xml">
]> "rfc2629-xhtml.ent">

<rfc submissionType="IETF" xmlns:xi="http://www.w3.org/2001/XInclude" docName="draft-ietf-bess-evpn-oam-req-frmwk-10" number="9062" submissionType="IETF" category="info" ipr="trust200902">
	<!-- Generated by id2xml 1.5.0 on 2021-04-28T21:49:22Z -->
	<?rfc strict="yes"?>
	<?rfc compact="yes"?>
	<?rfc subcompact="no"?>
	<?rfc symrefs="yes"?>
	<?rfc sortrefs="no"?>
	<?rfc text-list-symbols="-o*+"?>
	<?rfc toc="yes"?> consensus="true" ipr="trust200902" obsoletes="" updates="" xml:lang="en" symRefs="true" sortRefs="true" tocInclude="true" version="3" tocDepth="5">

  <front>
    <title abbrev="EVPN OAM Requirements/Framework">EVPN Operations, Administration Requirements/Framework">Framework and Maintenance Requirements for Ethernet VPN (EVPN) Operations, Administration, and Framework</title> Maintenance (OAM)</title>
    <seriesInfo name="RFC" value="9062"/>
    <author initials="S." surname="Salam" fullname="Samer Salam">
      <organization>Cisco</organization>
	<address><email>ssalam@cisco.com</email>
      <address>
        <email>ssalam@cisco.com</email>
      </address>
    </author>
    <author initials="A." surname="Sajassi" fullname="Ali Sajassi">
      <organization>Cisco</organization>
	<address><postal>
      <address>
        <postal>
          <street>170 West Tasman Drive</street>
          <city>San Jose</city>
          <region>CA</region>
          <code>95134</code>
          <country>United States of America</country>
        </postal>
        <email>sajassi@cisco.com</email>
      </address>
    </author>
    <author initials="S." surname="Aldrin" fullname="Sam Aldrin">
      <organization abbrev="Google">Google, Inc.</organization>
	<address><postal>
      <address>
        <postal>
          <street>1600 Amphitheatre Parkway</street>
          <city>Mountain View</city>
          <region>CA</region>
          <code>94043</code>
          <country>United States of America</country>
        </postal>
        <email>aldrin.ietf@gmail.com</email>
      </address>
    </author>
    <author initials="J." surname="Drake" fullname="John E. Drake">
      <organization abbrev="Juniper">Juniper Networks</organization>
	<address><postal>
      <address>
        <postal>
          <street>1194 N. Mathilda Ave.</street>
          <city>Sunnyvale</city>
          <region>CA</region>
          <code>94089</code>
          <country>United States of America</country>
        </postal>
        <email>jdrake@juniper.net</email>
      </address>
    </author>
    <author initials="D." surname="Eastlake" surname="Eastlake 3rd" fullname="Donald E. Eastlake, Eastlake 3rd">
      <organization abbrev="Futurewei">Futurewei Technologies</organization>
	<address><postal>
      <address>
        <postal>
          <street>2386 Panoramic Circle</street>
          <city>Apopka</city>
          <region>FL</region>
          <code>32703</code>
          <country>United States of America</country>
        </postal>
        <phone>+1-508-333-2270</phone>
        <email>d3e3e3@gmail.com</email>
      </address>
    </author>
    <date year="2021" month="April"/>

<!-- [rfced] Please insert any keywords (beyond those that appear in the title) for use on https://www.rfc-editor.org/search. -->

	<keyword>example</keyword>

	<abstract><t> month="June"/>

<keyword>PBB-EVPN</keyword>
<keyword>fault management</keyword>
<keyword>performance management</keyword>
    <abstract>
      <t>
   This document specifies the requirements and reference framework for
   Ethernet VPN (EVPN) Operations, Administration Administration, and Maintenance (OAM).
   The requirements cover the OAM aspects of EVPN and PBB-EVPN (Provider Provider Backbone Bridge EVPN). 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.</t>
    </abstract>
  </front>
  <middle>
    <section title="Introduction" anchor="sect-1"><t> anchor="sect-1" numbered="true" toc="default">
      <name>Introduction</name>
      <t>
   This document specifies the requirements and defines a reference
   framework for Ethernet VPN (EVPN) Operations, Administration Administration, and
   Maintenance (OAM, (OAM) <xref target="RFC6291"/>). target="RFC6291" format="default"/>. In this context, we use the term EVPN
   OAM "EVPN OAM" to loosely refer to the OAM functions required for and/or
   applicable to <xref target="RFC7432"/> target="RFC7432" format="default"/> and <xref target="RFC7623"/>.</t> target="RFC7623" format="default"/>.</t>
      <t>
   EVPN is a Layer 2 VPN (L2VPN) solution for multipoint Ethernet
   services,
   services with advanced multi-homing capabilities, using multihoming capabilities that uses BGP for
   distributing customer/client MAC Customer/Client Media Access Control (C-MAC) address reachability information
   over the core MPLS/IP network.</t>
      <t>
   PBB-EVPN combines Provider Backbone Bridging (PBB) <xref target="IEEE-802.1Q"/> target="IEEE-802.1Q" format="default"/> with EVPN in
   order to reduce the number of BGP MAC advertisement routes, routes; provide client
   MAC address mobility using C-MAC (Client MAC <xref target="RFC7623"/>) target="RFC7623" format="default"/> aggregation and
   B-MAC (Backbone
   Backbone MAC (B-MAC) <xref target="RFC7623"/>) sub-netting, target="RFC7623" format="default"/> sub-netting; confine the scope of C-MAC
   learning to only active flows, flows; offer per site policies, per-site policies; and avoid C-MAC
   address flushing on topology changes.</t>
      <t>
   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.</t>
      <section title="Relationship anchor="sect-1.1" numbered="true" toc="default">
        <name>Relationship to Other OAM Work" anchor="sect-1.1"><t> Work</name>
        <t>
   This document leverages concepts and draws upon elements defined
   and/or
   and / or used in the following documents:</t>
        <t>
   <xref target="RFC6136"/> target="RFC6136" format="default"/> specifies the requirements and a reference model for OAM as
   it relates to L2VPN services, pseudowires pseudowires, and associated Packet
   Switched Network (PSN) tunnels. This document focuses on VPLS Virtual Private LAN Service (VPLS) and
   VPWS Virtual Private Wire Service (VPWS) solutions and services.</t>
        <t>
   <xref target="RFC8029"/> target="RFC8029" format="default"/> defines mechanisms for detecting data plane failures in
   MPLS LSPs, Label Switched Paths (LSPs), including procedures to check the correct operation of the
   data plane, plane as well as mechanisms to verify the data plane against
   the control plane.</t>
        <t>
   <xref target="IEEE-802.1Q"/> target="IEEE-802.1Q" format="default"/> specifies the Ethernet Connectivity Fault Management (CFM)
   protocol, which defines the concepts of Maintenance Domains,
   Maintenance Associations, Maintenance End Points, and Maintenance
   Intermediate Points.</t>
        <t>
   [Y.1731]
   <xref target="Y.1731"/> extends Connectivity Fault Management in the following
   areas: it defines fault notification and alarm suppression functions
   for Ethernet.  It also Ethernet and specifies mechanisms for Ethernet performance
   management, including loss, delay, jitter, and throughput
   measurement.</t>
      </section>
      <section title="Specification anchor="sect-1.2" numbered="true" toc="default">
        <name>Specification of Requirements" anchor="sect-1.2"><t> Requirements</name>
        <t>
    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
    NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
    "<bcp14>MAY</bcp14>", and
   "OPTIONAL" "<bcp14>OPTIONAL</bcp14>" in this document are to be interpreted as
    described in BCP
   14 BCP&nbsp;14 <xref target="RFC2119"/> <xref target="RFC8174"/>
    when, and only when, they appear in all capitals, as shown here.</t> here.
        </t>
      </section>
      <section title="Terminology" anchor="sect-1.3"><t> anchor="sect-1.3" numbered="true" toc="default">
        <name>Terminology</name>
        <t>
   This document uses the following terminology terminology, much of which is defined
   in <xref target="RFC6136"/>:

	<list style="hanging" hangIndent="6">

	  <t hangText="CE">Customer target="RFC6136" format="default"/>:

        </t>
        <dl newline="false" spacing="normal" indent="12">
          <dt>CE</dt>
          <dd>Customer Edge device, e.g., device; for example, a host, router, or switch.</t>

	  <t hangText="CFM">Connectivity switch.</dd>
          <dt>CFM</dt>
          <dd>Connectivity Fault Management <xref target="IEEE-802.1Q"/>.</t>

	  <t hangText="DF">Designated target="IEEE-802.1Q" format="default"/></dd>
          <dt>DF</dt>
          <dd>Designated Forwarder <xref target="RFC7432"/>.</t>

	  <t hangText="Down MEP">A target="RFC7432" format="default"/></dd>
          <dt>Down MEP</dt>
          <dd>A MEP that originates traffic away from and terminates
  	     traffic towards the core of the device in whose port it is logically located.</t>

	  <t hangText="EVI">An located.</dd>
          <dt>EVI</dt>
          <dd>An EVPN instance spanning the Provider Edge (PE)
	  devices participating in that EVPN <xref target="RFC7432"/>.</t>

	  <t hangText="L2VPN">Layer target="RFC7432" format="default"/>.</dd>
          <dt>L2VPN</dt>
          <dd>Layer 2 VPN.</t>

	  <t hangText="MA">Maintenance Association is VPN</dd>
          <dt>LOC</dt>
          <dd>Loss of continuity</dd>
          <dt>MA</dt>
          <dd>Maintenance Association; a set of MEPs belonging
	  to the same Maintenance Domain (MD), (MD) established to verify the
	  integrity of a single service instance <xref target="IEEE-802.1Q"/>.</t>

	  <t hangText="MD">Maintenance Domain, target="IEEE-802.1Q" format="default"/>.</dd>
          <dt>MD</dt>
          <dd>Maintenance Domain; an OAM Domain that represents a
	  region over which OAM frames can operate unobstructed <xref
	  target="IEEE-802.1Q"/>.</t>

	  <t hangText="MEP">Maintenance target="IEEE-802.1Q" format="default"/>.</dd>
          <dt>MEP</dt>
          <dd>Maintenance End Point 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 <xref target="IEEE-802.1Q"/>.</t>

	  <t hangText="MIP"> target="IEEE-802.1Q" format="default"/>.</dd>
          <dt>MIP</dt>
          <dd> Maintenance Intermediate Point 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
	  <xref target="IEEE-802.1Q"/>.</t>

	  <t hangText="MP2P">Multipoint to Point.</t>

	  <t hangText="NMS">Network target="IEEE-802.1Q" format="default"/>.</dd>
          <dt>MP2P</dt>
          <dd>Multipoint to Point</dd>
          <dt>NMS</dt>
          <dd>Network Management Station <xref target="RFC6632"/>.</t>

	  <t hangText="P">Provider target="RFC6632" format="default"/></dd>
          <dt>P</dt>
          <dd>Provider network interior (non-edge) node.</t>

	  <t hangText="P2MP">Point to Multipoint.</t>

	  <t hangText="PBB">Provider node</dd>
          <dt>P2MP</dt>
          <dd>Point to Multipoint</dd>
          <dt>PBB</dt>
          <dd>Provider Backbone Bridge <xref target="RFC7623"/>.</t>

	  <t hangText="PE">Provider network target="RFC7623" format="default"/></dd>
          <dt>PE</dt>
          <dd>Provider Edge device.</t>

	  <t hangText="Up MEP"> network device</dd>
          <dt>Up MEP</dt>
          <dd> A MEP that originates traffic towards and
	  terminates traffic from the core of the device in whose port it is
	  logically located.</t>

	  <t hangText="VPN">Virtual located.</dd>
          <dt>VPN</dt>
          <dd>Virtual Private Network</t>

	</list>
	</t> Network</dd>
        </dl>
      </section>
    </section>
    <section title="EVPN anchor="sect-2" numbered="true" toc="default">
      <name>EVPN OAM Framework" anchor="sect-2"><section title="OAM Layering" anchor="sect-2.1"><t> Framework</name>
      <section anchor="sect-2.1" numbered="true" toc="default">
        <name>OAM Layering</name>
        <t>
   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 service and Network network layers.</t>

	<t><list style="symbols">

	<t>The Service Layer
        <ul spacing="normal">
          <li>The service layer runs end to end between the sites or Ethernet
     Segments
     segments that are being interconnected by the EVPN solution.</t>

	<t>The Network Layer solution.</li>
          <li>The network layer extends between the EVPN PE (Provider Edge) nodes
     and is mostly transparent to the P (Provider (provider network interior)
     nodes (except where Flow Entropy flow entropy comes into play). It leverages
     MPLS for service (i.e., EVI) multiplexing and Split-Horizon
     functions.</t>

	<t>The Transport Layer split-horizon
     functions.</li>
          <li>The transport layer is dictated by the networking technology of the
     PSN. It may be either based on either MPLS LSPs or IP.</t>

	<t>The Link Layer IP.</li>
          <li>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., POS, DWDM etc.).</t>

	</list>
	</t> Packet over SONET (POS), Dense Wavelength Division Multiplexing (DWDM), etc.).</li>
        </ul>
        <t>
   This layering extends to the set of OAM protocols that are involved
   in the ongoing maintenance and diagnostics of EVPN networks. Figure 1 <xref target="fig-1"/>
   below depicts the OAM layering, layering and shows which devices have
   visibility into what OAM layer(s).</t>
        <figure title="OAM Layering" anchor="fig-1"><artwork><![CDATA[ anchor="fig-1">
          <name>OAM Layering</name>
          <artwork name="" type="" align="left" alt=""><![CDATA[
        +---+                               +---+
+--+    |   |    +---+    +---+    +---+    |   |    +--+
|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
]]></artwork>
        </figure>
        <t>
   Service OAM and Network OAM mechanisms only have visibility to the PE
   (Provider Edge)
  nodes but not the P (Provider interior) nodes. As
   such, they can be used to deduce whether the fault is in the</t>

	<t> the customer's own network, the local CE-PE segment, the PE-PE segment segment, or
   the remote CE-PE segment(s). EVPN Transport OAM mechanisms can be
   used for fault isolation between the PEs and P nodes.</t>
   <t>
   Figure 2

   <xref target="fig-2"/> below shows an example network where native Ethernet domains
   are interconnected via EVPN using MPLS MPLS, and gives it shows the OAM mechanisms
   that are applicable at each layer. The details of the layers are described in
   the sections below.</t>
        <figure title="EVPN anchor="fig-2">
          <name>EVPN OAM Example" anchor="fig-2"><artwork><![CDATA[ Example</name>
          <artwork name="" type="" align="left" alt=""><![CDATA[
        +---+                               +---+
+--+    |   |    +---+    +---+    +---+    |   |    +--+
|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] 802.3 OAM
                                                       [IEEE-802.3]
]]></artwork>
        </figure>
      </section>
      <section title="EVPN anchor="sect-2.2" numbered="true" toc="default">
        <name>EVPN Service OAM" anchor="sect-2.2"><t> OAM</name>
        <t>
   The EVPN Service OAM protocol depends on what service layer service-layer
   technology is being interconnected by the EVPN solution. In the case of
   <xref target="RFC7432"/> target="RFC7432" format="default"/> and <xref target="RFC7623"/>, target="RFC7623" format="default"/>, the service layer is Ethernet; hence, the
   corresponding service Service OAM protocol is Ethernet Connectivity Fault
   Management (CFM) CFM <xref target="IEEE-802.1Q"/>.</t> target="IEEE-802.1Q" format="default"/>.</t>
        <t>
   EVPN service Service OAM is visible to the CEs and EVPN PEs, PEs but not to the P
   nodes. This is because the PEs operate at the Ethernet MAC layer in
   <xref target="RFC7432"/> target="RFC7432" format="default"/> and <xref target="RFC7623"/> target="RFC7623" format="default"/>, whereas the P nodes do not.</t>
        <t>
   The EVPN PE MUST <bcp14>MUST</bcp14> support MIP functions in the applicable service Service OAM
   protocol, for example
   protocol (for example, Ethernet CFM. CFM). The EVPN PE SHOULD <bcp14>SHOULD</bcp14> support MEP
   functions in the applicable service Service OAM protocol. This includes both
   Up and Down MEP functions.</t>
        <t>
   As shown in Figure 3, <xref target="fig-3"/>, 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
   network, but they would not be relevant to EVPN Service OAM as the
   traffic passing through them will be encapsulated/tunneled encapsulated/tunneled, so any
   customer level
   customer-level OAM messages will just be treated as data.)  Down MEP</t>

	<t> MEP
   functions are away from the core of the device while up 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 OAM, while such messages between the
   CEs or from a PE to its local CE or to the remote CE are Service OAM.</t> OAMs.</t>
        <figure title="CFM Details" anchor="fig-3"><artwork><![CDATA[ anchor="fig-3">
          <name>CFM Details</name>
          <artwork name="" type="" align="left" alt=""><![CDATA[
 +-------+   +----------------+       +----------------+   +-------+
 |+-----+|   |+--------------+|       |+--------------+|   |+-----+|
 ||  CE ||   ||     PE       ||  ...  ||       PE     ||   || CE  ||
 |+--+--+|   |+---+--------+-+|       |+-+--------+---+|   |+--+--+|
 |   |   |   |    |        |  |       |  |        |    |   |   |   |
 |+--+--+|   |+---+-----+  .  |       |  .  +-----+---+|   |+--+--+|
 || MEP ||   ||   | Up ^|  .  |  ...  |  .  | Up ^|   ||   || MEP ||
 ||DownV||   ||MIP|MEP  |  .  |       |  .  |MEP  |MIP||   ||DownV||
 |+--+--+|   ||   |DownV|  .  |       |  .  |DownV|   ||   |+--+--+|
 |   |   |   |+---+-----+  |  |       |  |  +-----+---+|   |   |   |
 +---|---+   +----|--------|--+       +--|--------|----+   +---|---+
     |            |        |             |        |            |
     +------------+        +---  ...  ---+        +------------+
]]></artwork>
        </figure>
        <t>
   The EVPN PE MUST, <bcp14>MUST</bcp14>, 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 SHOULD <bcp14>SHOULD</bcp14> be implemented.</t>
        <t>
   The EVPN PE SHOULD <bcp14>SHOULD</bcp14> advertise any MEP/MIP local to the PE as a MAC/IP
   Advertisement route. Since these are not subject to mobility, they
   SHOULD
   <bcp14>SHOULD</bcp14> be advertised with the static (sticky) bit set (see Section
   15.2 of <xref target="RFC7432"/>).</t> target="RFC7432" sectionFormat="of" section="15.2"/>).</t>
      </section>
      <section title="EVPN anchor="sect-2.3" numbered="true" toc="default">
        <name>EVPN Network OAM" anchor="sect-2.3"><t> OAM</name>
        <t>
   EVPN Network OAM is visible to the PE nodes only. This OAM layer is
   analogous to VCCV Virtual Circuit Connectivity Verification (VCCV) <xref target="RFC5085"/> target="RFC5085" format="default"/> in the case of VPLS/VPWS. It provides
   mechanisms to check the correct operation of the data plane, 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:</t>

	<t><list style="symbols"><t>the
        <ul spacing="normal">
          <li>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; Tag&gt;, and label
     per MAC address. In all three models, the label is bound to an EVPN
     Unicast FEC. Forwarding Equivalence Class (FEC).  EVPN Network OAM MUST <bcp14>MUST</bcp14> provide mechanisms to check the
     operation of the data plane and verify that operation against the
     control plane view.</t>

	<t>the view.</li>
          <li>the MP2P tunnels used for aliasing unicast traffic destined to a
     multi-homed
     multihomed Ethernet Segment. 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 MUST <bcp14>MUST</bcp14> provide
     mechanisms to check the operation of the data plane and verify that
     operation against the control plane view.</t>

	<t>the view.</li>
          <li>the multicast tunnels (either MP2P or P2MP) used for the transport
     of broadcast, unknown unicast 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 LSM (Label Label Switched Multicast), and Multicast (LSM) and, more specifically specifically,
     aggregate inclusive trees, again again, a label may be allocated per EVI
     or per &lt;EVI, Ethernet Tag&gt; and is bound to the tunnel FEC.</t>

	<t>the FEC.</li>
          <li>the correct operation of the ESI Ethernet Segment Identifier (ESI) split-horizon filtering function.
     In EVPN, a label is allocated per multi-homed multihomed Ethernet Segment segment for
     the purpose of performing the access split-horizon enforcement. The
     label is bound to an EVPN Ethernet Segment.</t>

	<t>the segment.</li>
          <li>the correct operation of the DF (Designated Designated Forwarder (DF) <xref target="RFC7432"/>) target="RFC7432" format="default"/>
     filtering function.  EVPN Network OAM MUST <bcp14>MUST</bcp14> provide mechanisms to
     check the operation of the data plane and verify that operation
     against the control plane view for the DF filtering function.</t>

	</list>
	</t> function.</li>
        </ul>
        <t>
   EVPN Network OAM mechanisms MUST <bcp14>MUST</bcp14> 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.</t>
        <t>
   EVPN Network OAM SHOULD <bcp14>SHOULD</bcp14> provide both proactive and on-demand
   mechanisms of monitoring the data plane operation and data plane
   conformance to the state of the control plane.</t>
      </section>
      <section title="Transport anchor="sect-2.4" numbered="true" toc="default">
        <name>Transport OAM for EVPN" anchor="sect-2.4"><t> EVPN</name>
        <t>
   The transport Transport OAM protocol depends on the nature of the underlying
   transport technology in the PSN. MPLS OAM mechanisms <xref target="RFC8029"/> target="RFC8029" format="default"/>
          <xref target="RFC6425"/> target="RFC6425" format="default"/> as well as ICMP <xref target="RFC0792"/> / target="RFC0792" format="default"/> and ICMPv6 <xref target="RFC4443"/> target="RFC4443" format="default"/> are applicable,
   depending on whether the PSN employs MPLS or IP transport,
   respectively.  Furthermore, BFD Bidirectional Forwarding Detection (BFD) mechanisms per <xref target="RFC5880"/>, target="RFC5880" format="default"/>, <xref target="RFC5881"/>, target="RFC5881" format="default"/>,
   <xref target="RFC5883"/> target="RFC5883" format="default"/>, and <xref target="RFC5884"/> target="RFC5884" format="default"/> apply. Also, the BFD mechanisms pertaining to
   MPLS-TP LSPs per <xref target="RFC6428"/> target="RFC6428" format="default"/> are applicable.</t>
      </section>
      <section title="Link OAM" anchor="sect-2.5"><t> anchor="sect-2.5" numbered="true" toc="default">
        <name>Link OAM</name>
        <t>
   Link OAM depends on the data link data-link technology being used between the
   PE and P nodes. For example, if Ethernet links are employed, then
   Ethernet Link OAM (<xref target="IEEE-802.3"/> target="IEEE-802.3" format="default"/>, Clause 57) may be used.</t>
      </section>
      <section title="OAM Inter-working" anchor="sect-2.6"><t> anchor="sect-2.6" numbered="true" toc="default">
        <name>OAM Interworking</name>
        <t>
   When inter-working interworking two networking domains, such as native 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 (CCMs)
   <xref target="IEEE-802.1Q"/>), target="IEEE-802.1Q" format="default"/>, 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., native 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.</t>
        <t>
   OAM inter-working interworking is not limited though limited, though, to scenarios involving disparate
   network domains. It is possible to perform OAM inter-working 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    client-layer OAM mechanisms. This allows the
   client layer
   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.</t>
        <t>
   EVPN OAM MUST <bcp14>MUST</bcp14> support inter-working interworking between the Network OAM and
   Service OAM mechanisms. EVPN OAM MAY <bcp14>MAY</bcp14> support inter-working interworking among
   other OAM layers.</t>
      </section>
    </section>
    <section title="EVPN anchor="sect-3" numbered="true" toc="default">
      <name>EVPN OAM Requirements" anchor="sect-3"><t> Requirements</name>
      <t>
   This section discusses the EVPN OAM requirements pertaining to Fault
   Management fault
   management and Performance Management.</t> performance management.</t>
      <section title="Fault anchor="sect-3.1" numbered="true" toc="default">
        <name>Fault Management Requirements" anchor="sect-3.1"><section title="Proactive Requirements</name>
        <section anchor="sect-3.1.1" numbered="true" toc="default">
          <name>Proactive Fault Management Functions" anchor="sect-3.1.1"><t> Functions</name>
          <t>
   The network operator configures proactive fault management functions
   to run periodically without a time bound. periodically. Certain actions, for
   example actions (for
   example, protection switchover or alarm indication signaling, signaling) can be
   associated with specific events, such as entering or clearing fault
   states.</t>
          <section title="Fault anchor="sect-3.1.1.1" numbered="true" toc="default">
            <name>Fault Detection (Continuity Check)" anchor="sect-3.1.1.1"><t> Check)</name>
            <t>
   Proactive fault detection is performed by periodically monitoring the
   reachability between service endpoints, end points, i.e., MEPs in a given MA,
   through the exchange of Continuity Check Messages CCMs <xref target="IEEE-802.1Q"/>. target="IEEE-802.1Q" format="default"/>. The
   reachability between any two arbitrary MEPs may be monitored for:</t>

	<t><list style="symbols"><t>in-band
            <ul spacing="normal">
              <li>in-band, per-flow monitoring. This enables per flow per-flow monitoring
     between MEPs. EVPN Network OAM MUST <bcp14>MUST</bcp14> support fault detection with
     per user
     per-user flow granularity. EVPN Service OAM MAY <bcp14>MAY</bcp14> support fault
     detection with per user per-user flow granularity.</t>

	<t>a granularity.</li>
              <li>a representative path. This enables a liveness check of the nodes
     hosting the MEPs 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, detection through the use of a test flow. EVPN Network OAM
     and Service OAM MUST <bcp14>MUST</bcp14> support fault detection using test flows.</t>

	<t>all flows.</li>
              <li>all paths. For MPLS/IP networks with ECMP, the monitoring of all unicast
     paths between MEPs (on non-adjacent nodes) may not be possible, 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. Monitoring The monitoring of all ECMP paths between
     MEPs (on non-adjacent nodes) is not a requirement for EVPN OAM.</t>

	</list>
	</t> OAM.</li>
            </ul>
            <t>
   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 MUST <bcp14>MUST</bcp14> provide procedures to monitor the
   unicast paths independently of the multicast paths. This applies to
   EVPN Service OAM and Network OAM.</t>
          </section>
          <section title="Defect Indication" anchor="sect-3.1.1.2"><t> anchor="sect-3.1.1.2" numbered="true" toc="default">
            <name>Defect Indication</name>
            <t>
   Defect indications can be categorized into two types: forward and
   reverse defect indications
   reverse, as described below. EVPN Service OAM MUST <bcp14>MUST</bcp14>
   support at least one of these types of event-driven defect indication indications
   upon the detection of a connectivity defect.</t>
            <section title="Forward anchor="sect-3.1.1.2.1" numbered="true" toc="default">
              <name>Forward Defect Indication" anchor="sect-3.1.1.2.1"><t>
   This Indication (FDI)</name>
              <t>
   FDI is used to signal a failure that is detected by a lower layer lower-layer
   OAM mechanism. A server MEP (i.e., an actual or virtual MEP)
   transmits a Forward Defect Indication forward defect indication in a direction that is away
   from the direction of the failure (refer to Figure 4 <xref target="fig-4"/> below).</t>
              <figure title="Forward anchor="fig-4">
                <name>Forward Defect Indication" anchor="fig-4"><artwork><![CDATA[ Indication</name>
                <artwork name="" type="" align="left" alt=""><![CDATA[
                           Failure
                              |
       +-----+      +-----+   V   +-----+      +-----+
       |  A  |------|  B  |--XXX--|  C  |------|  D  |
       +-----+      +-----+       +-----+      +-----+

           <===========|             |============>
             Forward                    Forward
             Defect                     Defect
             Indication                 Indication
]]></artwork>
              </figure>
              <t>
   Forward defect indication may be used for alarm suppression and/or
   for the purpose of inter-working interworking with other layer OAM protocols. Alarm
   suppression is useful when a transport/network level transport-level or network-level fault translates
   to multiple service service- or flow level flow-level faults. In such a scenario, it is
   enough to alert a network management station (NMS) of the single
   transport/network level
   transport-level or network-level fault in lieu of flooding that NMS with a
   multitude of Service or Flow granularity alarms. EVPN PEs SHOULD <bcp14>SHOULD</bcp14>
   support Forward Defect Indication forward defect indication in the Service OAM mechanisms.</t>
            </section>
            <section title="Reverse anchor="sect-3.1.1.2.2" numbered="true" toc="default">
              <name>Reverse Defect Indication (RDI)" anchor="sect-3.1.1.2.2"><t> (RDI)</name>

              <t>
   RDI is used to signal that the advertising MEP has detected a loss of
   continuity (LoC) LOC defect. RDI is transmitted in the direction of the
   failure (refer to Figure 5).</t> <xref target="fig-5"/>).</t>
              <figure title="Reverse anchor="fig-5">
                <name>Reverse Defect Indication" anchor="fig-5"><artwork><![CDATA[ Indication</name>
                <artwork name="" type="" align="left" alt=""><![CDATA[
                           Failure
                              |
       +-----+      +-----+   V   +-----+      +-----+
       |  A  |------|  B  |--XXX--|  C  |------|  D  |
       +-----+      +-----+       +-----+      +-----+

           |===========>             <============|
             Reverse                    Reverse
             Defect                     Defect
             Indication                 Indication
]]></artwork>
              </figure>
              <t>
   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 SHOULD <bcp14>SHOULD</bcp14> support Reverse Defect Indication reverse defect indication
   in the Service OAM mechanisms. This includes both the ability to
   signal LoC a LOC defect to a remote MEP, 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 LOC defect.</t>
            </section>
          </section>
        </section>
        <section title="On-Demand anchor="sect-3.1.2" numbered="true" toc="default">
          <name>On-Demand Fault Management Functions" anchor="sect-3.1.2"><t> Functions</name>
          <t>
   On-demand fault management functions are initiated manually by the
   network operator and continue for a bounded time bound period. These
   functions enable the operator to run diagnostics to investigate a
   defect condition.</t>
          <section title="Connectivity Verification" anchor="sect-3.1.2.1"><t> anchor="sect-3.1.2.1" numbered="true" toc="default">
            <name>Connectivity Verification</name>
            <t>
   EVPN Network OAM MUST <bcp14>MUST</bcp14> support on-demand connectivity verification
   mechanisms for unicast and multicast destinations. The connectivity
   verification mechanisms SHOULD <bcp14>SHOULD</bcp14> provide a means for specifying and
   carrying the following in the messages:</t>

	<t><list style="symbols"><t>variable length
            <ul spacing="normal">
              <li>variable-length payload/padding to test MTU (Maximum Transmission
     Unit) related connectivity problems.</t>

	<t>test problems related to the Maximum Transmission Unit (MTU).</li>
              <li>test frame formats as defined in Appendix C of <xref target="RFC2544"/> target="RFC2544" sectionFormat="of" section="C"/> to detect
     potential packet corruption.</t>

	</list>
	</t> corruption.</li>
            </ul>
            <t>
   EVPN Network OAM MUST <bcp14>MUST</bcp14> support connectivity verification at per flow 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).</t>
            <t>
   EVPN Service OAM MUST <bcp14>MUST</bcp14> support connectivity verification on test flows
   and MAY <bcp14>MAY</bcp14> support connectivity verification on user flows.</t>
            <t>
   For multicast connectivity verification, EVPN Network OAM MUST <bcp14>MUST</bcp14>
   support reporting on:</t>

	<t><list style="symbols"><t>the
            <ul spacing="normal">
              <li>the DF filtering status of a specific port(s) or all the ports in a
     given bridge-domain.</t>

	<t>the Split Horizon bridge domain.</li>
              <li>the split-horizon filtering status of a specific port(s) or all the
     ports in a given bridge-domain.</t>

	</list>
	</t> bridge domain.</li>
            </ul>
          </section>
          <section title="Fault Isolation" anchor="sect-3.1.2.2"><t> anchor="sect-3.1.2.2" numbered="true" toc="default">
            <name>Fault Isolation</name>
            <t>
   EVPN OAM MUST <bcp14>MUST</bcp14> support an on-demand fault localization function. This
   involves the capability to narrow down the locality of a fault to a
   particular port, link link, or node. The characteristic of forward/reverse path
   asymmetry,
   asymmetry in MPLS/IP, 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 fault-isolation procedures from PE A
   to PE B as well as from PE B to PE A.</t>
            <t>
   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 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.</t>
          </section>
        </section>
      </section>
      <section title="Performance Management" anchor="sect-3.2"><t> anchor="sect-3.2" numbered="true" toc="default">
        <name>Performance Management</name>
        <t>
   Performance Management management functions can be performed both proactively
   and on-demand. 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.</t>
        <section title="Packet Loss" anchor="sect-3.2.1"><t> anchor="sect-3.2.1" numbered="true" toc="default">
          <name>Packet Loss</name>
          <t>
   EVPN Network OAM SHOULD <bcp14>SHOULD</bcp14> provide mechanisms for measuring packet loss
   for a given service, service -- for example example, <xref target="RFC7680"/> target="RFC7680" format="default"/> and <xref target="RFC6673"/>.</t> target="RFC6673" format="default"/>.</t>
          <t>
   Given that EVPN provides inherent support for multipoint-to-multipoint
   connectivity, then 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,
   un-pruned multicast
   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.</t>
        </section>
        <section title="Packet anchor="sect-3.2.2" numbered="true" toc="default">
          <name>Packet Delay and Jitter" anchor="sect-3.2.2"><t> Jitter</name>
          <t>
   EVPN Service OAM SHOULD <bcp14>SHOULD</bcp14> 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 [Y.1731] <xref target="Y.1731"/> can
   be used. See also <xref target="RFC7679"/>, target="RFC7679" format="default"/>, <xref target="RFC2681"/>, target="RFC2681" format="default"/>, and <xref target="RFC3393"/></t> target="RFC3393" format="default"/>.</t>
          <t>
   EVPN Network OAM MAY <bcp14>MAY</bcp14> support measurement of one-way and two-way
   packet delay and delay variation (jitter) across the EVPN network.</t>
        </section>
      </section>
    </section>
    <section title="Security Considerations" anchor="sect-4"><t> anchor="sect-4" numbered="true" toc="default">
      <name>Security Considerations</name>
      <t>
   EVPN OAM MUST <bcp14>MUST</bcp14> 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.</t>
      <t>
   EVPN OAM SHOULD <bcp14>SHOULD</bcp14> provide mechanisms for implementation and optional
   use to:</t>

	<t><list style="symbols"><t>Prevent denial of service
      <ul spacing="normal">
        <li>prevent denial-of-service attacks caused by exploitation of the OAM
     message channel (for example example, by forging messages to exceed a
     maintenance end point's
     Maintenance End Point's capacity to maintain state).</t>

	<t>Authenticate state).</li>
        <li>authenticate communicating endpoints end points (for example example, MEPs and MIPs).</t>

	</list>
	</t> MIPs).</li>
      </ul>
    </section>
    <section title="IANA Considerations" anchor="sect-5"><t> anchor="sect-5" numbered="true" toc="default">
      <name>IANA Considerations</name>
      <t>
   This document requires has no IANA actions.</t>
    </section>

	<section title="Acknowledgements" anchor="sect-6"><t>
   The authors would like to thank the following for their review of
   this work and valuable comments:</t>

<figure><artwork><![CDATA[
      David Black, Martin Duke, Xiao Min, Gregory Mirsky,
      Zaheduzzaman Sarker, Dave Schinazi, John Scudder,
      Melinda Shore, Robert Wilton, Alexander Vainshtein,
      Stig Venaas, and Eric Vyncke.
 ]]></artwork></figure>

	</section>
  </middle>
  <back>
	<references title="Normative References">
	&RFC0792;
	&RFC2119;
	&RFC4443;
	&RFC5880;
	&RFC5881;
	&RFC5883;
	&RFC5884;
	&RFC6291;
	&RFC6425;
	&RFC6428;
	&RFC7432;
	&RFC7623;
	&RFC8029;
	&RFC8174;
    <references>
      <name>References</name>
      <references>
        <name>Normative References</name>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.0792.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4443.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5880.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5881.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5883.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5884.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6291.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6425.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6428.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7432.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7623.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8029.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/>
      </references>
	<references title="Informative References">
      <references>
        <name>Informative References</name>

        <reference anchor="IEEE-802.1Q"><front> anchor="IEEE-802.1Q">
          <front>
            <title>IEEE Standard for Local and metropolitan area networks - Media Access Control (MAC) Bridges networks--Bridges and Virtual Bridge Local Area Bridged Networks</title>
            <author>
              <organization>IEEE</organization>
            </author>
            <date month="December" year="2014"/>
          </front>
          <seriesInfo name="IEEE" value="Std 802.1Q-2014"/>
          <seriesInfo name="DOI" value="10.1109/IEEESTD.2014.6991462"/>
        </reference>

        <reference anchor="IEEE-802.3"><front> anchor="IEEE-802.3">
          <front>
            <title>IEEE Standard for Ethernet</title>
            <author>
              <organization>IEEE</organization>
            </author>
            <date year="2015"/> year="2018" month="August"/>
          </front>
          <seriesInfo name="IEEE" value="Std 802.3-2015"/> 802.3-2018"/>
          <seriesInfo name="DOI" value="10.1109/IEEESTD.2018.8457469"/>
        </reference>
	&RFC2544;
	&RFC2681;
	&RFC3393;
	&RFC5085;
	&RFC6136;
	&RFC6632;
	&RFC6673;
	&RFC7679;
	&RFC7680;

	<!--
   draft-ietf-bess-evpn-oam-req-frmwk-10-manual.txt(799): Warning: Failed parsing a
   reference.  Are all elements separated by commas (not periods, not just
   spaces)?:
   [Y.1731]  "ITU-T Recommendation Y.1731 (02/08) - OAM

        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2544.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2681.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3393.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5085.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6136.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6632.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6673.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7679.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7680.xml"/>

        <reference anchor="Y.1731">
          <front>

            <title>Operation, administration and maintenance (OAM) functions and mechanisms for Ethernet based networks", February 2008.
   --> Ethernet-based networks</title>
            <author>
              <organization>ITU-T</organization>
            </author>
            <date year="2015" month="August"/>
          </front>
          <seriesInfo name="ITU-T Recommendation" value="G.8013/Y.1731"/>
        </reference>
	</references>
    </references>
    <section anchor="sect-6" numbered="false" toc="default">
      <name>Acknowledgements</name>
      <t>
   The authors would like to thank the following for their review of
   this work and their valuable comments:
<contact fullname="David Black"/>, <contact fullname="Martin Duke"/>, <contact fullname="Xiao Min"/>, <contact fullname="Gregory Mirsky"/>, <contact fullname="Zaheduzzaman Sarker"/>, <contact fullname="Dave Schinazi"/>, <contact fullname="John Scudder"/>, <contact fullname="Melinda Shore"/>, <contact fullname="Robert Wilton"/>, <contact fullname="Alexander Vainshtein"/>, <contact fullname="Stig Venaas"/>, and <contact fullname="Éric Vyncke"/>.</t>
    </section>
  </back>

</rfc>