 |
 |
> Is this decision ministerial or discretionary? That is, if the remote switch proposal checks all the boxes in our policy, is MICE "required" (supposed to) always grant it, or is the board supposed to apply some discretion? I've understood the intention of the policy to be someplace in the middle with only the cases where some box wasn't checked going requiring deep board review and the "all boxes checked" being converted into a rubber stamp. > If the decision is ministerial, then why bother bringing this to the board (or for that matter, the members) all? Couldn't we save a bunch of time and hassle and simply have management (in some form, whether that's me, Jay, and/or Jeremy) approve it? yes, I think in almost all cases this is the case. > One criteria used in a discussion I had (and I can't recall which of us said it first) is "MICE's strategic interests". What would that phrase mean to you; what are some strategic interests of MICE? From the before times, the founding MICE fathers stated when in doubt take the option that improves connectivity. Granted, we weren't one of the largest IXes in North America back then with our Cisco 4500. Overall the remote model has been very effective at growing MICE. There is a down side that it does likely reduce port revenue on the main switch. The primary mission for the IX has been resolving the "Chicago Problem" which has been somewhat successfully moved to MSP. :) > For a bit of an absurd example for the thought experiment, imagine that someone was proposing a MICE remote switch, but we knew their goal was to attract a bunch of members and then convert that into a competing exchange. Is that something we would have to agree to simply because they met all the objective criteria? We likely need to add a utility component to the remote switch calc. A new remote switch in the 511 building is not likely to add much utility to the members. > When we were new and little, MICE certainly had an interest in making every decision in a way that would maximize additional peering. However, at this point, the calculus may be (I'd argue is) different. We are moving a lot of traffic and are important to our members / in our region. We have to be careful that our decisions do not destabilize the exchange--in multiple ways: technical, financial, or political. It's a fair point. > Either way, should we expand the list of objective criteria in the policy? Some examples: Yes > We have previously discussed dedicated vs non-dedicated switches. As time goes along, I am more convinced than ever that MICE remote switches should be required to be dedicated. Non-dedicated switches present extra complications for configuration and troubleshooting. (Jeremy has some additional insight on this that he will share.) I think we should make it a requirement that the switch be dedicated. (Perhaps the board could still grant an exception in exceptional cases.) We should require all new switches dedicated to MICE. There's been several problems involving a lot of troubleshooting time and fabric risk. > Should we require that a remote switch have X number of participants committed? And if so, what is X? In my view, it hardly makes sense to have a remote switch one or two participants. They could just as well backhaul to MICE directly. I'd propose that MICE look into adding a "VLAN reseller port type" where each member comes in on their own vlan into a MICE owned box (Juniper MX/ASR9k et al). This would cover a number of the smaller situations as well as the big PacketFabric/MegaPort/Console types. > The criteria for allowing new remote switches vs disconnecting existing remotes need not be the same. If we set a minimum of e.g. 5 participants, we don't necessarily need to disconnect existing remotes that don't meet that. And I think the consensus is that we would not, barring them creating some significant problem. Agreed > How do we feel about far-away remote switches? (This is a live issue in the context of the proposed Kansas City remote.) This doesn't bother me much, however it would be nice to tag the routes in the route server to let the other party know where the traffic is coming from. If a network doesn't want to bounce their traffic through a long path they could pref or discard the route based on the community. There are situations where the Main Switch isn't the best path as well as there is a closer path via the remotes. -- Jay Hanke, President South Front Networks [log in to unmask] Phone 612-204-0000