Re: [Ntp] NTP over PTP

[Doug Arnold <[e-mail]>]

Hello Miroslav

RE: acceptance of NTP over PTP
Obviously I do not speak for everyone, and I could be mistaken. But I talk to a lot of vendors and network operators and this is my take on where they are coming from.  I also believe that I have a good sense of the PTP standards world and doubt that anyone will include NTP over PTP in a PTP Profile.  NTP over PTP is a clever hack, and might be done quickly, but I think people will want something cleaner with fewer redundant message fields.  People in standards meetings frequently talk about the importance of keeping PTP messages small.

RE: use of unicast PTP in telecom:
Yes, telecom will use full on path support as soon as they can, and switch to G.8275.1 with SyncE.  But that is probably a decade out for some carriers.  Telecom grade switches are just too expensive to replace because they don’t support PTP. They replace them on a schedule that is planned for years in advance.  An active area of discussion in the ITU these days in defining the “interworking function.”  This is basically a boundary clock that translates between two PTP profiles, mainly to facilitate the gradual transition from G.8275.2 to G.8275.1.

RE: History of the ITU, NTP WG and IEEE 1588
About twenty years ago, after the telecom industry changed to Ethernet and packet switched networks, they knew that they needed packet based time transfer.  All of the telecom equipment vendors started presenting lab research papers at the annual T1 X1 workshops (now called WSTS) on what they called “carrier grade NTP”.  By this they meant NTP packets, but with high message rates, and different algorithms for clock steering and server selection.  Some people in the NTP WG proposed separating the over the wire protocol from the algorithms, just as you have done in your draft NTPv5.  Others in the working group wanted to keep NTP as a coherent complete solution for general IT use cases, as it traditionally had been.  The complete solution camp prevailed.  I can understand that.  NTP is spectacularly successful at meeting the general IT needs.

I went to an IEEE 1588 meeting in the early days of version two.  We were surprised when twice as many people showed up as had attended previously.  All of the new people worked for telecom equipment vendors, and were members of the ITU-T.  They explained to us that they had given up on carrier grade NTP and hoped that IEEE 1588 would help them.  That was about 2005.  After a few fierce arguments we agreed to make changes to PTP that they wanted.  Among the concessions was unicast PTP.  So the telecom folks got their carrier grade NTP after all.

If you want another take on this ask anyone who was in these groups 15 years ago: the NTP WG, IEEE 1588, ITU-T Q13/15.

RE: NTPv5 and protocol algorithm split
Some people in the finance industry have recently reinvented carrier grade NTP and prefer it to PTP.  They like that clients getting time from multiple servers is the norm, and the clients figure out which servers to believe, rather than running a BMCA as in PTP.

That is why I actively support the separating of protocol and algorithms in NTPv5, including supporting your proposal.  I may be the chair of IEEE 1588, but I’m not interested in turf wars.  I want the network operators to have everything they need, including a more flexible NTP, and a more secure PTP.

Doug

From: Miroslav Lichvar <[e-mail]>
Date: Wednesday, June 30, 2021 at 6:19 AM
To: Doug Arnold <[e-mail]>
Cc: Heiko Gerstung <heiko.gerstung=[e-mail]>, [e-mail] <[e-mail]>
Subject: Re: [Ntp] NTP over PTP
On Tue, Jun 29, 2021 at 05:10:02PM +0000, Doug Arnold wrote:
> PTP with embedded NTP messages would not be accepted by the equipment vendors who make PTP capable devices, and not be accepted by network operators who deploy PTP.

Do you speak for all vendors and operators?

> Even when the PTP ATHENTICATION TLV was defined people were concerned about making PTP messages longer.  The NTP messages would be redundant information that adds no value, accept for the attached ICV.  So why not just add the ICV and skip the NTP message.

Yes, you can do that, but you will not get all of the security of
NTS4NTP, which some people here seem to be interested in. You can
think of the NTP TLV as an authentication TLV that provides you with
that. It has to be longer as it contains the keys.

> However some industries are wedded to unicast PTP.  Telecom is heavily invested in PTP for wireless back haul timing.  The investment is in their standards, in product development and network deployment.

I'm somewhat familiar with the ongoing efforts in the telecom
industry. From what I understand, they are not going to use unicast
PTP in the new-generation networks. It's only for the older
generations as it cannot meet the new requirements. They need full
on-path support (i.e. G.8275.1) and in some cases even SyncE. Please
correct me if I'm wrong.

> Their contributions to the definition of NTPv4 were rejected,

This is the interesting part for me. Is the discussion archived
anywhere?

--
Miroslav Lichvar