[Green] Re: Next steps for draft-many-lsr-power-group-02

[Tony Li <[e-mail]>]

Hi Carlos,

Sorry for the delay, I have been on travel.

The best way to asses the power savings of this approach would be to look at the aggregate power consumption over time of this approach as compared to not using this approach.

Any single change made by this (or any) mechanism can easily be sub-optimal.  For example, moving traffic from path A to path B may increase energy consumption.  However, it may still the correct approach once more traffic is moved off of path A and components on path a can be powered off.  This would more than compensate for some minor increase.

Thus, it makes sense to evaluate this over time, not just on an operation-by-operation basis.

Even this is challenging in reality, as the traffic demand matrix is not a constant from one day to the next.

Regards,
Tony


> On May 10, 2026, at 3:09 PM, Carlos Pignataro - cpignata at gmail.com <[e-mail]> wrote:
> 
> Tony,
> 
> My question centered on first-principles energy accounting costs. You can always second/third order translate to USD, but use a source metric as energy. That way we can compare and derive. Think of net energy = energy saved via consolidation − energy overhead of the mechanism. I guess these emails would count as embedded energy... 
> 
> Think of how much fuel is needed to power a vehicle. And the fuel delta of an optimization (in cost and benefit). Not insurance costs, meetings and dealer negotiations, speeding tickets.
> 
> Carlos.
> 
> On Fri, May 8, 2026 at 12:16 PM Tony Li <[e-mail] <mailto:[e-mail]>> wrote:
>> 
>> Hi Carlos,
>> 
>> 
>>> I’m not asking “will this always save energy and how much?”  I’m asking “how is the mechanism evaluated rigorously?”  
>>> 
>>> IOW, I’m asking for an evaluation model to be discussed and included — not an operational conclusion. A “how”, not a number. 
>>> 
>>> My concern is that you are evaluating gross savings. And I am suggesting we care more about net savings. And eval mechanism ought to account for both:  
>>> * the energy savings enabled by consolidation/idling, and 
>>> * the incremental energy cost introduced by the mechanism itself.
>>> 
>>> It’s a methodology question — not a quantity or even simulation output one. 
>> 
>> 
>> Ok, I believe that I’ve already talked about the energy savings.  Thus, the remainder of the question is about the costs.  Those costs come in two flavors: direct costs and indirect costs.
>> 
>> The direct costs are easy to describe and difficult to quantify.  We are adding additional information to the IGP. This must be flooded. This information must be used during path computation. The additional considerations for power computation are going to consume a few dozen extra CPU cycles. The path, if changed, must be signaled and cut in.  This should only be considered if the change is due to power, as path changes are also common for other reasons.
>> 
>> I would estimate these direct costs at less than $1USD per day.
>> 
>> The indirect costs are larger and even more difficult to quantify without specifics. Someone in the operator’s network architecture group must create an initiative to power optimize their network. There will undoubtedly be endless meetings involving the network architecture group, the network engineering group, network executives, and the network operations group. They will consider all of the work done by their vendors, including meeting with the vendors, listening to marketing presentations, and evaluating the various offerings. Engineering will be asked to perform a differential design evaluation where each alternative is analyzed for their network. Operations will reject this evaluation and send it back for revisions. Three times. Pizza will be ordered. Coffee will be consumed. Voices will be raised. Finally, the executive in change of network architecture, who didn’t get enough sleep the night before, will make a decision based on non-technical inputs and choose the direction proposed by vendor X.  Vendor Y will protest, leading to another round of meetings, however, the decision will stand.  The engineering staff will then attempt to mock the deployment in the lab.  It will fail because of software issues in Vendor X’s implementation.  In parallel, operations will start the software developement project to enhance their configuration database and network management tools. After 6 weeks, vendor X will provide a patch.  This will also fail.  After 8 more weeks, vendor X will provide a second patch.  This will again fail.  There will then be a big meeting of network engineering to discuss the situation. The head of engineering will then change directions and select Vendor Y’s approach. Operations will restart their software development project. The vendor code will be taken to the lab and will similarly fail.  However, after 8 weeks, vendor Y will provide a patch that actually works. This will be tested in the lab for three weeks and it will be approved for deployment.  Of course, this cannot be deployed until a software update is deployed for both vendor X's and vendor Y’s gear. Additional lab testing will cyclically reveal software issues in each release, resulting in numerous iterations with both vendors getting issues resolved. This will take another 17 months before software images pass the lab tests. Operations will then start to schedule maintenance windows for deployment. Due to the policies for incremental windows, this takes 3 months before the update is deployed. At that point, engineering can configure the feature and start to exercise it, starting to recoup power savings. This is all quite simplified, but should give you some understanding of the operator’s costs.
>> 
>> I would estimate these indirect costs at $24,665,664.37 USD.
>> 
>> Regards,
>> Tony
>>