In my opinion the single MAC address per participant facing MICE is the most important requirement for the protection of MICE. I feel it is so important that I had contacted the board/received approval so that I could restrict my extension switch to 1 MAC address per participant regardless of if MICE requires it or not. I think short term exceptions for maintenance/upgrades are fine. I feel that trying to implement the 1 MAC address rule on a shared extension switch would be very problematic (mostly for other traffic that could be going across the same switch).
I do not feel that the added cost/complexity of requiring a dedicated extension switch would deter any network from connecting. As an extension switch operator that offers multiple different services I offer MICE completely for free to anyone with no requirements that they connect to anything other than MICE. With this being said they are responsible to getting one connection to me, however once I receive that connection all services are broken out onto separate dedicated hardware free of charge in a manner that would satisfy any IX that allows a connection to anything other than their own core switches.
From: MICE Discuss [mailto:[log in to unmask]] On Behalf Of Steve Howard
Sent: Monday, December 02, 2019 10:31 AM
To: [log in to unmask]
Subject: Re: [MICE-DISCUSS] WiscNet Remote Switch / Dedicated Remote Switches
I am not in favor of requiring MICE remote switches to be dedicated solely to MICE.
I think the proposed policy adds unnecessary complexity and costs (one-time hardware, monthly cross-connects, space at 511, and environmental) for remote switch operators. It also discourages additional membership (WiscNet) and, in my opinion, results in very little real value to MICE. Why institute a policy with real costs to MICE members and not much real value?
Sometimes the MICE community seems to worship larger exchanges, most notably, SIX and AMS-IX. MICE should make decisions based upon what is best for MICE. Just because the “big” exchanges do something doesn’t necessarily mean it is best for MICE. We are not SIX. We are not AMS-IX. Sometimes it is better to be a leader at not a follower!
I’d rather not have unnecessary rules and burdens. I’m not exactly sure what real problem this proposed rule is trying to solve. But, if there truly is a technical problem here that needs to be solved, I’d like to propose a couple of suggestions for discussion that could help protect the exchange:
1) If supported by the remote switch, enforce a specific MAC address requirement on the MICE VLAN for remote switches. Typically this would be one MAC address on the MICE VLAN, but there are a few cases where an additional MAC would be required. This could create some challenges when changing routers, but, in many cases, these can be resolved with some prior planning. For example: Paul Bunyan uses a switched virtual interface (a Cisco BVI) for its connection to SIX. This gives us the flexibility to move that interface to any device without having to contact people at SIX. Yet, it still gives SIX the protection of a single MAC address per port. MICE could also have a policy to briefly allow an extra MAC address when there is planned maintenance.
2) MICE could institute a “probationary” status for remote switches that have a history of problems at MICE. MICE has had non-dedicated remote switches from its beginning. To the best of my knowledge, this has never caused a problem. However, we’ve all seen the recent history of a single MICE remote switch operator that has had issues with packet loss, apparently slow downtime responses, etc. Fortunately, those problems have only affected their customers. Remote switch operators that have a history of poor performance could have additional requirements placed upon them until they’ve operated well for a period of time. Additionally, if a remote switch operator’s non-dedicated use causes problems at MICE, the remote switch operator could lose the privilege of having a non-dedicated switch.
3) MICE could determine an appropriate level of broadcast traffic and institute broadscast storm control based upon a multiplier of of the typical levels.
Disclaimers: I work for Paul Bunyan Communications which connects to MICE via the CNS remote switch; Paul Bunyan is a founder and part-owner of CNS; I help manage the CNS remote switch; I am one of the co-founders of MICE. I try to be loyal to Paul Bunyan, CNS, and MICE. It gets complicated sometimes!
To unsubscribe from the MICE-DISCUSS list, click the following link:
http://lists.iphouse.net/cgi-bin/wa?SUBED1=MICE-DISCUSS&A=1
