[Ippm-ioam-ix-dt] IOAM Meeting Summary, April 7th, 2021

[Tal Mizrahi <[e-mail]>]

...Apologies for not sending this out sooner.


IPPM IOAM Design Team
Virtual meeting
April 7th, 2021, 06:00 UTC
Webex meeting


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

Minutes by Tal Mizrahi.


Summary
=======
- Proposed DEX text to address the security issues was discussed. Tal
will update the proposed text.
- Haoyu presented a relatively new individual draft about IOAM E2E RTT
measurement.


Security Discussion
===================
Tal: I sent some proposed text to the mailing list. This text is
intended to be integrated into the DEX draft to address the security
issues that were raised.
https://mailarchive.ietf.org/arch/msg/ippm-ioam-ix-dt/VNTIGmxsRfKVD-OqRVWQ9K483QU/
Mickey: another point that should be added is implementing ACL
filtering in transit nodes.
Tal: so you suggest for transit nodes to check whether they are doing
IOAM processing on exported packets.
Mickey: right, every node between exporter and receiving entity.
Greg: I do not see why this is a problem in the first place.
Mickey: you need to target the exported traffic. ACL is a good start.
Not to include report packets in DEX trigger.
Greg: it depends on what the operator does. The problems we are
dealing with are generic to any exporting. It is true for DEX and for
hybrid two step collection. The operator should control how much
information is collected. Operators can use QoS to indicate whether
exported information is important.
Tal: the problem that was raised was if you export over a tunnel then
intermediate points do not necessarily know which packets are
exported, and their QoS.
Greg: it does not sound like a real scenario. An IOAM transit node
that exports DEX cannot start a new tunnel.
Mickey: I thought the main issue was an exported packet causing
secondary exporting.
Tal: so you agree with the new text about "Exported packets SHOULD not
be exported over a path or a tunnel...".
Mickey: but that is not a valid scenario.
Haoyu: I agree, but it does not hurt to add this sentence.
Micky: it should be generalized and say that we should avoid putting
IOAM on exported packets.
Tal: that makes sense.
Greg: DEX is an exported packet, not an IOAM packet.
Tal: right.
Greg: we need to make it explicit. The DEX exported packet is not an
IOAM packet.
Haoyu: nothing prevents you from adding an IOAM header to exported
packets and collect more data.
Greg: need to require that it does not happen.
Frank: let's put the sentence that exported packets should not be with IOAM.
Tal: right.
Greg: there is no benefit to tagging exported packets with IOAM.
Frank: why does the DEX draft even talk about exporting? You are not
necessarily exporting, but you may be doing internal processing. It is
not necessarily packet replication.
Tal: we may want to say that the exporting format is out of scope, and
specifically we can do aggregation or internal processing.
Frank: we may want to change the name of the document. Change the
state of mind, so that you do not necessarily want to export a packet
for each DEX.
Haoyu: it is more interesting and simpler to export every packet. It
is not clear how you aggregate.
Mickey: there are practical ways you can aggregate, and you do not
have to export everything.
Tal: I agree that we need to add text to clarify this, but this will
not solve the security issue that was raised here.
Frank: right, but still worth clarifying.
Mickey: in some cases you want to correlate across multiple points.
Frank: right, but we need to clarify the text.
Greg: the idea of aggregating data on the node and batch exporting is
interesting. Not specifying how this process is performed may cause
misconfiguration. Either part of the YANG model, or part of the IOAM
header should define this.
Frank: we are sending a DEX option, and there is a separate process
which is how it is exported and processed - this is not specified. We
should focus on the trigger, not on the way you export.
Greg: that is fair. That would be a reasonable scope. There is another
issue which is how to export.
Haoyu: we still need to address Martin's question.
Frank: you can have an informational paragraph about how it is used.
The exporting part would not be a normative part here.
Greg: what would be the normative part?
Frank: the DEX option format.
Greg: hybrid two step is another way of collecting data. If DEX is the
model where IOAM sends data to a collector, then the mechanism of how
to export data can be in another document.
Mickey: hybrid two step has to be in-band, i.e., on the same path as the data.
Greg: not necessarily. Topologically it is in-band, but not
necessarily in-band in QoS.
Mickey: DEX does not mandate a topological path.
Greg: the idea of DEX is that it triggers information from a single
path. Hybrid two-step collects along the path.
Mickey: right, you still need to get the information from the IOAM nodes.
Greg: collection is controlled by the IOAM header.
Mickey: I do not think aggregation should be defined in the spec. If
you just limit the traffic to a percentage of total traffic that
should work well even without aggregation.
Tal: I will add text that says that exporting is out of scope, and
that aggregation and internal processing are also possible.
Mickey: aggregation is a bit misleading. You can combine aggregation
with internal processing. Operator has to decide how to handle this.
Frank: clarify the scope of the document, specifically the abstract.
Greg: I agree.


IOAM E2E RTT Measurement Discussion
===================================
Haoyu presented an individual draft about E2E RTT measurement.
https://datatracker.ietf.org/doc/draft-song-ippm-inband-e2e-rtt-measurement/
Haoyu: we suggest to add a flag to the E2E option that indicates the
destination should reply.
Frank: only for E2E?
Haoyu: yes.
Mickey: but there is only one copy, contrary to the loopback in the flags draft.
Haoyu: the data draft does not specify the flag bits. Either we
allocate flags, or leave the data draft and propose updates to the
format in the current draft.
Greg: why are active OAM protocols not applicable here?
Haoyu: this is a dedicated measurement.
Greg: you are defining a new active protocol. For example sequence number, etc.
Haoyu: a sequence number is already defined there.
Greg: you need to add it. I do not support this. You need fate
sharing. Why do you want to create something that already exists?
Haoyu: are you asking why IOAM is needed?
Greg: you do not want IOAM to add functions that are already done
elsewhere. The use case has already been addressed. It is a test
packet, not a user packet. Why not use TWAMP?
Haoyu: the IOAM E2E is already there, we just want to add a new flag.
Greg: you are building a new protocol.