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

David Lamparter equinox at opensourcerouting.org
Fri May 3 13:33:19 BST 2013


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