Hi Ron, Although the PTPv2 is 80 bytes, but I don't see a need to use all 80 bytes for delay measurement. The upper 2^32 seconds covers almost 136 years, which should be good enough to measure delay. Also lets' be compatible with Y.1731 format since that HW already exist.
Thx Shahram From: Ron Cohen [mailto:[email protected]] Sent: Thursday, March 03, 2011 11:22 AM To: [email protected] Cc: Shahram Davari; [email protected]; [email protected]; [email protected] Subject: Re: [TICTOC] draft-ietf-mpls-loss-delay Timestamp Hi, I apologize in advance if my comments below where already been discussed. The draft specify using PTPv1 timestamp format and not PTPv2 timestamp format. The seconds part of the PTPv2 timestamp is 48bits, and not 32bits as written in the draft. NTP timestamps will roll over in 2036. PTPv2 timestamps do not rollover. I don't think its advisable to include timestamps that rolls over ~20 years from now. In addition, NTP timestamp, unlike PTP timestamp, 'jumps' in leap seconds events. This makes calculation of time differences hard, and would render some measurements ambiguous. It is much easier to use continuous timescale like PTP. In my opinion changing the timestamp format to PTPv2 timestamp format (i.e. 48bit/32bit sec/ns) should be the right way to go. I would also remove the NTP timestamp format option to avoid leap seconds confusion and 2036 rollover events. Best, Ron On Thu, Mar 3, 2011 at 8:26 PM, <[email protected]<mailto:[email protected]>> wrote: My feeling is 1588 is the right answer in the long run since it is already coupled to the hardware and widely deployed in networks using the "packet clock derived time" in precise time and frequency delivery. Pat "Shahram Davari" <davari@broadcom. com> To Sent by: "[email protected]<mailto:[email protected]>" tictoc-bounces@ie <[email protected]<mailto:[email protected]>>, tf.org<http://tf.org> "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>> cc "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>> 03/03/2011 10:05 Subject AM Re: [TICTOC] draft-ietf-mpls-loss-delay Timestamp Hi Stewart, Accurate delay measurement requires the Timestamp to be done in HW. It is true that most routers support NTP today, but the majority of those are really maintained in Software and AFAIK most HW based timestamps implementations are 1588 based and really the industry is shifting toward 1588 and SyncE for network synchronization. So I support 1588 as being the default. Thanks, Shahram From: [email protected]<mailto:[email protected]> [mailto:[email protected]<mailto:[email protected]>] On Behalf Of Stewart Bryant Sent: Thursday, March 03, 2011 8:07 AM To: [email protected]<mailto:[email protected]> Cc: [email protected]<mailto:[email protected]> Subject: [TICTOC] draft-ietf-mpls-loss-delay Timestamp 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]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/tictoc _______________________________________________ TICTOC mailing list [email protected]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/tictoc
_______________________________________________ TICTOC mailing list [email protected] https://www.ietf.org/mailman/listinfo/tictoc
