[dev] Dataplane API

Lou Berger lberger at labn.net
Wed May 30 13:11:02 EDT 2018


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://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 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://lists.frrouting.org/listinfo/dev
>>>>>
>>>> _______________________________________________
>>>> dev mailing list
>>>> dev at lists.frrouting.org
>>>> https://lists.frrouting.org/listinfo/dev
>>>
>>>
>>
>>
>




More information about the dev mailing list