<?xml version="1.0" encoding="US-ASCII"?>
<!-- edited with XMLSPY v5 rel. 3 U (http://www.xmlspy.com)
     by Daniel M Kohn (private) -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY RFC1157 PUBLIC ""
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.1157.xml">
<!ENTITY RFC3410 PUBLIC ""
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.3410.xml">
<!ENTITY RFC4176 PUBLIC ""
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.4176.xml">
<!ENTITY RFC4379 PUBLIC ""
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.4379.xml">
<!ENTITY RFC4443 PUBLIC ""
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.4443.xml">
<!ENTITY RFC4656 PUBLIC ""
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.4656.xml">
<!ENTITY RFC5357 PUBLIC ""
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.5357.xml">
<!ENTITY RFC5706 PUBLIC ""
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.5706.xml">
<!ENTITY RFC5880 PUBLIC ""
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.5880.xml">
<!ENTITY RFC6020 PUBLIC ""
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.6020.xml">
<!ENTITY RFC6123 PUBLIC ""
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.6123.xml">
<!ENTITY RFC6241 PUBLIC ""
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.6241.xml">
<!ENTITY RFC6291 PUBLIC ""
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.6291.xml">
<!ENTITY RFC6310 PUBLIC ""
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.6310.xml">
<!ENTITY RFC6374 PUBLIC ""
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.6374.xml">
<!ENTITY RFC6378 PUBLIC ""
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.6378.xml">
<!ENTITY RFC6428 PUBLIC ""
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.6428.xml">
<!ENTITY RFC7023 PUBLIC ""
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.7023.xml">
<!ENTITY RFC7276 PUBLIC ""
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.7276.xml">
]>
<rfc category="info" docName="draft-edprop-opsawg-multi-layer-oam-ps-02.txt"
     ipr="trust200902">
  <?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>

  <?rfc toc="yes" ?>

  <?rfc symrefs="yes" ?>

  <?rfc sortrefs="yes"?>

  <?rfc iprnotified="no" ?>

  <?rfc strict="yes" ?>

  <front>
    <title abbrev="Layer Independent OAM">Problem Statement for Layer
    and Technology Independent OAM in a Multi-Layer Environment</title>

    <author fullname="Qin Wu" initials="Q." surname="Wu">
      <organization>Huawei</organization>

      <address>
        <postal>
          <street>101 Software Avenue, Yuhua District</street>

          <city>Nanjing</city>

          <region>Jiangsu</region>

          <code>210012</code>

          <country>China</country>
        </postal>

        <email>bill.wu@huawei.com</email>
      </address>
    </author>

    <author fullname="Mishael Wexler" initials="M." surname="Wexler">
      <organization>Huawei</organization>

      <address>
        <postal>
          <street>Riesstr. 25</street>

          <region>Munich</region>

          <code>80992</code>

          <country>Germany</country>
        </postal>

        <email>mishael.wexler@huawei.com</email>
      </address>
    </author>
    
    <author initials="D." surname="Romascanu" fullname="Dan Romascanu">
      <organization>AVAYA</organization>
      <address>
        <postal>
          <street>Park Atidim, Bldg. #3</street>
          <city>Tel Aviv</city>
          <region></region>
          <code>61581</code>
          <country>Israel</country>
        </postal>
        <phone></phone>
        <email>dromasca@avaya.com</email>
      </address>
    </author>

    <author initials="T." surname="Taylor" fullname="T. Taylor"
     role="editor">
      <organization>PT Taylor Consulting</organization>
      <address>
        <postal>
          <street></street>
          <city>Ottawa</city>
          <region></region>
          <code></code>
          <country>Canada</country>
        </postal>
        <phone></phone>
        <email>tom.taylor.stds@gmail.com</email>
      </address>
    </author>
    
    <date year="2014"/>

    <area>OPS</area>

    <workgroup>Operations and Management Area Working Group</workgroup>

    <keyword>Multi-Layer OAM </keyword>
    <keyword>Technology Independent</keyword>
    

    <abstract>
      <t>Operations, Administration, and Maintenance (OAM) mechanisms are
      critical building blocks in network operations. They used for service
      fulfillment assurance, and for service diagnosis, troubleshooting, and
      repair. The current practice is that many technologies rely on their own
      OAM protocols and procedures that are exclusive to a given layer.
      </t>
      
      <t>At present, there is little consolidation of OAM in the management
      plane or well-documented inter-layer OAM operation. Vendors and operators
      dedicate significant resources and effort through the whole OAM life-cycle
      each time a new technology is introduced. This is exacerbated when dealing
      with integration of OAM into overlay networks, which require better OAM
      visibility since there is no method to exchange OAM information between
      overlay and underlay.</t> 
      
      <t>This document analyzes the problem space for multi-layer OAM in the
      management plane with a focus on layer and technology independent OAM
      management considerations. It concludes that an attempt to define an
      architecture for consolidated management should be undertaken, and if this
      attempt satisfies key objectives, a gap analysis and a program of 
      standardization should follow.
      </t> 
    </abstract>
  </front>

  <middle>
    <section anchor="intro" title="Introduction">

      <t>Operations, Administration, and Maintenance (OAM, <xref
      target="RFC6291"/>) mechanisms are critical tools, used for service
      assurance, fulfillment, or service diagnosis, troubleshooting, and repair,
      as well as supporting functions such as accounting and security
      management. The key foundations of OAM and its functional roles in
      monitoring and diagnosing the behavior of networks have been studied at
      OSI layers 1, 2 and 3 for many years. </t> 
      
      <t>When operating networks with more than one technology in an overlay
      network, maintenance and troubleshooting are achieved per technology and
      per layer. As a result, operational processes can be very cumbersome.
      Stitching together the OAM of adjacent transport segments (as defined
      in <xref target="terms"/> in one administrative domain is often not
      defined and left to proprietary solutions. </t> 
      
      <t>Current practice, which consists in enabling specific OAM techniques
      for each layer, has shown its limits. Concretely, we see today a large
      number of layer 1/2/3 OAM protocols being well developed and some of them
      being successfully deployed, but how these OAM protocols in each layer can
      be applied to overlay networks that are using different encapsulation 
      protocols so as to provide better OAM visibility is still a challenging
      issue. When no mechanism is defined to exchange performance and
      liveliness information between the underlay and overlay(s) by a
      coordination system, it is hard, for instance, to determine whether a
      fault originates in higher or lower layer.</t> 
      
      <t>Section 1.1 of <xref target="RFC7276"/> makes the point that
      each layer in a multi-layer architecture has its own OAM protocols.
      From this follows the basic principle that OAM in the data plane 
      cannot cross layer boundaries. A similar constraint holds for
      boundaries between different transport technologies in the same layer,
      barring the stitching mentioned above.</t>
      
      <t>One concludes that to simplify OAM and make it more responsive in a
      multi-layer network requires further consolidation in the management
      plane. The work on management consolidation would benefit from at least
      some new standardization. A detailed examination of the potential scope of
      the work is left for a gap analysis following successful definition of an
      architecture. 
      </t> 
      
      <t>This document further argues that in addition to the ability to
      retrieve technology specific information from managed entities when
      following up on problems, consolidated management requires
      a technology independent view of the network and supporting
      layers. How this view is obtained is a key architectural issue outside
      the scope of the present document.</t>
      
      <section anchor="vision" title="A Vision of Layer and Technology
Independent Management">

        <t>What follows is based on the assumption of a network supported by a
        strict hierarchy of underlying layers in the data plane. There may be
        multiple layers at a given level of the OSI layer 1-2-3 hierarchy, but
        that is irrelevant to the vision.</t>

        <t>A management application presents to an user a view of this network
        and its supporting layers that is strictly topological, free of any
        technology specific information. The user notes a defect along a path
        serving a particular customer. Looking at the next lower path, the
        user also sees a defect. Looking the next lower path again, there is
        also a defect. No lower defect is noted.</t>

        <t>At this point it is appropriate to indicate what the user can see
        along a given path. The path is divided into one or more segments,
        each spanned by a specific transport technology. However, as already
        stated, the user does not see any technology specific information.
        Instead, as well as distinguishing the segments, the user can identify
        the managed elements at the beginning and end of each segment.</t>

        <t>To clarify the situation, the user issues an abstract Continuity
        Check command, directed toward the initial managed element of the
        segment in which a fault appears to lie (i.e., in the lowest layer
        where a defect was observed). By means to be determined by
        architectural choice, this command is converted into a technology-
        specific request which is executed across the selected segment.
        Possible outcomes include:
        <list style="numbers">
          
          <t>The fault could come clear as a result of the test. The
          immediate problem is solved (and may have affected multiple upper
          paths besides the one of initial interest) and the point at which it
          occurred could be flagged for follow-up maintenance.</t>
          
          <t>Local craft action to clear the fault is available in timely
          fashion. </t>
          
          <t>Timely local craft action is not possible, and capacity is
          reallocated on other paths to ensure that service levels are
          maintained. Note that capacity reallocation can be done based on the
          topological view of the network, still on a layer and technology
          independent basis.</t>
          
        </list></t>

        <t>In case (2), technology specific management capabilities are likely
        to be required by the craftperson following up on the problem.</t>

      </section>  <!-- vision -->
      
      <section anchor="forward" title="Looking Forward">

        <t>The remainder of this document develops the ideas just stated at a
        greater level of detail. <xref target="terms"/> provides terminology
        that is important to the understanding of the rest of the document.
        <xref target="preObject"/> establishes preliminary objectives that are
        key to determining whether a complete program of standardization of
        consolidated management should be undertaken. <xref target="psAnal"/>
        provides the problem analysis. It is divided into three parts: an
        argument for consolidated management (<xref target="argConsol"/>), an
        argument for layer and technology independent management (<xref
        target="argLITI"/>), and an examination of some more detailed issues.
        <xref target="psStat"/> provides the problem statement, and <xref
        target="archCons"/> provides some considerations that should be taken
        into account in the proposed work on architecture. </t> 

      </section>  <!-- forward -->

    </section>  <!-- intro -->

    <section anchor="terms" title="Terminology">

      <t><xref target="RFC6291"/>, cited above, provides the official IETF
      description of Operations, Administration, and Maintenance (OAM)
      terminology. For a more extensive description of OAM and related terms,
      see the opening sections, but particularly
      Sections 2.2.1 through 2.2.3, of <xref target="RFC7276"/>.</t> 
      
      <t>Section 2.2.4 of <xref target="RFC7276"/> introduces the terms data
      plane, control plane, and management plane.</t>
      
      <t>This document introduces its own interpretation of the following
      terms, which are in wide use but in that general usage present
      ambiguities:
      <list style="hanging">
        <t hangText="Management:"><vspace blankLines="1"/>
        A definition of management can be inferred from <xref
        target="RFC6123"/>, which in turn refers to <xref target="RFC5706"/>.
        Unfortunately the latter chose to divide operations from management, at
        least from a documentation point of view. The present document chooses
        to define management as a function that is concerned with all three of
        operations, administration, and maintenance.</t>
        
        <t hangText="Layer:"><vspace blankLines="1"/>
        The word "layer" has two potential meanings. In the first instance, it
        is a topological concept, representing a position in a hierarchy of
        layers. In the second instance, it refers to OSI layers 1, 2 and 3.
        Within this document, "layer independent OAM management" as defined
        below emphasizes the latter meaning when talking about independence, but
        is intended to extend to all layers of the hierarchy supporting a given
        network or overlay (the topological view of "layer").</t> 
      </list></t>
      
      <t>This document makes use of the following additional terms:
      <list style="hanging">
        <t hangText="Layer independent OAM management:">
        <vspace blankLines="1"/>
        In a multi-layer network, layer independent OAM
        management refers to OAM in the management plane that can be
        deployed independently of media, data protocols, and routing
        protocols. It denotes the ability to gather OAM information at the
        different layers, correlate it with layer-specific identifiers
        and expose it to the management application through a unified
        interface.</t>
        
        <t hangText="Managed entity:"><vspace blankLines="1"/> An architectural
        concept, an instance of what the management function manages. By
        definition, a managed entity is capable of communicating with the
        management function in the management plane.</t> 
        
        <t hangText="Local Management Entity (LMgmtE):"> 
        <vspace blankLines="1"/> 
        An instance of a management function that is restricted in scope to
        communication with the managed entities associated with a specific
        transport segment in a specific layer. This term includes legacy
        management entities in an existing network, and may include entities of
        a similar scope if they are defined in a consolidated management
        architecture. </t> 
          
        <t hangText="Consolidated Management Entity (CMgmtE):">
        <vspace blankLines="1"/> 
        An instance of the management function that is capable of communicating
        with all of the LMgmtEs and/or managed entities in a scoped part of the
        network in order to achieve end-to-end and service-level views of
        network performance and status and initiate actions when required. The
        phrase "LMgmtEs and/or managed entities" allows for the possibility that
        the target architecture allows for direct communication between the
        CMgmtE and the managed entities or alternatively chooses to assume a
        distributed management architecture. In any case, as discussed 
        in <xref target="archCons"/>,
        the CMgmtE will have to communicate with legacy LMgmtEs during the
        transition from the existing to the target architecture.</t> 
        
        <t hangText="Management subsystem:"><vspace blankLines="1"/>
        The implementation of the management function in a given network.</t>
        
        <t hangText="Managed device:"><vspace blankLines="1"/>
        A network element associated with at least one technology layer and one
        managed entity.</t> 
        
        <t hangText="Transport segment:"><vspace blankLines="1"/>
        Refers to the portion of a path at a given layer bounded by
        two points between which a specific transport technology
        is used and beyond which either a different technology is
        used or the path is terminated.</t>
        
        <t hangText="Three-dimensional topology:"><vspace blankLines="1"/>
        Refers to a three-dimensional view of the topology of the network and
        supporting layers. The view of paths along a layer comprises two
        dimensions. The third dimension is provided by the ordered hierarchy of
        layers from bottom to top at any point along a path. 
        The three-dimensional topology includes per-path capacity and flow 
        information, permitting layer and technology independent reallocation
        of capacity as required.</t> 
       </list></t>
            
    </section>  <!-- terms -->
          
    
    <section anchor="preObject" title="A Preliminary Set Of Objectives">

      <t>Before going further, it is possible to state a preliminary set of
      objectives for this work. If it does not appear that these can be
      satisfied, there is no point in undertaking further effort.</t>
      
      <t>As a first objective, the outcome of the work must reduce
      the time required to respond to and mitigate service-affecting
      events. The ideal result is that the system be able to do so
      before the customer notices a service degradation. It is possible
      that satisfaction of this objective alone is sufficient to carry on.</t>
      
      <t>A second objective relates to the business case for the work
      and is more difficult for the IETF to judge but crucial for
      operators attempting to justify changes in their network infrastructure.
      It should be possible to expect a reduction in life cycle capex and
      opex as a result of making those changes, even taking account of the
      potential costs of abandoning or upgrading existing equipment. This
      objective may influence work on architecture for consolidated management
      toward minimizing those latter costs (capex). On the positive side, likely
      savings in craftsperson time implied by the first objective are helpful to
      the business case (opex).</t> 
      
      <t>At a more detailed level, the outcome of the work must allow management
      to have end-to-end and service-level views of network performance, down to
      the granularity of service instance. Pre-supposing the arguments made
      in <xref target="argLITI"/>, it must also allow management to have a
      layer and technology independent view of the network, at least in the
      form of the three-dimensional topology, as defined in <xref
      target="terms"/>. </t> 
      
    </section>  <!-- preObject -->

    <section anchor="psAnal" title="Analysis of the Problem">
    
      <section anchor="argConsol" title="Argument For Consolidated Management">

        <t>Multi-layer OAM actually presents two separate but inter-related 
        issues. The first is technology dependency, at the same or
        different layers. The second is correlation of events between
        layers.</t> 
        
        <t>OAM mechanisms have a strong technology dependency because each
        technology (or layer) has its best suited OAM tools. Some of them
        provide rich functionality with one protocol, while the others provide
        each function with a different protocol. Today a variety of OAM tools
        have been developed by different Standards Development Organizations
        (SDOs) for Optical Transport Network (OTN), Synchronous Digital
        Hierarchy (SDH), Ethernet, MPLS, and IP networks. </t> 
        
        <t>However, orchestrating and coordinating OAM in multi-layer networks
        to provide better network visibility and efficient OAM operations is
        still a challenging issue since no mechanisms are defined, for example,
        to exchange performance and liveliness information between different
        layers. This means that the required coordination has to happen in the
        management function through communication with the managed entities.</t>
        
        <t>The development of overlay networks, where one network is the
        client of another, adds to the magnitude of the problem. To take a
        specific example, in the Service Function Chaining (SFC) <xref
        target="I.D-ietf-sfc-problem-statement"/> environment, every Service
        Function (SF) may operate at a different layer and may use a different
        encapsulation scheme. When taking into account overlay technologies, the
        number of encapsulation options increases even more.</t>
        
        <t>At this point, it is useful to recall the preliminary objectives
        stated in <xref target="preObject"/>. To achieve end-to-end and 
        service-level views of network performance requires that the management
        function be capable of receiving and reacting to related information
        from every transport segment at every layer in the network. This is a
        working definition of consolidated management. </t> 
        
        <t>A key issue with "management consolidation" is that it may include
        a requirement for management to interact with every technology used in
        the network on a per-technology basis either initially or when it has 
        to follow up on detected problems by collecting detailed information.
        It is an architectural challenge beyond the scope of this document to
        determine whether consolidated management then becomes an aggregation of
        local managers of legacy type tied together by a coordination function,
        or whether simplifications are possible. </t> 
                   
      </section>  <!-- argConsol -->
      
      <section anchor="argLITI" title="Argument For Layer and Technology
 Independent Management">

        <t>The argument for consolidated management to have a layer and 
        technology independent view of the network and supporting layers is 
        two-pronged. The first argument is fairly straightforward and initially
        independent of architectural considerations. Some management functions
        are concerned solely with the topology of the network and supporting
        layers as represented by the three-dimensional topology defined in
        <xref target="terms"/>. These include network optimization, efficient
        enforcement of Traffic Engineering (TE) techniques including assurance
        of path diversity in one layer and over the complete hierarchy of
        layers, and fine-grained tweaking. Even in this case management action
        may require interaction with the managed elements at a 
        technology-specific level, barring an alternative architectural 
        solution.</t> 
        
        <t>The second argument for a layer and technology independent view
        involves considerably more substance than the first one. The 
        three-dimensional topology would be a starting point for this view, but
        in addition it would include an abstracted view of service-affecting or
        potentially service-affecting events, identified by layer and reporting
        managed device. This allows management to correlate events in different
        layers and identify the devices from which it must seek further
        information or to which it must direct other requests, without being
        burdened with excess information. The intention is to ease root cause
        analysis and improve the ability to maintain end-to-end and 
        service-level visibility.</t> 
        
        <t>Where this second version of a technology independent view is
        created is an architectural issue, beyond the scope of the present
        document. One possibility is that the work is all done in the 
        "consolidated management" function, in which case the latter
        just becomes an aggregation of legacy technology-specific managers
        tied together by a coordination function, as mentioned above.
        A contrasting possibility is that the managed devices
        also support the abstraction, with a view to minimizing the amount
        of technology specific information and management actions the management
        function has to support.</t>

      </section>  <!-- argLITI -->


      <section anchor="details" title="Detailed Issues">
      
        <section title="Strong Technology Dependency For MIB Modules" 
        anchor="techDep">
        
          <t>OAM protocols rely heavily on the specific network technology they
          are associated with. For example, ICMPv6 <xref target="RFC4443"/> and
          LSP Ping <xref target="RFC4379"/> provide the same OAM functionality,
          path discovery, for IPv6 and MPLS Label Switched Path (LSP)
          technologies respectively.</t> 
          
          <t>SNMP MIB modules to manage these protocols were developed on a per
          OAM protocol basis. As a result, there was little reuse of MIB modules
          for other existing OAM protocols. To the extent that management
          operations are being redesigned in terms of YANG modules <xref
          target="RFC6020"/> over NETCONF <xref target="RFC6241"/>, the
          opportunity exists to use the concept of layer and technology
          independent abstraction to extract the reusable parts, simplifying the
          work on the remainder. </t> 
          
        </section>  <!-- techDep -->
                
        <section title="Issues of Abstraction" anchor="abstrIss">
        
          <t>In a multi-layer network, OAM functions are enabled at different
          layers and OAM information needs to be gathered from various
          layers independently. Without multi-layer OAM in place, it is hard for
          management applications to understand what information (e.g., Context,
          OAM functionalities) at different layers stands for and have a unified
          view of OAM information at different layers. A mechanism is required
          to provide this information to management.</t>
          
          <t>The challenge is to abstract in a way that retains in the
          management plane as much useful information as possible while
          filtering the data that is not needed. An important part of this
          effort is a clear understanding of what information is actually
          needed. There is a close relationship between this issue and
          the issue already identified in the previous section.</t> 
          
        </section>  <!-- abstrIss -->
        
        <section title="OAM Interworking Issues" anchor="OAMinter">
        
          <t>When multiple layer OAMs are used in the different parts of the
          network, two layer OAMs interworking at the boundaries need to be
          considered: 
          <list style="symbols">
            <t>How one layer OAM in given part of the network interworks with
            another layer OAM in another part of the network operated by the
            same administrative entity through a consolidated management
            interface? e.g., E-LMI used in UNI interworks with Ethernet link OAM
            used on an IEEE 802.3 link in the same domain?</t> 
            
            <t>How one layer OAM interworks with another layer OAM in the same
            part of the network through a conssolidated management interface?
            e.g., Ethernet OAM interworks with MPLS OAM in the same part of the
            network? In this case, Ethernet OAM and MPLS OAM are both supported
            by the same two managed devices in communication.</t> 
          </list></t>
          
          <t>In these cases, mapping and notifications of defect states between
          different layer OAMs is required at the boundary nodes of the two
          parts of the network <xref target="RFC6310"/> <xref
          target="RFC7023"/> <xref target="I-D.ietf-l2vpn-vpws-iw-oam"/>. 
          Management must provide the interworking
          function to establish dynamic mapping and translation, supervise
          defects, and suppress alarms. [Issue for debate. The original
          text from draft-ww-oamwg provides for a separate interworking
          function. To me, that violates the concept of consolidated
          management. Maybe this is a case of local versus consolidated
          management as discussed in <xref target="archCons"/> -- 
          PTT as individual contributor]</t> 
          
        </section>  <!-- OAMinter -->
        
        <section title="Multiple (ECMP) Paths OAM Issue" anchor="ECMP">
        
          <t>Network devices typically use fields in the MAC or IP header or
          MPLS header and perform hash computations (e.g., 5-tuple hash
          consisting of IP protocol, source address, destination address, source
          port, and destination port) on these packet header fields to classify
          packets into flows and select the forwarding path for the flow among
          multiple equal cost paths, ECMP becomes more important when network
          overlay, service chain technology are introduced, e.g., in case of
          multi-instances of the same service function is invoked for a given
          chain to provide redundancy, how 5-tuple hash is used based on
          contents in the outer headers and inner encapsulated packet.</t> 
          
          <t>Multiple path OAM requires that Connectivity Check and Continuity
          Check must follow the same path as the data traffic (e.g., TCP traffic
          and UDP traffic). Overlay encapsulation allows OAM data to piggyback
          packets, in the way record route is used in IPv4 options. However,
          there is no standard way to exercise end to end continuity and
          connectivity verification that covers all of ECMP paths in the IP
          networks. Such a standard is desirable.</t>           
          
        </section>  <!-- ECMP -->
      
      </section>  <!-- details -->
    </section>  <!-- psAnal -->

    <section anchor="psStat" title="Problem Statement">

      <t>OAM functions are used heavily during service and network life-cycle.
      Today, OAM management requires expertise due to technology dependency
      despite the similarity in functions (adding to CAPEX and OPEX).
      Troubleshooting is cumbersome due to protocol variety and lack of multi-
      layer OAM. This requires expertise and long troubleshooting cycles (OPEX).
      Last but not least, today's various management interfaces make it
      difficult to accept and introduce new protocols and technologies</t> 
      
      <t>There is value in attempting to define an architecture for consolidated
      management that may reasonably be argued to meet the objectives stated in
      <xref target="preObject"/>. If this attempt succeeds, it can be followed
      up with a gap analysis, which in turn will define a further program of
      standardization.</t> 
      
      <t>At the detailed level, <xref target="techDep"/> and <xref
      target="abstrIss"/> deal with the matter of abstraction and its
      relationship to the specification of YANG modules. This is work beyond the
      initial definition of architecture and awaits justification and
      prioritization by the gap analysis. A similar consideration relates to the
      solution to the ECMP problem.</t> 
      
      <t>The remaining issue is the OAM interworking issue identified in
      <xref target="OAMinter"/>. This is architectural in nature, and should
      be addressed by the proposed work on architecture.</t>

    </section>  <!-- psStat -->
    
    <section anchor="archCons" title="Considerations For the Work On
Architecture">

      <t>Definition of an architecture for consolidated management is beyond
      the scope of the present document. This section instead provides
      considerations that should be taken into account when defining such an
      architecture. </t>
      
      <section anchor="archDefine" title="What the Architecture Must Define">
 
        <t>This section is a discussion in the nature of a very general use
        case rather than a discussion of functions and entities. However, as a
        preliminary remark, the architecture must be thought through for all
        five of the FCAPS areas (fault, configuration, accounting,
        performance, and security management). RFC 5706 Section 3, while
        nominally directed to protocol design, reviews operational issues
        associated with each of these areas. </t>
        
        <t>To begin with, previous analysis (<xref target="argLITI"/>) has
        indicated that the CMgmtE <xref target="terms"/> needs to work with a
        view of network topology that is layer and technology independent in
        order to achieve the objectives stated in <xref target="preObject"/>.
        Two questions immediately come to mind: where is this view prepared,
        taking account of the limited processing power of network devices in
        particular, and what model is used to present the topology to the
        CMgmtE? Of course, these questions are evaded if the architecture makes
        the CMgmtE responsible for creating the abstracted topology from data
        gathered from the LMgmtEs and/or managed entities <xref target="terms"/>
        within its scope. </t> 
        
        <t>Note that from the end-to-end point of view multiple network
        topologies will typically exist in the network at one time, possibly
        down to the granularity of a service instance. The relationship of the
        scope of a CMgmtE to the set of available topologies is subject to the
        condition that it has end-to-end and service-level views of all paths
        between the endpoints within its scope, and is otherwise undefined.
        </t>
        
        <t>The CMgmtE must be aware of all of the LMgmtEs and/or managed
        entities within its scope. The architecture must define how the CMgmtE
        identifies the correct sequence of these entities along a path in a
        given layer, and similarly, must identify the correct ordering of layers
        from bottom to top. In effect, the CMgmtE requires a three-dimensional
        topological view of the data plane maintenance infrastructure. Entity
        identification may be implicit in this work. Note that management
        actions may alter this topology (e.g., for routine maintenance or
        installation of new equipment). </t> 
        
        <t>The next issue is how the CMgmtE and the other entities discover
        each other. Bound up in this is the issue of trust. This bootstrapping
        problem is a hard one, constantly recurring in IETF work but never yet
        solved. The architecture work will have to come to its own conclusions
        on this topic. </t>
        
        <t>Where correlation of events from different layers and transport
        segments is done is not an issue. By definition it can be done only by
        the CMgmtE. The architecture must decide whether the necessary data
        gathering is done as required or continuously. </t>
        
        <t>As a final point, the architecture must specify how an existing
        network evolves from legacy operation to the target architecture. The
        existing network will have LMgmtEs in place. The question is whether
        the CMgmtE simply replaces them or communicates with them. If it
        simply replaces them, the architecture must define (in an operational
        considerations section) how testing of the new management
        configuration takes place before cutover. Considerations of data
        continuity during cutover should also be addressed. </t>
        
        <t>The above is not an exhaustive list of considerations, but should
        give a good start to the architectural work.</t>

      </section>  <!-- archDefine -->

    </section>  <!-- archCons -->

    <section title="Security Considerations">
    
      <t>The architectural work must include work on the security architecture
      of the whole system. Beyond that, potential future work on individual
      interfaces must include the appropriate security mechanisms within
      the architectural framework. The present document cannot be more specific
      by its nature.</t>
      
    </section>

    <section anchor="iana" title="IANA Considerations">
      <t>This document does not require any action from IANA.</t>
    </section>
    
    <section anchor="contrib" title="Contributors">
    
      <t>In the understanding of the Editor, the following individuals (listed
      in alphabetical order by last name) contributed text to or strongly
      influenced the development of versions of draft-ww-opsawg-multi-layer-oam,
      from which this document was derived: 
      <list style="symbols">
      
        <t>Sam Aldrin mailto:aldrin.ietf@gmail.com, Huawei USA;</t>
        <t>Mohamed Boucadair mailto:mohamed.boucadair@orange.com, 
        France Telecom;</t>
        <t>Huub van Helvoort mailto:huubatwork@gmail.com, Hai Gaoming BV;</t>
        <t>Tom Herbert mailto:therbert@google.com, Google;</t>
        <t>Pradeep Jain mailto:pradeep@nuagenetworks.net, Nuage Networks;</t>
        <t>Daniel King mailto:daniel@olddog.co.uk, Olddog Consulting;</t>
        <t>Greg Mirsky mailto:gregory.mirsky@ericsson.com, Ericsson;</t>
        <t>Ravi Shekhar mailto:rshekhar@juniper.net, Juniper.</t>
        
      </list></t>

    </section>  <!-- contrib -->

    <section title="Acknowledgements">
      <t>The authors would like to thank Jan Lindblad, Tissa Senevirathne, Yuji
      Tochio, Ignas Bagdonas, Eric Osborne, Rob Shakir, Georgis Karagiannis,
      Melinda Shore and Jouni Korhonen for their reviews and suggestions.</t> 
    </section>
    
  </middle>

  <back>
    <references title="Normative References">
    
      &RFC6291;
      &RFC7276;
      

    </references>  <!-- Normative -->

    <references title="Informative References">

<!--  &RFC1157;
      &RFC3410;
      &RFC4176;
 -->      
      &RFC4379;
      &RFC4443;
<!--  &RFC4656;
      &RFC5357;
 -->  
      &RFC5706;
<!--  &RFC5880;
 -->
      &RFC6020;
      &RFC6123;
      &RFC6241;     
      &RFC6310;
<!--       
      &RFC6374;
      &RFC6378;
      &RFC6428;
 -->      
      &RFC7023;
<!-- 
      <reference anchor="I.D-ietf-nvo3-framework">
        <front>
          <title>Framework for DC Network Virtualization (Work
in progress)</title>

          <author fullname="M.Lasserre" initials="M." surname="Lasserre">
            <organization/>
          </author>

          <date month="July" year="2014"/>
        </front>

        <seriesInfo name="ID" value="draft-ietf-nvo3-framework-00"/>
      </reference>
      
  <reference anchor="I-D.sridharan-virtualization-nvgre">
    <front>
      <title>NVGRE: Network Virtualization using Generic Routing Encapsulation
(Work in progress)</title>
      <author initials="M." surname="Sridharan">
        <organization>Microsoft</organization>
      </author>
      <author initials="A." surname="Greenberg">
        <organization>Microsoft</organization>
      </author>
      <author initials="Y." surname="Wang">
        <organization>Microsoft</organization>
      </author>
      <author initials="P." surname="Garg">
        <organization>Microsoft</organization>
      </author>
      <author initials="N." surname="Venkataramiah">
        <organization>Microsoft</organization>
      </author>
      <author initials="K." surname="Duda">
        <organization>Arista Networks</organization>
      </author>
      <author initials="I." surname="Ganga">
        <organization>Intel</organization>
      </author>
      <author initials="G." surname="Lin">
        <organization>Google</organization>
      </author>
      <author initials="M." surname="Pearson">
        <organization>Hewlett-Packard</organization>
      </author>
      <author initials="P." surname="Thaler">
        <organization>Broadcom</organization>
      </author>
      <author initials="C." surname="Tumuluri">
        <organization>Emulex</organization>
      </author>
      <date month="July" year="2014"/>
    </front>
  </reference>
  
  <reference anchor="I-D.gross-geneve">
    <front>
      <title> Geneve: Generic Network Virtualization Encapsulation 
(Work in progress)</title>
      <author initials="J." surname="Gross">
        <organization>VMware</organization>
      </author>
      <author initials="T." surname="Sridhar">
        <organization>VMware</organization>
      </author>
      <author initials="P." surname="Garg">
        <organization>Microsoft</organization>
      </author>
      <author initials="C." surname="Wright">
        <organization>Red Hat</organization>
      </author>
      <author initials="I." surname="Ganga">
        <organization>Intel</organization>
      </author>
      <date month="August" year="2014"/>
    </front>
  </reference>
 -->  
      <?rfc include='reference.I-D.ietf-l2vpn-vpws-iw-oam'?>
<!-- 
      <?rfc include='reference.I-D.tissa-netmod-oam'?>
 -->
      <reference anchor="I.D-ietf-sfc-problem-statement">
        <front>
          <title>Network Service Chaining Problem Statement 
(Work in progress)</title>

          <author fullname="P.Quinn" initials="P." surname="Quinn">
            <organization/>
          </author>

          <author fullname="J.Guichard" initials="J." surname="Guichard">
            <organization/>
          </author>

          <author fullname="S.Surendra" initials="S." surname="Surendra">
            <organization/>
          </author>

          <date month="August" year="2014"/>
        </front>

        <seriesInfo name="ID" value="draft-ietf-sfc-problem-statement"/>
      </reference>

<!--       
      <reference anchor="I-D.jain-nvo3-overlay-oam">
        <front>
          <title>Generic Overlay OAM and Datapath Failure Detection
(Expired Internet Draft)</title>

          <author fullname="P. Jain" initials="P." surname="Jain">
            <organization/>
          </author>

          <date month="February" year="2014"/>
        </front>

        <seriesInfo name="ID" value="draft-jain-nvo3-overlay-oam-01"/>
      </reference>

      <reference anchor="I-D.tissa-nvo3-yang-oam">
        <front>
          <title>YANG Data Model for NVO3 Operations, Administration, and
Maintenance (OAM) (Work in progress)</title>

          <author fullname="T.Senevirathne" initials="T."
                  surname="Senevirathne">
            <organization/>
          </author>

          <date month="June" year="2014"/>
        </front>

        <seriesInfo name="ID" value="draft-tissa-nvo3-yang-oam-00"/>

        <format target="http://tools.ietf.org/html/draft-tissa-nvo3-yang-oam-00"
                type="TXT"/>
      </reference>

      <reference anchor="I-D.penno-sfc-yang">
        <front>
          <title>Yang Data Model for Service Function Chaining
(Work in progress)</title>

          <author fullname="R. Penno" initials="R." surname="Penno">
            <organization/>
          </author>

          <date month="July" year="2014"/>
        </front>

        <seriesInfo name="ID" value="draft-penno-sfc-yang-06"/>

        <format target="http://tools.ietf.org/html/draft-penno-sfc-yang-06"
                type="TXT"/>
      </reference>
      
  <reference anchor="I-D.herbert-gue">
    <front>
      <title>Generic UDP Encapsulation (Work in progress)</title>
      <author initials="T." surname="Herbert">
        <organization>Google</organization>
      </author>
      <date month="March" year="2014"/>
    </front>
  </reference>

  <reference anchor="G.806">
    <front>
      <title>Characteristics of transport equipment - Description methodology
and generic functionality</title>
      <author initials="" surname="">
        <organization>ITU-T</organization>
      </author>
      <date month="March" year="2006"/>
    </front>
    <seriesInfo name="ITU-T Recommendation" value="G.806" />
  </reference>

      <reference anchor="MEF-38">
        <front>
          <title>Service OAM Fault Management YANG Modules</title>

          <author>
            <organization/>
          </author>

          <date month="April" year="2012"/>
        </front>

        <seriesInfo name="MEF" value="38"/>
      </reference>

      <reference anchor="MEF-39">
        <front>
          <title>Service OAM Performance Monitoring YANG Module</title>

          <author>
            <organization/>
          </author>

          <date month="April" year="2012"/>
        </front>

        <seriesInfo name="MEF" value="39"/>
      </reference>

      <reference anchor="Y.1375">
        <front>
          <title>Protocol-neutral management information model for the MPLS-TP
          network element</title>

          <author>
            <organization/>
          </author>

          <date month="September" year="2014"/>
        </front>

        <seriesInfo name="Draft Recommendation ITU-T" value="Y.1375"/>
      </reference>

      <reference anchor="Y.1346">
        <front>
          <title>Protocol-neutral management information model for the
          Ethernet transport capable network element</title>

          <author>
            <organization/>
          </author>

          <date month="September" year="2014"/>
        </front>

        <seriesInfo name="Draft Recommendation ITU-T" value="Y.1346"/>
      </reference>

      <reference anchor="Y.1370.1">
        <front>
          <title>Architecture of MPLS Transport Profile (MPLS-TP) layer
          network</title>

          <author>
            <organization/>
          </author>

          <date month="December" year="2011"/>
        </front>

        <seriesInfo name="ITU-T" value="Y.1370.1"/>
      </reference>
 -->      
    </references>

  </back>
</rfc>