NVO3 Operational Requirements
draft-ashwood-nvo3-operational-requirement-00

The information below is for an old version of the document
Document Type Active Internet-Draft (individual)
Authors Peter Ashwood-Smith  , Ali Sajassi 
Last updated 2012-06-14
Stream (None)
Formats pdf htmlized bibtex
Stream Stream state (No stream defined)
Consensus Boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date
Responsible AD (None)
Send notices to (None)
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]