mice-discuss
By thread
mice-discuss@lists.micemn.net
By month
Messages by month
- ----- 2026 -----
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2025 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2024 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2023 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2022 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2021 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2020 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2019 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2018 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2017 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2016 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2015 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2014 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2013 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2012 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2011 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2010 -----
- December
- November
- October
- September
- August
- July
- 1 participants
- 6649 messages
FW: How do I start an Internet Exchange Point?
by Michael Hemphill
Hello MICE people,
I saw this post on LinkedIn today & thought it may offer some more help and/or confusion to the current discussions.
Mike
Mike Hemphill
ColoConnect
612-812-5242
mikeh(a)ColoConnect.net<mailto:mikeh@ColoConnect.net>
[Kurt-Erik "Kurtis" Lindqvist]<https://www.linkedin.com/in/klindqvist>Kurt-Erik "Kurtis" Lindqvist<https://www.linkedin.com/in/klindqvist>CMO at LINX ( The London Internet Exchange)
How do I start an Internet Exchange Point?
September 17, 2016 • 13 Likes • 3 Comments
I have been involved in helping a lot of Internet Exchange Points (IXPs) get of the ground and I have also been to several countries and regions to help IXPs to prosper and sometimes even to explain to the IXP, the members and the regulators why things have failed. I have helped IXPs in Europe, Asia, the Middle East and even North America. In addition to this I have together with Philip Smith and others thought numerous classes for APRICOT<http://www.apricot.net/>s, MENOG<http://www.menog.org/>s, ISOC<http://www.isoc.org/>, AfPIF<http://www.internetsociety.org/events/afpif> and others on how routing, IXPs and peering work. Because of this involvement I very often get asked advice by people wanting to establish an IXP or even newly formed IXPs.
At LINX we are always very supportive of new IXPs being formed, and we try and contribute as much as we can. For those wanting to start an IXP I thought I would write up some comments that observations I have made over the years and post it here. There are already a large number of resources for new IXPs, and I will also list some of these considerations below.
Establishing the IXP
The hard part with establishing an IXP is not really the technical part, but building up a community and a community with trust with that. Also, an IXP needs to be sustainable beyond the establishment phase, i.e. have enough funds to operate, and in the future upgrade the equipment they need as technology develops and traffic grows. Most IXPs ensure this by setting up a mutual or membership association so that the users of the IXP have equal say in the operation of the IXP. This is by far the most successful model of IXPs today. The members pay a fee based on their port size to the association, so one fee for a 1GE port and one for a 10GE port. Not based on the actual traffic, but the port speed. The membership all have one vote each in the running of the organisation and normally appoints a board for the day to day operation of the IXP.
Secondly, new IXPs tend to believe it is a good idea to offer free ports to large content networks in order to attract other members. At first glance this might seem like a good idea, but you will quickly find yourself squeezed between the content networks and the broadband operators that then also want their ports for free. Generally it is better to charge everyone equally and threat everyone equally. It might make it slightly harder for the IXP to get off the ground but it certainly makes running the IXP easier in the long run. Most of the large content owners are also quite supportive of new IXPs being formed in locations or regions where no IXP exists.
Thirdly, what is very important is to ensure that the IXP does not in any way interfere with the peering arrangements across the IXP. If the members want to for example sell transit to each other across the IXP, that is fine. If someone only want to peer with a subset of the members, that is also fine.
Selecting the location for your IXP
Besides creating the community in order to support the IXP, the other important factor for establishing a successful IXP is the location. Successful IXPs needs to be accessible for everyone so a neutral datacenter, where any fibre infrastructure can be build in. These locations can be hard to find, but are very critical for the success. The wider the choice of fibre providers (or wlan for that matter in some parts of the world) and choice of carriers that are available, the better. Datacenters owned by current or former incumbents are not good choices as they generally tend to be very restrictive in what choice of infrastructure providers they offer.
Besides easy infrastructure access, the datacenter also needs to provide a stable power feed, or you need to ensure you have UPSes and perhaps even generators (depending on ambition, stability of power grid and if the datacenter provides generator power). Also make sure there is room to grow the IXP. You might only two racks to start with, but if you are successful you might need more and moving the IXP is always painful.
What type of switch do I need?
There is an excellent presentation<http://ripe71.ripe.net/presentations/30-1000-dollar-exchange-ripe71.pdf> by Remco van Mook that covers many of the same topics as this post, and that also points out that ~50% of IXPs carry less than 20Gbps of traffic. As a new start-up IXP you will most certainly carry less than 20Gbps.
What you need is a switch that will support 1GE and 10GE ports, preferably via SFPs, not an expensive and large switch with massive amount of features (although the vendors will try and sell you one).
Instead, make sure you get a switch that you can manage and that you can monitor. These are the most important components of an IXP switch.
Co-location of services
For the benefit of the membership of your IXP as well as the local Internet community, you should co-locate some critical shared resources with the IXP. The most important ones are
* The local ccTLD slave service (i.e .uk, .fr, .sg, .bd etc). If the ccTLD registry is supportive of the IXP, the contact them and ask if they are willing to locate one of their unicast slaves behind your IXP router. Never connect the DNS slaves directly to IXP L2 domain.
* It is likely that the ccTLD registry also uses an anycast provider for their slave service. In that case it might be worth contacting that DNS anycast provider and ask them to connect to the IXP. You should in any cast contact the DNS anycast providers as they are more than happy to peer at many of the IXPs. Many of these also operate or provide service to one the DNS root-servers. These are a critical part of the internet infrastructure and having one co-located with your IXP will provide a lot of value to your local Internet community. PCH<http://www.pch.net/>, Verisign<http://www.verisign.com/> and Netnod<http://www.netnod.se/> are some of the DNS Anycast providers that locate nodes around the world.
* Route-servers are also important to offer to your members, especially as you start to grow. The most stable software for route-servers today is BIRD<http://bird.network.cz/>. Providing two route-servers also adds redundancy as if one fails, the peering sessions will go down.
Last, some IXPs offer NTP services as part of the IXP to their community. This is a very good service, and something that the community should make use of. However, for a new start-up IXP, NTP services is quite expensive to provide and definitely not needed at the first stage.
Managing my IXP and members
The guys over at INEX<http://www.inex.ie/> has created an amazing tool called The IXP Manager<http://www.inex.ie/ixp/index/about> that provides you all the software you need to mange your IXP and the tools for your members. This is really an amazing resource that you should use for setting up the IXP!
How do I know if my IXP is a success?
What makes an IXP successful varies very much from each individual case. A small land-locked country where all ISPs or Internet Operators are forced to use Satellite capacity for Internet access will benefit enormously from an IXP no matter how little traffic that is exchanged, as each bit is a huge saving! Value of peering is always in the eye of the beholder. Access to one single route or Internet prefix can be extremely valuable to one ISP, while another might need large traffic volumes before it creates value to them.
In the end a successful IXP is defined by the membership. If there is a community that uses and continuous to see benefit from the IXP they will continue to support it. By being stable and sustainable the IXP is successful!
Other resources
IXP Associations
* IX-F<http://www.ix-f.net/>
* Euro-IX<http://www.euro-ix.net/>
* APIX<http://apix.asia/>
* LACIX<http://www.lac-ix.net/>
* AF-IX<http://www.af-ix.net/>
The IXP toolkit<http://www.ixptoolkit.org/> is a collection of resources for IXPs.
The Euro-IX movie<http://youtu.be/QuBde4Sn3f0> is a great resource for explaining in a non-technical manner how an IXP works and what it does.
You are always welcome to contact me for questions and advice!
Written by
[Kurt-Erik "Kurtis" Lindqvist]<https://www.linkedin.com/in/klindqvist>Kurt-Erik "Kurtis" Lindqvist<https://www.linkedin.com/in/klindqvist>CMO at LINX ( The London Internet Exchange)
3 comments
[ ]
2h
[https://media.licdn.com/mpr/mpr/shrink_100_100/AAEAAQAAAAAAAAltAAAAJDMwNWY0…]<https://www.linkedin.com/in/ivanbev>
Ivan Beveridge<https://www.linkedin.com/in/ivanbev>
Seeking network/systems opportunities in…
Typo correction: Establishing the IXP .... "Generally it is better to charge everyone equally and threat everyone equally" - threat -> treat
LikeReply
2h
[https://media.licdn.com/mpr/mpr/shrink_100_100/p/2/000/03f/0cb/2aae6f1.jpg]<https://www.linkedin.com/in/muhammad-aslam-1868a15>
Muhammad Aslam<https://www.linkedin.com/in/muhammad-aslam-1868a15>
Chief Operating Officer at ADRAS
Great article - mostly the technical would agree with the points mentioned in the article including the Remco van Mook presentation in terms of the technical and costing matrix. The biggest dilemma with the developing economies would be that their consulting partner being ITU that provides different approach towards the setup of IXP , so the question would be how to convin… See more
LikeReply
1
1h
[https://media.licdn.com/mpr/mpr/shrink_100_100/AAEAAQAAAAAAAAltAAAAJDMwNWY0…]<https://www.linkedin.com/in/ivanbev>
Ivan Beveridge<https://www.linkedin.com/in/ivanbev>
Seeking network/systems opportunities in…
You say "ITU that provides different approach towards the setup of IXP". Can you elaborate? What is their approach?
LikeReply
1h
[https://media.licdn.com/mpr/mpr/shrink_100_100/AAEAAQAAAAAAAAltAAAAJDMwNWY0…]<https://www.linkedin.com/in/ivanbev>
Ivan Beveridge<https://www.linkedin.com/in/ivanbev>
Seeking network/systems opportunities in…
Good article, highlighting important topics and linking to additional resources. I guess the particularly tricky part comes when wishing to setup in areas where there are few/no neutral colocation centres. I suspect such instances need to be treated on a case-by-case basis; is this what you/people (eg Bill, Gaurab, etc) have found?
Sept. 17, 2016
Re: Proposed Membership and Sponsorship Model
by DeLong, Owen
I would like to humbly suggest that we first focus the discussion on the revenue model we want to achieve
(flat fee vs. voluntary differentiations vs. differentiated services). Once we come to consensus on that,
it will be much easier to look at all the corner cases for making sure that each organization can provide
money in a way that meets both our and their accounting needs.
Owen
> On Sep 9, 2016, at 10:09 , Ben Franske <ben.lists(a)FRANSKE.COM> wrote:
>
> On 9/9/2016 1:28 AM, Richard Laager wrote:
>>
>> Ironically, I don't think this even works for the University of
>> Minnesota. I believe it was your position that you needed an invoice, as
>> "the University doesn't give donations; it accepts them".
>
> I was actually going to bring this up, but it wasn't the U of M that had this issue, it was Wisconsin/BadgerNet. I believe they stated that even a "membership" might be problematic, but port fees could definitely be paid.
>
> -Ben
>
> Ben Franske
> Inver Hills Community College (MICE via MNSCU via UMN)
Sept. 9, 2016
Re: Proposed Membership and Sponsorship Model
by Ben Franske
On 9/9/2016 1:28 AM, Richard Laager wrote:
>
> Ironically, I don't think this even works for the University of
> Minnesota. I believe it was your position that you needed an invoice, as
> "the University doesn't give donations; it accepts them".
I was actually going to bring this up, but it wasn't the U of M that had
this issue, it was Wisconsin/BadgerNet. I believe they stated that even
a "membership" might be problematic, but port fees could definitely be paid.
-Ben
Ben Franske
Inver Hills Community College (MICE via MNSCU via UMN)
Sept. 9, 2016
Wikstrom Telephone MICE Port Move
by Jason Hanke
Wikstrom Telephone is moving their connection from the Mankato Networks
Remote Switch to the Main Switch
The new port will be xe-2/0/6 on the main stack.
IP information will remain the same.
Welcome aboard (again)!
--
Jay Hanke
CTO
Neutral Path Communications
3 Civic Center Plaza, Suite 204
Mankato, MN 56001
(507) 327-2398 mobile
jayhanke(a)neutralpath.net
www.neutralpath.net
Sept. 9, 2016
Re: Richard Laager Board Seat
by Richard Laager
*
This election is important for the future of MICE. Please consider your
choices carefully, and please make sure to vote. If you cannot attend
the meeting, I encourage you to designate a proxy, which must be done in
advance. According to the bylaws, you can do this by email to the Chief
Manager. I believe that is Shaun, but if you want to be safe and nobody
confirms who holds that role, send your proxy to Shaun, Jay, and Reid.
Obviously, you should inform the proxy, too.
**
If you wish to vote for me, but cannot attend the meeting, you can
designate Mike Johnston as your proxy. I assume Owen will also provide
proxy instructions.
At the time of the MICE UG, I will be in San Francisco at the OpenZFS
Developer Summit. I may be able to attend the MICE UG remotely, but I
cannot commit to that. I definitely will not be able to attend in
person. At the last UG when we were scheduling this one, it seemed like
there were not a lot of dates that worked for the board, especially
Reid. I felt it was better to optimize for the current board, so I did
not ask for a date change.
I am a long-time MICE supporter. I have attended, in person, most of the
UG meetings since I learned of MICE, despite the distance and sometimes
the weather. I have also made a point of involving my co-workers. I
contribute in other ways, including mailing list discussions, handling
the routine website updates, and talking up MICE both privately and
publicly (e.g. NANOG 65 Peering Personals). I secured a donation from my
employer for MICE's Juniper service contract.
Overall, I think MICE is headed in the right direction. My top priority
is, of course, that we complete the non-profit filing in a timely
fashion. Immediately after that, we need to address financial
sustainability.
Along the way, there are a couple items related to the participant
versus member distinction:
*
I would like to formalize the procedure for new connections. I am
not envisioning big changes. We simply need to document the
procedure and be explicit about the various states and steps.
Specifically, we need to implement (as the board previously agreed)
a process of participants requesting membership.
*
In looking at the bylaws, we may need to make a small fix to address
non-member participants (e.g. University of Wisconsin System). The
current bylaws specify in 1.16(a) that a membership resignation
results in a port disconnection. One might be able to play games by
suggesting that they never accepted membership and thus did not
resign, but this is hole that needs to be fixed anyway.
> PVLAN service. What are your opinions on if MICE should offer it or not.
I do not think we should add features speculatively. If two or more
participants have concrete plans to actually use a PVLAN in short order,
I have no problem with it. As a volunteer-run exchange, the participants
involved bear the responsibility to engineer and implement the solution,
or convince someone to do it for them.
If implemented on the main switches, remote switch operators should not
be compelled to (nor prohibited from) participating in PVLAN service.
> Do you see any major conflicts between your other affiliations/obligations and MICE? I am interested both from the standpoint of availability, as well as from the professional interest point of view.
I am a board member (immediate past president) of the Thief River Falls
Rotary Club. I am a board member of Instant Messaging Freedom, the
non-profit foundation which assists Adium and Pidgin. I am a developer
of Pidgin. I am a member of the ZFS on Linux team. I maintain a couple
quasi-abandoned open source projects: docsis & pks. I maintain gbonds's
Debian packaging. I expect no professional conflicts with any of these.
Time conflicts are always a concern. None of these roles are huge time
commitments; the amount of time I spend on them is flexible. I have the
full support of my employer for participating in MICE, so that comes out
of work time.
The biggest potential for conflict is obviously my employment at
Wikstrom Telephone Company, a MICE member and participant. (I also vote
at ARIN on their behalf.) This is the same situation as the other board
members and candidates. I see no problem navigating this through
disclosure and, if necessary, recusal.
> Do you see the finical current model as sustainable for MICE?
I am skeptical that MICE can function indefinitely on ad-hoc donations.
> What changes would you suggest on the business side?
Long-time members may recall I was involved in previous planning for this.
Here is my current plan:
Expenses
First, we need to define what we need on the expense side. I believe
everyone agrees we need operating funds to pay the year's bills (ARIN
fees, etc.). My position is that we can accept the discounted Cologix
rates as a given. That is subject to change at the expiration of our
contract, of course, but that would be similar with a non-discounted
contract.
Opinions on the capital expenses are more varied, but I think we have a
broad consensus that we will need new switches over time. My position is
that, moving forward, MICE needs to be proactive, not reactive, in
planning for capital expenditures.
There are three reasons we need new switches:
1) Hardware failures
2) Bandwidth growth
3) New members
All of these rely on estimates. Reasonable people can disagree, so we
can adjust based on member consensus. The important thing is that we not
lose the budget forest for the trees. We need to get started with
something, and we can adjust over time.
For #1, let's assume a switch needs to be replaced, on average, every 10
years.
For #2, let's assume 50% annualized growth. This is the "Nielsen's Law"
number. That rate is higher than what I am seeing in reports of actual
national averages, but lower than my employers' actual bandwidth growth.
A 50% annualized growth rate means an order of magnitude port speed
increase occurs every 5 to 6 years. When it comes to planning for new
switches, the particular port speed is something which will be
determined at the time of purchase. That is, last year's 10G might be
next year's 40G or 100G.
For #3, it is very hard to predict. We cannot extrapolate from the
bootstrapping days of MICE, as it is unlikely we will continue to add
members at the same rate. As a starting point, I would suggest we round
#2's timeframe down to 5 years and then keep a close eye on what is
actually happening.Adding this all together looks like this:
1) We estimate the current replacement cost of each switches. We
subtract the amount we currently have budgeted. (At the start, that's
zero.) We calculate the years remaining (10 years minus how long we have
owned the switch). We divide those two numbers to determine how much we
need to budget per year for hardware replacement.
2) Of our fastest port type, we currently have two switches. So we need
to plan to replace those with two switches of the future port speed, at
some point. We take the cost of the Juniper 10G switch when we purchased
it. For each 10G switch, we take that cost, subtract what we currently
have budgeted (zero), and divide that by the remaining time in the
upgrade cycle (5 years minus the length of time we had the switch). This
gives the amount we need to budget per year for port speed growth.
Adding operating costs plus the capital costs defines our annual need.
This is independent of how we recover these costs.
Income
On the income side, there are many possible models. I start by defining
goals. Note that here I am talking about various types of fees which are
possible.
*
We recover our budgeted costs.
*
Members are treated equally.
o
If there is a member fee, all members pay it equally.
*
Participants are treated equally.
o
If there is a participant fee, all participants pay it equally.
*
Remote switch operators are treated equally.
o
If there is a remote switch operator fee, all remote switch
operators pay it equally.
*
Port users are treated neutrally.
o
If there are port fees, port users pay based on their port
types/counts.
o
I oppose giving free ports to eyeball networks.
o
I oppose giving free ports to content providers.
o
I oppose differentiating non-profit versus for-profit.
o
PCH is an interesting edge case, because they are providing
services for the Internet itself. I could accept them as a
special case, if there was broad member consensus. A better
answer, though, might be for the subset of interested members to
donate to PCH to cover their fees.
*
We should not create perverse incentives on port speeds.
o
For example, if a 10G port costs ten times as much as a 1G port,
we could see 4x1G or even 8x1G LAGs used rather than the
preferred 10G.
o
Likewise, but less so (as port users' equipment costs act as
disincentives), setting the prices the same may result in
smaller port users utilizing 10G ports when 1G ports would be
more than sufficient.
o
To address these concerns, the previous proposal put the
"relative value" at 2x.
Finally, here is my proposal of which possible fees to actually charge:
*
There should be a member fee, which is mandatory.
o
This formalizes whether or not you have voting rights within MICE.
o
The extra step weeds out participants who have no interest in
governance, which helps with quorum issues. (This mayallow us to
raise the quorum requirement, which was desired by some members.)
o
This fee should be a token amount.
o
Failure to pay the member fee results in a termination of
membership (and thus voting rights), but not other statuses
(e.g. participant status).
*
There should be a participant fee.
o
This fee should be a small amount.
o
We might set the amount based on the ARIN costs.
o
For the initial implementation, participant fees should be
"optional". We would invoice for them, but not enforce
disconnections for failure to pay.
+
We can revisit this item once we see how things go.
*
There should notbe a remote switch operator fee.
o
I do not see any costs to recover here.
*
There should be port fees.
o
This fee should be a large amount, relative to other fees. This
is how we recover the capital costs. This is also how we recover
the service contract costs.
o
For the initial implementation, port fees should be "optional".
We would invoice for them, but not enforce disconnections for
failure to pay.
+
We can revisit this item once we see how things go.
Determining the actual fees is a math exercise given the inputs above.
*
--
Richard
Sept. 9, 2016
Re: Proposed Membership and Sponsorship Model
by Richard Laager
On 09/09/2016 12:14 AM, David Farmer wrote:
> I added paying member dues in addition to being attached as a membership
> requirement for two reasons
...
I agree with this point 100%. I believe any solution should have this as
a component.
I am very opposed to the rest of proposal.
I highly doubt that the slightly increased recognition that comes from
established sponsorship levels will increase donations in any
significant way.
I see how donations equal priority access to ports, but I'm very
concerned about the "enforcement" of that. If we have a non-trivial
number of non-member participants, who gets kicked off when a member
needs the last available port? Do we kick off the participant with the
lowest amount of traffic, which gives big players an advantage? Do we
kick off the participant who connected last, entrenching older
participants? Do we make the board decide, putting them in a complicated
and conflict-prone position? If we don't kick anybody off, which seems
like the most likely outcome, then priority access isn't very
meaningful, and thus disappears as an incentive.
More importantly, the "MPR model" does nothing to address the fact that
invoices and donations are handled very differently in organizations.
Ironically, I don't think this even works for the University of
Minnesota. I believe it was your position that you needed an invoice, as
"the University doesn't give donations; it accepts them".
--
Richard
Sept. 9, 2016
Re: Proposed Membership and Sponsorship Model
by Nevin Lyne
> I very much appreciate your participation and donations and wish there was
> a good way to give you and others like you a vote in the governance of the
> exchange. However, requiring a network attached to the exchange for
> membership provides important protections. It helps prevent hostile or
> malicious takeovers. If sponsors got a vote simply by donating money,
> anyone with sufficient money could essentially stuff the ballot box. Less
> conspiratorial, it helps ensure that those governing the exchange, are
> tightly bound to the consequences of their decisions, which is usually a
> good thing from a governance perspective.
Forgive me I likely read something slightly wrong, pain meds from oral surgery can do that. That does make sense.
> If you have suggestions to safely allow broader participation I'd love to
> hear them.
For cases like mine there could be a two part process
a) I am indirectly part of the network as we are connected to a network of a member, IPHouse. We have both IP space from them, and they announce our own IP ranges via BGP for us. So traffic to our web hosting clients are routed via MICE to us via IPHouse's connection to MICE. We are also a large user of CloudFlare, and an Optimized Hosting Partner of theirs supplying a second connection to some degree of how traffic routes through MICE members to our clients. Just showing a case in how we could be seen as a connected member though not currently directly through our own port on the exchange.
b) For a case like this that a sponsor can show a direct routing of traffic to them through a connected member, could leave it up to a vote of existing members if that sponsor qualifies enough to be a member? Regardless of sponsorship level.
Just as you pointed out that some members of the exchange may not want to do anything to exchange traffic and not deal with governance you may have cases of a company that passes traffic over the exchange because of routing through a member's port and do want to be involved with a vote as what the exchange does, does impact traffic to my network too.
Again semantics at this point as this of course is just the start of how your suggestion might work as a membership model, but I wanted to get my thoughts out there, again though I am not an official member of the exchange but have been involved from early on in the exchange to some degree.
-Nevin
-- Nevin Lyne
-- Founder & Director of Technology
-- Arcustech, LLC. - arcustech.com
-- Gippy's Internet Solutions, LLC. - enginehosting.com
Sept. 9, 2016
Re: Proposed Membership and Sponsorship Model
by David Farmer
On Thu, Sep 8, 2016 at 11:06 PM, Nevin Lyne <nevin(a)enginehosting.com> wrote:
> ....
> Something like this actually I think helps equality for people/companies
> like mine where we do not have a need of direct ports on the exchange, but
> indirectly benefit from the exchange and would like to both support the
> exchange and have some say (a vote) as a member of the exchange. Currently
> I can't be a voting member of the exchange unless I have an active port,
> which I don't need, but we actively donate resources and hardware to the
> exchange.
>
> -Nevin
>
> -- Nevin Lyne
> -- Founder & Director of Technology
> -- Arcustech, LLC. - arcustech.com
> -- Gippy's Internet Solutions, LLC. - enginehosting.com
I added paying member dues in addition to being attached as a membership
requirement for two reasons;
1. It ensures at least some minimal financial contribution by everyone
participating in the governance of the exchange.
2. And, by requiring an additional action beyond simply connecting to be a
member, organizations that can't or simply don't want to be part of the
governance can connect and exchange traffic, without causing issues for
themselves or the good governance of the exchange.
If a network that never intends to participate in the governance is counted
as part of the membership, that will mess with quorum for meetings.
I very much appreciate your participation and donations and wish there was
a good way to give you and others like you a vote in the governance of the
exchange. However, requiring a network attached to the exchange for
membership provides important protections. It helps prevent hostile or
malicious takeovers. If sponsors got a vote simply by donating money,
anyone with sufficient money could essentially stuff the ballot box. Less
conspiratorial, it helps ensure that those governing the exchange, are
tightly bound to the consequences of their decisions, which is usually a
good thing from a governance perspective.
If you have suggestions to safely allow broader participation I'd love to
hear them.
Thanks.
--
===============================================
David Farmer Email:farmer@umn.edu
Networking & Telecommunication Services
Office of Information Technology
University of Minnesota
2218 University Ave SE Phone: 612-626-0815
Minneapolis, MN 55414-3029 Cell: 612-812-9952
===============================================
Sept. 9, 2016
Re: Proposed Membership and Sponsorship Model
by David Farmer
On Thu, Sep 8, 2016 at 10:28 PM, Matthew Beckwell <matthewb(a)aitech.net>
wrote:
> I like Mr. Farmer's proposal, it's got a little bit of an MPR feel to it,
> but I won't hold it against him :)
>
Well close, I think it was the recent PBS pledge drive echoing in my head,
at least the "sustaining member" bit. :) Actually, I think they are both
apt analogies, PBS and MPR are community funded public services, that many
people benefit from, but in varying and unequal ways.
> So, there's Neutrality-- which I think everyone connected to MICE has a
> common mindset in this department.
> But many of us connect to MICE for very different reasons, so I suspect it
> will never be equal. Neutral, yes. But probably never completely equal.
>
> ~Matthew
>
--
===============================================
David Farmer Email:farmer@umn.edu
Networking & Telecommunication Services
Office of Information Technology
University of Minnesota
2218 University Ave SE Phone: 612-626-0815
Minneapolis, MN 55414-3029 Cell: 612-812-9952
===============================================
Sept. 9, 2016