[Green] Re: Fwd: New Version Notification for draft-claise-green-capability-discovery-01.txt

[Marisol <[e-mail]>]

Hi,

Just a quick comment, addressing Qin's point on nameplate power(Q1):

Nameplate power applies to every hardware component:
* A line card has a nameplate (maximum input power it draws from the power
rail);
* a PSU has a nameplate (maximum output power it can deliver).
The system nameplate is roughly the sum of all component nameplate values,
and the PSU output nameplate must be able to cover that sum for a correctly
sized system.

The PSU is the special case because it has two faces:
1. input nameplate (iAC drawn from the wall) and
2. output nameplate (DC delivered to the system), connected by
efficiency... which is exactly what the different certification might
cover(80 PLUS, etc), and what POWEFF captured with its psu-efficiency leaf.

For all other components, nameplate is simpler: the maximum input power the
component draws.
This is my suggestion for the GREEN Terminology draft, under the nameplate
definition; please check Open issue under Terminology draft:
https://github.com/billwuqin/draft-bclp-green-terminology/issues/68

The capability discovery draft is right to define it at the per-component
level, consistent with RFC 8348. Even I would be consistent moving these
definitions to the Terminology draft.

Qin's three-tier diagram (peak/surge → nameplate → actual operating) maps
cleanly onto the three quantities in the draft: max-power (rated per
design), nominal-power (expected operating value), and nameplate-power
(absolute component maximum). As mentioned I would add the fix in the
terminology draft, which currently defines nameplate as "nominal power as
specified by the manufacturer".
In simple words I would instead say "maximum power a component is designed
to consume, as specified by the manufacturer", aligning it with the GREEN
YANG module.


On that note, Benoit, thank you for crediting POWEFF in the
Acknowledgments. POWEFF had the psu-efficiency leaf and the same
static/dynamic separation concept, and it is good to see that lineage
recognised formally in the draft. The nameplate ambiguity was already
present in POWEFF's max-output-pwr leaf, so resolving it cleanly here
closes a gap.

rgds,
Marisol




On Thu, Sep 17, 2026 at 2:23 AM Qin Wu <bill.wu=[e-mail]>
wrote:

