RE: Draft: PI addressing derived from AS numbers

On Sun, 2 Feb 2003, Pekka Savola wrote:

> For example, consider (in future) 10,000 routes coming behind a
> next-to-the-origin-AS ISP.   If something bad happens to the ISP, all
> 10,000 routes will be withdrawn, and a secondary path will be selected
> (perhaps 3,000 will go to ISP X, 3,000 will go to ISP Y, and 4,000 go
> nowhere, simplifying).

> The absolute numbers _might_ be manageable if changes were manageable: I'm
> fairly certain of that at least to the degree of O(10^6) -- memory is
> cheap.

I assume you mean 10^6 number of routes? Cisco's CEF seems to take
something like 300 bytes for a single route. That makes for 300 MB
worth of fowarding tables, which wouldn't stress current technology too
much.

BGP and routing table entries also seem to be something like 300 bytes
each, so for the main route processor the amount of memory could be
somewhat more problematic. But 4 copies of each route in the BGP table +
1 in the routing table would make for 1500 MB, also still doable.

> A way to make changes manageable could be to change how BGP works with
> regard to nested routes from multiple sources.  Or really, devise another
> protocol.  Here's a raw thought:

> When BGP is used for multihoming, all the paths are advertised throughout,
> not only the current best paths.  There has to be a marking on which ones
> aren't the best paths of course.  When a transit AS becomes unreachable,
> instead of withdrawing the routes and waiting for updates, the only thing
> that is signalled is "ASX went down, switch to alternative path(s) if
> any".  So, changes would not be processed per prefix, but mainly per
> (transit) AS, in an "aggregated" fashion. In that way, convergence could
> be near-instantaneuous and the amount of processing for BGP updates (at
> the cost of about N extra routes in RIB) needed when multihoming minimal.

We can do better than that. A new interdomain routing protocol should
separate the topology information from the NLRI. The AS <-> prefix
mapping can then be nearly static. Note that this would also be very
helpful in addressing the security concerns that currently exist about
BGP.

It would be logical to make such an idr protocol a link state protocol,
but I'm not sure if it is possible to make a link state routing protocol
that can function even if the full state of the network isn't always
completely known. Essentially, you'd want to know the state of what's
going on close to your AS in great detail, but more and more information
should be aggegated away as the distance increases.

Of course this aggregation should be based on geography for multihomers.