Hello Éric, Thank you for reviewing the draft. You raise a number of good questions. I will answer inline below:
## Intended status Should the IETF publish a standards track document for a IEEE protocol? In this case yes. IEEE 1588 defined the concept of profiles for specific use cases, and specifically set up rules for the definition of these profiles in other standards organizations, i.e. which ever organization has the best knowledge of the use case in question. PTP Profiles have been defined in various IEEE working groups in addition to IEEE 1588, but also in the ITU-T, IEC, SMPTE, AES, LXI, and 3GPP. There might be others. The enterprise profile was brought to the IETF with the belief that this organization has the best understanding of enterprise IT networks. Moreover (see my comments about section 5), it does not seem to be a profile only as it is more about recommendations; i.e., no need for normative language. See my response to section 5 comments. ## TICTOC charter The TICTOC charter has an item about profile but it also states that the profile should include a MIB: ``` To develop an IEEE1588v2 profile as necessary for time and frequency distribution, with primary focus on (1). This profile will include a MIB module for IEEE1588v2. This might be an error in the TICTOC charter. The IEEE1588v2 MIB was intended to be a separate project. ## Abstract Please expand PTP acronym before first use. I agree and would change “PTP” to “Precision Time Protocol (PTP)” in the abstract. Note that the acronym is also define defined in the first sentence of the introduction, but I don’t think that it hurts to expand it in the abstract as well. ## Section 1 It is considered inefficient that, even if the content of a message applies only to one receiver, it is forwarded by the underlying network (IP) to all nodes, requiring them to spend network bandwidth and other resources, such as CPU cycles, to drop the message. ``` What is meant here by 'underlying network' ? If it is a multi-link routed IP network, then multicast traffic is either dropped by the first router for forwarded efficiently with the use of PIM. If it is layer-2 network (e.g., Ethernet), then remove "(IP)" and note that many if not all NIC are able to drop unwanted mcast packets without CPU cycles. PTP is generic to transport layer technology if a mapping to the technology is defined. Mappings have been defined for Ethernet, IPv4, IPv6, OTN, and five specialized industrial network technologies. A PTP Profile typically defines which mappings are relevant. These can be referred to as the “underlying network.” PTP nodes receive all mcast packets directed to the PTP mcast addresses. However in pure mcast PTP, many message are irrelevant for a specific PTP node, but this can only be determined at the PTP level via the intended PTP Port Identity. ``` In PTP domains with a lot of nodes, devices had to throw away more than 99% of the received multicast messages because they carried information for some other node. ``` Is there a reference for the above text ? Else, consider removing it (or at least remove the 99% if unfounded). The 99+% is not unfounded. In pure mcast PTP a timeTranmitter port might send time to thousands of timeReceivers. The TimeTransmitter sends 1 sync message and 1 announce that is received by all of them. Each of the timeReceivers also sends a delay request so that it will be answered by the timeTransmitter. So far, no problem. However, in mcast PTP all of the other timeReceivers also receive the delay request, plus they each receive all of the delay responses, only one of which is relevant. If there are 1000 timeReceivers each timeReceiver receives 1 sync message, 1 announce message, 999 useless delay requests, 1 usefull delay response, and 999 useless delay responses. So 3 usefull messages out of 2001 received. This is an inherent property of mcast PTP. We could reference: P. V. Estrela and L. Bonebakker, "Challenges deploying PTPv2 in a global financial company," 2012 IEEE International Symposium on Precision Clock Synchronization for Measurement, Control and Communication Proceedings, San Francisco, CA, USA, 2012, pp. 1-6, doi: 10.1109/ISPCS.2012.6336634. ## Section 4 Accuracy currently required in the Financial Industry range from 100 microseconds to 1 nanoseconds to the Grandmaster. ``` Is there a reference for those numbers? A reference would be appropriate here, The 100 microseconds comes from MiFID II: Directive 2014/65/EU of the European Parliament and of the Council of 15 May 2014 on markets in financial instruments and amending Directive 2002/92/EC and Directive 2011/61/EU. The 1 ns end of the scale comes from high frequency traders, and they never publish anything. I only know this from talking to them at conferences. For this reason, it is desired to make use of multicast whenever the information going to many destinations is the same. ``` I find this text weird as I understood in the previous sections that "multicast is not suitable" ? Mcast is efficient when the exact same information needs to go to all other PTP Nodes. Unicast is inefficient when information is intended only for a specific PTP Node. This PTP profile, defines a hybrid or mixed multicast/unicast operation. ## Section 5 Out of curiosity, as PTP seems to be an application layer protocol, why is it that `IPv4 and IPv6 instances in the same network node MUST operate in different PTP Domains.` ? I have a little knowledge of PTP, I am trusting the authors for this statement. That’s a fair question. Mixed IPv4 and IPv6 PTP networks are not common as far as I know, and I wanted to avoid any complexities in the interaction between 2 PTP Port instances in a dual stack IP port. As the document is about a profile (in my mind values for parameters not topology), why using normative language in `The PTP system MAY include switches and routers.`? Same for `Thus, wherever possible, the network SHOULD be engineered so that the forward and reverse routes traverse the same physical path.` in section 6. Suggest changing the title of the document and using "recommendations" rather than "profile". Two IEEE 1588 conformant implementation do not necessarily interoperate. That is only assured when they are also conformant to the same PTP profile, and that profile needs to have MUST statements to guarantee that. All PTP Profiles that I know of are specified with at least some hard requirements. ## Section 15 Suggest adding a note to the RFC editor to replace the datatracker reference with the RFC number. This sounds like a good idea. I will ask someone what the standard way to state that is. ________________________________ From: Éric Vyncke via Datatracker <[email protected]> Sent: Monday, May 13, 2024 4:52 AM To: The IESG <[email protected]> Cc: [email protected] <[email protected]>; [email protected] <[email protected]>; [email protected] <[email protected]>; [email protected] <[email protected]>; [email protected] <[email protected]> Subject: Éric Vyncke's No Objection on draft-ietf-tictoc-ptp-enterprise-profile-26: (with COMMENT) Éric Vyncke 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: ---------------------------------------------------------------------- # Éric Vyncke, INT AD, comments for draft-ietf-avtcore-rtp-scip-05 Thank you for the work put into this document. Please find below some non-blocking COMMENT points (but replies would be appreciated even if only for my own education). Special thanks to Erik Kline (the responsible AD :-O ) for the shepherd's detailed write-up including the WG consensus and the justification of the intended status. Other thanks to Tommy Pauly, the Internet directorate reviewer (at my request), please consider this int-dir review: https://datatracker.ietf.org/doc/review-ietf-tictoc-ptp-enterprise-profile-26-intdir-telechat-pauly-2024-05-09/ (while the review is recent, I was unable to find a reply) I hope that this review helps to improve the document, Regards, -éric # DISCUSS (blocking) As noted in https://www.ietf.org/blog/handling-iesg-ballot-positions/, a DISCUSS ballot is a request to have a discussion on the following topics: ## # COMMENTS (non-blocking) ## Intended status Should the IETF publish a standards track document for a IEEE protocol ? Moreover (see my comments about section 5), it does not seem to be a profile only as it is more about recommendations; i.e., no need for normative language. ## TICTOC charter The TICTOC charter has an item about profile but it also states that the profile should include a MIB: ``` To develop an IEEE1588v2 profile as necessary for time and frequency distribution, with primary focus on (1). This profile will include a MIB module for IEEE1588v2. ``` ## Abstract Please expand PTP acronym before first use. ## Section 1 ``` It is considered inefficient that, even if the content of a message applies only to one receiver, it is forwarded by the underlying network (IP) to all nodes, requiring them to spend network bandwidth and other resources, such as CPU cycles, to drop the message. ``` What is meant here by 'underlying network' ? If it is a multi-link routed IP network, then multicast traffic is either dropped by the first router for forwarded efficiently with the use of PIM. If it is layer-2 network (e.g., Ethernet), then remove "(IP)" and note that many if not all NIC are able to drop unwanted mcast packets without CPU cycles. ``` In PTP domains with a lot of nodes, devices had to throw away more than 99% of the received multicast messages because they carried information for some other node. ``` Is there a reference for the above text ? Else, consider removing it (or at least remove the 99% if unfounded). ## Section 4 ``` Accuracy currently required in the Financial Industry range from 100 microseconds to 1 nanoseconds to the Grandmaster. ``` Is there a reference for those numbers ? ``` For this reason, it is desired to make use of multicast whenever the information going to many destinations is the same. ``` I find this text weird as I understood in the previous sections that "multicast is not suitable" ? ## Section 5 Out of curiosity, as PTP seems to be an application layer protocol, why is it that `IPv4 and IPv6 instances in the same network node MUST operate in different PTP Domains.` ? I have a little knowledge of PTP, I am trusting the authors for this statement. As the document is about a profile (in my mind values for parameters not topology), why using normative language in `The PTP system MAY include switches and routers.`? Same for `Thus, wherever possible, the network SHOULD be engineered so that the forward and reverse routes traverse the same physical path.` in section 6. Suggest changing the title of the document and using "recommendations" rather than "profile". ## Section 15 Suggest adding a note to the RFC editor to replace the datatracker reference with the RFC number.
_______________________________________________ TICTOC mailing list -- [email protected] To unsubscribe send an email to [email protected]
