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

[Matthew Kaufman]

On 5/31/2011 10:09 AM, Owen DeLong wrote:
> 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.
>

Exactly. So it is entirely different than when ARIN subdivides address 
space.

>> 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.
>

The recipients are the source of deaggregated routing table 
announcement. The source of the addresses being allowed to disaggregate 
their assignments is the original source of them problem you're seeking 
to fix.

>> 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

But there's also no need to do so. Perhaps this space is simply unusable 
for a time.

ALL restrictions that prevent what you seek to prevent (Org A fulfilling 
Org B's need for a /22 by giving them 4 disjoint /24s from the same 
block) *also* prevent maximal utilization of unused space.

Back to my original point, the right answer is somewhere between "all 
blocks may be broken up into /24-sized pieces" and "all blocks must not 
be broken up any further than the original ARIN allocation size"... and 
that's the *only* way to prevent table growth, as *who* gets the blocks 
is completely irrelevant for that point.

Org A fulfilling Org B's need for a /22 by giving them 4 disjoint /24s 
is *exactly* as bad for the router memory as Org A fulfilling org B, C, 
D, and Es needs for /24s with 4 disjoint /24s and so if the goal is to 
keep the table smaller, the policy *should not* differentiate between 
these cases.

Matthew Kaufman