IXP

[vixie at isc.org (Paul Vixie)]

> Date: Sat, 18 Apr 2009 16:35:51 +0100
> From: Nick Hilliard <nick at foobar.org>
> 
> ... i just don't care if people use L2 connectivity to get to an exchange
> from a router somewhere else on their LAN. They have one mac address to
> play around with, and if they start leaking mac addresses towards the
> exchange fabric, all they're going to do is hose their own
> connectivity.

yeah we did that at PAIX.  if today's extremenetworks device has an option
to learn one MAC address per port and no more, it's because we had a
terrible time getting people to register their new MAC address when they'd
change out interface cards or routers.  hilarious levels of fingerpointing
and downtime later, our switch vendor added a knob for us.  but we still
saw typo's in IP address configurations whereby someone could answer ARPs
for somebody else's IP.  when i left PAIX (the day MFN entered bankruptcy)
we were negotiating for more switch knobs to prevent accidental and/or
malicious ARP poisoning.  (and note, this was on top of a no-L2-devices
rule which included draconian auditing rights for L2/L3 capable hardware.)

> As you've noted, there is a natural progression for services providers
> here from shared access to pni, which advances according to the business
> and financial requirements of the parties involved. If exchange users
> decide to move from shared access peering to PNI, good for them - it
> means their business is doing well. But this doesn't mean that IXPs don't
> offer an important level of service to their constituents. Because of
> them, the isp industry has convenient access to dense interconnection at
> a pretty decent price.

yes, that's the progression of success.  and my way of designing for
success is to start people off with VNI's (two-port VLANs containing one
peering) so that when they move from shared-access to dedicated they're
just moving from a virtual wire to a physical wire without losing any of
the side-benefits they may have got from a shared-access peering fabric.

> > Q in Q is not how i'd build this... cisco and juniper both have
> > hardware tunnelling capabilities that support this stuff...  it just
> > means as the IXP fabric grows it has to become router-based.
> 
> Hey, I have an idea: you could take this plan and build a tunnel-based or
> even a native IP access IXP platform like this, extend it to multiple
> locations and then buy transit from a bunch of companies which would give
> you a native L3 based IXP with either client prefixes only or else an
> option for full DFZ connectivity over the exchange fabric.  You could
> even build a global IXP on this basis!  It's a brilliant idea, and I just
> can't imagine why no-one thought of it before.

:-).

i've been known to extend IXP fabrics to cover a metro, but never beyond.