As Robert noted, this point has already been discussed. This is not a claim that TE is universal; it is a recognition that, where power savings is an operational objective, TE-based mechanisms are a valid and practical way to influence path selection and reduce active components.
If power savings matters in a network, then using TE techniques to achieve it is a reasonable choice. Regards, -Pavan On Fri, Sep 4, 2026 at 2:46 PM Robert Raszuk <[email protected]> wrote: > Hi John, > > That question has been answered here. > > This solution is not a universal one to accommodate any type of network. > This is only for those who use 100% of TE for their interested traffic. > > If they have none TE traffic it still will be moved away gracefully > (make-before-break) just by metric bump but it will not be accounted for. > Yes that may result in qos drops of such traffic on some interfaces/links. > > Thx, > R. > > On Fri, Sep 4, 2026 at 11:21 PM John Drake <[email protected]> wrote: > >> What do you do to support networks that support a mix of TE and non-TE >> traffic, where the latter is typically much larger than the former, or in >> networks that only support non-TE traffic, using a distributed approach? >> Sent from my iPhone >> >> On Sep 4, 2026, at 4:48 PM, Vishnu Pavan Beeram < >> [email protected]> wrote: >> >> >> {as a WG participant} >> >> The key issue here is not whether global centralized coordination is >> valuable — clearly it is — but whether it is the only viable way to achieve >> meaningful network-wide efficiency. The argument in favor of distributed TE >> is that it can still steer traffic in a globally useful direction without >> the operational cost and complexity of a centralized optimization loop. >> >> I doubt there would be any dispute with the argument that global >> centralized coordination offers the best way to maximize network-wide >> efficiency. However, it is not the only viable model, and it is not always >> the operationally preferred one. >> >> In practice, many deployments already rely on the “most-fill” local path >> selection tie-breaker to bias TE path computation toward a preferred subset >> of links, and this knob is available across major vendor implementations. >> When such a tie-breaker is incorporated into a network-wide distributed TE >> profile, the resulting path placement, computed independently by different >> ingress nodes, is not arbitrary; it becomes intentionally polarized onto a >> narrower set of links. Over time, as tunnel bandwidth is resized and >> re-optimized, this polarization naturally converges toward the most >> efficient set of links, while leaving other links unused. >> >> The mechanism proposed in draft-many-teas-power-steering is conceptually >> no different. By carrying power-group information in the TED, distributed >> TE path computation gains the same kind of local biasing capability: >> ingress nodes can optimally place paths by taking power-group information >> into account, thereby consolidating traffic and increasing the number of >> links that may be eligible for power-sleep. In other words, the goal is not >> to compete with global coordination, but to make distributed TE path >> placement more effective overall without requiring a controller-based >> optimization loop for every case. >> >> The key point is that path selection can be made “network-aware” — and >> this is where the IGP extensions come into play — even without full >> centralized coordination. The effect may be more gradual than a >> controller-based optimization, but it is still a real and effective >> mechanism for driving traffic onto a preferred subset of links and creating >> power-sleep opportunities in a scalable manner. >> >> Regards, >> -Pavan >> >> On Fri, Sep 4, 2026 at 12:13 PM Robert Raszuk <[email protected]> wrote: >> >>> Hi Colby, >>> >>> I am not sure John is suggesting GCO. I think he as few other folks on >>> this list are simply puzzled to how your proposal works in practice. >>> >>> I voice my questions few time - but did not get any clear answer. Namely >>> my doubt comes down to the below question (maybe John and few others are >>> also wondering about this too) >>> >>> Assume there is set of links and there are network resources which would >>> have sufficient capacity to carry traffic from those links. Of course >>> assume 100% TE. >>> >>> The question is how would you assume that few hundreds of headends will >>> at their time to reoptimize LSPs act in concert that the same set of links >>> is being dried out ? >>> >>> Well I have had a nice chat with Tony on the side and he revealed one >>> subtle but vastly important point. The capability that given link can be >>> put to sleep is not really a constant capability of that link. The same >>> applies to Power Group. So such "capability" is advertised when some oracle >>> thinks it makes sense. It is not described in ISIS draft like this. >>> >>> I guess all we are asking here is to learn if this advertisement (via >>> IGP flooding) at specific time intervals of the network is what makes the >>> hope that even 100s of headends will notice that and will start their own >>> attempt to shift the traffic on links not painted as sleep capable. It may >>> actually work at scale it is just that current version of the draft is not >>> make it clear. >>> >>> Cheers, >>> R. >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> On Fri, Sep 4, 2026 at 6:03 PM Barth, Colby <jonathan.barth= >>> [email protected]> wrote: >>> >>>> 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 <jonathan.barth= >>>> [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 <jonathan.barth= >>>> [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] >>>> <[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] >>>> >>>> _______________________________________________ >>>> 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] >> >> _______________________________________________ > 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]
