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

Re: A new spin on multihoming: multihoming classes.



On Thu, 6 Sep 2001, Shane Kerr wrote:

> However, there is a need for network multihoming, which will probably
> need to be solved as well.  But given that most of the growth of the
> routing table seems to be end users desiring reliability and speed, I
> think the network multihoming problem can wait.

It never hurts to give the subject some thought.

Many of the large networks would really like an 8k global routing table
in IPv6. That means: no more than 8192 ISPs with a PA block of their own.
(I'll be using IPv4 terminology.)

I think this is a reasonable number if we can enforce strict requirements
on holding PA blocks. Avoiding renumbering can't be a reason for having a
PA block any more, even if this requires millions of hosts to renumber
when there is some change in connectivity. People will feel they're held
hostage by their existing ISP unless renumbering becomes completely
painless. I think the tools for the actual renumbering are there, but
changing DNS entries for all these hosts might be a problem.

Then there are the enterprises that want to multihome at the network
level. Obviously, giving those PI space would be impossible. So they would
have to announce a /48 out of one ISP's PA block to other ISPs. The other
ISPs will allow this, because it brings in cash. Small ISPs will be happy
to receive the /48s at exchange points, because that saves them cash.
However, we can expect some of the larger ISPs to filter the /48s because
they have no incentive for carrying the more specific routes.

Still, as long as all of its other ISPs peer with the "primary" ISP (the
one the enterprise got its addresses from), the enterprise will be
reachable when the link to its primary ISP fails or that ISP's POP fails.
Only when the entire primary ISP is wiped off the network, they'll be
unreachable from networks that filter the /48s.

But in that case, they can still fall back to multi-address / host level
multihoming.

Iljitsch van Beijnum