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
no
unpleasant 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
and
after 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
Lou
Berger
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.
Henk
Matt & 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