Re: [Ntp] ntp-over-ptp concerns

Miroslav Lichvar <> Mon, 25 March 2024 12:31 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 5C5B6C14F6A0 for <>; Mon, 25 Mar 2024 05:31:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.106
X-Spam-Status: No, score=-2.106 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, T_SCC_BODY_TEXT_LINE=-0.01] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id gs9xhbpN1O-n for <>; Mon, 25 Mar 2024 05:31:28 -0700 (PDT)
Received: from ( []) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by (Postfix) with ESMTPS id E2971C14F698 for <>; Mon, 25 Mar 2024 05:31:27 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=mimecast20190719; t=1711369886; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=92q8i853nEImhxFq+OC+bSQVw1sWECc6ODcnOBYOmNA=; b=AAqESCUjxaWJyfP/7NSWm2gLcN0gtZbsR9hEVSA+8U7TZqCL0QqWlY9YwefojWD+pF0Ck0 phWtIAYyRcj1cTLoNbJosE/TWO8BG+Antm7n5jbMsu9H4h+7g+yYJMCjG6FKADBJqu73t7 Xr5s1JgBQRUiYMHCfvxeirklSurwzXg=
Received: from ( []) by with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-66-r_jcRM96OeeO29n-JacN8A-1; Mon, 25 Mar 2024 08:31:23 -0400
X-MC-Unique: r_jcRM96OeeO29n-JacN8A-1
Received: from ( []) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by (Postfix) with ESMTPS id 85EBA101A526; Mon, 25 Mar 2024 12:31:22 +0000 (UTC)
Received: from localhost (unknown []) by (Postfix) with ESMTPS id 8D2E740C6DAE; Mon, 25 Mar 2024 12:31:21 +0000 (UTC)
Date: Mon, 25 Mar 2024 13:31:20 +0100
From: Miroslav Lichvar <>
To: Rodney Cummings <>
Cc: Rodney Cummings <>, NTP WG <>, Doug Arnold <>
Message-ID: <ZgFumDWc3r83DYkX@localhost>
References: <> <ZfG46DseQnstP42z@localhost> <> <Zfha5e_qPafzuhYz@localhost> <> <Zflgai93DduRfWyX@localhost> <> <Zfw-UJOw3-la9aEv@localhost> <>
MIME-Version: 1.0
In-Reply-To: <>
X-Scanned-By: MIMEDefang 3.4.1 on
X-Mimecast-Spam-Score: 0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
Archived-At: <>
Subject: Re: [Ntp] ntp-over-ptp concerns
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Network Time Protocol <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 25 Mar 2024 12:31:32 -0000

On Thu, Mar 21, 2024 at 11:39:53PM +0000, Rodney Cummings wrote:
> > The UNCALIBRATED state seems perfectly fine for NTP over PTP.
> 9.2.5 of 1588-2019 states that for UNCALIBRATED, “One or more PTP Ports in the MASTER state have been detected in the domain”,

Right. In our case that's set externally to the PTP instance.

> and “This is a transient state to allow initialization of…”.

That sentence ends with ", and other implementation-specific
activity". That's exactly what we are doing in NTP over PTP.

> To back up a bit, let’s assume that you can find a loophole for the 1588 port state requirements.
> That’s great, but then I can find a handful of other 1588 requirements that NTP-over-PTP is violating.
> You might find a handful of loopholes for those. We go back and forth, and ultimately folks in each WG will want to engage, and we end up exchanging rounds of formal liaison letters back and forth. I can’t speak for others, but personally I don’t find that sort of exchange to be a constructive use of my time.

I'm sorry about wasting your time. I have more interesting things to
do too.

It was you who came here and claimed the draft is violating some
1588 requirements. You should have something concrete, a single
sentence containing the word "shall" describing something NTP over PTP
cannot be doing, or a sentence containing "shall not" describing
something that NTP over PTP has to be doing.

Specifications are written to enable interoperation between different
implementations and avoid breaking existing and future things. The
only thing that NTP over PTP is doing is sending delay requests.
That's the most common thing happening in a PTP domain. I don't think
it can break anything. Every PTP instance must be able to handle it
(ignore or respond).

> In contrast, once 1588.1 is rolling, in 1588.1 we can specify a “SERVER state” and a “CLIENT state”, each of which does exactly what NTP-over-PTP needs. Everything is nice and clean and clear, without the need for loopholes.

That might work well for the protocols proposed by Facebook and
Meinberg, but I don't see how the PTP instance in NTP over PTP would
use a "SERVER state" or "CLIENT state". It's just a transport. There
is no client or server side, the same as there are no clients
or servers in UDP, IP, or Ethernet. The concept of a client and
server is at a higher level. That's NTP in NTP over PTP.

I suspect you just don't like the idea of something being built on top
of PTP instead of being included in PTP. That's understandable.

I think it's time for the chairs or AD to step in and provide some
guidance on how to deal with the politics.

Miroslav Lichvar