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

[Robert Raszuk <[e-mail]>]

Hi Tony,

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). Then again *all* headends need to be
super smart  to say Oh those 100 headends from opposite side is aggregating
traffic over North ... I will try to do the same. To me the
correlation between traffic removed from South and Central to take North
link from A to B is missing such that B to A knows that increase of
reservations on North actually were caused by traffic shift from
South/Central.

Yes this is mapping traffic to LSPs which to the best of my recollection we
do not flood.

Of course as we all agree that all works with 100% RSVP-TE forwarding in
the network.


But let's put that aside for a moment - I have a different question which
popped up yesterday.

All wise operators today build networks and use various FRR techniques to
minimize packet loss upon link or node failure. Waiting for any protocol
convergence IMHO is a thing of the past when it comes to connectivity
restoration time.

I am not seeing where in this entire story we are taking this aspect into
consideration. What if North/Central/South links are designed to protect
each other under a single failure scenario ? And while perhaps saving some
money by shutting Central and South, are we not making our SLAs thin when
it comes to potential failure of North when C/S are off and there is no
other protection path available (especially quite topology dependent in
MPLS-TE networks) ?

And while in theory headends do have all information to possibly make
what-if analysis for any network failure I strongly doubt that they will be
able to predict FRR options on possible potential shutdown of surrounding
links in the topology when making the traffic aggregation decisions.

Regards,
Robert



On Thu, May 21, 2026 at 12:06 PM Tony Li <[e-mail]> wrote:

>
> Hi Robert,
>
> > But I see no connection nor hint for also consolidating traffic from B
> to A to the North path. Traffic B to A may have completely different
> characteristics then traffic from A to B. And unless we are talking UDLR
> freeing links must be done bidirectionally - wouldn't you agree ?
>
>
> RFC 5305 tells us the unreserved bandwidth on the link.  If you look at
> both ends of the link, you get both directions. That’s the hint.
>
> Tony
>
>