Subject: Re: [CCAMP] convergence time for flooding information draft submitted: draft-zhangm-ccamp-metric-00

From: Weiqiang Sun <[email-masked]>
Date: Tue, 09 Nov 2010 10:28:14 +0800

Folks, 

The draft is good to start with, but still many issues to fix... Below is
few comments that come up to my mind during first read. I will post again in
case I have more comments.

A few editorial comments:
1. nodes or links failures MAY ... -> node or link failures may...
The use of standard languages (MAY, MUST, SHOULD/NOTŠ) is only necessary
when you define/specify a protocol behavior (an implementation SHOULD or
SHOULD NOT do something, for example). In another word, they are used to
regulate implementation behaviors. They are not intended to replace all use
of ``may'', ``should'' or ``must''.
2. After network updating..., because it MAY -> After network upgrading...
because it may
3. section 3: convergence ability -> convergence performance

Technical comments:
1. The convergence time is dependent on network size and topology. Should
these factors be taken into account when you do a measurement? Should these
factor be reported at least together with the metric value themselves?

2. In 4.1.2, you said that "All control node in this domain switch on
normally"
   1) What do you mean by normally? From a methodology point of view it is
not clear enough. Should all control nodes be switched on simultaneously or
they can be switched on one by one?
   2) Should the data plane be switched on as well?

3. The way of reporting the metric is not clearly defined. Reporting the
metric value itself is clearly not enough, given that this value is
dependent on and may be affected by many factors. You may need a separate
(sub-)section to define what parameters should be reported, along side the
metric value itself.

4. You have an incomplete section 6. To me, it is not wise to require any
changes to existing protocols (OSPF-TE or RSVP-TE), as this will make this
work difficult (if not impossible) to progress. I would recommend an
out-of-band measurement.

Best regards,
Weiqiang

On 10/29/10 9:18 AM, "hui ding" <[email-masked]> wrote:

> Hi,
> 
> The following draft has been submitted. Please review. Comments are
> appreciated. We will give a presentation on IETF 79.
> Please review. Comments are appreciated.
> 
> http://datatracker.ietf.org/doc/draft-zhangm-ccamp-metric/
> <https://datatracker.ietf.org/doc/draft-ashok-ccamp-gmpls-ospf-g709/>
> 
> thanks
> Authors
> 
> ---------- Forwarded message ----------
> From: IETF I-D Submission Tool <[email-masked]>
> Date: Mon, Oct 18, 2010 at 11:25 PM
> Subject: New Version Notification for draft-zhangm-ccamp-metric-00
> To: [email-masked]
> Cc: [email-masked], [email-masked], [email-masked],
> [email-masked]
> 
> 
> 
> A new version of I-D, draft-zhangm-ccamp-metric-00.txt has been successfully
> submitted by Hui Ding and posted to the IETF repository.
> 
> Filename:        draft-zhangm-ccamp-metric
> Revision:        00
> Title:           Performance Metric of Convergence Time of Information
> Flooding in Multi- Domain GMPLS Networks
> Creation_date:   2010-10-18
> WG ID:           Independent Submission
> Number_of_pages: 17
> 
> Abstract:
> To keep the information of topology and links resource synchronized
> at each control node, massive messages are necessary to be flooded in
> the control plane of General Multi-Protocol Label Switching (GMPLS)
> based multi-domain networks.  The convergence time of information
> flooding will have a significant impact on the performance of the
> networks.  So measuring and analyzing the convergence time of
> information flooding in multi-domains becomes very important.  A
> performance metric of convergence time of information flooding is
> proposed to characterize the ability of information synchronization
> in multi-domain networks.
> 
> 
> 
> The IETF Secretariat.
> 
> 
> 
> _______________________________________________
> CCAMP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ccamp

---

From: hui ding <[email-masked]>
Date: Tue, 9 Nov 2010 20:55:06 +0800

Hi Weiqiang,

Thank you very much for the comments. They are very helpful indeed.

Please see inline.

On Tue, Nov 9, 2010 at 10:28 AM, Weiqiang Sun <[email-masked]> wrote:

> The use of standard languages (MAY, MUST, SHOULD/NOT…) is only necessary
> Hui Ding: Thank you for pointing out my mistakes, this is the first time
> that I wrote an Internet-Draft and I will bear your comments in mind.
>
> Technical comments:
> Ding: Yes, they do. The convergence time largely depends on network size
> and topology, we will consider to report the network size (nodes number and
> links number) with the metric. But topology is not easy to report, topology
> in core network is mesh is most cases.
>
 Hui: 1) By normally I mean all the control nodes function well after being
> switched on. All control nodes be switched on simultaneousely.
> Hui: Indeed, we will illustrate reporting the metric in -01 version. And a
> seperate section may be added as well.
>
> Hui: I agree. Out-of-band measurement is appropriate for performance
> metric. The methodologies we proposed do not necessarily need to change
> exisiting protocols, they just need a sign to record the right moments.
> - Show quoted text -
>
> Best regards,
> Weiqiang
>
>
> On 10/29/10 9:18 AM, "hui ding" <[email-masked]<http://[email-masked]/>>
> wrote:
>
> - Show quoted text -
>
> Hi,
>
> http://datatracker.ietf.org/doc/draft-zhangm-ccamp-metric/ <
> https://datatracker.ietf.org/doc/draft-ashok-ccamp-gmpls-ospf-g709/>
>
> thanks
> Authors
>
> From: *IETF I-D Submission Tool* <[email-masked]>
> To: [email-masked] <http://[email-masked]/>
> A new version of I-D, draft-zhangm-ccamp-metric-00.txt has been
> successfully submitted by Hui Ding and posted to the IETF repository.
>
> ------------------------------

-- 
Hui Ding

---

From: Weiqiang Sun <[email-masked]>
Date: Tue, 09 Nov 2010 21:48:07 +0800

Hi Hui,

Thanks for your reply. Please see below.

>> Ding: Yes, they do. The convergence time largely depends on network size and
>> topology, we will consider to report the network size (nodes number and links
>> number) with the metric. But topology is not easy to report, topology in core
>> network is mesh is most cases.
>> WQ: Would it be better if you provide some typical topologies (probably as
>> test cases)? The measurement result will be more meaningful if it is reported
>> together with the network topology. You can use linear and/or full mesh
>> topologies or other regular topologies as examples.
>> 
>> WQ: In that case, I would suggest that you clarify this a little bit and add
>> somewhere in the draft that it is intended for lab testing (since otherwise
>> it is impossible to achieve).
>> 
>> metric value itself is clearly not enough, given that this value is dependent
>> on and may be affected by many factors. You may need a separate (sub-)section
>> to define what parameters should be reported, along side the metric value
>> itself.
>> WQ: that will be great. Please consider my suggestion on the choice of
>> topologies as well.
>> 
>> Hui: I agree. Out-of-band measurement is appropriate for performance metric.
>> The methodologies we proposed do not necessarily need to change exisiting
>> protocols, they just need a sign to record the right moments.
>> 
>> - Show quoted text -
>> 
>> Best regards,
>> Weiqiang