I support this as well.
Steven Ryerse
President
100 Ashford Center North, Suite 110, Atlanta, GA 30338
770.656.1460 - Cell
770.399.9099- Office
[Description: Description: Eclipse Networks Logo_small.png]℠ Eclipse Networks,
Inc.
Conquering Complex Networks℠
From: [email protected] [mailto:[email protected]] On Behalf
Of Rudolph Daniel
Sent: Tuesday, December 2, 2014 7:03 AM
To: [email protected]
Subject: Re: [arin-ppml] 2014:21.CI pool size
I Support this CI pool size increase.
Rudi Daniel
784 430 9235
On Dec 1, 2014 8:09 PM,
<[email protected]<mailto:[email protected]>> wrote:
Send ARIN-PPML mailing list submissions to
[email protected]<mailto:[email protected]>
To subscribe or unsubscribe via the World Wide Web, visit
http://lists.arin.net/mailman/listinfo/arin-ppml
or, via email, send a message with subject or body 'help' to
[email protected]<mailto:[email protected]>
You can reach the person managing the list at
[email protected]<mailto:[email protected]>
When replying, please edit your Subject line so it is more specific
than "Re: Contents of ARIN-PPML digest..."
Today's Topics:
1. Advisory Council Meeting Results - November 2014 (ARIN)
2. Draft Policy ARIN-2014-21: Modification to CI Pool Size per
Section 4.4 (ARIN)
3. Draft Policy ARIN-2014-22: Removal of Minimum in Section 4.10
(ARIN)
4. Weekly posting summary for [email protected]<mailto:[email protected]> (Thomas
Narten)
5. Re: Multi-homing justification removed? (Owen DeLong)
----------------------------------------------------------------------
Message: 1
Date: Tue, 25 Nov 2014 15:34:58 -0500
From: ARIN <[email protected]<mailto:[email protected]>>
To: [email protected]<mailto:[email protected]>
Subject: [arin-ppml] Advisory Council Meeting Results - November 2014
Message-ID: <[email protected]<mailto:[email protected]>>
Content-Type: text/plain; charset=gbk; format=flowed
In accordance with the ARIN Policy Development Process (PDP), the ARIN
Advisory Council (AC) met on 20 November 2014.
The AC recommended the following to the ARIN Board for adoption:
Recommended Draft Policy ARIN-2014-9: Resolve Conflict Between RSA
and 8.2 Utilization Requirements
The AC accepted the following Proposals as a Draft Policies:
ARIN-prop-213 Modification to CI Pool Size per Section 4.4
ARIN-prop-214 Removal of Minimum in Section 4.10
The AC is continuing to work on the following:
Draft Policy ARIN-2014-1: Out of Region Use
Draft Policy ARIN-2014-6: Remove 7.1 [Maintaining IN-ADDRs]
Draft Policy ARIN-2014-14: Removing Needs Test from Small IPv4 Transfers
Draft Policy ARIN-2014-17: Change Utilization Requirements from
last-allocation to total-aggregate
Draft Policy ARIN-2014-19: New MDN Allocation Based on Past Utilization
Draft Policy and Proposal texts are available at:
https://www.arin.net/policy/proposals/index.html
The ARIN Policy Development Process can be found at:
https://www.arin.net/policy/pdp.html
Regards,
Communications and Member Services
American Registry for Internet Numbers (ARIN)
------------------------------
Message: 2
Date: Tue, 25 Nov 2014 15:35:15 -0500
From: ARIN <[email protected]<mailto:[email protected]>>
To: [email protected]<mailto:[email protected]>
Subject: [arin-ppml] Draft Policy ARIN-2014-21: Modification to CI
Pool Size per Section 4.4
Message-ID: <[email protected]<mailto:[email protected]>>
Content-Type: text/plain; charset=gbk; format=flowed
On 20 November 2014 the ARIN Advisory Council (AC) accepted
"ARIN-prop-213 Modification to CI Pool Size per Section 4.4" as a Draft
Policy.
Draft Policy ARIN-2014-21 is below and can be found at:
https://www.arin.net/policy/proposals/2014_21.html
You are encouraged to discuss the merits and your concerns of Draft
Policy 2014-21 on the Public Policy Mailing List.
The AC will evaluate the discussion in order to assess the conformance
of this draft policy with ARIN's Principles of Internet Number Resource
Policy as stated in the PDP. Specifically, these principles are:
* Enabling Fair and Impartial Number Resource Administration
* Technically Sound
* Supported by the Community
The ARIN Policy Development Process (PDP) can be found at:
https://www.arin.net/policy/pdp.html
Draft Policies and Proposals under discussion can be found at:
https://www.arin.net/policy/proposals/index.html
Regards,
Communications and Member Services
American Registry for Internet Numbers (ARIN)
## * ##
Draft Policy ARIN-2014-21
Modification to CI Pool Size per Section 4.4
Date: 25 November 2014
Problem Statement:
At the time that this section of policy was written, IXP growth in North
America was stagnant. Efforts of late have increased significantly
within the IXP standards and other communities to improve critical
infrastructure in North America. This effort is paying dividends and we
project that a /16 will not be enough to continue to improve global
interconnect conditions and support needed IXP CI infrastructure.
Policy statement:
Change to text in section 4.4 Micro Allocations:
Current text:
ARIN will place an equivalent of a /16 of IPv4 address space in a
reserve for Critical Infrastructure, as defined in section 4.4. If at
the end of the policy term there is unused address space remaining in
this pool, ARIN staff is authorized to utilize this space in a manner
consistent with community expectations.
Proposed text to replace current text entirely:
ARIN will place an equivalent of a /15 of IPv4 address space in a
reserve for Critical Infrastructure, as defined in section 4.4.
Timetable for implementation: Immediate
------------------------------
Message: 3
Date: Tue, 25 Nov 2014 15:35:29 -0500
From: ARIN <[email protected]<mailto:[email protected]>>
To: [email protected]<mailto:[email protected]>
Subject: [arin-ppml] Draft Policy ARIN-2014-22: Removal of Minimum in
Section 4.10
Message-ID: <[email protected]<mailto:[email protected]>>
Content-Type: text/plain; charset=gbk; format=flowed
On 20 November 2014 the ARIN Advisory Council (AC) accepted
"ARIN-prop-214 Removal of Minimum in Section 4.10" as a Draft Policy.
Draft Policy ARIN-2014-22 is below and can be found at:
https://www.arin.net/policy/proposals/2014_22.html
You are encouraged to discuss the merits and your concerns of Draft
Policy 2014-22 on the Public Policy Mailing List.
The AC will evaluate the discussion in order to assess the conformance
of this draft policy with ARIN's Principles of Internet Number Resource
Policy as stated in the PDP. Specifically, these principles are:
* Enabling Fair and Impartial Number Resource Administration
* Technically Sound
* Supported by the Community
The ARIN Policy Development Process (PDP) can be found at:
https://www.arin.net/policy/pdp.html
Draft Policies and Proposals under discussion can be found at:
https://www.arin.net/policy/proposals/index.html
Regards,
Communications and Member Services
American Registry for Internet Numbers (ARIN)
## * ##
Draft Policy ARIN-2014-22
Removal of Minimum in Section 4.10
Date: 25 November 2014
Problem Statement:
The current section 4.10 Dedicated IPv4 block to facilitate IPv6
Deployment creates an issue where a small new organization that requires
an IPv4 allocation or assignment would potentially receive a block that
today would be unroutable and therefore unusable for it intended purposes.
Policy statement:
Change
"This block will be subject to a minimum size allocation of /28 and a
maximum size allocation of /24. ARIN should use sparse allocation when
possible within that /10 block."
To
"This block will be subject to an allocation of /24. ARIN should use
sparse allocation when possible within that /10 block."
Timetable for implementation: Immediate
------------------------------
Message: 4
Date: Fri, 28 Nov 2014 00:53:04 -0500
From: Thomas Narten <[email protected]<mailto:[email protected]>>
To: [email protected]<mailto:[email protected]>
Subject: [arin-ppml] Weekly posting summary for
[email protected]<mailto:[email protected]>
Message-ID:
<[email protected]<mailto:[email protected]>>
Content-Type: text/plain; charset=us-ascii
Total of 5 messages in the last 7 days.
script run at: Fri Nov 28 00:53:03 EST 2014
Messages | Bytes | Who
--------+------+--------+----------+------------------------
60.00% | 3 | 55.51% | 18354 | [email protected]<mailto:[email protected]>
20.00% | 1 | 22.60% | 7473 |
[email protected]<mailto:[email protected]>
20.00% | 1 | 21.89% | 7240 | [email protected]<mailto:[email protected]>
--------+------+--------+----------+------------------------
100.00% | 5 |100.00% | 33067 | Total
------------------------------
Message: 5
Date: Mon, 1 Dec 2014 16:04:21 -0800
From: Owen DeLong <[email protected]<mailto:[email protected]>>
To: Scott Leibrand <[email protected]<mailto:[email protected]>>
Cc: "[email protected]<mailto:[email protected]>"
<[email protected]<mailto:[email protected]>>
Subject: Re: [arin-ppml] Multi-homing justification removed?
Message-ID:
<[email protected]<mailto:[email protected]>>
Content-Type: text/plain; charset="utf-8"
FWIW, Scott, your interpretation agrees with my recollection and my intents
along the way.
I am not convinced that such a policy applied to the transfer market is a good
idea. I believe that portable blocks place sufficient demand on internet
resources that having a some number of hosts behind them (50%+) is not an
unreasonable requirement regardless of whether the block is freshly minted from
the RIR or recycled.
Owen
> On Nov 20, 2014, at 9:42 AM, Scott Leibrand
> <[email protected]<mailto:[email protected]>> wrote:
>
> Steve,
>
> I think your interpretation of 4.3.2.2 is incorrect. That policy section was
> not the one that authorized the receipt of a (PA) /24 for multihoming. That
> was, and still is, 4.2.3.6 <http://4.2.3.6/>:
> https://www.arin.net/policy/nrpm.html#four236
> <https://www.arin.net/policy/nrpm.html#four236>, which states that "The ISP
> will then verify the customer's multihoming requirement and may assign the
> customer a /24, based on this policy."
>
> 4.3.2.2 states that the minimum allocation size (from ARIN) for multihomed
> end users was a /24. However, that did not allow you to get a /24 from ARIN
> just by becoming multihomed. If you were/are in that situation, you always
> had to (and still have to) get your /24 from your upstream if you don't meet
> ARIN's /24 utilizatinon criteria, and demonstrate efficient utilization
> before getting one from ARIN.
>
> If my understanding does not match how policy was implemented by staff prior
> to implementation of ARIN-2014-13 on 17 September 2014, someone please
> correct me, but that was the intent of the policy as I understand it.
>
> When discussing 2014-13, my sense of the community was that we did not want
> to authorize receipt of a /24 from ARIN solely based on multihoming, because
> that could possibly open up a land rush of organizations spun up solely for
> the purpose of getting a /24 from the free pool, holding it for the requisite
> time, and then selling it on the transfer market. I personally would be more
> amenable to considering a policy change to liberalize the requirements for
> getting a /24 if/when they're available from the transfer market only.
>
> -Scott
>
> On Thu, Nov 20, 2014 at 9:26 AM, Steve King
> <[email protected]<mailto:[email protected]>
> <mailto:[email protected]<mailto:[email protected]>>>
> wrote:
> Multi-homing was not a requirement. It was an alternate justification. I
> can?t honestly meet the 50% utilization requirement for a /24, but under the
> pre-September rules I qualified for a /24 under 4.3.2.2 because I contract
> with multiple carriers and want to participate in BGP for failover.
>
>
>
> Now that the language in 4.3.2.2 is gone, my reading is I have to either:
>
>
>
> a) Lie about my utilization. Not willing to do that.
>
> b) Beg for a BGP-transferrable block from a carrier, and even then, deal
> with the fact that other ISPs are far more likely to aggregate and filter
> specific routes to large carrier-assigned blocks. I end up with a less
> reliable failover solution.
>
>
>
> The policy revision is a significant step backward for me. Maybe I?m enough
> of an edge case to not matter. But ARIN-2014-13 stated 4.3.2.2 was redundant
> given the lowered minimum allocation in 4.3.2.1. It was not redundant. It
> covered a case that I think matters.
>
>
>
> The worst part is, I?m probably going to end up with two non-BGP
> transferrable /24s from two carriers (we all know they hand them out like
> candy with big circuits), so I?ll end up burning more IPV4 space than I
> otherwise would.
>
>
>
>
>
>
>
> Steve King
>
> ICON Aircraft
>
>
>
> From: John Von Stein
> [mailto:[email protected]<mailto:[email protected]>
> <mailto:[email protected]<mailto:[email protected]>>]
> Sent: Wednesday, November 19, 2014 9:18 PM
> To: Richard J. Letts; Steve King;
> [email protected]<mailto:[email protected]>
> <mailto:[email protected]<mailto:[email protected]>>
> Subject: RE: Multi-homing justification removed?
>
>
>
> Speaking from recent / current experience, the multi-homing requirement is a
> bit of a challenge for tweener-sized organizations like QxC. We are too big
> for underlying fiber carriers to comfortably continue to supply our need for
> IP addresses but not in the position to carry the financial, technical or
> operational challenges of multi-homing. This was a very significant cost
> commitment for QxC and I can imagine this is not achievable for other
> like-sized ISPs. Granted, we are better off for it now but had I known how
> much of a financial and technical hurdle this really was then I probably
> would not have done it. I just needed more IP addresses to continue to grow
> my biz and would have much rather spent the money and manpower on
> marketing/sales/customer acquisition. Multi-homing is a nice-to-have luxury
> that none of my customers are willing to pay for so it is simply a cost of
> entry to get the IP addresses we need to continue to grow our customer base.
>
>
>
> As such, I support dropping multi-homing as a prerequisite for an IP
> allocation.
>
>
>
> Thank you,
>
> John W. Von Stein
>
> CEO
>
>
>
> <image001.jpg>
>
>
>
> 102 NE 2nd Street
>
> Suite 136
>
> Boca Raton, FL 33432
>
> Office: 561-288-6989<tel:561-288-6989> <tel:561-288-6989<tel:561-288-6989>>
> www.QxCcommunications.com<http://www.QxCcommunications.com>
> <http://www.qxccommunications.com/>
>
>
> This email and any files transmitted with it are confidential and intended
> solely for the use of the individual or entity to whom they are addressed.
>
>
>
> From: [email protected]<mailto:[email protected]>
> <mailto:[email protected]<mailto:[email protected]>>
> [mailto:[email protected]<mailto:[email protected]>
> <mailto:[email protected]<mailto:[email protected]>>] On
> Behalf Of Richard J. Letts
> Sent: Wednesday, November 19, 2014 1:24 PM
> To: Steve King; [email protected]<mailto:[email protected]>
> <mailto:[email protected]<mailto:[email protected]>>
> Subject: Re: [arin-ppml] Multi-homing justification removed?
>
>
>
> I believe the intent was there.
>
>
>
> orgs that have a justifiable/provable need for a /24 were been restricted by
> their current/lone provider being unwilling to give them enough address
> space. Not everyone has the ability to change providers, and if you can?t
> change providers then you certainly would not be able to multihome..
>
>
>
> Richard Letts
>
>
>
> From: [email protected]<mailto:[email protected]>
> <mailto:[email protected]<mailto:[email protected]>>
> [mailto:[email protected]<mailto:[email protected]>
> <mailto:[email protected]<mailto:[email protected]>>] On
> Behalf Of Steve King
> Sent: Wednesday, November 19, 2014 9:47 AM
> To: [email protected]<mailto:[email protected]>
> <mailto:[email protected]<mailto:[email protected]>>
> Subject: [arin-ppml] Multi-homing justification removed?
>
>
>
> The changes implemented in ARIN-2014-13, specifically the removal of 4.3.2.2,
> appear to have removed the multi-homing justification for a /24 for end
> users. Previously, the need to multi-home, and proof of contracts with
> multiple upstream providers, was sufficient to justify a /24 to participate
> in BGP.
>
>
>
> For reassignments from ISPs, the language remains in 4.2.3.6. Users can
> justify a /24 via a requirement to multi-home rather than utilization rate.
> However this revision appears to leave utilization rate as the only criterion
> for direct end-user assignments.
>
>
>
> Was this the intent or possibly an overlooked side effect of the change?
>
>
>
>
>
>
>
> Steve King
>
> ICON Aircraft
>
>
>
>
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List
> ([email protected]<mailto:[email protected]>
> <mailto:[email protected]<mailto:[email protected]>>).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> <http://lists.arin.net/mailman/listinfo/arin-ppml>
> Please contact [email protected]<mailto:[email protected]>
> <mailto:[email protected]<mailto:[email protected]>> if you experience any issues.
>
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List
> ([email protected]<mailto:[email protected]>).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact [email protected]<mailto:[email protected]> if you experience any
> issues.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.arin.net/pipermail/arin-ppml/attachments/20141201/28186cf1/attachment.html>
------------------------------
_______________________________________________
ARIN-PPML mailing list
[email protected]<mailto:[email protected]>
http://lists.arin.net/mailman/listinfo/arin-ppml
End of ARIN-PPML Digest, Vol 114, Issue 1
*****************************************
_______________________________________________
PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List ([email protected]).
Unsubscribe or manage your mailing list subscription at:
http://lists.arin.net/mailman/listinfo/arin-ppml
Please contact [email protected] if you experience any issues.
