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

Thank you Miroslav :)

The draft should emphasize, unless I missed it, that no "working" PTP is required. At first I thought that NTP-over-PTP is bound to a working PTP network. This is not the case.  It just uses PTP messages as a frame for NTP messages to use hardware time stamping and it could run without any conflicts next to PTP.

The TLV thing would still need to be clarified. IDs for the IETF are not known to me at this time.

best regards,
martin

-------------------
Martin Langer, M.Eng.
Ostfalia Hochschule für angewandte Wissenschaften
- Hochschule Braunschweig/Wolfenbüttel
University of Applied Sciences

Labor Datentechnik, Labor Design Digitaler Systeme
Fakultät Elektrotechnik
Salzdahlumer Straße 46/48
38302 Wolfenbüttel
Germany

Tel.: +49 5331 939 43370
Web: https://www.ostfalia.de/cms/de/pws/bermbach/mitarbeiter/martin-langer

________________________________
Von: ntp <ntp-bounces@ietf.org> im Auftrag von Miroslav Lichvar <mlichvar@redhat.com>
Gesendet: Montag, 27. März 2023 16:37:51
An: ntp@ietf.org
Betreff: Re: [Ntp] I-D Action: draft-mlichvar-ntp-over-ptp-03.txt

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

_______________________________________________
ntp mailing list
ntp@ietf.org
https://www.ietf.org/mailman/listinfo/ntp