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.
----- 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 www.juniper.net 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... /Sean ___________________________________ Sean Butler, CCIE #3897 AT&T Global Services -- OpenNet Support Phone: 727-533-8830 Fax: 813-878-5475 Internet email: sebutler@us.ibm.com
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)
participants (3)
-
Aleksi Suhonen -
Alex P. Rudnev -
Sean Butler