[Top] [All Lists]

Re: routable interfaces WAS( Re: [PATCH] hashed device lookup(DoesNOT

To: Ben Greear <greearb@xxxxxxxxxxxxxxx>
Subject: Re: routable interfaces WAS( Re: [PATCH] hashed device lookup(DoesNOT meet Linus' sumission policy!)
From: jamal <hadi@xxxxxxxxxx>
Date: Sun, 7 Jan 2001 19:37:30 -0500 (EST)
Cc: Sandy Harris <sandy@xxxxxxxx>, linux-kernel <linux-kernel@xxxxxxxxxxxxxxx>, "netdev@xxxxxxxxxxx" <netdev@xxxxxxxxxxx>
In-reply-to: <>
Sender: owner-netdev@xxxxxxxxxxx

On Sun, 7 Jan 2001, Ben Greear wrote:

> Hrm, what if they just made each IP-SEC interface a net_device?  If they
> are a routable entity, with it's own IP address, it starts to look a lot
> like an interface/net_device.

As in my response to Matti, i thing a netdevice is a generalized link
layer structure and should remain that way.
To add a new naming convention a "link" or maybe an "interface"
is what the protocol aware part should be.
Define a routable "interface" to be  one that (from an abstraction
perspective) sits on top of a netdevice and has a ifindex, name, and IP
address (v4 or V6)
I think the goals of the author of that IPSEC article are served with this
scheme. I need to read that article, i just schemed through it.

> This has seeming worked well for VLANs:  Maybe net_device is already
> general enough??

I think it is not proper to generalize netdevices for IP. I am not
thinking of dead protocols like IPX, more of other newer encapsulations
such as MPLS etc.

> So, what would be the down-side of having VLANs and other virtual interfaces
> be net_devices?  The only thing I ever thought of was the linear lookups,
> which is why I wrote the hash code.  The beauty of working with existing
> user-space tools should not be over-looked!

IP configuration tools you mean. Fine, they should be used to configure
"interfaces" in the way i defined them above.

> It may be easier to fix other problems with many interface/net_devices
> than cram a whole other virtual net_device structure (with many duplicate
> functionalities found in the current net_device).

It makes sense from an abstraction and management perspective to have all
virtual interfaces which run on top of a physical interface to be
managed in conjuction with the device. Device goes down, you destroy them
or send them to a shutdown state (instead of messaging) etc.


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