Subject: [Ippm-ioam-ix-dt] IOAM Virtual Meeting, May 19th, 2021

From: Tal Mizrahi <[email-masked]>
Date: Thu, 20 May 2021 13:38:13 +0300

IPPM IOAM Design Team
Virtual meeting
May 19th, 2021, 06:00 UTC
Webex meeting

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

Minutes by Tal Mizrahi.

Summary
=======
- Tal will respond to Alvaro, Eric and Erik regarding the IESG
comments about the data draft.

Data draft - IESG comment discussion
====================================
Tal: on the agenda today we have the data draft IESG comments. Any other issues?
Greg: Hybrid two step draft if we have time.
Tal: Alvaro raised an issue about a Namespace ID that can be used to
disambiguate two overlapping Node ID spaces. The comment was that this
may need some discussion in the deployment draft.
Frank: Not sure we need that there. The deployment draft purpose is a
bit different, and there are many potential issues that do not all
belong in the deployment draft.
Tal: There was a comment about encapsulation independent pieces from
the deployment draft that may belong in the data draft.
Frank: It looks like it fits better in the deployment draft.
Tal: NodeLen definition is a bit ambiguous.
Frank: right, and as I responded to Ben, let's remove the second part
that transit nodes can ignore the NodeLen field.
Mickey: in some cases we may want to process the length based on the
IOAM trace type. But I am fine with removing the second part.
Frank: do you plan to refresh the raw export draft?
Mickey: yes, I plan to.
Frank: we may want to ask for WG adoption for the raw export draft.
Mickey: we will need some more active support.
Tal: RemainingLen MAY be assigned according to the MTU, and MUST be
decreased by a transit node. May be an inconsistency.
Mickey: I do not think this is an inconsistency. You may set the field
according to MTU or according to another criterion.
Frank: rephrase to make it clearer. The field is not a MAY - the MAY
only refers to the MTU.
Tal: any newly assigned data fields will need to be 4 octets long. We
need to specify that explicitly.
Frank: Ben also commented about that.
Mickey: it will need to be 4 octets long.
Frank: we can either exclude 8 octets data fields from the future, or
say that IOAM transit nodes that receive unknown bits will completely
ignore the IOAM option.
Mickey: another option would be to add padding up to NodeLen.
Mickey: NodeLen does not include the Opaque field which has a variable length.
Frank: my suggestion to Ben was that transit nodes will not touch it
if there is an unknown bit.
Mickey: I would suggest to also use the padding option.
Frank: ignore if it is not unknown is already mentioned in the document.
Mickey: that means if you want to add a new feature you have to
upgrade the entire network.
Tal: so we want to update the text to say that transit nodes either
ignore in this case or pad up to NodeLen.
Frank: let's go for assuming all the remaining fields are 4 bytes.
Transit nodes that do not know some of the fields may ignore the IOAM
option.
Tal: okay, I will suggest some text.
Frank: you may want to synchronize with Ben's comment.
Tal: there is a general comment about the fact that some fields are
not completely well defined, e.g., transit delay and queue depth.
Frank: this was a general comment from the IESG. We are trying to be
flexible for various implementations. We need to add some text here.
Tal: we will need to add some text here. How do we handle these
different updates?
Frank: let's create pull requests.
Tal: there was a comment from Eric about PMTU discovery.
Frank: it belongs in the deployment draft.
Tal: another question was regarding the "Random" field and its collisions.
Frank: this was commented elsewhere as well.
Tal: will add a reference to the PoT draft.
Tal: there was another question from Eric about how IOAM nodes know
what the length of the IOAM option is.
Frank: if you know the type you know the length.
Mickey: do we say anything about the length of the trace option?
Tal: we can add some text that clarifies that length is defined by
type for these two options.
Frank: let's try just sending a response about this without changing the text.