Hi Robert, The maximum link utilization is configurable and not defined by our specifications. Use whatever traffic level you feel comfortable with.
The answer that you're looking for is simple: you spread traffic when you need all of your capacity. You consolidate your traffic when you have excess capacity. As I previously mentioned, we do not have a specific per-flex-algo application. Power sleep is applied on a per-component basis and may affect multiple algorithms. Tony On Wed, Jul 22, 2026 at 11:48 AM Robert Raszuk <[email protected]> wrote: > 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]
