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> wrote:

> PSB under [BG]
>
>
>
> Thanks,
>
> Barak
>
>
>
> *From:* Frank Brockners (fbrockne) <fbrockne@cisco.com>
> *Sent:* Tuesday, January 21, 2020 5:54 AM
> *To:* Barak Gafni <gbarak@mellanox.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
>
>
>
> Barak,
>
>
>
> Thanks. Please see inline (“…FB”).
>
>
>
> *From:* ippm <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>; IETF IPPM WG <
> 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> *On Behalf Of *Tommy Pauly
> *Sent:* Tuesday, January 7, 2020 8:48 AM
> *To:* IETF IPPM WG <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%7C03abe451ab064dba268608d79e7952b8%7Ca652971c7d2e4d9ba6a4d149256f461b%7C0%7C0%7C637152116230294920&sdata=V8DCZz%2ByMeocyFRBX6gSzYYd5n0EdO%2FZPGWqnkqHguc%3D&reserved=0>
> ).
>
>
>
> The last call will end on *Tuesday, January 21*... Please reply to
> 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
> https://www.ietf.org/mailman/listinfo/ippm
>