Re: [IPFIX] draft-ietf-ipfix-a9n

[Benoit Claise <[e-mail]>]

Brian, Rahul,
> On Feb 24, 2012, at 4:07 PM, Rahul Patel wrote:
>
>>>>> Section 5.1.1 Distributing values across Interval
>>>>> -------------------------------------------------
>>>>> * should add 'synchronized expiry of Original Flows' - Under this
>>>>> method
>>>>> Flow C would be exported three times with start-time/end-time
>>>>> matching the
>>>>> aggregation interval start-time/end-time.
>>> Make sense to me.
>>>>> * There will always going to some original flows which will arrive late
>>>>> and will not be accounted. It will be good have a cumulative counter of
>>>>> such late arrivals on per template id (aggregated flow) basis. This
>>>>> cumulative count should be periodically exported along with end-time
>>>>> (time-of-snapshot). The counter will provide a degree of confidence
>>>>> in the
>>>>> data exported by the aggregator for each template.
>>> So you want something similar to "The Metering Process Statistics Option
>>> Template" from RFC5101, http://tools.ietf.org/html/rfc5101#page-23, but
>>> for the Aggregation Intermediate Aggregation Process, right?
>> [RP] exactly.
> Still not convinced this is needed given the nature of active timeouts; however, that may well be an implementation-specific (or application-specific) opinion.
>
> In that case, I agree we should add it but I'm not convinced that this is an aggregation-specific thing. If you're going to count records that were dropped at an intermediate process due to missing a time window, couldn't this affect non-aggregation intermediate processes as well? How about adding this to MEDPROTO instead?
That makes sense in the MEDPROTO  
(http://tools.ietf.org/html/draft-ietf-ipfix-mediation-protocol-00)
We would need to take as a basis the  "The Metering Process Reliability 
Statistics Options Template" from 
http://tools.ietf.org/html/draft-ietf-ipfix-protocol-rfc5101bis-00#page-26, 
which solves already one issue compared to RC5101, by inserting the 
"meteringProcessId".
See my comments in UPPER CASE.

    (scope) observationDomainId
                            An identifier of an Observation Domain that
                            is locally unique to the Exporting Process.
                            This Information Element MUST be defined as a
                            Scope Field.

    (scope) meteringProcessId  =>  NEED IAPPROCESSID
                            The identifier of the Metering Process for
                            which lack of reliability is reported. This
                            Information Element MUST be defined as a
                            Scope Field.

    ignoredPacketTotalCount  =>  NEED SOMETHING SUCH AS IGNOREDFLOW..
                            The total number of IP packets that the
                            Metering Process did not process.

    ignoredOctetTotalCount  =>  DON'T NEED THIS ONE
                            The total number of octets in observed  IP
                            packets that the Metering Process did not
                            process.

    time first packet ignored  =>  THIS RELATES TO THE FLOW, BUT THE IE MIGHT
                            BE THE SAME
                            The timestamp of the first IP packet that was
                            ignored by the Metering  Process.  For this
                            timestamp, any of the following timestamp can
                            be used: observationTimeSeconds,
                            observationTimeMilliseconds,
                            observationTimeMicroseconds, or
                            observationTimeNanoseconds.

    time last packet ignored
                            The timestamp of the last IP packet that was
                            ignored by the Metering  Process.  For this
                            timestamp, any of the following timestamp can
                            be used: observationTimeSeconds,
                            observationTimeMilliseconds,
                            observationTimeMicroseconds, or
                            observationTimeNanoseconds.


would this work?

Regards, Benoit.
>
> Best regards,
>
> Brian
>
>