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

[Brian Haberman <[e-mail]>]

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