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.