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: [email protected] [mailto:[email protected]] On Behalf Of
Doug Arnold
Sent: Monday, February 25, 2013 11:52 PM
To: [email protected]
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
_______________________________________________
TICTOC mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/tictoc
