Colby, It’s nice to see that you’re admitting, implicitly, that my statements are correct.
Comments inline. John Sent from my iPhone > On Sep 4, 2026, at 12:12 PM, Barth, Colby > <[email protected]> wrote: > > Hi John, > > I assume you’re making the case for Global Concurrent Optimization (once > again)? JD: Not necessarily. > 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. JD: That presupposes that putting power group info in the IGP is a good idea, which is not a given. > > 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. JD: But what about those networks that don’t use TE? What networks lack a provisioning system? As I have indicated in previous emails, I think link power management belongs in the provisioning system. > > It would be nice if we could just discuss the specific IS-IS extensions we > proposed JD: Given the state of flux, that’s a bad idea. > and not continue this circular argument. JD: That’s the wrong term for this discussion. > > 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]
_______________________________________________ Lsr mailing list -- [email protected] To unsubscribe send an email to [email protected]
