Re: [ippm] draft-ietf-ippm-ioam-data and a new draft for IOAM flags

[Haoyu Song <[e-mail]>]

My comments below.

Haoyu

From: ippm <[e-mail]> On Behalf Of Frank Brockners (fbrockne)
Sent: Monday, July 08, 2019 4:42 AM
To: Tianran Zhou <[e-mail]>; [e-mail]
Cc: [e-mail]
Subject: Re: [ippm] draft-ietf-ippm-ioam-data and a new draft for IOAM flags

Hi Tianran,

Thanks for your comments. Per the WG discussion: "IOAM flags draft" (i.e. draft-mizrahi-ippm-ioam-flags-00) is not really a new draft, but it temporarily farms out the flags discussion that already existed in draft-ietf-ippm-ioam-data-05 into a dedicated document - so that we can finalize draft-ietf-ippm-ioam-data as quickly as possible. There isn't any new proposal in the flags draft. We intentionally did not change the contents - the objective was just to split the document.
In addition, the purpose of the flags draft is to motivate and define the flags, rather than detail procedures which would go beyond the definition of the flags. Those definitions could well live in dedicated documents (see more comments below). An evolved version of the postcard I-D that you refer to below - or probably a new focused I-D, could be such a more specific document.

Please also see inline...

From: Tianran Zhou <[e-mail]<mailto:[e-mail]>>
Sent: Freitag, 5. Juli 2019 04:32
To: Frank Brockners (fbrockne) <[e-mail]<mailto:[e-mail]>>; ippm@ietf..org<mailto:ippm@ietf..org>
Subject: RE: draft-ietf-ippm-ioam-data and a new draft for IOAM flags

Hi Frank,

Here are some comments on the IOAM flags:

