Re: [IPFIX] draft-ietf-ipfix-a9n
Benoit Claise <[email protected]>
| Newsgroups | gmane.ietf.ipfix |
|---|---|
| Message-ID | <[email protected]> |
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
>
>
_______________________________________________
IPFIX mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipfix