[dhcwg] Re: [ntpwg] Network Time Protocol (NTP) Options for DHCPv6

["David L. Mills" <[e-mail]>]

Brian,

We need to think about scenarios for server discovery. Without prejudice 
on the message formats, a virgin client might be directed to either:

1. Listen for broadcast/multicast on <address> and do/do not execute a 
volley. I like the delay field to enable/disable that and have added it 
to ntpd. In principle, the delay can be determined from the DHCP packets 
themselves, a feature that might be added.

2. Troll the pool at one of the pool DNS names, us.pool.ntp.org, etc. 
The client should be smart enough to use/not use iburst and preempt flags.

3. Specify a list of <addresses> to send to, each together with the mode 
and  minpoll. I don't think maxpoll is useful either.

4. Specify a manycast server group address, ttl limit and beacon interval.

In the broadcast/multicast, pool and manycast schemes, we need the 
optional tos floor and tos ceiling and tos cohort commands as well. All 
schemes may need the key ID or Autokey flag.

All this makes me nervous. A possible alternative is simply to send a 
configuration file like the ntpq program can now. However, this of 
course is implemention specific. It might be useful to provide the name 
of a local configuration file only. The most important thing is to make 
it flexible for use by current ntpd and possibly others.

Dave

2.Brian Utterback wrote:

> Benoit Lourdelet (blourdel) wrote:
>
>> Hello,
>>
>> A possible usage of all the NTP parameters specified in the new options
>> is to configure router gateway . In that scenario, the goal of a Service
>> Provider or an Enterprise IT is to autoconfigure the gateway as much as
>> possible, including some NTP client behavior, in order to keep the
>> control. An additional benefit is that the gateway can be shipped to
>> remote sites virtually without any configuration while keeping full
>> control of the NTP behavior.
>
> I'm sorry, but I still don't see it. Are you saying that the router
> is a DHCP client and gets the server from DHCP? Okay fine,
> but how does minpoll, maxpoll, I and B get used? I still
> don't see the point of maxpoll here at all, that is, I don't even
> get what it means to the client to get this value imposed.
> See, minpoll says "do not poll more often than this",
> but maxpoll would mean "do not poll less often than this".
> This just doesn't make sense to me.
>
>> Following that line of thought, I may still see a need for "minpoll,
>> maxpoll, I and B fields".
>>
>
> Now, I could see the I and B meaning "do not do this" rather than "do
> this". If I and B are 0, then
> it means to do whatever you want, but if they are 1, then do not do it.
> It doesn't
> make sense to tell a client to use iburst when it wasn't going to
> anyway. Same with burts, although
> in a strange set of ceircumstances I could imagine the need for burst
> being known centrally,
> so maybe the B flag makes some kind of sense as is.
>
>> Considering a central DHCP server, the use of remote-id [RFC4649] or
>> just link-id may tell the server from where
>> the request is coming then giving it the knowledge of the delay to
>> apply.
>> In the case of a DHCP server hosted by the first hop, the DHCP server is
>> well positioned to know the delay.
>>
>>
>
> Oh, agreed, it is possible for the delay to be known. But I just don't
> think it is likely
> that it will ever be used correctly in that scenario. All I said is that
> it should generally
> be left at 0 unless there is a good reason not to.
>
>> Considering the current option format which includes more than IP
>> addresses, the choice of multiple occurrences of the
>> same option looks sensible. Should we reduce the new options to IPv6
>> addresses only, a list makes more sense.
>>
>>
>
> Okay.
>
> --blu
>
> "You've added a new disk. Do you want to replace
> your current drive,protect your data from a drive failure
> or expand your storage capacity?"
> - Disk management as it should be.
> ----------------------------------------------------------------------
> Brian Utterback - Solaris RPE, Sun Microsystems, Inc.
>
> Ph:877-259-7345, Em:brian.utterback-at-ess-you-enn-dot-kom
>
>
> _______________________________________________
> ntpwg mailing list
> [e-mail]
> https://lists.ntp.org/mailman/listinfo/ntpwg



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