Re: [Ntp] Timescales

[Magnus Danielson <[e-mail]>]

Emmanuel,

On 2020-12-09 15:02, FUSTE Emmanuel wrote:
> 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.

Already in NTPv4 there is a mechanism as documented in RFC 5906
sub-clause 10.6 and some scattered comments around. As a minimum level
we should retain that after liberating it from the Autokey context. It
has the draw-back of depending on the leap-second history, as typical
with NTP time-stamps.

I see no reason to wait another major revision for it, if you choose
methods, it's fairly straight-forward and not a lot of code, the needed
corner cases can be described and well understood. What you propose is
to take a step back, not a step forward.

Cheers,
Magnus