Re: [Ntp] NTPv5 and anycasting

[Denis Reilly <[e-mail]>]

Hello Paul and Philip (and Watson):

The intent behind adding NTP over anycast to the BCP was to document a mode of operation that many network operators are already using. In my experience, it has its main value in Paul’s scenario 2. And when a network operator uses it on its corporate WAN, they need to understand that their choice will not lead to optimal time transfer, particularly when the network changes which server a client is talking to without that client’s knowledge. Perhaps that doesn’t happen often enough to cause concern? Ultimately, it is up to the operator to determine what their synchronization requirement is. Their application may be able to tolerate the slop when Anycast association changes, and so making configuration easier is worth the tradeoff.

This can also be accomplished via DNS, as you note, but I do know that there are some organization who prefer their anycast setup.

While I was composing this, Watson provided his reply, with much more relevant detail than I could have provided.

Best Regards,

--
Denis Reilly  |  Technical Lead  |  [e-mail]<mailto:[e-mail]>  [phone]<tel:(585)%20321-5837>

From: ntp <[e-mail]> On Behalf Of Paul Gear
Sent: Wednesday, December 02, 2020 4:37 PM
To: [e-mail]
Subject: Re: [Ntp] NTPv5 and anycasting


CAUTION: This email originated from outside of the organization.
Do not click links or open attachments unless you recognize the sender and know the content is safe.
On 3/12/20 3:48 am, Philip Prindeville wrote:

On Dec 2, 2020, at 1:08 AM, Miroslav Lichvar <[e-mail]><mailto:[e-mail]> wrote:



On Tue, Dec 01, 2020 at 10:41:01PM -0700, Philip Prindeville wrote:

Sorry if this has been discussed already, but do we want to have a specific prohibition against the use of anycasting with NTPv5?



I can’t see the point in sending packets non-deterministically to one of possibly many servers with different clock values, RTT’s, etc.



There is a section on anycast in the NTP BCP document. It can be

useful. I don't see a reason why NTPv5 specifically should prohibit

use of anycast.







What’s the scenario where non-determinism is a good thing?

Hi Philip,

I agree, and I'm curious to hear Miroslav's answer to this as well.

I can think of two scenarios where anycast might be useful, but neither is really non-deterministic under normal conditions:

  1.  Public services where the same well-known IP (or set of IPs) is anycast simultaneously from geographically dispersed locations and only moves when its prefix is withdrawn from BGP due to maintenance or faults.  (Similar to the various DNS services from Cloudflare, Google, etc.)  I would argue that the existing DNS-based public pool is a better solution than this for most use cases.
  2.  A corporate WAN where clients are configured with a single NTP server IP, which is anycast from the local branch router.  My argument against using anycast here would be that an internal DNS pool is simpler and more robust, but I can see some organisations wanting to use anycast due to a mix of platform limitations, management software, and available skills.

I think RFC8633 section 7 was rather too gentle in its downplaying of anycast, and would support wording stating that anycast SHOULD not be used with NTP.  Of course, that's not really within scope of Miroslav's v5 proposal.

Regards,
Paul