[dev] FRR North bound API

Philippe Guibert philippe.guibert at 6wind.com
Wed Dec 19 10:04:29 EST 2018


Hi Anzal,

About your question related to ODL-FRR interaction, may I know if you
have a specific ODL service in mind ?

I have come up with design proposals on ODL/FRR interaction for L3VPN
and L2VPN in ODL service.
Main points are:
- rely on the new yang NB API ( using GRPc technology).
- optional : extend L3VPN/L2VPN to Zebra, via remote dataplane

You can find specific proposal in [0]

Anzal, or everyone else in the FRR community,
your comments are welcome,

Thanks,

Philippe

[0] https://docs.google.com/presentation/d/18LkCGc8HAXto-c5IRT0NUBLmKRBYM6Oq6D5QNk_W-_k/edit#slide=id.g49ea94a8e7_0_0

On 11/21/18, Jeff Tantsura <jefftant at gmail.com> wrote:
> 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
>
>



More information about the dev mailing list