Giuseppe introduced the reason to have a joint session after invitation
from AD and the main goals of BMWG.
Marcus introduced the targets of IPPM.
Boris Khasanov: Happy to hear that there are open-source
implementations. Thanks for having this.
Marcus: Fully agree. Running code is a big plus.
Ritu Srivastava (chat): What are the used casestudies where measurement
are taken place?
Giuseppe: maybe good to follow up with Dan
Cancelled. Chairs will try to slot the presentation in on Thursday.
Marcus Ihlar: pushback regarding the quality classification mentioned in
the presentation; maybe interesting to see how this relates to QOO draft
so that apps determine their classification themselves.
Stuart Cheshire: Good suggestion, already working with Bjørn.
Benchmarking are useful because they reflect a customer experience.
Chris Box (chat): Thanks Stuart for sharing the information about beta
3. I look forward to trying the forced L4S mode and seeing what results
can be obtained.
Marcus: Again, good that we have the running code example for the STAMP.
Rakesh Gandhi: Yes.
Marcus: will consider adoption call for draft-gandhi-ippm-stamp-mpls-hdr
after this meeting
Giuseppe: We have a queue for last calls; will consider this after the
meeting. There is a related draft that is in 'if time permits' today;
maybe good to see if there is overlap that could be incorporated
(https://datatracker.ietf.org/doc/draft-samizadeh-bmwg-cni-benchmarking/)
Marcus: will consider WGLC for draft-ietf-ippm-alt-mark-deployment after
this meeting.
Giuseppe: open issue on draft-ietf-ippm-on-path-telemetry-yang. Welcome
comments.
Yunze Wei: Could you clarify the scope of the document further? scope of
the tests? performance or conformance or interop?
Vladimir Vassilev: Stateless traffic generation as specified in RFC2544.
It is more regarding performance, not really conformance or interop. You
can specify IP packets. However the IP transport properties, like TCP or
UDP is not in scope. Scapy might be more suitable.
Giuseppe: this should be next working group last call
Greg Mirsky: In RFC 9197, IOAM is being specified as Hybrid Type 1
Passive and In-Packet. In this draft, IOAM is given as example for
in-packet. So IOAM no longer hybrid type 1 but in-packet? do you want to
change terminology?
Tal Mizrahi: we are not intending to change the terminology.
Greg/Tal: some back and forth, discussing terminology nuances.
Greg: it seems like there is still a misunderstanding of the terminology
defined in the scope of ippm.
Greg: other question: did you say that ping is always non-path
congruent?
Tal: No, it's not necessarily path-congruent.
Giuseppe Fioccola: I also think that the in-packet definition overlaps
with Hybrid definition of RFC7799. It would be better to clarify this
point. Maybe a table to classify all the IPPM methods can help.
Thomas Graf: In Section 3.8 of RFC 7799, active and passive are two sub
categories of hybrid. I suggest to reflect that in this document.
Further, it would be helpful to clearly emphasis the reasoning of
in-packet as a sub category. That there also protocols why are
considered hybrid which are not modifying user packets.
Giuseppe: I think you are progressing well; one of the candidates for
future adoption
Giuseppe: Thanks for addressing my comments. will consider WG adoption
Luis Contreras: regarding the goal to benchmark subsystems. Do you have
a definition of what a subsystem would be? Different vendors could
define subsystems differently. Would be good to have a definition of
that in the draft.
Vladimir: It would be good to have a YANG model of the power consumption
Giuseppe: do you mean YANG model for testing efficiency?
Giuseppe: Do you plan to do hackathon test?
Luis: could be a good option, but logistics might be a challenge
Giuseppe: Two talks fell of the agenda; encourage speakers to send a
quick note to the mailing lists summarizing the main points + engaging
communities
note that time did not permit