On 27 October 2017 at 02:05, Pavel Lunin <[email protected]> wrote:
> Basically I agree with your concept, but it's worth to note that you assume > the current traffic as "given" and that links can't be saturated. This > assumption only holds when there is a great number of short-lived low > bandwidth sessions, like residential broadband subscribers traffic, and > enough bandwidth to accommodate all the traffic. In this case, a saturated > link and consequent drops is equivalent to "no service". However in some > environments (many enterprise networks, some DCs) hight traffic periods are > observed during backups/replications/etc. This normally implies relatively > low number of high bandwidth long-lasting TCP flows. Being forwarded through > a saturated link, TCP slows down and traffic "adapts" to network conditions. > Your backup will take 4 hours instead of 2. This is where real bandwidth > might be a meaningful metric. If I understand correctly, it was supposed to > work like this in the era when you always had more traffic than available > bandwidth. I can agree that if you can do unequal load balancing, there may be merit to BW based metric. However, obviously this is not how it works in SPF protocols like OSPF and ISIS. I think this particular scenario would fall in my previous statement about being unable to guarantee that SPT has sufficient capacity, I can fully appreciate that there are business cases where you cannot provision enough bandwidth to SPT, much less backup SPT. In this case you should deploy strategic-TE. -- ++ytti _______________________________________________ juniper-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/juniper-nsp
