[Linuxptp-devel] missing SET commands in PMC

[Rommel, Albrecht]

Dear Experts,

Is there a particular reason that linuxptp does not support some SET commands in PTP management client?
Example:

pmc -u -d 24 ŽGET LOG_SYNC_INTERVALŽ is implemented
pmc -u -d 24 ŽSET LOG_SYNC_INTERVALŽ is not implemented

Is this limitation only in PMC, that the composition of the relevant SET TLV is not implemented, but ptp4l would accept such a SET TLV?
Or is the limitation within ptp4l itself?

Regards,
Albrecht

[Richard Cochran]

Post by Rommel, Albrecht
Is there a particular reason that linuxptp does not support some SET commands in PTP management client?

The only reason is that no one has needed any additional SET commands.
In practice, with the exception of the GM settings, there does not
seem to be much utility in changing parameters on the fly.

Post by Rommel, Albrecht
Is this limitation only in PMC, that the composition of the relevant SET TLV is not implemented, but ptp4l would accept such a SET TLV?
Or is the limitation within ptp4l itself?

It would need to be implemented both in the pmc and in the ptp4l
programs.

Thanks,
Richard

[Rommel, Albrecht]

Hi Richard,

There is a demand for changing PORT_DATA_SET and probably CLOCK_DESCRIPTION while ptp4l is running.
The main reason is due to the circumstances involved for stopping ptp4l, modifying the config file (possibly from remote!), restarting ptp4l, and the likelihood of config file corruption. Having a network API (TLVs) to modify attributes would be more elegant and safe. If we want to complete the SET/GET TLVs for pmc/ptp4l, who would you recommend to do this? It should be aligned with the allowed GET/SET actions as defined in IEEE1588-2008, table 40 - managementtld values.

Regards,
Albrecht

[Richard Cochran]

Post by Rommel, Albrecht
There is a demand for changing PORT_DATA_SET and probably
CLOCK_DESCRIPTION while ptp4l is running.

First off, according to 1588 CLOCK_DESCRIPTION is GET only. There is
no SET.

Secondly, PORT_DATA_SET is a collection, and thus it also has no SET.
The individual elements are set-able, but these are determined by the
profile, and you don't go changing the profile suddenly. At least, I
have never heard of use case for that.

Post by Rommel, Albrecht
The main reason is due to the circumstances involved for stopping
ptp4l, modifying the config file (possibly from remote!), restarting
ptp4l, and the likelihood of config file corruption.

There is no issue changing a configuration file and restarting
remotely. That is what SSH was invented for.

Also, we *never* allow SET remotely, only via UDS. The PTP management
mechanism has no authentication at all, and so we cannot allow it over
the network.

Post by Rommel, Albrecht
Having a network API (TLVs) to modify attributes would be more
elegant and safe. If we want to complete the SET/GET TLVs for
pmc/ptp4l, who would you recommend to do this? It should be aligned
with the allowed GET/SET actions as defined in IEEE1588-2008, table
40 - managementtld values.

I'll consider patches that correctly implement SET actions from 1588.

Thanks,
Richard

[Rommel, Albrecht]

Hi Richard,

Thanks for clarification

There are some applications where a PTP clock node (i.e. a master-only-ordinary-clock) will be configured from remote in a secure environment, i.e. NETCONF YANG, or other transport technology (ITU PON, IEEE PON, DOCSIS) specific management protocols. As you mentioned, these elements are profile specific, the profile won't change dynamically, but there is the requirement to configure the profile via the management protocols mentioned above. Having the SET option via UDS to the individual elements as listed in table 40 1588-2008 would be great. The above management protocols could be (locally) translated to UDS.

Post by Richard Cochran
I'll consider patches that correctly implement SET actions from 1588.

Any timeline for that? How do you estimate the effort for implementation?

Best regards,
Albrecht

[Richard Cochran]

Post by Rommel, Albrecht
There are some applications where a PTP clock node (i.e. a
master-only-ordinary-clock) will be configured from remote in a
secure environment, i.e. NETCONF YANG, or other transport technology
(ITU PON, IEEE PON, DOCSIS) specific management protocols. As you
mentioned, these elements are profile specific, the profile won't
change dynamically, but there is the requirement to configure the
profile via the management protocols mentioned above. Having the SET
option via UDS to the individual elements as listed in table 40
1588-2008 would be great. The above management protocols could be
(locally) translated to UDS.

Right. At the end of the day, we will have a number of incompatible
SNMP MIBs for PTP, including the power profile, gPTP, and Yang.

Any of these can be implemented in stand alone programs that translate
SNMP into PTP over UDS. But so far, we seen exactly zero lines of
code offered to implement any of the SNMP stuff. :(

Post by Rommel, Albrecht
Any timeline for that? How do you estimate the effort for implementation?

Personally, I have no interest in this, but as I said before, I will
consider patches for inclusion...

Thanks,
Richard

[Rommel, Albrecht]

Richard,

Another question:
What does the ´NP´ stand for, with management TLVs *_NP, such as
GRANDMASTER_SETTINGS_NP
PORT_DATA_SET_NP
TIME_STATUS_NP

Regards,
Albrecht

[Richard Cochran]

Post by Rommel, Albrecht
Richard,
What does the ´NP´ stand for, with management TLVs *_NP, such as
GRANDMASTER_SETTINGS_NP
PORT_DATA_SET_NP
TIME_STATUS_NP

Non-Portable. IOW, these are custom TLVs.

HTH,
Richard