Hi Tony,
On 25/08/2026 01:52, Tony Li wrote:
Hi Benoit,
There is no tracking of interfaces in power-state-off, nor of
interfaces that are power-state-on but have not formed an adjacency.
There is no tracking of power state of higher levels of hardware.
Presumably when all relevant interfaces are sleeping, the platform
can put higher level hardware to sleep. Once again, we are not
trying to perform management plane functions, only control plane
traffic engineering.
You know, this is exactly my point. And I have seen this pattern in
the past. "It's just routing, not mgmt, so we don't care"
That’s grossly unfair. We do care. But we also have other
requirements. We are proposing to carry this information in the IGP,
as we have done for TE information for 30 years. However, the IGP is
not a limitless storage system. In fact, it has a very finite
capacity and the more that we add to it, the more it degrades IGP
performance. We are carrying the information that we need in the IGP
to do routing’s job. We have no objection to the GREEN YANG model and
support that effort, but carrying YANG in the IGP does not make sense.
"Carry YANG in the IGP" would not make sense, we agree.
My ask is different: "I really would like to understand (see described
somewhere) how an operator would use the LSR power groups, optimize
routing, and use the YANG module power state at the same time."
I read draft-many-teas-power-steering in more details now.
It does not tell how the 3 drafts (draft-many-lsr-power-group,
draft-many-teas-power-steering, and
draft-ietf-green-power-and-energy-yang) are supposed to work together.
Worse, many-teas-power-steering is a normative reference in
draft-many-lsr-power-group, but still an individual draft.
Assuming draft-ietf-green-power-and-energy-yang is implemented (or the
reverse, assuming draft-many-lsr-power-group &
draft-many-teas-power-steering), how does it fit with the other
draft(s)? Do I have to collect the information twice, with different
units/semantics: one with telemetry, one with IGP? How do I link the PSP
to the power states? How do I link the dynamic nature of some variables
(sleeping bandwidth) with the telemetry? Do we use the same index? Do I
have to connect my controller to the IGP link-state to get the
information? Etc.
Should we document how the pieces fit before adopting an encoding?
Ok, criticism easy but it's time to hopefully help out. I have been
spending my day doing my homework.
I believe the crux of the issue is that GREEN does not cover the
capability discovery.
Tony, at the IETF 125 GREEN meeting mentioned
<https://datatracker.ietf.org/doc/minutes-125-green-202603190600/>:
"How can I tell what can be turned off? "
Ron, during the "Re: Next steps for draft-many-lsr-power-group-02"
email thread
<https://mailarchive.ietf.org/arch/msg/green/Pht5LOqoTxos8fn2VzE12WEXLrw/>,
also mentioned
It would be great if there were a yang model that reflected the
following information for each power-save-capable hardware component:
*
How much energy does it consume when awake
*
What is its sleeping/waking history
From a mgmt plane point of view, this capability discovery IS obviously
an issue. Granted. To make a comparison, it's like we want to change
YANG-Push subscription to on-change but I don't know whether a specific
YANG leaf supports it.
Instead of long answers via email, I wrote this band new draft on how I
would do this discovery.
RL:https://www.ietf.org/archive/id/draft-claise-green-capability-discovery-00.txt
Status:https://datatracker.ietf.org/doc/draft-claise-green-capability-discovery/
HTML:https://www.ietf.org/archive/id/draft-claise-green-capability-discovery-00.html
HTMLized:https://datatracker.ietf.org/doc/html/draft-claise-green-capability-discovery
Abstract:
This document defines a YANG module 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 nominal Power the Component draws in that state.
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 or how much Power
each draws. 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.
I haven't had the opportunity yet to get feedback from the GREEN YANG
design team.
Your feedback is welcome.
Regards, Benoit
_______________________________________________
Lsr mailing list -- [email protected]
To unsubscribe send an email to [email protected]
