Re: multi6

[smd@clock.org]

[brought to list]

Vijay writes:

| To back up a point that sometimes we want to trade off state for longer
| paths in terms of bit/miles.

Well, that's a truism.  :-)

The problem is that in CIDR people deaggregate to longer prefix/masks
to optimize their routing because the only other tool to do so is 
renumbering to a completely different prefix/mask.

Now, one thing v6 could do that actually solves this particular IDR
problem is to provide for quick renumbering of everything covered
by a particular prefix/mask of arbitrary mask length.  For instance,
if an organization covered by /22, which has a (for the sake of argument)
/32 carried within its present provider, decides to go-it-alone, then
everything in that /32 should renumber into a new /22 provided by 
the registry.

Likewise we should document other cases, such as renumbering the /32
from one provider's /22 block to another's, and for the interesting
historical work on "sharing exceptions" by selectively leaking
the /32 among several providers, without making it globally visible,
and without requiring a renumbering or multi-numbering.

This is all covered in my suggestion that we focus on v6-CIDR
derived from v4-CIDR first, since there's a bunch of writing up
of BCP-esque and PS material to do.

| No, please continue, this is fascinating. I was still stuck in FIB land.

Well, there's not much more to say: the only IDR technology we
have now is BGP+CIDR and we know that this can be in trouble with
increasing numbers of prefixes.   There are no solutions, only
slower convergence times or serious work on reducing the number
of prefixes, or at least keeping a ceiling on the total number
where that ceiling runs at (hopefully less than) Moore's Law rates.

To the extent that we can DTRT early on with respect to advice to
registries and operators and people looking for addresses, we push
back the problem until other IDR technologies are available.

(e.g. GSE or multi-address multihoming with v6, or something completely
      different)

	Sean.