Re: [Ntp] Timescales

[FUSTE Emmanuel <[e-mail]>]

Le 09/12/2020 à 14:06, Magnus Danielson a écrit :
> No, that goes against the experience, and let me tell you it's bitter
> experience. You need to transport it, and leapsecond file updates is
> just a very big challenge to coordinate over a very diverse set of
> machines while we have an increase need for proper TAI and UTC replicas
> in clients. Remember that many uses of NTP is in wide range of
> infrastructures with great challenges in updates, etc. Some is in very
> locked down systems which may for all practical purposes be seen as
> private networks having very little or no connection to Internet, or may
> even be completely air-gaped. For such production environments even
> getting an upgrade every 2 years can be challenging. Much of the issues
> we have in other context is that machines do not get upgrades at all and
> may be in excess of 5 years from last upgrade. While I try to fight to
> have upgrades becoming natural for all systems, that fight will not be
> over and done with in any reasonable time, so depending on it will be
> moot. Some vendors tend to import code, but cripple configuration
> freedom, and their upgrade rate is low to very low in the same type of
> time-frame as system upgrades. Similarly will depending on detailed
> configuration, we need to move away from source, intermediary node and
> client configuration to be a major factor, as things is confusing and
> not very helpful. The bringing the needed info over the protocol, albeit
> out of the way for the core time-stamp processing, is what works and
> what will survive.
>
> Trying to rule out the transport of leap-second information from the bit
> protocol is the crazy idea, it is just going to create more of the same
> problems we face today, in fact, we could just put NTP into pension and
> let PTP take over in that case.
>
> So, to conclude my standing: Yes, you can move the core time mechanism
> over to some variant of TAI, that is going to make core processing
> easier and more robust, less corner cases in the core processing. No,
> you can not move the leap-second information out of the core protocol,
> in fact the opposite, you need to make it a mandatory field and
> processing, but you can now let that remaining processing beyond
> distribution become a client side issue as the core time over to
> whatever the client need.
>
> So, the crazy idea is in my mind thinking one can avoid the issue in the
> core protocol, which will not be going well and already with the current
> state of things can be a bit of a challenge. Just address the problem
> proper once and for all, and learn from the good experience of other
> systems.
So what do you think about this ?
What we need is some new NTP messages for leap / Time-scale 
conversion/correction tables "like" the GPS almanach and navigation tables.
A client could then built/rebuild/update local tables by chunk by doing 
a request with his serial/timestamp of it known data without external 
intervention and at a rate different from the NTP measuring messages.
It could be done securely with data signing and in band signing key 
rollover.
It is quite challenging and a lot of work for v5 but could be defined as 
an NTPv5 extension and core part of future v6.
For v5 without extension, we rely on out of band update of the data as 
"critical" systems do today anyways for the leap.
But it is perhaps too radical.

Emmanuel.