North American Network Operators Group|
Date Prev | Date Next |
Date Index |
Thread Index |
Author Index |
Re: Regarding global BGP community values
- From: Alex P. Rudnev
- Date: Mon Oct 18 07:19:25 1999
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.
On Sun, 17 Oct 1999, Aleksi Suhonen wrote:
> Date: Sun, 17 Oct 1999 15:53:00 +0300
> From: Aleksi Suhonen <email@example.com>
> To: firstname.lastname@example.org
> Cc: email@example.com
> Subject: Re: Regarding global BGP community values
> On Mon, 11 Oct 1999 22:19:21 -0600 Danny McPherson <firstname.lastname@example.org> 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
> 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)