Aijun, You said: “Until now, there is no evidence that can prove what you claim — when each ingress node independently uses this same technique, network traffic gradually polarizes onto a preferred set of resources.”
I would reiterate that this is an established operational practice, and I would again encourage you to check with operators who run large distributed bandwidth-engineered networks, as well as with vendors, about the use of the most-fill mechanism. If you are not convinced about how existing operational practice works with respect to gradual network traffic polarization, then it would be equally difficult to convince you about how the PCPPS metric can be leveraged in a distributed fashion. In other words, the underlying mechanism is the same: a local path-selection policy that biases traffic toward a preferred subset of resources, without requiring synchronized global coordination. At this point, I think the discussion is becoming somewhat circular. We have already answered the same question in the same way multiple times, and the underlying point remains the same: this is not a theoretical claim; it is an established behavior in distributed TE systems today, and it is already reflected in deployed implementations that use most-fill path selection. The effect is gradual and conditional, rather than globally optimal in every topology, but it is a real and operationally useful network-wide steering effect. I think we have reached the point where further repetition is unlikely to be productive, and I will leave it there. Regards, -Pavan On Fri, Sep 18, 2026 at 1:53 AM Aijun Wang <[email protected]> wrote: > Hi, Tony: > > > > Then, from the operator’s side, why will they deploy such > non-deterministic (network-wide polarization) solution in their network? > > > > And we should aware that “put the interface into sleep state” is more > strict requirement than the “bandwidth adjustment”: > > You should make sure all the services from each headend are not passing > the sleeping links, and *WILL NOT* the passing the sleeping links, or > else there will be service disrupt during the sleeping procedures. > > > > Without coordination of the LSPs requirements on each headend, when will > you end the “network-wide polarization” process and begin the sleeping > management procedures, which is the integral part of the overall proposal, > but the authors avoid touching it? > > > > Best Regards > > > > Aijun Wang > > China Telecom > > > > *From:* [email protected] [mailto:[email protected]] *On Behalf Of *Tony > Li > *Sent:* Friday, September 18, 2026 2:01 PM > *To:* Aijun Wang <[email protected]> > *Cc:* Vishnu Pavan Beeram <[email protected]>; Vishnu Pavan Beeram < > [email protected]>; Adrian Farrel <[email protected]>; Barth, > Colby <[email protected]>; Robert Raszuk < > [email protected]>; John Drake <[email protected]>; > John Drake <[email protected]>; WG TEAS <[email protected]>; lsr < > [email protected]> > *Subject:* [Lsr] Re: [Teas] Re: Re: Re: Re: Re: Re: Re: Re: [Green] > 【Distributed > Power-aware TE is Impossilbe】RE: RV: Call for adoption: > draft-many-teas-power-steering-01 (Ends 2026-09-10) > > > > > > Hi Aijun, > > > > > > Let’s assume the each headend synchronizes their necessary information, > and the network utilization is almost same in two links. > > To achieve “network-wide” polarize effect, we need to assure each headend > calculate its CSPF computation *in sequence*, or there will be no > deterministic results that they will select the same sleepable link. > > > > Can anyone support the distributed Power-aware TE answer it? > > > > > > Asked and answered. To repeat: > > > > Even if the PCPPS metric on two paths is identical, a difference in the > network utilization, even if they are almost the same is enough to attract > traffic to the higher utilization link. This need not be done in sequence, > as the attractive link will continue to attract more and more traffic. > > > > Furthermore, as paths are periodically optimized, the polarization will > continue, trying to fill the higher utlization path. > > > > We do not claim that it is deterministic. Indeed, it can never be, as the > headends are not coordinated. Fortunately, it does not need to be. > > > > > > And, if we dig more deeply, we should know CSPF calculate the path not > merely on power-aware information, there is also other constraints for > using the links. > > > > > > As stated, all normal CSPF constraints are available. This is standard > TE, please see RFC 5305. > > > > > > How to coordinate these constraints within the headends, to move the > traffic in synchronize out of some sets of links? > > > > > > The constraints do not need to be coordinated. The goal is to consolidate > traffic within the bounds of the constraints and power-sleep components > that are vacated. If no components are vacated due to bandwidth or > constraints, then nothing will be put into power-sleep. This is by > design. The goal is to save power if possible, but not disrupting traffic > is a higher priority. > > > > Regards, > > Tony > > >
_______________________________________________ Lsr mailing list -- [email protected] To unsubscribe send an email to [email protected]
