--- Begin Message ---
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:christian.jacquenet@francetelecom.com]
> Envoyé : mercredi 5 février 2003 11:39
> À : 'te-wg@ops.ietf.org'
> 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.
>
>
--- End Message ---