<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!-- One method to get references from the online citation libraries.
     There has to be one entity for each item to be referenced. 
     An alternate method (rfc include) is described in the references. -->

<!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC6136 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6136.xml">
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!-- used by XSLT processors -->
<!-- For a complete list and description of processing instructions (PIs), 
     please see http://xml.resource.org/authoring/README.html. -->
<!-- Below are generally applicable Processing Instructions (PIs) that most I-Ds might want to use.
     (Here they are set differently than their defaults in xml2rfc v1.32) -->
<?rfc strict="no" ?>
<!-- give errors regarding ID-nits and DTD validation -->
<!-- control the table of contents (ToC) -->
<?rfc toc="yes"?>
<!-- generate a ToC -->
<?rfc tocdepth="4"?>
<!-- the number of levels of subsections in ToC. default: 3 -->
<!-- control references -->
<?rfc symrefs="yes"?>
<!-- use symbolic references tags, i.e, [RFC2119] instead of [1] -->
<?rfc sortrefs="yes" ?>
<!-- sort the reference entries alphabetically -->
<!-- control vertical white space 
     (using these PIs as follows is recommended by the RFC Editor) -->
<?rfc compact="yes" ?>
<!-- do not start each main section on a new page -->
<?rfc subcompact="no" ?>
<!-- keep one blank line between list items -->
<!-- end of list of popular I-D processing instructions -->

