[dev] FRR North bound API

Wed Jan 16 00:55:58 EST 2019

Hi Philippe,

The approach in the second image will be something very analogous to 
this approach right - 
https://wiki.opendaylight.org/view/Vpnservice:BGP_Stack_setup

Instead of a thrift interface, the mechanism would be gRPC.

Correct me if my understanding is wrong here.

Thanks

On 15-01-2019 06:17 PM, Philippe Guibert wrote:
> Hi Mohammed,
>
> Thanks for your interest in the interaction between ODL and FRR proposal.
> I showed the two drawings, to try to identify the gap between that
> design and the current FRR.
>
> About #2585, this is an unrelated feature request. This was for
> substituting the ZAPI interface with gRPC.
> This is different in our case; In our case, we look for having a gRPC
> northbound API. Concretely, instead of vty, this would be gRPC.
>
> The fact is that at first sight, I was thinking that the first drawing
> was the only solution to be accepted.
> Actually, the more I look with solution, the more I think there is yet a gap.
> I can expose you the gaps that I identified with solution 1.
>
> o There is first an issue in the drawing, that mixes both FIB and RIB.
>
> Currently, the remote dataplane plugin is able to configure
> remote-dataplane as FIB.
> So, one could imagine having a dataplane plugin extension as
> Southbound interface equipped with gRPC.
>
> The reverse is not possible; this is not ZEBRA FIB is configurable,
> but ZEBRA RIB.
> That implies that an other plugin extension as Northbound interface
> equipped with gRPC should be made.
> This would either be located in Zebra, or in a separate daemon.
>
> o The second issue is that ODL, when configuring the BGP layer,
> handles some pure BGP concepts.
> For instance, Route Distinguisher is a pure BGP concept. Injecting
> entries in a non BGP instance would
> mean that we hardcode the relationship between VRF and RD.
> This would mean that ODL, when injecting route entries, would inject
> per-VRF route entries, and not per-RD route entries.
>
> As other example, End-of-RIB is something handled after having
> injected a whole series of prefixes. This is a BGP marker
> that informs the protocol about the termination of the route entries.
> This is useful on graceful restart scenarios.
> Those concepts are internal to BGP, as far as I know. Using those
> marker outside of BGP will require some work.
>
> o The third issue is related to the Zebra layer.
> Having a remote dataplane plugin is not enough. Some BGP information
> is kept on BGP only, and never goes to ZEBRA layer.
> Because ODL acts as the real dataplane configurator, ODL today has not
> really the need to rely on ZEBRA layer.
> However, having remote dataplane will require some extensions to
> ZEBRA. For instance, some EVPN entries are not exported to
> the correct VRF.
>
> Actually, like the first proposal, the second drawing takes reuses
> gRPC and yang based approach, thus facilitating
> the interoperability work between ODL and FRR.
> Adding to this, the second drawing does not have the 3 above issues.
> The configuration of BGP route entries would be
> done by using BGP. Also the update of BGP route entries would be done
> by registering to yang nodes.
>
> Mohammed,
> Now that I exposed you the main problems of the first drawing, what is
> your opinion about the concrete solutions that should be applied ?
>
> Thanks,
> Philippe
>
> On Mon, Jan 14, 2019 at 3:57 PM Mohammed Anzal K via dev
> <dev at lists.frrouting.org> wrote:
>>
>>
>>
>> ---------- Forwarded message ----------
>> From: Mohammed Anzal K <mohammeda at altencalsoftlabs.com>
>> To: dev at lists.frrouting.org
>> Cc:
>> Bcc:
>> Date: Mon, 14 Jan 2019 20:26:04 +0530
>> Subject: Re: [dev] FRR North bound API
>> Hi Philippe,
>>
>> Thanks for your inputs.
>>
>> I am also interested in the use case of L3VPN/L2VPN for ODL-FRR interaction.
>>
>> I would root for the approach mentioned by you in the first slide, of interfacing the zebra daemon for prefix handling, to ODL over gRPC.
>>
>> Meanwhile, when are we planning to start with the bgpd specific north bound API related work ?
>>
>> Is there any planned timeline for this feature request         #2585 - gRPC support for Zebra
>>
>> Thanks
>>
>> Anzal
>>
>> On 19-12-2018 08:34 PM, Philippe Guibert wrote:
>>> 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
>>> _______________________________________________
>>> dev mailing list
>>> dev at lists.frrouting.org
>>> https://lists.frrouting.org/listinfo/dev
>>
>>
>>
>>
>> ---------- Forwarded message ----------
>> From: Mohammed Anzal K via dev <dev at lists.frrouting.org>
>> To: dev at lists.frrouting.org
>> Cc:
>> Bcc:
>> Date: Mon, 14 Jan 2019 06:57:46 -0800 (PST)
>> Subject: Re: [dev] FRR North bound API
>> _______________________________________________
>> 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/20190116/b2375af9/attachment.html>