Hi Aijun, > If you (and also other authors) can’t provide the detail algorithm to achieve the “network-wide bias”
By the nature of TE all TE metrics are network-wide. And this entrie solution to the best of my understanding does not define any algorithm extensions. The vanilla CSPF is proposed to be used in section 4 of draft-many-teas-power-steering just with new constraint. And yes as discussed already the solution could work equally well by adjusting the value of already defined constraints. Yet authors decided that defining a new one is a better choice hence they defined a set of new TLVs. It is also pretty obvious that if ingress nodes will not understand the new extensions they will not act on it. Regards, R. On Thu, Sep 24, 2026 at 6:00 AM Aijun Wang <[email protected]> wrote: > Hi, Tony: > > > > If you (and also other authors) can’t provide the detail algorithm to > achieve the “network-wide bias” of most-fill, I think we can close the > discussions. > > What you insist is that you have one “practical solution” but there is no > theoretical basis. > > > > As you declared, there may be some chances to clear the traffic on some > “sleep-able” set of links. Even so, the nodes connects such links can’t > power off it, whatever how long these links are idle. (because they don’t > when will these links will be used again) > > > > And, we should be aware, in the network that are comprised of the devices > from different vendors, if there is no one universal agreed algorithm, it > will be more challenge to achieve the above unreliable distributed > power-aware TE. > > > > Let’s hear the opinions of experts from other operators? > > > > > > Best Regards > > > > Aijun Wang > > China Telecom > > > > *From:* [email protected] [mailto:[email protected]] *On Behalf > Of *Tony Li > *Sent:* Wednesday, September 23, 2026 11:38 AM > *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:* Re: [Lsr] [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, > > > > > > 1） There is no algorithm can assure the different headend selects > the same sets of links[Let’s call the *sleep-able set of links* ] to > power off, even each headend use the “most-fill” strategy. (such > phenomenon can occur in any topology network, regarding less they are in > the same continent or not ) > > > > > > This is incorrect. > > > > You seem to want a miracle. Some mechanism that will always save lots of > power no matter what the conditions are. > > > > The algorithm that we have described is a practical solution. Given > enough capacity in the network, given available paths that can support the > traffic, given enough redundancy in the network, and given a correct > configuration, the PCPPS algorithm consolidates traffic away from > power-save-capable links. The algorithm will avoid congestion situations, > even at the expense of keeping links awake. > > > > > > 2） There is no way to assure any third headend avoid using the > above *sleep-able set of links, * regarding less of how long they have > been idle. > > > > > > Again, we do not want such an assurance. That is a non-goal. If a > headend wants to use a power-sleep-capable link, it is because it is the > best available link for the traffic, based on the path metric and taking > PCPPS into account. Therefore, not using such a link would mean using an > even worse link or dropping traffic. > > > > > > 3） There is no way for every headend to exchange their LSP > requirements, to coordinate their path calculation results----“node-wide > bias” doesn’t lead to “network-wide bias”. > > > > > > We do not want headends to exchange their LSP requirements, nor is that > necessary. Routers can work together on a common database to make > collaborative decisions. This is the essence of all routing protocols, as > well as TE. > > > > > > Based on the above conclusions, how can the operator power off the idle > links? > > > > > > The best way, of course, is to let the PCPPS system operate. It will > shift traffic away and the put links and components into power-sleep. > > > > In addition, we also have a manual mechanism for powering off components, > but this is far less elegant. > > > > > > Please state the above constraints in your document, and relevant > solutions, before proposing any protocol extensions. > > > > > > Asked and answered. The constraints have already been described. We > respect normal TE path constraints plus PCPPS metric modifications. > > > > Cheers, > > Tony > > >
_______________________________________________ Lsr mailing list -- [email protected] To unsubscribe send an email to [email protected]
