Subject: Re: [IPFIX] Fwd: New Version Notification for draft-claise-ipfix-information-model-rfc5102bis-00.txt

From: Danny Llewallyn <[email-masked]>
Date: Tue, 11 Oct 2011 07:26:00 -0400 (GMT-04:00)

Concerning these elements:

3.1.17. dateTimeMicroseconds

The type "dateTimeMicroseconds" represents a time value in units of
microseconds based on coordinated universal time (UTC). The choice
of an epoch, for example, 00:00 UTC, January 1, 1970, is left to
corresponding encoding specifications for this type, for example, the
IPFIX protocol specification. Leap seconds are excluded. Note that
transformation of values might be required between different
encodings if different epoch values are used.

3.1.18. dateTimeNanoseconds

The type "dateTimeNanoseconds" represents a time value in units of
nanoseconds based on coordinated universal time (UTC). The choice of
an epoch, for example, 00:00 UTC, January 1, 1970, is left to
corresponding encoding specifications for this type, for example, the
IPFIX protocol specification. Leap seconds are excluded. Note that
transformation of values might be required between different
encodings if different epoch values are used.

I recently added support for these fields in the Lancope
collector, and the format I assumed was NTP.  Now I read
here that these can come down in epoch time.  Is there
anything in the IPFIX protocol that denotes the format
being used or the epoch time being used in these time
values?  I see also that the same Note exists at the end of each defined time element.  Perhaps this could be solved with an options template.

Thanks,

Danny Llewallyn

Lancope Inc.

-----Original Message-----

From: Benoit Claise

Sent: Oct 10, 2011 7:52 AM

To: "[email-masked]"

Subject: [IPFIX] Fwd: New Version Notification for draft-claise-ipfix-information-model-rfc5102bis-00.txt

Dear all,

Here is new draft, for our new charter proposal:
http://tools.ietf.org/html/draft-claise-ipfix-information-model-rfc5102bis-00

The diffs with RFC5102 are at
http://tools.ietf.org/rfcdiff?url2=draft-claise-ipfix-information-model-rfc5102bis-00.txt

Your feedback is welcome.

Regards, Benoit.

-------- Original Message --------

Subject:

New Version Notification for
draft-claise-ipfix-information-model-rfc5102bis-00.txt

Date:

Mon, 10 Oct 2011 03:00:52 -0700

From:

[email-masked]

To:

[email-masked]

CC:

[email-masked], [email-masked], [email-masked],
[email-masked], [email-masked]

A new version of I-D, draft-claise-ipfix-information-model-rfc5102bis-00.txt has been successfully submitted by Benoit Claise and posted to the IETF repository.

Filename: draft-claise-ipfix-information-model-rfc5102bis
Revision: 00
Title: Information Model for IP Flow Information eXport (IPFIX)
Creation date: 2011-10-10
WG ID: Individual Submission
Number of pages: 172

Abstract:
This memo defines an information model for the IP Flow Information
eXport (IPFIX) protocol. It is used by the IPFIX protocol for encoding
measured traffic information and information related to the traffic
Observation Point, the traffic Metering Process, and the Exporting
Process. Although developed for the IPFIX protocol, the model is
defined in an open way that easily allows using it in other protocols,
interfaces, and applications. This document obsoletes RFC 5102.

The IETF Secretariat

---

From: Andrew Feren <[email-masked]>
Date: Tue, 11 Oct 2011 11:19:03 -0400

Hi Danny,

RFC 5101 is pretty clear both dateTimeMicroseconds and 
dateTimeNanoseconds are encoded in NTP format.

6.1.9.  dateTimeMicroseconds

    The data type dateTimeMicroseconds represents a time value in units
    of microseconds normalized to the GMT timezone.  It MUST be encoded
    in a 64-bit integer, according to the NTP format given in [RFC1305].

6.1.10.  dateTimeNanoseconds

    The data type of dateTimeNanoseconds represents a time value in units
    of nanoseconds normalized to the GMT time zone.  It MUST be encoded
    in a 64-bit integer, according to the NTP format given in [RFC1305].

As I understand it the quotes you cite basically boil down to "it is up 
it to NTP/RFC1305 to define the epoch (start of time)" since that is the 
corresponding encoding specification.

-Andrew

