 |
 |
My concern would be protecting the integrity of the exchange. Just because there have been no issues, doesn't mean there will be no issues at some point. This doesn't necessarily require dedicated hardware, nor does dedicated hardware necessarily guarantee this. A request to disclose practices in place today sent to those that currently maintain shared extension switches would be a good starting point in achieving a better understanding of the potential risks and help identify potential best practices that are already in place in addition to the suggestions already offered by Steve. Ben Wiechman Director of IP Strategy and Engineering 320.247.3224 | [log in to unmask] Arvig | 224 East Main Street | Melrose, MN 56352 | arvig.com On Mon, Dec 2, 2019 at 12:09 PM Jeremy Lumby <[log in to unmask]> wrote: > 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 > > ------------------------------ > > To unsubscribe from the MICE-DISCUSS list, click the following link: > http://lists.iphouse.net/cgi-bin/wa?SUBED1=MICE-DISCUSS&A=1 >