Gengchen,
Inline........
Ron
________________________________
From: Chengen(GenChen) <[email protected]>
Sent: Wednesday, August 5, 2026 3:13 AM
To: Bonica, Ron <[email protected]>; Zafar Ali (zali) <[email protected]>; lsr
<[email protected]>
Subject: RE: [Lsr] Re: IS-IS Support for PCPPS
Hi Ron, Zafar, all,
Following the discussion, I'd like to raise three points that I believe are
critical.
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?
<rb> Our empirical study with real Tier 1 operators leads us to the opposite
conclusion. Each of these networks had enough capacity to compensate for a
failure during peak hours. They also experienced significant differences in
offered load between peak and non-peak hours. Therefore, they had much more
than enough capacity to compensate for a failure during non-peak hours. By
powering-down this excess capacity, they could save energy while maintaining a
sufficiently redundant topology.
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.
<rb> This is an operational consideration, beyond the scope of the LSR draft.
The operator can configure many parameters associated with wake up behavior.
If, after appropriate configuration, the network element still cannot wake up
quickly enough, its power-save-capable attribute can be set to FALSE. So, that
network element will never go to sleep
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?
<rb> This is also an operational consideration, beyond the scope of the LSR
document. One solution is to wake the network element up periodically to check
its health. But this is not done in LSR.
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.
<rb> Much of the hardware that we have observed displays a non-linear
relationship between throughput and power consumption. For example, a network
element might consume 80% of nominal power when passing no traffic and 100% of
nominal power when saturated.
<b> If an operator has hardware that displays a linear relationship, they might
not want to configure that network element to be power-save-capable.
Thanks,
Gen Chen
From: Bonica, Ron <[email protected]>
Sent: 2026年7月22日 16:08
To: Zafar Ali (zali) <[email protected]>; lsr <[email protected]>
Subject: [Lsr] Re: IS-IS Support for PCPPS
Inline....
________________________________
From: Zafar Ali (zali) <[email protected]<mailto:[email protected]>>
Sent: Tuesday, July 21, 2026 11:38 PM
To: Bonica, Ron <[email protected]<mailto:[email protected]>>; lsr
<[email protected]<mailto:[email protected]>>
Cc: Zafar Ali (zali) <[email protected]<mailto:[email protected]>>
Subject: Re: IS-IS Support for PCPPS
Hi Ron
What I highlighted is: how come someone who claims to have implemented this did
not realize that the sleeping power is non-zero?
[RB] Is this a technical question or an ad hominem attack?
[RB] Recall that in many hardware architectures, sleeping power is zero.
If I draw a dotted line, how does one ensure that the power-saving estimate for
a given “power group” is accurate?
[RB] Generally, hardware vendors publish this information.
The questions Robert asked are valid and related.
[RB] And answered in draft-many-teas-power-steering.
What is the right data model? We need to ask the Green WG.
[RB] The value of a data model is its descriptive efficiency. In this case, if
a data model can describe any hardware architecture that you need to describe,
it is good enough.
[RB] Can you describe a hardware architecture that the data model cannot? If
not, there is no valid criticism.
Also, operators perform many capacity planning exercises to design the network.
The operators need to consider what the implications are for shutting a “power
group”
What considerations must be in place before shutting down the "power groups"?
Is this a good idea, or will it create more pain for network operations?
[RB] In Section 3.3.4 of the draft, you will notice a power-sleep-capable bit.
This bit is set only of the operator configures the interface to be
power-sleep-capable.
[RB] There are many reasons why an operator may determine that an interface is
or is not power-save-capable. This is beyond the scope of this document.
Thanks
Regards … Zafar
From: Bonica, Ron <[email protected]<mailto:[email protected]>>
Date: Monday, July 20, 2026 at 3:55 AM
To: lsr <[email protected]<mailto:[email protected]>>; Zafar Ali (zali)
<[email protected]<mailto:[email protected]>>
Subject: IS-IS Support for PCPPS
Zafar,
If I understood your comment during the IETF 126 session correctly, you said
that the Power Group model may not support some existing hardware
architectures. Can you describe such an architecture?
Ron
_______________________________________________
Lsr mailing list -- [email protected]
To unsubscribe send an email to [email protected]
