Re: [Ntp] ntp-over-ptp concerns

[Rodney Cummings <[e-mail]>]

Thanks Miroslav,

I’m willing to drop my objection #1, because it really merges into #2. I saw the TICTOC WG as still “Active”, so I didn’t see why the NTP WG was enhancing PTP. It seems like maybe TICTOC is merging into NTP, in which case conformant/cooperative enhancements to PTP are in-scope for the NTP WG. Nevertheless, I don’t see anything in the recent NTP WG charter that grants permission to re-invent 1588 (objection #2).

Regarding objection #2, I’ll try to backup a bit.
Generally speaking how does protocol standardization work?
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.
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.

Is NTP-over-PTP a great new idea?
Sure… I’m wiling to accept that as true (with the possible exception of objection #3).
My objection relates to the process being used to standardize the idea… not the idea itself.


>>  IEEE approval of the new PAR for CSPTP…
> I couldn't find any information about this online.
Unfortunately that’s due to IEEE process. I’m not defending that process, but we have to deal with it. IEEE won’t allow a Working Group to formally work on a topic until the “PAR” document is formally approved (which we hope is in May).
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/
Contact me and I can point you to them. To be honest though, there isn’t much there.
At this stage, 1588 members like me can offer our personal opinion of what 1588.1 will become, but that’s about it. I can offer my opinion…

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.

In my opinion, the 1588.1 project will be the venue where advocates of each of these proposals argue for their new idea. In my view, passion brings progress, so I don’t see any problem if some of the debates get heated (but respectful). In the end, we’ll take the best features of all proposals, and draft that into 1588.1 as “CSPTP”. If we can reach consensus on a single solution, that will be far better than 4-5 solutions. When 1588.1 is published as a standard, it will follow the fundamentals of protocol standardization. When a device says “I am 1588”, CSPTP will be formally conformant in its specs.

Rodney

From: ntp <[e-mail]> On Behalf Of Miroslav Lichvar
Sent: Wednesday, March 13, 2024 9:32 AM
To: Rodney Cummings <rodney.cummings=[e-mail]>
Cc: NTP WG <[e-mail]>; Doug Arnold <[e-mail]>
Subject: Re: [Ntp] ntp-over-ptp concerns

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
ZjQcmQRYFpfptBannerStart
This Message is From an External Sender: Use caution opening files, clicking links or responding to requests.
ZjQcmQRYFpfptBannerEnd

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://urldefense.com/v3/__https://standards.ieee.org/products-programs/regauth/sdoid/__;!!I5pVk4LIGAfnvw!kmeX-7XLzGBbgVuEs4KZ6FoEgz0I8V4g5nz5jtDtYLpslNDT2_dDl1ScWpCusGnMj8ycs_o2Dp2rSTjLPpZDYHld$<https://urldefense.com/v3/__https:/standards.ieee.org/products-programs/regauth/sdoid/__;!!I5pVk4LIGAfnvw!kmeX-7XLzGBbgVuEs4KZ6FoEgz0I8V4g5nz5jtDtYLpslNDT2_dDl1ScWpCusGnMj8ycs_o2Dp2rSTjLPpZDYHld$>



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



_______________________________________________

ntp mailing list

[e-mail]<mailto:[e-mail]>

https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/ntp__;!!I5pVk4LIGAfnvw!kmeX-7XLzGBbgVuEs4KZ6FoEgz0I8V4g5nz5jtDtYLpslNDT2_dDl1ScWpCusGnMj8ycs_o2Dp2rSTjLPkFJYeKg$<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/ntp__;!!I5pVk4LIGAfnvw!kmeX-7XLzGBbgVuEs4KZ6FoEgz0I8V4g5nz5jtDtYLpslNDT2_dDl1ScWpCusGnMj8ycs_o2Dp2rSTjLPkFJYeKg$>