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]
