[dev] FRR North bound API

[anzal]

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

https://wiki.opendaylight.org/view/NETCONF:Testing#NETCONF_southbound_performance_test

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.


Regards

Anzal

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

> 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>