[c-nsp] smaller PI

[Łukasz Bromirski]

On 2010-07-01 20:38, Matthias Müller wrote:

>>> I do not expect this hardware to handle 524k prefixes.
>> Why? First of all, if You're not handling IP multicasts and IPv6 that
>> much, repartition when the 330k IPv4 becomes 500k IPv4.
> Excluding IPv6 routes is a really bad idea while talking about
 > accepting prefixes beyond /24. Getting smaller subnets for PI is a
 > direct result of IPv4 space exhausting, so telling someone to
 > forget about IPv6 routes and simply shift all space for IPv4 routing
 > is imho a bad advice.

First of all, you actually can't "forget about IPv6 routes" in
PFC3, and I didn't meant to exclude IPv6 totally. If indeed there's
trouble with the fact that todays 330k IPv4 prefixes may become 400k
tommorow, I'd go for dropping the limit for IPv6/multicast down to
something around 50-100k and configure maximum-routes to defend the
PFCs before overflowing them.

>> Filtring on minimal RIR allocations is fine, but again, with this
>> hardware, you're yet to reach its limits.
> I'd expect a lot of providers to drop routes with /25 or even /24
 > even more in the future after IPv6 is a must have and not a nice
 > to have, because they'll adjust fib space to include more IPv6
 > routes without upgrading the existing hardware.

Sure. But going back too much in terms of filtering, and dropping more
that it says in RIR allocation rules may get you in trouble, or
more precisely, suboptimal/more expensive routes for traffic.

-- 
"Everything will be okay in the end.  |                 Łukasz Bromirski
  If it's not okay, it's not the end." |      http://lukasz.bromirski.net