Re: [ippm] IOAM Direct Exporting Open Issue

[Barak Gafni <[e-mail]>]

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 <[e-mail]> 
Sent: Wednesday, October 14, 2020 10:29 AM
To: Barak Gafni <[e-mail]>; Frank Brockners (fbrockne) <[e-mail]>; Tommy Pauly <[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


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 <[e-mail]>
Sent: Wednesday, October 14, 2020 12:04 AM
To: Frank Brockners (fbrockne) <[e-mail]>; 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

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