Hi Robert, What I'm saying is that this is a draft about encoding power information in IS-IS. There is no reason that I can see that this could not be used in a flex algo network.
As you've seen, we have a draft in TEAS that discusses more about how to use this information. There probably needs to be another draft about using power information within flex algo, but that should be a separate document in TEAS. Regards, Tony On Wed, Jul 22, 2026 at 12:35 PM Robert Raszuk <[email protected]> wrote: > 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]
