1. emile.stephan@orange-ftgroup.com 78th IETF – IPPM WG IPPM metrics registry extension draft-stephan-ippm-registry-ext-00.txt 78th IETF Meeting – July 2010 IPPM Working Group Emile Stephan

2. emile.stephan@orange-ftgroup.com 78th IETF – IPPM WG 2 Overview o Current registry o Its limits o Ongoing discussions o Extension Metric flavor examples Structure Rules o Conclusion

3. emile.stephan@orange-ftgroup.com 78th IETF – IPPM WG 3 Current registry o 70 metrics ID o 1 rule: identifying each metric defined; goal: point to individual definition instead of a RFC. o 2 usages: usage by non experts Functional spec, RFP : o pointing exactly toward the same metrics definition usage by MIB modules;

4. emile.stephan@orange-ftgroup.com 78th IETF – IPPM WG 4 Current registry limits o Information OPS needs more than an identifier o language Written in SMI: o Limited to MIB compiler or expert;

5. emile.stephan@orange-ftgroup.com 78th IETF – IPPM WG 5 Ongoing discussions o Inputs from OPS area and IPPM felows Result: a MetricName:value relationship; more standardization needed; In the context of the metric registry; Units should be explicitly specified; Should carry metrics options As the Registry is unused it should be obsoleted

6. emile.stephan@orange-ftgroup.com 78th IETF – IPPM WG 6 Registry extension metric flavor o Metric flavor concept Specialization of a metric definition One metric definition may have several flavor i.e. traffic generation laws, statistics PS: Deal with option parameters Clarification of a metric definition PS: deal with results parameters Unification of metrics for reporting Actually the opposite of above :-)

7. emile.stephan@orange-ftgroup.com 78th IETF – IPPM WG 7 Registry extension example (1/2) Unification of metric ietfReportingOneWayDelay description"list of OneWayDelay singletons" originMetricietfOneWayDelay originMetricietfOneWayPeriodicDelay originMetricietfFiniteOneWayDelay originMetricietfSpatialOneWayDelay outputCardinality1 outputUnitmillisecond ietfReportingOneWayDelayStream description"list of ietfReportingOneWayDelay singletons" originMetricietfFiniteOneWayDelayStream originMetricietfSegmentOneWayDelayStream originMetricietfOneWayDelayPoissonStream originMetricietfOneWayDelayPeriodicStream outputCardinalityn outputUnitmillisecond

8. emile.stephan@orange-ftgroup.com 78th IETF – IPPM WG 8 Registry extension example (2/2) ST and LT metrics ietfOneWayDelayMean1mn originMetricietfFiniteOneWayDelayMean ObservationPeriod 60 outputCardinality 1 outputUnitmillisecond ietfOneWayDelayMean15mn originMetricietfFiniteOneWayDelayMean observationPeriod 900 outputCardinality 1 outputUnitmillisecond ietfOneWayDelayMean1hour originMetricietfFiniteOneWayDelayMean observationPeriod 3600 outputCardinality 1 outputUnitmillisecond ietfOneWayDelayMean1day originMetricietfFiniteOneWayDelayMean observationPeriod 86400 outputCardinality 1 outputUnitmillisecond

9. emile.stephan@orange-ftgroup.com 78th IETF – IPPM WG 9 Registry extension structure o A table of the metric flavors id Includes existing metrics o A list of flavors

10. emile.stephan@orange-ftgroup.com 78th IETF – IPPM WG 10 Registry extension mgmt rules o Mgmt by IANA o Keep consistent with the current numbering o Keep the current registry in a SMI leg o Add a new leg for metric flavors; o must be parsable by XML based NM syst. o Update based on 'Specification Required', see [RFC2434].

11. emile.stephan@orange-ftgroup.com 78th IETF – IPPM WG 11 Conclusion o May help the IPPM work on reporting; to predefine high level metrics for reporting without defining a management interface; There is a need for LT metrics exchange in cooperative projects related to ALTO WG E2e measures from apps; Per Network measures from ISPs;