{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]
