Date: Thu, 21 Sep 2006 19:16:43 -0700 From: Troy Davis To: members _at_ seattleix.net Subject: [members] SIX extension proposal: Layer42 Layer42 has proposed an SIX extension (below). The proposal has two parts: the request, and questions from the board plus answers from Layer42 and Sonic.net. Open for discussion and comments until 10/5/06 per Troy --- PROPOSAL --- Pursuant to the SIX Switch Interconnection Policy obtained on July 24, 2006 from http://www.seattleix.net/rules.htm, Nathan Patrick from Sonic.net, Inc. and Steve Rubin from Layer42 Networks request agreement from the SIX board to interconnect a Layer 2 device to the SIX fabric. The purpose of this connection will be to enable geographically-distributed Layer 2 connectivity to the SIX exchange for Layer42, Sonic.net, as well as other providers in the future. This will be accomplished through a Gigabit Ethernet port attached to the exchange that does not have any MAC restrictions. The directly connected device, a Cisco Catalyst 6500 Sup720, will Layer 2 bridge participants in San Jose, California, Ashburn, Virginia, as well as other locations over Layer42's MPLS-enabled backbone. Remote SIX port access speeds will be both Fast and Gigabit Ethernet. Administrative control over all devices in the network will be held solely by personnel at Layer42 Networks. To ensure continued stability of the exchange, all SIX access ports provisioned by Layer42 will contain the following Cisco IOS-based configuration: port security port security max-mac-count 1 port security action shutdown spanning-tree portfast bpduguard Note that this configuration requires a remote peering participant to contact Layer42's 24x7 NOC if BPDU guard is activated to manually clear the resulting errdisable port state. All access ports will be provisioned on Cisco Catalyst 6500 equipment containing either a Sup2 or Sup720 module. Care will be taken to ensure all remote peering participants meet all current and future SIX interconnection requirements. The switches in Layer42's network will be used for tasks other than SIX interconnection and are primarily employed as Layer 3 devices. Present methods for MPLS signaling of Layer 2 pseudowire tunnels prohibit topological loops, except in the case of very severe vendor bugs. Thus, the main threat to the exchange are the traditional edge connectivity concerns of unwanted spanning tree interactions as well as multiple MAC addresses. Both of these are addressed by our sample configuration above. Today, only Layer42 and Sonic.net are extension peers, and both are located in San Jose, CA. As a start, I expect we'd only offer the San Jose location -- however, Ashburn, VA could follow quite soon. I don't expect any near-term growth beyond those two sites unless other folks express an interest. We would ensure that the MPLS network allowed traffic between peers located on our system to stay local, meaning that the SIX proper would never see that traffic. As a start, Sonic.net would be paying Layer42 for access to Seattle on a 95% billed per-megabit basis. Future participants are likely to be billed in the same fashion. Layer42 would offer the SIX extension service as a standalone product available to the general public. --- Q&A --- > - SIX growth. Do the members want third-parties to make it easier to > peer remotely? That's not necessarily a bad thing, nor is this the > wrong way to do it, but allowing service providers to extend the SIX > fabric (inter)nationally could change the scope. Sure, and that's certainly a question that I'm not fit to answer. I will point out, however, that the SIX currently has no negative stance on the practice of "remote peering", e.g. peering at the SIX over Ethernet transport. The difference between lots of folks "remote peering" from, say, San Jose and a SIX extension switch in San Jose comes down to: 1.) Traffic passing between local peers remains local. I think this is a Good Thing, for the most part, and happens with any SIX extension switch. 2.) Peers would be required to use settlement-based transport to attach to the SIX. Certainly, we don't want a monopoly on this service, so competition should make the price reasonable. 3.) Trusting a 3rd party with a slightly more complex network topology. As previously stated, the MPLS protocol suite makes loops in the transport topology rather hard to construct, so the primary source of concern is the "looped port" issue. I'd argue that such an event is as likely to occur in a remote peering situation as it is in Seattle. > - Precedence. Allowing this case means others with less clue could try > to do the same thing. That could lead to disagreements about what's > practical or desirable (is the SIX Miami extension OK?), or how high the > technical bar is. I'd recommend a zero-tolerance policy to service impacting issues (L2 floods, etc.). If you screw things up, even once, you get fired. I also think that the SIX board should certify the network's exact topology, both physical and virtual. More specifically, I would look for a design that had only one L2 device at each location where the SIX transport services are offered. This considerably reduces the number of possible issues. > - Ability to bring up new peers nationally. That's a lot of trust, > even more so with inter-peer traffic running across their network. Not > that extension switches are different (peer-peer traffic on same > extension doesn't hit core), just that it's not thousands of miles. I don't see the difference between this and a normal extension switch. What's the difference between 10' and 1000 miles? --- END ---