Re: The state of IPv6 multihoming development

[Eliot Lear <lear@cisco.com>]

Nothing like 60 messages in one day after nothing in 6 months ;-)

Iljitsch van Beijnum wrote:

> I'm not convinced this is an "extra" service.

As Tony Li knows well I've never been one for artificial shortages and 
markets (which is what I think we have in v4).  On the other hand, you 
yourself later wrote the precise contradiction to this statement:

> Unfortunately, hierarchy -> tree structure -> no loops -> no redundancy.
Now, you could argue that the additional mechanism required should be at 
the transport or in a tunnel, or whatever.  But that's additional 
infrastructure as well.

By the way, Michel, when we use the term tunnel, in any form, we really 
ought to revisit existing technology to see if it can be adopted.  Thus 
Noel's allusion to MIPv6.

I'm not convinced.  I think we have to consider Craig's complexity 
question, but at the same time ask him what he's willing to pay for 
redundancy for his service, and what sort of redundancy he needs.

> So who benefits if Google is multihomed? The user or the server? Or
> both?

Google, or they wouldn't pay to be multihomed.  If their users 
experience a better service, in the end that is to Google's advantage. 
But let's also separate web services from Craig's case.  It's easy to do 
a service that knows about topology and delivers a single "close" 
address to a client name server or redirect to a client.  Been there 
done that.  In fact the actual physical hosts may not even be multihomed 
into the Internet, nor might their upstreams be.

Craig's problem is a lot more difficult.  Choosing the right source 
address in a large enterprise network is difficult.  Getting both the 
physics and economics correct here is important.

> For straight PI (or "CI") it is true that many organizations other than
> the multihomed one have to bear costs. However, this is far from
> "everyone else": only people who are default-free _need_ to pay for the
> extra memory and CPU power for their routers. In a multiple address
> solution this is much, much worse: in that case, all IPv6 hosts may have
> to implement extra functionality to be able to talk to multihomed
> destinations.

This is only because there isn't a viable alternative in v6 yet.  When 
there is you can impose a cost model in v4 and let the market do its 
thing.  And that cost model would include things like "maintenance of 
legacy v4 infrastructure, route sourcing charges, etc."  The IETF 
actually has heard from game theory researchers on this topic.

Not new.

The *real* cost I want to understand is how much someone is willing to 
pay to have fine grain control over their policy as they do today with 
BGP, padding, etc.

Eliot