[dev] why fork Quagga?

[Vincent Jardin]

Thanks JR.

@Carla,

It does not mean that we all agree in the "way"/"detail" things are done 
with FRR since we have different visions for solving similar problems. But 
what is important for contributors is to have a valorisation and 
integration of their innovations in a coherent manner with the others: 
accept all innovations as long as they do not hurt.

Quagga was created in 2002 because Zebra was not open enough (close in 
fact) for any innovations. Quagga was successful in creating a new momentum 
but after almost 15y an evolution was needed. Unfortunately this shift lead 
to a fork! We did try to avoid it during almost a year, but we did fail 
collectively. So based on the push and pressure of the backlogs (see JR's 
email) the only exit was a fork:
  - FRR name is owned by a 3rd party neutral  (LF was selected),
  - no money, only engineering that is focused on improving code, code rules!

I hope FRR could get more attention from more IETF folks because some 
protocols are over specified, some others are under specified, some 
protocols become vendor lockin. I hope to see more universities innovating 
with FRR (like babeld from Université Paris Diderot), I enjoy the works 
from Netdef having some people attending IETF and being involved in FRR, etc.

We see many DPDK projects around since dpdk.org was launched by 6WIND in 
2013 (fd.io from Cisco over DPDK, Contrail has been ported on DPDK by 
Juniper, NTT did launch lagopus) ; we see many networking orchestration and 
controller projects with some wide communities (ONOS,  cord,  Opendaylight, 
etc.) ; but there is a gap and lack of focus with routing protocols. So FRR 
becoming better is a must have into this networking landscape.

Best regards,
  Vincent


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.frrouting.org/pipermail/dev/attachments/20180403/d5a5d23e/attachment.html>