Re: [sfc] Review comments for : Performance Measurement Architecture for SFC
Gaurav agrawal <gaurav.agrawal@huawei.com> Thu, 24 November 2016 12:34 UTC
Return-Path: <gaurav.agrawal@huawei.com>
X-Original-To: sfc@ietfa.amsl.com
Delivered-To: sfc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6AF91129960 for <sfc@ietfa.amsl.com>; Thu, 24 Nov 2016 04:34:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.552
X-Spam-Level:
X-Spam-Status: No, score=-5.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DC_PNG_UNO_LARGO=0.001, DRUGS_MUSCLE=0.164, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 QfpyzOj5nD6W for <sfc@ietfa.amsl.com>; Thu, 24 Nov 2016 04:34:45 -0800 (PST)
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 1E2221294C8 for <sfc@ietf.org>; Thu, 24 Nov 2016 04:34:43 -0800 (PST)
Received: from 172.18.7.190 (EHLO lhreml701-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CVW62810; Thu, 24 Nov 2016 12:34:40 +0000 (GMT)
Received: from SZXEMI404-HUB.china.huawei.com (10.82.75.40) by lhreml701-cah.china.huawei.com (10.201.5.93) with Microsoft SMTP Server (TLS) id 14.3.235.1; Thu, 24 Nov 2016 12:34:39 +0000
Received: from SZXEMI502-MBX.china.huawei.com ([169.254.5.216]) by SZXEMI404-HUB.china.huawei.com ([10.82.75.40]) with mapi id 14.03.0235.001; Thu, 24 Nov 2016 20:34:29 +0800
From: Gaurav agrawal <gaurav.agrawal@huawei.com>
To: Phaneendra manda <phaneendra.manda@huawei.com>, "sfc@ietf.org" <sfc@ietf.org>
Thread-Topic: [sfc] Review comments for : Performance Measurement Architecture for SFC
Thread-Index: AdJEpQpj92A8+idKSra49KzWKaNe9ABaxE6Q
Date: Thu, 24 Nov 2016 12:34:29 +0000
Message-ID: <2F2059F256F9B24F82EAC5EE47F446C6E774F768@szxemi502-mbx.china.huawei.com>
References: <6A6AEA8F97B29F4585E1A9F4BE8838747E3A8A57@blreml501-mbx>
In-Reply-To: <6A6AEA8F97B29F4585E1A9F4BE8838747E3A8A57@blreml501-mbx>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
x-originating-ip: [10.18.250.69]
Content-Type: multipart/related; boundary="_004_2F2059F256F9B24F82EAC5EE47F446C6E774F768szxemi502mbxchi_"; type="multipart/alternative"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090203.5836DE62.0072, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.5.216, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32
X-Mirapoint-Loop-Id: 1d8962f98b17ccba53eeeccce436bd63
Archived-At: <https://mailarchive.ietf.org/arch/msg/sfc/__HicQ8IiuxF7L_WG_NZevF1N7w>
Cc: Aruna kumar padhi <aruna.padhi@huawei.com>
Subject: Re: [sfc] Review comments for : Performance Measurement Architecture for SFC
X-BeenThere: sfc@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Network Service Chaining <sfc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sfc>, <mailto:sfc-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/sfc/>
List-Post: <mailto:sfc@ietf.org>
List-Help: <mailto:sfc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sfc>, <mailto:sfc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 24 Nov 2016 12:34:48 -0000
Hi Phaneendra, Thanks for your review and suggestions. Please find my in-line comments. Thanks and Regards, Gaurav From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Phaneendra manda Sent: 2016年11月22日 15:15 To: sfc@ietf.org Cc: Aruna kumar padhi Subject: [sfc] Review comments for : Performance Measurement Architecture for SFC Hi, Please find the below review comments for draft-agv-sfc-performance-measurement-architecture-02 1. In section 2 Measurement Controller: An entity that controls and coordinates a set of measurement functions. The measurement controller is responsible for programming the performance measurement instance at measurement classifier and updating the same to measurement collector, additionally it can inject probe packets in SFP for measurement. can be Measurement Controller: An entity that controls and coordinates a set of measurement functions. The measurement controller is responsible for programming the performance measurement instance(PMI) at measurement classifier and updating the same to measurement collector, additionally it can inject probe packets in SFP for measurement. While going through document there is no abbreviation mapped for PMI. Marking this would improve the readability [Gaurav] Agree and text will be updated accordingly. 2. In section 3 Active measurement : Measurement controller induce probe packets with encoded performance measurement data or programs PMI at measurement classifier which will in turn induce probe packets with encoded performance measurement data. measurement controller updates the PMI to measurement collector. Participating measurement agents based on received encoded information carry out measurements and reports the collected data to measurement collector. measurement collector co-relates received data and provides measurement results. can be Active measurement : Measurement controller induce probe packets with encoded performance measurement data or programs PMI at measurement classifier which will in turn induce probe packets with encoded performance measurement data. Measurement controller updates the PMI to measurement collector. Participating measurement agents based on received encoded information carry out measurements and reports the collected data to measurement collector. measurement collector co-relates received data and provides measurement results. [Gaurav] Agree and text will be updated accordingly. 3. In section 4.1 "PMF identifier" - PMF is used without providing any abbreviation. [Gaurav] Agree and will be added in abbreviation. We also want to add text that it’s only required in deployments expecting to monitor fine grained flows within a coarse-grained flows. 4. In section 4.3.3 MA identifier has two parts 1) Node identifier - 24 bit a) For SFF: MUST be unique number assigned by controller b) For SF: All zero. Context identifier itself identifies SF node. I think here it should be Service Index. Context identifier referred nowhere in the draft. [Gaurav] Yes, it should be Service Index. Also we plan to provide more information about this: 1) For SF, Node identifier needn’t be explicitly configured (it’s all 0), as SI is sufficient enough to uniquely identify SF. 2) For SFF, Node identifier needs to be programmed. 3) MA identifier is combination of Node Identifier + SI (SI value is obtained from packet itself) 4) MA identifier is NOT required in case of E2E or Hop by hop measurement as PM type itself indicates whether SF/SFF needs to participate in measurement. Will update text to clarify this in draft. 5. In section 4.3.3 - At MA : Presence of self service index triggers the PM collection & reporting can be - At MA : Presence of self MA identifier triggers the PM collection & reporting Because of below reasons - A service function does not know its service index - As mentioned in section 5, point 1, it is mentioned Measurement controller programs the MA identifier to MA. So the MA knows the MA identifier not the service index. [Gaurav] Idea is to identify the SF or SFF in a chain (Note: This is not required for E2E or hop by hop measurement, only required in case measurement is specific to a set of SF/SFF). Let me elaborate how draft plan to handle it. Identify SFF: Since SPI+SI alone is not sufficient to identify SFF, draft introduce a new entity called node identifier to be configured by Controller in SFF. MA identifier for SFF is then the combination of “Node Identifier (programmed by Controller) + SI (this value is obtained from SFC service header in the packet)”. Now to identify whether it needs to carry out the measurement, SFF checks its MA identifier presence in the packet metadata. Identify SF: For this node identifier is not required. MA identifier of SF is “Node identifier (all zero) + SI (SI value in packet)”. SF checks its MA identifier presence in packet metadata Draft will add additional text to clarify this. 6. In section 2 In the description of Measurement Classifier : It can also generate probe packet. Need to be updated in description (In section 6 it is mentioned Measurement classifier may generate probe packet based on the instruction by measurement controller. [Gaurav] Agree, description will be updated accordingly. 7. In Section 4.3.3 A service function can be part of multiple service function chains, In this case the Measurement Agent will have 2 MA ID’s configured. As per the draft in section 4.3.3, there is no consideration for Service Path Index(SPI) while MA Identifier construction. So MA Identifier may have conflict. [Gaurav] Yes for two different chains MA identifier computed may be same, but that is fine as this MA identifier is just used to check if the given SFF needs to carry out any measurement by checking its presence in SFC packet metadata. Please look at below example for more details. In below example it’s expected to carry measurement at SFF1 Port P1, P2, P3, P4 and its also expected to carry out measurement at SF3. So below picture depicts the behavior. [cid:image001.png@01D2467D.31D8E500] 8. In Section 4.3.3 There is no clarity on Measurement Agent Identifier with PM type value on how it is encoded. Like few bits are used for MA Identifier and few bits are used for PM type. It is just mentioned MA Identifier with PM type. I think more details can be provided here. [Gaurav] Agree and text will be added for the same. Thanks & Regards Phaneendra Manda.
- [sfc] Review comments for : Performance Measureme… Phaneendra manda
- Re: [sfc] Review comments for : Performance Measu… Gaurav agrawal