MIME-Version: 1.0
References: <CABUE3X=Yk8LCvGZJB+6_X-S6GeDHLF9nNwyW01SkH0fBYqCf8A@mail.gmail.com>
In-Reply-To: <CABUE3X=Yk8LCvGZJB+6_X-S6GeDHLF9nNwyW01SkH0fBYqCf8A@mail.gmail.com>
From: Tal Mizrahi <tal.mizrahi.phd@gmail.com>
Date: Wed, 8 Apr 2020 08:35:26 +0300
Message-ID: <CABUE3XkLDKu0UCK8bVor0i7xg4-ry2UzQeNEfrBVHEaaEdv5sQ@mail.gmail.com>
To: ippm-ioam-ix-dt@ietf.org
Content-Type: multipart/alternative; boundary="000000000000c5be8005a2c0de59"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ippm-ioam-ix-dt/4RvY-PekE6CcdqTKvjisW2ZW5pg>
Subject: Re: [Ippm-ioam-ix-dt] IPPM IOAM Virtual Meeting
Precedence: list

--000000000000c5be8005a2c0de59
Content-Type: text/plain; charset="UTF-8"

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 <tal.mizrahi.phd@gmail.com>
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.
>
>

--000000000000c5be8005a2c0de59
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Reminder: the next IOAM virtual meeting will be=C2=A0on Ap=
ril 22nd, 2020, 06:00 UTC.<div><br></div><div>Cheers,</div><div>Tal.</div><=
/div><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">O=
n Wed, Apr 1, 2020 at 9:43 AM Tal Mizrahi &lt;<a href=3D"mailto:tal.mizrahi=
.phd@gmail.com">tal.mizrahi.phd@gmail.com</a>&gt; wrote:<br></div><blockquo=
te class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px =
solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><font face=3D"mon=
ospace">IPPM IOAM Design Team<br>Virtual meeting<br>April 1st, 2020, 06:00 =
UTC<br>Webex meeting<br><br><br>Attendees:<br>Shwetha Bhandari, Frank Brock=
ners, Barak Gafni, Greg Mirsky, Tal Mizrahi, Mickey Spiegel. <br><br>Minute=
s by Tal Mizrahi.<br><br><br>Summary:<br>=3D=3D=3D=3D=3D=3D=3D=3D<br>- The =
IPPM virtual interim meeting that will take place later today was discussed=
.<br>- Next virtual meeting will be on April 22nd, 2020, 06:00 UTC (the usu=
al time).<br><br><br>Detailed Discussions:<br>=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D<br>- Frank: the IPPM Interim is today.=
 We sent the slides to the chairs. If there are any last minute changes - j=
ust use Google docs. The slides highlight the main issues that need to be d=
iscussed.<br>- Barak: what was the open issue in the flag draft?<br>- 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 I=
OAM type, (3) clear RemainingLen on the reverse path. We need to choose one=
 of them.<br>- Mickey: is the RemainingLen solution applicable to the preal=
located version? Does not seem to work, since the decapsulating node will n=
ot have an indication of how much of the preallocated option was used.<br>-=
 Greg: are we allowing functionality for any flow, or for a specific flow? =
What is the data model?<br>- Barak: we do not want to limit to a specific m=
odel.<br>- Greg: we want to be able to apply IOAM to specific flows. Applyi=
ng it on all the traffic may be too much.<br>- Barak: we want to allow flow=
 specific IOAM, but not mandate it.<br>- Frank: the draft says that it is u=
p to the operator whether to apply IOAM to all flows or subset.<br>- Greg: =
maybe we should specify that the loopback function should be applied to spe=
cific flows based on a data model.<br>- Mickey: we have been a bit avoiding=
 this issue.<br>- Greg: we need to use our resources carefully. What is the=
 purpose of the loopback flag?<br>- Barak: it has been discussed.<br>- 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 loadi=
ng the WG members.<br>- Frank: right, the chairs have typically sequenced t=
hese processes. It is not urgent.<br>- Mickey: regarding the IPv6 code poin=
ts - the most painful point is the first three bits, and that implementatio=
ns that do not know what it is will pass it along, but implementations that=
 do know what it is should drop it.<br>- Frank: right, it may be a discussi=
on topic.<br>- Greg: the data draft is a priority.<br>- Frank: right.<br>- =
Mickey: yes. <br>- Barak: it sounds like two independent decisions.<br>- Fr=
ank: right, but all the encapsulation drafts have a normative reference to =
the data draft.<br>- Mickey: do we need anything from 6man?<br>- Shwetha: w=
e will probably need WG LC to go through 6man as well.<br>- Frank: either a=
 formal WG LC, or just a call for feedback from 6man - it is up to the chai=
rs.<br>- Mickey: slide 5 - we are missing &quot;not&quot;.<br>- Tal: I will=
 send an update of the slides.<br>=C2=A0</font><br></div>
</blockquote></div>

--000000000000c5be8005a2c0de59--