IETF Logo Mail Archive

Re: [Ntp] CLOCK_TAI (was NTPv5: big picture)

Philip Prindeville <philipp@redfish-solutions.com> Thu, 07 January 2021 07:43 UTC

Return-Path: <philipp@redfish-solutions.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 336A73A0408; Wed, 6 Jan 2021 23:43:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 kB9NqtJ3TQ2A; Wed, 6 Jan 2021 23:43:01 -0800 (PST)
Received: from mail.redfish-solutions.com (mail.redfish-solutions.com [45.33.216.244]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BB12A3A03FB; Wed, 6 Jan 2021 23:43:01 -0800 (PST)
Received: from [192.168.3.4] ([192.168.3.4]) (authenticated bits=0) by mail.redfish-solutions.com (8.16.1/8.16.1) with ESMTPSA id 1077h092363270 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 7 Jan 2021 00:43:00 -0700
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.40.0.2.32\))
From: Philip Prindeville <philipp@redfish-solutions.com>
In-Reply-To: <8cdc69d3-c795-6fee-3e5c-9ae11694e3da@meinberg.de>
Date: Thu, 07 Jan 2021 00:43:00 -0700
Cc: Martin Burnicki <martin.burnicki=40meinberg.de@dmarc.ietf.org>, Miroslav Lichvar <mlichvar@redhat.com>, Hal Murray <hmurray@megapathdsl.net>, ntp@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <B5016121-81C3-48AC-B59B-BF0CFC2926B4@redfish-solutions.com>
References: <20210105124544.5EF5C40605C@ip-64-139-1-69.sjc.megapath.net> <f876a3ff-16ee-fc63-c27c-d5a3cb847a3d@meinberg.de> <4E78BB38-5FA2-4974-AB25-85C5AD9E7DBE@redfish-solutions.com> <8cdc69d3-c795-6fee-3e5c-9ae11694e3da@meinberg.de>
To: Martin Burnicki <martin.burnicki@meinberg.de>
X-Mailer: Apple Mail (2.3654.40.0.2.32)
X-Scanned-By: MIMEDefang 2.84 on 192.168.1.3
Archived-At: <https://mailarchive.ietf.org/arch/msg/ntp/kXCHUlHOBOiGFEhfTY23-AHOhWk>
Subject: Re: [Ntp] CLOCK_TAI (was NTPv5: big picture)
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, 07 Jan 2021 07:43:03 -0000


> On Jan 6, 2021, at 3:50 AM, Martin Burnicki <martin.burnicki@meinberg.de> wrote:
> 
> Philip Prindeville wrote:
>>> On Jan 5, 2021, at 9:09 AM, Martin Burnicki <martin.burnicki=40meinberg.de@dmarc.ietf.org> wrote:
>>> 
>>> For NTP, things are different. There is a huge base of NTPv4
>>> installations, and making NTPv5 basically compatible with v4 would IMO
>>> strongly increase the acceptance of NTPv5.
>> 
>> 
>> The logical corollary to this argument is that because there ARE a lot of servers, it’s not unreasonable to think that there will be a lot of both NTPv4 and NTPv5 servers co-existing in the future, and the user is free to peer with either.
> 
> So you think it's not necessary to upgrade v4 nodes to v5, as it has
> been done from v3 to v4? Simply systems should stick with v4 and only
> enhanced system should start using v5?


No, where did I say that?

I’m saying that as part of the upgrade process, they can be re-configured to use different servers.  That’s hardly a rare occurrence.


> 
> In this case, wouldn't it be better to start defining a completely new
> protocol and e.g. call it "Extended Time Protocol", which can be chosen
> instead of NTP? This would be similar to PTP, which you can use instead
> of NTP. ;-)


Except we’re not a parallel track, we’re the next stepping stone on a migration path.


> 
>> Which eliminates the need for NTPv5 servers to also speak NTPv4.
> 
> If you have a large network with different types of client you will need
> to provide NTPv4 and "ETP" (AKA NTPv5) if NTPv5 has requirements that
> are not needed and can't be supported by some clients.


Sorry, something isn’t parsing…  If they’re not needed then are they really requirements?  Aren’t requirements “needed” by definition?

But if they’re not really needed after all and the clients don’t support them anyway, isn’t that a non-issue?

I’m not following…

-Philip



> 
> Martin
> -- 
> Martin Burnicki
> 
> Senior Software Engineer
> 
> MEINBERG Funkuhren GmbH & Co. KG
> Email: martin.burnicki@meinberg.de
> Phone: +49 5281 9309-414
> Linkedin: https://www.linkedin.com/in/martinburnicki/
> 
> Lange Wand 9, 31812 Bad Pyrmont, Germany
> Amtsgericht Hannover 17HRA 100322
> Geschäftsführer/Managing Directors: Günter Meinberg, Werner Meinberg,
> Andre Hartmann, Heiko Gerstung
> Websites: https://www.meinberg.de  https://www.meinbergglobal.com
> Training: https://www.meinberg.academy
>

v2.23.0 | Report a Bug | By Email