Subject: Re: [ippm] Proposed modification to draft-ietf-ippm-ioam-data-00

From: John Lemon <[email-masked]>
Date: Tue, 7 Nov 2017 11:19:47 -0800

Yes, it is possible to calculate ETE delay by having every intermediate
node calculate the per-hop delay and adding them all up. However, this is
not always possible, takes more computation time, takes more packet space,
and is unnecessary when all one wants is the end-to-end delay.

I agree that NTP does not usually provide as much precision as desired.
However, I am also aware that there are many enterprises that run NTP and
do not run PTP. They would like to be able to take advantage of NTP
timestamps, which in their case are better than nothing.

I also agree that we need an indication of which timestamp time was chosen.
I think it was a mistake to try to use the same fields for both PTP and NTP
timestamps. I'll modify my proposal to have these use different code points.

Thanks,
John Lemon

On Wed, Oct 18, 2017 at 7:00 PM, Mickey Spiegel <
[email-masked]> wrote:

>
> On Fri, Oct 6, 2017 at 8:08 AM, John Lemon <[email-masked]>
> wrote:
>
>> Not having heard any comments on the proposals indicated in the attached
>> message, can I assume that no one objects to these?
>>
>
> Timestamp is included in the IOAM Trace Option for the following reason,
> quoting from draft-ietf-ippm-ioam-data-00:
>
> This fields allows for delay computation between any two nodes in the network when the nodes are time synchronized.
>
>
> While NTP is a great mechanism to synchronize application clocks and
> control plane driven events such as SNMP, syslog, or traps, it does not
> provide enough precision for data plane delay computations. The mechanisms
> defined in IOAM Trace should provide accurate performance monitoring in
> terabit network environments for modern data centers, where end-to-end
> latency tends to be in tens of nanoseconds. This requires time
> synchronization precision of the same order.
>
>
> A couple of other observations regarding the proposed changes:
>
> 1. There is no indication in the packet whether the timestamp subseconds
> field is in nanoseconds or fractional seconds.
>
> 2. While there is a proposed change to the timestamp subseconds field,
> there is no proposed change to the transit delay which remains in
> nanoseconds.
>
> Mickey
>
>
>>
>> Thank you for your consideration,
>> John Lemon
>>
>>
>>
>> On Thu, Sep 21, 2017 at 4:06 PM, John Lemon <[email-masked]>
>> wrote:
>>
>>> Greetings,
>>>
>>> We would like to propose two simple changes
>>> to draft-ietf-ippm-ioam-data-00.
>>>
>>> Change 1: Extend the timestamp to allow it to support both PTP and NTP.
>>> The seconds portion would remain largely as is, although the seconds would
>>> obviously use different epochs, depending upon which type of timestamp is
>>> used within the in-situ OAM domain. The datatype currently named
>>> nanoseconds would be renamed to subseconds and would either carry
>>> nanoseconds or fractional seconds, for PTP or NTP, respectively.
>>>
>>> Change 2: Add a few Edge-To-Edge data types. In addition to the
>>> currently defined 64-bit sequence number, it would be handy to be able to
>>> send a sequence number taking up only 32 bits. And it would be useful to be
>>> able to measure delay (and delay variation) across the entire path, without
>>> having to use the Hop-By-Hop timestamps to measure at every node in the
>>> path.
>>>
>>> These two changes have been incorporated into a proposed modification of
>>> the XML source at GitHub, as indicated by this pull request:
>>> https://github.com/inband-oam/ietf/pull/57
>>>
>>> An XML2RFC output of the ID with the proposed changes is also attached.
>>>
>>> Thank you for your consideration,
>>> John Lemon
>>> Shahram Davari
>>> Rajeev Manur
>>>
>>
>>
>> _______________________________________________
>> ippm mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/ippm
>>
>>
>