<rfc category="info" docName="draft-ashwood-nvo3-operational-requirement-03" ipr="trust200902">
  <!-- category values: std, bcp, info, exp, and historic
     ipr values: trust200902, noModificationTrust200902, noDerivativesTrust200902
     pre5378Trust200902
     you can add the attributes updates="NNNN" and obsoletes="NNNN" 
     they will automatically be output with "(if approved)" -->

  <!-- ***** FRONT MATTER ***** -->

  <front>
    <!-- The abbreviated title is used in the page header - it is only necessary if the 
         full title is longer than 39 characters -->

    <title>NVO3 Operational Requirements</title>

    <author fullname="Peter Ashwood-Smith" initials="P." 
           surname="Ashwood-Smith">
      <organization>Huawei Technologies</organization>
      <address>
        <postal>
          <street>303 Terry Fox Drive, Suite 400</street>
          <!-- Reorder these if your country does things differently -->
          <city>Kanata</city>
          <region>Ontario</region>
          <country>Canada</country>
          <code>K2K 3J1</code>
        </postal>
        <phone>+1 613 595-1900</phone>
        <email>Peter.AshwoodSmith@huawei.com</email>

        <!-- uri and facsimile elements may also be added -->
      </address>
    </author>

    <author fullname="Ranga Iyengar" initials="R." surname="Iyengar">
      <organization>Huawei Technologies USA</organization>
      <address>
        <postal>
          <street>2330 Central Expy</street>
          <!-- Reorder these if your country does things differently -->
          <city>Santa Clara</city>
          <region>CA</region>
          <code>95050</code>
          <country>USA</country>
        </postal>
        <phone></phone>
        <email>ranga.Iyengar@huawei.com</email>

        <!-- uri and facsimile elements may also be added -->
      </address>
    </author>

     <author fullname="Tina Tsou" initials="T." surname="Tsou">
       <organization>Huawei Technologies USA</organization>
      <address>
        <postal>
          <street>2330 Central Expy</street>
          <!-- Reorder these if your country does things differently -->
          <city>Santa Clara</city>
          <region>CA</region>
          <code>95050</code>
          <country>USA</country>
        </postal>
        <phone></phone>
        <email>Tina.Tsou.Zouting@huawei.com</email>

        <!-- uri and facsimile elements may also be added -->
      </address>
    </author>

    <author fullname="Ali Sajassi" initials="A." surname="Sajassi">
      <organization>Cisco Technologies</organization>
      <address>
        <postal>
          <street>170 West Tasman Drive</street>
          <!-- Reorder these if your country does things differently -->
          <city>San Jose</city>
          <region>CA</region>
          <code>95134</code>
          <country>USA</country>
        </postal>
        <phone></phone>
        <email>sajassi@cisco.com</email>

        <!-- uri and facsimile elements may also be added -->
      </address>
    </author>

    <author fullname="Mohamed Boucadair" initials="M." surname="Boucadair">
      <organization>France Telecom</organization>
      <address>
        <postal>
          <street></street>
          <!-- Reorder these if your country does things differently -->
          <city>Rennes</city>
          <region></region>
          <code>35000</code>
          <country>France</country>
        </postal>
        <phone></phone>
        <email>mohamed.boucadair@orange.com</email>

        <!-- uri and facsimile elements may also be added -->
      </address>
    </author>

    <author fullname="Christian Jacquenet" initials="C." surname="Jacquenet">
      <organization>France Telecom</organization>
      <address>
        <postal>
          <street></street>
          <!-- Reorder these if your country does things differently -->
          <city>Rennes</city>
          <region></region>
          <code>35000</code>
          <country>France</country>
        </postal>
        <phone></phone>
        <email>christian.jacquenet@orange.com</email>

        <!-- uri and facsimile elements may also be added -->
      </address>
    </author>

    <author fullname="Masahiro Daikoku" initials="M." surname="Daikoku">
      <organization>KDDI corporation</organization>
      <address>
        <postal>
          <street>3-10-10, Iidabashi, Chiyoda-ku</street>
          <!-- Reorder these if your country does things differently -->
          <city></city>
          <region>Tokyo</region>
          <code>1028460</code>
          <country>Japan</country>
        </postal>
        <phone></phone>
        <email>ms-daikoku@kddi.com</email>

        <!-- uri and facsimile elements may also be added -->
      </address>
    </author>

   <date year="2013" />

    <!-- If the month and year are both specified and are the current ones,
    xml2rfc will fill in the current day for you. If only the current year is
    specified, xml2rfc will fill in the current day and month for you. If the
    year is not the current one, it is necessary to specify at least a month
    (xml2rfc assumes day="1" if not specified for the purpose of calculating
    the expiry date).  With drafts it is normally sufficient to specify just
    the year. -->

    <!-- Meta-data Declarations -->

    <area>General</area>

    <workgroup>Internet Engineering Task Force</workgroup>

    <!-- WG name at the upperleft corner of the doc,
         IETF is fine for individual submissions.  
	 If this element is not present, the default is "Network Working Group",
         which is used by the RFC Editor as a nod to the history of the IETF. -->

    <keyword>network virtualization over layer 3</keyword>
    <keyword>NVO3</keyword>

    <!-- Keywords will be incorporated into HTML output
         files in a meta tag but they have no effect on text or nroff
         output. If you submit your draft to the RFC Editor, the
         keywords will be used for the search engine. -->

    <abstract>
      <t>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 truly required for NVO3 and 
      expect the list to be narrowed by the working group as 
      subsequent versions of this draft are created.</t>
    </abstract>
  </front>

  <middle>
    <section title="Introduction">

      <t>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 
      <xref target="RFC6136"/>. As a result, sections of 
      <xref target="RFC6136"/> have been reused 
      with minor changes with the permission of the authors. </t> 

      <t>NVO3 OAM requirements are expected to be a subset of 
      IETF/IEEE etc. work done so far; however, we begin with a full 
      set of requirements and expect to prune them through several
      iterations of this document. </t>

      <section title="OSI Definitions of OAM" anchor="OSIdef">

        <t>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]: 
        <list style="symbols">
          <t>Fault Management,</t>

          <t>Configuration Management,</t> 

          <t>Accounting Management,</t>  

          <t>Performance Management, and</t>  

          <t>Security Management.</t>
        </list>
        </t> 

        <t>This document focuses on the Fault, Performance and to a limited
        extent the Configuration Management aspects. Other functional aspects of
        FCAPS and their relevance (or not) to NVO3 are for further study.</t> 

        <t>Fault Management can typically be viewed in terms of the 
        following categories:
        <list style="symbols">
          <t>Fault Detection;</t> 

          <t>Fault Verification;</t>        
          
          <t>Fault Isolation;</t> 

          <t>Fault Notification and Alarm Suppression;</t> 

          <t>Fault Recovery.</t>
        </list>
        </t>

        <t>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. Fault detection relies upon a set of mechanisms
        that first allow the observation of an event, then the use of a protocol 
        to dynamically notify a network/system operator (or management system) 
        about the event occurrence, then the use of diagnostic tools to assess
        the nature and severity of the fault.</t>
        
        <t>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 should be used in conjunction with a fault detection mechanism to
        notify the devices upstream and downstream to the fault
        detection point. The fault notification mechanism should also notify NMS
        systems.
        <list style="empty">
          <t>The terms "upstream" and "backward" are used here to denote the
          direction(s) from which data traffic is flowing. The terms "downstream"
          and "forward" denote the direction(s) to which data traffic is
          forwarded.</t> 
        </list>
        </t>
               
        <t>For example, when there is a client/server relationship between two
        layered networks (e.g., the NVO3 layer is a client of the
        outer IP server layer, while the inner IP layer is a client of
        the NVO3 server layer 2), fault detection at the server layer may
        result in the following fault notifications:
        <list style="symbols">
          <t>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.</t>

          <t>Sending a backward fault notification to the server 
          layer, if applicable, in the reverse direction.</t>

          <t>Sending a backward fault notification to the client
          layer, if applicable, in the reverse direction.</t>
        </list>
        </t>

        <t>Finally, fault recovery deals with recovering from the 
        detected failure by switching to an alternate available data
        path (depending on the nature of the fault) using alternate
        devices or links. In fact, the controller can provision another virtual
        network, thus automatically resolving the reported problem.</t>
        
        <t>The controller may also directly monitor the status of virtual
        network components such as Network Virtualization Edge elements (NVEs)
        <xref target="NVO3-framework"/> in order to respond to their failures.
        In addition to forward and backward fault notifications, the controller
        may deliver notifications to a higher level orchestration component,
        e.g., one responsible for Virtual Machine (VM) provisioning and
        management.</t> 
        
        <t>Note, given that the IP network on which NVO3 resides is usually self
        healing, it is expected that recovery by the NVO3 layer would not
        normally be required, although there may be a requirement for that layer
        to log that the problem has been detected and resolved. The special
        cases of a static IP overlay network, or possibly of a centrally
        controlled IP overlay network, may, however, require NVO3 involvement in
        fault recovery.</t> 

        <t>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
        measuring performance metrics, e.g., Frame Loss, Frame Delay, Frame
        Delay Variation (aka Jitter), Frame throughput, Frame discard, etc.,
        across managed entities when the managed entities are in available
        state. Performance Management is suspended across unavailable managed
        entities.</t>
        
      </section>  <!-- OSIdef -->

      <section title="Requirements Language">

        <t>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 <xref target="RFC2119"/>.</t>

      </section>

      <section title="Relationship with Other OAM Work">

        <t>This document leverages requirements that originate with
        other OAM work, specifically the following: 
        <list style="symbols">
          <t><xref target="RFC6136"/> provides a template and some of
          the high level requirements and introductory wording.</t>  

          <t><xref target="IEEE802.1ag"/> is expected to provide a 
          subset of the requirements for NVO3 both at the Tenant level
          and also within the L3 Overlay network.</t> 

          <t><xref target="Y.1731"/> is expected to provide a subset 
          of the requirements for NVO3 at the Tenant level.</t>

          <t>Section 3.8 of <xref target="NVO3-DP-Reqs"/> lists several
          requirements specifically concerning ECMP/LAG.</t>
        </list>
        </t> 

      </section>

    </section> <!-- Introduction -->

    <section title="Terminology">

      <t>The terminology defined in <xref target="NVO3-framework"/>
      and <xref target="NVO3-DP-Reqs"/> is used throughout this 
      document. We introduce no new terminology. </t>

    </section>

    <section title="NVO3 Reference Model" anchor="refModel">

      <t><xref target="fig1"/> below reproduces the generic NVO3
      reference model as per <xref target="NVO3-framework"/>.</t>

      <figure title="Generic reference model for DC network virtualization over a Layer3 infrastructure" anchor="fig1">
        <artwork>
  +--------+                                  +--------+ 
  | Tenant |                                  | Tenant | 
  |  End   +--+                           +---|  End   | 
  | System |  |                           |   | System | 
  +--------+  |    ...................    |   +--------+ 
              |  +-+--+           +--+-+  | 
              |  | NV |           | NV |  | 
              +--|Edge|           |Edge|--+ 
                 +-+--+           +--+-+ 
                /  .    L3 Overlay   .  \ 
  +--------+   /   .     Network     .   \     +--------+ 
  | Tenant +--+    .                 .    +----| Tenant | 
  |  End   |       .                 .         |  End   | 
  | System |       .    +----+       .         | System | 
  +--------+       .....| NV |........         +--------+ 
                        |Edge| 
                        +----+ 
                          | 
                          | 
                       +--------+ 
                       | Tenant | 
                       |  End   | 
                       | System | 
                       +--------+ 
        </artwork>
      </figure>

      <t><xref target="fig2"/> below, reproduces the Generic reference
      model for the NV Edge (NVE) as per 
      <xref target="NVO3-DP-Reqs"/>.</t>

      <figure title="Generic reference model for NV Edge" 
          anchor="fig2">
        <artwork>
                  +------- L3 Network ------+ 
                  |                         | 
                  |       Tunnel Overlay    | 
     +------------+---------^-+       +--------+-------------^-+ 
     | +----------+------+  | |       | +------+----------+  | | 
     | | Overlay Module  |  | |       | | Overlay Module  |  | | 
     | +--------+--------+  | |       | +--------+--------+  | | 
     |          | VNID      | |       |          | VNID      | | 
     |          |         OAM |       |          |         OAM | 
     |  +-------+-------+   | |       |  +-------+-------+   | | 
     |  |      VNI      |   | |       |  |      VNI      |   | | 
