Subject: Re: [Lime] LIME Charter Propsosal v1

From: Qin Wu <[email-masked]>
Date: Mon, 22 Sep 2014 02:41:28 +0000

Frank:
Thanks for your interests and comments.
We have a consolidated proposal that is built based on discussion on the list and uploaded to the github:
https://github.com/danielkinguk/lime/tree/master/charter-proposal

Your comments has been incorporated in, thanks!

-Qin
From: Lime [mailto:[email-masked]] On Behalf Of Xialiang (Frank)
Sent: Thursday, September 18, 2014 6:10 PM
To: Qin Wu
Cc: Benoit Claise; [email-masked]<mailto:[email-masked]>; Tom Taylor
Subject: Re: [Lime] LIME Charter Propsosal v1

Hi Qin,
Thanks for initiating and proposing this very valuable work to IETF!
I am very interested in it and will contribute to it. If the Charter Design Team is not too long, please add me~~
Now, I have some comments and questions to the Charter Proposal for your consideration. Please see inline:

Thanks!

B.R.
Frank

From: Lime [mailto:[email-masked]] On Behalf Of Qin Wu
Sent: Wednesday, September 17, 2014 9:34 AM
To: Benoit Claise; [email-masked]<mailto:[email-masked]>
Cc: Tom Taylor
Subject: Re: [Lime] LIME Charter Propsosal v1

Hi, all

Based on ADs suggestion on the Charter proposal, we design team write a 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:

[Frank] : I think we cannot say SNMP interfaces are proprietary interfaces, they have been standardized. So, I suggest to use “particular MIB modules” to replace “proprietary interfaces”

-- 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.

[Frank] : Should “status defects” be replaced by “status, defects”? One point maybe missed here is about the complexity of understanding and developing a management MIB module for the operators because of each one is technology and layer specific.

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:

[Frank] : I personally think the description about “guidelines” is not very clear. What’s the guidelines aim for? What’s  about the future OAM developments? What’s the relation between them? Hoping it has a more clear description here.

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

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

[Frank] : maybe need a explanation of what is 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]<mailto:[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)