Robert, As both Tony and I mentioned, the goal is to consolidate traffic. This implies the new path is different than the current path. Care can be taken to ensure this change is done in a MBB fashion. This is well known functionality, widely deployed. While not particularly relevant to this discussion, updating an LSP ‘in-place’ is a functionality also widely deployed. See https://datatracker.ietf.org/doc/draft-alibee-teas-rsvp-inplace-lsp-bw-update/ for a nice discussion on the topic.
Yes, these extensions are aimed to be used for TE and ensuring the BW demand is met a key attribute to determining what components can be transitioned to a power-sleep state. Yes, we can add some operational considerations, but I think that they will mostly amount to “use common sense” so the resiliency of the network isn’t compromised. Sure, routing systems will continue to evolve in many ways. Thnx, --Colby From: Robert Raszuk <[email protected]> Date: Sunday, August 3, 2025 at 10:33 AM To: Colby Barth <[email protected]> Cc: Tony Li <[email protected]>, Acee Lindem <[email protected]>, [email protected] <[email protected]>, LUIS MIGUEL CONTRERAS MURILLO <[email protected]>, Raul Arco (Nokia) <[email protected]>, Ron Bonica <[email protected]>, lsr <[email protected]> Subject: Re: [Lsr] Re: New Version Notification for draft-many-lsr-power-group-00.txt Hi Colby, “Ok.. Note I would not do it that way, but I see what you mean. Changing paths of an RSVP-TE given LSP is really not a make-before-break operation. At least last time I checked into this space. “ <cb> More often than not LSP path change is make-before-break. And especially in this scenario, care can be taken to ensure MBB. Yes if you signal new path and make it setup before the old path times out - sure. Or are you saying some implementations can send for a given LSP RSVP-Path messages over more then single path ? I have not see that. More over new LSP is setup and policy switchover happens to put all traffic which was traversing old LSP onto a new LSP. In any case you would end up in some situations with two LSPs having identical paths. Not sure what is the benefit of it. > Consider a TE policy that aims to satisfy a BW demand(s) where the best path > is the fewest number of > pwr-grps and the pwr-grp power value is a representation of power efficiency > for the group. Well BW demands really work well when you have 100% of TE in the network and all traffic can be accounted for. - - - In any case by putting to sleep some network elements, yes you are saving some power, but you are at the same time making the network more fragile to handle various failures. I presume your operational consideration section will discuss the consequences like triggering recomputation of all TI-LFA or MLA on each power optimization in the network. I view this power saving effort comparable to parallel moving pathways .. * Your suggestion is to shut one pathway when there is no enough people which would occupy all pathways * The alternative which is seen and deployed in practice is to slow down any pathway to 5-10% of the power until someone walks into it - then it auto-resumes at full speed. Needless to say I am in favor of building more intelligent forwarding engines which could reduce their power consumption when load is reduced. Regards, R.
_______________________________________________ Lsr mailing list -- [email protected] To unsubscribe send an email to [email protected]
