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

I believe that according to these comments we are converging towards agreement. “SHOULD” doesn’t preclude any implementation hence it keeps the RFC inclusive for devices that can’t align to Bytes. While as we all here for interoperability and simplicity of the designs, recommending the industry to align itself towards standard unit of measurement is desired from a standards body perspective. So I believe that it is aligned with your comments. As you denote, there are cases where standardization of units make sense, while it doesn’t hurt other cases.
In addition, from a personal observation, the market includes many kinds of ASICs implemented as part of switching and routing systems. Some ASIC vendors are reporting their ASIC “cell” sizes while some not, some system/NOS vendors report the ASIC they are using and some not. It may be hard in many environments to query the devices in order to know this data, and then process according. The suggested direction simplifies all this operational aspects when possible. And in the meanwhile, as stated above, doesn’t preclude current implementations.

Thanks,
Barak

From: Mickey Spiegel <mspiegel@barefootnetworks.com>
Sent: Tuesday, January 21, 2020 2:30 PM
To: Barak Gafni <gbarak@mellanox.com>
Cc: Frank Brockners (fbrockne) <fbrockne@cisco.com>; Tommy Pauly <tpauly=40apple.com@dmarc.ietf.org>; IETF IPPM WG <ippm@ietf.org>
Subject: Re: [ippm] Working Group Last Call: draft-ietf-ippm-ioam-data

Inline comments under [MS]

On Tue, Jan 21, 2020 at 11:09 AM Barak Gafni <gbarak@mellanox.com<mailto:gbarak@mellanox.com>> wrote:
PSB under [BG]

Thanks,
Barak

From: Frank Brockners (fbrockne) <fbrockne@cisco.com<mailto:fbrockne@cisco.com>>
Sent: Tuesday, January 21, 2020 5:54 AM
To: Barak Gafni <gbarak@mellanox.com<mailto:gbarak@mellanox.com>>; Tommy Pauly <tpauly=40apple.com@dmarc.ietf.org<mailto:40apple.com@dmarc.ietf.org>>; IETF IPPM WG <ippm@ietf.org<mailto:ippm@ietf.org>>
Subject: RE: [ippm] Working Group Last Call: draft-ietf-ippm-ioam-data

Barak,

Thanks. Please see inline (“…FB”).

From: ippm <ippm-bounces@ietf.org<mailto:ippm-bounces@ietf.org>> On Behalf Of Barak Gafni
Sent: Dienstag, 21. Januar 2020 08:33
To: Tommy Pauly <tpauly=40apple.com@dmarc.ietf.org<mailto:tpauly=40apple.com@dmarc.ietf.org>>; IETF IPPM WG <ippm@ietf.org<mailto:ippm@ietf.org>>
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.

[MS] There are several possible use cases for IOAM. Much of the initial work has been motivated by flow monitoring use cases, where switches and routers embed or export metadata relating to packets in a flow, at line rate for massively scaled data centers. At the receiver, typically the exported metadata is processed and analyzed in software. In such a scenario, in order to enable IOAM to work across as wide a range of devices as possible, it makes sense to use the design philosophy that Frank stated above: Allow the data producer to generate metadata in whatever units it wants, and normalize at the receiver where the exported metadata is processed and analyzed. For such use cases, I believe that standardization of units should not be a goal, not even as a recommendation.

[MS] There may be other use cases where standardization of units makes sense. Rather than constrain all use cases, my suggestion would be to define recommendations specific to such use cases, perhaps using the concept of profiles that Tal has proposed.

  1.  Additional measurements to consider – amount of Bytes transmitted by a port, rate of transmission of a port.

[MS] I support the addition of the amount of bytes transmitted by a port. However, I wonder whether this should be the amount of bytes transmitted on the entire port, or the amount of bytes transmitted using a specific queue on the port?

Mickey

  1.
…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 <ippm-bounces@ietf.org<mailto:ippm-bounces@ietf.org>> On Behalf Of Tommy Pauly
Sent: Tuesday, January 7, 2020 8:48 AM
To: IETF IPPM WG <ippm@ietf.org<mailto:ippm@ietf.org>>
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%7C978b1b54026b488140a808d79ec17cfe%7Ca652971c7d2e4d9ba6a4d149256f461b%7C0%7C0%7C637152426176952430&sdata=YM2cIQkJ7xtvqjq3vBdt%2BYW%2BU8cba2jtkjmzsDWw1QI%3D&reserved=0>).

The last call will end on Tuesday, January 21... Please reply to ippm@ietf.org<mailto:ippm@ietf.org> with your reviews and comments. Please indicate whether you think this document is ready for publication.

Best,
Tommy (as co-chair)
_______________________________________________
ippm mailing list
ippm@ietf.org<mailto:ippm@ietf.org>
https://www.ietf.org/mailman/listinfo/ippm<https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fippm&data=02%7C01%7Cgbarak%40mellanox.com%7C978b1b54026b488140a808d79ec17cfe%7Ca652971c7d2e4d9ba6a4d149256f461b%7C0%7C0%7C637152426176952430&sdata=S5HIOUimx8%2BSpw39LZnJWLE9gRO1rfazq%2F4WOHosQy8%3D&reserved=0>