[ippm] Re: 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 <Thomas.Graf-Zc0CTiu5wcBWk0Htik3J/[email protected]> wrote:

> Dear Greg,
>
>
>
> Thank you very much for the feedback. As an individual, see my reply
> inline.
>
>
>
> *From:* Greg Mirsky <[email protected]>
> *Sent:* Tuesday, April 28, 2026 1:16 AM
> *To:* Graf Thomas, SCS-INI-NET-VNC-E2E <Thomas.Graf-Zc0CTiu5wcBWk0Htik3J/[email protected]>
> *Cc:* [email protected]; [email protected]; [email protected];
> [email protected]; [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 <Thomas.Graf-Zc0CTiu5wcBWk0Htik3J/[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]
> To unsubscribe send an email to [email protected]
>
>

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