draft-ietf-bess-evpn-oam-req-frmwk-01.txt   draft-ietf-bess-evpn-oam-req-frmwk-02.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: January 7, 2020 July 8, 2019 Expires: June 31, 2020 January 1, 2020
EVPN Operations, Administration and Maintenance EVPN Operations, Administration and Maintenance
Requirements and Framework Requirements and Framework
draft-ietf-bess-evpn-oam-req-frmwk-01 draft-ietf-bess-evpn-oam-req-frmwk-02
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. The The requirements cover the OAM aspects of EVPN and PBB-EVPN. The
framework defines the layered OAM model encompassing the EVPN service framework defines the layered OAM model encompassing the EVPN service
layer, network layer and underlying Packet Switched Network (PSN) layer, network layer and underlying Packet Switched Network (PSN)
transport layer. transport layer.
skipping to change at page 1, line 48 skipping to change at page 1, line 48
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 http://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 http://www.ietf.org/shadow.html
Copyright and License Notice Copyright and License Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2020 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
INTERNET-DRAFT EVPN OAM Requirements/Framework INTERNET-DRAFT EVPN OAM Requirements/Framework
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 (http://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
skipping to change at page 5, line 18 skipping to change at page 5, line 18
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119] [RFC8174] document are to be interpreted as described in [RFC2119] [RFC8174]
when, and only when, they appear in all capitals, as shown here. when, and only when, they appear in all capitals, as shown here.
1.3 Terminology 1.3 Terminology
This document uses the following terminology defined in [RFC6136]: This document uses the following terminology defined in [RFC6136]:
CE Customer Edge device, e.g., a host, router, or switch.
DF Designated Forwarder
EVI An EVPN instance spanning the Provider Edge (PE) devices
participating in that EVPN.
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, established to verify the integrity of a
single service instance. single service instance.
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. termination of OAM frames for a given MA.
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 can process and respond to certain OAM frames but does not
initiate them. initiate them.
MD Maintenance Domain, an OAM Domain that represents a region over MD Maintenance Domain, an OAM Domain that represents a region over
which OAM frames can operate unobstructed. which OAM frames can operate unobstructed.
MP2P Multipoint to Point.
P2MP Point to Multipoint.
PE Provider Edge device.
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: using the EVPN family of solutions:
- 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 in between the EVPN PE nodes and is - The Network Layer extends between the EVPN PE nodes and is mostly
mostly transparent to the core nodes (except where Flow Entropy transparent to the core nodes (except where Flow Entropy comes into
comes into play). It leverages MPLS for service (i.e. EVI) play). It leverages MPLS for service (i.e. EVI) multiplexing and
multiplexing and Split-Horizon functions. 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. The in the ongoing maintenance and diagnostics of EVPN networks. The
skipping to change at page 7, line 46 skipping to change at page 7, line 46
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.
The EVPN PE MUST learn the MAC address of locally attached CE MEPs by The EVPN PE MUST learn the MAC address of locally attached CE MEPs by
snooping on CFM frames and advertising them to remote PEs as a MAC/IP snooping on CFM frames and advertising them to remote PEs as a MAC/IP
Advertisement route. Advertisement route.
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 stick bit set (see Section 15.2 of SHOULD be advertised with the static (sticky) bit set (see Section
[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
INTERNET-DRAFT EVPN OAM Requirements/Framework INTERNET-DRAFT EVPN OAM Requirements/Framework
mechanisms to check the correct operation of the data plane, as well mechanisms to check the correct operation of the data plane, as well
as a mechanism to verify the data plane against the control plane. as a mechanism to verify the data plane against the control plane.
skipping to change at page 9, line 43 skipping to change at page 9, line 43
(e.g. native Ethernet or EVPN network domain) to the other domain is (e.g. native Ethernet or EVPN network domain) to the other domain is
needed. There are also cases where a PE may not be able to process needed. There are also cases where a PE may not be able to process
Service OAM messages received from a remote PE over the PSN even when Service OAM messages received from a remote PE over the PSN even when
such messages are defined, as in the Ethernet case, thereby such messages are defined, as in the Ethernet case, thereby
necessitating support for fault notification message mapping between necessitating support for fault notification message mapping between
the EVPN Network domain and the Service domain. 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
mechanism may be injected into the Network OAM mechanism, and so on. 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 inter-working between the Network OAM and
Service OAM mechanisms. EVPN OAM MAY support inter-working among Service OAM mechanisms. EVPN OAM MAY support inter-working among
INTERNET-DRAFT EVPN OAM Requirements/Framework INTERNET-DRAFT EVPN OAM Requirements/Framework
other OAM layers. other OAM layers.
skipping to change at page 11, line 25 skipping to change at page 11, line 25
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. The reachability
between any two arbitrary MEPs may be monitored for: 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
skipping to change at page 12, line 25 skipping to change at page 12, line 25
detection of a connectivity defect. Defect indications can be detection of a connectivity defect. Defect indications can be
categorized into two types: forward and reverse defect indications. categorized into two types: forward and reverse defect indications.
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) transmits OAM mechanism. A server MEP (i.e. an actual or virtual MEP) transmits
a Forward Defect Indication in a direction that is away from the a Forward Defect Indication in a direction that is away from the
direction of the failure (refer to Figure 3 below). direction of the failure (refer to Figure 3 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 3: Forward Defect Indication Figure 3: 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 purpose of inter-working with other layer OAM protocols. Alarm
suppression is useful when a transport/network level fault translates suppression is useful when a transport/network level fault translates
to multiple service or flow level faults. In such a scenario, it is to multiple service or flow level faults. In such a scenario, it is
enough to alert a network management station (NMS) of the single enough to alert a network management station (NMS) of the single
transport/network level fault in lieu of flooding that NMS with a transport/network level fault in lieu of flooding that NMS with a
multitude of Service or Flow granularity alarms. EVPN PEs SHOULD multitude of Service or Flow granularity alarms. EVPN PEs SHOULD
support Forward Defect Indication in the Service OAM mechanisms. support Forward Defect Indication in the Service OAM mechanisms.
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
INTERNET-DRAFT EVPN OAM Requirements/Framework INTERNET-DRAFT EVPN OAM Requirements/Framework
failure (refer to Figure 4). failure (refer to Figure 4).
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 4: Reverse Defect Indication Figure 4: 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 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.
skipping to change at page 14, line 28 skipping to change at page 14, line 28
given bridge-domain. given bridge-domain.
- the Split Horizon filtering status of specific port(s) or all the - the Split Horizon filtering status of specific port(s) or all the
ports in a given bridge-domain. 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/reverse
path asymmetry, in MPLS/IP, renders fault isolation into 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/IP P nodes. As such, they can be used to deduce whether the
fault is in the customer's own network, the local CE-PE segment or 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 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.
skipping to change at page 16, line 14 skipping to change at page 16, line 14
INTERNET-DRAFT EVPN OAM Requirements/Framework INTERNET-DRAFT EVPN OAM Requirements/Framework
4. Security Considerations 4. Security Considerations
EVPN OAM must provide mechanisms for: EVPN OAM must provide mechanisms for:
- Preventing denial of service attacks caused by exploitation of the - Preventing denial of service attacks caused by exploitation of the
OAM message channel. OAM message channel.
- Optionally authenticate communicating endpoints (MEPs and MIPs) - Optionally authenticate communicating endpoints (MEPs and MIPs).
- Preventing OAM packets from leaking outside of the EVPN network or - Preventing OAM packets from leaking outside of the EVPN network or
outside their corresponding Maintenance Domain. This can be done by outside their corresponding Maintenance Domain. This can be done by
having MEPs implement a filtering function based on the Maintenance having MEPs implement a filtering function based on the Maintenance
Level associated with received OAM packets. Level associated with received OAM packets.
5. Acknowledgements 5. 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:
skipping to change at page 19, line 37 skipping to change at page 19, line 37
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, USA
Email: jdrake@juniper.net Email: jdrake@juniper.net
Donald E. Eastlake, 3rd Donald E. Eastlake, 3rd
Futurewei Technologies Futurewei Technologies
1424 Pro Shop Court 2386 Panoramic Cirlce
Davenport, FL 33896 USA Apopka, FL 32703 USA
Tel: +1-508-333-2270 Tel: +1-508-333-2270
Email: d3e3e3@gmail.com Email: d3e3e3@gmail.com
 End of changes. 19 change blocks. 
36 lines changed or deleted 49 lines changed or added

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