On Thu, Jun 22, 2000 at 02:39:27PM -0600, Danny McPherson wrote:
If a provider performed prefix filtering on their peers, the policies would need to be auto-generated from some database, a la IRR or the like. This used to be a problem not long ago, when things such as sequenced prefix lists (with incremental update support), and BGP route refresh didn't exist. Today, however, they do. The problem is that the data in the IRRs is stale -- at best,
Perhaps this should serve as a small head's up. One side effect of the RADB maintainer object fee is that stale objects from unowned maintainers will be purged from the RADB. This will probably happen Real Soon Now. One planned use of the planned Route Server extensions (RSng++) is to allow real-time correlation of routing data against the totality of the IRR. This will likely result in a publicly accessible database of what the Route Servers have seen in the global routing mesh. For completeness, such a database may also include views from other routers. One possible use for such a database is an report similar to the CIDR report showing non-registered routes. A development schedule for the new features has not been set yet.
the associated infrastructure isn't necessarily production quality, the routers can't store the policies, much less perform matches in a reasonable manner,
If the routers aren't able to handle this then people should start putting pressures on their router vendors. I would be curious if the various router vendors have benchmarked their route filtering mechanisms and published it anywhere. As a data point, most of the existing route servers at the RSng maintained exchange points are Sun Ultra-1 hosts (some are Alphas) with up to 512M of memory (the MAE's) and as little as 256M in other locations. The amount of memory required is (roughly) proportional to the number of routes received and the number of views the route servers has. A "normal" router wouldn't require nearly this amount of memory since normal routers do not maintain the idea of a "view" - just a pool of routes and policy filters for incoming and outgoing policy. Additionally, current RS prefix filters waste space since RSd requires duplicate ACLs in a given policy filter, even if they are identical in several places within the file. (Scheduled to be fixed.) The mae-east route server has 60 views, and receives an average of 70K routes from about the same number of peers. Mae-West has 56 views and about 57K routes. At these loads the RS's still has memory to spare. With the current inefficiencies in RSd it is still able to converge over 60 views in less than 2 minutes. Much of the time it takes for things to converge is due to the fact that when a peer is dropped it takes a while for it decide to come back. (The route server reconfig process is another thing that needs work - both in re-processing the prefix filters, and also BGP soft reconfigs.) My point is that although the route servers can be considered to be underloaded by the number of routes available from the number of peers we have (i.e. we're not receiving a full Internet view from each peer), convergence time is still good on an Ultra 1. And I'm pretty sure that I'm running more prefix filters than almost anyone else on this list. (45M for Mae-East.) Most people's prefix filters are targeted towards "Here is the routes I expect you to send me and here are the routes I want to send you." This protects one's network and one's downstream customers. However, such filters can be HUGE and contain many duplicate prefixes. In a perfect world where the IRR was sufficiently populated, one should need one prefix filter to protect against blackholing: "Are these people allowed to originate this block? Are these people allowed to originate this aggregate?" The IRR (as viewed from the RADB host) currently contains 153K route objects - including all stale data. Simply filtering on origin AS and prefix (or aggregator AS and aggregate prefix) provides a large chunk of the safety-net filtering that people are looking for. It doesn't prevent sub-optimal routing, but it helps prevent people from injecting stupid things into the mesh. Unfortunately, most policy filtering mechanisms aren't optimized to this simplified case. Perhaps it needs to be worked on.
-danny
-- Jeffrey Haas - Merit RSng project - jeffhaas@merit.edu