[TICTOC] Gunter Van de Velde's No Objection on draft-ietf-tictoc-ptp-enterprise-profile-26: (with COMMENT)

Gunter Van de Velde via Datatracker <noreply@ietf.org> Mon, 06 May 2024 11:36 UTC

Return-Path: <noreply@ietf.org>
X-Original-To: tictoc@ietf.org
Delivered-To: tictoc@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C332EC14F68B; Mon, 6 May 2024 04:36:52 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Gunter Van de Velde via Datatracker <noreply@ietf.org>
To: The IESG <iesg@ietf.org>
Cc: draft-ietf-tictoc-ptp-enterprise-profile@ietf.org, tictoc-chairs@ietf.org, tictoc@ietf.org, ek.ietf@gmail.com, ek.ietf@gmail.com
X-Test-IDTracker: no
X-IETF-IDTracker: 12.11.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Gunter Van de Velde <gunter.van_de_velde@nokia.com>
Message-ID: <171499541278.28864.16771310409797162833@ietfa.amsl.com>
Date: Mon, 06 May 2024 04:36:52 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/tictoc/3EjqftIMx4X_fFaJE9-3Q6Bbf6w>
Subject: [TICTOC] Gunter Van de Velde's No Objection on draft-ietf-tictoc-ptp-enterprise-profile-26: (with COMMENT)
X-BeenThere: tictoc@ietf.org
X-Mailman-Version: 2.1.39
List-Id: Timing over IP Connection and Transfer of Clock BOF <tictoc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tictoc>, <mailto:tictoc-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tictoc/>
List-Post: <mailto:tictoc@ietf.org>
List-Help: <mailto:tictoc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tictoc>, <mailto:tictoc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 06 May 2024 11:36:53 -0000

Gunter Van de Velde has entered the following ballot position for
draft-ietf-tictoc-ptp-enterprise-profile-26: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ 
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-tictoc-ptp-enterprise-profile/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

# Gunter Van de Velde, RTG AD, comments for
draft-ietf-tictoc-ptp-enterprise-profile-26

Please find https://www.ietf.org/blog/handling-iesg-ballot-positions/
documenting the handling of ballots.

#HIGH LEVEL COMMENTS
#===================
## Thank you for this write up. The documents reads well for a network
generalist as myself.

## One item kept confusing me was about delay. Is this the minimal delay of the
link or some overage? does it include queueing or QoS properties? Maybe some
words about these assuptions would be good to set the stage for the ongoing
usage of 'delay'

## on line 258 it is written that this document describes a version of PTP
while my nderstanding was that ptp was an IEE standard. ow can IETF describe a
new version of ptp? I assume my understanding of the wording 'describes a
version of PTP' is incorrect. Please confirm

## There is some assumption around line 320 about IPv4 addresses behind a NAT.
I was slightly surprised to not see a discussin around IPv6 and address
selection finding and using an address of the wrong scope. Is this not a
consern for ptp in the context of this document?

## some non compliant to RFC2119 normative language is used "NOT ALLOWED ". Is
that intentional?

#DETAILED COMMENTS
#=================
##classified as [minor] and [major]

14         This document describes a PTP Profile for the use of the Precision
15         Time Protocol in an IPv4 or IPv6 Enterprise information system
16         environment.  The PTP Profile uses the End-to-End delay measurement

[minor] What about following suggestion for start of abstract?
"This document outlines a PTP Profile for the use of the Precision Time
Protocol within an IPv4 or IPv6 Enterprise Information System environment."

86         master, and timeReceiver, in stead of slave, as defined in the IEEE

[minor] typo
s/in stead/instead/

102        The third edition of the standard (IEEE 1588-2019) defines PTPv2.1

[minor] I am not sure i discovered the 2nd edition of in the earlier
text. I know very little about this technology, so i may have missed the
subtle description.

103        and includes the possibility to use unicast communication between the
104        PTP nodes in order to overcome the limitation of using multicast
105        messages for the bi-directional information exchange between PTP

[minor] disclaimer that my ptp knowledge is not existing. This phrase
seems to indicate that the restriction is that communication
in both directions is muticast. In most tehnologoes the server side sends
mcast to everybody and then the clients pick up the mcast messags and
complete the remainder with unicast packets. Is this not happening
with ptp first and second version?

