On Sat, May 30, 2015 at 03:32:19PM +0100, Paul Jakma wrote: > On Sat, 30 May 2015, David Lamparter wrote: > > To get to actual use, all of these protocols mandate some level of > > single-process multi-VRF support at least in bgpd. A "maximum split > > process" approach would need to demultiplex the data from one bgpd onto > > different zebra processses. > > Or just speak BGP-over-AF-Unix between the bgpds, with some tweaks to make > such 'internal' sessions more auto-magic. (Which could also help with > applying divide-and-conquer to tame other scaling issues - already > possible today by running multiple bgpds with manually configured peerings > locally between each). > > Even if BGP is special and one bgpd is preferred, you could easily > teach it to speak ZServ to multiple zebras, and direct routes to the > relevant socket based on RD. So it isn't at all clear it /requires/ > the single-daemon VRF patch and can only be fulfilled by the > single-daemon patch. > > So it doesn't look like this design discussion was held before,
I think the "design discussion" has concluded. We want both in-process as well as split-process VRFs. That's all we need to know, the remainder should IMO not be designed but engineered. As such, I'd mark the entire field as experimental (i.e. we won't care about API or CLI breakage for VRFs), and let the bright people on this list apply their engineering chops to it. If some patchsets are badly engineered, we can point out those specific engineering issues at that occasion. For all we know, we can later chop off the variants that didn't end up useful much. We're playing a puzzle game with a bunch of pieces here, the best way to find out what the picture looks like is to actually put the pieces together. And nothing prevents us from taking pieces back out and putting them somewhere else. NB: for the sake of non-VRF user stability, the VRF patches should therefore be "invisible" in CLI config-write, to ensure we're not corrupting their config. I haven't checked that yet. > nor is that patch a user for this patchset, at this time? cf. Lou's mail, the code depending on the VRF patchset is waiting in the pipes. Cheers, -David _______________________________________________ Quagga-dev mailing list [email protected] https://lists.quagga.net/mailman/listinfo/quagga-dev
