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] > >
_______________________________________________ Lsr mailing list -- [email protected] To unsubscribe send an email to [email protected]
