Internet Engineering Task Force P. Ashwood-Smith Internet Draft R.Iyenger Intended status: Informational T. Tsou Expires: December 12, 2012 Huawei A. Sajassi Cisco June 12, 2012 NVO3 Operational Requirements draft-ashwood-nvo3-operational-requirement-00.txt Abstract This document provides framework and requirements for Network Virtualization over Layer 3 (NVO3) Operations, Administration, and Maintenance (OAM). This document for the most part gathers requirements from existing IETF drafts and RFCs which have already extensively studied this subject for different data planes and layering. As a result this draft is high level and broad. We begin to ask which are truely required for NVO3 and expect the list to be narrowed by the working group as subsequent versions of this draft are created. Status of this Memo This Internet-Draft is submitted 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/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html Ashwood-Smith, et al. Expires November 18 2012 Page 1] Internet-Draft OAM Requirements for NVO3 June 2012 This Internet-Draft will expire on December 14, 2012. Copyright 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. Table of Contents 1. Introduction 3 1.1. OSI Definitions of OAM 3 1.2. Specification of Requirements 5 1.3. Relationship with Other OAM Work 5 2. Terminology 6 3. NVO3 Reference Model 6 4. OAM Framework for NVO3 7 4.1. OAM Layering 8 4.2. OAM Domains 9 5. NVO3 OAM Requirements 9 5.1. Discovery 9 5.2. Connectivity Fault Management 9 5.2.1. Connectivity Fault Detection 9 5.2.2. Connectivity Fault Verification 10 5.2.3. Connectivity Fault localization 10 5.2.4. Connectivity Fault Notification and Alarm Suppression 10 5.3. Frame Loss 10 5.4. Frame Delay 10 5.5. Frame Delay Variation 10 5.6. Availability 10 5.7. Data Path Forwarding 11 5.8. Scalability 11 5.9. Extensibility 11 5.10. Security 11 5.11. Transport Independence 12 5.12. Application Independence 12 6. Security Considerations 12 7. IANA Considerations 12 8. References 12 8.1. Normative References 12 Ashwood-Smith, et al.Expires November 18, 2012 [Page 2] Internet-Draft OAM Requirements for NVO3 June 2012 8.2. Informative References 12 9. Authors' Addresses 13 10. Contributors 14 11. Acknowlegement 14 1. Introduction This document provides framework and requirements for Network virtualization over Layer 3(NVO3) Operation, Administration, and Maintenance (OAM). Given that this OAM subject is far from new and has been under extensive investigation by various IETF working groups (and several other standards bodies) for many years, this document draws from existing work, starting with RFC 6136 [L2VPN-OAM] "Layer 2 Virtual Private Network (L2VPN) Operations, Administration and Maintenance (OAM) Requirements and Framework" as a result sections of text have been reused with minor changes with the permission of these authors. NVO3 OAM requirements are expected to a be a subset of IETF/IEEE etc. work done so far however we begin with a full set and expect to prune through several iterations of this document. 1.1. OSI Definitions of OAM The scope of OAM for any service and/or transport/network infrastructure technologies can be very broad in nature. OSI has defined the following five generic functional areas commonly abbreviated as "FCAPS" [NM-Standards]: o Fault Management, o Configuration Management, o Accounting Management, o Performance Management, and o Security Management. This document focuses on the Fault and Performance Management aspects. Other functional aspects of FCAPS and their relevance (or not) to NVO3 are for further study. Fault Management can typically be viewed in terms of the following categories: Ashwood-Smith, et al.Expires November 18, 2012 [Page 3] Internet-Draft OAM Requirements for NVO3 June 2012 o Fault Detection o Fault Verification o Fault Isolation o Fault Notification and Alarm Suppression o Fault Recovery Fault detection deals with mechanism(s) that can detect both hard failures such as link and device failures, and soft failures, such as software failure, memory corruption, misconfiguration, etc. Typically, a lightweight protocol is desirable to detect the fault and thus it would be prudent to verify the fault via a fault verification mechanism before taking additional steps in isolating the fault. After verifying that a fault has occurred along the data path, it is important to be able to isolate the fault to the level of a given device or link. Therefore, a fault isolation mechanism is needed in Fault Management. A fault notification mechanism can be used in conjunction with a fault detection mechanism to notify the devices upstream and downstream to the fault detection point. For example, when there is a client/server relationship between two layered networks (for example the NVO3 layer would be a client of the outer IP server layer) while the inner IP layer would be a client of the NVO3 server layer 2); fault detection at the server layer may result in the following fault notifications: o Sending a forward fault notification from the server layer to the client layer network(s) using the fault notification format appropriate to the client layer. o Sending a backward fault notification at the server layer, if applicable, in the reverse direction. o Sending a backward fault notification at the client layer, if applicable, in the reverse direction. Finally, fault recovery deals with recovering from the detected failure by switching to an alternate available data path using alternate devices or links (e.g., device redundancy or link redundancy). Note, given that the IP network on which NVO3 resides is usually self healing, it is expected that recovery would not normally be required by the NVO3 layer. The special case of a static IP overlay network, or possibly a centrally Ashwood-Smith, et al.Expires November 18, 2012 [Page 4] Internet-Draft OAM Requirements for NVO3 June 2012 controlled IP overlay network may however require NVO3 involvement in fault recovery. Performance Management deals with mechanism(s) that allow determining and measuring the performance of the network/services under consideration. Performance Management can be used to verify the compliance to both the service-level and network-level metric objectives/specifications. Performance Management typically consists of measurement of performance metrics, e.g., Frame Loss, Frame Delay, Frame Delay Variation (aka Jitter), etc., across managed entities when the managed entities are in available state. Performance Management is suspended across unavailable managed entities. This document uses the above broad OAM definitions as a guide for the requirements. We recognize this is likely 'overkill' and that pruning will be required since the layers above and below NVO3 are already quite full featured. 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 [RFC2119]. 1.3. Relationship with Other OAM Work This document leverages requirements that originate with other OAM work, specifically the following: o [L2VPN-OAM] Layer 2 Virtual Private Network(L2VPN) Operations, Administration and Maintenance (OAM) Requirements and Framework. This document provides a template and some of the high level requirements and introduction wording. o [IEEE802.1ag] IEEE Std. 802.1ag-2007. This document is expected to provide a subset of the requirements for NVO3 both at the Tenant level and also within the L3 Overlay network. o [Y.1731] ITU-T Std. Y.1731. This document is expected to provide a subset of the requirements for NVO3 at the Tenant level. Ashwood-Smith, et al.Expires November 18, 2012 [Page 5] Internet-Draft OAM Requirements for NVO3 June 2012 o NVO3 Data Plane Requirements [NVO3-DP-REQ] (section 3.8 - OAM) lists several requirements specifically concerning ECMP/LAG. 2. Terminology The terminology defined in [NVO3-framework] and [NVO3-DP-REQS] is used throughtout this document. We introduce no new terminology. 3. NVO3 Reference Model Figure 1 below reproduces the generic NVO3 reference model as per [NVO3-Framework]. +--------+ +--------+ | Tenant | | Tenant | | End +--+ +---| End | | System | | | | System | +--------+ | ................... | +--------+ | +-+--+ +--+-+ | | | NV | | NV | | +--|Edge| |Edge|--+ +-+--+ +--+-+ / . L3 Overlay . \ +--------+ / . Network . \ +--------+ | Tenant +--+ . . +----| Tenant | | End | . . | End | | System | . +----+ . | System | +--------+ .....| NV |........ +--------+ |Edge| +----+ | | +--------+ | Tenant | | End | | System | +--------+ Figure 1 : Generic reference model for DC network virtualization over a Layer3 infrastructure Ashwood-Smith, et al.Expires November 18, 2012 [Page 6] Internet-Draft OAM Requirements for NVO3 June 2012 Figure 2 below, reproduces the Generic reference model for the NV Edge (NVE) as per [NVO3-DP-Reqs]. +------- L3 Network ------+ | | | Tunnel Overlay | +------------+--------+ +--------+------------+ | +----------+------+ | | +------+----------+ | | | Overlay Module | | | | Overlay Module | | | +--------+--------+ | | +--------+--------+ | | | VNID | | | VNID | | | | | | | | +-------+-------+ | | +-------+-------+ | | | VNI | | | | VNI | | NVE1 | +-+-----------+-+ | NVE2 | +-+-----------+-+ | | | VAPs | | | | VAPs | | +----+-----------+----+ +----+-----------+----+ | | | | -------+-----------+-----------------+-----------+------- | | Tenant | | | | Service IF | | Tenant End Systems Tenant End Systems Figure 2 - Generic reference model for NV Edge 4. OAM Framework for NVO3 Figure 1 shows the generic reference model for a DC network virtualization over an L3 (or L3VPN) infrastructure while Figure 2 shows the generic reference model for the NV Edge. L3 network(s) or L3 VPN networks (either IPV6 or IPV4), provide transport for an emulated layer 2 created by NV Edge devices. Unicast and multicast tunneling methods (demultiplexed by VNID) are used to provide connectivity between the NV Edge devices. The NV Edge devices then present an emulated layer 2 network to the Tenant End Systems at a VNI through VAPs. The NV Edge devices map layer 2 unicast to layer 3 unicast point-to-point tunnels and may either map layer 2 multicast to layer 3 multicast tunnels or may replicate packets onto multiple l3 unicast tunnels. Ashwood-Smith, et al.Expires November 18, 2012 [Page 7] Internet-Draft OAM Requirements for NVO3 June 2012 4.1. OAM Layering The emulated layer 2 network is provided by the NV Edge devices to which the Tenant End Systems are connected. This network of NV Edges can belong to a single network operator or can span across multiple network operators and / or administrative domains. Likewise the L3 Overlay Network can belong to a single network operator or can span across multiple network operators / administrative domains. While each of the layers is responsible for its own OAM, each layer may consist of several different administrative domains. OAM --- TENANT |----------------------------| TENANT {all IP/ETH} NV-Edge |----------------------| NV-Edge {t.b.d} IP(VPN) |---| IP (VPN) |---| IP(VPN) {IP(VPN)/ETH} Figure 3 : OAM layers in an NVO3 network For example, at the bottom, at the L3 IP overlay network layer IP(VPN) and/or Ethernet OAM mechanisms are used to probe link by link, node to node etc. OAM addressing here means physical node loopback or interface addresses. Further up, at the NV-Edge layer, NVO3 OAM messages are used to probe the NV-Edge to NV-Edge tunnels and NV-Edge entity status. OAM addressing here likely means the physical node loopback together with the VNI (to demultiplex the tunnels). Finally, at the Tenant layer, the IP and/or Ethernet OAM mechanisms are again used but here they are operating over the logical L2/L3 provided by the NV-Edge through the VAP. OAM addressing at this layer deals with the logical interfaces on Vswitches and Virtual Machines. Ashwood-Smith, et al.Expires November 18, 2012 [Page 8] Internet-Draft OAM Requirements for NVO3 June 2012 4.2. OAM Domains Complex OAM relationships exist as a result of the hierarchical layering of responsibility and of breaking up of end to end responsibility. The OAM domain above NVO3, is expected to be supported by existing IP and L2 OAM methods and tools. The OAM domain below NVO3, is expected to be supported by existing IP/L2 and MPLS OAM methods and tools. Where this layer is actually multiple domains spliced together, the existing methods to deal with these boundaries are unchanged. Note however that exposing LAG/ECMP detailed behavior may result in additional requirements to this domain. When we refer to an OAM domain in this document, or just 'domain', we therefore refer to a closed set of NVEs and the tunnels which interconnect them. 5. NVO3 OAM Requirements The following numbered requirements originate from [L2VPN-OAM]. All are included however where they seem obviously not relevant (to these authors) an explaination as to why is included. 5.1. Discovery R1) NVO3 OAM MUST allow an NV Edge device to discover other NV Edge devices that share the same VNI within a given NVO3 domain. 5.2. Connectivity Fault Management 5.2.1. Connectivity Fault Detection R2) NVO3 OAM MUST allow proactive connectivity monitoring between two NV Edge devices that support the same VNIs within a given NVO3 domain. R3) NVO3 OAM MUST allow monitoring/tracing of all possible paths between NV Edge devices such that equal cost paths that traverse LAG and/or ECMP may be differenciated. Ashwood-Smith, et al.Expires November 18, 2012 [Page 9] Internet-Draft OAM Requirements for NVO3 June 2012 5.2.2. Connectivity Fault Verification R4) NVO3 OAM MUST allow connectivity fault verification between two NV Edge devices that support the same VNI within a given NVO3 domain. 5.2.3. Connectivity Fault localization R5) NVO3 OAM MUST allow connectivity fault localization between two NV Edge devices that support the same instance within a given NVO3 domain. 5.2.4. Connectivity Fault Notification and Alarm Suppression R6) NVO3 OAM MUST support fault notification to be triggered as a result of the IP underlay network faults. This fault notification SHOULD be used for the suppression of redundant service-level alarms. 5.3. Frame Loss R7) NVO3 OAM MUST support measurement of per VNI frame/packet loss between two NV Edge devices that support the same VNI within a given NVO3 domain. 5.4. Frame Delay R8) NVO3 OAM MUST support measurement of per VNI two-way frame/packet delay between two NV edge devices that support the same VNI within a given NVO3 domain. R9) NVO3 OAM SHOULD support measurement of per VNI one-way frame/packet delay between two NV Edge devices that support the same VNI within a given NVO3 domain. 5.5. Frame Delay Variation R10) NVO3 OAM MUST support measurement of per VNI frame/packet delay variation between two NV Edge devices that support the same VNI within a given NVO3 domain. 5.6. Availability A service may be considered unavailable if the service frames/packets do not reach their intended destination (e.g., connectivity is down or frame/packet loss is occurring) or the service is degraded (e.g., frame/packet delay and/or delay Ashwood-Smith, et al.Expires November 18, 2012 [Page 10] Internet-Draft OAM Requirements for NVO3 June 2012 variation threshold is exceeded). Entry and exit conditions may be defined for the unavailable state. Availability itself may be defined in the context of a service type. Since availability measurement may be associated with connectivity, frame/packet loss, frame/packet delay, and frame/packet delay variation measurements, no additional requirements are specified currently. 5.7. Data Path Forwarding R11) NVO3 OAM frames MUST be forwarded along the same path (i.e., links (including LAG members) and nodes) as the NVO3 data frames. R12) NVO3 OAM frames MUST provide a mechanisms to exercise/trace all data paths that result due to ECMP/LAG hops. 5.8. Scalability R13) NVO3 OAM MUST be scalable such that an NV edge device can support proactive OAM for each VNI that is supported by the device. (Note - Likely very hard to achieve with hash based ECMP/LAG). 5.9. Extensibility R14) NVO3 OAM MUST be extensible such that new functionality and information elements related to this functionality can be introduced in the future. R15) NVO3 OAM MUST be defined such that devices not supporting the OAM are able to forward the OAM frames in a similar fashion as the regular NVO3 data frames/packets. 5.10. Security R16) NVO3 OAM frames MUST be prevented from leaking outside their NVO3 domain. R17) NVO3 OAM frames from outside an NVO3 domain MUST be prevented from entering the NVO3 domain when such OAM frames belong to the same level or to a lower-level OAM. (Trivially met because hierarchical domains are independent technologies) R18) NVO3 OAM frames from outside an NVO3 domain MUST be transported transparently inside the NVO3 domain when such OAM Ashwood-Smith, et al.Expires November 18, 2012 [Page 11] Internet-Draft OAM Requirements for NVO3 June 2012 frames belong to a higher-level NVO3 domain. (Trivially met because hierarchical domains are independent technologies). 5.11. Transport Independence Similar to transport requirement from [L2VPN-OAM], we expect NOV3 OAM will leverage the OAM capabilities of the transport layer (e.g., IP underlay). R19) NVO3 OAM MAY allow adaptation/interworking with its IP underlay OAM functions. For example, this would be useful to allow fault notifications from the IP layer to be sent to the NVO3 layer and likewise exposure of LAG / ECMP will require such non-independence. 5.12. Application Independence R20) NVO3 OAM MUST be independent of the application technologies and specific application OAM capabilities. 6. Security Considerations TBD. 7. IANA Considerations This memo includes no request to IANA. 8. References 8.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 8.2. Informative References [NVO3-framework] Lasserre, M. et al, "Framework for DC Network Virtualization", draft-lasserre-nvo3-framework work in progress) [NVO3-DP-Reqs] Bitar, N. Et al, "NVO3 Data Plane Requirements",draft-bl-nvo3-dataplane- requirements, (work in progress) Ashwood-Smith, et al.Expires November 18, 2012 [Page 12] Internet-Draft OAM Requirements for NVO3 June 2012 [IEEE802.1ag] "IEEE Standard for Local and metropolitan area networks - Virtual Bridged Local Area Networks, Amendment 5: Connectivity Fault Management", 2007. [IEEE802.1ah] "IEEE Standard for Local and metropolitan area networks - Virtual Bridged Local Area Networks, Amendment 6: Provider Backbone Bridges", 2008. [Y.1731] "ITU-T Recommendation Y.1731 (02/08) - OAM functions and mechanisms for Ethernet based networks", February 2008. [L2VPN-OAM] A. Sajassi and D. Mohan, "Layer 2 Virtual Private Network (L2VPN) Operations, Administration, and Maintenance (OAM) Requirements and Framework", RFC 6136, March 2011. [NM-Standards] "TMN Management Functions", M.3400, February 2000. 9. Authors' Addresses Peter Ashwood-Smith Huawei 303 Terry Fox Drive, Suite 400, Kanata, Ontario K2K 3J1 Email: Peter.AshwoodSmith@huawei.com Ranga Iyenger Huawei 2330 Central Expy, Santa Clara, CA 95050 Email: ranga.Iyenger@huawei.com Ashwood-Smith, et al.Expires November 18, 2012 [Page 13] Internet-Draft OAM Requirements for NVO3 June 2012 Ting Zou Huawei 2330 Central Expy, Santa Clara, CA 95050 Email: Tina.Tsou.Zouting@huawei.com Ali Sajassi Cisco 170 West Tasman Drive San Jose, CA 95134 Email: sajassi@cisco.com 10. Contributors We invite more contributors. 11. Acknowlegement We invite more feedback. Ashwood-Smith, et al.Expires November 18, 2012 [Page 14]