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

[Owen DeLong]

On May 31, 2011, at 10:30 AM, Matthew Kaufman wrote:

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

No, it is somewhat different because the available space limitations create additional constraints.

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

This can be argued either way. In fact, both sides have a contributory role and responsibility.

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

I disagree. I believe that maximal use of address space can still be achieved under the
proposed changes to 8.3. However, I agree that it might make some changes as to
which parties are performing that utilization. Overall, I don't see this as a significant
problem.

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

Yes and no. The right answer is to allow transfers that disaggregate only to the
extent absolutely necessary to meet a given recipient's need. If they need
a /20, then, transferring a /20 is vastly preferable to
transferring 16 disjoint /24s. On the other hand, 16 organizations, each of
whom need a /24 have no better solution than to transfer 16 /24s, whether
they come from the same source or not.

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

While it is equally bad for router memory, the latter case is inevitable if the /24 needs of {B,C,D,E} are to be met, while meeting the /22 need of B can be accomplished without this impact. As such, allowing Org B to transfer 4 disjoint /24s rather than seek a /22, even if it costs them more per address or takes them longer has a negative impact on the rest of the community.

Owen