Re: [Ntp] ntp-over-ptp concerns

[David Venhoek <[e-mail]>]

I was under the impression that one needed to be a member of the IEEE to
participate in any of its working groups. This is financially not viable
for a number of us and part of the reason we aren't yet involved in any of
these discusisons. The page you link to suggests this might not be the
case. Could you clarify on this for us?

Kind regards,
David Venhoek


On Wed, Mar 13, 2024 at 6:47 PM Rodney Cummings <rodney.cummings=
[e-mail]> wrote:

> 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]
>
> 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$>
>
> _______________________________________________
> ntp mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ntp
>