[Xorp-hackers] Doubt on VLAN implementation

[Bruce M Simpson]

Suresh Kannan wrote:
> Hi Bruce & all,
>
> interface foo {
> vif vlan 10.200 {
> }
> }
>
> Is the above syntax makes clear view for QinQ support ?.
>

That was on the tip of my tongue, but I didn't dare speak it, because in 
some implementations, fooXX.YY can be used to mean "VLAN YY on interface 
fooXX".

So I've been wary of using a period as a delimiter for the vlan term, 
given that overloaded meanings quickly lead to problems for network 
engineers during deployment, and it makes sense to make things easier 
for your user base.

(Yes, I'd like to just get the damn bikeshed painted so the code can 
happen...)

Even once we solve this simple problem of how to invoke a thing, we are 
left with the problem of the manifestation of the thing. Currently XORP 
knows how to make VLANs for Linux and FreeBSD, and to deal with that in 
the FEA block's syntax.

Juniper has a very specific syntax for dual-tagging:
 http://www.juniper.net/techpubs/software/junos/junos90/swconfig-network-interfaces/flexible-vlan-tagging.html#id-13039477

I can see why they've done this. It is easier IMHO to treat dual-tagging 
as a special case, because it's not the default, and most open source 
forwarding plane implementations out there are geared towards dealing 
with a single VLAN tag.

I left Q-in-Q as an exercise for the reader in FreeBSD; my refactoring 
there was just so that I could use 802.1p. At the moment the way to 
accomplish Q-in-Q there is to use Netgraph. obviously this is purely 
software plane and thus isn't optimal, and I wager newer cards are 
actually able to support Q-in-Q in ASIC, so it makes sense to go about 
solving the VLAN problem in a way which is able to capture these new 
MPLS/Metro Ethernet oriented use cases.

cheers
BMS