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.
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
On Mon, Oct 8, 2012 at 10:08 AM, Jay Hanke
<[log in to unmask]> 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