Subject: [nvo3] Fwd: WG Action: Formed Layer Independent OAM Management in the Multi-Layer Environment (lime)

From: Benson Schliesser <[email-masked]>
Date: Fri, 17 Oct 2014 13:31:22 -0400

FYI, this may be interesting to some NVO3 participants, and is almost certainly relevant to the WG work.

Cheers,
-Benson

Begin forwarded message:

> From: The IESG <[email-masked]>
> Subject: WG Action: Formed Layer Independent OAM Management in the Multi-Layer Environment (lime)
> Date: October 17, 2014 at 11:27:25 AM EDT
> To: IETF-Announce <[email-masked]>
> Cc: lime WG <[email-masked]>
> Reply-To: [email-masked]
> 
> A new IETF working group has been formed in the Operations and Management
> Area. For additional information please contact the Area Directors or the
> WG Chairs.
> 
> Layer Independent OAM Management in the Multi-Layer Environment (lime)
> ------------------------------------------------
> Current Status: Proposed WG
> 
> Chairs:
>  Carlos Pignataro <[email-masked]>
>  Ron Bonica <[email-masked]>
> 
> Assigned Area Director:
>  Benoit Claise <[email-masked]>
> 
> Mailing list
>  Address: [email-masked]
>  To Subscribe: https://www.ietf.org/mailman/listinfo/lime
>  Archive:
> http://www.ietf.org/mail-archive/web/lime/current/maillist.html
> 
> Charter:
> 
> Network Operators are increasingly challenged with operational and
> management limitations in network deployments due to Operations,
> Administration, and Maintenance (OAM) operating at different
> administrative and technology layers. This problem is exacerbated by the
> lack of a common architectural OAM management in those different layers
> and protocols. New work on network virtualization further complicates the
> layering model and the problems of coordinating OAM between layers and
> protocols.
> 
> 
> The absence of a common approach to OAM management has made it difficult
> for operators to:
> - Suppress large numbers of unnecessary alarms and notifications related
> to defects and failures arising in lower layers and visible in each
> higher layer
> - Quickly identify root causes of network failures 
> - Coordinate end-to-end performance measurement with the results of
> performance monitoring at different layers in the network
> - Correlate defects, faults, and network failures between the different
> layers to improve efficiency of defect and fault localization and provide
> better OAM visibility.
> 
> 
> The LIME working group will concentrate on the operational challenges in
> consistent handling of end-to-end OAM and coordination of OAM within
> underlying network layers. This work will enable consistent
> configuration, reporting, and presentation for the OAM mechanisms used to
> manage the network, regardless of the layers and technologies, including
> management mechanisms to facilitate better mapping between information
> reported from OAM mechanisms that operate in different network layers. It
> will also produce architectural guidelines for the development of new OAM
> tools and protocols in both management plane and data plane so that they
> may be coherent with these mechanisms and more easily integrated from an
> operational points of view.
> 
> The working group will work on the following deliverables:
> 
> - YANG data model(s) for generic layer-independent and
> technology-independent configuration, reporting and presentation for OAM
> mechanisms.
> 
> - An architecture for OAM that can be used as guidance by other IETF
> working groups developing new OAM protocols or modifying existing OAM
> protocols, at any layer and for any technology. This guidance will cover
> both the management and data planes. Existing OAM architectures will be
> reviewed.
> 
> - Applicability document: The YANG model(s) specified in this working
> group must be usable and extensible by the existing OAM technologies.
> This usability and extensibility must be demonstrated, for example with
> IP Ping, traceroute, BFD, and LSP Ping. Note the technology-specific data
> model extensions should ideally be worked on in the respective working
> groups.
> 
> The working group will explore and document use-cases for converged
> management of OAM in multi-layer and multi-technology networks that
> triggered this work. The use cases will consider scenarios that include
> (but are not limited to) those that rely upon a centralized control point
> responsible for the overall OAM management and those that assume the
> delegation of layer-specific OAM management control points. The working
> group will decide later whether the use case document needs to be
> published as an RFC.
> 
> If the working group finds it necessary to work on an information model
> before the data model, it might do so. The working group will decide
> later whether the information model needs to be published as an RFC.
> 
> The initial scope is restricted to a single administrative domain and may
> be extended for inter-domain scenarios in future as and when a need
> rises.
> 
> The working group will not develop any new OAM protocols.
> 
> The LIME WG is not chartered to work on information or data models
> specific to any data plane or forwarding plane technology that is
> developed outside of the IETF. However, it is the intention that the
> generic information and data models produced by the working group should
> be applicable to multiple layers and technologies in a technology
> agnostic fashion. Therefore, it is anticipated that the working group
> will closely coordinate its activities with other SDOs (including, but
> not limited to the ITU-T, MEF, IEEE, BBF and 3GPP) to ensure that the
> generic models are harmonized with work done in those SDOs and are
> applicable to many technologies.
> 
> 
> Milestones:
>  Feb 2015 - Adopt the WG draft on YANG data model(s)
>  May 2015 - Adopt the WG draft on LIME Architecture
>  Aug 2015 - Adopt the WG draft for Applicability of the generic model
>  Sep 2015 - Submit the YANG model(s) document to IESG as a Proposed
> Standards RFC
>  Nov 2015 - Submit the Architecture document to IESG for review as an
> informational RFC
>  Apr 2016 - Submit the Applicability document to IESG for review as an
> Informational RFC
>  Apr 2016 - Recharter or conclude
> 
>