INTERNET-DRAFT Samer Salam Intended Status: Informational Ali Sajassi Cisco Sam Aldrin Huawei John E. Drake Juniper Networks Expires: April 18, 2013 October 15, 2012 E-VPN Operations, Administration and Maintenance Requirements and Framework draft-salam-l2vpn-evpn-oam-req-frmwk-00 Abstract This document specifies the requirements and reference framework for Ethernet VPN (E-VPN) Operations, Administration and Maintenance (OAM). The requirements cover the OAM aspects of E-VPN, PBB-EVPN and TRILL-EVPN. The framework defines the layered OAM model encompassing the E-VPN service layer, network layer and underlying PSN transport layer. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html Salam et al. Expires April 18, 2013 [Page 1] INTERNET DRAFT E-VPN OAM Requirements and Framework October 15, 2012 Copyright and License Notice Copyright (c) 2012 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 (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to 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 are provided without warranty as described in the Simplified BSD License. Table of Contents 1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1 Relationship to Other OAM Work . . . . . . . . . . . . . . . 3 1.2 Specification of Requirements . . . . . . . . . . . . . . . 4 1.3 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 4 2 E-VPN OAM Framework . . . . . . . . . . . . . . . . . . . . . . 4 2.1 OAM Layering . . . . . . . . . . . . . . . . . . . . . . . . 4 2.2 E-VPN Service OAM . . . . . . . . . . . . . . . . . . . . . 5 2.3 E-VPN Network OAM . . . . . . . . . . . . . . . . . . . . . 5 2.4 Transport OAM for E-VPN . . . . . . . . . . . . . . . . . . 6 2.5 Link OAM . . . . . . . . . . . . . . . . . . . . . . . . . . 6 3 E-VPN OAM Requirements . . . . . . . . . . . . . . . . . . . . . 6 3.1 Fault Management Requirements . . . . . . . . . . . . . . . 6 3.1.1 Proactive Fault Management Functions . . . . . . . . . . 6 3.1.1.1 Fault Detection (Continuity Check) . . . . . . . . . 6 3.1.1.2 Defect Indication . . . . . . . . . . . . . . . . . 7 3.1.2 On-Demand Fault Management Functions . . . . . . . . . . 8 3.1.2.1 Connectivity Verification . . . . . . . . . . . . . 8 3.1.2.2 Fault Isolation . . . . . . . . . . . . . . . . . . 9 3.2 Performance Management . . . . . . . . . . . . . . . . . . . 9 3.2.1 Packet Loss . . . . . . . . . . . . . . . . . . . . . . 9 3.2.2 Packet Delay . . . . . . . . . . . . . . . . . . . . . . 9 4. Security Considerations . . . . . . . . . . . . . . . . . . . 10 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 6.1 Normative References . . . . . . . . . . . . . . . . . . . 10 6.2 Informative References . . . . . . . . . . . . . . . . . . 10 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 Salam et al. Expires April 18, 2013 [Page 2] INTERNET DRAFT E-VPN OAM Requirements and Framework October 15, 2012 1 Introduction This document specifies the requirements and defines a reference framework for Ethernet VPN (E-VPN) Operations, Administration and Maintenance (OAM, [RFC6291]). In this context, we use the term E-VPN OAM to loosely refer to the OAM functions required for and/or applicable to [E-VPN], [PBB-EVPN] as well as [TRILL-EVPN]. E-VPN introduces an L2VPN solution for multipoint Ethernet services, with advanced multi-homing capabilities, using BGP for distributing customer/client MAC address reach-ability information over the core MPLS/IP network. PBB-EVPN combines Provider Backbone Bridging (PBB) [802.1ah] with E- VPN in order to reduce the number of BGP MAC advertisement routes, provide client MAC address mobility using C-MAC aggregation and B-MAC 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. TRILL-EVPN provides a solution for interconnecting TRILL [TRILL] networks over an MPLS/IP network using E-VPN, with two key characteristics: C-MAC address transparency on the hand-off point and control-plane isolation among the interconnected TRILL networks. This document focuses on the fault management and performance management aspects of E-VPN OAM. 1.1 Relationship to Other OAM Work This document leverages concepts and draws upon elements defined and/or used in the following documents: [RFC6136] specifies the requirements and a reference model for OAM as it relates to L2VPN services, pseudowires and associated Public Switched Network tunnels. This document focuses on VPLS and VPWS solutions and services. [RFC4379] defines mechanisms for detecting data plane failures in MPLS LSPs, including procedures to check the correct operation of the data plane, as well as mechanisms to verify the data plane against the control plane. [802.1Q] specifies the Ethernet Connectivity Fault Management (CFM) protocol, which defines the concepts of Maintenance Domains, Maintenance End Points, and Maintenance Intermediate Points. [Y.1731] extends Connectivity Fault Management in the following Salam et al. Expires April 18, 2013 [Page 3] INTERNET DRAFT E-VPN OAM Requirements and Framework October 15, 2012 areas: it defines fault notification and alarm suppression functions for Ethernet. It also specifies mechanisms for Ethernet performance management, including loss, delay, jitter, and throughput measurement. 1.2 Specification of Requirements The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. 1.3 Terminology This document uses the following terminology defined in [RFC6136]: MEP Maintenance End Point is responsible for origination and termination of OAM frames for a given MEG. MIP Maintenance Intermediate Point is located between peer MEPs and can process and respond to certain OAM frames but does not initiate or terminate them. Maintenance Domain OAM Domain represents a region over which OAM frames can operate unobstructed. 2 E-VPN OAM Framework 2.1 OAM Layering Multiple layers come into play for implementing an L2VPN service with the E-VPN family of solutions: - The Service Layer runs end to end between the sites, or Ethernet Segments, that are being interconnected by the E-VPN solution. It can be either Ethernet (as in [E-VPN], [PBB-EVPN] and [SPB-EVPN]) or TRILL (as in [TRILL-EVPN]). - The Network Layer extends in between the E-VPN PE nodes and is mostly transparent to the core nodes (except where Flow Entropy comes into play). It leverages 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 either based on MPLS LSPs or IP. - The Link Layer is dependent upon the physical technology used. Ethernet is a popular choice for this layer, but other alternatives are deployed (e.g. POS, DWDM etc...). Salam et al. Expires April 18, 2013 [Page 4] INTERNET DRAFT E-VPN OAM Requirements and Framework October 15, 2012 This layering extends to the set of OAM protocols that are involved in the ongoing maintenance and diagnostics of E-VPN networks. The figure below depicts the OAM layering, and shows which devices have visibility into what OAM layer(s). +---+ +---+ +--+ | | +---+ +---+ +---+ | | +--+ |CE|----|PE1|----| P |----| P |----| P |----|PE2|----|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: E-VPN OAM Layering 2.2 E-VPN Service OAM The E-VPN Service OAM protocol depends on what service layer is being transported by the E-VPN solution. In case of [E-VPN] and [PBB-EVPN], the service OAM protocol is Ethernet Connectivity Fault Management (CFM) [802.1Q]. Whereas, in case of [TRILL-EVPN], the service OAM protocol is TRILL OAM [TRILL-OAM]. E-VPN service OAM is visible to the CEs and E-VPN PEs, but not to the core (P) nodes. This is because the PEs operate at the Ethernet MAC layer in [E-VPN][PBB-EVPN], or the TRILL RBridge layer in [TRILL- EVPN], whereas the P nodes do not. The E-VPN PE should support both MEP and MIP functions for the associated service OAM protocol. 2.3 E-VPN Network OAM E-VPN Network OAM is visible to the PE nodes only. This OAM layer is analogous to pseudowire OAM in the case of VPLS/VPWS. It provides capabilities to test connectivity for: - a given unicast MAC address in a bridge-domain within an EVI (to verify unicast connectivity) Salam et al. Expires April 18, 2013 [Page 5] INTERNET DRAFT E-VPN OAM Requirements and Framework October 15, 2012 - a given Ethernet Segment in an EVI (to verify the correct operation of Aliasing) - a given multicast group in a bridge-domain within an EVI (to verify multicast connectivity), including verification of the DF Election status and Split-Horizon filtering. For the E-VPN network OAM mechanisms to be truly in-band, their messages must be encoded so that they exhibit identical entropy characteristics to data traffic. 2.4 Transport OAM for E-VPN The transport OAM protocol depends on the nature of the underlying transport in the PSN. MPLS OAM mechanisms [RFC4379][RFC6425] as well as ICMP [RFC792] are applicable, depending on whether the PSN employs MPLS or IP transport, respectively. 2.5 Link OAM Link OAM depends on the data link technology being used between the PE and P nodes. For e.g., if Ethernet links are employed, then Ethernet Link OAM [802.3] Clause 57 may be used. 3 E-VPN OAM Requirements This section discusses the E-VPN OAM requirements pertaining to Fault Management and Performance Management. In a future revision of this document, we will identify the OAM layer(s) to which each of the requirements applies. 3.1 Fault Management Requirements 3.1.1 Proactive Fault Management Functions Proactive fault management functions are configured by the network operator to run periodically without a time bound, or are configured to trigger certain actions upon the occurrence of specific events. 3.1.1.1 Fault Detection (Continuity Check) Proactive fault detection is performed by periodically monitoring the reachability between service endpoints, i.e. MEPs in a given MA, through the exchange of Continuity Check messages. The reachability between any two arbitrary MEPs may be monitored for: - a specified path taken by a particular user data flow. This enables per Flow monitoring of data paths. E-VPN OAM must support per user Salam et al. Expires April 18, 2013 [Page 6] INTERNET DRAFT E-VPN OAM Requirements and Framework October 15, 2012 flow fault detection. - a representative path. This enables liveness check of the nodes hosting the MEPs but does not conclusively indicate liveness of the path(s) taken by user data traffic. This enables node failure detection but not path failure detection, through the use of a test flow. E-VPN OAM must support per test flow fault detection. - all paths. For MPLS/IP networks with ECMP, monitoring of all unicast paths between MEPs may not be possible, since the per-hop ECMP hashing behavior may yield situations where it is impossible for a MEP to pick flow entropy characteristics that result in exercising the exhaustive set of ECMP paths. Monitoring of all ECMP paths between MEPs is not a requirement for E-VPN OAM. The fact that MPLS/IP networks do not enforce congruency between unicast and multicast paths means that the proactive fault detection mechanisms for E-VPN must provide procedures to monitor the unicast paths independently of the multicast paths. 3.1.1.2 Defect Indication E-VPN OAM MUST support event-driven defect indication upon the detection of a connectivity defect. Defect indications can be categorized into two types: forward and reverse defect indications. 3.1.1.2.1 Forward Defect Indication This is used to signal a failure that is detected by a lower layer OAM mechanism. Forward Defect indication is transmitted by a server MEP (i.e. an actual or virtual MEP) in a direction that is away from the direction of the failure (refer to Figure 2 below). Failure | +-----+ +-----+ V +-----+ +-----+ | A |------| B |--XXX--| C |------| D | +-----+ +-----+ +-----+ +-----+ <===========| |============> Forward Forward Defect Defect Indication Indication Figure 2: Forward Defect Indication Forward defect indication may be used for alarm suppression and/or for purpose of inter-working with other layer OAM protocols. Alarm Salam et al. Expires April 18, 2013 [Page 7] INTERNET DRAFT E-VPN OAM Requirements and Framework October 15, 2012 suppression is useful when a transport/network level fault translates to multiple service or flow level faults. In such a scenario, it is enough to alert a network management station (NMS) of the single transport/network level fault in lieu of flooding that NMS with a multitude of Service or Flow granularity alarms. 3.1.1.2.2 Reverse Defect Indication (RDI) 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 failure (refer to Figure 3). Failure | +-----+ +-----+ V +-----+ +-----+ | A |------| B |--XXX--| C |------| D | +-----+ +-----+ +-----+ +-----+ |===========> <============| Reverse Reverse Defect Defect Indication Indication Figure 3: 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. 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 E-VPN OAM must support on-demand connectivity verification for unicast and multicast. The connectivity verification mechanism should provide a means for specifying and carrying in the messages: - variable length payload/padding to test MTU related connectivity problems. - test traffic patterns as defined in [RFC2544]. For multicast connectivity verification, E-VPN OAM must support Salam et al. Expires April 18, 2013 [Page 8] INTERNET DRAFT E-VPN OAM Requirements and Framework October 15, 2012 reporting on: - DF Election Status - Split Horizon Filtering Status 3.1.2.2 Fault Isolation E-VPN OAM must support an on-demand connectivity 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, renders fault isolation into a direction-sensitive operation. That is, given two PEs A and B, localization of connectivity faults between them requires running fault isolation procedures from PE A to PE B as well as from PE B to PE A. 3.2 Performance Management Performance Management functions can be performed both proactively and on-demand. Proactive management involves a scheduling function, where the performance management probes can be triggered on a recurring basis. Since the basic performance management functions involved are the same, we make no distinction between proactive and on-demand functions in this section. 3.2.1 Packet Loss E-VPN OAM must provide mechanisms for measuring packet loss for a given service. Given that E-VPN 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 RBridges 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 E-VPN OAM must support measurement of one-way and two-way packet delay and delay variation (jitter). Salam et al. Expires April 18, 2013 [Page 9] INTERNET DRAFT E-VPN OAM Requirements and Framework October 15, 2012 4. Security Considerations E-VPN 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 E-VPN 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. IANA Considerations None. 6. References 6.1 Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC6291] Andersson et al., BCP 161 "Guidelines for the Use of the "OAM" Acronym in the IETF", June 2011. [E-VPN] Sajassi et al., "BGP MPLS Based Ethernet VPN", draft-ietf- l2vpn-evpn-01.txt, work in progress, July 2012. [PBB-EVPN] Sajassi et al., "PBB-EVPN", draft-ietf-l2vpn-pbb-evpn- 03.txt, work in progress, June 2012. [TRILL-EVPN] Sajassi et al., "TRILL-EVPN", draft-ietf-l2vpn-trill- evpn-00.txt, work in progress, June 2012. 6.2 Informative References [802.1Q] "IEEE Standard for Local and metropolitan area networks - Media Access Control (MAC) Bridges and Virtual Bridge Local Area Networks", 31 August 2011. [Y.1731] "ITU-T Recommendation Y.1731 (02/08) - OAM functions and mechanisms for Ethernet based networks", February 2008. [TRILL-OAM] Senevirathne et al., "Requirements for Operations, Salam et al. Expires April 18, 2013 [Page 10] INTERNET DRAFT E-VPN OAM Requirements and Framework October 15, 2012 Administration and Maintenance (OAM) in TRILL", draft-ietf-trill-oam- req-01.txt, work in progress, August 2012. Authors' Addresses Samer Salam Cisco 595 Burrard Street, Suite 2123 Vancouver, BC V7X 1J1, Canada Email: ssalam@cisco.com Ali Sajassi Cisco 170 West Tasman Drive San Jose, CA 95134, USA Email: sajassi@cisco.com Sam Aldrin Huawei Technologies 2330 Central Express Way Santa Clara, CA 95951, USA Email: aldrin.ietf@gmail.com John E. Drake Juniper Networks 1194 N. Mathilda Ave. Sunnyvale, CA 94089, USA Email: jdrake@juniper.net Salam et al. Expires April 18, 2013 [Page 11]