RE: Solving the right problems ...

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



-----BEGIN PGP SIGNED MESSAGE-----

Iljitsch van Beijnum [mailto:iljitsch@muada.com] 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.

And ever since they haven't progressed much unfortunatly :(
 
> 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,

Indeed, one will always have this problem, my current idea relies
on DNS, but if a program currently tries to contact another host
it will usually already do a forward resolve and some apps
(ssh for instance) also like to do a reverse resolve already.
So these shouldn't be much of a problem. In the idea I have I
have also added the possibility to limit these lookups until
a failure occurs.

> additional per-packet overhead,

Not required for my idea.

> loss of backward compatibility, 

I covered that in my idea, by simply adding functionality
and not replacing it in a manner which could cause
unexpected effects on the installed base.
The installed base won't have the benefit

> increased complexity.

Not overcomable, but it should not be noticeble much in
the idea I have. It's also more of a Proof of concept for me
to see if I can get such a mechanism to work and to proof
that such mechanisms are viable. Query me at RIPE next week
if you want to hear more about it.

Greets,
 Jeroen

-----BEGIN PGP SIGNATURE-----
Version: Unfix PGP for Outlook Alpha 13 Int.
Comment: Jeroen Massar / jeroen@unfix.org / http://unfix.org/~jeroen/

iQA/AwUBP0zaOimqKFIzPnwjEQL+ZQCeIR0X0MEUnLsow6IGwKfFLsYTstEAn2SQ
zMvifMn7z9A12oPp82cjXmCF
=LdLQ
-----END PGP SIGNATURE-----



[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]