Re: [IPFIX] new monitoring interval information elements

Paul,

Ok, I see the difference to discontinuity time.

Some further thoughts:

The common understanding is that the "time since re-initialization" 
means sysUpTime. For example, have a look at the description of 
flowEndSysUpTime:
"The relative timestamp of the last packet of this Flow. It indicates 
the number of milliseconds since the last (re-)initialization of the 
IPFIX Device (sysUpTime)."

Your proposed IEs do not mention neither (re-)initialization nor 
sysUpTime. They rather seem to specify a time interval which is located 
somewhere within the sysuptime interval. Hence, the interval does not 
work to define the time frame of exportedMessageTotalCount, for example. 
You would need to define a new IE exportedMessageInMonitoringInterval.

The different IE descriptions suggest that the time of re-initialization 
(i.e. sysuptime) can be different for Metering Process, Exporting 
Process etc.
It seems that we need IE to export sysUpTime for each process.

Thanks
Gerhard



On 25.06.2012 17:38, Paul Aitken wrote:
> Gerhard,
>
> It's not entirely clear what a "discontinuity" is since it's not clearly
> defined. However, inferring from section 5.8 of RFC 5815,
> ipfixMeteringProcessCacheDiscontinuityTime and cacheDiscontinuityTime
> are intended to indicate when the Metering Process was running but
> wasn't able to meter correctly.
>
> The new Information Elements which I'm proposing below aren't related to
> discontinuities. They address a different set of problems. In this case
> the Metering Process is functioning correctly, so there are no
> discontinuities. If there were, they can be expressed with
> ipfixMeteringProcessCacheDiscontinuityTime and cacheDiscontinuityTime.
> However, they are not relevant to the discussion here.
>
> Looking in IANA's IPFIX Information Element registry, we can see many
> Information Elements (about 15) defined as "The number of X since the
> Metering Process (re-)initialization" - so we need to know when that was
> in order to be able to use these Information Elements properly.
>
> These definitions suggest an expectation that the Metering Process will
> start and may subsequently restart. That could be for many reasons;
> there's no suggestion that it's an error.
>
> The new Information Elements proposed below serve to indicate when the
> Metering Process (re)started, and when it ended. As far as I know, there
> are currently no Information Elements for this.
>
> Reviewing RFC 5101, I noticed that the "Metering Process Statistics
> Option Template" contains several fields defined as, "The total number X
> since the Exporting Process re-initialization", so it seems that an
> additional Information Element is required for that too, in the case of
> connectionless export transports.
>
> Thanks,
> P.
>
>
> On 17/06/12 18:17, Gerhard Muenz wrote:
>>
>> Paul,
>>
>> Please check if the proposed IEs are compatible with
>> ipfixMeteringProcessCacheDiscontinuityTime in IPFIX-MIB and
>> cacheDiscontinuityTime in IPFIX-CONFIG.
>>
>> Parameters which exist in IPFIX-MIB, IPFIX-CONFIG and as IE should
>> follow the same naming scheme and semantic, if possible.
>>
>> Thanks,
>> Gerhard
>>
>>
>> On 16.06.2012 16:56, Paul Aitken wrote:
>>> Dear IPFIX experts,
>>>
>>> FYI, I'm requesting two new IPFIX Information Elements from IANA to
>>> record the start and end of a monitoring interval, which is a period of
>>> time during which the Metering Process is running.
>>>
>>> The existing IPFIX Information Elements provide flow based timestamps,
>>> system init, and observation times. There's no indication of the
>>> Metering Process, whichmay be running for a period of time during which
>>> no flows of interest or relevanceare observed.
>>>
>>> In fact, many existing elements are described as "The total number of X
>>> since the Metering Process (re-)initialization". However, there's
>>> currently no indication of when that (re-)initialization was. These new
>>> Information Elements enable an IPFIX device to indicate when the
>>> Metering Process started and ended.
>>>
>>> These new elements are particularly useful when the Metering Process is
>>> windowed - ie, it runs for a fixed interval, exporting all its
>>> observations only at the end of that interval, before optionally
>>> starting over. With these new Information Elements, an IPFIX device can
>>> readily indicate the start (and end) of each interval.
>>>
>>> Our present need is only for milliseconds resolution. At this time we
>>> don't need the equivalent seconds, microseconds, or nanoseconds
>>> elements, although these could be created in future if needs be.
>>>
>>> Also note the subtle distinction between "monitoring" and "metering": a
>>> device could be monitoring traffic for some time, without detecting
>>> anything of interest or relevance to be metered. The metering interval
>>> could almost be expressed by minFlowStart* to maxFlowEnd*. We've chosen
>>> to name these elements "monitoring interval" rather than "metering
>>> interval" to clearly express this difference.
>>>
>>>
>>> Name:         monitoringIntervalStartMilliSeconds
>>> Data Type:    dateTimeMilliseconds
>>> Sematics:     -
>>> Description: The absolute timestamp at which the monitoring interval
>>> started.
>>>                  A Monitoring interval is the period of time during which
>>> the Metering Process is running.
>>> Units:        milliseconds
>>>
>>>
>>> Name:         monitoringIntervalEndMilliSeconds
>>> Data Type:    dateTimeMilliseconds
>>> Sematics:     -
>>> Description: The absolute timestamp at which the monitoring interval
>>> ended.
>>>                  A Monitoring interval is the period of time during which
>>> the Metering Process is running.
>>> Units:        milliseconds
>>>
>>>
>>> Thanks,
>>> P.
>>>
>>> _______________________________________________
>>> IPFIX mailing list
>>> [email protected]
>>> https://www.ietf.org/mailman/listinfo/ipfix
>

_______________________________________________
IPFIX mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipfix