Stewart, IMO a default serves two purposes:
1) A baseline everyone must implement 2) A reduction in the amount of additional configuration to get something working. NTP arguably covers (1) better because as the draft notes it has had wide deployment on the Internet. However I would think (and I'm no expert so may be wrong) that NTP has not generally been used for the sort of use cases that draft-ietf-mpls-loss-delay attempts to cover and I do not think it would provide the level of accuracy expected by Transport Network Operators. If NTP were the default then I would expect that in the majority of cases Transport Network Operators would immediately change from the NTP default to 1588. The one case I would think where maybe operators would stick with NTP is if their equipment cannot for some reason support 1588 but does support NTP. Even in those cases I expect the operator may well just choose to not use draft-ietf-mpls-loss-delay at all as measurements that aren't sufficiently accurate for a transport network operator could be considered worse than no measurements at all. So IMO 1588 covers (2) better and it is not a new protocol so 1588 has also seen quite a bit of deployment AFAIK. Therefore the only case where making NTP the default makes sense IMO is where it is felt that implementing 1588 is so burdensome that a significant proportion of equipment will exist that will only ever be capable of supporting NTP timestamps and that deployers of draft-ietf-mpls-loss-delay would accept the level of accuracy provided by NTP. I am not the right person to judge whether that would be the case but my gut tells me that it won't. So I'd vote for 1588 to be the default. Ben On 3 Mar 2011, at 16:06, Stewart Bryant wrote: > > 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) > > _______________________________________________ > mpls mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/mpls _______________________________________________ TICTOC mailing list [email protected] https://www.ietf.org/mailman/listinfo/tictoc
