Robert, Ack. We should update that statement.
Thanks, -- Colby From: Robert Raszuk <[email protected]> Date: Thursday, August 20, 2026 at 4:48 PM To: Barth, Colby <[email protected]> Cc: Les Ginsberg (ginsberg) <[email protected]>; Christian Hopps <[email protected]>; [email protected] <[email protected]>; [email protected] <[email protected]>; [email protected] <[email protected]>; [email protected] <[email protected]> Subject: Re: [Lsr] Re: WG adoption call for draft-many-lsr-power-group-03 (Ends 2026-08-30) Hi Colby, Specific to "But the current definition addresses the needs of only one type of traffic”. I fail to see why any application (SR policy, Flex-algo, LFA, RSVP (p2p and p2mp), detour or facility bypass tunnels, MPTE, …) can’t use the power-group as currently defined in their respective optimizations. There are many TE oriented attributes that have been defined similarly. e.g. SRLGs. Can you elaborate a bit more as to what specifically you’re looking for here? Well currently text in the draft says this: The Sleeping bandwidth field carries the sleeping bandwidth on a link, forwarding adjacency [RFC4206], or bundled link. For a link or forwarding adjacency, sleeping bandwidth is defined as the maximum bandwidth [RFC5305] minus the bandwidth currently allocated to RSVP- TE label switched paths that was transitioned to power-sleep. So at least definition of sleeping bandwidth seems quite limited to single TE technology. Cheers, R.
_______________________________________________ Lsr mailing list -- [email protected] To unsubscribe send an email to [email protected]
