Re: [Ntp] ntp over ptp

[Miroslav Lichvar <[e-mail]>]

On Tue, Mar 12, 2024 at 09:05:30PM +0000, Doug Arnold wrote:
> Now that there is a fair number of switches and routers that support PTP, several standards organizations have specified or proposed specifications for timing protocols that use PTP messages, including the PTP reserved EtherType, for new timing protocols that are not PTP.  The IEEE 1588 Working Group has had several discussions about this and there is a great deal of concern that the behavior of PTP capable equipment receiving messages from quasi PTP protocols is uncertain, and therefore makes PTP less reliable.

You mean there could be bugs in PTP switches/routers that would be
triggered by NTP-over-PTP or similar protocols, but not regular PTP?
Can you describe an example of how would that happen?

I think it would be best if there was an additional layer between PTP
and UDP or other transports used specifically only for triggering
hardware timestamping and making transparent delay corrections, so it
could be used by different protocols like PTP and NTP.

I suspect it's too late to do anything about that. When PTP was
originally designed I guess nobody expected it would be used in
computer networks, but here we are. Existing hardware cannot be
changed and future hardware supporting multiple protocols seems
unlikely. The logic in the hardware timestamping path needs to be as
simple as possible to be able to run at increasing network speeds. 

> I have no objection to people defining new timing protocols, or to people copying aspects of PTP, but they should not use the reserved PTP EtherType in their new protocol.  The EtherType is the one thing that PTP implementations should be able to count on.

Are you suggesting we limit NTP over PTP to the following two
transports?
- NTP over PTP over UDP over IPv4
- NTP over PTP over UDP over IPv6

Currently as it is written it allows any transport that supports
unicast messaging. I wouldn't expect much interest in non-IP
transports like NTP over PTP over Ethernet or DeviceNet or ControlNet.

-- 
Miroslav Lichvar