Subject: Re: [mpls] AD review of daft-ietf-mpls-loss-delay

From: Huub van Helvoort <[email-masked]>
Date: Thu, 02 Jun 2011 12:17:07 +0200

Hello Adrian,

You commented:

> ---
>
> 2.9.11
>
>     There are two significant timestamp formats in common use: the
>     timestamp format of the Internet standard Network Time Protocol
>     (NTP), described in [RFC5905], and the timestamp format used in the
>     IEEE 1588 Precision Time Protocol (PTP) [IEEE1588].
>
> Please avoid the word "standard" as RFC 5905 is not an Internet
> Standard. Suggest you delete "Internet standard" without any loss of
> meaning.
>
> Can you please add to this section some text such as...
>
>     To ensure interop it is necessary that support of at least one
>     format is mandatory. This specification requires the support of
>     the PTP format as discussed in Section 3.4 and Appendix A.
>
> ---

Would it be possible to mix the two timestamp formats?
In case of "dyadic" measurements the operator at A can use one
timestamp format while the operator at B can use the other format.

Regards, Huub.

-- 
*****************************************************************
                          我爱外点一七三一

---

From: Alexander Vainshtein <[email-masked]>
Date: Thu, 2 Jun 2011 14:52:45 +0300

Huub,
I've raised this issue with the authors already. IMHO and FWIW:

(a) For 2-way delay measurements disparate timestamp formats are a non-issue since all that is required is the ability to compute differences between two timestamps in the same format for both formats, and this computation does not have to be done in real-time.

(b) For 1-way delay measurements disparate timestamp formats are a minor implementation issue: while ability to compute the difference between two timestamps in different formats is required, there is still no need to do this computation in real time. 

Based on this I've claimed that there is no need to define the default timestamp format, but the authors did not agree even if they have, to the best of my  recollection, accepted (a) and (b).

Aside==> This case is very much different from the case of  mixed MPLS-TP identifiers: 
different timestamp formats represent the same reality (absolute time).

Regards,
     Sasha

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Huub van Helvoort
> Sent: Thursday, June 02, 2011 1:17 PM
> To: [email-masked]
> Cc: [email-masked]
> Subject: Re: [mpls] AD review of daft-ietf-mpls-loss-delay
> 
> Hello Adrian,
> 
> You commented:
> 
> > ---
> >
> > 2.9.11
> >
> _______________________________________________
> mpls mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mpls

This e-mail message is intended for the recipient only and contains information which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have received this transmission in error, please inform us by e-mail, phone or fax, and then delete the original and all copies thereof.

---

From: Dan Frost <[email-masked]>
Date: Fri, 03 Jun 2011 11:25:44 +0100

Hi Adrian,

Thanks for the review.  The authors have made these changes in -03
following the review comments:

* Add reference to draft-ietf-mpls-tp-loss-delay-profile

* Clarify scope of Message Length field and size of counter/timestamp
  fields

* Clarify that error response codes imply invalid measurement data

* Replace "Implementation-specific" TLV slots with a single slot for
  experimental use

* s/Reserved/Unallocated/ in TLV range list

* Clarify positional constraints of padding TLVs

* Fix IEEE 1588 version references

* Revise security considerations

* Minor editorial fixes

-d

---

From: Dan Frost <[email-masked]>
Date: Fri, 3 Jun 2011 11:39:37 +0100

Huub,

> timestamp format while the operator at B can use the other format.

Yes, it is possible.  The draft explains how multiple formats can
coexist in the same message.

-d

---

From: Stewart Bryant <[email-masked]>
Date: Fri, 03 Jun 2011 11:48:45 +0100

Sasha

Whilst we have the ability to interwork TS formats it is not as simple
as operating with a common format, and thus we believe that
the specification of a default is of benefit to both the network
operator and the vendor. If nothing else it useful in providing
guidance on the time distribution protocol that is currently
considered to provide the higher accuracy.

Stewart

---

From: Dan Frost <[email-masked]>
Date: Fri, 3 Jun 2011 11:51:03 +0100

Hi Sasha,

On Thu, Jun 02, 2011 at 02:52:45PM +0300, Alexander Vainshtein wrote:
> (a) For 2-way delay measurements disparate timestamp formats are a
> non-issue since all that is required is the ability to compute
> differences between two timestamps in the same format for both
> formats, and this computation does not have to be done in real-time.
> 
> (b) For 1-way delay measurements disparate timestamp formats are a
> minor implementation issue: while ability to compute the difference
> between two timestamps in different formats is required, there is
> still no need to do this computation in real time. 
> 
> Based on this I've claimed that there is no need to define the default
> timestamp format, but the authors did not agree even if they have, to
> the best of my recollection, accepted (a) and (b).

We agree that things could be made to work by making further format
reconciliation requirements of implementations rather than mandating a
default.  But as we discussed, we think it is important to provide
guidance to hardware implementors as to the preferred format to support,
and consensus from the timing people at present is that 1588 is
preferred.

Cheers,
-d

> Aside==> This case is very much different from the case of  mixed
> MPLS-TP identifiers: different timestamp formats represent the same
> reality (absolute time).
> 
> Regards,
>      Sasha