[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.