Colby,
On 17/07/2026 21:48, Colby Barth wrote:
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.
it may.
The problem is that if the link 1 is congested and you use TTE for it,
which crosses link2, and links 2 is congested, you may use TTE for link
2 which sends the traffic via link 1.
It may not be the same traffic, so no loops, but you did not solve the
congestion problem. This is because the backup path computation does not
take congestion into consideration.
thanks,
Peter
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]
