[dev] Dataplane API

[Mark Stapp]

This is an interesting case - and I have to say that I have been focussed
on the zebra-to-dataplane path, and haven't given much thought to the
inbound path yet (and there are several kinds of info that flow _into_
zebra). a couple of things:

0. if the interfaces aren't in the kernel ... does that mean the daemons
don't use them?

1. the general software model that I've been trying to work with is that
there will be some fairly neutral data structure that represents the
information that's being exchanged between the vendor-specific and frr
sides of the system. for incoming notifications, those structures will be
queued towards the main zebra processing context/pthread - the vendor
plugin will be running in a different pthread/context. the transport and
marshalling between your own system and frr is your own business - a plugin
will need to deal with that, and it sounds like you're already on that
path. at some point, we'll add the 'interface notification' type, migrate
the existing code to use it, and make it available to plugins.

2. you used the phrase "interface configurations", and I just want to
clarify that a bit. incoming configuration is going to be using the
management api, imo - not some special zebra-specific path. there's work
going on to provide a comprehensive "northbound" management interface. the
existence of a device is sort of a special case, and that's the case that
will need some specific handling.

Cheers,
Mark


On Fri, Jul 20, 2018 at 5:04 PM, Jia Chen <jchen1 at paloaltonetworks.com>
wrote:

> In order to port FRR to our firewall/router platform, two things need to
> be differ from the current FRR paradigm. One is that we have a data plane
> and hardware forwarding. The other one is that we have an interface manager
> for interface configurations and their up/down status update.
>
> For the first one, we are able to use FPM mechanism and successfully
> redirect FIB from Zebra to our data plane.
>           Zebra(FIB via. FPM) --- routed --- data plane
>
> For interfaces, we are developing the API from “routed(IFM) to Zebra”. I
> would like to start the discussion here, such that our development can be
> aligned with FRR and can be contributed back to FRR.
>
> A. A TCP connection between Routed and Zebra, that handle bidirectional
> communications about request (from Zebra) and reply (from routed)
> B. At Zebra start/restart, requests to Routed about interfaces
> (interfaces, IP addresses, interface up/down status)
> C. Routed IFM (interface manager) reply to the requests with all interface
> information requested (formatted same as if it comes from kernel)
> D. If Routed restart (IFM), once the TCP connection re-established, routed
> will resend all configured interfaces to Zebra
>
> This is what we are planning to handle the interface are not in the kernel
> case.
>
> Please share your thought, any comments, questions, caveat, or
> suggestions? I remember Donald have investigated some a while back,
> anything we should watch for?
>
> Thanks,
> Jay
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.frrouting.org/pipermail/dev/attachments/20180723/ba7f73cb/attachment.html>