[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

To: "Thomas D. Nadeau" <tom.nadeau at bt.com>
Subject: Re: [ippm] [CCAMP] [Fwd: IPPM expert review request]
From: Lou Berger <lberger at labn.net>
Date: Wed, 19 Aug 2009 12:20:24 -0400
Cc: zhangguoying at mail.ritt.com.cn, Rschrage <rschrage at schrageconsult.net>, 'IETF IPPM WG' <ippm at ietf.org>, ccamp at ietf.org, 'Henk Uijterwaal' <henk at ripe.net>, 'Weiqiang Sun' <sunwq at MIT.EDU>
Delivered-to: ippm at core3.amsl.com
Domainkey-signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=labn.net; h=Received:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:X-Enigmail-Version:Content-Type:Content-Transfer-Encoding:X-Identified-User; b=g9TUnunNhuFR5iYRnOz3X02WwnJENkBfhuGfVGHCyS7NSKWe9R81kA+CmBZ39rm75hlQ/zBACkK/JffBMRI02B8sVh8b5dWah3JMjJFhZtFlPwB3K5xAjul3Aa4fxDRk;
In-reply-to: <C6B19005.16A30%tom.nadeau at bt.com>
List-archive: <http://www.ietf.org/mail-archive/web/ippm>
List-help: <mailto:ippm-request@ietf.org?subject=help>
List-id: IETF IP Performance Metrics Working Group <ippm.ietf.org>
List-post: <mailto:ippm@ietf.org>
List-subscribe: <https://www.ietf.org/mailman/listinfo/ippm>, <mailto:ippm-request@ietf.org?subject=subscribe>
List-unsubscribe: <https://www.ietf.org/mailman/listinfo/ippm>, <mailto:ippm-request@ietf.org?subject=unsubscribe>
References: <C6B19005.16A30%tom.nadeau at bt.com>
User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b3pre) Gecko/20090408 Eudora/3.0b2

Tom,
	This document covers evaluation metrics that you'd expect to see
produced by a test tool rather than from the systems (DUTs) themselves.
 In short, no GMPLS network node is expected to implement this spec.

WRT the quoted text.  I viewed this as referring to a benchmarking tool
that is deployed in an operational network.  I can see how this can be
misinterpreted and I have no objection to asking that the text be
removed from the document.

Will dropping this text address your concerns?

Note that this document has been a WG document for well over a year and
was first discussed in the WG ~2.5 years ago.

Lou

On 8/19/2009 11:18 AM, Thomas D. Nadeau wrote:
>     Lou,
> 
>     I'd like to ask a question about this draft. How does it relate to (or
> not) to any of the GMPLS MIBs? As you know, the MIBs contain performance
> counters. If these metrics present in this draft do not coincide with the
> MIBs, this will cause more work for implementations. In particular, the
> following statement in this document worries me:
> 
>    On the other hand, it can also be used in operational environments for
>    carriers to monitor the control plane operation in real-time.  For
>    example, a new object can be added to GMPLS TE STD MIB [RFC4802] so
>    that the current and past control plane performance can be monitored
>    through network management systems.  The extension of TE-MIB to
>    support the defined metrics is outside the scope of this document.
> 
> 
>     Does the WG really want to progress a document that requires these
> changes?
> 
>     --Tom
> 
> 
> 
> On 8/19/09 9:57 AM, "Rschrage" <rschrage at schrageconsult.net> wrote:
> 
>> 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
>> _______________________________________________
>> CCAMP mailing list
>> CCAMP at ietf.org
>> https://www.ietf.org/mailman/listinfo/ccamp
>

Follow-Ups:
- Re: [ippm] [CCAMP] [Fwd: IPPM expert review request]
  - From: Thomas D. Nadeau

References:
- Re: [ippm] [CCAMP] [Fwd: IPPM expert review request]
  - From: Thomas D. Nadeau

Prev by Date: Re: [ippm] [CCAMP] [Fwd: IPPM expert review request]
Next by Date: Re: [ippm] [CCAMP] [Fwd: IPPM expert review request]
Previous by thread: Re: [ippm] [CCAMP] [Fwd: IPPM expert review request]
Next by thread: Re: [ippm] [CCAMP] [Fwd: IPPM expert review request]
Index(es):
- Date
- Thread