[Xorp-hackers] Some thoughts
Mark Handley
M.Handley@cs.ucl.ac.uk
Sun, 6 Nov 2005 21:13:20 +0000
On 11/6/05, Hasso Tepper <hasso@linux.ee> wrote:
> Interface/vif concept is a little bit strange as well - ie. mostly naming
> decision. Forcing to use just the same name of vif by default is bad
> enough. What "show interface fxp0" shows to me? Interface or vif? It
> might not be so important at the moment, but I'm almost sure that there
> will be cases in future when it matters. And how to fit existing vlan
> naming schemes in unixes to that model? It might sound lame (how many
> times it was written in this list? ;), but I really think that Junos way
> is better in this respect - <physical>.<vif> and vif define vif 0 as
> special - vif directly on top of physical interface without any virtual
> device in system.
> (I know that it doesn't solve any problems for systems where virtual
> interface naming scheme doesn't contain any link to physical interface
> though.)
This is another area where there is no good solution.
The standard Unix naming scheme sucks, and was a hack to retro-fit
virtual interface naming into a framework that was intended only for
physical interface naming.
Juniper's naming scheme is the ideal. But they re-wrote the
networking stack, and we only get that luxury when we run on click,
which we don't want to mandate. We couldn't do this and run on a
stock Unix forwarding path.
So, the compromise is what we ended up with. We have the
physical/virtual split being explicit, which allows properties of
physical interfaces to be dealt with as a whole, and provides an
appropriate framework for dealing with things such as creating VLANs
or ATM VCs on a physical interface (where we have a forwarding path
such as click, and control over naming). But we also have a namespace
(VIFs) which can directly map to Unix interface names when we're
running on regular Unix kernels.
It may seem a bit odd, but the requirements are a bit odd too.
Cheers,
Mark