On 7/2/2015 12:01 AM, Anil Kumar S N (VRP Network BL) wrote: >> 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 >
The analysis needs to be in its own thread and has nothing to do with the checksum trailer draft. >> >>> 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 > You mean that IANA is the only place you should look? >>> 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. > I believe that Dave Mills has a paper somewhere about the problems with v3 and why he went to v4. >>> 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. > All servers are also clients so that argument doesn't hold water. >>> 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. The administrator already makes a decision by choosing a list of servers in the configuration file or dynamically adding them if necessary. Most admins do this went setting up a system but once they have chosen they forget all about it and never come back. That's the reality. > >>> >>> 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. > I know and that's not JUST adding a bit. The amount of testing is enormous in addition to everything else. Danny _______________________________________________ TICTOC mailing list [email protected] https://www.ietf.org/mailman/listinfo/tictoc
