[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.
- [TICTOC] Gunter Van de Velde's No Objection on dr… Gunter Van de Velde via Datatracker