Re: [TICTOC] PTP Enterprise Profile draft

[Tal Mizrahi <[e-mail]>]

Hi Doug, Heiko,

I believe the draft is well written, and is valuable to the industry.
A few comments below.

Comments:

1.       Section 4: “The accuracy currently required can be as tight as 1 µs.”

a.       It doesn’t say ‘SHALL’ or ‘SHOULD’, but I suggest to clarify whether this accuracy number is brought as a requirement, or as an informational figure.

b.      I suggest to clarify exactly what 1us accuracy means from the 2 options below (unfortunately the two meanings below are used inconsistently :)

                                                               i.      The maximal difference between 2 clocks in the domain is 1us
or

                                                             ii.      All clocks are synchronized to the master by at most ±1 us.

2.       Section 6: “Master clocks and Transparent clocks MAY be either one-step clocks or two-step clocks.”
It is implied that you refer to BCs as well, but it is worth clarifying this explicitly.

3.       I am a bit confused about the usage this draft makes of the terms ‘Discovery’ (clause 17.5 in 1588) and ‘negotiation’ (clause 16.1 in 1588) – probably worth clarification.

a.       There is no explicit requirement to refrain from using unicast negotiation, but the requirement is implicitly stated in Section 6.1: “All Sync messages MUST be sent as multicast messages to the PTP event message multicast address.”

b.      Section 13 says: “the Enterprise profile will not interoperate with clocks operating in the Telecom Profile for Frequency Synchronization[G8265.1], because the Enterprise Profile forbids Unicast Discovery with message negotiation”.
I searched ITU-T G.8265.1, and did not find the word ‘discovery’, although unicast negotiation is indeed used.

c.       Section 3 should probably define ‘negotiation’ and explain the difference from ‘discovery’.

4.       General comment: you may want to discuss the fact that in IP networks Sync messages and Delay_Req messages exchanged between a master and a slave do not necessarily traverse the same physical path. Thus, wherever possible, the network should be traffic engineered so that the forward and reverse routes traverse the same physical path.

5.       General comment: You may want to discuss NAT scenarios. When a path between a master and a slave traverses address translations, it means that multiple clocks may appear to have the same IP address.
Thus, I believe this document should require clock to identify the peer clock based on its Clock Identity, and not based on its IP address. I think this issue is not discussed in detail in IEEE 1588, but is certainly relevant in enterprise networks.

6.       Question [I had a similar comment about the MPLS draft]: should we define the term “PTP port” in the context of this profile? For a router, a PTP port is a router interface, whereas for a switch it is a physical port. I wonder whether this is clear to the reader, or needs to be clarified.

Minor comments:

1.       s/Precise Time Protocol /Precision Time Protocol/

2.       s/The profile used/The profile uses/

3.       Semantic comment: In Section 3, definition of Best Master Clock Algorithm, it is implied that the algorithm elects the grandmaster. This is not necessarily accurate for BCs, so it is probably more accurate to state that BMCA elects a master.
The same issue applies to the second paragraph of section 1.

4.       Section 5: “If a network contains both IPv4 and IPv6, then they SHALL be treated as separate PTP systems.” – does that mean different domains? Please clarify.

5.       Section 5: I suggest to clarify that PTP-over-IPv4 and PTP-over-IPv6 SHALL comply to Annex D and Annex E of 1588, respectively.

6.       Section 10: using multiple masters mitigates not only a rouge master attack, but also man-in-the-middle attacks such as delay attacks, packet interception / manipulation attacks. Assuming the path to each master is different, a man-in-the-middle attacker is limited only to the path she attacks.

7.       Section 14 Security Considerations:
There should be a short discussion about the Rouge master attack (Section 10), and a cross reference to Section 10.

8.       Section 15 IANA Considerations: this section should probably include the <Organization SubType> values and < Delay Request/Response Mode> values from section 9, since these are specific values to the Enterprise profile, and are defined by the IETF.

Thanks,
Tal.

From: [e-mail] [mailto:[e-mail]] On Behalf Of Doug Arnold
Sent: Monday, February 25, 2013 11:52 PM
To: [e-mail]
Subject: [TICTOC] PTP Enterprise Profile draft

Here is a first cut at a draft of a PTP profile foe enterprise networks.  Any feedback/suggestions would be much appreciated.

I enclose both a MS Word version and a pure text version, since I used the Joe Touch’s template.

//Doug