Hi, Tony:
Let me state the logic more clear: 1) One headend(headend A) use the “most-fill” strategy to move the traffic out of a set of links, let’s call it “Set A” 2) Another headend(headend B) use also its “most-fill” strategy to move the traffic out of a set of links, let’s call it “Set B”. 3) According to the previous discussions, we can know there is no theoretical guardedness that can assure the “Set A” is equal to “Set B” , Right? If luckily, “Set A” is equal “Set B”, the set of these links are idle now, how can you assure there will be no other headend(headend C) will allocate its LSP on such sets of the links later? If you can’t assure, when will the nodes that connects these idle links power off the these links then? If you can’t power off the links, even they are idle for a long time, where is the cost saved? Where is the benefits of applying the distributed power-save TE? Best Regards Aijun Wang China Telecom From: [email protected] [mailto:[email protected]] On Behalf Of Tony Li Sent: Monday, September 21, 2026 2:13 PM To: Aijun Wang <[email protected]> Cc: Vishnu Pavan Beeram <[email protected]>; Vishnu Pavan Beeram <[email protected]>; Adrian Farrel <[email protected]>; Barth, Colby <[email protected]>; Robert Raszuk <[email protected]>; John Drake <[email protected]>; John Drake <[email protected]>; WG TEAS <[email protected]>; lsr <[email protected]> Subject: Re: [Lsr] [Teas] Re: Re: 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 Aijun, Let’s give you one another example that demonstrates that bandwidth management is different from the power-aware TE: Power-aware TE is part of bandwidth management. It is an optional portion used to also save power under low bandwidth utilization. Image the hotel booking scenario, if you book one room(similar with bandwidth usage is full), no other guest will book again. But if the room isn’t reserved (no traffic via it), the manager will not take the room out of their website.------Because he can’t assure there will be no other guest to book this vacant room in future. I’m sorry, I can’t parse this. Back to our scenario, if fortunately, the traffic on some links are cleared, the nodes connecting these links shouldn’t still make these idle links sleep, because these nodes don’t know the LSP requirements from other headend. If a link is idle, then there are no LSPs assigned to that link. By definition, for the link to be idle all LSPs must be assigned to other acceptable paths. If the headend doesn’t know when to sleep the idle links, how to save costs (“millions of dollar?”)? The headend is not responsible for sleeping idle links. It is only responsible for placing LSPs on other links. The nodes that are the link endpoints are responsible for putting the link to sleep. And, we should be aware, as the operator, to keep the service uninterrupted is the first aim. That is very much the primary goal. Tony
_______________________________________________ Lsr mailing list -- [email protected] To unsubscribe send an email to [email protected]
