Hi Gen, This is applicable not only in access networks. But WRT access networks while the typical design may be rings and hub-n-spoke, even those networks have many parallel, redundant, links that are ideal candidates for power-sleep during periods of low utilization. In Metro networks and WAN networks, not only are there many parallel links but also the mesh designs lend themselves to additional power-sleep options.
The proposal does not impede an operator ’s “policy” decisions as it pertains to what get transitioned to power-sleep. If a platform’s capabilities cannot meet a given SLA, then the operator may choose (along with guidance from their vendor) not to put some component to power-sleep. And as Tony already stated, generous resource and redundancy margins can be leveraged. -- Colby From: Chengen(GenChen) <[email protected]> Date: Sunday, August 9, 2026 at 10:38 PM To: Tony Li <[email protected]> Cc: Bonica, Ron <[email protected]>; lsr <[email protected]> Subject: [Lsr] Re: IS-IS Support for PCPPS Hi Tony, Ron, Please see inline. Kind Regards Gen chen From: Tony Li <[email protected]> On Behalf Of Tony Li Sent: 2026年8月6日 0:11 To: Chengen(GenChen) <[email protected]> Cc: Bonica, Ron <[email protected]>; lsr <[email protected]> Subject: Re: [Lsr] IS-IS Support for PCPPS 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. [GC] Thanks for letting me know the focus is on the access portion. It seems that the typical design for access networks is dual‑homing or ring‑based — providing mostly two redundant paths between two points. This architecture is intentionally built for reliability and load sharing and with only two paths, powering down one removes all redundancy. Please correct me if I am wrong, PCPPS works without compromising reliability when there are at least three disjoint paths between two points(so that at least two paths remain after powering down the spare paths while still preserving protection). The question is in the claimed simulation results (e.g., xx% of the network can be put to sleep), for the two‑path portions, are they excluded from the power‑saving calculations, or is the simulation assuming they can be safely powered down despite losing redundancy? 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. [GC] It may depend on the type of the network and the requirements of the operators considering the wake-up latency. In some cases, it is mandatory. 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. [GC] Got it, yes it could be solved adding extended mechanisms. 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. [GC] To be short, increasing traffics in some paths may also need some limitations on the paths such as thresholds introduction to deal with unexpected situations where the overall energy savings can be negative. Regards, Tony
_______________________________________________ Lsr mailing list -- [email protected] To unsubscribe send an email to [email protected]
