Re: [ippm] IOAM Direct Exporting Open Issue

[Barak Gafni <[e-mail]>]

+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) <[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 <[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%2F
> >>> 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.