Re: Network layer reqt? [was Re: Transport level multihoming]

[Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp>]

Brian;

> > > Restoring
> > > network level connectivity after an outage is necessary and sufficient.
> > 
> > It is often very complex to build into an application system.
> 
> Yes, but my point is that for the apps that need it,

The problem is that apps do not need it. Its people using the apps
who need multihoming, regardless of whether their apps really need
it or not.

If you make only apps, which really need multihoming, multihomed,
people using other apps keep demanding IPv4 style multihoming.

> this was done
> years ago. I have no problem with offering something better
> for future apps, but we have to live with the old ones. Apps are
> *not* going to be rewritten for IPv6.

I know. In IPv4 dominant world, there is absolutely no incentive
to offer IPv6.

However, in IPv6 world, there is incentive to support IPv6 style
multihoming, if TLAs are not supplied easily.

IPv6 apps will be rewritten to support IPv6 multihoming.

It's just a simple economics.

> > > > Note also that you are assuming large, thus, slow to converge,
> > > > routing table.
> > >
> > > Unfortunately that is the only safe assumption, until we find a multihoming
> > > solution that doesn't punch holes.
> > 
> > Considering that there virtualy is NO install base of IPv6, we
> > can assume anything.
> 
> If we deploy IPv6 on today's model - punching holes
> to multihome - then we *will* get a massive routing table. 
> That's 100% certain. The only way to avoid it is to avoid
> punching holes. But we shouldn't talk about how to do that
> until we have agreed on the requirements.

Nonsense.

*THE* requirement, not an assumption, is to make global routing table
small.

						Masataka Ohta