Re: [apops] Re: The Mandatory One Reply To This Weeks: The Cidr Report

[Joe Abley <jabley@automagic.org>]

On Thu, Mar 22, 2001 at 12:28:43PM +1100, Phillip Grasso-Nguyen wrote:
> Not if backbone providers allowed users to control their own routing
> policies via communities,
> This wouldn't be hard, but what it does mean is that it gives much more
> control to end providers which direction traffic flows.
> 
> e.g. if matching a community (small example). This would stamp the route
> apply these settings to it's directly connected peers.
> 
> 5511:10000, set no-export to all peers
> 5511:10001, set no-export to AS701
> 5511:10002, set no-export to AS6461
> 5511:10003, set no-export to all European peers
> 5511:10004, set no-export to all north american peers
> 5511:10005, set no-expor tto all Asian peers
> 5511:11000, set prepend once (5511) to all peers
> 5511:11001, set prepend once (5511) to AS701
> 5511:11002, set prepend once (5511) to AS6461
> 5511:11003, set prepend once (5511) to European peers
> 5511:11004, set prepend once (5511) to north American peers
> 5511:11005, set prepend once (5511) to all Asian peers

There are lots of ASes that support this kind of policy, but when you get
big, and there is noticable flux in peers being turned up and going away
on a daily or weekly basis, the challenge is to find a system of
communities that doesn't need substantial modification the whole time.
Rolling out configuration changes to all routers to support every new
peer is not practical.

What we need is a consistent mechanism that can be implemented once across
ASes, and which will scale as external connectivity changes without config
truck-roll.

Ultimately you might imagine a default policy which filters based on
prefix length (e.g. by allocation boundaries) but which allows longer
prefixes to propagate as long as they are explicitly tagged with
instructions on how far they need to be carried.


Joe
*             APOPS: Asia Pacific Operations Forum              *
* To unsubscribe: send "unsubscribe" to apops-request@apnic.net *