Received: by oss.sgi.com id ; Fri, 2 Jun 2000 08:04:36 -0700 Received: from cx97923-a.phnx3.az.home.com ([24.9.112.194]:64525 "EHLO grok.yi.org") by oss.sgi.com with ESMTP id ; Fri, 2 Jun 2000 08:04:12 -0700 Received: from candelatech.com (IDENT:greear@localhost [127.0.0.1]) by grok.yi.org (8.9.3/8.9.3) with ESMTP id IAA32352; Fri, 2 Jun 2000 08:40:59 -0700 Message-ID: <3937D58B.708AE7F8@candelatech.com> Date: Fri, 02 Jun 2000 08:40:59 -0700 From: Ben Greear Organization: Candela Technologies X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.14-5.0 i586) X-Accept-Language: en MIME-Version: 1.0 To: jamal CC: netdev@oss.sgi.com, buytenh@gnu.org, gleb@tochna.technion.ac.il Subject: Re: 802.1q Was (Re: Plans for 2.5 / 2.6 ??? References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-netdev@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;netdev-outgoing jamal wrote: > > > I just scanned through the other code and this is _exactly_ what i had in > mind. ccing the authors incase they are not in the list. > Their scanning algorithm certainly needs improvement I'm confused: You like their implementation better, though it needs improvement? or it is wrong just as you expected?? If it is the former, could you enlighten the discussion with what you like better about theirs? If unification ever happens, it would be best if we took the best from both... > > A VLAN should look just like an ethernet port. I **WANT** it to look > > exactly like a device, so why not actually make it one?? I want to > > use tcpdump on it, > > Modify tcpdump to do Vlan recognition (if it doesnt already). Not so hard, but consider how much more friendly tcpdump -i vlan0005 is than tcpdump -ben_hack_foo 5 eth0 The same holds true for every other program that interacts with (logical) devices. > > > I want to route, firewall, bridge and do everything > > else that a device would do. > > VLANs are primarily for switching. Fair enough that you want to route > them. But you can certainly still do this with policy routing for example. > The only place i see routing taking effect is in the boundary between > VLANs and non-VLAN domains. In applications that people are using my code for, I've heard of NO ONE switching, and everyone is using the interfaces for traffic management (ie routing, firewalling, etc..) The truth is that dedicated hardware switches much better (ie a 10/100 etherswitch). However, routing and other cool stuff is handled better (or at least much cheaper) by Linux.. > Again from the above, you really dont need a device. I think this is just a matter of taste at this point. I dissagree with your assumption. I wrote VLAN because it could solve problems that I saw in managing DSLAM (DSL) installations, and that definately needs the VLANs to be able to firewall and route. I see no reason to limit what people can do with VLANS, and I have little desire to patch 50 different tools that work with interfaces to have special handling for VLANS. > Use a table or whatever structure (radix tree etc); allow search by > VLANid, priority etc; I have an array of 4096 entries, one per VLAN ID. Wastes a little memory, but gives constant time lookup. In the case of VLANs being able to be duplicated across physical devices, there is one array per physical port. > With these you are free to put whatever search schemes, naming conventions > etc that you want instead of subjecting the rest of the kernel to > something that you need for your feature. What have I subjected the kernel too? The only part of my code that touches the existing kernel is some in the eth.c to detect VLAN, and some other structure changes to allow for bigger ethernet headers... > 1) Fix pppd. Paulus is planning on a total re-write (i think you were > copied on that email) 2) allow for multiple channels per device. > With the new pppox architecture, you can then have a single socket > selecting/polling for multiple circuits. So, what about routing between circuits? Firewalling? People don't write generalized code (ie making them all devices) for no good reason.... Thanks, Ben -- Ben Greear (greearb@candelatech.com) http://www.candelatech.com Author of ScryMUD: scry.wanfear.com 4444 (Released under GPL) http://scry.wanfear.com http://scry.wanfear.com/~greear