Subject: [netmod] draft-ietf-netmod-system-mgmt NTP server issues

From: Andrew McGregor <[email-masked]>
Date: Tue, 27 Mar 2012 14:23:19 +0200

The present NTP configuration tree in the draft looks like this:

+--rw system
	...
         +--rw ntp
            +--rw use-ntp?      boolean
            +--rw ntp-server [address]
               +--rw address    inet:host
               +--rw enabled    boolean

This does not quite line up with the way the protocol actually works.  The NTP protocol determines the server priority itself, it does not support a priority list per se, although it has several per-server options that bias the selection process.  There are also several kinds of association.

Thus the tree should be something more like:

+--rw system
	...
         +--rw ntp
            +--rw use-ntp?      boolean
            +--rw ntp-server [address]
               +--rw type       ntp-association-type
               +--rw address    inet:host
               +--rw enabled    boolean
               +--rw iburst     boolean
               +--rw prefer     boolean
               +--rw true       boolean

where ntp-association-type is an enum with values 'server' 'peer' or 'pool' and the booleans iburst, noselect, prefer and true are as defined by the NTP reference implementation.  A server is not expected to synchronise with the device being configured, a peer may be expected to synchronise with the device being configured, and 'pool' is synonymous with 'server' except that the DNS lookup process is altered to operate with NTP pool servers.  iburst enables burst synchronisation when the association becomes reachable, prefer increases the likelihood of selecting the association if it is functional (i.e not obviously out of sync), and true causes the association to be functional if the host is reachable (irregardless of sync status, this is used if the association is to a reference clock).

These options should be sufficient for most routers and hosts that are not NTP reference clocks and do not have special security requirements.  It could be extended to include the authentication and broadcast/multicast features, however for a generic system management draft I do not see the need.

Andrew

---

From: Andy Bierman <[email-masked]>
Date: Tue, 27 Mar 2012 05:27:25 -0700

> These options should be sufficient for most routers and hosts that are not NTP reference clocks and do not have special security requirements.  It could be extended to include the authentication an…

thanks -- I will change the draft to match your data model

> Andrew

Andy

>
> _______________________________________________
> netmod mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netmod

---

From: Per Hedeland <[email-masked]>
Date: Fri, 30 Mar 2012 15:39:56 +0200

On 2012-03-27 14:23, Andrew McGregor wrote:
> This does not quite line up with the way the protocol actually works.
> The NTP protocol determines the server priority itself, it does not
> support a priority list per se,

I agree, though I was at first confused since your tree snippet did not
show the problem. I.e. the problem is that the list is ordered-by user,
with "The user specified order indicates the server priority" as part of
the description. The list order should not be significant, a
standards-compliant NTP client can't obey such a configuration.

> although it has several per-server options that bias the selection
> process. There are also several kinds of association.
> 
> where ntp-association-type is an enum with values 'server' 'peer' or
> 'pool' and the booleans iburst, noselect, prefer and true are as
> defined by the NTP reference implementation. 

I guess the question here is wether this should be a model for a generic
standard NTP client, or for the (so-called) reference implementation.
Personally I think the only reasonable choice is the former, among other
things there exists viable freely-available alternatives to the reference
implementation, and vendors can presumably augment the model with
proprietary knobs.

I'm pretty sure that 'pool' and 'iburst', although useful and relevant
here, are not part of the NTP standard, and I don't believe 'prefer' is
either. The 'true' as a configuration option is unknown to me even for
the reference implementation, but I may be missing it in the plethora of
options. Traditionally the reference implementation uses "magic"
127.127.x.x addresses to indicate a reference clock. In any case I doubt
that it is meaningful for this model to cover the configuration of
reference clocks.

The concept of 'server' and 'peer' association modes are part of the
standard, and may be useful to be able to configure, the alternative
being to have 'server' be implicit. I'm not sure that 'peer' has more
merit than the possibility to configure broadcast/multicast client
modes, though.

Another viewpoint is that the model should also - or maybe instead -
cover the configuration of a SNTP client, which may well be the only
thing that many devices have. As far as the standard is concerned, a
SNTP client has a single server - i.e. the obviously desirable
possibility to have multiple servers for redundancy, and the manner in
which they are selected/combined, is outside the standard. In this case
the ordered-by user prioritized list in the current draft may make
sense.

I'm afraid I don't have good specific suggestions for alternate text at
this point, just wanted to give another opinion...

--Per Hedeland

---

From: "Lange, Jeffrey K (GE Energy)" <[email-masked]>
Date: Fri, 30 Mar 2012 09:55:27 -0400

I've just recently implemented this NTP model, and for what it's worth, I used the following approach:

- the first server in the user ordered list gets the preferred tag applied to it
- all entries have iburst applied to them

I think that the iburst option is best left to the vendor to decide if it should be applied or not.. we chose to use it for all entries.

-Jeff

Jeff Lange
Lead Software Engineer
GE Digital Energy - MDS
 
T: +1 585 242 8375
F: +1 585 241 5590
E: [email-masked] 
www.GEDigitalEnergy.com
 
175 Science Parkway
Rochester, NY, 14620, USA

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Per Hedeland
Sent: Friday, March 30, 2012 9:40 AM
To: [email-masked]
Subject: Re: [netmod] draft-ietf-netmod-system-mgmt NTP server issues

> support a priority list per se,

I agree, though I was at first confused since your tree snippet did not show the problem. I.e. the problem is that the list is ordered-by user, with "The user specified order indicates the server priority" as part of the description. The list order should not be significant, a standards-compliant NTP client can't obey such a configuration.

> defined by the NTP reference implementation.

I guess the question here is wether this should be a model for a generic standard NTP client, or for the (so-called) reference implementation.
Personally I think the only reasonable choice is the former, among other things there exists viable freely-available alternatives to the reference implementation, and vendors can presumably augment the model with proprietary knobs.

I'm pretty sure that 'pool' and 'iburst', although useful and relevant here, are not part of the NTP standard, and I don't believe 'prefer' is either. The 'true' as a configuration option is unknown to me even for the reference implementation, but I may be missing it in the plethora of options. Traditionally the reference implementation uses "magic"
127.127.x.x addresses to indicate a reference clock. In any case I doubt that it is meaningful for this model to cover the configuration of reference clocks.

The concept of 'server' and 'peer' association modes are part of the standard, and may be useful to be able to configure, the alternative being to have 'server' be implicit. I'm not sure that 'peer' has more merit than the possibility to configure broadcast/multicast client modes, though.

Another viewpoint is that the model should also - or maybe instead - cover the configuration of a SNTP client, which may well be the only thing that many devices have. As far as the standard is concerned, a SNTP client has a single server - i.e. the obviously desirable possibility to have multiple servers for redundancy, and the manner in which they are selected/combined, is outside the standard. In this case the ordered-by user prioritized list in the current draft may make sense.

I'm afraid I don't have good specific suggestions for alternate text at this point, just wanted to give another opinion...

--Per Hedeland