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

Qin Wu <bill.wu@huawei.com> Wed, 25 June 2014 08:26 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 718711B2B0C; Wed, 25 Jun 2014 01:26:12 -0700 (PDT)
X-Quarantine-ID: <pbMLoQ2Ndf_i>
X-Virus-Scanned: amavisd-new at amsl.com
X-Amavis-Alert: BAD HEADER SECTION, Improper folded header field made up entirely of whitespace (char 20 hex): References: ...@OPEXCLILM23.corporate.adroot.infra.ftgroup>\n
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 pbMLoQ2Ndf_i; Wed, 25 Jun 2014 01:26: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 297581B2B0D; Wed, 25 Jun 2014 01:26:08 -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 BGL19435; Wed, 25 Jun 2014 08:26:07 +0000 (GMT)
Received: from NKGEML404-HUB.china.huawei.com (10.98.56.35) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 25 Jun 2014 09:26:05 +0100
Received: from NKGEML501-MBS.china.huawei.com ([169.254.2.155]) by nkgeml404-hub.china.huawei.com ([10.98.56.35]) with mapi id 14.03.0158.001; Wed, 25 Jun 2014 16:25:58 +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: AQHPkE8W8CxlgcIH60mieSMdYwEo9w==
Date: Wed, 25 Jun 2014 08:25:56 +0000
Message-ID: <B8F9A780D330094D99AF023C5877DABA84575736@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>
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_B8F9A780D330094D99AF023C5877DABA84575736nkgeml501mbschi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: http://mailarchive.ietf.org/arch/msg/time/alSZf1JzjEbNO9phxxidESwBg6I
Cc: "mohamed.boucadair@orange.com" <mohamed.boucadair@orange.com>
Subject: [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: Wed, 25 Jun 2014 08:26:12 -0000

Hi, again:
Regarding Issue of OAM information Gathering from Service Function described in section 4.6,
“
   When the service packets is steered through a set of service nodes
   distributed in the network, each service node work at different
   layers above layer 3 and may have several SFs collocated with itself.
   When OAM mechanism is applied, it is necessary to allow OAM packet
   exchanged between these service nodes or service function at
   different layers. when Service function involved in the SFC doesn't
   support OAM capability(e.g., SF is SFC-unaware service function),
   Service node should be responsible for monitor and diagnose the
   Service function and check service availability to these service
   function.  It is more desirable to allow service function register to
   service node.  Either service function report status to service node
   or service node perform live check to these service function.

   In addition, service functions usually don't have Layer 2-3 switching/
   routing capability and therefore are not aware of any OAM function at
   layer 2-3.  Also when there is no OAM functions at service layers at
   top of layer 3, it is hard to identify layer that can be used to
   gather OAM information when it comes to a fault situation or
   degradation of performance.  For example, when a data packet is
   transmitted from one service function to another service function and
   the data packet may be lost between two service functions or
   discarded by either of service function, assume two service functions
   are embedded in two different service nodes, how to detect the fault
   between them and how to isolate problem to that layer?
”
As you said, The above text can be presented as an example to illustrate a problem not a problem per section.
I agree it is too much specific to SFC case. I am expecting to cover overlay OAM case as well.

In the overlay OAM, When any Overlay Segment fails to deliver user traffic, there is a
need to provide a tool that would enable users to detect such
failures, and a mechanism to isolate faults.  It may also be
desirable to test the data path before mapping user traffic to the
Overlay Segment.

I will see how to abstract common issue from both SFC case and Overlay OAM case.
Yes, we really need a use case draft to discuss what these use case look like and provide high-level requirements
To support various use cases.

Regards!
-Qin
发件人: mohamed.boucadair@orange.com<mailto:mohamed.boucadair@orange.com> [mailto:mohamed.boucadair@orange.com]
发送时间: 2014年6月24日 22:13
收件人: Qin Wu
主题: RE: Unified oam BOF proposal request in IETF 90

Hi Qin,

Please find attached a first set of comments.

Cheers,
Med