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. -- Len Sorensen _______________________________________________ Quagga-dev mailing list [email protected] https://lists.quagga.net/mailman/listinfo/quagga-dev
