RE: Again no multi6 at IETF#56

["Tony Li" <Tony.Li@procket.com>]

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

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

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.

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

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


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.

Tony