Re: Move forward

[Iljitsch van Beijnum <iljitsch@muada.com>]

On Wed, 12 Mar 2003, Masataka Ohta wrote:

> > If we can make an upgrade path from type 1 solutions to type 2
> > solutions and from type 2 solutions to type 3 solutions, this will
> > greatly enhance the prospects of each.

> No.

If we want to do something with PI in type 1, that's going to be hard
because it doesn't scale well enough in the long run. If we want to do 2
at all there's the problem that everyone has to implement it before it
works. However, if we first do 1 and then 2 people who want 2 will use 1
as long as 2 isn't available yet (so more use for 1) and people don't
have to be afraid 1 will blow up in their faces because they're
migrating to 2 later. So both are more viable.

> > 1. "No changes" routing-based approaches, ranging from simple (ignore
> >    the scalability problem for now) to complex (geo aggregation).

> > 2. Weak identifier/locator separation: the identifier is an address
> >    usable for routing that is replaced/hidden in transit in some way,
> >    typically by a router or middlebox (MHAP, but also
> >    tunneling/redirection mechanisms)

> The proble is that there is no such solutions.

There are drafts. Don't know if they solve anything...

But the point is that we work on it. It seems likely that any existing
draft or proposal can be improved upon if we work together. You wouldn't
know it, but there are actually some very smart people in multi6.  :-)

> If you disagree, feel free to use type 1 and 2 solutions with IPv4.

GFN isn't going to work to any usable degree with IPv4 because there
simply aren't enough bits. There are many other type 1-like solutions in
actual use in v4, though. Type 2 could work well if you don't mind
burning two or three times as many addresses.

> > 3. Strong identifier/locator separation: the identifer isn't an address
> >    usable for routing, so the end host must implement the solution
> >    (basic multiaddressing as we know it today, SCTP, HIP)

> Here is the point where the merit of having longer address could be
> deployed.

Actually this type of solution doesn't really need the bigger addresses.
I would even like to have type 3 run over both v4 and v6.

> > With those requirements in hand we can apply the "people who say
> > something can't be done shouldn't get in the way of the people doing it"
> > rule.

> You are getting in the way of the people doing type 2 and 3 insisting
> that there should be upgrade path from type 1 and 2.

Since anything that can be done in a middlebox can also be done in a
host, the upgrade path from 2 to 3 shouldn't limit 2 too much.
Essentially, 2 is a subset of 3. As for 1 to 2: I think the burden
should be mostly on 1 there. More concrete: I want to use PI addresses
in a type 1 solution that become the identifiers in a type 2 solution. A
type 2 solution could also use PA addresses but that would be stupid as
PI is much better for the user and there aren't many down sides to using
PI in type 2. There are in type 1 so we should see if we can afford it
there.