Hi John, I assume you’re making the case for Global Concurrent Optimization (once again)? Sure, that would provide better results than distributed TE. This is not a new argument, we already discussed it in this thread (and for many years, for that matter). As we’ve stated many times already, if you want a “Controller” to consume the power-group info (and all the associated per interface, per tunnel, power telemetry streaming) and perform GCO, this solution does not prohibit you.
However, not all operators leverage a central Controller and GCO comes with its own ‘costs’ (also already highlighted in this thread by Tony) nor should we require it. Therefore, this proposal caters to both centralize and distributed TE to facilitate power savings. It would be nice if we could just discuss the specific IS-IS extensions we proposed and not continue this circular argument. Thanks, -- Colby From: John Drake <[email protected]> Date: Friday, September 4, 2026 at 8:29 AM To: Barth, Colby <[email protected]> Cc: John Drake <[email protected]>; Aijun Wang <[email protected]>; Tony Li <[email protected]>; WG TEAS <[email protected]>; lsr <[email protected]> Subject: Re: [Lsr] Re: [Teas] Re: Re: [Green] 【Distributed Power-aware TE is Impossilbe】RE: RV: Call for adoption: draft-many-teas-power-steering-01 (Ends 2026-09-10) 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]
