Matt, On Aug 14, 2024, at 6:08 PM, Matt Erculiani <[email protected]> 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
signature.asc
Description: OpenPGP digital signature
_______________________________________________ ARIN-PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List ([email protected]). Unsubscribe or manage your mailing list subscription at: https://lists.arin.net/mailman/listinfo/arin-ppml Please contact [email protected] if you experience any issues.
