Subject: RE: Again no multi6 at IETF#56

From: "Tony Li" <[email-masked]>
Date: Sun, 16 Mar 2003 23:46:14 -0800

|    I still think 
|    that doing it the IPv4 way is the best and fastest hack we 
|    have for 
|    multihoming IPv6.

Kurt,

It may well be the fastest.  Certainly the old way usually is.
And it may be the 'best' that we have right now because we don't
have agreement on a better path.  However, if we do go down the
path of long prefix distribution, the core is almost certain to
implode.  Here, there be dragons that we should avoid.

And regarding the issue of 'choice', we need there to be no
choice in the matter.  If there is a choice in how to multi-home,
then some folks will inevitably choose the wrong way and we
will again implode.

	Freedom from choice: it's what you want.
					-- Devo

Tony

---

From: Kurt Erik Lindqvist <[email-masked]>
Date: Mon, 17 Mar 2003 18:55:54 +0100

Tony,

> implode.  Here, there be dragons that we should avoid.

I fully agree that this is a far from perfect model. However, note one 
thing. I only advocate the _announcement_ of a longer prefix, not 
_allocation_. If I change provider, I need to hand the address space 
back.

But let's look at the explosion of the routing table. Today there are 
15k ASes in the DFZ. If these all have three upstreams that is 45k 
routes. If we use all the 16-bit AS numbers we have around 192k routes. 
This is a poor calculation and comparison, but the fact is  that the 
natural aggregation of the larger IPv6 allocations are helping us here. 
I still think that what will limit multihoming for the coming years is 
not scarcity of resources but the  cost of doing it.

Last, as we today think that a policy of not announcing longer prefixes 
are prohibiting this, I assume that we believe we can enforce this in 
the future as well? That gives us a potential roll-back scenario. Also 
note that this is almost more of documenting BCP than defining a new 
policy.-

> then some folks will inevitably choose the wrong way and we

There will be different choices at different times. 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.

Best regards,

- kurtis -