Hi Colby, Tony, Vishnu, Ron,
after let's call it "scrolling through" the power-group draft, I'm wondering two things: - is it really a good idea to assume power usage is hierarchical? 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.) Rather than expressing a hierarchy of power usage, I think it might be preferrable to completely "flatten it down" to a list of (boolean expression => power) items, with some provisions for efficient encoding. For example: For the example with a crosspoint, and assuming 5W per port, 50W per FE, the list would be something like: (1 xor 2 | 3 xor 4 | 5 xor 6 | 7 xor 8) => +50W (1 and 2 | 3 and 4 | 5 and 6 | 7 and 8) => +100W (1, 2, 3, 4, 5, 6, 7, 8) => +5W per interface (maybe this is 8 rules) Which your TE system then throws into a linear minimum solver to get a solution. (Which it's probably going to do anyway since even if you use a hierarchical per-router representation, the "beauty"/simplicity of that is going to fall apart when you add the second router.) The LC and FE from the example in your draft wouldn't directly exist in this representation, it'd be implicit in the list of rules. And, secondly: - 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? I agree that the "sleeping link" parts of this are valuable to have in IS-IS, but I'm not sure that this applies for the representation of ports and their power relationships. (To be clear, "I'm not sure" really is "I'm not sure" here, not a polite "I don't think so".) But it might be worth thinking through an approach where the more static information is pulled off netconf (it's not like you can't occasionally refresh that too). In particular, this would also allow giving multiple power values (minimum, average, current, maximum, design, etc.), and also make it easier to enter "override" rules if one of the 5 vendors in your network is holding the meter sideways while measuring power. (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.) Hope this is useful input, -equi (David) P.S.: I actually put a yes on the meetecho poll, so unfortunately this isn't in the category of "how to get the 'no's to 'yes'" _______________________________________________ Lsr mailing list -- [email protected] To unsubscribe send an email to [email protected]
