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

[Chris Grundemann]

On Fri, Nov 6, 2009 at 18:42, James Hess <mysidia at gmail.com> wrote:
> 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..

Under the current requirements, they would not be eligible to receive
an initial allocation at all.

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

Under this proposal, if you are an ISP and you have utilized a /24
equivalent of space, you can get an initial allocation of a /23.
Later, if you need (and can justify) more space, you are given a
replacement initial allocation.  This is in contrast to an
_additional_ allocation.  You are required to return the original
allocation in exchange for a larger allocation - it is a replacement,
hence the wording in the proposal text.

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

Understood, this is why we very deliberately included the line "When
prefixes are assigned which are longer than /20, they will be from a
block reserved for that purpose whenever that is feasible."  This way,
you only need to adjust your filters for a given block, not across the
board.

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

This has been discussed at length (both on this list and elsewhere)
and it appears that everyone who filters at anything larger than the
/24 boundary understands that they must include some form of a default
route when doing so.  Even in PA space, there is no guarantee that the
upstream provider is announcing a covering aggregate.  Should they be?
Yes, but no one with any clue is going to bet their customer's
connectivity on that - with or without this proposal.

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

This is already true for multihomers with /22s and the critical
infrastructure or legacy blocks which go down to /24.

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

Again, this proposal requires that all allocations smaller than /20 be
from a dedicated block (as long as that is possible) so that you can
adjust such filters accordingly.  Also, if you are not using the whole
table, you probably need a default (or perhaps a process by which you
determine which routes have covering aggregates and which do not).

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

I agree - with or without this proposal, it is hard to find a likely
scenario where the cost to everyone with regard to the routing table
ever becomes less than it is now.  Also, allowing a new class of
organizations access to direct allocations will likely increase the
consumption of routing table slots at least a little bit.  The real
question is: In comparison with all of the other things (policy and
otherwise) that are bloating the table, is this a worthy purpose for
adding a few more entries?

~Chris

>
> --
> -J
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.
>





-- 
@ChrisGrundemann
weblog.chrisgrundemann.com
www.burningwiththebush.com
www.coisoc.org