On 12/10/2014 10:03 PM, Paul Jakma wrote:
Yeah, I remember when that was added in GNU Zebra days. Lot of churn.
I had assumed back then multi-instance support was going to follow,
but it never did.
It's my memory of that churn that makes me a bit resistant to
N-instance-in-1. However, for ospfd, if the price has already been
paid and VRF can build on that without further churn, maybe...
Tthere's still the config story though. I'd hate to end up with VRF
config relating a protocol instance to VRFs potentially in both the
config file of a VRF management daemon (to manage what processes
handle what), and also in the config of a daemon (if it's handling
multiple VRFs in one 1).
If you can allay that fear, that'd help too.
regards,
Hi Paul,
Have you seen in the patch of OSPF multi-instance from Cumulus?
An individual daemon is already started for an instance. Hence
we would think there would be only a little code to handle the
instance related stuff within the instance (except the redist
commands). But it is not. For examples:
- The instance ID is added to lots of commands, and is used to
check whether the instance is the correct instance;
- All commands under the "router ospf" context now need to check
whether the current instance exists.
I would say, that's another type of churn. Maybe it is not so
much as managing multiple instances in one daemon, while would
be at the same level, I think.
Well, if it was decided to forbid the idea of multi-instance in
one daemon, I would suggest to use some other way to manage the
daemons, trying to minimize the instance-ID-sensitive within
the code. But I will not, because that's just the first step to
handle multiple instances in one daemon. ;)
What I want to say is - please release the fear to churn. Just
do it, if people need it. :)
Best regards,
Feng Lu
_______________________________________________
Quagga-dev mailing list
[email protected]
https://lists.quagga.net/mailman/listinfo/quagga-dev
