[ippm] Re: [Green] Re: [bmwg] Re: draft-ietf-bmwg-powerbench

["[e-mail]" <[e-mail]>]

Hi GenChen,

On 25/08/2026 11:09, Chengen(GenChen) wrote:
>
> Hi Benoit and All,
>
> Based on the initial review of the GREEN and BMWG power/energy drafts, 
> I would like to propose the following three alignment issues and 
> potential optimization directions.
>
> 1. Power Measurement states in the BMWG draft to be aligned with GREEN 
> Power State
>
> Issue: The BMWG draft defines five power measurement states (Base, 
> Idle, Idle+, Typical, and Power with Traffic Load). The term 
> "low-power mode" appears once in the Idle and Idle+ power measurement 
> description, but no explicit mapping to GREEN's "Power State" concept.
>
> Potential Optimizations: BMWG draft to explicitly mention in its five 
> measurement states to consider the GREEN Power States info for 
> reference, the existing "low-power mode" reference to be aligned with 
> GREEN's Power State taxonomy.
>
That would be welcome, absolutely, specifically in light of the 
"Adoption of draft-many-lsr-power-group" email thread, it's important to 
align the power states.
Taking into account this brand new draft 
draft-claise-green-capability-discovery, 
<https://datatracker.ietf.org/doc/draft-claise-green-capability-discovery/>which 
provides this power state capability discovery

      augment /sysc:system-capabilities:
        +--ro power-state-capabilities
           +--ro unit-multiplier?        identityref
           +--ro supported-power-state* [power-state]
              +--ro power-state      identityref
              +--ro nominal-power?   uint32
              +--ro max-power?       uint32
      augment /sysc:system-capabilities
                /sysc:datastore-capabilities
                /sysc:per-node-capabilities:
        +--ro power-state-capabilities
           +--ro unit-multiplier?        identityref
           +--ro supported-power-state* [power-state]
              +--ro power-state      identityref
              +--ro nominal-power?   uint32
              +--ro max-power?       uint32

Knowing the nominal-power and max-power per power state (assuming that 
we can set it globally for the DUT) is typically something done by BMWG, 
hence draft-ietf-bmwg-powerbench. So aligning the power sates is key.

Let's keep in mind, as described in 
draft-claise-green-capability-discovery 
<https://datatracker.ietf.org/doc/draft-claise-green-capability-discovery/>:

        may be provided at implementation
        time as YANG instance data per RFC 9195 so that an Energy Management
        System can learn a platform's Power State capabilities before the
        equipment is deployed or even powered on.

So from a device development life cycle point of view
     1. benchmarking the DUT, draft-ietf-bmwg-powerbench, ideally per 
power state
     2. creating the RFC9195 instance of 
draft-claise-green-capability-discovery, to be shared BEFORE the device 
is shipped to the operators, to prepare the controller.
     3. once shipped, discovering the capability 
draft-claise-green-capability-discovery from the device.
     4. once in production, refinement of the advertised values based on 
traffic mix/temperature/etc., using draft-ietf-green-power-and-energy-yang

All these should work smoothly together.

> 2. EER Definition Alignment
>
> Issue: GREEN draft defines EER using total throughput while BMWG draft 
> defines EER using weighted throughput.
>
> Potential Optimizations: GREEN draft to update its EER definition to 
> clarify using both NDR-based total throughput and weighted throughput 
> meet the requirement as they have linear relationship.
>
I see  Energy Efficiency Ratio specified in the terminology draft, but 
not in the framework or YANG module drafts?
So in which context do we use it in GREEN (the use case draft will not 
be standardized)
>
> 3. Traffic Model Definition in GREEN
>
> Issue: GREEN terminology currently lacks any traffic model 
> definitions. BMWG uses traffic type (IMIX or rfc2544 packets), load 
> levels (e.g., 0%/30%/100%), and weighting factors (Bi) without 
> foundational terminology in GREEN.
>
> Potential Optimizations: Add to GREEN terminology Traffic Model 
> (traffic mix, load levels, weighting factors).
>
We could add this definition, no problem but in which context? Just to 
mention that the power depends on the traffic mix?

