Re: [TICTOC] NSH Timestamp

[Tal Mizrahi <[e-mail]>]

Hi Rory,

Thanks for the detailed response.

A few follow-up questions/comments:


>1.      The draft currently does not clarify the use case. While the draft
>describes how the timestamp is inserted into the NSH, I could not find a
>description of how the timestamp is *used*, and what is the expected
>accuracy. It is hard to assess whether the solution is adequate without
>understanding the requirement.
>
>RB: We want to be able to tell if a VNF or and underlay segment is
>misbehaving on subscriber traffic. Expected accuracy in the low 10s of
>microseconds.

10s of microsecond: do you see this as a requirement, or is it a best practice based on what common IEEE 1588 equipment can provide?
Can you please give a short example that explains why 10s of microseconds is necessary?
I would strongly recommend to add a section in the draft (preferably at the beginning) that would describe these use cases and accuracy requirements in detail.


>.        Could you explain why you require very accurate frequency
>synchronization, but inaccurate time synchonization (section 3.1)?
>
>RB: The time of day used at the start of the header does not have to be very
>accurate (Can be 10's of ms out for example) the PTP needs to me more
>accurate (in 10s of microsecond range)

- Can you please clarify this point: what is the difference between how the timestamp-at-the-start-of-the-header is used and how the other timestamps are used?
- PTP provides the time-of-day with a microsecond accuracy, so why would we need an additional less accurate time reference?


>
>.        The format of the fields "UTC Reference", "Ingress Timestamp", and
>"Egress Timestamp" is not clear.
>RB: Can you explain
>

Based on your response, I understand that <UTC Reference> uses the NTP 64-bit timestamp format.
Is the same format used also for <Ingress Timestamp> and <Egress Timestamp>? This should be defined explicitly in the draft.



Cheers,
Tal.