On Sat, 23 Sep 2000 mccreary@colorado.edu wrote:
> 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.
>
<snip>
> 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
What comes to mind for me is the discussion that happened either
on Nanog or the IDR list (w/in the last year, but I can't say when).
The proposal was to introduce two or so new "well known" community
values called something like "always prefer" and "never prefer".
There was quite a bit of discussion but no consensus that I can recall.
Issues that came to mind (and were likely discussed):
-Practice of observing and preserving communities across intervening
routing domains is uneven.
-Policy for a routing domain is typically expressed w/r/t neighboring
domains (eg. who's a customer and who's not, which types of connections
might be preferred, general traffic engineering, etc.)
Permitting the originator of an advertisement to affect and override
this kind of policy may often be undesirable and increase complexity
and risk in ways that aren't agreeable.
Sorry I can't provide a pointer to the relevant archive, but perhaps
someone else here has it more in the front of their mind.
As for the merit of your generic suggestion, nothing comes to mind
to give me an opinion other than "maybe".
Tony
This archive was generated by hypermail 2b29 : Mon Aug 04 2003 - 04:10:03 EDT