[dev] Dataplane API

Jia Chen jchen1 at paloaltonetworks.com
Fri Jun 22 11:05:32 EDT 2018


Continue on this topic. 
For our POC of FRRrouting, we have two issues to differ a little bit. 
A. FIB push to separate data plane instead to kernel
B. Interface come from “interface manager” other than from kernel

For A, what we have done is to add a FPM server. It works with Zebra FPM client. Now we can push the FIB to our data plane. 

For B, I would like to start a discussion here. If we are going to use the same FPM server/client, and send the interface info from server to zebra client. Will that be doable as a quick work around? 

Let us know if something for B is already done or any other suggestions? 

If any change we have to do to Zebra, we would like it to upstream the change 

Thanks,
Jay



On 5/30/18, 10:45 AM, "Lou Berger" <lberger at labn.net> wrote:

    Olivier, Julien,
    
         Great! Let's setup a time to talk.  Drop me a line off list to 
    coordinate time - please suggest some times next week.
    
    All,
    
         drop me a line if interested in participating (I'll start a doodle 
    if enough are interested).
    
    Lou
    
    On 5/30/2018 12:57 PM, Olivier Dugeon wrote:
    >
    > Lou,
    >
    > Add Julien Meuric in the loop (PCE WG co-chair) who work with me on 
    > this subject.
    >
    > We are ready to collaborate with you to facilitate open source of your 
    > code.
    > How can we help ?
    >
    > Regards
    >
    > Olivier
    >
    > Le 30/05/2018 à 17:48, Lou Berger a écrit :
    >> Olivier,
    >>
    >> On 5/30/2018 10:24 AM, Olivier Dugeon wrote:
    >>> Hi Lou, Donald,
    >>>
    >>> 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.
    >> I think this is certainly workable.
    >>
    >> 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://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_FRRouting_frr_pull_2292&d=DwIDaQ&c=V9IgWpI5PvzTw83UyHGVSoW3Uc1MFWe5J8PTfkrzVSo&r=yetdj-aXQpuqTCJGs-93hOpK3740MIRXowfUNLByeos&m=oroD23WZarzqhyLy-lyk4mmKW0gjOlokZHSgpmovWjM&s=ZHk17U36FHxN1aPPG-8cS3YKE-yzJ2gO4mBdoolERtA&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=DwIDaQ&c=V9IgWpI5PvzTw83UyHGVSoW3Uc1MFWe5J8PTfkrzVSo&r=yetdj-aXQpuqTCJGs-93hOpK3740MIRXowfUNLByeos&m=oroD23WZarzqhyLy-lyk4mmKW0gjOlokZHSgpmovWjM&s=z6t2zbG-086lVcc49t8hSe6N8cmWt559HWcWLGS5UI4&e=
    >>>>>
    >>>> _______________________________________________
    >>>> dev mailing list
    >>>> dev at lists.frrouting.org
    >>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.frrouting.org_listinfo_dev&d=DwIDaQ&c=V9IgWpI5PvzTw83UyHGVSoW3Uc1MFWe5J8PTfkrzVSo&r=yetdj-aXQpuqTCJGs-93hOpK3740MIRXowfUNLByeos&m=oroD23WZarzqhyLy-lyk4mmKW0gjOlokZHSgpmovWjM&s=z6t2zbG-086lVcc49t8hSe6N8cmWt559HWcWLGS5UI4&e=
    >>>
    >>>
    >>
    >>
    >
    
    



More information about the dev mailing list