multi-homing fixes

Fri Aug 31 15:04:28 UTC 2001

| Assigning a prefix to a continent wouldn't be a good idea, because
| that way every regional ISP has to

Well, that's what's been happening for a few years now...

But consider this:

| announce the very large bitmap for the entire continent, while most of it
| contains just zeros. Per metro area would be better. But two ISPs that
| have many multi-homing customers in common could use a prefix for just the
| two of them, regardless of geography.

Instead of a bit-vector with lots of zeros, do run-length encoding
of the bits you don't have, or the bits you do have.

Now compare that to doing automatic aggregation, so that instead
of 16 contiguous 1 bits you introduce a prefix of x.x.x.x/(n-4).

See what I mean by your bit-vector just being another representation
(possibly more efficient on the wire) of what's already there?

That is, you are noticing that for any given abstraction boundary
that is non-topological, exception routes (more specifics or
described with your bit-vector) have to be introduced when a black
hole would otherwise result, and may be desirable to optimize
routing.

This is why the RIRs' prefixes are announced as relatively long
chunks of /20s or so rather than the /8s or shorter as they are
gotten from IANA/ICANN/ASO/thin air/whatever.

If you try to take the same approach and have a "SRIR" (s = sub),
you will see a carving up of the prefixes over time, in the same fashion.

The ONLY way to avoid this right now is to have addressing exactly
match topology.   The problem here of course is that nobody will
agree on which N entities are "top level".

| I'm mostly trying to solve the memory problem, but it should also help
| with (but certaintly not completely solve) the processing problem.

It doesn't really do either.  You have made a few time-vs-space tradeoffs
which move the problems around a bit, but don't actually eliminate them.

| Since an updated bitmap is always the same size and it updates many routes
| at a time, it should take less CPU power to process the updates. 

Parsing the received updates is not the major worry, and your
fix is targetted on the syntax of the updates, rather than 
their semantics, which is where the problem lies.

| I think the only way to really know what the processing benefits of all of
| this are is implementing it, or run detailed simulations, but those
| require pretty much an implementation as well.

Well, I won't stop you from testing an implementation or two.  Write back
to the list (or better yet, the IDR list) when you're done.

Let me take some of your text out of context and agree with it fully:

[A permanently stable holes-in-CIDR-blocks environment exists]
| Only if there is a limit on the number of ISPs. I don't think there 
| is such a [practical rather than absolute] limit

The problem with metro-based addressing is that the statement
above is equally true for it as for PA addressing.

	Sean.