IETF Logo Mail Archive

Re: [Time] Issue of OAM information Information gathering Gathering from Service Function

Qin Wu <bill.wu@huawei.com> Mon, 30 June 2014 08: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 141B91A0079; Mon, 30 Jun 2014 01:04:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.851
X-Spam-Level:
X-Spam-Status: No, score=-4.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, 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 DG_Dtgd7Ylag; Mon, 30 Jun 2014 01:04:52 -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 073491A0053; Mon, 30 Jun 2014 01:04:51 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml401-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BGQ02417; Mon, 30 Jun 2014 08:04:48 +0000 (GMT)
Received: from nkgeml409-hub.china.huawei.com (10.98.56.40) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 30 Jun 2014 09:04:34 +0100
Received: from NKGEML501-MBS.china.huawei.com ([169.254.2.155]) by nkgeml409-hub.china.huawei.com ([10.98.56.40]) with mapi id 14.03.0158.001; Mon, 30 Jun 2014 16:04:28 +0800
From: Qin Wu <bill.wu@huawei.com>
To: "time@ietf.org" <time@ietf.org>, "opsawg@ietf.org" <opsawg@ietf.org>
Thread-Topic: Issue of OAM information Information gathering Gathering from Service Function
Thread-Index: AQHPkE8W8CxlgcIH60mieSMdYwEo95uIzRhQ
Date: Mon, 30 Jun 2014 08:04:27 +0000
Message-ID: <B8F9A780D330094D99AF023C5877DABA8457B6C5@nkgeml501-mbs.china.huawei.com>
References: <B8F9A780D330094D99AF023C5877DABA845491A9@nkgeml501-mbs.china.huawei.com> <787AE7BB302AE849A7480A190F8B9330016F2E@OPEXCLILM23.corporate.adroot.infra.ftgroup> <B8F9A780D330094D99AF023C5877DABA84573094@nkgeml501-mbs.china.huawei.com> <787AE7BB302AE849A7480A190F8B933001D499@OPEXCLILM23.corporate.adroot.infra.ftgroup> <B8F9A780D330094D99AF023C5877DABA84575736@nkgeml501-mbs.china.huawei.com>
In-Reply-To: <B8F9A780D330094D99AF023C5877DABA84575736@nkgeml501-mbs.china.huawei.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: multipart/alternative; boundary="_000_B8F9A780D330094D99AF023C5877DABA8457B6C5nkgeml501mbschi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: http://mailarchive.ietf.org/arch/msg/time/bBEzmqwaGrzF-IvKp968JpIh4ko
Cc: Gregory Mirsky <gregory.mirsky@ericsson.com>
Subject: Re: [Time] Issue of OAM information Information gathering Gathering from Service Function
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: Mon, 30 Jun 2014 08:04:55 -0000

Hi, Greg:
Thanks for comments on SFC related cases in the problem statement draft.

http://tools.ietf.org/html/draft-ww-opsawg-multi-layer-oam-01
See my reply inline below.

Greg>Service may be in form of NF instantiated in a cloud/data center. I think that in such case there would not be physical node to point to.

[Qin]:Yes, service node can be either physical node or virtual node. Do you have any proposed change here?


Greg> For the purpose of SFC OAM location of SF is irrelevant. Location of SF is OAM information of the lower layer than SFC OAM.
[Qin]:Correct, for SFC OAM, SF location doesn’t matter, what matter is where OAM information is located and where OAM function is performed.
Any proposed change here?

v2.23.0 | Report a Bug | By Email