Subject: IETF multihoming powder: just add IPv6 and stir

From: Iljitsch van Beijnum <[email-masked]>
Date: Sat, 26 Apr 2003 14:56:53 +0200

That's not going to happen.

If we want to make progress at the Vienna meeting something has to 
give. I agree with Erik that a detailed discussion of all proposals (or 
even all drafts) isn't going to do much good. Not that we could fit 
that into a reasonable timeslot anyway. But I don't think asking one 
person to go over all the proposals is the solution, as the current 
proposals are typically so complex it's impossible to do them justice 
in a significantly shorter form than their drafts.

It seems to me the problem is that everyone brings different 
assumptions and requirements to the table. For instance, the HIP people 
are mainly interested in security and mobility, and solving multihoming 
is secondary to those goals. Christian Huitema's proposals are built 
around the idea that we can only make baby steps and should work as 
much as possible with existing mechanisms. Michel Py doesn't mind much 
that both ends must be changed in order to support MHAP; in my geo 
stuff I don't worry about the fact that this will impose limits on the 
network topology; and the GSE++ people aren't all that concerned with 
the fact that GSE needs changes to not just one, but many aspects of 
IP: routers, hosts, DNS.

As long as this is the case I don't think it's possible to reach 
consensus on protocols. You can't ask people to agree on the best way 
to do something if they feel that something shouldn't be done in the 
first place. (And as long as they think it's still possible to prevent 
the "something" from happening.)

So we should use Vienna to decide WHAT we want to do, the HOW is then 
only a question of engineering, which we're supposed to know how to do 
here in the IETF.

It looks like the type of solution that most people like / the least 
people hate is a GSE++/8+8/6+2+10/16+16 type of solution. Such a 
solution is probably the least ambitious that can still be expected to 
work well in the long term and probably the most ambitious we can 
expect to be deployed before we run out of IPv6^H^H^H^HIPv4 address 
space. If we can't reach rough consensus on this as a general approach 
it is extremely unlikely we can reach it on something else.

Note that agreeing on this approach doesn't mean all other proposals 
should be off the table immediately: if they provide additional 
benefits (for instance, they can be deployed before the "official" 
solution is ready) they should be viable so individual authors can keep 
working on them as they see fit.