Subject: Re: [ippm] IOAM Direct Exporting Open Issue

From: "Frank Brockners (fbrockne)" <[email-masked]>
Date: Wed, 14 Oct 2020 06:32:48 +0000

Cc'ing IPPM WG.

IMHO it makes sense to tackle the question of how IOAM applies to L2 networks as a separate topic.

Cheers, Frank

> -----Original Message-----
> From: Tommy Pauly <[email-masked]>
> Sent: Freitag, 2. Oktober 2020 20:35
> To: Haoyu Song <[email-masked]>
> Cc: Frank Brockners (fbrockne) <[email-masked]>; Tal Mizrahi
> <[email-masked]>; IPPM Chairs <[email-masked]>; draft-ietf-
> [email-masked]
> Subject: Re: IOAM Direct Exporting Open Issue
> 
> If there are scenarios where the hop limit/TTL is not available, could those not
> have a separate mechanism to define a hop limit? This DEX alone could remain
> simple and without duplication for the L3 case, but not preventing combining
> with another mechanism for L2?
> 
> Tommy
> 
> > On Oct 2, 2020, at 10:17 AM, Haoyu Song <[email-masked]>
> wrote:
> >
> > Hi Frank and Tommy,
> >
> > It's also clear that "Hop_count" is not semantically identical to "Hop_lim" (or
> TTL) as specified in IOAM data. The most critical question is: what if Hop_lim is
> not available at all (e.g., in L2 networks)? Then how can we get such
> information? We need to add explanations in the draft how to handle such a
> possibility, and how to get and interpret Hop_lim, if it exists.
> >
> > Best regards,
> > Haoyu
> >
> > -----Original Message-----
> > From: Frank Brockners (fbrockne) <[email-masked]>
> > Sent: Friday, October 2, 2020 9:31 AM
> > To: Tommy Pauly <[email-masked]>; Tal Mizrahi
> > <[email-masked]>
> > Cc: IPPM Chairs <[email-masked]>;
> > [email-masked]
> > Subject: RE: IOAM Direct Exporting Open Issue
> >
> > Hi Tommy,
> >
> > as we all agree, one guiding principle in standards is to avoid reimplementation
> of an already available functionality. This principle helps implementors and avoid
> a proliferation of different options to implement the same functionality. IMHO
> we're presented with such a case here.
> >
> > DEX was originally designed to avoid recording/updating the IOAM related
> metadata in the packet as the packet traverses the network, but instead have
> every transited node create and immediately export the OAM data of interest.
> Let's call this "Vanilla DEX".
> >
> > If we add "hop count recording", we create a "Hybrid DEX" mode, in that we
> record and update a hop-count field in the packet *and* have every transited
> node create and immediately export the OAM data of interest. The hop-count
> recording in this "Hybrid DEX" mode would just be a re-implementation of a
> capability which we already have if we combine "Vanilla DEX" with "IOAM
> tracing". draft-ietf-ippm-ioam-direct-export-01 kind of states this in section 7 -
> but IMHO we should make it really clear that we're talking about a re-
> implementation of an already existing capability.
> >
> > Maybe this context could help us to come to a conclusion on this topic.
> >
> > Cheers, Frank
> >
> >> -----Original Message-----
> >> From: Tommy Pauly <[email-masked]>
> >> Sent: Mittwoch, 16. September 2020 19:48
> >> To: Tal Mizrahi <[email-masked]>
> >> Cc: IPPM Chairs <[email-masked]>; draft-ietf-ippm-ioam-direct-
> >> [email-masked]
> >> Subject: Re: IOAM Direct Exporting Open Issue
> >>
> >> Hi Tal,
> >>
> >> We may need to take some time on our upcoming IETF 109 agenda to
> >> dedicate to resolving this if we can’t get it done before then.
> >>
> >> To get a sense from the authors, for either option, is there someone
> >> who can’t live with that outcome? I can see the trade offs either
> >> way, and I do think we should prescribe only one method. The text
> >> lists the pros and cons—how do they weigh against one another?
> >>
> >> Tommy
> >>
> >>> On Sep 15, 2020, at 11:21 PM, Tal Mizrahi
> >>> <[email-masked]>
> >> wrote:
> >>>
> >>> Dear Chairs,
> >>>
> >>> There were no responses to this email, probably since everyone who
> >>> had comments about this open issue has already commented in the past.
> >>> At this point we would like your help with proceeding to resolve this issue.
> >>>
> >>> Thanks,
> >>> Tal.
> >>>
> >>> ---------- Forwarded message ---------
> >>> From: Tal Mizrahi <[email-masked]>
> >>> Date: Sun, Aug 30, 2020 at 8:52 AM
> >>> Subject: IOAM Direct Exporting Open Issue
> >>> To: IETF IPPM WG <[email-masked]>
> >>>
> >>>
> >>> Hi,
> >>>
> >>> There is an open issue in the DEX draft about whether to include an
> >>> explicit Hop Count field in the DEX header, or to rely on the
> >>> existing Hop_Lim/Node_ID data field.
> >>>
> >>> Section 7 of the draft presents the pros and cons of each of these
> >>> alternatives. This issue has also been discussed on the mailing list
> >>> a couple of times, and on the last few IPPM meetings.
> >>>
> >>> We would like to encourage non-authors to express their opinion
> >>> about which approach should be taken: (1) use an explicit Hop Count
> >>> field, or (2) rely on the existing Hop_Lim/Node_ID data field.
> >>>
> >>> Cheers,
> >>> Tal.
> >>>
> >>>
> >>> Here is a link to the draft:
> >>> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fda
> >>> tatracker.ietf.org%2Fdoc%2Fdraft-ietf-ippm-ioam-direct-export%2F&amp
> >>>
> ;data=02%7C01%7Chaoyu.song%40futurewei.com%7C2f840fbff5b34808bb3f08
> d
> >>>
> 866f0c247%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C6373725315
> 361
> >>>
> 39070&amp;sdata=zOeIUtzXzqkyb5D9pdc1UgUP%2Bnpjc0aB0AHU0Df8Y1E%3D
> &amp
> >>> ;reserved=0
> >>>
> >>> Section 7 of the draft, which presents the two alternatives is
> >>> quoted here for convenience.
> >>>
> >>>     Hop Limit / Hop Count: in order to help correlate and order the
> >>>     exported packets, it is possible to include a 1-octet Hop Count
> >>>     field in the DEX header (presumably by claiming some space from
> >>>     the Flags field).  Its value starts from 0 at the encapsulating
> >>>     node and is incremented by each IOAM transit node that supports
> >>>     the DEX option.  The Hop Count field value is also included in the
> >>>     exported packet.  An alternative approach is to use the Hop_Lim/
> >>>     Node_ID data field; if the IOAM-Trace-Type
> >>>     [I-D.ietf-ippm-ioam-data] has the Hop_Lim/Node_ID bit set, then
> >>>     exported packets include the Hop_Lim/Node_ID data field, which
> >>>     contains the TTL/Hop Limit value from a lower layer protocol.  The
> >>>     main advantage of the Hop_Lim/Node_ID approach is that it provides
> >>>     information about the current hop count without requiring each
> >>>     transit node to modify the DEX option, thus simplifying the data
> >>>     plane functionality of Direct Exporting.  The main advantage of
> >>>     the Hop Count approach is that it counts the number of IOAM-
> >>>     capable nodes without relying on the lower layer TTL, especially
> >>>     when the lower layer cannot prvide the accurate TTL information,
> >>>     e.g., Layer 2 Ethernet or hierarchical VPN.  It also explicitly
> >>>     allows to detect a case where an IOAM-capable node fails to export
> >>>     packets.  In order to facilitate the Hop Count approach it is
> >>>     possible to use a flag to indicate an optional Hop Count field,
> >>>     which enables to control the tradeoff.  On one hand it addresses
> >>>     the use cases that the Hop_Lim/Node_ID cannot cover, and on the
> >>>     other hand it does not require transit switches to update the
> >>>     option if it is not supported or disabled.  Further discussion is
> >>>     required about the tradeoff between the two alternatives.

