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.
what he said but there is an underlying problem. i have a business relationship with my direct neighbors under which we can negotiate traffic patterns. i do not have a business relationship with a 'distant' network. hence i am rather reluctant to allow them to influence my policies when those decisions my be costing me money, or my customers performance, or ... randy