Yes, i agree (actually, the BGP with metrics per that document is compatible with currently deployed BGP) - but isn't it better to provide a real fix and get rid of several kludges at once?
You sure you agree? Hank's suggestion requires no change to the BGP protocol in that use of communities which aren't known are ignored (i.e. won't break old speakers). But making speakers act on it requires changes to the implementation. In practice however, the fact inter-AS peerings do not normally have send-community enabled means that the information will often be dropped across the net without widescale changes. Your suggestion also requires no change to the BGP protocol in that use of optional transitive attributes which aren't known just results in them being ignored, so won't break old speakers. But making speakers act on it requires changes to the implementation. In practice however, the fact that non-fixed speakers may well drop the attribute means the information is likely to be dropped without widescale deployment of new code. Also, your scheme has another advantage over Hank's: The code changes to make Hank's scheme work are probably larger in various router vendor's code. Take Cisco: route-map handling of communities is really dumb. Let's say Hank's pref-prefix is (say) 1234:xxxx (where xxxx is the preference). You cannot easilly filter out 1234:anything and *just* drop that community from a string, and substitute in your own pref, nor do arithmetic operations (like add 5 to the pref). You can't even delete individual communities. I think better implement it properly. -- Alex Bligh GX Networks (formerly Xara Networks)