I had some discussions around it and I think next version will be something along 5 bytes unix timestamp and millisec resolution.
I look for reasonable input on what kind of precision scale we're looking for clock precision. anything under 1msec makes no sense for a routing protocol, anything above 1 sec probably loses enough precision timestamp is of questionable value (or should we allow more?). I also thought we could put the precision into router info. However, on precision change router basically needs to reissue all fragments. this sound like serious storming on unstable clock. possibly sticking it into router info and saying "it is highly advisable to re-issue fragments after a clock flip only once you had stable clock for extended time". This leaves the window of receivers reading the timestamp with incorrect time precision if router info already indicates new precision. Opinions? 3 bytes on very large networks are 3 bytes wasted on each fragment, some of those large networks are pushing bounds of encoding size more than one could think possible, especially during migrations/redistributions. -- tony On Fri, Jul 26, 2024 at 5:21 PM Christian Hopps <cho...@chopps.org> wrote: > The reason I suggested just using 64 bits which then provides nanosecond > resolution (whether we need it today or not), is it seems KISS, which makes > me feel warm inside — people aren’t going to screw up the unit values; we > really aren’t going to need to revisit this anytime soon for different > resolution or have to “just deal” with resolution not being quite what we > want for some future use, and we’re talking about 3 out of ~1500 octets > here. Using fractions of fractions to count things to save a 3 octets and > possibly have to change it again someday just seems a bit overly careful. > If 3 octets matter the user is in need of one of the LSP space expanding > solutions at this point I guess. > > Thanks, > Chris. > > > On Jul 26, 2024, at 11:18 AM, Antoni Przygienda <prz= > 40juniper....@dmarc.ietf.org> wrote: > > > > Well, you cannot design protocols around broken platforms since the spec > needs to hold up for 20 years, the platforms are fixed daily. > > > > Is the leap second etc. dramatic`? Today definitely NOT but who knows > where the stuff goes including satellites in the future ;-) > > > > I read the comment on the “just use epoch and burn the bytes” though I’m > not too happy about it practically speaking. There are some customers that > are squeaking last bytes out the encoding today, sometimes during complex > migrations caused by redistributions and given more and more “garbage > trucking” to paraphrase the other Tony the bytes are precious. > > > > However, if majority of folks feels that way, we could sway to 5 bytes > timestamp (need to do the math on rollover first) and some better > resolution on msecs and precision, probably a byte each which puts us at > roughly 5msec resolution which is far beyond what practically will matter > ever I think > > > > — Tony > > > >> On 26 Jul 2024, at 10:44, David 'equinox' Lamparter <equi...@diac24.net> > wrote: > >> > >> [External Email. Be cautious of content] > >> > >> > >> Hi all, > >> > >> > >> I haven't quite been able to express what I meant at the mic, sorry. I > >> was trying to point out that at least one IS-IS implementation (ours, > >> FRRouting) will occasionally get the PTP timestamp wrong due to having > >> an incorrect leap seconds offset. > >> > >> The only reliable timestamp on a Linux system is the unix timestamp. To > >> get a PTP timestamp, I need to apply the constant offset *and* also the > >> TAI-UTC offset aka leap seconds count. On a *correctly configured* > >> system, this will be in clock_adjtime()'s result (timex->tai) and/or I > >> can query CLOCK_TAI rather than CLOCK_REALTIME. > >> > >> ... unfortunately this is configured by other userspace software beyond > >> our control. If the system is running a PTP daemon[note 1], it > >> *hopefully* retrieves the tzdb leap-seconds file and loads it into the > >> kernel. Some other system components (systemd, ntpd) may load it but > >> don't update it[note 2] (which is, honestly, worse than having nothing > >> loaded, because then you can recognize it's 0, which is not an invalid > >> offset but at least an "unlikely" one.) > >> > >> If we were talking about a core protocol feature here, I'd raise this as > >> a serious concern. For a debugging feature - I think we'll be OK, maybe > >> it's a chance to get the distro builders to fix their shit re. > >> leap-seconds updates. (It's been getting better, but not quite there > >> yet I'd say.) > >> > >> Also, if the IERS follows through on their decision to stop doing leap > >> seconds, this will become irrelevant... ...in 2035. > >> > >> Regards, > >> > >> > >> equi > >> (David) > >> > >> > >> [note 1] a PTP daemon is _not_ part of FRRouting. There are >= 2 > >> implementations but FRRouting doesn't know if anything is running. > >> > >> [note 2] they rely on updating the file through regular system package > >> updates, which happen whenever the system operator feels like it. > > > > _______________________________________________ > > Lsr mailing list -- lsr@ietf.org > > To unsubscribe send an email to lsr-le...@ietf.org > > _______________________________________________ > Lsr mailing list -- lsr@ietf.org > To unsubscribe send an email to lsr-le...@ietf.org >
_______________________________________________ Lsr mailing list -- lsr@ietf.org To unsubscribe send an email to lsr-le...@ietf.org