111        PTPv2.1 also includes PTP Profiles (IEEE 1588-2019 [IEEE1588]
112        subclause 20.3).  This construct allows organizations to specify
113        selections of attribute values and optional features, simplifying the
114        configuration of PTP nodes for a specific application.  Instead of
115        having to go through all possible parameters and configuration
116        options and individually set them up, selecting a PTP Profile on a
117        PTP node will set all the parameters that are specified in the PTP
118        Profile to a defined value.  If a PTP Profile definition allows
119        multiple values for a parameter, selection of the PTP Profile will
120        set the profile-specific default value for this parameter.

[minor] are there any profiles that are industry standard and well known?
or is this all local to the site or the ptp server-client relationship?

143     3.  Technical Terms
145        *  Acceptable TimeTransmitter Table:
149        *  Alternate timeTransmitter:

[minor] This section has terminology that either starts with single capital
and others that have words with more as a single capital. Is this intentional?

204        *  Peer-to-Peer delay measurement mechanism: A network delay
205           measurement mechanism in PTP facilitated by an exchange of
206           messages over the link between adjacent devices in a network.

[minor] does adjacent mean L2 adjacent or L3 session/tunneled adjacent between
peers?

210        *  Preferred timeTransmitter: A device intended to act primarily as
211           the Grandmaster of a PTP system, or as a back up to a Grandmaster.

[minor] How is the correlation with the Best timeTransmitter as mentioned above?
The differentiation betweenGrandmaster and Best timeTransmitter confuses me a
slightly.

221        *  PTP Profile: A set of constraints on the options and features of
222           PTP, designed to optimize PTP for a specific use case or industry.
223           The profile specifies what is required, allowed and forbidden
224           among options and attribute values of PTP.

[minor] is this Profile a local network construct or something are there
profiles that are well known in the industry?

232           Algorithm, and does not set the Alternate timeTransmitter flag.

[minor] not sure if this should be 'does not' or 'has not'?

258        This document describes a version of PTP intended to work in large
259        enterprise networks.  Such networks are deployed, for example, in

[major] I assumed from earlier text that ptp was an IEEE specification.
How can IETF outline a new version of ptp when it is owned by IEEE?

272        a traditional time transfer such as NTP, without adding non-standard
273        customizations such as on-path support, similar to what is done in
274        PTP with Transparent Clocks and Boundary Clocks.  Such PTP support is

[minor] what does 'on-path' exactly mean support mean in the context of ptp?

281        Although enterprise networks can be large, it is becoming
282        increasingly common to deploy multicast protocols, even across
283        multiple subnets.  For this reason, it is desired to make use of

[minor] 'even across multiple subnets'. This is oddly written.
If there is a single subnet then ther eis no need for multicast protocols
because all is a single flooding domain. The need for multicast protocols
comes when there is need for multicast to sent between L3-subnets. Maybe the
subnets refered to here are not L3-subnets but administrative boundaries or so?

285        same.  It is also advantageous to send information which is only
286        relevant to one device as a unicast message.  The latter can be

[minor] yes, advantageous, assuming hte message is sent to the intended
target device :-)

299        This PTP Profile MUST operate only in networks characterized by UDP
300        RFC 768 [RFC0768] over either IPv4 RFC 791 [RFC0791] or IPv6 RFC 8200
301        [RFC8200], as described by Annexes C and D in IEEE 1588 [IEEE1588]
302        respectively.  A network node MAY include multiple PTP instances

[minor] i am not entirely sure what 'charactarized' means in the above phrase.
Is is intended to say 'operate exclusively' maybe?

What about this proposal:
"This PTP Profile MUST operate exclusively in networks using UDP as defined
in RFC 768 [RFC0768] over either IPv4 [RFC0791] or IPv6 [RFC8200], as
detailed in Annexes C and D of IEEE 1588 [IEEE1588], respectively."

320        PTP messages are retranmitted.  In IPv4 networks some clocks might be
321        hidden behind a NAT, which hides their IP addresses from the rest of
322        the network.

[major] in IPv6 networks the source address selection mechanisms may have
selected an IPv6 address unknown (for example due to different address
scope usage) to the recipient. Is that something to consider
or detail?

332        the PTP system from meeting the timing requirements.  The details of
333        network asymmetry are outside the scope of this document.  See for
334        example, ITU-T G.8271 [G8271].

[minor] what about queing delays when different queue are used for the
traffic due to QoS? I assume this wil be out of scope also. Maybe
worthwile to add that consideration. The delay assumed will be the min delay
of link (not the avg or max or anything else). If for example the link is
a fiber then the delay should be the result of the length of te link and
speed of light through the fiber. Are other delays included in the procedure
proposed with this document?

479        timing for delay measurement.  Grandmaster Clusters are NOT ALLOWED.

[major] the NOT ALLOWED seems not official formal RFC2119 language.