Re: [IPFIX] Fwd: New Version Notification for draft-claise-ipfix-information-model-rfc5102bis-00.txt
Brian Trammell <[email protected]>
| Newsgroups | gmane.ietf.ipfix |
|---|---|
| Message-ID | <[email protected]> |
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. > > 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: >> 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 protected]" >> 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 protected] >> To: [email protected] >> CC: [email protected], [email protected], [email protected], [email protected], [email protected] >> >> 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 >> >> >> >> >> >> _______________________________________________ >> IPFIX mailing list >> >> [email protected] >> https://www.ietf.org/mailman/listinfo/ipfix > > _______________________________________________ > IPFIX mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/ipfix _______________________________________________ IPFIX mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipfix