Re: [Ntp] ntp-over-ptp concerns

[Miroslav Lichvar <[e-mail]>]

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