Hi Gen, Please see inline.
> 1. Where is the actual deployment case? > PCPPS assumes networks have "excess capacity" that can be powered down. But > in real carrier networks, that excess is usually design redundancy for > failures. Can the authors point to a specific production network topology > where shutting down redundant paths still satisfies the operator's redundancy > policy? > We have three Tier 1 SP’s all interested in this technology. All are real carrier networks that you’ve heard of and regularly attend IETF. The access portion of those networks show a very strong diurnal usage cycle. In the most extreme example, 85% of the network is idle. Simulations show that our approach can put 70% of the network to sleep. We have presented the motivational parts of this several times before, especially during the formation of the GREEN working group. You’re welcome to review those presentations. > 2. Wake-up latency and dead while asleep consideration > > A Power Group can represent an interface, a line card, etc., wake-up latency > varies from milliseconds to minutes. If PCPPS puts a line-card-level group to > sleep and later needs it for fast recovery, the minutes level wake-up may > break the service lossless requirement. > We intentionally do this with generous margins precisely so that we do not need to power things up for fast recovery. > More critically, how does the network know the sleeping component is still > healthy? When PCPPS later tries to wake it up for recovery, what if it > discovers the link is dead, does the current design have any mechanism to > verify the health of sleeping Power Groups without fully waking them? > Failures are a fact of life. Backhoes can strike regardless of whether the equipment is asleep. If links or components don’t come back up, then we try waking other components. If this is a very serious concern, an implementation could periodically wake things. At this point, this seems unnecessary. > 3. Static power values vs. vendor-specific wake-up thresholds > > The draft recommends static power values to avoid LSDB churn. But real > hardware power consumption is load-dependent, and different vendors may have > implemented power saving with step functions, not linear curves. A device may > consume X watts at 20% load, but when load exceeds 40%, the internal > controller wakes up a second component, and power jumps to X+Y W instantly. > That threshold is vendor-proprietary and not advertised. > > Now consider PCPPS, let’s say it moves traffic from path B to path A based on > static values (A = 100W, B = 100W), letting B sleep (save 100W). The > increased load on A crosses the 40% threshold — A wakes up extra components > and jumps to 300W. Net result: path B saves 100W, path A spends +200W — > negative energy savings. > Were those extra components advertised? PCPPS does consider that. If A advertises a potential power savings of 100W, but it’s actually 200W, that seems like a very large misconfiguration/software error. Regards, Tony
_______________________________________________ Lsr mailing list -- [email protected] To unsubscribe send an email to [email protected]
