Re: [Time] Editor's proposed draft of TIME/LIME Problem Statement

-----邮件原件-----
>发件人: Time [mailto:time-bounces@ietf.org] 代表 Melinda Shore
>发送时间: 2014年9月8日 11:22
>收件人: time@ietf.org
>主题: Re: [Time] Editor's proposed draft of TIME/LIME Problem Statement

>On 9/7/14 4:30 PM, Tom Taylor wrote:
>> 1.1 A Vision of Layer and Technology Independent Management

>I just had a thorough read of a recent version of the problem statement and I think that the terminology around the problem really needs to be tweaked.  
>In some sense we've already got layer- and technology- independent management, in the form of several highly modular protocols that can convey management and/or configuration >information for all sorts of devices and protocols.

[Qin]: Today we see a large number of Managed objects (called SNMP MIBs) be developed, each MIB is developed for each technology. When a new technology is introduced, there is little reuse of any SNMP MIB designed for the existing technologies.

Therefore I am not sure we can call SNMP is layer and technology independent management protocol.
NETCONF can provide layer and technology independent management feature since it use modeling language to define operation data, configuration data and notification.
One model defined by NETCONF can be reused by another model if we allow model to be extended. What addition you need to do is to define technology specific feature.

Secondly what we like to see is management plane to provide adaption layer between user and managed element, user doesn't need to care about what specific OAM technologies are used,
Adaption layer can provide mapping and translation between technologies specific information and technologies independent information(e.g., CFM model related information)

>  What's unique here is that there's a proposal to path-couple management messages and possibly have them intercepted by management modules in varying sorts of devices along that path. 

[Qin]: Our proposal is to couple with multi-layer network, allow stitching OAM systems in different layer, correlate faults in different layer and provide abstract view of OAM information to the user.

It looks your proposal is additional to our proposal in the draft-edprop-opsawg-multi-layer-oam-ps-00 and more related to forwarding plane OAM, I remember there was some discussion before on forwarding plane OAM, it was organized by IESG and IAB.
http://www.ietf.org/mail-archive/web/oam/current/msg00030.html
http://www.ietf.org/mail-archive/web/oam/current/msg00067.html

It might be interesting to see how local management entity interact with managed entity for technology specific information when such path couple message is exchanged between management entities. But not sure it should be in the scope of our current proposal.

>It's been proposed before (for example, I proposed it here:
>draft-shore-nls-tl-06.txt) but has never been developed.  What's significant about this proposal that it attempts to deal with managing and diagnosing problems that may be related to >topology, perhaps without foreknowledge of topology or routing.

[Qin]:Yes, it is not necessary to rely on routing protocol. Management interface can also be used to gather such kind of information(e.g., supporting layer, layer identifier).

>I'd try to be clearer about why this is interesting.  "Layer and Technology Independence" is one aspect of it but not one that's unique to this proposal.

[Qin]: See above. 

Melinda

_______________________________________________
Time mailing list
Time@ietf.org
https://www.ietf.org/mailman/listinfo/time