[mpls] [mpls-tp] Several open issues on draft-xiao-mpls-tp-throughput-estimation-00
xiao.min2@zte.com.cn Fri, 06 August 2010 05:36 UTC
Return-Path: <xiao.min2@zte.com.cn>
X-Original-To: mpls@core3.amsl.com
Delivered-To: mpls@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 22E5D3A684D; Thu, 5 Aug 2010 22:36:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -100.787
X-Spam-Level:
X-Spam-Status: No, score=-100.787 tagged_above=-999 required=5 tests=[AWL=1.051, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_DOUBLE_IP_LOOSE=0.76, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id faSPNZyrjJE0; Thu, 5 Aug 2010 22:36:07 -0700 (PDT)
Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by core3.amsl.com (Postfix) with ESMTP id 2999A3A6832; Thu, 5 Aug 2010 22:36:04 -0700 (PDT)
Received: from [10.30.17.100] by mx5.zte.com.cn with surfront esmtp id 205951570495873; Fri, 6 Aug 2010 13:35:25 +0800 (CST)
Received: from [10.30.3.19] by [192.168.168.16] with StormMail ESMTP id 14146.1570495873; Fri, 6 Aug 2010 13:27:50 +0800 (CST)
Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse2.zte.com.cn with ESMTP id o765ZhQx023941; Fri, 6 Aug 2010 13:35:44 +0800 (CST) (envelope-from xiao.min2@zte.com.cn)
To: mpls@ietf.org, mpls-tp@ietf.org
MIME-Version: 1.0
X-Mailer: Lotus Notes Release 6.5.4 March 27, 2005
Message-ID: <OFB24FBA92.2A65AF1E-ON48257777.001E0969-48257777.001EB7AE@zte.com.cn>
From: xiao.min2@zte.com.cn
Date: Fri, 06 Aug 2010 13:35:13 +0800
X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 6.5.4|March 27, 2005) at 2010-08-06 13:35:35, Serialize complete at 2010-08-06 13:35:35
Content-Type: multipart/alternative; boundary="=_alternative 001EB7AB48257777_="
X-MAIL: mse2.zte.com.cn o765ZhQx023941
Subject: [mpls] [mpls-tp] Several open issues on draft-xiao-mpls-tp-throughput-estimation-00
X-BeenThere: mpls@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Multi-Protocol Label Switching WG <mpls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/mpls>, <mailto:mpls-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mpls>
List-Post: <mailto:mpls@ietf.org>
List-Help: <mailto:mpls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mpls>, <mailto:mpls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 06 Aug 2010 05:36:10 -0000
Hi all, In light of the previous comments and discussions on this draft, there are still some open issues which need to be closed before updating it, so I want to request for your opinions, details as follow: 1. Wouldn't it be better to have a threshold on the acceptable frame loss rate and not require absolutely no packet loss? This question was raised by Ayal Lior (Ayal.Lior@celtro.com) As I know in practice the threshold is a configurable parameter when executing throughput measurement, but in RFC1242 and RFC2544 the throughput is defined as that way no packet loss permitted. 2. How to align the format of test data packets between draft-boutros-mpls-tp-li-lb-01 and this draft? As I said in my presentation of this draft, IMO in order to simplify the implementation, the format of test data packets should be the same whether it's used for data plane loopback or throughput estimation. Now the format of data packets defined in section 5 of draft-boutros-mpls-tp-li-lb-01 is different from the format of test packets defined in section 3.2 of this draft. I prefer the format with OAM encapsulation defined in this draft, and my reason is that with this format it's easy to distinguish the test data packets from other packets when counting them. 3. Is there a need to simplify the procedures defined in this draft and how? I received the comment both in the mailing list and in private discussions that the procedures defined in this draft are some complex, but I have no idea about the proposed simplified solution, and IMHO the procedures defined in this draft are enough efficient and also the usual operations for throughput measurement. Hope for your concrete suggestions. Any other comment and discussion are welcome. Best Regards, Xiao Min