-----Original Message-----
So here is an idea that I hope someone shoots down.
We've been talking about pseudo-wires, and the high level of expertise a shared-fabric IXP needs to diagnose weird switch oddities, etc.
As far as I can tell, the principal reason to use a shared fabric is to allow multiple connections to networks that may not justify their own dedicated ($$$$) router port. Once they do, they can move over to a PNI. However, an IXP is (at the hardware level at least) trying to achieve any-to-any connectivity without concern for capacity up to the port size of each port on every flow. Scaling this to multiple pieces of hardware has posed interesting challenges when the connection speed to participants is of the same order as the interconnection between IXP switches.
So here is a hybrid idea, I'm not sure if It has been tried or seriously considered before.
Since the primary justification for a shared fabric is cost savings....
What if everyone who participated at an IXP brought their own switch. For argument's sake, a Nexus 5xxx. It has 20+ ports of L2, wire speed 10G.
[Michael K. Smith - Adhost]
This sounds like fertile ground for unintended consequences. Unmanaged spanning tree topological changes as three people, previously connected to their own switch and to others, now decide to connect to each other as well, using those inexpensive L2 ports.
If each port is in its own pVLAN or similar, and they are only allowed to talk to their uplinks and not other L2 ports on the same switch, loops are avoided. I should have hashed that point out with another line. Yes, strictly throwing up an unconfigured switch becomes a problem after the 2nd one goes in -- but only for those brave enough to peer with you and dumb enough to allow their switch to behave that way. The double-edged clue sword. Deepak [Michael K. Smith - Adhost] The problem is the model as you've presented it, or as I've read it anyway, allows that type of insertion as part of its root design. If all of the switches have to speak spanning tree because they may be connected to each other on some connection outside of your administrative control, then you have no control over what happens "over there" that causes issues with the STP domain. I'm a big fan of the operational simplicity of a L2 shared fabric with spanning tree disallowed by policy and configuration with all of its resources dedicated to forwarding frames. I'm not convinced that a more complex L3 shared architecture over a shared L2 fabric gets you any more security or resiliency, but it certainly keeps the exchange people busy! I should note that I do technical work for the Seattle Internet Exchange so I'm showing a bias. But, with that said, we have benefited greatly from this model, through consistent, tragedy free growth and very high uptime. Regards, Mike