[ippm] Re: Joint BMWG/IPPM chartering

Hi Carsten,
Thank you for sharing your perspective on the proposed merger between IPPM
and BMWG. It's invaluable as a reflection on the remarkable work of the
EANTC. Please find my notes below, tagged GIM>>.

Regards,
Greg

On Tue, Apr 28, 2026 at 1:43 AM Carsten Rossenhoevel <[email protected]> wrote:

> Hi Zafar, All,
>
>
>
> I have attended BMWG for a while.  From my point of view, several pain
> points will be resolved by a merger:
>
>
>
>    1. Benchmarking challenges move away from the user plane; in the
>    future, the management plane, telemetry, and automation will keep us busy.
>    With technological evolution, the scope of BMWG and IPPM is naturally
>    converging.
>
> GIM>> I think that benchmarking of the data plane will remain important to
operators and vendors. Equally important, in my opinion, is benchmarking of
the elements of the management and control planes. I agree that BMWG and
IPPM domains of interest overlap on the data plane but the measurement
conditions and methodologies are distinctly different.

>
>    1.
>    2. Standards are better when they are well peer-reviewed. BMWG has had
>    a steady but extremely small community; our drafts often take a long time
>    and/or receive only a few reviews.  In IPPM, the community is a bit larger
>    but could benefit from further growth, too, I believe.  In both WGs, mostly
>    very specialized long-term domain experts attended (which may explain some
>    of the resistance against a merger 😉).  I see benefits in
>    cross-pollinating and broadening our respective views.
>
> GIM>> I agree that cross-pollination of expertise across WG is beneficial
but merging established groups doesn't seem like the right way to achieve
that. If I extend your argument, merging all groups in the given area could
increase peer-review of drafts and speed up the process even further. And
merging all areas, all directorates would maximize these metrics. But I
don't think that that is the path we want to go. IETF has other ways to
reach out across WGs and directorates for the expertise and feedback.

>
>    1.
>    2. The IETF experiences continued growth of the number of WGs, which
>    requires resources, jams the meeting calendar, and fragments IETF work
>    increasingly.  I feel we shall do our bit to clean up the mess.  BMWG was
>    established in 1989, and IPPM in 1997 (if Gemini is right; I wasn’t there
>    👴). Both WGs have undergone five to six charter reformulations each
>    over the last 30 years (again, trusting Gemini). Our work areas have
>    evolved, and so could the structures.
>
> GIM>> Some WGs live long and productive lives, some are closed once they
achieve their goals.

>
>    1.
>
>
>
> Best regards, Carsten
>
>
>
>
>
>
>
> *From:* Zafar Ali (zali) <zali=40cisco.com-Tr9gZwTxerDR74oF6e/[email protected]>
> *Sent:* April 28, 2026 8:13
> *To:* Thomas.Graf-Zc0CTiu5wcBWk0Htik3J/[email protected]; [email protected]; [email protected]
> *Cc:* [email protected]; [email protected]; [email protected]; Zafar
> Ali (zali) <[email protected]>
> *Subject:* [bmwg] Re: Joint BMWG/IPPM chartering
>
>
>
> Hi Thomas
>
>
>
> “Many" have argued against the merger of the WGs, including the point that
> the problem you are trying to solve cannot be solved by simply merging the
> WGs.
>
>
>
> The first question is - should the WGs be merged?
>
> What is wrong with keeping the WG as per the original intention (and
> addressing the root cause of the problem you are trying to solve with the
> merger)?
>
> Thanks
>
> Regards … Zafar
>
> *From: *Thomas.Graf-Zc0CTiu5wcBWk0Htik3J/[email protected] <Thomas.Graf-Zc0CTiu5wcBWk0Htik3J/[email protected]>
> *Date: *Tuesday, April 28, 2026 at 12:42 AM
> *To: *Zafar Ali (zali) <[email protected]>; [email protected] <[email protected]>;
> [email protected] <[email protected]>
> *Cc: *[email protected] <[email protected]>; [email protected] <
> [email protected]>; [email protected] <[email protected]>
> *Subject: *RE: Joint BMWG/IPPM chartering
>
> Dear Zafar,
>
>
>
> Thanks a lot for the honest feedback.
>
>
>
> The meeting minutes for IETF 124, interim after and IETF 125 are available
> here:
>
>
>
> https://datatracker.ietf.org/doc/minutes-125-ippm-202603190100/
>
> https://datatracker.ietf.org/doc/minutes-interim-2025-ippm-01-202511201300/
>
> https://datatracker.ietf.org/doc/minutes-124-ippm-202511051430/
>
>
>
> See below my feedback inline.
>
>
>
> Best wishes
>
> Thomas
>
>
>
> *From:* Zafar Ali (zali) <[email protected]>
> *Sent:* Monday, April 27, 2026 10:05 PM
> *To:* Graf Thomas, SCS-INI-NET-VNC-E2E <Thomas.Graf-Zc0CTiu5wcBWk0Htik3J/[email protected]>;
> [email protected]; [email protected]
> *Cc:* [email protected]; [email protected]; [email protected]; Zafar
> Ali (zali) <[email protected]>
> *Subject:* Re: Joint BMWG/IPPM chartering
>
>
>
> *Be aware:* This is an external email.
>
>
>
> Dear chairs and the WG
>
>
>
> I am surprised to see this email.
>
>
>
> Given the discussion in Montreal (WG session, ops area) and the following
> interim meeting, I the feedback from most was that these WGs should not be
> merged. I am not reiterating the comments from many (please see minutes,
> recording).
>
>
>
> TG> I have participated all 3 sessions and also the chartering session and
> I have seen different feedback. Some of them supportive. Some of them
> against. I believe we have both. As an individual, from the chartering
> session my impression was that both working groups have much in common but
> there are clear distinct features between IPPM and BMWG. However I believe
> this can be accommodated in a joint charter.
>
>
>
> TG> As chairs we have started with IETF 125 to poll specific questions to
> gauge the possible pain points so that we can address them better. One
> clear outcome was that the time allocated did not facilitate enough time
> for discussions. The last minute additions in proposed work did not help,
> and was in the past already with IPPM a challenge. Therefore similar to
> other working groups we decided to add some buffer time next IETF in case
> discussions need more time and also requested a second session slot in case
> we need to accommodate for more proposed work.
>
>
>
> I have not heard any consensus on the need for a merger (sorry if I missed
> it).
>
>
>
> TG> This is a proposed charter. Similar as with the join sessions we would
> like to understand from an actual charter proposal what the community
> feedback, proposals and possible concerns are.
>
>
>
> TG> Attendance indicates that IPPM and BMWG needs to find ways to improve
> the allocated time and resources better. This is the driver between the
> joint sessions and proposed joint charter.
>
>
>
> Are we putting cart before the horse?
>
>
>
> TG> Certainly not. I would appreciate your feedback on the proposed
> charter.
>
> Thanks
>
> Regards … Zafar
>
> *From: *Thomas.Graf-Zc0CTiu5wcBWk0Htik3J/[email protected] <Thomas.Graf-Zc0CTiu5wcBWk0Htik3J/[email protected]>
> *Date: *Sunday, April 26, 2026 at 4:02 AM
> *To: *[email protected] <[email protected]>; [email protected] <[email protected]>
> *Cc: *[email protected] <[email protected]>; [email protected] <
> [email protected]>; [email protected] <[email protected]>
> *Subject: *[ippm] Joint BMWG/IPPM chartering
>
> 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]
> To unsubscribe send an email to [email protected]
>

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