Hi, Vishnu:
Power-aware TE requires network-wide polarize, it is more strict than “distributed bandwidth-engineered networks”, which is node-wide polarize. Image one simple example: Let’s assume the each headend synchronizes their necessary information, and the network utilization is almost same in two links. To achieve “network-wide” polarize effect, we need to assure each headend calculate its CSPF computation in sequence, or there will be no deterministic results that they will select the same sleepable link. For some more complex network, it will be more challenge to achieve such “network-wide” polarize effect”. In order to close the argument, similar with the comments from Adrian, I think the document should provide: 1) Either the limited scope of distributed power-aware TE can be applied. 2) Or, detail algorithm that it can apply in most of the network real network. Given the network has enough capacity to concentric traffic. Best Regards Aijun Wang China Telecom From: [email protected] [mailto:[email protected]] On Behalf Of Vishnu Pavan Beeram Sent: Thursday, September 17, 2026 6:54 AM To: [email protected] Cc: Barth, Colby <[email protected]>; Aijun Wang <[email protected]>; Robert Raszuk <[email protected]>; John Drake <[email protected]>; John Drake <[email protected]>; Tony Li <[email protected]>; WG TEAS <[email protected]>; lsr <[email protected]> Subject: [Lsr] Re: [Teas] Re: Re: Re: Re: Re: Re: [Green] 【Distributed Power-aware TE is Impossilbe】RE: RV: Call for adoption: draft-many-teas-power-steering-01 (Ends 2026-09-10) Hi Adrian, I just realized that this email had not yet received a response. Thank you for your thoughtful comments. Regarding applicable topologies, I believe any topology in which distributed TE, or distributed bandwidth engineering, is deployed today could also be relevant for distributed power-aware TE. As you noted, distributed TE may not achieve a globally optimal network-wide outcome. However, this has not prevented operators from deploying it successfully across a variety of topologies and operating conditions. Mechanisms such as most-fill tie-breakers are widely used to polarize traffic in distributed bandwidth-engineered networks. The same principle applies to power-aware TE. The draft also notes that PCPPS can be applied when CSPF is performed centrally or in a distributed manner. Nothing in the draft precludes a centralized computation function from using the PCPPS metric and associated power-awareness information. More generally, power-aware TE is most likely to be effective in networks with sufficient spare capacity and enough path diversity or mesh connectivity to consolidate traffic without violating bandwidth, redundancy, or other constraints. These conditions apply to both centralized and distributed computation, although centralized computation can typically achieve better consolidation more quickly. The intent of the draft is not to claim that distributed PCPPS provides global optimization. Rather, it extends the CSPF model by adding power awareness, allowing the computation function, whether centralized or distributed, to bias path placement toward appropriate resources when topology, traffic, and capacity permit. If consolidation cannot be achieved without compromising capacity, redundancy, or other constraints, the relevant resources should remain active. Best regards, Pavan On Tue, Sep 8, 2026 at 3:49 PM Adrian Farrel <[email protected] <mailto:[email protected]> > wrote: Hello all, Colby said “TE solutions aren’t required to be globally optimal to be effective.” And he is right, and this is possibly one of the messages of RFC 9522. However, the perils of non-centralised systems are also well-known. As the network resources get more contested (i.e., as the traffic load approaches network capacity), distributed TE is increasingly likely to cause blocked contention. And, of course, it is always possible to derive degenerate examples where even simple networks and loads will fail in the distributed case, but can be solved with a centralised view. None of this is new or shocking. Practically, if the sizes of flows are small relative to the capacity of links, distributed TE works well until the links are almost full. In fact, when the sizes of the flows are quite a bit smaller than the unused link bandwidths and/or when the network is very meshy, distributed TE will be fine. Curiously, one of the early motivations for PCE was distributed *re*-optimisation which tended (in the way of all things) to converge on a synchronous moment which increased the chances of contention. But, to cut back to this conversation, it may be helpful to describe the types of network where distributed power-aware TE is applicable/satisfactory and contrast with the types of network where centralisation is to be preferred. Adrian From: Barth, Colby <[email protected] <mailto:[email protected]> > Sent: 08 September 2026 14:08 To: Aijun Wang <[email protected] <mailto:[email protected]> >; 'Robert Raszuk' <[email protected] <mailto:[email protected]> > Cc: 'Vishnu Pavan Beeram' <[email protected] <mailto:[email protected]> >; 'Barth, Colby' <[email protected] <mailto:[email protected]> >; 'John Drake' <[email protected] <mailto:[email protected]> >; 'John Drake' <[email protected] <mailto:[email protected]> >; 'Tony Li' <[email protected] <mailto:[email protected]> >; 'WG TEAS' <[email protected] <mailto:[email protected]> >; 'lsr' <[email protected] <mailto:[email protected]> > Subject: [Teas] Re: [Lsr] Re: Re: Re: Re: Re: [Green] 【Distributed Power-aware TE is Impossilbe】RE: RV: Call for adoption: draft-many-teas-power-steering-01 (Ends 2026-09-10) Hi Aijun, I’ll try to repeat what Robert said in a different way. TE solutions aren’t required to be globally optimal to be effective. Consider BW optimization as an example; there is no debate that a centralized computation may result in a more optimal state (at least on paper) than a fully distributed solution but a distributed solution still produces better BW optimization than doing nothing at all. If you are arguing that path computation MUST be centralized, that is incorrect. Evidence by the very, very big networks out there operating successfully using distributed TE. -- Colby From: Aijun Wang <[email protected] <mailto:[email protected]> > Date: Monday, September 7, 2026 at 9:28 PM To: 'Robert Raszuk' <[email protected] <mailto:[email protected]> > Cc: 'Vishnu Pavan Beeram' <[email protected] <mailto:[email protected]> >; 'Barth, Colby' <[email protected] <mailto:[email protected]> >; 'John Drake' <[email protected] <mailto:[email protected]> >; 'John Drake' <[email protected] <mailto:[email protected]> >; 'Tony Li' <[email protected] <mailto:[email protected]> >; 'WG TEAS' <[email protected] <mailto:[email protected]> >; 'lsr' <[email protected] <mailto:[email protected]> > Subject: [Teas] Re: [Lsr] Re: Re: Re: Re: Re: [Green] 【Distributed Power-aware TE is Impossilbe】RE: RV: Call for adoption: draft-many-teas-power-steering-01 (Ends 2026-09-10) Hi, Robert: If the network are composed by some power aware links, and also some power unaware links, the traffic may be converged into the power unaware links, but such effects can be achieved only under some specific network topology. That is to say, such solution is not one generalize solution, and can’t get the deterministic effect. And, if the network evolved to the state that links are all power aware, it is impossible to find some special links, penalize them at the same time by every headend, and then move the traffic out of these Oracle-selected links. To Tony’s example of “Nash Equilibrium”, we should know “Nash Equilibrium” is not equal “Global Optimum”(POA=1). If you want to prove you have the mechanism to overwritten the above conclusion, please state clearly your mechanism, and then the necessary extension of the IGP protocol. Until now, we can still make the following conclusions: 1) The proposal has no deterministic global effect, that can assure the traffic being centralized successfully on some limited links, in any arbitrary topology. 2) The proposal can only apply to the 100% TE controlled network, which is rarely in real network. 3) There is no detail mechanism description in the current document, or in other references documents that can achieve the power saving goal aim. Best Regards Aijun Wang China Telecom From: [email protected] <mailto:[email protected]> [mailto:[email protected]] On Behalf Of Robert Raszuk Sent: Monday, September 7, 2026 6:29 PM To: Aijun Wang <[email protected] <mailto:[email protected]> > Cc: Vishnu Pavan Beeram <[email protected] <mailto:[email protected]> >; Barth, Colby <[email protected] <mailto:[email protected]> >; John Drake <[email protected] <mailto:[email protected]> >; John Drake <[email protected] <mailto:[email protected]> >; Tony Li <[email protected] <mailto:[email protected]> >; WG TEAS <[email protected] <mailto:[email protected]> >; lsr <[email protected] <mailto:[email protected]> > Subject: [Lsr] Re: [Teas] Re: Re: Re: Re: [Green] 【Distributed Power-aware TE is Impossilbe】RE: RV: Call for adoption: draft-many-teas-power-steering-01 (Ends 2026-09-10) Hi Ajiun, Actually if you zoom into how CSPF really works what the draft assumes (distributed TE computation) and shifting paths onto non power saving designated links is very much possible. To understand it just forget about all of the power stuff. Imagine you are running a vanilla TE with ISIS extensions as described in RFC5305 So here you already have number of ways to discourage CSPF on all headends to keep using link which you would advertise using sub-TLV 18 (Traffic Engineering Default Metric) and apply there for example MAX_PATH_METRIC. I see no reason why this would not result in all headends running their independent CSFP to avoid such link. I also see no oscillation affecting the subject link. Of course when more then one ingress node will start compete for the TE bw of some non power aware link there could be collisions - but those are normal in TE world and most robust TE implementations know how to handle it. Cheers, R. On Mon, Sep 7, 2026 at 2:45 AM Aijun Wang <[email protected] <mailto:[email protected]> > wrote: Hi, Vishnu(and also Barth, Tony, or other experts who support such proposal) We are arguing that, even in 100% TE environment, “Distributed Power-aware TE” is impossible, if the headend routers don’t exchange their path calculation results. Let’s make the analogy as “the WG document adoption call”-----each expert make the judgement based on his/her own knowledge. Even we exchange intensely our thoughts on the mail list, there are difficulties to make the consensus---how can you expect each headend can coordinate with each other, or, without coordinating with each other, to make the same decision, to put out of their own traffic out of one specific link? Some detail replies for your arguments are inline below. Best Regards Aijun Wang China Telecom From: [email protected] <mailto:[email protected]> [mailto:[email protected] <mailto:[email protected]> ] On Behalf Of Vishnu Pavan Beeram Sent: Saturday, September 5, 2026 4:48 AM To: Robert Raszuk <[email protected] <mailto:[email protected]> > Cc: Barth, Colby <[email protected] <mailto:[email protected]> >; John Drake <[email protected] <mailto:[email protected]> >; John Drake <[email protected] <mailto:[email protected]> >; Aijun Wang <[email protected] <mailto:[email protected]> >; Tony Li <[email protected] <mailto:[email protected]> >; WG TEAS <[email protected] <mailto:[email protected]> >; lsr <[email protected] <mailto:[email protected]> > Subject: [Lsr] Re: [Teas] Re: Re: Re: Re: [Green] 【Distributed Power-aware TE is Impossilbe】RE: RV: Call for adoption: draft-many-teas-power-steering-01 (Ends 2026-09-10) {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. [WAJ] Each headend make the decisions themselves, How can you get the “globally useful direction”? please explain this conclusion in detail. 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. [WAJ] “Such polarized effect” is your aim, but you don’t describe how to achieve it. This is key argument points. Would you elaborate it in more detail? 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. [WAJ] If the aim can’t be achieved, we will not evaluate whether it is efficient or not. 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. [WAJ] Path selection can be made “network-aware”, but can’t achieve the “network-wide” effect. Because each headend determine the “network-aware” path itself. It will make the traffic oscillation, not concentrated. Regards, -Pavan On Fri, Sep 4, 2026 at 12:13 PM Robert Raszuk <[email protected] <mailto:[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 <[email protected] <mailto:[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] <mailto:[email protected]> > Date: Friday, September 4, 2026 at 8:29 AM To: Barth, Colby <[email protected] <mailto:[email protected]> > Cc: John Drake <[email protected] <mailto:[email protected]> >; Aijun Wang <[email protected] <mailto:[email protected]> >; Tony Li <[email protected] <mailto:[email protected]> >; WG TEAS <[email protected] <mailto:[email protected]> >; lsr <[email protected] <mailto:[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] <mailto:[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] <mailto:[email protected]> > Date: Friday, September 4, 2026 at 7:14 AM To: Barth, Colby <[email protected] <mailto:[email protected]> > Cc: Aijun Wang <[email protected] <mailto:[email protected]> >; Tony Li <[email protected] <mailto:[email protected]> >; WG TEAS <[email protected] <mailto:[email protected]> >; lsr <[email protected] <mailto:[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] <mailto:[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] <mailto:[email protected]> > Date: Thursday, September 3, 2026 at 6:23 PM To: 'Tony Li' <[email protected] <mailto:[email protected]> > Cc: 'TEAS WG' <[email protected] <mailto:[email protected]> >; 'lsr' <[email protected] <mailto:[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]> [mailto:[email protected]] On Behalf Of Tony Li Sent: Friday, September 4, 2026 3:18 AM To: Aijun Wang <[email protected] <mailto:[email protected]> > Cc: TEAS WG <[email protected] <mailto:[email protected]> >; lsr <[email protected] <mailto:[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] <mailto:[email protected]> To unsubscribe send an email to [email protected] <mailto:[email protected]> _______________________________________________ Teas mailing list -- [email protected] <mailto:[email protected]> To unsubscribe send an email to [email protected] <mailto:[email protected]> _______________________________________________ Teas mailing list -- [email protected] <mailto:[email protected]> To unsubscribe send an email to [email protected] <mailto:[email protected]> _______________________________________________ Lsr mailing list -- [email protected] <mailto:[email protected]> To unsubscribe send an email to [email protected] <mailto:[email protected]> _______________________________________________ Teas mailing list -- [email protected] <mailto:[email protected]> To unsubscribe send an email to [email protected] <mailto:[email protected]> _______________________________________________ Lsr mailing list -- [email protected] <mailto:[email protected]> To unsubscribe send an email to [email protected] <mailto:[email protected]>
_______________________________________________ Lsr mailing list -- [email protected] To unsubscribe send an email to [email protected]
