[ppml] 2005-1 status
gih at apnic.net
Mon Jan 23 18:56:52 EST 2006
At 10:38 AM 24/01/2006, Tom Vest wrote:
>On Jan 23, 2006, at 6:20 PM, Geoff Huston wrote:
>>At 08:18 AM 24/01/2006, Daniel Golding wrote:
>>>That is proof by assertion. The routing table has grown relatively
>>Relative to what?
>>>and there is NO reason to think it will grow faster under IPv6.
>>Given that there are few natural constraints to routing table bloat
>>than an advanced state of social consciousness, the drivers for IPv6
>>routing table bloat appear to include a vastly larger end device
>>and a commodity utility provider structure that cares little about
>>time (and money) to take measures to avoid routing table expansion.
>>That would appear to constitute grounds for thinking that, yes,
>>there is a distinct risk of IPv6 route table bloat at levels greater
>>than we've seen in IPv4.
>There is another factor also. ASes have now been implicitly adopted
>as a pricing factor for interconnection, in a way that could
>contribute to inflated demand for ASNs relative to the current demand
>drivers/trend. To the extent that ASN proliferation correlates with
>routing table bloat, and there are no new countervailing factors, we
>could be facing a new routing table growth dynamic altogether.
hmm - assuming that the 4byte implementations appear in the coming years
then its not a scarcity factor that would be driving AS consumption.
I'm not sure of the extent to which AS number growth drives BGP
scaling issues - I suppose I could identify two areas: a decline in the number
of prefixes per Update message, causing a greater number of
update messages to be generated, and (depending on implementation
approach) a greater memory load
(However, I vaguely recall that one major vendor's implementation of BGP
used 1 prefix per update for many years - but I'm not sure when and
where I heard it and whether it was "fixed" recently or not - if this is
case then the update load for such an implementation would be
independent of the number of ASs in the routing system.)
More information about the ARIN-PPML