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