Hi Joel,
Thanks for reading the whole discussion and and sharing a new pair of eyes and insight. While that would not fully address my concern, I do believe your proposal would be a welcome, improved modification! It would, for example, improve the binary on-off current granularity. Thanks, Carlos. > On May 19, 2026, at 4:29 PM, Joel Halpern <[email protected]> wrote: > > (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] >> <mailto:[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] <mailto:[email protected]> >> To unsubscribe send an email to [email protected] >> <mailto:[email protected]>
signature.asc
Description: Message signed with OpenPGP
_______________________________________________ Lsr mailing list -- [email protected] To unsubscribe send an email to [email protected]
