[Ippm-ioam-ix-dt] IOAM Virtual Meeting Minutes, January 22nd, 2020

[Tal Mizrahi <[e-mail]>]

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


Attendees:
Frank Brockners, Greg Mirsky, Tal Mizrahi, Mickey Spiegel.

Minutes by Tal Mizrahi.


Summary:
========
- Tal will wait to see if there are comments regarding pull requests #141,
#143, #145, and merge them.
- After posting an updated flag draft Tal will raise the open issues
regarding the flag draft and specifically regarding the loopback flag.
- The next virtual meeting will be in two weeks.


Introduction (Tal):
===================
- Tal: the agenda is to talk about open pull requests on github (
https://github.com/inband-oam/ietf/pulls). Any other topics?
- No responses.


#145: Removed the term collector
================================
- Tal: pull request regarding collector.
- Frank: consider "Receiving entities" instead of singular.
- Tal: makes sense. I am waiting to see if there are more comments, and
will then merge the pull request.


#141: Updated Loopback flag
===========================
- Tal: loopback - there is an open issue regarding how to handle the
reverse path, such that transit nodes do not push IOAM data to the
returning packet. One way to do this is to clear the "RemainingLen" field
when the packet is looped back.
- Greg: loopback is similar to DEX (Direct Exporting). Why don't we use the
DEX export format on the reverse path of loopback?
- Frank: we are not specifying the export format at this point, other than
Mickey's raw export draft. It is a question whether the export is in scope
or not. With loopback you do not need to define the exporting format in
order to implement the functionality of loopback. We will not be able to
get away with defining a loopback functionality without defining the format
of the returning packet.
- Greg: in MPLS, how do you know who is the source and what is the reverse
path?
- Mickey: in direct exporting we do not use a reverse path, but just export
the data to an external entity.
- Greg: there is no need to overload the data plane.
- Mickey: you can't teach all the nodes about the source of each packet.
- Greg: what do you do in MPLS?
- Tal: we added new text that says that loopback is only possible when the
reverse path is possible to trace from the source address.
- Frank: it does not make sense to mix loopback with direct exporting. In
loopback you have tracing information in the packet, and in DEX you only
have local information exported by each node, so it gives a different
result.
- Greg: there may be more technologies that do not have the source
information. NSH is also an example. Loopback may be limited in its
applicability.
- Frank: even if it was only applicable to IPv6, it would already be useful.
- Greg: we are looking for a generic technology.
- Frank: how will loopback work with the management plane?
- Greg: the management plane already plays a significant role in IOAM. The
collector can be use for path tracing. Loopback is a special case of DEX.
- Frank: it is a special case, but it provides a different result.
- Mickey: loopback also tells you that the information can go back to the
source, which is not something you know from DEX. Loopback also does not
depend on the export format.
- Tal: Greg - it sounds like you are suggesting to remove the loopback flag
completely. How can we make progress about this open issue?
- Frank: I agree with the proposal that RemainingLen = 0 when the packet is
looped back.
- Mickey: not sure if that will work. You can't necessarily tell the
difference between a looped back packet and a packet that just runs out of
space.
- Tal: other options are to either add IOAM data on the reverse path (which
is what the draft says right now), or to add a new flag that says "this is
a looped back packet on the reverse path".
- Frank: we do not want another flag.
- Mickey: how about a different IOAM type?
- Tal: how do you tell the forward from the reverse path?
- Mickey: the different IOAM type would be only on the reverse path.
- Frank: makes sense.
- Tal: would the new IOAM type be defined in a new draft?
- Mickey: maybe.
- Frank: bring it to the list.
- Tal: let's publish an updated version based on the existing pull
requests, and then raise the discussion on mailing list.


Data draft last call
====================
- Tal: regarding the data draft last call comments.
- Frank: editorial comments are simple. Two new data fields - that is a
bigger issue.
- Mickey: we have an interface ID, but we do not know the port ID, so how
do we know the context of the byte count?
- Frank: we are imposing requirements on the silicon, which may not be a
good idea.
- Mickey: the fact that we have two interface IDs makes it confusing. We
already have a queue occupancy, but we do not have a queue ID.
- Mickey: is "Interface Byte Count" good enough?
- Frank: then we will need to define what we mean.
- Mickey: "Interface Byte Count" relies on how you define Interface, which
is already there.
- Tal: so what are you suggesting? New field or leave it as is?
- Mickey: I am struggling about whether it should be now or at a later
point.
- Tal: the discussion on last call is still in progress. Should we wait?
- Mickey: how do we handle the remaining last call comments on the mailing
list?
- Tal: some of them are straightforward, and some of them need to be
explained on the mailing list.
- Mickey: there was a comment regarding the Hop Limit. We may need to be
more specific.
- Mickey: how do we define the term "IOAM capable"?
- Frank: I will work on the editorial changes. Regarding the bigger issues,
we will discuss them on the mailing list. Hopefully we can reach consensus
on the mailing list before Vancouver.