- mice-discuss - lists.micemn.net

Re: MICE Cost Breakdowns

by Owen DeLong

On Oct 8, 2012, at 12:58 PM, Shaun Carlson <shaun.carlson(a)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(a)arvig.com > > > > On Mon, Oct 8, 2012 at 10:08 AM, Jay Hanke <jayhanke(a)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

Oct. 8, 2012

Re: MICE Cost Breakdowns

by Shaun Carlson

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(a)arvig.com On Mon, Oct 8, 2012 at 10:08 AM, Jay Hanke <jayhanke(a)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

Oct. 8, 2012

Re: ARIN in Minneapolis

by Hannigan, Martin

I’ll be there as well. Best, -M< On 9/11/12 9:32 AM, "Reid Fishler" <rfishler(a)HE.NET> wrote: I am Reid. :-P Sorry, I had to. Reid On Tue, Sep 11, 2012 at 9:07 AM, Brian Mort <brian.mort(a)arvig.com> wrote: I am Jay. On Tue, Sep 11, 2012 at 8:01 AM, Jay Hanke <jayhanke(a)mankatonetworks.net> wrote: Is anyone else going to the ARIN meeting on Thursday in Minneapolis? -- Jay Hanke CTO, CCIE #19093 Mankato Networks LLC PO Box 54 619 S Front St Mankato, MN 56001-3838 Google 530-618-2398 <tel:530-618-2398> jayhanke(a)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 ######################################################################## To unsubscribe from the MICE-DISCUSS list, click the following link: http://lists.iphouse.net/cgi-bin/wa?SUBED1=MICE-DISCUSS&A=1

Oct. 8, 2012

Re: MICE Cost Breakdowns

by Jay Hanke

> 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

Oct. 8, 2012

Re: MICE Cost Breakdowns

by Richard Laager

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

Oct. 8, 2012

Re: MICE Cost Breakdowns

by Jay Hanke

> 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(a)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

Oct. 6, 2012

Re: MICE Cost Breakdowns

by Owen DeLong

> 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

Oct. 6, 2012

MICE Cost Breakdowns

by Jay Hanke

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(a)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

Oct. 6, 2012

Re: New cost breakdown worksheet

by Owen DeLong

On Oct 5, 2012, at 11:50 AM, Dean Bahls <dean.bahls(a)COOPERATIVE-NETWORKS.COM> wrote: > Shaun and Richard, > > I like and appreciate the work and thought that you guys have put into this. > > The only comment I have is regarding the acquisition of new members. Since MICE is still relatively young, I’d encourage us to look at ways to make it easy for companies to come on board. Can we extend the life expectancy of hardware from 3 years to 5 or 6 years? The switches really should live much longer than 3 years in the way we are using them. > > And one question: A significant portion of the annual cost is related to the Base Member Fee, and a large portion of that is associated with the Cologix-donated space and power fees that are currently forgiven. I agree with the notion that charging members for those otherwise forgiven fees is a good way to build cash reserves without asking for more donations. Is $11K annual a reasonable number for a MICE bank account? > It might be a little on the low side, but I think it's as good a starting point as any. Owen ######################################################################## To unsubscribe from the MICE-DISCUSS list, click the following link: http://lists.iphouse.net/cgi-bin/wa?SUBED1=MICE-DISCUSS&A=1

Oct. 6, 2012

Re: New cost breakdown worksheet

by Richard Laager

On Fri, 2012-10-05 at 13:50 -0500, Dean Bahls wrote: > The switches really should live much longer than 3 years in the way we > are using them. We're using our current costs as a way to estimate future costs. In other words, we're not saying that we need to buy another 40-port 10G switch in 3 years. We're saying we need to buy an X-port 40G or 100G switch in 3 years, and by then, it'll probably cost about what the 10G switch cost us this time. I realize this isn't perfectly accurate, but at this point, I like the fact that it's closer to objective than subjective. I'd hate to see us get bogged down discussing what each of us predicts a 40G switch will cost 3 years from now. -- Richard ######################################################################## To unsubscribe from the MICE-DISCUSS list, click the following link: http://lists.iphouse.net/cgi-bin/wa?SUBED1=MICE-DISCUSS&A=1

Oct. 5, 2012