RE: **Please comment on these proposals:** TE Measurement - 02 version

["Lai, Wai S (Waisum), ALASO" <wlai@att.com>]

Tom,
   Many thanks for your positive and supportive comments of our work.
We will incorporate your proposals in the next version.  Other authors
please chime in.
   Regarding VPNs, we are not really talking about them per se.
We just want to point out that path-based measurements would be useful
to gather data to help traffic engineer LSPs to support VPNs.  May be
this point hasn't come out clearly.  Any suggested wording?
Thanks, Wai Sum.

-----Original Message-----
From: Thomas D. Nadeau [mailto:tnadeau@cisco.com]
Sent: Friday, March 08, 2002 4:05 PM
To: Lai, Wai S (Waisum), ALASO
Cc: te-wg@ops.ietf.org
Subject: Re: **Please comment on these proposals:** TE Measurement - 02
version



         Hi,

         I think that this is a good document that captures many
good requirements for a TE system. A few comments and
suggested additions below.

         In section 11, I am not sure why you are talking about
VPNs. This is a TE document, no?

    Besides traffic engineering, a major application of MPLS is the
    support of network-based virtual private networks (VPNs).  A VPN can
    be an enterprise network or a carrier's carrier network.  Path-based
    measurement by a network operator on behalf of the VPN customers
    facilitates the estimation of the traffic offered by these VPNs.

    Section 10.1 Measurement types related to traffic or performance:
    (3) As a starting point, statistics collected by passive measurement
    through the MPLS traffic engineering MIBs [17, 18, 19]

         I would not refer to the MPLS-LSR MIB as a "traffic engineering
MIB" per se. I would instead say, "...through MIBs useful for Traffic
Engineering [17, 18, 19]."

>An updated TE Measurement I-D has now been posted:
>http://www.ietf.org/internet-drafts/draft-ietf-tewg-measure-02.txt
>
>Recall that in the discussion of the draft at IETF-52, Jim noted that
>(from the minutes of the TEWG):
>
>"Jim: purpose of milestone - one can identity concrete measurements
>for the purpose of TE - independent of technology (ATM, FR, MPLS, ...).
>Concerned that draft does not meet objective.  Want to have folks read
>and comment on whether or not objective is satisfied."
>
>To address these concerns, we agreed at IETF-52 to add specific
>recommendations to the draft.  As such, the following recommendations
>are made for specific TE measurements:
>
>. Use of node-pair-based traffic data to derive per-service-class
>   traffic matrix statistics
>. Statistics of carried load versus performance
>. MIB extensions, including the MPLS Router MIB,

         Should be MPLS-LSR MIB not "MPLS Router MIB".

>MPLS TE MIB, and TEWG TE MIB

         I would propose that you modify the following statement:

    Measures (represented by their estimates) should be centrally stored
    and collected.  Two methods are: (1) extend MIBs with new
    definitions for TE measure estimates, and (2) create data
    depositories through more centralized facilities, such as LDAP
    repositories.  Both methods have merits as collection processes for
    TE measures.

to include distributed storage that might be centrally
located logically. The requirement below seems to state
that it is preferable to keep all of your collected data in
one place physically, but I think that it is certainly acceptable
to keep the information in different places (maybe even redundantly)
and have the NMS be able to view it logically in one place (i.e.: NFS).



>Also, the following recommendations are made on traffic data collection
>methods:
>
>. Need for uniform definitions across vendors and operators
>. Distinction between traffic offered load versus achieved
>   throughput
>. Need for higher-order statistics for service assurance
>. Need for packet sampled measurements that preserve representative
>   traffic detail at manageable sample volumes
>. Packet sampling, statistical estimation and information modeling

         I suggest you should include as a requirement offline bulk file 
transfer
as a means for helping manage large volumes of measured TE
data. Many of the existing SNMP, TMS and NetFlow mechanisms use
this as their way of xferring large volumes of data in bulk form from the 
nodes
to the collection device or NMS using some standard file transfer mechanism
(NFS/TFTP).  This can help reduce network packet processing overhead
experienced by using some of the other management interfaces.

         I don't see any discussion of data correlation/suppression/filtering
as appropriate or acceptable means for pruning down the volume of
TE data. For example, NetFlow collectors can have filtering rules or
correlation set up to suppress redundant data. This reduces the overall
volume of TE data that the TE system will ultimately have to store, maintain
and process.  I would think that this would be a requirement too.

         ---Tom



>We feel that this version has now incorporated all of the comments
>we received during the December 2001 meeting at IETF'52.
>
>**Please comment on these proposals.**
>
>We ask for your concurrence on these recommendations, and/or if
>you have any additions/deletions/comments, or what more is needed.
>
>Following the comment period, we propose that the next step is
>WG last call.
>
>Thanks, Wai Sum.



------------------------------------------------------------------------
Mathematics is the supreme nostalgia of our time.