jamal wrote:
>
> On Mon, 12 Jun 2000, Gleb Natapov wrote:
>
> > jamal wrote:
> > >
> > > On Sat, 10 Jun 2000, Gleb Natapov wrote:
> > >
> > > > >
> > > jamal> > Gleb, I am afraid i didnt understand you. You mean broken
> > > jamal> > programs like DHCP?
> > > > >
> > > >
> > > 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.
By looking into the header you break the layering. Anyway what do you
expect to find there? IP, IPX or some protocol that I just wrote? How
are you going to support my protocol? Or you suppose that I should write
my own code in order to support my new protocol over VLAN ?
>
> > 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?
>
> 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 I want to run IPX in separate VLAN! How will I be able to do
that with your implementation?
>
> >
> > If answer is yes, you implementation is broken IMO.
> > If answer is no, I really want to see your code.
>
> I still dont understand why you make that claim; you'll have to wait for
> the code then.
>
Because you change IP stack implementation to suit your needs. This was
you initial argument against existing solution.
> Hint:
> 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*
Current implementation doesn't touch the common path at all (unless you
insist that many devices is a performance hit, and I don't see any
reason to have many vlans on the same network anyway).
>
> >
> > > On 11 Jun 2000, Jes Sorensen wrote:
> > >
> > > Jes> Broad support for as much as possible is good, but limiting support
> > > Jes> for the mainstream in order to improve support for something broken
> > > Jes> is wrong.
> > >
> >
> > What's limited in current implementation? We have equally good support
> > for all L3 protocols. Our code even doesn't depend on L3 protocol you
> > uses. This is the way it should be IMO.
> >
> > > Jes just hit it on the head above. Infact i am begining to believe that
> > > even if you could look up the device in one lookup, always, the
> > > architecture being used is _wrong_.
> > >
> >
> > Why? It seams to me that *you* don't provide any justification to your
> > claims.
> > Your only complain about existent implementation was theoretical
> > performance hit. What's wrong with the architecture if we have no
> > performance hit?
> >
> > "Interface" is a nice abstraction with well defined API and good support
> > in user space (ifconfig, route, ipchains, etc). You want to create new
> > abstraction for VLANs, new set of user tools new API just because you
> > can. To have unique API for every little thing looks like Windows to me.
> >
>
> 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 don't use them as the excuse, I point you on additional advantages.
> 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.
I agree with you here. VLAN should not be a device VLAN should be an
interface. I don't see what makes you think that what 'ifconfig -a'
shows are devices they are _interfaces_. Interface can be attached to
device (eth0), can be not (dummy0, lo), one interface can be attached to
many devices (bridging), many interfaces can be attached to single
device (tunneling, vlans).
>
> Perhaps the debate we are having here can be used to re-think what the
> netdevice structure should look in 2.5; as it is right now, i will totaly
> and _very strongly_ disagree with you
I see ;).
>
> cheers,
> jamal
--
Gleb.
|