[dev] FRR North bound API

anzal mohammedanz at gmail.com
Tue Nov 20 00:33:53 EST 2018

Hi Philippe,

Thanks a lot for your insights.

I happened to glance over a report regarding the performance of the ODL
southbound netconf interface. Please see


I do understand that optimizations will be needed in the path you referred

odl client <---> netopeer server <---> sysrepo server <---> bgp/zebra server

But wouldn't this report justify that a yang based model can help with
cases of handling 10K prefix updates.

What are your thoughts.



On Sat, Nov 17, 2018 at 1:56 PM Philippe Guibert <philippe.guibert at 6wind.com>

> Hi Anzal,
> I agree with your proposal, with some concerns however.
> I presented a few weeks ago at FRR weekly meetings, some slides about
> what would be the mechanisms involved for an SDN controller to be able
> to use FRR as BGP speaker. ODL can be the target, obviously. See in
> [0]
> The yang solution applied to BGP northbound API has been proposed.
> However, there were two remarks:
> - on the data exchanged between SDN and FRR.
> What was ok was for configuration ( BGP, VPN, BGP peers, ...), since
> it fits well with BGP NB API.
> However, at one moment, SDN had to populate the IPs information coming
> from its VMs. The best solution was to use an other API plugged into
> ZEBRA ( and not BGP), so that this IP information could be seen as a
> remote dataplane. Here, the API is not well defined yet. Should this
> API be equipped with Yang too?
> - on the constraints between SDN and FRR. Some API require performance.
> For instance, will yang fit well when SDN retrieves thousands of
> prefix entries ?
> Remember that if you use a netconf server like netopeer, the data flow
> will look like the below:
> odl client <---> netopeer server <---> sysrepo server <---> bgp/zebra
> server
> which may not be the optimised path when you want to retrieve a lot of
> prefix entries. to be confirmed.
> There is an alternative. From document [1], figure 2 depicts a new NB
> API that bypasses sysrepo, and relies on scripts (it looks like a data
> format ( gRPC with protoBuf) carried close to sysrepo bgp data
> exchanges ( using protobuf) could be used to exchange with routing
> daemons.
> Because that path would bypass netopeer and sysrepo, while keeping a
> data format close to what is done with netconf ( though not all would
> be possible), retrieving prefix entries ( and why not configuration
> too) could be optimised. Here too, that path has to be confirmed.
> Which technology could suit well with FRR (also from licensing point
> of view..).
> Philippe
> [0]
> https://docs.google.com/presentation/d/194vUFaWxmhfTpHyANHsP66Ffw0BQuJ9sI0ir2jrXyXo/edit#slide=id.g4538793aa3_0_0
> [1] https://github.com/opensourcerouting/frr/wiki/Architecture
> On Thu, Nov 15, 2018 at 1:59 PM anzal <mohammedanz at gmail.com> wrote:
> >
> > Hi
> >
> > @Renato Westphal "
> https://github.com/opensourcerouting/frr/wiki/Architecture"
> >
> > Can this not be used to manage, configure and get updates from the FRR
> routing daemons by an external NETCONF device, say an SDN controller ?
> >
> > Like ODL has a south bound Netconf -
> https://docs.opendaylight.org/en/stable-oxygen/user-guide/netconf-user-guide.html
> >
> > So by using this I think ODL would be able to configure and get prefix
> updates from the signalling daemons in FRR. Correct me if I am wrong here.
> >
> > Thanks
> >
> > _______________________________________________
> > dev mailing list
> > dev at lists.frrouting.org
> > https://lists.frrouting.org/listinfo/dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.frrouting.org/pipermail/dev/attachments/20181120/1ed70032/attachment.html>

More information about the dev mailing list