IETF Logo Mail Archive

Re: [Ntp] NTPv5 and anycasting

Steven Sommars <stevesommarsntp@gmail.com> Thu, 03 December 2020 04:29 UTC

Return-Path: <stevesommarsntp@gmail.com>
X-Original-To: ntp@ietfa.amsl.com
Delivered-To: ntp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 933163A0AB1 for <ntp@ietfa.amsl.com>; Wed, 2 Dec 2020 20:29:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9NTshlUbbIH1 for <ntp@ietfa.amsl.com>; Wed, 2 Dec 2020 20:29:43 -0800 (PST)
Received: from mail-il1-x132.google.com (mail-il1-x132.google.com [IPv6:2607:f8b0:4864:20::132]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B9B2F3A0AB4 for <ntp@ietf.org>; Wed, 2 Dec 2020 20:29:43 -0800 (PST)
Received: by mail-il1-x132.google.com with SMTP id g1so712611ilk.7 for <ntp@ietf.org>; Wed, 02 Dec 2020 20:29:43 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=qKAnLfbKwUuwbvGZQ84wkIt1Ln9Kao0keTLm9A2EU3Q=; b=d2gUjeovOZMu1YHnOyzkwEbp4/uMe9pOvB42mdUHvovGyxKlKESZObX2X0+/8qtpII Pq74fj5e3U+1ou8SG1D6Vp2STpJ0wIVEqsrlPKlR+5eQFFgUD0kkbZMhLV3NG03ByvhW NXYugcjI/6ZCLA+41A2FVz/pGaqrtvrs2UsfuB3oSRJCxA5oSuS3RzTIC2YiSX7DPxTq ewR+usK5THh/kjT5gVu0uhYoblpf9X4ndlkKZsHnxA3Q4a5PK7fJNI/vlHOtQhLHZtJz cp9PWe6jALNhqfo2PrKgrce9RG8KzMAZ7ZEfAtNoj2YcQDWCWSntS+kSeACYmBYzymQh rlaQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=qKAnLfbKwUuwbvGZQ84wkIt1Ln9Kao0keTLm9A2EU3Q=; b=Nko2XwJU40zNxgo0vK16FQAscfoGLWYsFyULgf/evEAEadJjIwGmu0Q5aEbfhwCTGr Enwj4NaimBcLE48ob30kHdqdVWb1VVcfjsGORwiBNyF/yUddxNmPPxhbVEJIZZ5PjVW+ NHOmUC4cGiW7AkssAGryJLdpIo3lLNnJN41UVLEm9TRPrDa8TzJOJCEKOdPryUAnk5Gx C89vIurEP+nZJqFnoQBDs005rskoNISXlo8fhTJiPNAlkBVWaaiN5qQdVcxsjS9LvTIL bVTspKt7iUkMHnbW/XBufplACWLMQhSVsDG92ct3eS2TBqa6CUpEGFw+Ub8usZEf3vkJ 865A==
X-Gm-Message-State: AOAM531uSIkNyg7KUR5+FJ1iwI6CWUrWVm2s0AtnX9Yuo8unK1HAwEWa 8NcClX+CbCUA7JziNsiBi8OaWETXXChSSmh0ROGWKiaz
X-Google-Smtp-Source: ABdhPJzwolcoRpvQLcC/I1KNjKaLdKQyWMxfCPySrgA/nNrST+rBGJPFJgu8SMNOxxmGUdpQyZGcu1u6tD1NE07tyFs=
X-Received: by 2002:a05:6e02:e44:: with SMTP id l4mr1494946ilk.208.1606969782962; Wed, 02 Dec 2020 20:29:42 -0800 (PST)
MIME-Version: 1.0
References: <F2AD65AD-3403-486E-AEF9-3EF07F88A7FF@redfish-solutions.com> <20201202080839.GO1900232@localhost> <6CAE44A6-41A6-4516-8CD1-217C87C28E47@redfish-solutions.com> <e316ffcf-91e1-1e95-b905-76e63200cba2@libertysys.com.au>
In-Reply-To: <e316ffcf-91e1-1e95-b905-76e63200cba2@libertysys.com.au>
From: Steven Sommars <stevesommarsntp@gmail.com>
Date: Wed, 02 Dec 2020 22:29:31 -0600
Message-ID: <CAD4huA4ikMjiHWZB4nNxV=dNuoz=sepJhuDJTs=RtM1v6o7YZA@mail.gmail.com>
To: Paul Gear <ntp=40libertysys.com.au@dmarc.ietf.org>
Cc: NTP WG <ntp@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000140f9905b587cf39"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ntp/T1o25_YtQhAb16r8A20wyakOdCg>
Subject: Re: [Ntp] NTPv5 and anycasting
X-BeenThere: ntp@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <ntp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ntp>, <mailto:ntp-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ntp/>
List-Post: <mailto:ntp@ietf.org>
List-Help: <mailto:ntp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ntp>, <mailto:ntp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 03 Dec 2020 04:29:46 -0000

Clients should be able to tell if a server uses anycast.
E.g., the client may not want to use *prefer* with an anycast NTP server


On Wed, Dec 2, 2020 at 3:40 PM Paul Gear <ntp=
40libertysys.com.au@dmarc.ietf.org> wrote:

> On 3/12/20 3:48 am, Philip Prindeville wrote:
>
> On Dec 2, 2020, at 1:08 AM, Miroslav Lichvar <mlichvar@redhat.com> <mlichvar@redhat.com> 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
> _______________________________________________
> ntp mailing list
> ntp@ietf.org
> https://www.ietf.org/mailman/listinfo/ntp
>

v2.23.0 | Report a Bug | By Email