Enterprise Profile for the Precision Time Protocol With Mixed Multicast and Unicast messages
draft-ietf-tictoc-ptp-enterprise-profile-28

Thank you to Tero Kivinen for his careful review of draft 24.  While some of his of his points were addressed, there are still some that remain in draft 26.  I will only highlight a few of these:
  - The use of MUST NOT in cases where a positive requirement could be used, where a direct requirement of MUST can be used.  Often MUST is clearer to understand.
  - For PTP Management messages, the discrepency of 'MAY' in Section 12 and SHOULD NOT in Section 18 need to be reconciled.  (My recommendation would be to change Section 12 to 'SHOULD NOT')

# 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.

This review consists of both COMMENTs and NITs.

-------------------------------------------------------------------------------
COMMENT
-------------------------------------------------------------------------------

Section 1, paragraph 4
>    PTPv2.1 also includes PTP Profiles (IEEE 1588-2019 [IEEE1588]
>    subclause 20.3).  This construct allows organizations to specify
>    selections of attribute values and optional features, simplifying the
>    configuration of PTP nodes for a specific application.  Instead of
>    having to go through all possible parameters and configuration
>    options and individually set them up, selecting a PTP Profile on a
>    PTP node will set all the parameters that are specified in the PTP
>    Profile to a defined value.  If a PTP Profile definition allows
>    multiple values for a parameter, selection of the PTP Profile will
>    set the profile-specific default value for this parameter.
>    Parameters not allowing multiple values are set to the value defined
>    in the PTP Profile.  Many PTP features and functions are optional,
>    and a PTP Profile should also define which optional features of PTP
>    are required, permitted, and prohibited.  It is possible to extend
>    the PTP standard with a PTP Profile by using the TLV mechanism of PTP
>    (see IEEE 1588-2019 [IEEE1588] subclause 13.4), defining an optional
>    Best TimeTransmitter Clock Algorithm and a few other ways.  PTP has
>    its own management protocol (defined in IEEE 1588-2019 [IEEE1588]
>    subclause 15.2) but allows a PTP Profile to specify an alternative
>    management mechanism, for example NETCONF.

While NETCONF is the management protocol that can carry a PTP profile information, the actual profile needs to be defined as part of a YANG model or an augmentation of the existing PTP YANG model. Specifically, RFC 8575 says:
   -  A profile standard based on IEEE Std 1588-2008 may create a
      dedicated YANG module for its profile.  The profile's YANG module
      SHOULD use YANG "import" to import the IEEE Std 1588-2008 YANG
      module as its foundation.  Then the profile's YANG module SHOULD
      use YANG "augment" to add any profile-specific enhancements.
   -  A product that conforms to a profile standard may also create its
      own YANG module.  The product's YANG module SHOULD "import" the
      profile's module, and then use YANG "augment" to add any product-
      specific enhancements.
Where is the work of defining this new profile being done?

Section 15, paragraph 3
>    The IEEE 1588 standard requires that all PTP Profiles provide the
>    following identifying information.
> 
>              PTP Profile:
>              Enterprise Profile
>              Version: 1.0
>              Profile identifier: 00-00-5E-00-01-00
> 
>              This PTP Profile was specified by the IETF
> 
>              A copy may be obtained at
>              https://datatracker.ietf.org/wg/tictoc/documents

I am not an expert in how different profiles are maintained, but is there a common registry where one can go to look for all profiles defined for PTP? For example, I see ITU has define Telecom Profile G8275.1 and G8275.2, and here we have a Enterprise Profile. Are there other profiles? Does it make sense to define a registry? In IANA?

At the same time, I realize that it is not this documents responsibility to collect all the profiles, but creating a registry might enable profiles to be registered in one location.

Section 18, paragraph 2
>    PTP native management messages SHOULD NOT be used, due to the lack of
>    a security mechanism for this option.  Secure management can be
>    obtained using standard management mechanisms which include security,
>    for example NETCONF NETCONF [RFC6241].
In general, the document should refer to both NETCONF and RESTCONF[RFC8040]; the latter also provides a secure mechanism to distribute management information.

This document uses the RFC2119 keywords "SHALL NOT", "RECOMMENDED", "SHALL",
"MAY", "NOT RECOMMENDED", "SHOULD NOT", "SHOULD", "MUST NOT", "MUST",
"REQUIRED", and "OPTIONAL", but does not contain the recommended RFC8174
boilerplate. (It contains some text with a similar beginning.)

