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 to [email protected]
