[arin-ppml] ARIN-prop-167 Removal of Renumbering Requirement for Small Multihomers

[Owen DeLong]

On May 3, 2012, at 8:12 AM, William Herrin wrote:

> On 5/2/12, Owen DeLong <owen at delong.com> wrote:
>> OTOH, anyone can now buy as many /24s on the transfer market as they can
>> justify, even one /24 at a time (we got rid of the single aggregate
>> provision in the transfer policy), so, if you want to worry about nibbling
>> away at the routing table, let's focus on the potential for problems there,
>> rather than in this piddling little policy.
> 
> Hi Owen,
> 
> 8.3 today says "can demonstrate the need for such resources in the
> amount which they can justify under current ARIN policies." There are
> changes to that already in the pipeline, yes? Yet the policy -today-
> (if the implementation matches the words) would seem to be that
> section 4 requirements apply to 8.3 transfers as well.
> 

Only with respect to amount.

That's a key difference.

If I can justify a /16 under section 4, ARIN will issue a /16, or, if they cannot,
offer me the choice between the largest block they can issue or a slot in
the waiting list (see waiting list policy adopted about a year ago).

Under 8.3, if I can justify a /16, since we removed the "as a single aggregate"
clause from 8.3 (and unfortunately due to an error in positioning, even before),
ARIN will approve an 8.3 transfer whether that /16 worth of space comes from
a single /16, 16 /20s, or 256 /24s or any other combination of /24s and larger
that make up that amount of space. This is current operational practice as
implemented by ARIN. One need look no further than the Nortel->Micr0$0ft
transaction to see clear evidence of this.

> On Thu, May 3, 2012 at 2:58 AM, Owen DeLong <owen at delong.com> wrote:
>> In fact, the current way for an organization that has a /24 and
>> doesn't want to renumber to get to having 2 /24s worth of space
>> is quite simple. Entity A creates corporation B and multihomes
>> corporation B.
> 
> This sort of process is my standing recommendation to my large end
> user customers. At the /22 level even before the current /24 policy.
> 
Meh.

> With large end users, one often finds that the central IT organization
> is completely hopeless. It's routinely picked clean of anyone talented
> enough to support a paying product, leaving it a bastion of
> mediocrity. Even where not hopeless, central IT is rarely structured
> in a way capable of facilitating a particular product group's need for
> ARIN resources.
> 

Sounds like a radically different form of internal problem.

It has not been my experience in dealing with several large end user
organizations that this always holds true, but, I would agree it is not
uncommon.

However, I'm not sure it's relevant to the debate on this proposal.

Owen