rfc9062xml2.original.xml   rfc9062.xml 
<?xml version='1.0' encoding='utf-8'?> <?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY RFC0792 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.0792.xml">
<!ENTITY RFC2119 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.2119.xml">
<!ENTITY RFC4443 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.4443.xml">
<!ENTITY RFC5880 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.5880.xml">
<!ENTITY RFC5881 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.5881.xml">
<!ENTITY RFC5883 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.5883.xml">
<!ENTITY RFC5884 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.5884.xml">
<!ENTITY RFC6291 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.6291.xml">
<!ENTITY RFC6425 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.6425.xml">
<!ENTITY RFC6428 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.6428.xml">
<!ENTITY RFC7432 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.7432.xml">
<!ENTITY RFC7623 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.7623.xml">
<!ENTITY RFC8029 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.8029.xml">
<!ENTITY RFC8174 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.8174.xml">
<!ENTITY RFC2544 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.2544.xml">
<!ENTITY RFC2681 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.2681.xml">
<!ENTITY RFC3393 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.3393.xml">
<!ENTITY RFC5085 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.5085.xml">
<!ENTITY RFC6136 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.6136.xml">
<!ENTITY RFC6632 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.6632.xml">
<!ENTITY RFC6673 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.6673.xml">
<!ENTITY RFC7679 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.7679.xml">
<!ENTITY RFC7680 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.7680.xml">
]>
<rfc submissionType="IETF" docName="draft-ietf-bess-evpn-oam-req-frmwk-10" categ
ory="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"?>
<front>
<title abbrev="EVPN OAM Requirements/Framework">EVPN Operations, Administ
ration and Maintenance Requirements and Framework</title>
<author initials="S." surname="Salam" fullname="Samer Salam">
<organization>Cisco</organization>
<address><email>ssalam@cisco.com</email>
</address>
</author>
<author initials="A." surname="Sajassi" fullname="Ali Sajassi">
<organization>Cisco</organization>
<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>
<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>
<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" fullname="Donald E. Eastlake, 3r
d">
<organization abbrev="Futurewei">Futurewei Technologies</organization>
<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"/> <!DOCTYPE rfc SYSTEM "rfc2629-xhtml.ent">
<!-- [rfced] Please insert any keywords (beyond those that appear in the title) for use on https://www.rfc-editor.org/search. --> <rfc xmlns:xi="http://www.w3.org/2001/XInclude" docName="draft-ietf-bess-evpn-oa m-req-frmwk-10" number="9062" submissionType="IETF" category="info" consensus="t rue" ipr="trust200902" obsoletes="" updates="" xml:lang="en" symRefs="true" sort Refs="true" tocInclude="true" version="3" tocDepth="5">
<keyword>example</keyword> <front>
<title abbrev="EVPN OAM Requirements/Framework">Framework and Requirements f
or Ethernet VPN (EVPN) Operations, Administration, and 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>
</author>
<author initials="A." surname="Sajassi" fullname="Ali Sajassi">
<organization>Cisco</organization>
<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>
<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>
<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 3rd" fullname="Donald E. Eastlake 3r
d">
<organization abbrev="Futurewei">Futurewei Technologies</organization>
<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="June"/>
<abstract><t> <keyword>PBB-EVPN</keyword>
<keyword>fault management</keyword>
<keyword>performance management</keyword>
<abstract>
<t>
This document specifies the requirements and reference framework for This document specifies the requirements and reference framework for
Ethernet VPN (EVPN) Operations, Administration and Maintenance (OAM). Ethernet VPN (EVPN) Operations, Administration, and Maintenance (OAM).
The requirements cover the OAM aspects of EVPN and PBB-EVPN (Provider The requirements cover the OAM aspects of EVPN and Provider Backbone Bridge E
Backbone Bridge EVPN). The framework defines the layered OAM model VPN (PBB-EVPN). The framework defines the layered OAM model
encompassing the EVPN service layer, network layer, underlying Packet encompassing the EVPN service layer, network layer, underlying Packet
Switched Network (PSN) transport layer, and link layer but focuses on Switched Network (PSN) transport layer, and link layer but focuses on
the service and network layers.</t> the service and network layers.</t>
</abstract>
</abstract> </front>
</front> <middle>
<section anchor="sect-1" numbered="true" toc="default">
<middle> <name>Introduction</name>
<section title="Introduction" anchor="sect-1"><t> <t>
This document specifies the requirements and defines a reference This document specifies the requirements and defines a reference
framework for Ethernet VPN (EVPN) Operations, Administration and framework for Ethernet VPN (EVPN) Operations, Administration, and
Maintenance (OAM, <xref target="RFC6291"/>). In this context, we use the term Maintenance (OAM) <xref target="RFC6291" format="default"/>. In this context,
EVPN we use the term "EVPN OAM" to loosely refer to the OAM functions required for a
OAM to loosely refer to the OAM functions required for and/or nd/or
applicable to <xref target="RFC7432"/> and <xref target="RFC7623"/>.</t> applicable to <xref target="RFC7432" format="default"/> and <xref target="RFC
7623" format="default"/>.</t>
<t> <t>
EVPN is a Layer 2 VPN (L2VPN) solution for multipoint Ethernet EVPN is a Layer 2 VPN (L2VPN) solution for multipoint Ethernet
services, with advanced multi-homing capabilities, using BGP for services with advanced multihoming capabilities that uses BGP for
distributing customer/client MAC address reachability information distributing Customer/Client Media Access Control (C-MAC) address reachabilit
y information
over the core MPLS/IP network.</t> over the core MPLS/IP network.</t>
<t>
<t> PBB-EVPN combines Provider Backbone Bridging (PBB) <xref target="IEEE-802.1Q"
PBB-EVPN combines Provider Backbone Bridging (PBB) <xref target="IEEE-802.1Q" format="default"/> with EVPN in
/> with EVPN in order to reduce the number of BGP MAC advertisement routes; provide client
order to reduce the number of BGP MAC advertisement routes, provide client MAC address mobility using C-MAC <xref target="RFC7623" format="default"/> ag
MAC address mobility using C-MAC (Client MAC <xref target="RFC7623"/>) aggreg gregation and
ation and Backbone MAC (B-MAC) <xref target="RFC7623" format="default"/> sub-netting; c
B-MAC (Backbone MAC <xref target="RFC7623"/>) sub-netting, confine the scope onfine the scope of C-MAC
of C-MAC learning to only active flows; offer per-site policies; and avoid C-MAC
learning to only active flows, offer per site policies, and avoid C-MAC
address flushing on topology changes.</t> address flushing on topology changes.</t>
<t>
<t>
This document focuses on the fault management and performance This document focuses on the fault management and performance
management aspects of EVPN OAM. It defines the layered OAM model management aspects of EVPN OAM. It defines the layered OAM model
encompassing the EVPN service layer, network layer, underlying Packet encompassing the EVPN service layer, network layer, underlying Packet
Switched Network (PSN) transport layer, and link layer but focuses on Switched Network (PSN) transport layer, and link layer but focuses on
the service and network layers.</t> the service and network layers.</t>
<section anchor="sect-1.1" numbered="true" toc="default">
<section title="Relationship to Other OAM Work" anchor="sect-1.1"><t> <name>Relationship to Other OAM Work</name>
<t>
This document leverages concepts and draws upon elements defined This document leverages concepts and draws upon elements defined
and/or used in the following documents:</t> and / or used in the following documents:</t>
<t>
<t> <xref target="RFC6136" format="default"/> specifies the requirements and a re
<xref target="RFC6136"/> specifies the requirements and a reference model for ference model for OAM as
OAM as it relates to L2VPN services, pseudowires, and associated Packet
it relates to L2VPN services, pseudowires and associated Packet Switched Network (PSN) tunnels. This document focuses on Virtual Private LAN
Switched Network (PSN) tunnels. This document focuses on VPLS and Service (VPLS) and Virtual Private Wire Service (VPWS) solutions and services.</
VPWS solutions and services.</t> t>
<t>
<t> <xref target="RFC8029" format="default"/> defines mechanisms for detecting da
<xref target="RFC8029"/> defines mechanisms for detecting data plane failures ta plane failures in
in MPLS Label Switched Paths (LSPs), including procedures to check the correct o
MPLS LSPs, including procedures to check the correct operation of the peration of the
data plane, as well as mechanisms to verify the data plane against data plane as well as mechanisms to verify the data plane against
the control plane.</t> the control plane.</t>
<t>
<t> <xref target="IEEE-802.1Q" format="default"/> specifies the Ethernet Connecti
<xref target="IEEE-802.1Q"/> specifies the Ethernet Connectivity Fault Manage vity Fault Management (CFM)
ment (CFM)
protocol, which defines the concepts of Maintenance Domains, protocol, which defines the concepts of Maintenance Domains,
Maintenance Associations, Maintenance End Points, and Maintenance Maintenance Associations, Maintenance End Points, and Maintenance
Intermediate Points.</t> Intermediate Points.</t>
<t>
<t> <xref target="Y.1731"/> extends Connectivity Fault Management in the followin
[Y.1731] extends Connectivity Fault Management in the following g
areas: it defines fault notification and alarm suppression functions areas: it defines fault notification and alarm suppression functions
for Ethernet. It also specifies mechanisms for Ethernet performance for Ethernet and specifies mechanisms for Ethernet performance
management, including loss, delay, jitter, and throughput management, including loss, delay, jitter, and throughput
measurement.</t> measurement.</t>
</section>
<section anchor="sect-1.2" numbered="true" toc="default">
<name>Specification of Requirements</name>
<t>
The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQU
IRED</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 "<bcp14>OPTIONAL</bcp14>" in this document are to
be interpreted as
described in BCP&nbsp;14 <xref target="RFC2119"/> <xref target="RFC8174"/>
when, and only when, they appear in all capitals, as shown here.
</t>
</section>
<section anchor="sect-1.3" numbered="true" toc="default">
<name>Terminology</name>
<t>
This document uses the following terminology, much of which is defined
in <xref target="RFC6136" format="default"/>:
</section> </t>
<dl newline="false" spacing="normal" indent="12">
<section title="Specification of Requirements" anchor="sect-1.2"><t> <dt>CE</dt>
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", <dd>Customer Edge device; for example, a host, router, or switch.</dd>
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and <dt>CFM</dt>
"OPTIONAL" in this document are to be interpreted as described in BCP <dd>Connectivity Fault Management <xref target="IEEE-802.1Q" format="d
14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only when, the efault"/></dd>
y appear in all <dt>DF</dt>
capitals, as shown here.</t> <dd>Designated Forwarder <xref target="RFC7432" format="default"/></dd
>
</section> <dt>Down MEP</dt>
<dd>A MEP that originates traffic away from and terminates
<section title="Terminology" anchor="sect-1.3"><t> traffic towards the core of the device in whose port it is logically
This document uses the following terminology much of which is defined located.</dd>
in <xref target="RFC6136"/>: <dt>EVI</dt>
<dd>An EVPN instance spanning the Provider Edge (PE)
<list style="hanging" hangIndent="6"> devices participating in that EVPN <xref target="RFC7432" format="defau
lt"/>.</dd>
<t hangText="CE">Customer Edge device, e.g., a host, router, or switch. <dt>L2VPN</dt>
</t> <dd>Layer 2 VPN</dd>
<dt>LOC</dt>
<t hangText="CFM">Connectivity Fault Management <xref target="IEEE-802. <dd>Loss of continuity</dd>
1Q"/>.</t> <dt>MA</dt>
<dd>Maintenance Association; a set of MEPs belonging
<t hangText="DF">Designated Forwarder <xref target="RFC7432"/>.</t> to the same Maintenance Domain (MD) established to verify the
integrity of a single service instance <xref target="IEEE-802.1Q" forma
<t hangText="Down MEP">A MEP that originates traffic away from and term t="default"/>.</dd>
inates <dt>MD</dt>
traffic towards the core of the device in whose port it is logically <dd>Maintenance Domain; an OAM Domain that represents a
located.</t> region over which OAM frames can operate unobstructed <xref target="IEE
E-802.1Q" format="default"/>.</dd>
<t hangText="EVI">An EVPN instance spanning the Provider Edge (PE) <dt>MEP</dt>
devices participating in that EVPN <xref target="RFC7432"/>.</t> <dd>Maintenance End Point; it is responsible for
<t hangText="L2VPN">Layer 2 VPN.</t>
<t hangText="MA">Maintenance Association is a set of MEPs belonging
to the same Maintenance Domain (MD), established to verify the
integrity of a single service instance <xref target="IEEE-802.1Q"/>.</t
>
<t hangText="MD">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 End Point is responsible for
origination and termination of OAM frames for a given MA. A MEP is 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> logically located in a device's port <xref target="IEEE-802.1Q" format=
"default"/>.</dd>
<t hangText="MIP"> Maintenance Intermediate Point is located between <dt>MIP</dt>
<dd> Maintenance Intermediate Point; it is located between
peer MEPs and can process and respond to certain OAM frames but does 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 not initiate them. A MIP is logically located in a device's port
<xref target="IEEE-802.1Q"/>.</t> <xref target="IEEE-802.1Q" format="default"/>.</dd>
<dt>MP2P</dt>
<t hangText="MP2P">Multipoint to Point.</t> <dd>Multipoint to Point</dd>
<dt>NMS</dt>
<t hangText="NMS">Network Management Station <xref target="RFC6632"/>.< <dd>Network Management Station <xref target="RFC6632" format="default"
/t> /></dd>
<dt>P</dt>
<t hangText="P">Provider network interior (non-edge) node.</t> <dd>Provider network interior (non-edge) node</dd>
<dt>P2MP</dt>
<t hangText="P2MP">Point to Multipoint.</t> <dd>Point to Multipoint</dd>
<dt>PBB</dt>
<t hangText="PBB">Provider Backbone Bridge <xref target="RFC7623"/>.</t <dd>Provider Backbone Bridge <xref target="RFC7623" format="default"/>
> </dd>
<dt>PE</dt>
<t hangText="PE">Provider network Edge device.</t> <dd>Provider Edge network device</dd>
<dt>Up MEP</dt>
<t hangText="Up MEP"> A MEP that originates traffic towards and <dd> A MEP that originates traffic towards and
terminates traffic from the core of the device in whose port it is terminates traffic from the core of the device in whose port it is
logically located.</t> logically located.</dd>
<dt>VPN</dt>
<t hangText="VPN">Virtual Private Network</t> <dd>Virtual Private Network</dd>
</dl>
</list> </section>
</t> </section>
<section anchor="sect-2" numbered="true" toc="default">
</section> <name>EVPN OAM Framework</name>
<section anchor="sect-2.1" numbered="true" toc="default">
</section> <name>OAM Layering</name>
<t>
<section title="EVPN OAM Framework" anchor="sect-2"><section title="OAM L
ayering" anchor="sect-2.1"><t>
Multiple layers come into play for implementing an L2VPN service Multiple layers come into play for implementing an L2VPN service
using the EVPN family of solutions as listed below. The focus of this using the EVPN family of solutions as listed below. The focus of this
document is the Service and Network layers.</t> document is the service and network layers.</t>
<ul spacing="normal">
<t><list style="symbols"> <li>The service layer runs end to end between the sites or Ethernet
segments that are being interconnected by the EVPN solution.</li>
<t>The Service Layer runs end to end between the sites or Ethernet <li>The network layer extends between the EVPN PE (Provider Edge) node
Segments that are being interconnected by the EVPN solution.</t> s
and is mostly transparent to the P (provider network interior)
<t>The Network Layer extends between the EVPN PE (Provider Edge) nodes nodes (except where flow entropy comes into play). It leverages
and is mostly transparent to the P (Provider network interior) MPLS for service (i.e., EVI) multiplexing and split-horizon
nodes (except where Flow Entropy comes into play). It leverages functions.</li>
MPLS for service (i.e., EVI) multiplexing and Split-Horizon <li>The transport layer is dictated by the networking technology of th
functions.</t> e
PSN. It may be based on either MPLS LSPs or IP.</li>
<t>The Transport Layer is dictated by the networking technology of the <li>The link layer is dependent upon the physical technology used.
PSN. It may be either based on MPLS LSPs or IP.</t>
<t>The Link Layer is dependent upon the physical technology used.
Ethernet is a popular choice for this layer, but other alternatives Ethernet is a popular choice for this layer, but other alternatives
are deployed (e.g., POS, DWDM etc.).</t> are deployed (e.g., Packet over SONET (POS), Dense Wavelength Division Mult
iplexing (DWDM), etc.).</li>
</list> </ul>
</t> <t>
<t>
This layering extends to the set of OAM protocols that are involved This layering extends to the set of OAM protocols that are involved
in the ongoing maintenance and diagnostics of EVPN networks. Figure 1 in the ongoing maintenance and diagnostics of EVPN networks. <xref target="fi
below depicts the OAM layering, and shows which devices have g-1"/>
below depicts the OAM layering and shows which devices have
visibility into what OAM layer(s).</t> visibility into what OAM layer(s).</t>
<figure anchor="fig-1">
<figure title="OAM Layering" anchor="fig-1"><artwork><![CDATA[ <name>OAM Layering</name>
<artwork name="" type="" align="left" alt=""><![CDATA[
+---+ +---+ +---+ +---+
+--+ | | +---+ +---+ +---+ | | +--+ +--+ | | +---+ +---+ +---+ | | +--+
|CE|----|PE |----| P |----| P |----| P |----|PE |----|CE| |CE|----|PE |----| P |----| P |----| P |----|PE |----|CE|
+--+ | | +---+ +---+ +---+ | | +--+ +--+ | | +---+ +---+ +---+ | | +--+
+---+ +---+ +---+ +---+
o-------o----------- Service OAM -----------o-------o o-------o----------- Service OAM -----------o-------o
o----------- Network OAM -----------o o----------- Network OAM -----------o
o--------o--------o--------o--------o Transport OAM o--------o--------o--------o--------o Transport OAM
o----o o----o o----o o----o o----o o----o Link OAM o----o o----o o----o o----o o----o o----o Link OAM
]]></artwork> ]]></artwork>
</figure> </figure>
<t> <t>
Service OAM and Network OAM mechanisms only have visibility to the PE Service OAM and Network OAM mechanisms only have visibility to the PE
(Provider Edge) nodes but not the P (Provider interior) nodes. As nodes but not the P nodes. As
such, they can be used to deduce whether the fault is in the</t> such, they can be used to deduce whether the fault is in the customer's own n
etwork, the local CE-PE segment, the PE-PE segment, or
<t>
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 the remote CE-PE segment(s). EVPN Transport OAM mechanisms can be
used for fault isolation between the PEs and P nodes.</t> used for fault isolation between the PEs and P nodes.</t>
<t>
<t> <xref target="fig-2"/> below shows an example network where Ethernet domains
Figure 2 below shows an example network where native Ethernet domains are interconnected via EVPN using MPLS, and it shows the OAM mechanisms
are interconnected via EVPN using MPLS and gives the OAM mechanisms that are applicable at each layer. The details of the layers are described in
applicable at each layer. The details of the layers are described in
the sections below.</t> the sections below.</t>
<figure anchor="fig-2">
<figure title="EVPN OAM Example" anchor="fig-2"><artwork><![CDATA[ <name>EVPN OAM Example</name>
<artwork name="" type="" align="left" alt=""><![CDATA[
+---+ +---+ +---+ +---+
+--+ | | +---+ +---+ +---+ | | +--+ +--+ | | +---+ +---+ +---+ | | +--+
|CE|----|PE |----| P |----| P |----| P |----|PE |----|CE| |CE|----|PE |----| P |----| P |----| P |----|PE |----|CE|
+--+ | | +---+ +---+ +---+ | | +--+ +--+ | | +---+ +---+ +---+ | | +--+
+---+ +---+ +---+ +---+
o----o---------- CFM (Service OAM) ----------o----o o----o---------- CFM (Service OAM) ----------o----o
o-------- EVPN Network OAM ---------o o-------- EVPN Network OAM ---------o
o--------o--------o--------o--------o MPLS OAM o--------o--------o--------o--------o MPLS OAM
o----o o----o o----o o----o o----o o----o [802.3] OAM o----o o----o o----o o----o o----o o----o 802.3 OAM
[IEEE-802.3]
]]></artwork> ]]></artwork>
</figure> </figure>
</section> </section>
<section anchor="sect-2.2" numbered="true" toc="default">
<section title="EVPN Service OAM" anchor="sect-2.2"><t> <name>EVPN Service OAM</name>
The EVPN Service OAM protocol depends on what service layer <t>
technology is being interconnected by the EVPN solution. In case of The EVPN Service OAM protocol depends on what service-layer
<xref target="RFC7432"/> and <xref target="RFC7623"/>, the service layer is E technology is being interconnected by the EVPN solution. In the case of
thernet; hence, the <xref target="RFC7432" format="default"/> and <xref target="RFC7623" format="
corresponding service OAM protocol is Ethernet Connectivity Fault default"/>, the service layer is Ethernet; hence, the
Management (CFM) <xref target="IEEE-802.1Q"/>.</t> corresponding Service OAM protocol is Ethernet CFM <xref target="IEEE-802.1Q"
format="default"/>.</t>
<t> <t>
EVPN service OAM is visible to the CEs and EVPN PEs, but not to the P 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 nodes. This is because the PEs operate at the Ethernet MAC layer in
<xref target="RFC7432"/> <xref target="RFC7623"/> whereas the P nodes do not. <xref target="RFC7432" format="default"/> and <xref target="RFC7623" format="
</t> default"/>, whereas the P nodes do not.</t>
<t>
<t> The EVPN PE <bcp14>MUST</bcp14> support MIP functions in the applicable Servi
The EVPN PE MUST support MIP functions in the applicable service OAM ce OAM
protocol, for example Ethernet CFM. The EVPN PE SHOULD support MEP protocol (for example, Ethernet CFM). The EVPN PE <bcp14>SHOULD</bcp14> suppo
functions in the applicable service OAM protocol. This includes both rt MEP
functions in the applicable Service OAM protocol. This includes both
Up and Down MEP functions.</t> Up and Down MEP functions.</t>
<t>
<t> As shown in <xref target="fig-3"/>, the MIP and MEP functions being referred
As shown in Figure 3, the MIP and MEP functions being referred to are to are
logically located within the device's port operating at the customer logically located within the device's port operating at the customer
level. (There could be MEPs/MIPs within PE ports facing the provider 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 network, but they would not be relevant to EVPN Service OAM as the
traffic passing through them will be encapsulated/tunneled so any traffic passing through them will be encapsulated/tunneled, so any
customer level OAM messages will just be treated as data.) Down MEP</t> 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
<t>
functions are away from the core of the device while up MEP functions
are towards the core of the device (towards the PE forwarding 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 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 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 OAM.</t> CEs or from a PE to its local CE or to the remote CE are Service OAMs.</t>
<figure anchor="fig-3">
<figure title="CFM Details" anchor="fig-3"><artwork><![CDATA[ <name>CFM Details</name>
<artwork name="" type="" align="left" alt=""><![CDATA[
+-------+ +----------------+ +----------------+ +-------+ +-------+ +----------------+ +----------------+ +-------+
|+-----+| |+--------------+| |+--------------+| |+-----+| |+-----+| |+--------------+| |+--------------+| |+-----+|
|| CE || || PE || ... || PE || || CE || || CE || || PE || ... || PE || || CE ||
|+--+--+| |+---+--------+-+| |+-+--------+---+| |+--+--+| |+--+--+| |+---+--------+-+| |+-+--------+---+| |+--+--+|
| | | | | | | | | | | | | | | | | | | | | | | | | | | |
|+--+--+| |+---+-----+ . | | . +-----+---+| |+--+--+| |+--+--+| |+---+-----+ . | | . +-----+---+| |+--+--+|
|| MEP || || | Up ^| . | ... | . | Up ^| || || MEP || || MEP || || | Up ^| . | ... | . | Up ^| || || MEP ||
||DownV|| ||MIP|MEP | . | | . |MEP |MIP|| ||DownV|| ||DownV|| ||MIP|MEP | . | | . |MEP |MIP|| ||DownV||
|+--+--+| || |DownV| . | | . |DownV| || |+--+--+| |+--+--+| || |DownV| . | | . |DownV| || |+--+--+|
| | | |+---+-----+ | | | | +-----+---+| | | | | | | |+---+-----+ | | | | +-----+---+| | | |
+---|---+ +----|--------|--+ +--|--------|----+ +---|---+ +---|---+ +----|--------|--+ +--|--------|----+ +---|---+
| | | | | | | | | | | |
+------------+ +--- ... ---+ +------------+ +------------+ +--- ... ---+ +------------+
]]></artwork> ]]></artwork>
</figure> </figure>
<t> <t>
The EVPN PE MUST, by default, learn the MAC address of locally The EVPN PE <bcp14>MUST</bcp14>, by default, learn the MAC address of locally
attached CE MEPs by snooping on CFM frames and advertising them to 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 remote PEs as a MAC/IP Advertisement route. Some means to limit the
number of MAC addresses that a PE will learn SHOULD be implemented.</t> number of MAC addresses that a PE will learn <bcp14>SHOULD</bcp14> be impleme
nted.</t>
<t> <t>
The EVPN PE SHOULD advertise any MEP/MIP local to the PE as a MAC/IP The EVPN PE <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 Advertisement route. Since these are not subject to mobility, they
SHOULD be advertised with the static (sticky) bit set (see Section <bcp14>SHOULD</bcp14> be advertised with the static (sticky) bit set (see <xr
15.2 of <xref target="RFC7432"/>).</t> ef target="RFC7432" sectionFormat="of" section="15.2"/>).</t>
</section>
</section> <section anchor="sect-2.3" numbered="true" toc="default">
<name>EVPN Network OAM</name>
<section title="EVPN Network OAM" anchor="sect-2.3"><t> <t>
EVPN Network OAM is visible to the PE nodes only. This OAM layer is EVPN Network OAM is visible to the PE nodes only. This OAM layer is
analogous to VCCV <xref target="RFC5085"/> in the case of VPLS/VPWS. It provi analogous to Virtual Circuit Connectivity Verification (VCCV) <xref target="R
des FC5085" format="default"/> in the case of VPLS/VPWS. It provides
mechanisms to check the correct operation of the data plane, as well mechanisms to check the correct operation of the data plane as well
as a mechanism to verify the data plane against the control plane. as a mechanism to verify the data plane against the control plane.
This includes the ability to perform fault detection and diagnostics This includes the ability to perform fault detection and diagnostics
on:</t> on:</t>
<ul spacing="normal">
<t><list style="symbols"><t>the MP2P tunnels used for the transport of un <li>the MP2P tunnels used for the transport of unicast traffic between
icast traffic between
PEs. EVPN allows for three different models of unicast label PEs. EVPN allows for three different models of unicast label
assignment: label per EVI, label per &lt;ESI, Ethernet Tag&gt; and 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 per MAC address. In all three models, the label is bound to an EVPN
Unicast FEC. EVPN Network OAM MUST provide mechanisms to check the Unicast Forwarding Equivalence Class (FEC). EVPN Network OAM <bcp14>MUST</ bcp14> provide mechanisms to check the
operation of the data plane and verify that operation against the operation of the data plane and verify that operation against the
control plane view.</t> control plane view.</li>
<li>the MP2P tunnels used for aliasing unicast traffic destined to a
<t>the MP2P tunnels used for aliasing unicast traffic destined to a multihomed Ethernet segment. The three label assignment models,
multi-homed Ethernet Segment. The three label assignment models,
discussed above, apply here as well. In all three models, the label discussed above, apply here as well. In all three models, the label
is bound to an EVPN Aliasing FEC. EVPN Network OAM MUST provide is bound to an EVPN Aliasing FEC. EVPN Network OAM <bcp14>MUST</bcp14> prov ide
mechanisms to check the operation of the data plane and verify that mechanisms to check the operation of the data plane and verify that
operation against the control plane view.</t> operation against the control plane view.</li>
<li>the multicast tunnels (either MP2P or P2MP) used for the transport
<t>the multicast tunnels (either MP2P or P2MP) used for the transport of broadcast, unknown unicast, and multicast traffic between PEs. In
of broadcast, unknown unicast and multicast traffic between PEs. In
the case of ingress replication, a label is allocated per EVI or 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 per &lt;EVI, Ethernet Tag&gt; and is bound to an EVPN Multicast FEC. In
the case of LSM (Label Switched Multicast), and more specifically the case of Label Switched Multicast (LSM) and, more specifically,
aggregate inclusive trees, again a label may be allocated per EVI 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.</t> or per &lt;EVI, Ethernet Tag&gt; and is bound to the tunnel FEC.</li>
<li>the correct operation of the Ethernet Segment Identifier (ESI) spl
<t>the correct operation of the ESI split-horizon filtering function. it-horizon filtering function.
In EVPN, a label is allocated per multi-homed Ethernet Segment for In EVPN, a label is allocated per multihomed Ethernet segment for
the purpose of performing the access split-horizon enforcement. The the purpose of performing the access split-horizon enforcement. The
label is bound to an EVPN Ethernet Segment.</t> label is bound to an EVPN Ethernet segment.</li>
<li>the correct operation of the Designated Forwarder (DF) <xref targe
<t>the correct operation of the DF (Designated Forwarder <xref target="RF t="RFC7432" format="default"/>
C7432"/>) filtering function. EVPN Network OAM <bcp14>MUST</bcp14> provide mechanism
filtering function. EVPN Network OAM MUST provide mechanisms to s to
check the operation of the data plane and verify that operation check the operation of the data plane and verify that operation
against the control plane view for the DF filtering function.</t> against the control plane view for the DF filtering function.</li>
</ul>
</list> <t>
</t> EVPN Network OAM mechanisms <bcp14>MUST</bcp14> provide in-band monitoring
<t>
EVPN Network OAM mechanisms MUST provide in-band monitoring
capabilities. It is desirable, to the extent practical, for OAM test capabilities. It is desirable, to the extent practical, for OAM test
messages to share fate with data messages. Details of how to achieve messages to share fate with data messages. Details of how to achieve
this are beyond the scope of this document.</t> this are beyond the scope of this document.</t>
<t>
<t> EVPN Network OAM <bcp14>SHOULD</bcp14> provide both proactive and on-demand
EVPN Network OAM SHOULD provide both proactive and on-demand
mechanisms of monitoring the data plane operation and data plane mechanisms of monitoring the data plane operation and data plane
conformance to the state of the control plane.</t> conformance to the state of the control plane.</t>
</section>
</section> <section anchor="sect-2.4" numbered="true" toc="default">
<name>Transport OAM for EVPN</name>
<section title="Transport OAM for EVPN" anchor="sect-2.4"><t> <t>
The transport OAM protocol depends on the nature of the underlying The Transport OAM protocol depends on the nature of the underlying
transport technology in the PSN. MPLS OAM mechanisms <xref target="RFC8029"/> transport technology in the PSN. MPLS OAM mechanisms <xref target="RFC8029" f
<xref target="RFC6425"/> as well as ICMP <xref target="RFC0792"/> / ICMPv6 <x ormat="default"/>
ref target="RFC4443"/> are applicable, <xref target="RFC6425" format="default"/> as well as ICMP <xref target
="RFC0792" format="default"/> and ICMPv6 <xref target="RFC4443" format="default"
/> are applicable,
depending on whether the PSN employs MPLS or IP transport, depending on whether the PSN employs MPLS or IP transport,
respectively. Furthermore, BFD mechanisms per <xref target="RFC5880"/>, <xre respectively. Furthermore, Bidirectional Forwarding Detection (BFD) mechanis
f target="RFC5881"/>, ms per <xref target="RFC5880" format="default"/>, <xref target="RFC5881" format=
<xref target="RFC5883"/> and <xref target="RFC5884"/> apply. Also, the BFD me "default"/>,
chanisms pertaining to <xref target="RFC5883" format="default"/>, and <xref target="RFC5884" format=
MPLS-TP LSPs per <xref target="RFC6428"/> are applicable.</t> "default"/> apply. Also, the BFD mechanisms pertaining to
MPLS-TP LSPs per <xref target="RFC6428" format="default"/> are applicable.</t
</section> >
</section>
<section title="Link OAM" anchor="sect-2.5"><t> <section anchor="sect-2.5" numbered="true" toc="default">
Link OAM depends on the data link technology being used between the <name>Link OAM</name>
<t>
Link OAM depends on the data-link technology being used between the
PE and P nodes. For example, if Ethernet links are employed, then PE and P nodes. For example, if Ethernet links are employed, then
Ethernet Link OAM (<xref target="IEEE-802.3"/> Clause 57) may be used.</t> Ethernet Link OAM (<xref target="IEEE-802.3" format="default"/>, Clause 57) m
ay be used.</t>
</section> </section>
<section anchor="sect-2.6" numbered="true" toc="default">
<section title="OAM Inter-working" anchor="sect-2.6"><t> <name>OAM Interworking</name>
When inter-working two networking domains, such as native Ethernet <t>
When interworking two networking domains, such as actual Ethernet
and EVPN to provide an end-to-end emulated service, there is a need 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 to identify the failure domain and location, even when a PE supports
both the Service OAM mechanisms and the EVPN Network OAM mechanisms. both the Service OAM mechanisms and the EVPN Network OAM mechanisms.
In addition, scalability constraints may not allow running proactive In addition, scalability constraints may not allow the running of proactive
monitoring, such as Ethernet Continuity Check Messages (CCMs monitoring, such as Ethernet Continuity Check Messages (CCMs)
<xref target="IEEE-802.1Q"/>), at a PE to detect the failure of an EVI across <xref target="IEEE-802.1Q" format="default"/>, at a PE to detect the failure
the EVPN of an EVI across the EVPN
domain. Thus, the mapping of alarms generated upon failure detection domain. Thus, the mapping of alarms generated upon failure detection
in one domain (e.g., native Ethernet or EVPN network domain) to the 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 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 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, the PSN even when such messages are defined, as in the Ethernet case,
thereby necessitating support for fault notification message mapping thereby necessitating support for fault notification message mapping
between the EVPN Network domain and the Service domain.</t> between the EVPN Network domain and the Service domain.</t>
<t>
<t> OAM interworking is not limited, though, to scenarios involving disparate
OAM inter-working is not limited though to scenarios involving disparate network domains. It is possible to perform OAM interworking across
network domains. It is possible to perform OAM inter-working across
different layers in the same network domain. In general, alarms generated different layers in the same network domain. In general, alarms generated
within an OAM layer, as a result of proactive fault detection mechanisms, within an OAM layer, as a result of proactive fault detection mechanisms, may
may be injected into its client layer OAM mechanisms. This allows the be injected into its client-layer OAM mechanisms. This allows the
client layer OAM to trigger event-driven (i.e., asynchronous) fault client-layer OAM to trigger event-driven (i.e., asynchronous) fault
notifications. For example, alarms generated by the Link OAM mechanisms may notifications. For example, alarms generated by the Link OAM mechanisms may
be injected into the Transport OAM layer, and alarms generated by the be injected into the Transport OAM layer, and alarms generated by the
Transport OAM mechanism may be injected into the Network OAM mechanism, and Transport OAM mechanism may be injected into the Network OAM mechanism, and
so on.</t> so on.</t>
<t>
<t> EVPN OAM <bcp14>MUST</bcp14> support interworking between the Network OAM and
EVPN OAM MUST support inter-working between the Network OAM and Service OAM mechanisms. EVPN OAM <bcp14>MAY</bcp14> support interworking amon
Service OAM mechanisms. EVPN OAM MAY support inter-working among g
other OAM layers.</t> other OAM layers.</t>
</section>
</section> </section>
<section anchor="sect-3" numbered="true" toc="default">
</section> <name>EVPN OAM Requirements</name>
<t>
<section title="EVPN OAM Requirements" anchor="sect-3"><t> This section discusses the EVPN OAM requirements pertaining to fault
This section discusses the EVPN OAM requirements pertaining to Fault management and performance management.</t>
Management and Performance Management.</t> <section anchor="sect-3.1" numbered="true" toc="default">
<name>Fault Management Requirements</name>
<section title="Fault Management Requirements" anchor="sect-3.1"><section <section anchor="sect-3.1.1" numbered="true" toc="default">
title="Proactive Fault Management Functions" anchor="sect-3.1.1"><t> <name>Proactive Fault Management Functions</name>
<t>
The network operator configures proactive fault management functions The network operator configures proactive fault management functions
to run periodically without a time bound. Certain actions, for to run periodically. Certain actions (for
example protection switchover or alarm indication signaling, can be example, protection switchover or alarm indication signaling) can be
associated with specific events, such as entering or clearing fault associated with specific events, such as entering or clearing fault
states.</t> states.</t>
<section anchor="sect-3.1.1.1" numbered="true" toc="default">
<section title="Fault Detection (Continuity Check)" anchor="sect-3.1.1.1" <name>Fault Detection (Continuity Check)</name>
><t> <t>
Proactive fault detection is performed by periodically monitoring the Proactive fault detection is performed by periodically monitoring the
reachability between service endpoints, i.e., MEPs in a given MA, reachability between service end points, i.e., MEPs in a given MA,
through the exchange of Continuity Check Messages <xref target="IEEE-802.1Q"/ through the exchange of CCMs <xref target="IEEE-802.1Q" format="default"/>. T
>. The he
reachability between any two arbitrary MEPs may be monitored for:</t> reachability between any two arbitrary MEPs may be monitored for:</t>
<ul spacing="normal">
<t><list style="symbols"><t>in-band per-flow monitoring. This enables per <li>in-band, per-flow monitoring. This enables per-flow monitoring
flow monitoring between MEPs. EVPN Network OAM <bcp14>MUST</bcp14> support fault detection
between MEPs. EVPN Network OAM MUST support fault detection with with
per user flow granularity. EVPN Service OAM MAY support fault per-user flow granularity. EVPN Service OAM <bcp14>MAY</bcp14> support faul
detection with per user flow granularity.</t> t
detection with per-user flow granularity.</li>
<t>a representative path. This enables liveness check of the nodes <li>a representative path. This enables a liveness check of the no
hosting the MEPs assuming that the loss of continuity to the MEP is des
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 interpreted as a failure of the hosting node. This, however, does
not conclusively indicate liveness of the path(s) taken by user not conclusively indicate liveness of the path(s) taken by user
data traffic. This enables node failure detection but not path data traffic. This enables node failure detection but not path
failure detection, through the use of a test flow. EVPN Network OAM failure detection through the use of a test flow. EVPN Network OAM
and Service OAM MUST support fault detection using test flows.</t> and Service OAM <bcp14>MUST</bcp14> support fault detection using test flow
s.</li>
<t>all paths. For MPLS/IP networks with ECMP, monitoring of all unicast <li>all paths. For MPLS/IP networks with ECMP, the monitoring of a
paths between MEPs (on non-adjacent nodes) may not be possible, since the ll 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 per-hop ECMP hashing behavior may yield situations where it is impossible
for a MEP to pick flow entropy characteristics that result in exercising for a MEP to pick flow entropy characteristics that result in exercising
the exhaustive set of ECMP paths. Monitoring of all ECMP paths between 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.</t> MEPs (on non-adjacent nodes) is not a requirement for EVPN OAM.</li>
</ul>
</list> <t>
</t>
<t>
The fact that MPLS/IP networks do not enforce congruency between The fact that MPLS/IP networks do not enforce congruency between
unicast and multicast paths means that the proactive fault detection unicast and multicast paths means that the proactive fault detection
mechanisms for EVPN networks MUST provide procedures to monitor the mechanisms for EVPN networks <bcp14>MUST</bcp14> provide procedures to monito r the
unicast paths independently of the multicast paths. This applies to unicast paths independently of the multicast paths. This applies to
EVPN Service OAM and Network OAM.</t> EVPN Service OAM and Network OAM.</t>
</section>
</section> <section anchor="sect-3.1.1.2" numbered="true" toc="default">
<name>Defect Indication</name>
<section title="Defect Indication" anchor="sect-3.1.1.2"><t> <t>
Defect indications can be categorized into two types: forward and Defect indications can be categorized into two types: forward and
reverse defect indications as described below. EVPN Service OAM MUST reverse, as described below. EVPN Service OAM <bcp14>MUST</bcp14>
support at least one of these types of event-driven defect indication support at least one of these types of event-driven defect indications
upon the detection of a connectivity defect.</t> upon the detection of a connectivity defect.</t>
<section anchor="sect-3.1.1.2.1" numbered="true" toc="default">
<section title="Forward Defect Indication" anchor="sect-3.1.1.2.1"><t> <name>Forward Defect Indication (FDI)</name>
This is used to signal a failure that is detected by a lower layer <t>
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) OAM mechanism. A server MEP (i.e., an actual or virtual MEP)
transmits a Forward Defect Indication in a direction that is away transmits a forward defect indication in a direction away
from the direction of the failure (refer to Figure 4 below).</t> from the direction of the failure (refer to <xref target="fig-4"/> below).</t
>
<figure title="Forward Defect Indication" anchor="fig-4"><artwork><![CDAT <figure anchor="fig-4">
A[ <name>Forward Defect Indication</name>
<artwork name="" type="" align="left" alt=""><![CDATA[
Failure Failure
| |
+-----+ +-----+ V +-----+ +-----+ +-----+ +-----+ V +-----+ +-----+
| A |------| B |--XXX--| C |------| D | | A |------| B |--XXX--| C |------| D |
+-----+ +-----+ +-----+ +-----+ +-----+ +-----+ +-----+ +-----+
<===========| |============> <===========| |============>
Forward Forward Forward Forward
Defect Defect Defect Defect
Indication Indication Indication Indication
]]></artwork> ]]></artwork>
</figure> </figure>
<t> <t>
Forward defect indication may be used for alarm suppression and/or Forward defect indication may be used for alarm suppression and/or
for purpose of inter-working with other layer OAM protocols. Alarm for the purpose of interworking with other layer OAM protocols. Alarm
suppression is useful when a transport/network level fault translates suppression is useful when a transport-level or network-level fault translate
to multiple service or flow level faults. In such a scenario, it is s
to multiple service- or flow-level faults. In such a scenario, it is
enough to alert a network management station (NMS) of the single enough to alert a network management station (NMS) of the single
transport/network level fault in lieu of flooding that NMS with a transport-level or network-level fault in lieu of flooding that NMS with a
multitude of Service or Flow granularity alarms. EVPN PEs SHOULD multitude of Service or Flow granularity alarms. EVPN PEs <bcp14>SHOULD</bcp1
support Forward Defect Indication in the Service OAM mechanisms.</t> 4>
support forward defect indication in the Service OAM mechanisms.</t>
</section> </section>
<section anchor="sect-3.1.1.2.2" numbered="true" toc="default">
<section title="Reverse Defect Indication (RDI)" anchor="sect-3.1.1.2.2"> <name>Reverse Defect Indication (RDI)</name>
<t>
RDI is used to signal that the advertising MEP has detected a loss of
continuity (LoC) defect. RDI is transmitted in the direction of the
failure (refer to Figure 5).</t>
<figure title="Reverse Defect Indication" anchor="fig-5"><artwork><![CDAT <t>
A[ 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 <xref target="fig-5"/>).</t>
<figure anchor="fig-5">
<name>Reverse Defect Indication</name>
<artwork name="" type="" align="left" alt=""><![CDATA[
Failure Failure
| |
+-----+ +-----+ V +-----+ +-----+ +-----+ +-----+ V +-----+ +-----+
| A |------| B |--XXX--| C |------| D | | A |------| B |--XXX--| C |------| D |
+-----+ +-----+ +-----+ +-----+ +-----+ +-----+ +-----+ +-----+
|===========> <============| |===========> <============|
Reverse Reverse Reverse Reverse
Defect Defect Defect Defect
Indication Indication Indication Indication
]]></artwork> ]]></artwork>
</figure> </figure>
<t> <t>
RDI allows single-sided management, where the network operator can RDI allows single-sided management, where the network operator can
examine the state of a single MEP and deduce the overall health of a examine the state of a single MEP and deduce the overall health of a
monitored service. EVPN PEs SHOULD support Reverse Defect Indication monitored service. EVPN PEs <bcp14>SHOULD</bcp14> support reverse defect indi cation
in the Service OAM mechanisms. This includes both the ability to in the Service OAM mechanisms. This includes both the ability to
signal LoC defect to a remote MEP, as well as 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 recognize RDI from a remote MEP. Note that, in a multipoint MA, RDI
is not a useful indicator of unidirectional fault. This is because is not a useful indicator of unidirectional fault. This is because
RDI carries no indication of the affected MEP(s) with which the RDI carries no indication of the affected MEP(s) with which the
sender had detected a LoC defect.</t> sender had detected a LOC defect.</t>
</section>
</section> </section>
</section>
</section> <section anchor="sect-3.1.2" numbered="true" toc="default">
<name>On-Demand Fault Management Functions</name>
</section> <t>
<section title="On-Demand Fault Management Functions" anchor="sect-3.1.2"
><t>
On-demand fault management functions are initiated manually by the On-demand fault management functions are initiated manually by the
network operator and continue for a time bound period. These network operator and continue for a bounded time period. These
functions enable the operator to run diagnostics to investigate a functions enable the operator to run diagnostics to investigate a
defect condition.</t> defect condition.</t>
<section anchor="sect-3.1.2.1" numbered="true" toc="default">
<section title="Connectivity Verification" anchor="sect-3.1.2.1"><t> <name>Connectivity Verification</name>
EVPN Network OAM MUST support on-demand connectivity verification <t>
EVPN Network OAM <bcp14>MUST</bcp14> support on-demand connectivity verificat
ion
mechanisms for unicast and multicast destinations. The connectivity mechanisms for unicast and multicast destinations. The connectivity
verification mechanisms SHOULD provide a means for specifying and verification mechanisms <bcp14>SHOULD</bcp14> provide a means for specifying
carrying in the messages:</t> and
carrying the following in the messages:</t>
<t><list style="symbols"><t>variable length payload/padding to test MTU ( <ul spacing="normal">
Maximum Transmission <li>variable-length payload/padding to test connectivity problems
Unit) related connectivity problems.</t> related to the Maximum Transmission Unit (MTU).</li>
<li>test frame formats as defined in <xref target="RFC2544" sectio
<t>test frame formats as defined in Appendix C of <xref target="RFC2544"/ nFormat="of" section="C"/> to detect
> to detect potential packet corruption.</li>
potential packet corruption.</t> </ul>
<t>
</list> EVPN Network OAM <bcp14>MUST</bcp14> support connectivity verification at per
</t> -flow
<t>
EVPN Network OAM MUST support connectivity verification at per flow
granularity. This includes both user flows (to test a specific path 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) as well as test flows (to test a representative path
between PEs).</t> between PEs).</t>
<t>
<t> EVPN Service OAM <bcp14>MUST</bcp14> support connectivity verification on tes
EVPN Service OAM MUST support connectivity verification on test flows t flows
and MAY support connectivity verification on user flows.</t> and <bcp14>MAY</bcp14> support connectivity verification on user flows.</t>
<t>
<t> For multicast connectivity verification, EVPN Network OAM <bcp14>MUST</bcp14>
For multicast connectivity verification, EVPN Network OAM MUST
support reporting on:</t> support reporting on:</t>
<ul spacing="normal">
<t><list style="symbols"><t>the DF filtering status of specific port(s) o <li>the DF filtering status of a specific port(s) or all the ports
r all the ports in a in a
given bridge-domain.</t> given bridge domain.</li>
<li>the split-horizon filtering status of a specific port(s) or al
<t>the Split Horizon filtering status of specific port(s) or all the l the
ports in a given bridge-domain.</t> ports in a given bridge domain.</li>
</ul>
</list> </section>
</t> <section anchor="sect-3.1.2.2" numbered="true" toc="default">
<name>Fault Isolation</name>
</section> <t>
EVPN OAM <bcp14>MUST</bcp14> support an on-demand fault localization function
<section title="Fault Isolation" anchor="sect-3.1.2.2"><t> . This
EVPN OAM MUST support an on-demand fault localization function. This
involves the capability to narrow down the locality of a fault to a involves the capability to narrow down the locality of a fault to a
particular port, link or node. The characteristic of forward/reverse path particular port, link, or node. The characteristic of forward/reverse path
asymmetry, in MPLS/IP, makes fault isolation a direction-sensitive asymmetry in MPLS/IP makes fault isolation a direction-sensitive
operation. That is, given two PEs A and B, localization of continuity operation. That is, given two PEs A and B, localization of continuity
failures between them requires running fault isolation procedures from PE A failures between them requires running fault-isolation procedures from PE A
to PE B as well as from PE B to PE A.</t> to PE B as well as from PE B to PE A.</t>
<t>
<t>
EVPN Service OAM mechanisms only have visibility to the PEs but not 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 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 the fault is in the customer's own network, the local CE-PE segment,
or remote CE-PE segment(s). EVPN Network and Transport OAM mechanisms 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> can be used for fault isolation between the PEs and P nodes.</t>
</section>
</section> </section>
</section>
</section> <section anchor="sect-3.2" numbered="true" toc="default">
<name>Performance Management</name>
</section> <t>
Performance management functions can be performed both proactively
<section title="Performance Management" anchor="sect-3.2"><t> and on demand. Proactive management involves a recurring function,
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 where the performance management probes are run continuously without
a trigger. We cover both proactive and on-demand functions in this a trigger. We cover both proactive and on-demand functions in this
section.</t> section.</t>
<section anchor="sect-3.2.1" numbered="true" toc="default">
<section title="Packet Loss" anchor="sect-3.2.1"><t> <name>Packet Loss</name>
EVPN Network OAM SHOULD provide mechanisms for measuring packet loss <t>
for a given service, for example <xref target="RFC7680"/> <xref target="RFC66 EVPN Network OAM <bcp14>SHOULD</bcp14> provide mechanisms for measuring packe
73"/>.</t> t loss
for a given service -- for example, <xref target="RFC7680" format="default"/>
<t> and <xref target="RFC6673" format="default"/>.</t>
<t>
Given that EVPN provides inherent support for multipoint-to-multipoint Given that EVPN provides inherent support for multipoint-to-multipoint
connectivity, then packet loss cannot be accurately measured by means of connectivity, packet loss cannot be accurately measured by means of
counting user data packets. This is because user packets can be delivered 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, to more PEs or more ports than are necessary (e.g., due to broadcast,
un-pruned multicast or unknown unicast flooding). As such, a statistical unpruned multicast, or unknown unicast flooding). As such, a statistical
means of approximating packet loss rate is required. This can be achieved means of approximating the packet loss rate is required. This can be achieve
d
by sending "synthetic" OAM packets that are counted only by those ports by sending "synthetic" OAM packets that are counted only by those ports
(MEPs) that are required to receive them. This provides a statistical (MEPs) that are required to receive them. This provides a statistical
approximation of the number of data frames lost, even with approximation of the number of data frames lost, even with
multipoint-to-multipoint connectivity.</t> multipoint-to-multipoint connectivity.</t>
</section>
</section> <section anchor="sect-3.2.2" numbered="true" toc="default">
<name>Packet Delay and Jitter</name>
<section title="Packet Delay and Jitter" anchor="sect-3.2.2"><t> <t>
EVPN Service OAM SHOULD support measurement of one-way and two-way EVPN Service OAM <bcp14>SHOULD</bcp14> support measurement of one-way and two
-way
packet delay and delay variation (jitter) across the EVPN network. packet delay and delay variation (jitter) across the EVPN network.
Measurement of one-way delay requires clock synchronization between Measurement of one-way delay requires clock synchronization between
the probe source and target devices. Mechanisms for clock the probe source and target devices. Mechanisms for clock
synchronization are outside the scope of this document. Note that synchronization are outside the scope of this document. Note that
Service OAM performance management mechanisms defined in [Y.1731] can Service OAM performance management mechanisms defined in <xref target="Y.1731
be used. See also <xref target="RFC7679"/>, <xref target="RFC2681"/>, and <xr "/> can
ef target="RFC3393"/></t> be used. See also <xref target="RFC7679" format="default"/>, <xref target="RF
C2681" format="default"/>, and <xref target="RFC3393" format="default"/>.</t>
<t> <t>
EVPN Network OAM MAY support measurement of one-way and two-way EVPN Network OAM <bcp14>MAY</bcp14> support measurement of one-way and two-wa
y
packet delay and delay variation (jitter) across the EVPN network.</t> packet delay and delay variation (jitter) across the EVPN network.</t>
</section>
</section> </section>
</section>
</section> <section anchor="sect-4" numbered="true" toc="default">
<name>Security Considerations</name>
</section> <t>
EVPN OAM <bcp14>MUST</bcp14> prevent OAM packets from leaking outside of the
<section title="Security Considerations" anchor="sect-4"><t> EVPN
EVPN OAM MUST prevent OAM packets from leaking outside of the EVPN
network or outside their corresponding Maintenance Domain. This can network or outside their corresponding Maintenance Domain. This can
be done for CFM, for example, by having MEPs implement a filtering be done for CFM, for example, by having MEPs implement a filtering
function based on the Maintenance Level associated with received OAM function based on the Maintenance Level associated with received OAM
packets.</t> packets.</t>
<t>
<t> EVPN OAM <bcp14>SHOULD</bcp14> provide mechanisms for implementation and opti
EVPN OAM SHOULD provide mechanisms for implementation and optional onal
use to:</t> use to:</t>
<ul spacing="normal">
<li>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).</li>
<li>authenticate communicating end points (for example, MEPs and MIPs).<
/li>
</ul>
</section>
<section anchor="sect-5" numbered="true" toc="default">
<name>IANA Considerations</name>
<t>
This document has no IANA actions.</t>
</section>
</middle>
<back>
<references>
<name>References</name>
<references>
<name>Normative References</name>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.0792.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.2119.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.4443.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.5880.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.5881.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.5883.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.5884.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.6291.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.6425.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.6428.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.7432.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.7623.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8029.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8174.xml"/>
</references>
<references>
<name>Informative References</name>
<t><list style="symbols"><t>Prevent denial of service attacks caused by e <reference anchor="IEEE-802.1Q">
xploitation of the OAM <front>
message channel (for example by forging messages to exceed a <title>IEEE Standard for Local and metropolitan area networks--Bridg
maintenance end point's capacity to maintain state).</t> es and Bridged Networks</title>
<author>
<t>Authenticate communicating endpoints (for example MEPs and MIPs).</t> <organization>IEEE</organization>
</author>
</list> <date month="December" year="2014"/>
</t> </front>
<seriesInfo name="IEEE" value="Std 802.1Q-2014"/>
</section> <seriesInfo name="DOI" value="10.1109/IEEESTD.2014.6991462"/>
</reference>
<section title="IANA Considerations" anchor="sect-5"><t>
This document requires 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>
<references title="Informative References">
<reference anchor="IEEE-802.1Q"><front>
<title>IEEE Standard for Local and metropolitan area networks - Media Acc
ess Control (MAC) Bridges and Virtual Bridge Local Area Networks</title>
<author>
<organization>IEEE</organization>
</author>
<date year="2014"/>
</front>
<seriesInfo name="IEEE" value="Std 802.1Q-2014"/>
</reference>
<reference anchor="IEEE-802.3"><front>
<title>IEEE Standard for Ethernet</title>
<author>
<organization>IEEE</organization>
</author>
<date year="2015"/> <reference anchor="IEEE-802.3">
</front> <front>
<title>IEEE Standard for Ethernet</title>
<author>
<organization>IEEE</organization>
</author>
<date year="2018" month="August"/>
</front>
<seriesInfo name="IEEE" value="Std 802.3-2018"/>
<seriesInfo name="DOI" value="10.1109/IEEESTD.2018.8457469"/>
</reference>
<seriesInfo name="IEEE" value="Std 802.3-2015"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
</reference> FC.2544.xml"/>
&RFC2544; <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
&RFC2681; FC.2681.xml"/>
&RFC3393; <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
&RFC5085; FC.3393.xml"/>
&RFC6136; <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
&RFC6632; FC.5085.xml"/>
&RFC6673; <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
&RFC7679; FC.6136.xml"/>
&RFC7680; <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.6632.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.6673.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.7679.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.7680.xml"/>
<!-- <reference anchor="Y.1731">
draft-ietf-bess-evpn-oam-req-frmwk-10-manual.txt(799): Warning: Failed parsin <front>
g a
reference. Are all elements separated by commas (not periods, not just
spaces)?:
[Y.1731] "ITU-T Recommendation Y.1731 (02/08) - OAM functions and
mechanisms for Ethernet based networks", February 2008.
-->
<title>Operation, administration and maintenance (OAM) functions and
mechanisms for 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>
</back> </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 f
ullname="Xiao Min"/>, <contact fullname="Gregory Mirsky"/>, <contact fullname="Z
aheduzzaman Sarker"/>, <contact fullname="Dave Schinazi"/>, <contact fullname="J
ohn Scudder"/>, <contact fullname="Melinda Shore"/>, <contact fullname="Robert W
ilton"/>, <contact fullname="Alexander Vainshtein"/>, <contact fullname="Stig Ve
naas"/>, and <contact fullname="Éric Vyncke"/>.</t>
</section>
</back>
</rfc> </rfc>
 End of changes. 103 change blocks. 
691 lines changed or deleted 663 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/