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

["Frank Brockners (fbrockne)" <[e-mail]>]

Thanks Barak. I’ve replied to your suggestion on #153.
Wrt/ #154: Given that the data draft is very close to the finish line, I agree that net new functionality should be covered by new/future drafts.

Cheers, Frank

From: Ippm-ioam-ix-dt <[e-mail]> On Behalf Of Barak Gafni
Sent: Freitag, 6. März 2020 19:14
To: Barak Gafni <[e-mail]>; Tal Mizrahi <[e-mail]>; [e-mail]
Subject: Re: [Ippm-ioam-ix-dt] IPPM IOAM Virtual Meeting, March 4th, 2020

I have just posted a new suggestion for issue #153, please review
Re issue #154 – we should agree whether to add new measurements to the data draft, which I understand the team is leaning towards writing new drafts for such. Please comment

Thanks,
Barak

From: Ippm-ioam-ix-dt <[e-mail]<mailto:[e-mail]>> On Behalf Of Barak Gafni
Sent: Wednesday, March 4, 2020 6:00 PM
To: Tal Mizrahi <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>
Subject: Re: [Ippm-ioam-ix-dt] IPPM IOAM Virtual Meeting, March 4th, 2020

Thank you Tal for the summary,

Tal, as the one took the action on the slides for DEX:
For the DEX presentation – I would like to suggest adding a slide to reconsider IPv4 options as an encapsulation for DEX. Two major issues that were introduced in the past were regarding modifying IPv4 options at intermediate devices as well as the limited size available within these options. Both are solved by DEX, so I believe that it makes sense to reconsider this route, as this is the only clean way I can see as of today to make IOAM available for IPv4. I can work with you on such slide.

Thanks,
Barak

From: Ippm-ioam-ix-dt <[e-mail]<mailto:[e-mail]>> On Behalf Of Tal Mizrahi
Sent: Wednesday, March 4, 2020 12:10 AM
To: [e-mail]<mailto:[e-mail]>
Subject: [Ippm-ioam-ix-dt] IPPM IOAM Virtual Meeting, March 4th, 2020

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<https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Finband-oam%2Fietf%2Fpull%2F160&data=02%7C01%7Cgbarak%40mellanox.com%7C54cfccb9714943ab1dfc08d7c0a90cc0%7Ca652971c7d2e4d9ba6a4d149256f461b%7C0%7C1%7C637189704622354983&sdata=%2F7U0NWZcYapwPM8pvThmssykChX2zSr1L7EmT2uMKNA%3D&reserved=0>).
- 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.