"Olivier Bonaventure" writes:
can define its own semantic. Second, since the community attribute is transitive, you might receive routes from any peer containing such community values and apply an invalid filter to those routes. This leakage of community values is not uncommon in practice based on our analysis of the BGP routing tables (see http://alpha.infonet.fundp.ac.be/anabgp and http://www.infonet.fundp.ac.be/doc/tr/Infonet-TR-2002-02.html )
This seems to be just as easily cured by setting an internal community on routes from peers, and not specifying "additive" (in ciscospeak): route-map peer-in set community xxx:yyy
Using such community values for traffic engineering purposes could quickly become a headache unless every one filters the community values that it annouces to peers, but few operators have implemented such filtering.
I don't know about others, but at the couple of ISPs I have worked at it was standard procedure to set a non-additive community on incoming prefixes from peers -- if this is done consistently, there will be no problem with bogus matches from the peer, even if the community space you and your peer use overlaps. Further, if you are actually making decisions based on an internal community scheme when you send routes to your peers, those routes already go through an outbound route-map at the border -- so I don't see a whole lot of overhead in adding a "set community" to some null value when you send the prefixes out. Perhaps this situation is better served with a BCP rather than adding additional features to BGP itself? Cheers. -travis