IXP

[vixie at isc.org (Paul Vixie)]

stephen, any idea why this hasn't hit the nanog mailing list yet?
it's been hours, and things that others have sent on this thread
has appeared.  is it stuck in a mail queue? --paul

re:

> To: Deepak Jain <deepak at ai.net>
> cc: Matthew Moyle-Croft <mmc at internode.com.au>,
>         Arnold Nipper <arnold at nipper.de>, Paul Vixie <vixie at isc.org>,
>         "nanog at merit.edu" <nanog at merit.edu>
> Subject: Re: IXP 
> Date: Sat, 18 Apr 2009 05:30:41 +0000
> From: Stephen Stuart <stuart at tech.org>
> 
> > Not sure how switches handle HOL blocking with QinQ traffic across trunks,
> > but hey...
> > what's the fun of running an IXP without testing some limits?
> 
> Indeed. Those with longer memories will remember that I used to
> regularly apologize at NANOG meetings for the DEC Gigaswitch/FDDI
> head-of-line blocking that all Gigaswitch-based IXPs experienced when
> some critical mass of OC3 backbone circuits was reached and the 100
> MB/s fabric rolled over and died, offered here (again) as a cautionary
> tale for those who want to test those particular limits (again).
> 
> At PAIX, when we "upgraded" to the Gigaswitch/FDDI (from a DELNI; we
> loved the DELNI), I actually used a feature of the switch that you
> could "black out" certain sections of the crossbar to prevent packets
> arriving on one port from exiting certain others at the request of
> some networks to align L2 connectivity with their peering
> agreements. It was fortunate that the scaling meltdown occurred when
> it did, otherwise I would have spent more software development
> resources trying to turn that capability into something that was
> operationally sustainable for networks to configure the visibility of
> their port to only those networks with which they had peering
> agreements. That software would probably have been thrown away with
> the Gigaswitches had it actually been developed, and rewritten to use
> something horrendous like MAC-based filtering, and if I recall
> correctly the options didn't look feasible at the time - and who wants
> to have to talk to a portal when doing a 2am emergency replacement of
> a linecard to change registered MAC addresses, anyway?. The port-based
> stuff had a chance of being operationally feasible.
> 
> The notion of a partial pseudo-wire mesh, with a self-service portal
> to request/accept connections like the MAEs had for their ATM-based
> fabrics, follows pretty well from that and everything that's been
> learned by anyone about advancing the state of the art, and extends
> well to allow an IXP to have a distributed fabric benefit from
> scalable L2.5/L3 traffic management features while looking as much
> like wires to the networks using the IXP.
> 
> If the gear currently deployed in IXP interconnection fabrics actually
> supports the necessary features, maybe someone will be brave enough to
> commit the software development resources necessary to try to make it
> an operational reality. If it requires capital investment, though, I
> suspect it'll be a while.
> 
> The real lesson from the last fifteen or so years, though, is that
> bear skins and stone knives clearly have a long operational lifetime.
> 
> Stephen