October 2012 - mice-discuss - lists.micemn.net

Dormant Ports

by Jay Hanke

The Integra, Zayo and Implex port have been dormant (down/down) for quite some time. If you're part of these organizations please let us know if you plan to connect and peer so we can clean up the records. Thanks, Jay ######################################################################## To unsubscribe from the MICE-DISCUSS list, click the following link: http://lists.iphouse.net/cgi-bin/wa?SUBED1=MICE-DISCUSS&A=1

Oct. 10, 2012

Books

by Anthony Anderberg

I brought a couple topical books to the MICE UG7 meeting, including a book called Tubes that mentions MICE. As the social hour started to die down I went down to do some work in our racks and when I came back the books were gone. All of the people were gone too so I assume someone picked them up and has thus-far forgotten to ping me regarding their current location. Ping away. Anthony Anderberg Sr. Systems Analyst [NUtel_email_logo_1] 320-234-5239 anthonyanderberg(a)nu-telecom.net<mailto:anthonyanderberg@nu-telecom.net> www.nutelecom.net ######################################################################## To unsubscribe from the MICE-DISCUSS list, click the following link: http://lists.iphouse.net/cgi-bin/wa?SUBED1=MICE-DISCUSS&A=1

Oct. 10, 2012

Cologix Press Release - MICE IP Exchange

by Mike Hemphill

Good morning, FYI, please see attached Press Release that Cologix is sending out this morning announcing that we have renewed and extended our support for the Midwest Internet Cooperative Exchange <http://www.micemn.net/> (MICE). Thank you to all MICE members, Cologix appreciates our relationship with MICE & each MICE member! Best regards, Mike Mike Hemphill General Manager | *Cologix, Inc.** *511 11th Ave S, Suite 450 | Minneapolis, MN 55415 P: 612.333.1922 | M: 612.812.5242 mike.hemphill(a)cologix.com cologix.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. 10, 2012

Re: Route Server

by Doug McIntyre

On Tue, Oct 09, 2012 at 08:36:46AM -0500, Jay Hanke wrote: > Can someone add the new IP addresses to the rviews router? Oh yeah, forgot about that one. Okay, the IPs are up. I'll get the new BGP sessions later today. -- Doug McIntyre <merlyn(a)iphouse.net> -- ipHouse/Goldengate/Bitstream/ProNS -- Network Engineer/Provisioning/Jack of all Trades ######################################################################## To unsubscribe from the MICE-DISCUSS list, click the following link: http://lists.iphouse.net/cgi-bin/wa?SUBED1=MICE-DISCUSS&A=1

Oct. 9, 2012

Route Server

by Jay Hanke

Can someone add the new IP addresses to the rviews router? -- 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. 9, 2012

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