> I've been thinking about other information that could be conveyed in
> communities. For instance, bandwidth, delay and packet loss.
And generate a route flap every time a link gets used more or less?
That would be suboptimal to say the least (the word `countereffective'
seems more applicable to me).
Using dynamic data for this is not going to work in BGP, so this would
have to be static information (hm, packet loss is not too static,
hopefully).
Static system-derived or configured information would already help a lot.
You can then easily select the route with the highest potential bandwidth
or the lowest speed-of-light delay, without the need to know a lot about
the internals of a transit network.
Introducing "metrics" like this like this is not contrary to BGP design
philosophy: the way in which an AS selects the best route is not defined
in the RFC and the length of the AS path is certainly not the best
possible criterion.
The processing along the way would be limited to a simple addition
(delay), compare/replace (bandwidth) or multiplication (packet loss)
without introducing anything SPF-like.
I guess using static information for BW could be useful however surely
in most peering situation only the "best" path is advertised and this
selection is based on normal prefix lenght/BGP attributes so for
1:1 peers you are relying on there IGP metrics for the best "internal"
path. So multi hop traffic engineering is not possible within others
AS's ?
I agree an automatic system (a bit like auto-tag in Cisco world) could
be very useful for example in a trival situation where you have two peers
to say AS701 and one is an OC12 and one is a DS3 and auto community on
just the bandwidth would be useful, especially if there was added logic
in the BGP decesion process. Of course for vendors who do not use the
logic it is invisible.
Regards,
Kevin