Re: [ippm] IOAM Direct Exporting Open Issue

["Frank Brockners (fbrockne)" <[e-mail]>]

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