[Ippm-ioam-ix-dt] IPPM IOAM Virtual Meeting Summary, May 6th, 2020

Tal Mizrahi <tal.mizrahi.phd@gmail.com> Mon, 11 May 2020 05:34 UTC

MIME-Version: 1.0
From: Tal Mizrahi <tal.mizrahi.phd@gmail.com>
Date: Mon, 11 May 2020 08:34:06 +0300
Message-ID: <CABUE3Xni69UL=OWuLNLRWU0aONJP6OmfuM7wjTPisc6P_LL_Ng@mail.gmail.com>
To: ippm-ioam-ix-dt@ietf.org
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ippm-ioam-ix-dt/Df-W3zBDncCObD_IKviROrg2kEM>
Subject: [Ippm-ioam-ix-dt] IPPM IOAM Virtual Meeting Summary, May 6th, 2020
Precedence: list

IPPM IOAM Design Team
Virtual meeting
May 6th, 2020, 06:00 UTC
Webex meeting

Attendees:
Shwetha Bhandari, Barak Gafni, Greg Mirsky, Tal Mizrahi, Mickey Spiegel.

Minutes by Tal Mizrahi.

Summary:
========
- The next meeting will be on May 20th, 2020 at 06:00 UTC.
- Tal will ping the mailing list regarding the Hop Count issue.
- Tal will raise the DEX optional fields issue on the mailing list.
- Barak will talk to the AD regarding how to make progress with the IPv4 draft.


Introduction:
=============
Tal: the Direct Exporting draft is one item that should discussed
today. Any other items?
Barak: I would like to raise the IPv4 draft again.
Tal: sure, let's start with the DEX draft.


Direct Exporting (DEX) Draft:
=============================
Hop Count Issue
Tal: there are two possible options, as discussed in the draft: either
to have a Hop Count field, or to use the existing Hop Limit data
field.
Barak: I understand that the Hop Count is related to TTL. This is not
a good idea.
Tal: the way I understand it is the Hop Count is just a counter that
is incremented by each IOAM node, so it is not related to the TTL of
lower layers.
Shwetha: I understood that this field is related to TTL as well.
Tal: just to make sure we are on the same page: the draft presents two
different suggestions: one is to have a Hop Count field that is
incremented by each IOAM transit node independent of lower layer TTLs,
and the other is to use the Hop Limit data field, as discussed in the
data draft.
Barak: having transit nodes update the DEX header is against what we
tried to do in DEX, which is to have transit nodes forward the packet
without modification.
Tal: some of the people in the WG still do not agree, and we have two
different opinions. How do we proceed?
Mickey: some say that modifying the packet is against what we want.
Others argue that copying the TTL from lower layers only gives partial
information.
Barak: why are we reinventing the wheel? There is already a TTL in the
IP header.
Tal: I can raise it on the list again, and will need people to respond
with their opinion.
Mickey: I am not sure I understand the advantage of the Hop Count field.
Barak: if we follow the spirit of the IOAM data draft, it is natural
to go with the Hop_Lim/Node_ID data field.
Mickey: so you are saying that any advantage of the Hop Count would
apply to the data draft as well?
Barak: yes.
Tal: I will raise it on the list.

Length Issue
Tal: the second issue regarding the DEX draft is the fact that we have
two different variants, 8 octet long and 16 octet long. The draft
currently says that we distinguish between the two using the lower
layer length field. An issue was raised by the working group that this
approach will prevent us from adding fields in the future.
Mickey: I agree with the comment.
Tal: one way to go is to use the flags in the DEX header to indicate
which optional fields are present.
Mickey: you can use two flags, one for each field.
Tal: that is possible.
Shwetha: I agree that we should have a separate flag for each optional field.
Tal: will update the draft.
Greg: this is a working group draft, please aske the WG first.
Tal: right, needs to be approved by the WG, but we can always change
it back if there are strong objections.
Greg: better take it to the list.
Tal: I will take it to the list.


IOAM IPv4 Draft
===============
Barak: I believe we should pursue the IPv4 draft. There were two
arguments against this draft in the past. One is that IPv4 options are
too short for IOAM, and the second was that we do not want to modify
IPv4 options by transit nodes. I believe that with DEX we can bring
back the IPv4 draft.
Tal: I would also like to see a solution over IPv4. There was also an
argument that the IETF does not define new IPv4 options. It would not
be simple to convince people to approve this.
Greg: right, IPv4 is considered legacy.
Mickey: right, the general opinion is not to touch IPv4.
Greg: we may want to go with informational or experimental. Maybe we
can talk to the AD, and see what can get through.
Barak: does experimental make sense here?
Greg: the most important thing is interoperability. Experimental
allows us to publish a document that would enable interoperability.
Talk to the AD.
Mickey: another idea is to consider something that is not an IPv4
option. For example, you can use a UDP header, as was suggested for
INT.
Barak: that affects ECMP and ACLs.
Mickey: right, but you have a higher probability of succeeding to publish it.
Barak: I am not sure that a UDP tunnel is a good idea.
Greg: X-over-UDP is already something that exists.
Mickey: we have been going in circles around IPv4 for a while.
Barak: was there a follow up on the suggestion to have IPv6 extensions
over IPv4?
Mickey: Was it suggested by Tom Herbert?
Shwetha: this suggestion did not progress so far.
Shwetha: it is a steep uphill. Will not be easy.
Tal: better talk to the transport AD, and see if they agree with this
approach. If they do they can take it with the INT AD.
Barak: I will try to take it with the AD.

[Ippm-ioam-ix-dt] IPPM IOAM Virtual Meeting Summa… Tal Mizrahi