Reviewer: Tim Chown
Review result: Has Nits
Hi,
I have reviewed this document as part of the Operational directorate's ongoing
effort to review all IETF documents being processed by the IESG. These
comments were written with the intent of improving the operational aspects of
the IETF drafts. Comments that are not addressed in last call may be included
in AD reviews during the IESG review. Document editors and WG chairs should
treat these comments just like any other last call comments.
The document describes a PTP Profile for use in enterprise networks, be they
IPv4 or IPv6.
Overall, the document is well written. I would currently say it is Ready with
Nits.
General comments
I’m not familiar enough with PTP to know what a Profile is, or looks like.
Section 5 begins with “This PTP Profile SHALL operate only in…” but it’s not
obvious to me what part(s) of the document constitute the Profile, and in the
extensive glossary of technical terms, ‘Profile’ is not included. Perhaps this
could be clearer.
The document includes several negative comments about multicast, without citing
any RFCs or other references as to why multicast is problematic. This would be
helpful. I am familiar for example with RFC 9119 on multicast in wireless
networks, and am a co-author of RFC 8115 on deprecation of inter-domain ASM,
but the issues hinted at here don’t fall under either of those documents. The
third paragraph seems to suggest PTP nodes “throw away 99% of multicast”, but
usually one would assume multicast is used because the information sent is of
interest to multiple nodes concurrently.
The document uses SHALL quite extensively rather than MUST. This is unusual,
but in line with RFC 2119. I suspect readers will be more used to seeing MUST.
Other comments:
Technical terms
The section doesn’t clearly differentiate e2e delay measurement mechanism and
p2p delay measurement - I assume the timeTransmitter and timeReceiver may not
be directly connected, and relay via a Boundary clock? If so, is the Boundary
clock not a transmitter and receiver also, or at least the definition implies
that?
Problem statement
I believe you can use hardware timestamping for general NTP, and we are doing
so in our own network with a notable improvement in stability. So perhaps here
be clearer about why hardware timestamping with PTP is advantageous.
Section 5
The text appears a little inconsistent over IPv4 and IPv6 use. It says if both
are present, they MUST be treated as separate paths (implying duplication over
a path between dual-stack devices), but then a PTP domain MUST use IPv4 or IPv6
but not both. Perhaps be clearer, and also mention how the IP version is
selected when communicating devices are dual-stack.
It’s also not clear to me why the source address changes at a Transparent
clock. I’m sure there’s a good reason, given in another RFC, but it would be
useful to have a pointer to that reason included here. Does the address also
need to have at least the scope of the e2e communication (more relevant for
IPv6)?
Section 6
Maybe cite
https://www.iana.org/assignments/ipv6-multicast-addresses/ipv6-multicast-addresses.xhtml
for the multicast reserved address, and likewise IPv4. I note 182-184 are
reserved also for PTP alternates.
Section 11
What’s a ‘servo loop’?
Best wishes,
Tim
