Hi Tony, Ok so we established that at best for 1RUs boxes you could turn off the laser.
> The low link utilization for transition to power sleep is a configurable level. My question was the opposite. Let me rephrase - What is the ceiling in % you would allow to consolidate traffic onto any link ? I don't think this is "beyond the scope of the doc" and making it configurable 0-100% is an answer. Quite contrary IMO. And seeing proposals in LSR which actually aim to do the opposite (spread traffic when threshold is exceeded on a link) it becomes an interesting question which way operators should go :) > The use of power groups would not change the flex algo topology. Yes, that is pretty obvious. > Traffic would remain within the same algorithm. So to make sure I understand .. you can only consolidate within the boundaries of a given Flex-Algo ? I do not see anywhere in the document including section 3.1 how do you associate flexible-algorithms topology to power groups. Note that a link/interface can belong to more than one flex-algo. With that I think the current encoding does not seem to provide a per flex-algo association. Kind regards, Robert On Wed, Jul 22, 2026 at 8:07 AM Tony Li <[email protected]> wrote: > > Hi Robert, > > Dealing with a pizza box is straightforward. In section 3.3.2 we describe > the interface PSP TLV. This carries the power savings potential for an > interface. The power consumption of the QSFP would belong in that TLV. > > The low link utilization for transition to power sleep is a configurable > level. > > The use of power groups would not change the flex algo topology. Traffic > would remain within the same algorithm. > > Tony > > > On Tue, Jul 21, 2026 at 11:01 PM Robert Raszuk - robert at raszuk.net < > [email protected]> wrote: > >> Hi Ron, >> >> I am not sure what types of platforms Zafar had in mind but I would be >> interested in your response how do you apply concept of power groups >> to single-chip/systems-on-chip (SoCs) 1RU pizza ODM boxes. >> >> Would you say put each QSFP into a separate group and the only saving you >> could claim is to turn off laser on the selective sender interfaces after >> drying the entire traffic on it ? >> >> - - - A side two question - - - >> >> 1) >> To what % number of link utilization do you consider acceptable to >> consolidate traffic for the purpose of power saving on some other links ? >> >> 2) >> If the network is built in a bit complex way ... say there is Algo 0 but >> also 16 other Flex_Algo topologies I have a question how do you account for >> that such that before the optimization and after optimization traffic >> suddenly is not forwarded in a "foreign" topology ? Or is the current >> proposal simply not interested in addressing such networks ? >> >> Thx, >> R. >> >> >> >> >> >> >> On Mon, Jul 20, 2026 at 9:55 AM Bonica, Ron <ronald.bonica= >> [email protected]> wrote: >> >>> Zafar, >>> >>> If I understood your comment during the IETF 126 session correctly, you >>> said that the Power Group model may not support some existing hardware >>> architectures. Can you describe such an architecture? >>> >>> Ron >>> _______________________________________________ >>> 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] >> >
_______________________________________________ Lsr mailing list -- [email protected] To unsubscribe send an email to [email protected]
