Return-Path: X-Original-To: green@mail2.ietf.org Delivered-To: green@mail2.ietf.org Received: from localhost (localhost [127.0.0.1]) by mail2.ietf.org (Postfix) with ESMTP id 12F3512F972E2; Wed, 26 Aug 2026 03:23:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1787739788; bh=P/OiMyihloai4NsYt/HiZGAEnckJGT0v7tT7ZAC1RL0=; h=Date:Subject:To:Cc:References:From:In-Reply-To; b=nzkR/jCCpUQ0yTPfr4nVuSEon2+uF1GT57Py2zr5A2lVMhcd2d5ksD6Dtf8/bxSx1 qlqMLQ8SSVMkuixSNZGRscPzE7rj5OGrWDtPZXv9FlHzEUpOStyeTKZfdYyOLv93rE YYeNcUp6iKcVDqf1rfMVrh62kEIwS4d82w97Hc2M= X-Virus-Scanned: amavisd-new at ietf.org X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, RCVD_IN_VALIDITY_SAFE_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: mail2.ietf.org (amavisd-new); dkim=pass (2048-bit key) header.d=everything-ops.net Received: from mail2.ietf.org ([166.84.6.31]) by localhost (mail2.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YFD_iZHeYXD1; Wed, 26 Aug 2026 03:23:03 -0700 (PDT) Received: from smtpout3.mo536.mail-out.ovh.net (smtpout3.mo536.mail-out.ovh.net [51.210.91.12]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by mail2.ietf.org (Postfix) with ESMTPS id 94D8D12F972CC; Wed, 26 Aug 2026 03:23:03 -0700 (PDT) Received: from director5.derp.mail-out.ovh.net (director5.derp.mail-out.ovh.net [79.137.60.225]) by mo536.mail-out.ovh.net (Postfix) with ESMTPS id 4hVLM434KTz88QH; Wed, 26 Aug 2026 10:22:56 +0000 (UTC) Received: from director5.derp.mail-out.ovh.net (director5.derp.mail-out.ovh.net. [127.0.0.1]) by director5.derp.mail-out.ovh.net (inspect_sender_mail_agent) with SMTP for ; Wed, 26 Aug 2026 10:22:56 +0000 (UTC) Received: from mta3.priv.ovhmail-u1.ea.mail.ovh.net (unknown [10.110.43.114]) by director5.derp.mail-out.ovh.net (Postfix) with ESMTPS id 4hVLM42X2Vz6NnH; Wed, 26 Aug 2026 10:22:56 +0000 (UTC) Received: from everything-ops.net (unknown [10.1.6.9]) (Authenticated sender: benoit@everything-ops.net) by mta3.priv.ovhmail-u1.ea.mail.ovh.net (Postfix) with ESMTPSA id 6E390941B33; Wed, 26 Aug 2026 10:22:55 +0000 (UTC) Authentication-Results: garm.ovh; auth=pass (GARM-107S0017f7271fe-83fa-42bb-9fc0-5c06e2adb7d7, AB2C89FD3CCD504B69D939E002663FBD4658D0E7) smtp.auth=benoit@everything-ops.net X-OVh-ClientIp: 91.86.233.52 Content-Type: multipart/alternative; boundary="------------MnE388rdFUDrYb6dJF7U3Fe7" Message-ID: Date: Wed, 26 Aug 2026 12:22:54 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird To: "Chengen(GenChen)" , Marisol , "mohamed.boucadair@orange.com" References: <028a3957-7173-4b97-bc1a-22a2609b0a60@everything-ops.net> <7b6a2504ea884f4db1322b0cd1594668@huawei.com> Content-Language: en-US, fr From: "Benoit@everything-ops.net" In-Reply-To: <7b6a2504ea884f4db1322b0cd1594668@huawei.com> x-ovh-tracer-id: 13726971666660304156 X-VR-SPAMSTATE: OK X-VR-SPAMSCORE: -100 X-VR-SPAMCAUSE: dmFkZTEtu7cWfENkkX4pjWKBNa7CZM9a7DheIwuQMlt4t48sa3hr1pZxoVi2VUD/MQFeAQuXahJDK7vTrFXlw4enyJ7g3de0pc6jqqpCu3d1pdZ6l0ku7WEvTbvMTt7v1es/bVWHcXQi4rHoApYGc5e6gfBbYHYEYEl+C1z6OOyRl5b2SEBLiNCSsC5WLGnOC6K6zcGGjq3jRLTRGv12krgS7AJGWggMryDr3Qizx21U3xtxETWhMmHAras9UaLtrOSIBCxGGxC60B6d+H5GbBVKkTQXuZkWzsuetJlWlbGXCxRfo9KrVqbJwDSy+/bAnhCSOPhLzcrgPmtaZFFeAaTZMb4opqV5zjXjiQJb0I1Wtnpx5kBZaYqIHmwv3RtFTzTGpjov6h7AjoSFDo9NG98AsgpSenPVS1Fcw/WTupNJwRSKsOv+uD7tNC0xROXxFqc4Uxu28F31NBI5tTaoobZ1PYzEFzfhFF5lVGWYUOC3I88J2fniYhBiCsf6PoqVIrFtyhnUo61vvfnsNKfgAxMcKKsW9/a7caQp1eLLns8w/AnIAyUI1D9ZAFF98+MnC4bzkg2/ZAyfcyRGBt1owe1q02g+4RhqLIZIYu0/lgyEgEzRpaMnQsv+Z6pnu6/zXpWJTG3r5PYtdIxYcGKhmeyiF6QbcGeOU5d6cbabo6vO72NdIA DKIM-Signature: a=rsa-sha256; bh=Q7iuWvC93EImYhZeWwOjN7Zj3G5MSFl8cMgLfZNVwRM=; c=relaxed/relaxed; d=everything-ops.net; h=From; s=ovhmo-selector-1; t=1787739776; v=1; b=FPFqwegbi9XX7cqtVVCQ2sr/wOBGpLccjpL5qt3kuvRw/5/2wu0gi3Fyoa4RvAcHsanr2kkh 3g64O/hntXwp4sX0quwbQPtmtgNm84cK9U8mA8wrrGwdCmn+AOqgSOiXlrlevJggrYb5wDb1mqO MbgZnziboQMSinlXYZ5TrGBM7fcW7KLjqFv4qz1fpgXnfc+EWUAbzup+Wh2UU3KlpqTU/rr8sk/ WiZLsZHlczhM7v0jWFVKrEcJ74iB2qx2o1rQn0V2Krj8nQU4FOtforrIXwgMBt/d11ZBvlkXffU Y1JP+R2lbHfVxSePuhlZMvH/bvaf6k+9NzWdEULPBisIg== Message-ID-Hash: J34UOZ3ULB7YB2TFMKDR5ONXWMPVKAUQ X-Message-ID-Hash: J34UOZ3ULB7YB2TFMKDR5ONXWMPVKAUQ X-MailFrom: benoit@everything-ops.net X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header CC: Getting Ready for Energy-Efficient Networking Discussion List , bmwg , ippm X-Mailman-Version: 3.3.9rc6 Precedence: list Subject: =?utf-8?q?=5BGreen=5D_Re=3A_=5Bbmwg=5D_Re=3A_draft-ietf-bmwg-powerbench?= List-Id: Getting Ready for Energy-Efficient Networking WG Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: This is a multi-part message in MIME format. --------------MnE388rdFUDrYb6dJF7U3Fe7 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit 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, 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 : 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:* Benoit@everything-ops.net > *Sent:* 2026年8月25日 0:15 > *To:* Chengen(GenChen) ; Marisol > ; mohamed.boucadair@orange.com > *Cc:* Getting Ready for Energy-Efficient Networking Discussion List > ; bmwg ; ippm > *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 > > *收件人：*mohamed.boucadair@orange.com > > *抄****送：*Getting Ready for Energy-Efficient Networking Discussion > List ;bmwg ;ippm > > *时****间：*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 > 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 -- green@ietf.org > > To unsubscribe send an email to green-leave@ietf.org > > _______________________________________________ > bmwg mailing list -- bmwg@ietf.org > To unsubscribe send an email to bmwg-leave@ietf.org > > > > _______________________________________________ > > Green mailing list --green@ietf.org > > To unsubscribe send an email togreen-leave@ietf.org > --------------MnE388rdFUDrYb6dJF7U3Fe7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit 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, 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:
   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: Benoit@everything-ops.net <benoit@everything-ops.net>
Sent: 2026年8月25日 0:15
To: Chengen(GenChen) <chengen@huawei.com>; Marisol <marisol.ietf@gmail.com>; mohamed.boucadair@orange.com
Cc: Getting Ready for Energy-Efficient Networking Discussion List <green@ietf.org>; bmwg <bmwg@ietf.org>; ippm <ippm@ietf.org>
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 <marisol.ietf@gmail.com>

抄 送：Getting Ready for Energy-Efficient Networking Discussion List <green@ietf.org>;bmwg <bmwg@ietf.org>;ippm <ippm@ietf.org>

时 间：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 <mohamed.boucadair@orange.com> 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 -- green@ietf.org
> To unsubscribe send an email to green-leave@ietf.org

_______________________________________________
bmwg mailing list -- bmwg@ietf.org
To unsubscribe send an email to bmwg-leave@ietf.org



_______________________________________________
Green mailing list -- green@ietf.org
To unsubscribe send an email to green-leave@ietf.org

 


--------------MnE388rdFUDrYb6dJF7U3Fe7--