RFC 9062

Framework and Requirements for Ethernet VPN (EVPN) Operations, Administration, and Maintenance (OAM)

📅 published June 2021, from ietf

Framework and Requirements for Ethernet VPN (EVPN) Operations, Administration, and Maintenance (OAM) 🦋

Okay bestie, let's start with the title block 💅 This is RFC 9062, and it's from the Internet Engineering Task Force (IETF). The authors are S. Salam (Cisco), A. Sajassi (Cisco), S. Aldrin (Google), J. Drake (Juniper), and D. Eastlake 3rd (Futurewei). The category is Informational 📚, the ISSN is 2070-1721, and the date is June 2021 🌸. Its title block doesn't list anything it obsoletes or updates.

Abstract ✨

So the abstract is giving overview 🎀 This document sets out the requirements and a reference framework for Ethernet VPN (EVPN) Operations, Administration, and Maintenance (OAM). The requirements cover the OAM side of EVPN and Provider Backbone Bridge EVPN (PBB-EVPN). The framework is a layered OAM model that includes the EVPN service layer, network layer, underlying Packet Switched Network (PSN) transport layer, and link layer, but it focuses on the service and network layers 🦋

Status of This Memo 🧚

Quick heads up: this is NOT an Internet Standards Track spec. It's published for informational purposes 💜

This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are candidates for any level of Internet Standard; see Section 2 of RFC 7841.

Info about the current status of this document, any errata, and how to give feedback on it can be found at https://www.rfc-editor.org/info/rfc9062.

Copyright (c) 2021 IETF Trust and the persons identified as the document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) as they're in effect on the date of publication. Please read these carefully, because they describe your rights and restrictions for this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions, and they're provided without warranty as described in the Simplified BSD License 🫶

Table of Contents 🍓

1.  Introduction
  1.1.  Relationship to Other OAM Work
  1.2.  Specification of Requirements
  1.3.  Terminology
2.  EVPN OAM Framework
  2.1.  OAM Layering
  2.2.  EVPN Service OAM
  2.3.  EVPN Network OAM
  2.4.  Transport OAM for EVPN
  2.5.  Link OAM
  2.6.  OAM Interworking
3.  EVPN OAM Requirements
  3.1.  Fault Management Requirements
    3.1.1.  Proactive Fault Management Functions
      3.1.1.1.  Fault Detection (Continuity Check)
      3.1.1.2.  Defect Indication
        3.1.1.2.1.  Forward Defect Indication (FDI)
        3.1.1.2.2.  Reverse Defect Indication (RDI)
    3.1.2.  On-Demand Fault Management Functions
      3.1.2.1.  Connectivity Verification
      3.1.2.2.  Fault Isolation
  3.2.  Performance Management
    3.2.1.  Packet Loss
    3.2.2.  Packet Delay and Jitter
4.  Security Considerations
5.  IANA Considerations
6.  References
  6.1.  Normative References
  6.2.  Informative References
Acknowledgements
Authors' Addresses

1. Introduction ✨

Here's the big picture 💖 This document sets out the requirements and a reference framework for Ethernet VPN (EVPN) Operations, Administration, and Maintenance (OAM) [RFC6291]. In this context, "EVPN OAM" is a loose way of talking about the OAM functions that are required for and/or applicable to [RFC7432] and [RFC7623].

EVPN is a Layer 2 VPN (L2VPN) solution for multipoint Ethernet services. It has advanced multihoming capabilities and uses BGP to distribute Customer/Client Media Access Control (C-MAC) address reachability information over the core MPLS/IP network 🌸

PBB-EVPN combines Provider Backbone Bridging (PBB) [IEEE-802.1Q] with EVPN. The point is to reduce the number of BGP MAC advertisement routes, provide client MAC address mobility using C-MAC [RFC7623] aggregation and Backbone MAC (B-MAC) [RFC7623] sub-netting, confine the scope of C-MAC learning to only active flows, offer per-site policies, and avoid C-MAC address flushing on topology changes. Iconic 👑

This document focuses on the fault management and performance management parts of EVPN OAM. It defines the layered OAM model, which includes the EVPN service layer, network layer, underlying Packet Switched Network (PSN) transport layer, and link layer, but it focuses on the service and network layers 🦋

1.1. Relationship to Other OAM Work

This doc borrows concepts and elements from a few other documents 🧚

