Lou,
Olivier,
On 5/30/2018 10:24 AM, Olivier Dugeon wrote:
Hi Lou, Donald,I think this is certainly workable.
I have also in mind another use case: ROADM.
Indeed, optical devices may take the opportunity of FRR to support GMPLS
(OSPF-TE + RSVP-TE). In this scenario, interface i.e. optical ports are
also decoupled from the control plane. Optical ports that are not yet fire
up (from an optical point of view) are not forward any packets, so no
routing protocol, but they must be announce at the Traffic Engineering
level at least for their availability. When a light path is activated
tough RSVP-TE, the signalling is received by the control plane through the
management interface, but to activate a different optical interface.
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.
Lou
Regards
Olivier
Le 30/05/2018 à 15:29, Lou Berger a écrit :
Thanks Donald,
VNC/RFAPI can also be used today (with some environment specific
integration) to support controller based models such as defined in NVO3
where forwarders (NVEs) are completely disjoint from anything else on
the controller. As has been discussed in the past, VNC/RFAPI was
designed about 10 years ago with a BGP-centric optimization approach -
and included 2 distinct parts: L3VPN VRF management and NVA style remote
forwarder (NVE) control. We've agreed that the long term right answer
for FRR is to separate these two, where the first stays in BGP and the
second moves under zebra using FPM or it's successor (e.g., the PR
mentioned below). The first part was recently completed and is in 5.0.
The second part remains on our todo (wish) list - and I expect will be
facilitated by Donald's work.
Lou
On 05/30/2018 09:19 AM, Donald Sharp wrote:
I actually agree with both Vincent and Lou :)_______________________________________________
The current paradigm is a kernel based infrastructure and will be so
for the foreseeable future. So if you are doing development *now* I
would highly recommend working towards this paradigm. So Vincent is
correct.
Having said that, we are looking towards more formally defining the
DataPlane API so that it becomes possible to allow a fully implemented
dataplane api that if someone wanted to implement non-kernel based
interfaces they could. So Lou is correct too!
There is a lot of work here though, mainly of a infrastructure
updates. I've currently (slowly) started trying to define this api(
See https://github.com/FRRouting/frr/pull/2292 ). The current api
line for the dataplane is fuzzy at best and lots of assumptions are
made about behavior and how data structures are created. This line
must be wedged apart as a first step. If you are unsure where to
start here, please ask and we'll have suggestions. We also have
additional goals for zebra such as true pthreads and nexthop-group
route entry indirection to name a few.
Please note we are not doing this work specifically to allow a full
dataplane outside of a kernel, it should fall out if I do the work
correctly for what I am interested in. I am doing this work because I
think this work will allow me to do some work with route-aggregation
as well as more efficiently pass data to the kernel for route
installs. I'm sure other people have their own reasons, just as long
as we keep those in mind and work together.
thanks!
donald
On Tue, May 29, 2018 at 3:04 PM, Jay Chen <jchen1@paloaltonetworks.com> wrote:
A quick question about FRR interfaces. The Zebra get interface information/status from Kernel._______________________________________________
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)?
Thanks,
Jay
dev mailing list
dev@lists.frrouting.org
https://lists.frrouting.org/listinfo/dev
dev mailing list
dev@lists.frrouting.org
https://lists.frrouting.org/listinfo/dev