On 5/30/2015 9:45 AM, David Lamparter wrote: > On Sat, May 30, 2015 at 02:32:36PM +0100, Paul Jakma wrote: >> On Sat, 30 May 2015, David Lamparter wrote: >> >>> Upfront was half a year ago... and we have users that would like to >>> start meshing with this. [http://patchwork.quagga.net/patch/952/] >> I don't see the VRF design discussion or multi v single daemon discussion >> there? Nor does that patch seem to depend on, or need VRF? >> >> Exhanging information on BGP-MPLS/L3VPN/$ENCAP_SCHEME_DE_JOUR seems >> orthogonal to this. > BGP L3VPN transports connectivity information for various VRFs (VPNs) > through a common BGP+MPLS backbone, using route distinguishers to tell > the VRFs apart. > > The linked patch doesn't implement any of that, yet, it just adds more > encodings to the ones we already have. bgpd had the IPv4 L3VPN support > even back in the initial import -- it just never could do anything > useful with it. It's current usefulness is just route reflectors. > > (The patch linked has the advantage of bringing this topic out of the > MPLS problem space and into areas where kernel-support exists, i.e. > IPsec & 'plain' tunnels.) > > 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.
We actually have the code to do the per-VRF import/export as well that we'd like to submit as well. One of the challenges has been how to integrate it with a testable forwarding plane. (The code was originally developed as what is essentially an NVO3 controller with a proprietary -- now DOA -- NVA to NVE, think openflow-ish, protocol). Having multiple VRF-RIB/Zebras supported in a single process will certainly be easier and perhaps cleaner integration -- keep in mind the code submitted *must* run in a single bgpd. That said, this single bgpd that does the per-VRF import/export could use an RPC mechanism per zebra process. I think both single-process multi-VRF and multi-process models have their places. The former is more scalable while the latter provides greater isolation. I view the latter as being closer to a logical system/network element than a providing a simple VRF. And as I think is generally understood, there is value in being able to support both in larger systems, and that smaller systems may only support one (or neither) type. For now, I like the idea of integrating with the patch. Of course, I may feel differently once I/we really dig into the code. Lou > > -David > > _______________________________________________ > Quagga-dev mailing list > Quagga-dev@lists.quagga.net > https://lists.quagga.net/mailman/listinfo/quagga-dev > _______________________________________________ Quagga-dev mailing list Quagga-dev@lists.quagga.net https://lists.quagga.net/mailman/listinfo/quagga-dev
