Re: IXP

[Stephen Stuart <stuart () tech org>]

> 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.