Hi Tony, "reduce the paths of the packets" - I meant to say reduce number of paths (presumably TE end to end paths) the packets may take to traverse a domain from ingress to egress. Apologies for the shortcut.
Back to your case ... So assume there are two ingress nodes and two spine nodes. Both ingress nodes happen to be connected via the same ingress line cards of the respected two spines. Ingress_1 decides to move traffic to Spine_1 and Ingress_2 to move the traffic to Spine_2. Both make the decision independently. Q1 - How is this helping to put one of the spine's ingress line card to sleep (provided there is no demand which requires to run both ingress line cards on both spines) Q2 - Once the traffic is moved (of course in make-before-break) fashion who will trigger given line cards to go to sleep ? Is Spine going to do it all by itself or there will be some management station telling it - hey spine_x sleep your LC-N. ? Thx, R. On Sat, Aug 2, 2025 at 10:03 PM Tony Li <[email protected]> wrote: > > Hi Robert, > > > > Hmm so you are saying that you are proposing power optimisation > architecture without central controller which will have a global view of > all demands in the network and will reduce the paths of the packets ? > > > No, there is no global view of all demands. We are working towards a > distributed solution. I don’t understand what you mean by “reduce the paths > of the packets”. The point is to consolidate traffic as much as possible > with an eye towards taking all traffic off of an interface and then putting > the interface into power sleep. Further, if traffic can be sufficiently > consolidated, NPUs and line cards can be put into power sleep. This > results in a significant power savings. > > > > I am not seeing how can you do that safely with fully distributed and > independent CSPF running on each ingress only knowing his view of the > network. > > > As always, this is done with an understanding of the approximate current > loading of the network, with path setup done in a make-before-break > fashion. The only thing that changes over conventional traffic engineering > is that path computation also considers power consumption. > > > > Moreover as traffic is often bi-directional doing this independently in > both directions makes it even more fun to watch. > > > Indeed. > > > > And sure I am personally not a big fan of controllers too, but when it > comes to global view of the network I have not seen an alternative for any > type of optimization. > > > I will be the first to admit that a true global view is necessary to get > to optimal. However, if you’re willing to settle for Super Good Enough (TM > Ryan Jenks), we believe that you can get a near-optimal solution with a > distributed approach. > > Tony > > >
_______________________________________________ Lsr mailing list -- [email protected] To unsubscribe send an email to [email protected]
