Re: Again no multi6 at IETF#56

[Kurt Erik Lindqvist <kurtis@kurtis.pp.se>]

>
(Trying to catch up on mail here)

> |    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.
>
>
> All of the pain and none of the gain?  Any announcement of longer
> prefixes is at the expense of routing scalability.
Agreed. No question. But with 350 routes I am more worried over the 
lack of routes....


> |    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.
>
>
> The cost of multihoming is falling.  Today, sitting at home on
> my couch, I can easily connect to my neighbor's WAP.  If we
> were to tweak things a bit, both of us would be multi-homed
> through the other.  In fact, the cost of connectivity is
> continuing to fall, so one might expect that the cost of
> multi-homing will fall too.
I don't question that. What makes me wonder is how many home users will 
actually want/need multihoming? How many SOHO will? How many 
enterprises?

> If you subscribe to the view that businesses find the Web
> interface to be important, then it stands to reason that the
> interest in multihoming would continue to grow.
Agreed, the question is how fast?

> |    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.-
>
>
> It's very unlikely that we can ever undo what was done before.
> You may recall the flap during the CIDR days about asking
> people to renumber so that we could aggregate.
I tend to agree with you here. Which is why I have always said that it 
only has potential to do this. Just as we scaled back the routing table 
growth a few years ago (I know it was more the .com hysteria 
collapsing) with filters, we have the potential do to similar things 
here.

> And then, six months from now, someone stands up and says "thanks,
> but we've got an installed base and we can't change".  No thanks.
> Do it right the first time, or not at all.
Well, I think we need to move in steps for a number of reasons, 
urgency, implementation lead times, and last to get consensus. This 
said, I think that we need to always keep in mind how we will get from 
A to B, and eventually to C.

But that is what I hope will be the first issue we could get agreement 
here on.

- kurtis -