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
