Subject: Mitchell Blank Jr: Re: 802.1q Was (Re: Plans for 2.5 / 2.6 ???
To: None <>
From: Michael Richardson <>
List: tech-net
Date: 06/12/2000 18:14:07
Content-Type: text/plain; charset=US-ASCII

  I forward this rather well written message.

  It kind of sums up the thinking in the Linux world wrt. VLANs and network
code in general.

  The summary, as I understand it so far is:

  One camp argues that VLANs should appear as real interfaces so that
everything just works. (I agree with this!)

  The other camp (Jes, Jamal) feels that this will break all sorts of code
that assumes that the number of interfaces is small and can be looked through
in a linear search. Further, that VLAN output code should be IPv4 specific...

  Perhaps this will all get hashed out at the Ottawa Linux Symposium this
July. If you are going to be there, there will be a number of more
"enlightened" people there.

Content-Type: message/rfc822

Delivery-Date: Mon Jun 12 14:50:16 2000
Date:   Mon, 12 Jun 2000 11:46:10 -0700
From: Mitchell Blank Jr <>
To: jamal <>
Cc: Gleb Natapov <>, Gleb Natapov <>,
        Ben Greear <>,
        Andrey Savochkin <>,,,, Jes Sorensen <>
Subject: Re: 802.1q Was (Re: Plans for 2.5 / 2.6 ???
Message-ID: <>
References: <> <>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
In-Reply-To: <>; from on Mon, Jun 12, 2000 at 09:39:17AM -0400

jamal wrote:
> IP rules. Who cares about
> IPX? Just encapsulate it (IPX) in the ether-packet and let it be
> switched/routed somewhere. some policy maps it to some VLAN. Is this not
> sufficient?

It's already been explained several times in this thread why this is
not so - namely, that one of the major uses of vlans is to isolate
large networks running broadcast-happy protocols in such a way that
they can still talk to their servers directly.  Suppose you had a
big appletalk installation - you could split it in 10 pieces by VLAN
and then have your linux+netatalk servers bring in all the VLANs
on 802.1q.

Only your IP-centric solution doesn't handle this very well.

> We already have a very powerful modular routing architecture; use the
> route flags and dst_in/out properly and you have yourself specific routing
> code which does not touch the common path *at all*

Do you have a reference for this code - I wonder if we could make ATM-CLIP
work better.

Still, I don't see it as relevant to the VLAN discussion.  The biggest problem
with your idea is that it changes the API that protocols use to pass
packets out a VLAN opposed to a LAN (i.e. net_device), you're changing
the abstration used for lots of configuring protocls (i.e. net_device),
and you're changing the abstration presented to the user space tools
(i.e. a named net_device)

jamal - answer this one question: what plans do you have for PPPoE?
After all, it's just another protocol for expressing VLANs on an
ethernet.  It also has the exact same (supposedly fatal) flow
control issues that VLANs have.  Therefore, I assume your arguments
are the same against them being a net_device, right?  This one's
particularly hairy because you'll need to keep the ppp_generic
layer the same (to interface with pppd and speak the various PPP
protocols... this will become more even more important if we do
some of the things proposed for 2.5 like ppp-layer-bridging)
I'd like to see your proposal for handling this (and I mean a
real proposal, not just "use netfilter")

Technically, while you're fixing places that have broken flow control,
you can note that the same is true of any net_device that internally
uses dev_queue_xmit.  Specifically, eql.c, shaper.c, bonding.c are
all busted in the same way you describe.  These actually could
be done with netfilter, though, so I'm more interested in the PPPoE

> I dislike extending the kernel to 'help' a few things at the expense of 
> the common path.

I don't see where you can claim to hold the high ground on "common path".