---

From: Barak Gafni <[email-masked]>
Date: Wed, 14 Oct 2020 07:03:37 +0000

+1
My view is that if there is a need to discuss what a hop count is - the scope is the data draft where it has been defined, rather than DEX. Would you agree?

Thanks,
Barak

-----Original Message-----
From: Frank Brockners (fbrockne) <[email-masked]> 
Sent: Tuesday, October 13, 2020 11:33 PM
To: Tommy Pauly <[email-masked]>; Haoyu Song <[email-masked]>
Cc: Tal Mizrahi <[email-masked]>; IPPM Chairs <[email-masked]>; [email-masked]; IETF IPPM WG ([email-masked]) <[email-masked]>
Subject: RE: IOAM Direct Exporting Open Issue

External email: Use caution opening links or attachments

Cc'ing IPPM WG.

Cheers, Frank

> <[email-masked]>; IPPM Chairs <[email-masked]>; 
> draft-ietf- [email-masked]
> If there are scenarios where the hop limit/TTL is not available, could 
> those not have a separate mechanism to define a hop limit? This DEX 
> alone could remain simple and without duplication for the L3 case, but 
> not preventing combining with another mechanism for L2?
>
> Tommy
>
> TTL) as specified in IOAM data. The most critical question is: what if 
> Hop_lim is not available at all (e.g., in L2 networks)? Then how can 
> we get such information? We need to add explanations in the draft how 
> to handle such a possibility, and how to get and interpret Hop_lim, if it exists.
> >
> > Best regards,
> > Haoyu
> >
> of an already available functionality. This principle helps 
> implementors and avoid a proliferation of different options to 
> implement the same functionality. IMHO we're presented with such a case here.
> >
> metadata in the packet as the packet traverses the network, but 
> instead have every transited node create and immediately export the OAM data of interest.
> record and update a hop-count field in the packet *and* have every 
> transited node create and immediately export the OAM data of interest. 
> The hop-count recording in this "Hybrid DEX" mode would just be a 
> re-implementation of a capability which we already have if we combine 
> "Vanilla DEX" with "IOAM tracing". 
> draft-ietf-ippm-ioam-direct-export-01 kind of states this in section 7 
> - but IMHO we should make it really clear that we're talking about a re- implementation of an already existing capability.
> >
> >> draft-ietf-ippm-ioam-direct- [email-masked]
> >> To get a sense from the authors, for either option, is there 
> >> someone who can’t live with that outcome? I can see the trade offs 
> >> either way, and I do think we should prescribe only one method. The 
> >> text lists the pros and cons—how do they weigh against one another?
> >>
> >> Tommy
> >>
> >>> There is an open issue in the DEX draft about whether to include 
> >>> an explicit Hop Count field in the DEX header, or to rely on the 
> >>> alternatives. This issue has also been discussed on the mailing 
> >>> list a couple of times, and on the last few IPPM meetings.
> >>>
> >>> about which approach should be taken: (1) use an explicit Hop 
> >>> Count field, or (2) rely on the existing Hop_Lim/Node_ID data field.
> >>>
> >>> Cheers,
> >>> Tal.
> >>>
> >>>

