Hi John, > Rather, I have consistently indicated my preference for the > provisioning system, since that is the entity which controls > the resources in a network.
My understanding is that no one is arguing that. Best, R. On Fri, Sep 11, 2026 at 2:34 PM John Drake <[email protected]> wrote: > Hi, > > I have tried to avoid the term 'controller' because that term seems to > have the connotation of 'the entity which computes paths on behalf of other > nodes' which is NOT at all what I am talking about. > > Rather what I am talking about is the entity that decides at every point > in time the set of links that can be used to carry traffic and the set of > links which can’t and which distributes this information to all of the > nodes in the network. > > This is the entity which provides, as Robert blithely describes in one of > his earlier emails: "a hint flooded to headends to try to avoid the > links which are to be put to sleep". > > I think this is a big job and one which can't be done in a distributed > manner. Rather, I have consistently indicated my preference for the > provisioning system, since that is the entity which controls the resources > in a network. > > As an aside, I am completely happy with distributed path computation. > > Thanks, > > John > > On Friday, September 11, 2026 at 04:29:07 AM PDT, 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]
