[arin-ppml] ARIN-PPML Digest, Vol 103, Issue 1 micro allocations For IXP

Rudolph Daniel rudi.daniel at gmail.com
Thu Jan 9 21:28:49 EST 2014


Re: Someone pointed me at 4.4 and noted that it says that an IXP can
receive an
allocation if two parties are present. The common understanding in the
industry is that two parties connected are private peering and three on a
common switch "could" be an IXP.
Is there a reason not to bump this number up to three in light of
prevailing circumstances and conservation of the infrastructure pool? If
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.
"End quote"

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

I also question the payback for changing .. V..  insuring  the effective
use of resources.

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??
Or do you think that IPv6 adoption is not going to have much or little
effect on IXPs....
RD
HNY


On Jan 9, 2014 8:08 PM, <arin-ppml-request at arin.net> wrote:

> Send ARIN-PPML mailing list submissions to
>         arin-ppml at arin.net
>
> 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
>         arin-ppml-request at arin.net
>
> You can reach the person managing the list at
>         arin-ppml-owner at arin.net
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of ARIN-PPML digest..."
>
>
> Today's Topics:
>
>    1. Weekly posting summary for ppml at arin.net (Thomas Narten)
>    2. 4.4 Micro Allocations and IXP requirements (Martin Hannigan)
>    3. Re: 4.4 Micro Allocations and IXP requirements (David Farmer)
>    4. Re: 4.4 Micro Allocations and IXP requirements (Martin Hannigan)
>    5. Re: 4.4 Micro Allocations and IXP requirements (CJ Aronson)
>    6. Re: 4.4 Micro Allocations and IXP requirements (Aaron)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Fri, 03 Jan 2014 00:53:02 -0500
> From: Thomas Narten <narten at us.ibm.com>
> To: arin-ppml at arin.net
> Subject: [arin-ppml] Weekly posting summary for ppml at arin.net
> Message-ID: <201401030553.s035r2Y5010595 at rotala.raleigh.ibm.com>
> Content-Type: text/plain; charset=us-ascii
>
> Total of 1 messages in the last 7 days.
>
> script run at: Fri Jan  3 00:53:02 EST 2014
>
>     Messages   |      Bytes        | Who
> --------+------+--------+----------+------------------------
> 100.00% |    1 |100.00% |     6145 | narten at us.ibm.com
> --------+------+--------+----------+------------------------
> 100.00% |    1 |100.00% |     6145 | Total
>
>
>
> ------------------------------
>
> Message: 2
> Date: Thu, 9 Jan 2014 16:41:16 -0500
> From: Martin Hannigan <hannigan at gmail.com>
> To: "arin-ppml at arin.net" <arin-ppml at arin.net>
> Subject: [arin-ppml] 4.4 Micro Allocations and IXP requirements
> Message-ID:
>         <CAMDXq5NO_k2jSUAp4Qy_7mgFpJE=
> K-fv1UMqsYNgc7-apKqYjA at mail.gmail.com>
> Content-Type: text/plain; charset="iso-8859-1"
>
> Someone pointed me at 4.4 and noted that it says that an IXP can receive an
> allocation if two parties are present. The common understanding in the
> industry is that two parties connected are private peering and three on a
> common switch "could" be an IXP.
>
> Is there a reason not to bump this number up to three in light of
> prevailing circumstances and conservation of the infrastructure pool? If
> 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.
>
> Thoughts?
>
>
> -M<
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> http://lists.arin.net/pipermail/arin-ppml/attachments/20140109/83b5a123/attachment-0001.html
> >
>
> ------------------------------
>
> Message: 3
> Date: Thu, 09 Jan 2014 16:15:49 -0600
> From: David Farmer <farmer at umn.edu>
> To: Martin Hannigan <hannigan at gmail.com>,       "arin-ppml at arin.net"
>         <arin-ppml at arin.net>
> Subject: Re: [arin-ppml] 4.4 Micro Allocations and IXP requirements
> Message-ID: <52CF1F95.9080206 at umn.edu>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
> On 1/9/14, 15:41 , Martin Hannigan wrote:
> >
> > Someone pointed me at 4.4 and noted that it says that an IXP can receive
> > an allocation if two parties are present. The common understanding in
> > the industry is that two parties connected are private peering and three
> > on a common switch "could" be an IXP.
> >
> > Is there a reason not to bump this number up to three in light of
> > prevailing circumstances and conservation of the infrastructure pool? If
> > 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.
> >
> > Thoughts?
>
> Sounds reasonable to me.
>
> I'd add that if there are only two it seems reasonable that one of the
> two participants can provide the address block, when there is three or
> more that much more reasonably meets the definition of an IXP and better
> justifies allocation of addresses independent of any of the participants.
>
> Further, the same change should be considered to for IPv6 in 6.10.1.
> Micro-allocations for Critical Infrastructure.  I think it would be a
> bad idea to have different definitions for an IXP between IPv4 and IPv6.
>
> Thanks.
>
> --
> ================================================
> David Farmer               Email: farmer at umn.edu
> Office of Information Technology
> University of Minnesota
> 2218 University Ave SE     Phone: 1-612-626-0815
> Minneapolis, MN 55414-3029  Cell: 1-612-812-9952
> ================================================
>
>
> ------------------------------
>
> Message: 4
> Date: Thu, 9 Jan 2014 17:17:45 -0500
> From: Martin Hannigan <hannigan at gmail.com>
> To: David Farmer <farmer at umn.edu>
> Cc: "arin-ppml at arin.net" <arin-ppml at arin.net>
> Subject: Re: [arin-ppml] 4.4 Micro Allocations and IXP requirements
> Message-ID:
>         <CAMDXq5OzdoV0uw=odsOv=
> 1PDCb+hrWhoGXbNyGUazWx2vM45pg at mail.gmail.com>
> Content-Type: text/plain; charset="iso-8859-1"
>
> Right, and a much smaller block. I think I also agree re: v6.
>
>
> On Thu, Jan 9, 2014 at 5:15 PM, David Farmer <farmer at umn.edu> wrote:
>
> > On 1/9/14, 15:41 , Martin Hannigan wrote:
> >
> >>
> >> Someone pointed me at 4.4 and noted that it says that an IXP can receive
> >> an allocation if two parties are present. The common understanding in
> >> the industry is that two parties connected are private peering and three
> >> on a common switch "could" be an IXP.
> >>
> >> Is there a reason not to bump this number up to three in light of
> >> prevailing circumstances and conservation of the infrastructure pool? If
> >> 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.
> >>
> >> Thoughts?
> >>
> >
> > Sounds reasonable to me.
> >
> > I'd add that if there are only two it seems reasonable that one of the
> two
> > participants can provide the address block, when there is three or more
> > that much more reasonably meets the definition of an IXP and better
> > justifies allocation of addresses independent of any of the participants.
> >
> > Further, the same change should be considered to for IPv6 in 6.10.1.
> > Micro-allocations for Critical Infrastructure.  I think it would be a bad
> > idea to have different definitions for an IXP between IPv4 and IPv6.
> >
> > Thanks.
> >
> > --
> > ================================================
> > David Farmer               Email: farmer at umn.edu
> > Office of Information Technology
> > University of Minnesota
> > 2218 University Ave SE     Phone: 1-612-626-0815
> > Minneapolis, MN 55414-3029  Cell: 1-612-812-9952
> > ================================================
> >
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> http://lists.arin.net/pipermail/arin-ppml/attachments/20140109/56d752ef/attachment-0001.html
> >
>
> ------------------------------
>
> Message: 5
> Date: Thu, 9 Jan 2014 15:53:42 -0700
> From: CJ Aronson <cja at daydream.com>
> To: Martin Hannigan <hannigan at gmail.com>
> Cc: "arin-ppml at arin.net" <arin-ppml at arin.net>
> Subject: Re: [arin-ppml] 4.4 Micro Allocations and IXP requirements
> Message-ID:
>         <
> CAC6JZKQ6oLFG_Hdzc1BkvH76WBTh_72C0DPDxUQkJ9wq412JZA at mail.gmail.com>
> Content-Type: text/plain; charset="iso-8859-1"
>
> Just for reference the policy with regard to IXPs says this below.  I
> believe that the point was that the IXP had to have at least two customers
> and all this other information that they are providing a credible IXP in
> order to get a micro allocation.
> -----Cathy
>
>
> "Exchange point operators must provide justification for the allocation,
> including: connection policy, location, other participants (minimum of two
> total), ASN, and contact information. ISPs and other organizations
> receiving these micro-allocations will be charged under the ISP fee
> schedule, while end-users will be charged under the fee schedule for
> end-users. This policy does not preclude exchange point operators from
> requesting address space under other policies."
>
>
> On Thu, Jan 9, 2014 at 2:41 PM, Martin Hannigan <hannigan at gmail.com>
> wrote:
>
> >
> > Someone pointed me at 4.4 and noted that it says that an IXP can receive
> > an allocation if two parties are present. The common understanding in the
> > industry is that two parties connected are private peering and three on a
> > common switch "could" be an IXP.
> >
> > Is there a reason not to bump this number up to three in light of
> > prevailing circumstances and conservation of the infrastructure pool? If
> > 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.
> >
> > Thoughts?
> >
> >
> > -M<
> >
> >
> >
> > _______________________________________________
> > 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 --------------
> An HTML attachment was scrubbed...
> URL: <
> http://lists.arin.net/pipermail/arin-ppml/attachments/20140109/0d9964df/attachment-0001.html
> >
>
> ------------------------------
>
> Message: 6
> Date: Thu, 09 Jan 2014 17:11:36 -0600
> From: Aaron <aaron at wholesaleinternet.net>
> To: arin-ppml at arin.net
> Subject: Re: [arin-ppml] 4.4 Micro Allocations and IXP requirements
> Message-ID: <52CF2CA8.1090804 at wholesaleinternet.net>
> Content-Type: text/plain; charset="iso-8859-1"; Format="flowed"
>
> When I got my IXP allocation I was told that I couldn't host any
> infrastructure on it -  web sites, monitoring boxes, mail servers and
> that it was only to be given out to exchange members.  I use other IP
> space to host the exchange's web, mail and monitoring services.
>
> It seems like a pretty poor way to "game the system" and get IP space
> since it's a /24 and the initial scrutiny is pretty tough.
>
> Aaron
>
>
> On 1/9/2014 4:53 PM, CJ Aronson wrote:
> > Just for reference the policy with regard to IXPs says this below.  I
> > believe that the point was that the IXP had to have at least two
> > customers and all this other information that they are providing a
> > credible IXP in order to get a micro allocation.
> > -----Cathy
> >
> >
> > "Exchange point operators must provide justification for the
> > allocation, including: connection policy, location, other participants
> > (minimum of two total), ASN, and contact information. ISPs and other
> > organizations receiving these micro-allocations will be charged under
> > the ISP fee schedule, while end-users will be charged under the fee
> > schedule for end-users. This policy does not preclude exchange point
> > operators from requesting address space under other policies."
> >
> >
> > On Thu, Jan 9, 2014 at 2:41 PM, Martin Hannigan <hannigan at gmail.com
> > <mailto:hannigan at gmail.com>> wrote:
> >
> >
> >     Someone pointed me at 4.4 and noted that it says that an IXP can
> >     receive an allocation if two parties are present. The common
> >     understanding in the industry is that two parties connected are
> >     private peering and three on a common switch "could" be an IXP.
> >
> >     Is there a reason not to bump this number up to three in light of
> >     prevailing circumstances and conservation of the infrastructure
> >     pool? If 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.
> >
> >     Thoughts?
> >
> >
> >     -M<
> >
> >
> >
> >     _______________________________________________
> >     PPML
> >     You are receiving this message because you are subscribed to
> >     the ARIN Public Policy Mailing List (ARIN-PPML at arin.net
> >     <mailto: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 <mailto:info at arin.net> if you
> >     experience any issues.
> >
> >
> >
> >
> > _______________________________________________
> > 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 --------------
> An HTML attachment was scrubbed...
> URL: <
> http://lists.arin.net/pipermail/arin-ppml/attachments/20140109/013523f0/attachment.html
> >
>
> ------------------------------
>
> _______________________________________________
> ARIN-PPML mailing list
> ARIN-PPML at arin.net
> http://lists.arin.net/mailman/listinfo/arin-ppml
>
> End of ARIN-PPML Digest, Vol 103, Issue 1
> *****************************************
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20140109/d6efad65/attachment.html>


More information about the ARIN-PPML mailing list