[dev] Dataplane API

[Jia Chen]

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



    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://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_FRRouting_frr_pull_2292&d=DwICaQ&c=V9IgWpI5PvzTw83UyHGVSoW3Uc1MFWe5J8PTfkrzVSo&r=yetdj-aXQpuqTCJGs-93hOpK3740MIRXowfUNLByeos&m=ohGtAKMZqSpz-aUCrRZS4tooXEf324pbRrCk7OeoYls&s=ewgiTgsCBCLle8kdgudDmD3DbYfOe4nWbPaqAErRqa4&e= ).  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 at 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 at lists.frrouting.org
    > https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.frrouting.org_listinfo_dev&d=DwICaQ&c=V9IgWpI5PvzTw83UyHGVSoW3Uc1MFWe5J8PTfkrzVSo&r=yetdj-aXQpuqTCJGs-93hOpK3740MIRXowfUNLByeos&m=ohGtAKMZqSpz-aUCrRZS4tooXEf324pbRrCk7OeoYls&s=Hg3FSjSX5y6BzZMVDpl75ufOpvSr_bU2tQPwUWxXED4&e=
    >