Re: [Int-dir] Intdir early review of draft-ietf-bier-ping-08

[Greg Mirsky <[e-mail]>]

Hi Brian,
thank you for the suggestion. I agree, it is reasonable to recommend that a
system is able to interpret both timestamp formats. Would you agree to make
that a recommendation rather than a requirement?

Regards,
Greg

On Thu, May 11, 2023 at 1:15 PM Brian Haberman <[e-mail]>
wrote:

> Hey Greg,
>
> On 5/11/23 3:06 PM, Greg Mirsky wrote:
> >
> >>
> >>>> 2. Section 3.1
> >>>>
> >>>>       * It is unclear if the two header formats described here both
> >> occur in
> >>>> a
> >>>>       transmitted frame or if the second header format is a modified
> >> version
> >>>> of
> >>>>       the first header. If it is the former, it seems odd to have to
> >>>> duplicate
> >>>>       versions, message type, protocol, and reserved fields.
> >>>>
> >>> GIM>> Thank you for pointing that out. Indeed, these are the same. I've
> >>> updated the figures. Please let me know if it helped to make the text
> >>> clearer.
> >>>
> >>>>
> >>>>        * Is there a requirement that the timestamp formats be the
> same in
> >>>> both
> >>>>        the Echo Request and the Echo Reply? If not, is there a
> >> requirement
> >>>> that
> >>>>        BFRs MUST support both formats?
> >>>>
> >>> GIM>> A good question. I believe that there is no requirement for the
> >>> Sender and Responder to use the same timestamp format, as the format
> used
> >>> can be explicitly indicated for each actor separately. As a result, a
> BFR
> >>> can support one format or both. The decision of which one to use may be
> >>> based on the comparison of the accuracy of the timestamp each method
> >>> provides.
> >>>
> >>
> >> Any concerns with routers not supporting/recognizing all specified
> >> timestamp formats?
> >>
> > GIM2>> RFC 8877  <https://datatracker.ietf.org/doc/rfc8877/>provides an
> > excellent analysis of timestamp formats being used in known networking
> > protocols:
> >
> >     - NTPv4 64-Bit Timestamp Format (RFC 5905)
> >     - NTPv4  32-Bit Timestamp Format (RFC 5905)
> >     - The PTPv2 64-Bit Truncated Timestamp Format
> >
> > It seems like the situation where a networking system doesn't support
> > either NTPv4 or PTPv2 format is highly unlikely. WDYT?
>
> I am aware of existing systems that support the NTP formats, but not the
> PTP ones (they don't do PTP). However, as this soon-to-be-RFC will
> require updates to systems, I would suggest putting in language
> requiring support for those formats. Given that supporting the PTPv2
> format does not require support for PTP, that seems pretty reasonable.
>
> Brian
>
>