Hi Colby, The former is a local event and link/node failures are an isolated events. >
> <cb> Can you point us to the source of this assumption? > You mean the above ? Does it require a source of this "assumption" ? To me this is a basic fact. > That is actually one question I forgot to ask .. when or based on what > network event do you "deactivate" TTE ? > > > > <cb> It’s described in the draft (or should be). In summary, when the > cumulative byte rate across the newly formed ECMP falls below the low > threshold for some consecutive number of traffic samples TTE activated > prefixes are deactivated according to the prefix selection technique. > Wait ? What newly formed ECMP ??? So the FRR is not a unicast bypass ? Also let's consider that FRR techniques used in networks do not rightfully allow for nested protection. So by using them to avoid congestion one could argue that you are actually making network weaker as bypasses will be subject to drops when link or node fails on the paths. Also not sure what you call "cumulative rates". Congestion can very well as Jim said be caused by short lived traffic bursts. Hi Tony, Really. If your network is capacity challenged, then this feature will not > fix your network. > The worry is not to make it worse. > We’re not suggesting that a network need to handle multiple simultaneous > correlated failures. > Congestion if long lived by its nature is a corelleted event across N nodes. If congestion is network wide, then yes, TTE will not help. Again, capacity > is a zero-sum game. We can only shed load and we need capacity to redirect > it to. > How can congestion not be a network wide (from ingress to egress) event ? I am assuming we are talking about unicast. > If there are many links along a path that are congested, then TTE may > help. It can activate prefixes on each of the congested links, thereby > alleviating congestion along the path. > By shifting the traffic to other possibly also congested links ? FRR like various LFA algorithms do not consider congestion when computing backup bypass paths. Both link failure and TTE activation are going to shift traffic onto the > bypass path. If your network can’t support that, then the use of bypass > paths is not recommended. > Since congestion is an unexpected network event how can you (or anyone know) if a given network is ready for it ? That is actually one question I forgot to ask .. when or based on what > network event do you "deactivate" TTE ? > > When the utilization on the protected link falls below the low threshold, > then TTE will redirect traffic to the protected link. > Well the moment you apply a bypass to a subset of traffic the utilization of such a link will immediately fall below the threshold. So if you remove TTE you will get congestion again. Some people choose to act prior to queue build up. As you know, traffic is > bursty. Queues can wax and wane very rapidly. Responding to just queue > depth would result in a very high frequency oscillation which would be an > inappropriate time frame for traffic redirection. > This is not what I meant. In all cases the trigger to start bypass should consider crossing the threshold of X for time T. This should be done in the same way when looking at the interface or queue. > Further, we want to be able to address congestion before there is > significant queue occupancy. Using TTE, an operator could, for example, > start to redirect traffic when a link exceeds an unusual traffic level but > well before there was significant queuing. > If so this is not a "congestion", but increased load of a link. Those two are completely different things. REF: https://en.wikipedia.org/wiki/Network_congestion If you have massive congestion and QoS, then you could have TTE redirect > your BE flows, keeping your priority flows on the primary link. > Maybe ... I would just allow for BE applications to slow down. > Now I am sure creative folks will go step further and ask to "protect" in > such a way based on increased delay or loss on link (with additional > measurements). And honestly such new triggers would be safer than > congestion trigger as those again are localized and are not chained by > their nature across many nodes. > > Again, those measures are likely to result in high-frequency oscillation, > which we very much want to avoid. > Only if you would take a redirect action without consideration of its duration T. Thx, Robert
_______________________________________________ rtgwg mailing list [email protected] https://www.ietf.org/mailman/listinfo/rtgwg
