Re: Solving the right problems ...

Using a 1D numbering plan to support 5 (?) distinct dimensions (plan, 
technology, network routing, global host addressing and interface 
identification) looks like X121 or old telephony.
Which additionnal information do you need to move accross if you use fixed 
size dimension and gives evey dimension its separate numbering 
authority/structure and then concatenate them into a multidimentional 
address? Like for mobiles.
I remember when CCITT voted they would never allocate addresses of more 
than X bytes. (was it not 32?). Would anyone recall if at that time they 
discussed some kind of layer splitting? Old experience often carries 
interesting concepts. They were probably thinking hierarchichal instead of 
multidimensional?
jfc


At 16:49 27/08/03, Iljitsch van Beijnum wrote:

> On woensdag, aug 27, 2003, at 13:18 Europe/Amsterdam, Jeroen Massar wrote:
>
> > I totally agree with your current insight that we need to seperate
> > the routing from the host identifier. IMHO every host should have
> > one globally unique ID and could have multiple transports, even if
> > those are IPv4, IPv6, IPX or whatever based and going over multiple
> > links or not. Though we should limit to IP based protocols to not
> > make it too complicated. Such a mechanism could solve problems for:
> > "site-locals" constructions, multihoming, mobile-ip without hindering
> > the size of the routing table as people could continue to use current
> > routing, thus TLA based and fully aggregated to the TLA level in the GRT.
> The multi6 wg has been working on locator/identifier separation as a way 
> to solve the multihoming in IPv6 problem for a while now.
> The problems we're facing (apart from the fact that there are many ways to 
> skin this particular cat and everyone has a different preference) is that 
> additional mechanisms are needed to get the extra information across, and 
> there is a price to be paid in one or more of: additional round trips, 
> more dependence on the DNS or something similar to DNS, additional 
> per-packet overhead, loss of backward compatibility, increased complexity.
>
>
>
>
>
>
>
> ---
> Incoming mail is certified Virus Free.
> Checked by AVG anti-virus system (http://www.grisoft.com).
> Version: 6.0.512 / Virus Database: 309 - Release Date: 19/08/03