[arin-ppml] ARIN-2023-8 - Reduce 4.1.8 Maximum Allocation

[David Conrad]

Matt,

On Aug 14, 2024, at 6:08 PM, Matt Erculiani <merculiani at gmail.com> wrote:
> > You might want to look at RFC 7020, section 2.2.
> 
> I think the use of the phrase “permits aggregation” is key there. Aggregation is a consideration, not a requirement. An example being don’t satisfy someone asking for a /19 with 4x/21s when you could break up a /18 instead. The goal in RFC 7020-2.2 appears to be “don’t *unnecessarily* contribute to increasing table size”, not “make table size a reason for prohibiting very small allocations” which was really the point I was refuting (perhaps too tersely).
> 
> Perhaps that was not the authors’ intent? I know for sure at least half of them are here ;)

I cannot speak for the other authors of 7020, but in my case I can state fairly authoritatively that one of the goals of address allocation policy as implemented by the RIRs was indeed to minimize the impact of allocations on the (concept of the) global routing table and part of the reason for this was that, in their history, some RIRs allocated longer than /24 (IPv4) and the community of the time felt (appropriately, IMHO) this was a bad idea.

Regards,
-drc



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20240815/eaaa1b18/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 249 bytes
Desc: OpenPGP digital signature
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20240815/eaaa1b18/attachment.sig>