In some cases folks choose bird, because BFD is supported.
I would like to eventually find time to abstract it a bit more and allow different solutions. Just not been high on my list of things to do.
There is nothing preventing you from downloading the PTM code and using it? donald On Wed, Apr 5, 2017 at 10:35 AM, Konstantin Shalygin <k0ste@k0ste.ru> wrote:
In some cases folks choose bird, because BFD is supported.
I would like to eventually find time to abstract it a bit more and allow different solutions. Just not been high on my list of things to do.
Nothing, except that only experts will use ptm outside CumulusLinux, network engineer just use bird. I mean BFD in frr it is not feature request for backlog. So it may be worthwhile to increase the priority. On 04/05/2017 09:35 PM, Donald Sharp wrote:
There is nothing preventing you from downloading the PTM code and using it?
There is nothing preventing you from downloading the PTM code and using it?
This is the code? https://github.com/CumulusNetworks/ptm
From that page: "It takes a graphviz-DOT specified network cabling plan (something many operators already generate) and couples it with runtime information derived from LLDP to verify that the cabling matches the specification."
Can some of this be stripped out? Or will the daemon run without this input? The documentation is a little sparse. But I did get an idea of how it works from the power point presentation. The presentation indicates the possibility for running without input. So... if I build and run that daemon, it will activate the bfd checks in frr's bgp and ospf daemons?
I mean BFD in frr it is not feature request for backlog. So it may be worthwhile to increase the priority.
Please count this as a vote for the feature request. An alternate additional option would be to make it work with the openvswitch's bfd implementation. You can always turn around and say 'pull requests welcome' ;-)
In some cases folks choose bird, because BFD is supported.
Frr looks good because of the vrf, mpls, and l2 advertisement tie-ins. So I'm not sure if bird is a suitable substitute for this. I havn't looked at their feature set in a while.
I would like to eventually find time to abstract it a bit more and allow different solutions. Just not been high on my list of things to do.
If I may ask, what is the current high profile feature people are looking for on which you are working? -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.
Inline... On Wed, Apr 5, 2017 at 12:13 PM, Raymond Burkholder <ray@oneunified.net> wrote:
There is nothing preventing you from downloading the PTM code and using it?
This is the code? https://github.com/CumulusNetworks/ptm
From that page: "It takes a graphviz-DOT specified network cabling plan (something many operators already generate) and couples it with runtime information derived from LLDP to verify that the cabling matches the specification."
Can some of this be stripped out? Or will the daemon run without this input? The documentation is a little sparse. But I did get an idea of how it works from the power point presentation. The presentation indicates the possibility for running without input.
So... if I build and run that daemon, it will activate the bfd checks in frr's bgp and ospf daemons?
That is my understanding. I believe people have gotten this to work. It is a bit outside of what I have had to deal with so far.
I mean BFD in frr it is not feature request for backlog. So it may be worthwhile to increase the priority.
Please count this as a vote for the feature request.
An alternate additional option would be to make it work with the openvswitch's bfd implementation. You can always turn around and say 'pull requests welcome' ;-)
Pull Requests are welcome from anyone/everyone. If I do have something to request out of this though is to run by your design with the Technical Meeting or send an email here for discussion :)
In some cases folks choose bird, because BFD is supported.
Frr looks good because of the vrf, mpls, and l2 advertisement tie-ins. So I'm not sure if bird is a suitable substitute for this. I havn't looked at their feature set in a while.
I would like to eventually find time to abstract it a bit more and allow different solutions. Just not been high on my list of things to do.
If I may ask, what is the current high profile feature people are looking for on which you are working?
<cumulus hat> I am working on PIM-SM. We(Cumulus) has some MPLS ( See the MPLS branch in my Forked Repo for where we are ) that I need to finish up and get into place We(Cumulus) has Type 2/3 EVPN routes( See the CumulusNetworks Quagga repo ) that I also need to finish up and get into a place that can be upstreamed. We(Cumulus) has a mpls ping/traceroute implementation that I would like to bring into the FRR, but we are in internal discussions about the approach that I originally took. <Individual Contributor> I am working on EIGRP ( See the EIGRP branch in my Forked Repo ) I'm hoping to enlist Donnie in helping me. I'll be having lunch with him next week to see if some sort of agreement can be reached. I am really interested in cleaning up the code base via refactoring. There are lots of duplicated functionality, cut-n-paste code, v4 -vs- v6 code paths that just need attention. I am interested in bringing Babel back into the repository and have started some very preliminary discussions with Juliuscz. I am sure other people can answer for themselves too :) donald
-- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.
Yes! I don't say bird better frr. I mean when BFD is needed noc choose bird, because *quagga* doe's not support this. Frrdoes not have to go the same way! At the moment, the product is just gaining popularity, so if a road map is available (Donald created frr 2.0 -> frr 3.0 on github and is good), then in the long term the first acquaintance will be decisive in most cases, I think. On 04/05/2017 11:13 PM, Raymond Burkholder wrote:
Frr looks good because of the vrf, mpls, and l2 advertisement tie-ins. So I'm not sure if bird is a suitable substitute for this. I havn't looked at their feature set in a while.
participants (3)
-
Donald Sharp -
Konstantin Shalygin -
Raymond Burkholder