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

[Brad Knowles]

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 <brad at shub-internet.org>
LinkedIn Profile: <http://tinyurl.com/y8kpxu>