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

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