[Ippm-ioam-ix-dt] IPPM IOAM Virtual Meeting Minutes, January 8th 2020

[Tal Mizrahi <[e-mail]>]

IPPM IOAM Immediate Exporting Design Team
Virtual meeting
January 8th, 2020, 07:00 UTC
Webex meeting


Attendees:
Shwetha Bhandari, Frank Brockners, Barak Gafni, Greg Mirsky, Tal Mizrahi,
Mickey Spiegel.

Minutes by Tal Mizrahi.


Summary:
========
- The next meeting will be held on January 15th 2020, and the remaining
pull requests will be discussed.
- Tal will remove the term "collector" wherever possible, and in general
replace it with the term "receiving entity", with an explicit definition.
This applies to both the data draft and the DEX draft.
- A Github issue (#144) will be added to the DEX draft regarding the
checksum complement bit - whether it should always be zero or not.
- Hop limit / hop count issue in the DEX draft - will be raised to the
working group as an open issue after the draft is adopted by the WG.


Introduction (Tal):
===================
- Tal: the agenda is to talk about open pull requests on github (
https://github.com/inband-oam/ietf/pulls). Any other topics?
- Barak: I would like to raise a new issue: additional data fields.
- Tal: we will discuss at the end if we have time.


DEX-related pull request (https://github.com/inband-oam/ietf/pull/137)
========================
- Tal: it looks like the main issue throughout this pull request is to get
rid of the term "collector". I suggest to clarify that exporting is not
specifically to an external node, but may also be to a source, a
destination, or a local agent. The data draft also mentions a collector.
- Barak: we do not want to talk about the collector, but about how you
export. Exporting should be abstract.
- Frank: the data draft only mentions the collector once. We can easily
change that.
- Barak: you may potentially have many exporters, and therefore it may
limit the design if you have a single collector.
- Tal: let's use a common term that captures all the options.
- Barak: let's look at the text.
- Frank: a set of entities that collect IOAM data. In the deployment draft
we make sure that all the exporting scenarios are covered. We are talking
about an entity that collects data for further processing.
- Barak: it may be just to store it.
- Tal: I suggest to get rid of unnecessary places where we use "collector",
and add aspecific definition.
- Frank: how about "receiving entity"?
- Tal: "receiving entity" - will add that. Also in the data draft.
- Barak: based on the current pull request.

- Barak: this pull request also include a change in the hop limit / hop
count text.
- Tal: we need to think about how to resolve this. This subsection - we
want to get rid of it anyway once we resolve the hop limit / hop count open
issue.
- Barak: let's raise the issue on the list.
- Frank: right, let's raise it, and see whether there is WG consensus.
- Tal: will bring it to the list.

- Barak: regarding the checksum complement in the DEX draft, the text
"should be assigned to be zero": I suggest it to be a MUST.
- Mickey: when you are exporting you are changing the packet, so maybe you
do need this data field.
- Barak: changing the hop limit would require a checksum update.
- Frank: that is another argument against the hop limit.
- Mickey: why would you care what the checksum is?
- Mickey: one way to export is to just act as a transit node and add the
data fields after the DEX. We may want to leave it a "should".
- Frank: let's reconsider it. For certain encaps the checksum complement is
necessary in order to avoid dropping the packet somewhere.
- Mickey: it depends on the exporting format.
- Barak: let's give it some more thought.
- Shwetha: an exported packet is a new packet anyway, so it would have a
new checksum.
- Mickey: it depends on how exporting is implemented.
- Barak: the encapsulating node adds a header anyway.
- Mickey: but transit nodes do not change the DEX.
- Barak: if the encapsulating node wants to push a DEX without changing the
checksum, then the checksum complement may be useful.
- Mickey: I always believed that the checksum complement should be optional.
- Frank: we need to think about how we want to solve this.
- Mickey: for conventional IOAM it may be useful.
- Frank: let's add an issue.
- Tal: I will add a Github issue for the DEX draft.


Data Units (https://github.com/inband-oam/ietf/pull/140)
==========
- Tal: this issue is related to the data draft, specifically to the Queue
Depth units. Currently the data draft defines that the units as memory
buffers. Barak suggested to use bytes.
- Barak: allows uniform processing across devices.
- Mickey: I do not agree with the change. For simplicity, it is best to use
buffer units.
- Frank: it is a philosophical problem. The timestamp format is similar -
we defined three timestamp formats. Regarding memory units - there may be
different architectures. We want to simplify implementations. If it is a
simple mapping from buffers to bytes, then it is not very difficult for the
collector.
- Barak: the problem is the processing at the collector may be device
specific.
- Frank: right, that is the case for various data fields.
- Shwetha: if you want to know where the congestion is you just need to
compare it against the specific node's architecture. That would be true for
byte units as well.
- Barak: we want to keep track of each node and its congestion status.
- Shwetha: you need to know the maximal queue depth anyway.
- Barak: not necessarily. We just want to know the depth of the queue,
regardless of the queue capacity.
- Shwetha: it is more useful to know the percentage of the queue fill level.
- Barak: if I want to know if the queue is above or below 100 K bytes it
requires byte units.
- Frank: if you want the queue length of 100 K bytes - what would you do
with that number?
- Barak: currently the collector cannot take an action based on byte
threshold.
- Frank: what is the motivation for a byte threshold?
- Barak: to keep the queues low.
- Frank: how does the operator compute this threshold?
- Barak: based on experience with customers, it makes life hard if you do
not know the units. Collector processing may be done in hardware, which
makes this processing difficult.
- Mickey: we may need to get into areas we did not consider so far, like
exporting to the source.
- Barak: software is not necessarily relevant for high speed processing.
- Frank: is it complicated to multiply the queue depth by a constant?
- Barak: the problem is that the constant may be different for each device.
- Mickey: we have the Namespace ID. Can it be used for this?
- Frank: that can be done in specific networks. That is what the Namespace
is for.
- Frank: changing the units this late in the game is a problem.
- Frank: if you think it is important, bring it up in the working group
last call. You may want to mention the Namespace option.
- Mickey: one can define a public Namespace, and still add some additional
functionality using your own Namespace ID.
- Barak: maybe the word "SHOULD" is more appropriate.
- Mickey: that is still a problem.
- Barak: we want to try to drive implementations towards a specific
direction.