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

[Tal Mizrahi <[e-mail]>]

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.