Hi Colby, True .. at t=0 controller needs to learn network topology. And I see no reason why passive listening to IGP flooding would not be sufficient for that. **
But at t>0 if we are doing controller based TE while still listening to topology state (for link or node failures) the TE load would be rather known locally to such a controller. That was my point. ** I am not subscribing to BGP-LS "invention". Cheers, R. On Fri, Sep 11, 2026 at 1:29 PM Barth, Colby <[email protected]> wrote: > 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]> 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]
