> We got to go through all the badness that was the ATM NAPs (AADS, > PacBell NAP, MAE-WEST ATM). > > I think exactly for the reason Leo mentions they failed. That is, it > didn't even require people to figure out all the technical reasons they > were bad (many), they were fundamentally doomed due to increasing the > difficulty of peering which translated to an economic scaling problem. > > i.e. if you make it hard for people to peer then you end up with less > peers and shared vlan exchanges based on things like ethernet outcompete > you. > > Been there done that. > > We've already experienced the result of secure ID cards and the > PeerMaker tool. It was like pulling teeth to get sessions setup, and > most peers plus the exchange operator didn't believe in oversubscription > (can you say CBR? I knew you could), so you end up with 2 year old > bandwidth allocations cast in stone because it was such a pain to get > the peer to set it up in the first place, and to increase bandwidth to > you means your peer has to reduce the bandwidth they allocated to > somebody else.
I, too, had a SecureID card, whose PIN I promptly forgot. I actually feel sorry for the poor software developers of that system; who knows what "requirements" were imposed on them by management fiat versus researched from the customer (and potential customer) base? Ethernet != shared VLAN, as I'm sure you know, so equating the two is non-sequitur. Ethernet has grown enough features that it can be used effectively in a variety of ways - and knowing which features to avoid is just as important as knowing which features to expose. "Not every knob that can be turned, should be turned." The challenge to a developer of the software infrastructure of a modern IXP is to take what we learned about the ease of use of shared VLAN peering and translate it into the world of pseudo-wire interconnect. Does it have to be as hard as PeerMaker? Clearly not. If someone is going to jump into that space, though, there's a lot of homework to do to research what a provisioning system would need to do to present as little a barrier to peering as possible. Your argument, and Leo's, is fundamentally the complacency argument that I pointed out earlier. You're content with how things are, despite the failure modes, and despite inefficiencies that the IXP operator is forced to have in *their* business model because of your complacency.
