Subject: Fwd: TR: Comments on draft-ietf-tewg-measure-04.txt

From: Steven Van den Berghe <[email-masked]>
Date: Wed, 5 Feb 2003 15:26:33 +0100

-- 
Steven Van den Berghe
[email-masked]
Workgroup Broadband Communication Networks
Department Information Technology
Ghent University - Belgium
Phone:  +32 (0)9 267 35 86 | Fax  :  +32 (0)9 267 35 99
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
A computer scientist is someone who, when told to 'Go to Hell',
sees the 'go to', rather than the destination, as harmful.
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*

Subject: TR: Comments on draft-ietf-tewg-measure-04.txt
From: "JACQUENET Christian FTLD/IAP" <[email-masked]>
To: <[email-masked]>
Date: Wed, 5 Feb 2003 12:10:24 +0100

Steven,

For some reason, it seems I've been unsusbcribed from the tewg list:
therefore, I'm not sure this mail has been actually received by the WG
members - it doesn't appear on the archive yet) - could you check this for
me and possibliy forward it to the list, since I'll be out of my office
until next tuesday?

Thanx and cheers,

Christian.

>  -----Message d'origine-----
> De : 	Christian JACQUENET
> [mailto:[email-masked]]
> Envoyé :	mercredi 5 février 2003 11:39
> À :	[email-masked]'
> Objet :	Comments on draft-ietf-tewg-measure-04.txt
> Importance :	Haute
>
> Dear all,
>
> Since the last call deadline for the aforementioned document
> is now very close, here's a couple of comments on this draft
> (sorry about the late show-up).
>
> 1. First of all, to answer Jim's question about the on/off
> target topic, I think the document is perfectly on target, as
> it represents a concise and valuable input for addressing the
> TE measurement issue.
>
> 2. Section 1 (page 1) and in other sections as well: why not
> simply talk about IP networks, rather than "IP-based"
> networks, which may somehow introduce confusion?
>
> 3. Section 4.1. (page 4): I think a MPLS tunnel is an
> *example* of a LSP, but there is no strict equivalence, since
> classical MPLS/LDP operation also refers to the (dynamic)
> establishement of LSP paths, without explicitly activating
> MPLS TE functions. I would therefore suggest a slight
> rewording of the definition of a path, stating that "a path
> refers to an MPLS LSP, this LSP possibly being a
> trafrfic-engineered LSP."
>
> 4. Section 4.2 (page 5): I think the definition of the
> traffic volume (second paragraph) is too restrictive, since
> the network may not have been *designed* to support the
> volume of traffic measured at a given period of time (hence
> the need for planning activities). I'm not a big fan of the
> notion of "level of traffic" either, and I would tehrefore
> suggest slight rewording such as "Traffic volume is the
> amount of traffic measured at a given period of time. Such
> measurement may/should be performed on a regular basis."
>
> 5. Section 5.2 (page 6): two comments.
> 5.1.: generally speaking, there are additional terms that are
> defined in sections different from section 4 (such as "peg
> count" (section 9.2) or  "goodput" (section 8.2): why not
> gather all these definitions in section 4, so as to provide
> some consistency as far as the organization of the document
> is concerned?
> 5.2. I can see a contradiction between the definition of
> QoS/GoS (BTW, the notion of GoS is not that widely used by
> Internet service providers - e.g. we prefer the "Class of
> Service" wording for IP networks where DiffServ mechanisms
> have been activated), as it appears in the second bullet
> (referring to end users), and as it appears in the last
> paragraph of the section (referring to inter-domain QoS). I
> would either provide a reference to RFC 2475, or simply
> delete the last sentence of the paragraph, which is rather
> confusing ("QoS delivered to external peers by an autonomous
> system" is a bit fuzzy to me).
>
> 6. Section 8 (page 9): in the second paragraph, "Currently,
> there *IS* a number of 3rd-party...".
>
> 7. Section 8 (page 10): "...a passive measurement may be to
> obtain packet inter-arrival times by time-stamping *succesive
> packets of the offered traffic* at a selected point in the
> network..." (I think it's more readable). The notion of
> *offered* traffic should deserve some elaboration, otherwise
> I would simply mention "traffic".
>
> 8. Section 9.1 (page 12): the notion of "MPLS path duration"
> should deserve some elaboration.
>
> 9. Section 9.1(page 13):
> - (first paragraph) "...and hence may *BE* used to derive..."
> - I would summarize the note about the delay variation,
> because it somehow unbalances the text with the rest of the
> section, and also because the corresponding text can be found
> in the ITU reference, hence no need to reproduce it in the draft.
>
> 10. Section 11(page 16): I think the second sentence of the
> paragraph is a bit too radical. How about: "This data may be
> gracefully used for the dynamic computation and selection of
> traffic-engineered routes that aim at complying as much as
> possible with the forementioned demands, be they p2p or p2mp"?
>
> 11. Section 11 (page 17): in the second paragraph, I would
> refer to section 8.4 instead of "section on path-based
> measurement bases" for a better readability.
>
> 12. Section 12 (page 18): in the last sentence before section
> 13, I would quote draft-ietf-mpls-lsp-ping-01.txt as a reference.
>
> 13. Section 13 (page 19): (second paragraph) "...these
> functionS to provide..."
>
> 14. Section 14.2 (page 21):
> - COPS is not an information model per se, rather a protocol.
> I would tehrefore suggest a reference to RFC 2753 instead.
> - I would talk about "policy decision points" rather than
> "policy control points"
> - I would introduce the notion of PIB rather than "LDAP
> repositories", to balance with the MIB quotation. After all,
> LDAP is a protocol (among others) to access a
> database/directory. BTW, you might want to take a look at
> http://www.ietf.org/internet-drafts/draft-jacquenet-ip-te-cops-04.txt.
>
> 15. Before section 15 (page 22): I would be tempted to drop
> some lines about some requirements on what could be the basic
> characteristics of a protocol to convey traffic measurement
> data. Something like:
>
> "Although this draft focuses on the motivation for providing
> Internet traffic measurement information, it is assumed that
> this information should be provided to the participating
> devices by means of a communication protocol that would be
> used between the aforementioned participating devices and a
> presumably centralized entity that would aim at storing,
> maintaining and updating this information, as well as making
> appropriate decisions at the right time and under various conditions.
>
> This communication protocol should have the following characteristics:
>
> 1. The protocol should use of a reliable transport mode,
> given the importance of configuration information,
> 2. The protocol architecture should provide a means for
> dynamically provision the configuration information to the
> participating devices, so that it may introduce/contribute to
> a high level of automation in the actual Internet traffic
> measurement operation,
> 3. The protocol should support a reporting mechanism that may
> be used for statistical information retrieval,
> 4. The protocol should support the appropriate security
> mechanisms to provide some guarantees as far as the
> preservation of the confidentiality of the configuration
> information is concerned."
>
> Best regards,
>
> Christian.
>     _________________    ________  ______  ______
>    /_____________   /__ /_    _ / /     / /     /   Christian
> "I'm a ZZ Fan" Jacquenet
>       /_________/  /  /   /  /   /  /  / /  /__/    France
> Telecom Long Distance IAP/CTO
>                /  /  /___/__/___/_____/_/__/____   "The blues
> has got a hold on me,
>               /__/  /__________________________/_ I believe
> I'm gettin' dizzy."
>                 /_______________________________/ - My heads
> in Mississippi.
>
>

---

From: "Dr. Richard W. Tibbs" <[email-masked]>
Date: Wed, 05 Feb 2003 09:40:18 -0500

Thanks, Christian.  This kind of critical review is very welcome.
I will be looking closely at the sections of the document that you 
identified and respond with more comments in a few days.
Rick.

Steven Van den Berghe wrote:

>
> ------------------------------------------------------------------------
>
> Subject:
>
> TR: Comments on draft-ietf-tewg-measure-04.txt
> From:
>
> "JACQUENET Christian FTLD/IAP" <[email-masked]>
> Date:
>
> Wed, 5 Feb 2003 12:10:24 +0100
> To:
>
> <[email-masked]>
>
>
>Steven,
>