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

[Greg Mirsky <[e-mail]>]

Thank you, Brian, for your constructive comments and suggestions. I've
uploaded the new version with updates that reflect our discussion.

Best regards,
Greg

On Fri, May 19, 2023 at 11:33 AM Brian Haberman <[e-mail]>
wrote:

> Hi Greg,
>       I am fine with that language.
>
> Regards,
> Brian
>
> On 5/15/23 4:24 PM, Greg Mirsky wrote:
> > Hi Brian,
> > thank you for your suggestion. The following text is proposed for Section
> > 3.1 (after the definitions of QTF and RTF):
> > NEW TEXT:
> >     The sender of the BIER Echo Request might receive the BIER Echo Reply
> >     with RTF different from the Sender's QTF, Thus, the Sender MUST be
> >     able to interpret both timestamp formats, i.e., NTP [RFC5905] and PTP
> >     [IEEE.1588.2008].
> >
> > Please let me know if this addresses your concern.
> >
> > Regards,
> > Greg
> >
> > On Thu, May 11, 2023 at 2:14 PM Brian Haberman <[e-mail]
> >
> > wrote:
> >
> >> Hey Greg,
> >>        Given that the QTF and RTF fields call out those standards, I
> >> would be hard pressed to see how they aren't requirements. May be worth
> >> asking your AD.
> >>
> >> Brian
> >>
> >> On 5/11/23 4:34 PM, Greg Mirsky wrote:
> >>> 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
> >>>>
> >>>>
> >>>
> >>
> >
>