Subject: [Anima] Fwd: [Lime] LIME Charter Propsosal v1

From: Laurent Ciavaglia <[email-masked]>
Date: Wed, 17 Sep 2014 17:09:47 +0200

Dear all,

FYI.
The LIME initiative is referring to ANIMA in its draft charter:
     "Related work: -- ANIMA very interested in the mutual discovery aspect"

Might be worth to synchronize at some point with the (future) WG.

Best regards, Laurent.

-------- Original Message --------
Subject: 	[Lime] LIME Charter Propsosal v1
Date: 	Wed, 17 Sep 2014 01:11:22 +0000
From: 	Qin Wu <[email-masked]>
To: 	Benoit Claise <[email-masked]>, "[email-masked]" <[email-masked]>
CC: 	Gregory Mirsky <[email-masked]>, Pradeep Jain 
<[email-masked]>, Mishael Wexler <[email-masked]>, 
Jouni <[email-masked]>, "[email-masked]" 
<[email-masked]>, Sam Aldrin <[email-masked]>, "Romascanu, 
Dan (Dan)" <[email-masked]>, Ravi Shekhar <[email-masked]>, 
Tom Taylor <[email-masked]>, Tom Herbert 
<[email-masked]>, "[email-masked]" 
<[email-masked]>, Daniel King <[email-masked]>

Hi, all

Based on ADs suggestion on the Charter proposal, we call for a design 
team to write the Charter proposal after a few internal discussions.

Here is the initial version of proposed charter for discussion on the 
list (See below or attached).

Layer Independent OAM Management in the Multi-Layer Environment (LIME)

------------------------------------------------------------------------------------------------------------------------------------------

Operations, Administration, and Maintenance (OAM) is a general term that 
refers to tools created for network management.  Quoting from RFC 6291:

     Examples of tools related to "operations" are performance monitoring

     tools used for service level agreement (SLA) measurement, fault

     management tools used to monitor the health of nodes and links in the

     network, and network provisioning tools.

     Examples of "administration" tools are network discovery and planning

     tools.

     Examples of "maintenance" tools are implementations of connectivity

     check, loopback, link trace, and other tools that can be used to

     monitor and diagnose failures in a network or network element.

An operator's network is made up of layers -- consisting of OSI layers 1 
through 3 in the first instance, but made more complex by the emergence 
of network overlays such as NVO3 [reference]. Looking along a particular 
layer, a path may be made up of multiple segments of differing network 
technologies, such as MPLS at one point, IP at another.

Traditionally, fault management and path maintenance have been achieved 
through a series of technology and layer specific OAM protocols together 
with technology and layer specific management interfaces. The latter 
have been based on SNMP MIB modules developed independently without 
coordination between them and on proprietary interfaces for 
configuration. The limited scope of of each management interface has 
made it very difficult to:

-- suppress large numbers of unnecessary alarms and notifications

     related to defects and failures

-- quickly identify root causes

-- monitor performance on an end-to-end basis

-- correlate status defects, faults and network failures between the

     different layers to improve efficiency of defect and fault

     localization and provide better OAM visibility, since it has been 
necessary to navigate the peculiarities of each individual technology 
specific management interface at each layer, then try to bring the 
results together into a coherent picture.

There is now a move afoot to replace the SNMP MIB modules with YANG 
modules instead. YANG is more flexible and extensible than SMIv2, and 
can more safely be used for configuration as well as information 
retrieval. This movement to YANG opens up the possibility of modeling 
OAM operations management in a more uniform fashion and creating 
management interfaces that are more friendly to a centralized management 
function than the present set.

The objective of the LIME initiative is to encourage consistent 
configuration, reporting, and presentation for the OAM mechanisms used 
to manage the network, over all layers and technologies. It will do this 
by preparing a set of guidelines for future OAM developments as its 
initial task. These guidelines will cover OAM for all five FCAPS (fault, 
capacity, accounting, performance, security) management areas, and will 
not be limited to Layer 1-3 technologies but also consider management at 
higher OSI layers. Two initial cases will be considered:

(1) where the centralized management function communicates directly with 
the managed elements;

(2) where the centralized management function communicates with a local 
management function.

The first case takes priority.

Development of one or more management information models may be 
undertaken if it is seen as necessary to move the work forward.

Out of scope initially, but potentially within subsequent scope:

   -- development of any YANG modules.

   -- development of a solution for mutual discovery of the centralized 
management function and the managed elements or local managers.

Related work:

   -- ANIMA very interested in the mutual discovery aspect

   -- Metro Ethernet Forum work on ...

*·¢¼þÈË:*Lime [mailto:[email-masked]] *´ú±í *Benoit Claise
*·¢ËÍÊ±¼ä:*2014Äê9ÔÂ16ÈÕ18:58
*ÊÕ¼þÈË:[email-masked]
*Ö÷Ìâ:*[Lime] OAM Initiative: Situation

Dear all,

LIME is a new mailing list, transitioning from TIME (in case you want to 
read the archives).
As one of the first email to the list, let me summarize the current 
situation.

During the last IETF meeting, there were various discussions with 
different audiences regarding this OAM initiative.

Here is what we concluded:
1. Building an OAM generic protocol is impractical for multiple reasons.
2. It is desirable to have an unified view of OAM information at each 
layer, in order to correlate information, and detect the faulty element 
in the network path
3. Consistent configuration, reporting, and presentation for the OAM 
mechanisms makes sense.
4. Using YANG as a modeling language is a logical choice. Note that 
there are already some efforts in that direction
5. A set of guidelines for future OAM developments would be welcome for 
consistency sake

We also believe that there is sufficient interest to start working on a 
charter proposal.

Regards, Joel and Benoit (OPS ADs)

-- 

Bien cordialement, Best regards,

*Laurent Ciavaglia*

Advanced Internet Research

Bell Labs | Alcatel Lucent

phone: +33 160 402 636

email: [email-masked] 
<mailto:[email-masked]>

linkedin: laurentciavaglia <http://fr.linkedin.com/in/laurentciavaglia/>

address: Route de Villejust | 91620 Nozay | France