<p dir="ltr">Re: Someone pointed me at 4.4 and noted that it says that an IXP can receive an<br>
allocation if two parties are present. The common understanding in the<br>
industry is that two parties connected are private peering and three on a common switch "could" be an IXP.<br>
Is there a reason not to bump this number up to three in light of<br>
prevailing circumstances and conservation of the infrastructure pool? If<br>
two is arbitrarily low, it's a good time to make three arbitrarily low. I think it would be wise in terms of insuring that resources are being used effectively. <br>
"End quote"<br></p>
<p dir="ltr">View....My offered view is If you have an IXP and meet the criteria for allocation then why can it not be a min 2 operators.<br>
Two change it to 3, because so many IXP s are 3 up... does not sound like good justification....because whether 2 or 3.....it is still either private peering OR 'could be an IXP'.</p>
<p dir="ltr">I also question the payback for changing .. V.. insuring the effective use of resources.</p>
<p dir="ltr">Additionally, I would ask the question...are we to reasonably to expect that the exact same situation ie ...how we understand the function and use of an IXP will that stay the same for IPv6 as we see more of the development of the.. "internet of things" ....which may well morph or maybe re define some parts of network architect??<br>
Or do you think that IPv6 adoption is not going to have much or little effect on IXPs.... <br>
RD<br>
HNY<br><br><br></p>
<div class="gmail_quote">On Jan 9, 2014 8:08 PM, <<a href="mailto:arin-ppml-request@arin.net">arin-ppml-request@arin.net</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Send ARIN-PPML mailing list submissions to<br>
<a href="mailto:arin-ppml@arin.net">arin-ppml@arin.net</a><br>
<br>
To subscribe or unsubscribe via the World Wide Web, visit<br>
<a href="http://lists.arin.net/mailman/listinfo/arin-ppml" target="_blank">http://lists.arin.net/mailman/listinfo/arin-ppml</a><br>
or, via email, send a message with subject or body 'help' to<br>
<a href="mailto:arin-ppml-request@arin.net">arin-ppml-request@arin.net</a><br>
<br>
You can reach the person managing the list at<br>
<a href="mailto:arin-ppml-owner@arin.net">arin-ppml-owner@arin.net</a><br>
<br>
When replying, please edit your Subject line so it is more specific<br>
than "Re: Contents of ARIN-PPML digest..."<br>
<br>
<br>
Today's Topics:<br>
<br>
1. Weekly posting summary for <a href="mailto:ppml@arin.net">ppml@arin.net</a> (Thomas Narten)<br>
2. 4.4 Micro Allocations and IXP requirements (Martin Hannigan)<br>
3. Re: 4.4 Micro Allocations and IXP requirements (David Farmer)<br>
4. Re: 4.4 Micro Allocations and IXP requirements (Martin Hannigan)<br>
5. Re: 4.4 Micro Allocations and IXP requirements (CJ Aronson)<br>
6. Re: 4.4 Micro Allocations and IXP requirements (Aaron)<br>
<br>
<br>
----------------------------------------------------------------------<br>
<br>
Message: 1<br>
Date: Fri, 03 Jan 2014 00:53:02 -0500<br>
From: Thomas Narten <<a href="mailto:narten@us.ibm.com">narten@us.ibm.com</a>><br>
To: <a href="mailto:arin-ppml@arin.net">arin-ppml@arin.net</a><br>
Subject: [arin-ppml] Weekly posting summary for <a href="mailto:ppml@arin.net">ppml@arin.net</a><br>
Message-ID: <<a href="mailto:201401030553.s035r2Y5010595@rotala.raleigh.ibm.com">201401030553.s035r2Y5010595@rotala.raleigh.ibm.com</a>><br>
Content-Type: text/plain; charset=us-ascii<br>
<br>
Total of 1 messages in the last 7 days.<br>
<br>
script run at: Fri Jan 3 00:53:02 EST 2014<br>
<br>
Messages | Bytes | Who<br>
--------+------+--------+----------+------------------------<br>
100.00% | 1 |100.00% | 6145 | <a href="mailto:narten@us.ibm.com">narten@us.ibm.com</a><br>
--------+------+--------+----------+------------------------<br>
100.00% | 1 |100.00% | 6145 | Total<br>
<br>
<br>
<br>
------------------------------<br>
<br>
Message: 2<br>
Date: Thu, 9 Jan 2014 16:41:16 -0500<br>
From: Martin Hannigan <<a href="mailto:hannigan@gmail.com">hannigan@gmail.com</a>><br>
To: "<a href="mailto:arin-ppml@arin.net">arin-ppml@arin.net</a>" <<a href="mailto:arin-ppml@arin.net">arin-ppml@arin.net</a>><br>
Subject: [arin-ppml] 4.4 Micro Allocations and IXP requirements<br>
Message-ID:<br>
<CAMDXq5NO_k2jSUAp4Qy_7mgFpJE=<a href="mailto:K-fv1UMqsYNgc7-apKqYjA@mail.gmail.com">K-fv1UMqsYNgc7-apKqYjA@mail.gmail.com</a>><br>
Content-Type: text/plain; charset="iso-8859-1"<br>
<br>
Someone pointed me at 4.4 and noted that it says that an IXP can receive an<br>
allocation if two parties are present. The common understanding in the<br>
industry is that two parties connected are private peering and three on a<br>
common switch "could" be an IXP.<br>
<br>
Is there a reason not to bump this number up to three in light of<br>
prevailing circumstances and conservation of the infrastructure pool? If<br>
two is arbitrarily low, it's a good time to make three arbitrarily low. I<br>
think it would be wise in terms of insuring that resources are being used<br>
effectively.<br>
<br>
Thoughts?<br>
<br>
<br>
-M<<br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <<a href="http://lists.arin.net/pipermail/arin-ppml/attachments/20140109/83b5a123/attachment-0001.html" target="_blank">http://lists.arin.net/pipermail/arin-ppml/attachments/20140109/83b5a123/attachment-0001.html</a>><br>
<br>
------------------------------<br>
<br>
Message: 3<br>
Date: Thu, 09 Jan 2014 16:15:49 -0600<br>
From: David Farmer <<a href="mailto:farmer@umn.edu">farmer@umn.edu</a>><br>
To: Martin Hannigan <<a href="mailto:hannigan@gmail.com">hannigan@gmail.com</a>>, "<a href="mailto:arin-ppml@arin.net">arin-ppml@arin.net</a>"<br>
<<a href="mailto:arin-ppml@arin.net">arin-ppml@arin.net</a>><br>
Subject: Re: [arin-ppml] 4.4 Micro Allocations and IXP requirements<br>
Message-ID: <<a href="mailto:52CF1F95.9080206@umn.edu">52CF1F95.9080206@umn.edu</a>><br>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed<br>
<br>
On 1/9/14, 15:41 , Martin Hannigan wrote:<br>
><br>
> Someone pointed me at 4.4 and noted that it says that an IXP can receive<br>
> an allocation if two parties are present. The common understanding in<br>
> the industry is that two parties connected are private peering and three<br>
> on a common switch "could" be an IXP.<br>
><br>
> Is there a reason not to bump this number up to three in light of<br>
> prevailing circumstances and conservation of the infrastructure pool? If<br>
> two is arbitrarily low, it's a good time to make three arbitrarily low.<br>
> I think it would be wise in terms of insuring that resources are being<br>
> used effectively.<br>
><br>
> Thoughts?<br>
<br>
Sounds reasonable to me.<br>
<br>
I'd add that if there are only two it seems reasonable that one of the<br>
two participants can provide the address block, when there is three or<br>
more that much more reasonably meets the definition of an IXP and better<br>
justifies allocation of addresses independent of any of the participants.<br>
<br>
Further, the same change should be considered to for IPv6 in 6.10.1.<br>
Micro-allocations for Critical Infrastructure. I think it would be a<br>
bad idea to have different definitions for an IXP between IPv4 and IPv6.<br>
<br>
Thanks.<br>
<br>
--<br>
================================================<br>
David Farmer Email: <a href="mailto:farmer@umn.edu">farmer@umn.edu</a><br>
Office of Information Technology<br>
University of Minnesota<br>
2218 University Ave SE Phone: <a href="tel:1-612-626-0815" value="+16126260815">1-612-626-0815</a><br>
Minneapolis, MN 55414-3029 Cell: <a href="tel:1-612-812-9952" value="+16128129952">1-612-812-9952</a><br>
================================================<br>
<br>
<br>
------------------------------<br>
<br>
Message: 4<br>
Date: Thu, 9 Jan 2014 17:17:45 -0500<br>
From: Martin Hannigan <<a href="mailto:hannigan@gmail.com">hannigan@gmail.com</a>><br>
To: David Farmer <<a href="mailto:farmer@umn.edu">farmer@umn.edu</a>><br>
Cc: "<a href="mailto:arin-ppml@arin.net">arin-ppml@arin.net</a>" <<a href="mailto:arin-ppml@arin.net">arin-ppml@arin.net</a>><br>
Subject: Re: [arin-ppml] 4.4 Micro Allocations and IXP requirements<br>
Message-ID:<br>
<CAMDXq5OzdoV0uw=odsOv=<a href="mailto:1PDCb%2BhrWhoGXbNyGUazWx2vM45pg@mail.gmail.com">1PDCb+hrWhoGXbNyGUazWx2vM45pg@mail.gmail.com</a>><br>
Content-Type: text/plain; charset="iso-8859-1"<br>
<br>
Right, and a much smaller block. I think I also agree re: v6.<br>
<br>
<br>
On Thu, Jan 9, 2014 at 5:15 PM, David Farmer <<a href="mailto:farmer@umn.edu">farmer@umn.edu</a>> wrote:<br>
<br>
> On 1/9/14, 15:41 , Martin Hannigan wrote:<br>
><br>
>><br>
>> Someone pointed me at 4.4 and noted that it says that an IXP can receive<br>
>> an allocation if two parties are present. The common understanding in<br>
>> the industry is that two parties connected are private peering and three<br>
>> on a common switch "could" be an IXP.<br>
>><br>
>> Is there a reason not to bump this number up to three in light of<br>
>> prevailing circumstances and conservation of the infrastructure pool? If<br>
>> two is arbitrarily low, it's a good time to make three arbitrarily low.<br>
>> I think it would be wise in terms of insuring that resources are being<br>
>> used effectively.<br>
>><br>
>> Thoughts?<br>
>><br>
><br>
> Sounds reasonable to me.<br>
><br>
> I'd add that if there are only two it seems reasonable that one of the two<br>
> participants can provide the address block, when there is three or more<br>
> that much more reasonably meets the definition of an IXP and better<br>
> justifies allocation of addresses independent of any of the participants.<br>
><br>
> Further, the same change should be considered to for IPv6 in 6.10.1.<br>
> Micro-allocations for Critical Infrastructure. I think it would be a bad<br>
> idea to have different definitions for an IXP between IPv4 and IPv6.<br>
><br>
> Thanks.<br>
><br>
> --<br>
> ================================================<br>
> David Farmer Email: <a href="mailto:farmer@umn.edu">farmer@umn.edu</a><br>
> Office of Information Technology<br>
> University of Minnesota<br>
> 2218 University Ave SE Phone: <a href="tel:1-612-626-0815" value="+16126260815">1-612-626-0815</a><br>
> Minneapolis, MN 55414-3029 Cell: <a href="tel:1-612-812-9952" value="+16128129952">1-612-812-9952</a><br>
> ================================================<br>
><br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <<a href="http://lists.arin.net/pipermail/arin-ppml/attachments/20140109/56d752ef/attachment-0001.html" target="_blank">http://lists.arin.net/pipermail/arin-ppml/attachments/20140109/56d752ef/attachment-0001.html</a>><br>
<br>
------------------------------<br>
<br>
Message: 5<br>
Date: Thu, 9 Jan 2014 15:53:42 -0700<br>
From: CJ Aronson <<a href="mailto:cja@daydream.com">cja@daydream.com</a>><br>
To: Martin Hannigan <<a href="mailto:hannigan@gmail.com">hannigan@gmail.com</a>><br>
Cc: "<a href="mailto:arin-ppml@arin.net">arin-ppml@arin.net</a>" <<a href="mailto:arin-ppml@arin.net">arin-ppml@arin.net</a>><br>
Subject: Re: [arin-ppml] 4.4 Micro Allocations and IXP requirements<br>
Message-ID:<br>
<<a href="mailto:CAC6JZKQ6oLFG_Hdzc1BkvH76WBTh_72C0DPDxUQkJ9wq412JZA@mail.gmail.com">CAC6JZKQ6oLFG_Hdzc1BkvH76WBTh_72C0DPDxUQkJ9wq412JZA@mail.gmail.com</a>><br>
Content-Type: text/plain; charset="iso-8859-1"<br>
<br>
Just for reference the policy with regard to IXPs says this below. I<br>
believe that the point was that the IXP had to have at least two customers<br>
and all this other information that they are providing a credible IXP in<br>
order to get a micro allocation.<br>
-----Cathy<br>
<br>
<br>
"Exchange point operators must provide justification for the allocation,<br>
including: connection policy, location, other participants (minimum of two<br>
total), ASN, and contact information. ISPs and other organizations<br>
receiving these micro-allocations will be charged under the ISP fee<br>
schedule, while end-users will be charged under the fee schedule for<br>
end-users. This policy does not preclude exchange point operators from<br>
requesting address space under other policies."<br>
<br>
<br>
On Thu, Jan 9, 2014 at 2:41 PM, Martin Hannigan <<a href="mailto:hannigan@gmail.com">hannigan@gmail.com</a>> wrote:<br>
<br>
><br>
> Someone pointed me at 4.4 and noted that it says that an IXP can receive<br>
> an allocation if two parties are present. The common understanding in the<br>
> industry is that two parties connected are private peering and three on a<br>
> common switch "could" be an IXP.<br>
><br>
> Is there a reason not to bump this number up to three in light of<br>
> prevailing circumstances and conservation of the infrastructure pool? If<br>
> two is arbitrarily low, it's a good time to make three arbitrarily low. I<br>
> think it would be wise in terms of insuring that resources are being used<br>
> effectively.<br>
><br>
> Thoughts?<br>
><br>
><br>
> -M<<br>
><br>
><br>
><br>
> _______________________________________________<br>
> PPML<br>
> You are receiving this message because you are subscribed to<br>
> the ARIN Public Policy Mailing List (<a href="mailto:ARIN-PPML@arin.net">ARIN-PPML@arin.net</a>).<br>
> Unsubscribe or manage your mailing list subscription at:<br>
> <a href="http://lists.arin.net/mailman/listinfo/arin-ppml" target="_blank">http://lists.arin.net/mailman/listinfo/arin-ppml</a><br>
> Please contact <a href="mailto:info@arin.net">info@arin.net</a> if you experience any issues.<br>
><br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <<a href="http://lists.arin.net/pipermail/arin-ppml/attachments/20140109/0d9964df/attachment-0001.html" target="_blank">http://lists.arin.net/pipermail/arin-ppml/attachments/20140109/0d9964df/attachment-0001.html</a>><br>
<br>
------------------------------<br>
<br>
Message: 6<br>
Date: Thu, 09 Jan 2014 17:11:36 -0600<br>
From: Aaron <<a href="mailto:aaron@wholesaleinternet.net">aaron@wholesaleinternet.net</a>><br>
To: <a href="mailto:arin-ppml@arin.net">arin-ppml@arin.net</a><br>
Subject: Re: [arin-ppml] 4.4 Micro Allocations and IXP requirements<br>
Message-ID: <<a href="mailto:52CF2CA8.1090804@wholesaleinternet.net">52CF2CA8.1090804@wholesaleinternet.net</a>><br>
Content-Type: text/plain; charset="iso-8859-1"; Format="flowed"<br>
<br>
When I got my IXP allocation I was told that I couldn't host any<br>
infrastructure on it - web sites, monitoring boxes, mail servers and<br>
that it was only to be given out to exchange members. I use other IP<br>
space to host the exchange's web, mail and monitoring services.<br>
<br>
It seems like a pretty poor way to "game the system" and get IP space<br>
since it's a /24 and the initial scrutiny is pretty tough.<br>
<br>
Aaron<br>
<br>
<br>
On 1/9/2014 4:53 PM, CJ Aronson wrote:<br>
> Just for reference the policy with regard to IXPs says this below. I<br>
> believe that the point was that the IXP had to have at least two<br>
> customers and all this other information that they are providing a<br>
> credible IXP in order to get a micro allocation.<br>
> -----Cathy<br>
><br>
><br>
> "Exchange point operators must provide justification for the<br>
> allocation, including: connection policy, location, other participants<br>
> (minimum of two total), ASN, and contact information. ISPs and other<br>
> organizations receiving these micro-allocations will be charged under<br>
> the ISP fee schedule, while end-users will be charged under the fee<br>
> schedule for end-users. This policy does not preclude exchange point<br>
> operators from requesting address space under other policies."<br>
><br>
><br>
> On Thu, Jan 9, 2014 at 2:41 PM, Martin Hannigan <<a href="mailto:hannigan@gmail.com">hannigan@gmail.com</a><br>
> <mailto:<a href="mailto:hannigan@gmail.com">hannigan@gmail.com</a>>> wrote:<br>
><br>
><br>
> Someone pointed me at 4.4 and noted that it says that an IXP can<br>
> receive an allocation if two parties are present. The common<br>
> understanding in the industry is that two parties connected are<br>
> private peering and three on a common switch "could" be an IXP.<br>
><br>
> Is there a reason not to bump this number up to three in light of<br>
> prevailing circumstances and conservation of the infrastructure<br>
> pool? If two is arbitrarily low, it's a good time to make three<br>
> arbitrarily low. I think it would be wise in terms of insuring<br>
> that resources are being used effectively.<br>
><br>
> Thoughts?<br>
><br>
><br>
> -M<<br>
><br>
><br>
><br>
> _______________________________________________<br>
> PPML<br>
> You are receiving this message because you are subscribed to<br>
> the ARIN Public Policy Mailing List (<a href="mailto:ARIN-PPML@arin.net">ARIN-PPML@arin.net</a><br>
> <mailto:<a href="mailto:ARIN-PPML@arin.net">ARIN-PPML@arin.net</a>>).<br>
> Unsubscribe or manage your mailing list subscription at:<br>
> <a href="http://lists.arin.net/mailman/listinfo/arin-ppml" target="_blank">http://lists.arin.net/mailman/listinfo/arin-ppml</a><br>
> Please contact <a href="mailto:info@arin.net">info@arin.net</a> <mailto:<a href="mailto:info@arin.net">info@arin.net</a>> if you<br>
> experience any issues.<br>
><br>
><br>
><br>
><br>
> _______________________________________________<br>
> PPML<br>
> You are receiving this message because you are subscribed to<br>
> the ARIN Public Policy Mailing List (<a href="mailto:ARIN-PPML@arin.net">ARIN-PPML@arin.net</a>).<br>
> Unsubscribe or manage your mailing list subscription at:<br>
> <a href="http://lists.arin.net/mailman/listinfo/arin-ppml" target="_blank">http://lists.arin.net/mailman/listinfo/arin-ppml</a><br>
> Please contact <a href="mailto:info@arin.net">info@arin.net</a> if you experience any issues.<br>
<br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <<a href="http://lists.arin.net/pipermail/arin-ppml/attachments/20140109/013523f0/attachment.html" target="_blank">http://lists.arin.net/pipermail/arin-ppml/attachments/20140109/013523f0/attachment.html</a>><br>
<br>
------------------------------<br>
<br>
_______________________________________________<br>
ARIN-PPML mailing list<br>
<a href="mailto:ARIN-PPML@arin.net">ARIN-PPML@arin.net</a><br>
<a href="http://lists.arin.net/mailman/listinfo/arin-ppml" target="_blank">http://lists.arin.net/mailman/listinfo/arin-ppml</a><br>
<br>
End of ARIN-PPML Digest, Vol 103, Issue 1<br>
*****************************************<br>
</blockquote></div>