Hi Tony, Ok I see ... so this addition of TLVs and sub-TLVs is not to be used alone, but with already flooded other information for each interface. And in the case of regular networks (say flex-algo free) more details how they are used is described in draft-many-teas-power-steering-01.
For networks which use flex-algo another document is needed in TEAS. Let's however observe that title of current TEAS doc gives the impression to be covering this concept for all types of networks: *"A Power Conserving Path Placement Strategy (PCPPS)"* Thx. R. On Wed, Jul 22, 2026 at 1:45 PM Tony Li <[email protected]> wrote: > 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]
