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

[Scott Leibrand]

Ted Mittelstaedt wrote:
>
> 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)
>   

Good.  With those advertisements, he only needs to do a couple more 
things: make sure that his transit providers not only accept all those 
routes from him, but also accept them from each other, and announce a 
peer-level localpref community on the backup routes (in addition to the 
prepending).  That way, the backup link will be truly backup, and will 
not receive inbound traffic from singly-homed downstream customers of 
that transit provider.  (All the NSPs we work with offer some form of 
low-localpref community, and this is a routine current practice by our 
multihomed customers.)

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

Not if you do peer-level localpref communities on the backup 
announcements.  That way, if I'm a third party network filtering at 
RIR-assignment size, and I prefer transit provider 1 (like everyone 
else), then my packets hit that transit provider, then get immediately 
sent across the closest peering link to the preferred transit provider.  
Not completely optimal, but it preserves the ISP's ability to do inbound 
TE, while providing a safety valve to filter deaggregates where 
necessary without losing reachability.  Again, I'm not advocating anyone 
start filtering just yet, but I think we need to design our policies to 
ensure we don't block the safety valve.


-Scott