Just a thought, if the lowest link on the route to a destination has 1 single link at 10kbps this will also be the maximum speed you can achieve over that path towards this specifc destinatio , so there is no need to multiply the different communities.

Ok... In that case a (small) number of communities could be used and a filter list to match them from slow to fast and assign some preference value. However, this will not be enough to make a consistent and optimal set of routes I'm afraid. We'll see how it works out once we encounter this situation in practice and can check if it leads to unwanted routes and this change would improve it.

BTW we use eBGP between sites but we combine this with BGP confederation. This brings the benefit of eBGP (only BGP sessions with link peers) and keeps AS PATHs short towards our external peers.

I still have to find the limits of the AS PATH length (hard or practical). Looking this up after a mention in a direct mail I found that there apparently is or was an implementation limit in Cisco routers at a path length of 256 that destabilized the internet 7 years ago. We are not anywhere near such lengths. However, I am aware that longer path lengths probably mean more data traffic between peers and maybe a little more memory and CPU use, so it could be worthwile to keep these down a bit.

We also opted for a single routing protocol versus OSPF within the internal network with iBGP overlay and eBGP on the edge.

Ok, that is what I am doing for now as well, it has to be kept a bit simple not only for me but also for other people who like to install a node and configure it themselves.

Rob