Re: [ippm] IOAM Direct Exporting Open Issue

Hi Barak, please see below,
Al

> -----Original Message-----
> From: ippm [mailto:ippm-bounces@ietf.org] On Behalf Of Barak Gafni
> Sent: Wednesday, October 14, 2020 3:04 AM
> To: Frank Brockners (fbrockne) <fbrockne@cisco.com>; Tommy Pauly
> <tpauly@apple.com>; Haoyu Song <haoyu.song@futurewei.com>
> Cc: IPPM Chairs <ippm-chairs@ietf.org>; draft-ietf-ippm-ioam-direct-
> export@ietf.org; IETF IPPM WG (ippm@ietf.org) <ippm@ietf.org>
> 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
> 
> -----Original Message-----
> From: Frank Brockners (fbrockne) <fbrockne@cisco.com>
> Sent: Tuesday, October 13, 2020 11:33 PM
> To: Tommy Pauly <tpauly@apple.com>; Haoyu Song <haoyu.song@futurewei.com>
> Cc: Tal Mizrahi <tal.mizrahi.phd@gmail.com>; IPPM Chairs <ippm-
> chairs@ietf.org>; draft-ietf-ippm-ioam-direct-export@ietf.org; IETF IPPM
> WG (ippm@ietf.org) <ippm@ietf.org>
> 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 <tpauly@apple.com>
> > Sent: Freitag, 2. Oktober 2020 20:35
> > To: Haoyu Song <haoyu.song@futurewei.com>
> > Cc: Frank Brockners (fbrockne) <fbrockne@cisco.com>; Tal Mizrahi
> > <tal.mizrahi.phd@gmail.com>; IPPM Chairs <ippm-chairs@ietf.org>;
> > draft-ietf- ippm-ioam-direct-export@ietf.org
> > 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 <haoyu.song@futurewei.com>
> > 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) <fbrockne@cisco.com>
> > > Sent: Friday, October 2, 2020 9:31 AM
> > > To: Tommy Pauly <tpauly@apple.com>; Tal Mizrahi
> > > <tal.mizrahi.phd@gmail.com>
> > > Cc: IPPM Chairs <ippm-chairs@ietf.org>;
> > > draft-ietf-ippm-ioam-direct-export@ietf.org
> > > 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 <tpauly@apple.com>
> > >> Sent: Mittwoch, 16. September 2020 19:48
> > >> To: Tal Mizrahi <tal.mizrahi.phd@gmail.com>
> > >> Cc: IPPM Chairs <ippm-chairs@ietf.org>;
> > >> draft-ietf-ippm-ioam-direct- export@ietf.org
> > >> 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
> > >>> <tal.mizrahi.phd@gmail.com>
> > >> 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 <tal.mizrahi.phd@gmail.com>
> > >>> Date: Sun, Aug 30, 2020 at 8:52 AM
> > >>> Subject: IOAM Direct Exporting Open Issue
> > >>> To: IETF IPPM WG <ippm@ietf.org>
> > >>>
> > >>>
> > >>> 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://urldefense.com/v3/__https://nam11.safelinks.protection.outlook.com
> /?url=https*3A*2F*2F__;JSUl!!BhdT!xwFSlaNT6BBqgAJ2EE9N7ants16G3QEoa14kb-
> 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
> ippm@ietf.org
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/ippm__;!
> !BhdT!xwFSlaNT6BBqgAJ2EE9N7ants16G3QEoa14kb-FKtmSU6-TwblMb8P58kzmL$