Subject: Re: [ippm] IPFIX AS /IPPM

From: Juergen Quittek <[email-masked]>
Date: Fri, 04 Aug 2006 11:03:02 +0200

Hi Emile,

--On 28.07.2006 16:39 Uhr +0200 STEPHAN Emile RD-CORE-LAN wrote:

> Hi,
>
> I reread IPFIX AS regarding IPPM aspects.
>
> I think that it (section 2.5) may refer to the RFCs which define the
> IPPM metrics presented.
>
> As IPFIX (section 2.7) can also be used to transfer metrics result I

What are "metrics results"?  Is this correct IPPM terminology?

> consider that the Applicability Statement has to propose to transfer the
> result conjointly with its corresponding metric identifier in the IANA
> IPPM registry
> (http://www.iana.org/assignments/ianaippmmetricsregistry-mib).

Yes, you are right, this is a potential application area of IPFIX.
Still, it needs exploration.  Main work would be specifying information
elements for reporting results of the specified measurements.
This has not been done yet, but might be a potential future work item
for IPFIX or IPPM.

Thanks,

    Juergen

> Note that the draft
> http://tools.ietf.org/wg/ippm/draft-ietf-ippm-multimetrics/ includes
> pure passive metrics. So there will be metric identifiers for passive
> metrics in the IANA IPPM metrics registry.
>
>
> Regards
> Emile
>
>
>
> _______________________________________________
> ippm mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/ippm

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

---

From: "Tanja Zseby" <[email-masked]>
Date: Fri, 4 Aug 2006 11:35:44 +0200

Hi Jürgen,

in our IPIFX implementation we already have defined some (vendor specific) IEs for reporting QoS metrics. We are working on a short technical report on this. So we could provide the descriptions of the QoS IEs.  

Regards,
Tanja

> -----Original Message-----
> From: Juergen Quittek [mailto:[email-masked]] 
> Sent: Friday, August 04, 2006 11:25 AM
> To: Tanja Zseby; STEPHAN Emile RD-CORE-LAN; 
> [email-masked]; [email-masked]
> Cc: [email-masked]
> Subject: RE: [ippm] IPFIX AS /IPPM
> 
> Hi Tanja,
> 
> --On 02.08.2006 10:35 Uhr +0200 Tanja Zseby wrote:
> 
> > Hi Emile,
> >
> > the IPPM RFCs are already mentioned in section 2.5. in 
> version 09 of the docuemnt.
> > Using the IANA numbers from the IPPM registry sound like a 
> good idea.
> > Does this mean that we probably could use the IANA numbers for the 
> > metrics directly as element identifier for the IPFIX 
> information elements?
> > Jürgen, is this possible with the IPFIX info model? e.g. using 
> > ianaIppmMetrics in the same way as an enterprise ID?
> 
> This would be an option to be considered.  However, the IANA 
> numbers identify metrics, not results from measurements 
> according to a metric.  We would have to investigate whether 
> or not a one-to-one mapping from metric identifier to an 
> information element carrying measured results would make sense.
> 
> There might be a need to have more than one information 
> element for a single metrics, for example, when time is 
> measured.  In the current information model we have different 
> elements for reporting the same time information with 
> different precisions (nanoseconds, microseconds, 
> milliseconds, seconds).
> 
> Anyway, it looks like a useful task to specify IPFIX 
> information elements for reporting measurements according to 
> IPPM metrics.  Which numbers to assign to these elements 
> would be just one issue to be solved within this task.
> 
> Thanks,
> 
>     Juergen
> 
> > Regards,
> > Tanja
> >
> >
> >> -----Original Message-----
> >> From: STEPHAN Emile RD-CORE-LAN 
> [mailto:[email-masked]]
> >> Sent: Friday, July 28, 2006 4:40 PM
> >> To: [email-masked]; [email-masked]
> >> Cc: [email-masked]
> >> Subject: [ippm] IPFIX AS /IPPM
> >>
> >> Hi,
> >>
> >> consider that the Applicability Statement has to propose 
> to transfer 
> >> the result conjointly with its corresponding metric 
> identifier in the 
> >> IANA IPPM registry 
> >> http://tools.ietf.org/wg/ippm/draft-ietf-ippm-multimetrics/
> >> includes pure passive metrics. So there will be metric identifiers 
> >> for passive metrics in the IANA IPPM metrics registry.
> >>
> >>
> >> Regards
> >> Emile
> >>
> >>
> >>

---

From: "STEPHAN Emile RD-CORE-LAN" <[email-masked]>
Date: Tue, 22 Aug 2006 15:16:29 +0200

Dear all,

It is obvious that reporting metrics measurement results need much more information that an identifier of the metric. Nevertheless the usage of a measurement result requires the presence of 2 pieces of information 'what is measured? 'and 'how it was measured?'.

By now IPFIX data model does not provide anything to couple measurement described in draft-ietf-ipfix-as-10.txt and IPPM metrics. So to get a standard mapping between IPPM metrics definitions and measurements (IPFIX or IPPM ones) it is urgent to define IEs to say 'what is measured?' and 'how it was measured?': 

Name:                ianaIppmMetricsIdentifier
Description:         The identifier of a metric as per http://www.iana.org/assignments/ianaippmmetricsregistry-mib .
Abstract Data Type:  integer
Data Type Semantics: identifier

Name:                metricMeasurementMethod
Description:         The measurement method (NDLR: add description and ref to IPPM, IPFIX and PSAMP RFC which define the methods)
Abstract Data Type:  integer
Data Type Semantics: enum { passive, periodic, poisson ... }

Name:                measurementId
Description:         The identifier of one measure
Abstract Data Type:  integer
Data Type Semantics: identifier

My thinking is that we have to define now with these IE firstly to reach a minimal level of interoperability of IPFIX measurement information as per IPFIX AS and finally to couple definitively passive and active measurement methods.

I agree that measurement methods and metrics have specific parameters that are not addressed by http://www.iana.org/assignments/ianaippmmetricsregistry-mib. So I started the definition of a reporting registry (http://tools.ietf.org/wg/ippm/draft-stephan-ippm-reporting-registry-00.txt ) to register progressively the specific set of parameters to report per metric application. Based on IPPM WG works on composition, aggregation and reporting this registry will gather protocol neutral set of parameters to report that should be used any data model. 

To sum up, I propose to add now the 3 IE above in the IPFIX/PSAMP data model; then I suggest completing the definition of the set of parameters of several metrics usage in the ippm reporting registry before San Diego meeting; there we might present their usage using IPFIX data model in a IPPM/PSAMP/IPFIX common meeting.

Regards
Emile

> -----Message d'origine-----
> De : Al Morton [mailto:[email-masked]]
> Envoyé : vendredi 4 août 2006 15:05
> À : Juergen Quittek; Tanja Zseby; STEPHAN Emile RD-CORE-LAN;
> Cc : [email-masked]
> Objet : RE: [ippm] IPFIX AS /IPPM
> 
> At 05:24 AM 8/4/2006, Juergen Quittek wrote:
> >>the IPPM RFCs are already mentioned in section 2.5. in version 09 of the
> >>docuemnt.
> >>Using the IANA numbers from ...
> >>...snip...
> >This would be an option to be considered.  However, the IANA numbers
> identify
> >metrics, not results from measurements according to a metric.  We would
> >have to
> >investigate whether or not a one-to-one mapping from metric identifier to
> an
> Depending on the options selected for some metrics, like
> delay variation, even the metric itself can be completely
> different from another instance with alternative options.
> 
> 
> >There might be a need to have more than one information element
> >for a single metrics, for example, when time is measured.
> 
> All the IPPM metrics have a set of parameters that allow one to specify
> the variable aspects of the metric (e.g., Poisson or Periodic
> stream and all their stream variables, Loss waiting time threshold).
> Somehow, these need to be linked to the results, or they will
> loose their meaning.  This is an issue for IPPM's existing registry.
> 
> Al
> 
> >In the current
> >information model we have different elements for reporting the same time
> >information with different precisions (nanoseconds, microseconds,
> >milliseconds, seconds).