[address-policy-wg] getting second IPv6 PA as a LIR

On 05/04/2011 10:25 AM, poty at iiat.ru wrote:
> When we add several hundred thousands IPV6 routes we are going to
> extremely upgrades our infrastructure, but smaller ISP (business...)
> which can't pay $100/month will not be able to do so definitely.

> You know - they are different. :) Mostly they have distributed computing
> environment and hardware programmed to do specific operations, huge
> backbones and many-many other things which PC lacks.

Not really. BGP table calculation isn't distributed (you need single
place for this calculation final table). If we imagine your hundred
thousands IPV6 routes scenario, CPU on these "hardware" routers will
have troubles, too.

> The widespread PI will definitely adds significant amount to the number
> of routes, so your forwarding problem will be much worse.

Deaggregation of PA address space causes similar problems and nobody
really can do anything with this. And routers aren't making difference
between PI and PA. Look into IPv4 routing table, what mess is here
caused not by PI assignments, but by announced /24 from aggregatable
/20, /19, from PA blocks... same thing is already happening in IPv6,
where're more specifics than /32 announced from PA blocks.

With blocking PI you cause only one thing - people will start
deaggregation of PA space more widely. And any kind of (RIPE) policy
cannot forbid this. For each restriction in RIPE policy people discover
some policy-conforming workaround...

PI vs PA separation is just administrative thing for RIPE NCC evidence.
It's impossible to force network operators filter some prefixes, just
because prefix is deaggregated. You can filter in your own network, but
probably nobody will filter his paying customer - money are on the first
place...

With regards,
Daniel