[j-nsp] Best practice for igp/bgp metrics
Saku Ytti
saku at ytti.fi
Thu Oct 26 19:44:42 EDT 2017
On 27 October 2017 at 02:05, Pavel Lunin <plunin at gmail.com> 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
More information about the juniper-nsp
mailing list