---

From: "MORTON, ALFRED C (AL)" <[email-masked]>
Date: Wed, 14 Oct 2020 13:53:38 +0000

Hi Barak, please see below,
Al

> From: ippm [mailto:[email-masked]] On Behalf Of Barak Gafni
> Sent: Wednesday, October 14, 2020 3:04 AM
> To: Frank Brockners (fbrockne) <[email-masked]>; Tommy Pauly
> <[email-masked]>; Haoyu Song <[email-masked]>
> [email-masked]; IETF IPPM WG ([email-masked]) <[email-masked]>
> Subject: Re: [ippm] IOAM Direct Exporting Open Issue
> 
> +1
> My view is that if there is a need to discuss what a hop count is 
[acm] 
Do the https://tools.ietf.org/html/draft-ietf-ippm-route-10 
definitions help with this?

that was our part of our goal with this draft (now in RFCEditor queue).
Al

- the
> scope is the data draft where it has been defined, rather than DEX. Would
> you agree?
> 
> Thanks,
> Barak
> 
> Cc: Tal Mizrahi <[email-masked]>; IPPM Chairs <ippm-
> [email-masked]>; [email-masked]; IETF IPPM
> WG ([email-masked]) <[email-masked]>
> > - but IMHO we should make it really clear that we're talking about a re-
> https://urldefense.com/v3/__https://nam11.safelinks.protection.outlook.com
> /?url=https*3A*2F*2F__;JSUl!!BhdT!xwFSlaNT6BBqgAJ2EE9N7ants16G3QEoa14kb-
> FKtmSU6-TwblMb8NKl6bf_$
> > >>> da
> _______________________________________________
> ippm mailing list
> [email-masked]
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/ippm__;!
> !BhdT!xwFSlaNT6BBqgAJ2EE9N7ants16G3QEoa14kb-FKtmSU6-TwblMb8P58kzmL$

---

From: Haoyu Song <[email-masked]>
Date: Wed, 14 Oct 2020 17:28:43 +0000

Hi Barak,

