Re: [Time] OAM Initiative: Situation - Sketch of a charter

Qin Wu <bill.wu@huawei.com> Thu, 11 September 2014 02:04 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 F14DF1A0322 for <time@ietfa.amsl.com>; Wed, 10 Sep 2014 19:04:11 -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 ZPZgu1iNwusm for <time@ietfa.amsl.com>; Wed, 10 Sep 2014 19:04:10 -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 DD9881A0313 for <time@ietf.org>; Wed, 10 Sep 2014 19:04:09 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml404-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BMK73347; Thu, 11 Sep 2014 02:04:08 +0000 (GMT)
Received: from NKGEML402-HUB.china.huawei.com (10.98.56.33) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 11 Sep 2014 03:03:39 +0100
Received: from NKGEML501-MBS.china.huawei.com ([169.254.2.209]) by nkgeml402-hub.china.huawei.com ([10.98.56.33]) with mapi id 14.03.0158.001; Thu, 11 Sep 2014 10:03:33 +0800
From: Qin Wu <bill.wu@huawei.com>
To: Benoit Claise <bclaise@cisco.com>, Tom Taylor <tom.taylor.stds@gmail.com>, "time@ietf.org" <time@ietf.org>
Thread-Topic: [Time] OAM Initiative: Situation - Sketch of a charter
Thread-Index: AQHPy3q+XrvFxMfZE0OjF9YXiJqj+5v4WiuAgALO41A=
Date: Thu, 11 Sep 2014 02:03:33 +0000
Message-ID: <B8F9A780D330094D99AF023C5877DABA845C2422@nkgeml501-mbs.china.huawei.com>
References: <540B022E.3070601@cisco.com> <540D6249.205@cisco.com> <540DCD05.3030508@gmail.com> <540F10B9.9090400@cisco.com>
In-Reply-To: <540F10B9.9090400@cisco.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/GbRa94RIHwRhHAPX1hcZWmUrFlk
Subject: Re: [Time] OAM Initiative: Situation - Sketch of a charter
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: Thu, 11 Sep 2014 02:04:12 -0000

I agree, we should focus on consistent configuration, reporting and presentation for the centralized management at the first step,
But how?
I think we should use YANG Language to provide consistent presentation if we can model all the technology specific OAM in the same way

To provide consistent reporting, we can stitch OAM at different layer in the management platform, we can allow OAM test and reporting work together,
One of example, we can allow test(e.g.,ping) can be initiated from centralized management, centralized management can convert test into technology specific operation(e.g., IP ping),
And then in-band mechanism can be activated in the data plane, when test results return, the test results can be reported to centralized management through unified management interface.
Another example, if the path can be divided into two segment and centralized management can stitch two segment together, when the same fault is detected by segment A and segment B,
And segment A and segment B report the same fault to the centralized management, centralized management should the same fault is detected by two segments.

To provide consistent configuration, we need to figure out how to install and configure, activate various OAM functions at the different layer in the same way,
Model all the OAM information in the same way using YANG is a good way, also we need to figure out how to convert common OAM information to technology specific configuration.

Regards!
-Qin
-----邮件原件-----
发件人: Time [mailto:time-bounces@ietf.org] 代表 Benoit Claise
发送时间: 2014年9月9日 22:38
收件人: Tom Taylor; time@ietf.org
主题: Re: [Time] OAM Initiative: Situation - Sketch of a charter

Hi Tom,

> It seems to me, taking Melinda's remarks into account, that the one 
> work item missing from this announcement is the means whereby 
> management is tied together along a path. The original TIME/LIME 
> proposal spoke in terms of discovery by a centralized management 
> application.
Exactly. Interesting that the problem statement changed along the time.
> Melinda suggests path-coupled management messages, possibly 
> intercepted by management modules in varying sorts of devices along 
> that path. Would this be an appropriate item of exploration within the 
> charter?
This point was not discussed in details during the last meeting. Let's keep in mind that there were no BoF but two quick presentations in OPSAWG and the Routing Area.
My point is: shouldn't we start by walking before running, i.e. focusing first on consistent configuration, reporting, and presentation for the centralized management?

Regards, Benoit
>
> Tom Taylor
>
> On 08/09/2014 4:01 AM, Benoit Claise wrote:
>> Dear all,
>>
>> [Let us call this "OAM Inititiave" for now, as the mailing list is 
>> being renamed from TIME to LIME]
>>
>> During the last IETF meeting, there were various discussions with 
>> different audiences regarding OAM.
>>
>> 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)
>>
> ...
> .
>

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