Re: Regarding global BGP community values

["Alex P. Rudnev" <alex () virgin relcom eu net>]

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.

Alex.


On Sun, 17 Oct 1999, Aleksi Suhonen wrote:

> Date: Sun, 17 Oct 1999 15:53:00 +0300
> From: Aleksi Suhonen <nanog-poster () axu tm>
> To: nanog () merit edu
> Cc: danny () ice ip qwest net
> Subject: Re: Regarding global BGP community values
>
>
>
> On Mon, 11 Oct 1999 22:19:21 -0600 Danny McPherson <danny () qwest net> wrote:
>
> > 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
> dampening.
>
> 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.
>
> --
>       Aleksi Suhonen
>
> 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 www.juniper.net
> were password protected. Hence I need pointers that would tell me how
> to configure a Juniper router.

Aleksei Roudnev, Network Operations Center, Relcom, Moscow
(+7 095) 194-19-95 (Network Operations Center Hot Line),(+7 095) 230-41-41, N 13729 (pager)
(+7 095) 196-72-12 (Support), (+7 095) 194-33-28 (Fax)