Subject: [Lime] 回复： Re: LIME Charter Propsosal v1

From: Qin Wu <[email-masked]>
Date: Wed, 17 Sep 2014 22:18:37 +0800

See inline.

-------- 原始邮件 --------
发件人： Stewart Bryant <[email-masked]> 
日期: 2014-09-17  21:32  (GMT+08:00) 
收件人： Qin Wu <[email-masked]>,Benoit Claise <[email-masked]>,[email-masked] 
主题： Re: [Lime] LIME Charter Propsosal v1 
 
On 17/09/2014 14:18, Qin Wu wrote:
发 件人: Stewart Bryant [mailto:[email-masked]] 
发 送时间: 2014年9月17日 18:35
收件人: Qin Wu; Benoit Claise; [email-masked]
抄送: Gregory Mirsky; Pradeep Jain; Mishael Wexler; Jouni; [email-masked]; Sam Aldrin; Romascanu, Dan (Dan); Ravi Shekhar; Tom Taylor; Tom Herbert; [email-masked]; Daniel King
主题: Re: [Lime] LIME Charter Propsosal v1
 
On 17/09/2014 02:11, Qin Wu wrote:
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.

SB> I volunteer to help.

    Examples of "administration" tools are network discovery and planning
    tools.

SB> Regardless of RFC6291, network discovery is normally part of routing, or of an application layer broker.

SB> Surely the normal definition of admin is configuration?

[Qin]: Yes, I agree routing protocol or application protocol provide a good functionality for network discovery.

Also I agree configuration is a good example of administration. Before configuration, management function needs to know who needs to be configured and where it is.

Doesn't this come from a network management database, or in these modern times the orchestrator.
[ Qin ]yes,one way I am thinking is to make each local management function have such database per Layer,central management function doesn't need to maitain these Databases for each layer but need to be configured with all the local management functions or Legacy management functions.
However. What if without any local management functions involved ?
I agree manually configuration can solve this. But isn't discovery provided by autonomic networking giving a better way.

Perhaps we need to go up a level and understand where on the spectrum of full manual configuration to autonomic networking we are targeting the discovery, and what is in and out of scope in a "traditional" network.
[ Qin]agree. That's a good suggestion.

- Stewart

configuration. The limited scope of of each management interface has made it very difficult to:

SB> of of (typo)

[Qin]: Thanks.

SB> Shouldn't the instantiation of these models in a particular protocol be explicitly out of scope?

Here is what we concluded:
1. Building an OAM generic protocol is impractical for multiple reasons.
SB> Agree
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
SB> Hopefully we can achieve this, but we need to be clear that this should not be a constraint on new protocols, i.e. if we miss something that a new protocol needs, then the model has to be improved.
[Qin]: Yes, if we can get generic OAM management model, generic model should not put constraint on new protocols, but generic model doesn’t need to changed each time there is something that a new protocol needs. What we can do is to define Specific OAM technology models that is augmented from  generic model i.e.,  Specific OAM technology model extends generic model to support technology specific feature.
 
3. Consistent configuration, reporting, and presentation for the OAM mechanisms makes sense.
SB> Yes, subject to (2)
4. Using YANG as a modeling language is a logical choice. Note that there are already some efforts in that direction
SB> Agree
5. A set of guidelines for future OAM developments would be welcome for consistency sake
SB> Agree
- Stewart

-- 
For corporate legal information go to:

http://www.cisco.com/web/about/doing_business/legal/cri/index.html