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

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

To: Lou Berger <lberger at labn.net>
Subject: Re: [ippm] [CCAMP] [Fwd: IPPM expert review request]
From: "Thomas D. Nadeau" <tom.nadeau at bt.com>
Date: Wed, 19 Aug 2009 15:15:06 -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
In-reply-to: <4A8C2648.9000002 at labn.net>
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>
Thread-index: AcohAVxCDlmyJZofI0exyOyPZQSTtg==
Thread-topic: [CCAMP] [ippm] [Fwd: IPPM expert review request]
User-agent: Microsoft-Entourage/12.20.0.090605

On 8/19/09 12:20 PM, "Lou Berger" <lberger at labn.net> wrote:

> 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?

    Yes and no. For the current document I think yes, but from a wider WG
perspective, does the WG believe that MIBs can be used for the purposes of
measuring metrics (say as the target for a tool like you refer to above)?
Or does the WG feel new MIBs (or other APIs) should be developed to support
such a tool?  The worry I have, as an operator, is the introduction of such
metrics without a standardized means of getting at them in devices. This
will result in a hodgepodge of CLI-like mechanisms for anyone wishing to
produce a measurement tool, thus increasing the costs to operators wishing
to use said tools. 
 
> 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.

    That is a valid point, but as you know many documents unfortunately
don't get the attention they deserve until a LC is issued. :(

    --Tom



 
> 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
>> 

-- 
Principal Architect - 21CN Networks

References:
- Re: [ippm] [CCAMP] [Fwd: IPPM expert review request]
  - From: Lou Berger

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