Subject: [ippm] Common templates for exporting measurement results and middlebox metrics

From: "STEPHAN Emile RD-CORE-LAN" <[email-masked]>
Date: Thu, 31 Mar 2005 11:40:28 +0200

Hi Benoit,

It is clear that IPFIX is suitable to export binary data such as measurement results (either active or passive).

Having common templates and clear metrics definitions is the only way to increase the usability, interoperability and the scalability of the collecting part of measurement systems.

Templates:
----------

Nevertheless there are at least 3 issues with the current version of IPFIX:
	Field Types SampleID, metricID are missing;
	The current delta timestamp computation is not applicable to measure related to delay or jitter;
	Templates are not defined;

That fully motivates the first I-D "common templates for exporting measure results". It will fully specify the templates to export active and passive measurement result;

Metrics:
--------

draft-ietf-ipfix-as-04.txt presents several usages for IPFIX. One of them consists in using PSAMP technique to measure IPPM metrics. Unfortunately the current IPPM metrics definitions are not directly applicable to this technique. They must be adapted to routers and middlebox.

This is clearly the intent of the second I-D "traceroute and middlebox metrics". Each section defining a metric will discuss measurement issues related to the measure, the reporting... as RFC2679-80 do. 

IPFIX Info Model:
-----------------

I explained in the last PSAMP meeting (discussion related to draft-pohl-perpktinfo-02.txt) that we have to identify the few field types needed in the info model. What about basically adding PacketID, SampleID, metricID and MeasureID in the IPFIX info model?

IPFIX Protocol:
---------------

Regarding measurement result, delta timestamping is the major issue. The current approach is not applicable to measurement results and does not conform to the IPFIX architecture. I proposed yesterday a solution. What is the opinion of the WG fellows on this proposal?

Regards
Emile

-----Message d'origine-----
De : Benoit Claise [mailto:[email-masked]] 
Envoyé : mercredi 30 mars 2005 23:30
À : STEPHAN Emile RD-CORE-LAN
Cc : Juergen Quittek; Lutz Mark; [email-masked]; [email-masked]
Objet : Re: [ipfix] RE: [ippm] traceroute as WG work item? IPFIX traceroute records

Emile,

If there is a need to push some IPPM data to a NMS (as opposed to pull 
the data with SNMP), then the IPFIX protocol makes perfect sense as it 
is efficient and flexible.
BTW, this is described in the IPFIX applicability draft 
(http://www.ietf.org/internet-drafts/draft-ietf-ipfix-as-04.txt)

    2.7  SLA validation...........................................8 
    2.8  Traffic Monitoring.......................................8 
    2.8.1 Measurement of Round-trip-time (RTT)....................9 
    2.8.2 Measurement of One-way-delay (OWD)......................9 
    2.8.3 Measurement of One-way-loss (OWL)......................10 
    2.8.4 Measurement of IP delay variation (IPDV)...............10 
    3.3 IPFIX and IPPM 

Note that this draft speaks of passive measurements as opposed to active measurements in IPPM.
However, from the pure IPFIX protocol point of view, the measurement mechanism is not relevant.

Regards, Benoit.

>Hi Juergen and Lutz
>
>What we experienced with the IPPM MIB is that measures generate a lot of data. So the binary format is the best for collecting. 
>
>Traceroute Field Types do not differ from Per Packet Field Types (draft-pohl-perpktinfo-02.txt) or from IPPM Field Types, especially if we include spatial and multicast metrics (dratf-stephan-ippm-multimetrics-00.txt). 
>
>Moreover most of these fields are already defined as illustrated by the example I sent. So it appears very fast and very easy to define in IPFIX a common info model and a common set of templates to export results of IPPM measures, traceroute measures and 'Per Packet' measures. 
>
>Regarding traceroute metric I propose to try to design this metric using the IPPM framework and terminology (RFC2330), and then to present it to the IPPM WG. At large this document may include metrics definitions of middlebox one-way delay and jitter corresponding to 'Per Packet' measurement technique. 
>
>To sum up I propose to write 2 drafts:
>	The fist one defines in the IPFIX WG common templates for exporting measure results;
>	The second one defines in the IPPM WG traceroute and middlebox metrics.
>
>Regards
>Emile
>
>-----Message d'origine-----
>De : Juergen Quittek [mailto:[email-masked]] 
>Envoyé : lundi 28 mars 2005 03:06
>À : STEPHAN Emile RD-CORE-LAN
>Cc : [email-masked]; [email-masked]
>Objet : RE: [ippm] traceroute as WG work item? IPFIX traceroute records
>
>Emile,
>
>Thanks for your comments!
>
>The basic issue I raised was whether or not the standardization
>of an information model and data model for traceroute results would
>be a work item for the IPPM WG.
>
>Do I understand correctly from your message that,
>  1. yes, it should be standardized,
>  2. but not necessarily in the IPPM WG?
>
>Concerning the discussion at IPPM whether we should use a binary
>or an XML-based format for traceroute results, I interpret your
>message as support for a binary format.
>
>I think your thoughts open an interesting discussion on transmitting
>traceroute results in IPFIX records.  Probably, this issue is worth
>mentioning it in the IPFIX applicability statement.
>
>Also, the issue should be considered by the information model discussions
>in IPFIX and PSAMP.
>
>Thanks,
>
>    Juergen
>  
>

_______________________________________________
ippm mailing list
[email-masked] 
https://www1.ietf.org/mailman/listinfo/ippm

---

From: Benoit Claise <[email-masked]>
Date: Thu, 31 Mar 2005 12:28:17 +0200

Hi Emile,

>Having common templates and clear metrics definitions is the only way to increase the usability, interoperability and the scalability of the collecting part of measurement systems.
Agreed on the clear metrics definitions, this is the IPPM WG job.
Regarding the common templates, I'm more in favor of letting the user 
export what they need with a flexible export mechanism such as IPFIX.
Imposing the templates is not the right approach. We tried that with 
NetFlow version 5: it doesn't scale when you have new Information 
Elements. Therefore NetFlow version 9 was created. Note for the IPPM 
users: IPFIX is based on NetFlow version 9.

>Templates:
SampleId is a typical PSAMP field that will be specified in the 
information model. See the selectorID ... unless I misunderstood what 
you meant with SampleID. Maybe you mean a hash value? Again it will 
defined part of PSAMP.

>	Templates are not defined;
See my point above.

>This is clearly the intent of the second I-D "traceroute and middlebox metrics". Each section defining a metric will discuss measurement issues related to the measure, the reporting... as RFC2679-80…
We still have to work on the PSAMP information model

>
>IPFIX Protocol:
>---------------
>
>Regarding measurement result, delta timestamping is the major issue. The current approach is not applicable to measurement results and does not conform to the IPFIX architecture. I proposed yesterday a solution. 
>
I replied to it. Let's keep 2 separate threads (BTW, I still don't 
understand why it doesn't conform to the IPFIX architecture)

Regards, Benoit.

>What is the opinion of the WG fellows on this proposal?
>
>
>Regards
>Emile
>