[dev] FRR North bound API

[anzal]

>
>
> Hi
>
> 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/20181121/6b870bae/attachment.html>