Global BGP community values?

Tue Oct 5 12:49:41 UTC 1999

> 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