*
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
