[arin-ppml] Proposal 99 -- IPv4 multihomed end-user minimum to /24

[Ted Mittelstaedt]

Sorry for the top post, I also agree the title needs to be
changed to assignment.  While I have no problem with the
idea of the proposal I do have a concern about this sentence:

"...When prefixes are assigned which are longer than /20, they will be 
from a block reserved for that purpose so long as that is feasible..."

To me, this sentence is basically deadweight.  The first part of it
mandates use of a special block reserved for this purpose (what makes 
that block special is not defined) then the second part of it lets
ARIN staff off the hook since there is no definition of what
constitutes feasibility.

It seems your trying to kill 2 birds with one stone - you want to
reduce fragmentation by making the less-than-/20 crowd renumber
and return (which is a goal I agree with, as renumbering a couple
/24's over a year's time should not be a problem) and you want
to push the small block holders into a "neighborhood" of other
small block holders - yet your not mandating this, your just kind
of "encouraging" it.

Stuff that doesn't mandate the ARIN staff to follow a particular
set of rules is a distraction, may cause some people who would
support the proposal to oppose it, and in the event that the
proposal gets accepted, the ARIN staffers may end up stumbling
over the thinly-defined section of the policy.

At the risk of beating a dead horse, look at the WHOIS POC cleanup -
that was deliberately written with a vague section because the
concern was that a more explicit definition would tie ARIN staff's
hands - yet instead of being happy about that, and using the
freedom to overcome implementation roadblocks on the cleanup -
ARIN staff pushed back, wanting to delay implementation, saying they had 
a problem implementing that section. :-(  (Kind of a damned if you
do, damned if you don't issue)

Anyway, I think you ought to either strike that sentence entirely
or add more sentences that more clearly define what it is that
your getting at.

Ted

Owen DeLong wrote:
> The following proposal has been sent to PPML before.  It is now on the 
> AC docket.  There
> was, unfortunately, insufficient time to get it to the Dearborn meeting 
> for adoption discussion
> outside of the petition process.
> 
> At this time, I would like to solicit any additional community feedback 
> regarding changes that
> should be made to the proposal before asking the AC to place it on the 
> next meeting agenda
> for adoption discussion.
> 
> Thanks,
> 
> Owen
> 
> 
>>/ TEMPLATE: ARIN-POLICY-PROPOSAL-TEMPLATE-2.0
> />/
> />/ 1.      Policy Proposal Name: /24 End User Minimum Allocation Unit
> />/ 2.      Proposal Originator: Owen DeLong
> />/     
> />/
> />/ 3.      Proposal Version: 0.9
> />/ 4.      Date: 8/3/09
> />/ 5.      Proposal type: new
> />/ 6.      Policy term: permanent
> />/ 7.      Policy statement:
> />/
> />/ Replace section 4.3.2.2 of the NRPM with the following:
> />/
> />/ 4.3.2.2 Multihomed Connection
> />/
> />/ For end-users who demonstrate an intent to announce the requested space in a
> />/ multihomed fashion to two or more distinct providers, the minimum block of IP
> />/ address space assigned is a /24. If assignments smaller than a /24 are needed,
> />/ multihomed end-users should contact their upstream providers. When prefixes are
> />/ assigned which are longer than /20, they will be from a block reserved for that
> />/ purpose so long as that is feasible. End-users may not receive a block 
> />/ smaller
> />/ than /22 under this policy if they already have resources from ARIN, 
> />/ except as
> />/ specified in section 4.3.6.2.
> />/
> />/ Renumber the existing paragraph under the 4.3.6 to 
> />/
> />/ 4.3.6.1 Utilization requirements for additional Assignment
> />/
> />/ Add the following paragraph 4.3.6.2
> />/
> />/ 4.3.6.2 Replacement assignments for small multi-homers
> />/
> />/ Any end-user that possesses an assignment smaller than /22 under any 
> />/ part of
> />/ section 4.3 shall not be able to get an additional assignment unless 
> />/ they agree
> />/ to return all existing assignments within 12 months of receiving a new 
> />/ assignment.
> />/ The new assignment shall be sized to accommodate their existing 
> />/ utilization in
> />/ addition to their justified additional growth space under section 4.3.6.1.
> />/ The common cases for this are expected to be a /24 returned after 
> />/ receipt of a /23,
> />/ or a /23 returned after receipt of a /22.
> />/
> />/ 8.      Rationale:
> />/
> />/ This policy attempts to incorporate the recent and historical discussions of
> />/ policy for multi-home users on PPML. The intent is to provide as fair a process
> />/ as possible for multi-homed organizations down to the smallest feasible size
> />/ while still preserving some control over growth in the routing table.
> />/
> />/ It has been repeatedly noted that /24 multi-homers exist today with PA space
> />/ and still occupy a routing table slot, so, it is unlikely that moving this
> />/ boundary to /24 would significantly impact the routing table.
> />/
> />/ By requiring smaller assignments to renumber and return, rather than add more
> />/ small blocks to their assignments, this policy seeks to further reduce the
> />/ chances of unnecessary growth in the routing table and encourage good aggregation
> />/ where possible.
> />/
> />/ 9.      Timetable for implementation: Immediate
> />/
> />/ END OF TEMPLATE
> />
> 
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> 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.