Subject: Re: Again no multi6 at IETF#56

From: "J. Noel Chiappa" <[email-masked]>
Date: Tue, 18 Mar 2003 15:38:42 -0500

> From: Kurt Erik Lindqvist <[email-masked]>

    >> If there is a choice in how to multi-home, then some folks will
    >> inevitably choose the wrong way and we will again implode. 

    > 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.

	Noel

---

From: Masataka Ohta <[email-masked]>
Date: Wed, 19 Mar 2003 05:59:17 +0859 ()

Noel;

>     > something better. Let's do that then.

Our LIN6 based scalable multihoming implementaion has been working
for about a year on the world largest mobile IPv6 environment
with more than hundred wireless routers and less than 10 users.

A problem is that we haven't written specification in English, yet. :-)

> doubt we could stop them, actually.

We can't stop them use IPv4 with IPv4-style multihoming. :-)

							Masataka Ohta

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Tue, 18 Mar 2003 22:30:59 +0100 (CET)

> 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

---

From: Masataka Ohta <[email-masked]>
Date: Wed, 19 Mar 2003 06:43:00 +0859 ()

Iljitsch;

> modes. (Ok, not counting ISP going bankrupt as "common" here...)

It does not protect a site from ISP failure including but
not limited to bankrupcy.

Moreover, routes to imported addresses can not be aggregated that it
cause a scalability problems within ISPs.

							Masataka Ohta

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Tue, 18 Mar 2003 23:11:04 +0100 (CET)

> cause a scalability problems within ISPs.

Both true but I don't think this technique is thereby disqualified.

---

From: Masataka Ohta <[email-masked]>
Date: Wed, 19 Mar 2003 07:40:26 +0859 ()

Iljitsch;

> Both true but I don't think this technique is thereby disqualified.

The former problem is already too bad for people expecting multihomed
environment.

Moreover, I'm afraid you underestimate the latter scalability problem.

To move on, we must estimate the seriousness of lack of scalability
and, if it is not so bad, develop proper address assignment policy,
both of which take time, which disqualify your proposal.

							Masataka Ohta

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Wed, 19 Mar 2003 00:10:44 +0100 (CET)

> The former problem is already too bad for people expecting multihomed

It's still better than singlehoming.

> both of which take time, which disqualify your proposal.

It doesn't, as the evaluation can be performed while the solution is
being used. As there is a built in "you have to renumber at some point"
guarantee, whenever problems come up they can be fixed.

But if you feel that geographic aggregation is superior to such a stop
gap solution, I'm not going to argue.

---

From: Masataka Ohta <[email-masked]>
Date: Wed, 19 Mar 2003 08:43:47 +0859 ()

Iljitsch;

> It's still better than singlehoming.

It is a variation of singlehoming.

> guarantee, whenever problems come up they can be fixed.

That kind of guarantee never works.

> gap solution, I'm not going to argue.

I see no point discussing on stop gap solutions.

						Masataka Ohta

---

From: Kurt Erik Lindqvist <[email-masked]>
Date: Thu, 20 Mar 2003 07:19:06 +0100

The below is exactly what I describe in the 
draft-kurtis-longprefix-multihoming-00.txt draft. I agree that 
declaring it BCP is probably better than propose it as a standard. It 
still have the problems that Tony points out though.

- kurtis -

On tisdag, mar 18, 2003, at 22:30 Europe/Stockholm, Iljitsch van