Re: [Ippm-ioam-ix-dt] IPPM IOAM Virtual Meeting Minutes, July 22nd, 2020

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

Per the discussion in our last DT meeting: Here’s a draft set of slides to discuss the status of
draft-ietf-ippm-ioam-ipv6-options-01 – incl. the issue that Tom recently brought up on the mailing list:
https://docs.google.com/presentation/d/1ku4bbsjh45JHkOQuy93szMXHBDb7KCceJZbTpETvTuA/

Appreciate your comments/thoughts/edits.

Thanks, Frank

From: Ippm-ioam-ix-dt <[e-mail]> On Behalf Of Tal Mizrahi
Sent: Mittwoch, 22. Juli 2020 14:55
To: [e-mail]
Subject: [Ippm-ioam-ix-dt] IPPM IOAM Virtual Meeting Minutes, July 22nd, 2020

IPPM IOAM Design Team
Virtual meeting
July 22nd, 2020, 06:00 UTC
Webex meeting

Attendees:
Shwetha Bhandari, Frank Brockners, Barak Gafni, Tal Mizrahi.

Minutes by Tal Mizrahi.


Summary:
========
- The IOAM presentations for IETF 108 were discussed.
- The next meeting will be on the 12th of August.


IETF 108 Presentation Discussion
================================
Tal: regarding the DEX presentation, we still have the open issue of hop limit / hop count. I suggest we just describe the status of the draft, and ask the WG chairs for help with the open issue.
Barak: there was the PBT-M draft, which is open. Should it be to some extent integrated into the DEX document?
Frank: let's try to focus on what we have, and not try to have a too complicated solutions document.
Barak: IPv6 encap is also in IPPM. It is on the agenda.
Shwetha: the data draft is not on the agenda.
Frank: regarding the IPv6 options - we need to handle the concern of leaking information, and the proper use of the two flags in the option definition (which tell the router whether to skip the extension, discard the packet, etc.). There is an ongoing disucssion on the mailing list about how to prevent leaking; that routers must drop packets with the IOAM extension unless explicitly configured to handle IOAM extensions. A domain that contains non-IOAM nodes will drop packets - that is a problem. We have two possible approaches: (1) require every node in the IOAM domain to be IOAM capable, or (2) we put the '00' value, which means that routers not familiar with this extension should skip it.
Shwetha: here is the discussion: https://mailarchive.ietf.org/arch/msg/ippm/F3Ew6hBp6xihMajU7iV0hTtqPYo/
Barak: filtering should be done by firewalls, not routers.
Frank: this is an unresolved issue that we should raise. Implementers need some guidance. I will work with Shwetha on a slide or two that presents the issue. Let's see what the working group thinks.
Tal: flags draft - a couple of people said they will review the security part again.
Frank: better ping the people before the meeting.
Tal: will do that. There is also an open issue about the loopback on the reverse path.
Frank: you may want more details about this in the slides.
Tal: I will add a slide about the loopback open issue.
Frank: regarding the POT draft - was there a conclusion for the WG last call?
Tal: I will ping the SFC WG chairs.
Barak: what about IOAM over Geneve - what is the status of this draft?
Frank: still working on it, but not sure where it will be accepted, and we may consider just publishing as informational. We may want to raise this question on the mailing list.