Subject: Re: [IPFIX] when flow{Start,End}SysUpTime overflow

From: Andrew Johnson <[email-masked]>
Date: Sun, 05 Nov 2006 16:52:32 +0000

Hello all

Hitoshi Irino wrote:
> Paul Aitken wrote:
>>>   sysUpBaseTimeMilliseconds
>>>
>>>    Description:
>>>       The absolute timestamp of the base time for flowStartSysUpTime 
>>>       and flowEndSysUpTime. The initial value is equal to 
>>>       systemInitTimeMilliseconds, and the value is updated every 49
>>>       days to prevent overflow of flowStartSysUpTime and flowEndSysUpTime.

Like Template IDs and Common Property IDs, this should be bound to the
transport session.  Something like:
  "The absolute timestamp of the base time for any System Uptime based
   value sent within this Transport Session."

[SNIP]
>> We should say that where it's present it's to be used in preference to 
>> the systemInitTimeMilliseconds, where "present" means there's a value 
>> for this IE in the flow, or in an option that's in scope.
>>
>> But you want to export the sysUpBaseTimeMilliseconds value in an 
>> option because you certainly you don't want to have to export the 
>> value in every flow, right?
> 
> I want to export in option.
> 
>> That raises an interesting question concerning the change of value. If 
>> you're exporting some flows based on a certain value of 
>> sysUpBaseTimeMilliseconds, and you export an option containing an 
>> updated value, you must ensure that all the old flows have reached and 
>> been processed by the collector before the updated 
>> sysUpBaseTimeMilliseconds, and that the updated 
>> sysUpBaseTimeMilliseconds reaches the collector and is processed 
>> before any of the new flows. Else you risk interpreting some of the 
>> flows with the wrong value of sysUpBaseTimeMilliseconds.
>>
>> Unless we can show how that can be done, it'd be necessary to export 
>> systemInitTimeMilliseconds in every flow which, as previously 
>> discussed at some length, is incredibly inefficient and should not be 
>> done.
> 
> I have not considered about this problem.
> I think that if the option template which includes
> sysUpBaseTimeMilliseconds can notify the sequence number of header of
> corresponding data record which contains flowStartSysUpTime and
> flowEndSysUpTime relating new updated sysUpBaseTimeMilliseconds to
> collector (but suitable IE does not exist in nowadays IPFIX-INFO), this
> problem can be solved.

The main problem here is one of re-ordering, and it is not unique to this
IE, for example also applies to Template IDs.  One reasonable approach for
dealing with the re-ordering problem is to only use the option with data
that has was received with a later sequence ID than the one the update was
received in.

Hitoshi-san, what scope were you thinking of using when updating the
base time?  I can't think of any obvious one.  Template IDs would be one
possibility as you could change the templates every 47 days and therefore
there would be no confusion about where the base time applied to.
However I suspect you want any base time updates to apply to all
templates.

regards

Andrew

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

---

From: Andrew Johnson <[email-masked]>
Date: Sun, 05 Nov 2006 16:52:32 +0000

Hello all

[SNIP]

regards

Andrew

---

From: Hitoshi Irino <[email-masked]>
Date: Mon, 20 Nov 2006 18:04:22 +0900

Dear Andrew,

I am sorry for late reply,

Andrew Johnson wrote:
>>> That raises an interesting question concerning the change of value. 
>>> If you're exporting some flows based on a certain value of 
>>> updated value, you must ensure that all the old flows have reached 
>>> and been processed by the collector before the updated 

I did not want any base time updates to apply to all templates.
My previous proposed method (described above) can restrict scope, by
scope field in option template, I think.
However, Template ID renewal what you wrote is better, I understood and
agreed it by these sentences (as below) in the protocol draft.

*****
Section 8. (Template Management)
    If the measurement parameters change, the Template MUST be withdrawn
    (using a Template Withdraw Message and a new Template definition) or
    an unused Template ID MUST be used. Examples of the measurement
    changes are: a new sampling rate, a new flow expiration process, a
    new filtering definition, etc. If a Template is changed, a Template
    Withdraw Message MUST be sent to delete the Template.

Section 10.3.6 (UDP Template Management)
    Following a configuration change that can modify the interpretation
    of the Data Records (for example, a sampling rate change) a new
    Template ID MUST be used and the old Template ID MUST NOT be reused
    until its lifetime (see section 10.3.7) has expired.
***

The base time is one of measurement parameters and it relates
interpretation of the Data Records.
I agree to change the templates (and these ID) when the base time should
be updated.

regards,
Hitoshi Irino

-- 
Hitoshi Irino
NTT Network Service Systems Laboratories
9-11 Midori-cho 3-Chome, Musashino-shi, Tokyo 180-8585 Japan
Tel: +81-422-59-4403  Fax: +81-422-59-4549

---

From: Hitoshi Irino <[email-masked]>
Date: Mon, 20 Nov 2006 18:04:22 +0900

Dear Andrew,

*****

regards,
Hitoshi Irino