[ippm] Re: Joint BMWG/IPPM chartering

Hi all,

Focusing on the “intrusive/non-intrusive” part (thanks Greg for raising that important point), this is one of the recurrent concerns raised against several of the specs such as UPDSPT or QoO recently. Gorry (WIT AD) was kind enough to provide support and help include guards to prevent misuses. However, we need to think about these matters early in the development of the specs and not wait for the last mile to fix them.

I created a PR that adds the following:

NEW:

“The WG will follow transport-related BCPs (mainly, BCP 133 on Specifying New Congestion Control Algorithms, BCP 145 on UDP Usage Guidelines, and BCP 208 on Network Transport Circuit Breakers) and will seek advice from the WIT area as needed.“

Cheers,
Med

De : Greg Mirsky <[email protected]>
Envoyé : mercredi 29 avril 2026 00:56
À : [email protected]
Cc : [email protected]; [email protected]; [email protected]; [email protected]; [email protected]
Objet : Re: [ippm] Joint BMWG/IPPM chartering


Hi Thomas,
Thank you for taking an interest in my notes and sharing your thoughts. Please find my follow-up notes below, tagged GIM2>>.

Regards,
Greg

On Mon, Apr 27, 2026 at 9:16 PM <[email protected]<mailto:[email protected]>> wrote:
Dear Greg,

Thank you very much for the feedback. As an individual, see my reply inline.

From: Greg Mirsky <[email protected]<mailto:[email protected]>>
Sent: Tuesday, April 28, 2026 1:16 AM
To: Graf Thomas, SCS-INI-NET-VNC-E2E <[email protected]<mailto:[email protected]>>
Cc: [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]>
Subject: Re: [ippm] Joint BMWG/IPPM chartering

Be aware: This is an external email.

Hi Thomas,
thank you for sharing the updated proposals. I appreciate the work put into the proposal. I read the proposed charter for the new WG, please kindly consider my notes below:

  *   The xxxx xxxx Working Group (xxxx WG) develops and maintains metrics, methodologies, and protocols that can be applied to the quality, performance, and reliability of data delivery services and applications running over public and private networks using IETF technologies.
While I agree that this is consistent with the IPPM WG's work, I cannot see how it applies to the scope of work performed in the BMWG. I have raised this concern several times: one of the major gaps between the two WGs is the environments for which the methodologies and procedures they specify are intended. The methodologies developed by the BMWG, AFAICS, from its current charter, are applicable in the lab environment, where an observer fully controls the network in all aspects, including configuration, offered payloads, and any changes to them. On the other hand, methodologies and protocols developed by the IPPM WG are intended for production networks, public or private, to provide operators with insights into network conditions with as little disturbance as possible to payloads. I don't think this statement closes the gap.

TG> I agree that this initial sentence doesn't address the difference between lab and production. I fully agree, this is, needs to be addressed, clearly in subsequent sentences. In my opinion, the "and" should be replaced with "or" in the " running over public and private networks" sentence.
GIM2>> I interpret "private networks" not as a synonym for "lab environment" as a private network may be a production network though not connected to the Internet. To me s/and/or/ in that sentence still leaves the domain studied by the BMWG outside of the scope of the new WG. Replacing "private" with "lab" might fix that.
GIM2>> After re-reading the list of the applicability, I notice that it misses an important metric that is measured only by methods developed by the BMWG - scalability. And this specificity so far has been outside of the scope for the work conducted by the IPPM WG.

TG> I think the following sentence should be change from

These metrics, methodologies, and protocols are designed as such that they can be used by network operators, end users, or independent testing groups in production or lab environments. Such metrics are intended to provide unbiased quantitative performance measurements.

to

These metrics, methodologies, and protocols are designed as such that they can be used by network operators and end users in production or independent testing groups in lab environments. Such metrics are intended to provide unbiased quantitative performance measurements.

Would that be better?
GIM2>>  It is, thank you.

  *   Where in lab environments the testing procedures ensure consistent, reproducible, and reportable benchmarking results.
And what is produced in a real production network? Would someone will measure, for example, how fast an implementation learns 100000 prefixes in a live network? Or what's the rate of MAC flushes in EVPN that serve a subscriber? This is another manifestation of the gap I see between the objects of study for the IPPM and the BMWG. And I don't see that the gap was closed or even narrowed.

