[arin-ppml] Does Moore's law help with routing table growth?
>> Michel Py wrote:
>> I must have missed a step; how does multihoming with
>> private ASNs work?
> Scott Leibrand wrote:
> Our mutual customer runs BGP with both of us, uses a private ASN to
> run BGP, and announces both of us his route. We both implement the
> remote-private-as command (or equivalent) to strip his private ASN
> from the path before announcing it to our providers and peers. As a
> result, the BGP table contains the route with two different origin
> ASNs: mine and yours. That's ugly, but it doesn't really break
Oh. Well while in that mood we might as well announce PA prefixes, it
doesn't break anything either. No ASN, no PI prefix. Simpler. We don't
need BGP either, there's always static routes :-D
>> Besides, ASNs are not in short supply, slots in the routing table
>> are problematic. How would raising the price of ASNs would prevent
>> people from announcing a gazillion prefixes from one ASN?
> Exactly correct. Which is why any viable method would have to
> monetize the routing slots directly,
> for example by tier 1 transit providers charging their customers
> per route announced, and adding deaggregation ratio requirements
> to their existing traffic ratio requirements in their peering
> agreements with each other.
This may be a sticky thing.
> Which won't happen unless the rate of growth of the routing table
> becomes a much more significant problem than it is today, or router
> capacity growth dramatically slows.
> Christopher Morrow wrote:
> Speed of change is how quickly you can update, and often across
> a severely limited pathway, the FIB when a RIB change happens.
> Today you stay ahead of that change rate (mostly) and your
> device's view of the world is 'converged'. Tomorrow if that
> change rate is higher than you can keep up with you will never
Indeed; when a tier-1 flaps there is a ripple effect globally; I'm not a
dampening specialist though. I can certainly see a potential issue if
the pathway ratios between tier-1 and multihomed customers changes
significantly; conceptually a large route flap could be handled by the
core but overwhelm the edge just because of the sheer size of the