RE: [ntpwg] [dhcwg] Network Time Protocol (NTP) OptionsforDHCPv6

[<[e-mail]>]

And not easy to implement where you have many thousands of clients as
you have to monitor each one individually to determine whether it is
behaving correctly and hence whether to send it the KOD.

Tony Flavin
-----Original Message-----
From: ntpwg-bounces+anthony.flavin=[e-mail]
[mailto:ntpwg-bounces+anthony.flavin=[e-mail]] On Behalf Of
Brad Knowles
Sent: 29 November 2007 19:32
To: Richard Gayraud (rgayraud); [e-mail]; [e-mail]
Subject: Re: [ntpwg] [dhcwg] Network Time Protocol (NTP)
OptionsforDHCPv6

On 11/29/07, Richard Gayraud (rgayraud) wrote:

>  - aren't KOD packets part of the solution ? (This draft only
>    addresses NTPv4 clients with IPv6 connectivity). Maybe we
>    can enforce support for KOD for clients supporting DHCP NTP
>    configuration.

Unfortunately, many clients ignore KOD.  We can't depend on this being
the ultimate saviour in UWisc-type events.

>  Issue #3: Irrelevant parameters (maxpoll/minpoll/burst/iburst)
>  --------------------------------------------------------------
>
>  When writing the first version of this draft, one of our goals  was 
> to allow better control of the tradeoff between NTP clock  precision 
> and traffic generated over a LAN. IPv6 has a large  address space, and

> an IPv6 subnet can contain a huge number of  hosts. Thus, it may be 
> suitable to reduce the amount of traffic  generated by NTP clients. On

> the other hand, some deployments  may require fast and precise clock 
> synchronization. Hence the  Maxpoll, Minpoll, Burst and IBurst 
> parameters. Again, these are  not mandatory and will rarely be used.

As I see it, the bigger problem is that there is an amazing amount of
potential complexity in the configuration file syntax of the Reference
Implementation, and 99.99% of sites don't need that much complexity.
Therefore, I believe it would be a serious mistake to try to encode any
significant amount of that complexity into DHCP.

Moreover, since the configuration file syntax is not standardized in an
RFC (as the NTP protocol is), you would be encoding a proprietary
implementation into your protocol standard.  I think the IETF should be
violently opposed to doing such a thing.

>  => I do not understand why theworkstation users (controlling
>     their individual ntpd.conf file) would be more skilled to
>     set these parameters than network administrators (controlling
>     the DHCP server)?

They wouldn't.

>  If some parameter is questionable in a DHCP option, I think it  is 
> also questionable as an ntpd.conf option. Isn't it?

This isn't a transitive case.  A implies B and C implies D does not
necessarily mean that A implies D.

The difference is that we have an entire file to work with, and it's up
to us how complex to make that process.  We're not trying to encode
everything into 512 bits, or even just the "important" parts.

We're also not trying to publish the syntax for all NTP clients as an
RFC -- this is just our own internal proprietary implementation, and
doesn't have anything to do with the NTP protocol standard.  Other NTP
clients are welcome to support a similar syntax (if they like), or they
could do something totally different.  So long as they properly
implement the protocol itself, it shouldn't matter what configuration
file options and syntax they use.

>  I do remember examples of customers requesting that their NTP  
> clients quickly sync (and acquire time) on startup. If the network  
> administrator wants NTP this kind of behavior, he will set the  Burst 
> flag to reach fast NTP convergence. Anything I missed here?

Using "burst" is inherently bad, unless you own all the resources on
both sides of the table, and even then it's probably not such a good
idea in most cases.  This is not a nuclear weapon you want to give to J.
Random Network Admin, or J. Random Embedded Vendor, or anyone else for
that matter.

Using "iburst" is generally considered to be okay, since it only does a
burst of packets on startup, and then operates normally afterwards. 
But in this case, we could argue that we could safely assume that iburst
should be used in all DHCPv6-derived client configurations, and simply
drop the entire "burst" or "iburst" configuration option altogether.


In fact, I would argue that most of the configuration options are
unlikely to be useful in the general case.  They have accumulated over
the decades as the protocol and the Reference Implementation have
evolved, mostly to solve one or another edge case, and over the decades
we've had a lot of these edge cases.

In some circumstances, after years of experience with the NTP protocol
as it has evolved, and the Reference Implementation and how it has
evolved, we've concluded that the assumptions we made years ago are no
longer valid.  However, we're caught in a straight-jacket that we
created for ourselves at the time because we could not see the potential
need for any other view of the situation at that point. 
So, we have a lot of legacy cruft that has accumulated.  I really don't
think that you want to try to incorporate our old legacy cruft into your
new protocol standard.

Keep in mind that the legacy cruft I'm talking about doesn't have
anything to do with the NTP protocol itself, it has to do with certain
assumptions at various different points in the code that implements the
operations related to the protocol, and other clients or servers could
easily make different assumptions and yet still have fully interoperable
implementations of the NTP protocol standard.

>  Issue #6: "multiple instances versus list of addresses"
>  -------------------------------------------------------
>
>  The use of multiple instances of the same DHCP option to  advertise 
> several NTP servers seems to be somewhat confusing.
>  Depending on the decision made for other issues, we will  probably 
> change the syntax of the options (or sub-options if  any).

I'm not getting this point at all.  Can you elaborate?

>  Issue #8: Carrying an URL for a config file
>  -------------------------------------------
>
>  This has been suggested a few times, but has 2 major drawbacks:
>
>  - It requires the client to be ftp/tftp/http-enabled (a lot
>    of complexity on the client),
>
>  - It would be implementation dependant,

This is part of why I like the idea of a Simple NTP Configuration
Service.  I believe it could be much simpler and easier to implement
than FTP, TFTP, or HTTP.  And it would let us keep all the NTP
configuration complexity outside of the DHCP protocol.

>  If sub-options are used in the DHCP message, we will certainly  have 
> the same level of flexibility.

Um, I don't think that your DHCP messages can be as long as our
configuration files.

I wouldn't make any claims about your ability to have the same level of
flexibility unless you want to include the full syntax of the
proprietary configuration files that we support in the Reference
Implementation.  I'm not sure how that lexer and parser are built, but I
imagine it shouldn't be a problem to contribute that to a willing
recipient project.


That said, I really don't think you want to try to implement anything
remotely close to the full complexity of our configuration files, and I
really don't think you want to implement anything that does not have
it's own IETF standards-track RFC to guide you and associated working
group with which to liaise.

Since none of the configuration file options you've mentioned have
anything to do with the NTP protocol per se, I think you'd at least need
to wait until some group takes up the task of standardizing the
configuration file options and syntax for all NTP servers and clients
-- including, but not limited to, the Reference Implementation.



There's one common theme here:

	Standard Protocol != Proprietary Configuration File
Options/Syntax

One of these you can work with and interface with as part of your
standard.  The other, I don't think so.

You don't encode Cisco router configuration file syntax into the DHCP
standard (do you?), and I wouldn't suggest trying to do the same for NTP
or the NTP Reference Implementation.

--
Brad Knowles <[e-mail]>
LinkedIn Profile: <http://tinyurl.com/y8kpxu>
_______________________________________________
ntpwg mailing list
[e-mail]
https://lists.ntp.org/mailman/listinfo/ntpwg

_______________________________________________
dhcwg mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/dhcwg