draft-ietf-bess-evpn-oam-req-frmwk-02.txt   draft-ietf-bess-evpn-oam-req-frmwk-03.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: June 31, 2020 January 1, 2020 Expires: January 2, 2021 July 3, 2020
EVPN Operations, Administration and Maintenance EVPN Operations, Administration and Maintenance
Requirements and Framework Requirements and Framework
draft-ietf-bess-evpn-oam-req-frmwk-02 draft-ietf-bess-evpn-oam-req-frmwk-03
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 3, line 17 skipping to change at page 3, line 17
Table of Contents Table of Contents
1. Introduction............................................4 1. Introduction............................................4
1.1 Relationship to Other OAM Work.........................4 1.1 Relationship to Other OAM Work.........................4
1.2 Specification of Requirements..........................5 1.2 Specification of Requirements..........................5
1.3 Terminology............................................5 1.3 Terminology............................................5
2. EVPN OAM Framework......................................6 2. EVPN OAM Framework......................................6
2.1 OAM Layering...........................................6 2.1 OAM Layering...........................................6
2.2 EVPN Service OAM.......................................7 2.2 EVPN Service OAM.......................................7
2.3 EVPN Network OAM.......................................7 2.3 EVPN Network OAM.......................................8
2.4 Transport OAM for EVPN.................................9 2.4 Transport OAM for EVPN.................................9
2.5 Link OAM...............................................9 2.5 Link OAM...............................................9
2.6 OAM Inter-working......................................9 2.6 OAM Inter-working.....................................10
3. EVPN OAM Requirements..................................11 3. EVPN OAM Requirements..................................11
3.1 Fault Management Requirements.........................11 3.1 Fault Management Requirements.........................11
3.1.1 Proactive Fault Management Functions................11 3.1.1 Proactive Fault Management Functions................11
3.1.1.1 Fault Detection (Continuity Check)................11 3.1.1.1 Fault Detection (Continuity Check)................11
3.1.1.2 Defect Indication.................................12 3.1.1.2 Defect Indication.................................12
3.1.1.2.1 Forward Defect Indication.......................12 3.1.1.2.1 Forward Defect Indication.......................12
3.1.1.2.2 Reverse Defect Indication (RDI).................12 3.1.1.2.2 Reverse Defect Indication (RDI).................12
3.1.2 On-Demand Fault Management Functions................13 3.1.2 On-Demand Fault Management Functions................13
3.1.2.1 Connectivity Verification.........................13 3.1.2.1 Connectivity Verification.........................13
skipping to change at page 6, line 50 skipping to change at page 6, line 50
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
PEs but not the 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 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
INTERNET-DRAFT EVPN OAM Requirements/Framework
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, and the OAM mechanisms applicable at are interconnected via EVPN, and the OAM mechanisms applicable at
each layer. The details of the layers are described in the sections each layer. The details of the layers are described in the sections
below. below.
INTERNET-DRAFT EVPN OAM Requirements/Framework
+---+ +---+ +---+ +---+
+--+ | | +---+ +---+ +---+ | | +--+ +--+ | | +---+ +---+ +---+ | | +--+
|CE|----|PE1|----| P |----| P |----| P |----|PE2|----|CE| |CE|----|PE1|----| P |----| P |----| P |----|PE2|----|CE|
+--+ | | +---+ +---+ +---+ | | +--+ +--+ | | +---+ +---+ +---+ | | +--+
+---+ +---+ +---+ +---+
o--------o--------- Service CFM -------------o--------o o--------o--------- Service CFM -------------o--------o
o-------- EVPN Network OAM ---------o o-------- EVPN Network OAM ---------o
skipping to change at page 7, line 38 skipping to change at page 7, line 45
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
core (P) nodes. This is because the PEs operate at the Ethernet MAC core (P) nodes. This is because the PEs operate at the Ethernet MAC
layer in [RFC7432] [RFC7623] whereas the P nodes do not. layer in [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 logically located within the CE
facing port of a PE. Down MEP functions are towards the CE. Up MEP
functions are towards the PE forwarding mechanism. CFM between the PE
Up MEPs is a type of EVPN Network OAM while CFM between the CEs or
from a PE to its local CE or to the remote CE is Service OAM.
INTERNET-DRAFT EVPN OAM Requirements/Framework
+-------+ +---------------+ +---------------+ +-------+
| CE | | PE1 | ... | PE2 | | CE |
+---+---+ +---+--------+--+ +--+--------+---+ +---+---+
| | | | | |
| +----+----+ | | +----+----+ |
+--+--+ | up^ | . . |up^ | +--+--+
| MEP | |MIP|MEP | . ... . |MEP |MIP| | MEP |
|downV| | downV| . . |downV | |downV|
+--+--+ +----+----+ | | +----+----+ +--+--+
| | | | | |
+-----------+ +--- ... ---+ +------------+
Figure 3: CFM Details
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 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
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.
This includes the ability to perform fault detection and diagnostics This includes the ability to perform fault detection and diagnostics
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. Unicast FEC.
skipping to change at page 8, line 29 skipping to change at page 9, line 5
the data plane and verify that operation against the control plane the data plane and verify that operation against the control plane
view. 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, 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.
INTERNET-DRAFT EVPN OAM Requirements/Framework
- 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, and more specifically aggregate inclusive trees, the case of LSM, and more specifically aggregate inclusive trees,
again a label may be allocated per EVI or per <EVI, Ethernet Tag> again a label may be allocated per EVI or per <EVI, Ethernet Tag>
and is bound to the tunnel FEC. 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
skipping to change at page 9, line 5 skipping to change at page 9, line 34
view for the DF filtering function. view for the DF filtering function.
EVPN network OAM mechanisms MUST provide in-band management EVPN network OAM mechanisms MUST provide in-band management
capabilities. As such, OAM messages MUST be encoded so that they capabilities. As such, OAM messages MUST be encoded so that they
exhibit identical entropy characteristics to data traffic. exhibit identical entropy characteristics to data traffic.
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.
INTERNET-DRAFT EVPN OAM Requirements/Framework
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] are applicable, depending on [RFC6425] as well as ICMP [RFC792] are applicable, depending on
whether the PSN employs MPLS or IP transport, respectively. whether the PSN employs MPLS or IP transport, respectively.
Furthermore, BFD mechanisms per [RFC5880], [RFC5881], [RFC5883] and Furthermore, BFD mechanisms per [RFC5880], [RFC5881], [RFC5883] and
[RFC5884] apply. Also, the BFD mechanisms pertaining to MPLS-TP LSPs [RFC5884] apply. Also, the BFD mechanisms pertaining to MPLS-TP LSPs
per [RFC6428] are applicable. 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 [802.3] Clause 57 may be used.
INTERNET-DRAFT EVPN OAM Requirements/Framework
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), at a
PE to detect the failure of an EVI across the EVPN domain. Thus, the PE to detect the failure of an EVI across the EVPN domain. Thus, the
mapping of alarms generated upon failure detection in one domain mapping of alarms generated upon failure detection in one domain
skipping to change at page 10, line 4 skipping to change at page 10, line 37
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
other OAM layers. other OAM layers.
INTERNET-DRAFT EVPN OAM Requirements/Framework 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
skipping to change at page 12, line 23 skipping to change at page 12, line 23
EVPN Service OAM MUST support event-driven defect indication upon the EVPN Service OAM MUST support event-driven defect indication upon the
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 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 3: 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 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 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 4: 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 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 8 skipping to change at page 14, line 8
problems. problems.
- 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
INTERNET-DRAFT EVPN OAM Requirements/Framework INTERNET-DRAFT EVPN OAM Requirements/Framework
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 rest 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 specific port(s) or all the ports in a
given bridge-domain. given bridge-domain.
skipping to change at page 16, line 26 skipping to change at page 16, line 26
- 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:
Gregory Mirsky, Alexander Vainshtein Gregory Mirsky, Alexander Vainshtein, Xiao Min
6. IANA Considerations 6. IANA Considerations
This document requires no IANA actions. This document requires no IANA actions.
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
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
2386 Panoramic Cirlce 2386 Panoramic Circle
Apopka, FL 32703 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. 
22 lines changed or deleted 47 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/