BCP for multisite multihoming

[Iljitsch van Beijnum]

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.