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

["Anil Kumar S N (VRP Network BL)" <[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.

 [Anil >>] I have posted a mail with analysis for backward compatibility 
Let me know if you find any issues with respect to backward compatibility

> 
> > 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.
> 
[Anil >>]  Servers understand only Autokey now as per IANA, So Autokey 
is untouched, For any new extension if they follow M-bit then there is 
no issues and if server dosent understand new extension anyways server
is gonna drop packet irrespective of M-Bit

> > 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.
> 
[Anil >>] I feel if we introduce new version, we must make sure 
They move into NTPv5 not because of compulsion instead new features 
Available. NTPv3 is so stable that it has proved its correctness from 
Years. People are happy with NTPv3.

> > 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.
> 
[Anil >>] Server will never initiate NTP messages, So there should be 
A way that client and server negotiate what they support. This is tricky 
because backward compatibility has to be supported.

> > 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?

 [Anil >>] Yes, In access network NTP server is loaded with ntp client 
Packets or its server's response packets. For the sake of correctness NTP 
server process first N packets rest of the packets are droped due to incorrect 
timestamping this case is when there is no hardware timestamping. 
This could be one of the reason where server looses its server and
In response to client says server is unsync. When server synchronized 
To its server again clients will get synchronized to server.

The main reason is in the network they will not have many servers,
As per ntp RFC at least three servers are expected for correctness of 
Server selection but administrators will have two servers where one is 
Preferred. But these two servers are parallel servers (Same level, same staratum), 
which is synchronized to same server.

One more reason that NTP servers goes to sync and unsync due to step adjustment
is server running with poor hardware, or to be specific very very old device.

> 
> > 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.
> 

[Anil >>] 
I agree administrator can't make this decision, but he can't feel handicapped. 
I believe in NTP selection procedure, But the problem which I would to address 
for them is by giving options. Somehow client should get to know all the NTP 
servers available in the network which is cleared NTP selection process.
These must be candidate for administrator. Here Administrator cant select 
Just based on looking at IP address, He has to give some more information 
About servers which will make him feel confidant on selecting one of the server.

> >
> > 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.
> 
[Anil >>]  I don't think any major vendors even have autokey in their release till now.
Huawei has autokey but not even one customer is using inspite of hundreds of thousands 
Routers are running NTP. We should understand what difficulties they are facing and why 
They don't want to use Autokey.

Success of new protocol lies in number of interested people to use it. 

> > So I feel we need to solve issue by issue. Lets not differintiate
> small or big.
> >
> 
> It's the details that kill you.
[Anil >>]  There are lot more complicated protocols in the network with 
100's of extensions. I am routing background, I know how complicated BGP and OSPF is.
This is just adding a bit to field type. So that new extension are added and used with ease.

> 
> Danny



Thanks & Regards
Anil S N

"Be liberal in what you accept, and conservative in what you send" - Jon Postel
_______________________________________________
ntpwg mailing list
[e-mail]
http://lists.ntp.org/listinfo/ntpwg