<cb> inline
Juniper Business Use Only From: Robert Raszuk <[email protected]> Date: Friday, May 22, 2026 at 8:03 AM To: Barth, Colby <[email protected]> Cc: Tony Li <[email protected]>; Carlos Pignataro <[email protected]>; Christian Hopps <[email protected]>; lsr <[email protected]>; [email protected] <[email protected]>; ops-ads <[email protected]>; [email protected] <[email protected]> Subject: [Green] Re: [Lsr] Next steps for draft-many-lsr-power-group-02 [External Email. Be cautious of content] Hi Colby, Ok so *all* headends need to be smart and apply rule of traffic aggregation (180 degrees to one of traditional uses of TE which is traffic spreading over available topology). <cb> An operator has the choice to deploy such a solution if power savings is important to them. So let's zoom on this for a second ... How would an operator enable this ? Clearly all headends in the network (at those which are used for SLA sensitive traffic) need to be upgraded and enabled. <cb> Correct. Ingress routers need to be capable of computing power aware paths. Further, all nodes in the network need to support and advertise power-groups. But how do you enable this ? <cb> Configuration. Are you saying that now traffic spread by TE across links is no longer important and power savings becomes prime citizen ? <cb> Have a look at https://datatracker.ietf.org/doc/draft-many-teas-power-steering/ Existing metrics are “honored". Or are you saying that this optimization would be enabled between 1:00 AM and 6:00 AM ? Well for Tier-1 or even some Tier-2 backbones there is never night everywhere. In fact there always daylight in some part of the world. So here we are now talking about properly designed networks with areas/levels corresponding to traffic patterns. <cb> Sure. It could be enabled only during certain periods of time on certain portions of a network. <cb> The draft defines a power-save capability for a link, section 7.3.4. Resilient topologies can be designed or calculated (periodically, on demand, …) such that resilience is not compromised. Links just need to be marked as not-available-for-power-sleep. The point I am highlighting is that FRR protection is fully distributed in the network and is beyond control of the headend. PLRs can not guess which links will be shut in the future unless you mark all as "not-available-for-power-sleep". To come back to Tony's example if North link is marked as "not-available-for-power-sleep" and we put to sleep Central and South some PLRs may no longer have a repair path available. Moreover that knowledge is not readily available on each headend as they can not predict the future how other headends will behavie in time T+N. <cb> FRR tunnels can be moved apriori or after-the-fact but either way, there would be a resilient topo available for FRR tunnel placement. Very topology dependent assumption and clearly and significantly reducing the space for savings. <cb> Sure, to maintain resilency it would reduce power savings. Whether that is significant or not is topology dependent. —Colby Thx, Robert
_______________________________________________ Lsr mailing list -- [email protected] To unsubscribe send an email to [email protected]
