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

Qin Wu <bill.wu@huawei.com> Thu, 03 July 2014 07:49 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 3CC5C1A01AE; Thu, 3 Jul 2014 00:49:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.251
X-Spam-Level:
X-Spam-Status: No, score=-4.251 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_47=0.6, 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 DjvKtKJRzCds; Thu, 3 Jul 2014 00:49:37 -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 47D081A008D; Thu, 3 Jul 2014 00:49:36 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml405-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BGS98055; Thu, 03 Jul 2014 07:49:34 +0000 (GMT)
Received: from NKGEML401-HUB.china.huawei.com (10.98.56.32) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 3 Jul 2014 08:49:33 +0100
Received: from NKGEML501-MBS.china.huawei.com ([169.254.2.155]) by nkgeml401-hub.china.huawei.com ([10.98.56.32]) with mapi id 14.03.0158.001; Thu, 3 Jul 2014 15:49:30 +0800
From: Qin Wu <bill.wu@huawei.com>
To: Gregory Mirsky <gregory.mirsky@ericsson.com>, "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: AQHPkE8W8CxlgcIH60mieSMdYwEo95uIzRhQgAM9N3CAAfsMcA==
Date: Thu, 03 Jul 2014 07:49:30 +0000
Message-ID: <B8F9A780D330094D99AF023C5877DABA8457CE92@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> <B8F9A780D330094D99AF023C5877DABA8457B6C5@nkgeml501-mbs.china.huawei.com> <7347100B5761DC41A166AC17F22DF1121B7E5543@eusaamb103.ericsson.se>
In-Reply-To: <7347100B5761DC41A166AC17F22DF1121B7E5543@eusaamb103.ericsson.se>
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_B8F9A780D330094D99AF023C5877DABA8457CE92nkgeml501mbschi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: http://mailarchive.ietf.org/arch/msg/time/7jMWj7yu_Hv2ewDyhUa-OY4gpLg
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: Thu, 03 Jul 2014 07:49:39 -0000

Hi, Greg:
I think the relationship between service node and service function is service node can host service function, service function maintain affinity with service node.
Service node can be virtual or physical.
Therefore to avoid confusion, I propose the following change:
s/service node/service node(virtual or physical) hosting service function.

Regards!
-Qin
发件人: Gregory Mirsky [mailto:gregory.mirsky@ericsson.com]
发送时间: 2014年7月2日 9:53
收件人: Qin Wu; time@ietf.org; opsawg@ietf.org
主题: RE: Issue of OAM information Information gathering Gathering from Service Function

Hi Qin,
please find my notes in-line and tagged by GIM>>.

                Regards,
                                Greg

From: Qin Wu [mailto:bill.wu@huawei.com]
Sent: Monday, June 30, 2014 1:04 AM
To: time@ietf.org<mailto:time@ietf.org>; opsawg@ietf.org<mailto:opsawg@ietf.org>
Cc: Gregory Mirsky
Subject: RE: Issue of OAM information Information gathering Gathering from Service Function

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?
GIM>> I’d propose to use “Service Function” in place of “service node” as that seems to be accepted term for an element of an Service Function Chain.


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?

GIM>> Service Functions may be applied at different network layers, not only above Layer 3. (Interesting, if SFC may include SFs at different layers.)  I’d propose to edit the first sentence of the Section 3.6.1 to
The service packets are steered through a set of service functions distributed in the network that may be applied at different layers of the network protocol stack.