[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