Re: [Ntp] ntp-over-ptp concerns

[Miroslav Lichvar <[e-mail]>]

On Tue, Mar 12, 2024 at 11:42:18PM +0000, Rodney Cummings wrote:
> 1. The draft violates the IETF NTP WG charter. The draft does not enhance NTP. The draft specifies a TLV to enhance PTP. Therefore, the project should have been proposed in the IEEE 1588 Working Group.

I'm not sure if I can agree with that statement. I'd say NTP over PTP
enhances NTP by giving it a new transport. It's not useful for PTP in
any way. PTP already has multiple transports specified and more can
be specified by anyone who needs it. It could use NTP as a transport
if someone thought that was useful. NTP currently has just one
transport (UDP) and this would be the second one.

I think that would be like saying that DNS over HTTPS enhances HTTPS.
No, it's just an additional transport to carry DNS messages that has
some useful properties that the original transport doesn't have (e.g.
encryption).

> 2. The protocol specified in the draft uses two IEEE 1588 message formats, and therefore the protocol advertises itself as conformant to the IEEE 1588 standard. The protocol is not conformant to IEEE 1588, in that it ignores most requirements of that standard. This sort of disregard for IEEE conformance has never been published in the past by IETF. In the past, cooperation between IETF WGs and IEEE WGs has been excellent, and it is important that this cooperation continue.

NTP over PTP uses unicast delay requests conforming to IEEE 1588. If
such a message reaches a PTP implementation conforming to one of the
specific PTP profiles, the PTP clock will either ignore it (e.g. due
to unexpected domain number) or respond with a valid delay response,
which will be ignored by the NTP-over-PTP host. The NTP-over-PTP host
doesn't send announce messages, so it cannot be selected as the master
clock. If it received multicast delay requests from other hosts, it
would ignore them due to missing the NTP TLV.

> 3. If objection #1 and #2 are ignored, there is the problem that the draft's protocol breaks other conformant PTP Profiles that are running on the same network. Apparently, the draft is attempting to use domainNumber of 123 to isolate itself from other conformant PTP Profiles. This attempt is technically insufficient, because any other conformant PTP Profile is allowed to also use domainNumber 123.

Ok, that's a fair point. I think we can change it to allow a range of
domain numbers, so admins can avoid conflicts with future PTP
profiles if they need to be used alongside NTP over PTP.

> If IETF wishes to specify an isolated protocol, IETF must register to obtain an IEEE 1588 sdoId for that purpose, as described in:
>    https://standards.ieee.org/products-programs/regauth/sdoid/

Thanks, I think we can look into that.

> I would like to suggest a solution to all three of these problems.
> 
> The IEEE 1588 Working Group has recently submitted an IEEE Project Authorization Request (PAR) for IEEE P1588.1, Client Server Precision Time Protocol (CSPTP). The goals for the CSPTP project are to formally specify a simple client/server message exchange, similar to the message exchange described in draft-ietf-ntp-over-ptp-02. CSPTP will meet IEEE conformance and compatibility requirements, including use of sdoId.
> 
> IEEE approval of the new PAR for CSPTP is scheduled for May 2024, after which proposals will begin, leading to draft text. If the IEEE 1588 WG and IETF NTP WG cooperate to propose a TLV for CSPTP that encapsulates NTP, the result will effectively be NTP-over-CSPTP. In my view, that sort of IEEE/IETF cooperation is the best approach.

I couldn't find any information about this online. The "Client Server"
part indicates a new PTP exchange will be defined, perhaps using new
message types? But I'm not sure what difference it makes if we use
CSPTP instead of PTP for transporting NTP. If CSPTP can be made to
conform to the existing IEEE requirement, NTP-over-PTP can be changed
to do that too, right?

If you are only starting now, how long will it take to be finalized?
NTP over PTP started 3 years ago. We already have experimental
implementations, confirmed to be working with existing hardware. If
you are interested in IEEE/IETF cooperation, why don't you help us
finish it? The development would need to be public either way.

If there are other protocols interested in this, I think we can change
it from NTP to a more general UDP or IP transport.

-- 
Miroslav Lichvar