On Mon, 1 Jun 2015, Lou Berger wrote:
One Zserv instance for all makes it much harder to do multiple-processes
later
I'm not sure I see this.
You have a Zserv protocol, which is an API. This API, with the proposed
patch train, is extended to add a VRF-Id field. This is so a client can
send a route and have zebra install it into the relevant VRF. Once we add
support for a given way of working, it may become hard to ever change or
remove it.
[zebra VRF 0..n]----------[client]
If you want to split zebra into multiple processes that means you have
either:
[zebra VRF0] |
[zebra VRF1] | ZServ
. |----------------------[client]
. |
. |
[zebra VRFn] |
How do you demux the messages from the client to the right zebra in a sane
way with zebra-daemon-per-VRF, if the protocol requires that it support
clients that expect to be able to send routes for different VRFs over *one
message stream* on a single socket?
(Similarly, how do these daemons mux together their messages back into a
single message stream to the client in a sane way, that doesn't negate
many of the benefits of using multiple, isolated independent processes
that might motivate this approach?)
If there isn't an easy way to do this, then the above approach would seem
to cast it into stone that we support single-daemon-for-all-VRF zebra
forever more, no?
What I'm asking is that we consider the above issue, and weight it against
the alternative of using a separate Zserv per VRF.
A separate Zserv session per VRF is easy to implement in a non-problematic
way regardless of the chosen single/multi-processing approach:
Zserv
[zebra VRF0] |-----|-----------------------
[zebra VRF1] |-----| |
. | . |[single daemon client]|
. | . | |
. | . | |
[zebra VRFn] |-----|-----------------------
or
|-----|
|-----|
[single zebra]| . | [single daemon client]
| . |
| . |
|-----|
[zebra VRF0] |-----|[VRF0 client daemon]
[zebra VRF1] |-----|[VRF1 client daemon]
. | . | .
. | . | .
. | . | .
[zebra VRFn] |-----|[VRFn client daemon]
or
etc.
I.e. no need to change Zserv. The VRF becomes implicit in the filename.
Does my concern make more sense now?
regards,
--
Paul Jakma [email protected] @pjakma Key ID: 64A2FF6A
Fortune:
A dream will always triumph over reality, once it is given the chance.
-- Stanislaw Lem
_______________________________________________
Quagga-dev mailing list
[email protected]
https://lists.quagga.net/mailman/listinfo/quagga-dev
