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

IETF multihoming powder: just add IPv6 and stir



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.