Re: [ippm] Working Group Last Call: draft-ietf-ippm-ioam-data

[Barak Gafni <[e-mail]>]

PSB under [BG]

Thanks,
Barak

From: Frank Brockners (fbrockne) <[e-mail]>
Sent: Tuesday, January 21, 2020 5:54 AM
To: Barak Gafni <[e-mail]>; Tommy Pauly <tpauly=[e-mail]>; IETF IPPM WG <[e-mail]>
Subject: RE: [ippm] Working Group Last Call: draft-ietf-ippm-ioam-data

Barak,

Thanks. Please see inline ("...FB").

From: ippm <[e-mail]<mailto:[e-mail]>> On Behalf Of Barak Gafni
Sent: Dienstag, 21. Januar 2020 08:33
To: Tommy Pauly <tpauly=[e-mail]<mailto:tpauly=[e-mail]>>; IETF IPPM WG <[e-mail]<mailto:[e-mail]>>
Subject: Re: [ippm] Working Group Last Call: draft-ietf-ippm-ioam-data

Hi,
Few comments to consider:

  1.  Queue depth format - In order to align the standardization of units across the route, as done for time measurements for example, I would suggest to direct implementations towards reporting Bytes, rather than keeping it open for interpretation by the implementors.
...FB: As you know, the original rationale used throughout IOAM is to avoid forcing the data producer (e.g. the forwarding ASIC) to translate a counter into a specific unit, which could be costly. One would rather do the transformation on the receiver of the data than on the sender of the data. At this point you'd probably argue that for time, we also specify the format/unit - though for time, we have 3 options available, and one of which is expected to be supported by the source natively, hence the "exception".
[BG] Agree, forcing this reporting method may be too much for some implementation that we don't want to prevent from supporting IOAM. Hence, my suggestion is to use SHOULD, which can drive better interoperability going forward without prevent current implementations from being compatible.

  1.  Additional measurements to consider - amount of Bytes transmitted by a port, rate of transmission of a port.
...FB: The data fields currently defined in the draft are considered a "baseline" - i.e. a set that everyone agrees with. We all know there have been proposals for other data fields in the past - but those proposals never got broader momentum. One can always leverage the opaque state snapshot to carry deployment specific data. So in order to add those two additional data fields to the draft at this stage, we'd need to get a good understanding of how common the need for the two additional data fields is. Who else would see a need? What would be the use-cases?
[BG] Would be great to have the list further comment on that

Thanks, Frank

Thanks,
Barak

From: ippm <[e-mail]<mailto:[e-mail]>> On Behalf Of Tommy Pauly
Sent: Tuesday, January 7, 2020 8:48 AM
To: IETF IPPM WG <[e-mail]<mailto:[e-mail]>>
Subject: [ippm] Working Group Last Call: draft-ietf-ippm-ioam-data

Hello IPPM,

Happy New Year! This email starts a working group last call for "Data Fields for In-situ OAM" (https://datatracker.ietf.org/doc/draft-ietf-ippm-ioam-data/<https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-ippm-ioam-data%2F&data=02%7C01%7Cgbarak%40mellanox.com%7C03abe451ab064dba268608d79e7952b8%7Ca652971c7d2e4d9ba6a4d149256f461b%7C0%7C0%7C637152116230294920&sdata=V8DCZz%2ByMeocyFRBX6gSzYYd5n0EdO%2FZPGWqnkqHguc%3D&reserved=0>).

The last call will end on Tuesday, January 21.. Please reply to [e-mail]<mailto:[e-mail]> with your reviews and comments. Please indicate whether you think this document is ready for publication.

Best,
Tommy (as co-chair)