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 <[email protected]> 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 > >
_______________________________________________ Lsr mailing list -- [email protected] To unsubscribe send an email to [email protected]