I don't understand what do you mean the issue is not in the scope of DEX draft.
The hop information is used to order the DEX data for the same user packet along the path. 
To make it work, you need to consider how such information can be acquired in every possible application environment.
It's fine we can't foresee everything, but for the known ones, we'd better have solutions ready, 
otherwise we might need expensive update in the future.
(Having said that, I'm okay if we acknowledge and decide to accept that in some case such information is missing) 

Best,
Haoyu

-----Original Message-----
From: Barak Gafni <[email-masked]> 
Sent: Wednesday, October 14, 2020 12:04 AM
To: Frank Brockners (fbrockne) <[email-masked]>; Tommy Pauly <[email-masked]>; Haoyu Song <[email-masked]>
Cc: Tal Mizrahi <[email-masked]>; IPPM Chairs <[email-masked]>; [email-masked]; IETF IPPM WG ([email-masked]) <[email-masked]>
Subject: RE: IOAM Direct Exporting Open Issue

+1

Thanks,
Barak

-----Original Message-----
From: Frank Brockners (fbrockne) <[email-masked]>
Sent: Tuesday, October 13, 2020 11:33 PM
To: Tommy Pauly <[email-masked]>; Haoyu Song <[email-masked]>
Cc: Tal Mizrahi <[email-masked]>; IPPM Chairs <[email-masked]>; [email-masked]; IETF IPPM WG ([email-masked]) <[email-masked]>
Subject: RE: IOAM Direct Exporting Open Issue

Cc'ing IPPM WG.

Cheers, Frank

---

From: Haoyu Song <[email-masked]>
Date: Wed, 14 Oct 2020 17:59:28 +0000

Hi Barak,

That’s a possible solution.
The nature of DEX makes the DEX data correlation a unique requirements.
Now we already have the built-in support for flow correlation (using optional flow ID) and packet correlation (using optional sequence number). The last piece is data order correlation. TTL/Hop Limit, if exist, can be used to server this purpose
(we also need to realize, this is not ideal because a missing TTL number from the export data can imply either a dropped export packet  or a DEX-incapable hop. It’s not easy to tell).
Previously I suggest to use an optional hop_count to support it just in case such info can’t be acquired elsewhere.
If we don’t want to have this, then we need either provide an alternative solution or claim we accept it in exchange of simplicity.
In any case, we should include the discussion to show the tradeoffs in the draft.

Best,
Haoyu

________________________________
From: Barak Gafni <[email-masked]>
Sent: Wednesday, October 14, 2020 10:34:34 AM
To: Haoyu Song <[email-masked]>; Frank Brockners (fbrockne) <[email-masked]>; Tommy Pauly <[email-masked]>
Cc: Tal Mizrahi <[email-masked]>; IPPM Chairs <[email-masked]>; [email-masked] <[email-masked]>; IETF IPPM WG ([email-masked]) <[email-masked]>
Subject: RE: IOAM Direct Exporting Open Issue

Hi Haoyu,
Thanks, I think this is a good suggestion. Taking that into consideration, let's move forward with:
1. Acknowledge current design for DEX w/o additional "special" hop-count field
2. Discuss needs and potential implications related to hop-count as part of data draft, so one can use it for its applications

Does it make sense?

Thanks,
Barak

-----Original Message-----
From: Haoyu Song <[email-masked]>
Sent: Wednesday, October 14, 2020 10:29 AM
To: Barak Gafni <[email-masked]>; Frank Brockners (fbrockne) <[email-masked]>; Tommy Pauly <[email-masked]>
Cc: Tal Mizrahi <[email-masked]>; IPPM Chairs <[email-masked]>; [email-masked]; IETF IPPM WG ([email-masked]) <[email-masked]>
Subject: RE: IOAM Direct Exporting Open Issue

Hi Barak,

It's fine we can't foresee everything, but for the known ones, we'd better have solutions ready, otherwise we might need expensive update in the future.

Best,
Haoyu

-----Original Message-----
From: Barak Gafni <[email-masked]>
Sent: Wednesday, October 14, 2020 12:04 AM
To: Frank Brockners (fbrockne) <[email-masked]>; Tommy Pauly <[email-masked]>; Haoyu Song <[email-masked]>
Cc: Tal Mizrahi <[email-masked]>; IPPM Chairs <[email-masked]>; [email-masked]; IETF IPPM WG ([email-masked]) <[email-masked]>
Subject: RE: IOAM Direct Exporting Open Issue

+1

Thanks,
Barak

-----Original Message-----
From: Frank Brockners (fbrockne) <[email-masked]>
Sent: Tuesday, October 13, 2020 11:33 PM
To: Tommy Pauly <[email-masked]>; Haoyu Song <[email-masked]>
Cc: Tal Mizrahi <[email-masked]>; IPPM Chairs <[email-masked]>; [email-masked]; IETF IPPM WG ([email-masked]) <[email-masked]>
Subject: RE: IOAM Direct Exporting Open Issue

Cc'ing IPPM WG.

Cheers, Frank

---

From: Tommy Pauly <[email-masked]>
Date: Fri, 16 Oct 2020 13:42:19 -0700

> On Oct 14, 2020, at 10:59 AM, Haoyu Song <[email-masked]> wrote:
> 
> Hi Barak,
>  

Ultimately the draft should just define one method and not present two approaches. The rationale can be mentioned, perhaps in an appendix.

Thanks,
Tommy

> > >>> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2F <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2F>
> > >>> da

---

From: Barak Gafni <[email-masked]>
Date: Wed, 14 Oct 2020 15:22:47 +0000

Al, 
Thank you for this pointer! It is indeed on the same area but I am not sure that it solves the challenge under discussion here.

Anyway, 
Please note that here below my claim is about the context of the discussion - which in my view is the IOAM data draft, rather than DEX. 
As a consequence, DEX should move forward while we discuss resolution related to data draft. This is where this tool has been specified, and one may argue about this specification.

Thanks,
Barak

-----Original Message-----
From: MORTON, ALFRED C (AL) <[email-masked]> 
Sent: Wednesday, October 14, 2020 6:54 AM
To: Barak Gafni <[email-masked]>; Frank Brockners (fbrockne) <[email-masked]>; Tommy Pauly <[email-masked]>; Haoyu Song <[email-masked]>
Cc: IPPM Chairs <[email-masked]>; [email-masked]; IETF IPPM WG ([email-masked]) <[email-masked]>
Subject: RE: IOAM Direct Exporting Open Issue

> My view is that if there is a need to discuss what a hop count is
[acm]
Do the https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-ietf-ippm-route-10&amp;data=04%7C01%7Cgbarak%40nvidia.com%7C13301ae9c30d4a82b63108d870489f38%7C43083d15727340c1b7db39efd9ccc17a%7C0%7C1%7C637382804516445351%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=92gL4P8SkHbSLsiEW5piN%2FC6zuZeh1hxB1gLdPGrpLU%3D&amp;reserved=0
definitions help with this?

- the
> scope is the data draft where it has been defined, rather than DEX. 
> Would you agree?
>
> Thanks,
> Barak
>
> [email-masked]>; [email-masked]; IETF 
> IPPM WG ([email-masked]) <[email-masked]>
> > If there are scenarios where the hop limit/TTL is not available, 
> > could those not have a separate mechanism to define a hop limit? 
> > This DEX alone could remain simple and without duplication for the 
> > L3 case, but not preventing combining with another mechanism for L2?
> >
> > Tommy
> >
> > TTL) as specified in IOAM data. The most critical question is: what 
> > if Hop_lim is not available at all (e.g., in L2 networks)? Then how 
> > can we get such information? We need to add explanations in the 
> > draft how to handle such a possibility, and how to get and interpret 
> > Hop_lim, if
> it exists.
> > >
> > > Best regards,
> > > Haoyu
> > >
> > implement the same functionality. IMHO we're presented with such a 
> > case
> here.
> > >
> > instead have every transited node create and immediately export the 
> > OAM
> data of interest.
> > re-implementation of a capability which we already have if we 
> > combine "Vanilla DEX" with "IOAM tracing".
> > >> someone who can’t live with that outcome? I can see the trade 
> > >> offs either way, and I do think we should prescribe only one 
> > >> method. The text lists the pros and cons—how do they weigh against one another?
> > >>
> > >> Tommy
> > >>
> > >>> There were no responses to this email, probably since everyone 
> > >>> who had comments about this open issue has already commented in 
> > >>> the
> past.
> > >>> Section 7 of the draft presents the pros and cons of each of 
> > >>> these alternatives. This issue has also been discussed on the 
> > >>> mailing list a couple of times, and on the last few IPPM meetings.
> > >>>
> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Furld
> efense.com%2Fv3%2F__https%3A%2F%2Fnam11.safelinks.protection.outlook.c
> om&amp;data=04%7C01%7Cgbarak%40nvidia.com%7C13301ae9c30d4a82b63108d870
> 489f38%7C43083d15727340c1b7db39efd9ccc17a%7C0%7C1%7C637382804516445351
> %7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6I
> k1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=tdZEKfTvJI%2BrDZRK8FTZkZHcRjqv5
> aJhDnlnWtHjr3g%3D&amp;reserved=0
> > >>> tatracker.ietf.org%2Fdoc%2Fdraft-ietf-ippm-ioam-direct-export%2F
> > >>> &a
> > >>> mp
> > >>>
> > >>>     the DEX option.  The Hop Count field value is also included 
> > >>> in
> the
> > >>>     option if it is not supported or disabled.  Further 
> > >>> discussion
> is
> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fippm__&amp;data=04%7C01%7Cgbarak%40nvidia.com%7C13301ae9c30d4a82b63108d870489f38%7C43083d15727340c1b7db39efd9ccc17a%7C0%7C1%7C637382804516445351%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=iZ7qBPgknWmen09PBV%2BFuireAb2BvJLnBs60Dcky3Vk%3D&amp;reserved=0;!

