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
On Fri, 29 May 2015, Lennart Sorensen wrote:
multiple VRFs but can also be run as multiple processes would make
everyone happy, although it does mean there are two ways of running
things that would have to be supported in the code.
My worry is more whether the two approaches be supported
On Sat, May 30, 2015 at 09:34:04AM +0100, Paul Jakma wrote:
On Fri, 29 May 2015, Lennart Sorensen wrote:
multiple VRFs but can also be run as multiple processes would make
everyone happy, although it does mean there are two ways of running
things that would have to be supported in the
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
On Sat, 30 May 2015, Paul Jakma wrote:
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
Agreed.
Andrew
Donald Sharp sha...@cumulusnetworks.com wrote:
I think that a single daemon approach is the way to go. Code churn, memory
pressure, more complicated startup/stop scenarios, and lots of work that can be
done to improve daemon performance don't lead me to believe that I think
