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

Qin Wu <bill.wu@huawei.com> Tue, 09 September 2014 03:15 UTC

Return-Path: <bill.wu@huawei.com>
X-Original-To: time@ietfa.amsl.com
Delivered-To: time@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1723F1A06E7 for <time@ietfa.amsl.com>; Mon, 8 Sep 2014 20:15:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.064
X-Spam-Level:
X-Spam-Status: No, score=-3.064 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CN_BODY_35=0.339, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.652, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vKtnBZpMuGOJ for <time@ietfa.amsl.com>; Mon, 8 Sep 2014 20:15:47 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 585121A06E8 for <time@ietf.org>; Mon, 8 Sep 2014 20:15:46 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml403-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BJF12873; Tue, 09 Sep 2014 03:15:44 +0000 (GMT)
Received: from NKGEML410-HUB.china.huawei.com (10.98.56.41) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 9 Sep 2014 04:15:43 +0100
Received: from NKGEML501-MBS.china.huawei.com ([169.254.2.209]) by nkgeml410-hub.china.huawei.com ([10.98.56.41]) with mapi id 14.03.0158.001; Tue, 9 Sep 2014 11:15:36 +0800
From: Qin Wu <bill.wu@huawei.com>
To: Melinda Shore <melinda.shore@gmail.com>, "time@ietf.org" <time@ietf.org>
Thread-Topic: [Time] Editor's proposed draft of TIME/LIME Problem Statement
Thread-Index: AQHPyalU4JMG30eSaUSJISQbv/6P1ZvzXEAAgAKCjwCAAC/cAIACByzQ
Date: Tue, 9 Sep 2014 03:15:35 +0000
Message-ID: <B8F9A780D330094D99AF023C5877DABA845C1505@nkgeml501-mbs.china.huawei.com>
References: <5409DA04.2020200@gmail.com> <461483BC-58E7-483D-8B81-FB15C015C4B7@gmail.com> <540CF8B2.10006@gmail.com> <540D20D8.6050704@gmail.com>
In-Reply-To: <540D20D8.6050704@gmail.com>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.138.41.180]
Content-Type: text/plain; charset="gb2312"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: http://mailarchive.ietf.org/arch/msg/time/F8zPjuUyO0YDuICP2kDqny2ELxY
Subject: Re: [Time] Editor's proposed draft of TIME/LIME Problem Statement
X-BeenThere: time@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Transport Independent OAM in Multi-Layer network Entity \(TIME\) discussion list." <time.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/time>, <mailto:time-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/time/>
List-Post: <mailto:time@ietf.org>
List-Help: <mailto:time-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/time>, <mailto:time-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 09 Sep 2014 03:15:49 -0000

-----邮件原件-----
>发件人: 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