NVE1 |  +-+-----------+-+   | |  NVE2 |  +-+-----------+-+   | | 
     |    |   VAPs    |     | |       |    |   VAPs    |     | | 
     +----+-----------+-----V-+       +----+-----------+-----V-+ 
          |           |                 |           | 
   -------+-----------+--------------------+-----------+-----_-- 
          |           |        Tenant      |           | 
          |           |      Service IF    |           | 
        Tenant End Systems               Tenant End Systems 
        </artwork>
      </figure>

    </section> <!-- refModel -->

    <section title="OAM Framework for NVO3" anchor="frame">

      <t><xref target="fig1"/> showed the generic reference model for
      a DC network virtualization over an L3 (or L3VPN) infrastructure
      while <xref target="fig2"/> showed the generic reference model
      for the Network Virtualization (NV) Edge.</t> 

      <t>L3 network(s) or L3 VPN networks (either IPv6 or IPv4, or 
      a combination thereof), provide transport for an emulated layer
      2 created by NV Edge devices. Unicast and multicast tunneling 
      methods (de-multiplexed by Virtual Network Identifier (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 Virtual Network Interface (VNI) 
      through Virtual Access Points (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 layer 3 unicast tunnels.
      </t>

      <section title="OAM Layering">

        <t>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 be operated by a single service 
        provider or can span across multiple administrative domains. Likewise,
        the L3 Overlay Network can be operated by a single service
        provider or span across multiple administrative domains.</t>

        <t>While each of the layers is responsible for its own OAM,
        each layer may consist of several different administrative 
        domains. <xref target="fig3"/> shows an example.</t>

        <figure title="OAM layers in an NVO3 network" anchor="fig3">
          <artwork>
                                                       OAM 
                                                       --- 

   TENANT    |----------------------------| TENANT {all IP/ETH} 
         
   NV Edge   |----------------------|  NV Edge     {t.b.d.} 
  
   IP(VPN)   |---| IP (VPN) |---| IP(VPN)          {IP(VPN)/ETH}
          </artwork>
        </figure> 

        <t>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.</t> 

        <t>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 de-multiplex the 
        tunnels).</t>  

        <t>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.
        </t>

      </section> <!-- layering -->

      <section title="OAM Domains">

        <t>Complex OAM relationships exist as a result of the 
        hierarchical layering of responsibility and of breaking up of
        end-to-end responsibility.</t> 

        <t>The OAM domain above NVO3, is expected to be supported by 
        existing IP and L2 OAM methods and tools.</t> 

        <t>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, the details of which will be
        specified in the future versions of this draft.</t> 

        <t>When we refer to an OAM domain in this document, or just 
        'domain', we therefore refer to a closed set        
        of NV Edges and the tunnels which interconnect them. Inter-domain OAM
        considerations will be specified in the future versions of this
        draft.</t> 

      </section>

    </section> <!-- frame -->

    <section title="NVO3 OAM Requirements">

      <t>The following numbered requirements originate from 
      <xref target="RFC6136"/>. All are included however where they 
      seem obviously not relevant (to the present authors) an 
      explanation as to why is included.</t>

      <section title="Discovery">

        <t>R1) NVO3 OAM MUST allow an NV Edge device to dynamically 
        discover other NV Edge devices that share the same VNI within
        a given NVO3 domain. This may be based on a discovery mechanism used to
        set up data path forwarding between NVEs.</t> 

      </section>

      <section title="Connectivity Fault Management">

        <section title="Connectivity Fault Detection">
          
          <t>R2) NVO3 OAM MUST allow proactive connectivity monitoring between
          two or more NV Edge devices that support the same VNIs within a given
          NVO3 domain. NVO3 OAM MAY act as a protection trigger. That is,
          automatic recovery from transmission facility failure by switchover to
          a redundant replacement facility may be triggered by notifications
          from NVO3 OAM.</t> 
          
          <t>R3) NVO3 OAM MUST allow monitoring/tracing of all possible paths in
          the underlay network between a specified set of two or more NV Edge
          devices. Using this feature, equal cost paths that traverse LAG and/or
          ECMP may be differentiated. </t> 

        </section>

        <section title="Connectivity Fault Verification"> 

          <t>R4) NVO3 OAM MUST allow connectivity fault verification
          between two or more NV Edge devices that support the same VNI 
          within a given NVO3 domain.</t> 

        </section>

        <section title="Connectivity Fault localization">

          <t>R5) NVO3 OAM MUST allow connectivity fault localization between 
          two or more NV Edge devices that support the same VNI within a 
          given NVO3 domain.</t> 

        </section>

        <section title="Connectivity Fault Notification and Alarm Suppression">

          <t>R6) NVO3 OAM MUST support fault notification to be triggered as a
          result of the faults occurring in the underneath network
          infrastructure. This fault notification SHOULD be used for the
          suppression of redundant service-level alarms.</t> 

        </section>

      </section> <!-- Connect fault mgmt -->

      <section title="Frame Loss">

        <t>R7) NVO3 OAM MUST support measurement of per VNI frame 
        loss between two NV Edge devices that support the same VNI 
        within a given NVO3 domain.</t> 

      </section>

      <section title="Frame Delay"> 

        <t>R8) NVO3 OAM MUST support measurement of per VNI two-way 
        frame delay between two NV edge devices that support 
        the same VNI within a given NVO3 domain.</t>

        <t>R9) NVO3 OAM MUST support measurement of per VNI one-way
        frame delay between two NV Edge devices that support the same
        VNI within a given NVO3 domain.</t>

      </section> 

      <section title="Frame Delay Variation"> 

        <t>R10) NVO3 OAM MUST support measurement of per VNI 
        frame delay variation between two NV Edge devices that
        support the same VNI within a given NVO3 domain.</t> 

      </section> 

      <section title="Frame Throughput"> 

        <t>R11) NVO3 OAM MAY [*** Should this be stronger? ***] support
        measurement of per VNI frame throughput throughput (in frames and bytes)
        between two NV Edge devices that support the same VNI within a given
        NVO3 domain. This feature could be an effective way to confirm whether
        or not assigned path bandwidth conforms to service level agreement
        before providing the path between two NV Edge devices. </t> 

      </section> 

      <section title="Frame Discard"> 

        <t>R12) NVO3 OAM MAY support measurement of per VNI 
        frame discard between two NV Edge devices that
        support the same VNI within a given NVO3 domain. This feature
        MAY be effective to monitor bursty traffic between two 
        NV Edge devices.</t> 

      </section> 

      <section title="Availability"> 

        <t>A service may be considered unavailable if the service
        frames/packets do not reach their intended destination (e.g.,
        connectivity is down) or the service is degraded (e.g., frame
        loss and/or frame delay and/or delay 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 loss, frame delay, and
        frame delay variation measurements, no additional requirements
        are specified currently. </t>

      </section> 

      <section title="Data Path Forwarding"> 

        <t>R13) NVO3 OAM frames MUST be forwarded along the same path 
        (i.e., links (including LAG members) and nodes) as the NVO3 
        data frames.</t> 

        <t>R14) NVO3 OAM frames MUST provide a mechanism to 
        exercise/trace all data paths that result due to ECMP/LAG 
        hops in the underlay network.
        </t>

      </section> 

      <section title="Scalability"> 

        <t>R15) 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).</t>

      </section> 

      <section title="Extensibility"> 

        <t>R16) NVO3 OAM should be extensible such that new 
        functionality and information elements related to this 
        functionality can be introduced in the future.</t> 

        <t>R17) 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.</t> 

      </section> 

      <section title="Security"> 

        <t>R18) NVO3 OAM frames MUST be prevented from leaking outside 
        their NVO3 domain.</t>  

        <t>R19) NVO3 OAM frames from outside an NVO3 domain MUST be 
        prevented from entering the said 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.)
        </t>

        <t>R20) NVO3 OAM frames from outside an NVO3 domain MUST be 
        transported transparently inside the NVO3 domain when such OAM
        frames belong to a higher-level NVO3 domain. (Trivially met 
        because hierarchical domains are independent technologies).
        </t>
        
      </section> 

      <section title="Transport Independence"> 

        <t>Similar to transport requirement from 
        <xref target="RFC6136"/>, we expect NVO3 OAM will leverage the
        OAM capabilities of the transport layer (e.g., IP underlay).
        </t> 

        <t>R21) 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.</t>

      </section> 

      <section title="Application Independence"> 

        <t>R22) NVO3 OAM MUST [*** discuss -- is this too strong? ***] be
        independent of the application technologies and specific application OAM
        capabilities.</t> 
        
        <t>[Comment -- ECM: Noticed Nicira implementation has a dedicated NVP
        manager node to play the role of FCAPS here. It is both application
        layer and OAM layer. May not meet this requirement. In reality, due to
        the nature of overlay network, very often, vendors are going to make
        everything all together to a dedicated manager node.]</t> 

      </section>
      
      <section title="Prioritization">

        <t>R23) NVO3 OAM messages MUST be preferentially treated in NVE and between
        NVEs, since NVO3 OAM MAY be used to trigger protection switching. As
        noted above (R2), protection switching is the automatic replacement of a
        failed transmission facility with a working one providing equal or
        greater capacity, typically within a few tens of milliseconds from fault
        detection. </t> 
        
        <t>[Comment -- ECM: giving NVO3 OAM messages priority treatment may
        interfere with measurements of frame delay and jitter.]</t> 
        
      </section>  <!--   -->

    </section>  <!-- OAM reqs -->

    <section title="Items for Further Discussion">

      <t>This section identifies a set of operational items which may
      be elaborated further if these items fall within the scope of
      the NVO3.
      <list style="symbols">
        <t>VNID renumbering support
        <list style="symbols">
          <t>Means to change the VNID assigned to a given instance 
          MUST [*** discuss: is this too strong? ***] be supported.</t> 
          
          <t>System convergence subsequent to VNID renumbering MUST NOT take
          longer than a few seconds, to minimize impact on the tenant systems. </t> 
          
          <t>A VNE MUST be able to map a VNID with a virtual network 
          context.</t>
        </list>
        </t>

        <t>VNI migration and management operations
        <list style="symbols">
          <t>Means to delete an existing VNI MUST be supported.</t> 

          <t>Means to add a new VNI MUST be supported.</t>

          <t>Means to merge several VNIs MAY be supported.</t>

          <t>Means to retrieve reporting data per VNI MUST be 
          supported.</t>

          <t>Means to monitor the network resources per VNI MUST be 
          supported.</t> 
        </list>
        </t>

        <t>Support of planned maintenance operations on the NVO3 
        infrastructure
        <list style="symbols">
          <t>Graceful procedure to allow for planned maintenance operation on
          NVE MUST be supported. This includes undoing any configuration changes
          made for maintenance purposes after completion of the maintenance.</t> 
        
        </list>
        </t>

        <t>Support for communication among virtual networks
        <list style="symbols">
          <t>For global reachability purposes, communication among virtual
          networks MUST be supported. This can be enforced using a NAT
          function.</t> 
        </list>
        </t>

        <t>Activation of new network-related services to the NVO3
        <list style="symbols">
          <t>Means to assist in activating new network services 
          (e.g., multicast) without impacting running service should 
          be supported.</t>
        </list>
        </t>

        <t>Inter-operator NVO3 considerations
        <list style="symbols">
          <t>As NVO3 may be deployed over inter-operator 
          infrastructure, coordinating OAM actions in each individual
          domain are required to ensure an end-to-end OAM. In particular, 
          this assumes existence of agreements on the measurement and
          monitoring methods, fault detection and repair actions, 
          extending QoS classes (e.g., DSCP mapping policies), etc.
          <list> 
            <t>[[DISCUSSION NOTE: Should inter-operator issues be 
            declared out of scope?]]</t>
          </list>
          </t>
        </list>
        </t>
      </list>
      </t>

    </section>

    <section anchor="IANA" title="IANA Considerations">

      <t>This memo includes no request to IANA.</t>

    </section>

    <section anchor="Security" title="Security Considerations">

      <t>TBD</t>

    </section>
    
    <section anchor="ack" title="Acknowledgements">

      <t>The authors are grateful for the contributions of David Black, Dennis
      Qin, Erik Smith and Ziye Yang to this latest version.</t> 

    </section>  <!-- ack -->
  </middle>

  <!--  *****BACK MATTER ***** -->

  <back>
    <!-- References split into informative and normative -->

    <references title="Normative References">

      &RFC2119;

    </references>

    <references title="Informative References">

      &RFC6136;

       <reference anchor="NVO3-framework">
        <front>
          <title>Framework for DC Network Virtualization</title>

          <author initials="M." surname="Lasserre">
            <organization>Alcatel-Lucent</organization>
          </author>

          <author initials="F." surname="Balus">
            <organization>Alcatel-Lucent</organization>
          </author>

          <author initials="T." surname="Morin">
            <organization>France Telecom Orange</organization>
          </author>

          <author initials="N." surname="Bitar">
            <organization>Verizon</organization>
          </author>

          <author initials="Y." surname="Rekhter">
            <organization>Juniper</organization>
          </author>

          <date month="July" year="2012" />
        </front>
      </reference>

      <reference anchor="NVO3-DP-Reqs">
        <front>
          <title>NVO3 Data Plane Requirements</title>

          <author initials="N." surname="Bitar">
            <organization>Verizon</organization>
          </author>

          <author initials="M." surname="Lasserre">
            <organization>Alcatel-Lucent</organization>
          </author>

          <author initials="F." surname="Balus">
            <organization>Alcatel-Lucent</organization>
          </author>

          <author initials="T." surname="Morin">
            <organization>France Telecom Orange</organization>
          </author>

          <author initials="L." surname="Jin">
            <organization>ZTE</organization>
          </author>

          <author initials="B." surname="Khasnabish">
            <organization>ZTE</organization>
          </author>

          <date month="October" year="2012" />
        </front>
      </reference>

      <reference anchor="IEEE802.1ag">
        <front>
          <title>IEEE Standard for Local and metropolitan area networks - Virtual Bridged Local Area Networks, Amendment 5: Connectivity Fault Management</title>

          <author initials="" surname="">
            <organization>IEEE</organization>
          </author>

          <date year="2007" />
        </front>
      </reference>

      <reference anchor="IEEE802.1ah">
         <front>
          <title>IEEE Standard for Local and metropolitan area networks - Virtual Bridged Local Area Networks, Amendment 6: Provider Backbone Bridges</title>

          <author initials="" surname="">
            <organization>IEEE</organization>
          </author>

          <date year="2008" />
        </front>
      </reference>

      <reference anchor="Y.1731">
        <front>
          <title>ITU-T Recommendation Y.1731 (02/08) - OAM functions and mechanisms for Ethernet based networks</title>

          <author initials="" surname="">
            <organization>ITU-T</organization>
          </author>

          <date month="February" year="2008" />
        </front>
      </reference>

      <reference anchor="NM-Standards">
        <front>
          <title>ITU-T Recommendation M.3400 (02/2000) - TMN Management Functions</title>

          <author initials="" surname="">
            <organization>ITU-T</organization>
          </author>

          <date month="February" year="2000" />
        </front>
      </reference>
    </references>

  </back>
</rfc>