On 10/11/2011 07:26 AM, Danny Llewallyn wrote:
>         3.1.17. dateTimeMicroseconds The type "dateTimeMicroseconds"
>         represents a time value in units of microseconds based on
>         coordinated universal time (UTC). The choice of an epoch, for
>         example, 00:00 UTC, January 1, 1970, is left to corresponding
>         encoding specifications for this type, for example, the IPFIX
>         protocol specification. Leap seconds are excluded. Note that
>         3.1.18. dateTimeNanoseconds The type "dateTimeNanoseconds"
>         represents a time value in units of nanoseconds based on
>         coordinated universal time (UTC). The choice of an epoch, for
>         example, 00:00 UTC, January 1, 1970, is left to corresponding
>         encoding specifications for this type, for example, the IPFIX
>         protocol specification. Leap seconds are excluded. Note that
> I recently added support for these fields in the Lancope collector, 
> and the format I assumed was NTP.  Now I read here that these can come 
> down in epoch time.  Is there anything in the IPFIX protocol that 
> denotes the format being used or the epoch time being used in these 
> time values?  I see also that the same Note exists at the end of each 
> defined time element.  Perhaps this could be solved with an options 
> template.
>
> Thanks,
>
> Danny Llewallyn
> Lancope Inc.
>
>
>
>     Subject: [IPFIX] Fwd: New Version Notification for
>     Subject: 	New Version Notification for
>     Date: 	Mon, 10 Oct 2011 03:00:52 -0700
>     From: 	[email-masked]
>     To: 	[email-masked]
>     CC: 	[email-masked], [email-masked], [email-masked],
> _______________________________________________
> IPFIX mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ipfix

---

From: Brian Trammell <[email-masked]>
Date: Tue, 11 Oct 2011 17:48:40 +0200

Hi, all,

As I read these, they are internally-self consistent, though they certainly don't look that way until you remove the irrelevant verbiage.

5102 leaves the encoding of µs and ns up to 5101; everything else in 5102 on these types is essentially window dressing and should be ignored.

5101 chooses RFC 1305 style NTP encoding for _both_ of these. Specification of GMT is irrelevant here. The missing epoch is misleading. 1305 specifies an epoch of 1 Jan 1900 00:00 UTC, and 2^32 seconds in the era that ends in February 2036.

So, why have two data types for identical encodings of timestamps? 1305 allows 2^-32 s of precision (~232ps), sufficient for both µs and ns. The assumption made by the authors of RFC 5153 behind this reasoning was that the data type signaled the underlying precision of the measurement; i.e., the bottom two bits or so should be ignored for ns, and the bottom twelve bits or so should be ignored for ns. This is specified in RFC 5153 section 4.5 paragraph 3.

5101 is canonical but not particularly forthcoming, while 5102 is unclear to the point of being misleading on this point.

I believe the correct action in the -bis documents is to correct these errors, preferably by specifying the reference to 1305 and the epoch explicitly in both.

Updating to NTPv4 with support for eras will give these timestamps a life beyond the next 21 years, but that requires a change to the definition of the IEs via the iedoctors process, I think.

Regards,

Brian

On Oct 11, 2011, at 5:19 PM, Andrew Feren wrote:

> Hi Danny,
> 
> RFC 5101 is pretty clear both dateTimeMicroseconds and dateTimeNanoseconds are encoded in NTP format.
> 
> As I understand it the quotes you cite basically boil down to "it is up it to NTP/RFC1305 to define the epoch (start of time)" since that is the corresponding encoding specification.
> 
> -Andrew
> 
> 
>> I recently added support for these fields in the Lancope collector, and the format I assumed was NTP.  Now I read here that these can come down in epoch time.  Is there anything in the IPFIX protocol that denotes the format being used or the epoch time being used in these time values?  I see also that the same Note exists at the end of each defined time element.  Perhaps this could be solved with an options template.
>> 
>> Thanks,
>> 
>> Danny Llewallyn
>> Lancope Inc.
>> 
>> 
>> 
>> Here is new draft, for our new charter proposal: http://tools.ietf.org/html/draft-claise-ipfix-information-model-rfc5102bis-00
>> The diffs with RFC5102 are at http://tools.ietf.org/rfcdiff?url2=draft-claise-ipfix-information-model-rfc5102bis-00.txt
>> 
>> Subject:	New Version Notification for draft-claise-ipfix-information-model-rfc5102bis-00.txt
>> CC:	[email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
>>