Colby,

Your statement is incorrect. 

Because your proposal is distributed, there is always the possibility that 
links that should have been put to sleep are not, because the re-distribution 
of LSPs in order to put links to sleep is not co-ordinated in order to provide 
global co-ordination of that re-distribution.

John

Sent from my iPhone

> On Sep 4, 2026, at 11:07 AM, Barth, Colby 
> <[email protected]> wrote:
> 
> 
> John,
> 
> It only results in no links being put to sleep IF there are insufficient 
> resources to consolidate traffic.  That’s a feature, not a limitation.
> 
> -- Colby
> 
> From: John Drake <[email protected]>
> Date: Friday, September 4, 2026 at 7:14 AM
> To: Barth, Colby <[email protected]>
> Cc: Aijun Wang <[email protected]>; Tony Li <[email protected]>; 
> WG TEAS <[email protected]>; lsr <[email protected]>
> Subject: Re: [Teas] Re: [Lsr] Re: [Green] 【Distributed Power-aware TE is 
> Impossilbe】RE: RV: Call for adoption: draft-many-teas-power-steering-01 (Ends 
> 2026-09-10)
> 
> Colby,
> 
> Path placement in this proposal is indeed deterministic.  However, its 
> effects are not;  i.e.,  even though it may be possible to put some links to 
> sleep,  this proposal will not do that deterministically.  In particular, 
> this proposal may not put any links to sleep.
> 
> I don’t think that’s acceptable.
> 
> John
> Sent from my iPhone
> 
> On Sep 4, 2026, at 9:47 AM, Barth, Colby 
> <[email protected]> wrote:
> 
> 
> Aijin,
> 
> Distributed TE path placement is deterministic.  Tony’s example is about 
> placing TE tunnels on paths with sufficient resources.
> 
> You are criticizing many other solutions with your example.  The PCE 
> architecture follows the same model.
> 
> -- Colby
> 
> From: Aijun Wang <[email protected]>
> Date: Thursday, September 3, 2026 at 6:23 PM
> To: 'Tony Li' <[email protected]>
> Cc: 'TEAS WG' <[email protected]>; 'lsr' <[email protected]>
> Subject: [Teas] Re: [Lsr] Re: [Green] 【Distributed Power-aware TE is 
> Impossilbe】RE: RV: Call for adoption: draft-many-teas-power-steering-01 (Ends 
> 2026-09-10)
> 
> Hi, Tony:
> 
> Then, there will be no deterministic effect for the distributed power-aware 
> TE, Right?
> Why the operator will deploy such proposal that has the unknown probability 
> of success?
> 
> And, for the power group related information, since they are static, and will 
> almost never to be changed, even the controller based approaches need them, 
> it is not the IGP's role to flooding them.
> 
> Let's image the possible scenario:
> NMS configure the power group information on each device---->IGP flood such 
> information among all the nodes---->BGP-LS collect such information to the 
> Controller
> Why don’t we let the NMS synchronize such information to the Controller? In 
> most of the real deployment, NMS is almost the same, or collocate with SDN 
> controller.
> 
> So, what's the usage of the distributed power-aware TE proposal?
> 
> Best Regards
> 
> Aijun Wang
> China Telecom
> 
> -----Original Message-----
> From: [email protected] [mailto:[email protected]] On 
> Behalf Of Tony Li
> Sent: Friday, September 4, 2026 3:18 AM
> To: Aijun Wang <[email protected]>
> Cc: TEAS WG <[email protected]>; lsr <[email protected]>
> Subject: [Lsr] Re: [Teas] [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 trim the discussions within TEAS only.
> 
> 
> No, let’s not.
> 
> 
> > "the relevant nodes can then detect that the link is idle and can put it 
> > into power-sleep."  via the "reserved bandwidth"?
> > Then the proposal depends solely on RSVP style TE.
> 
> 
> No.  Other proposals are free to use the information as well.  If you have a 
> controller-based approach and want PSP information on the network, here’s one 
> way.
> 
> 
> > Even so, how you assure all the ingress node will select to avoid the same 
> > link along the e2e path that is determined by its own? Only behave in such 
> > manner, can you move out of the traffic from one link step by step.
> 
> 
> There is no guarantee that all headends will be able to consolidate traffic.  
> If the traffic levels are sufficiently low and the relevant headends compute 
> paths that do consolidate traffic, then links can transition to power-sleep.  
> If traffic levels are not sufficiently low and one headend cannot find a path 
> that avoids the link, well, the the link cannot be put into power sleep.  
> This is not a bug, this is a feature.
> 
> 
> > Changing the link metric can get the effect of " in the middle of a flock 
> > of birds and clap your hands, they will fly away ".
> > But for the distributed TE proposal, the effect will be the birds fly from 
> > east to west, and then from north to south, or, fly around within the 
> > forest, because every edge router direct them to avoid some different tree.
> 
> 
> We are not changing the link metric.  We are adding a penalty to the path for 
> the link in question.  There may be many links on a path that are capable of 
> power-sleep, so there may be many penalties.  Those penalties do not have to 
> be the same from LSP to LSP, nor from head-end to head-end, nor from link to 
> link to have an effect on path computation.  As long as each headend finds a 
> path with sufficient capacity, then the network is in an acceptable state.
> 
> Tony
> 
> _______________________________________________
> Lsr mailing list -- [email protected]
> To unsubscribe send an email to [email protected]
> 
> _______________________________________________
> Teas mailing list -- [email protected]
> To unsubscribe send an email to [email protected]
> _______________________________________________
> Teas 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]
_______________________________________________
Lsr mailing list -- [email protected]
To unsubscribe send an email to [email protected]

Reply via email to