<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body text="#666666" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">Hi Philippe,</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix">The approach in the second image will
be something very analogous to this approach right -
<a class="moz-txt-link-freetext" href="https://wiki.opendaylight.org/view/Vpnservice:BGP_Stack_setup">https://wiki.opendaylight.org/view/Vpnservice:BGP_Stack_setup</a></div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix">Instead of a thrift interface, the
mechanism would be gRPC. <br>
</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix">Correct me if my understanding is wrong
here.<br>
</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix">Thanks</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix">On 15-01-2019 06:17 PM, Philippe
Guibert wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CABkgeBML9FpuXY1S=EPVTtusMTY7vmKQjuM4h9TGA9a3Z7f+kA@mail.gmail.com">
<pre class="moz-quote-pre" wrap="">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
<a class="moz-txt-link-rfc2396E" href="mailto:dev@lists.frrouting.org"><dev@lists.frrouting.org></a> wrote:
</pre>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">
---------- Forwarded message ----------
From: Mohammed Anzal K <a class="moz-txt-link-rfc2396E" href="mailto:mohammeda@altencalsoftlabs.com"><mohammeda@altencalsoftlabs.com></a>
To: <a class="moz-txt-link-abbreviated" href="mailto:dev@lists.frrouting.org">dev@lists.frrouting.org</a>
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:
</pre>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">
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] <a class="moz-txt-link-freetext" href="https://docs.google.com/presentation/d/18LkCGc8HAXto-c5IRT0NUBLmKRBYM6Oq6D5QNk_W-_k/edit#slide=id.g49ea94a8e7_0_0">https://docs.google.com/presentation/d/18LkCGc8HAXto-c5IRT0NUBLmKRBYM6Oq6D5QNk_W-_k/edit#slide=id.g49ea94a8e7_0_0</a>
On 11/21/18, Jeff Tantsura <a class="moz-txt-link-rfc2396E" href="mailto:jefftant@gmail.com"><jefftant@gmail.com></a> wrote:
</pre>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">
Hi,
Netconf is a configuration protocol and is not particularly suitable for
streaming data, one could use
YANG-push(<a class="moz-txt-link-freetext" href="https://tools.ietf.org/html/draft-ietf-netconf-yang-push-20">https://tools.ietf.org/html/draft-ietf-netconf-yang-push-20</a>), has
been implemented in ODL’ Baron release
(<a class="moz-txt-link-freetext" href="https://docs.opendaylight.org/en/stable-boron/user-guide/yang-push.html">https://docs.opendaylight.org/en/stable-boron/user-guide/yang-push.html</a>)
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
(<a class="moz-txt-link-freetext" href="https://github.com/openconfig/gribi/blob/master/doc/motivation.md">https://github.com/openconfig/gribi/blob/master/doc/motivation.md</a>) could be
considered, this what we (IETF) envisioned with I2RS effort but, reality is
different.
Cheers,
Jeff
</pre>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">On Nov 17, 2018, at 12:26 AM, Philippe Guibert
<a class="moz-txt-link-rfc2396E" href="mailto:philippe.guibert@6wind.com"><philippe.guibert@6wind.com></a> 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]
<a class="moz-txt-link-freetext" href="https://docs.google.com/presentation/d/194vUFaWxmhfTpHyANHsP66Ffw0BQuJ9sI0ir2jrXyXo/edit#slide=id.g4538793aa3_0_0">https://docs.google.com/presentation/d/194vUFaWxmhfTpHyANHsP66Ffw0BQuJ9sI0ir2jrXyXo/edit#slide=id.g4538793aa3_0_0</a>
[1] <a class="moz-txt-link-freetext" href="https://github.com/opensourcerouting/frr/wiki/Architecture">https://github.com/opensourcerouting/frr/wiki/Architecture</a>
On Thu, Nov 15, 2018 at 1:59 PM anzal <a class="moz-txt-link-rfc2396E" href="mailto:mohammedanz@gmail.com"><mohammedanz@gmail.com></a> wrote:
</pre>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">
Hi
@Renato Westphal
<a class="moz-txt-link-rfc2396E" href="https://github.com/opensourcerouting/frr/wiki/Architecture">"https://github.com/opensourcerouting/frr/wiki/Architecture"</a>
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 -
<a class="moz-txt-link-freetext" href="https://docs.opendaylight.org/en/stable-oxygen/user-guide/netconf-user-guide.html">https://docs.opendaylight.org/en/stable-oxygen/user-guide/netconf-user-guide.html</a>
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
<a class="moz-txt-link-abbreviated" href="mailto:dev@lists.frrouting.org">dev@lists.frrouting.org</a>
<a class="moz-txt-link-freetext" href="https://lists.frrouting.org/listinfo/dev">https://lists.frrouting.org/listinfo/dev</a>
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">
_______________________________________________
dev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:dev@lists.frrouting.org">dev@lists.frrouting.org</a>
<a class="moz-txt-link-freetext" href="https://lists.frrouting.org/listinfo/dev">https://lists.frrouting.org/listinfo/dev</a>
</pre>
</blockquote>
</blockquote>
<pre class="moz-quote-pre" wrap="">
_______________________________________________
dev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:dev@lists.frrouting.org">dev@lists.frrouting.org</a>
<a class="moz-txt-link-freetext" href="https://lists.frrouting.org/listinfo/dev">https://lists.frrouting.org/listinfo/dev</a>
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">
---------- Forwarded message ----------
From: Mohammed Anzal K via dev <a class="moz-txt-link-rfc2396E" href="mailto:dev@lists.frrouting.org"><dev@lists.frrouting.org></a>
To: <a class="moz-txt-link-abbreviated" href="mailto:dev@lists.frrouting.org">dev@lists.frrouting.org</a>
Cc:
Bcc:
Date: Mon, 14 Jan 2019 06:57:46 -0800 (PST)
Subject: Re: [dev] FRR North bound API
_______________________________________________
dev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:dev@lists.frrouting.org">dev@lists.frrouting.org</a>
<a class="moz-txt-link-freetext" href="https://lists.frrouting.org/listinfo/dev">https://lists.frrouting.org/listinfo/dev</a>
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">
</pre>
</blockquote>
<p><br>
</p>
</body>
</html>