<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<p><font face="Ubuntu">Lou,</font><br>
</p>
Add Julien Meuric in the loop (PCE WG co-chair) who work with me on
this subject.<br>
<br>
We are ready to collaborate with you to facilitate open source of
your code.<br>
How can we help ?<br>
<br>
Regards<br>
<br>
Olivier<br>
<br>
<div class="moz-cite-prefix">Le 30/05/2018 à 17:48, Lou Berger a
écrit :<br>
</div>
<blockquote type="cite"
cite="mid:245e99a9-892e-7cd4-747b-0a1956a3a5a0@labn.net">Olivier,
<br>
<br>
On 5/30/2018 10:24 AM, Olivier Dugeon wrote:
<br>
<blockquote type="cite">Hi Lou, Donald,
<br>
<br>
I have also in mind another use case: ROADM.
<br>
<br>
Indeed, optical devices may take the opportunity of FRR to
support GMPLS
<br>
(OSPF-TE + RSVP-TE). In this scenario, interface i.e. optical
ports are
<br>
also decoupled from the control plane. Optical ports that are
not yet fire
<br>
up (from an optical point of view) are not forward any packets,
so no
<br>
routing protocol, but they must be announce at the Traffic
Engineering
<br>
level at least for their availability. When a light path is
activated
<br>
tough RSVP-TE, the signalling is received by the control plane
through the
<br>
management interface, but to activate a different optical
interface.
<br>
</blockquote>
I think this is certainly workable.
<br>
<br>
as I think I mentioned before, LabN actually has some GMPLS-TE
code (including path computation and RSVP-TE) we'd love to open
source, but haven't found the time/support to strip out the
non-source compatible code and integrate with FRR.
<br>
<br>
Lou
<br>
<br>
<br>
<blockquote type="cite">
<br>
Regards
<br>
<br>
Olivier
<br>
<br>
Le 30/05/2018 à 15:29, Lou Berger a écrit :
<br>
<blockquote type="cite">Thanks Donald,
<br>
<br>
VNC/RFAPI can also be used today (with some environment
specific
<br>
integration) to support controller based models such as
defined in NVO3
<br>
where forwarders (NVEs) are completely disjoint from anything
else on
<br>
the controller. As has been discussed in the past, VNC/RFAPI
was
<br>
designed about 10 years ago with a BGP-centric optimization
approach -
<br>
and included 2 distinct parts: L3VPN VRF management and NVA
style remote
<br>
forwarder (NVE) control. We've agreed that the long term
right answer
<br>
for FRR is to separate these two, where the first stays in BGP
and the
<br>
second moves under zebra using FPM or it's successor (e.g.,
the PR
<br>
mentioned below). The first part was recently completed and
is in 5.0.
<br>
The second part remains on our todo (wish) list - and I expect
will be
<br>
facilitated by Donald's work.
<br>
<br>
Lou
<br>
<br>
On 05/30/2018 09:19 AM, Donald Sharp wrote:
<br>
<blockquote type="cite">I actually agree with both Vincent and
Lou :)
<br>
<br>
The current paradigm is a kernel based infrastructure and
will be so
<br>
for the foreseeable future. So if you are doing development
*now* I
<br>
would highly recommend working towards this paradigm. So
Vincent is
<br>
correct.
<br>
<br>
Having said that, we are looking towards more formally
defining the
<br>
DataPlane API so that it becomes possible to allow a fully
implemented
<br>
dataplane api that if someone wanted to implement non-kernel
based
<br>
interfaces they could. So Lou is correct too!
<br>
<br>
There is a lot of work here though, mainly of a
infrastructure
<br>
updates. I've currently (slowly) started trying to define
this api(
<br>
See <a class="moz-txt-link-freetext" href="https://github.com/FRRouting/frr/pull/2292">https://github.com/FRRouting/frr/pull/2292</a> ). The
current api
<br>
line for the dataplane is fuzzy at best and lots of
assumptions are
<br>
made about behavior and how data structures are created.
This line
<br>
must be wedged apart as a first step. If you are unsure
where to
<br>
start here, please ask and we'll have suggestions. We also
have
<br>
additional goals for zebra such as true pthreads and
nexthop-group
<br>
route entry indirection to name a few.
<br>
<br>
Please note we are not doing this work specifically to allow
a full
<br>
dataplane outside of a kernel, it should fall out if I do
the work
<br>
correctly for what I am interested in. I am doing this work
because I
<br>
think this work will allow me to do some work with
route-aggregation
<br>
as well as more efficiently pass data to the kernel for
route
<br>
installs. I'm sure other people have their own reasons,
just as long
<br>
as we keep those in mind and work together.
<br>
<br>
thanks!
<br>
<br>
donald
<br>
<br>
On Tue, May 29, 2018 at 3:04 PM, Jay Chen
<a class="moz-txt-link-rfc2396E" href="mailto:jchen1@paloaltonetworks.com"><jchen1@paloaltonetworks.com></a> wrote:
<br>
<blockquote type="cite">A quick question about FRR
interfaces. The Zebra get interface information/status
from Kernel.
<br>
<br>
In our platform, it is almost impossible to put interface
into kernel (due to history reasons people object to do
so). Is there anyone else facing the same situation and
any suggestions for a work around? Or anything similarly
to FPM existing for interface to bypass kernel (from
interface manager to Zebra instead)?
<br>
<br>
Thanks,
<br>
Jay
<br>
<br>
<br>
</blockquote>
_______________________________________________
<br>
dev mailing list
<br>
<a class="moz-txt-link-abbreviated" href="mailto:dev@lists.frrouting.org">dev@lists.frrouting.org</a>
<br>
<a class="moz-txt-link-freetext" href="https://lists.frrouting.org/listinfo/dev">https://lists.frrouting.org/listinfo/dev</a>
<br>
<br>
</blockquote>
_______________________________________________
<br>
dev mailing list
<br>
<a class="moz-txt-link-abbreviated" href="mailto:dev@lists.frrouting.org">dev@lists.frrouting.org</a>
<br>
<a class="moz-txt-link-freetext" href="https://lists.frrouting.org/listinfo/dev">https://lists.frrouting.org/listinfo/dev</a>
<br>
</blockquote>
<br>
<br>
</blockquote>
<br>
<br>
</blockquote>
<br>
</body>
</html>