Draft: draft-ietf-detnet-dp-sol-ip-00

Commentary: Aligned the Time Synchronization text with the MPLS equivalent text . Added an informative ref to RFC8169 Deleted ref to IEEE1588 as not needed Slightly reduced the width of  3 by deleting one column of spaces and " - " in the middle to stop the compile warning .
SB> This section should point the reader to RFC8169 (residence
time in MPLS n/w.  We need to consider if we need to introduce the
same concept in IP.
Agree.  For IP we could reference to PTPv2 or v3 over UDP/IP,
since it measures residence time among other things.
PTP packets can be sent either as DetNet flows or as high-priority
best effort packets.  Using DetNet for PTP packets requires
careful consideration to prevent unwanted interactions between
clock-synchronized network nodes and the packets that synchronize
the clocks.
PTP packets are sent as a normal DetNet flow through network nodes
that are not time-synchronized: in this approach PTP traffic is
forwarded as a DetNet flow, and as such it is forwarded in a way
that allows a low delay variation.  However, since intermediate
nodes do not take part in the synchronization protocol, this
approach provides a relatively low degree of accuracy.
PTP with on-path support: in this approach PTP packets are sent as
ordinary or as DetNet flows, and intermediate nodes take part in
the protocol as Transparent Clocks or Boundary Clocks IEEE1588.
The on-path PTP support by intermediate nodes provides a higher
degree of accuracy than the previous approach.  The actual
accuracy depends on whether all intermediate nodes are PTP-
capable, or only a subset of them.
Time-as-a-service: in this approach accurate time is provided as-
a-service to the DetNet source and destination, as well as the
intermediate nodes.  Since traffic between the source and
destination is sent over a provider network, if the provider
supports time-as-a-service, then accurate time can be provided to
both the source and the destination of DetNet traffic.  This
approach can potentially provide the highest degree of accuracy.
It is expected that the latter approach will be the most common one,
as it provides the highest degree of accuracy, and creates a layer
separation between the DetNet data and the synchronization service.
It should be noted that in all four approaches it is not recommended
to use replication and elimination for synchronization packets; the
replication/elimination approach may in some cases reduce the
synchronization accuracy, since the observed path delay will be
bivalent.
SB> I am not sure why we sould not use PREP.  We should explain to
the reader.
Agree that a this can be opened a bit more in detail.  The issue
is explained briefly in the last sentence but it could be more
clear.
Editor's Note: A detailed discussion of time synchronization is
outside the scope of this document, and the production of a
specialist text discussing this topic is encouraged.  This section
will be updated if such a documents is available before publication
of this text.
Time synchronization is important both from the perspective of
operating the DetNet network itself and from the perspective of
transferring time across the network between client applications.
Some clients may be able to use the DetNet as their provider of time
and frequency, others may require the DetNet to transfer time between
a client clock source and a client clock user.
The reader's attention is drawn to RFC8169 which describes a method
of recording the packet queuing time in an MPLS LSR on a packet by
per packet basis and forwarding this information to the egress edge
system.  This allows compensation for any variable packet queuing
delay to be applied at the packet receiver.  Whether a similar
mechanism needs to be defined for IP is for further study.  Such a
mechanism may have wider application than basic time transfer in a
DetNet.
A more detailed discussion of time synchronization is outside the
scope of this document.