Hi Tony, > as the traffic demand matrix is not a constant from one day to the next.
Hmmm that is a pretty bold statement and intuitively hard to argue with. However maybe you and some of the folks on the list recall Cariden and their tool to build traffic demands in days, weeks and months of the number of tier 1 ISPs. Well the outcome of that was contrary and they found the traffic demand patterns to actually be pretty consistent in a given time deltas. That in turn allowed them to achieve traffic engineering of the relatively large global backbones by only adjusting the link metrics and the proven claim was that it was as good (say - 10%) as compared to the outcome of RSVP-TE. I am mentioning it here as a potential alternative view on how to shift traffic between selected paths without the need to run full RSVP-TE in the network. Obviously this would rather fall into a controller driven bucket of solutions. Cheers, R. On Mon, May 18, 2026 at 8:02 PM Tony Li <[email protected]> wrote: > > 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 < > [email protected]> 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 to [email protected] >
_______________________________________________ Lsr mailing list -- [email protected] To unsubscribe send an email to [email protected]
