[arin-ppml] ARIN-prop-153 Correct erroneous syntax in NRPM 8.3

[Owen DeLong]

On May 31, 2011, at 9:26 AM, Matthew Kaufman wrote:

> On 5/31/2011 12:11 AM, Owen DeLong wrote:
>> I think we kind of have to accept that circumstance because it has little differentiation from
>> when ARIN subdivides address space the same way.
>> 
> 
> But ARIN was previously able to subdivide space in a way that allows for growth without increasing table size, and at a fairly known rate, and with a finite limit imposed by the free pool size.
> 

This required having the ability to do somewhat sparse allocations. A transfer market has no
such ability. There is no possibility of reserving adjacent free blocks in a transfer market.

> If the goal is to prevent the BGP table size from growing too quickly, or causing it to grow in a predictable way, then we should come up with policies that reduce disaggregation at the source, no matter who the recipients are.
> 

The recipients are the source of the disaggregation. The source of the addresses are not
the actual source of the disaggregation.

> If breaking up every block into /24-sized pieces is acceptable if the recipients are all different, then the table size is no different than if the recipients are all the same... and so there's no real win on table size, instead we simply make things overly complicated for the buyer for no benefit.
> 

While this is true, there is no possibility to serve the 65,536 disparate organizations
(which is also an unlikely corner case to begin with) with a single aggregate, while
a single organization which needs a /8 can be served with a /8 and does not need
to occupy 65,536 slots in the routing table.

While it is possible to create theoretical scenarios where there is no effect on table
size, in the real world, the effect is actually significant and there is a real win on
table size. As such, yes, things get a little bit more complex (not much, frankly),
but there is significant benefit.

Owen