Re: [Ntp] I-D Action: draft-mlichvar-ntp-over-ptp-03.txt

[Miroslav Lichvar <[e-mail]>]

On Mon, Mar 27, 2023 at 01:49:12PM +0000, Langer, Martin wrote:
> I read your draft and added a few comments. I hope it helps you a bit.

That's great. Thank you.

> I still have one general question about it. Are the hardware timestamps written
> directly to the NTP TLV? I didn't find anything about this in the draft.

The draft is about enabling hardware receive timestamps on hardware
which can timestamp only PTP messages. The hardware is not expected to
modify the message. The timestamps have to be fetched by the
networking driver from some specific registers of the NIC. This limits
the maximum rate of timestamping and is the reason why PTP uses two
UDP ports. The event port is used only for messages that needs to be
timestamped.

To answer some of the questions you added to the pdf:

One-step mode doesn't matter here as that is for transmit timestamps,
not receive timestamps.

The lack of on-path support was mentioned as an advantage of
NTP-over-PTP, because it still processes measurements as NTP and
doesn't assume a constant network delay (changing only on network
reconfiguration or server reselection).

Symmetric mode works in NTP-over-PTP and still cannot be secured by
NTS.

There doesn't have to be an actual PTP clock with ports in some
specific PTP state operating on the NTP server or client. There could
be a PTP clock in other domain or transport, but doesn't have to be.

I'm not sure how exactly it works with specifying new TLVs for PTP.
Does IETF have an organization Id we could use?

NTP request and NTP response are both included in a PTP delay request.

Modifying the PTP sequenceId (not protected by NTP authentication)
doesn't matter for NTP. We just need the hardware+driver to not
deduplicate the messages in case they actually look at the value. A
MITM attacker can always cause a denial of service.

-- 
Miroslav Lichvar