On Mon, 12 Jun 2000, Mitchell Blank Jr wrote:
> 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.
And i never 'broke' this requirement.
> Only your IP-centric solution doesn't handle this very well.
But "IP centric" is the main requirement! again, i really fail to see how
i break the traffic isolation requirement.
> > 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.
Look at James Leu's MPLS code for starters.
> Still, I don't see it as relevant to the VLAN discussion.
IP centrisim. Its all about IP, she said.
> 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)
If it is a packet mungler it is a packet mungler, it is a packet mungler.
Dont try to call it anything else, it wont change the facts. I seen VLAN
as such. The major reason any of the arguements i have seen presented here
end up using the user space tools is because they want to associate things
with IP; they need to attach an IP address etc. So if that equates to
something being a net_device then you are right. But you have argued
against that citing ATM.
As you mentioned in your earlier email, we might need to abstract things
out better and tame net_device a little. we can probably resolve this
then. I am just concerned about now.
> 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")
I thinking shunting (or bridging) between protocol blocks cant be
solved by netfilter; but netfilter can probably be extended.
With the curent pppox (Look at Michal's code) the main "device" problem
you refer to is caused by pppd's lameness. You should easily be able to
send several pppoe sockets/circuits across the same ppp "device";
just ioctl attach them.
We can work towards a better solution. Michal and I already talked about
this. He points to the BSD solution; i think we can do better.
> 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
Lets talk about it at some point. Although code speaks louder, some times
it is safer to solve a problem like this by having some design. Its
definetly a 2.5 thing. I think we need to have a "real" proposal as you