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