Re: The state of IPv6 multihoming development

["Robert J. Rockell" <rrockell@sprint.net>]

->
->What we should do
->-----------------
->
->This is what I think this wg should do:
->
->0. Move past the requirements. There is consensus--sort of. It's not going
->   to get much better than this.

This 'sort of' could serve as a good indicator that the current solution
space is not well-received.    I think it is important that requirements
get documented, blessed, and put through the system in this working group.
There is already enough 'bad blood' in the IETF about IPv6.  If one were to
develop a solution to the multi-homing problem, without first having the
requriements document solidified, this just furthers the problem (ex. "the
solution stinks, it doesn't take into account X,Y, and Z").

Summary: Define the problem before you solve it. This has gotten us into
trouble with this nasty little protocol before. We should learn from
mistakes in the past.


->
->1. Make recommendations to developers and other wgs about what
->   they can do to better support multihoming.
->
->2. Several tunnelling/aliasing solutions have been proposed. It would be
->   good if those could interoperate. This would make it possible for a
->   multihomed host with (for instance) modified mobility support, to
->   interact in a multihomed-meaningful way with a host sitting behind a
->   cluster of big aliasing boxes. This would greatly relieve the
->   chicken/egg problem for this type of solution and make experimentation
->   with the really hard part (discovery and its security) easier. So we
->   should come up with a protocol that makes this interoperation possible.

Good for 6bone, bad for 'real' networks.  inter-provider SLA's are a long
way off... and this is requirement #1 for most of the tunneling stuff to
work.

->3. Open the lines of communication with people working on mobility.

...but they scale the same as this problem does... not sure. Perhaps
safer to circle back frequently, then try to develop some consistency
between the groups for the sake of similarity.

->
->4. Work on geographical aggregation, especially by getting an address
->   allocation mechanism that supports this off the ground.

I'm with RJA on this one.   that dog won't hunt.  You're making assumptions
about how interconnection occurs, and implementing a protocol BCP, that has
dependancies on what a network engineer can do/afford/justify/etc... a
dangerous game.   It is probably an ok assumption to say that every
geographic provider is not connected to each of it's 'peers' (in the
they-do-the-same-business sense of the word) in region.    Will the world
get better or worse?
Are we REALLY assuming filtering in iBGP? Really?  It
would seem that is a tertiary requirement out of every thread I see in this
solution.  I would like to see more operators weigh in on the feasibility of
these solutions.

rjr




->
->Iljitsch van Beijnum
->
->