Hi Colby,
please see inline (##PP)::
On 17/07/2026 15:09, Colby Barth wrote:
Hi Peter,
Yes, I carefully read your draft and understand its purported
benefits. I think, more importantly, all three drafts attempt to
tackle the same problem space, i.e. how to respond to local
congestion, and unfortunately none of the proposals are perfect.
WRT DCM:
*
If you're creating a congestion free topology, why not just always
use the congestion free topology?
##PP
because we do not shift the entire traffic out of congested link, only
part of it, sufficient to eliminate the congestion on the primary path.
*
A colleague reminded me of
https://www.cs.princeton.edu/~jrex/teaching/spring2005/reading/khanna89.pdf
It
would seem to me that you risk recreating the oscillation problems
described there.
##PP
there are mechanisms described in the DCM draft that are used to avoid
the oscillation, and if that is not sufficient, to mitigate it.
*
What happens if/when an endpoint in the OFA topology becomes
unreachable due to multiple simultaneous congestion events? I
presume packets get dropped?
##PP
if the endpoint reachability in OFA is lost due to network congestion,
that indicates that you have no available bandwidth to offload the
traffic from your congested primary path. Not much we can do in case
when there is no bandwidth available in the network.
*
Terminating offloading for topological events associated with the
OFA path to an endpoint, on any reasonably size network, would
suggest this has very limited applicability.
##PP
not really, the offloading will re-start on a new OFA path.
*
*
For SRv6 networks, a packet arriving at an endpoint with 2 SRv6
headers would be quite problematic for many forwarding engines
##PP
for that case, you can use the uA SID from the parent of the endpoint as
described in section 8.
*
As far as your criticisms of TTE go:
*
1st, I’d argue that none of the proposals really address strategic
resource management in an SR network. Said another way, all the
proposals need the congestion to be abated via some means. i.e.
global optimization, human intervention, magic controllers, etc.
o
In that regard, all three proposals are incomplete from an
over resource management perspective
##PP
they may not be perfect, but if it addresses reasonable amount of use
cases, it's worth the usage. That's the feedback we got from the providers.
o
*
Wrt #2, loops are easily preventable in SR networks through the
use of SSFP SIDs when a flow is forwarded along the TI-LFA path.
Maybe I should update the TTE draft so this is specifically
addressed and not left to the reader to infer.
##PP
TI-LFA was designed to provide protection in case of a single failure
(link, node, SRLG). TI-LFA paths used simultaneously at different places
in the network are not loop free. SSPF-SIDs are not solving that problem
- traffic diverted to it's backup path on node-1 may be diverted back to
node-1 based on the node-2 's backup path.
*
o
TTE does support multiple congestion events, however, the same
flow will not be “TTE’d” more than once. The flow selection
techniques described in the TTE draft easily facilitate this
##PP
I tend to disagree with the above, using the reasoning from the previous
point.
o
*
For all practical purposes, introducing 1 or more additional
flex-algo’s results in non-trivial scaling considerations on any
reasonably sized network.
##PP
We have not get that feedback from any of the providers we discussed DCM
with.
*
o
Further, if flex-algo is already in use, do you also need per
flex-algo OFA topologies so as to maintain the optimization
objective for the flex-algo topology you’re off-loading from?
##PP
depends, you can share the same OFA for multiple FAs, or you can have
unique OFA for each of them.
It is not always required to offload the traffic for all algos - e.g.
offloading the best effort traffic only may be sufficient in many cases.
o
o
In contrast, TTE will work with flex-algo to maintain the
optimization objective along the backup path.
##PP
same can be done with DCM.
thanks,
Peter
o
Cheers,
—Colby
*From: *Peter Psenak <[email protected]>
*Date: *Friday, July 17, 2026 at 3:14 AM
*To: *Colby Barth <[email protected]>; lsr <[email protected]>;
[email protected] <[email protected]>
*Subject: *Re: [Lsr] Comments on draft-psenak-lsr-igp-dcm-00
Colby,
if you read the DCM draft carefully, you will find out that what you
put below is maybe funny, but not more than that.
Here are the significant differences between the two:
1. TTE is based on a backup paths, DCM calculates its own offload paths
2. LFA/TI-LFA does not take congestion into account, DCM offload path
is calculated to be congestion free
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.
3. TTE is proposed to be used for a short duration of the time and
then the TE is expected to recompute. DCM is meant to be used for long
time and does not need any TE action.
4. As a result of (3), DCM offload path is fully protected by
LFA/TI-LFA, TTE paths are note protected.
Contrary, the other draft that I pointed out in the RTGWG list, is way
more closer to the DCM.
regards,
Peter
On 16/07/2026 19:42, Colby Barth wrote:
All,
I would like to point authors of draft-psenak-lsr-igp-dcm-00to an
existing draft:
https://datatracker.ietf.org/doc/draft-li-rtgwg-tte/02/There is a
significant overlap between the two drafts, which makes me think
that either: a) the authors of the draft-psenak-lsr-igp-dcm-00were
aware of the original TTE work, but decided to publish their own
draft anyway.
If that was the case, they should have at minimum referenced the
TTE draft and described the differences between the two, including
the motivations behind these differences. or b) the authors of the
draft-psenak-lsr-igp-dcm-00were not aware of the original TTE
work, in which case I would advise them to read the TTE draft
before they take any further action with their draft. Thanks,
—Colby
_______________________________________________ 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]
