Hi Vishu, > The expectation is that the intelligence that determines whether a TE link needs to be put to sleep is aware of any backup paths (in-use or not)
I do not doubt that even for a second. But my point was quite different - apologies for perhaps not describing it correctly. When 1000 headends start their work to consolidate traffic CSPF is running independently on all of them. And each TE path consists of lots of links. It is unrealistic to compute consolidation including in CSPF of each node a map of FRR protection paths bidirectionally when trying to optimize the flows. Moreover it is even harder to get synchronous results of such computations across 100s (if not 1000s) of nodes. So far we have been discussing traffic consolidation from the perspective of the link. But IMO it is quite impossible to get distributed consolidation in place for more then few core links ... think of it like for a 100 TE paths from headend A to B meeting following: * The resulting consolidated paths have to be similar across many headend nodes * The headend nodes LSPs may be going to various tail nodes * The SLA guarantees should be met irrespective of which link is being shut down across all TE LSPs * The entire story must result in similar actions in both directions. If you tell me all that is missing today to accomplish the above (considering RSVP-TE networks) by supporting extensions in draft-many-lsr-power-group + already defined extensions that would be nice to know. Cheers, Robert On Fri, May 22, 2026 at 2:06 PM Vishnu Pavan Beeram < [email protected]> wrote: > > *>>> 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) ? * > > Sufficient guardrails are in place to ensure no compromise in resiliency. > The expectation is that the intelligence that determines whether a TE link > needs to be put to sleep is aware of any backup paths (in-use or not) that > traverse this link and makes an informed decision based on that. If RSVP-TE > is in use, there is sufficient state on the node itself to make an informed > decision. > > Regards, > -Pavan > > On Fri, May 22, 2026 at 2:42 AM Robert Raszuk <[email protected]> wrote: > >> 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] >> >
_______________________________________________ Lsr mailing list -- [email protected] To unsubscribe send an email to [email protected]
