EVPN Operations, Administration and Maintenance Requirements and Framework
draft-ietf-bess-evpn-oam-req-frmwk-03

Salam et al                                                    [Page 12]
INTERNET-DRAFT                           EVPN OAM Requirements/Framework

   failure (refer to Figure 5).

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

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

                    Figure 5: Reverse Defect Indication

   RDI allows single-sided management, where the network operator can
   examine the state of a single MEP and deduce the overall health of a
   monitored service. EVPN PEs SHOULD support Reverse Defect Indication
   in the Service OAM mechanisms. This includes both 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
   is not a useful indicator of unidirectional fault.  This is because
   RDI carries no indication of the affected MEP(s) with which the
   sender had detected a LoC defect.

3.1.2 On-Demand Fault Management Functions

   On-demand fault management functions are initiated manually by the
   network operator and continue for a time bound period. These
   functions enable the operator to run diagnostics to investigate a
   defect condition.

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 in the messages:

   - variable length payload/padding to test MTU related connectivity
     problems.

   - 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

Salam et al                                                    [Page 13]
INTERNET-DRAFT                           EVPN OAM Requirements/Framework

   granularity. This includes both user flows (to test a specific path
   between PEs) as well as test flows (to test a representative path
   between PEs).

   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 specific port(s) or all the ports in a
     given bridge-domain.

   - the Split Horizon filtering status of 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
   involves the capability to narrow down the locality of a fault to a
   particular port, link or node. The characteristic of forward/reverse
   path asymmetry, in MPLS/IP, makes fault isolation a direction-
   sensitive operation. That is, given two PEs A and B, localization of
   continuity failures between them requires running fault isolation
   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
   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
   remote CE-PE segment(s). EVPN Network and Transport OAM mechanisms
   can be used for fault isolation between the PEs and P nodes.

3.2 Performance Management

   Performance Management functions can be performed both proactively
   and on-demand. Proactive management involves a recurring function,
   where the performance management probes are run continuously without
   a trigger. We cover both proactive and on-demand functions in this
   section.

3.2.1 Packet Loss

   EVPN Network OAM SHOULD provide mechanisms for measuring packet loss
   for a given service.

Salam et al                                                    [Page 14]
INTERNET-DRAFT                           EVPN OAM Requirements/Framework

   Given that EVPN provides inherent support for multipoint-to-
   multipoint connectivity, then packet loss cannot be accurately
   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
   (e.g. due to broadcast, un-pruned multicast or unknown unicast
   flooding). As such, a statistical means of approximating packet loss
   rate is required. This can be achieved by sending "synthetic" OAM
   packets that are counted only by those ports (MEPs) that are required
   to receive them. This provides a statistical approximation of the
   number of data frames lost, even with multipoint-to-multipoint
   connectivity.

3.2.2 Packet Delay

   EVPN Service OAM SHOULD support measurement of one-way and two-way
   packet delay and delay variation (jitter) across the EVPN network.
   Measurement of one-way delay requires clock synchronization between
   the probe source and target devices. Mechanisms for clock
   synchronization are outside the scope of this document. Note that
   Service OAM performance management mechanisms defined in [Y.1731] can
   be used.

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

Salam et al                                                    [Page 15]
INTERNET-DRAFT                           EVPN OAM Requirements/Framework

4. Security Considerations

   EVPN OAM must provide mechanisms for:

   - Preventing denial of service attacks caused by exploitation of the
     OAM message channel.

   - Optionally authenticate communicating endpoints (MEPs and MIPs).

   - Preventing OAM packets from leaking outside of the EVPN network or
     outside their corresponding Maintenance Domain. This can be done by
     having MEPs implement a filtering function based on the Maintenance
     Level associated with received OAM packets.

5. Acknowledgements

   The authors would like to thank the following for their review of
   this work and valuable comments:

      Gregory Mirsky, Alexander Vainshtein, Xiao Min

6. IANA Considerations

   This document requires no IANA actions.

Salam et al                                                    [Page 16]
INTERNET-DRAFT                           EVPN OAM Requirements/Framework

