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

From: "Frank Brockners (fbrockne)" <[email-masked]>
Date: Tue, 1 Oct 2019 14:43:46 +0000

Hi Tal,

Thanks for the update. Per the earlier discussion: Could you separate the hop limit discussion into a dedicated section (e.g. “related considerations”), given that per-hop updates isn’t anything that Direct Export is expected to do. See also https://github.com/inband-oam/ietf/commit/80a20d25bfcb1b0406a644005b12f9f2e85dd7ba#r35312342

Thanks, Frank

From: Ippm-ioam-ix-dt <[email-masked]> On Behalf Of Tal Mizrahi
Sent: Sonntag, 29. September 2019 11:19
To: [email-masked]
Subject: Re: [Ippm-ioam-ix-dt] IPPM IOAM Immediate Exporting Design Team Meeting Minutes - September 18th 2019

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 <[email-masked]<mailto:[email-masked]>> 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 <[email-masked]<mailto:[email-masked]>> 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.

---

From: Tal Mizrahi <[email-masked]>
Date: Wed, 2 Oct 2019 08:57:06 +0300

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 <[email-masked]>
wrote:

> On Sun, Sep 22, 2019 at 12:18 PM Tal Mizrahi <[email-masked]>
> 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.
>>
>> On Wed, Sep 18, 2019 at 12:35 PM Tal Mizrahi <[email-masked]>
>> wrote:
>>
>>> - 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.
>>>
>>>
>>> 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.
>>> 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.
>>> 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.
>>> Tal: in general we need to define in the data draft what we do about
>>> unknown options, and what we do about unknown flags.
>>> 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.
>>> 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: 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.
>>> 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.
>>> Haoyu: the sequence number serves a different purpose. it is used for
>>> matching different exported packets from different nodes.
>>> 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.
>>> 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.
>>> 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.
>>> 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.