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
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
I think better implement it properly.