Re: [Ntp] ntp-over-ptp concerns

[Rodney Cummings <[e-mail]>]

Hi Miroslav,

> NTP over PTP transmits only unicast delay request messages.

> requirements of IEEE 1588 which the current proposal of NTP over PTP doesn't follow?



As one recent example, refer to this liaison from IEEE 1588 WG to the IEEE 802.1 WG, approved unanimously in the 1588 WG:
            https://www.ieee802.org/1/files/public/docs2024/liaison-ieee1588-P8021ASebPARcomments-feb24.pdf
Background: 802.1AS is a profile of 1588 that is layer-2 multicast, and allows for BMCA to be disabled. When BMCA is disabled, the 802.1 WG wanted an option to disable the Announce message as well. 1588-2019 requires Announce in 9.5.8 and elsewhere, so both WGs faced the same sort of problem as we are discussing here. The 802.1 WG has agreed to work with the 1588 WG on the problem, and the solution will ultimately involve cooperative projects in both standards.

The point is that if one WG has valid reasons to violate the requirements in 1588, that’s okay, but it requires a project in the 1588 WG in order to loosen the requirements.

Rodney

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

On Wed, Mar 13, 2024 at 05: 46: 43PM +0000, Rodney Cummings wrote: > 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…
ZjQcmQRYFpfptBannerStart
This Message is From an External Sender: Use caution opening files, clicking links or responding to requests.
ZjQcmQRYFpfptBannerEnd

On Wed, Mar 13, 2024 at 05:46:43PM +0000, Rodney Cummings wrote:

> 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.



We are not trying to change or ignore any of that. NTP over PTP uses a

subset of the specified protocol, which could be observed in a normal

PTP network. It's a delay request which doesn't have a delay response.



It's not supposed to be a new behavior of PTP, which would have to be

specified by IEEE.



> 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.



Can you please point to (some of) the specific requirements of IEEE

1588 which the current proposal of NTP over PTP doesn't follow? I'm

not aware of anything forbidden or conflicting with what NTP over PTP

is doing, but it's possible I missed it. I admit I have not read all

500 pages and even the parts I have read I'm not able to keep all in

my head.



NTP over PTP transmits only unicast delay request messages. That's

what ports in the UNCALIBRATED and SLAVE states normally do. There is

no unicast negotiation for this message, so we don't need any

signalling messages.



Only ports in the MASTER state respond to delay requests. In other

states they are ignored. Without MASTER ports there are no delay

responses, announce messages and sync messages.



An alternate BMCA is allowed by 1588. It doesn't have to use data from

received announce messages. It can select statically or dynamically

based on other inputs.



>From the PTP point of view I think we can describe NTP over PTP as a

domain of ordinary clocks using unicast messaging, E2E delay

mechanism, and an alternative BMCA with ports switching between the

PASSIVE and UNCALIBRATED states. When an NTP-over-PTP instance needs

to send an NTP message, it changes its internal PTP state so that the

alternative BMCA selects the corresponding NTP target as the master,

the port state is switched to the UNCALIBRATED state, the unicast

NTP-over-PTP delay request is sent, and the state is immediately

changed back to switch the port to the PASSIVE state. The PTP part of

the receiver ignores the message, but the NTP part processes it. The

minimum delay request interval can be a very small fixed value.



Do you see anything wrong with that?



I think there are other ways how it could be described, e.g.

temporary PTP instances.



> 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://urldefense.com/v3/__https://sagroups.ieee.org/1588/how-to-join-p1588/__;!!I5pVk4LIGAfnvw!mj7IfSoBow1vjVqjNzL3-YLx7gNEb93WW3pA_i7hh3pbhLTYRSfR3dFscY4Osb3lZDp_x6ssCc2NzrXSCHZ9d3Kf$<https://urldefense.com/v3/__https:/sagroups.ieee.org/1588/how-to-join-p1588/__;!!I5pVk4LIGAfnvw!mj7IfSoBow1vjVqjNzL3-YLx7gNEb93WW3pA_i7hh3pbhLTYRSfR3dFscY4Osb3lZDp_x6ssCc2NzrXSCHZ9d3Kf$>



If we could join as the whole WG with this list that would be nice.



> 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://urldefense.com/v3/__https://engineering.fb.com/2024/02/07/production-engineering/simple-precision-time-protocol-sptp-meta/__;!!I5pVk4LIGAfnvw!mj7IfSoBow1vjVqjNzL3-YLx7gNEb93WW3pA_i7hh3pbhLTYRSfR3dFscY4Osb3lZDp_x6ssCc2NzrXSCC1FCzd0$<https://urldefense.com/v3/__https:/engineering.fb.com/2024/02/07/production-engineering/simple-precision-time-protocol-sptp-meta/__;!!I5pVk4LIGAfnvw!mj7IfSoBow1vjVqjNzL3-YLx7gNEb93WW3pA_i7hh3pbhLTYRSfR3dFscY4Osb3lZDp_x6ssCc2NzrXSCC1FCzd0$>

> https://urldefense.com/v3/__https://github.com/meinberg-sync/flashptpd__;!!I5pVk4LIGAfnvw!mj7IfSoBow1vjVqjNzL3-YLx7gNEb93WW3pA_i7hh3pbhLTYRSfR3dFscY4Osb3lZDp_x6ssCc2NzrXSCOygcfhq$<https://urldefense.com/v3/__https:/github.com/meinberg-sync/flashptpd__;!!I5pVk4LIGAfnvw!mj7IfSoBow1vjVqjNzL3-YLx7gNEb93WW3pA_i7hh3pbhLTYRSfR3dFscY4Osb3lZDp_x6ssCc2NzrXSCOygcfhq$>

> I view ntp-over-ptp as a third.



Those two proposals look very different to me than NTP over PTP and

in this case I'd agree they do not conform to the current 1588

requirements, because they send unicast sync messages without

negotiation.



--

Miroslav Lichvar



_______________________________________________

ntp mailing list

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

https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/ntp__;!!I5pVk4LIGAfnvw!mj7IfSoBow1vjVqjNzL3-YLx7gNEb93WW3pA_i7hh3pbhLTYRSfR3dFscY4Osb3lZDp_x6ssCc2NzrXSCOdYIQ-a$<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/ntp__;!!I5pVk4LIGAfnvw!mj7IfSoBow1vjVqjNzL3-YLx7gNEb93WW3pA_i7hh3pbhLTYRSfR3dFscY4Osb3lZDp_x6ssCc2NzrXSCOdYIQ-a$>