Hi folks,
I'll chime in with some unofficial opinion.
I agree with everything that Richard says below. 1588 v2.1 is compatible. 1588
v2.0 implementations ignore the received minorVersionNumber, and will
interoperate just fine if it is received as 1. It is simpler to use macros for
the versions, and that's conformant.
Richard asked:
> What is the use case for making the version configurable?
My educated guess as to why minorVersionNumber is configurable in portDS is:
In 1588-2008, versionNumber (major version 2) was configurable in
portDS.
For v2.1, when the 1588 group added minorVersionNumber, we probably just added
it to the same location as versionNumber.
Why was it that way in 1588-2008 (v2.0)?
I don't see a strong argument for it personally, but I suppose the 1588
working group just wanted to allow for maximum flexibility.
In any event, there's nothing that mandates configurability at the port level.
I think most PTP implementations will use macros at the instance level.
Yangbo asked:
> It seems IEEE 1588-2019 specified minorVersionNumber in portDS,
> but not in PORT_DATA_SET management TLV data field. It's confusing.
That was an oversight. I'll submit a maintenance request to add it.
It'll happen at the blazing fast speeds of IEEE SA process (sarcasm), but it'll
happen eventually.
In the meantime, I think most PTP implementations will report the versions as
read-only from management, so adding minorVersionNumber to PORT_DATA_SET is a
small nice-to-have feature, and there's no problem skipping it for this patch.
As an aside, if folks in this list find other bugs in 1588-2019 in the future,
the 1588 working group recently opened up the maintenance process to folks who
don't attend the meetings:
https://sagroups.ieee.org/1588/contact/
Rodney Cummings
IEEE 1588 Vice Chair
> -----Original Message-----
> From: Richard Cochran <richardcoch...@gmail.com>
> Sent: Wednesday, February 24, 2021 9:18 AM
> To: Y.b. Lu <yangbo...@nxp.com>
> Cc: Linuxptp-devel@lists.sourceforge.net
> Subject: [EXTERNAL] Re: [Linuxptp-devel] [PATCH] ptp4l: version
> preparation for IEEE 1588-2019
>
> On Tue, Feb 23, 2021 at 03:40:38AM +0000, Y.b. Lu wrote:
> > Considering only 1588, v2.1 is backward compatible.
>
> Yes.
>
> > Regarding to many profiles, I only know 802.1AS... One thing I'm
> > unsure is, if a profile is based on a specific 1588 version, does the
> > message must use the corresponding version in header?
>
> I think that if you implement an optional v2.1 feature (like the security
> extension) then you can and should advertise v2.1 in the header. We
> already have some v2.1 optional stuff, and so we can bump up the version
> number. (I've just been too lazy to do that myself, and so I'm glad you
> are doing it!)
>
> > Should the message header use version v2 for AS-2011 profile, and use
> v2.1 for AS-2020 profile?
>
> No, I don't think the minor version (the X in 2.X) conveys any actionable
> information to the PTP network at run time. There are no practical
> standardized constraints on the use of profiles. Sadly, It is up to the
> administrator to get the settings right.
>
> > Another thing I'm unsure is, whether new version of a profile is also
> backward compatible. I hope yes.
>
> Yes. All 2.x versions are compatible, according to 1588.
>
> > So, may I have your suggestion on how to move ptp4l to v2.1? Do we need
> to implement something like deciding 1588 version per profile in program?
>
> Please, just make the v2.1 as macros, fill out the minor field in the
> frames, and forget about dynamic version changes at run time.
>
> Thanks,
> Richard
>
>
> _______________________________________________
> Linuxptp-devel mailing list
> Linuxptp-devel@lists.sourceforge.net
> https://urldefense.com/v3/__https://lists.sourceforge.net/lists/listinfo/l
> inuxptp-devel__;!!FbZ0ZwI3Qg!6JmeTb-
> Ug48qhqib23EZaM53rJjawM92zHIQEYgIOVFFghe8tHHtE2uc7whaVX5tGA$
_______________________________________________
Linuxptp-devel mailing list
Linuxptp-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
