Subject: [Ippm-ioam-ix-dt] IPPM IOAM Virtual Meeting - July 1st - Minutes

From: Tal Mizrahi <[email-masked]>
Date: Mon, 20 Jul 2020 09:29:46 +0300

Apologies for the delay in sending the minutes.
Please note that the next virtual meeting will be in two days, and we will
focus on presentations for next week.

IPPM IOAM Design Team
Virtual meeting
July 1st, 2020, 06:00 UTC
Webex meeting

Attendees:
Shwetha Bhandari, Frank Brockners, Greg Mirsky, Tal Mizrahi, Mickey Spiegel.

Minutes by Tal Mizrahi.

Summary
=======
- Open Git issues regarding the data draft were discussed and assigned to
people.
- The next meeting will be on July 22nd at 06:00 UTC.

Discussion
==========
Frank: regarding the data draft, there are about 10 open issues on Github
that still need to be handled. Some of them are pretty small. We can go
over them and assign them.
Shwetha: are the -08 issues still relevant?
Frank: no, we can close them, and focus on the -09 issues.
Shwetha: Tal, do you want to take #171 regarding the number of authors?
Tal: yes, I sent a suggestion. We will wait a couple of more days to see if
there are any comments. I will take this issue.
Shwetha: I will take #172.
Frank: yes, it would be best to avoid lowercase language where possible.
Frank: regarding #173, as I suggested in the comment on Github, I will
clarify this issue.
Shwetha: I will take #173.
Tal: regarding #174, I think it is pretty similar to receiving a data field
you are not familiar with. Transit nodes should ignore, and decapsulating
nodes should decapsulate.
Frank: if you do not understand the field - ignore it.
Mickey: remaining length can't be "wrong". If it is too high, it just means
you can push the data fields.
Frank: in general if you can't parse the IOAM header it is an error.
Mickey: maybe we should go over the IOAM header fields and see which ones
can have errors. I do not see any fields in the trace header that can cause
the problem indicated in #174. I believe we have covered.
Tal: maybe it would be good to have a statement saying that if something
does not make sense in the IOAM header the transit nodes ignore, and the
decapsulating nodes decapsulate.
Mickey: I am not sure it is needed. It does not seem that there are any
fields that can give us trouble.
Mickey: is it assumed that the Namespace ID is always the first two bytes,
regardless of the IOAM type?
Frank: there is a wider question here of what you do when you do not
understand what you receive. This was specifically a problem in the IPv6
extension header. If you forward something you do not understand you may
leak information.
Mickey: what if the Namespace ID is a criterion for whether you drop or
not? For example, if the Namespace ID is relevant but you do not understand
something else - you should drop it, but if the Namespace does not make
sense - forward it.
Frank: in decap nodes, if you do not understand an option type - you drop
everything. We already have text that a decap node removes everything for a
particular namespace.
Mickey: there is already text that says that based on the namespace ID you
decide whether to remove options or not. Let's add that this applies to
IOAM types that you do not understand. Transit node: if it is an IOAM type
you do not understand then just ignore it - where should we state this?
Mickey: what do we do about unknown POT type?
Frank: ignore and carry on.
Mickey: you can assign #174 to me.
Frank: #175 - do we want to do something here?
Mickey: there is no point. You are not supposed to parse it anyway. I agree
with closing the issue.
Frank: let's add a comment that it does not make sense.
Greg: let's tone down the language on that comment.
Mickey: the collector does not look at that anyway.
Frank: regarding #176 - we need some guidelines for an expert review.
Tal: I will take #176 and suggest text.
Shwetha: #177 is pretty straightforward.
Tal: I can take that as well.
Frank: #179 on manageability - I believe we do not need to do much here. It
would be best to add a reference to the deployment draft. No point in
replicating text.
Mickey: what is this discussion on 'congest'?
Shwetha: it was related to the loopback flag and the DEX option.
Replicating data packets could cause congestion.
Frank: the fact that we are changing the packet source - that is a fair
point.
Mickey: the word 'congest' may not be the right word.
Frank: let's add a manageability section with a single line, referencing
the deployment draft.
Shwetha: this reference may delay the publication.
Greg: it may be a misref if it becomes a normative reference.
Frank: let's start with a short section, and if it is fine with the OPS
people we will go with that. Otherwise, we can copy some text from the
deployment draft.
Frank: #180 on PMTU - we have a suggestion that seems to be fine. Let's go
with that.