Normative References

   [RFC792] Postel, J., "Internet Control Message Protocol", STD 5, RFC
             792, DOI 10.17487/RFC0792, September 1981,
             <https://www.rfc-editor.org/info/rfc792>.

   [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
             Requirement Levels", BCP 14, RFC 2119, DOI
             10.17487/RFC2119, March 1997, <https://www.rfc-
             editor.org/info/rfc2119>.

   [RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection
             (BFD)", RFC 5880, DOI 10.17487/RFC5880, June 2010,
             <https://www.rfc-editor.org/info/rfc5880>.

   [RFC5881] Katz, D. and D. Ward, "Bidirectional Forwarding Detection
             (BFD) for IPv4 and IPv6 (Single Hop)", RFC 5881, DOI
             10.17487/RFC5881, June 2010, <https://www.rfc-
             editor.org/info/rfc5881>.

   [RFC5883] Katz, D. and D. Ward, "Bidirectional Forwarding Detection
             (BFD) for Multihop Paths", RFC 5883, DOI 10.17487/RFC5883,
             June 2010, <https://www.rfc-editor.org/info/rfc5883>.

   [RFC5884] Aggarwal, R., Kompella, K., Nadeau, T., and G. Swallow,
             "Bidirectional Forwarding Detection (BFD) for MPLS Label
             Switched Paths (LSPs)", RFC 5884, DOI 10.17487/RFC5884,
             June 2010, <https://www.rfc-editor.org/info/rfc5884>.<

   [RFC6291] Andersson, L., van Helvoort, H., Bonica, R., Romascanu, D.,
             and S. Mansfield, "Guidelines for the Use of the "OAM"
             Acronym in the IETF", BCP 161, RFC 6291, DOI
             10.17487/RFC6291, June 2011, <https://www.rfc-
             editor.org/info/rfc6291>.

   [RFC6425] Saxena, S., Ed., Swallow, G., Ali, Z., Farrel, A.,
             Yasukawa, S., and T. Nadeau, "Detecting Data-Plane Failures
             in Point-to-Multipoint MPLS - Extensions to LSP Ping", RFC
             6425, DOI 10.17487/RFC6425, November 2011,
             <https://www.rfc-editor.org/info/rfc6425>.

   [RFC6428] Allan, D., Ed., Swallow, G., Ed., and J. Drake, Ed.,
             "Proactive Connectivity Verification, Continuity Check, and
             Remote Defect Indication for the MPLS Transport Profile",
             RFC 6428, DOI 10.17487/RFC6428, November 2011,
             <https://www.rfc-editor.org/info/rfc6428>.

   [RFC7432] Sajassi, A., Ed., Aggarwal, R., Bitar, N., Isaac, A.,
             Uttaro, J., Drake, J., and W. Henderickx, "BGP MPLS-Based
             Ethernet VPN", RFC 7432, DOI 10.17487/RFC7432, February

Salam et al                                                    [Page 17]
INTERNET-DRAFT                           EVPN OAM Requirements/Framework

             2015, <https://www.rfc-editor.org/info/rfc7432>.

   [RFC7623] Sajassi, A., Ed., Salam, S., Bitar, N., Isaac, A., and W.
             Henderickx, "Provider Backbone Bridging Combined with
             Ethernet VPN (PBB-EVPN)", RFC 7623, DOI 10.17487/RFC7623,
             September 2015, <https://www.rfc-editor.org/info/rfc7623>.

   [RFC8029] Kompella, K., Swallow, G., Pignataro, C., Ed., Kumar, N.,
             Aldrin, S., and M. Chen, "Detecting Multiprotocol Label
             Switched (MPLS) Data-Plane Failures", RFC 8029, DOI
             10.17487/RFC8029, March 2017, <https://www.rfc-
             editor.org/info/rfc8029>.

   [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119
             Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May
             2017, <http://www.rfc-editor.org/info/rfc8174>

Informative References

   [802.1Q] "IEEE Standard for Local and metropolitan area networks -
             Media Access Control (MAC) Bridges and Virtual Bridge Local
             Area Networks", 2014.

   [Y.1731]  "ITU-T Recommendation Y.1731 (02/08) - OAM functions and
             mechanisms for Ethernet based networks", February 2008.

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

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

Salam et al                                                    [Page 18]
INTERNET-DRAFT                           EVPN OAM Requirements/Framework

Authors' Addresses

      Samer Salam
      Cisco

      Email: ssalam@cisco.com

      Ali Sajassi
      Cisco
      170 West Tasman Drive
      San Jose, CA  95134, USA

      Email: sajassi@cisco.com

      Sam Aldrin
      Google, Inc.
      1600 Amphitheatre Parkway
      Mountain View, CA USA

      Email: aldrin.ietf@gmail.com

      John E. Drake
      Juniper Networks
      1194 N. Mathilda Ave.
      Sunnyvale, CA  94089, USA

      Email: jdrake@juniper.net

      Donald E. Eastlake, 3rd
      Futurewei Technologies
      2386 Panoramic Circle
      Apopka, FL 32703 USA

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

Salam et al                                                    [Page 19]