Re: [ippm] IOAM Direct Exporting Open Issue

[Tommy Pauly <[e-mail]>]

Hi Tal,

This proposal looks good to me. Thanks for writing it up!

Tommy

> On Oct 26, 2020, at 1:28 AM, Tal Mizrahi <[e-mail]> wrote:
> 
> Hi Tommy, Barak, Haoyu,
> 
> I created a pull request that I believe resolves the issue based on
> the latest comments.
> 
> https://github.com/inband-oam/ietf/pull/200
> 
> In the proposed version the Hop Count field is not included in the DEX
> header, but the discussion about it is included in an appendix.
> 
> Please let me know if this makes sense.
> 
> Thanks,
> Tal.
> 
> On Fri, Oct 16, 2020 at 11:42 PM Tommy Pauly <[e-mail]> wrote:
>> 
>> 
>> 
>> On Oct 14, 2020, at 10:59 AM, Haoyu Song <[e-mail]> wrote:
>> 
>> Hi Barak,
>> 
>> That’s a possible solution.
>> The nature of DEX makes the DEX data correlation a unique requirements.
>> Now we already have the built-in support for flow correlation (using optional flow ID) and packet correlation (using optional sequence number). The last piece is data order correlation. TTL/Hop Limit, if exist, can be used to server this purpose
>> (we also need to realize, this is not ideal because a missing TTL number from the export data can imply either a dropped export packet  or a DEX-incapable hop. It’s not easy to tell).
>> Previously I suggest to use an optional hop_count to support it just in case such info can’t be acquired elsewhere.
>> If we don’t want to have this, then we need either provide an alternative solution or claim we accept it in exchange of simplicity.
>> In any case, we should include the discussion to show the tradeoffs in the draft.
>> 
>> 
>> Ultimately the draft should just define one method and not present two approaches. The rationale can be mentioned, perhaps in an appendix.
>> 
>> Thanks,
>> Tommy
>> 
>> 
>> Best,
>> Haoyu
>> 
>> ________________________________
>> From: Barak Gafni <[e-mail]>
>> Sent: Wednesday, October 14, 2020 10:34:34 AM
>> To: Haoyu Song <[e-mail]>; Frank Brockners (fbrockne) <[e-mail]>; Tommy Pauly <[e-mail]>
>> Cc: Tal Mizrahi <[e-mail]>; IPPM Chairs <[e-mail]>; [e-mail] <[e-mail]>; IETF IPPM WG ([e-mail]) <[e-mail]>
>> Subject: RE: IOAM Direct Exporting Open Issue
>> 
>> 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.
>> 
>>