Well to me this is not a separate topic, but the key one for LSR WG. It is much more efficient to unicast information to a PCE or controller instead of flooding it. After all we are all doing this telemetry and YANG models so maybe we could try to make at least once some real use of that other then plotting it on the grafana dashboards only :).
I am not a big supporter of central path computation however here where we need to optimize bidirectional flows domain wide, doing it in a fully distributed manner is IMO not very deterministic. In fact set of mechanisms as defined today seems to have no correlation for both directions of transit flows. Regards, Robert On Tue, May 5, 2026 at 4:30 PM Joel Halpern <[email protected]> wrote: > My understanding from the draft and their emails is that the purpose is to > enable the path computation. Whether that is done via a PCE or done via a > distributed algorithm that converges to avoiding the same power groups > seems to be a separate topic from the advertisement draft. > > Yours, > > Joel > On 5/5/2026 3:15 AM, Robert Raszuk wrote: > > Hi Tony, > > >> I’m not understanding what you’re requesting. draft-many-lsr-power-group >> provides a basis for path computation that allows PCE implementations to >> consolidate traffic, thereby idling components that can be put into >> power-sleep. >> > > Till this sentence I was all under the impression (as we discussed offline > with Colby) that there is no need for PCE in your solution. And that your > solution is fully distributed hence we need to extend ls flooding to > distribute the constraints around. > > Has that changed ? > > Thx, > Robert > > > _______________________________________________ > Lsr 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]
