Thanks for all the work and input on this. I got a chance to play with the orange squares this morning. I adjusted the Relative value of the 10G to 1G to 2.64, basically to make the 10G port cost come out to 1k per solar cycle. The total 10G at $1440 (1k + 440) seemed to be reasonable. Remote Switches I'd further propose that remote switch operators pay their port fee but not an IP fee unless they are peering as well. Anyone who pays any fee is a member and has voting rights. Which is a change from our current requirement of having 1 BGP session. Any AS connected to a remote switch pays the IP Fee and the port costs are between them and the remote switch "owner". Remote Switch owners must provide superuser rights to MICE for their switches to provide common administration. I'd also argue the equipment switching must be dedicated. Remote switch operators are responsible for all the costs associated with running their remote switches. Addition of future switches requires Board of Governors approval, and likely some written agreement in the future. Remote Switches applies to attaching a L2 fabric to the network not transporting single connections. I think MICE not purchase or provide any transport period. If other parties want to offer that service I don't see an issue with it Grace Period I'd advocate offering a six month grace for new members on either 1G or 10G ports for new participants. Small Networks Under this model, small networks could connect to a "cheaper" remote switch so they would have a way to connect and participate in MICE that's feasible for them. ~$500/year isn't a huge hurdle. Expansion beyond 511 I think MICE should focus on getting our ducks in a row in 511 for now. I would be open to "seeding" a second exchange somewhere else in the Midwest. Promotion We should budget something for promotion and holding events. Organizing a UG is a PITA when you need to get everything for free. In addition, we may need to chip in for some travel at some point. Remote Hands Entering in a contract for 24x7 support is also something we should explore. -- Jay Hanke CTO, CCIE #19093 Mankato Networks LLC PO Box 54 619 S Front St Mankato, MN 56001-3838 Google 530-618-2398 jayhanke@mankatonetworks.net http://www.mankatonetworks.com ######################################################################## To unsubscribe from the MICE-DISCUSS list, click the following link: http://lists.iphouse.net/cgi-bin/wa?SUBED1=MICE-DISCUSS&A=1
Remote Switches
I'd further propose that remote switch operators pay their port fee but not an IP fee unless they are peering as well. Anyone who pays any fee is a member and has voting rights. Which is a change from our current requirement of having 1 BGP session. Any AS connected to a remote switch pays the IP Fee and the port costs are between them and the remote switch "owner".
Remote Switch owners must provide superuser rights to MICE for their switches to provide common administration. I'd also argue the equipment switching must be dedicated. Remote switch operators are responsible for all the costs associated with running their remote switches. Addition of future switches requires Board of Governors approval, and likely some written agreement in the future.
In light of this requirement, do we want to spell out that among the BoG approval criteria is the use of a model/brand of switch compatible with the knowledge/training of the current fabric administrators? Have we documented the criteria for this BoG approval at all? Is that something we want to do, or just leave it as an assumption that all parties will work in good faith to do "the right thing" in this regard? I'm fine with either decision, but I'd like it to be a conscious decision made deliberately rather than an implied decision.
Remote Switches applies to attaching a L2 fabric to the network not transporting single connections.
I would clarify the definition as: A remote switch is any piece of active hardware not owned by MICE which connects more than one member to the MICE core infrastructure.
I think MICE not purchase or provide any transport period. If other parties want to offer that service I don't see an issue with it
I would suggest: All costs and contracts required for remote switches to reach and connect to the MICE core infrastructure shall be the responsibility of the remote switch operator.
Grace Period
I'd advocate offering a six month grace for new members on either 1G or 10G ports for new participants.
I think a 3 month grace period is probably a more reasonable compromise. I think MICE is well enough established and presents a good enough value proposition to be attractive to new members as is. I don't know of any other (paid) IX offering 3 months free service, let alone 6.
Small Networks
Under this model, small networks could connect to a "cheaper" remote switch so they would have a way to connect and participate in MICE that's feasible for them. ~$500/year isn't a huge hurdle.
I haven't had a chance to look over the spreadsheet yet, but if $500/year is the IP fee, that seems rather steep to me. To the best of my knowledge, an IX is treated as an end-user organization and not a subscriber member in terms of ARIN fees. That means we should have paid about $2,250 for our initial IPv6 and IPv4 assignments combined and $500 for our ASN as a one-time fee, but should be paying $100/year thereafter. We should never need more IPv6 (a /48 is realistically enough to run several thousand of the worlds largest exchange points) and I suggest we treat the cost of additional IPv4 space ($1,250 or $MARKET, depending on timing) as a problem to solve when we have more than 200 attachments to the exchange (I think that's a ways off and the cost of IPv4 by then is unpredictable at best, if it can be obtained at all.)
Expansion beyond 511
I think MICE should focus on getting our ducks in a row in 511 for now. I would be open to "seeding" a second exchange somewhere else in the Midwest.
Agreed. Any seeding should probably be done by forming a separate organization and having MICE make an agreed upon (by vote of the members) contribution to said organization.
Promotion
We should budget something for promotion and holding events. Organizing a UG is a PITA when you need to get everything for free. In addition, we may need to chip in for some travel at some point.
Factual questions (the answers to which might shape members thoughts on the opinion questions): How frequent are the UG meetings? What is typical attendance? What level of facilities/etc. is required to hold a UG meeting? + Banquet room of a restaurant + Small Conference Room (essentially like a board room) + Large Conference Room (hotel ballroom in conference configuration) + Other? (please specify) Other than space, what logistics/facilities are required? Solicit other members opinions questions: Should UG meeting costs be borne by the full membership or by the attendees or some combination? Do we want to start requiring UG meetings to support remote participation?
Remote Hands
Entering in a contract for 24x7 support is also something we should explore.
+1 Owen ######################################################################## To unsubscribe from the MICE-DISCUSS list, click the following link: http://lists.iphouse.net/cgi-bin/wa?SUBED1=MICE-DISCUSS&A=1
In light of this requirement, do we want to spell out that among the BoG approval criteria is the use of a model/brand of switch compatible with the knowledge/training of the current fabric administrators?
I don't think we need to go to that level of detail. I think requiring a plan as to how the switch will be connected and maintained and how issues are resolved would be sufficient.
Have we documented the criteria for this BoG approval at all?
No, I just brought it up because the proposed pricing model distinguishes between MICE ports for fees. I'd love it if someone would take a stab at such a policy.
Is that something we want to do, or just leave it as an assumption that all parties will work in good faith to do "the right thing" in this regard?
I think the connection and maintenance plan would suffice.
I would clarify the definition as: A remote switch is any piece of active hardware not owned by MICE which connects more than one member to the MICE core infrastructure.
Agreed
I would suggest: All costs and contracts required for remote switches to reach and connect to the MICE core infrastructure shall be the responsibility of the remote switch operator.
Agreed
Grace Period
I'd advocate offering a six month grace for new members on either 1G or 10G ports for new participants.
I think a 3 month grace period is probably a more reasonable compromise. I think MICE is well enough established and presents a good enough value proposition to be attractive to new members as is. I don't know of any other (paid) IX offering 3 months free service, let alone 6.
MICE is just cheaper, faster and better than any of the other paid exchanges you've come across. ;)
Small Networks
I haven't had a chance to look over the spreadsheet yet, but if $500/year is the IP fee, that seems rather steep to me. To the best of my knowledge, an IX is treated as an end-user organization and not a subscriber member in terms of ARIN fees. That means we should have paid about $2,250 for our initial IPv6 and IPv4 assignments combined and $500 for our ASN as a one-time fee, but should be paying $100/year thereafter. We should never need more IPv6 (a /48 is realistically enough to run several thousand of the worlds largest exchange points) and I suggest we treat the cost of additional IPv4 space ($1,250 or $MARKET, depending on timing) as a problem to solve when we have more than 200 attachments to the exchange (I think that's a ways off and the cost of IPv4 by then is unpredictable at best, if it can be obtained at all.)
Who cares about v4 anyway? We'll just force them to tunnel their IPv4 over v6. ;)
Expansion beyond 511 Agreed. Any seeding should probably be done by forming a separate organization and having MICE make an agreed upon (by vote of the members) contribution to said organization.
Exactly
Promotion
Factual questions (the answers to which might shape members thoughts on the opinion questions): How frequent are the UG meetings?
2 per year
What is typical attendance?
20-45
What level of facilities/etc. is required to hold a UG meeting? + Banquet room of a restaurant + Small Conference Room (essentially like a board room) + Large Conference Room (hotel ballroom in conference configuration) + Other? (please specify)
A good sized banquet room is sufficient. Although missing wifi the last place worked pretty well.
Other than space, what logistics/facilities are required?
Food/Drink/Speaker/Connectivity Promotion wise, I was also thinking about sending representatives to other non-MICE events to speak. Mainly for events that we can't cover during our respective day jobs. -- Jay Hanke CTO, CCIE #19093 Mankato Networks LLC PO Box 54 619 S Front St Mankato, MN 56001-3838 Google 530-618-2398 jayhanke@mankatonetworks.net http://www.mankatonetworks.com ######################################################################## To unsubscribe from the MICE-DISCUSS list, click the following link: http://lists.iphouse.net/cgi-bin/wa?SUBED1=MICE-DISCUSS&A=1
On Sat, 2012-10-06 at 11:15 -0500, Jay Hanke wrote:
Remote Switches
I'd further propose that remote switch operators pay their port fee but not an IP fee unless they are peering as well. Anyone who pays any fee is a member and has voting rights. Which is a change from our current requirement of having 1 BGP session. Any AS connected to a remote switch pays the IP Fee and the port costs are between them and the remote switch "owner".
Remote Switch owners must provide superuser rights to MICE for their switches to provide common administration. I'd also argue the equipment switching must be dedicated. Remote switch operators are responsible for all the costs associated with running their remote switches. Addition of future switches requires Board of Governors approval, and likely some written agreement in the future.
Remote Switches applies to attaching a L2 fabric to the network not transporting single connections.
If we do that, I'd like to propose also that ports be limited to one MAC. Obviously, this wouldn't apply to ports between (any combination of) MICE Switches and Remote Switches. The Amsterdam Internet exchange is using L2ACLs for this with great success. Here'd be an example of what this would look like (with * marking ports limited to 1 MAC): +-------------+ | MICE Switch |--- 1G * ipHouse +-------------+ |Stacking | | Link +----- 1G * TDS | +-------------+ | MICE Switch |--- 10G * UMN +-------------+ |10G | | +--------- 10G * Akamai | +--------------------+ | Mankato Networks | | MICE Remote Switch | +--------------------+ <-------- MICE's authority ends here |1G |1G |1G |* |* |* +--------------------+ | BBV Wiktel Vaultas | | | | Mankato Networks | | non-MICE Switch | +--------------------+ For now, we'd treat the CNS switch as a MICE Switch (since it's loaned to MICE), but if that changed, then it might be another example of a Remote Switch. CNS & Mankato Networks: Does the requirement to break each customer out into the Remote Switch kill your business model? -- Richard ######################################################################## To unsubscribe from the MICE-DISCUSS list, click the following link: http://lists.iphouse.net/cgi-bin/wa?SUBED1=MICE-DISCUSS&A=1
If we do that, I'd like to propose also that ports be limited to one MAC. Obviously, this wouldn't apply to ports between (any combination of) MICE Switches and Remote Switches.
I played with port security for this and had pretty decent success.
The Amsterdam Internet exchange is using L2ACLs for this with great success.
Using port security also had the benefit of not having to track each carriers mac address.
Here'd be an example of what this would look like (with * marking ports limited to 1 MAC):
For now, we'd treat the CNS switch as a MICE Switch (since it's loaned to MICE), but if that changed, then it might be another example of a Remote Switch.
Mankato Networks remote switch is managed by MICE.
CNS & Mankato Networks: Does the requirement to break each customer out into the Remote Switch kill your business model?
Not really a problem, I started breaking them out anyway. I'd have a couple of legacy users that would need to shuffle ports but not a big deal. ######################################################################## To unsubscribe from the MICE-DISCUSS list, click the following link: http://lists.iphouse.net/cgi-bin/wa?SUBED1=MICE-DISCUSS&A=1
Based on some of the discussion, in particular the base IP fee, I wanted to test one change. I shifted the Colo costs from the base member fee to the switch portion of the spreadsheet to see how that would impact the distribution. I've included this for your reference. I think it's fair to shift some of that burden, but perhaps move the base fee up slightly to help cover those costs as the resources would be in use either way. MICE Cost Breakdown, Oct 2012 - Revision 1.xlsx <http://db.tt/g1h86bb8> A couple of other thoughts came to mind as I was reading through these comments as well. First, for the meetings, should we consider moving them around a little? Perhaps one at 511, one in Central MN and one in Fargo for 3 a year (or something like that). How would this impact the attendance and cost? Second, there is a lot of talk about remote switches. Should MICE care about the remote switches and should MICE have control of those switches. It occurs to me that we are discussing a fee structure which provides for a base member fee (gets you the IP allocation, peering and vote) and a separate fee for actually connecting to the MICE fabric. Do we care how the member gets to the 511 building so long as it's an L2 connection from their border to the MICE core? In other words, I think this fee structure lends itself to other member companies providing transport and it's up to them what they want to charge for that transport. All MICE would really care about is the costs of maintaining the switch fabric for those members directly connected and the base fee to peer with MICE. In fact, this could arguably encourage member companies to provide transport, leaving MICE fee to focus on it's assets in the 511 building the future needs/goals we decide on as a group. Thoughts? s *Shaun Carlson *Senior Network Engineer | Arvig ph: (218) 346-8673 | contact: protocol.by/scarlson em: shaun.carlson@arvig.com On Mon, Oct 8, 2012 at 10:08 AM, Jay Hanke <jayhanke@mankatonetworks.net>wrote:
If we do that, I'd like to propose also that ports be limited to one MAC. Obviously, this wouldn't apply to ports between (any combination of) MICE Switches and Remote Switches.
I played with port security for this and had pretty decent success.
The Amsterdam Internet exchange is using L2ACLs for this with great success.
Using port security also had the benefit of not having to track each carriers mac address.
Here'd be an example of what this would look like (with * marking ports limited to 1 MAC):
For now, we'd treat the CNS switch as a MICE Switch (since it's loaned to MICE), but if that changed, then it might be another example of a Remote Switch.
Mankato Networks remote switch is managed by MICE.
CNS & Mankato Networks: Does the requirement to break each customer out into the Remote Switch kill your business model?
Not really a problem, I started breaking them out anyway. I'd have a couple of legacy users that would need to shuffle ports but not a big deal.
########################################################################
To unsubscribe from the MICE-DISCUSS list, click the following link: http://lists.iphouse.net/cgi-bin/wa?SUBED1=MICE-DISCUSS&A=1
######################################################################## To unsubscribe from the MICE-DISCUSS list, click the following link: http://lists.iphouse.net/cgi-bin/wa?SUBED1=MICE-DISCUSS&A=1
On Oct 8, 2012, at 12:58 PM, Shaun Carlson <shaun.carlson@ARVIG.COM> wrote:
Based on some of the discussion, in particular the base IP fee, I wanted to test one change. I shifted the Colo costs from the base member fee to the switch portion of the spreadsheet to see how that would impact the distribution. I've included this for your reference. I think it's fair to shift some of that burden, but perhaps move the base fee up slightly to help cover those costs as the resources would be in use either way.
MICE Cost Breakdown, Oct 2012 - Revision 1.xlsx
A couple of other thoughts came to mind as I was reading through these comments as well.
First, for the meetings, should we consider moving them around a little? Perhaps one at 511, one in Central MN and one in Fargo for 3 a year (or something like that). How would this impact the attendance and cost?
Second, there is a lot of talk about remote switches. Should MICE care about the remote switches and should MICE have control of those switches. It occurs to me that we are discussing a fee structure which provides for a base member fee (gets you the IP allocation, peering and vote) and a separate fee for actually connecting to the MICE fabric. Do we care how the member gets to the 511 building so long as it's an L2 connection from their border to the MICE core? In other words, I think this fee structure lends itself to other member companies providing transport and it's up to them what they want to charge for that transport. All MICE would really care about is the costs of maintaining the switch fabric for those members directly connected and the base fee to peer with MICE. In fact, this could arguably encourage member companies to provide transport, leaving MICE fee to focus on it's assets in the 511 building the future needs/goals we decide on as a group. Thoughts?
The current model greatly simplifies addressing any technical issues that come up with remote connections, so I would advocate sticking with it. A more laissez faire model could lead to extended outages and/or the need to play "isolate that problem" by segmenting the exchange, neither of which seems desirable to me. For examples of what I speak, see the various histories of early days of MAE East and West. Owen
s
Shaun Carlson Senior Network Engineer | Arvig ph: (218) 346-8673 | contact: protocol.by/scarlson em: shaun.carlson@arvig.com
On Mon, Oct 8, 2012 at 10:08 AM, Jay Hanke <jayhanke@mankatonetworks.net> wrote:
If we do that, I'd like to propose also that ports be limited to one MAC. Obviously, this wouldn't apply to ports between (any combination of) MICE Switches and Remote Switches.
I played with port security for this and had pretty decent success.
The Amsterdam Internet exchange is using L2ACLs for this with great success.
Using port security also had the benefit of not having to track each carriers mac address.
Here'd be an example of what this would look like (with * marking ports limited to 1 MAC):
For now, we'd treat the CNS switch as a MICE Switch (since it's loaned to MICE), but if that changed, then it might be another example of a Remote Switch.
Mankato Networks remote switch is managed by MICE.
CNS & Mankato Networks: Does the requirement to break each customer out into the Remote Switch kill your business model?
Not really a problem, I started breaking them out anyway. I'd have a couple of legacy users that would need to shuffle ports but not a big deal.
########################################################################
To unsubscribe from the MICE-DISCUSS list, click the following link: http://lists.iphouse.net/cgi-bin/wa?SUBED1=MICE-DISCUSS&A=1
To unsubscribe from the MICE-DISCUSS list, click the following link: http://lists.iphouse.net/cgi-bin/wa?SUBED1=MICE-DISCUSS&A=1
######################################################################## To unsubscribe from the MICE-DISCUSS list, click the following link: http://lists.iphouse.net/cgi-bin/wa?SUBED1=MICE-DISCUSS&A=1
participants (4)
-
Jay Hanke -
Owen DeLong -
Richard Laager -
Shaun Carlson