The IANA review of this document seems to not have concluded yet.

Possible DOWNREF from this Standards Track doc to [IEEE1588g]. If so, the IESG
needs to approve it.

Possible DOWNREF from this Standards Track doc to [IEEE1588]. If so, the IESG
needs to approve it.

Found terminology that should be reviewed for inclusivity; see
https://www.rfc-editor.org/part2/#inclusive_language for background and more
guidance:

 * Term "master"; alternatives might be "active", "central", "initiator",
   "leader", "main", "orchestrator", "parent", "primary", "server"
 * Term "slave"; alternatives might be "follower", "peripheral", "replica",
   "responder", "secondary", "standby", "worker"
 * Term "traditional"; alternatives might be "classic", "classical", "common",
   "conventional", "customary", "fixed", "habitual", "historic",
   "long-established", "popular", "prescribed", "regular", "rooted",
   "time-honored", "universal", "widely used", "widespread"
 * Term "native"; alternatives might be "built-in", "fundamental", "ingrained",
   "intrinsic", "original"

Found IP block or address not inside RFC5737/RFC3849 example ranges:
"224.0.1.129".

-------------------------------------------------------------------------------
NIT
-------------------------------------------------------------------------------

All comments below are about very minor potential issues that you may choose to
address in some way - or ignore - as you see fit. Some were flagged by
automated tools (via https://github.com/larseggert/ietf-reviewtool), so there
will likely be some false positives. There is no need to let me know what you
did with these suggestions.

Duplicate normative references to: https://www.ieee.org.

Section 3, paragraph 13
> randmaster of a PTP system, or as a back up to a Grandmaster. * PTP: The Prec
>                                     ^^^^^^^
When "back-up" is used as a noun or modifier, it needs to be hyphenated.

Section 3, paragraph 21
> sm for PTP timeReceivers to establish a unicast communication with PTP timeTr
>                                       ^
Use "an" instead of "a" if the following word starts with a vowel sound, e.g.
"an article", "an hour".

Section 3, paragraph 26
>  range from 100 microseconds to 1 nanoseconds to the Grandmaster. This PTP P
>                                 ^^^^^^^^^^^^^
Please verify that the plural noun "nanoseconds" is in agreement with the
quantifier "1". Did you mean to use the singular form?

Section 4, paragraph 1
> ich is only relevant to one device as a unicast message. The latter can be e
>                                       ^
Use "an" instead of "a" if the following word starts with a vowel sound, e.g.
"an article", "an hour".

Section 7, paragraph 1
> r the number of UTC leap seconds. If a unicast negotiation signaling message
>                                      ^
Use "an" instead of "a" if the following word starts with a vowel sound, e.g.
"an article", "an hour".

Section 9, paragraph 1
> , a Transparent Clock MUST NOT change a unicast message to a multicast messa
>                                       ^
Use "an" instead of "a" if the following word starts with a vowel sound, e.g.
"an article", "an hour".

Section 9, paragraph 2
> is not set to All 1s, MUST be sent as a unicast message. Similarly, if any s
>                                       ^
Use "an" instead of "a" if the following word starts with a vowel sound, e.g.
"an article", "an hour".

Section 14, paragraph 1
> or PTP? For example, I see ITU has define Telecom Profile G8275.1 and G8275.
>                                    ^^^^^^
It appears that the past participle should be used here.

Section 14, paragraph 1
> G8275.1 and G8275.2, and here we have a Enterprise Profile. Are there other p
>                                       ^
Use "an" instead of "a" if the following word starts with a vowel sound, e.g.
"an article", "an hour".

Section 14, paragraph 1
> s later been converted manually into xml format using an xml2rfc template. 1
>                                      ^^^
File types are normally capitalized.

Section 14, paragraph 1
> verted manually into xml format using an xml2rfc template. 17. IANA Consider
>                                       ^^
Use "a" instead of "an" if the following word doesn't start with a vowel sound,
e.g. "a sentence", "a university".

# Orie Steele, ART AD, comments for draft-ietf-tictoc-ptp-enterprise-profile-26 
CC @OR13

https://author-tools.ietf.org/api/idnits?url=https://www.ietf.org/archive/id/draft-ietf-tictoc-ptp-enterprise-profile-26.txt&submitcheck=True

I agree with the comments from Deb Cooley regarding framing of normative language.

## Comments

### Grandmaster term

```
157	   *  Best timeTransmitter: A clock with a PTP Port in the
158	      timeTransmitter state, operating as the Grandmaster of a PTP
159	      domain.
```

Does IEEE1588g define an alternative term for Grandmaster?

Given the other terminology changes, perhaps `primaryTimeTransmitter`, is a better term to use.

Later, the term `Preferred timeTransmitter` is used, is a "Preferred timeTransmitter" always a "primary timeTransmitter Clock within a domain of a PTP system". It seems odd to have the concept of a "preferred primary..." that is a backup... is the alternate timeTransmitter flag set when the "Preferred timeTransmitter" is a backup?

Consider defining Grandmaster cluster as well, given the term appears later:

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

### How to operate in the presence of a rogue timeTransmitter?

```
429	   timeTransmitters in their clock control subsystems.  TimeReceiver
430	   Clocks MUST be able to operate properly in the presence of a rogue
431	   timeTransmitter.  TimeReceivers SHOULD NOT Synchronize to a
```

Its not clear to me how to comply with this MUST, based on the surrounding context.
Perhaps there is a citation that could be given for to answer the question of "how?".

## Nits

### aloted -> alloted

```
357	   Section D.3.  These addresses are aloted by IANA, see the Ipv6
```

### ensembled -> assembled

```
373	   Domain.  Redundant sources of timing can be ensembled, and/or
```

ensembled is ok, but a more common word might be easier to comprehend for most readers. 

### syntonize -> synchronize

```
456	   Clocks which syntonize to the timeTransmitter Clock might need to
```

        This PTP Profile MUST operate only in networks characterized by UDP

What does "networks characterized by UDP" mean? My home network sees a lot
more TCP than UDP. Is it still "characterized by UDP" ?



        A copy may be obtained at
          https://datatracker.ietf.org/wg/tictoc/documents

Shouldn't this be pointing to https://datatracker.ietf.org/doc/rfcXXXX/
with a note to the RFC Editor to update XXXX ?


The Acknowledgement Section should move to after the IANA Considerations and
Security Considerations section (although I understand the author's desire to express
their pain using the tools they used)

Thank you to Susan Hares for the GENART review.

Thanks for addressing my DISCUSS and COMMENT feedback.

** Section 15. 
             A copy may be obtained at
             https://datatracker.ietf.org/wg/tictoc/documents

Per using “https://datatracker.ietf.org/wg/tictoc/documents “ for “sourceIdentification, the IEEE guidance says: "This attribute shall be a URL, e-mail, or regular mail address to which inquiries concerning the profile or requests for copies may be sent.” Consider using the WG mailing list.  I understand that the WG is being shutdown, but I would imaging the responsible AD will keep the list open.

# Éric Vyncke, INT AD, comments for draft-ietf-tictoc-ptp-enterprise-profile-26

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.

This seems like what RFC 2026 defines as an Applicability Statement.  Should it say so explicitly?

NTP in the Abstract could use a reference to its RFC.

The SHOULD in Section 5 is bare.  When might an implementer legitimately decide to deviate from the advice given there?  Or maybe MUST is better?

The first SHOULD in Section 9 seems to me to be redundant to the MUST that precedes it.

Is the SHOULD in Section 10 a restatement of the SHOULD in the last paragraph of Section 6?

Thank you very much for writing this document - I found it an interesting read.

Also, much thanks to Tim Chown for their excellent Ops-Dir review (https://datatracker.ietf.org/doc/review-ietf-tictoc-ptp-enterprise-profile-24-opsdir-lc-chown-2024-03-07/), and to the authors for addressing the comments; I think that there is still one remaining unaddressed comment ("In practice, would PTP operate over just one or the other, or might messages be duplicated in each protocol?  How does the profile look for a dual-stack environment?").

Thanks for working on this specification. 

I have following comments which I believe would help improving document when addressed -

 # Please define Grandmaster more precisely and consistently. In the introduction is says - Grandmaster = active reference time source and in the terminology section is says Grandmaster =  primary timeTransmitter Clock. lets decide which one it is. I am also wondering why we are using the term "Grandmaster". The term "primary reference timeTransmitter" would it clear about the role, why do we need to hide it? (And while the goal is to use inclusive language - GrandMASTER has a master in it.)

 # What are "Grandmaster Clusters" and how do we interpret "NOT ALLOWED"?