[Xorp-hackers] Doubt on VLAN implementation

[Suresh Kannan]

On Tue, Mar 25, 2008 at 1:39 PM, Bruce M Simpson <bms at incunabulum.net>
wrote:

> 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.


delimiter can be anything; need not be period. May be supporting flexibility
in delimiter (at some extend) makes good for various 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.


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.


>
> 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
>

having tpid.vlanid is looks good. but do user need to specify always when
the configure?.

interface foo {
  vif vlan 10.200 {
    inner-tpid 0x9100 /* only if user want to over-ride the default (0x8100)
settings */
  }
}

Thanks,
Regards,
Suresh kannan.

>
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-hackers/attachments/20080325/9f82c8be/attachment.html