[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: BCP for multisite multihoming

On 23-mei-2007, at 13:47, Gert Doering wrote:


considering that there are 1.4 million businesses in the
Netherlands alone, I'm thinking we can screw this up if we try hard
enough and take enough time to do it.



You missed my point.  My point wasn't "we can afford to give anyone
that comes a /32" - it was "for the number of routes that we can afford, it doesn't make a (big) difference whether it's a /32 or a /40, because 
this is not going to use up all the available space anyway".


Ok.
Wouldn't it suck, though, if through some herculian effort, we'd be able to make routing scale, and then we run out of address space? 


A good filter catches
everything that's in the routing table by mistake, and allows
everything that's in there by design.
A *good* filter is one that permits exactly what is supposed to be there 
(as documented in a routing registry) and nothing else.


That is one thing that you may want to design your filter for, yes.


1. PA assignments are (often) /48s, same thing for PI blocks, so it's
not possible to see the difference between leaked PA deaggregates and PI 


Indeed it is, as the RIRs take good care to set aside specific blocks
for special-case prefixes (PI, IXP, ...). It's a bit time- consuming to 
always figure out which block is what, but it can be done.
True. But being able to reject leaked PA without having to hunt for special case blocks on the various RIR sites would be better. 


Indeed.  If one assumes that those enterprise have nothing better to
do than to deaggregate to /32s.
Experience with IPv4 shows that some people indeed do this. And if you have a /21 for world-wide use, do you really want to receive your traffic for Nigeria in Hong Kong? Or would you want to advertise more specifics in various locations? 


1. Make PI blocks a different size than PA end-user assignments. /44
makes sense, this is a good deal bigger than /48 so even fewer people
are going to need more and it's on a nibble boundary for easy DNS
delegation and no need to reserve for growth. Filtering could happen
on /47 which rejects leaked /48s but allows 3 bits for traffic
engineering
See my comment to "1." above - this is a solution in search of a problem :-) 

This would also help with PA multihoming.
Doing this has another drawback: it makes PI more attractive to end sites 
than PA ("I can get a bigger address block with PI!!!")
As if you can't get more than a /48 from an ISP... I currently have a /48 for use at home and another /48 for my colocated server. 


2. Make all allocations from a given block of address space the same
size, so there would be ranges for /32s allocations, for /28
allocations, /44 assignments, etc.
Given the sheer and overwhelming amount of bigger-than-/32 allocations, 
filtering these ranges explicitely is not a seriously big deal.


At least keeping the bigger blocks out of the /32 pool would be a start.