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

[Brian Haberman <[e-mail]>]

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
>>
>>
>