[RFC6136] specifies the requirements and a reference model for OAM as it relates to L2VPN services, pseudowires, and associated Packet Switched Network (PSN) tunnels. This document focuses on Virtual Private LAN Service (VPLS) and Virtual Private Wire Service (VPWS) solutions and services.

[RFC8029] defines mechanisms for detecting data plane failures in MPLS Label Switched Paths (LSPs). That includes procedures to check that the data plane is operating correctly, and mechanisms to verify the data plane against the control plane.

[IEEE-802.1Q] specifies the Ethernet Connectivity Fault Management (CFM) protocol. It defines the concepts of Maintenance Domains, Maintenance Associations, Maintenance End Points, and Maintenance Intermediate Points.

[Y.1731] extends Connectivity Fault Management in the following areas: it defines fault notification and alarm suppression functions for Ethernet, and it specifies mechanisms for Ethernet performance management, including loss, delay, jitter, and throughput measurement.

1.2. Specification of Requirements

Okay, this part is the important one 👑 It's where the BCP 14 key words get defined.

Here's how the key words work in this doc. "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" are interpreted as described in BCP 14 [RFC2119] [RFC8174], but only when, and only when, they appear in all capitals, as shown here 🎀

1.3. Terminology

Now the glossary 🍓 Lots of this is defined in [RFC6136], so it's a good idea to check there too 💅

This document uses the following terminology, much of which is defined in [RFC6136]:

CE          Customer Edge device; for example, a host, router, or
            switch.

CFM         Connectivity Fault Management [IEEE-802.1Q]

DF          Designated Forwarder [RFC7432]

Down MEP    A MEP that originates traffic away from and terminates
            traffic towards the core of the device in whose port it
            is logically located.

EVI         An EVPN instance spanning the Provider Edge (PE) devices
            participating in that EVPN [RFC7432].

L2VPN       Layer 2 VPN

LOC         Loss of continuity

MA          Maintenance Association; a set of MEPs belonging to the
            same Maintenance Domain (MD) established to verify the
            integrity of a single service instance [IEEE-802.1Q].

MD          Maintenance Domain; an OAM Domain that represents a
            region over which OAM frames can operate unobstructed
            [IEEE-802.1Q].

MEP         Maintenance End Point; it is responsible for origination
            and termination of OAM frames for a given MA.  A MEP is
            logically located in a device's port [IEEE-802.1Q].

MIP         Maintenance Intermediate Point; it is located between
            peer MEPs and can process and respond to certain OAM
            frames but does not initiate them.  A MIP is logically
            located in a device's port [IEEE-802.1Q].

MP2P        Multipoint to Point

NMS         Network Management Station [RFC6632]

P           Provider network interior (non-edge) node

P2MP        Point to Multipoint

PBB         Provider Backbone Bridge [RFC7623]

PE          Provider Edge network device

Up MEP      A MEP that originates traffic towards and terminates
            traffic from the core of the device in whose port it is
            logically located.

VPN         Virtual Private Network

2. EVPN OAM Framework 🌈

2.1. OAM Layering

Layers, layers, layers 🧚✨ A few layers come into play when you run an L2VPN service with the EVPN family of solutions. The focus of this document is the service and network layers 💖

  • The service layer runs end to end between the sites or Ethernet segments that EVPN is interconnecting.
  • The network layer runs between the EVPN PE (Provider Edge) nodes and is mostly transparent to the P (provider network interior) nodes, except where flow entropy comes into play. It uses MPLS for service (i.e., EVI) multiplexing and split-horizon functions.
  • The transport layer is dictated by the networking technology of the PSN. It may be based on either MPLS LSPs or IP.
  • The link layer depends on the physical technology used. Ethernet is a popular choice here, but other options are deployed too (e.g., Packet over SONET (POS), Dense Wavelength Division Multiplexing (DWDM), etc.).

This layering extends to the set of OAM protocols involved in the ongoing maintenance and diagnostics of EVPN networks. Figure 1 below shows the OAM layering and which devices can see which OAM layer(s) 👀

        +---+                               +---+
+--+    |   |    +---+    +---+    +---+    |   |    +--+
|CE|----|PE |----| P |----| P |----| P |----|PE |----|CE|
+--+    |   |    +---+    +---+    +---+    |   |    +--+
        +---+                               +---+

  o-------o----------- Service OAM -----------o-------o

          o----------- Network OAM -----------o

          o--------o--------o--------o--------o  Transport OAM

   o----o   o----o   o----o   o----o   o----o   o----o  Link OAM

                        Figure 1: OAM Layering

