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

From: "Frank Brockners (fbrockne)" <[email-masked]>
Date: Thu, 4 Jul 2019 18:21:42 +0000

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). 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://tools.ietf.org/html/draft-ietf-ippm-ioam-data-06

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

---

From: Tianran Zhou <[email-masked]>
Date: Fri, 5 Jul 2019 02:32:01 +0000

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/) 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.

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.

Regards,
Tianran

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

Thanks much, Frank

---

From: "Frank Brockners (fbrockne)" <[email-masked]>
Date: Mon, 8 Jul 2019 11:41:37 +0000

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 <[email-masked]>
Sent: Freitag, 5. Juli 2019 04:32
To: Frank Brockners (fbrockne) <[email-masked]>; [email-masked]
Subject: RE: draft-ietf-ippm-ioam-data and a new draft for IOAM flags

Hi Frank,

...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.".

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.
* (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.

...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:[email-masked]] On Behalf Of Frank Brockners (fbrockne)
Sent: Friday, July 05, 2019 2:22 AM
To: [email-masked]<mailto:[email-masked]>
Subject: [ippm] draft-ietf-ippm-ioam-data and a new draft for IOAM flags

Thanks much, Frank

---

From: Haoyu Song <[email-masked]>
Date: Mon, 8 Jul 2019 16:53:34 +0000

My comments below.

Haoyu

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

Hi Tianran,

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

Hi Frank,

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.

...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.

[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.

Cheers, Frank

Regards,
Tianran

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>

Thanks much, Frank

---

From: Tianran Zhou <[email-masked]>
Date: Tue, 9 Jul 2019 07:47:15 +0000

Hi Frank,

Some comments added on Haoyu. Please see in line.

Tianran

From: Haoyu Song [mailto:[email-masked]]
Sent: Tuesday, July 09, 2019 12:54 AM
To: Frank Brockners (fbrockne) <[email-masked]>; Tianran Zhou <[email-masked]>; [email-masked]
Cc: [email-masked]
Subject: RE: draft-ietf-ippm-ioam-data and a new draft for IOAM flags

My comments below.

Haoyu

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

Hi Tianran,

[Tianran] Yes, I know the reason to split the draft. My comments were mainly about the draft-mizrahi-ippm-ioam-flags-00.
But now I am confused with the purpose of the draft-mizrahi-ippm-ioam-flags-00 based on your statements.
To be clear, do you mean you are not going to evolve this draft? I.e., it's temporary. So each flag will need a specific document?

Hi Frank,

...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.
[Tianran]: It seems you proposed another approach for the use case. It may work. I think the major problem is it changes the default procedure of IOAM trace. IMO, by default, IOAM will trace data according to the bitmap instruction, no matter isn't seen as significant or not.

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.

[Tianran]: I think the significant flag is similar to the "priority". It's only the design choice whether to use multiple bits for several priority levels. It's also the design choice whether to give each data field a priority or just set one flag for one packet. IMHO, it's easy to decide "yes" or "no" with one bit, for example the threshold breach, but hard to decide the level with multiple bits priority.

Cheers, Frank

Regards,
Tianran

Thanks much, Frank

---

From: "Frank Brockners (fbrockne)" <[email-masked]>
Date: Tue, 9 Jul 2019 07:56:51 +0000

Hi Tianran,

Please see inline ("FB2").

From: Tianran Zhou <[email-masked]>
Sent: Dienstag, 9. Juli 2019 09:47
To: Haoyu Song <[email-masked]>; Frank Brockners (fbrockne) <[email-masked]>; [email-masked]
Cc: [email-masked]
Subject: RE: draft-ietf-ippm-ioam-data and a new draft for IOAM flags

Hi Frank,

Tianran

To: Frank Brockners (fbrockne) <[email-masked]<mailto:[email-masked]>>; Tianran Zhou <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>

My comments below.

Haoyu

Hi Tianran,

..FB2: See https://datatracker.ietf.org/meeting/104/materials/minutes-104-ippm-00 which states "Tommy: On the flags - separate the flag discussion into separate drafts and  then fold it into the data draft based on WG consensus." - If we can agree on the flags draft quickly, we could fold it back into the draft-ietf-ippm-ioam-data. Otherwise, I'd expect the flags draft to be a standalone document which we could adopt as the WG.

Cheers, Frank

Hi Frank,

Cheers, Frank

Regards,
Tianran

Thanks much, Frank

---

From: Tianran Zhou <[email-masked]>
Date: Tue, 9 Jul 2019 08:53:04 +0000

Hi Frank,

Based on "FB2", my comments were mainly about the draft-mizrahi-ippm-ioam-flags-00.
Hope we can discuss on them to achieve the consensus.

Regards,
Tianran

From: Frank Brockners (fbrockne) [mailto:[email-masked]]
Sent: Tuesday, July 09, 2019 3:57 PM
To: Tianran Zhou <[email-masked]>; Haoyu Song <[email-masked]>; [email-masked]
Cc: [email-masked]
Subject: RE: draft-ietf-ippm-ioam-data and a new draft for IOAM flags

Hi Tianran,

To: Haoyu Song <[email-masked]<mailto:[email-masked]>>; Frank Brockners (fbrockne) <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>

Hi Frank,

Tianran

My comments below.

Haoyu

Hi Tianran,

Cheers, Frank

Hi Frank,

Cheers, Frank

Regards,
Tianran

Thanks much, Frank

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Thu, 11 Jul 2019 00:13:07 +0000

Hi、　IPPM　Chairs,

One process question: draft-mizrahi-ippm-ioam-flags-00 is effectively a spin-off of draft-ietf-ippm-ioam-data-05, splitting text from it into a new document, and adding WG discussion related to draft-ietf-ippm-ioam-data. In that case, and since draft-ietf-ippm-ioam-data is an adopted WG document, should draft-mizrahi-ippm-ioam-flags be effectively automatically adopted as a WG Doc?

Asking as that is my experience, when splitting a WG document into two.

Thanks!

Carlos.

On Jul 4, 2019, at 2:21 PM, Frank Brockners (fbrockne) <[email-masked]<mailto:[email-masked]>> wrote:

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). Unfortunately it took a bit longer than expected but today two new documents were published following Tommy’s conclusion:

