Peter, “This algorithm mandates that the packet be forwarded according to the ECMP-aware SPF algorithm and instructs any router in the path to ignore any possible local policy overriding the SPF decision. … a packet received with a Strict-SPF SID may be rerouted through an FRR mechanism."
I think this[may] allows TTE to avoid loops. Thnx, —cb From: Peter Psenak <[email protected]> Date: Friday, July 17, 2026 at 12:46 PM To: Tony Li <[email protected]> Cc: Colby Barth <[email protected]>; lsr <[email protected]>; [email protected] <[email protected]> Subject: Re: [rtgwg] [Lsr] Comments on draft-psenak-lsr-igp-dcm-00 Hi Tony, please see inline (##PP2): On 17/07/2026 18:30, Tony Li wrote: Hi Peter, ##PP I see thinks differently, but let's not argue about that, does not lead us anywhere. In the spirit of intellectual integrity, you owe a reference, as does EBR. ##PP2 I have no problem with that. ##PP The problem described in that paper is a result of the entire traffic shifting between links A and B. That is not what DC does. DCM always keeps the traffic on the link A and moves part of it on B. It also monitors B's utilization and stops adding more before B becomes congested. DCM is also done for local links only, which is different to what is described in that paper, where all routers react. So we are far from conditions described in that paper. I disagree. You are shifting traffic away from a congested link. Even if it is not all traffic, it must be some significant chunk of traffic to have any effect. As soon as you do that, the link can (and should) transition back to uncongested state. You want to get things back to uncongested because you want the headroom for future (fractal) congestion events. ##PP2 There are some thresholds with hysteresis involved to avoid shifting traffic back and forth. ##PP We do not react to spikes. And we do incremental offload. All to avoid what you described. Then you are not solving the problem. ##PP2 we are, but maybe a different one that you intended to solve with TTE. DCM is not trying to solve the microburst problem. 2. TTE does not support multiple congested links in the network at the same time. Using multiple LFA/TI-LFA paths simultaneously on different nodes can easily lead to loops. One can avoid this via SSPF. ##PP if your protection is via local LFA, which does not use any extra labels, SSPF is not going to help you, because your backup traffic is using the native SID. SSPF will prevent possible looping. ##PP2 RCF 8402 allows SSPF SODs to be protected: "Note that Fast Reroute (FRR) [RFC5714<https://datatracker.ietf.org/doc/html/rfc5714>] mechanisms are still compliant with the Strict Shortest Path First algorithm. In other words, a packet received with a Strict-SPF SID may be rerouted through an FRR mechanism" In such case I'm not sure how does it solves the problem of backup paths being used in multiple places in the area. thanks, Peter Tony
_______________________________________________ Lsr mailing list -- [email protected] To unsubscribe send an email to [email protected]