Here's the good part 💅 Service OAM and Network OAM mechanisms only have visibility into the PE nodes, not the P nodes. Because of that, they can be used to work out whether a 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 nodes 🔥

Figure 2 below shows an example network where Ethernet domains are interconnected via EVPN using MPLS. It also shows the OAM mechanisms that apply at each layer. The details of each layer are covered in the sections below 🦋

        +---+                               +---+
+--+    |   |    +---+    +---+    +---+    |   |    +--+
|CE|----|PE |----| P |----| P |----| P |----|PE |----|CE|
+--+    |   |    +---+    +---+    +---+    |   |    +--+
        +---+                               +---+

   o----o---------- CFM (Service OAM) ----------o----o

          o-------- EVPN Network OAM ---------o

          o--------o--------o--------o--------o MPLS OAM

   o----o   o----o   o----o   o----o   o----o   o----o 802.3 OAM
                                                       [IEEE-802.3]

                      Figure 2: EVPN OAM Example

2.2. EVPN Service OAM 🎀

okay so the EVPN Service OAM protocol depends on what service-layer tech is being connected by the EVPN solution 🫶. For [RFC7432] and [RFC7623], the service layer is Ethernet, so the matching Service OAM protocol is Ethernet CFM [IEEE-802.1Q] ✨.

EVPN Service OAM is visible to the CEs and EVPN PEs but not to the P nodes 👀. That's because PEs work at the Ethernet MAC layer in [RFC7432] and [RFC7623], and P nodes don't 💅.

The EVPN PE MUST support MIP functions in the applicable Service OAM protocol (for example, Ethernet CFM) 💖. The EVPN PE SHOULD support MEP functions in that protocol too, and that includes both Up and Down MEP functions 🔥.

Here's the vibe 🧚. As shown in Figure 3, the MIP and MEP functions we're talking about live inside the device's port at the customer level. (There could be MEPs/MIPs within PE ports facing the provider network, but they wouldn't matter for EVPN Service OAM, because traffic through them gets encapsulated or tunneled, so any customer-level OAM messages just get treated as data 🙈.) Down MEP functions point away from the core of the device, while Up MEP functions point toward the core (toward the PE forwarding mechanism, in the case of a PE) 🌸. OAM messages between the PE Up MEPs are a type of EVPN Network OAM, while messages between the CEs, or from a PE to its local CE or to the remote CE, are Service OAMs 💜.

    +-------+   +----------------+       +----------------+   +-------+
    |+-----+|   |+--------------+|       |+--------------+|   |+-----+|
    ||  CE ||   ||     PE       ||  ...  ||       PE     ||   || CE  ||
    |+--+--+|   |+---+--------+-+|       |+-+--------+---+|   |+--+--+|
    |   |   |   |    |        |  |       |  |        |    |   |   |   |
    |+--+--+|   |+---+-----+  .  |       |  .  +-----+---+|   |+--+--+|
    || MEP ||   ||   | Up ^|  .  |  ...  |  .  | Up ^|   ||   || MEP ||
    ||DownV||   ||MIP|MEP  |  .  |       |  .  |MEP  |MIP||   ||DownV||
    |+--+--+|   ||   |DownV|  .  |       |  .  |DownV|   ||   |+--+--+|
    |   |   |   |+---+-----+  |  |       |  |  +-----+---+|   |   |   |
    +---|---+   +----|--------|--+       +--|--------|----+   +---|---+
        |            |        |             |        |            |
        +------------+        +---  ...  ---+        +------------+

                           Figure 3: CFM Details

The EVPN PE MUST, by default, learn the MAC address of locally attached CE MEPs by snooping on CFM frames and advertising them to remote PEs as a MAC/IP Advertisement route 🦋. Some means to limit the 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 Advertisement route ✨. Since these aren't subject to mobility, they SHOULD be advertised with the static (sticky) bit set (see Section 15.2 of [RFC7432]) 📌.

2.3. EVPN Network OAM 🌈

