RE: charter

[Jim.Bound@nokia.com]

Sean,

All good points below Sean.

thanks
/jim

> -----Original Message-----
> From: ext Sean Doran [mailto:smd@ebone.net]
> Sent: Friday,February 16,2001 6:39 PM
> To: Jim.Bound@nokia.com; randy@psg.com
> Cc: multi6@ops.ietf.org; rja@extremenetworks.com
> Subject: RE: charter
> 
> 
> 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.
>