Hi David, A few thoughts. 1st, a picture is worth 1,000 words for me! Are you describing a switch architecture such as this?
[image.png] I think you could describe it, with the current proposal, like this: Power-grp1 FE0 + FE1 parent: none Power-grp 2 FE0 parent: pwr-grp1 Interfaces 1-48 - pwr-grp1 Interfaces 1-24 - pwr-grp2 Pwr-grp2 would attract traffic 1st because of the lower power value. The above resorts to forcing a bit of port numbering/ deployment discipline though. The other option, is to treat it a bit like a LAG and either advertise sleeping BW or its purely a local platform decision based on load. Hth, —cb Juniper Business Use Only From: David 'equinox' Lamparter <[email protected]> Date: Monday, November 3, 2025 at 11:33 AM To: Tony Li <[email protected]> Cc: [email protected] <[email protected]>, [email protected] <[email protected]> Subject: Re: [Lsr] lsr-power-group: flattened representation & static-ish inventory? [External Email. Be cautious of content] (inline) On Mon, Nov 03, 2025 at 11:06:38AM -0500, Tony Li wrote: > On Mon, Nov 3, 2025 at 10:57 AM David 'equinox' Lamparter - equinox at > diac24.net <[email protected]> wrote: > > - is it really a good idea to assume power usage is hierarchical? > > We didn't get into it in the presentation, but we are not assuming that > power usage is a single hierarchy. In fact, for the cases of LAGs, we need > multiple hierarchies, as a LAG can span multiple line cards and NPUs. > > > I'm not a low-level hardware person, but to my knowledge there are e.g. > > platforms that have crosspoint switches between their front panel ports and > > the forwarding engines. AIUI this is more of a reliability/redundancy > > thing, but that doesn't preclude its use for optimizing power usage. Such > > a platform might have, say, 4 pairs of interfaces that can each be swapped > > between 2 forwarding engines. (There are probably more complicated setups > > too, but AIUI this is a realistic example.) > > We have not gotten into the situation where an interface can swap between > forwarding engines, but you could easily model any single configuration > hierarchically. > > A power group can represent the entire crosspoint switch, with each > forwarding engine as a power-group with the crosspoint switch as a parent. Okay, I'm not sure I understand the TLVs correctly then. How can you model the case where you can switch off one of the FEs if only one of a pair each of physical interfaces is active? Actually - better question. Looking at the crosspoint, would this model the *current* state or *possible* states? I agree it is trivial to model the current state, but can you [or do you want to] express the possibility of changing the crosspoint configuration? > > - how much of this is dynamic/worth putting into IS-IS, vs. how much of > > this would be better served getting pulled from the routers via > > netconf/inventory? > > We have been trying for years to get the appropriate YANG model > standardized. The GREEN WG is still discussing terminology. We are not > young enough to take that path. I believe I am younger than you, but yes, this is why I went with "I'm not sure" ;-) > > (And, just to point out, the usage of live/actual power data is somewhat > > limited by the fact that it won't be available for sleeping interfaces, and > > you can probably get some very ugly oscillations if you have live data from > > running interfaces competing with stale or theoretical data for sleeping > > interfaces. Even freezing the last known is finnicky if the entire system > > then heats up and everything uses 25% more power.) > > In most cases, getting live/actual power is very hard. Most devices don't > have a built-in power meter. As I said at the mic, we are hoping for best > effort numbers, which in many cases, will be a static average-case number. Ok, I wasn't sure how dynamic this data would be/where it'd be sourced from. That said, it probably makes sense to incorporate a warning about this into the document ("don't try to be clever if you have live consumption data, you can shoot yourself in the foot with oscillations") -equi
img-97f21ecc-3c82-48c7-a053-7ee524f6d299
Description: img-97f21ecc-3c82-48c7-a053-7ee524f6d299
_______________________________________________ Lsr mailing list -- [email protected] To unsubscribe send an email to [email protected]
