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

[Owen DeLong]

On Jun 1, 2011, at 11:59 PM, Benson Schliesser wrote:

> Hi, Bill.
> 
> On May 31, 2011, at 12:18 PM, William Herrin wrote:
> 
>> If that's the consensus goal then put together some verbiage for 8.3
>> that hits these five points:
>> 
>> a. Any registrant may offer an entire ARIN IPv4 address block
>> registration for transfer without restriction.
>> 
>> b. Any registrant may offer part of an ARIN IPv4 address block
>> registration with a prefix no longer than /24 for transfer. /8 through
>> /24 allowed, /25 through /32 prohibited.
>> 
>> c. Transfers under 8.3 are only received as fulfillment of an ordinary
>> section 4 request following all ordinary policies and procedures under
>> section 4. To the extent that turns out to obstruct reasonable
>> behavior, we'll fix it in section 4.
>> 
>> d. Any registrant may receive any number of address blocks from (a) as
>> needed to fulfill their ARIN-approved section 4 request.
>> 
>> e. Any registrant may receive no more than $N discontiguous address
>> blocks per $UNIT_TIME from (b) as needed to fulfill their approved
>> section 4 request. So if you buy a partial fill, shop wisely.
> 
> It seems to me that disaggregation in the routing table will be dominated by the source of an address block rather than a recipient.  If somebody disaggregates a very large block, in order to parcel it out or because they can only spare a part of it, then multiple new routes will appear from the original source even if the new recipient only announces a single route.  For example, if I have a /16 announcement in BGP today and I want to sell a /19, then I have to start announcing a /17, /18, and /19 to cover the retained space - while my buyer starts announcing a /19 prefix that I transfer to him.  That results in 4 routes in BGP where there used to be 1.
> 
There are two possibilities...

1: The source wants to disaggregate it because they don't want to renumber to aggregate their available space.

I agree this should be avoided to the extent possible.

2: The recipient wants to purchase smaller disjoint blocks because:
	a)	They are cheaper
	b)	They can find sources for them sooner
	c)	They are otherwise easier to come by than a full aggregate

In the case of 1, this can be prevented by restricting transactions to a single aggregate and restricting any given
recipient to one sub-aggregate transfer per n-unit of time (currently proposed at 1 year).

Disaggregation outside of the aspects covered by that provision would be the result of dividing the address space
up to multiple organizations with smaller needs and would be akin to the deaggregation that ARIN does when issuing
new space. While I think it would be better to preserve aggregates, the consensus of the community as we were
developing the current 8.3 was that doing so would be overly restrictive, so, in this respect, I bow to the will of the
majority and am attempting to preserve this capability.

Quite frankly, if you sell a /19, you really don't have to announce the /17, /18, and /19. You could just continue to
announce the /16 knowing that the recipient's /19 would override your /16 announcement.

There is little or no benefit to you announcing the /17, /18, and /19 instead of the /16.

> Clearly, limiting what people can receive will have an effect on disaggregation - reducing the number of blocks allowed per-recipient-per-time-period will encourage buyers to acquire as much as they can afford as a single block, rather than many small blocks over time.  That's good.  But just as disaggregation occurs today at the "whim" of the announcing AS, it will continue to do so under the regime described above.
> 

I think this is somewhat inevitable and not really an address policy matter.

> ARIN could attempt to limit this by only accepting disaggregation in Whois by +N (e.g. +1 or +2) bits of prefix-length per year.  Of course, that means holders of very large blocks will have a hard time selling their unused space - they may need to disaggregate by larger values of N in order to meet demand under a "justified need" regime - so some kind of sliding scale might be useful, based on original block size.  Otherwise, for a uniform value of N this policy would limit the supply of address blocks (and probably drive up prices).
> 

We have long since examined the idea of fixed values of N per unit time deaggregation as you propose above and determined that it was beyond
dysfunctional. As such, I think that rehashing it here really isn't worth while. I realize this discussion occurred before you were active on PPML,
but, if you want to review it, I suggest reviewing the archives for 2008-2, 2008-15, and 2009-1.

> I'm personally inclined to view this (+N idea) as market distorting, and probably ineffective since ARIN doesn't control BGP anyways. But I offer it for your consideration, regardless.
> 

Understood, and, in this case, I actually agree with you.

Owen