[dev] FRR North bound API

[Jeff Tantsura]

Hi,

Netconf is a configuration protocol and is not particularly suitable for streaming data, one could use YANG-push(https://tools.ietf.org/html/draft-ietf-netconf-yang-push-20), has been implemented in ODL’ Baron release (https://docs.opendaylight.org/en/stable-boron/user-guide/yang-push.html)
however - general performance implications apply, 
gRPC on another hand is de-facto industry standard for streaming telemetry
OpenConfig has defined number of frameworks.
Specifically for prefix injection, gRIBI (https://github.com/openconfig/gribi/blob/master/doc/motivation.md) could be considered, this what we (IETF) envisioned with I2RS effort but, reality is different.  

Cheers,
Jeff
 

> On Nov 17, 2018, at 12:26 AM, 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
> 
> _______________________________________________
> dev mailing list
> dev at lists.frrouting.org
> https://lists.frrouting.org/listinfo/dev