[quagga-dev 10519] Re: Adding "encapsulation dot1q" option to interfaces

Adrian Ban bluelightning at mantech.ro
Fri May 3 15:00:25 BST 2013

Well .. Thanks for suggestion!
This is a good idea. Maybe will be more coding to build another daemon but 
I will start from quagga daemons.
If this kind of setup fits with your design is fine to me.

I will start to build this daemon. Also you can move the remaining commands 
that are non-routing related to this daemon too and leave the core of 
quagga only for routing part.

Best regards.

On May 3, 2013 3:33:19 PM David Lamparter <equinox at opensourcerouting.org> 
> On Fri, May 03, 2013 at 03:20:52PM +0300, Adrian Ban wrote:
> > Ok, I understand. Thanks for supporting.
> > I will add patches to my own Quagga tree and I will add to the git-hub if 
> anybody doesn't have  anything against this solution naming the tree 
> something like this: quagga-SOMETHING.
> > I will try to keep up the patch for each Quagga release.
> > The bad part is that the distributions will never benefit for this features.
> There is actually a reasonable middle path here I think - make it a
> separate daemon within the Quagga daemon herd.  That way it can use the
> vtysh architecture, library code, and probably reuse code from zebra
> too.  It might be a little more work, but it's nicely isolated, you can
> switch it on/off, and if the code is good and well-maintained I believe
> we can merge it into mainline Quagga.  Call it grévy, to test OS support
> for UTF-8 process names ;).
> In the long run I believe we should modularise the Quagga CLI and
> configuration architecture anyway - in both daemon and user direction.
> Having other software components in the same fold (think ethernet,
> bridge, VPN, etc. config) would be good user interface as well as adding
> other ways to access the fold like better scriptable command-line tools
> (better "vtysh -c") and maybe interfaces to other parts of the system
> (stuff like configuration RPC and/or NETCONF).
> However, that's a rather large project and might fall to the inner
> platform effect.
> -David
> > On 5/3/2013 3:03 PM, James Carlson wrote:
> > > On 05/03/13 01:51, Adrian Ban wrote:
> > >> There is somewhere a documentation about Quagga which says that adding
> > >> interface functions are outside the scope? I'm curious where is written.
> > >> If other Quagga users will ask to add those kind of new features will be
> > >> refused by Quagga maintainers as well because is outside the scope even
> > >> the features will be fully complained with* **Unix platforms,
> > >> particularly FreeBSD, Linux, Solaris and NetBSD** *?
> > > Well, the good news is that there's a third zebra species name that's
> > > still up for grabs -- Grevy.  There for the taking by anyone who feels
> > > that another fork is necessary.
> > >
> > > For what it's worth, I agree with the maintainers.  It's well out of
> > > scope of routing protocols, and a serious pain to maintain per platform.
> > >   The Quagga command line is not actually the Cisco command line, and
> > > dumping the kitchen sink into it in an attempt at convergence sounds
> > > like a bad plan for Quagga.  It may make sense for some users, but can't
> > > be good for the project.

More information about the Quagga-dev mailing list