Hi Tony, Ok so what you are saying the algorithm which decides that it is OK to shut down a link needs to verify first if there is sufficient capacity within each flex-algo present on that link to carry the offloaded traffic.
Is this correct ? I don't know how would it do that. I am not seeing anywhere in the document such statement. In fact I am not seeing any way to associate RSVP-TE LSPs or CSPF with Flex-Algos. RFC9350 does not provide much clue in that either. Thx a lot, R. On Wed, Jul 22, 2026 at 12:27 PM Tony Li <[email protected]> wrote: > Hi Robert, > > No, I am being entirely consistent. I'm sorry if you find it to be > unclear. > > A particular interface or component can be used by one or more flex-algo > topologies. An interface or component may be placed into power sleep > state, where it will carry no traffic. Traffic will need to be diverted to > the remainder of the flex-algo topology. > > The current proposal is wholly compatible with and orthogonal to flex-algo. > > Tony > > > On Wed, Jul 22, 2026 at 12:14 PM Robert Raszuk <[email protected]> wrote: > >> 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]
