Re: [TICTOC] Extension of working group last call (WGLC) for draft-ietf-tictoc-ptp-enterprise-profile-03 (PTP Enterprise Profile)

[Karen ODonoghue <[e-mail]>]

Folks,

I have received the following comments on the enterprise profile from
John Eidson, co-chair of the IEEE 1588 Working Group...

Regards,
Karen

I have also read the RFC and have the following comments:

1- Last ~sentence "When Preferred Master Clocks are not the Best Master
in one domain, they SHOULD      operate in another domain when they. "
on page 7 section 8 is unclear, i.e. when they "what"?

2- Section 8 describes a TLV you intend to use and is defined as an
organization specific TLV. The issue raised by the architecture
committee is whether 1588 should require that profile identification be
carried in a 1588 defined TLV rather than an organization specific. It
certainly would help with global issues such as distinguishing different
profiles, possibly isolation, etc. The current draft 1588 profile ID TLV
could certainly handle the information you have. I urge you to consider
a) moving to the 1588 TLV when it is defined, and b) contributing to the
discussion. My plan is to have this completed and voted upon by the end
of the September P1588 face-to-face. Whether we like it or not networks
especially IP will carry multiple profiles and applications using 1588
so some sort of globally agreed upon identification scheme appears
necessary (at least to me).

3- Section 9- I have heard Geoff argue that even Announce messages
traversing a TC will have the IP source address changed. I think for the
same reason as in layer 2 Ethernet that all PTP packets are handled
above the IP layer and therefore retransmission is actually a new
message with a new sourceIP address. Not sure he is right but I think
that is his argument- I would appreciate some clarity on this!

4- Section 11- I see you are requiring management messages. This needs
to be emphasized to the P1588 management committee as I know there are
those that would like to deprecate management messages and require only
SNMP or some such.

There is another issue which definitely will impact this profile, all
other profiles, 1588 itself, bluetooth and probably a lot of other
things as well. Namely the IEEE Registration Authority has changed their
policy on MAC addresses, OUIs and related things. For 1588 and its
cousins this affects the clock Identity specification. Perhaps you have
followed some of the discussions. Again Geoff is point man on this since
he is on the IEEE RAC. The current thinking is that none of the proposed
"solutions" will work and the only organization that can provide a
solution is the IEEE RAC itself. However it works out it is clear that
1588 clause 7.5.2 Port Identity will have changes. These will likely be
backward compatible but future implementations will definitely be
affected. Geoff indicates that the RAC realizes that a lot of work
depends on their finding a solution in a timely manner. Don't know what
your approval schedule is but I think this needs to be considered. My
own guess is that the resolution by RAC and whatever changes this forces
on 1588 will be 6 months. Hopefully less but it is a complicated mess
(for once not of our making).