<br><br><div class="gmail_quote">On Tue, Mar 25, 2008 at 1:39 PM, Bruce M Simpson <<a href="mailto:bms@incunabulum.net">bms@incunabulum.net</a>> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="Ih2E3d">Suresh Kannan wrote:<br>
> Hi Bruce & all,<br>
><br>
> interface foo {<br>
> vif vlan 10.200 {<br>
> }<br>
> }<br>
><br>
> Is the above syntax makes clear view for QinQ support ?.<br>
><br>
<br>
</div>That was on the tip of my tongue, but I didn't dare speak it, because in<br>
some implementations, fooXX.YY can be used to mean "VLAN YY on interface<br>
fooXX".<br>
<br>
So I've been wary of using a period as a delimiter for the vlan term,<br>
given that overloaded meanings quickly lead to problems for network<br>
engineers during deployment, and it makes sense to make things easier<br>
for your user base.</blockquote><div><br>delimiter can be anything; need not be period. May be supporting flexibility in delimiter (at some extend) makes good for various user base. <br> <br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>
<br>
(Yes, I'd like to just get the damn bikeshed painted so the code can<br>
happen...)<br>
<br>
Even once we solve this simple problem of how to invoke a thing, we are<br>
left with the problem of the manifestation of the thing. Currently XORP<br>
knows how to make VLANs for Linux and FreeBSD, and to deal with that in<br>
the FEA block's syntax.</blockquote><div> </div><div>This is interesting part i yet to peek into. Is there any plan to extend XORP towards switching platform?. As above mentioned, XORP understand VLAN for linux and its mac-based. Implementing XORP for learning of MACS and other L2 functions, would help people to try out switching side and would explore possibilites of MPLS/Metro oriented use cases as BMS mentioned. <br>
<br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br>
<br>
Juniper has a very specific syntax for dual-tagging:<br>
<a href="http://www.juniper.net/techpubs/software/junos/junos90/swconfig-network-interfaces/flexible-vlan-tagging.html#id-13039477" target="_blank">http://www.juniper.net/techpubs/software/junos/junos90/swconfig-network-interfaces/flexible-vlan-tagging.html#id-13039477</a><br>
</blockquote><div><br>having tpid.vlanid is looks good. but do user need to specify always when the configure?. <br><br>interface foo {<br>
vif vlan 10.200 {<br> inner-tpid 0x9100 /* only if user want to over-ride the default (0x8100) settings */<br>
}<br>}<br><br>Thanks,<br>Regards,<br>Suresh kannan.<br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br>
I can see why they've done this. It is easier IMHO to treat dual-tagging<br>
as a special case, because it's not the default, and most open source<br>
forwarding plane implementations out there are geared towards dealing<br>
with a single VLAN tag.<br>
<br>
I left Q-in-Q as an exercise for the reader in FreeBSD; my refactoring<br>
there was just so that I could use 802.1p. At the moment the way to<br>
accomplish Q-in-Q there is to use Netgraph. obviously this is purely<br>
software plane and thus isn't optimal, and I wager newer cards are<br>
actually able to support Q-in-Q in ASIC, so it makes sense to go about<br>
solving the VLAN problem in a way which is able to capture these new<br>
MPLS/Metro Ethernet oriented use cases.<br>
<br>
cheers<br>
<font color="#888888">BMS<br>
</font></blockquote></div><br>