rfc9062.original   rfc9062.txt 
INTERNET-DRAFT Samer Salam Internet Engineering Task Force (IETF) S. Salam
Intended Status: Informational Ali Sajassi Request for Comments: 9062 A. Sajassi
Cisco Category: Informational Cisco
Sam Aldrin ISSN: 2070-1721 S. Aldrin
Google Google
John E. Drake J. Drake
Juniper Juniper
Donald Eastlake D. Eastlake 3rd
Futurewei Futurewei
Expires: October 14, 2021 April 15, 2021 June 2021
EVPN Operations, Administration and Maintenance Framework and Requirements for Ethernet VPN (EVPN) Operations,
Requirements and Framework Administration, and Maintenance (OAM)
draft-ietf-bess-evpn-oam-req-frmwk-10
Abstract Abstract
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
The requirements cover the OAM aspects of EVPN and PBB-EVPN (Provider (OAM). The requirements cover the OAM aspects of EVPN and Provider
Backbone Bridge EVPN). The framework defines the layered OAM model Backbone Bridge EVPN (PBB-EVPN). The framework defines the layered
encompassing the EVPN service layer, network layer, underlying Packet OAM model encompassing the EVPN service layer, network layer,
Switched Network (PSN) transport layer, and link layer but focuses on underlying Packet Switched Network (PSN) transport layer, and link
the service and network layers. layer but focuses on the service and network layers.
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Status of This Memo
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months This document is not an Internet Standards Track specification; it is
and may be updated, replaced, or obsoleted by other documents at any published for informational purposes.
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at This document is a product of the Internet Engineering Task Force
https://www.ietf.org/1id-abstracts.html. The list of Internet-Draft (IETF). It represents the consensus of the IETF community. It has
Shadow Directories can be accessed at received public review and has been approved for publication by the
https://www.ietf.org/shadow.html Internet Engineering Steering Group (IESG). Not all documents
approved by the IESG are candidates for any level of Internet
Standard; see Section 2 of RFC 7841.
INTERNET-DRAFT EVPN OAM Requirements/Framework Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
https://www.rfc-editor.org/info/rfc9062.
Copyright and License Notice Copyright Notice
Copyright (c) 2021 IETF Trust and the persons identified as the Copyright (c) 2021 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
INTERNET-DRAFT EVPN OAM Requirements/Framework
Table of Contents Table of Contents
1. Introduction............................................4 1. Introduction
1.1 Relationship to Other OAM Work.........................4 1.1. Relationship to Other OAM Work
1.2 Specification of Requirements..........................5 1.2. Specification of Requirements
1.3 Terminology............................................5 1.3. Terminology
2. EVPN OAM Framework
2. EVPN OAM Framework......................................7 2.1. OAM Layering
2.1 OAM Layering...........................................7 2.2. EVPN Service OAM
2.2 EVPN Service OAM.......................................8 2.3. EVPN Network OAM
2.3 EVPN Network OAM.......................................9 2.4. Transport OAM for EVPN
2.4 Transport OAM for EVPN................................10 2.5. Link OAM
2.5 Link OAM..............................................11 2.6. OAM Interworking
2.6 OAM Inter-working.....................................11 3. EVPN OAM Requirements
3.1. Fault Management Requirements
3. EVPN OAM Requirements..................................12 3.1.1. Proactive Fault Management Functions
3.1 Fault Management Requirements.........................12 3.1.1.1. Fault Detection (Continuity Check)
3.1.1 Proactive Fault Management Functions................12 3.1.1.2. Defect Indication
3.1.1.1 Fault Detection (Continuity Check)................12 3.1.1.2.1. Forward Defect Indication (FDI)
3.1.1.2 Defect Indication.................................13 3.1.1.2.2. Reverse Defect Indication (RDI)
3.1.1.2.1 Forward Defect Indication.......................13 3.1.2. On-Demand Fault Management Functions
3.1.1.2.2 Reverse Defect Indication (RDI).................14 3.1.2.1. Connectivity Verification
3.1.2 On-Demand Fault Management Functions................14 3.1.2.2. Fault Isolation
3.1.2.1 Connectivity Verification.........................14 3.2. Performance Management
3.1.2.2 Fault Isolation...................................15 3.2.1. Packet Loss
3.2 Performance Management................................15 3.2.2. Packet Delay and Jitter
3.2.1 Packet Loss.........................................16 4. Security Considerations
3.2.2 Packet Delay and Jitter.............................16 5. IANA Considerations
6. References
4. Security Considerations................................17 6.1. Normative References
5. IANA Considerations....................................17 6.2. Informative References
Acknowledgements
6. Acknowledgements.......................................17 Authors' Addresses
Normative References......................................18
Informative References....................................19
INTERNET-DRAFT EVPN OAM Requirements/Framework
1. Introduction 1. Introduction
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, [RFC6291]). In this context, we use the term EVPN Maintenance (OAM) [RFC6291]. In this context, we use the term "EVPN
OAM to loosely refer to the OAM functions required for and/or OAM" to loosely refer to the OAM functions required for and/or
applicable to [RFC7432] and [RFC7623]. applicable to [RFC7432] and [RFC7623].
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
over the core MPLS/IP network. reachability information over the core MPLS/IP network.
PBB-EVPN combines Provider Backbone Bridging (PBB) [802.1Q] with EVPN PBB-EVPN combines Provider Backbone Bridging (PBB) [IEEE-802.1Q] with
in order to reduce the number of BGP MAC advertisement routes, EVPN in order to reduce the number of BGP MAC advertisement routes;
provide client MAC address mobility using C-MAC (Client MAC provide client MAC address mobility using C-MAC [RFC7623] aggregation
[RFC7623]) aggregation and B-MAC (Backbone MAC [RFC7623]) sub- and Backbone MAC (B-MAC) [RFC7623] sub-netting; confine the scope of
netting, confine the scope of C-MAC learning to only active flows, C-MAC learning to only active flows; offer per-site policies; and
offer per site policies, and avoid C-MAC address flushing on topology avoid C-MAC address flushing on topology changes.
changes.
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. the service and network layers.
1.1 Relationship to Other OAM Work 1.1. Relationship to Other OAM Work
This document leverages concepts and draws upon elements defined This document leverages concepts and draws upon elements defined and
and/or used in the following documents: / or used in the following documents:
[RFC6136] specifies the requirements and a reference model for OAM as [RFC6136] specifies the requirements and a reference model for 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 VPLS and Switched Network (PSN) tunnels. This document focuses on Virtual
VPWS solutions and services. Private LAN Service (VPLS) and Virtual Private Wire Service (VPWS)
solutions and services.
[RFC8029] defines mechanisms for detecting data plane failures in [RFC8029] defines mechanisms for detecting data plane failures in
MPLS LSPs, including procedures to check the correct operation of the MPLS Label Switched Paths (LSPs), including procedures to check the
data plane, as well as mechanisms to verify the data plane against correct operation of the data plane as well as mechanisms to verify
the control plane. the data plane against the control plane.
[802.1Q] specifies the Ethernet Connectivity Fault Management (CFM) [IEEE-802.1Q] specifies the Ethernet Connectivity Fault Management
protocol, which defines the concepts of Maintenance Domains, (CFM) protocol, which defines the concepts of Maintenance Domains,
Maintenance Associations, Maintenance End Points, and Maintenance Maintenance Associations, Maintenance End Points, and Maintenance
Intermediate Points. Intermediate Points.
INTERNET-DRAFT EVPN OAM Requirements/Framework
[Y.1731] extends Connectivity Fault Management in the following [Y.1731] extends Connectivity Fault Management in the following
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. measurement.
1.2 Specification of Requirements 1.2. Specification of Requirements
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in
14 [RFC2119] [RFC8174] when, and only when, they appear in all BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
1.3 Terminology 1.3. Terminology
This document uses the following terminology much of which is defined
in [RFC6136]:
CE Customer Edge device, e.g., a host, router, or switch.
CFM Connectivity Fault Management [802.1Q]. This document uses the following terminology, much of which is
defined in [RFC6136]:
DF Designated Forwarder [RFC7432]. CE Customer Edge device; for example, a host, router, or
switch.
Down MEP A MEP that originates traffic away from and terminates CFM Connectivity Fault Management [IEEE-802.1Q]
traffic towards the core of the device in whose port it is
logically located.
EVI An EVPN instance spanning the Provider Edge (PE) devices DF Designated Forwarder [RFC7432]
participating in that EVPN [RFC7432].
L2VPN Layer 2 VPN. Down MEP A MEP that originates traffic away from and terminates
traffic towards the core of the device in whose port it
is logically located.
MA Maintenance Association is a set of MEPs belonging to the same EVI An EVPN instance spanning the Provider Edge (PE) devices
Maintenance Domain (MD), established to verify the integrity of participating in that EVPN [RFC7432].
a single service instance [802.1Q].
MD Maintenance Domain, an OAM Domain that represents a region over L2VPN Layer 2 VPN
which OAM frames can operate unobstructed [802.1Q].
MEP Maintenance End Point is responsible for origination and LOC Loss of continuity
termination of OAM frames for a given MA. A MEP is logically
located in a device's port [802.1Q].
MIP Maintenance Intermediate Point is located between peer MEPs and MA Maintenance Association; a set of MEPs belonging to the
same Maintenance Domain (MD) established to verify the
integrity of a single service instance [IEEE-802.1Q].
INTERNET-DRAFT EVPN OAM Requirements/Framework MD Maintenance Domain; an OAM Domain that represents a
region over which OAM frames can operate unobstructed
[IEEE-802.1Q].
can process and respond to certain OAM frames but does not MEP Maintenance End Point; it is responsible for origination
initiate them. A MIP is logically located in a device's port and termination of OAM frames for a given MA. A MEP is
[802.1Q]. logically located in a device's port [IEEE-802.1Q].
MP2P Multipoint to Point. MIP Maintenance Intermediate Point; it is located between
peer MEPs and can process and respond to certain OAM
frames but does not initiate them. A MIP is logically
located in a device's port [IEEE-802.1Q].
NMS Network Management Station [RFC6632]. MP2P Multipoint to Point
P Provider network interior (non-edge) node. NMS Network Management Station [RFC6632]
P2MP Point to Multipoint. P Provider network interior (non-edge) node
PBB Provider Backbone Bridge [RFC7623]. P2MP Point to Multipoint
PE Provider network Edge device. PBB Provider Backbone Bridge [RFC7623]
Up MEP A MEP that originates traffic towards and terminates traffic PE Provider Edge network device
from the core of the device in whose port it is logically
located.
VPN Virtual Private Network Up MEP A MEP that originates traffic towards and terminates
traffic from the core of the device in whose port it is
logically located.
INTERNET-DRAFT EVPN OAM Requirements/Framework VPN Virtual Private Network
2. EVPN OAM Framework 2. EVPN OAM Framework
2.1 OAM Layering 2.1. OAM Layering
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
document is the Service and Network layers. this document is the service and network layers.
- The Service Layer runs end to end between the sites or Ethernet * The service layer runs end to end between the sites or Ethernet
Segments that are being interconnected by the EVPN solution. segments that are being interconnected by the EVPN solution.
- The Network Layer extends between the EVPN PE (Provider Edge) nodes * The network layer extends between the EVPN PE (Provider Edge)
and is mostly transparent to the P (Provider network interior) nodes and is mostly transparent to the P (provider network
nodes (except where Flow Entropy comes into play). It leverages interior) nodes (except where flow entropy comes into play). It
MPLS for service (i.e., EVI) multiplexing and Split-Horizon leverages MPLS for service (i.e., EVI) multiplexing and split-
functions. horizon functions.
- The Transport Layer is dictated by the networking technology of the * The transport layer is dictated by the networking technology of
PSN. It may be either based on MPLS LSPs or IP. the PSN. It may be based on either MPLS LSPs or IP.
- The Link Layer is dependent upon the physical technology used. * 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
are deployed (e.g., POS, DWDM etc.). alternatives are deployed (e.g., Packet over SONET (POS), Dense
Wavelength Division Multiplexing (DWDM), etc.).
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.
below depicts the OAM layering, and shows which devices have Figure 1 below depicts the OAM layering and shows which devices have
visibility into what OAM layer(s). visibility into what OAM layer(s).
+---+ +---+ +---+ +---+
+--+ | | +---+ +---+ +---+ | | +--+ +--+ | | +---+ +---+ +---+ | | +--+
|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
Figure 1: OAM Layering Figure 1: OAM Layering
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
such, they can be used to deduce whether the fault is in the whether the fault is in the customer's own network, the local CE-PE
segment, the PE-PE segment, or the remote CE-PE segment(s). EVPN
INTERNET-DRAFT EVPN OAM Requirements/Framework Transport OAM mechanisms can be used for fault isolation between the
PEs and P nodes.
customer's own network, the local CE-PE segment, the PE-PE segment or
the remote CE-PE segment(s). EVPN Transport OAM mechanisms can be
used for fault isolation between the PEs and P nodes.
Figure 2 below shows an example network where native Ethernet domains Figure 2 below shows an example network where Ethernet domains are
are interconnected via EVPN using MPLS and gives the OAM mechanisms interconnected via EVPN using MPLS, and it shows the OAM mechanisms
applicable at each layer. The details of the layers are described in that are applicable at each layer. The details of the layers are
the sections below. described in the sections below.
+---+ +---+ +---+ +---+
+--+ | | +---+ +---+ +---+ | | +--+ +--+ | | +---+ +---+ +---+ | | +--+
|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]
Figure 2: EVPN OAM Example Figure 2: EVPN OAM Example
2.2 EVPN Service OAM 2.2. EVPN Service OAM
The EVPN Service OAM protocol depends on what service layer The EVPN Service OAM protocol depends on what service-layer
technology is being interconnected by the EVPN solution. In case of technology is being interconnected by the EVPN solution. In the case
[RFC7432] and [RFC7623], the service layer is Ethernet; hence, the of [RFC7432] and [RFC7623], the service layer is Ethernet; hence, the
corresponding service OAM protocol is Ethernet Connectivity Fault corresponding Service OAM protocol is Ethernet CFM [IEEE-802.1Q].
Management (CFM) [802.1Q].
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
[RFC7432] [RFC7623] whereas the P nodes do not. [RFC7432] and [RFC7623], whereas the P nodes do not.
The EVPN PE MUST support MIP functions in the applicable service OAM The EVPN PE MUST support MIP functions in the applicable Service OAM
protocol, for example Ethernet CFM. The EVPN PE SHOULD support MEP protocol (for example, Ethernet CFM). The EVPN PE SHOULD support MEP
functions in the applicable service OAM protocol. This includes both functions in the applicable Service OAM protocol. This includes both
Up and Down MEP functions. Up and Down MEP functions.
As shown in Figure 3, the MIP and MEP functions being referred to are As shown in Figure 3, the MIP and MEP functions being referred 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 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
INTERNET-DRAFT EVPN OAM Requirements/Framework
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. CEs or from a PE to its local CE or to the remote CE are Service
OAMs.
+-------+ +----------------+ +----------------+ +-------+ +-------+ +----------------+ +----------------+ +-------+
|+-----+| |+--------------+| |+--------------+| |+-----+| |+-----+| |+--------------+| |+--------------+| |+-----+|
|| 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| || |+--+--+|
| | | |+---+-----+ | | | | +-----+---+| | | | | | | |+---+-----+ | | | | +-----+---+| | | |
+---|---+ +----|--------|--+ +--|--------|----+ +---|---+ +---|---+ +----|--------|--+ +--|--------|----+ +---|---+
| | | | | | | | | | | |
+------------+ +--- ... ---+ +------------+ +------------+ +--- ... ---+ +------------+
Figure 3: CFM Details Figure 3: CFM Details
The EVPN PE MUST, by default, learn the MAC address of locally The EVPN PE MUST, 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. number of MAC addresses that a PE will learn SHOULD be implemented.
The EVPN PE SHOULD advertise any MEP/MIP local to the PE as a MAC/IP The EVPN PE SHOULD 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 SHOULD be advertised with the static (sticky) bit set (see
15.2 of [RFC7432]). Section 15.2 of [RFC7432]).
2.3 EVPN Network OAM
EVPN Network OAM is visible to the PE nodes only. This OAM layer is 2.3. EVPN Network OAM
analogous to VCCV [RFC5085] in the case of VPLS/VPWS. It provides
mechanisms to check the correct operation of the data plane, as well
as a mechanism to verify the data plane against the control plane.
This includes the ability to perform fault detection and diagnostics
on:
- the MP2P tunnels used for the transport of unicast traffic between EVPN Network OAM is visible to the PE nodes only. This OAM layer is
PEs. EVPN allows for three different models of unicast label analogous to Virtual Circuit Connectivity Verification (VCCV)
assignment: label per EVI, label per <ESI, Ethernet Tag> and label [RFC5085] in the case of VPLS/VPWS. It provides mechanisms to check
per MAC address. In all three models, the label is bound to an EVPN the correct operation of the data plane as well as a mechanism to
Unicast FEC. EVPN Network OAM MUST provide mechanisms to check the verify the data plane against the control plane. This includes the
operation of the data plane and verify that operation against the ability to perform fault detection and diagnostics on:
control plane view.
INTERNET-DRAFT EVPN OAM Requirements/Framework * 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 <ESI, Ethernet Tag>, and
label per MAC address. In all three models, the label is bound to
an EVPN Unicast Forwarding Equivalence Class (FEC). EVPN Network
OAM MUST provide mechanisms to check the operation of the data
plane and verify that operation against the control plane view.
- the MP2P tunnels used for aliasing unicast traffic destined to a * the MP2P tunnels used for aliasing unicast traffic destined to a
multi-homed Ethernet Segment. The three label assignment models, multihomed 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
is bound to an EVPN Aliasing FEC. EVPN Network OAM MUST provide label is bound to an EVPN Aliasing FEC. EVPN Network OAM MUST
mechanisms to check the operation of the data plane and verify that provide mechanisms to check the operation of the data plane and
operation against the control plane view. verify that operation against the control plane view.
- the multicast tunnels (either MP2P or P2MP) used for the transport * 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.
the case of ingress replication, a label is allocated per EVI or In the case of ingress replication, a label is allocated per EVI
per <EVI, Ethernet Tag> and is bound to an EVPN Multicast FEC. In or per <EVI, Ethernet Tag> and is bound to an EVPN Multicast FEC.
the case of LSM (Label Switched Multicast), and more specifically In the case of Label Switched Multicast (LSM) and, more
aggregate inclusive trees, again a label may be allocated per EVI specifically, aggregate inclusive trees, again, a label may be
or per <EVI, Ethernet Tag> and is bound to the tunnel FEC. allocated per EVI or per <EVI, Ethernet Tag> and is bound to the
tunnel FEC.
- the correct operation of the ESI split-horizon filtering function. * the correct operation of the Ethernet Segment Identifier (ESI)
In EVPN, a label is allocated per multi-homed Ethernet Segment for split-horizon filtering function. In EVPN, a label is allocated
the purpose of performing the access split-horizon enforcement. The per multihomed Ethernet segment for the purpose of performing the
label is bound to an EVPN Ethernet Segment. access split-horizon enforcement. The label is bound to an EVPN
Ethernet segment.
- the correct operation of the DF (Designated Forwarder [RFC7432]) * the correct operation of the Designated Forwarder (DF) [RFC7432]
filtering function. EVPN Network OAM MUST provide mechanisms to filtering function. EVPN Network OAM MUST provide mechanisms 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. against the control plane view for the DF filtering function.
EVPN Network OAM mechanisms MUST provide in-band monitoring 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. this are beyond the scope of this document.
EVPN Network OAM SHOULD 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. conformance to the state of the control plane.
2.4 Transport OAM for EVPN 2.4. Transport OAM for EVPN
The transport OAM protocol depends on the nature of the underlying
transport technology in the PSN. MPLS OAM mechanisms [RFC8029]
[RFC6425] as well as ICMP [RFC792] / ICMPv6 [RFC4443] are applicable,
depending on whether the PSN employs MPLS or IP transport,
respectively. Furthermore, BFD mechanisms per [RFC5880], [RFC5881],
[RFC5883] and [RFC5884] apply. Also, the BFD mechanisms pertaining to
MPLS-TP LSPs per [RFC6428] are applicable.
INTERNET-DRAFT EVPN OAM Requirements/Framework The Transport OAM protocol depends on the nature of the underlying
transport technology in the PSN. MPLS OAM mechanisms [RFC8029]
[RFC6425] as well as ICMP [RFC0792] and ICMPv6 [RFC4443] are
applicable, depending on whether the PSN employs MPLS or IP
transport, respectively. Furthermore, Bidirectional Forwarding
Detection (BFD) mechanisms per [RFC5880], [RFC5881], [RFC5883], and
[RFC5884] apply. Also, the BFD mechanisms pertaining to MPLS-TP LSPs
per [RFC6428] are applicable.
2.5 Link OAM 2.5. Link OAM
Link OAM depends on the data link technology being used between the 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 ([802.3] Clause 57) may be used. Ethernet Link OAM ([IEEE-802.3], Clause 57) may be used.
2.6 OAM Inter-working 2.6. OAM Interworking
When inter-working two networking domains, such as native Ethernet When interworking two networking domains, such as actual Ethernet and
and EVPN to provide an end-to-end emulated service, there is a need EVPN to provide an end-to-end emulated service, there is a need to
to identify the failure domain and location, even when a PE supports 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
monitoring, such as Ethernet Continuity Check Messages (CCMs proactive monitoring, such as Ethernet Continuity Check Messages
[802.1Q]), at a PE to detect the failure of an EVI across the EVPN (CCMs) [IEEE-802.1Q], at a PE to detect the failure of an EVI across
domain. Thus, the mapping of alarms generated upon failure detection the EVPN domain. Thus, the mapping of alarms generated upon failure
in one domain (e.g., native Ethernet or EVPN network domain) to the detection in one domain (e.g., actual Ethernet or EVPN network
other domain is needed. There are also cases where a PE may not be domain) to the other domain is needed. There are also cases where a
able to process Service OAM messages received from a remote PE over PE may not be able to process Service OAM messages received from a
the PSN even when such messages are defined, as in the Ethernet case, remote PE over the PSN even when such messages are defined, as in the
thereby necessitating support for fault notification message mapping Ethernet case, thereby necessitating support for fault notification
between the EVPN Network domain and the Service domain. message mapping between the EVPN Network domain and the Service
domain.
OAM inter-working is not limited though to scenarios involving OAM interworking is not limited, though, to scenarios involving
disparate network domains. It is possible to perform OAM inter- disparate network domains. It is possible to perform OAM
working across different layers in the same network domain. In interworking across different layers in the same network domain. In
general, alarms generated within an OAM layer, as a result of general, alarms generated within an OAM layer, as a result of
proactive fault detection mechanisms, may be injected into its client proactive fault detection mechanisms, may be injected into its
layer OAM mechanisms. This allows the client layer OAM to trigger client-layer OAM mechanisms. This allows the client-layer OAM to
event-driven (i.e., asynchronous) fault notifications. For example, trigger event-driven (i.e., asynchronous) fault notifications. For
alarms generated by the Link OAM mechanisms may be injected into the example, alarms generated by the Link OAM mechanisms may be injected
Transport OAM layer, and alarms generated by the Transport OAM into the Transport OAM layer, and alarms generated by the Transport
mechanism may be injected into the Network OAM mechanism, and so on. OAM mechanism may be injected into the Network OAM mechanism, and so
on.
EVPN OAM MUST support inter-working between the Network OAM and EVPN OAM MUST support interworking between the Network OAM and
Service OAM mechanisms. EVPN OAM MAY support inter-working among Service OAM mechanisms. EVPN OAM MAY support interworking among
other OAM layers. other OAM layers.
INTERNET-DRAFT EVPN OAM Requirements/Framework 3. EVPN OAM Requirements
3. EVPN OAM Requirements
This section discusses the EVPN OAM requirements pertaining to Fault This section discusses the EVPN OAM requirements pertaining to fault
Management and Performance Management. management and performance management.
3.1 Fault Management Requirements 3.1. Fault Management Requirements
3.1.1 Proactive Fault Management Functions 3.1.1. Proactive Fault Management Functions
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
example protection switchover or alarm indication signaling, can be switchover or alarm indication signaling) can be associated with
associated with specific events, such as entering or clearing fault specific events, such as entering or clearing fault states.
states.
3.1.1.1 Fault Detection (Continuity Check) 3.1.1.1. Fault Detection (Continuity Check)
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 [802.1Q]. The through the exchange of CCMs [IEEE-802.1Q]. The reachability between
reachability between any two arbitrary MEPs may be monitored for: any two arbitrary MEPs may be monitored for:
- in-band per-flow monitoring. This enables per flow monitoring
between MEPs. EVPN Network OAM MUST support fault detection with
per user flow granularity. EVPN Service OAM MAY support fault
detection with per user flow granularity.
- a representative path. This enables liveness check of the nodes * in-band, per-flow monitoring. This enables per-flow monitoring
hosting the MEPs assuming that the loss of continuity to the MEP is between MEPs. EVPN Network OAM MUST support fault detection with
interpreted as a failure of the hosting node. This, however, does per-user flow granularity. EVPN Service OAM MAY support fault
not conclusively indicate liveness of the path(s) taken by user detection with per-user flow granularity.
data traffic. This enables node failure detection but not path
failure detection, through the use of a test flow. EVPN Network OAM
and Service OAM MUST support fault detection using test flows.
- all paths. For MPLS/IP networks with ECMP, monitoring of all * a representative path. This enables a liveness check of the nodes
unicast paths between MEPs (on non-adjacent nodes) may not be hosting the MEPs, assuming that the loss of continuity (LOC) to
possible, since the per-hop ECMP hashing behavior may yield the MEP is interpreted as a failure of the hosting node. This,
situations where it is impossible for a MEP to pick flow entropy however, does not conclusively indicate liveness of the path(s)
characteristics that result in exercising the exhaustive set of taken by user data traffic. This enables node failure detection
ECMP paths. Monitoring of all ECMP paths between MEPs (on non- but not path failure detection through the use of a test flow.
adjacent nodes) is not a requirement for EVPN OAM. EVPN Network OAM and Service OAM MUST support fault detection
using test flows.
INTERNET-DRAFT EVPN OAM Requirements/Framework * all paths. For MPLS/IP networks with ECMP, the monitoring of all
unicast paths between MEPs (on non-adjacent nodes) may not be
possible since the per-hop ECMP hashing behavior may yield
situations where it is impossible for a MEP to pick flow entropy
characteristics that result in exercising the exhaustive set of
ECMP paths. The monitoring of all ECMP paths between MEPs (on
non-adjacent nodes) is not a requirement for EVPN OAM.
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 MUST provide procedures to monitor 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. EVPN Service OAM and Network OAM.
3.1.1.2 Defect Indication 3.1.1.2. Defect Indication
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 MUST support at least
support at least one of these types of event-driven defect indication one of these types of event-driven defect indications upon the
upon the detection of a connectivity defect. detection of a connectivity defect.
3.1.1.2.1 Forward Defect Indication 3.1.1.2.1. Forward Defect Indication (FDI)
This is used to signal a failure that is detected by a lower layer FDI is used to signal a failure that is detected by a lower-layer OAM
OAM mechanism. A server MEP (i.e., an actual or virtual MEP) mechanism. A server MEP (i.e., an actual or virtual MEP) transmits a
transmits a Forward Defect Indication in a direction that is away forward defect indication in a direction away from the direction of
from the direction of the failure (refer to Figure 4 below). the failure (refer to Figure 4 below).
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
Figure 4: Forward Defect Indication Figure 4: Forward Defect Indication
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.
suppression is useful when a transport/network level fault translates Alarm suppression is useful when a transport-level or network-level
to multiple service or flow level faults. In such a scenario, it is fault translates to multiple service- or flow-level faults. In such
enough to alert a network management station (NMS) of the single a scenario, it is enough to alert a network management station (NMS)
transport/network level fault in lieu of flooding that NMS with a of the single transport-level or network-level fault in lieu of
multitude of Service or Flow granularity alarms. EVPN PEs SHOULD flooding that NMS with a multitude of Service or Flow granularity
support Forward Defect Indication in the Service OAM mechanisms. alarms. EVPN PEs SHOULD support forward defect indication in the
Service OAM mechanisms.
INTERNET-DRAFT EVPN OAM Requirements/Framework
3.1.1.2.2 Reverse Defect Indication (RDI) 3.1.1.2.2. Reverse Defect Indication (RDI)
RDI is used to signal that the advertising MEP has detected a loss of RDI is used to signal that the advertising MEP has detected a LOC
continuity (LoC) defect. RDI is transmitted in the direction of the defect. RDI is transmitted in the direction of the failure (refer to
failure (refer to Figure 5). Figure 5).
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
Figure 5: Reverse Defect Indication Figure 5: Reverse Defect Indication
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 SHOULD support reverse defect indication
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. sender had detected a LOC defect.
3.1.2 On-Demand Fault Management Functions 3.1.2. On-Demand Fault Management Functions
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. defect condition.
3.1.2.1 Connectivity Verification 3.1.2.1. Connectivity Verification
EVPN Network OAM MUST support on-demand connectivity verification EVPN Network OAM MUST support on-demand connectivity verification
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 SHOULD provide a means for specifying and
carrying in the messages: carrying the following in the messages:
- variable length payload/padding to test MTU (Maximum Transmission
Unit) related connectivity problems.
INTERNET-DRAFT EVPN OAM Requirements/Framework * variable-length payload/padding to test connectivity problems
related to the Maximum Transmission Unit (MTU).
- test frame formats as defined in Appendix C of [RFC2544] to detect * test frame formats as defined in Appendix C of [RFC2544] to detect
potential packet corruption. potential packet corruption.
EVPN Network OAM MUST support connectivity verification at per flow 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). between PEs).
EVPN Service OAM MUST support connectivity verification on test flows EVPN Service OAM MUST support connectivity verification on test flows
and MAY support connectivity verification on user flows. and MAY support connectivity verification on user flows.
For multicast connectivity verification, EVPN Network OAM MUST For multicast connectivity verification, EVPN Network OAM MUST
support reporting on: support reporting on:
- the DF filtering status of specific port(s) or all the ports in a * the DF filtering status of a specific port(s) or all the ports in
given bridge-domain. a given bridge domain.
- the Split Horizon filtering status of specific port(s) or all the * the split-horizon filtering status of a specific port(s) or all
ports in a given bridge-domain. the ports in a given bridge domain.
3.1.2.2 Fault Isolation 3.1.2.2. Fault Isolation
EVPN OAM MUST support an on-demand fault localization function. 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 particular port, link, or node. The characteristic of forward/
path asymmetry, in MPLS/IP, makes fault isolation a direction- reverse path asymmetry in MPLS/IP makes fault isolation a direction-
sensitive operation. That is, given two PEs A and B, localization of sensitive operation. That is, given two PEs A and B, localization of
continuity failures between them requires running fault isolation continuity failures between them requires running fault-isolation
procedures from PE A to PE B as well as from PE B to PE A. procedures from PE A to PE B as well as from PE B to PE A.
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
can be used for fault isolation between the PEs and P nodes. mechanisms can be used for fault isolation between the PEs and P
nodes.
3.2 Performance Management 3.2. Performance Management
Performance Management functions can be performed both proactively Performance management functions can be performed both proactively
and on-demand. Proactive management involves a recurring function, 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. section.
INTERNET-DRAFT EVPN OAM Requirements/Framework 3.2.1. Packet Loss
3.2.1 Packet Loss
EVPN Network OAM SHOULD provide mechanisms for measuring packet loss EVPN Network OAM SHOULD provide mechanisms for measuring packet loss
for a given service, for example [RFC7680] [RFC6673]. for a given service -- for example, [RFC7680] and [RFC6673].
Given that EVPN provides inherent support for multipoint-to- Given that EVPN provides inherent support for multipoint-to-
multipoint connectivity, then packet loss cannot be accurately multipoint connectivity, packet loss cannot be accurately measured by
measured by means of counting user data packets. This is because user means of counting user data packets. This is because user packets
packets can be delivered to more PEs or more ports than are necessary can be delivered to more PEs or more ports than are necessary (e.g.,
(e.g., due to broadcast, un-pruned multicast or unknown unicast due to broadcast, unpruned multicast, or unknown unicast flooding).
flooding). As such, a statistical means of approximating packet loss As such, a statistical means of approximating the packet loss rate is
rate is required. This can be achieved by sending "synthetic" OAM required. This can be achieved by sending "synthetic" OAM packets
packets that are counted only by those ports (MEPs) that are required that are counted only by those ports (MEPs) that are required to
to receive them. This provides a statistical approximation of the receive them. This provides a statistical approximation of the
number of data frames lost, even with multipoint-to-multipoint number of data frames lost, even with multipoint-to-multipoint
connectivity. connectivity.
3.2.2 Packet Delay and Jitter 3.2.2. Packet Delay and Jitter
EVPN Service OAM SHOULD support measurement of one-way and two-way EVPN Service OAM SHOULD 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 [Y.1731] can
be used. See also [RFC7679], [RFC2681], and [RFC3393] be used. See also [RFC7679], [RFC2681], and [RFC3393].
EVPN Network OAM MAY support measurement of one-way and two-way EVPN Network OAM MAY 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.
INTERNET-DRAFT EVPN OAM Requirements/Framework 4. Security Considerations
4. Security Considerations
EVPN OAM MUST prevent OAM packets from leaking outside of the 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. packets.
EVPN OAM SHOULD provide mechanisms for implementation and optional EVPN OAM SHOULD provide mechanisms for implementation and optional
use to: use to:
- Prevent denial of service attacks caused by exploitation of the OAM * prevent denial-of-service attacks caused by exploitation of the
message channel (for example by forging messages to exceed a OAM message channel (for example, by forging messages to exceed a
maintenance end point's capacity to maintain state). Maintenance End Point's capacity to maintain state).
- Authenticate communicating endpoints (for example MEPs and MIPs).
5. IANA Considerations
This document requires no IANA actions.
6. Acknowledgements
The authors would like to thank the following for their review of
this work and valuable comments:
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.
INTERNET-DRAFT EVPN OAM Requirements/Framework * authenticate communicating end points (for example, MEPs and
MIPs).
Normative References 5. IANA Considerations
[RFC792] Postel, J., "Internet Control Message Protocol", STD 5, RFC This document has no IANA actions.
792, DOI 10.17487/RFC0792, September 1981,
<https://www.rfc-editor.org/info/rfc792>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 6. References
Requirement Levels", BCP 14, RFC 2119, DOI
10.17487/RFC2119, March 1997, <https://www.rfc-
editor.org/info/rfc2119>.
[RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet 6.1. Normative References
Control Message Protocol (ICMPv6) for the Internet Protocol
Version 6 (IPv6) Specification", STD 89, RFC 4443, DOI
10.17487/RFC4443, March 2006, <https://www.rfc-
editor.org/info/rfc4443>.
[RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection [RFC0792] Postel, J., "Internet Control Message Protocol", STD 5,
(BFD)", RFC 5880, DOI 10.17487/RFC5880, June 2010, RFC 792, DOI 10.17487/RFC0792, September 1981,
<https://www.rfc-editor.org/info/rfc5880>. <https://www.rfc-editor.org/info/rfc792>.
[RFC5881] Katz, D. and D. Ward, "Bidirectional Forwarding Detection [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
(BFD) for IPv4 and IPv6 (Single Hop)", RFC 5881, DOI Requirement Levels", BCP 14, RFC 2119,
10.17487/RFC5881, June 2010, <https://www.rfc- DOI 10.17487/RFC2119, March 1997,
editor.org/info/rfc5881>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC5883] Katz, D. and D. Ward, "Bidirectional Forwarding Detection [RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet
(BFD) for Multihop Paths", RFC 5883, DOI 10.17487/RFC5883, Control Message Protocol (ICMPv6) for the Internet
June 2010, <https://www.rfc-editor.org/info/rfc5883>. Protocol Version 6 (IPv6) Specification", STD 89,
RFC 4443, DOI 10.17487/RFC4443, March 2006,
<https://www.rfc-editor.org/info/rfc4443>.
[RFC5884] Aggarwal, R., Kompella, K., Nadeau, T., and G. Swallow, [RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection
"Bidirectional Forwarding Detection (BFD) for MPLS Label (BFD)", RFC 5880, DOI 10.17487/RFC5880, June 2010,
Switched Paths (LSPs)", RFC 5884, DOI 10.17487/RFC5884, <https://www.rfc-editor.org/info/rfc5880>.
June 2010, <https://www.rfc-editor.org/info/rfc5884>.<
[RFC6291] Andersson, L., van Helvoort, H., Bonica, R., Romascanu, D., [RFC5881] Katz, D. and D. Ward, "Bidirectional Forwarding Detection
and S. Mansfield, "Guidelines for the Use of the "OAM" (BFD) for IPv4 and IPv6 (Single Hop)", RFC 5881,
Acronym in the IETF", BCP 161, RFC 6291, DOI DOI 10.17487/RFC5881, June 2010,
10.17487/RFC6291, June 2011, <https://www.rfc- <https://www.rfc-editor.org/info/rfc5881>.
editor.org/info/rfc6291>.
[RFC6425] Saxena, S., Ed., Swallow, G., Ali, Z., Farrel, A., [RFC5883] Katz, D. and D. Ward, "Bidirectional Forwarding Detection
Yasukawa, S., and T. Nadeau, "Detecting Data-Plane Failures (BFD) for Multihop Paths", RFC 5883, DOI 10.17487/RFC5883,
in Point-to-Multipoint MPLS - Extensions to LSP Ping", RFC June 2010, <https://www.rfc-editor.org/info/rfc5883>.
6425, DOI 10.17487/RFC6425, November 2011,
<https://www.rfc-editor.org/info/rfc6425>.
[RFC6428] Allan, D., Ed., Swallow, G., Ed., and J. Drake, Ed., [RFC5884] Aggarwal, R., Kompella, K., Nadeau, T., and G. Swallow,
"Proactive Connectivity Verification, Continuity Check, and "Bidirectional Forwarding Detection (BFD) for MPLS Label
Remote Defect Indication for the MPLS Transport Profile", Switched Paths (LSPs)", RFC 5884, DOI 10.17487/RFC5884,
June 2010, <https://www.rfc-editor.org/info/rfc5884>.
INTERNET-DRAFT EVPN OAM Requirements/Framework [RFC6291] Andersson, L., van Helvoort, H., Bonica, R., Romascanu,
D., and S. Mansfield, "Guidelines for the Use of the "OAM"
Acronym in the IETF", BCP 161, RFC 6291,
DOI 10.17487/RFC6291, June 2011,
<https://www.rfc-editor.org/info/rfc6291>.
RFC 6428, DOI 10.17487/RFC6428, November 2011, [RFC6425] Saxena, S., Ed., Swallow, G., Ali, Z., Farrel, A.,
<https://www.rfc-editor.org/info/rfc6428>. Yasukawa, S., and T. Nadeau, "Detecting Data-Plane
Failures in Point-to-Multipoint MPLS - Extensions to LSP
Ping", RFC 6425, DOI 10.17487/RFC6425, November 2011,
<https://www.rfc-editor.org/info/rfc6425>.
[RFC7432] Sajassi, A., Ed., Aggarwal, R., Bitar, N., Isaac, A., [RFC6428] Allan, D., Ed., Swallow, G., Ed., and J. Drake, Ed.,
Uttaro, J., Drake, J., and W. Henderickx, "BGP MPLS-Based "Proactive Connectivity Verification, Continuity Check,
Ethernet VPN", RFC 7432, DOI 10.17487/RFC7432, February and Remote Defect Indication for the MPLS Transport
2015, <https://www.rfc-editor.org/info/rfc7432>. Profile", RFC 6428, DOI 10.17487/RFC6428, November 2011,
<https://www.rfc-editor.org/info/rfc6428>.
[RFC7623] Sajassi, A., Ed., Salam, S., Bitar, N., Isaac, A., and W. [RFC7432] Sajassi, A., Ed., Aggarwal, R., Bitar, N., Isaac, A.,
Henderickx, "Provider Backbone Bridging Combined with Uttaro, J., Drake, J., and W. Henderickx, "BGP MPLS-Based
Ethernet VPN (PBB-EVPN)", RFC 7623, DOI 10.17487/RFC7623, Ethernet VPN", RFC 7432, DOI 10.17487/RFC7432, February
September 2015, <https://www.rfc-editor.org/info/rfc7623>. 2015, <https://www.rfc-editor.org/info/rfc7432>.
[RFC8029] Kompella, K., Swallow, G., Pignataro, C., Ed., Kumar, N., [RFC7623] Sajassi, A., Ed., Salam, S., Bitar, N., Isaac, A., and W.
Aldrin, S., and M. Chen, "Detecting Multiprotocol Label Henderickx, "Provider Backbone Bridging Combined with
Switched (MPLS) Data-Plane Failures", RFC 8029, DOI Ethernet VPN (PBB-EVPN)", RFC 7623, DOI 10.17487/RFC7623,
10.17487/RFC8029, March 2017, <https://www.rfc- September 2015, <https://www.rfc-editor.org/info/rfc7623>.
editor.org/info/rfc8029>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 [RFC8029] Kompella, K., Swallow, G., Pignataro, C., Ed., Kumar, N.,
Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May Aldrin, S., and M. Chen, "Detecting Multiprotocol Label
2017, <http://www.rfc-editor.org/info/rfc8174> Switched (MPLS) Data-Plane Failures", RFC 8029,
DOI 10.17487/RFC8029, March 2017,
<https://www.rfc-editor.org/info/rfc8029>.
Informative References [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[802.1Q] IEEE, "IEEE Standard for Local and metropolitan area 6.2. Informative References
networks - Media Access Control (MAC) Bridges and Virtual
Bridge Local Area Networks", IEEE Std 802.1Q-2014, 2014.
[802.3] IEEE, "IEEE Standard for Ethernet", IEEE Std 802.3-2015, [IEEE-802.1Q]
2015. IEEE, "IEEE Standard for Local and metropolitan area
networks--Bridges and Bridged Networks", IEEE Std 802.1Q-
2014, DOI 10.1109/IEEESTD.2014.6991462, December 2014,
<https://doi.org/10.1109/IEEESTD.2014.6991462>.
[RFC2544] Bradner, S. and J. McQuaid, "Benchmarking Methodology for [IEEE-802.3]
Network Interconnect Devices", RFC 2544, DOI IEEE, "IEEE Standard for Ethernet", IEEE Std 802.3-2018,
10.17487/RFC2544, March 1999, <https://www.rfc- DOI 10.1109/IEEESTD.2018.8457469, August 2018,
editor.org/info/rfc2544>. <https://doi.org/10.1109/IEEESTD.2018.8457469>.
[RFC2681] Almes, G., Kalidindi, S., and M. Zekauskas, "A Round-trip [RFC2544] Bradner, S. and J. McQuaid, "Benchmarking Methodology for
Delay Metric for IPPM", RFC 2681, DOI 10.17487/RFC2681, Network Interconnect Devices", RFC 2544,
September 1999, <https://www.rfc-editor.org/info/rfc2681>. DOI 10.17487/RFC2544, March 1999,
<https://www.rfc-editor.org/info/rfc2544>.
[RFC3393] Demichelis, C. and P. Chimento, "IP Packet Delay Variation [RFC2681] Almes, G., Kalidindi, S., and M. Zekauskas, "A Round-trip
Metric for IP Performance Metrics (IPPM)", RFC 3393, DOI Delay Metric for IPPM", RFC 2681, DOI 10.17487/RFC2681,
10.17487/RFC3393, November 2002, <https://www.rfc- September 1999, <https://www.rfc-editor.org/info/rfc2681>.
editor.org/info/rfc3393>.
[RFC5085] Nadeau, T., Ed., and C. Pignataro, Ed., "Pseudowire Virtual [RFC3393] Demichelis, C. and P. Chimento, "IP Packet Delay Variation
Circuit Connectivity Verification (VCCV): A Control Channel Metric for IP Performance Metrics (IPPM)", RFC 3393,
DOI 10.17487/RFC3393, November 2002,
<https://www.rfc-editor.org/info/rfc3393>.
INTERNET-DRAFT EVPN OAM Requirements/Framework [RFC5085] Nadeau, T., Ed. and C. Pignataro, Ed., "Pseudowire Virtual
Circuit Connectivity Verification (VCCV): A Control
Channel for Pseudowires", RFC 5085, DOI 10.17487/RFC5085,
December 2007, <https://www.rfc-editor.org/info/rfc5085>.
for Pseudowires", RFC 5085, DOI 10.17487/RFC5085, December [RFC6136] Sajassi, A., Ed. and D. Mohan, Ed., "Layer 2 Virtual
2007, <https://www.rfc-editor.org/info/rfc5085>. Private Network (L2VPN) Operations, Administration, and
Maintenance (OAM) Requirements and Framework", RFC 6136,
DOI 10.17487/RFC6136, March 2011,
<https://www.rfc-editor.org/info/rfc6136>.
[RFC6136] Sajassi, A., Ed., and D. Mohan, Ed., "Layer 2 Virtual [RFC6632] Ersue, M., Ed. and B. Claise, "An Overview of the IETF
Private Network (L2VPN) Operations, Administration, and Network Management Standards", RFC 6632,
Maintenance (OAM) Requirements and Framework", RFC 6136, DOI 10.17487/RFC6632, June 2012,
DOI 10.17487/RFC6136, March 2011, <https://www.rfc- <https://www.rfc-editor.org/info/rfc6632>.
editor.org/info/rfc6136>.
[RFC6632] Ersue, M., Ed., and B. Claise, "An Overview of the IETF [RFC6673] Morton, A., "Round-Trip Packet Loss Metrics", RFC 6673,
Network Management Standards", RFC 6632, DOI DOI 10.17487/RFC6673, August 2012,
10.17487/RFC6632, June 2012, <https://www.rfc- <https://www.rfc-editor.org/info/rfc6673>.
editor.org/info/rfc6632>.
[RFC6673] Morton, A., "Round-Trip Packet Loss Metrics", RFC 6673, DOI [RFC7679] Almes, G., Kalidindi, S., Zekauskas, M., and A. Morton,
10.17487/RFC6673, August 2012, <https://www.rfc- Ed., "A One-Way Delay Metric for IP Performance Metrics
editor.org/info/rfc6673>. (IPPM)", STD 81, RFC 7679, DOI 10.17487/RFC7679, January
2016, <https://www.rfc-editor.org/info/rfc7679>.
[RFC7679] Almes, G., Kalidindi, S., Zekauskas, M., and A. Morton, [RFC7680] Almes, G., Kalidindi, S., Zekauskas, M., and A. Morton,
Ed., "A One-Way Delay Metric for IP Performance Metrics Ed., "A One-Way Loss Metric for IP Performance Metrics
(IPPM)", STD 81, RFC 7679, DOI 10.17487/RFC7679, January (IPPM)", STD 82, RFC 7680, DOI 10.17487/RFC7680, January
2016, <https://www.rfc-editor.org/info/rfc7679>. 2016, <https://www.rfc-editor.org/info/rfc7680>.
[RFC7680] Almes, G., Kalidindi, S., Zekauskas, M., and A. Morton, [Y.1731] ITU-T, "Operation, administration and maintenance (OAM)
Ed., "A One-Way Loss Metric for IP Performance Metrics functions and mechanisms for Ethernet-based networks",
(IPPM)", STD 82, RFC 7680, DOI 10.17487/RFC7680, January ITU-T Recommendation G.8013/Y.1731, August 2015.
2016, <https://www.rfc-editor.org/info/rfc7680>.
[Y.1731] "ITU-T Recommendation Y.1731 (02/08) - OAM functions and Acknowledgements
mechanisms for Ethernet based networks", February 2008.
INTERNET-DRAFT EVPN OAM Requirements/Framework The authors would like to thank the following for their review of
this work and their valuable comments: David Black, Martin Duke, Xiao
Min, Gregory Mirsky, Zaheduzzaman Sarker, Dave Schinazi, John
Scudder, Melinda Shore, Robert Wilton, Alexander Vainshtein, Stig
Venaas, and Éric Vyncke.
Authors' Addresses Authors' Addresses
Samer Salam Samer Salam
Cisco Cisco
Email: ssalam@cisco.com Email: ssalam@cisco.com
Ali Sajassi Ali Sajassi
Cisco Cisco
170 West Tasman Drive 170 West Tasman Drive
San Jose, CA 95134, USA San Jose, CA 95134
United States of America
Email: sajassi@cisco.com Email: sajassi@cisco.com
Sam Aldrin Sam Aldrin
Google, Inc. Google, Inc.
1600 Amphitheatre Parkway 1600 Amphitheatre Parkway
Mountain View, CA 94043 USA Mountain View, CA 94043
United States of America
Email: aldrin.ietf@gmail.com Email: aldrin.ietf@gmail.com
John E. Drake John E. Drake
Juniper Networks Juniper Networks
1194 N. Mathilda Ave. 1194 N. Mathilda Ave.
Sunnyvale, CA 94089, USA Sunnyvale, CA 94089
United States of America
Email: jdrake@juniper.net Email: jdrake@juniper.net
Donald E. Eastlake, 3rd Donald E. Eastlake 3rd
Futurewei Technologies Futurewei Technologies
2386 Panoramic Circle 2386 Panoramic Circle
Apopka, FL 32703 USA Apopka, FL 32703
United States of America
Tel: +1-508-333-2270 Phone: +1-508-333-2270
Email: d3e3e3@gmail.com Email: d3e3e3@gmail.com
 End of changes. 180 change blocks. 
544 lines changed or deleted 515 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/