BCP for multisite multihoming

[Brandon Butterworth]

> >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?

Filtering sucks, people get it wrong or obsolete it. The only
safe filtering (?) is to make it static or simply deterministic,
i.e you know what it should be such as /32 for everywhere.

If we have random allocation sizes someone will always get it wrong
or have an excuse to deaggregate "some ISPs do longer so we have to
deagg to at least that so people don't announce more specifics and
break our services". I'm guessing deagg will eat more space than
people multihoming (if all the /32's felt they had to advertise /48s)

At least if everyone filters to /32 by default that's one less
source of polution and risk

> >>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.

That's a good plan too. Three classes (heh) big, medium, small

If they grow they will try and get extra space rather than move
to a larger class, when that happens we'll be back on the slope
of table growth

> >>Filtering could happen
> >>on /47 which rejects leaked /48s but allows 3 bits for traffic
> >>engineering

Given the size of v6 space and the pressure on routing tables
that any deagg would cause is it really a sensible TE solution
where everyone may pay a huge price? Perhaps some other mechanism
would be better used and have no deagg. Have a simple known filter size
and anything unusual be a new prefix as overall a few extra is
way less than lots of deagg as you only get the extra prefixes
needed rather than all the consequentials of deagg  (rambling here)

brandon