---

From: Barak Gafni <[email-masked]>
Date: Wed, 14 Oct 2020 17:34:34 +0000

Hi Haoyu,

Does it make sense?

Thanks,
Barak

-----Original Message-----
From: Haoyu Song <[email-masked]> 
Sent: Wednesday, October 14, 2020 10:29 AM
To: Barak Gafni <[email-masked]>; Frank Brockners (fbrockne) <[email-masked]>; Tommy Pauly <[email-masked]>
Cc: Tal Mizrahi <[email-masked]>; IPPM Chairs <[email-masked]>; [email-masked]; IETF IPPM WG ([email-masked]) <[email-masked]>
Subject: RE: IOAM Direct Exporting Open Issue

Hi Barak,

Best,
Haoyu

-----Original Message-----
From: Barak Gafni <[email-masked]>
Sent: Wednesday, October 14, 2020 12:04 AM
To: Frank Brockners (fbrockne) <[email-masked]>; Tommy Pauly <[email-masked]>; Haoyu Song <[email-masked]>
Cc: Tal Mizrahi <[email-masked]>; IPPM Chairs <[email-masked]>; [email-masked]; IETF IPPM WG ([email-masked]) <[email-masked]>
Subject: RE: IOAM Direct Exporting Open Issue

+1

Thanks,
Barak

