Re: [ippm] IOAM Direct Exporting Open Issue

[Barak Gafni <[e-mail]>]

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) <[e-mail]> 
Sent: Wednesday, October 14, 2020 6:54 AM
To: Barak Gafni <[e-mail]>; Frank Brockners (fbrockne) <[e-mail]>; Tommy Pauly <[e-mail]>; Haoyu Song <[e-mail]>
Cc: IPPM Chairs <[e-mail]>; [e-mail]; IETF IPPM WG ([e-mail]) <[e-mail]>
Subject: RE: IOAM Direct Exporting Open Issue

External email: Use caution opening links or attachments


Hi Barak, please see below,
Al

> -----Original Message-----
> From: ippm [mailto:[e-mail]] On Behalf Of Barak Gafni
> Sent: Wednesday, October 14, 2020 3:04 AM
> To: Frank Brockners (fbrockne) <[e-mail]>; Tommy Pauly 
> <[e-mail]>; Haoyu Song <[e-mail]>
> Cc: IPPM Chairs <[e-mail]>; draft-ietf-ippm-ioam-direct- 
> [e-mail]; IETF IPPM WG ([e-mail]) <[e-mail]>
> 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://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?

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
>
> -----Original Message-----
> From: Frank Brockners (fbrockne) <[e-mail]>
> Sent: Tuesday, October 13, 2020 11:33 PM
> To: Tommy Pauly <[e-mail]>; Haoyu Song 
> <[e-mail]>
> Cc: Tal Mizrahi <[e-mail]>; IPPM Chairs <ippm- 
> [e-mail]>; [e-mail]; IETF 
> IPPM WG ([e-mail]) <[e-mail]>
> Subject: RE: IOAM Direct Exporting Open Issue
>
> External email: Use caution opening links or attachments
>
>
> 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 <[e-mail]>
> > Sent: Freitag, 2. Oktober 2020 20:35
> > To: Haoyu Song <[e-mail]>
> > Cc: Frank Brockners (fbrockne) <[e-mail]>; Tal Mizrahi 
> > <[e-mail]>; IPPM Chairs <[e-mail]>;
> > draft-ietf- [e-mail]
> > 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 <[e-mail]>
> > 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) <[e-mail]>
> > > Sent: Friday, October 2, 2020 9:31 AM
> > > To: Tommy Pauly <[e-mail]>; Tal Mizrahi 
> > > <[e-mail]>
> > > Cc: IPPM Chairs <[e-mail]>; 
> > > [e-mail]
> > > 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 <[e-mail]>
> > >> Sent: Mittwoch, 16. September 2020 19:48
> > >> To: Tal Mizrahi <[e-mail]>
> > >> Cc: IPPM Chairs <[e-mail]>;
> > >> draft-ietf-ippm-ioam-direct- [e-mail]
> > >> 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 
> > >>> <[e-mail]>
> > >> 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 <[e-mail]>
> > >>> Date: Sun, Aug 30, 2020 at 8:52 AM
> > >>> Subject: IOAM Direct Exporting Open Issue
> > >>> To: IETF IPPM WG <[e-mail]>
> > >>>
> > >>>
> > >>> 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%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
> /?url=https*3A*2F*2F__;JSUl!!BhdT!xwFSlaNT6BBqgAJ2EE9N7ants16G3QEoa14k
> b-
> FKtmSU6-TwblMb8NKl6bf_$
> > >>> da
> > >>> tatracker.ietf.org%2Fdoc%2Fdraft-ietf-ippm-ioam-direct-export%2F
> > >>> &a
> > >>> mp
> > >>>
> > ;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.
> _______________________________________________
> ippm mailing list
> [e-mail]
> 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;!
> !BhdT!xwFSlaNT6BBqgAJ2EE9N7ants16G3QEoa14kb-FKtmSU6-TwblMb8P58kzmL$