[Xorp-hackers] Some thoughts

Hasso Tepper hasso@linux.ee
Sun, 6 Nov 2005 15:35:20 +0200


I have been looking through current state of Xorp project, made some
tests and reported some bugs (more to follow hopefully) and read quickly
through hackers list with hope that I can use Xorp as base of some
inhouse platforms in long term. Here are some of my thoughts.

Interface handling.

Xorp ignores runtime address/interface deletes/adds from OS and users
have to configure all interfaces in Xorp. As I understand it, it's done
by design and I remember some of developers saying that it will not
change as main focus of Xorp is research platform. It prevents to use
Xorp as software for production in many cases (including mine, seems).
But this requirement is IMHO strange even for research platform:

* You have to configure even IPv6 link local addresses which is business
  of underlying stack and out of users control in every platform I know
* It doesn't allow to use Xorp together with software which modify
  addresses and routes - high availability stuff for example (vrrp, carp
  etc.)

Ability to configure nonexistant (yet) devices is must be as well (in the
cases like hotlug, tunnels etc.) in any production system. If device will
appear, it will be configured by Xorp.

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

Configuration handling

I have read through threads in list and object strongly to ideas to have
functionality to rewrite configuration by new version to be compatible.
Nothing like this should happen in routers I maintain ;). My idea to
define behaviour to deal with deprecated and incompatible changes via
template keywords:

%deprecated - Using this command is not recommended any more, but
software still handles this. It's hidden in CLI (doesn't appear in
possible completions list) and if used by user, comment is added to the
configuration - "use xxx instead". With clearly defined deprecating
mechanism it gives good way to handle just syntax changes gracefully. For
example "deprecated command is there for one stable version and will be
removed after that".

%incompatible - Software doesn't handle this construct any more. There
should be way to parse configuration before executing (restart) the new
software and to give error in these cases (and in case of just error) -
"This construct will be ignored by version you are upgrading to."


Anyway, project looks very promising and I hope to contribute at least
via bugreports in the future as well. And I'm sure that at least one Xorp
install will stay there in my lab.


with my best wishes,

-- 
Hasso Tepper