EVPN Network OAM is only visible to the PE nodes 👑. This OAM layer is analogous to Virtual Circuit Connectivity Verification (VCCV) [RFC5085] for VPLS/VPWS 💅. It gives you mechanisms to check that the data plane is working correctly, plus a way to verify the data plane against the control plane 🔍. That includes fault detection and diagnostics on:

  • the MP2P tunnels used for transporting unicast traffic between PEs 🚇. EVPN allows three different models of unicast label assignment: label per EVI, label per <ESI, Ethernet Tag>, and label per MAC address 🏷️. In all three models, the label is bound to an EVPN Unicast Forwarding Equivalence Class (FEC) 💖. EVPN Network OAM MUST provide mechanisms to check the operation of the data plane and verify that operation against the control plane view 🫶.
  • the MP2P tunnels used for aliasing unicast traffic destined to a multihomed Ethernet segment 🪞. The three label assignment models discussed above apply here as well 🍓. In all three models, the label is bound to an EVPN Aliasing FEC 🌸. EVPN Network OAM MUST provide mechanisms to check the operation of the data plane and verify that operation against the control plane view 💜.
  • the multicast tunnels (either MP2P or P2MP) used for transporting broadcast, unknown unicast, and multicast traffic between PEs 📣. With ingress replication, a label is allocated per EVI or per <EVI, Ethernet Tag> and is bound to an EVPN Multicast FEC 🔊. With Label Switched Multicast (LSM), and more specifically aggregate inclusive trees, a label may again be allocated per EVI or per <EVI, Ethernet Tag> and is bound to the tunnel FEC 🌊.
  • the correct operation of the Ethernet Segment Identifier (ESI) split-horizon filtering function 🪓. In EVPN, a label is allocated per multihomed Ethernet segment so the access split-horizon enforcement can happen 🛡️. The label is bound to an EVPN Ethernet segment 🎯.
  • the correct operation of the Designated Forwarder (DF) [RFC7432] filtering function ⭐. EVPN Network OAM MUST provide mechanisms to check the operation of the data plane and verify that operation against the control plane view for the DF filtering function 🙌.

EVPN Network OAM mechanisms MUST provide in-band monitoring capabilities 🧵. It's desirable, to the extent that's practical, for OAM test messages to share fate with data messages 🤞. How to actually achieve this is beyond the scope of this document 🙈.

EVPN Network OAM SHOULD provide both proactive and on-demand mechanisms for monitoring data plane operation, and for monitoring data plane conformance to the state of the control plane 🩷.

2.4. Transport OAM for EVPN 🚀

The Transport OAM protocol depends on the nature of the underlying transport technology in the PSN 🛣️. MPLS OAM mechanisms [RFC8029] [RFC6425], as well as ICMP [RFC0792] and ICMPv6 [RFC4443], are applicable, depending on whether the PSN uses MPLS or IP transport, respectively 🌐. Bidirectional Forwarding Detection (BFD) mechanisms per [RFC5880], [RFC5881], [RFC5883], and [RFC5884] also apply 💫. And the BFD mechanisms for MPLS-TP LSPs per [RFC6428] are applicable too 🧚‍♀️.

Link OAM depends on the data-link technology used between the PE and P nodes 🧩. For example, if Ethernet links are in play, then Ethernet Link OAM ([IEEE-802.3], Clause 57) may be used 🎀.

2.6. OAM Interworking 🤝

When you're interworking two networking domains, like actual Ethernet and EVPN, to provide an end-to-end emulated service, you need to be able to identify the failure domain and location, even when a PE supports both the Service OAM mechanisms and the EVPN Network OAM mechanisms 🕵️‍♀️. On top of that, scalability constraints may mean you can't run proactive monitoring, such as Ethernet Continuity Check Messages (CCMs) [IEEE-802.1Q], at a PE to detect the failure of an EVI across the EVPN domain 😭. So alarms raised when a failure is detected in one domain (e.g., actual Ethernet or the EVPN network domain) need to be mapped to the other domain 🔁. There are also cases where a PE can't process Service OAM messages received from a remote PE over the PSN, even when those messages are defined (like in the Ethernet case), which means it needs support for mapping fault notification messages between the EVPN Network domain and the Service domain 🫠.

