Hi Tony, News to me that you want PCPPS metric to *MODIFY* currently used metric. But this is good news :)
But you did not comment on the question how PCPPS would relate to RFC7810 constraints if at all. In respect to power groups you said: *Power groups allow vendors and operators to advertise the power consumption of NPUs and other silicon components and the relationships between those components so that external devices can make good decisions about path computation.* Excellent I fully get the desire to shut NPU not just bunch of lasers. But now you are really asking for ingress nodes to understand that per node groupings in their path calculations. And here I must say that I share the concern of others that selecting the same set of power groups (not only interfaces) by independent ingress nodes may be a matter of luck then heuristics. And needless to say that needs to be done bidirectionally which by itself argues against the nature of power groups. Why ? NPUs serving east ingress nodes (east-headends) may be part of completely disjoined power groups from NPUs serving traffic coming from west ingress nodes (west-headends). With staying on a per link granularity the likehood of success (moving LSPs to other paths) IMO is much bigger then if adding to the mix the concept of power groups (which again brings the question of how CSPF actually is supposed to use them). Kind regards, Robert On Thu, Sep 24, 2026 at 6:50 PM Tony Li <[email protected]> wrote: > > Hi Robert, > > > *Comment 1: * > > > More precisely, we have proposed a metric modifcation in PCPPS. > > What I am quite unclear from both drafts is the relation of the PCPPS > metric to normal TE metric, link attributes or bunch of other > constrains used today for TE purposes ? For example those defined in > RFC7810 ? > > > > In modern TE, an operator can choose to use a number of different > metrics. You can use the IGP metric, the TE metric, and others (e.g., RFCs > 7810 and 9843). In addition, an operator could, in principle, be using > different metrics for different LSPs. For example, latency sensitive > traffic might require a delay metric, while bulk data should only use the > IGP metric. > > Rather than redefine all of those metrics, we are proposing that power > information can be used as a metric modifier. Potential power savings > becomes an addition to the metric, thereby biasing traffic away from > components that could be put into power-save. In our implementation, the > operator is allowed to control the relationship between the power and the > metric, so that the they can express the importance of power savings to > them. For example, power savings for delay-sensitive traffic may not be > important, but very important for bulk traffic. This also makes the > potential power-savings comparable to the basis for whatever metric the > operator chooses. > > > Are you saying all of those do not matter any more and first link > pruning should be done based on PCPPS metric $$$ saving is more important ? > > > > Exactly the opposite. Current metrics are important and we are proposing > a mechanism whereby the operator can tell us how important power savings is > to them. > > > Or should CSPF run normally and only when there are multiple paths meeting > application constrains prune those with higher PCPPS metric ? > > > > Pruning is not necessary. If power savings is sufficiently important, > then PCPPS will bias traffic away from power-save-capable links. > > > *Comment 2: * > > Now after thinking more about this while it looks cool on paper I am not > sure if we should expose concept of Power Groups. What's wrong with staying > on a per link granularity ? > > > > In a modern router, the primary power savings comes from the potential > power savings of the silicon, not the interfaces. > > Interface optics today is typically around 10W. Yes, somewhat higher for > LR, lower for multimode or SR. > > Silicon power consumption is typically much higher than that, from 100W to > over 1000W. > > If you only turn off interfaces, you’d be missing 90% of your potential > savings. > > > It may add lot's of confusion among implementations for unclear benefit. > > > > I think that the benefits are quite clear. > > > Internally within the box sure one could still support such grouping > directly or indirectly in a form of interface templates. > > > > If you only expose per-interface power consumption, then you cannot > understand the relationship between interfaces that use the same NPU. This > would lead to lost opportunities, such as pushing all traffic on a router > through a single NPU, allowing you to power-save the other NPUs. > > Power groups allow vendors and operators to advertise the power > consumption of NPUs and other silicon components and the relationships > between those components so that external devices can make good decisions > about path computation. > > > *Comment 3: * > > Did anyone analyze the impact of this to the transmission layer ? When > light goes down on the laser the circuit alarm is raised. If we start doing > random shuts of interfaces the poor transmissions guys will go crazy in > their NOCs. And last time I checked the API there is email and phone. > > And if they start ignoring those alarms they may miss some important ones > .. for example ATC fiber cuts. > > > > This is an excellent point. Yes, there is work to be done in the > management plane to indicate when interfaces are going into power-sleep to > prevent false positive interface alarms. > > Cheers, > Tony > > >
_______________________________________________ Lsr mailing list -- [email protected] To unsubscribe send an email to [email protected]