-----Original Message-----
From: Frank Brockners (fbrockne) <[email-masked]>
Sent: Tuesday, October 13, 2020 11:33 PM
To: Tommy Pauly <[email-masked]>; Haoyu Song <[email-masked]>
Cc: Tal Mizrahi <[email-masked]>; IPPM Chairs <[email-masked]>; [email-masked]; IETF IPPM WG ([email-masked]) <[email-masked]>
Subject: RE: IOAM Direct Exporting Open Issue

Cc'ing IPPM WG.

Cheers, Frank

---

From: Tal Mizrahi <[email-masked]>
Date: Mon, 26 Oct 2020 10:28:56 +0200

Hi Tommy, Barak, Haoyu,

I created a pull request that I believe resolves the issue based on
the latest comments.

https://github.com/inband-oam/ietf/pull/200

In the proposed version the Hop Count field is not included in the DEX
header, but the discussion about it is included in an appendix.

Please let me know if this makes sense.

Thanks,
Tal.

---

From: Tommy Pauly <[email-masked]>
Date: Mon, 26 Oct 2020 08:44:24 -0700

Hi Tal,

This proposal looks good to me. Thanks for writing it up!

Tommy

> On Oct 26, 2020, at 1:28 AM, Tal Mizrahi <[email-masked]> wrote:
> 
> Hi Tommy, Barak, Haoyu,
>

---

From: Haoyu Song <[email-masked]>
Date: Mon, 26 Oct 2020 18:45:54 +0000

Hi Tal,

Thanks for the update. For now it looks good but it still doesn't solve the problem. I think we should try to achieve consensus to progress the draft.  i.e., if we decide to not include the optional explicit hop count field, we need to document the implication and limitation of such a design choice in the main text. My 2 cents.

Best,
Haoyu

-----Original Message-----
From: Tal Mizrahi <[email-masked]> 
Sent: Monday, October 26, 2020 1:29 AM
To: Tommy Pauly <[email-masked]>; Barak Gafni <[email-masked]>; Haoyu Song <[email-masked]>
Cc: Frank Brockners (fbrockne) <[email-masked]>; IPPM Chairs <[email-masked]>; [email-masked]; IETF IPPM WG ([email-masked]) <[email-masked]>
Subject: Re: IOAM Direct Exporting Open Issue

Hi Tommy, Barak, Haoyu,

I created a pull request that I believe resolves the issue based on the latest comments.

https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Finband-oam%2Fietf%2Fpull%2F200&amp;data=04%7C01%7Chaoyu.song%40futurewei.com%7C3a358549dc21473666f708d879893660%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637392977521276253%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=Hlww2VflP060MV7RJBL1xd4iGJ0wx5v5LwcwA6xVjvo%3D&amp;reserved=0

In the proposed version the Hop Count field is not included in the DEX header, but the discussion about it is included in an appendix.

Thanks,
Tal.

