Robert, Even a controller needs to sync topology state from the network and that may take more time than normal IGP flooding.
-- Colby From: Robert Raszuk <[email protected]> Date: Friday, September 11, 2026 at 6:13 AM To: Aijun Wang <[email protected]> Cc: Barth, Colby <[email protected]>; Vishnu Pavan Beeram <[email protected]>; John Drake <[email protected]>; John Drake <[email protected]>; Tony Li <[email protected]>; WG TEAS <[email protected]>; lsr <[email protected]> Subject: Re: [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 Aijun, Can we call such features as “undetermined ”? Sure ... even with controllers in place nothing is 100% deterministic here. Simply because you can only try to predict the future of your transit traffic demands. See controller will be doing the very same computation. However the difference when using a controller - it will always have a full picture of the resources. With distributed reoptimization you need to wait for your IGP reflooding or RSVP-PATH failures to know that some capacity has been already "reserved" by some other node. So the way I look at this is that distributed CSPF and controller based may eventually lead to pretty much the same final state .. it is just in the controller case you will achieve it faster as it immediately has full view of the entire network and its resources. And, following your example, the challenge is, how to select the subset of links that be put down, if many of their PCPPS are same? You simply exclude all of them from CSPF and see during computation if what's left still meets the TE policies. No great magic there. Thx, R. Aijun Wang China Telecom On Sep 10, 2026, at 19:48, Robert Raszuk <[email protected]<mailto:[email protected]>> wrote: Hi Aijun, The entire idea of distributed TE is no coordination between headends and it still works. Imagine a constraint - link failed in the core. All headends see it and recomputre their LSPs such that the given link is not considered in CSPF. Here we are dealing with similar constraint ... ie. a hint flooded to headends to try to avoid the links which are to be put to sleep. Yes in both examples there will be contention for BW on the remaining links ... yes in both cases RSVP PATH may fail to setup LSP, but this is how distributed TE works since day one. That is btw why in TE we have quite a lot of control to prioritize LSP between each other, we have preemption etc ... But eventually LSPs get moved to those links in the topology which are not going to be put to sleep. If there is no free capacity and if operator does not agree to put a link to sleep even with some remaining LSPs still traversing it the link will be kept up. Authors call it a feature and I will agree with them on this. Best, R.
_______________________________________________ Lsr mailing list -- [email protected] To unsubscribe send an email to [email protected]
