[113670] in North American Network Operators' Group
RE: IXP
daemon@ATHENA.MIT.EDU (Deepak Jain)
Sat Apr 18 00:31:31 2009
From: Deepak Jain <deepak@ai.net>
To: Matthew Moyle-Croft <mmc@internode.com.au>, Arnold Nipper
<arnold@nipper.de>
Date: Sat, 18 Apr 2009 00:30:54 -0400
In-Reply-To: <49E95424.7010400@internode.com.au>
Cc: Paul Vixie <vixie@isc.org>, "nanog@merit.edu" <nanog@merit.edu>
Errors-To: nanog-bounces@nanog.org
> Not agreeing or disagreeing with this as a concept, but I'd imagine
> that
> since a number of vendors support arbitrary vlan rewrite on ports that
> in simple environment you could do some evil things with that. (ie.
> you could use QinQ "like" ATM Virtual Paths between core switches and
> then reuse the VLAN tag as a VC). Then, as long as no peer has more
> than 4096 peers you're sweet. It'd hurt your head and probably never
> work, but heck, there's a concept to argue about. (Please note: I
> don't
> endorse this as an idea).
>=20
This would be best managed by a very smart, but very simple piece of softwa=
re.
Just like Facebook or LinkedIn, or what-have-you, a network accepts a "peer=
/friend"
request from another network. Once both sides agree (and only as long as bo=
th sides
agree) the configuration is pinned up. Either side can pull it down. The co=
nfigs, up
to the hardware limits, would be pretty trivial.. Especially QinQ managemen=
t for VLANID=20
uniqueness.
Not sure how switches handle HOL blocking with QinQ traffic across trunks, =
but hey...=20
what's the fun of running an IXP without testing some limits?
Deepak Jain
AiNET
