We have received a LC comment on draft-ietf-mpls-loss-delay concerning
the default timestamp.
In the first version of the draft we proposed NTP, but following initial
comments from the MPLS-TP community we changed to IEEE1588. This
requirement for IEEE1588 can be traced back to the choice of using
IEEE1588 in Y.1731.
We have now received a LC request to change the default back to NTP.
NTP is the "natural" choice for an IETF protocol. NTP is specified in
IETF and is used in other MPLS protocols such as LSP ping. It is
implemented on almost every host and every router. However in general
the implementations provides a relatively low precision timestamp, and
the NTP time distribution infrastructure operates on a best effort
basis. Thus even a good client implementation would normally have a
relatively low quality path to the server, which would result in a low
quality of timestamp. NTP could be made to work to higher accuracy, but
defacto upgrading NTP and providing high quality NTP paths to the time
servers is not getting much attention. Computing timestamp differences
is easier with NTP.
On the other hand IEEE1588 has defacto become the two way time tranfer
protocol for precision applications. IEEE1588 only provides high quality
time in well engineered networks with some form of hop by hop
assistance. It is not widely implemented other than in equipment
targeted to specific markets, although one of those markets is in mobile
backhaul applications where we expect to see significant initial
deployment of MPLS-TP. Computing timestamp differences is harder with
IEEE1588
The loss-delay work is targeting to be able to do one way packet delay
measurement, so it does need a higher quality of timestamp than is
required in general purpose network instrumentation.
Converting from IEEE1588 to NTP is not trivial, since they use different
epochs, and different representations of sub-second time. In a
"traditional" NTP implementation the time error due to on the fly
conversion is likely to be small compared to the time error in the time
synchronization system, but an IEEE1588 system would need hardware
conversion to maintain the accuracy for an NTP timestamp.
So the question arises, should we make IEEE1588 or NTP the default for
draft-ietf-mpls-loss-delay. Much as I would like to suggest that we
should go back to NTP for consistency with other IETF protocols, I have
difficulty reconciling this with the situation in network deployments
and thus suggest that we continue to use IEEE1588.
What is the opinion of the working group?
Stewart (speaking as a draft editor)
_______________________________________________
TICTOC mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/tictoc
