[Lsr] Re: [Green] Next steps for draft-many-lsr-power-group-02

[Robert Raszuk <[e-mail]>]

Hi Tony,

> Let’s not repeat the debate of centralized vs. distributed yet again,
please.  It only generates heat and no light.

:)

It was not my intention to start such a debate again. And personally I hate
any centralized solutions for IP networks.

But it seems clear that those who subscribe to full TE in their network are
not that big enemies of controllers too.

Having a fully distributed solution is always cool, but as we discussed
offline I do have lots of hesitation that specific links or line cards
could be drained *bidirectionally* in a distributed CSPF computation
fashion. Clearly you have spent loads of time more than me making sure it
does work so I am not questioning that. Just expressing my hesitation.

But my overall comment was not aimed there .. It was attempting to hint
that perhaps there are other alternatives to full mesh RSVP-TE to
accomplish traffic shifts such that nodes could start powering off single
lasers or NPUs.

And that real question I am asking is if we should have separate draft and
separate extensions or could that be part of the same architecture
to accommodate different alternatives of load draining from the links .

Kind regards,
Robert


On Thu, May 21, 2026 at 1:41 AM Tony Li <[e-mail]> wrote:

>
> Hi Robert,
>
> > > as the traffic demand matrix is not a constant from one day to the
> next.
> >
> > Hmmm that is a pretty bold statement and intuitively hard to argue with.
>
>
> Well, Carlos did ask that we be rigorous.  It’s quite clear that the
> traffic demand is not 100% identical from day to day. The question then is
> does it change enough to matter
>
> If one wants to be rigorous, one needs to ensure that the traffic matrix
> between the power save case and the non-power save case is within a delta
> so small that it doesn’t affect LSP placement. [Fond memories of
> delta-epsilon proofs come to mind.]
>
>
> > However maybe you and some of the folks on the list recall Cariden and
> their tool to build traffic demands in days, weeks and months of the number
> of tier 1 ISPs. Well the outcome of that was contrary and they found the
> traffic demand patterns to actually be pretty consistent in a given time
> deltas.
> >
> > That in turn allowed them to achieve traffic engineering of the
> relatively large global backbones by only adjusting the link metrics and
> the proven claim was that it was as good (say - 10%) as compared to the
> outcome of RSVP-TE.
>
>
> I am not arguing that such a delta does not exist.  Certainly it does,
> however if one wants to make a true apples-to-apples comparison, the delta
> must be shown to be small enough to not affect the result.
>
>
> > I am mentioning it here as a potential alternative view on how to shift
> traffic between selected paths without the need to run full RSVP-TE in the
> network. Obviously this would rather fall into a controller driven bucket
> of solutions.
>
>
> Let’s not repeat the debate of centralized vs. distributed yet again,
> please.  It only generates heat and no light.
>
> Cheers,
> Tony
>
>
>