RE: charter

[smd@ebone.net (Sean Doran)]

Jim Bound writes:

| I agree we that. Only concern is that we just need to think long term on
| IPv6.

Well, I'm not sure that's going to be very easy.

To a much smaller (almost private) audience, I suggested that it may
be a good idea to "rob" two MSB bits to facilitate experimentation
with IDR for IPv6.   One bit would indicate whether a BGP information
would carry the prefix as NLRI _at all_, with the other in reserve
for testing things like IGPs, or doing bake-off tests in the wild.

The general idea is that one keeps 127 of the 128 bits one already
has, but in flipping the 128th bit, you have the prefix be used by
one of the other parallel IDR systems.

That way, we could continue with CIDR-v6 as the default best/only 
interdomain routing system, while making it possible to test and 
possibly transition to something else.

(How I imagine this would work is that entity X would stop announcing
prefix(es) to the worldwide BGP and start announcing prefixes with
the test bit set to the new parallel IDR; routers talking the parallel
IDR protocol suite would install in the FIB the prefix with the
test bit OFF & see whether traffic to host (with bit OFF) would
still work.  Or,  one picks a global IDR system by flipping
a bit in one's prefix, while still using the old IDR -- then,
check various routers to see whether both the normal prefix
and the mutated prefix with the bit turned on are heard, check
how the FIBs are built, etc etc, using the multiple-prefix-per-
host scheme.   There are probably a variety of more sensible ways
of dealing with it, but they probably will all benefit from the use 
of a different prefix, allocated specifically, or a new prefix type 
than the global unicast format, or a flag bit, in order to compare
reachability and actual routing between existing (BGP) IDR and 
some new test IDR.

One could think of it like the EGP/IGP/unknown BGP attribute...)

| For example a Table Search entry address is 4 times as large

A multiplier of 4x is nothing for a RIB, given that we see
exponential growth of prefixes and paths in BGP today, and 
any v6/v4 router will have multiple RIBs or will share a common
multiprotocol RIB, each having various time-space tradeoffs
and parallelizability issues, but each likely growing alot.

FIBs - hm - well, the worst case is you do alot more descending
through a tree or have alot bigger flattish table (or more m in
an m-way tree).  As long as nobody violates the initial assumption
that nobody cares what the 65th bit is in the core, I don't think
anybody will sweat.   An implementation that can handle /128s at
some large-ish fraction of (highspeed) line-rate is not inconceivable.

Really, v6 and v4 are amazingly identical, and the extra prefix
length does not really impose intractable technology costs in
CIDR longest-match routing/forwarding.   The question is, can we
get something alot better than CIDR longest-match given that we
have a bunch of extra space?

| not to detract from that applicability, but rather to just state we "may"
| have some new unknowns here.

Well, it's pretty hard to foresee unknowns. :-) :-) :-)

	Sean.