1. Why proposing the "Immediate Exporting" when a new postcard option (https://datatracker.ietf.org/doc/draft-song-ippm-postcard-based-telemetry/<https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-song-ippm-postcard-based-telemetry%2F&data=02%7C01%7Chaoyu.song%40futurewei.com%7C67f6648f0a65476ae8dc08d7039b9174%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C636981839021779806&sdata=auZa6UADUGp7Gp3lS%2B03uluzABOKZ%2FPTdKnuRMvMKtk%3D&reserved=0>) is already proposed for IOAM? What's the difference for use?
One scenario may apply to this flag is to indicate the node to export all the existing tracing data when the node is not able to attach data. Other capable nodes will still trace and attach data. This may make the flag useful and different.

In addition, you mentioned to use the e2e option to assist the postcard. That may need an encapsulation extension to IPv6 HbH for e2e option.

...FB: draft-mizrahi-ippm-ioam-flags-00 already mentions the use of the IOAM E2E option with sequence number: "As a means to  support correlation of exported IOAM data different nodes in the network, a deployment could consider attaching an IOAM E2E option in  addition to the trace option, that includes a sequence number.".
[HS] As we have discussed before, I still think such statement should be dropped from the document. It complicates the operation, obscures the semantics, and make further extensions harder. I see no reason to support a hack like this when we have an explicit and dedicated option.
Having a dedicated document that expands on immediate export and the different types of use cases could be seen as beneficial. Section 3 of draft-song-ippm-postcard-based-telemetry-03 could be a starting point. A few things from my perspective that we still have to get sorted are:
* inclusion of the different "uses" of data created by immediate export. In his draft draft-bonica-6man-oam, Ron (cc'ed) documented a couple actions that a node could perform when doing immediate export, e.g. "1 - log the packet", "2 - count the packet", "3 - send ICMP to the source", "4 - send telemetry". We should add those to the new I-D.

[HS] We should have more discussion on this. If this is truly needed, it can be supported either by flags or by data type definition.

* (specifically on the postcard draft, section 3): close on the discussion of whether we need a flow-id field (as E2E option) and how this field would be defined and used. Back in Prague, several opinions were voiced on this topic - ranging from support of a new "flow id option" to not seeing the need to define a new option.

[HS] As discussed in last meeting, we could make the flow-ID optional. In some cases, it's very useful to reduce data transport bandwidth and data parsing workload. As  for the ID generation mechanisms, we can provide several suggestions but it can also be left open for user to decide. Of course, if we can decide a best method, we can adopt it.

2. I suggested before. I would like to propose a "significant data" bit in the flag. It is set by the intermediate node who think the attached data is significant. The use case is to reduce the exporting data at the end of the IOAM domain. i.e., only the meta data with "significant data" bit set will be exported. For example, when we are tracing the transit delay hop by hop, transit delay within a threshold may not be useful, and not worth to be exported to the collector. Any intermediate node can set this "significant data" bit when the transit delay breaches the threshold. So data are exported only when path congestion. This can be extended to other examples, e.g. buffer.

...FB: Hmm. I think I need to better understand the use case to be convinced. In the first place, why would a node insert data that isn't seen as significant? Rather than use a significant flag, just set up operations in a way that only data considered significant is inserted - otherwise would choose to not insert any data. If you really want to follow your thought to the end, it would translate into adding a "priority" to every IOAM data field. We would then need to decide how many different priorities we'd need, how they are defined and used. Thus, before going there, let's understand the use case.

Cheers, Frank

Regards,
Tianran

From: ippm [mailto:[e-mail]] On Behalf Of Frank Brockners (fbrockne)
Sent: Friday, July 05, 2019 2:22 AM
To: [e-mail]<mailto:[e-mail]>
Subject: [ippm] draft-ietf-ippm-ioam-data and a new draft for IOAM flags

Back in the IPPM WG meeting in Prague, Tommy concluded on the discussion of draft-ietf-ippm-ioam-data-05, that we should "separate the flag discussion into separate drafts and  then fold it into the data draft based on WG consensus." (see IPPM minutes
https://datatracker.ietf.org/meeting/104/materials/minutes-104-ippm-00<https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fmeeting%2F104%2Fmaterials%2Fminutes-104-ippm-00&data=02%7C01%7Chaoyu.song%40futurewei.com%7C67f6648f0a65476ae8dc08d7039b9174%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C636981839021779806&sdata=IbDeAy9SihbGfPDXCFxh6AxPjwxpYbW9d652lbYdOR4%3D&reserved=0>). Unfortunately it took a bit longer than expected but today two new documents were published following Tommy's conclusion:

https://tools.ietf.org/html/draft-mizrahi-ippm-ioam-flags-00<https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-mizrahi-ippm-ioam-flags-00&data=02%7C01%7Chaoyu.song%40futurewei.com%7C67f6648f0a65476ae8dc08d7039b9174%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C636981839021789799&sdata=FW8wDVotaLxD%2FHLw0vGIFqjk1tlGAyOkUkcg5ajq738%3D&reserved=0>
https://tools..ietf.org/html/draft-ietf-ippm-ioam-data-06<https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-ietf-ippm-ioam-data-06&data=02%7C01%7Chaoyu.song%40futurewei.com%7C67f6648f0a65476ae8dc08d7039b9174%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C636981839021789799&sdata=Iy1hgvce%2F7R%2FzDvw6z4jJ%2BI1aiigDeibu161Hta3HUk%3D&reserved=0>

draft-mizrahi-ippm-ioam-flags-00 is a new document which provides the description of those flags that describe IOAM behavior not immediately associated to updating the IOAM data fields, i.e. the new draft took the text related to flags from the draft-ietf-ippm-ioam-data. draft-ietf-ippm-ioam-data-06 is the associated update to the -05 version with the description of the flags removed.

With the -00 draft cut off still a few days away, it would be great to get comments on the split and even more so on the new ioam-flags draft, so that we could create a rev before the cut off (if required) and then try to close the discussion in Montreal.

Thanks much, Frank