On Fri, Oct 16, 2020 at 11:42 PM Tommy Pauly <[email-masked]> wrote:
> Now we already have the built-in support for flow correlation (using 
> optional flow ID) and packet correlation (using optional sequence number). The last piece is data order correlation. TTL/Hop Limit, if exist, can be used to server this purpose (we also need to realize, this is not ideal because a missing TTL number from the export data can imply either a dropped export packet  or a DEX-incapable hop. It’s not easy to tell).
> To: Haoyu Song <[email-masked]>; Frank Brockners (fbrockne) 
> <[email-masked]>; Tommy Pauly <[email-masked]>
> Cc: Tal Mizrahi <[email-masked]>; IPPM Chairs 
> <[email-masked]>; [email-masked] 
> <[email-masked]>; IETF IPPM WG 
> ([email-masked]) <[email-masked]>
> 1. Acknowledge current design for DEX w/o additional "special" 
> hop-count field 2. Discuss needs and potential implications related to 
> hop-count as part of data draft, so one can use it for its 
> applications
>
> Does it make sense?
>
> Thanks,
> Barak
>
> To: Barak Gafni <[email-masked]>; Frank Brockners (fbrockne) 
> <[email-masked]>; Tommy Pauly <[email-masked]>
> Cc: Tal Mizrahi <[email-masked]>; IPPM Chairs 
> <[email-masked]>; [email-masked]; 
> IETF IPPM WG ([email-masked]) <[email-masked]>
> (Having said that, I'm okay if we acknowledge and decide to accept 
> that in some case such information is missing)
>
> Best,
> Haoyu
>
> Cc: Tal Mizrahi <[email-masked]>; IPPM Chairs 
> <[email-masked]>; [email-masked]; 
> IETF IPPM WG ([email-masked]) <[email-masked]>
> Cc: Tal Mizrahi <[email-masked]>; IPPM Chairs 
> <[email-masked]>; [email-masked]; 
> IETF IPPM WG ([email-masked]) <[email-masked]>
> > draft how to handle such a possibility, and how to get and interpret Hop_lim, if it exists.
> > >
> > > Best regards,
> > > Haoyu
> > >
> > >>> who had comments about this open issue has already commented in the past.
> > >>> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%
> > >>> 2F
> > >>> da

---

From: Tal Mizrahi <[email-masked]>
Date: Wed, 28 Oct 2020 09:07:55 +0200

Hi Haoyu,

On Mon, Oct 26, 2020 at 8:45 PM Haoyu Song <[email-masked]> wrote:

[snip]
> For now it looks good but it still doesn't solve the problem.
[snip]

Thanks, Haoyu. I suggest to post the current (pull request) version as
a base for discussion in IETF 109.
Unless there are objections I will post this version before the IETF
109 submission deadline.

Cheers,
Tal.

---

From: "Frank Brockners (fbrockne)" <[email-masked]>
Date: Wed, 28 Oct 2020 07:43:23 +0000

Thanks Tal for reflecting the most recent discussion in the updated draft.
IMHO it would be good to get the most recent version officially posted so that we can use it for the discussions in IETF 109.

Thanks, Frank

