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

Jerry,

> >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.



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.