BGP4 COMMUNITY attribute

> > >the attribute is defined as transitive (i.e., once associated

> > > >with a route it *stays* associated with the route). however, in
> > >
> > > Unless an intermediate provider deliberately changes the value, as
> > > opposed to appending to it.
> >
> >these values aren't an end-to-end thing .. it's simply a
> >way for providers to more easily facilitate routing policies.
> >your comment implies somebody being a bad guy...
> Actually, I hadn't necessarily meant to imply "being a bad guy".
> The comment was meant to show that the "intermediate" ISP has this
> kind of control over the attribute. In any case, if the decision
> about whether or not to pass on an attribute (or to modify it) was
> part of the intermediate ISP's policy, whether or not he/she is a
> bad guy would depend on varying points of view.

to date communities haven't been an end-to-end thing. they
have mostly had significance only to adjacent ASs. i do know
of a small number of exceptions where a subscriber sets the
communities, they're carried through a mid-level provider to
a top-level provider, at which point the top-leve. provider
reacts in some way (e.g., setting local-pref to a certain

to me the practical bottom line seems to be that communities
are being used to ease the configuration work to achieve
certain routing policies, and since an AS has complete
autonomy over its routing policies, that AS should have the
freedom to keep, add to, or stomp on communities that it
hears from others. it's possible that in the future we
might have an end-to-end application of communities, but i
don't know of one yet, so i'm loathe to mandate anything
about how far communities are carried and how much they're
kept intact