I-D Action:draft-azinger-scalable-addressing-00.txt

Brian E Carpenter brian.e.carpenter at gmail.com
Tue Sep 28 04:38:44 CEST 2010


On 2010-09-28 11:03, Doug Barton wrote:
> On 9/27/2010 2:36 PM, Fred Baker wrote:
>>
>> On Sep 27, 2010, at 2:24 PM, Doug Barton wrote:
>>> So this is one more strong argument for IPv6 PI in as many places
>>> as humanly possible.
> 
>>> Please note that I am not suggesting that this is a "fire and
>>> forget" solution, I'm aware that even in IPv6-topia there will
>>> still be renumbering due to organizational changes (e.g., mergers
>>> and acquisitions) but we really should be focusing on IPv6 PI as
>>> the answer, not as the problem.
>>
>> So you would very strongly prefer a world in which router memory
>> sizes are required to be effectively infinite.
> 
> Easy there tiger, that's not at all what I said, and it's not even close
> to what I think. Someone else already pointed out that where they have
> 2-4 IPv4 blocks advertised now, they could easily get by with just 1
> IPv6 announcement. In my book that's making the routing table smaller,
> not larger. :)
> 
> What I'm advocating is not blindly bloating the routing table ad
> infinitum. What I'm suggesting is that we look at the whole chess board.

Right, one BGP4 update on the first square, two BGP4 updates on the second
square, four on the third square, and so on...

The question is, as Fred was I think getting at, where do you stop?

If you arrange guidelines and policies such that you stop at, say,
a few hundred thousand PI prefixes announced world-wide, we can hope that
the routers won't melt.

If you arrange guidelines and policies such that you head towards ten
million PI prefixes announced in BGP4, then San Jose, we got a problem.

I think this is what the IETF, and v6ops specifically, needs to
communicate on a technical basis to the RIR and ops community.
People on this list here probably know it, but not everybody.

Beyond that, please read draft-irtf-rrg-recommendation, but
remember that it's only words.

    Brian



More information about the ipv6-ops mailing list