[quagga-users 12325] Re: quagga evolution ?

Gernot Schmied gernot.schmied at chello.at
Mon Jun 6 09:40:41 IST 2011

Hi Alexis,

maybe my use of English is incomprehensible, so be it, your first name
doesn't sound US or UK either, so get a life if you have nothing better
to do than picking on other folk's language skills. Anyway, it was
intended to stir up things and get a discussion going, so it served its

I did my share of quagga promotion over the years, especially among
ISPS, even wrote a book about it and the point I am making is an
operational one, an OPEX one, something an ISP operating staff can
handle and feel comfortable with, not just developers or PhD students, I
am talking mainstream ISP daily business. Maybe that surprises you, but
the regular network operator isn't a coding or Linux IP stack wizz and
neither has the time to. 

I talked a lot to small and medium size ISPs here in Europe and after
having a look at the daily business and evaluating quagga unfortunately
they decided to use Juniper or Cisco or the other usual suspects by
purely operational and deployment reasons. This also has to do with a
lot of details you have to consider assembling hardware and tuning
network stack options, besides, hardware appliances got more affordable.
Anyway, nothing one cannot handle in a design or consulting phase and
yes, I know, it is used at peering points ;-).

It would have been so easy to move quagga in a direction where it would
be a remarkable option for ISPs, it isn't there and I don't see it
heading there either. IMHO it is not converging or maybe it is just
poorly communicated that it is not supposed to ?!? Implementing every
freaky protocol field or MPLS is not what I am talking about, just
getting the basic stuff rock solid and scalable. The project maintainers
never managed to see the importance of a stable long time support branch
vs. the current way of doing it, and they never had the wisdom to call a
feature freeze and mobilize the community for heavy testing and
polishing and be done with it. Whatever experiments or chaos or
architectural changes or regressions happen in a development branch
would not hurt. The community is waiting now for years for a
psychological signal you might refer to as "quagga 1.0 stable & LTS",
that pretty much sums it up. By the way, I am no big fan of arguments
such as "it is ready when it is ready and when you don't like it or our
ways get lost".

So tell me, how many ISPs are you aware of that are using quagga for IGP
and EGP, for route reflector and so on? Some folks do looking glasses
and occasional exchange point presence and that pretty much is it. Ever
spent a minute pondering why this might be so and how little is missing
that it will accumulate critical mass, become a great success and
attract more developers? And don't tell me the usual crap about it being
"a psychological management problem that people deploy Cisco and not

Regarding "Quagga is far from perfect, but it's more than adequate for
production use in many scenarios. Which is more that I can say for quite
a lot of networking gear I've bought in the last 25 years."

Pretty vague statement and maybe poor product decisions on your
part ;-)? What szenarios are you referring to? SOHO networking?
enterprise networking? ISP? And please elaborate on your perception of
"adequate", because signaling is a high-availability issue in even the
smallest deployment scenarios.

To contribute at least something I'd like to hear the group's opinion
about moving quagga towards a virtual appliance/ISO stripped down
distro/deployment, that would offer a lot of advantages for tuning and
compile time optimization, pretty much the way vyatta was doing. What
people need is a bundle and a signal. What would also help a lot is a
hardware design guide (reference system) which I'd be willing to
contribute, but I am no expert on threading and multitasking issues, so
I'd require help. 


Am Sonntag, den 05.06.2011, 14:48 -0400 schrieb Alexis Rosen:
> On Jun 5, 2011, at 7:51 AM, Gernot Schmied wrote:
> > Everynow and then the question arises, where quagga is heading in terms
> > of a feature freeze 1.0 production release. This discussion is going on
> > now for years, still regressions and feature bloating but now
> > convergence in terms of a release that can be deployed and *supported*
> > in a production grade environment and a clear signal, that the project
> > maintainers *want* to move it in that direction.
> > 
> > Does quagga has a future in terms of acceptance or will it always be a
> > research project just the developers consider production grade? Is it a
> > problem of software project management or something else?
> If your use of English were comprehensible, it'd be a lot easier to figure out just how insulting you're really trying to be. But it seems clear that if you get any sort of answer from the devs, it's more than you deserve.
> Quagga is far from perfect, but it's more than adequate for production use in many scenarios. Which is more that I can say for quite a lot of networking gear I've bought in the last 25 years.
> /a

More information about the Quagga-users mailing list