|
North American Network Operators Group Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical Re: Regarding global BGP community values
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 <[email protected]> > To: [email protected] > Cc: [email protected] > Subject: Re: Regarding global BGP community values > > > > On Mon, 11 Oct 1999 22:19:21 -0600 Danny McPherson <[email protected]> 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)
|