Thanks much, Frank
_______________________________________________
ippm mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/ippm

---

From: Tommy Pauly <[email-masked]>
Date: Wed, 10 Jul 2019 17:32:40 -0700

Hi Carlos,

Thanks for the question! One of the reasons we asked for documents to be split was to be able to isolate the conversations a bit more, and keep the scope of the already-adopted document to what the working group felt confident about.

With that in mind, the draft-mizrahi-ippm-ioam-flags should not be considered to be automatically adopted. Specifically, we do want to be able to have a discussion as a working group.

I really appreciate that these documents were split, and we’ll definitely make sure to spend time in Montreal to discuss next steps.

Thanks,
Tommy

> On Jul 10, 2019, at 5:13 PM, Carlos Pignataro (cpignata) <[email-masked]> wrote:
> 
> Hi、　IPPM　Chairs,
> 
>> On Jul 4, 2019, at 2:21 PM, Frank Brockners (fbrockne) <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>> https://datatracker.ietf.org/meeting/104/materials/minutes-104-ippm-00 <https://datatracker.ietf.org/meeting/104/materials/minutes-104-ippm-00>). 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://tools.ietf.org/html/draft-mizrahi-ippm-ioam-flags-00>
>> https://tools.ietf.org/html/draft-ietf-ippm-ioam-data-06 <https://tools.ietf.org/html/draft-ietf-ippm-ioam-data-06>
>>  
>> [email-masked] <mailto:[email-masked]>
>> https://www.ietf.org/mailman/listinfo/ippm <https://www.ietf.org/mailman/listinfo/ippm>

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Thu, 11 Jul 2019 00:48:20 +0000

Thanks, Tommy, for a quick response!

This makes good sense to allow demarcation of discussion. The risk is that the isolation of conversation dissociates the tech, and in a while we find the documents had become desynchronized and with a larger gap.

I like this approach, and look forward to discussing at IETF105 (in Montreal or remotely); my only request is that we do not let ippm-ioam-flags decelerate falling behind.

Thanks!

Carlos.

On Jul 10, 2019, at 8:32 PM, Tommy Pauly <[email-masked]<mailto:[email-masked]>> wrote:

Hi Carlos,

Thanks,
Tommy

On Jul 10, 2019, at 5:13 PM, Carlos Pignataro (cpignata) <[email-masked]<mailto:[email-masked]>> wrote:

Hi、　IPPM　Chairs,

Thanks!

Carlos.

Thanks much, Frank