(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
_______________________________________________
Lsr mailing list -- [email protected]
To unsubscribe send an email to [email protected]
