Re: [Ippm-ioam-ix-dt] IPPM IOAM Virtual Meeting

[Tal Mizrahi <[e-mail]>]

Reminder: the next IOAM virtual meeting will be on April 22nd, 2020, 06:00
UTC.

Cheers,
Tal.

On Wed, Apr 1, 2020 at 9:43 AM Tal Mizrahi <[e-mail]>
wrote:

> IPPM IOAM Design Team
> Virtual meeting
> April 1st, 2020, 06:00 UTC
> Webex meeting
>
>
> Attendees:
> Shwetha Bhandari, Frank Brockners, Barak Gafni, Greg Mirsky, Tal Mizrahi,
> Mickey Spiegel.
>
> Minutes by Tal Mizrahi.
>
>
> Summary:
> ========
> - The IPPM virtual interim meeting that will take place later today was
> discussed.
> - Next virtual meeting will be on April 22nd, 2020, 06:00 UTC (the usual
> time).
>
>
> Detailed Discussions:
> =====================
> - Frank: the IPPM Interim is today. We sent the slides to the chairs. If
> there are any last minute changes - just use Google docs. The slides
> highlight the main issues that need to be discussed.
> - Barak: what was the open issue in the flag draft?
> - Tal: the loopback flag on the reverse path - transit nodes need to know
> that the packet is on the reverse path. Three alternatives: (1) new flag,
> (2) new IOAM type, (3) clear RemainingLen on the reverse path. We need to
> choose one of them.
> - Mickey: is the RemainingLen solution applicable to the preallocated
> version? Does not seem to work, since the decapsulating node will not have
> an indication of how much of the preallocated option was used.
> - Greg: are we allowing functionality for any flow, or for a specific
> flow? What is the data model?
> - Barak: we do not want to limit to a specific model.
> - Greg: we want to be able to apply IOAM to specific flows. Applying it on
> all the traffic may be too much.
> - Barak: we want to allow flow specific IOAM, but not mandate it.
> - Frank: the draft says that it is up to the operator whether to apply
> IOAM to all flows or subset.
> - Greg: maybe we should specify that the loopback function should be
> applied to specific flows based on a data model.
> - Mickey: we have been a bit avoiding this issue.
> - Greg: we need to use our resources carefully. What is the purpose of the
> loopback flag?
> - Barak: it has been discussed.
> - Greg: comment about the slides. Regarding IPv6 option - we are not
> necessarily ready for WG LC because the data draft should be done first, to
> avoid loading the WG members.
> - Frank: right, the chairs have typically sequenced these processes. It is
> not urgent.
> - Mickey: regarding the IPv6 code points - the most painful point is the
> first three bits, and that implementations that do not know what it is will
> pass it along, but implementations that do know what it is should drop it.
> - Frank: right, it may be a discussion topic.
> - Greg: the data draft is a priority.
> - Frank: right.
> - Mickey: yes.
> - Barak: it sounds like two independent decisions.
> - Frank: right, but all the encapsulation drafts have a normative
> reference to the data draft.
> - Mickey: do we need anything from 6man?
> - Shwetha: we will probably need WG LC to go through 6man as well.
> - Frank: either a formal WG LC, or just a call for feedback from 6man - it
> is up to the chairs.
> - Mickey: slide 5 - we are missing "not".
> - Tal: I will send an update of the slides.
>
>