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

[Tal Mizrahi <[e-mail]>]

Hi,

Following the summary from the last meeting, I am going to go ahead and
merge pull requests 141, 143, 145.

Cheers,
Tal.

On Wed, Jan 22, 2020 at 10:17 AM Tal Mizrahi <[e-mail]>
wrote:

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