> Sent: Mittwoch, 28. Oktober 2020 08:08
> Cc: Tommy Pauly <[email-masked]>; Barak Gafni <[email-masked]>;
> Frank Brockners (fbrockne) <[email-masked]>; IPPM Chairs <ippm-
> [email-masked]>; [email-masked]; IETF IPPM WG
> Thanks, Haoyu. I suggest to post the current (pull request) version as a base for
> discussion in IETF 109.
> > Thanks for the update. For now it looks good but it still doesn't solve the
> problem. I think we should try to achieve consensus to progress the draft.  i.e., if
> we decide to not include the optional explicit hop count field, we need to
> document the implication and limitation of such a design choice in the main text.
> My 2 cents.
> >
> > Best,
> > Haoyu
> >
> > Cc: Frank Brockners (fbrockne) <[email-masked]>; IPPM Chairs
> > https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgith
> > ub.com%2Finband-
> oam%2Fietf%2Fpull%2F200&amp;data=04%7C01%7Chaoyu.song%
> >
> 40futurewei.com%7C3a358549dc21473666f708d879893660%7C0fee8ff2a3b24
> 0189
> >
> c753a1d5591fedc%7C1%7C0%7C637392977521276253%7CUnknown%7CTWFp
> bGZsb3d8e
> >
> yJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7
> C10
> >
> 00&amp;sdata=Hlww2VflP060MV7RJBL1xd4iGJ0wx5v5LwcwA6xVjvo%3D&amp;
> reserv
> > ed=0
> >
> > In the proposed version the Hop Count field is not included in the DEX header,
> but the discussion about it is included in an appendix.
> >
> > > optional flow ID) and packet correlation (using optional sequence number).
> The last piece is data order correlation. TTL/Hop Limit, if exist, can be used to
> server this purpose (we also need to realize, this is not ideal because a missing
> TTL number from the export data can imply either a dropped export packet  or a
> DEX-incapable hop. It’s not easy to tell).
> > > If we don’t want to have this, then we need either provide an alternative
> solution or claim we accept it in exchange of simplicity.
> > > Ultimately the draft should just define one method and not present two
> approaches. The rationale can be mentioned, perhaps in an appendix.
> > >
> > > Thanks,
> > > Tommy
> > >
> > >
> > > Best,
> > > Haoyu
> > >
> > > To: Haoyu Song <[email-masked]>; Frank Brockners
> > > (fbrockne) <[email-masked]>; Tommy Pauly <[email-masked]>
> > > hop-count field 2. Discuss needs and potential implications related
> > > to hop-count as part of data draft, so one can use it for its
> > > applications
> > >
> > > Does it make sense?
> > >
> > > Thanks,
> > > Barak
> > >
> > > To make it work, you need to consider how such information can be
> acquired in every possible application environment.
> > > It's fine we can't foresee everything, but for the known ones, we'd better
> have solutions ready, otherwise we might need expensive update in the future.
> > > My view is that if there is a need to discuss what a hop count is - the scope is
> the data draft where it has been defined, rather than DEX. Would you agree?
> > >
> > > Thanks,
> > > Barak
> > >
> > > > TTL) as specified in IOAM data. The most critical question is:
> > > > what if Hop_lim is not available at all (e.g., in L2 networks)?
> > > > Then how can we get such information? We need to add explanations
> > > > in the draft how to handle such a possibility, and how to get and interpret
> Hop_lim, if it exists.
> > > > >
> > > > > Best regards,
> > > > > Haoyu
> > > > >
> > > > draft-ietf-ippm-ioam-direct-export-01 kind of states this in
> > > > section
> > > > 7
> > > > >> We may need to take some time on our upcoming IETF 109 agenda
> > > > >> to dedicate to resolving this if we can’t get it done before then.
> > > > >>
> the past.
> > > > >>> There is an open issue in the DEX draft about whether to
> > > > >>> include an explicit Hop Count field in the DEX header, or to
> > > > >>> rely on the existing Hop_Lim/Node_ID data field.
> > > > >>>
> > > > >>> We would like to encourage non-authors to express their
> > > > >>> opinion about which approach should be taken: (1) use an
> > > > >>> explicit Hop Count field, or (2) rely on the existing Hop_Lim/Node_ID
> data field.
> > > > >>>
> > > > >>> Cheers,
> > > > >>> Tal.
> > > > >>>
> > > > >>>

---

From: Haoyu Song <[email-masked]>
Date: Wed, 28 Oct 2020 16:46:05 +0000

Hi Tal,

It's a good idea to post it for IETF109 discussion. Thanks!

Haoyu

-----Original Message-----
From: Tal Mizrahi <[email-masked]> 
Sent: Wednesday, October 28, 2020 12:08 AM
To: Haoyu Song <[email-masked]>
Cc: Tommy Pauly <[email-masked]>; Barak Gafni <[email-masked]>; Frank Brockners (fbrockne) <[email-masked]>; IPPM Chairs <[email-masked]>; [email-masked]; IETF IPPM WG ([email-masked]) <[email-masked]>
Subject: Re: IOAM Direct Exporting Open Issue

Hi Haoyu,

[snip]
[snip]

Thanks, Haoyu. I suggest to post the current (pull request) version as a base for discussion in IETF 109.
Unless there are objections I will post this version before the IETF
109 submission deadline.

Cheers,
Tal.

On Mon, Oct 26, 2020 at 8:45 PM Haoyu Song <[email-masked]> wrote:
> ub.com%2Finband-oam%2Fietf%2Fpull%2F200&amp;data=04%7C01%7Chaoyu.song%
> 40futurewei.com%7C3c6079797b3d40d7645f08d87b103957%7C0fee8ff2a3b240189
> c753a1d5591fedc%7C1%7C0%7C637394656896177440%7CUnknown%7CTWFpbGZsb3d8e
> yJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C10
> 00&amp;sdata=P7hxJvRCFxz39FnCZOsnzmleD%2FibR96b9COuu7uG6bE%3D&amp;rese
> rved=0
>
> > > in the draft how to handle such a possibility, and how to get and interpret Hop_lim, if it exists.
> > > >
> > > > Best regards,
> > > > Haoyu
> > > >
> > > >>> explicit Hop Count field, or (2) rely on the existing Hop_Lim/Node_ID data field.
> > > >>>
> > > >>> Cheers,
> > > >>> Tal.
> > > >>>
> > > >>>
> > > >>> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2
> > > >>> F%25
> > > >>> 2F
> > > >>> da