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?
s
*Shaun Carlson
*Senior Network Engineer | Arvig
ph: (218) 346-8673 | contact: protocol.by/scarlson
em: [log in to unmask]
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
>
########################################################################
To unsubscribe from the MICE-DISCUSS list, click the following link:
http://lists.iphouse.net/cgi-bin/wa?SUBED1=MICE-DISCUSS&A=1
