Re: [ntpwg] [TICTOC] WGLC on draft-ietf-ntp-checksum-trailer-01.txt (Was: WGLC on draft-mizrahi-ntp-checksum-trailer-02.txt)

[Danny Mayer <[e-mail]>]

On 6/30/2015 11:57 PM, Anil Kumar S N (VRP Network BL) wrote:
> I believe RFC is not specific to ntpd, sntp, ntpdate, ntimed, Windows Time, chrony etc...
> All above has to follow RFC, So if conformance is with RFC is ultimate reasoning.
> 

I know that but you cannot be sure you won't break things if you don't
check the most widely used implementations of NTP.

> I will publish detailed analysis on behavior NTPv3/NTPv4 with respect to M-Bit. 
> The problem is that while designing extension addition padding issue should have been taken care, 
> We are trying to solve it. This is an honest attempt. 
> 

You cannot solve it in NTPv4 because you cannot signal this change in
any way to any NTPv4 system that don't know about it. While I agree that
we should relax the requirements on the length of the extension field,
servers that don't know about this change will drop the packet because
it doesn't conform to the existing requirements for extension field sizes.

> I discussed with our network solution team, in real network most of devices use only NTPv3 and 
> they are not even willing to move into NTPv4 as NTPv3 is serving their purpose. 

That's always been true and going to a new version of NTP won't change
that. On the other hand vendors who don't moved to the newer versions of
NTP won't get the benefit of all the changes, enhancements and bug fixes
but then most network devices are only interested in setting their own
time and don't care if the time received contains unknown extra information.

> Moving into New version is not the only solution to all the issues. 
> We need some improvements in current NTPv4 too.
> 

The problem is that you lose a lot of servers if the extension field
does not comply with existing standards. They will drop the packet.

> Core network is easy to upgrade as there will be less device using NTP, if we move towards 
> Access ring the number of devices are huge. 
> 
> The point is customer is willing to move NTPv5 if we can provide them only with very attractive/convincing 
> features with integrated diagnostic tools, Since each server at the access ring is handling 
> huge number of clients, if there is a flapping in server.

Can you explain what you mean by flapping in server?

> Server receives burst of client 
> requests. One of the requirements came for solution team is to find as many servers as possible 
> dynamically (with out multicast) and narrow down to stable servers. Administrator should be able
> select one of the best server.

The problem with that idea is that the Adminstrator rarely knows enough
to choose the right server. The selection rules in NTP are complicated
and they would need to know a great deal about NTP to be able to choose
a server. But it gets worse. What's a good server at one instance of
time is a bad server the next. NTP is designed to select the best server
at each point in time and use it and change it as conditions change. An
administrator is never going to be doing that. For most administrators,
it's set and forget and move on to the next task. NTP (at least the
reference implementation) is good at making those decisions for the
administrator.

> 
> Selecting server : histroy of stability, challenge is trustability & current load.
> 

Which changes from moment to moment. past performance is not an
indicator of future performance. If you need trustability you should be
using autokey or similar technologies.

> So I feel we need to solve issue by issue. Lets not differintiate small or big.
> 

It's the details that kill you.

Danny

_______________________________________________
ntpwg mailing list
[e-mail]
http://lists.ntp.org/listinfo/ntpwg