BGP load balancing techniques provide a good example of how protocol features
are currently being used to meet operational requirements through side-effects
rather than designed protocol behavior. There are at least two techniques
in widespread use today, and are likely more that I'm not aware of. They are:
1. AS path prepending: The practice of adding your own AS number
multiple times in a row to artificially increase the AS
path length of the route you pass on to your peers. Since
AS path length is the default metric for route selection in
BGP, increasing the path length decreases the preference
of your advertised route in all downstream routers.
2. Route de-aggregation: The practice of advertising multiple routes
for a single block of address space so that your advertised
route has a longer effective prefix length. Since the longest
prefix match is always chosen by the route selection
algorithm, this has the effect of increasing the preference
of your advertised route in all downstream routers.
Both of these techniques co-opt protocol features to obtain new transitive
attributes that affect route preference through side effects. It is quite
clear that both of them have significant disadvantages, since increased
path lengths increase convergence times due to the bouncing effect (re: Craig
Labovitz et. al., http://www.research.microsoft.com/~labovit/presentations/SIGCOMM00.ppt),
and advertising multiple routes that carry redundant information wastes
resources in core routers.
It seems like the addition of a single scalar transitive attribute that
indicates a relative preference level would meet the operational requirements
without the disadvantages of either of the `hack' methods. However, this feels
like too obvious a solution. Has this been discussed elsewhere and rejected
for a reason I have missed? Or are the problems presented by current load
balancing techniques considered too insignificant to merit a change to BGP?
-- Sean McCreary mccreary@colorado.edu
This archive was generated by hypermail 2b29 : Mon Aug 04 2003 - 04:10:03 EDT