Hi Shahram, I guess adding a requirement to take timestamp rollover into account would do. If there is a strong reason to also leave NTP timestamp as an option, a note explaining the ramification of leap seconds should be added. I suggest that a continuous timescale (i.e. PTP) would be selected in the draft as the default/must option. Best, Ron
On Thu, Mar 3, 2011 at 9:45 PM, Shahram Davari <[email protected]> wrote: > 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]> 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]" > tictoc-bounces@ie <[email protected]>, > tf.org "[email protected]" <[email protected]> > cc > "[email protected]" <[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]] On Behalf > Of > Stewart Bryant > Sent: Thursday, March 03, 2011 8:07 AM > To: [email protected] > Cc: [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] > https://www.ietf.org/mailman/listinfo/tictoc > > > _______________________________________________ > TICTOC mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/tictoc > > >
_______________________________________________ TICTOC mailing list [email protected] https://www.ietf.org/mailman/listinfo/tictoc
