Subject: Re: [ippm] [Fwd: IPPM expert review request]

From: Lou Berger <[email-masked]>
Date: Tue, 18 Aug 2009 20:40:52 -0400

Reinhard,
	Thank you very much for the comments.

draft-ietf-ccamp-lsp-dppm Authors,
	Please address the comments/discussion points raised.

Lou

On 8/18/2009 8:23 AM, Rschrage wrote:
> 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
> [email-masked]
> 
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Lou
> Berger
> Sent: Dienstag, 28. Juli 2009 14:59
> To: Henk Uijterwaal
> Cc: [email-masked]; BRUNGARD, DEBORAH A, ATTLABS;
> [email-masked]; IETF IPPM WG
> Subject: Re: [ippm] [Fwd: IPPM expert review request]
> 
> Hank/Reinhard,
> 
> Thank you very much for undertaking this review.  Please cc
> [email-masked] 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 ([email-masked]) 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 <[email-masked]>
>>> To: [email-masked]
>>> CC: Brungard, Deborah A, ALABS <[email-masked]>, [email-masked],   
>>> zhangguoying <[email-masked]>
>>>
>>> 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ippm

---

From: "Weiqiang Sun" <[email-masked]>
Date: Wed, 19 Aug 2009 14:48:59 +0800

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" <[email-masked]>
Sent: Tuesday, August 18, 2009 8:23 PM
To: "'Lou Berger'" <[email-masked]>; "'Henk Uijterwaal'" <[email-masked]>
Cc: <[email-masked]>; "'BRUNGARD, DEBORAH A,	ATTLABS'" 
<[email-masked]>; <[email-masked]>; "'IETF IPPM WG'" <[email-masked]>; 
<[email-masked]>
Subject: RE: [ippm] [Fwd: IPPM expert review request]