[Bulk] [Xorp-hackers] Some thoughts

[Mike Horn]

Hi Tasso,

First, I want to say that I think this type of dialog is very important for
XORP to progress forward into a platform that can be run in production
networking environments.  There have been a large number of bug fixes and
enhancements recently that greatly improve XORP's deployability (thanks to
Atanu, Pavlin and team!).

I have also been testing the software and opening bugs, unfortunately I
don't write much code, so I haven't been able to contribute fixes.  I agree
that there are a number of areas that can still be improved, however I'm
pretty sure that the current interface structure can be integrated with
VRRP, tunnels, etc. but might take some additional development.

I think your ideas on using template keywords for deprecated and
incompatible commands is excellent!

-mike

-----Original Message-----
From: xorp-hackers-admin@icir.org [mailto:xorp-hackers-admin@icir.org] On
Behalf Of Hasso Tepper
Sent: Sunday, November 06, 2005 6:35 AM
To: xorp-hackers@xorp.org
Subject: [Bulk] [Xorp-hackers] Some thoughts

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
_______________________________________________
Xorp-hackers mailing list
Xorp-hackers@icir.org
http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers