What happens next? was: Re: Agenda for Atlanta

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

On Wed, 23 Oct 2002, RJ Atkinson wrote:

> Generally a subset of the mailing list attends a given WG meeting,
> for reasons of cost and calendar complexity.  They generally do not
> draw a wider audience.

Ok. I assume more people will show if we tell them we may be straying
onto their turf.

Although nobody bothered to answer directly, it seems there is consensus
that the requirements can be accepted with some small changes. Good.

So what happens next?

As I see it, we are ready to start working on (relatively) short term
routing-only, no changes to code solutions. Some people feel these
solutions are inherently inadequate. I don't think that's sufficient
reason to not work on this. It may be sufficient reason to not implement
it later, but let's see what we can come up with first.

We are NOT ready to start working on solutions that use multiple
addresses, as there are no good routing <-> source address selection <->
filtering/failing <-> session rehoming mechanisms. I think it
would be good to come up with a multi address requirements document. (Or
maybe there already is one and I missed it?)

When the multi address thing is clear, work can start on address agile
transport protocols. However, I don't think this wg is the right place
for developing individual transport protocols.

There are already several proposals for tunnelling/aliasing solutions.
However, having several of those that don't interoperate would be a Bad
Thing so I think when we've sorted out the multi address thing, this wg
should focus on making different solutions in this area interoperate, or
maybe come up with a single solution that is so good others aren't
needed.

In the mean time, the IRTF can brood on IPv7 and perfect routing. The
right answer too late is just as wrong as the wrong answer immediately.

There is one thing I want to stress: we all have opinions on which type
of solution is better. However, at some point input along the lines of
"this solution type simply doesn't cut it" stops being productive. The
IETF has produced many protocols that aren't perfect, or even very good.
Some of them are in wide use. The best way to stop a bad solution is not
to try and stop a bad solution, but to create a good solution of your
own.

> > However, if we can get some routing, transport protocol and mobility
> > people together, we may actually come up with some new insights or even
> > a broad consensus.

> 	The routing people who have showed up here are not slouches,
> yet seem to be ignored by some of the vocal multihoming advocates.
> Sigh.  And I don't think we lack for transport or architectural clue
> here either.

I wasn't commenting on the cluefulness of the multi6 participants. The
problem here is that so little happens. Some fresh input might be just
the thing to get things moving.

Iljitsch