Hi Tony, So in the first mail you said:
"Traffic would remain within the same algorithm." Now you are saying something opposite: "Power sleep is applied on a per-component basis and may affect multiple algorithms." I don't quite see how would you take into consideration in the current document flex-algo topologies. I am asking for it as it seems that perhaps the current encoding needs to change and if so it is better to do that before allocation. Or at least state in the draft that current proposal is not applicable to be used in networks which deploy flex-algo topologies. Many thx, R On Wed, Jul 22, 2026 at 12:06 PM Tony Li <[email protected]> wrote: > > 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]