> Hi, Benoit:
>
> Thanks for the update to this interesting draft, a few comments below:
>
> In this draft, nominal power is separated from max-power. In GREEN
> terminology draft, nameplate power is specified, which has been consumed by
> GREEN YANG data model  and GREEN framework.Since you introduce both max
> power and nominal power in capability discovery draft, I am wondering how
> nameplate power is related to or different from nominal power, max-power,
> here is my Understanding:
>
> ===============================================================
>
> [Peak/Surge power] -->Absolute Physical Maximum(Watts)
>
>           ^
>
>           |
>
>           |
>
>           |       (Safety margin/Overload Capacity)
>
>           V
>
>
>
> [Nameplate/Rated Power] --> Maximum Continuous power you can
>
>           ^                  Run indefinitely
>
>           |
>
>           |
>
>           |       (Normal Daily Usage)
>
>           V
>
>
>
> [Actual Operating Power] -->Real time Power being used or generated
>
> =================================================================
>
> I think Nameplate power IS a specific type of maximum power—specifically,
> the maximum continuous power*.* The maximum power you are referred to in
> the draft is more like
>
> peak, surge, or maximum transient power. So I am wondering whether we
> should specify all 3 terms in the GREEN terminology draft?
>
>
> Second, take nameplate data of a photovoltaic panel as an example,
> nameplate data of a photovoltaic panel is essential to understand its
> performance and make informed decisions about purchase and installation.I
> think in addition to nameplate data or maximum power data, I think the
> voltage and current values at the maximum power point/ I am wondering
> whether you should also add voltage and current value associated with
> maximum power or nameplate power. Third, it is not clear to me how
> component level capability can be mapped to per node capability, note that
> node here is about data node, how it is mapped to each component within the
> network device.   Fourth, I feel power saving capable capability is
> implicitly expressed in this model, do you think power saving capable
> should be explicitly represented?
>
>
>
> -Qin
>
> *发件人:* [e-mail] [mailto:[e-mail]]
> *发送时间:* 2026年9月10日 18:32
> *收件人:* [e-mail]
> *抄送:* [e-mail]
> *主题:* [Green] Fwd: New Version Notification for
> draft-claise-green-capability-discovery-01.txt
>
>
>
> Dear all,
>
> Here is an update to YANG Data Model for Power State Capability Discovery.
>
> Changes since draft-claise-green-capability-discovery-00
> - New sections: Applicability,, Applicability to the GREEN Use Cases, Open
> Issues
> - Added four per-Power-State transition-time leaves: typical-exit-time,
> max-exit-time, typical-entry-time, and max-entry-time (reintroducing the
> wake/transition-time concept that was absent in -00).
> - Removed the unit-multiplier leaf and the multiplier-based scaling;
> nominal-power and max-power are now fixed in Watts (uint32), to be aligned
> with draft-ietf-green-power-and-energy-yang
> - Distinguished nominal-power (expected operating draw) from max-power
> (rated per-state ceiling, the per-state counterpart of Nameplate Power),
> with max-power for power-state-on required not to exceed nameplate-power.
> - Clarified that the model is operational-state (config false) data in the
> operational datastore (NMDA-consistent).
> - Expanded the Operational Considerations: weigh exit/entry time against
> the Energy Saving
>
>
> Thanks and regards, Benoit (on behalf of the co-authors)
>
> -------- Forwarded Message --------
>
> *Subject: *
>
> New Version Notification for draft-claise-green-capability-discovery-01.txt
>
> *Date: *
>
> Thu, 10 Sep 2026 03:27:52 -0700
>
> *From: *
>
> [e-mail]
>
> *To: *
>
> Benoit Claise <[e-mail]> <[e-mail]>,
> Gen Chen <[e-mail]> <[e-mail]>, Nils Warnke
> <[e-mail]> <[e-mail]>, Nils Warnke
> <[e-mail]> <[e-mail]>, Reshad Rahman
> <[e-mail]> <[e-mail]>
>
>
>
> A new version of Internet-Draft
> draft-claise-green-capability-discovery-01.txt
> has been successfully submitted by Benoit Claise and posted to the
> IETF repository.
>
> Name: draft-claise-green-capability-discovery
> Revision: 01
> Title: A YANG Data Model for Power State Capability Discovery
> Date: 2026-09-10
> Group: Individual Submission
> Pages: 25
> URL:
> https://www.ietf.org/archive/id/draft-claise-green-capability-discovery-01.txt
> Status:
> https://datatracker.ietf.org/doc/draft-claise-green-capability-discovery/
> HTML:
> https://www.ietf.org/archive/id/draft-claise-green-capability-discovery-01.html
> HTMLized:
> https://datatracker.ietf.org/doc/html/draft-claise-green-capability-discovery
> Diff:
> https://author-tools.ietf.org/iddiff?url2=draft-claise-green-capability-discovery-01
>
> Abstract:
>
> This document defines a YANG data model that augments the system
> capabilities model of RFC 9196 to allow a network element to
> advertise, per hardware Component, the set of Power States that the
> Component supports, together with a static characterization of each
> such state: the expected and maximum Power the Component draws in it,
> and the time to enter and exit it.
>
> This capability model complements the operational Power and Energy
> data model defined in the GREEN Power and Energy YANG module, which
> reports the current Power State and the measured Power of a
> Component, but not which Power States are available, how much Power
> each draws, or how long transitions between them take. It is
> anchored to the hardware inventory of RFC 8348, reuses the Power
> State identities of the GREEN Power and Energy model, and, because it
> is static, 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.
>
>
>
> The IETF Secretariat
>
> _______________________________________________
> Green mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
>