...

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