Re: Again no multi6 at IETF#56

[Iljitsch van Beijnum <iljitsch@muada.com>]

On Tue, 18 Mar 2003, J. Noel Chiappa wrote:

>     > We need apply the solution we have today with zero implementation. And
>     > I don't see any other alternative. six months from now we might have
>     > something better. Let's do that then.

> The thing is that we don't need to do anything to allow people to do it the
> "current way" (i.e. let the routing handle it, al la IPv4 MH) - in fact, I
> doubt we could stop them, actually.

> On the other hand, there's no need to put the IETF Gold Seal of Approval on
> something we now won't scale in the long term.

> Taken together, that all argues that we should press on and say nothing about
> the interim IPv4-type thing.

Well there is one way of multihoming that provides reasonable benefits
without too many issues that can be deployed today: take address space
from one ISP and announce it to two or more ISPs. As long as there is
peering between these ISPs you're protected against all common failure
modes. (Ok, not counting ISP going bankrupt as "common" here...)

If ISPs filter the /48, there isn't much of an issue as long as the
aggregate is still visible from ISP A and ISP A forwards the traffic to
ISP B.

The one thing that needs some consideration is filtering between ISPs:
if ISP C filters packets it gets from ISP B with ISP A source addresses,
all of this breaks. There are two ways around this: ISP C accepts the
/48 (assuming they're doing uRPF) or they don't filter but trust ISP B
to filter their customers.

Now do this with two /48s from two ISPs and you can start experimenting
with multiaddressing and have a safety net at the same time.

Just one down side for the enterprise: this is PA space, so it is
necessary to renumber when changing ISPs.

Any reason why we shouldn't publish this with the IETF bronze seal of
approval as a temporary best practice?

About the first most important multihoming issue you ranted about in an
earlier message: I don't think we are overlooking this (see my comments
to Marcelo's draft, and my conversion to favoring transport layer
solutions a few months ago). But:

1. This isn't all that controversial
2. Doing it wrong first and improve later doesn't create an
   impossible-to-clean-up-mess (like allowing /48s in the DFZ)

Iljitsch