Lennart, I agree. I Kinda made the same statements in earlier emails.
I also don't have a strong opinion against moving VRF
creation/management to a new daemon.
Unlike other protocol daemons that need to be replicated across
different VRFs creating a scalability concern on
some platforms, a VRF daemon is only one so the overhead is fixed.
Another point of information/discussion which might affect scalability
at the network level,
What is the effect of VRFs on protocol messages? take ospfd for example,
does it need to
send independent protocol packets for every VRF it has? or can some of
them be combined?
Do we need hello packets per physical router? or per VRF? wht about
other types of packets? etc...
--Jafar
On 5/28/2015 10:45 AM, Lennart Sorensen wrote:
On Thu, May 28, 2015 at 03:36:30PM +0100, Paul Jakma wrote:
Hi Vincent,
I still have some stuff I need addressed, to be "sold" on.
First off, we need to discus the end-destination. As it may be very
difficult, if not impossible, to agree on the next step if we're not
agreed on the destination.
There seemed to wide agreement that in a perfect world we'd have a
RIB for each VRF/netns, and each instance of a protocol, in a
separate process. Indeed, you might want further separation (e.g.
each AFI/SAFI RIB in a different process, as there's next to no data
sharing between them).
The major obstacle to this is that our config/control code and UI
are currently too directly entwined. That needs fixing one day.
The destination then is to have a collection of processes, that
scales out with VRFs and/or protocol instances, peers, etc. I would
imagine there would be /one/ process there to add/destroy/create
VRFs and associated daemons, and that it'd be separate from the RIB
task in the VRF and other protocols.
Are we on the same page with that? Or is there disagreement there?
As someone working on small embedded level boxes without lots of cpu
cores, the separate process per VRF is not desirable at all. One process
with one config interface running in multiple namespaces is ideal for us
(and in fact what we are currently working on doing).
If someone wants to support multiple processes as well, that's fine,
as long as it works with a single process too for those that are not
interested in the multi core scalability and associated overhead of
multiple processes.
If on the same page:
The next question how this patch set affects the distance to the
desired state. If we're at A and ultimately want to get to B, then
is this getting us directly there (great!)? Or is it perhaps at a
slight angle from the straight path, a slight detour but still
generally decreasing the distance to B? Or is it at right angles or
greater - increasing the distance?
Now we have to try make this specific, to try get some kind of
objective technical handle on how to assess this:
The first specific issue is whether commands added suit the destination:
I've looked through the code and the commands added look like
if/when we fix the config/control/rendezvous issues, and are able to
try split VRF management from 'zebra' into a VRF management daemon,
then the command definition should still be fine.
So that's good, that's getting us closer to the destination.
(Though, I wonder, why not just /start/ by putting the VRF code in a
dedicated VRF management daemon?)
Background: Note that it is already possible today to run
zebra+protocol daemons one-set-per-VRF/netns. You can write a script
to setup the VRFs and inter-VRF interfaces and it works. For each
VRF you launch zebra and the client daemons for that VRF with a
VRF-specific Zserv path.
The next specific issue is how is this going to interact with client
daemons?
Your patch-set does this by making VRF part of ZServ. Every client
must now become VRF-aware, even if to set the VRF-Id.
However, couldn't this also be accomplished by simply having a
separate ZServ socket for each VRF? The socket for the default VRF
having the (existing) default path? No client mods needed?
Doing it inside the 1 ZServ socket can only serve adding multi-VRF
to client daemons. I will have major concerns about taking such
patches though.
We've not been given a use-case for single-daemon/multi-instance.
Note that protocol-daemon per netns _already_ works today. So what
reason will we have in the future to accept multi-VRF-single-daemon
patches, to take on that level of churn and maintenance needs - when
the use-case will already be covered?
Without multi-VRF-single-daemon, there is no need to have ZServ
support VRF Ids.
Indeed, even with multi-VRF-single-daemon, it might still be better
to have 1 ZServ protocol instance/socket per VRF. It would then be
easier later to split up the zebra side into per-VRF processes.
It makes configuration management from another process much more work.
That's why we aren't doing that.
---
So in summary, the issues I have:
* Why not have VRF setup/management separate from zebra? A single VRF
management daemon, then dumb (zebra+client daemons)-per VRF (already
somewhat possible now with scripts)?
Because of the overhead of extra processes and complexity in managing
the config of those processes. Some of us are not going to go there,
so if quagga as a project decides to go that way, we may be stuck on
our own private branch forever which would suck.
* Doing it with one ZServ socket assumes that Quagga will want to support
single-process (certainly single-peer) multi-VRF daemons. Why is that
latter point attractive when we can already cover the VRF use-case with
existing VRF-unaware-daemons-per-VRF?
Basically, my problem is that if I sign up to this zebra multi-VRF
patch, am I signing up for later immense amounts of churn in the
routing client daemons, for a use-case that does need the
client-daemons to be modified?
Note: I'd sign up for a simple VRF management daemon, with
VRF-specific ZServ paths, in a jiffy.
_______________________________________________
Quagga-dev mailing list
[email protected]
https://lists.quagga.net/mailman/listinfo/quagga-dev
