[Top] [All Lists]

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

To: jamal <hadi@xxxxxxxxxx>
Subject: Re: routable interfaces WAS( Re: [PATCH] hashed device lookup(DoesNOTmeet Linus' sumission policy!)
From: Ben Greear <greearb@xxxxxxxxxxxxxxx>
Date: Sun, 07 Jan 2001 22:25:41 -0700
Cc: Sandy Harris <sandy@xxxxxxxx>, linux-kernel <linux-kernel@xxxxxxxxxxxxxxx>, "netdev@xxxxxxxxxxx" <netdev@xxxxxxxxxxx>
Organization: Candela Technologies
References: <>
Sender: owner-netdev@xxxxxxxxxxx
jamal wrote:
> 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.

Yes, but VLANs are a link-layer structure too, and things like tunnels
are really link-layer too, as far as protocols using them are concerned.

With tunneling and virtual interfaces, you could conceivably do something

OC3 - ATM - Ethernet - VLAN - IP - IP-Sec - IP
as well as plain old:
Ethernet - IP

Which of these are netdevices?

(I argue that at least the Ethernet-over-ATM, VLAN, and IP-Sec entities could
profit from being a net_device at it's core.)

You argue that we should split the net_device into physical and virtual 

Perhaps you could give an idea of the data members that would belong in the new
structures?  I argue that you lose the minute you need one in both structures :)

> > 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.

MPLS can run over FrameRelay, Ethernet, and ATM, at the moment (right?).

What if you want to run MPLS over an IP-Sec link?  If you want it to
magically work, IP-Sec could be a net_device with it's own particular
member methods and private data that let it do the right thing.

> > 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.

Think also of creating sockets with SOCK_RAW and other lower-level
(but user-space) access to the net_device's methods.

> 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.

What if you had an inverse-MUX type of device that spanned two different
physical interfaces.  Then, one can go down, but the virtual interface
is still up.  So, there is not a one-to-one coorespondence.  At a higher
level, what if your interface is some tunnel running over IP.  IP in turn
can be routed out any physical interface (and may dynamically change due
to routing protocols.)

> Device goes down, you destroy them
> or send them to a shutdown state (instead of messaging) etc.
> cheers,
> jamal

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

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