Regards, Benoit
>
> BMWG draft to reference these GREEN terms where it uses traffic type, 
> load levels and weighting factors.
>
> BR,
>
> GenChen
>
> *From:* [e-mail] <[e-mail]>
> *Sent:* 2026年8月25日 0:15
> *To:* Chengen(GenChen) <[e-mail]>; Marisol 
> <[e-mail]>; [e-mail]
> *Cc:* Getting Ready for Energy-Efficient Networking Discussion List 
> <[e-mail]>; bmwg <[e-mail]>; ippm <[e-mail]>
> *Subject:* Re: [Green] Re: [bmwg] Re: draft-ietf-bmwg-powerbench
>
> Dear all,
>
> On 23/07/2026 13:26, Chengen(GenChen) wrote:
>
>     Hi All,
>
>     I agree with Marisol and would like to emphasize the following points.
>
>     1. The two efforts are complementary without conflict. BMWG doc
>     addresses offline laboratory power measurement and benchmarking,
>     while GREEN docs focuse on online energy monitoring and energy
>     management for live network operations.
>
> Complimentary but terribly aligned.
> https://datatracker.ietf.org/doc/html/draft-ietf-bmwg-powerbench 
> figure 1 is completely aligned with figure 3 in 
> https://datatracker.ietf.org/doc/draft-ietf-green-framework/
> The fact that the BMWG document focuses on a DUT in lab, as opposed to 
> the GREEN one that focuses on a real device with a physical meter, is 
> not that important.
> Both uses the Metering Relationship relationship
>
>     ​
>
>     2. Terminology and metrics need joint review. BMWG shall extend
>     based on GREEN’s foundational terminology and metrics, instead of
>     defining separate standalone vocabulary. Cross review is essential
>     to prevent inconsistent semantics.
>
> Yes, please.
>
>     ​
>
>     3. The BMWG doc may elaborate on lab measurement precision,
>     relationship properties and fundamental measurement capabilities,
>     and clarify how offline benchmark measurements can align with
>     GREEN-defined base policies.
>
> Even if we know that BMWG uses the DUT as black box, it would great to 
> know the DUT Power State.
>
> Regards, Benoit
>
>     BR,
>
>     Genchen
>
>     *发件人：*Marisol <[e-mail]>
>
>     *收件人：*[e-mail] <[e-mail]>
>
>     *抄****送：*Getting Ready for Energy-Efficient Networking Discussion
>     List <[e-mail]>;bmwg <[e-mail]>;ippm <[e-mail]>
>
>     *时****间：*2026-07-23 11:31:09
>
>     *主****题：*[bmwg] Re: [Green] draft-ietf-bmwg-powerbench
>
>     Hi Med,
>     this might require a bit more time, but now that we are still in
>     Vienna, and we can discuss things "life" just want to highlight a few
>     things.
>
>
>     PowerBench defines a laboratory benchmarking methodology,  under
>     controlled conditions.
>     The consideration for PowerBench is to have external Power Meter
>     measuring PSU input power on a Device Under Test (DUT) under
>     controlled traffic loads. It is not an operational monitoring
>     framework.
>     This distinction is important: GREEN is about what a device reports
>     about itself during operations;
>     PowerBench is about what an external instrument measures in a test
>     lab. They are complementary, not competing.
>     I think PowerBench it is ideal to deep dive in idle power and give
>     some baseline for some of the real time measurements considered in
>     GREEN WG, setting up thresholds to consider in operations.
>
>
>     * PowerBench defines EER:
>     PowerBench gives it a name, a unit, and a precise method/formula. The
>     GREEN framework discusses the concept but never settles on a formula
>     or name. Im not convinced we need to include it in GREEN framework
>     though.
>     There are other terminology that should be aligned or mentioned in the
>     terminology GREEN draft:
>     * Total Power (PowerBench) and total-power-input(GREEN) at device
>     level are equivalent terms
>     * Base Power(PowerBench), No GREEN power-state maps to this exactly
>     >>> to be considered in GREEN data model
>     * Idle Power and Typical power (PowerBench), not alignment in GREEN
>     * Alignment on the  measurement accuracy from GREEN is missing in
>     PowerBench: PowerBench uses an external Power Meter measuring PSU,
>     this should corresponds idealy with accuracy-measured-gold
>     * The GREEN power state model (power-state-on/off/low-power), has been
>     discussed in the working group already, but it is not aligned with
>     powerbench:  Base → Idle → Idle+ → Typical → Full Load.
>     * PowerBench lists RFC 7460 (EMAN MIB) as a normative reference, I
>     think it should be informative. And make a note for informative
>     reference as well for GREEN YANG data model as it replaces RFC 7460,
>     and framework.
>     * PowerBench Reporting Format can maps almost entirely onto GREEN
>     YANG leaves.
>
>
>     rgds,
>     Marisol
>
>     Marisol Palmero
>     https://tidycal.com/marisolietf
>
>
>     On Thu, Jul 23, 2026 at 9:32 AM <[e-mail]>
>     <mailto:[e-mail]> wrote:
>     >
>     > Hi all,
>     >
>     >
>     >
>     > draft-ietf-bmwg-powerbench was just presented in IPPM/BMWG joint
>     session. It would be appreciated if some volunteers here in GREEN
>     can look into that document and share comments with IPPM/BMWG.
>     >
>     >
>     >
>     > Thank you.
>     >
>     >
>     >
>     > Cheers,
>     >
>     > Med
>     >
>     >
>     ____________________________________________________________________________________________________________
>     > 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.
>     >
>     > _______________________________________________
>     > Green mailing list -- [e-mail]
>     > To unsubscribe send an email to [e-mail]
>
>     _______________________________________________
>     bmwg mailing list -- [e-mail]
>     To unsubscribe send an email to [e-mail]
>
>
>
>     _______________________________________________
>
>     Green mailing list [e-mail]
>
>     To unsubscribe send an email [e-mail]
>