
<html><head><meta http-equiv="content-type" content="text/html; charset=UTF-8"/></head><body style="overflow-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;">Matt,<div><br/></div><div><div><div><div>On Aug 14, 2024, at 6:08 PM, Matt Erculiani <merculiani@gmail.com> wrote:</div></div><blockquote type="cite"><div dir="auto">> <span style="font-family: -apple-system, helveticaneue; border-color: rgb(0, 0, 0);">You might want to look at RFC 7020, section 2.2.</span></div><div dir="auto"><br/></div><div dir="auto">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).</div><div dir="auto"><br/></div><div dir="auto">Perhaps that was not the authors’ intent? I know for sure at least half of them are here ;)<br/></div></blockquote><div><br/></div>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.</div><div><br/></div><div>Regards,</div><div>-drc</div><div><br id="lineBreakAtBeginningOfMessage"/><div><br/><blockquote type="cite"></blockquote></div></div><br/></div></body></html>