On Wed, 20 Jan 2016, Vincent JARDIN wrote:
Paul, both are possible:
a- you can have 1 single process that handles all VRF
b- you can have 1 process per VRF
and both can be mixed a+ and b+ , which means that a subset of VRF is
managed by 1 zebra daemon.
It depends how you'll use the OS's VRF and netns features and how
you'll want to build your policy routing between the VRFs.
Both are possible. However:
- you have to design to allow for separation, or else the design may
make separation impossible.
E.g., it is _really_ difficult for multiple distinct processes to read
messages off the same socket in a way that scales. So a design that
bakes in a single-socket APIs makes separation harder.
- A separated design can be implemented either way, sure. However, is it
advisable to try support both ways in _one_ project?
And I have seen no attempt to try design this in a way that works either
way. Just on the socket API, it seemed to take a lot of arguing just to
get people to even consider that there needed to be a publication step
to avoid a single-socket-for-all assumption. Maybe that was partly my
fault for not explaining the detail of the concern well enough, but I
think it was equally an issue of a lack of upfront consideration of
separation.
(And there are other Zserv clients out there, and they can be really
hard to find out about, so it'd be good to be careful about breaking
ZServ).
Sorry to bang on about this, but I think it's important, so I will. :)
Show me that the design explicitly aims to support responsibilities that
can be separated and divided across processes, then I'll be less
agitated on this.
regards,
--
Paul Jakma [email protected] @pjakma Key ID: 64A2FF6A
Fortune:
Freedom's just another word for nothing left to lose.
-- Kris Kristofferson, "Me and Bobby McGee"
_______________________________________________
Quagga-dev mailing list
[email protected]
https://lists.quagga.net/mailman/listinfo/quagga-dev
