Re: [mpls] [TICTOC] draft-ietf-mpls-loss-delay Timestamp

[Stewart Bryant <[e-mail]>]

I do not think that rollover or leap seconds are much of a problem in 
this application. We are measuring the transit time of a packet across a 
network. That is less than a second. Rollover or leap second errors mean 
that we make a mistake once in every 136 years in the first case and 
maybe never in the case of leap seconds. I am sure that it would be 
acceptable to simply state that for that for that one second at some 
time in the future we cannot make that measurement.

BTW we are only going to use 32 bits of seconds and 32 bits of sub 
seconds in the 1588 case, and even then most of the sub second bits will 
be ignored. I don't thing that we need to be measuring time of flight 
over 8" of  cable.

Stewart

On 03/03/2011 22:12, Shahram Davari wrote:
> Agree.
>
> Shahram
>
> ------------------------------------------------------------------------
> *From*: Ron Cohen <[e-mail]>
> *To*: Shahram Davari
> *Cc*: [e-mail] <[e-mail]>om>; [e-mail] 
> <[e-mail]>rg>; [e-mail] <[e-mail]>rg>; 
> [e-mail] <[e-mail]>
> *Sent*: Thu Mar 03 13:35:11 2011
> *Subject*: Re: [TICTOC] draft-ietf-mpls-loss-delay Timestamp
>
> 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 <[e-mail] 
> <mailto:[e-mail]>> 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:[e-mail]
>     <mailto:[e-mail]>]
>     *Sent:* Thursday, March 03, 2011 11:22 AM
>     *To:* [e-mail] <mailto:[e-mail]>
>     *Cc:* Shahram Davari; [e-mail] <mailto:[e-mail]>;
>     [e-mail] <mailto:[e-mail]>;
>     [e-mail] <mailto:[e-mail]>
>     *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, <[e-mail]
>     <mailto:[e-mail]>> 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:                  "[e-mail]
>     <mailto:[e-mail]>"
>                 tictoc-bounces@ie <[e-mail]
>     <mailto:[e-mail]>>,
>     tf.org <http://tf.org>                    "[e-mail]
>     <mailto:[e-mail]>" <[e-mail] <mailto:[e-mail]>>
>                                                                      
>          cc
>                                           "[e-mail]
>     <mailto:[e-mail]>" <[e-mail] <mailto:[e-mail]>>
>                 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: [e-mail] <mailto:[e-mail]>
>     [mailto:[e-mail] <mailto:[e-mail]>]
>     On Behalf Of
>     Stewart Bryant
>     Sent: Thursday, March 03, 2011 8:07 AM
>     To: [e-mail] <mailto:[e-mail]>
>     Cc: [e-mail] <mailto:[e-mail]>
>     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
>     [e-mail] <mailto:[e-mail]>
>     https://www.ietf.org/mailman/listinfo/tictoc
>
>
>     _______________________________________________
>     TICTOC mailing list
>     [e-mail] <mailto:[e-mail]>
>     https://www.ietf.org/mailman/listinfo/tictoc
>
>
>
> _______________________________________________
> mpls mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mpls


-- 
For corporate legal information go to:

http://www.cisco.com/web/about/doing_business/legal/cri/index.html