<div dir="ltr"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div dir="ltr"><br>Hi<div><br></div><div>Thanks a lot for your insights.</div><div><br></div><div>I happened to glance over a report regarding the performance of the ODL southbound netconf interface. Please see</div><div><br></div><div><a href="https://wiki.opendaylight.org/view/NETCONF:Testing#NETCONF_southbound_performance_test" target="_blank">https://wiki.opendaylight.org/view/NETCONF:Testing#NETCONF_southbound_performance_test</a><br></div><div><br></div><div>I do understand that optimizations will be needed in the path you referred</div><div><div><p class="MsoNormal"><span style="font-size:10pt;font-family:Tahoma,sans-serif;color:rgb(77,77,77)"><br></span></p><p class="MsoNormal"><span style="font-size:10pt;font-family:Tahoma,sans-serif;color:rgb(77,77,77)">odl client <-</span><span style="font-size:10pt;font-family:Tahoma,sans-serif"><font color="#0000ff">--> netopeer server <---> sysrepo server <---></font></span><span style="font-size:10pt;font-family:Tahoma,sans-serif;color:rgb(77,77,77)"> bgp/zebra server</span></p><p class="MsoNormal"><span style="font-size:10pt;font-family:Tahoma,sans-serif;color:rgb(77,77,77)"><br></span></p><p class="MsoNormal"><font color="#4d4d4d" face="Tahoma, sans-serif"><span style="font-size:10pt">But </span><span style="font-size:13.3333px">wouldn't</span><span style="font-size:10pt"> this report justify that a yang based model can help with cases of handling 10K prefix updates.</span></font></p><p class="MsoNormal"><span style="font-size:10pt;font-family:Tahoma,sans-serif;color:rgb(77,77,77)"><br></span></p><p class="MsoNormal"><span style="font-size:10pt;font-family:Tahoma,sans-serif;color:rgb(77,77,77)">What are your thoughts.</span></p></div></div><div><br></div><div><br></div><div>Regards</div><div><br></div><div>Anzal</div></div></div><br><div class="gmail_quote"><div dir="ltr">On Sat, Nov 17, 2018 at 1:56 PM Philippe Guibert <<a href="mailto:philippe.guibert@6wind.com" target="_blank">philippe.guibert@6wind.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Anzal,<br>
<br>
I agree with your proposal, with some concerns however.<br>
<br>
I presented a few weeks ago at FRR weekly meetings, some slides about<br>
what would be the mechanisms involved for an SDN controller to be able<br>
to use FRR as BGP speaker. ODL can be the target, obviously. See in<br>
[0]<br>
<br>
The yang solution applied to BGP northbound API has been proposed.<br>
<br>
However, there were two remarks:<br>
- on the data exchanged between SDN and FRR.<br>
What was ok was for configuration ( BGP, VPN, BGP peers, ...), since<br>
it fits well with BGP NB API.<br>
<br>
However, at one moment, SDN had to populate the IPs information coming<br>
from its VMs. The best solution was to use an other API plugged into<br>
ZEBRA ( and not BGP), so that this IP information could be seen as a<br>
remote dataplane. Here, the API is not well defined yet. Should this<br>
API be equipped with Yang too?<br>
<br>
- on the constraints between SDN and FRR. Some API require performance.<br>
For instance, will yang fit well when SDN retrieves thousands of<br>
prefix entries ?<br>
<br>
Remember that if you use a netconf server like netopeer, the data flow<br>
will look like the below:<br>
odl client <---> netopeer server <---> sysrepo server <---> bgp/zebra server<br>
<br>
which may not be the optimised path when you want to retrieve a lot of<br>
prefix entries. to be confirmed.<br>
<br>
There is an alternative. From document [1], figure 2 depicts a new NB<br>
API that bypasses sysrepo, and relies on scripts (it looks like a data<br>
format ( gRPC with protoBuf) carried close to sysrepo bgp data<br>
exchanges ( using protobuf) could be used to exchange with routing<br>
daemons.<br>
Because that path would bypass netopeer and sysrepo, while keeping a<br>
data format close to what is done with netconf ( though not all would<br>
be possible), retrieving prefix entries ( and why not configuration<br>
too) could be optimised. Here too, that path has to be confirmed.<br>
Which technology could suit well with FRR (also from licensing point<br>
of view..).<br>
<br>
Philippe<br>
<br>
[0] <a href="https://docs.google.com/presentation/d/194vUFaWxmhfTpHyANHsP66Ffw0BQuJ9sI0ir2jrXyXo/edit#slide=id.g4538793aa3_0_0" rel="noreferrer" target="_blank">https://docs.google.com/presentation/d/194vUFaWxmhfTpHyANHsP66Ffw0BQuJ9sI0ir2jrXyXo/edit#slide=id.g4538793aa3_0_0</a><br>
[1] <a href="https://github.com/opensourcerouting/frr/wiki/Architecture" rel="noreferrer" target="_blank">https://github.com/opensourcerouting/frr/wiki/Architecture</a><br>
On Thu, Nov 15, 2018 at 1:59 PM anzal <<a href="mailto:mohammedanz@gmail.com" target="_blank">mohammedanz@gmail.com</a>> wrote:<br>
><br>
> Hi<br>
><br>
> @Renato Westphal "<a href="https://github.com/opensourcerouting/frr/wiki/Architecture" rel="noreferrer" target="_blank">https://github.com/opensourcerouting/frr/wiki/Architecture</a>"<br>
><br>
> 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 ?<br>
><br>
> Like ODL has a south bound Netconf - <a href="https://docs.opendaylight.org/en/stable-oxygen/user-guide/netconf-user-guide.html" rel="noreferrer" target="_blank">https://docs.opendaylight.org/en/stable-oxygen/user-guide/netconf-user-guide.html</a><br>
><br>
> 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.<br>
><br>
> Thanks<br>
><br>
> _______________________________________________<br>
> dev mailing list<br>
> <a href="mailto:dev@lists.frrouting.org" target="_blank">dev@lists.frrouting.org</a><br>
> <a href="https://lists.frrouting.org/listinfo/dev" rel="noreferrer" target="_blank">https://lists.frrouting.org/listinfo/dev</a><br>
</blockquote></div>
</blockquote></div></div>