[ppml] Effects of explosive routing table growth on ISP behavior

[Ted Mittelstaedt]

>-----Original Message-----
>From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net]On Behalf Of
>Scott Leibrand
>Sent: Wednesday, October 31, 2007 12:23 PM
>To: Brian Johnson
>Cc: ppml at arin.net
>Subject: Re: [ppml] Effects of explosive routing table growth on ISP
>behavior
>
>
>Brian Johnson wrote:
>> This is true today; I can break-up my ARIN allocation and advertise
>> longer prefixes down to a point where I will lose some network
>> reachability. Actually, we should remove the language from the IPv6
>> policy that indicates anything about advertising the "covering
>> aggregate" unless we are willing to cede that all assignments will
>> remain purely hierarchical in nature. So anyone who multi-homes will
>> have to get an assignment from a RIR to maintain reachability.
>>   
>
>I don't think that's true.  Today, anything you advertise in IPv4 down 
>to a /24 will be accepted more or less by everyone.  However, that's 
>only a convenience for optimal TE.  In order to just maintain 
>reachability, all you really need is for your upstreams (all your 
>transit providers and all their transit providers) to accept your 
>deaggregated routes from you and from each other.  The rest of the world 
>need only accept the RIR-assignment-size covering aggregate, route the 
>traffic toward one of your transit providers, and then let the 
>more-specifics take over when they hand the traffic off to them.
>

But But But...

Suppose you have an ISP who has a /20.

He has 3 NOCs.  The first has a /21 assigned, the second and
3rd each have /22's, all of these are out of this /20

The 3 NOCs are fully meshed for failover redundancy in case one
of the providers tanks it, and he has a feed from each NOC
to a transit provider.

He starts out advertising the aggregate /20 to all 3 transit
providers.  But he then finds out that most of the destinations
on the Internet favor 1 transit provider and so most of his
traffic is coming in to 1 of the NOCs and being sent over
the mesh failover links.

He doesen't like this - so he splits the /20 advertisement into
3 advertisements, a /21 and 2 /22's and advertises all 4 out
of each NOC, with prepending on the advertisements that are
not for that specific NOC, (the 4th being the aggregated /20)

If the rest of the world starts filtering out his RIR-assignment
size, then won't his load balancing go right out the window?

Ted