[routing-wg] IPv6 Routing Recommendations

On Tue, 27 Apr 2010, João Damas wrote:

> the idea here is twofold:
> 1) to take routing policy out of addressing policy. That part was done

This strikes me as a bad idea. If you can't aggregate a set of addresses 
into a single announcement, then the best way to keep the number of 
prefixes in the global tables down is to have people get another block. 
That way you can have a strict filtering policy, and noone tries to get 
away with deaggregation because:

i) It won't work
ii) It isn't needed


This is a little extra work for the RIRs - each new non aggregatable block 
needs another resource request, but it means that we avoid the mess that 
we've already got in IPv4 where things tend to work as /24s anywhere, so 
why bother aggregating beyond that.


In other words, if an organisation can't announce its address space in a 
single aggregatable block, then give it multiple blocks - a new block for 
each disconnected network, rather than force it to deaggregate the block 
and announce it in little pieces (and thus opening the door for everyone 
to deaggregate their blocks unnecessarily).



> 2) make people aware that while de-aggregation is possible, it has its 
> costs, for everyone, not just the de-aggregator, and therefore one 
> should think a bit before splitting an allocation down into atoms.

The problem is not that organisation don't know, it's that they don't 
care, and there's little reason for them to care! If someone were to 
deaggregate a /32 into 256 /40s, it doesn't cost them - it costs everyone 
else. It costs in router FIBs, RAM, and convergence time. Does their 
deaggreation harm themselves specifically? As long as it seems to work, 
no.

Making people aware it has costs (for everyone else) doesn't stop it 
happening. Having a recommendation paper isn't going to be enough - it 
didn't work for IPv4, there's no reason to expect it will work for IPv6. 
It's also solvable fairly easily as described above.

What we do now (potentially opening the door for orders of magnitude of 
deaggregation) could have rather large consequences in future - even if 
RAM, TCAM, FIB, etc are orders of magnitude larger in future, convergence 
time is still increased proportionally (or worse?).



Regards
James