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

Tue Oct 27 14:34:47 EDT 2009

On Oct 27, 2009, at 9:11 AM, Ted Mittelstaedt wrote:

>
> 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:
>
The title will be changed, as I already stated.

> "...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.
>
The first phrase is verbatim from the existing policy allowing for
assignments to be made down to /22.  The "So long as it is feasible"
refers to the fact that if ARIN runs out of space in this block, we  
don't
want them to be unable to assign these addresses while there is
still space in the block previously reserved for /20 and shorter
assignments.

> 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.
>
No, we're mandating it as long as it can be maintained.  I have reason
to believe that ARIN staff is quite clear on the meaning of this and  
their
obligations as a result.  It doesn't let ARIN off the hook until such  
time
as they have no space to assign from this separate block and must
issue the space from the few remaining blocks which contain some
/20 and shorter issuances.

> 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.
>
Agreed, but, that's not the case here.

> 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)
>
This issue is, actually being worked on and I think we will see
cooperation from staff going forward.

> 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.
>
Tell you what... Let's wait for the staff and legal assessment on
this one.  If staff doesn't clearly state what they accept the phrase
to mean along the lines I just specified above, I'll update with
clarifying language.  However, I think it is pretty clear as it stands
and believe that more verbiage to explain the meaning of the
term feasible in this context would simply be superfluous.

Owen

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2105 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20091027/3d400a47/attachment.p7s>