Re: [TICTOC] Enterprise Profile

[Wojciech Owczarek <[e-mail]>]

Doug,

Here are some last comments from myself:

---

Clause 8. Requirements for Master Clocks - Enterprise profile TLV - Maximum
Absolute Phase Adjustment:

>> Slaves can use the Maximum Phase Adjustment to determine if the clock

WO: Which Clock? Master clock? I think this could/should be explicitly
stated.

>> is slewing to rapidly for the applications which are of interest.

WO: is slewing or can slew? - see below. Also should be "too rapidly"

General question about this value - I understand that the value is scaled
to the sync interval, but does this denote the maximum phase adjustment the
GM is *capable of*, the maximum phase adjustment the GM *has applied* since
going into MASTER state, or the value *applied during the last sync
interval*?

Finally, do you think there is room to add an octet (or better two) of an
Implementation Specific field to the end of this TLV? This would allow for
a very easy way to add custom data.

----

Clause 11. Management and signaling messages:

While the restriction of the wildcard target port identity to multicast
only makes sense from a consistency point of view, this also makes it
impossible to use Unicast management messages without knowing the exact
port identity. This makes it more difficult to deploy management stations
which (blasphemy!) are not part of the timing domain, multicast
distribution wise. Could this requirement perhaps state that an exception
are unicast management messages sent to the wildcard identity, only if they
are of the GET type? OR, that one device can send unicast management
messages to another device using the wildcard entity only until it learns
its identity, such as when  it receives the first reply?

On the same note re. unicast and multicast: the standard itself essentially
says that if a message requiring a reply, comes in via unicast (at least
with the PTP_UNICAST flag lit) - the reply should also be unicast -
analogically with multicast. Could the Enterprise Profile perhaps state
this explicitly?

Basically where I'm going with this is that if you're in conformance with
the Enterprise Profile, it's guaranteed that you can remotely poll PTP
clock datasets from a monitoring station using unicast.

----

Otherwise this is good - the soon this becomes an official profile the
better. Some particularly uncooperative vendors tend to use the lack of a
profile definition as an excuse for not implementing the features we
(finance) want.


Regards
Wojciech






On 4 July 2014 14:25, Tim Frost <[e-mail]> wrote:

>  Hi Doug,
>
>
>
> Sorry, I hadn’t read the previous versions, so I hadn’t commented before.
>
>
>
> The one big technical comment I have is on security and multiple domains.
> You talk about slave clocks being capable of synchronizing to (and by
> implication ensembling information from) multiple masters in multiple
> domains.  This has to be outside of the IEEE1588 protocol, since what
> happens in one domain shouldn’t influence what happens on another.  I
> accept G.8265.1  has set a precedence for this type of “outside of
> IEEE1588” behaviour, but at least that makes clear what the rules and
> expected behavior are.  This is a little vague on what you are allowed to
> do; that may be intentional to not narrow down implementations or prevent
> innovation, but it doesn’t make for easy interoperability.
>
>
>
> In clause 14 you present this as the main plank of your security strategy,
> but don’t really make it clear how it should work. I think some elaboration
> here is required.
>
>
>
> Some other minor comments:
>
> -          There is none of the expected “boiler plate” for a profile,
> i.e. profileName, profileIdentifier, profileVersion etc.
>
> -          In clause 6, you don’t mention if Follow-up messages are
> multicast or unicast (I assume it should be multicast, but it doesn’t say)
>
> -          In clause 8, you should elaborate on what a “preferred master”
> is and why it is different from other masters
>
> -          In clause 8, paragraph 1, sentence 3 stops abruptly: “…they
> SHOULD operate in another domain when they.” What’s missing?
>
> -          In clause 8, what is the main purpose and expected use of the
> TLV? What should subsequent clocks do with it and why do they need to
> receive it?
>
>
>
> Best regards,
>
> Tim
>
>
>
>
>
> Tim Frost   |   *Calnex Solutions Ltd.*   |   [phone]   |
> www.calnexsol.com
>
>
>
> *From:* TICTOC [mailto:[e-mail]] *On Behalf Of *Douglas
> Arnold
> *Sent:* 03 July 2014 04:39
> *To:* [e-mail]
> *Subject:* [TICTOC] Enterprise Profile
>
>
>
> Hello Everyone,
>
>
>
> I have posted a new version (v03) of the PTP Enterprise Profile.  The only
> difference since the last time is to change the location of the port
> address in the announce TLV.  The purpose of this is to bring the TLV
> structure into alignment with the IEEE C37.238 (Power Profile) revision
> which has gone to ballot with the IEEE.  That would make two profiles with
> the same general announce TLV structure, which hopefully starts a trend.
>
>
>
> Aside from this minor cosmetic change the document has been stable since
> the February version.  All comments have been addressed one way or another,
> so I hope to see this go to last call.
>
>
>
> --
>
> Doug Arnold
>
> Principal Technologist
>
> *JTime!* Meinberg USA
>
> [phone]
>
>
>
> _______________________________________________
> TICTOC mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tictoc
>
>


-- 
-

Wojciech Owczarek