Re: [Ntp] ntp-over-ptp concerns

[Miroslav Lichvar <[e-mail]>]

On Wed, Mar 13, 2024 at 05:46:43PM +0000, Rodney Cummings wrote:
> By protocol standardization, I mean any protocol: IP, TCP, HTTP, NTP, PTP, LLDP, etc.
> First, the transmitting device identifies the protocol’s message on the network… “Hello this message is from protocol <whatever>”.
> Second , the standard for the protocol specifies how the protocol works on the network. This standard is *not* limited to the format of the message. It includes behavior (e.g., response to a request, periodic transmit), state machines, management… all sorts of required/optional specs beyond just the message format.

We are not trying to change or ignore any of that. NTP over PTP uses a
subset of the specified protocol, which could be observed in a normal
PTP network. It's a delay request which doesn't have a delay response.

It's not supposed to be a new behavior of PTP, which would have to be
specified by IEEE.

> Of course people come up with great new ideas, but these fundamentals of protocol standardization have to be respected, or else our entire technological world will break down (e.g., TCP won’t work).
> If a great new idea comes around, that idea needs to be formally integrated into the protocol standard.
> 
> The problem with draft-ietf-ntp-over-ptp-02 is that it is violating these fundamentals. It uses the 1588 message format (i.e., says “Hello I am 1588”), but it doesn’t follow the requirements in the IEEE 1588 standard.

Can you please point to (some of) the specific requirements of IEEE
1588 which the current proposal of NTP over PTP doesn't follow? I'm
not aware of anything forbidden or conflicting with what NTP over PTP
is doing, but it's possible I missed it. I admit I have not read all
500 pages and even the parts I have read I'm not able to keep all in
my head. 

NTP over PTP transmits only unicast delay request messages. That's
what ports in the UNCALIBRATED and SLAVE states normally do. There is
no unicast negotiation for this message, so we don't need any
signalling messages.

Only ports in the MASTER state respond to delay requests. In other
states they are ignored. Without MASTER ports there are no delay
responses, announce messages and sync messages.

An alternate BMCA is allowed by 1588. It doesn't have to use data from
received announce messages. It can select statically or dynamically
based on other inputs.

>From the PTP point of view I think we can describe NTP over PTP as a
domain of ordinary clocks using unicast messaging, E2E delay
mechanism, and an alternative BMCA with ports switching between the
PASSIVE and UNCALIBRATED states. When an NTP-over-PTP instance needs
to send an NTP message, it changes its internal PTP state so that the
alternative BMCA selects the corresponding NTP target as the master,
the port state is switched to the UNCALIBRATED state, the unicast
NTP-over-PTP delay request is sent, and the state is immediately
changed back to switch the port to the PASSIVE state. The PTP part of
the receiver ignores the message, but the NTP part processes it. The
minimum delay request interval can be a very small fixed value.

Do you see anything wrong with that?

I think there are other ways how it could be described, e.g.
temporary PTP instances.

> Until then, the documents working up to the PAR creation must be kept internal to the 1588 WG. Anyone on the mailing list is welcome to join the 1588 WG to see those docs. Just use these instructions to send an email:
> https://sagroups.ieee.org/1588/how-to-join-p1588/

If we could join as the whole WG with this list that would be nice.

> There are a small handful of proposals out there for unicast client/server protocols that use 1588 messages, but do not conform to 1588 requirements. Two of them are publicly documented:
> https://engineering.fb.com/2024/02/07/production-engineering/simple-precision-time-protocol-sptp-meta/
> https://github.com/meinberg-sync/flashptpd
> I view ntp-over-ptp as a third.

Those two proposals look very different to me than NTP over PTP and
in this case I'd agree they do not conform to the current 1588
requirements, because they send unicast sync messages without
negotiation.

-- 
Miroslav Lichvar