Interworking isn't limited to totally different network domains, though 🌍. It's also possible to do OAM interworking across different layers in the same network domain 💅. In general, alarms generated within an OAM layer, as a result of proactive fault detection mechanisms, may be injected into its client-layer OAM mechanisms 💉. This lets the client-layer OAM trigger event-driven (i.e., asynchronous) fault notifications ⚡. For example, alarms from the Link OAM mechanisms may be injected into the Transport OAM layer, alarms from the Transport OAM mechanism may be injected into the Network OAM mechanism, and so on 🔄.

EVPN OAM MUST support interworking between the Network OAM and Service OAM mechanisms 💖. EVPN OAM MAY support interworking among other OAM layers 🌷.

3. EVPN OAM Requirements 📋

This section covers the EVPN OAM requirements for fault management and performance management 🩵.

3.1. Fault Management Requirements 🚨

3.1.1. Proactive Fault Management Functions ⏰

The network operator configures proactive fault management functions to run periodically 🗓️. Certain actions (for example, protection switchover or alarm indication signaling) can be tied to specific events, like entering or clearing fault states 🎢.

3.1.1.1. Fault Detection (Continuity Check) 💓

Proactive fault detection works by periodically monitoring reachability between service end points, i.e., MEPs in a given MA, through the exchange of CCMs [IEEE-802.1Q] 🫀. The reachability between any two arbitrary MEPs may be monitored for:

  • in-band, per-flow monitoring 🌊. This gives you per-flow monitoring between MEPs 🔎. EVPN Network OAM MUST support fault detection with per-user flow granularity 💎. EVPN Service OAM MAY support fault detection with per-user flow granularity 🌤️.
  • a representative path 🛤️. This gives you a liveness check of the nodes hosting the MEPs, assuming that loss of continuity (LOC) to the MEP is read as a failure of the hosting node 🖥️. It doesn't conclusively show liveness of the path(s) user data traffic takes, though 🙃. This enables node failure detection but not path failure detection through the use of a test flow 🧪. EVPN Network OAM and Service OAM MUST support fault detection using test flows 🫶.
  • all paths 🛣️. For MPLS/IP networks with ECMP, monitoring all unicast paths between MEPs (on non-adjacent nodes) may not be possible 🥴. The per-hop ECMP hashing behavior may produce situations where a MEP can't pick flow entropy characteristics that exercise the exhaustive set of ECMP paths 🌀. Monitoring all ECMP paths between MEPs (on non-adjacent nodes) is not a requirement for EVPN OAM 🙅‍♀️.

The fact that MPLS/IP networks don't enforce congruency between unicast and multicast paths means that the proactive fault detection mechanisms for EVPN networks MUST provide procedures to monitor the unicast paths independently of the multicast paths 🧐. This applies to EVPN Service OAM and Network OAM 💜.

3.1.1.2. Defect Indication 🚩

Defect indications come in two types: forward and reverse, as described below 🔀. EVPN Service OAM MUST support at least one of these types of event-driven defect indications when a connectivity defect is detected 🫢.

🌸 That's the end of this part, bestie. Keep reading for the next one! 🌸

3.1.1.2.1. Forward Defect Indication (FDI) ✨

okay so FDI is how a failure gets reported away from where it happened 🚨. A server MEP (an actual one or a virtual one, both count 🫶) sends a forward defect indication in the direction away from the failure. Figure 4 shows it. The arrows point out from the break, not back toward it 🦋

                              Failure
                                 |
          +-----+      +-----+   V   +-----+      +-----+
          |  A  |------|  B  |--XXX--|  C  |------|  D  |
          +-----+      +-----+       +-----+      +-----+

              <===========|             |============>
                Forward                    Forward
                Defect                     Defect
                Indication                 Indication

                    Figure 4: Forward Defect Indication

Forward defect indication may be used for alarm suppression and/or for the purpose of interworking with other layer OAM protocols. Alarm suppression is the big one here 🙈 It's needed when one transport-level or network-level fault causes a bunch of service- or flow-level faults. Instead of flooding the network management station (NMS) with a whole pile of Service or Flow granularity alarms, you just tell it about the one real problem at the transport or network level. So much less noise 💖 EVPN PEs SHOULD support forward defect indication in the Service OAM mechanisms. 🌸

3.1.1.2.2. Reverse Defect Indication (RDI) 🎀

