[arin-ppml] ARIN-prop-153 Correct erroneous syntax in NRPM 8.3
matthew at matthew.at
Tue May 31 13:30:25 EDT 2011
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
>> 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
>> 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
More information about the ARIN-PPML