[Ippm-ioam-ix-dt] IPPM IOAM Virtual Meeting, March 4th, 2020

[Tal Mizrahi <[e-mail]>]

IPPM IOAM Design Team
Virtual meeting
March 4th, 2020, 07:00 UTC
Webex meeting


Attendees:
Shwetha Bhandari, Frank Brockners, Barak Gafni, Greg Mirsky, Tal Mizrahi,
Mickey Spiegel, Haoyu Song.

Minutes by Tal Mizrahi.


Summary:
========
- Greg will review and give feedback about pull request 160 (
https://github.com/inband-oam/ietf/pull/160)
- Mickey will update pull request 161 about the timestamping point based on
the discussion below.
- Barak will propose text to address issues 153 and 154 (the first bullet
of 154).
- Tal will work on draft presentations for the DEX draft and flag draft.
- Frank will work on a draft presentation for the data draft.
- The next virtual meeting will be on the 11th of March at 07:00 UTC.


Introduction
============
- Tal: on the agenda today we want to talk about open issues in the data
draft, presentations for IETF 107, and Haoyu's new draft.
- Frank: who is going to attend IETF 107?
- All participants of this call will attend remotely.


Data Draft Open Issues
======================
- Shwetha: there is a pull request (160) that includes several changes that
address comments from WG LC. Mickey has also submitted a pull request (161).
- Frank: Greg, most of the comments were from you. Did you have a chance to
go over the pull request?
- Greg: not yet. I will.
- Shwetha: will appreciate if you can review the pull request. There is
also a comment from Mickey that I plan to incorporate.
- Frank: most of the changes are editorial, so no problem.
- Shwetha: Mickey has also added a pull request (161). Some of the open
issues in Github do not require any changes in the draft.
- Mickey: regarding issue 153 and 154 - these are on Barak.
- Barak: I will take a look.
- Mickey: regarding 154 there are two sub-issues there. One regarding the
queue depth, and the other does not require a change in the draft. We have
not concluded on the queue depth issue.
- Barak: we have not discussed the queue depth issue.
- Frank: I believe we discussed that currently we are not making changes in
the data fields, and may introduce such changes in the future.
- Mickey: did we conclude on this?
- Frank: I believe this was the understanding.
- Barak: I was not aware.
- Mickey: for #153, Barak was going to suggest text regarding the queue
depth units.
- Shwetha: regarding #151 and #152 we still need to consider. For #151 -
what happens if the SHOULD requirement (selective IOAM) is not satisfied.
- Mickey: it could be considered to change it to a MUST.
- Barak: I don't see how that makes sense.
- Frank: we need some text that talks about consequences of not having this
ability. Perhaps an example.
- Mickey: the SHOULD on independence between IOAM and encap - this is not
required.
- Frank: I suggest to rephrase this.
- Mickey: no need for an uppercase SHOULD.
- Tal: right, there is no need for normative language.
- Frank: I will rephrase and move this from a requirement to a scope
statement.
- Shwetha: issue #152 consists of a lot of sub-issues. How do we address it?
- Mickey: maybe we can avoid the term IOAM-capable?
- Frank: that may be the right approach. Maybe rephrase to a node that
supports the IOAM functionality described in this draft.
- Frank: regarding the units of some of the fields, again going back to the
question of defining units and whether we want that at this point.
- Mickey: I do not think we want that. Do we need to say anything in the
document?
- Frank: we may be able to avoid it. We can add some rationale for not
adding units.
- Barak: for timestamps we are defining units. For queue depth it is also
required.
- Mickey: for timestamps there are also a few options.
- Barak: right, very specific options.
- Frank: some more explanation here would make sense. A text suggestion
from Barak regarding units is expected.
- Mickey: regarding #156 - I tried to leave things flexible. The
administrator can determine the timestamping point.
- Tal: that means an implementer will have to implement all options. For
endpoints it may not be possible to implement all of them.
- Frank: that is right for endpoint.
- Mickey: for a switch I am not sure how you define this boundary.
- Shwetha: up to the implementer. The implementer would have to document
where the timestamping point is.
- Tal: right, that makes sense.
- Mickey: so we would leave it to the implementer?
- Frank: maybe we should say that the timestamping point is
implementation-specific, and the implementer has to document the
timestamping point.
- Barak: by "implementer", what do you mean?
- Frank: the equipment vendor.
- Barak: we usually think about a box.
- Frank: it will be implemented somewhere, a box, a NIC, a PC. In either
case it would be documented.
- Barak: it could be a software stack.
- Mickey: we are trying to nail something down in a way that makes sense.
Will update the pull request.
- Tal: I updated the security-related pull request (146) based on our
discussion from the last virtual meeting.
- Mickey: a comment about the v6 draft. The default behavior is to drop
something you do not understand. The codepoint we asked for should be
aligned with the default behavior.
- Frank: Mickey, can you please bring it up on the list? Let's close it on
email.


Presentations for IETF 107
==========================
- Tal: I will work on draft presentations about DEX and about the flag
draft.
- Frank: I will prepare one about the data draft.
- Frank: I have requested a slot for the working group documents.
- Frank: we can have one more meeting before IETF 107.
- Tal: then let's meet at the usual time on the 11th of March.