RDI is the reverse vibe 🔁. It's used to say that the MEP sending it has detected a LOC defect. This one goes toward the failure, as shown in Figure 5 💅

                              Failure
                                 |
          +-----+      +-----+   V   +-----+      +-----+
          |  A  |------|  B  |--XXX--|  C  |------|  D  |
          +-----+      +-----+       +-----+      +-----+

              |===========>             <============|
                Reverse                    Reverse
                Defect                     Defect
                Indication                 Indication

                    Figure 5: Reverse Defect Indication

RDI is what makes single-sided management possible 🧚 The network operator can look at just one MEP and figure out how healthy the whole monitored service is. Lowkey genius 👑 EVPN PEs SHOULD support reverse defect indication in the Service OAM mechanisms. That covers two things: sending a LOC defect signal to a remote MEP, and recognising RDI coming in from a remote MEP 🫶. Also, in a multipoint MA, RDI is not a useful way to spot a unidirectional fault 💀 Why? RDI doesn't say which affected MEP(s) the sender had spotted the LOC defect with, so you're kinda guessing 🙈

3.1.2. On-Demand Fault Management Functions ✨

On-demand fault management functions are kicked off manually by the network operator and keep going for a bounded amount of time 🕒 They're basically the diagnostics tools you reach for when you want to dig into a defect 🔍

3.1.2.1. Connectivity Verification 💜

EVPN Network OAM MUST support on-demand connectivity verification mechanisms for unicast and multicast destinations. The connectivity verification mechanisms SHOULD provide a means for specifying and carrying the following in the messages:

  • variable-length payload/padding to test connectivity problems related to the Maximum Transmission Unit (MTU).
  • test frame formats as defined in Appendix C of [RFC2544] to detect potential packet corruption.

EVPN Network OAM MUST support connectivity verification at per-flow granularity. That includes user flows (to test a specific path between PEs) and test flows (to test a representative path between PEs) 🦋

EVPN Service OAM MUST support connectivity verification on test flows and MAY support connectivity verification on user flows. 🌈

For multicast connectivity verification, EVPN Network OAM MUST support reporting on:

  • the DF filtering status of a specific port(s) or all the ports in a given bridge domain.
  • the split-horizon filtering status of a specific port(s) or all the ports in a given bridge domain.

3.1.2.2. Fault Isolation 🔎

EVPN OAM MUST support an on-demand fault localization function. This is the ability to narrow a fault down to a particular port, link, or node 🎯 Here's the tea: in MPLS/IP, the forward and reverse paths can be asymmetric, so fault isolation is direction-sensitive 🙃 Say you've got two PEs, A and B. To localise continuity failures between them, you have to run fault-isolation procedures from PE A to PE B and from PE B to PE A. Both directions, bestie 💅

EVPN Service OAM mechanisms can only see the PEs, not the MPLS or IP P nodes 👀 So they can help you deduce whether the fault is in the customer's own network, the local CE-PE segment, or a remote CE-PE segment (or segments). EVPN Network and Transport OAM mechanisms are the ones you use for fault isolation between the PEs and the P nodes 🧩

3.2. Performance Management 📈

Performance management functions can be performed both proactively and on demand 💖 Proactive management is a recurring thing, where the performance management probes run continuously without needing a trigger. This section covers both the proactive and the on-demand functions 🫶

3.2.1. Packet Loss 💧

EVPN Network OAM SHOULD provide mechanisms for measuring packet loss for a given service -- for example, [RFC7680] and [RFC6673]. 🌸

Here's the thing 🙈 EVPN has inherent multipoint-to-multipoint connectivity, so you can't accurately measure packet loss by counting user data packets. User packets can get delivered to more PEs or more ports than they need to (think broadcast, unpruned multicast, or unknown unicast flooding), so the count gets messed up 💀 That's why a statistical approach is required to approximate the packet loss rate. The trick is sending "synthetic" OAM packets that only get counted by the ports (MEPs) that are supposed to receive them 🧚 That gives you a statistical approximation of how many data frames were lost, even with multipoint-to-multipoint connectivity. Iconic 👑

3.2.2. Packet Delay and Jitter ⏱️

EVPN Service OAM SHOULD support measurement of one-way and two-way packet delay and delay variation (jitter) across the EVPN network. One-way delay needs clock synchronisation between the probe source and target devices 🕰️ How you get clock synchronisation is outside the scope of this document, so don't look for it here 🙃 Service OAM performance management mechanisms defined in [Y.1731] can be used. See also [RFC7679], [RFC2681], and [RFC3393]. 📚

