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

[Tal Mizrahi <[e-mail]>]

Webex details (ietf.webex.com) are as follows:

Meeting number (access code): 646 487 538
Meeting password: y2JXZa3H


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

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