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

From: John Lemon <[email-masked]>
Date: Fri, 6 Oct 2017 08:08:16 -0700

Not having heard any comments on the proposals indicated in the attached
message, can I assume that no one objects to these?

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
>

---

From: Haoyu song <[email-masked]>
Date: Fri, 6 Oct 2017 17:39:29 +0000

I think these are reasonable proposals. These use cases highlight the potential needs for more data types in the future. Soon we’ll used up all the reserved bits. We have proposed a general way  to extend it (https://tools.ietf.org/html/draft-song-ippm-ioam-scalability-01) and if you come up with new and better ideas, we can surely incorporate them in.

Haoyu

From: ippm [mailto:[email-masked]] On Behalf Of John Lemon
Sent: Friday, October 06, 2017 8:08 AM
To: [email-masked]
Cc: Rajeev Manur <[email-masked]>
Subject: Re: [ippm] Proposed modification to draft-ietf-ippm-ioam-data-00

Not having heard any comments on the proposals indicated in the attached message, can I assume that no one objects to these?

On Thu, Sep 21, 2017 at 4:06 PM, John Lemon <[email-masked]<mailto:[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

---

From: Mickey Spiegel <[email-masked]>
Date: Wed, 18 Oct 2017 19:00:00 -0700

> 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

> _______________________________________________
> ippm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ippm
>
>

---

From: J Ignacio Alvarez-Hamelin <[email-masked]>
Date: Fri, 20 Oct 2017 10:38:22 -0300

It is an interesting point. NTP normally can assure some milliseconds in LAN or hundred of milliseconds in WAN networks. I think that OAM could also provide the synchronization method: NTP, TSCclock or other. This information would be useful to know when timestamps are or no significative upon the final application. 
I am working on a proposal that could provide 10 microseconds in WAN environments; I think that could be useful for IPPM.

Best,

Dr. Ing. José Ignacio Alvarez-Hamelin
_______________________________________________________________

CONICET and Facultad de Ingeniería, Universidad de Buenos Aires
Av. Paseo Colón 850 - C1063ACV - Buenos Aires - Argentina
+54 (11) 5285 0716 / 5285 0705
e-mail: [email-masked]
web: http://cnet.fi.uba.ar/ignacio.alvarez-hamelin/
_______________________________________________________________

> On Oct 18, 2017, at 11:00 PM, Mickey Spiegel <[email-masked]> wrote:
> 
> 
> 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.
> 
> 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
>  
>