Re: [dhcwg] Review of draft-ietf-dhc-dhcpv6-failover-protocol-00

>1) If the time should be synced, then I would suggest merely requiring that, rather than specifying NTP - ie specify the what rather than the how.

See my email to Brian (sent a few minutes ago).

>2) Are there any other benefits to having time synced ? Eg, does having a significant time offset make troubleshooting any harder - eg by having logs on two servers with

The protocol does mostly send relative times, but also includes the base time and the time at which the packet was "sent" (well, this should be as close as possible to the time sent from the application's view (I.e., at socket send). The reason time matters is that there could be time spent "in the transport" (i.e., send queue on the sender, network latency, and receive queue on the receiver). This time could easily tens of seconds. Which can thus skew things when events occur "close" to each other (perhaps the client is communicating with both servers such as when in communications interrupted) - it is then difficult to determine what happened "before" something else. By using synchronized clocks, the time the packet was sent/received no longer matters and it is possible to "correct" events. Though as we are only using second resolution (for base, sent, and relative time), we obviously can't do much better than that (and when a clock ticks over a second may also introduce small drifts - 1 or 2 seconds).

The main advantage of using synchronized clocks is that you no longer need to worry about calculating any drift related to the transport latency. And, with TCP this is a bit more problematic.

- Bernie

-----Original Message-----
From: dhcwg [mailto:dhcwg-bounces@ietf.org] On Behalf Of Simon Hobson
Sent: Monday, November 30, 2015 11:56 AM
To: dhcwg@ietf.org
Subject: Re: [dhcwg] Review of draft-ietf-dhc-dhcpv6-failover-protocol-00

Kim Kinnear <kkinnear@cisco.com> wrote:

> Folks,
> 
> One of Bernie's comments on the failover draft was:
> 
>> -          7.1 (Time Skew) - Should we require NTP to synchronize the clocks on failover partners?
> 
> The current draft (-00.txt) has a capability to allow the failover 
> protocol to operate with two machines which have clock skew of a 
> largely arbitrary amount (limited in some way to perhaps 24 hours or 
> something).  So two systems that are 3-5 minutes apart (the usual 
> skew, if any) will work fine.
> 
> Bernie is suggesting that we require failover partners to have 
> essentially synchronized time by requiring NTP sync.  If they are 
> synchronized to the level of 1-2 seconds, that would be synchronized 
> for the purposes of this protocol.  We aren't talking milliseconds 
> here.

I see two points :

1) If the time should be synced, then I would suggest merely requiring that, rather than specifying NTP - ie specify the what rather than the how.

2) Are there any other benefits to having time synced ? Eg, does having a significant time offset make troubleshooting any harder - eg by having logs on two servers with different timestamps for the same event ?
I'm inclined to thinking that there's isn't really any argument against having server times set correctly, particularly for services (such as DHCP) which include a time element. Perhaps if it's not an actual requirement, it should be suggested as recommended practice for stability and ease of troubleshooting - or is that going too far into "stuff any half decent admin shouldn't need telling" territory ?

_______________________________________________
dhcwg mailing list
dhcwg@ietf.org
https://www.ietf.org/mailman/listinfo/dhcwg