Re: [Ippm-ioam-ix-dt] IPPM IOAM Immediate Exporting Design Team Meeting Minutes - September 18th 2019

[Tal Mizrahi <[e-mail]>]

The next virtual meeting is this week on Wednesday, October 2nd, at 06:00
UTC.

Thanks,
Tal.

On Sun, Sep 22, 2019 at 12:18 PM Tal Mizrahi <[e-mail]>
wrote:

> Hi,
>
> The Hop Count issue was updated based on the discussion in the last
> virtual meeting, and based on the comments sent to the mailing list from
> Haoyu. Hopefully the current text captures the discussion.
>
> Here is a link to the Github commit:
>
> https://github.com/inband-oam/ietf/commit/80a20d25bfcb1b0406a644005b12f9f2e85dd7ba
>
>
> Summary of the last virtual meeting:
>
> https://mailarchive.ietf.org/arch/msg/ippm-ioam-ix-dt/rHBfFHftx1JaTVA2gQoOWOq1hfk
>
> Haoyu's comments:
>
> https://mailarchive.ietf.org/arch/msg/ippm-ioam-ix-dt/TcYgy-uKNFjV5sJc0Vy5rEAnKRA
>
> Cheers,
> Tal.
>
> On Wed, Sep 18, 2019 at 12:35 PM Tal Mizrahi <[e-mail]>
> wrote:
>
>> IPPM IOAM Immediate Exporting Design Team
>> Virtual meeting
>> September 18th, 2019, 06:00 UTC
>> Webex meeting
>>
>> Attendees:
>> Shwetha Bhandari, Frank Brockners, Tal Mizrahi, Haoyu Song, Mickey
>> Spiegel.
>>
>> Minutes by Tal Mizrahi.
>>
>>
>> Summary:
>> ========
>> - Clarifying text will be added to the IOAM data draft regarding how to
>> handle unknown options or uknown flags.
>> - Haoyu will create a pull request with new text regarding the Hop Count
>> field.
>> - The flag draft will be revised, excluding the immediate export flag.
>> - Details about the next virtual meeting will be announced next week.
>>
>>
>> Introduction (Tal):
>> ===================
>> - The draft has been updated on Github:
>>
>> https://github.com/inband-oam/ietf/blob/master/drafts/versions/00/draft-ioamteam-ippm-ioam-direct-export-00.txt
>> - The main changes since the previous version are based on the discussion
>> in the last meeting. Two main changes:
>>   - Updated the "SHOULD" to a "MUST" in "A decapsulating node that does
>> not support the DEX option SHOULD remove it".
>>   - Updated the text about the Hop Limit based on the discussion on the
>> meeting. The text now presents the pros and cons of each of the
>> alternatives, and proposes to use the Hop_Lim/Node_ID data field when
>> necessary.
>>
>>
>> Decapsulating Node Discussion:
>> ==============================
>> Mickey: regarding the "SHOULD" that was changed to a "MUST", if a node
>> does not support direct exporting then it will not necessarily comply to
>> this requirement.
>> Tal: are you suggesting to add this requirement to the IOAM Data draft?
>> Frank: it is hard to specify this requirement differently. It is
>> important to avoid IOAM data leaking, and it is important for the readers
>> of this draft to be aware of this.
>> Mickey: the fact that the decapsulating node must remove all options
>> should go into the main data draft.
>> Tal: if it is mentioned in the data draft, then we should just mention it
>> in the current draft and add a reference to the data draft.
>> Mickey: it seems that this is related to the Namespace ID. It is a
>> question of whether the decapsulating node should only remove options in a
>> Namespace ID it recognizes, or should remove all options.
>> Frank: we do not have this statement in the data draft at this point.
>> Mickey: we need to add it.
>> Tal: in general we need to define in the data draft what we do about
>> unknown options, and what we do about unknown flags.
>> Mickey: it would be best to ignore them by transit nodes, and remove them
>> in decapsulating nodes.
>> Frank: just opened an issue about this on Github.
>>
>>
>> Hop Limit Discussion:
>> =====================
>> Haoyu: regarding the hop limit discussion, it looks like the current text
>> does not include the Hop Limit field in the DEX option. I am not sure we
>> are ready to decide to remove it yet.
>> Tal: there are two alternatives that are described, either to include an
>> explicit Hop Limit field, or to rely on the Hop_Lim/Node_ID data field. The
>> pros and cons of each option are desribed. Based on the discussion of the
>> previous meeting, the current text relies on the Hop_Lim/Node_ID data field.
>> Haoyu: as the text suggests, the two alternatives are not identical. The
>> Hop Limit field allows you to detect when there is an IOAM-capable node
>> that fails to send the exported packets to the collector.
>> Mickey: I agree that the two alternatives are not identical, but avoiding
>> an update by transit nodes is an advantage.
>> Haoyu: I suggest to ask the working group.
>> Tal:  this is still not a working group document, so it is early to ask
>> the working group. The people who are interested from the working group are
>> already involved in this discussion. It is up to us to decide. The current
>> text tries to reflect all the pros and cons of each alternative.
>> Haoyu: I suggest to change the "Hop Limit" to "Hop Count".
>> Mickey: it seems there are three alternatives here.
>> Haoyu: no, just two alternatives: either having a "Hop Count" field in
>> the IOAM DEX option header, or relying on the Hop_Lim/Node_ID data field.
>> The two fields are not identical.
>> Shwetha: one of the advantages of the Hop_Lim/Node_ID data field is that
>> the option is not modified by transit nodes. The exported data already has
>> enough information to know about packet loss, or failure to transport,
>> versus failure to export.
>> Haoyu: if you can find another way to see if there is a missing exported
>> packet from a transit IOAM node, that would be fine.
>> Shwetha: there may be another way to reach this requirement, not
>> necessarily by adding this field to the DEX option header.
>> Mickey: there are two cases: either there is a node that does not support
>> IOAM, or there is an IOAM-capable node that does not export data.
>> Haoyu: right, if you use a TTL field with the Hop_Lim/Node_ID data field,
>> you cannot distinguish between these two cases. You do not know whether
>> there is an IOAM-capable node that simply did not export.
>> Shwetha: we are assuming there is an operational layer that knows which
>> nodes are there, and detects when we are missing exported data from one of
>> the nodes, so this does not necessarily need to be done using this field.
>> Mickey: would the collector be doing something different in the two cases?
>> Haoyu: yes. Only in one of the cases there is a problem - if the
>> IOAM-capable node is not exporting correctly. The other case is okay.
>> Mickey: we already have a sequence number.
>> Haoyu: the sequence number serves a different purpose. it is used for
>> matching different exported packets from different nodes.
>> Mickey: there is an IPFIX sequence number.
>> Haoyu: the Flow ID and Sequence Number are used to match packets from the
>> same flow and from different nodes, but does not help in detecting a
>> missing packet from an IOAM-capable node.
>> Mickey: we have an implementation that allows you to correlate exported
>> packets without the Flow ID and Sequence Number.
>> Haoyu: but the Hop Count field is not related.
>> Frank: the Hop Count addresses a corner case. It does not solve a generic
>> problem. So it is not worth a lot of effort unless you get it for free.
>> Haoyu: if you use a TTL field you may be misled by IP routers that
>> decrement the TTL, but are not IOAM capable.
>> Frank: that is a very specific issue. It is a niche, and we do not
>> necessarily want to change the solution based on a niche. We discussed this
>> in the last meeting and it seems that you are the only one who supports
>> this field.
>> Haoyu: I am not sure we are ready to decide. I suggest to revise the
>> paragraph to clarify it.
>> Frank: would you create a pull request?
>> Haoyu: yes.
>>
>>
>> Other Issues:
>> =============
>> Tal: in the current draft we have removed open issues from the last
>> section. I will add the Hop Count back into the list of open issues.
>> Tal: are there any other open issues?
>> Frank: on a related note, the flags draft has been adopted. We need to
>> revise it. Based on the discussion here, we can probably remove the
>> immediate export flag.
>> Tal: yes, I will remove the immediate export flag, and revise the text
>> about the loopback flag based on the discussion on the mailing list.
>> Frank: you might want to send the Github draft to the mailing list before
>> posting an internet draft.
>>
>>