[address-policy-wg] Re: 2009-06 New Policy Proposal (Removing Routing Requirements from the IPv6 Address Allocation Policy)

> On Tue, May 26, 2009 at 04:30:34PM +0200, Filiz Yilmaz wrote:
>> PDP Number: 2009-06
>> Removing Routing Requirements from the IPv6 Address Allocation Policy
>>
>>     http://www.ripe.net/ripe/policies/proposals/2009-06.html

I partially agree, but with comments.

True, it does not relate directly to address allocation, but it does
relate to the number of routing entries that will appear in the routing
tables.

More importantly why are we calling those prefixes then "Provider
Aggregated"? If they are not aggregated anymore by the above change?

Simple example: if 1000 ISPs will take their /32 and announce their
65536 more specifics out of that then we will have 655.360.000 routes.

That is something that a lot of hardware vendors and of course the large
networks will love to see.

The ones who will hurt by this will be the small ISPs who will want to
de-aggregate, not the big fishes who are able to do whatever they want
anyway and buy bigger boxes to handle larger routing tables.

Filtering happens anyway, so a /32 will most likely be the minimum space
in the PA range that one can announce anyway, which does mean that an
ISP with a /20 could split it up into /32's.


Thus, indeed having the text about what to announce and not to announce
in the Allocation Policy is not required, especially as it is covered in
other documents, but having maybe at least a pointer to those documents
might be a good idea.

To twist this in another way: could there be added a requirement that
prefixes are properly registered in RPSL? That would help ISPs decide
which prefixes should be there and how to filter, with maybe having
exclusions.

Greets,
 Jeroen

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 187 bytes
Desc: OpenPGP digital signature
URL: </ripe/mail/archives/address-policy-wg/attachments/20090527/6d3c6630/attachment.sig>