(Disclosure: I am now an employee of HPE.)
Reading this discussion, I wonder if a minor clarification /
modification in the power groups draft would help your concern Carlos.
As I read it, the draft currently advertises the power consumption of
the power group. While an interesting piece of data in the abstract, I
wonder if we could instead advertise a slightly different value that is
more use for deciding about moving traffic. That is, advertise how much
power could be saved if this power group were able to be put in the
reduce usage state.
Yours,
Joel
On 5/10/2026 6:09 PM, Carlos Pignataro 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 <[email protected]> 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
_______________________________________________
Lsr mailing list [email protected]
To unsubscribe send an email [email protected]
_______________________________________________
Lsr mailing list -- [email protected]
To unsubscribe send an email to [email protected]
