Hi John, No one is giving you different versions of the same story. I take offense to the accusation. We have been consistent from the start, albeit maybe intentionally vague at times.
"Speaking of which, as I have noted, there is no way to optimize power management for TE links in a distributed solution. ” This statement is completely incorrect. "There is also no way to optimize power management between TE and non-TE links in a given network, or in an all non-TE network.” As previously noted(multiple times), this is a TE solution. -- Colby From: John Drake <[email protected]> Date: Sunday, September 6, 2026 at 11:10 AM To: Robert Raszuk <[email protected]> Cc: Barth, Colby <[email protected]>; John Drake <[email protected]>; Vishnu Pavan Beeram <[email protected]>; Aijun Wang <[email protected]>; Tony Li <[email protected]>; WG TEAS <[email protected]>; lsr <[email protected]> Subject: Re: [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) Robert, I think we’re dealing with the ‘Rashomon’ effect. Nominally, the authors understand this proposal and should be able to consistently answer questions, comments, concerns, and suggestions regarding it. Speaking of which, as I have noted, there is no way to optimize power management for TE links in a distributed solution. There is also no way to optimize power management between TE and non-TE links in a given network, or in an all non-TE network. John Sent from my iPhone On Sep 6, 2026, at 9:14 AM, Robert Raszuk <[email protected]> wrote: Hi John, I think there is a subtle disconnect between what you consider as an "Oracle" and definitions of centralized vs distributed models for preparing the network for power saving. Of course if one would push configuration from central mgmt station at specific times to start advertising links as power sleep capable - that would fall under centralized configuration model - but as we know configuration is still centralized. (For now I am not talking about autonomous (or self driving) networks). And I think you are pointing this piece of the solution. However if someone configures his routes to start advertising power sleep capable links by cron say between 1:00 AM and 6:00 AM every day (in his local time zone) then I am not so sure if this falls under a centralized model. To me this is much more of a distributed one. - - - But either way to me it really does not matter if we are dealing with centralized trigger or a distributed one. The ISIS extension role is still to flood additional TE information such that all headends augment (or include it) in their CSPF computation. And this is where the real distributed vs centralized approach makes a difference. Clearly I have not seen in any of the authors emails or documents anything which would indicate otherwise. The analogy would be for controller or PCE to compute TE policies and push them to headends. Yes that may be in fact a much more accurate option, but not everyone out of those using full TE in their networks like to have a controller driven traffic management. Or even if they do it is still perhaps safe to have a fallback to a distributed option before falling back on pure SPF based forwarding. Kind regards, Robert On Sun, Sep 6, 2026 at 2:44 PM John Drake <[email protected]<mailto:[email protected]>> wrote: Hi, Yes, I did see these emails. My impression was that they said very little and they said it at great length. Marketing brochures come to mind. If we assume that Robert’s email, describing Tony’s explanation of how this proposal is supposed to work, is to be ignored as your email seems to suggest, then we are back to a situation in which all of the questions and comments which have posted, including mine, are back in play. John Sent from my iPhone On Sep 6, 2026, at 8:02 AM, Barth, Colby <[email protected]<mailto:[email protected]>> wrote: Hi John, The solution that would leverage these proposed IS-IS extensions does not require an “Oracle” though they do not preclude the use of a Controller should an operator prefer that model. I’m repasting Pavan and Ron’s emails. Maybe you missed them? Ron Bonica wrote: "Each of you have expressed concern regarding a distributed approach to the Power Conserving Path Placement Strategy (PCPPS). The following is a response. A Power Conservation Strategy includes many components. First among them is the Path Placement Component. The Path Placement Component concentrates traffic onto relatively few network resources during periods of low demand and redistributes traffic during periods of high demand. It *does not* power interfaces up and down. Its only function is path computation. When it computes paths, it optimizes for energy efficiency, leaving some network resources idle or nearly idle. Another component is the Sleep Management Component. The Sleep Management Component is configured with criteria that must be satisfied before a network resource is powered down. It monitors network resources and powers them down when they satisfy the configured criteria. It also powers them up again when the power up criteria are satisfied. The Power Placement Component and Sleep Management Component are decoupled from one another. In the simplest case, one could run a Path Placement Component without a Sleep Management Component. (Although I can't imagine why). One could also run a Sleep Management Component without a Path Placement Component. In some networks, and for some power down criteria, this makes sense. In a more complex case, the Sleep Management component may require information from the Path Placement component to determine if an interface satisfies the power-up/power-down criteria. For example, the Sleep Management algorithm may prevent interfaces that support LSPs from being powered down. Draft-many-teas-power-steering and draft-many-lsr-power-groups describe the Path Placement Component. They *do not* describe the Sleep Management function. This is beyond their scope. Many of your comments address the Sleep Management function. For example: * You will not find an instruction to power an interface up or down in either of the current drafts * The problem of oscillation due to frequent power-up/power-down events is beyond the scope of the current documents, because they do not power network resources up or down. Finally, regarding the question of distributed versus centralized implementation..... Path Placement Strategies rely on CSPF and the CSPF relies on the LSDB/TED. Each node must maintain an identical LSDB copy. In the past, we have populated the LSDB/TED in a distributed manner, using an IGP, or in a centralized manner, using a PCE and BGP-LS. Both approaches work. Some customers prefer one while other customers prefer the other. The Power Conserving Path Placement Strategy is no different from legacy path placement strategies. There is no reason why it should be limited to one approach or the other." Pavan Beeram wrote: "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.” Thanks, -- Colby From: John Drake <[email protected]<mailto:[email protected]>> Date: Saturday, September 5, 2026 at 10:13 AM 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]>>; 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: Re: Re: [Green] 【Distributed Power-aware TE is Impossilbe】RE: RV: Call for adoption: draft-many-teas-power-steering-01 (Ends 2026-09-10) Robert, Thanks for the reply. I did see that but I assumed it was the first thing that occurred to Tony in response to a question from you. So, we have an Oracle that selects which links to potentially power-down and which sends a message, to be defined, to every node that has an endpoint of at least one of the selected links? But this is in no way, shape, or form a centralized solution? Each of these nodes then sends a link state update for each of the selected links for which it is an endpoint? If the link does not support TE the link state update contains a bumped up link metric? If the link supports TE the link state updates contains contains a bumped up link metric for the non-TE traffic, to quickly move it away from the link, a bumped up TE metric for those nodes that don’t support the new power management TLVs, and the power management TLVs for those that do? Since the Oracle has already selected the links to be potentially powered down, why is including the power management TLVs necessary? The IGP is used to send the power management TLVs from each node that supports power management to the Oracle? Why is this necessary? Are there not a multiplicity of methods by this information could be conveyed? A related question is how is power management information for a link that is not configured to support TE conveyed to the Oracle? Thanks, John Sent from my iPhone On Sep 4, 2026, at 5:46 PM, Robert Raszuk <[email protected]<mailto:[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]<mailto:[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]<mailto:[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]<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]<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]<mailto:[email protected]> To unsubscribe send an email to [email protected]<mailto:[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]
