Hi Reinhard,Many thanks for doing the careful review. We appreciate your many wording suggestions. We will go through these one by one and adopt those we feel appropriate. In this email I will not list all the comments since these will not lead to major technical changes.
Below I try to respond to the points you raised in the revision. RS1.This would imply that the metric may produce a range of several values at one time with the minimum value to be taken from that range. I believe what the authors are trying to say is, that the LSP Setup Delay Metric provides a lower bound on all possible LSP Delay Metrics of actually instantiated LSPs, or in other words: an actual LSP Delay Metric cannot get smaller than an LSP Setup Delay Metric.
[sunwq]This point is raised regarding the motivation of the sigleton definition of Single Uni-directional LSP Setup Delay (ie. 4.1, para 2). We are trying to say that the minimum value of this metric reflects the (likely) single lsp setup delay when the control plane is lightly loaded. The formal definition of the minimum value is in "14.1 The minimum of metric" In fact we have inherited this from the IPPM documents (see RFC 2681, page 2 section 1.1 bullet 3).
RS2. How? Should there be a methodology be defined for this? [sunwq]This point is raised regarding the sentense in our methodologies sections - "Make sure that the network has enough resource to set up the requested LSP." We have assumed that test personnel should have adequate expertise in allocating enough resources for the testing. The allocation of resources for the testing purpose can be very test specific and we believe it is quite outside the scope of this document.
RS3.Too vague? As both timestamps are to be taken on the same ingress node, they should be taken at the same application/network level.
[sunwq]This point is raised regarding the sentense "If the corresponding RESV message arrives within a reasonable period of time, take the timestamp (T2) as soon as possible upon receipt of the message." Yes, ideally the timestamp should be taken immediately after the reception of the RESV message. The wording "as soon as possible" is used to allow for some flexibility when RESV message needs to be propagated to certain modules where timestamp-taking is most appropriate. And again, this text is inherited from the IPPM documents (see RFC 2681 page 7, bullet 3).
Thanks again and looking forward to your further comments and revisions. Weiqiang -- Weiqiang Sun Shanghai Jiao Tong University http://front.sjtu.edu.cn/~sunwq/ -------------------------------------------------- From: "Rschrage" <rschrage at schrageconsult.net> Sent: Tuesday, August 18, 2009 8:23 PM To: "'Lou Berger'" <lberger at labn.net>; "'Henk Uijterwaal'" <henk at ripe.net>Cc: <zhangguoying at mail.ritt.com.cn>; "'BRUNGARD, DEBORAH A, ATTLABS'" <dbrungard at att.com>; <sunwq at mit.edu>; "'IETF IPPM WG'" <ippm at ietf.org>; <ccamp at ietf.org>
Subject: RE: [ippm] [Fwd: IPPM expert review request]
Hello, sorry for late response- Nevertheless here is a first edition of my revision of doc draft-ietf-ccamp-lsp-dppm-06. The doc has been saved in Word 2003 format to easily track changes.I am using Kaspersky Anti Virus 2010 software so I trust there should be nounpleasant surprises when downloading the attached word doc.I thought it would be advisable to first address the suggested comments and questions upto and including the uni-directional LSP setup delay metric andafter that to continue with the bi-directional and sample definitions as covered in the doc. Please let me have your thoughts on this. Many thanks. Reinhard Schrage Tel: +49 (0) 5137 909540 Mobile: +49 (0) 172 26.36.046 reinhard at schrageconsult.com -----Original Message-----From: ippm-bounces at ietf.org [mailto:ippm-bounces at ietf.org] On Behalf Of LouBerger Sent: Dienstag, 28. Juli 2009 14:59 To: Henk Uijterwaal Cc: zhangguoying at mail.ritt.com.cn; BRUNGARD, DEBORAH A, ATTLABS; sunwq at mit.edu; IETF IPPM WG Subject: Re: [ippm] [Fwd: IPPM expert review request] Hank/Reinhard, Thank you very much for undertaking this review. Please cc ccamp at ietf.org on any comments you may have. Lou On 7/28/2009 6:47 AM, Henk Uijterwaal wrote:Lou, others,We received the request for a review of a document currently under discussion in the CCAMP WG, please see below. Is there anybody who has time to do this review in the near future?Reinhard Schrage (rschrage at schrageconsult.net) has voluntered to do this. Reinhard: please post anything you find to both the list and the authors. And thank you for doing this. HenkMatt & Henk -------- Original Message -------- Subject: IPPM expert review request Date: Fri, 24 Jul 2009 15:57:41 -0400 From: Lou Berger <lberger at labn.net> To: ippm-chairs at tools.ietf.org CC: Brungard, Deborah A, ALABS <dbrungard at att.com>, sunwq at mit.edu, zhangguoying <zhangguoying at mail.ritt.com.cn> Hi, We, the CCAMP WG chairs, would like to request that the IPPM WG review a draft that is progressing through the CCAMP WG. This work applies IPPM approaches to GMPLS. The document we'd like reviewed is available at: http://tools.ietf.org/html/draft-ietf-ccamp-lsp-dppm-06 Is this acceptable? Can you undertake this review? Alternatively, we can just last call the document in your WG (it has already passed CCAMP WG LC). Thank you, Lou (and Deborah)_______________________________________________ ippm mailing list ippm at ietf.org https://www.ietf.org/mailman/listinfo/ippm