EVPN Network OAM MAY support measurement of one-way and two-way packet delay and delay variation (jitter) across the EVPN network. 🦋

4. Security Considerations 🔐

⚠️ This section is serious business, bestie. Don't skip it 💀

EVPN OAM MUST prevent OAM packets from leaking outside of the EVPN network or outside their corresponding Maintenance Domain. For CFM, for example, this can be done by having MEPs run a filtering function based on the Maintenance Level attached to received OAM packets 🛡️

EVPN OAM SHOULD provide mechanisms for implementation and optional use to:

  • prevent denial-of-service attacks caused by exploitation of the OAM message channel (for example, by forging messages to exceed a Maintenance End Point's capacity to maintain state).
  • authenticate communicating end points (for example, MEPs and MIPs).

5. IANA Considerations 📋

This document has no IANA actions. Nothing to see here, so we're moving on 💅

6. References 📚

6.1. Normative References 🌷

6.2. Informative References 📚✨

okay so these are the bonus reads, bestie 🧚 the stuff the spec points at for extra context but doesn't strictly need you to implement. Every one of them is listed below exactly as the original has it, so you can go find the real thing 💅

[IEEE-802.1Q]
           IEEE, "IEEE Standard for Local and metropolitan area
           networks--Bridges and Bridged Networks", IEEE Std 802.1Q-
           2014, DOI 10.1109/IEEESTD.2014.6991462, December 2014,
           <https://doi.org/10.1109/IEEESTD.2014.6991462>.

[IEEE-802.3]
           IEEE, "IEEE Standard for Ethernet", IEEE Std 802.3-2018,
           DOI 10.1109/IEEESTD.2018.8457469, August 2018,
           <https://doi.org/10.1109/IEEESTD.2018.8457469>.

[RFC2544]  Bradner, S. and J. McQuaid, "Benchmarking Methodology for
           Network Interconnect Devices", RFC 2544,
           DOI 10.17487/RFC2544, March 1999,
           <https://www.rfc-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
           Circuit Connectivity Verification (VCCV): A Control
           Channel for Pseudowires", RFC 5085, DOI 10.17487/RFC5085,
           December 2007, <https://www.rfc-editor.org/info/rfc5085>.

[RFC6136]  Sajassi, A., Ed. and D. Mohan, Ed., "Layer 2 Virtual
           Private Network (L2VPN) Operations, Administration, and
           Maintenance (OAM) Requirements and Framework", RFC 6136,
           DOI 10.17487/RFC6136, March 2011,
           <https://www.rfc-editor.org/info/rfc6136>.

[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 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>.

[Y.1731]   ITU-T, "Operation, administration and maintenance (OAM)
           functions and mechanisms for Ethernet-based networks",
           ITU-T Recommendation G.8013/Y.1731, August 2015.

Acknowledgements 💖

the authors wanted to give a huge shoutout to everyone who reviewed this work and dropped their really valuable comments 🫶 the squad is:

  • David Black
  • Martin Duke
  • Xiao Min
  • Gregory Mirsky
  • Zaheduzzaman Sarker
  • Dave Schinazi
  • John Scudder
  • Melinda Shore
  • Robert Wilton
  • Alexander Vainshtein
  • Stig Venaas
  • Éric Vyncke

literally the best group project crew ever 😭🌈

Authors' Addresses 🎀

here's where you can find the authors, bestie. the details are copied exactly so nothing gets lost in translation 🦋

Samer Salam
Cisco
The Atrium Building, Floor 3
Weygand St.
Beirut
Lebanon

Email: ssalam@cisco.com


Ali Sajassi
Cisco
170 West Tasman Drive
San Jose, CA 95134
United States of America

Email: sajassi@cisco.com


Sam Aldrin
Google, Inc.
1600 Amphitheatre Parkway
Mountain View, CA 94043
United States of America

Email: aldrin.ietf@gmail.com


John E. Drake
Juniper Networks
1194 N. Mathilda Ave.
Sunnyvale, CA 94089
United States of America

Email: jdrake@juniper.net


Donald E. Eastlake 3rd
Futurewei Technologies
2386 Panoramic Circle
Apopka, FL 32703
United States of America

Phone: +1-508-333-2270
Email: d3e3e3@gmail.com

🌸 and that's a wrap on RFC 9062, slay 👑

📦 where this page comes from