Hi all, pls find attached a further updated edition of previous revised doc draft-ietf-ccamp-lsp-dppm-06. I believe this is as far as we can go for the moment before a mutual satisfactory understanding has been reached and a new draft has been issued by the authors. Again, pls feel free to comment. Many thanks. Brgds. 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 Weiqiang Sun Sent: Mittwoch, 19. August 2009 09:28 To: Rschrage; 'Lou Berger'; 'Henk Uijterwaal' Cc: ccamp at ietf.org; zhangguoying at mail.ritt.com.cn; 'BRUNGARD, DEBORAH A, ATTLABS'; 'IETF IPPM WG' Subject: Re: [ippm] [Fwd: IPPM expert review request] More responses below: RS4. Should be more specific as to why this metric is no simple function of single uni-directional LSP Setup Delay metric, i.e. why can it not be deduced from single LSP Setup Delay? [sunwq] This point is raised regarding the sentence "The time needed to setup a large number of LSPs during a short time period can not be deduced by single LSP setup delay." One reason is that when a large number of LSPs in being setup during a short period of time, the control plane may be crowded or even overwhelmed by the large number of signaling and routing messages. This may significantly slow down the processing of a particular signaling message, which will results in longer LSP provisioning delays. Are you suggesting that we add similar explanations to the document? We'd love to do that if you feel it is necessary. RS5. The current definition only addresses multiple uni-directional LSP setups between two nodes ID0 and ID1. What about the the case when ID0 is to setup multiple uni-directional LSP setups to different egress nodes ID1, ID2, ID3,.,IDN? [sunwq] Yes, it is a useful case. Likewise you would expect a case to establish a varied number of (instead of one) LSPs to a set of destinations. Our suggestion is that this case is approached by integrating the defined methodologies of single/multiple LSPs provisioning delay, in the form of a particular testing case, rather than a formal testing methodology. This is in fact a trade-off between complexity and accuracy. Best regards, Weiqiang -- Weiqiang Sun Shanghai Jiao Tong University http://front.sjtu.edu.cn/~sunwq/ -------------------------------------------------- From: "Weiqiang Sun" <sunwq at mit.edu> Sent: Wednesday, August 19, 2009 2:48 PM To: "Rschrage" <rschrage at schrageconsult.net>; "'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>; "'IETF IPPM WG'" <ippm at ietf.org>; <ccamp at ietf.org> Subject: Re: [ippm] [Fwd: IPPM expert review request] > 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 >> _______________________________________________ ippm mailing list ippm at ietf.org https://www.ietf.org/mailman/listinfo/ippm
Attachment:
draft-ietf-ccamp-lsp-dppm-06 Revised 1.doc
Description: MS-Word document