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

[Tal Mizrahi <[e-mail]>]

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.