Carlos,
I think that you have a good point that is relevant to a different part of the
design.
Operators will deploy this technology only if the Return on Investment (ROI) is
high. To calculate the return on investment, the operator needs to know how
much power (aka, money) they saved.
This draft advertises power information in IS-IS so that CSPF can optimize path
computation for power savings. Rerouting traffic doesn't save money. However,
it facilitates another system that monitors power-save-capable hardware and
powers it down when it is not needed. It also powers it up when it is needed
again. That component saves energy and money.
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
If such a yang model existed, it would provide a history of power savings.
Interested?
Ron
________________________________
From: Carlos Pignataro <[email protected]>
Sent: Tuesday, May 5, 2026 2:08 PM
To: Tony Li <[email protected]>
Cc: Christian Hopps <[email protected]>; lsr <[email protected]>;
"“[email protected]”" <[email protected]>; ops-ads <[email protected]>;
[email protected] <[email protected]>
Subject: [Lsr] Re: [Green] Next steps for draft-many-lsr-power-group-02
Hi, Tony,
> On May 5, 2026, at 2:10 AM, Tony Li <[email protected]> wrote:
>
>
> Hi Carlos,
>
>
>> One additional suggestion: it would be valuable for
>> draft-many-lsr-power-group to include some consideration of how its
>> mechanisms can be evaluated from an energy perspective. For example,
>> guidance on measuring impact, comparing against a baseline, or reporting
>> observed energy savings (and any managed decreases and/or unintended
>> increases) in deployments.
>>
>> Even lightweight guidance here could help ensure that experimental results
>> are actionable and can inform the broader work in green or elsewhere.
>
>
> I’m not understanding what you’re requesting. draft-many-lsr-power-group
> provides a basis for path computation that allows PCE implementations to
> consolidate traffic, thereby idling components that can be put into
> power-sleep. Without a specific analysis of a network, traffic demand
> matrix, and detailed hardware information, (all of which are operator
> confidential), I’m not sure what we can provide that is helpful.
Thanks — I was too open-ended and broad, so let me clarify. This is not about
the particulars of any specific network or requiring confidential inputs.
The intent is simply to ensure that the evaluation captures the net
system-level impact (i.e., whether the mechanisms enable sufficient
consolidation to reduce overall energy consumption relative to a baseline.) In
other words, the considering both sides: the additional overhead introduced,
and the potential energy savings from traffic consolidation and resource
idling. How is the simulation / premise / framework evaluating net >0 or <0?
>
> We’ve already presented simulation results to substantiate the underlying
> premise.
>
> I ask that we please proceed.
Yes — and not mutually exclusive with ^^^
Best,
Carlos.
>
> Regards,
> Tony
>
>
_______________________________________________
Lsr mailing list -- [email protected]
To unsubscribe send an email to [email protected]
