draft-ietf-bess-evpn-oam-req-frmwk-08.txt   draft-ietf-bess-evpn-oam-req-frmwk-09.txt 
INTERNET-DRAFT Samer Salam INTERNET-DRAFT Samer Salam
Intended Status: Informational Ali Sajassi Intended Status: Informational Ali Sajassi
Cisco Cisco
Sam Aldrin Sam Aldrin
Google Google
John E. Drake John E. Drake
Juniper Juniper
Donald Eastlake Donald Eastlake
Futurewei Futurewei
Expires: October 5, 2021 April 6, 2021 Expires: October 11, 2021 April 12, 2021
EVPN Operations, Administration and Maintenance EVPN Operations, Administration and Maintenance
Requirements and Framework Requirements and Framework
draft-ietf-bess-evpn-oam-req-frmwk-08 draft-ietf-bess-evpn-oam-req-frmwk-09
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 (OAM).
The requirements cover the OAM aspects of EVPN and PBB-EVPN (Provider The requirements cover the OAM aspects of EVPN and PBB-EVPN (Provider
Backbone Bridge EVPN). The framework defines the layered OAM model Backbone Bridge 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. the service and network layers.
skipping to change at page 1, line 44 skipping to change at page 1, line 44
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/1id-abstracts.html. The list of Internet-Draft https://www.ietf.org/1id-abstracts.html. The list of Internet-Draft
Shadow Directories can be accessed at http://www.ietf.org/shadow.html Shadow Directories can be accessed at
https://www.ietf.org/shadow.html
INTERNET-DRAFT EVPN OAM Requirements/Framework INTERNET-DRAFT EVPN OAM Requirements/Framework
Copyright and License Notice Copyright and License 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
skipping to change at page 4, line 15 skipping to change at page 4, line 15
INTERNET-DRAFT EVPN OAM Requirements/Framework 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 an 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 multi-homing capabilities, using BGP for
distributing customer/client MAC address reachability information distributing customer/client MAC address reachability information
over the core MPLS/IP network. over the core MPLS/IP network.
PBB-EVPN combines Provider Backbone Bridging (PBB) [802.1Q] with EVPN PBB-EVPN combines Provider Backbone Bridging (PBB) [802.1Q] with EVPN
in order to reduce the number of BGP MAC advertisement routes, in order to reduce the number of BGP MAC advertisement routes,
provide client MAC address mobility using C-MAC aggregation and B-MAC provide client MAC address mobility using C-MAC (Client MAC
sub-netting, confine the scope of C-MAC learning to only active [RFC7623]) aggregation and B-MAC (Backbone MAC [RFC7623]) sub-
flows, offer per site policies, and avoid C-MAC address flushing on netting, confine the scope of C-MAC learning to only active flows,
topology changes. offer per site policies, and avoid C-MAC address flushing on topology
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
skipping to change at page 4, line 53 skipping to change at page 5, line 5
[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 LSPs, including procedures to check the correct operation 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. the control plane.
[802.1Q] specifies the Ethernet Connectivity Fault Management (CFM) [802.1Q] specifies the Ethernet Connectivity Fault Management (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. Intermediate Points.
[Y.1731] extends Connectivity Fault Management in the following
areas: it defines fault notification and alarm suppression functions
INTERNET-DRAFT EVPN OAM Requirements/Framework INTERNET-DRAFT EVPN OAM Requirements/Framework
[Y.1731] extends Connectivity Fault Management in the following
areas: it defines fault notification and alarm suppression functions
for Ethernet. It also specifies mechanisms for Ethernet performance for Ethernet. It also 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 BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all 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 This document uses the following terminology much of which is defined
in [RFC6136]: in [RFC6136]:
CE Customer Edge device, e.g., a host, router, or switch. CE Customer Edge device, e.g., a host, router, or switch.
DF Designated Forwarder CFM Connectivity Fault Management [802.1Q].
DF Designated Forwarder [RFC7432].
Down MEP A MEP that originates traffic away from and terminates Down MEP A MEP that originates traffic away from and terminates
traffic towards the device in whose port it is logically traffic towards the core of the device in whose port it is
located. logically located.
EVI An EVPN instance spanning the Provider Edge (PE) devices EVI An EVPN instance spanning the Provider Edge (PE) devices
participating in that EVPN. participating in that EVPN [RFC7432].
L2VPN Layer 2 VPN. L2VPN Layer 2 VPN.
MA Maintenance Association is a set of MEPs belonging to the same MA Maintenance Association is a set of MEPs belonging to the same
Maintenance Domain, established to verify the integrity of a Maintenance Domain (MD), established to verify the integrity of
single service instance. a single service instance [802.1Q].
MD Maintenance Domain, an OAM Domain that represents a region over
which OAM frames can operate unobstructed [802.1Q].
MEP Maintenance End Point is responsible for origination and MEP Maintenance End Point is responsible for origination and
termination of OAM frames for a given MA. A MEP is logically termination of OAM frames for a given MA. A MEP is logically
located in a device's port. located in a device's port [802.1Q].
MIP Maintenance Intermediate Point is located between peer MEPs and MIP Maintenance Intermediate Point 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.
MD Maintenance Domain, an OAM Domain that represents a region over INTERNET-DRAFT EVPN OAM Requirements/Framework
which OAM frames can operate unobstructed.
can process and respond to certain OAM frames but does not
initiate them. A MIP is logically located in a device's port
[802.1Q].
MP2P Multipoint to Point. MP2P Multipoint to Point.
INTERNET-DRAFT EVPN OAM Requirements/Framework NMS Network Management Station [RFC6632].
P Provider (non-edge) device. P Provider network interior (non-edge) node.
P2MP Point to Multipoint. P2MP Point to Multipoint.
PBB Provider Backbone Bridge. PBB Provider Backbone Bridge [RFC7623].
PE Provider Edge device. PE Provider network Edge device.
Up MEP A MEP that originates traffic towards and terminates traffic Up MEP A MEP that originates traffic towards and terminates traffic
from the device in whose port it is logically located. from the core of the device in whose port it is logically
located.
VPN Virtual Private Network VPN Virtual Private Network
INTERNET-DRAFT EVPN OAM Requirements/Framework INTERNET-DRAFT EVPN OAM Requirements/Framework
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 this
document is the Service and Network layers. 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) nodes
and is mostly transparent to the core P (Provider) nodes (except and is mostly transparent to the P (Provider network interior)
where Flow Entropy comes into play). It leverages MPLS for service nodes (except where Flow Entropy comes into play). It leverages
(i.e., EVI) multiplexing and Split-Horizon functions. MPLS for service (i.e., EVI) multiplexing and Split-Horizon
functions.
- The Transport Layer is dictated by the networking technology of the - The Transport Layer is dictated by the networking technology of the
PSN. It may be either based on MPLS LSPs or IP. PSN. It may be either based on 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 alternatives
are deployed (e.g., POS, DWDM etc.). are deployed (e.g., POS, 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. Figure 1
below depicts the OAM layering, and shows which devices have below depicts the OAM layering, and shows which devices have
visibility into what OAM layer(s). visibility into what OAM layer(s).
+---+ +---+ +---+ +---+
+--+ | | +---+ +---+ +---+ | | +--+ +--+ | | +---+ +---+ +---+ | | +--+
|CE|----|PE1|----| P |----| P |----| P |----|PE2|----|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 nodes (Provider network interior (Provider Edge) nodes but not the P (Provider interior) nodes. As
nodes). As such, they can be used to deduce whether the fault is in such, they can be used to deduce whether the fault is in the
the customer's own network, the local CE-PE segment, the PE-PE
INTERNET-DRAFT EVPN OAM Requirements/Framework INTERNET-DRAFT EVPN OAM Requirements/Framework
segment or the remote CE-PE segment(s). EVPN Transport OAM mechanisms customer's own network, the local CE-PE segment, the PE-PE segment or
can be used for fault isolation between the PEs and P nodes. 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 native Ethernet domains
are interconnected via EVPN using MPLS and gives the OAM mechanisms are interconnected via EVPN using MPLS and gives the OAM mechanisms
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. the sections below.
+---+ +---+ +---+ +---+
+--+ | | +---+ +---+ +---+ | | +--+ +--+ | | +---+ +---+ +---+ | | +--+
|CE|----|PE1|----| P |----| P |----| P |----|PE2|----|CE| |CE|----|PE |----| P |----| P |----| P |----|PE |----|CE|
+--+ | | +---+ +---+ +---+ | | +--+ +--+ | | +---+ +---+ +---+ | | +--+
+---+ +---+ +---+ +---+
o--------o---------- Service CFM ------------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
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 case of
[RFC7432] and [RFC7623], the service layer is Ethernet; hence, the [RFC7432] and [RFC7623], the service layer is Ethernet; hence, the
corresponding service OAM protocol is Ethernet Connectivity Fault corresponding service OAM protocol is Ethernet Connectivity Fault
Management (CFM) [802.1Q]. Management (CFM) [802.1Q].
EVPN service OAM is visible to the CEs and EVPN PEs, but not to the EVPN service OAM is visible to the CEs and EVPN PEs, but not to the P
core (P) nodes. This is because the PEs operate at the Ethernet MAC nodes. This is because the PEs operate at the Ethernet MAC layer in
layer in [RFC7432] [RFC7623] whereas the P nodes do not. [RFC7432] [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 device while up MEP functions are towards
INTERNET-DRAFT EVPN OAM Requirements/Framework INTERNET-DRAFT EVPN OAM Requirements/Framework
the device (towards the PE forwarding mechanism in the case of a PE). functions are away from the core of the device while up MEP functions
OAM messages between the PE Up MEPs shown are a type of EVPN Network are towards the core of the device (towards the PE forwarding
OAM while such messages between the CEs or from a PE to its local CE mechanism in the case of a PE). OAM messages between the PE Up MEPs
or to the remote CE are Service OAM. 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.
+-------+ +----------------+ +----------------+ +-------+ +-------+ +----------------+ +----------------+ +-------+
|+-----+| |+--------------+| |+--------------+| |+-----+| |+-----+| |+--------------+| |+--------------+| |+-----+|
|| CE || || PE1 || ... || PE2 || || 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 learn the MAC address of locally attached CE MEPs by The EVPN PE MUST, by default, learn the MAC address of locally
snooping on CFM frames and advertising them to remote PEs as a MAC/IP attached CE MEPs by snooping on CFM frames and advertising them to
Advertisement route. 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.
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 Section
15.2 of [RFC7432]). 15.2 of [RFC7432]).
2.3 EVPN Network OAM 2.3 EVPN Network OAM
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 [RFC5085] in the case of VPLS/VPWS. It provides analogous to VCCV [RFC5085] in the case of VPLS/VPWS. It provides
skipping to change at page 9, line 54 skipping to change at page 10, line 5
on: on:
- the MP2P tunnels used for the transport of unicast traffic between - the MP2P tunnels used for the transport of unicast 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 <ESI, Ethernet Tag> and 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 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 FEC. EVPN Network OAM MUST 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. control plane view.
- the MP2P tunnels used for aliasing unicast traffic destined to a
INTERNET-DRAFT EVPN OAM Requirements/Framework INTERNET-DRAFT EVPN OAM Requirements/Framework
- the MP2P tunnels used for aliasing unicast traffic destined to a
multi-homed 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 MUST provide
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. 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. 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 <EVI, Ethernet Tag> and is bound to an EVPN Multicast FEC. In per <EVI, Ethernet Tag> and is bound to an EVPN Multicast FEC. In
the case of LSM (Label Switched Multicast), and more specifically the case of LSM (Label Switched Multicast), 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 <EVI, Ethernet Tag> and is bound to the tunnel FEC. 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 ESI split-horizon filtering function.
In EVPN, a label is allocated per multi-homed Ethernet Segment for In EVPN, a label is allocated per multi-homed 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. label is bound to an EVPN Ethernet Segment.
- the correct operation of the DF (Designated Forwarder) filtering - the correct operation of the DF (Designated Forwarder [RFC7432])
function. EVPN Network OAM MUST provide mechanisms to check the filtering function. EVPN Network OAM MUST provide mechanisms to
operation of the data plane and verify that operation against the check the operation of the data plane and verify that operation
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. As such, OAM messages MUST be encoded so that they capabilities. OAM messages SHOULD be encoded so that they exhibit
exhibit identical entropy characteristics to data traffic in order similar entropy characteristics to data traffic in order to maximize
that they share the same fate. the fate sharing between OAM and data.
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 The transport OAM protocol depends on the nature of the underlying
transport technology in the PSN. MPLS OAM mechanisms [RFC8029] transport technology in the PSN. MPLS OAM mechanisms [RFC8029]
[RFC6425] as well as ICMP [RFC792] / ICMPv6 [RFC4443] are applicable, [RFC6425] as well as ICMP [RFC792] / ICMPv6 [RFC4443] are applicable,
skipping to change at page 11, line 20 skipping to change at page 11, line 20
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 ([802.3] Clause 57) may be used.
2.6 OAM Inter-working 2.6 OAM Inter-working
When inter-working two networking domains, such as native Ethernet When inter-working two networking domains, such as native 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 running proactive
monitoring, such as Ethernet Continuity Check Messages (CCMs), at a monitoring, such as Ethernet Continuity Check Messages (CCMs
PE to detect the failure of an EVI across the EVPN domain. Thus, the [802.1Q]), at a PE to detect the failure of an EVI across the EVPN
mapping of alarms generated upon failure detection in one domain domain. Thus, the mapping of alarms generated upon failure detection
(e.g., native Ethernet or EVPN network domain) to the other domain is in one domain (e.g., native Ethernet or EVPN network domain) to the
needed. There are also cases where a PE may not be able to process other domain is needed. There are also cases where a PE may not be
Service OAM messages received from a remote PE over the PSN even when able to process Service OAM messages received from a remote PE over
such messages are defined, as in the Ethernet case, thereby the PSN even when such messages are defined, as in the Ethernet case,
necessitating support for fault notification message mapping between thereby necessitating support for fault notification message mapping
the EVPN Network domain and the Service domain. between the EVPN Network domain and the Service domain.
OAM inter-working is not limited though to scenarios involving OAM inter-working 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 inter-
working across different layers in the same network domain. In working 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 client
layer OAM mechanisms. This allows the client layer OAM to trigger layer OAM mechanisms. This allows the client layer OAM to trigger
event-driven (i.e., asynchronous) fault notifications. For example, event-driven (i.e., asynchronous) fault notifications. For example,
alarms generated by the Link OAM mechanisms may be injected into the alarms generated by the Link OAM mechanisms may be injected into the
Transport OAM layer, and alarms generated by the Transport OAM Transport OAM layer, and alarms generated by the Transport OAM
skipping to change at page 12, line 26 skipping to change at page 12, line 26
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 without a time bound. 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. 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 endpoints, i.e., MEPs in a given MA,
through the exchange of Continuity Check messages. The reachability through the exchange of Continuity Check Messages [802.1Q]. The
between any two arbitrary MEPs may be monitored for: reachability between any two arbitrary MEPs may be monitored for:
- in-band per-flow monitoring. This enables per flow monitoring - in-band per-flow monitoring. This enables per flow monitoring
between MEPs. EVPN Network OAM MUST support fault detection with between MEPs. EVPN Network OAM MUST support fault detection with
per user flow granularity. EVPN Service OAM MAY support fault per user flow granularity. EVPN Service OAM MAY support fault
detection with per user flow granularity. detection with per user flow granularity.
- a representative path. This enables liveness check of the nodes - a representative path. This enables liveness check of the nodes
hosting the MEPs assuming that the loss of continuity to the MEP is hosting the MEPs assuming that the loss of continuity 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
skipping to change at page 12, line 50 skipping to change at page 13, line 5
and Service OAM MUST support fault detection using test flows. and Service OAM MUST support fault detection using test flows.
- all paths. For MPLS/IP networks with ECMP, monitoring of all - all paths. For MPLS/IP networks with ECMP, monitoring of all
unicast paths between MEPs (on non-adjacent nodes) may not be unicast paths between MEPs (on non-adjacent nodes) may not be
possible, since the per-hop ECMP hashing behavior may yield possible, since the per-hop ECMP hashing behavior may yield
situations where it is impossible for a MEP to pick flow entropy situations where it is impossible for a MEP to pick flow entropy
characteristics that result in exercising the exhaustive set of characteristics that result in exercising the exhaustive set of
ECMP paths. Monitoring of all ECMP paths between MEPs (on non- ECMP paths. Monitoring of all ECMP paths between MEPs (on non-
adjacent nodes) is not a requirement for EVPN OAM. adjacent nodes) is not a requirement for EVPN OAM.
The fact that MPLS/IP networks do not enforce congruency between
INTERNET-DRAFT EVPN OAM Requirements/Framework INTERNET-DRAFT EVPN OAM Requirements/Framework
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 defect indications as described below. EVPN Service OAM MUST
support at least one of these types of event-driven defect indication support at least one of these types of event-driven defect indication
upon the detection of a connectivity defect. upon the detection of a connectivity defect.
3.1.1.2.1 Forward Defect Indication 3.1.1.2.1 Forward Defect Indication
This is used to signal a failure that is detected by a lower layer This 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 that is away
from the direction of the failure (refer to Figure 4 below). from the direction of 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
skipping to change at page 14, line 13 skipping to change at page 14, line 13
support Forward Defect Indication in the Service OAM mechanisms. support Forward Defect Indication in the Service OAM mechanisms.
INTERNET-DRAFT EVPN OAM Requirements/Framework 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 loss of
continuity (LoC) defect. RDI is transmitted in the direction of the continuity (LoC) defect. RDI is transmitted in the direction of the
failure (refer to Figure 5). failure (refer to 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
skipping to change at page 14, line 50 skipping to change at page 14, line 50
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 in the messages:
- variable length payload/padding to test MTU related connectivity - variable length payload/padding to test MTU (Maximum Transmission
problems. Unit) related connectivity problems.
INTERNET-DRAFT EVPN OAM Requirements/Framework INTERNET-DRAFT EVPN OAM Requirements/Framework
- 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).
skipping to change at page 15, line 38 skipping to change at page 15, line 38
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/reverse
path asymmetry, in MPLS/IP, makes fault isolation a direction- 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/IP P nodes. As such, they can be used to deduce whether the the MPLS or IP P nodes. As such, they can be used to deduce whether
fault is in the customer's own network, the local CE-PE segment or the fault is in the customer's own network, the local CE-PE segment
remote CE-PE segment(s). EVPN Network and Transport OAM mechanisms or remote CE-PE segment(s). EVPN Network and Transport OAM mechanisms
can be used for fault isolation between the PEs and P nodes. 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 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 [RFC7680] [RFC6673]. for a given service, for example [RFC7680] [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, then packet loss cannot be accurately
measured by means of counting user data packets. This is because user measured by means of counting user data packets. This is because user
packets can be delivered to more PEs or more ports than are necessary packets can be delivered to more PEs or more ports than are necessary
(e.g., due to broadcast, un-pruned multicast or unknown unicast (e.g., due to broadcast, un-pruned multicast or unknown unicast
flooding). As such, a statistical means of approximating packet loss flooding). As such, a statistical means of approximating packet loss
rate is required. This can be achieved by sending "synthetic" OAM rate is required. This can be achieved by sending "synthetic" OAM
packets that are counted only by those ports (MEPs) that are required packets that are counted only by those ports (MEPs) that are required
to receive them. This provides a statistical approximation of the to 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
skipping to change at page 17, line 33 skipping to change at page 17, line 33
5. IANA Considerations 5. IANA Considerations
This document requires no IANA actions. This document requires no IANA actions.
6. Acknowledgements 6. Acknowledgements
The authors would like to thank the following for their review of The authors would like to thank the following for their review of
this work and valuable comments: this work and valuable comments:
David Black, Martin Duke, Xiao Min, Gregory Mirsky, Dave Schinazi, David Black, Martin Duke, Xiao Min, Gregory Mirsky,
Melinda Shore, Alexander Vainshtein, and Stig Venaas. Zaheduzzaman Sarker, Dave Schinazi, John Scudder, Melinda Shore,
Robert Wilton, Alexander Vainshtein, Stig Venaas, and Eric Vyncke.
INTERNET-DRAFT EVPN OAM Requirements/Framework INTERNET-DRAFT EVPN OAM Requirements/Framework
Normative References Normative References
[RFC792] Postel, J., "Internet Control Message Protocol", STD 5, RFC [RFC792] Postel, J., "Internet Control Message Protocol", STD 5, RFC
792, DOI 10.17487/RFC0792, September 1981, 792, DOI 10.17487/RFC0792, September 1981,
<https://www.rfc-editor.org/info/rfc792>. <https://www.rfc-editor.org/info/rfc792>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
skipping to change at page 19, line 32 skipping to change at page 19, line 32
Switched (MPLS) Data-Plane Failures", RFC 8029, DOI Switched (MPLS) Data-Plane Failures", RFC 8029, DOI
10.17487/RFC8029, March 2017, <https://www.rfc- 10.17487/RFC8029, March 2017, <https://www.rfc-
editor.org/info/rfc8029>. editor.org/info/rfc8029>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119
Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May
2017, <http://www.rfc-editor.org/info/rfc8174> 2017, <http://www.rfc-editor.org/info/rfc8174>
Informative References Informative References
[802.1Q] "IEEE Standard for Local and metropolitan area networks - [802.1Q] IEEE, "IEEE Standard for Local and metropolitan area
Media Access Control (MAC) Bridges and Virtual Bridge Local networks - Media Access Control (MAC) Bridges and Virtual
Area Networks", 2014. Bridge Local Area Networks", IEEE Std 802.1Q-2014, 2014.
[Y.1731] "ITU-T Recommendation Y.1731 (02/08) - OAM functions and [802.3] IEEE, "IEEE Standard for Ethernet", IEEE Std 802.3-2015,
mechanisms for Ethernet based networks", February 2008. 2015.
[RFC2544] Bradner, S. and J. McQuaid, "Benchmarking Methodology for [RFC2544] Bradner, S. and J. McQuaid, "Benchmarking Methodology for
Network Interconnect Devices", RFC 2544, DOI Network Interconnect Devices", RFC 2544, DOI
10.17487/RFC2544, March 1999, <https://www.rfc- 10.17487/RFC2544, March 1999, <https://www.rfc-
editor.org/info/rfc2544>. editor.org/info/rfc2544>.
[RFC2681] Almes, G., Kalidindi, S., and M. Zekauskas, "A Round-trip [RFC2681] Almes, G., Kalidindi, S., and M. Zekauskas, "A Round-trip
Delay Metric for IPPM", RFC 2681, DOI 10.17487/RFC2681, Delay Metric for IPPM", RFC 2681, DOI 10.17487/RFC2681,
September 1999, <https://www.rfc-editor.org/info/rfc2681>. September 1999, <https://www.rfc-editor.org/info/rfc2681>.
skipping to change at page 20, line 16 skipping to change at page 20, line 16
for Pseudowires", RFC 5085, DOI 10.17487/RFC5085, December for Pseudowires", RFC 5085, DOI 10.17487/RFC5085, December
2007, <https://www.rfc-editor.org/info/rfc5085>. 2007, <https://www.rfc-editor.org/info/rfc5085>.
[RFC6136] Sajassi, A., Ed., and D. Mohan, Ed., "Layer 2 Virtual [RFC6136] Sajassi, A., Ed., and D. Mohan, Ed., "Layer 2 Virtual
Private Network (L2VPN) Operations, Administration, and Private Network (L2VPN) Operations, Administration, and
Maintenance (OAM) Requirements and Framework", RFC 6136, Maintenance (OAM) Requirements and Framework", RFC 6136,
DOI 10.17487/RFC6136, March 2011, <https://www.rfc- DOI 10.17487/RFC6136, March 2011, <https://www.rfc-
editor.org/info/rfc6136>. editor.org/info/rfc6136>.
[RFC6632] Ersue, M., Ed., and B. Claise, "An Overview of the IETF
Network Management Standards", RFC 6632, DOI
10.17487/RFC6632, June 2012, <https://www.rfc-
editor.org/info/rfc6632>.
[RFC6673] Morton, A., "Round-Trip Packet Loss Metrics", RFC 6673, DOI [RFC6673] Morton, A., "Round-Trip Packet Loss Metrics", RFC 6673, DOI
10.17487/RFC6673, August 2012, <https://www.rfc- 10.17487/RFC6673, August 2012, <https://www.rfc-
editor.org/info/rfc6673>. editor.org/info/rfc6673>.
[RFC7679] Almes, G., Kalidindi, S., Zekauskas, M., and A. Morton, [RFC7679] Almes, G., Kalidindi, S., Zekauskas, M., and A. Morton,
Ed., "A One-Way Delay Metric for IP Performance Metrics Ed., "A One-Way Delay Metric for IP Performance Metrics
(IPPM)", STD 81, RFC 7679, DOI 10.17487/RFC7679, January (IPPM)", STD 81, RFC 7679, DOI 10.17487/RFC7679, January
2016, <https://www.rfc-editor.org/info/rfc7679>. 2016, <https://www.rfc-editor.org/info/rfc7679>.
[RFC7680] Almes, G., Kalidindi, S., Zekauskas, M., and A. Morton, [RFC7680] Almes, G., Kalidindi, S., Zekauskas, M., and A. Morton,
Ed., "A One-Way Loss Metric for IP Performance Metrics Ed., "A One-Way Loss Metric for IP Performance Metrics
(IPPM)", STD 82, RFC 7680, DOI 10.17487/RFC7680, January (IPPM)", STD 82, RFC 7680, DOI 10.17487/RFC7680, January
2016, <https://www.rfc-editor.org/info/rfc7680>. 2016, <https://www.rfc-editor.org/info/rfc7680>.
[Y.1731] "ITU-T Recommendation Y.1731 (02/08) - OAM functions and
mechanisms for Ethernet based networks", February 2008.
INTERNET-DRAFT EVPN OAM Requirements/Framework INTERNET-DRAFT EVPN OAM Requirements/Framework
Authors' Addresses Authors' Addresses
Samer Salam Samer Salam
Cisco Cisco
Email: ssalam@cisco.com Email: ssalam@cisco.com
Ali Sajassi Ali Sajassi
 End of changes. 53 change blocks. 
94 lines changed or deleted 111 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/