Hello FRR devs, I'm writing an article on FRRouting for Linux.com. I've read a number of articles on why it was forked from Quagga (for example http://www.enterprisenetworkingplanet.com/netsp/free-range-routing-protocol-... and http://packetpushers.net/free-range-routing-project-forks-quagga/) Is there anything anyone would like to add or correct? It's not a huge deal and I'm not looking for scandals. Readers will want to know the reasons for forking. It looks like the tl;dr version is 'quagga was bottlenecked by a single maintainer and development stalled'. I've also seen discussion on frrouting.org about new features and support for additional protocols-- anyone care to comment what these new things mean for network admins? You don't have to write a book, summaries like "We're working on support for Foov5, which means transferring good beer securely over untrusted networks!" are good. If there is anything else you think is cool and needs to be shared, throw that in too. I will attribute any comments that I use, so if you want to be anonymous let me know. My deadline is Tuesday evening. I know that's not much time--welcome to my world :) thanks, Carla -- ++++++++++++++++++++++++++++++++++++++++ Ace Linux guru + carlaschroder.com + Where words fail, music speaks. + ++++++++++++++++++++++++++++++++++++++++
Hi Carla, On April 2, 2018 1:37:29 PM Carla Schroder <carla@tuxcomputing.com> wrote: Hello FRR devs, I'm writing an article on FRRouting for Linux.com. I've read a number of articles on why it was forked from Quagga (for example http://www.enterprisenetworkingplanet.com/netsp/free-range-routing-protocol-... and http://packetpushers.net/free-range-routing-project-forks-quagga/) Is there anything anyone would like to add or correct? A minor point, but BigSwitch didn't play a notable role in the fork. It's not a huge deal and I'm not looking for scandals. Readers will want to know the reasons for forking. It looks like the tl;dr version is 'quagga was bottlenecked by a single maintainer and development stalled'. I'd add "and there was a desire for a project that was governed by community consensus and documented process." I've also seen discussion on frrouting.org about new features and support for additional protocols-- anyone care to comment what these new things mean for network admins? You don't have to write a book, summaries like "We're working on support for Foov5, which means transferring good beer securely over untrusted networks!" are good. If there is anything else you think is cool and needs to be shared, throw that in too. I think enhanced support for BGP MPLS L3VPN and EVPNs, for both controller and on-box forwarding models, are particularly notable. Lou I will attribute any comments that I use, so if you want to be anonymous let me know. My deadline is Tuesday evening. I know that's not much time--welcome to my world :) thanks, Carla -- ++++++++++++++++++++++++++++++++++++++++ Ace Linux guru + carlaschroder.com + Where words fail, music speaks. + ++++++++++++++++++++++++++++++++++++++++ _______________________________________________ dev mailing list dev@lists.frrouting.org https://lists.frrouting.org/listinfo/dev
If there is anything else you think is cool and needs to be shared, throw that in too.
I think enhanced support for BGP MPLS L3VPN and EVPNs, for both controller and on-box forwarding models, are particularly notable.
The EVPN has come in handy for me. As has the VRF capability. I am looking forward to experimenting with the MPLS L3VPN capability, which relies on the VRF capability. The quick pace of development is refreshing. Code seems to expand almost daily. Main line code works very well. The easy and pleasant direct access to the developers is a great bonus.
I will attribute any comments that I use, so if you want to be anonymous let me know.
-- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.
I would like to see olsr integrated. On 2 April 2018 21:03:52 CEST, Raymond Burkholder <ray@oneunified.net> wrote:
If there is anything else you think is cool and needs to be shared, throw that in too.
I think enhanced support for BGP MPLS L3VPN and EVPNs, for both controller and on-box forwarding models, are particularly notable.
The EVPN has come in handy for me. As has the VRF capability. I am looking forward to experimenting with the MPLS L3VPN capability, which relies on the VRF capability.
The quick pace of development is refreshing. Code seems to expand almost daily. Main line code works very well.
The easy and pleasant direct access to the developers is a great bonus.
I will attribute any comments that I use, so if you want to be anonymous let me know.
-- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.
_______________________________________________ dev mailing list dev@lists.frrouting.org https://lists.frrouting.org/listinfo/dev
-- Sent from my Android device with K-9 Mail. Please excuse my brevity.
Bjorn - Do you know of a implementation that was done in the past? donald On Mon, Apr 2, 2018 at 3:52 PM, Bjorn Pehrson <bpehrson@kth.se> wrote:
I would like to see olsr integrated.
On 2 April 2018 21:03:52 CEST, Raymond Burkholder <ray@oneunified.net> wrote:
If there is anything else you think is cool and needs to be shared, throw that in too.
I think enhanced support for BGP MPLS L3VPN and EVPNs, for both controller and on-box forwarding models, are particularly notable.
The EVPN has come in handy for me. As has the VRF capability. I am looking forward to experimenting with the MPLS L3VPN capability, which relies on the VRF capability.
The quick pace of development is refreshing. Code seems to expand almost daily. Main line code works very well.
The easy and pleasant direct access to the developers is a great bonus.
I will attribute any comments that I use, so if you want to be anonymous let me know.
-- Sent from my Android device with K-9 Mail. Please excuse my brevity.
_______________________________________________ dev mailing list dev@lists.frrouting.org https://lists.frrouting.org/listinfo/dev
I've heard of a couple, but would be interested if there is a preference... On 4/3/2018 4:00 PM, Donald Sharp wrote:
Bjorn -
Do you know of a implementation that was done in the past?
donald
On Mon, Apr 2, 2018 at 3:52 PM, Bjorn Pehrson <bpehrson@kth.se> wrote:
I would like to see olsr integrated.
On 2 April 2018 21:03:52 CEST, Raymond Burkholder <ray@oneunified.net> wrote:
If there is anything else you think is cool and needs to be shared, throw that in too.
I think enhanced support for BGP MPLS L3VPN and EVPNs, for both controller and on-box forwarding models, are particularly notable.
The EVPN has come in handy for me. As has the VRF capability. I am looking forward to experimenting with the MPLS L3VPN capability, which relies on the VRF capability.
The quick pace of development is refreshing. Code seems to expand almost daily. Main line code works very well.
The easy and pleasant direct access to the developers is a great bonus.
I will attribute any comments that I use, so if you want to be anonymous let me know.
-- Sent from my Android device with K-9 Mail. Please excuse my brevity.
_______________________________________________ dev mailing list dev@lists.frrouting.org https://lists.frrouting.org/listinfo/dev
_______________________________________________ dev mailing list dev@lists.frrouting.org https://lists.frrouting.org/listinfo/dev
Donald, Bjorn, Long time ago (more than 10y) we had olsrd with Quagga : https://github.com/OLSR/olsrd/tree/master/src/ We had both vty and zapi. It was good enough. We did give up because of the lack of users but this code was a good one. Le 3 avril 2018 22:02:05 Donald Sharp <sharpd@cumulusnetworks.com> a écrit : Bjorn - Do you know of a implementation that was done in the past? donald On Mon, Apr 2, 2018 at 3:52 PM, Bjorn Pehrson <bpehrson@kth.se> wrote: I would like to see olsr integrated. On 2 April 2018 21:03:52 CEST, Raymond Burkholder <ray@oneunified.net> wrote: If there is anything else you think is cool and needs to be shared, throw that in too. I think enhanced support for BGP MPLS L3VPN and EVPNs, for both controller and on-box forwarding models, are particularly notable. The EVPN has come in handy for me. As has the VRF capability. I am looking forward to experimenting with the MPLS L3VPN capability, which relies on the VRF capability. The quick pace of development is refreshing. Code seems to expand almost daily. Main line code works very well. The easy and pleasant direct access to the developers is a great bonus. I will attribute any comments that I use, so if you want to be anonymous let me know. -- Sent from my Android device with K-9 Mail. Please excuse my brevity. _______________________________________________ dev mailing list dev@lists.frrouting.org https://lists.frrouting.org/listinfo/dev _______________________________________________ dev mailing list dev@lists.frrouting.org https://lists.frrouting.org/listinfo/dev
Le 02/04/2018 à 19:35, Carla Schroder a écrit :
If there is anything else you think is cool and needs to be shared, throw that in too.
I think you should analyze the pace of patches from the git's repos, for the features and for the bug fixes integration. Frankly, no-one likes forking (code and community!), but sometime it helps to reorganize some projects with some different visions. Look in the past to the *BSD for instance... Then, it can be good to have some forks: each fork can be a sandbox with some different models of organizations. Down the roads, any "goods" (protocols, design improvement, tools, etc.) from any "forks" get usually cross merged. best regards, Vincent
Combining the former articles with Lou and Vincent's comments is pretty telling. Due to circumstance, there was a VERY large backlog of outstanding patches against Quagga at various companies/institutions. The group was interested in both getting through that backlog as well as creating a fast paced, community oriented project, and the output and nature of the project are a reflection of the developer's efforts. On Tue, Apr 3, 2018 at 2:07 AM, Vincent JARDIN <vincent.jardin@6wind.com> wrote:
Le 02/04/2018 à 19:35, Carla Schroder a écrit :
If there is anything else you think is cool and needs to be shared, throw that in too.
I think you should analyze the pace of patches from the git's repos, for the features and for the bug fixes integration.
Frankly, no-one likes forking (code and community!), but sometime it helps to reorganize some projects with some different visions. Look in the past to the *BSD for instance... Then, it can be good to have some forks: each fork can be a sandbox with some different models of organizations. Down the roads, any "goods" (protocols, design improvement, tools, etc.) from any "forks" get usually cross merged.
best regards, Vincent
_______________________________________________ dev mailing list dev@lists.frrouting.org https://lists.frrouting.org/listinfo/dev
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
Thanks everyone, this is all great feedback. Anyone else who wants to chime in, you have until 6pm PDT today. It's good to see so much energy going into a vital bit of software. best, Carla -- ++++++++++++++++++++++++++++++++++++++++ Ace Linux guru + carlaschroder.com + Where words fail, music speaks. + ++++++++++++++++++++++++++++++++++++++++
participants (8)
-
Bjorn Pehrson -
Carla Schroder -
Donald Sharp -
JR Rivers -
Lou Berger -
Raymond Burkholder -
Vincent Jardin -
Vincent JARDIN