Re: [Ntp] ntp-over-ptp concerns

[Rodney Cummings <[e-mail]>]

Hi Miroslav,


> 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”, and “This is a transient state to allow initialization of…”.



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.



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.



I still say that latter approach is preferable.

Rodney

From: Miroslav Lichvar <[e-mail]>
Sent: Thursday, March 21, 2024 9:04 AM
To: Rodney Cummings <[e-mail]>
Cc: Rodney Cummings <rodney.cummings=[e-mail]>; NTP WG <[e-mail]>; Doug Arnold <[e-mail]>
Subject: Re: [Ntp] ntp-over-ptp concerns

On Tue, Mar 19, 2024 at 04: 14: 44PM +0000, Rodney Cummings wrote: > There’s a very basic statement in 6. 6. 2 of 1588-2019: > “MASTER: The PTP Port is the source of time on the PTP Communication Path served by the PTP Port. ” > > What
ZjQcmQRYFpfptBannerStart
This Message is From an External Sender: Use caution opening files, clicking links or responding to requests.
ZjQcmQRYFpfptBannerEnd

On Tue, Mar 19, 2024 at 04:14:44PM +0000, Rodney Cummings wrote:

> There’s a very basic statement in 6.6.2 of 1588-2019:

>                 “MASTER: The PTP Port is the source of time on the PTP Communication Path served by the PTP Port.”

>

> What is the source of time in NTP-over-PTP?



There is no working PTP source of time in NTP over PTP. It's like a

network where all PTP clocks are slaveOnly clocks, waiting for a

master to appear, but that never happens. The PTP clocks are just

sending unicast delay requests transporting NTP messages according to

their configuration. Nothing interesting is happening from the PTP

point of view.



> You seem to be saying “It doesn’t comply with any state in 1588”. If so, that proves my point.



No, I'm not saying that. The UNCALIBRATED state seems perfectly fine

for NTP over PTP. It allows delay requests to be sent by the port. It

doesn't require any messages to be received before that. The unicast

option doesn't require the delay response grant for sending delay

requests.



9.5.11.2 has requirements for timing of delay requests. It starts with

"Unless the unicast option of 16.1 is in use", but 16.1 refers back to

9.5.11.2 with "In addition to these transmission requirements,

Delay_Req messages are also required to comply with the transmission

requirements defined in 9.5.11.2.", i.e. there is a loop in the

specification.



Assuming the intention for timing of unicast delay requests was

to also follow the general requirements specified for multicast delay

requests, we need a different state to stop sending delay requests

when not needed. The PASSIVE state seems like a good option. It

ignores all received messages and doesn't transmit anything.

Alternatively, we can immediately destroy the PTP instance after

sending the delay request and create it again when needed.



The port can reach the UNCALIBRATED and PASSIVE states the usual way

from INITIALIZING through LISTENING using an alternate BMCA, or

directly using the "17.6 Mechanism for external configuration of a PTP

Instance’s PTP Port state" option.



Please let me know if you see any errors in this.



--

Miroslav Lichvar