On 12/10/2014 05:11 AM, Paul Jakma wrote:
On Mon, 8 Dec 2014, David Lamparter wrote:
On Fri, Dec 05, 2014 at 10:04:47AM +0800, Feng Lu wrote:
The main discussion is around which is better, N-in-1 or 1-for-1?
While, many comments indicate the preference with support from only
experiences.
My question is: why not both?
Because making a protocol daemon do N-vrfs-in-1 will very likely
involve a lot of internal churn to the code + incur an ongoing
maintenance cost. If instance-per-VRF avoids some of those costs, why
then still take them on?
Hi Paul,
I think there's no need to worry about that.
(1) 6WIND has already the patches to support multi-VRFs-in-single-daemon
for zebra/ospfd/ospf6d/ripd/ripngd/bgpd. The patches, which supports
multi-VRFs in only zebra I sent to the list, is just the first stage
of the series.
Once the patches are merged, 6WIND will contribute to the maintenance.
(2) I think, what's more important for a software is more ease to users,
rather than more ease to coders.
If we must choose one of two approaches, which is better? That's just
what Iwant to make clear in the original email "1-daemon-per-inst vs.
all-inst-in-1-daemon".
From users point of view, with having the same complexity in cfg,
one would take 10 times amount of memory than the other one, which
would be better?
(3) Well in fact, we really don't need to choose only one of them. :)
They are for different use case.
The Cumulus patch makes the routes from the multiple OSPF instances
comparable. If they advertise the same prefix, only one of them can
be installed into the system.
The 6WIND patch makes the routes from the multiple OSPF instances
completely separated. The system has separated forwarding tables
to hold the routes from the corresponding OSPF instance, no matter
the prefixes are some or not among the instances.
(4) Would you please look into the OSPF code? I believe that the code
is designed to *handle multiple instances in only one daemon*. :)
I can show the proof:
- The struct ospf_interface and ospf_area both have a member:
struct ospf *ospf
If there's only one instance, what's the use of it?
- Nearly all functions can access the working instance (except that
it does not need), by having a parameter of *ospf/*area/*oi (the
*ospf can be obtained from *area/*oi).
If there's only one instance, that parameter is extremely redundant.
- The struct ospf_master has a member, which is showing the truth: :)
struct list *ospf
I could maybe see zebra and bgpd supporting vrfs (bgpd more than zebra
probably), but OSPF just doesn't make sense to me.
In some cases, users may need separated forwarding tables, where the
routes are learnt from OSPF(v3) (or other protocols).
Running protocol daemons in multiple VRFs can meet their needs.
Wwe also need at least a plan on how to support UI/config for VRFs.
Yes, I completely agree.
Supporting muliple approaches may make that more complicated.
As I explained above, the patches from Cumulus and 6WIND are different
in use case.
And please think of the shortage of starting a daemon for each instance
as I have explained in the email, the best status I can find is to
have both the approaches as I suggested.
Thanks and best regards,
Feng Lu
_______________________________________________
Quagga-dev mailing list
[email protected]
https://lists.quagga.net/mailman/listinfo/quagga-dev