TG> You do have a point here. In my opinion, reflecting your comment, the charter proposal lacks a sentence that measurements in production can't be intrusive, interfere with production management, control and data plane. Therefore I suggest to add the following sentence right after "Where in lab environments" or before.

Where in production environments non-intrusive measurement procedures ensure that production management, control and data plane performance impact is as minimal as possible.

What do you think?
GIM2>> I think that truly non-intrusive, per RFC 7799, measurement methods are passive observations. I think that if "non-intrusive" is removed, the sentence you propose will still deliver the intended point.

  *   The xxxx WG fosters commonality and comparability of metrics and measurements across IETF protocols at different layers.
This is a very appropriate clarification that could be in place before the first sentence in the preceding paragraph, i.e., before
The methodologies cover management, control, and forwarding planes and they apply to hardware, virtualized, and containerized network infrastructure (such as Data Center network fabric, SDN controllers, routers, and firewalls), including endpoints in production and lab environments.
TG> I agree that order make more sense to me as well.
In summary, my impression of the updated proposal for the new WG's charter is that the gap between the respective groups' areas of study remains. If the leadership sees a benefit in holding joint sessions during f2f meetings, I think that can be done without formally merging the IPPM and BMWG.

TG> Indeed that is also an option. Update both charters similar to the joint charter proposed here, keep both working groups separate, and continue with the joint sessions. This is why we chairs are gauging with polls the usefulness of joint meetings and we would like to hear more feedback in this thread on the proposed chartering.

Regards,
Greg


On Sun, Apr 26, 2026 at 1:02 AM <[email protected]<mailto:[email protected]>> wrote:
Dear BMWG and IPPM,

On behalf of the chairs. At IETF 125 we had a public joint chartering session onsite. In that session and during the discussion afterwards, we consolidated and simplified the existing charters

https://datatracker.ietf.org/wg/bmwg/about/
https://datatracker.ietf.org/wg/ippm/about/

for a new joint charter proposal

https://github.com/ietf-ippm/wg-charter/blob/main/ippm-bmwg-joint.md

Out of this exercise we highlight that the following items are specific to BMWG or IPPM today:

- applications running over public and private networks
- including endpoints in production and lab environments. Where in lab environments the testing procedures ensure consistent, reproducible, and reportable benchmarking results.
- The WG will also produce terminology documents and recommendations concerning the key performance characteristics of internetworking technologies, or benchmarks for network devices, systems, and services.

We added new items to the charter based on recent working group discussions

-           IETF protocols at different layers
-           documenting common security building blocks
-           The WG will also produce terminology documents and recommendations
-           the WG will specify related manageability aspects, such as YANG data models for configuration, operation, and Network Telemetry data export
-           Layer 2 applications can be covered as well but require explicit approval from the Responsible Area Director.
-           It specifically coordinates with other WGs such as MPLS, 6MAN, and SPRING where data plane encapsulations are specified.
-           The WG liaises with other Standards Development Organizations such as ITU-T, IEEE, 3GPP, and BBF and reaches out to other operator communities such as NANOG, RIPE, and APRICOT.

Many thanks to Carsten, Luis, Med, Qin, Marcus, Giuseppe and Sarah for this proposal.

We would like to get reviews and feedback on the joint charter proposal from both working groups. And in particular, we also invite BMWG and IPPM authors to check whether the newly proposed joint charter covers their work accurately.

-           Do you believe that this joint charter covers your existing and future work?
-           Do you believe it describes and scopes accurately the current and future work of both working groups?
-           Is something missing or should be omitted? Why?

Please comment on this thread and also feel free to open change proposals here: https://github.com/ietf-ippm/wg-charter/issues

We intend to follow up also with the MPLS, 6MAN, and SPRING working groups once this discussion is stabilizing.

Best wishes
Qin, Giuseppe, Sarah, Marcus and Thomas
_______________________________________________
ippm mailing list -- [email protected]<mailto:[email protected]>
To unsubscribe send an email to [email protected]<mailto:[email protected]>
____________________________________________________________________________________________________________
Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

_______________________________________________
ippm mailing list -- [email protected]
To unsubscribe send an email to [email protected]