Subject: RE: I-D ACTION:draft-ietf-tewg-measure-06.txt

From: "Ash, Gerald R (Jerry), ALABS" <[email-masked]>
Date: Wed, 5 Nov 2003 10:22:47 -0600

> >For example, in Section 2 "Conclusions & Recommendations", the 
> >very first requirement is:
> >
> >'(1) Requirements for specific TE measurements 
> >    
> >. Node-pair-based traffic data to derive per-service-class 
> >traffic matrix statistics, including statistics of carried 
> >load and offered load (Sections 3.3 and Appendix A) 
> >. Statistics of achieved performance and throughput (Section 3.4)
> >. A standardized method to detect and record label binding 
> >changes for LDP-signaled label-switched paths, at the 
> >ingress-egress pair level (Section 3.5)'
> >
> >Such a requirement is basic to operating any network, and 
> >allows a traffic matrix to be derived for purposes of 
> >engineering and management of the network.  Such a measurement 
> >*is not available in any MIB or protocol*.  It is a major 
> >problem in the engineering and management of IP-based networks 
> >today that such measurements are not available.  There are 
> >indirect work-arounds to this that are not altogether accurate 
> >or satisfactory, but there is no substitute for the actual 
> >measurements.  

> 	That is not entirely accurate. The IETF's IPFX WG is 
> standardizing the NetFlow protocol which can be used for 
> precisely this. It has been available in a proprietary form 
> from my company and others for several years now.

I believe it is accurate.

We are, of course, familiar with IPFX/NetFlow, and have used NetFlow for many years in AT&T.  NetFlow has its place, but does *not* satisfy the requirement for node-node measurements as called for in the I-D.

As Jim suggested, such measurements should perhaps be included in some (TE) MIB.  As you know, we have discussed that very issue with you in connection with this draft.  You even said at one point that you would provide some text describing how this could be done as a MIB enhancement, but you did not provide the text.  

As you know, we have requested such extensions be included in an appropriate MIB, and this has been discussed on the lists.  But again there has been no progress on that as yet.

Hopefully the TEM draft will advance the requirement into some MIB or protocol implementation.

Jerry

---

From: "Thomas D. Nadeau" <[email-masked]>
Date: Fri, 7 Nov 2003 12:45:22 -0500

>TEWG,
>  The above I-D currently proposes a set of TE measurement 
>requirements.
>The are extracted below.  I would like to ask WG opinion:
>. should any or all of these requirements be dropped as they are not
>  "additional measurements needed for TE" as described in the TEWG
>  charter?
>. are there any "additional measurements needed for TE" that 
>are missing
>  from the list below and hence should be included?

	These requirements seem to be reasonable and 
necessary for the development of TE-based tools
and the refinement of existing ones.

	--Tom

>Thanks, Wai Sum
>
>*********
>Summary of requirements extracted from the above I-D:
>
>   For interoperable compatibility and consistency, 
>   requirements for traffic measurement recommended for 
>standardization 
>   include: 
>    
>   (1) Requirements for specific TE measurements 
>    
>   . Node-pair-based traffic data to derive per-service-class traffic 
>     matrix statistics, including statistics of carried load and 
>     offered load (Sections 3.3 and Appendix A) 
>   . A standardized method to detect and record label binding changes 
>     for LDP-signaled label-switched paths, at the ingress-egress pair 
>     level (Section 3.5) 
>    
>   (2) Requirements for traffic data collection methods 
> 
>   . Standardization of measurement definitions and sampling methods, 
>     to achieve uniformity across vendors and operators, and to 
>     preserve sufficient traffic detail at manageable sample volumes 
>     (Section 6 and Appendix C) 
>   . Higher-order statistics to facilitate service assurance (Section 
>     3.1) 
>   . Offline bulk file transfer and standardized filtering/aggregation 
>     mechanisms to manage large volumes of measured traffic data 
>     (Section 5 and Appendix D) 
>   . Linkage between policy mechanisms and TE measurement, possibly 
>     triggered by a measurement-driven event notification (Section 5) 
>   . Standardization of information models for TE measurement (Section 
>     5) 
>    
>

---

From: Benoit Claise <[email-masked]>
Date: Tue, 18 Nov 2003 01:24:42 +0100

Jerry,

 We are, of course, familiar with IPFX/NetFlow, and have used NetFlow for
 many years in AT&T.  NetFlow has its place, but does *not* satisfy the
 requirement for node-node measurements as called for in the I-D.

I see from the draft that you have multiple requirements. Some of them could be fulfilled with IPFIX

   Traffic measurement can be performed on the basis of flows, 
   interfaces, links, nodes, node-pairs, or paths.  Based on these 
   objects, different measurement entities can be defined, such as 
   traffic volume, average holding time, bandwidth availability, 
   throughput, delay, delay variation, packet loss, and resource usage.  
   Using these measured traffic data, in conjunction with other network 
   data such as topological data and router configuration data, traffic 
   matrix and other relevant statistics can be derived for TE purposes. 

If you would report flow records composed of BGP Next Hop and TOS or flow records composed of FEC (IP address) and EXP, you would have a pretty good idea of your core traffic matrix.

You wrote also regarding the flow-based measurements:

   Some shortcomings in today's method to derive traffic matrix 
   statistics as above include the volume of data from flow-based 
   measurement, the lack of sufficient routing control information, and 
   the need to correlate data from a variety of sources. 

Volume:
Well, the volume of data will be as voluminious as you want it to be.
Look at PSAMP for packet sampling. Note that PSAMP will use IPFIX as export protocol (and NetFlow version 9 was selected as the basis protocol for IPFIX).
I think that packet sampling is fine anyway: we don't need a 100% precise core traffic matrix.

Correlation:
With the mechanism, you don't need to correlate anymore with the SNMP counters.

Routing Control information:
Could be an issue.
IPFIX requires (http://www.ietf.org/internet-drafts/draft-ietf-ipfix-reqs-11.txt):
   The exporting process MUST be able to report the following attributes
   for each metered flow:
     11. if MPLS is supported at the observation point: the top MPLS
         label or the corresponding forwarding equivalence class (FEC,
         [RFC3031]) bound to that label.  The FEC is typically defined
         by an IP prefix.

As you summarized in the table of section 4.1, the flow-based passive
measurements can not answer all your requirement (example offered load).

So I'm not telling that IPFIX/PSAMP is THE solution for all your
problems. I'm just telling the core traffic matrix could be produced
with IPFIX.

And I'm just wondering if a possible extension to the IPFIX information
model would help you exporting what you need, and help answering the
requirement "Standardization of an information model for TE
measurement."!

To come back on the offered load, IMHO, it should be done off the
network (not with active probing) with a tool that would take as input:
the core traffic matrix, the topology and the routing tables info!

Note: I'm also a little bit confused by
   Some shortcomings in today's method to derive traffic matrix 
   statistics as above include the volume of data from flow-based 
   measurement, the lack of sufficient routing control information, and 
   the need to correlate data from a variety of sources.  To avoid some 
   of these deficiencies and to take advantage of the routing control 
   offered by MPLS, node-pair-based passive measurement should be 
   developed. 
And you defined in the appendix:
A.3 Node-pair-based 
       Active measurements by probing, as specified ...

Regards, Benoit.