[Top] [All Lists]

Re: 802.1q Was (Re: Plans for 2.5 / 2.6 ???

To: jamal <hadi@xxxxxxxxxx>
Subject: Re: 802.1q Was (Re: Plans for 2.5 / 2.6 ???
From: Ben Greear <greearb@xxxxxxxxxxxxxxx>
Date: Mon, 12 Jun 2000 09:14:25 -0700
Cc: Gleb Natapov <gleb@xxxxxxxxxxx>, Gleb Natapov <gleb@xxxxxxxxxxxxxxxxxxxxx>, Mitchell Blank Jr <mitch@xxxxxxxxxx>, Andrey Savochkin <saw@xxxxxxxxxxxxx>, rob@xxxxxxxxxxx, buytenh@xxxxxxx, netdev@xxxxxxxxxxx, Jes Sorensen <jes@xxxxxxxxxxxxx>
Organization: Candela Technologies
References: <Pine.GSO.4.20.0006120900170.1871-100000@xxxxxxxxxxxxxxxx>
Sender: owner-netdev@xxxxxxxxxxx
jamal wrote:
> On Mon, 12 Jun 2000, Gleb Natapov wrote:
> > jamal wrote:
> > >
> > > On Sat, 10 Jun 2000, Gleb Natapov wrote:
> > >

> > > Gleb > No, I mean IPV6, IPX, DECnet, appletalk etc.
> > >
> > > This is a very strong statement that you make above. You have
> > > to provide justification. The protocol type is still available on the
> > > header. how is any of the above protocols broken?
> >
> > I _never_ said they are broken! What I've said is that you will need to
> > add explicit support of VLANs in each one of these protocols (if I
> > understand correct you suggestion).
> >
> And this is what i was refering to as you saying "broken" ;->
> small miscomunication ..
> If you can uniquely distinguish each protocol from looking at the header,
> how can the implementation be 'broken'? Thats was my question to you.

So now the plan is to basically break all protocol layering in the
kernel and hack little pieces of VLAN support into every layer three

To summarize, the current VLAN scheme requires these changes:
1.  Rewrite the device lookup methods.
2.  Add the soft VLAN device code (done, twice).
3.  Small user-level config program (vconfig, for example).  Done.

NOTE:  The above solution has not been, IMHO, shown to have any
serious performance hits in the critical path.

The Jamal/Jes solution requires:
1.  Change IPv4
2.  Change IPv6
3.  Change ip and/or ifconfig
4.  Change route
5.  Hell, change every other user-level program that needs to use VLANs
    like they are devices.
6.  Change every other layer 3 protocol that will be supported by VLAN.
7.  Test a million different ways.
8.  Fix DHCP and others that bind to specific devices, and may now want
    to bind to VLANs.
9.  And for what gain?

> > Answer me this question: are you going to change something in net/ipv4/
> > directory in your VLAN implementation?
> The main requirement seems to be to be able to 'route' -- thats what about
> 90% of the arguements here seem to be saying. 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 the other 10% that always kills you.  I don't even understand your
argument for IPX.  Isn't linux supposed to be able to route/switch IPX?
You'd be taking that away and asking that it be done somewhere else?

Oh, and when we get bridging working, will your implementation allow us to
add VLANs to PPP (bridging ethernet) devices?  That is something we may want
out of whatever VLAN implementation survives...

> if you are asking whether i'll put files in net/ipv4/ or ipv6; yes
> indeed, i might but not necessarily so. I see little or zero changes to
> the current common case of routing IPV4/6 packets. Why would i wanna touch
> IPX code?

Because you just brok it w/regard to VLANs, eh?

> And this is based on the simple fact by trying to make all those tools a
> swiss army knife is wrong. Trying to use them as _the_ excuse is wrong.
> I dislike extending the kernel to 'help' a few things at the expense of
> the common path. I would rather extend the user space tools or even
> re-write them. I dont claim to be a purist, but certainly i think that a
> VLAN should be abstracted on a device and is therefore not a device.

So rather than stick a small shim (another device on a device) into the
stack layers, you are going to stick pieces of it all over the place?
How does that make architectural sense?

What is wrong with generic code?  Note that NO changes had to be made
to the swiss-army knife programs, they just worked, magically!  I
don't think we have any additional costs to the common path, even w/out hashed


Ben Greear (greearb@xxxxxxxxxxxxxxx)
Author of ScryMUD: 4444        (Released under GPL)     

<Prev in Thread] Current Thread [Next in Thread>