[arin-ppml] Policy Proposal 102: Reduce and Simplify IPv4 Initial Allocations

James Hess mysidia at gmail.com
Fri Nov 6 20:42:22 EST 2009


I  find myself  undecided  in regards to this proposal at the present
time,  with regards to  support/oppose...


On Fri, Nov 6, 2009 at 2:58 PM, Ted Mittelstaedt <tedm at ipinc.net> wrote:
> William Herrin wrote:
>> On Thu, Nov 5, 2009 at 1:46 PM, Member Services <info at arin.net> wrote:
> Under this proposal they qualify for what might be termed a
> "temporary" allocation.  If they never grow, they never renumber.

Then it's not temporary at all..  it's more like a provisional allocation.

> If they grow, they renumber into a larger allocation that reduces
> the burden of carrying their routes - same as the current requirements.

Under the current requirements, they might  choose not to renumber..

> Thus they are not really "Initial requesters"   However, since
> they are getting their first allocation, they ARE "Initial
> requesters" - from a certain point of view.

Um..  they can't be both  "not really 'Initial requestors'" and
Initial requestors at the same time...

It's a  confusing  and contrived thing to suggest  "initial allocation"
is anything other than the very first allocation they get.


> Your making a claim here that the simple property of
> being multihomed somehow acts as a deterrent to an org for
> subnetting, and splitting their advertisements, thus
> creating new overhead cost for everyone else.

The cost is not based solely on whether they subnet or not,  it's also
based on whether other providers   can effectively  filter  the
additional noise out.

A small ISP gets IPs from upstream providers out of PA blocks from
which ARIN  allocates  prefixes   no longer than  /20.

Providers who need table size reduction to avoid increased cost may
have that  option of filtering, discarding announcements with prefixes
 longer than /20,  rely on the  non-customer's  ISP's  covering route
to provide connectivity.

For the  blocks  ARIN assigns /22s  from,  for multi-homed users,
/22s  definitely  need be accepted  or  connectivity would be quite
broken.

If  ARIN  were to   allocate  smaller blocks such as /23,  these could
not be filtered, since there is no upstream provider  announcing an
overall /20 PA  that contains the /23.

The smaller an allocation ARIN makes  from any  given  block,  the
less effective that an aggressive filtering  strategy could  be.


When  single-homed  ISPs  get a /23  from  an   upstream provider  the
DFZ   _MIGHT_   see      1 additional /23  and 2  additional  /24s
being broadcast, for a total of  3 new table entries,     but then
again they might not..   the single-homed ISP   may not announce a
thing...

When  single-homed ISPs  get a /23  from ARIN,  you can be  assured,
almost  guaranteed   an additional  /23  appearing,   and  2
additional /24s   getting announced cannot be ruled out.


It seems like a plausible scenario,  that the costs  to others would
be much greater,   in the scenario  where  ARIN  allocates   a
significant number of  /23s  to single-homed providers.

I  couldn't  think of any plausible scenario  where the costs to
others would be less or the same,  if single-homed entities  are
allowed to  receive  small   direct allocations.


--
-J



More information about the ARIN-PPML mailing list