Regarding global BGP community values

While it's clear that a considerable amount of disagreement exists regarding
transitive communities dynamically doing things, it's extremely simple for
providers to just not pay attention to them.

Which is desirable. Customers who want them to work will buy from
providers who can make them work. There will still be customers who
don't need them for those providers who don't want to pay attention
to such communities. The rest shall be history.

Another potential application for global transitive communities,
which is likely even more debatable than path selection issues,
is using them in conjunction with MEDs and "more specifics" of
provider aggregates (to fix some of the brokenness of aggregates
and MEDs) in order to provide a safety net for potential route leaking.

This is what the already well established community "no-export" is for.

You announce the supernet as you would any normal route and you
announce the specifics with "no-export" at only their "best-exits"
and only to your multi-exit-peers. That way the specifics can't
(well shouldn't be able to at least) leak but no connectivity is
lost since the supernet is never a candidate for filtering or

The traffic will follow the supernet until it gets to a network
that has the more specifics. No need to litter the routing tables
of thousands of autonomous systems that don't have a need to know.

The community 65530:arg was in my message for two purposes:
("when announcing to <arg>, replace this community with no-export")

* So that you can scratch those hard to reach places, I.e. peers
  of transits. Tier 1 providers don't have those of course.
* So that you can tag your specifics when injecting them with a
  community that will get automatically replaced with no-export
  when exporting to your own direct peers. More useful for Tier 1s.

It doesn't have the desired effect alone of course, but a trained
mind can easily see what other communities are needed to create the
correct combination in their own environment.

----- Original Message >

PS. Andrew Partan suggested that I'd write up an example implementation
of these communities for Cisco, Juniper and Gated. The Cisco version
was already included in the end of my original message, but I'm having
trouble with the Juniper implementation. I have no access to a Juniper
router and all the references for a configuration manual on

were password protected. Hence I need pointers that would tell me how
to configure a Juniper router.

If someone from Juniper hasn't already offered, forward me the Cisco
configs and I'll work out the Juniper equivalents...


Hmm, if some ISP allow the customer to control specifics (i.e. to say
_send specifics to A but don't send them to B etc), it can cause a lot of
broken routing over the network. The customers never (almost) understand
how does specifics work.

On the other hand, a lot of policy violence in the existing Internet was
caused just by the specifics. A lot of back-up-only links get traffic due
to this specific leaks, a lot of _peering only_ links provide hidden
back-ups due to this. Specifics are the very sharp weapons.

Through I don't complain against the idea of the transitive communities;
on the other hand, the question _how ISP can select transitive-only
communities when send advertisements_ have not good answer yet.