Subject: RE: Solving the right problems ...

From: "Jeroen Massar" <[email-masked]>
Date: Wed, 27 Aug 2003 18:20:10 +0200

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

Iljitsch van Beijnum [mailto:[email-masked]] 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

--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [email-masked]
--------------------------------------------------------------------

---

From: "Tony Hain" <[email-masked]>
Date: Wed, 27 Aug 2003 09:48:42 -0700

Iljitsch van Beijnum wrote:
> 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.
> 

At least the backward compatibility issue is primarily due to trying to
force a lower layer to mask the topological realities. There may be some
need for additional round trips, or enhanced mapping infrastructure, but if
that only applied to apps using a new stabilization layer, there wouldn't be
as much complaint because those would see a clear benefit. In any case I
don't think adding a layer will be a trivial task, but from here it looks
like the least the path of least resistance.

Tony