Hi Paul,
See answers in-line
There has already been some remarks on the patchset about the code
itself; my believe is that they are addressed now (of course if there
is still some code that needs to be reworked, it will be done)
Can we see the ospfd changes needed? That will be the best case wrt
churn as it already went through lots of churn long ago to add (struct
ospf *) arguments everywhere.
Our OSPF patch is based on quite old un-merged quagga, it progressed in
our source tree in several steps, and due to old source management, I
fear it will be hard to extract it out properly; anyway that's something
we may have to work on, once the VRF support in zebra is settled.
That said, the current question is more about zebra, and the code churn
is easy to evaluate :)
So let's move forward !
PS: The same thing applies for some OSPF patches once proposed by
Cumulus: they are in favor on one daemon per OSPF instance (and
combined with the VRF patch should allow one OSPF per VRF), I'm more
in favor of one daemon with one instance per internal context: the use
case as we already discussed are simply not the same; I won't fight
against their approach because both make sense and they can co-exists;
They can co-exist, sure. The question is, if you have the multi-daemon
approach, do you need the single-daemon way?
I still believe so, and my feeling is based on the same use case as for
zebra single daemon: many VRF, and "almost nothing"; i.e. just a bunch
of routes in each VRF. Opposed to this, several daemons will benefit
from multi-core CPU, but the footprint will be higher: let the final
user decide according to his own use case. (Of course there will be the
ones who want many of VRF, and in each VRF many routes; they will have
to select the "least worse" option, and be prepared to suffer a bit.)
Regards
Alain
--
Alain RITOUX
Integration & Maintenance Manager
Tel +33-1-39-30-92-32
Fax +33-1-39-30-92-11
http://www.6wind.com/
http://www.6windblog.com/
===============================================================
This e-mail message, including any attachments, is for the sole
use of the intended recipient(s) and contains information that
is confidential and proprietary to 6WIND. All unauthorized
review, use, disclosure or distribution is prohibited. If you
are notthe intended recipient, please contact the sender by
reply e-mail and destroy all copies of the original message.
===============================================================
_______________________________________________
Quagga-dev mailing list
[email protected]
https://lists.quagga.net/mailman/listinfo/quagga-dev
