draft-ietf-bess-evpn-oam-req-frmwk-06.txt   draft-ietf-bess-evpn-oam-req-frmwk-07.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: September 18, 2021 March 19, 2021 Expires: September 26, 2021 March 27, 2021
EVPN Operations, Administration and Maintenance EVPN Operations, Administration and Maintenance
Requirements and Framework Requirements and Framework
draft-ietf-bess-evpn-oam-req-frmwk-06 draft-ietf-bess-evpn-oam-req-frmwk-07
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 3, line 19 skipping to change at page 3, line 19
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......................................7 2. EVPN OAM Framework......................................7
2.1 OAM Layering...........................................7 2.1 OAM Layering...........................................7
2.2 EVPN Service OAM.......................................8 2.2 EVPN Service OAM.......................................8
2.3 EVPN Network OAM.......................................9 2.3 EVPN Network OAM.......................................9
2.4 Transport OAM for EVPN................................10 2.4 Transport OAM for EVPN................................10
2.5 Link OAM..............................................10 2.5 Link OAM..............................................11
2.6 OAM Inter-working.....................................11 2.6 OAM Inter-working.....................................11
3. EVPN OAM Requirements..................................12 3. EVPN OAM Requirements..................................12
3.1 Fault Management Requirements.........................12 3.1 Fault Management Requirements.........................12
3.1.1 Proactive Fault Management Functions................12 3.1.1 Proactive Fault Management Functions................12
3.1.1.1 Fault Detection (Continuity Check)................12 3.1.1.1 Fault Detection (Continuity Check)................12
3.1.1.2 Defect Indication.................................13 3.1.1.2 Defect Indication.................................13
3.1.1.2.1 Forward Defect Indication.......................13 3.1.1.2.1 Forward Defect Indication.......................13
3.1.1.2.2 Reverse Defect Indication (RDI).................13 3.1.1.2.2 Reverse Defect Indication (RDI).................13
3.1.2 On-Demand Fault Management Functions................14 3.1.2 On-Demand Fault Management Functions................14
3.1.2.1 Connectivity Verification.........................14 3.1.2.1 Connectivity Verification.........................14
3.1.2.2 Fault Isolation...................................15 3.1.2.2 Fault Isolation...................................15
3.2 Performance Management................................15 3.2 Performance Management................................15
3.2.1 Packet Loss.........................................15 3.2.1 Packet Loss.........................................15
3.2.2 Packet Delay........................................16 3.2.2 Packet Delay and Jitter.............................16
4. Security Considerations................................17 4. Security Considerations................................17
5. IANA Considerations....................................17 5. IANA Considerations....................................17
6. Acknowledgements.......................................17 6. Acknowledgements.......................................17
Normative References......................................18 Normative References......................................18
Informative References....................................19 Informative References....................................19
Authors' Addresses........................................20
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].
skipping to change at page 5, line 28 skipping to change at page 5, line 28
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 DF Designated Forwarder
Down MEP A MEP that originates traffic away from and terminates
traffic towards the device in whose port it is 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.
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, 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. A MEP is logically
located in a device's port.
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. A MIP is logically located in a device's port.
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. MP2P Multipoint to Point.
INTERNET-DRAFT EVPN OAM Requirements/Framework
P Provider (non-edge) device. P Provider (non-edge) device.
P2MP Point to Multipoint. P2MP Point to Multipoint.
INTERNET-DRAFT EVPN OAM Requirements/Framework
PBB Provider Backbone Bridge. PBB Provider Backbone Bridge.
PE Provider Edge device. PE Provider Edge device.
Up MEP A MEP that originates traffic towards and terminates traffic
from 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
skipping to change at page 8, line 46 skipping to change at page 8, line 46
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. As shown in Figure 3, the MIP and MEP Up and Down MEP functions.
functions being referred to are logically located within the CE
facing port of a PE. Down MEP functions are towards the CE. Up MEP As shown in Figure 3, the MIP and MEP functions being referred to are
functions are towards the PE forwarding mechanism. CFM between the PE logically located within the device's port operating at the customer
Up MEPs is a type of EVPN Network OAM while CFM between the CEs or level. (There could be MEPs/MIPs within PE ports facing the provider
from a PE to its local CE or to the remote CE is Service OAM. network but they would not be relevant to EVPN Service OAM as the
traffic passing through them will be encapsulated/tunneled so any
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).
| CE | | PE1 | ... | PE2 | | CE | OAM messages between the PE Up MEPs 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.
| +----+----+ | | +----+----+ |
+--+--+ | | up^ | . . |up^ | | +--+--+ +-------+ +----------------+ +----------------+ +-------+
| MEP | |MIP|MEP | . ... . |MEP |MIP| | MEP | |+-----+| |+--------------+| |+--------------+| |+-----+|
|downV| | |downV| . . |downV| | |downV| || CE || || PE1 || ... || PE2 || || CE ||
+--+--+ +----+----+ | | +----+----+ +--+--+ |+--+--+| |+---+--------+-+| |+-+--------+---+| |+--+--+|
| | | | | | | | | | | | | | | | | | | |
+-----------+ +--- ... ---+ +------------+ |+--+--+| |+---+-----+ . | | . +-----+---+| |+--+--+|
|| MEP || || | Up^ | . | ... | . |Up^ | || || MEP ||
||DownV|| ||MIP|MEP | . | | . |MEP |MIP|| ||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 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
skipping to change at page 9, line 48 skipping to change at page 10, line 4
- 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 - the MP2P tunnels used for aliasing unicast traffic destined to a
INTERNET-DRAFT EVPN OAM Requirements/Framework
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
INTERNET-DRAFT EVPN OAM Requirements/Framework
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
skipping to change at page 10, line 43 skipping to change at page 11, line 5
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.
INTERNET-DRAFT EVPN OAM Requirements/Framework
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 15, line 50 skipping to change at page 15, line 50
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.
3.2.1 Packet Loss 3.2.1 Packet Loss
EVPN Network OAM SHOULD provide mechanisms for measuring packet loss EVPN Network OAM SHOULD provide mechanisms for measuring packet loss
for a given service. for a given service [RFC7680] [RFC6673].
INTERNET-DRAFT EVPN OAM Requirements/Framework INTERNET-DRAFT EVPN OAM Requirements/Framework
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 3.2.2 Packet Delay and Jitter
EVPN Service OAM SHOULD support measurement of one-way and two-way EVPN Service OAM SHOULD support measurement of one-way and two-way
packet delay and delay variation (jitter) across the EVPN network. packet delay and delay variation (jitter) across the EVPN network.
Measurement of one-way delay requires clock synchronization between Measurement of one-way delay requires clock synchronization between
the probe source and target devices. Mechanisms for clock the probe source and target devices. Mechanisms for clock
synchronization are outside the scope of this document. Note that synchronization are outside the scope of this document. Note that
Service OAM performance management mechanisms defined in [Y.1731] can Service OAM performance management mechanisms defined in [Y.1731] can
be used. be used. See also [RFC7679], [RFC2681], and [RFC3393]
EVPN Network OAM MAY support measurement of one-way and two-way EVPN Network OAM MAY support measurement of one-way and two-way
packet delay and delay variation (jitter) across the EVPN network. packet delay and delay variation (jitter) across the EVPN network.
INTERNET-DRAFT EVPN OAM Requirements/Framework INTERNET-DRAFT EVPN OAM Requirements/Framework
4. Security Considerations 4. Security Considerations
EVPN OAM MUST prevent OAM packets from leaking outside of the EVPN EVPN OAM MUST prevent OAM packets from leaking outside of the EVPN
network or outside their corresponding Maintenance Domain. This can network or outside their corresponding Maintenance Domain. This can
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, Xiao Min, Gregory Mirsky, Dave Schinazi, Melinda David Black, Martin Duke, Xiao Min, Gregory Mirsky, Dave Schinazi,
Shore, Alexander Vainshtein, and Stig Venaas. Melinda Shore, Alexander Vainshtein, and Stig Venaas.
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 38 skipping to change at page 19, line 38
Area Networks", 2014. Area Networks", 2014.
[Y.1731] "ITU-T Recommendation Y.1731 (02/08) - OAM functions and [Y.1731] "ITU-T Recommendation Y.1731 (02/08) - OAM functions and
mechanisms for Ethernet based networks", February 2008. mechanisms for Ethernet based networks", February 2008.
[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
Delay Metric for IPPM", RFC 2681, DOI 10.17487/RFC2681,
September 1999, <https://www.rfc-editor.org/info/rfc2681>.
[RFC3393] Demichelis, C. and P. Chimento, "IP Packet Delay Variation
Metric for IP Performance Metrics (IPPM)", RFC 3393, DOI
10.17487/RFC3393, November 2002, <https://www.rfc-
editor.org/info/rfc3393>.
[RFC5085] Nadeau, T., Ed., and C. Pignataro, Ed., "Pseudowire Virtual [RFC5085] Nadeau, T., Ed., and C. Pignataro, Ed., "Pseudowire Virtual
Circuit Connectivity Verification (VCCV): A Control Channel Circuit Connectivity Verification (VCCV): A Control Channel
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,
INTERNET-DRAFT EVPN OAM Requirements/Framework
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>.
[RFC6673] Morton, A., "Round-Trip Packet Loss Metrics", RFC 6673, DOI
10.17487/RFC6673, August 2012, <https://www.rfc-
editor.org/info/rfc6673>.
[RFC7679] Almes, G., Kalidindi, S., Zekauskas, M., and A. Morton,
Ed., "A One-Way Delay Metric for IP Performance Metrics
(IPPM)", STD 81, RFC 7679, DOI 10.17487/RFC7679, January
2016, <https://www.rfc-editor.org/info/rfc7679>.
[RFC7680] Almes, G., Kalidindi, S., Zekauskas, M., and A. Morton,
Ed., "A One-Way Loss Metric for IP Performance Metrics
(IPPM)", STD 82, RFC 7680, DOI 10.17487/RFC7680, January
2016, <https://www.rfc-editor.org/info/rfc7680>.
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. 26 change blocks. 
39 lines changed or deleted 81 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/