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

[hui ding <[e-mail]>]

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 <[e-mail]> wrote:

>  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
> 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:
> 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?
> 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.
>
> 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?
>
 Hui: 1) By normally I mean all the control nodes function well after being
> switched on. All control nodes be switched on simultaneousely.
>  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.
> Hui: Indeed, we will illustrate reporting the metric in -01 version. And a
> seperate section may be added as well.
>
> 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.
> 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" <[e-mail]<http://[e-mail]/>>
> wrote:
>
> - Show quoted text -
>
> 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* <[e-mail]>
> Date: Mon, Oct 18, 2010 at 11:25 PM
> Subject: New Version Notification for draft-zhangm-ccamp-metric-00
> To: [e-mail] <http://[e-mail]/>
> Cc: [e-mail], [e-mail], [e-mail],
> [e-mail]
>
>
>
> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ccamp
>
>


-- 
Hui Ding